万字综述：域控制器四大支柱（下）

自适应Autosar

AUTOSAR只是一个软件框架，不具备实操意义（务虚）。必须购购买第三方的软件系统或二次开发，全球主要有三家商业化的Autosar软件供应商，分别是Vector、EB和ETAS。EB属于德国大陆汽车软件子公司，独立性略差，硬件方方面与瑞萨和英飞凌捆绑稍明显，ETAS规模比较小，ETAS铺盖面最广，独立性最强，规模最大，因此Vector市市场占有率最高，大约有70%。

AUTOSAR结构比较臃肿，想定义一切，灵活性不高，新兴造车通通常不感兴趣。开发AUTOSAR和硬件也捆绑得有点紧，比如国内普华基础软件就跟意法半导体捆绑的紧。

国内有东软、恒润、普华和华为在做，需要芯片厂家配合提供MCAL抽象层，但芯片厂家地位超然，不屑于和小公司合作。普华汽车电子事业部国内唯一通过ASIPICE三级和ASIL D级认证的公司，隶属中中国电子科技集团，国企背景。主要客户包括一汽、东风、长安、奇瑞、江淮等国企。

即便是大公司如奔驰宝马也是购买Vector的Autosar工具MICROSAR。

奔驰的Vector Microsar

为什么要搞自适应Autosar，因为经典Autosar只能对应OSEK这样复杂程度很低的嵌入式操作系统，无法适应Linux这样的大型操作系统，而自动驾驶和部分智能驾驶操作系统都是Linux，因此催生了自适应Autosar。

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），安全和以太网。增强利用ImprovedExploitation组，负责命题（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目前对中小企业来说恐怕不合适，标准未完善，一次性投入过高，开发难度过高，开发周期长。

上图为Vector的自适应Autosar产品Adaptice MICROSAR 配置开发工具和工作流。

上图为Vector推荐的自适应Autosar开发流程图，与经典Autosar不同，自适应Autosar要求最好和整车电子架构一起开发，因为自适应Auotsar是整车电子架构的核心底层。因此自适应Autosar常常与整车电子设计架构软件PREEvision捆绑。

PREEvision分4层

需求层（Requirements Layer）：该层需要导入需求开发的输出物：需求说明书，作为工程设计的指导文件。需求层一般由三部分组成：Requirement、Customer Feature、FFN。

功能逻辑层：该层用于描述系统的逻辑功能关系，即系统功能的模块框架以及各模块之间的接口关系。主要包括两个层面的内容：系统逻辑架构层和软件架构层。前者关注系统功能实现的所有逻辑关系；后者关注系统实现过程中的软件相关的逻辑关系。内容包括逻辑传感器、功能块、逻辑执行器等功能模块，以及各功能模块之间的信息交互接口（Port）。当各模块之间的端口通过信息交互接口连接后，相应模块就能进行数据和控制信息的交换。在功能逻辑架构中，开发人员可以方便的查看各个功能模块之间的逻辑关系。

硬件架构层（Hardware Architecture Layer）：该层主要包括网络层（Network Layer）、部件层（Components Layer）和线路原理层（Schematic/Circuit Layer）。网络层主要描述各个部件之间的逻辑链接方式，如总线系统、传统连接、电源供应和地线连接等（还会在线路原理层进行进一步细化）；部件层描述每个部件内部构成及其对外接口的详细信息；线路原理层描述网络层中逻辑连接的具体实现情况，如：具体导线、线缆连接方式、保险继电器盒内部结构等。

E/E架构

先进E/E架构实际就是车载以太网和自适应Autosar的具体应用。无论是软件定义汽车还是服务架构导向，其最核心的支柱也是车载以太网和自适应Autosar。

上图为汽车E/E架构演进路线图，资料来源：博世

Vehicle Computer阶段实际就是Zonal架构，Centralization中央化就是域控制器架构。这都离不开TSN。

TSN为骨干网的Zonal架构

Zonal架构可算是SOA架构的典型代表，可以说SOA架构离不开TSN。ADAS/座舱/车身三个运算单元类似大众MEB里的ICAS。

大众的MEB架构

网关中最核心的则是对应TSN的交换机

Zonal网关的内部框架图

CAN到以太网，即SOME/IP-UDP-IP-MAC，或TCP-IP-MAC。这也意味着经典Autosar或自适应Autosar不可或缺。TSN、Autosar是SOA不可或缺的成分。

