内容提要：配备强大的中央计算机的AUTOSAR Adaptive Platform能够为未来实现更高级别的车辆架构。

得益于新的AUTOSAR Adaptive（自适应汽车开放系统架构）软件标准，如今车辆中的E/E架构逐渐变得更强大、更灵活。当前，基于以太网的ECU（电子控制单元）广泛用作AUTOSAR Adaptive体系结构中的中央应用服务器。其最大的优点在于：在车辆的整个生命周期内，自适应ECU可以实现应用程序的更新，并便于后期添加新的软件功能。

随着汽车的更新换代，高度发达的驾驶功能将对网络架构和各个ECU之间的相互作用产生巨大影响。同时，驾驶辅助系统的不断发展，以及高水平自动驾驶功能的研发都离不开由雷达、激光雷达和各种摄像头组成的先进传感器。这些传感器为车辆提供了一致的环境模型，也就要求车辆网络必须在短时间内传输和处理大量数据。仅仅就数据传输这一方面，就需要能够在较低延时的情况下实现高数据吞吐量的网络体系结构。此外，传感器数据的融合也离不开通过特殊的硬件来处理复杂算法的高性能车载计算系统。在此计算过程链中，必须将传感器和执行器等安全地、且低延迟地集成到车辆中。

· 新功能对车辆架构的影响

IT后端上可用的数字服务对汽车架构有很大的影响。具体来说，高带宽移动无线电接口和低延时V2X通信可提供环境条件相关的信息（例如天气、交通流和建筑区域）；ECU将这些数据与路线信息以及车辆传感器获取的周围环境数据汇总在一起；车载计算系统执行必要的图形密集型操作；而用户配置的高分辨率显示群集或平视显示器将显示计算结果。

因此，必须保证这些与外界相连的无线接口以及复杂数据传输的安全性。即使是相对简单的电动车辆，也要与充电站建立安全连接，因为会涉及到充电计费。而这种安全的充电通信的实现离不开车辆计算能力的提高。

到2025年，借助于这些新功能，电子和软件对车辆增值的促进比例将提高到65％，其中软件的比例增长最多，将达到25％左右。随着车辆系统变得越来越复杂，在ECU开发过程中需要对任务进行更严格划分。尽管ECU的硬件开发通常由1级供应商完成，但汽车OEM普遍拥有更多种类的软件资源，这也是一个非常重要的竞争要素。OEM既可以进行内部算法开发，也可以从专门的第三方供应商处购买软件组件。

· 高要求的新系统

在ECU投入生产后，汽车OEM或终端应该能够在后期随时添加或修改软件功能，例如扩展车辆等。但是，第三方供应商在搜寻潜在软件的过程中创造了新的市场形势，为此，动态软件集成环境在未来车辆平台中成为必要的属性。为了执行将来车辆中的计算密集型算法和功能，需要功能更强大的ECU），因此配备64位多核处理器和MMU（内存管理单元）作为支持。

这些处理器为虚拟化技术和与外部存储器的快速连接提供了额外的硬件支持。SoC作为硬件加速器，可以对图形、图像和算法进行处理，从而以较低功耗来实现所需的处理速率。ECU中还使用了用于实现安全相关功能的其他微控制器或SoC，以及用于防止未经授权的组件访问，例如非法访问硬件安全模块（HSM）和可信平台模块（TPM）。

即使未来车辆技术高速发展，与车辆内部网络和车辆外部连接的接口仍然发挥重要作用。在车辆内部，基于IEEE 100BASE-T1（100 Mbit / s）或1000BASE-T1（1 Gbit / s）的以太网将作为骨干网来不断改变网络结构并增加数据吞吐量。与此同时，外部通信接口（例如WiFi、蓝牙、5G和V2X）也实现了高数据吞吐量。通过LVDS（低电压差分信号）或APIX（汽车像素链路）连接到传感器和执行器的接口也十分常见，这些接口的传输速率在千兆位范围内。虽然之前的常规总线系统会得到沿用，但它将不再在整个车辆集成中发挥主导作用。

