万字综述:域控制器四大支柱(下)

发布于 2022-11-3 17:50
浏览
0收藏

万字综述:域控制器四大支柱(下)-汽车开发者社区

自适应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算力统计


万字综述:域控制器四大支柱(下)-汽车开发者社区


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

收藏
回复
举报
回复
相关推荐