一文聊聊汽车软件中心件（Autosar为例）

其余中间件的定位不是操作系统，而是一套软件框架，虽然包括了RTOS，MCAL，做事通信层等协议和做事。
两者看着很靠近，但没有多少竞争关系。

随着汽车运用哀求的不断提高，软件总量也随之迅速增长，这导致了系统的繁芜性和本钱的剧增，为了提高软件的管理性、移植性、裁剪性和质量，须要定义一套架构( Architecture )；方法学( Methodology )和运用接口( Application Interface )。
从而实现标准的接口、高质量的无缝集成、高效的开拓以及通过新的模型来管理繁芜的系统。

目前在汽车掌握领域有多种总线标准，各侧重点有所不同。
只管总线通信速率越来越高，但是还没有通信网络可以完备知足未来汽车的所有本钱和性能哀求，因此须要兼容多种总线和底层协议的通信协议和规范。

中间件的核心思想在于“统一标准、分散实现、集中配置”。
统一标准才能给各个厂商供应一个通用的开放的平台；分散实现则哀求软件系统层次化、模块化，并且降落运用与平台之间的耦合度；不同模块来自不同的厂商，它们之间存在繁芜的相互联系，要想将其整合成一个完善的系统，必须哀求将所有模块的配置信息以统一的格式集中管理起来，集中配置天生系统。

这个架构还须要具备如下功能：办理汽车功能的可用性和安全性需求；保持汽车电子系统一定的冗余；可以移植到不同汽车的不同平台上；实现标准的基本系统功能作为汽车供应商的标准软件模块；通过网络共享软件功能；集成多个开拓商供应的软件模块；在产品生命期内更好地进行软件掩护；更充分地利用硬件平台的处理能力；可实现汽车电子软件的更新和升级等。

所有把标准统一后的做事的上风都大同小异，总结紧张几点

对付Autosar，说实话，最有利的是OEM和根本软件公司，OEM可以标准化接口，自己做运用层或找软件公司开拓运用，根本软件公司可以多卖软件。
最不愿意的是tier1，由于增加了本钱，还逐步可能沦为硬件生产商。
但这个也不能说是autosar的锅，软件定义汽车下这个趋势的发展是一定的。

汽车软件中间件有什么缺陷？

诚笃讲，这块大家讲的很少，都说这个很美好，但实际操作过程中，我以为是软硬件一体设计上的阻碍。

值得把稳的像Tesla这样的新兴企业并没有利用autosar这是为什么？所有平台性的软件，都有一个弊病，便是为了兼容同等性，会对软硬件协作的效率带来影响，autosar也不例外。

我觉得“Autosar便是汽车行业的塞班系统，看似很好，很标准，但是终极会被淘汰。
就像当年的诺基亚一样，缘故原由是末了会被一个软硬件集成度更好的iphone取代，iphone可不纠结能够给其他公司用自己的系统。

从商业和本钱角度看

Autosar设计上已经有些掉队，代码臃肿，对本钱影响很大。
打个比方，北美一个程序员一年的cost也便是15万美金，自己完成底层的开拓就这个价，利用Autosar的工具链和代码臃肿带来的升级MCU开销远大于节省的这部分开拓本钱。
细分Autosar的本钱：

1.开拓本钱:首先须要购买autosar，本身便是本钱，autosar包含的模块多，肯定要贵，但不一定所有的都会被用上。
其次是人力投入，对付一个原来就有其他平台的新的第一个项目转换到autosar是增加人力的，对付新公司，购买autosar是降落人力的，很多模块不用自己开拓了。
对付建立平台往后的项目，实际差不多。

2.生产本钱:首先是硬件本钱，现在MCU越来越便宜，用不用autosar基本没差异，如果说存储空间特殊小的MCU，比如防夹模块，本来也没哀求autosar。
其次是软件本钱，这个才是问题，跟以前根本软件不同autosar现在收量产license费。

从技能角度看

关于autosar的运用，autosar之前定义的紧张便是BCM、TCU、EMS、ESP等哀求实时掌握的ECU。
不是针对娱乐系统，自动驾驶MPU的，当然这些掌握器里也有MCU，可以用运行autosar的MCU。
autosar现在最善于的是16bit MCU以及不太繁芜的32bitMCU。
32bit以上的MCU，须要RTOS支持，比如自动驾驶软件。
车的中控也不可能基于autosar,也是由于没有一个强有力的RTOS， 在越来越强调security的软件开拓中，AUTOSAR也没有进程隔离的观点。
前景难料.

所有中间件方案中，最著名的是AUTOSAR, 其是由各大整车厂商和零部件厂商开始动手联合制订软件的标准化接口。
AUTOSAR(AUTomotive Open System ARchitecture)是由环球的紧张汽车生产厂商、零部件供应商、软硬件和电子工业等企业(如BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等)共同制订的汽车开放式系统架构标准。

