布谷鸟信息技术（布谷鸟产研-全面了解自适应Autosar）

经典Autosar是将MCU硬件与软件层分离，提高软件复用率，减少工作量。自适应Autosar是将POSIX操作系统与上层API分离，让软件开发变成APP开发。一般情况下，POSIX系统的应用程序通过应用编程接口(API)而不是直接通过系统调用来编程。本文由布谷鸟科技-产研首席分析师周彦武老师编写。

Adaptive Autosar，自适应Autosar第一版诞生自2017年3月，目前已经有6版，最新版本是2019年11月。据说第一版的自适应Autosar的英文规格书用A4纸打印出来摞起来有7米高。

经典Autosar与自适应Autosar对比，目前Autosar有284个会员，9个核心会员，分别是宝马、奔驰、大陆汽车、福特、戴姆勒、PSA、通用汽车、丰田和大众。两个战略会员，电装和LG电子。55个高级会员，其中中国企业有长城、华为、百度、香港英恒。另外说一句，这4家企业是近两年才成为高级会员的，2017年高级会员没有中国企业。

Autosar组织结构，主要工作由Working组完成。

Working组架构如上图。用户组下面再分三个小组，分别是中国组，负责演示开发和基础软件集成。北美组，负责一般性培训（OEM-Tier1 Workflows/Security），安全和以太网。增强利用Improved Exploitation组，负责命题（Thesis）优化。

自适应Autosar路线图，版本是不能混用的，比如你买了R19-03的部分模块，剩下的模块想用R19-11版是不可能的。Adaptive AUTOSAR中，主要包含两种Application：

1）Application-Level的Application

2）Platform-Level的Application

Application-Level的Application会生成源代码和目标代码，这部分与 “用户” 有关。Platform-Level的Application会生成目标代码，这部分与 "工具供应商" 有关。不是所有工具供应商都能提供完整的Platform-Level的Application，通常只能提供部分，某些领域，标准未确定，如V2X，工具供应商几乎完全无能为力。

自适应Autosar与经典Autosar计划增加的特色有23个，例如针对中国特色的V2X。

自适应Autosar是针对自动驾驶的，2021年11月版计划对应L3级自动驾驶，不过这个L3级换到中国或者马斯克口中，估计是L5了，目前一般推荐19-03版，比较稳定。

自适应Autosar典型应用场景

自适应Autosar的层架构如上图。基础服务层中，主要服务包括，通信服务（COM）、加密服务（crypto）、日志记录服务（Log）、诊断服务（Diag）、存储服务（Per）、状态管理（SM）、执行管理（Exec）、时间同步（Tsync）、升级配置管理（UCM）等。

非Autosar、经典Autosar和自适应Autosar对比

ARA的COM架构，还是Autosar定义的ARXML文件格式为核心。

ARA工具链

自适应Autosar关键点一：Everything is a process .. as in “OS process”，一切都是一个进程，OS中的进程。

关键点二：面向服务的进程间通讯。

每个AA（自适应应用或者说APP）都作为一个独立的进程来实现，具有自己的逻辑内存空间和名称空间。一个AA可以包含多个进程，并且可以应用到一个AP（自适应平台）实例上，或者分布在多个AP实例上。从模块组织的角度来看，每个进程都是由操作系统在可执行文件中去实现的。可以从单个可执行文件实现多个进程。AA可以构成多个可执行文件。从操作系统的角度上看，一个AP模块只形成一组进程，每个进程包含一个或多个线程 。这些进程通过IPC或任何其他可用的操作系统功能相互作用。但是，AA进程不能直接使用IPC，只能通过ARA（AUTOSAR Runtime for Adaptive applications） 的进行通信。

为了与AA交互，还需要使用IPC。要实现这一点，有两种可选设计。一种是“基于库”的设计，其中接口库由功能集群提供并链接到AA，直接调用IPC。另一种是“基于服务”的设计，流程使用通信管理功能，并有一个链接到AA的服务器代理库。代理库调用通信管理接口，该接口协调AA进程和服务器进程之间的IPC。实现定义决定了AA是只执行带有通信管理的IPC，还是通过代理库与服务器混合使用IPC。

Application就是OS的一个一个进程，Autosar 采用一个Manifest用来配置管理这些进程信息，包含平台相关的信息，恢复操作以及与服务或库相关的依赖关系，Instance 配置文件主要包含静态的信息，这里会配合执行管理Exec、升级与配置管理UCM以及状态管理SM等来配合管理进程。自适应Autosar采用Proxy/Skeleton的通信架构，同时采用中间件SOME/IP。

目前明确使用自适应Autosar的量产车就是大众的MEB平台。

大众MEB的软件架构，POSIX可以是Linux、VxWorks、QNX、Integrity等。

经典Autosar是将MCU硬件与软件层分离，提高软件复用率，减少工作量。自适应Autosar是将POSIX操作系统与上层API分离，让软件开发变成APP开发。一般情况下，POSIX系统的应用程序通过应用编程接口(API)而不是直接通过系统调用来编程(即并不需要和内核提供的系统调用来编程)。一个API定义了一组应用程序使用的编程接口。它们可以实现成调用一个系统，也可以通过调用多个系统来实现，而完全不使用任何系统调用也不存在问题。实际上，API可以在各种不同的操作系统上实现给应用程序提供完全相同的接口，而它们本身在这些系统上的实现却可能迥异。如下图，当应用程序调用printf()函数时，printf函数会调用C库中的printf，继而调用C库中的write，C库最后调用内核的write()。而经典Autosar的前身OSEK是不可能的。

从程序员的角度看，系统调用无关紧要，只需要跟API打交道。相反，内核只跟系统调用打交道，库函数及应用程序是怎么系统调用不是内核所关心的。

那个大众API就是大众所说的VW.OS。大众定义输入输出，第三方软件开发商基于这个定义开发APP。

PPE是奥迪的下一代电动车平台，大众在2023年开始全部使用VW.OS。

上图以WindRiver的操作系统为例，显示出Autosar的另一个优势，灵活架构。对于安全性和实时性要求高的领域采用VxWorks，对于要求不高也达不到高安全性的如深度学习（无功能安全要求）等采用Linux。在虚拟机上实现两个操作系统。顺便说一句Windriver是全球最大的商业RTOS供应商，最大的嵌入式商业Linux供应商。Windriver已经在2018年脱离英特尔独立。

多种操作系统等于自适应Autosar可以构建时间分区架构。避免各个CPU核心之间的干扰。保证ADAS的安全性。

以Windriver产品为例L4级无人驾驶的自适应Autosar软件架构。对V2X 5G和高精度地图非常友好。

大陆汽车子公司Elektrobit的Corbos自适应Autosar架构

自适应Autosar将运行的硬件视为一台机器，实现一致的平台视图，而不考虑所使用的虚拟化技术。这台机器可能是一台真正的物理机器、一台完全虚拟化的机器、一个准虚拟化的操作系统、一个操作系统级的虚拟化容器或任何其他虚拟化环境。在硬件上，可以有一台或多台机器，并且只有一个自适应Autosar服务在机器上运行。这种“硬件”上一般会有一个芯片，并承载着一台或多台机器。然而，如果自适应Autosar服务允许的话，多个芯片也可能形成一台机器。

自适应Autosar也使得车内电子架构得以大幅度跃进，进入中央化和区域化时代。

自适应Autosar平台与经典Autosar网关连接

自适应Autosar、车载TSN以太网、Zonal架构是三位一体的，也是未来汽车电子的核心。不过自适应Autosar目前对中小企业来说恐怕不合适，标准未完善，一次性投入过高，开发难度过高，开发周期长。

,