前言
搞一下新架构下的软件技术系列会从高层软件架构出发，从宏观的软件技术运用开始，逐步展开每个方面的软件技术细节，为读者朋友们提供学习软件相关技术的平台。全系将涵盖软件架构设计，服务应用设计，中间件技术，模型开发技术等方面进行分享。
全系内容可在《搞一下汽车电子》后台回复 “系列”，或进入菜单栏 “分享平台” –> “系列分享”
本系列请点击：《搞一下新架构下的软件技术》
所有系列请点击：《汽车电子系列分享》
汽车ECU发展
首先回顾汽车ECU的发展，从这张图我们可以看到，从1975年第一代电子电喷控制器开始，汽车ECU发展迅速，ECU的数量与发展度也随之快速增长。
微控制器具备一定的外设资源，如果Timer, IO, ADC, PWM。另外它具备一个软件系统必须的CPU，Program Flash, RAM等。
在这类微控制器系统上可以进行一些基本的任务调度，通过定期的产生时间中断来触发周期性的任务调度。任务包括对信 的采集，处理，然后输出相应功能的信 输出。
它是基于分层的软件架构。与硬件之间相关的是硬件驱动层，它称为MCAL层，是对硬件的适配层。在这之上是抽象层，它的作用将标准软件模块与硬件的不同特性进行解耦，以实现标准化软件模块设计。在这之上就是典型的系统服务，内存服务，通信服务，IO服务等。
该服务层提供了控制器基础的底层软件功能，它们对于控制器来说，需求是相对相似的，ECU模块之间的软件复用性很强，很适合做成标准化，可配置的模块。这也是汽车软件标准化的前提。
由于软件模块的复杂度的提升，对操作系统的要求也相应提升，对操作系统的要求就是需要实时性强，任务调度管理能力强，并且支持高优先级任务抢占的操作系统能力。
这些描述文件可以通过工具进行识别，进而生成不同ECU的动态代码部分，也叫做配置文件。除静态代码和动态代码部分，一款ECU通常还会有为专用功能开发的软件模块，以及解决集成问题的粘连代码模块，它们合在一起就组成了完整的项目工程，将它们进行编译后，即可生成ECU的可执行文件。
以这样的方式开发出来的软件具有良好的应用层接口，通信行为，以及系统任务调度策略。
OSEK/VDX 主要的规范
OSEK/VDX主要相关的规范有：
OSEK OS（操作系统）
OSEK COM（通讯）
OSEK NM（ 络管理)
实时操作系统（RTOS）
在讲OSEK操作系统之前，我们先介绍下什么是实时操作系统。
如图所示，在一个Event事件发生后，经过一定的延迟后，触发相应的函数功能。该函数的执行时间经过严格的计算，保证在期限时间内能运行完成。这就是通常对一个实时操作系统的定义。
OSEK Conformance Classes
OSEK支持多级RTOS能力等级划分，称为”Conformance Classes”。
主要由三个方面去描述RTOS能力等级，第一个是任务的类别，分基础任务和扩展任务，它们之间的区别在于基础任务没有等待状态，而扩展任务允许有等待状态。
第二个差别在于多任务的激活，第三点是具有优先级的多任务调度。从这三个能力角度，组合成了4种Conformance Classess, BCC1， BCC2, ECC1，还有ECC2。如下图所示，从RTOS能力上来说，ECC2是具备最高等级的。
OSEK 通信
第二个主要的OSEK标准是OSEK COM。对于一个典型的 络，对照参考模型，可以划分为7层。
OSEK COM主要实现了 络层，和数据链路层的标准实现。OSEK COM在总线通信硬件上设计了标准的设计驱动接口， 络层实现了标准的总线协议，同时对上层应用也提供了标准的应用程序接口。这样设计的目的在于为汽车控制器应用软件提供统一的通信环境，好处是提升了应用软件的可移植性。
汽车开放系统架构 AUTOSAR
OSEK/VDX是一个汽车软件标准化的开端，而进一步将汽车软件标准化的就是AUTOSAR。AUTOSAR已经广泛运用在主流的ECU控制器软件中。
AUTOSAR和OSEK/VDX的关系相当于， AUTOSAR是OSEK/VDX的继承和发展，从很多AUTOSAR的标准文档中，我们可以看到它借鉴了OSEK的协议标准，比如AUTOSAR OS和OSEK OS很多概念都是一致的。
当然AUTOSAR增加了很多新特性，比如Schedule Table, 时间同步，栈监控，内存保护等机制。AUTOSAR的引入在于OSEK定义的标准模块，仅包含OS, COM, NM，但一个完整的ECU软件组件还包括内存的处理，标准的外设处理等，进一步将这些软件模块进行标准化的详细设计也是很有必要的。
AUTOSAR除了分层软件架构体系，详细模块组件设计之外，另一重要的概念是提供了一整套应用程序开发的方法论。
所有的这些工作都是为了实现这些目标：为了应对数量日益增多且功能复杂的汽车ECU，同时要改善每家ECU控制器供应商各自开发软件而造成的软件质量参差不齐，并且难以有效开展合作的问题。
由于可以购买到第三方软件公司提供的基础软件模块，可以缩短产品研发时间，更快的推向市场。而可拓展的分层软件架构可以提供灵活多变的解决方案，适应不同控制器的软件要求。
AUTOSAR 方法论
AUTOSAR的方法论总体设计开发分为三个步骤，系统配置，ECU设计与配置，代码生成。
首先由整车厂完成整个功能架构，系统架构，软件架构，并且定义总线的拓扑结构，以及信 列表。软件组件框架包含每个软件组件之间的交互关系，运行实体等要素。之后将软件组件按功能分配给ECU硬件。
在完成这些设计后，系统描述文件包含了每一个ECU软件框架描述，并且包含了每个ECU的系统信 。这些描述文件将分发给ECU开发商去完成每个ECU具体底层功能配置并生成相应的BSW代码，同时还需开发应用软件的行为模型及代码。
RTE是虚拟功能总线在具体ECU上的实现，它承担着在ECU内运行的应用层软件组件之间互相通信，以及应用软件向通信协议栈发送总线信 的作用。
这张图就是大家都很熟悉的CP AUTOSAR的软件架构。包含了微控制器抽象层，ECU抽象层，服务层，还有复杂驱动层，RTE将底层软件和上层应用软件组件分开，提供虚拟总线实时运行环境。
例如应用程序要向总线上发送一个总线信 ，典型的处理过程是首先通过RTE把信 传给COM通信模块, 它属于通信服务层。通信硬件抽象层的作用是将不同类型的 络通信进行抽象，使得上层的处理不需要关心底下具体是以哪些类型的 络发送数据。
通信驱动层的作用是使上层模块可以更方便的使用硬件设备，比如用简单的API去操作发送或接受一个CAN信 ，具体对硬件的处理操作由驱动去完成。微控制器抽象层的作用就是解决不同微控制器厂商硬件设计的差异，使得驱动层可以统一标准化设计。
汽车软件架构的发展趋势
对于汽车软件架构未来的发展趋势，有以下几个方面。
第一是面向服务的软件架构变化，服务架构的转型需要将当前基于信 的软件设计进行重构，使得功能的调用更符合服务化的通信框架。第二，中央计算+区域控制分布式远程调用框架RPC。当前适用车内使用的RPC就是SOME/IP，它可以在运行CP AUTOSAR的实时控制器上使用，也可以在运行AP AUTOSAR的高性能SOC上使用，是两个不同平台进行通信的纽带。
第三，高算力SoC软件架构也是重要的发展方向，传统功能上移到中央计算单元，计算集中化是未来的电子电气架构趋势。也对高算力SoC的软件架构提出更高的要求。
同时这样的软件架构还涉及到一个新的概念，混合关键性软件系统，即在一个SoC系统上同时运行不同安全等级的软件系统，这对软硬件隔离技术，虚拟化技术都是新的考验。另外云端，车端，以及基础设施的功能协同等也是发展的新趋势。
对于前面讲的未来的汽车软件发展趋势，当前比较推荐的方案就是AP AUTOSAR。设计AP AUTOSAR的初衷就是该平台应具备一定的实时性，高可靠性，同时适合运行高性能软件算法的应用场景。另外该平台具备一点的灵活性，可以动态的加载车辆应用功能。
AP AUTOSAR的功能组件。其核心组件ARA COM提供了服务化的通信功能，自适应应用程序AA之间的通信通过ARA COM来完成。属于Services类型的模块包括升级和配置管理UCM，提供FOTA, SOTA的功能支持。
Security Management提供和信息安全相关的服务，Diagnostics则提供和诊断相关的功能入口。其他API组件，提供了时间管理，执行管理，Persistency，健康管理等，都是必须的平台中间件软件。
AP AUTOSAR的兴起源于当前对高性能SoC系统的应用需求，在一个完整的汽车汽车电子电器架构中，因为每个ECU都有其特殊的应用需求，所以AP AUTOSAR, CP AUTOSAR, 以及非AUTOSAR的ECU将是同时存在的，都扮演者重要的角色。
在AP AUTOSAR发展的同时，CP AUTOSAR也在继续升级新增新的模块，以适应新的需求。
当然，除此之外，未来汽车电子软件中人工智能技术也是一大应用。汽车电子也会跟其他行业会有更多的交集，也会引入其他行业的很多技术，如IEEE制定的相关标准；跟OPC UA结合以解决TSN的问题，机器领域的ROS，以及已经在航空航天中使用的到的光纤通信技术等。
汽车电子软件未来发展如何，让我们拭目以待吧！
本期分享就到这里，进群、工具链评估、培训、集成等其他问题，也可以随时与我们联系。
联系我们
微信：shactiontech
邮箱：support@shactiontech.com声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！