服务于全新E/E架构的AUTOSAR Adaptive

智能驾驶系统，软件OTA更新，以及应用软件持续集成将很快成为许多车辆的标准功能。然而，如果没有新的架构和高性能ECU，这些复杂的电子功能就无法实现。新的软件标准AUTOSAR Adaptive应运而生，那么它在这些新的应用场景下发挥了什么作用呢？

由于上述功能的加入，车辆中软件的数量和复杂性持续快速增加，而且增长速度是前所未有的。当前，为了满足新的市场需求，汽车行业的大部分领域都在经历重大变革，对于汽车电子尤为如此。由于新功能所需的计算量非常大，微处理器（microprocessors）作为微控制器（microcontrollers）的补充，越来越多地用于电子控制单元（ECU）中。一个或多个微处理器通常与微控制器组合，形成所谓的高性能ECU。这些ECU中的微处理器与智能手机或PC中使用的微处理器非常相似，它们需要用到与传统汽车电子不同的软件架构。这种架构的一个重要特性就是要兼容POSIX标准的操作系统，从而有效利用计算资源。与以前使用的实时操作系统相比，这些操作系统可以更加动态地处理被执行软件，并将处理器的硬件信息抽象得更加彻底。为了将这些微处理器无缝集成到现有的车辆网络中，运行在操作系统之上的中间件应基于AUTOSAR Adaptive标准。

车辆的E/E架构同样在经历变革。域的概念和中央服务器架构可以将上面描述的高性能ECU集成到车辆中。在高速数据网络和强大处理器的支持下，重点不再是高效的数据传输，而是更严苛的ECU解耦。更换单个ECU应该对系统剩余部分带来尽可能小的影响。典型的方法是引入面向服务通信方式的架构。

带中央服务器的新E/E架构
除了解耦各个组件之外，增加硬件和软件的可重用性是另一个目标。这意味着组件可以跨车辆甚至跨OEM使用。近年来的经典E/E架构无法满足此要求，图1.a展示了这种面向ECU的架构。在经典E/E架构中，一个功能由一个ECU实现。ECU直接关联一组传感器和执行器，并从车辆网络接收总线数据。车辆的通信矩阵描述了ECU之间的通信行为，如果总线上新增节点需要使用这些数据，则需要更改通信矩阵。这种设计限制了系统组件的可重用性。

为了克服这个问题，域控制器架构（图1.b）应运而生。典型的域例如“车身”、“动力传动系统”和“信息娱乐”。这种架构的基本思想是每个域使用一个强大的控制器，此域中的大部分传感器、执行器连接到该控制器，此控制器还负责协调域内子控制器的执行。这极大地增加了在域内扩展功能的灵活性，因为调整通常仅导致域本地更改。但是智能驾驶系统不能直接分配给单个域，高度自动化的驾驶功能需要来自所有域的信息，并将处理后的数据反馈给他们。

为了解决智能驾驶这种跨功能域系统的重用问题，下一个发展方向就是中央服务器架构（图1.c）。众多域功能被整合在一个大型高性能计算机或计算机集群中。与域控制器架构相比，不再将传感器、执行器直接连接到中央控制单元，因为很多I/O外设无法连接到当前可用的处理器。传感器、执行器会直接连接到网络，即“智能传感器”和“智能执行器”，执行相关任务。这类传感器、执行器独立于ECU和车辆，使模块化系统具有很高的可重用潜力。相比于低成本传感器、执行器，目前这种方式不具备性价比，但是随着芯片制造成本的降低以及智能传感器、执行器跨车辆跨OEM的重用，价格劣势会逐渐减弱。

智能传感器、执行器可以直接连接到图1.c所示的蓝色集成节点。这些蓝色集成节点具有一个重要功能：它们充当传感器和执行器所连接的不同总线系统之间的网关，即CAN、LIN、FlexRay和以太网数据路由。在该网络中，为了配合中央计算机，以太网将作为主要的总线系统，通过适当抽象传感器和执行器的接口来创建模块化和功能可扩展的架构。

中央服务器的复杂架构
中央服务器或集成节点是非常复杂的ECU，它们通常由几个微控制器和微处理器组成，微控制器和微处理器在属性上可以相互补充。

微控制器的启动时间更快，在上电之后，可以快速准备好运行，继而开始与其他ECU通信并执行其功能。此外，微控制器甚至可以满足带抖动的微秒级时序要求。如果实现的功能需要频繁的中断，微控制器也更加合适。
微处理器则在其他领域具有优势，其中最重要的当然是计算性能。微处理器使用的运算核具备高时钟频率，使得多标量或跳变预测成为可能，从而提升了整体的计算性能。更大的高速缓存也允许连接慢而大的外部存储设备，除此之外，微处理器还提供更好的硬件虚拟化支持，使得Hypervisor技术的实现更为容易。微处理器加微控制器这种异构设备的另一个优点是它在安全需求方面的实现。根据ISO 26262，当前微处理器最高可达到ASIL B的安全等级。通过使用冗余设计，智能驾驶系统可达到ASIL D等级。在这样一个系统中，附加的微控制器执行两个任务：一方面执行监控任务，当故障出现时提供降级的功能，从而保证系统继续以高度的可靠性来执行它的功能。这是失效可操作系统（Fail-operational Systems）的一个重要特征，即系统发生失效时仍可以继续运行（图2）。

