AUTOSAR背后，核心还是“话语权”

上周，中国汽车工业协会发布了中国汽车基础软件生态委员会（英文缩写 AUTOSEMO）的成立。

一汽、上汽、广汽、蔚来、 吉利、长城、东风、一汽解放、小鹏汽车9家整车企业，以及东软睿驰、恒润、地平线等6家供应商成为第一批成员企业。

按照官方披露的信息，AUTOSEMO的成立标志着中国自主品牌主机厂及供应商企业共同面对现存汽车软件研发领域的挑战，协同生态，打造基于中国自主知识产权系统的生态圈。

不过，AUTOSEMO标准工作组仍然是基于AUTOSAR现有软件架构（经典平台和自适应平台），顺应中国汽车行业发展趋势，开展自动驾驶、新能源的应用程序接口标准的制定工作。

两个重点：

1、AUTOSAR已经在制定的应用程序接口标准（车身、传动、动力、底盘、被动安全、HMI多媒体车联网）暂不纳入标准工作组的业务范围。

2、AUTOSEMO系统软件和测试的标准与AUTOSAR标准保持一致。这和之前日本的JASPAR标准非常相似。

换个角度说，AUTOSEMO是在现有AUTOSAR基础上基于中国汽车行业的本地化需求，构建一部分特有（差异化）的软件开发标准，同时与AUTOSAR保持一致性（尽最大可能不增加额外成本）。

而作为AUTOSAR，是在复杂的汽车供应链体系下，帮助汽车制造商保持创新功能的竞争力，提供更高的设计灵活性。

同时，提高供应商功能开发的效率，为开发过程提供具有公共接口的工具提供者，为其提供一个无缝的、可管理的和任务优化的工作环境。

一、什么是AUTOSAR

AUTOSAR是一个开放的系统架构（相当于中间件），以支持汽车OEM和一级供应商提高ECU软件质量，降低开发成本，并避免重复开发类似的组件。

按照定义，这是一个不断增长和发展的标准，为软件定义分层的体系结构。原因是，过去车辆拥有多达100个ECU，它们通过CAN总线、CAN FD或以太网相互通信，支持复杂的车辆功能。

AUTOSAR诞生之前，OEM使用的ECU软件是在不同的平台上开发，并没有一套被一级供应商和他们的供应商（二三级供应商）用于为OENM设计ECU软件的标准软件体系结构。

因此，无论什么时候OEM希望切换到一个新的一级供应商，或者反之，转换都是非常困难的。在理解ECU软件开发中使用的现有软件体系结构、硬件平台和标准方面，新的供应商过去常常面临巨大的挑战。

为了简化汽车制造商和一级供应商之间的开发协调，提高ECU软件质量并减少开发时间和成本，汽车制造商、一级汽车供应商、半导体厂商、软件供应商、工具供应商和其他企业在2003年提出并创建了一个名为汽车开放系统架构（AUTOSAR）的联盟。

作为一种开放和标准化的汽车软件架构，AUTOSAR（汽车开放系统架构）支持应用软件和功能之间的接口标准化，为所有AUTOSAR成员建立通用的ECU软件架构。

经典的AUTOSAR平台运行在一个微控制器上，通常分为三层：基础软件架构层、AUTOSAR运行环境层、以及应用层。

基础软件架构层由数百个软件模块组成，这些模块在不同的层中构造，并且对任何AUTOSAR ECU都是通用的。这意味着不同供应商之间可以实现共享。

AUTOSAR运行环境层是基础软件架构层和应用层之间的中间件层，为应用程序软件提供通信服务。

应用层则是用于支持自定义功能的实现。这一层由特定的软件组件和许多按照指令执行特定任务的应用程序组成。

应用层由三个组件组成：应用程序软件组件、软件组件的端口和端口接口。AUTOSAR确保应用程序层中软件组件的标准化接口。

上述AUTOSAR的架构是它的经典平台（也就是通常称为：Classic AUTOSAR），支持实时需求和安全约束。基于微控制器，经典平台能够支持网络和安全领域的应用，允许CEU访问车辆传感器和执行器。

二、经典AUTOSAR的演进

从2003年到2015年，经典AUTOSAR成为了一个成熟的平台，支撑整车ECU数量的快速增长。

不过，随着V2X连接、自动驾驶等新技术的导入，现有的经典AUTOSAR平台已经不太适合新的软硬件平台的开发，需要更强大和灵活的E/E架构。

随后，一个名为Adaptive AUTOSAR的全新架构正式亮相，并在2017年3月完成了AUTOSAR Adaptive平台的第一个版本发布。

