往期回顾
什么是AUTOSAR规范？
AUTOSAR（AUTomotive Open System ARchitecture，汽车开放系统架构）是目前应用范围最广的车载电子系统标准规范，由全球汽车制造商、零部件供应商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（Elecmal Control Unit，ECU）标准软件架构，规范了车载操作系统标准与API接口。
与IT界著名的“Talk is cheap, Show me the code.”不同，以制造业立国的国家喜欢标准，喜欢规范，所谓“无规矩不成方圆”。AUTOSAR是由欧洲主导的规范，严格意义上来讲，是由德国主导的规范。2003年，宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众等9家汽车行业巨头发起了AUTOSAR联盟的建立，这9家公司后来也称为AUTOSAR联盟的核心成员。截至2020年10月， AUTOSAR联盟已经拥有了56家高级成员、51家开发成员、144家普通成员以及24家观察员公司及机构，包括全球各大主流整车厂、一级供应商、标准软件供应商、开发工具与服务提供商、半导体供应商、高校和研究机构等。许多中国厂商也是AUTOSAR联盟成员，例如华为、百度、长城、东风、一汽、上汽、吉利、蔚来、拜腾、宁德时代等。
比较特殊的是，炙手可热的特斯拉没有加入AUTOSAR联盟，这意味着特斯拉很可能拥有自己的一套电子电气（E/E）开发流程和控制器软件架构。
AUTOSAR规范产生的背景
我们首先看看汽车行业中整车厂（OEM）和供应商的关系。
汽车行业里有众多的整车厂（OEM）和供应商。一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。
减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上；同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。
另一方面，各个供应商的开发进度往往是不同步的。人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。
这便是AUTOSAR规范制定的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。
为此，AUTOSAR联盟做了3件事情：
- 建立独立于硬件的分层软件架构；
- 为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU；
- 制定各种车辆应用接口规范，作为应用软件整合标准，以便软件在不同汽车平台复用。
通过这些手段，AUTOSAR联盟希望可以做到：
- 提高软件的可扩展性和灵活性，方便应用功能的集成和转换以及控制器网络的优化；
- 提升软件的可复用性；
- 降低产品和流程的复杂度和风险；
- 提升软件的开发和更新速度；
- 降低软件开发和维护成本。
AUTOSAR联盟提出了一个口号，叫做“Cooperate on standards, compete on implementation”，意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。
打个简单的比方。整车和零部件就好比是电脑和外设的关系，它们之间通过标准的USB接口来连接。无论是惠普的电脑，还是戴尔的电脑，无论是100块的鼠标，还是1000块的鼠标，它们都可以相互即插即用。电脑厂家可以专注做自己的电脑，而无需考虑会外接什么样的鼠标键盘；相应的，外设厂可以专注做自己的鼠标键盘，而无需考虑会用在什么样的电脑上。它们之间的接口和交换格式，已经由USB标准规定了。这就是标准化带来的便利。
AUTOSAR的基本思想
在一个汽车控制器中，除了实现具体功能及算法的应用软件，还有许多底层软件来保证控制器的正常运行，比如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。一方面，不同控制器中这部分底层软件的功能重复度很高；另一方面，这部分底层软件又跟硬件紧密相连，在一个处理器平台上写好的软件，换一个处理器平台就不能用了，而为每一个控制器项目专门写一套底层软件显然非常低效，而且也容易出错。
于是，人们就想通过标准化应用软件和底层软件之间的接口，来让应用软件开发者可以专注于具体应用功能的开发，而无需考虑控制器底层的运行过程。这样，即使更换了处理器硬件，应用软件也无需做太多修改就可以被移植过去。而底层软件的开发则交给专门的公司，他们为每一个处理器硬件写好驱动，并封装成标准化接口提供给上层。这样底层软件就可以被高效地集成到不同项目中。而由于同一套底层软件被大量重复使用，发现bug的概率大大提高，从而可以很快得到修补，并且通过更新对其它项目进行同步修补。
04
AUTOSAR的基本架构
目前AUTOSAR分为两个平台，即Classic Platform和Adaptive Platform，分别对应传统控制类车辆电子系统与对应自动驾驶的高性能类车载电子系统。
1、Classic Platform（Classic平台，CP）
Classic平台是AUTOSAR针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性限制。
Classic平台软件架构包括：
- 微控制器（Microcontroller）：即控制器硬件。
- 基础软件层（Basic Software Layer，BSW）：基础软件层包含以下4个部分：
- 微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：与硬件直接相关的驱动软件，例如存储器驱动、通信驱动、I/O驱动等。
- ECU抽象层（ECU Abstraction Layer，ECUAL）：对控制器的基础功能和接口进行统一，例如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等。
- 服务层（Services Layer）：为应用层提供各种后台服务，例如网络管理、存储器管理、总线通信管理服务以及操作系统等。
- 复杂设备驱动（Complex Device Drivers，CDD）：由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以，在AUTOSAR规范中并没有对这一部分做标准化，但为用户提供了一个可以自行编写特殊设备驱动软件的可能性。
- 运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，例如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。
- 应用软件层（Application Software Layer，ASW）：实现具体应用功能的软件，可以包含多个软件组件（Software Component，SWC），软件组件之间通过端口（Port）进行交互。
Classic平台软件架构实现了汽车软件的层次化与模块化，将硬件依赖和非硬件依赖的软件进行了封装，同时，如果使用工具链进行开发，基础软件可以通过配置参数即可实现功能剪裁、算法逻辑，便于基础软件的开发。
除此之外，接口的标准化便于基础软件与硬件抽象层软件对接，缩短开发周期的同时也为OEM提供了更多的选择空间。
2、Adaptive Platform（Adaptive平台，AP）
Adaptive平台不是针对Classic平台的升级替代，它的出现，是面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架构标准，从2016年开始制定，修改了大量Classic平台标准的内容，采用了基于POSIX标准的操作系统，以面向对象的思想进行开发，并且可使用所有标准的POSIX API，主要目的是为满足未来的高级自动驾驶需求。
Adaptive平台软件架构包括：
- 硬件层：Adaptive平台将运行的硬件视作机器（Machine），其隐含意义是硬件可以通过各种管理程序相关技术进行虚拟化，并且可以实现一致的平台视图。
- ARA（AUTOSAR Runtime for Adaptive Application，实时运行环境）：由功能集群提供的一系列应用接口组成。ARA有两种类型的功能集群：自适应平台基础功能、自适应平台服务。
- 应用层：运行在Adaptive平台上的一系列应用，一个应用可以为其他应用提供服务，这样的服务称为非平台服务。
3、CP vs AP
AUTOSAR的优缺点总结
毫无疑问，AUTOSAR规范的出现，是汽车嵌入式软件标准化进程迈出的巨大一步，让汽车嵌入式软件标准化成为了可能。
AUTOSAR的主要优点包括：
- 提高软件复用度，尤其是跨平台的复用度；
- 分层架构的高度抽象使得汽车嵌入式系统软硬件耦合度大大降低；
- 便于软件的升级维护；
- 标准化软件接口和模块，减少设计错误；
- 减少了手动代码量，提供软件质量；
- 统一标准，方便各个公司合作交流。
这些优势在越来越复杂的汽车嵌入式系统软件开发过程中，保证软件质量的同时，也降低了开发的风险。
而AUTOSAR联盟成立至今，一直提倡的是“在标准上合作，在实现上竞争”的原则。其核心思想总结起来就是“统一标准、分散实现、集中配置”。
- “统一标准”：给各厂商提供一个开放、通用的平台；
- “分散实现”：软件系统高度层次化、模块化，降低应用软件与硬件平台之间的耦合，不同的模块可以由不同的公司去完成开发；
- “集中配置”：用统一的格式集中管理从而配置生成一个完整的系统。
因此，AUTOSAR并不是真正意义上的开源项目。AUTOSAR的缺点也比较明显：
1、各厂商对规范理解不太一致
目前各个厂商对AUTOSAR规范的理解并不是那么一致，集成各个厂商所开发的软件模块需要大量的精力和时间。各个厂商提供的工具也并不真正相互兼容。目前提供AUTOSAR开发工具链及基础层软件的基本上就Vector、Elektrobit（Continental）和Bosch三家，而由于各家对AUTOSAR标准的理解和具体实现方式不同，导致它们的基础层软件在某些方面是不兼容的，这使得应用时的灵活性受到了限制。
2、软件价格高昂
完整的AUTOSAR开发环境至少是一般的开发环境价格的几倍甚至十几倍。AUTOSAR的优势是提高软件的可复用性来降低成本，但对于一些小供应商来说，如果做的量太小的话，这一优势相对于购置整套开发环境的成本便不那么明显了。
3、软件的重用性面临挑战
在真实的项目中，基于某个AUTOSAR项目重新配置所需要的时间和精力也是巨大的，并不是理想中那么完美。
结束语
在“硬件定义时代”，整车厂受制于自身研发能力的薄弱，同时，考虑到包揽所有开发工作所带来的成本耗费，其更多选择依赖于具备较强研发能力的ECU供应商。但是，由于各供应商之间ECU标准的不统一，导致了底层软件重复的问题凸显，资源利用率较低。在此背景下，AUTOSAR规范的制定，将不同结构的ECU接口实现统一，而应用层与软硬件层也获得了初步的解耦**。同时，其赋予了应用软件更好的可扩展性和可移植性，进一步增强了软件的复用率**。因此，我们认为，AUTOSAR规范的出现，在原有架构下驱动了软硬件实现初步分离，整车厂也因此获得“解放”。如果整车厂和供应商都遵循同一套软件开发标准，将大大提高开发效率和产品的灵活度。虽然当前阶段AUTOSAR规范在实现落地过程中仍面临一些问题，但随着AUTOSAR规范的接受度越来越高，标准也会逐步完善，AUTOSAR在汽车软件的开发过程中将会扮演举足轻重的角色。
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/UJKibaxWklFqdZAN-hrbdA
相关文章推荐
更多汽车电子干货请关注汽车电子设计专栏。