帧的分组，包括目的地，优先级，截至周期等

高性能处理器

上图为ARM在2017年投资者大会上发布的内容，ARM预计2020年顶级座舱的算力是50K DMIPS

   智能座舱典型功能，资料来源：IHS Markit

对于座舱来说，决定其功能和性能的关键是主SoC的算力，衡量CPU算力的单位主要是DMI。

PS，DMIPS是DhrystoneMillion Instructions Per Second的缩写，每秒处理的百万级的机器语言指令数。基本上SoC高于20000DMIPS才能流畅地运行智能座舱的主要功能（AR导航或云导航、360全景、播放流媒体、AR-HUD、多操作系统虚拟机等），GPU方面，只需要100GFLOPS的算力就可以支持3个720P屏幕，因此简单定义一下，CPU高于20000DMIPS，GPU高于100GFLOPS的SoC的座舱就是智能座舱。

程序编译和运行过程中，代码会经过编译器转化成机器可以理解的指令。CPU每个指令周期分为取指令、指令译码、指令执行三个过程，只有在指令执行时才真正有效，在取指令和指令译码时，CPU时间是白白浪费的，而同样的运算在不同架构不同指令集需要的指令数也不一样。

不同的CPU指令集不同、硬件加速器不同、CPU架构不同，导致不能简单的用核心数和CPU主频来评估性能，所以出了一个跑分算法叫Dhrystone：程序用来测试CPU整数计算性能，其输出结果为每秒钟运行Dhrystone的次数，即每秒钟迭代主循环的次数。

Dhrystone所代表的处理器分数比MIPS（million instructionsper second 每秒钟执行的指令数）更有意义，因为在不同的指令系统中，比如RISC（Reduced Instruction Set Computer精简指令集计算机）系统和CISC（ComplexInstruction Set Computer复杂指令集计算机）系统，Dhrystone的得分更能表现其真正性能。由于在一个高级任务中，RISC可能需要更多的指令，但是其执行的时间可能会比在CISC中的一条指令还要快。由于Dhrystone仅将每秒钟程序执行次数作为指标，所以可以让不同的机器用其自身的方式去完成任务。另一项基于Dhrystone的分数为DMIPS（DhrystoneMIPS），其含义为每秒钟执行Dhrystone的次数除以1757（这一数值来自于VAX 11/780机器，此机器在名义上为1MIPS机器，它每秒运行Dhrystone次数为1757次）。

影响CPU算力最关键的参数是Decode Wide译码宽度，译码宽度可简单等同于每周期指令数量即IPC，即每个周期完成多少个指令。

译码宽度的增加是非常困难的，不是想多少就多少的，简单来说每增加一位宽度，系统复杂度会提高15%左右，裸晶面积也就是成本会增加15-20%左右。如果简单地增加译码宽度，那么成本也会增加，厂家就缺乏更新的动力，所以ARM的做法是配合台积电和三星的先进工艺，利用晶体管密度的提高来减少裸晶面积降低成本，因此ARM的每一次译码宽度升级都需要先进制造工艺的配合，否则成本增加比较多。同时ARM也从商业角度考虑，每年小升级一次，年年都有提升空间。8位宽度是目前的极限，苹果一次到位使用8位宽度，缺点是必须使用台积电最先进的制造工艺，但苹果依然使用的是ARM的指令集。

此外，RISC和CISC还有区别，CISC增加宽度更难，但CISC的1位宽度基本可顶RISC的1.2-1.5位。英特尔是有实力压制苹果的，就是制造工艺不如台积电。CISC指令的长度不固定，RISC则是固定的。因为长度固定，可以分割为8个并行指令进入8个解码器，但CISC就不能，它不知道指令的长度。因此CISC的分支预测器比RISC要复杂很多，当然目前RISC也有长度可变的指令。遇到有些长指令，CISC可以一次完成，RISC因为长度固定，就像公交车站，一定要在某个站停留一下，肯定不如CISC快。也就是说，RISC一定要跟指令集，操作系统做优化，RISC是以软件为核心，针对某些特定软件做的硬件，而CISC相反，他以硬件为核心，针对所有类型的软件开发的。

 目前与未来常见座舱与智能驾驶SoC算力统计

本文转载自公众号：焉知智能汽车