登陆

从工程师的角度看AUTOSAR

来源：公众号“汽车电子与软件”

2020-08-03

作者 | Paulfrank

来源 | 汽车电子与软件

引言：

“软件定义汽车”的火热带动了工程师们对于汽车电子软件热烈地讨论。不曾想到，隐藏在控制器内部，默默地发挥着作用的汽车电子软件，如今备受瞩目。本人毕业到现在，一直在汽车行业做软件，切身感受到一系列的变化。写软件的方法在变，行业技术标准在变，和OEM合作模式在变，还有敏捷转型等等。10多年前，有人认为汽车行业是夕阳产业，IT是朝阳产业。现在看来，无论是汽车还是IT，依然朝气蓬勃，更令人欣喜的是，这两个产业的融合为未来的发展带来了新的契机。

开端-OSEK/VDX

OSEK/VDX标准的出现代表着汽车电子软件标准化的开端，该标准的构成：实时的操作系统（OSEK OS），通讯子系统（OSEK-COM）和网络管理系统（OSEK-NM）。

在OSEK出现之前，软件生产商们仅依靠自身积累，写出的软件五花八门，水平参差不齐，有些甚至没有清晰的软件层次结构，这样写出的软件质量堪忧，并且可维护性是很差的。有了OSEK标准的借鉴和指导，很多软件生产商依照OSEK标准开发出了自己的软件产品。像汽车行业的Tier1，提供软件与硬件整套完整方案是常态，Tier1自研的完善可靠的软件产品也是其核心竞争力之一。

OSEK OS是实时操作系统，可以满足大多数汽车控制器的任务调度要求。另外其可移植性和可扩展性很高，可以轻松移植到新MCU平台。对于实时性要求，除了要有好的操作系统，也需要程序设计者合理地规划常规任务和中断处理程序，如果任务阻塞或执行时间过长，会极大的影响正常任务的调度。近年来，软件系统的实时性和确定性执行也不断地在演进。确定性操作系统，再配合逻辑执行时间（LET）模型，可提供更高级别的功能安全机制。

下图摘取自OSEK标准文档，图中展示了OSEK/VDX的基本结构和各组件间的关系。这也算是典型的带网络通信的汽车ECU软件的最小系统了。

在2000年左右，Tier1的ECU软件自研比例非常高，对软件产品的掌控力也相当强，底层软件和应用层软件都由Tier1完成开发。OEM和Tier1之间软件开发的合作方式，主要是由OEM向Tier1分发书写格式和内容非常规范化的需求文档，有些做到好的，则采用格式化的语言来描述需求，甚至是伪代码的书写形式。

V模型开发流程(瀑布模型的进阶)是当时的主流。按自上而下的过程递交交付物，并在相对应层级依次验证，是V模型开发的特点。V模型开发迭代周期长，一般与功能交样时间相匹配。迭代次数少，一般5到6次迭代后，基本就到SOP量产了。当时汽车ECU功能定义固化早，每个ECU功能数量较少，需求开发相对稳定，在当时看来，V模型的开发流程是非常合适的。

进阶-AUTOSAR

上文提到了OSEK，因为它与AUTOSAR颇具渊源，AUTOSAR的部分设计也参考了OSEK标准。OSEK是汽车软件标准化的第一步，它影响的范围是ECU层面。OEM和Tier1之间稳定的合作方式也已经形成。但汽车软件标准化的进程并没有停下来。

这里插句题外话。OEM和Tier1的这种合作模式下，Tier1的系统与软件能力变得格外的强，另外OSEK的标准化，总线设计的标准化，也让各个厂家设计的ECU之间的连通变得简单。在这个背景下，Tier1对整车电子电器架构的影响很大，依靠Tier1的能力，攒起一套主流的电子电器架构也成为可能。行业头部的整车厂，Tier1，芯片等其他环节的供应商，对电子电器架构的构想也一定程度上推动着行业的发展。

上文有提到过，OEM需要花费相当大的精力来书写需求说明书，以描述ECU的应用层功能，完成后交予Tier1来开发软件。而随着车上的ECU数量不断增加，信号复杂程度增加，传统的开发方式显露出了开发复杂，维护困难等弊端。让汽车电子系统开发更灵活，更有效率，成为汽车工程师的目标。AUTOSAR的诞生旨在达成这个目标。AUTOSAR从一开始就志在整体汽车电子开发的标准化。所以AUTOSAR所涵盖的方法论，虚拟功能总线，元模型与模板工具，软件架构及模块，所有这些工作都导向这一目标。可以毫不夸张的说，AUTOSAR是汽车工程师的智慧结晶。

AUTOSAR的推出，OEM与Tier1之间的合作方式有了微妙的变化。在介绍新的合作方式之前，这里先介绍下AUTOSAR的核心概念：虚拟功能总线(VFB)。

