从工程师的角度看AUTOSAR.docVIP

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