和经典平台的最大差别是，Adaptive AUTOSAR架构附带了一个中央应用服务器，主要用于支持高性能计算。

Adaptive AUTOSAR是可伸缩的，并具有动态架构，其中应用程序可以在车辆的生命周期中更新（也就是近年来特斯拉掀起的OTA应用潮流）。

按照官方的定义，Adaptive AUTOSAR支持所有未来汽车应用程序，如信息娱乐，v2x，预测维护，ADAS功能与多传感器融合，地图更新，电动化，以及更多其他新技术应用。

此外，AUTOSAR已经集成了各种IT安全应用程序，例如用于保护车内通信或保护机密数据。但是，由于经典和自适应的AUTOSAR架构不同，它们提供的安全应用程序部分相同，部分不同。

至此，AUTOSAR完成了未来面向服务软件架构的体系建立。当然，怎么用，用得好不好，仍然取决于企业自身。

三、用不用，取决于话语权

2008年，Android手机的推出成为智能手机行业的转折点。

类似地，在汽车行业，当特斯拉将数据聚合引入大规模并行ECU或具有CASE(连接、自动、安全/安全/智能和电动)架构融合的全域控制器时，转折点出现了。

另一方面，传统汽车制造商，还在采用数以百计的传感器和执行器相关的分布ECU架构，造成了大量的数据处理瓶颈。

换句话说，早期的分布式ECU架构，见证了类似AUTOSAR在欧洲和美国的兴起、JASPAR在日本的兴起。

当然，JASPAR标准与AUTOSAR标准是一致的，只是将西方的方式用日本的方式进行翻译和转换。

AUTOSAR最初由大众、宝马、戴姆勒、克莱斯勒、大陆、博世和西门子组成，旨在为汽车电子/电气体系结构开发和建立一个开放的行业标准。

后来，更多的公司加入了核心合作伙伴，如通用汽车、丰田和福特。到了2018年，全球有超过200家公司加入联盟。

事实上，AUTOSAR已经实现了从硬件中抽象软件组件和应用程序的开发实践，同时实现了软件模块的重用。

作为汽车工业史上的一个重要里程碑，AUTOSAR实现了在不同硬件平台上运行功能代码需要将基础软件与应用模块分离，将客户特定的基础模块转换为标准模块和通过统一接口描述的应用模块。

因为在过去，汽车软硬件模块的主要问题之一是可重用性差，这主要是因为汽车制造商和供应商之间高度依赖关系，也因为嵌入式系统不支持完整的硬件抽象或有限的模块化。

而借助特斯拉的成功，大规模并行硬件生态系统得以加速发展，以满足海量数据聚合需求。

过去，对于ECU的开发，AUTOSAR方法是显而易见的选择。汽车制造商和他们的一级供应商已经使用超过十几年时间，并已成功部署到大规模的量产车。

事实上，现在，随着开放资源的可用性和AUTOSAR的适应性，甚至包括很多新供应商在没有太多汽车行业量产经验的情况下，都可以通过基于AUTOSAR的开放平台架构与传统供应商进行平等竞争。

因为AUTOSAR的口号是“在标准上合作，在实现上竞争”。使用AUTOSAR软件体系结构，可以尽可能独立于硬件部分开发AUTOSAR应用程序的软件部分。

当然，作为一套E/E开发流程和控制器软件架构，AUTOSAR也只是汽车制造商的选择之一。主要目的是为了提升汽车软件技术开发协作效率和缩减开发成本。

对于供应商而言，不同OEM之间的软件模块可以重用；对于OEM而言，不同供应商的软件模块互换性增强。而这种标准也是分摊开发成本的一种方法。

同时，对于车企来说，也是一笔不小的成本。车载ECU，每开发一个ECU都需获得AUTOSAR Tool（工具）许可证，同时每一种车型的AUTOSAR Tool也不一样，所以这本身就形成了一个巨大的市场。

比如，作为全栈解决方案的核心，华为MDC智能驾驶计算平台(MDC)基于自研AI芯片、车控OS等基础领域技术，既兼容AUTOSAR，同时提供的工具链也可以让车企灵活快速开发不同应用。

华为可能会构建另一套和现有汽车行业遵循的AUTOSAR软件标准平台平行的一套体系，不过，第一步仍然是开发自适应AUTOSAR系统/子系统，支持合作项目的早期量产落地。

事实上，不管是特斯拉、华为亦或是传统汽车制造商、零部件供应商，软件定义汽车并非一定要用AUTOSAR，核心仍然取决于汽车制造商和生态体系的话语权。

总之还是那句老话：一流的企业（或者联合）做标准，二流的企业（参与或选择一种标准）做品牌，三流的企业（付出高昂标准成本）做产品。