下图引用自AUTOSAR标准。如图，VFB之上描述的是软件组件(SWC)，以实现软硬分离。OEM着重于系统层面的设计，包含SWC的设计及它们之间的通信方式。VFB是虚拟总线，真实的情况是它们以Flexray，CAN总线方式通信，或者是ECU的内部通信。而这些都会在整车开发流程中的SWC部署，网络设计中体现。

在了解以上的基本概念后，再来讲讲OEM和Tier1的合作方式有哪些。

方式一：

OEM：以AUTOSAR的标准方法设计系统及软件架构，并以ARXML的形式导出，同时负责应用层软件SWC的开发。

Tier1：以AUTOSAR的标准方法完成基础软件的配置与生成，复杂驱动软件的开发，最终软件的集成与版本释放，并提供硬件平台。

特点：双方关注自己负责的软件部分，耦合部分不多，沟通成本最低。

方式二：

OEM：基本与方式一相同，但OEM自己不开发应用层软件。

Tier1：除了方式一提到的内容，还包括应用层软件的开发。

特点：软件开发的工作都落到了Tier1身上，但应用层软件需求沟通的成本较高。

方式三：

OEM：除了系统及软件架构设计以外，OEM还负责应用层及底层软件开发，包括最终软件的集成与释放。

Tier1：仅配置MCAL部分的软件。

特点：OEM包揽了大部分的软件工作，Tier1的价值仅在于提供硬件平台(包括MCAL软件)。

方式四：

OEM：按自身的方式设计系统架构及发布需求，但并不是AUTOSAR的标准方法，应用层软件开发为备选。

Tier1：以AUTOSAR的标准方法完成底层软件，应用层软件为备选，取决于OEM是否提供基于标准接口的应用层软件。

特点：此方式用到了AUTOSAR软件标准架构和模块，但缺少了精髓的系统设计部分。

另外，AUTOSAR也改变了软件工程师需要的技能和工作方式。手工代码渐渐转向基于模型的开发，底层功能模块依靠工具配置及代码生成。验证软件的方式也更多样，模型仿真，SIL，HIL等等。

突破-AP AUTOSAR

从本节开始，AUTOSAR会标注CP (Classic Platform) 和AP (Adaptive Platform)，以示区分。

CP AUTOSAR标准其实也在不停的演进中，Ethenet, Crypto, E2E, SOME/IP等等也是在4.X的版本中才出现。基本上，有新的技术需要运用，AUTOSAR就有推出相应的标准。

但CP平台毕竟有它的局限性，对于高算力的应用场景无能为力。AP AUTOSAR的出现正是应对高性能计算平台的需要，AP AUTOSAR的定位是运行于POSIX操作系统之上的中间件。设计者也不乏考虑，AP平台和CP平台在一个架构下共存的问题。所以它与生俱来，具备和CP AUTOSAR有良好的交互能力。

高性能计算平台必然是未来电子电器架构的主角，已经有不少架构师们设想把它运用到多域控制器，以及中央计算平台当中。AP AUTOSAR在高性能计算平台的作用不可小觑。这可以从AP AUTOSAR的设计细节得出。

ARA：COM提供应用层之间标准且可靠的通信方式，统一化的通信方式有助于避免由于通信机制的不同造成的设计缺陷。同时支持事件驱动和轮询模式也是它的主要特点，因实时应用程序通常基于轮询模式，而支持此模式可以保证前后级数据传递式样的一致，避免不必要的上下文切换。

ARA：EXEC主控应用程序的生命周期，设计者同时也考虑了功能安全方面的设计，例如状态恢复，资源管理，确定性执行等机制。

ARA：SM 收集应用程序的各种异常状态并适时地调整相应的应用程序功能，为功能安全提供有效的机制。

ARA：PHM提供监控应用程序的能力，并在检测到异常后执行恢复动作。它支持几种典型的任务监测机制：alive, deadline, logical supervision。

其他AP AUTOSAR包含的API及Service组件不在这里一一介绍。可以看出，APAUTOSAR除了提供基本的应用层开发平台中间件，同时也有不少功能安全上的考虑，其中一些机制可以有效的应对ISO26262软件部分“Freedom from interference”中提出的相关需求。

AP AUTOSAR在这样一个复杂的环境下诞生，工程师们必定对其赋予厚望，从它的设计思路来看，AP AUTOSAR不但吸取了现有成熟的技术，同时也有所创新，引入互联网技术的同时也不乏考虑其适用性和可靠性。如今AP AUTOSAR刚经历了几个版本，对比CP AUTOSAR从萌芽到茁壮成长的过程，AUTOSAR的未来必定可期。