从外部来看，同时具有微处理器和微控制器的ECU仍然是一个单独的ECU。但从内部看，这个 ECU的功能是由多个独立的软件系统来实现的。这引发了技术和组织上的挑战。从技术的角度看，这些组件必须能够互相通信来实现一个共同的功能，ECU供应商需要通过IPC（inter-processor communication，处理器间通信）把不同系统连接起来并描述所需交互的数据。这是ECU供应商的新任务，从前的工作流程中是没有这一步的。以前ECU供应商只需要遵循OEM所定义的ECU之间的通信行为。然而现在，IPC数据库的定义则需要由ECU供应商来负责。相同的情形也适用于诊断功能、软件更新和系统的网络管理：以前为多个简单ECU定义的内容，现在需要分布式、协调性地实现。从组织的角度看，集成多种多样的软件组件代表剧增的挑战，ECU的模块化设计和POSIX标准的操作系统使得软件可以由若干独立的团队进行开发，这就导致了ECU集成工程师这一角色的任务变得越来越复杂，继而需要强大专业的工具来支持ECU集成工程师这项极具挑战性的工作。

AUTOSAR Adaptive作为中央ECU平台
微处理器上执行的软件组件通常不是基于AUTOSAR Classic标准，取而代之的是AUTOSAR Adaptive，以满足模块化、动态性和持续更新能力的需求。AUTOSAR Adaptive正在成为汽车高性能平台上约定俗成的软件标准。AUTOSAR Adaptive使用符合POSIX标准的操作系统，如Linux、 PikeOS或QNX，并为其在汽车领域的应用提供了功能扩展。AUTOSAR Adaptive的一个主要功能是通信层ara::com，它负责AUTOSAR Adaptive应用之间的通信，也负责与汽车中其他ECU之间的通信（图3）。

AUTOSAR Adaptive还为诊断、信息安全和功能安全提供功能支持。这与AUTOSAR Classic基础软件非常相似，但是有一些架构和技术上的区别，例如ara::com是一个面向服务的中间件，这使得在运行期间动态创建通信路径成为可能，这种动态性是ECU运行期间安装软件的前提。然而在AUTOSAR Classic中，需要首先修改通信矩阵，然后才能让ECU接收或发送新的内容。使用面向服务的方法，可以动态建立服务的订阅，从而实现硬件驱动和上层软件更严格的分离，使得汽车中独立于硬件的应用变得高度可移植。与基于AUTOSAR Classic的ECU相比，这种方式更加优化了资源配置。例如，在开发阶段，如果某个ECU的资源达到上限，可以在不更改硬件的情况下把软件轻松的移植到另一个或另几个ECU上，软件组件在不同车型上的重用性大大提升。

在AUTOSAR Adaptive项目中，软硬件隔离使得OEM和供应商之间的任务分配有了新的变化。从前一个功能块通常被作为汽车中的一个物理设备来订购，现在完全可以做到只采购软件。为了实现这种方式，每个AUTOSAR Adaptive应用都是一个独立的二进制文件，应用开发将独立于ECU开发。通过安装应用商店的应用，汽车司机自己也可以成为一个软件集成者。

但假如运行的系统出现了故障，谁该为此负责呢？未经测试的应用组合可以被安装在车辆上，这种情形和传统的ECU集成要求相冲突，AUTOSAR Classic下每一个配置都需要经过彻底的测试。为了避免测试AUTOSAR Adaptive上所有应用的组合，必须保证应用之间无干扰。操作系统可以保证安全相关的应用不会超过内存上限。为了达到这个目的，操作系统提供硬实时调度方法，为应用定义内存上限和最差情况执行时间。因为没有与硬件的直接交互，中断导致的负载变化变得不再重要。

当然，这个做法仅针对安全相关的应用。当使用Hypervisor时，不同程度动态性和安全性的系统可以并行运行，QM等级的应用可以被置于系统中更动态、更像IT的分区中，也可以使用开源软件。在涉及安全的分区中，则需要格外小心，因为软件错误和安全漏洞无法被快速消除，而且使用开源软件还涉及到产品可靠性的风险。

展望
性能和软件开发灵活性的需求伴随着成本敏感度日益增长，它需要整个供应链的变化，AUTOSAR Adaptive是未来高性能ECU开发的一个必要组件，E/E架构的适配已经在当前一代的汽车中显现，将功能从传感器、执行器转换到中央ECU的这一过程，会逐步实现。