来源：汽车电子与软件
开端-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的未来必定可期。