2003年7月，由宝马、博世、大陆、戴姆勒-克莱斯勒、西门子VDO和大众联合成立AUTOSAR发展同盟，为汽车E/E架构建立了一种开放式的行业标准。

2003年11月，福特公司作为核心伙伴加入，12月标致雪铁龙和丰田汽车加入。
接下来的11月通用汽车也作为核心伙伴加入。
自从西门子VDO被大陆在2008年2月收购后，它就不再作为AUTOSAR的独立核心伙伴。

在2013年，AUTOSAR同盟进入一种持续改进模式，紧张用来坚持标准和供应所选择的改进,今后实际上，autosar更新就很少了，开始转向AUTOSAR-Adaptive。

对付用于实现范例动力总成和底盘功能的深度嵌入式系统，AUTOSAR经典平台仍将是首选。
在低本钱硬件上运行时，对安全性、实时性和确定性哀求较高。
同时，AUTOSAR为这些运用程序供应了一个经由良好验证的成熟软件平台，包括一个广泛利用的方法，它支持当今所有的协作模型。
而为了支持客户运用程序的动态支配，并为须要高端打算能力的运用程序供应环境，AUTOSAR在2017年推出了第二个软件平台，即AUTOSAR Adaptive platform。
这个想法是尽可能从其他领域(如消费电子产品)的发展中获益，同时仍旧考虑汽车的特定哀求，如功能安全。

Adaptive须要支持，未来E/E架构的两个关键特色是：

1) 异构软件平台的集成，当今汽车的网络架构可以聚拢身分歧的领域，用于信息娱乐和连接、底盘、动力系统等。
虽然infotainment ECUs常日利用Linux、QNX或其他通用操作系统，但AUTOSAR Classic平台是深度嵌入式掌握单元的标准。
随着新的用例和对打算能力的深入嵌入式运用程序不断增长的需求，第三种ecu将涌现，它具有不同的特性，必须集成到现有的E/E体系构造中。

2) 面向做事和基于旗子暗记的通信，传统的汽车通信仍旧是基于ecu向其他ecu供应旗子暗记广播的思想。
这种范式非常适宜于有限大小的掌握数据，这些数据必须循环地进行通信。
前辈的运用程序，如高自动化驾驶与更高的负载哀求，例如交流工具列表检测到的一组传感器和以太网作为一个通信系统须要更繁芜的协议。
面向做事通信的观点是基于在通信系统上供应做事的运用程序和订阅此做事的其他运用程序。
然后数据只发送给订阅做事器。

面向做事的通信与现有的基于旗子暗记的范式的结合是未来E/E体系构造的第二个关键方面，从这个角度来看，这是一个艰巨的寻衅。

为理解决AUTOSAR僵化的问题，Adaptive希望可以找到一种中间过程平台

ADAPTIVE为承载这些功能的软件根本举动步伐增加了新的需求。
除了现有的需求(如功能安全和安全性)，软件架构还必须支持硬件(如具有高端打算能力的硬件)、空中更新、与后端系统的通信或运用程序的动态支配。

AUTOSAR Adaptive扩展了AUTOSAR平台，以知足当前汽车自动驾驶、电气化和互联互通等趋势的需求。
因此，它在许多方面改变了已建立的E/E开拓过程。
最主要的变革是，基于旗子暗记的通信被面向做事的设计所取代。
c++取代了C措辞作为自适应运用程序的编程措辞，以及基于posix的操作系统(如Linux用于自适应电子掌握单元)是进一步的打破性转变。

AUTOSAR Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议，IPC等)，同时供应代理(Proxy)-骨架(Skeleton)模型，该模型以C 面向工具措辞描述，方便上层运用开拓职员调用标准做事接口(API)进行开拓。
Application Design Model是该模型另一种可配置的呈现，开拓职员通过利用相应的配置工具对Application Design Model进行描述和配置，即可实现基于SOA做事架构的软件落地和支配。
联合电子利用AUTOSAR Adaptive组件完成SOA做事架构软件的开拓

可以看到，自适应Autosar又找到了延续自己生命的其余一个情由，供应了一种由现在旗子暗记导向的架构往SOA架构的标准。
未来由于掌握器数量大幅度降落, 类似特斯拉这样的车企多数是不理会自适应AutosarAdaptive