高数据吞吐量硬件的有效使用离不开灵活的软件体系结构。通常，基于POSIX（可移植操作系统接口）的操作系统是使用复杂处理器及其外围设备的先决条件，此类操作系统包括Linux以及安全相关系统（如PikeOS）。许多类型的库和开发框架，特别是图形和人工智能应用程序库，也能够有效地帮助软件功能开发。

· AUTOSAR Adaptive：新标准

为了满足这些新要求，除了已建立的Classic Platform之外，AUTOSAR联盟还定义了另一个标准：AUTOSAR Adaptive Platform。Classic Platform支持成本优化的微控制器。但是，在以太网、安全性和功能安全性领域中，这些功能较弱的处理器也可用来实现具有挑战性的应用程序。传统平台主要用于执行ECU，这些ECU直接访问传感器和执行器，并且需要满足严格的实时性要求。另一方面，Adaptive Platform旨在支持具有特殊性能要求的应用程序（如高度自动化的驾驶），它能够提供一个灵活、拥有较强更新和扩展能力的集成环境。显然，Adaptive Platform还必须满足严格的时间要求，而AUTOSAR Classic Platform更适合处理高频事件。在当前背景下，只有将Classic  ECU与自适应Adaptive AUTOSAR ECU结合起来才能满足最严格的安全要求。这是因为AUTOSAR Adaptive Platform标准能够在使用过程中赋予组件和操作系统更大的自由度和灵活性，在此过程中，POSIX-OS起到决定性作用。当前正在进行全面的研究，以确定将来是否可以将Adaptive Platform作为唯一的系统普遍用于保证每个实际用例中的功能安全。

在与AUTOSAR Classic Platform的相互作用与影响下，自适应标准为ECU提供支持，并为系统设计人员提供开发高性能车辆平台所必要的构造块。在这之前，此类ECU是通过专门方法来实现的。但是， AUTOSAR自适应有哪些组成成分？同时这两个平台从技术上方面来说有何区别（如图1）？

图片图1 AUTOSAR Classic和AUTOSAR Adaptive平台之间的差异

在自适应平台中，应用程序利用“自适应应用程序的AUTOSAR运行环境”，也称为ARA。该运行时环境为用户提供了标准化的界面，从而可以有效地将不同的应用程序集成到系统中。ARA为ECU内部和网络间通信以及基本服务（例如诊断和网络管理）的访问提供了相应的机制。此外，通过ARA，应用程序程序员可以直接访问操作系统功能的子集，即“最小实时系统配置文件”（PSE51）。

在基于POSIX的操作系统中，自适应应用程序的实现可以看作是某一个进程。在运行环境下，应用进程被加载到它们相关的虚拟地址空间中并在其中执行， 而这些进程的协同启动由应用程序控制（执行管理）模块来实现。

在此过程中，自适应环境持续提供例如诊断和网络管理之类的基本服务，这也是将ECU集成到E/E架构中的必要要求。提供基本功能的其他服务包括数据的持久保存（持续性）、平台的功能监视（平台健康管理）、访问密码操作（加密）和测量值记录（行驶和追踪）。

另外，更新和配置管理（UCM）是自适应平台的核心功能。虽然Classic Platform通常可以以更新的形式来替换整个ECU代码，但Adaptive Platform现在提供了能够删除、更新或添加单个应用程序的选项。每个自适应应用程序都由一个包含可执行程序和清单文件的组件进行定义，以便灵活地处理ECU（电子控制单元）功能。除了可以对应用程序的接口（如面向服务的通信端口和IP地址）进行建模，清单文件还设立了调用参数执行应用程序的前提条件。

不同于AUTOSAR Classic Platform，C++在AUTOSAR Adaptive Platform中被用作编程语言。通过将面向对象的编程语言、动态内存管理和现有的标准库相结合，应用程序员可以有效地开发出具有挑战性的可重用软件。

