以下文章来源于智能汽车开发者平台
摘要
现代汽车中软件的复杂性迅速增加，这决定了电气和/或电子（E/E）汽车架构的新趋势。因此，许多原始设备制造商（OEM）和供应商一直主张将集中式E/E架构作为未来的汽车架构。在本文中，我们提出了在汽车工业中采用集中式E/E架构的理由。我们通过仔细研究传统分散式汽车E/E架构的挑战和缺点，并与集中式架构带来的相应好处进行对比，来讨论集中化架构方案的动机。然后，我们详细讨论了支持新的集中式结构所需的技术。我们介绍了网络技术、虚拟化、电子控制单元（ECU）硬件和AUTOSAR方面的技术现状，并讨论了这些技术在工业中的采用情况。自始至终，功能安全都是作为汽车行业的首要问题来考虑和解决的。
1 介绍
在自动驾驶、交互、电气化和智能交通等行业趋势的推动下，现代汽车所需功能的范围和复杂性在持续不断增加。此外，为了遵守汽车标准(如AUTOSAR和ISO 26262)的要求，以及应对当前和未来的行业需求，传统的汽车分散式电气和/或电子(E/E)架构面临着越来越大的挑战。在分散式E/E架构中，嵌入式车辆功能分布在大量相互连接的电子控制单元（ECU）中，每个ECU都能处理自己的数据并与其他ECU进行通信，以实现高级车辆功能。
虽然长期以来分散式架构有一些优势，但它们也存在严重的缺点，最明显缺陷集中在可扩展性和通信性能方面。传统的分散式架构大多在车辆功能和ECU之间是一对一的映射，这导致越来越多的汽车拥有超过100个ECU，用以执行大约1.5亿行代码。当一个功能由多个协同ECU实现时，车载网络的通信负荷会增加。由于存在大量的ECU和笨重的线束，为单个功能添加单独的ECU的做法导致了成本的大幅增加。这种做法进一步增加了汽车ECU的软件复杂性和大量的软件变体。因此，汽车开发正面临着巨大的开发和维护成本，以及可能错过项目里程碑。
为了解决分散式E/E架构的局限性，近期，汽车E/E架构开始向集中式替代方案发展，如领域集中式（或称面向领域）、跨域集中式（或称面向跨域）和车辆集中式（或称面向区域）架构。面向领域、面向跨域和面向区域的架构统称为称为集中式架构。集中式架构的基本思想是集中处理车辆中各个域、域组或整车级别上的功能。这一演变受到了航空工业从联合架构（即分散架构）到集成架构（即集中架构）的成功过渡的影响。
现代集中式E/E架构的运行需要多种技术支持。为了支持日益复杂的车辆功能，需要具有增强的处理能力的ECU，同时这些ECU必须满足功能安全和安保的硬件规定。此外，需要改进通信网络，提高带宽、实时和流量分区能力、容错机制、先进的网关（即旨在利用基于硬件的加速技术减少延迟和提高吞吐量的网关）和增强安全措施，以支持日益智能化的运输系统的要求。
虽然一些汽车原始设备制造商（如宝马、大众和捷豹路虎）和汽车供应商（如德尔福、恩智浦和博世）已经将集中化的解决方案商业化，并主张将集中化作为未来的E/E架构趋势，但其他汽车公司仍处于实验的早期阶段。在本文中，我们给出了将集中化作为未来汽车的E/E架构模式的理由，它将解决上述传统的分散式架构所面临的可扩展性问题。
我们仔细研究了集中式架构的关键使能技术，以证明有足够的技术临界质量，使集中化成为E/E架构中各个领域和应用的可行解决方案。在本文中，我们反思了集中式架构及其使能技术对汽车功能安全的影响，这也是汽车行业最关注的问题之一。
本文的其余部分组织如下。
第二节阐述了集中化的必要性，并概述了现代E/E架构的基本概念以及它们在汽车行业的应用。
第三节介绍了ISO 26262功能安全标准的基本功能安全注意事项和概念，之后在本文中用于讨论集中化对功能安全的影响。
第四节详细介绍了集中式E/E架构的关键使能技术。
第五节讨论了本文的要点，同时指出了集中化样E/E架构时可能面临的挑战。
第六节对这项研究进行了总结。
2 E/E 架构的现状：
动机、基本概念和挑战
本节介绍了集中式汽车E/E架构的动机。随后介绍了架构中的基本概念。最后，讨论了集中式E/E解决方案在汽车工业中的应用。
A. 必要性
车辆E/E架构包括ECU、传感器、制动器及其所有互连设备，以及电气网络(如高压网络、电力电子)和信息娱乐系统(如消费电子元件)。传统上，车辆E/E架构是分散式的。
分散式车辆E/E架构有一些优点。例如，分散式结构本质上支持ECU之间分离：它们允许在单个ECU上部署一个或几个非常紧密相关的功能。这使得验证ECU集成到网络的条件相对简单，主要是确保所需总线带宽的可用性和检查通信信息的简单时序要求。此外，更换损坏的ECU很容易，因为ECU很轻，很多功能没法实现。对于每个ECU，可以使用具有平均处理能力的CPU，因为每个ECU封装的功能有限。然而，分散式架构存在一些限制。
首先，在现代汽车软件实现的功能迅速和稳步上升的时代，"每个ECU一个功能 "的方法已被证明是行不通的。为单个功能增加单独的ECU会导致成本增加，因为需要额外的ECU及其线束存根。线束长度的增加进一步引入了一个不必要的副作用，即限制了架构物理布局的自由，因此在优化最终架构时会受到更严格的限制。此外，传统的E/E架构大多使用CAN（控制器区域网络）组网，但也依赖FlexRay、LIN（本地互连网络）和MOST（面向媒体的系统传输）。虽然这些网络技术足以用于传统的通信，但由于预期的数据量和不同ECU之间的互连数量，预计在不久的将来它们将不再适用。然而，尽管汽车以太网不被认为是一种传统的汽车通信技术，但在过去的十年中，它在汽车网络中的应用已经稳步上升。汽车以太网能够支持大量的数据，以及具有功能安全要求的时间关键型通信。我们的观点，也是许多其他作者（例如Matheus和Königseder）的观点，即汽车以太网是未来汽车网络的通信技术，尽管它不会是未来汽车所采用的唯一通信技术。汽车以太网的使用将是向集中式架构发展的主要驱动力之一。
如今，为不同的细分市场构建不同的车型意味着需要发布大量的软件，并且可能需要构建多个架构来支持不同的车型特性。因此，目前市场要求的多样性意味着需要一个多功能的、具有成本效益的E/E架构解决方案。这个解决方案需要处理大量的车型，这些车型都是由客户的期望引起的，例如，个性化的舒适功能，以及对自动驾驶辅助系统(ADAS)等自动支持的依赖。这增加了所需提供的车型的数量。此外，目前汽车生产线支持各种市场、技术和配置（例如，不同的动力系统架构、不同的硬件平台和来自不同供应商的部件）。在减少支持大型汽车软件产品线所需的软件发布数量方面，E/E集中化具有很大的潜力，这一点将在下一节讨论。
此外，当前的 E/E 架构解决方案不一定设计为对外部恶意攻击具有鲁棒性。考虑到车辆与外界的连接不断增加，未来的车辆架构需要保证这些安全特性。
除了这些缺点，原始设备制造商和供应商采取的策略也影响了E/E架构的演变趋势。例如，除了要求原始设备制造商和供应商与汽车标准(如AUTOSAR, ISO 26262)兼容外，原始设备制造商还依赖越来越多的供应商提供的软件和硬件。在需求的驱使下，他们不得不整合改进的技术，如先进的高清显示器、快速网络和执行高端功能的新ECU。但目前的架构不够灵活，无法让OEM厂商轻松整合新的、多样化的技术。
上述驱动因素促使汽车行业研究更加集中的汽车E/E架构解决方案，如前面介绍的领域集中式、跨域集中式和车辆集中式（或面向区域）的架构。本节中介绍的行业向集中式E/E架构转变的动机，可以通过下一节介绍的一些基本例子和结果来进一步确定。
B. 动因分析
1) 不同处理要求:对大型汽车生产线进行成本效益的处理，是业界寻找新的E/E架构解决方案的主要动力。例如，一个大型汽车OEM的引擎控制器软件支持三种不同的引擎，在分散式E/E架构中可以生成144个软件/校准版本。在一个集中的、面向领域的架构中，一个强大的（领域）控制器承载了控制器的大部分功能，而一个非常简单的智能执行器只捕捉硬件变化（不同引擎之间的差异和底层硬件平台之间的差异），领域控制器的发布数量将减少到72个，智能执行器为3个，合计为75个。
作为集中式架构支持汽车软件产品线的成本效益开发的另一个例子，我们可以考虑一个汽车系统需求的案例，该需求因地理区域的不同而不同。在美国，汽车在被关闭时不能滑动，其法规要求 “... 启动系统必须防止按键被移除... 除非变速器或齿轮选择控制被锁定在‘停车’”。印尼等国家的规定可能会有不一样要求，即 “车辆可以关闭钥匙，然后进入空挡，前提是司机被通知并明确接受关闭变速器的状态。” 这一区域性要求允许车辆在自动停车库或停车空间有限的地方关闭钥匙后仍可滚动。
在分散式架构的插电式混合动力汽车中，这个简单的需求变化可能需要对大量ECU进行软件修改：
1) 车身控制模块(BCM)，它监控按键和电源开关用户界面，并更新变速器位置显示，包括接受用户确认的特殊齿轮选择模式；
2) 变速器控制模块（TCM），它与换挡器连接并控制变速器，同时可能与一个单独的电子驻车ECU连接，该ECU控制驻车棘爪，将传动系统锁定在适当的位置；
3) 混合动力监督控制器（HSC），它协调混合动力电动驱动系统的整体控制；
4) 电池管理系统（BMS），即电池控制器，在美国版本中，可能只允许在停放棘爪啮合时充电。
所有这些组件都可能需要在生产印尼车辆时更新软件版本。例如，BCM的用户界面必须进行修改，以允许汽车在空档状态下关闭，向司机发出警报，并等待司机的明确确认。为了允许在空挡状态下关闭钥匙，HSC和TCM必须进行适当的修改，以适应需求的变化。此外，印尼版的BMS可能会实现更多衍生的要求，即 "如果汽车在停车时正在充电，则在插入时需要停车制动"，因为美国版的BMS出于安全原因不允许在非停车状态下充电。
总的来说，受影响的ECU的数量相对比较多。在分散式架构中，前面提到的模块通常位于独立的ECU上。随着动力总成领域的集中化，例如，TCM、电机控制模块（MCM）、BMS和HSC的可变功能将被整合到一个ECU上：在分散式架构中对这些模块的所有必要修改现在将集中在一个ECU上，导致一个单一的软件版本捕获这四个模块的变化。随着进一步的集中化，例如将底盘和HMI（人机界面）合并到BCM中，将所有详细的动力总成要求合并到HSC中，由TCM、BMS和MCM作为智能执行器发挥作用，只需要更新用于用户界面的BCM和用于其余功能的HSC。所有的智能执行器代码可以保持不变。因此，领域控制器架构不需要分散式架构的四、五个ECU软件版本，而只需要两个版本。
2) 一项研究:另外一个例子是，Kanajan等人的早期的一项研究比较了四种不同的E/E架构，涵盖了包括控制和I/O的集中化程度。在他们的研究中，集中式控制与本文讨论的概念相同，而集中式I/O是指一个特定的传感器或执行器是否直接连接到控制器（“集中式”），或作为一个智能执行器连接到通信网络（“分散式”）。到目前为止，在本文中，我们完全专注于智能执行器，在他们的术语中是 "分散式"。
Kanajan等人考虑的四种架构分别是CICC(集中式I/O，集中式控制)、CIDC(集中式I/O，分散式控制)、DIDC(分散式I/O，分散式控制)和MDICC(混合分散式I/O，集中式控制)。这其中，我们只对DIDC和MDICC感兴趣。DIDC是由CAN总线上的许多具有独立功能的ECU组成，同时只有智能传感器/执行器直接连接到同一CAN总线上。MDICC是由集中式和分散式ECU和传感器/执行器混合组成，同时与CAN互连。该作者在一些理想的架构指标方面对这四种架构进行了比较：端到端控制延迟；物理属性（如电线长度和ECU数量）；网络上的数据量；架构灵活性（(鲁棒性）变化，如重新定位、集中或分散车辆中的传感器和执行器，以及增加或删除ECU（与车辆类型有关的架构变化）。
该比较代表了在CAN总线上混合ECU、软件控制和传感器/执行器的各种选择，以形成E/E网络。MDICC最能代表一个典型的传统的、分散式E/E结构。然而，我们所描述的集中式架构与DIDC最相似，除了我们的控制都集中在一个有足够能力的ECU上。我们可以肯定地说，在作者最初的DIDC架构中，将控制权集中在一个强大的ECU上，对他们的四个标准有如下影响。
第一, 控制延迟的减少只有两个原因。第一个原因是，对于需要在单个ECU之间协调的控制操作来说，现在协调是在单个ECU上进行的，相比之下几乎没有延迟。第二个原因是，如果所有ECU都被合并，那么CAN总线上可以争夺总线访问权的不同信息的数量就会减少，因为所有这些信息现在都是由一个ECU发出的。减少总线争用导致控制延迟的减少。第二，由于现在没有合并的每个ECU的线桩，所以总的电线长度有所减少。第三, 在最坏的情况下，ECU之间不进行通信，总线上的总数据量保持不变。然而，这是一个不现实的场景，我们预计总数据量是会减少的。第四, 由于额外的控制功能可以作为软件添加到一个中央ECU上，而传感器和执行器的移除/插入/重新定位不需要任何架构上的更改，因此可以在成本方面提高设计的鲁棒性。
现在，我们根据对DIDC的这种修改来重新审视作者的结果。第一，对于直接连接到相应控制器的传感器和执行器，无论是在原研究中，还是与修改后的DIDC相比，MDICC具有更好的延迟。然而，由于前面提到的原因，对于总线上的智能传感器和执行器来说，在集中控制的DIDC中，控制延迟有望减少。第二，作者最初版本的DIDC仅在ECU总数方面逊于MDICC，但在架构的修改版本中，由于有一个单一的主ECU，情况就不再是这样了。必须承认，整体的ECU成本差异是一个需要单独研究的问题。第三，正如预期的那样，原始研究中DIDC的全分布式架构将所有信号放在CAN总线上，因此比MDICC更广泛地使用该总线。随着控制权完全集中到单个ECU上，总线的利用率预计会下降，因为一些信号将成为中央ECU的内部信号，但不能说明DIDC的修改版在这方面与MDICC相比如何。第四，在最初的研究中，DIDC在结构灵活性方面优于MDICC。由于所有的控制都集中在单个ECU上，这一点并没有改变。
可以看出，Kanajan等人的研究可以用来理解集中式E/E架构与经典的分散式架构在一些重要方面的比较。事实上，假设将基础的CAN技术改变为更现代的CAN FD或汽车E网，后者的数据传输率提高了几个数量级，并将对上述原因三中的DIDC产生积极的影响，作者的结果使集中化处于压倒性的优势。
3) 航空航天工业的经验教训：航空航天业已经成功地从分散式（航空术语中的 "联合式"）E/E架构过渡到集中式（"集成式"）架构。现代飞机采用了集成模块化航空电子设备(IMA)概念，这是一种用于航空电子设备的集成(集中)架构。IMA被广泛认为是一种具有成本效益的解决方案，可用于提高航空电子学的复杂性，具有以下优点：减少CPU、通信通道、I/O模块的数量，并相应地减少电子设备的尺寸、重量和功耗；改善模块化和软硬件的复用率；提高资源效率等。波音787采用了IMA概念，使波音减少了100多个LRU(线路可更换单元)，减少了约900公斤的飞机重量。同样，空客A380也采用了IMA概念，将处理器单元的数量减少了一半。在对35个项目（包括商用飞机和战斗机）的研究中，已经报告了功率消耗、空间和重量的减少。此外，Mairaj的研究展示了机载电子系统总数的减少，以及可靠性（平均故障间隔时间）和资源利用率的改善。在汽车行业，只报告了少数类似的结果。例如，德尔福报告说，奥迪A3上ADAS功能的集中化降低了30%的线束重量，节省了30%的成本，而博世报告说，从一个集中化的架构（面向领域）到一个更集中的架构（面向区域的架构）时，线束重量减少了15-20%。但通过观察，我们可以发现，汽车E/E架构在本质上类似于航空器的架构，只是没有那么复杂。考虑到如前所述，一辆高端汽车有100多个ECU，而上述数字与波音公司采用IMA后减少的电子系统数量相同--这种比较提供了一种规模感。因此，在向集中化过渡的汽车领域中，我们有理由期待类似IMA的好处。
图1. 车辆E/E架构的预期演变
C. 基本概念
为了提高E/E体系结构的可扩展性，一些基于集中化总体思路的现代架构已经逐渐取代了分散化的架构。图1由Bosch设计，展示了电子/电子建筑的历史和未来。汽车OEM目前正在尝试上述三种类型的集中式架构，即面向领域的、面向跨域的和面向区域的架构，它们都是基于将多个相关功能集成到一个功能强大的单一ECU上的想法。在本节中，我们将介绍这些架构背后的基本概念。
图2. 典型的面向领域的E/E架构
在面向领域的架构中，软件组件(SWC)根据车辆功能域进行聚类，如图2所示。尽管各组织之间的车辆领域略有不同，但汽车行业普遍认同的主要领域有四个：车身和驾驶室（舒适度和照明）、信息娱乐（显示器、娱乐和信息系统）、车辆运动和安全（底盘、主动/被动安全和驾驶辅助功能）以及动力系统（推进和废气处理）。在面向领域的架构中，每个领域都有一个相应的领域集群，该集群由一个领域控制单元（DCU）和零个或多个子领域ECU组成。DCU控制仅与其链接的子域ECU。一个典型的DCU有一个强大的多核CPU，承载着领域的主要功能，同时提供一个额外的抽象层，简化了DCU所处领域和其他领域之间的接口。子域ECU封装了辅助域的功能，所需的CPU功率较小。通常情况下，它们与相关的车辆硬件一起，构成了智能执行器。不同的DCU的连接是通过高速连接实现的，以太网数据主干。子域ECU通过典型的现场总线（如CAN、LIN、FlexRay）与它们的DCU相连，但如果需要的话，也可以通过汽车以太网实现。
虽然面向领域的架构解决了分散式架构的许多问题，但它们仍面临两个主要挑战。首先，某些高端功能如ADAS需要DCU之间的大量互动，使得DCU之间的边界不明确。其次，由于DCU之间的互动越来越多，更多高端功能的出现，人们可能怀疑目前的通信带宽将不足以满足未来E/E架构的需要。跨域集中式架构的出现解决了这些问题。
在跨域集中式架构中，多个域的功能被整合到单个ECU上，称为跨域ECU（CDCU），如图1所示。因此，一个可能实现的跨域集中式架构看起来与图2中的架构类似，此处用CDCU取代了DCU。例如，底盘和动力系统领域的功能可以合并到一个车辆运动控制CDCU中。
对于领域集中式架构和跨域集中式架构，分别在DCU和CDCU中进行复杂函数的处理。因此，随着功能的复杂性增加，在这些ECU中进行的本地处理也在增加，需要更大的带宽来在ECU之间传输经过处理的、越来越复杂的信息。此外，由于单个车辆的功能变得越来越复杂，越来越依赖于其他功能，所以需要更多的线路。这些问题可以在一个车辆集中式或面向区域的架构中得到解决。
图3. 典型的面向区域的E/E架构
在面向区域的架构中，汽车被分为多个区域，每个区域都有一个区域ECU（ZCU），例如，"前右 "区域和 "前左 "区域。与面向领域的架构中的子域ECU类似，ZCU与传感器和执行器相连。但是ZCU与子域ECU不同之处在于，它们不进行任何处理以实现车辆功能。相反，它们收集并将与各自区域有关的信息转发给一个功能更强大的中央服务器，该服务器对复杂功能进行必要的处理。在这种架构中，复杂的处理也可以负载到云端。图3展示了一个面向区域的架构的实现。这种架构可以缓解上面提到的线束长度问题。如前所述，博世报告称，当使用面向区域的架构而不是面向领域的架构时，线束重量减少了15-20%。据我们所知，还没有供应商或OEM采用过以云计算为基础的分区架构；这种方法只在理论上讨论过。面向区域的体系结构的另一个主要优势是，高带宽传感器(如视觉或深度传感器)可以直接连接到中央服务器进行数据处理，从而消除了在遵守ISO 26262标准1时对功能安全造成的潜在代价。功能安全性和ISO 26262将下一节进行讨论。
本文所讨论的架构，即集中式架构，包括本节中定义的面向领域、面向跨域和面向区域的架构。
D. 在汽车行业的应用
许多一级供应商已经发布了DCU解决方案。而这些解决方案已经被整合到汽车中。伟世通的域控制器实现—SmartCore，已于2018年3月与梅赛德斯奔驰一起推出。DCU实现了一个集成的数字驾驶舱，该驾驶舱包括仪表盘、信息娱乐、连接、平视显示器（HUD）和驾驶员监控功能。另一家汽车一级供应商Aptiv报告了发布主动安全域控制器，由宝马公司集成，以及由法拉利公司集成的驾驶舱（域）控制器。此外，Aptiv还为奥迪的A8开发了一个集中式控制器，实现了SAE J3016的3级自动驾驶系统。博世则开发了驾驶辅助系统域控制器（DASy）。此外，许多一级供应商也提供动力总成DCUs。例如，博世开发了车辆控制单元（VCU），可以作为动力总成域控制器、作为通信接口，并可用于ADAS应用。博世正在考虑在领域集中化的E/E架构之后的几个里程碑，即面向跨域和区域的架构（后者可能通过云计算得到增强）。图1体现了博世的愿景。到目前为止，博世已经采用了一个面向跨领域的架构和一个面向区域的架构。如前所述，博世表示，与面向领域的架构相比，使用面向区域的架构实现了线束重量减少15-20%。德尔福宣称，奥迪A3上ADAS功能的集中化，实现了线束质量和成本的30%的节约。据一份报告显示，DCU市场预计将迅速增长：2019年至2025年期间，用于集成驾驶舱和自动驾驶的DCU数量预计年均增长率为50.7%。
已有多家OEM制造商采用了集中式E/E架构。宝马和奥迪一直呼吁将他们的E/E架构集中化，以支持当前和未来的行业趋势。自2017年以来，车身域控制器已经出现在宝马的一些车辆上。虽然关于宝马最新的E/E架构的报道很少，但很显然，未来宝马的E/E架构将是集中式的。2016年，大众汽车公司宣布他们计划开发和部署一个完整的面向领域的架构，其主要有五个方面：动力系统、底盘、安全、驾驶辅助/自主以及驾驶舱。当时，该公司报告了从头开始开发和部署一个完整的领域架构的规划。此后，该公司基于集中式E/E架构，开发了MEB平台，这是一个用于电动汽车的模块化汽车平台（用于奥迪、西雅特、斯柯达和大众的多款车型）。自2017年以来，捷豹路虎一直在其E/E架构中使用以太网骨干网，并通过让DCU控制所有信息娱乐功能来集中管理信息娱乐领域。此外，捷豹路虎报告称，计划使用动态网络配置和面向服务的架构(SOA)，以提供更大的灵活性，安装新功能，更好地处理各种车辆，促进硬件和软件重复使用，并支持带宽的增加。
总的来说，客户的需求，一级产品的数量和多样性，以及OEM厂商的成功实验，这些都在未来交通自动化的预期下，正在推动OEM采用新的汽车E/E架构。新的汽车E/E架构是必要的，而且似乎是不可避免的，以便在微观（车内）和宏观（区域交通信息交流）规模的信息交流水平空前的时代，保证未来的汽车生产。
3 功能安全的作用
随着车辆功能的复杂性增加，由于E/E系统的故障而导致的不安全行为的可能性大大增加。这迫使OEM厂商严格按照安全标准来开发车辆。目前，汽车E/E架构事实上的功能安全标准是ISO 26262。在本节中，我们将介绍该标准的主要概念和要求。本文的其余部分使用这些概念来讨论集中式架构背景下的功能安全问题
ISO 26262于2011年首次发布，并于2018年修订，为将安全工程与产品开发生命周期相结合以实现道路车辆E/E系统的功能安全提供了指导。该标准的核心概念是一组汽车安全完整性等级（ASILs），细分为4个等级。这些最终决定了开发一个给定组件的严谨度。ASILs根据其关键程度被分配到最高级别的安全需求（安全目标）。ASILs通过设计过程传播到各个层次要求，直至与安全相关的软件和硬件要求。ASIL A被分配给相对低关键性的功能（如仪表盘显示），ASIL D被分配给最关键的功能（如线控刹车）。因此，ASIL较高的要求在实施时要比ASIL较低的要求有更严格的准则。在发生故障的情况下，相互作用并可能相互影响的部件必须全部开发到它们之间的最高ASIL水平。当然，开发给定功能的成本会随着ASIL等级的增加而增加。
为了帮助降低开发成本，该标准引入了ASIL分解，通过这种方法，具有特定ASIL的要求可以被分解为具有较低ASIL的独立但冗余的要求。标准中规定了分解的模式和规则，以及特定分解是否有效的条件。ASIL分解依赖于标准的一个核心概念，即包括SWC在内的E/E架构元素之间的充分技术独立性。这个概念本身包括无共因失效、无级联失效和无干扰。图4显示了一个干扰的例子，在这个例子中，由于一个错误（例如，未发现的软件bug，粒子撞击，硅故障），SWC 1获得了向分配给SWC 2的内存分区写入的能力。只有在分配给被分解要求的元素被证明在共因失效和级联失效方面足够独立的情况下，ASIL分解才有效。
图4. 由于未发现的错误而产生的内存干扰
该标准的ASIL方法在结构上为供应商创造了机会，使高关键性的汽车部件商品化。支持这个生态系统的方案是 "脱离背景的安全要素（SEooC）"。SEooCs是根据标准开发的通用组件，但被汽车供应商作为商业现货（COTS）组件出售。最常见的例子就是CPU。SEooCs是在对其使用的某些假设下开发的。当原始设备制造商整合这些组件时，他们是在组件被整合的背景下验证这些假设的。如果假设成立，那么组件可以被分配到低级别的技术安全要求，整合组件的ASIL最多与组件本身的ASIL一样高。例如，一个ASIL C的加密密钥存储硬件外设SEooC可以被赋予ASIL B的技术安全要求，以安全地存储加密密钥。但它不能被分配到ASIL D。标准中的这一规定使供应商能够对他们的产品进行试验。只要这些产品是作为SEooCs开发的，供应商就能指导汽车E/E架构如何发展。如今的市场上看到，许多汽车CPU是作为ASIL D SEooCs开发的。
基于ISO 26262的要求，有几个软件工程原则和硬软件技术在集中式背景下特别重要例如，围绕SWC之间的松散耦合而设计的软件，可以减轻证明没有级联失效的任务，这是高ASILs标准的要求。内存保护是集中化的必要条件，必须证明在同一ECU上共存的SWC之间没有干扰，故障抑制，即隔离有故障的SWC，使其他SWC不受影响，在SWC之间共享内存和外设的集中式架构中，更难进行故障抑制。传统架构中采用的成熟技术，如静态恢复机制、并行/独立执行路径和多版本软件等，都是多核CPU所能实现的，可以重新使用。
对于集中化作为可扩展性瓶颈的解决方案的可行性问题，功能安全的专用硬件支持是至关重要的。目前所有龙头供应商的DCU产品都表明了这一点。专用支持包括内存保护单元、故障报告单元、冗余和锁步核、内存和通信级的错误检查和纠正、基于优先级的中断机制等。将具有ASIL D级别的硬件支持与增加的计算能力相结合，自然地产生了能够支持领域集中的ECU产品，正如我们在下一节将会讨论到的那样。ISO 26262在2018年第一次更新。更新内容包括构建故障操作系统的指导。到目前为止，标准的重点一直是建立故障安全系统。但在越来越多的情况感知和自主车辆中，系统仅仅针对故障安全是不够的。通常情况下，在故障发生后，需要高级别的功能才能使系统处于安全状态（例如，在ECU故障的情况下，使自动驾驶汽车脱离行驶路段）。该标准还进行了更新，以反映功能安全对网络安全的日益依赖。然而，该标准将区别对待实现安全E/E系统的活动和实现功能安全的活动。因此，仅就这两项活动之间的交互提供信息指导。例如，网络攻击可能导致违反安全目标，因此网络安保分析和安全分析可能会协调一致。
4 支持技术
虽然一些现有的技术可以直接用于集中式架构，但也有一些技术需要调整，以促进集中式车辆E/E架构的开发、运行和维护。本节将介绍支持集中式E/E架构的技术。首先，在第四节A部分中，我们讨论了开发功能强大的集中式控制器所需的ECU硬件的进展。然后第四节B部分讨论了虚拟化，虚拟化这是一种基本的硬件支持的软件技术，允许软件重用，并能在集中式E/E架构解决方案中有效和安全地集成。第四节C部分讨论了满足集中式E/E架构需要的网络技术，第四节D部分讨论了AUTOSAR对现代E/E架构的支持。
A. ECU硬件
围绕（跨）域或区域控制器集中车辆的E/E架构，会使车辆中的ECU的数量减少，但也增加了一些ECU的处理器负载，因为有更多的功能部署到这些因此，汽车行业正在向带有多核CPU的ECU过渡（目前，典型配置是两到六核），以增加处理能力，并允许在不同的核上并行运行几个SWC。
许多硬件厂商已经发布了多核处理器，用于高性能实时安全关键的汽车应用。恩智浦推出了几款微处理器，可以在现代E/E架构的域控制器中加以利用。例如，他们的S32S24是一个基于ARM R52的四核微控制器，时钟频率为800 MHz，应用范围包括汽车车辆动力学、领域控制和安全协处理器应用。英飞凌的AURIX微控制器系列基于英飞凌专有的TriCore架构，可提供多达六个时钟频率为300MHz的内核。无论何时，电路的设计都是为了满足ASIL D的应用。正如预期的那样，已经投入生产的域控制器利用了现有的微控制器技术。例如，第二节D部分中提到的Visteon的SmartCore是基于高通公司的8155芯片，这是一个基于ARM定制的64位八核微处理器。
对功能安全来说，多核CPU提供的执行环境能增加免受干扰的自由度，因为物理上不同的内核隔离了具有不同临界水平的SWC的同时执行，这是很重要的。虽然这种分离并不像传统架构那样彻底，不能每个ECU重新接收一个SWC，但与使用功能强大的单核CPU和部署相同数量的SWC的ECU相比，它能更有效地减轻软件和硬件故障的影响。然而，在符合ISO 26262标准的情况下，在同一多核CPU上运行混合关键性软件需要分区机制，以防止核心之间在共享资源方面的处理干扰，包括主存储器、通信基础设施（在汽车领域，最常见的是CAN和LIN总线）以及数字和模拟I/O。现代多核产品包含专用硬件，有助于实现这种分离，这是ISO 26262的直接支持。在核心冗余、故障报告、内存分区、错误检测和纠错等专用硬件功能的辅助下，最终的汽车软件可以更安全、更高效、更安全地运行。
采用多核ECU需要考虑方方面面，最重要的是迁移和调度策略。绝大多数情况下，将看到为单核ECU构建的单体、经过验证的传统应用程序的迁移，有些是将软件原封不动地迁移到其中一个核心上，或者将软件重新设计成（也许是并行的）任务，按照时间表在单个核心或几个核心上同时运行。分区调度可以应用于第一种情况，即任务被静态地分配到一个核心，而不能在另一个内核上执行。在第二种情况下，可以使用带有任务重定位的全局调度，在这种情况下，可以通过将任务转移到内核上而动态地加载未被充分利用的内核。第一个迁移策略一般是可行的，因为目前多核产品的单个内核比早期的单核ECU功能更强大。在第二种情况下，现代汽车CPU内核相对较高的性能能力足以抵消内核间通信、任务同步和任务调度的额外计算负荷。如同在其他依赖计算的领域一样，在汽车领域，通过适当的并行软件工程或者将单片软件重新设计为并行任务，可以最好地发挥并行计算的作用。在这种情况下，必须尽量减少任务间的通信，从而使跨核通信保持在最低限度，并且调度必须使内核得到最大限度的利用，同时确保任务优先、相互排斥以及各任务的时间限制。汽车行业正在应对这些挑战，以便从ECU的并行计算中获得最大利益。
另一个有希望开发强大的领域、跨域和区域控制器的平台是众核CPU。众合CPU的内核数量较多，从几十到几千，而且对CPU进行了并行处理的优化。这些内核通常通过片上网络（NoC）连接，与传统的基于总线或基于环的多核系统配置相比，它提供了更多可扩展的解决方案。与多核CPU相比，众核CPU具有一些优势；特别是，它们尤其1适合于计算密集型的应用。
域控制器需要进行大量处理，因此往往需要硬件加速器，如人工智能应用的加速器、密码学加速器和线性代数加速器。例如，恩智浦的S32S24平台有三个硬件加速器，其中包括一个硬件安全引擎（HSE），能提供加密算法、散列和随机数生成等安全支持。AURIX TC3xx还利用了密码学加速器。一般来说，硬件供应商会通过专用的快速硬件实现加密操作、安全密钥存储、安全通信网关、网络总线信息验证和入侵检测来提供安全功能。以上这些功能都可以在软件中执行，但硬件加速可以实现量级提速。硬件加速器通常利用图形处理单元（GPU）、数字信号处理器（DSP）和现场可编程门阵列（FPGA）。前面提到的驾驶舱域控制器Visteon SmartCore，在单个片上系统（SoC）上实现，它载有高通Adreno GPU和高通Hexagon DSP，可用于计算机绘图。GPU也被用于现有ADAS解决方案的各种应用中，包括行人检测、线路跟踪和路径规划。FPGA在现代ECU中有很多应用，包括包括在发动机控制单元中的应用，用于并行采集发动机数据和与其他子系统的接口；激光雷达信号处理和数据融合、安全网关、连接和用于娱乐制图；ADAS数据聚合、传感器融合和对象分类。
B. 虚拟化
虚拟化是支撑E/E集中化趋势的一项重要技术。几十年，虚拟化软件和多核计算平台相辅相成。在嵌入式汽车领域中，避免干扰和简单软件集成的需求等因素也推动了这种共生关系。在本节中，我们将描述驱动在多核汽车ecu上采用虚拟化的因素，并试图演示为什么虚拟化的便利使其成为集中化的必然选择。
图5. 在一台主机上运行的四个虚拟机；这些虚拟机承载着不同操作系统的混合关键性堆栈。
图6. 虚拟化被用来在四个不同的SWC之间划分内存、CAN硬件和CPU内核。
如图5所示，一个虚拟化系统由一层虚拟机（VM，软件）和一个虚拟机监视器（VMM，也是软件）组成，在物理机主机（硬件）上运行。虚拟机是一种通过模拟物理机来封装和执行其他软件的软件。被执行的软件可以是一个单一的程序，也可以是一个完整的操作系统(OS)，按照通常的方式执行任务。VMM是一个中间软件层，用于在虚拟机之间划分处理、内存和通信资源，并将同时运行的虚拟机调度和迁移到不同的资源上。与嵌入式汽车应用程序相关的VMM被称为hypervisor。它们直接在ECU处理器上运行，可以看作是虚拟机的操作系统，其中它的“任务”就是虚拟机本身。
虚拟化的一个主要用途是整合需要不同操作系统，以及相同操作系统的不同版本的ECU功能，如图6所示。例如，可能有必要将一个ECU的遗产软件（应用程序和操作系统）与另一个ECU（例如符合AUTOSAR标准的ECU）的软件并排使用。这种整合有几个好处。复用遗产ECU软件可以降低成本和上市时间，因为遗产软件是已经经过验证的。
但是，由于功能干扰，如果不使用专门的隔离机制，不同的操作系统以及同一操作系统的不同版本的共存，是一个非常难以管理的问题。将需要不同操作系统或操作系统版本的应用程序隔离在虚拟机内，可以完全消除这个问题。每个应用程序都会收到它所需要的操作系统，并且由于在虚拟机内的隔离，它们不“知道”其他操作系统的存在。
汽车行业的另一个常见场景是混合关键性ECU的整合，如图6所示。ISO 26262要求，保证整合后的功能不受干扰，如一个SWC的故障（例如，设计或实现缺陷，或由于硬件失效导致的故障）不会传播到部署在同一ECU的其他更高ASILs的SWC。在传统的设置中，当这种故障表现在一个ECU上时，它对其他SWC的影响会因为ECU的物理分离而降到最低。例如，故障的SWC不能覆盖不同ECU上的SWC的内存。确保SWC之间免受这些影响的唯一途径是ECU之间的通信链路。实现这一目标的成熟方法已经存在，例如在通信链路上检测畸形数据的传输。但在集中式设置中，这种物理分离消失了，不同ECU的功能被整合到一个ECU上。根据ISO 26262，要合并两个具有不同ASIL要求的功能的ECU，例如ASIL D和ASIL A，这两个功能必须按照ASIL D的要求开发，或者必须使用按照ASIL D要求开发的机制，以保证两个功能之间不会有干扰。
虚拟化是解决这些困难的一个完美方案。不同的遗产SWC可以并排部署在单个ECU的虚拟机内。由于虚拟化促进了遗产软件的迁移，异构软件可以被整合，而VM内部的隔离消除了不同版本的软件和操作系统共存的担忧。每个虚拟机都可以使用最合适的操作系统，而VMM提供了所需的免受虚拟机之间干扰的自由。例如，伟世通的SmartCore DCU实现了一个集成式数字驾驶舱（在第二节D部分中介绍过），它使用一个hypervisor来集成在Linux上运行的非ASIL信息娱乐领域和ASIL B仪器集群领域。用于嵌入式应用的Hypervisor通常是按照ASIL D要求开发的，所以它们是符合ISO 26262标准的软件功能集成的COTS解决方案。最后，虚拟化足够灵活，可以促进构建灵活的、可扩展的体系架构，在ECU之间迁移SWC才是可行的。
虚拟化第一次被证明是整合企业IT基础设施上的异构软件的可行解决方案。然后，该技术在21世纪初被作为航空系统的集中化使能技术。
现在，市场上的hypervisor，其中许多已经在航空航天、国防和医疗领域的安全关键应用中取得了巨大的成功，正在推动采用虚拟化成为汽车E/E架构中的首选集成方案。通用动力公司（General Dynamics)和风河系统公司(Wind River Systems)等航空航天和国防领域的老牌供应商，都在提供非常适合汽车应用的关键任务管理程序（hypervisor）。
虚拟化技术有几个局限性。首先，实时性能通常是不可预测的，因为虚拟化可以导致在两个级别上进行调度，即管理（hypervisor）级别和虚拟机级别。解决这一限制的一种方法是将 VM 静态分配到内核。其次，虚拟机利用了相当可观的内存资源。第三， ECU 外设（例如 CAN 总线）的虚拟化是一个需要进一步研究的复杂问题。第四，hypervisor必须保持较小规模，以确保安全、可靠和无 bug ，以便在用作 SEooC 时能够开发到最高的ASIL级别。最后，在过去，ECU 中对虚拟化的硬件支持有限。不过，随着汽车 CPU 中硬件虚拟化支持的引入，这种情况目前正在得到改善。这些扩展基于 ARM 内核的 CPU，加速了虚拟化环境的执行。比如来自NXP，英飞凌和德州仪器都包括硬件虚拟化支持。
虚拟化对工业界和学术界都是一个重大机遇。对于工业界来说，它为所有汽车制造商面临的难题提供了现成的解决方案；对于学术界来说，它提供了新的方法，将日益复杂的汽车系统的开发方法与 ISO 26262 等标准的要求相结合。在这两种情况下，虚拟化都是不可或缺的支持技术。因此，我们预计航空行业的故事将会重演，虚拟化将是未来汽车行业标准遵从的首选技术。
C. 联网
传统上， CAN 总线一直被用作车载连接的实际标准。CAN 总线是用于互连车辆内部 ECU 的串行总线。随着车辆功能及其产生的数据流量的日益复杂，CAN 网络越来越不适合未来的 E/E 架构，因为它们的数据速率限制为每秒1mb。CAN FD (flexible data rate灵活数据速率)和汽车以太网可用于替代在不同领域的CAN 总线。
CAN FD的特点为动力总成领域（如混合动力和全电动驱动）、车身领域（如与舒适性相关的先进车身部件）和底盘领域（不包括驾驶辅助子领域）的先进功能提供了必要的性能升级。这些特点包括几乎为6 Mbit/s的实际最大数据速率，具有64个字节的数据字段的数据包（相对于CAN的8个字节的数据字段），与传统的CAN系统向后兼容，并且功耗低。将现有的网络从CAN转换到CAN FD可以大大减少总线负载，允许在可接受的延迟情况下传输更多的数据。但是，由于在信号级别与 CAN 相同，我们可以预测在最大节点数和最大电缆长度方面有类似的限制。事实上，尽管作者无法找到任何具有支持性的实验证据，但可以推断出，对于较高的CAN FD数据速率来说，最大的电缆长度要和CAN相比明显减少，这一因素对于某些制造商和某些应用来说可能是不可接受的。更重要的是，CAN FD作为现代和未来软件定义的汽车所需要的网络技术，本质上是不能够通用的。在这些应用中，服务导向成为主导的软件范例。预定义服务的集成，以及在车辆制造时未知的服务——电话、音乐播放器、健身追踪器等个人小工具，以及与交通基础设施的整合--需要数据速率和功能分离、带宽预留、安全等方面的多功能，而CAN FD无法提供。在一定的复杂程度之上，仍然需要更快、更可靠和更通用的通信技术，例如汽车以太网，以便为不同的汽车应用提供更高的带宽，包括ADAS领域和信息娱乐领域。
汽车以太网是指在车辆中使用的基于以太网的通信方案，在信号级别上与原始以太网完全不同。汽车以太网提供了一个轻量级和具有成本效益的通信媒介，它使用单一非屏蔽双绞线。100 Mbit/s和1000 Mbit/s的通信数据率很常见，IEEE 802.3ch-2020规定的最大数据率为2.5、5和10 Gbit/s。IEEE P802.3cy工作组正在制定25、50和100 Gbit/s的规格。与传统的汽车现场总线相比，高数据率是汽车以太网的一个显著优势。事实上，由于未来的自动驾驶汽车估计会产生4TB/h的数据量，市场专家相信，全面采用汽车以太网是不可避免的。然而，由于它是一种相对较新的技术，文献似乎还没有反映出一套既定的基于汽车以太网的车载网络物理层的设计原则。目前的研究正在揭示这种网络技术的电磁兼容性和信号质量特性，这是物理层设计的基础。此外，开放联盟提供了几个测试规范，可用于汽车以太网应用的物理层面。为了支持高带宽和低延迟的实时车载通信，联盟已经制定了一套标准，即TSN（Time-Sensitive Networking时间敏感网络）标准。TSN标准扩展了AVB（音频视频桥接）标准，通过以太网提供时间敏感的通信。时钟同步是满足系统级实时性要求的关键。在日益复杂的车辆中，严格的实时要求，即如果在E/E系统运行时，违反这些要求将对功能安全造成严重后果，这些要求将必然依赖于网络性能的时间保证。实例包括ADAS和 "by-wire"系统。TSN的IEEE 802.1AS-2020标准规定了跨以太网的时间同步机制。它定义了一个在网络中分配时基的主控器，以保证所有组件遵循相同的全局时钟，但也允许在同一个网络中运行多个不同的时域。此外，该标准还定义了同步时间的传输。该标准的时钟同步协议是IEEE 1588-2008定义的精确时间协议的变体。
实例包括ADAS和 "by-wire "系统。TSN的IEEE 802.1AS-2020标准规定了跨以太网的时间同步机制。它定义了一个在网络中分配时基的主控器，以保证所有组件遵循相同的全局时钟，但也允许在同一个网络中运行多个不同的时域。此外，该标准还定义了同步时间的传输。该标准的时钟同步协议是IEEE 1588-2008定义的精确时间协议的变体。
TSN标准IEEE 802.1Q-2018提供了有界限的低延迟。几个不同的流量类别被定义为基于优先级的。然后，该标准为以太网帧的传输定义了两种调度机制：严格的优先权和基于信用的整形器。第三种调度算法也被定义为TAS（Time Aware Shaper时间感知整形器），它使用时分多址（TDMA）方案确定性地调度帧，使时间关键的帧在每个时间段的时间窗口内享有独家传输权。为了使最高关键性的帧获得更低的延迟，建议采用帧抢占的方式，即较低优先级的帧被中断和分割，从而使高关键性的帧能够尽早被发送。
IEEE 802.1Q-2018还定义了执行网络工作流控制和监控的措施。例如，该标准规定了如何通过限制某些端口的允许入口带宽来避免通信网络的过载。对于容错，IEEE 802.1CB-2017 TSN标准规定了冗余措施以保证车辆网络内的容错。该标准定义了识别和复制数据包的方法，以及识别其他重复的数据包并消除它们的方法。然而，该标准并没有定义数据包的冗余路径。相反，IEEE 802.1Q-2018定义了在网络上配置多条路径以提供冗余性的方法。IEEE 802.1Q-2018和IEEE 802.1CB-2017 TSN标准结合在一起，可以被用来进行动态网络配置。动态网络配置的能力对于支持未来的车辆网络，通过FOTA（空中下载固件）和SOTA（空中下载软件）实现软件更新至关重要。例如，添加一个需要增加以太网链路带宽的新功能时，将需要用到此功能。此外，将采用动态网络配置替代静态的手工网络配置，以有效地处理车辆产品线中越来越多不同变体的网络配置。
总的来说，TSN标准旨在提供网络性能的基本保证（延迟的界限、带宽预留、流量分离等），这是实现任务和安全关键要求的先决条件。另一个协议，时间触发以太网（TTEthernet），是SAE AS6802标准，定义了支持确定性、实时通信和功能安全相关应用的机制。例如，该标准通过将一个物理通信通道划分为独立的子通道来支持功能安全，这些子通道不受逻辑和时间干扰，从而避免了故障传播。
与 TSN 一样，TTEthernet 需要为三种流量（包括时间关键流量）中的每一种流量分配一个静态定义的时隙时间表，以保证传输时间。在这两种情况下，必须离线解决时间表，例如通过SMT技术解决。但与TSN不同的是，必须解决所有涉及的交通类别和路线的时间表。相比之下，在 TSN 的情况下，必须只为时间关键流解决时间表，而其他流量则通过各种机制尽力而为。但是，也可能通过在解决时间关键性的流量计划的同时考虑到非关键流量，来优化所有流量。由于并非车辆应用程序中的所有流程都是时间关键的，因此完全基于TTEthernet的车辆模型的变体可能需要解决比完全基于TSN的车辆模型的不同的网络配置更多的调度。在车辆型号频繁变化，并且伴随着车辆变型的情况下，TSN也许比TTEthernet提供了更高的灵活性。
虽然下一代架构将巧妙地混合使用 CAN、CAN FD、LIN、FlexRay 和以太网技术，但许多汽车制造商已经在量产车辆中使用以太网，和/或计划使用以太网主干。事实上，通过实时和安全扩展（如AVB、TSN和TTEthernet）适当扩展的汽车以太网，正在成为域间通信的最优解决方案。通过实时扩展，汽车以太网也完美地适用于与智能执行器的域内通信，如电动马达控制和SONAR/雷达/激光雷达传感系统，在这种情况下，必须满足时序保证。此外，我们预计，车辆将越来越多地被要求与智能交通系统集成，实时通信的要求将越来越严格，因为关于车辆如何与环境通信的规定变得更加苛刻。这将对车载网络技术提出了额外的要求，以便在未来扩大规模，满足这一需求。
D. AUTOSAR
集中化E/E架构需要在软件架构层面的适当支持。汽车行业一直在逐步遵守包括AUTOSAR在内的几个标准。AUTOSAR标准化的趋势有几个优势，所有这些优势都与E/E集中化的目标相一致，如促进来自不同供应商的部件集成，不同的车辆项目和平台的组件重用，以及以系统的方式控制故障。在这一节中，我们重点讨论AUTOSAR为集中式架构提供的支持。
AUTOSAR（汽车开放系统架构）提供了一个用于开发汽车嵌入式系统的框架。该标准由一个由OEM制造商、供应商和厂商组成的联盟开发，目的是促进车辆软件的可移植性和可组合性。AUTOSAR的软件架构定义了在ECU上执行的三个软件层，如图7所示。这些层分别是应用层、运行时环境（RTE）和基本软件（BSW）。应用层以独立于硬件的SWC的形式实现ECU的功能，这些SWC可以执行车辆功能或传感器/执行器功能。RTE是架构的通信媒介，即SWC通过RTE与其他SWC（在同一或不同的ECU上）以及BSW模块进行通信。RTE是网关，车辆应用软件通过它访问ECU的功能以实现其目标。这些功能在BSW中通过几个抽象层实现（图7），成为应用软件可以使用的服务。BSW的最上层、最抽象的一层是服务层，它为应用程序、RTE和BSW模块提供服务。这些服务包括系统服务，如操作系统，一个是可以被所有模块使用的功能。在抽象谱的另一端是微控制器抽象层（MCAL），这是BSW的最低层。它由直接访问微控制器和外设的驱动程序组成。这一层是针对硬件的。
图 7. AUTOSAR 的分层软件架构
AUTOSAR的分层结构通过将车辆SWC与硬件平台分离来支持集中化，有效地提高了软件的模块化和复用性，软件的模块化和复用性又反过来促进了集中化在E/E架构中部署和重新定位到不同的ECU。因此，我们认为AUTOSAR是集中化的重要软件架构支柱，也是可以解决一直困扰汽车行业的可扩展性问题的E/E架构方案。
关于功能安全，AUTOSAR定义了便于检测和处理故障的机制，以确保在符合AUTOSAR的ECU中为SWC提供无干扰的执行环境，这是符合ISO 26262的必要条件。对于软件来说，内存分区就是这样一个功能，不同的操作系统应用程序被限制访问隔离的内存分区，以帮助执行应用程序之间的功能分离。然后，应用程序的内存访问由内存分区机制监控，该机制最好放在操作系统中。操作系统可以完全在特权模式下运行，也可以被拆分，这样只有与安全相关的函数才能在特权模式下运行。除了内存分区，AUTOSAR中的定时保护允许操作系统对定时故障作出反应，并采取预定义的行动，以实现应用程序之间的时间分离（即避免定时故障的传播）。逻辑监督机制也可用于监控软件的控制流，确保其正确执行。最后，端到端的通信保护机制可以用来处理操作系统应用程序或ECU之间的错误信号传输。
AUTOSAR通过诊断机制（如核心和RAM测试）支持硬件的功能安全。内核测试检测ECU的处理单元中可能会引发不正确输出的故障，例如算术逻辑单元中的故障。RAM测试可以检测出可能破坏ECU易失性存储器的故障。这些测试在现代汽车级CPU中具有完备的硬件支持。
为了支持安保性，AUTOSAR定义了安全车载通信（SecOC）模块，这是一个BSW模块，为汽车网络内的敏感数据传输提供认证机制。此外，AUTOSAR定义了加密抽象库（CAL）和加密服务管理器（CSM），以支持加密服务。
虽然AUTOSAR最初是为单核ECU开发的，但后来通过解决BSW在不同内核上的分配（即BSW的并行化），该标准被扩展到支持多核ECU。然而，标准中没有涉及应用层中SWC的并行化问题。关于SWCs并行化的研究有限，有的在高层讨论并行化过程(例如Macher等人的工作)，有的在没有将其应用于现实世界的AUTOSAR系统的情况下进行了具体的研究。
行业向集中式E/E架构的转变，往往需要将已经验证的AUTOSAR顺序应用迁移到现代多核平台上。这种迁移面临几个挑战。首先，AUTOSAR中的每个SWC都由可运行项组成，可运行项必须映射到任务，而这些任务又将被分配到内核中。可运行任务到任务的映射和任务分配到内核的工作需要同时进行，以避免过多的跨核通信，同时保持系统的约束（如优先权约束）。其次，AUTOSAR的BSW的服务层中的系统服务（图7）是为单核ECU设计的。如前所述，系统服务是所有AUTOSAR层内的所有模块都可以使用的辅助功能（例如，操作系统）。因此，迁移到多核ECU可能需要调整这些系统服务，以支持在不同分区上运行的相同BSW模块的不同场景。另外，在应用层面的并行化也是一项相当具有挑战性的任务。为了应对这些挑战，未来应该需要定义并行设计模式，并为映射、调度、同步和通信提供指导。
许多汽车OEM已经明确表态会将其软件迁移到AUTOSAR，这是一个巨大的工程。但是，当OEM正在向本文所述的AUTOSAR版本（称为AUTOSAR "经典"版）过渡时，AUTOSAR联盟正在致力开发另一个AUTOSAR平台，以精确满足汽车功能不断增加的复杂性和多样性对汽车E/E架构的要求，特别是高带宽应用，如ADAS和高度自动驾驶、信息娱乐以及V2X连接。其成果是2017年发布的AUTOSAR "自适应 "标准。AUTOSAR自适应标准转向了面向服务的架构，其中服务和客户端在ECU运行时动态链接。
AUTOSAR自适应并不是AUTOSAR经典版的替代品——它们针对不同的应用，因此相互补充。AUTOSAR经典版的目标是在低资源硬件上实施的具有硬实时要求和低带宽通信的安全关键系统，而AUTOSAR自适应版的目标是具有高带宽和空中传输（OTA）要求的高性能、低关键性系统。设计之初，设想这两个平台能在车辆网络中与非AUTOSAR平台和后端系统（如道路基础设施）一起共存。两个平台的互操作性是由共同的基础一套共同的要求和技术规范实现的。虽然AUTOSAR自适应有望将接管自主/自动驾驶、连接和信息娱乐等领域，但AUTOSAR经典版仍将是传统汽车领域（如动力总成和底盘等）的首选平台。伴随着跨越领域边界的多/多核系统功能整合的进一步趋势，不难想象AUTOSAR经典分区和AUTOSAR自适应分区在同一平台上共存。针对这类系统，如Kritikakou 等人已经提出了高效且安全的调度算法。
5 讨论情况
个别关于汽车行业可扩展性问题的解决方案，如增加ECU的能力，或将无处不在的CAN改为CAN FD或以太网，需要在E/E架构层面上的适当支持。简单地按要求升级单个ECU以应对增加的处理负荷，并不是一个可行的解决方案，因为复杂的处理最终会产生大量的数据。同样，通过用汽车以太网技术升级所有的ECU来提高分散式架构的吞吐能力，也是成本过高。
集中式架构是一种很有前景的方法，因为它可以沿不同的方向解决可扩展性问题：它有可能纳入越来越强大的ECU，并允许SWC部署拓扑结构的多功能性，同时减少软件变体的数量并减轻产品线的工程努力。此外，集中式架构通过最小化其上存在的节点数量来保证关键的高速通信主干线的未来发展。
我们已经见证了E/E集中化在各行业中的应用。供应商已经迅速支持集中化的试验。强大的多核汽车CPU与定制ECU硬件的整合在市场上随处可见。目前，DCU产品包括对关键功能安全要素的硬件支持、管理程序（hypervisor） ，以及通常对先进自动化功能的支持，如雷达和激光雷达数据处理、机器视觉和学习，以及传感器融合。还包括在网络攻击方面对车辆安全的硬件支持。正如我们所看到的，OEM和供应商一直在试验这些新技术，而这些技术往往需要很长的交付时间。这表明OEM和供应商认为这些实验是值得花时间和资金投资的。
正如预期那样，信息娱乐系统和ADAS是集中化的首批应用，并将继续成为E/E架构中集中化的焦点。在这些特定领域内实施集中化，表明这些应用所需技术的可用性（如多核CPU和汽车以太网）。然而，最新的一级产品和OEM产品，以及本文介绍的技术现状表明，有足够的技术临界量，使集中化成为具有硬实时要求、高性能和高安全临界水平的汽车应用的可行解决方案，如动力总成和底盘领域。
一般来说，开发汽车E/E架构是一项复杂的冒险，涉及到解决多目标优化问题。从历史上看，在汽车工业中，全局优化，甚至是接近优化，都还没有达到。E/E架构的开发过程包括在不同的ECU上和ECU内部找到令人满意的车辆功能分配，以满足大量的约束条件以及功能性和非功能性要求，包括成本最小化、现有资源的有效利用、可维护性和可扩展性。对于这个行业来说，向集中化的E/E架构转移是一非常大的工程，它带来了E/E架构工程的一般挑战，但也产生了一些不一样的问题。例如，在功能安全方面，由于功能被整合在一个强大的ECU上，该ECU如果故障可能会对功能安全产生更大的影响。反过来，需要行之有效和高效的安全架构模式，以便在发生此类故障时提供故障操作行为。此外，虽然多核ECU提供了更大的处理能力，但如何设计，特别是如何重新设计软件以获得更多内核的速度提升，在汽车行业仍然是一个开放的问题。集中化的另一个主要挑战在于调整现有的汽车软件和安全流程以实现集中化的预期收益。例如，在领域集中式架构的情况下，集成测试需要在几个集成层面上进行调整和执行，即要在领域集群层面进行集成测试，然后对所有领域集群进行集成测试。另外，从历史层面上来上看，汽车E/E架构中的不同领域利用了不同的开发工具和方法。因此，当将这些领域的功能集成到一个集中式架构的ECU上时，流程和工具的协调将是汽车行业的一项主要工作。
航空业在更严格和复杂的环境中已经成功过渡到集中式架构，这证明了汽车业的上述挑战是可以克服的。在航空领域成功过渡到集中式E/E架构的背景下，很明显，本文所讨论的要素，即行业趋势、E/E架构的当前临界状态、供应商的迅速反应、AUTOSAR标准的支持，以及日益增长的符合标准的需求，形成了一个临界质量，使集中化成为未来汽车制造的E/E架构方法。
6 结论
现代汽车功能的数量和复杂性的增加，推动了汽车E/E架构的发展需求。航空领域已经成功过渡到集中式E/E架构，在作者看来，面对日益增长的车辆复杂性，下一步的工作，显然是将汽车E/E架构过渡到这种类型。目前的行业趋势也清楚地表明，这就是汽车E/E架构的未来。在本文中，我们呈现了这些趋势。然后，我们讨论了几种使能技术。在整篇文章中，我们都在强调集中化及其使能技术对功能安全性的影响。
此外，虽然本文鼓励并论证了汽车行业的集中化的理由，但它也可以作为一个特定技术的目录，这些技术可用于提出的四大类实现技术。这篇文章还强调了实现技术和标准方面的挑战和差距，这些技术和标准仍然需要研究人员和从业人员进行深入调查。
作者：Victor
来源：汽车电子与软件
微信公众号：
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。