与此同时，更多的干系配套供应商也在加快与AUTOSAR自适应平台的对接。
去年11月，Real-Time Innovations（RTI）宣告，AUTOSAR最新版本的自适应平台（版本18-10），已经具有数据分发做事(DDS)标准的完全网络绑定。
这意味着汽车制造商现在可以利用DDS实现AUTOSAR自适应框架，并开拓高度自动驾驶系统，如4级和5级。
DDS许可AUTOSAR完备支持高度自动驾驶系统，并供应“量产级通信框架”，担保这些繁芜系统所需的可靠性、可伸缩性和性能。
比如，在AUTOSAR中完备指定了DDS之后，汽车行业现在可以利用RTI Connext和DDS开拓高性能运用程序，比如传感器领悟运用程序。

AUTOSAR版本18-10有助于办理OEM软件开拓团队在支持不同价格区间车型时所面临的各种安全和连接性寻衅。
此外，许可开拓职员“动态配置平台”，以支持每个车型平台的各种操作模式和硬件功能。

技能细节-AUTOSAR的分层设计

架构层面

AUTOSAR定义一个软件分层架构以支持汽车电子系统的集成。
其体系架构从上至下依次为运用层、运行环境层(RTE)、以及根本软件层（BSW)

接着再繁芜一些，BSW再分为繁芜驱动模块， 微掌握器抽象层、ECU抽象层、系统做事层

(1)运用层。
包括运用软件组件、传感器和实行器软件组件，都位于运用层。
该层的软件组件通过RTE进行内部通讯和访问ECU资源。
运用层的软件实现独立于微掌握器、ECU。

(2)RTE层。
RTE层为运用层供应通讯做事。
RTE层的实现与ECU和详细运用干系，必须为每个ECU分别实现，AUTOSAR软件组件之间通信须要通过RTE。

(3)做事层。
包含RTOS、通信与网络管理、内存管理、诊断做事、状态管理、程序监控等做事。
它为运用和根本软件模块供应基本做事，包括：操作系统做事、汽车网络通讯和管理做事、存储做事、诊断做事和ECU状态管理。
做事层的实现部分与微掌握器、ECU和详细运用干系。

(4)ECU抽象层。
ECU抽象层抽象出ECU构造，如外设与ECU的联接办法等．虽然该层与ECU平台干系，但是与微掌握器是无关的。
这种无关性是由微掌握器抽象层来实现的。
个中封装了微掌握器层及外围设备的驱动，并对微掌握器内外设的访问进行了统一，实现了软件运用层与硬件系统的分离

(5)微掌握器的抽象层(microcontroller abstraction layer，MCAL)。
位于根本软件的最底层，包含了访问微掌握器的驱动（如I/O驱动、ADC驱动等），做到了上层软件与微掌握器的分离，以便运用的后续的移植复用。
微掌握器的抽象层是实现不同硬件接口统一化的分外层，通过微掌握器的抽象层可将硬件封装起来，避免了高层软件直接与微掌握器的寄存器打交道。
MCAL供应机制，并以此将指令、相应和信息分离身分歧的过程。
微掌握器抽象层包括微掌握器干系的驱动，它卖力管理微掌握器的外部设备，并将微掌握器的旗子暗记供应给根本软件的元件。

(6)繁芜驱动层，由于其严格的时序为运用层通过RTE访问硬件供应支持。

再繁芜一些

再再繁芜一些

接着我们从RTE层往上看

运行时环境( RTE )是运用软件和根本软件通信的桥梁，无论通信发生在 ECU之间( 如通过CAN、LIN、FlexRay、MOST等网络) ，还是在ECU内部，RTE均通过供应同等的接口和做事来实现SWC之间的通信抽象，其终极实现会因ECU的不同而有所差异。
一样平常情形下，每一层只能利用下一层的接口，并向上一层供应做事接口。

运用层中的功能由各软件组件（SWC）实现，组件中封装了部分或者全部汽车电子功能，包括对其详细功能的实现以及对应描述，如掌握大灯，空调等部件的运作，但与汽车硬件系统没有连接。

在设计开拓阶段中，软件组件通信层面引入了一个新的观点，虚拟功能总线VFB（Virtual Functional Bus），它是对AUTOSAR所有通信机制的抽象，利用VFB，开拓工程师将软件组件的通信细节抽象，只须要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，乃至ECU内部或者是与其他ECU之间的数据传输。

因此软件组件只需向VFB发送输出旗子暗记，VFB将信息传输给目标组建的输入端口，这样的办法使得在硬件定义之前，即可完成功能软件的验证，而不须要依赖于传统的硬件系统。

中间件RTE与面向工具OO（object oriented）的编程思想非常靠近，所有ECU所对应的RTE都是特定的，它卖力着软件构件间以及软件构件与根本软件之间的通信。
对付软件构件来说，根本软件不能够直接访问，必须通过RTE进入。
因而RTE也被理解成是VFB的接口实现。

而构件之间及构件与根本软件的通信关系如图所示：