Adaptive Platform的另一个特性是可以过渡到专门面向服务的体系结构范例，这为系统设计提供了更大的灵活性。在自适应平台的帮助下，应用程序将其自身功能的提供作为一项可以使用的服务（图2）。执行Adaptive Platform的ECU通过以太网进行互连。客户端预先向服务器提供的服务发出请求，该信息与面向IP的可扩展服务导向中间件（SOME / IP）网络协议通过以太网一起传输，同时服务器使用相关数据回复请求。此数据的序列化也由可扩展服务导向中间件（SOME / IP）进行定义。相比之下，Classic Platform平台的重点主要在于面向信号的通信。但是，通过基于服务的方式，AUTOSAR Classic Platform也可与Adaptive Platform一样通过太网连接和可扩展服务导向中间件（SOME / IP）实现多个ECU（电子控制单元）之间的通信。

图2 AUTOSAR自适应应用程序的接口

实际上，AUTOSAR Adaptive Platform和Classic Platform的主要属性是相辅相成的。因此，可以假定基于这两种标准的ECU的应用会造成未来车辆体系结构的异构。除了熟悉的Classic Platform的功能实现之外，矢量自适应MICROSAR（多核功能安全架构）等自适应平台解决方案目前已经在市场上得到应用。

· 域控制器和网关

一些现代车辆具有以域为中心的E/E架构，该架构根据其逻辑作业将车辆功能（如咨询宣传、车身控制器和传动系统）分配到各个域中。每个域都有自己的域控制器，它们通过以太网互连，并且与分配其中的其他ECU进行协调，从而对传感器和执行器进行访问。诸如CAN或LIN之类的车辆总线与特定域控制器进行连接，而另一个称为连接单元的控制器通过板外诊断程序、蓝牙和移动无线电实现车辆与外界的连接。

AUTOSAR Adaptive的使用不会导致基本车辆架构的突然改变（图3）。但其中最显着的变化是车辆中以太网的普遍应用以及相关交换器的使用，每个交换器都在ECU之间产生无碰撞的点对点连接。为了优化线束，这些交换器以集成形式，而非作为单独的ECU来执行操作。此外，通过各种不同的高性能接口，多台高性能计算机将会连接到雷达/激光传感器、摄像机、显示器和其他ECU。在这些连接中最重要的是用于确保在传感器级别和执行器级别进行访问的ECU，以及常规的高频和高时效性数据传输总线系统之间的网关。另一方面，配备有Adaptive Platform软件的高性能计算机可以处理车辆网络中的通信任务和计算密集型任务。

图3 具有AUTOSAR Adaptive和AUTOSAR Classic的车辆架构

在这种情况下，如何实现自适应和传统ECU的相互通信就成为了一个问题。在最简单的案例中，通过以太网互连的ECU在可扩展服务导向中间件（SOME/IP）上使用面向服务的通信（图4），其中AUTOSAR Classic ECU1连接到与其他ECU（电子控制单元）相连的多个总线系统。ECU1此配置中充当网关，并负责把来自总线侧的消息信号“打包”到服务中，以便AUTOSAR Adaptive Platform可以直接对其进行访问。不论Classic Platform平台还是Adaptive Platform，通信布局都是AUTOSAR ECU设计的固定组成部分。但是，由于两个平台的配置格式不同，因此有必要通过转换的形式来映射服务配置。

图4 通过以太网和SOME / IP进行平台间通信

与仅基于信号的AUTOSAR Classic ECU进行通信时，情况更加复杂内可用的服务。除了通过通信矩阵进行信号描述之外，基于此架构的操作执行还需要将服务的映射规则作为AUTOSAR Classic Platform配置的组成部分。这些映射规则已经作为AUTOSAR Adaptive Platform规范的一部分进行了标准化。服务到信号的映射基于这些规则进行编码，并作为ECU中的独立服务来执行。

· 掌握软件复杂性

向车辆自动化和扩展通信的范式转换既要求处理和传输大量的数据，也需要掌握由此产生的软件复杂性，而当前系统几乎无法满足这些严格的要求。这就是为什么基于以太网的，拥有面向服务的通信，以及配备强大的中央计算机的AUTOSAR Adaptive Platform能够为未来实现更高级别的车辆架构提供最佳基础的原因。在此开发过程中，对于AUTOSAR Adaptive Platform和Classic ECU，可以通过灵活的网关方案实现两者的并行连接使用。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！