AUTOSAR软件构件无法直接访问根本软件中的操作系统OS，因而在运用程序中就不存在「task」的观点，且不能动态创建线程，因此并行的任务由RTE直接管理调入的「构件运行实体」来实现。
每个软件构件大概会有一个或者多个运行实体，但是一个运行实体只对应一个入口。

方法学层面

「AUTOSAR方法论」是指在汽车电子系统开拓的某些步骤中所须要的通用技能方法。

1、 但AUTOSAR方法既非完全的过程描述也不是商业模式，也没有定义「角色」和「任务」。

2、 方法论仅是一个work-product flow，并定义了个中的依赖关系。

根据AUTOSAR方法论，完全的基于AUTOSAR规范的配置天生过程分为以上图示两部分，即系统配置过程及ECU配置过程。
两者之间并无先后关系，系统配置过程中的输入包内含有ECU配置的干系模块，ECU配置也会反馈于系统配置。
系统配置过程：

系统配置输入（System Configuration Input）必须被定义好，AUTOSAR方向于通过信息交流格式（软件构件、ECU资源、系统限定）以及模版来减少这些厨师系统设计决定的正式描述。
模板包含三部分：

配置步骤如下

输入的系统配置文件借助配置系统（configure-system）将软件构件映射到资源与计时哀求干系的ECU上，所得到的文件便是系统配置描述文件（system configuration description）。
个中包含了软件构件与ECU映射时所需把稳的限定条件，以及通信矩阵（Communication-Matrix），矩阵中描述了整车网络构造中的数据包内容及其时序关系。

ECU配置过程

系统配置完成后，天生了系统配置描述文件，作为ECU配置过程的输入。

Extract ECU-Specific Information会卖力从系统配置文件中剥离出各ECU干系的系统配置信息，如通信矩阵、拓扑构造、顶级功能组合，天生到ECU Extract of System Configuration中。

Configure ECU的是天生包含了特定ECU局部信息的ECU Configuration Description，而这些信息可以构件该特定ECU的可实行软件。

Generate Executable根据从ECU Configuration Description中得到的信息天生可实行程序。

AUTOSAR 的特性使得当ECU底层硬件配置升级时，也并不一定要牵动其他软件系统，正因其统一的标准规范，越来越多的企业将会加入到个中，这也为未来汽车电子行业内高效管理以及复用愈加繁芜的汽车软件系统奠定了根本。

系统配置紧张是将端口数据映射到通信矩阵，将SWC映射到ECU。
ECU配置紧张是将runnable(可运行实体)映射到task(任务)中。
对以上各项内容角色分工

接口层面

AUTOSAR各层软件的交互通过三类接口实现，分别是标准接口、AUTOSAR接口和AUTOSAR标准接口。
个中，标准接口用于BSW各个模块之间的交互，已用C措辞定义，如void Adc_Init (const Adc_ConfigType ConfigPtr)。
AUTOSAR接口用于软件构件（Software Component, SW-C）之间的交互或者软件构件和ECU硬件（IO硬件抽象、繁芜设备驱动）之间的交互，这类接口命名以“Rte_”为前缀。
AUTOSAR标准接口用于软件构件访问AUTOSAR做事。

依赖这种分层架构和接口定义，AUTOSR显著提高了汽车电子嵌入式软件的复用性——层级越高者，复用性越强。
值得把稳的是：

AUTOSAR在定义软件架构和接口的同时。
也定义了易于交流的硬件平台标准。
AUTOSAR标准不仅供应了根本软件模块的规范。
还供应了用于开拓分布式系统运用软件的方法。
这种方法以基于模型的软件和分布式系统描述开始。
以自动代码天生和可重复的测试结束。

Autosar也定义了与网络总线接口干系的模块，CAN,LIN等网络总线接口驱动、诊断等。
AUTOSAR的涌现使得ECU中的软件包括网络总线通信软件第三方供货成为可能。
未来的网络总线标准是否仍旧各自独立、互不兼容，目前还无法断定，但AUTOSAR却实实在在地将部分标准公开化、标准化，兼容化，而且实际的产品也已经被运用，AUTOSAR已对现在相互之间封闭的网络总线标准形成寻衅。

此外，AUTOSAR还定义了一套标准的软件开拓流程，从系统建模到天生可实行的代码，包括软件组件设计、系统配置、ECU配置和代码天生三大流程，如图

技能细节-AUTOSAR ADAPTIVE架构先容

活动推举：

ICVS中国智能汽车及自动驾驶展览会，暨同期：中国智能汽车家当链展

2022年9月26-29日

江苏·苏州国际博览中央

30,000m²展览面积

100场会议演讲

500家参展企业

30,000专业不雅观众

点击进入ICVS智能汽车家当联盟主页—>进入菜单栏展会报名页面，即可免费领取参不雅观门票，现阶段报名还将获取更多报告福利。