汽车ECU发展

首先回顾汽车ECU的发展，从这张图我们可以看到，从1975年第一代电子电喷控制器开始，汽车ECU发展迅速，ECU的数量与发展度也随之快速增长。

发展到1985年，已经出现了像变速箱控制器，发动机控制器等，同时也出现了第一代车内网络总线CAN。接近2000年，更复杂的主动安全控制器，车辆稳定系统控制器，自适应导航控制器等陆续出现。

伴随着汽车ECU的发展，车内网路总线的技术也在不断发展，从相对低速的CAN、LIN总线技术发展出更高速的Flexray, 可以到达10M的通信速率。

最近几年，车内以太网开始应用100-baseT1，1000-BaseT1的以太网技术，从应用场景上是为了满足自动驾驶以及车联系网所需的高数据通信的应用需求。

为了满足复杂的应用功能，相对比较独立的汽车软件，也慢慢引入了互联网的软件技术，如在工业以太网运行成熟的实时通信技术，互联网服务架构理念，给汽车软件带来了创新的灵感。

在这个背景下，对汽车ECU的发展起到了非常大的推动作用。另外新能源汽车发掘出了新颖的功能，更方便的AI人机交互过程，以及越来越智能的辅助驾驶系统。

独立单一功能ECU

接下来讲一下汽车ECU软件的发展历程，一开始汽车上出现的ECU主要是解决单体功能，比如以软件的方式对电油门喷嘴进行更精确的控制，以达到更好的燃油和动力的效率。对于这类控制器，软件的架构也是相对简单的。

微控制器具备一定的外设资源，如果Timer, IO, ADC, PWM。另外它具备一个软件系统必须的CPU，Program Flash, RAM等。

在这类微控制器系统上可以进行一些基本的任务调度，通过定期的产生时间中断来触发周期性的任务调度。任务包括对信号的采集，处理，然后输出相应功能的信号输出。

在逐步的发展中，由多个解决单体功能的ECU，它们之间需要有信号的交互，由此衍生出来带网络通信，更复杂的ECU，他们之间通过网络的互联，将信号收集到功能域控制器，以实现更高级，智能的车辆功能。

比如车身控制器包含了对车上所有车身相关的所有功能，包含有大灯，车窗，雨刮，门锁等。对于这类ECU，它软件的复杂度相对较高。

它是基于分层的软件架构。与硬件之间相关的是硬件驱动层，它称为MCAL层，是对硬件的适配层。在这之上是抽象层，它的作用将标准软件模块与硬件的不同特性进行解耦，以实现标准化软件模块设计。在这之上就是典型的系统服务，内存服务，通信服务，IO服务等。

该服务层提供了控制器基础的底层软件功能，它们对于控制器来说，需求是相对相似的，ECU模块之间的软件复用性很强，很适合做成标准化，可配置的模块。这也是汽车软件标准化的前提。

由于软件模块的复杂度的提升，对操作系统的要求也相应提升，对操作系统的要求就是需要实时性强，任务调度管理能力强，并且支持高优先级任务抢占的操作系统能力。

汽车软件标准化的开端 OSEK/VDX

OSEK是德文的缩写：“Offene Systeme und deren Schnittstellen für die Elektronikim Kraftfahrzeug”

VDX代表：“Vehicle Distributed eXecutive”

在更多ECU控制器出现的同时，每家公司都必须掌握ECU软件的开发，如果是独立的ECU控制器，则不需要关注和其他ECU通信协议兼容的问题。

但实际情况下，大多数车辆ECU都需要和其他ECU实现通信，如果是一个通信速率不高，信号数量不大的ECU，可以采用LIN的通信协议。如果通信的数量和速率达到一定程度，就有必要采用CAN通信协议。

通常一辆整车，它的零部件是由不同供应商去提供的，每个供应商开发的软件必须对外实现相同的通信协议以及管理的策略。汽车软件标准化的开端就是OSEK/VDK. OSEK/VDK是德文首字母的缩写，OSEK含义是汽车电子开放式系统及其接口，VDX则是汽车分布式运行系统

OSEK/VDX 目标和动机

动机

OSEK/VDX的动机在于解决ECU基础与通信部分软件可以在不同的硬件平台上重用，快速的移植到新的硬件平台。

解决由于协议和接口不同造成的各供应商的控制器之间不兼容，开放式系统及其接口的好处也体现在软件质量的提升和不同供应商合作开发过程中。

目标

提高应用层软件的可移植性和可重用性。

制定标准化的实时操作系统RTOS，以及处理器之间的通信用到的通信协议栈，以及相同行为的网络管理策略。

在软件架构层面实现接口抽象化，应用与硬件解耦。

对于操作系统，通信协议中与网络管理，ECU有差异的部分进行配置，比如任务的配置，通信信号的配置等，而大多数的软件实现都是静态固定的代码，使得软件的复用性和可靠性得到大幅度的提升。同时要求架构具有扩展性，方便未来增加新的标准软件模块。

下图描述了工具化实现OSEK标准模块的过程，开发者通过接口描述语言描述功能接口， 通常包含应用程序接口，网络信号接口等。接口描述语言和具体的编程语言无关，但它可以作为一个标准化的语言对一个系统进行描述。

这些描述文件可以通过工具进行识别，进而生成不同ECU的动态代码部分，也叫做配置文件。除静态代码和动态代码部分，一款ECU通常还会有为专用功能开发的软件模块，以及解决集成问题的粘连代码模块，它们合在一起就组成了完整的项目工程，将它们进行编译后，即可生成ECU的可执行文件。

以这样的方式开发出来的软件具有良好的应用层接口，通信行为，以及系统任务调度策略。

OSEK/VDX 主要的规范

OSEK/VDX主要相关的规范有：

OSEK OS（操作系统）

OSEK COM（通讯）

OSEK NM（网络管理)

实时操作系统（RTOS）

在讲OSEK操作系统之前，我们先介绍下什么是实时操作系统。

如图所示，在一个Event事件发生后，经过一定的延迟后，触发相应的函数功能。该函数的执行时间经过严格的计算，保证在期限时间内能运行完成。这就是通常对一个实时操作系统的定义。

对这样一个操作系统，它需要具备一定的调度能力，即该系统能够满足在任何情况下，在限定时间内完成对任务的调度。

第二是响应能力，要求系统具备低延迟响应，即使在Worst case下依然能保证这个性能。

第三就是任务过载时的稳定性，即使在发生任务过重而出现过载，无法满足在限定时间内完成对所有任务的调度的情况下，仍然可以保证高优先级的任务得到调度。

OSEK 操作系统

OSEK操作系统规范就是基于这些要求而制定的，OSEK操作系统最合适运行的硬件环境就是微处理器，在这类系统中，通常需要实现的是实时要求高的应用功能，对外设的要求需要有总线控制器，如CAN, LIN, 以及对数字输出端口进行操作。

OSEK OS首先定义了标准化的接口。即应用软件和操作系统之间的接口由统一化的操作系统服务定义，这样对于不同的处理器，操作系统对外的系统服务都是相同的。

第二就是可扩展性，OSEK OS定义了多种不同的调度机制，不同的RTOS能力分类，使得它适用于各种应用程序和硬件。

第三错误检查，提供开发阶段和生产阶段所需的错误检查的处理。第三就是应用软件的可移植性，这就是OSEK的主要目标之一

OSEK Conformance Classes

OSEK支持多级RTOS能力等级划分，称为”Conformance Classes”。

主要由三个方面去描述RTOS能力等级，第一个是任务的类别，分基础任务和扩展任务，它们之间的区别在于基础任务没有等待状态，而扩展任务允许有等待状态。

第二个差别在于多任务的激活，第三点是具有优先级的多任务调度。

从这三个能力角度，组合成了4种Conformance Classess, BCC1， BCC2, ECC1，还有ECC2。如下图所示，从RTOS能力上来说，ECC2是具备最高等级的。

OSEK 相关术语

在OSEK OS标准中，有一些常用的术语：

Tasks

Scheduling

Interrupt

Resources

Alarms&Counters

Event

Hook Routines

System Services

下图展示的是任务的状态转换示意图。

OSEK 通信

第二个主要的OSEK标准是OSEK COM。对于一个典型的网络，对照参考模型，可以划分为7层。

OSEK COM主要实现了网络层，和数据链路层的标准实现。OSEK COM在总线通信硬件上设计了标准的设计驱动接口，网络层实现了标准的总线协议，同时对上层应用也提供了标准的应用程序接口。这样设计的目的在于为汽车控制器应用软件提供统一的通信环境，好处是提升了应用软件的可移植性。

从图中可以看出，OSEK COM和OSEK NM，OSEK OS有着依赖关系，它们之间需同时配合，以实现ECU的通信功能。

OSEK 网络管理

对于一个带网络通信的ECU，网络管理是十分重要的，直接影响到整车的使用体验，网络管理如果出现故障，可直接引起车辆无法启动，整车无法休眠等问题。

OSEK网络管理能有效的管理参与网络的各个ECU的唤醒和睡眠。该协议主要定义了网络管理报文，报文定义了每个ECU的状态，以及睡眠，唤醒意图的标识位。

在建立通信的过程，相当于建立起环状的通信链路。同时考虑到某个ECU点可能会发生故障而不能继续参与网络通信，它也可以识别出这种异常状态，并且由剩余的ECU，重新建立起环状的通信链路。

网络管理的目的和职责如图所示，如激活通信硬件，同步网络节点同步转换到睡眠状态等，同时对网络进行诊断，网络出现错误后进行恢复等。

汽车开放系统架构 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除了分层软件架构体系，详细模块组件设计之外，另一重要的概念是提供了一整套应用程序开发的方法论。

该方法论从元模型开始，制定了每个环节需要的工作内容，输出文件以及产出文件，中间的交互文件和格式也有具体的定义，例如arxml为载体的交互文件。对于系统建模工具，需要有专门的编辑工具，ECU的底层功能由配置工具去做相应的配置，进而生成相应的执行代码。

所有的这些工作都是为了实现这些目标：为了应对数量日益增多且功能复杂的汽车ECU，同时要改善每家ECU控制器供应商各自开发软件而造成的软件质量参差不齐，并且难以有效开展合作的问题。

由于可以购买到第三方软件公司提供的基础软件模块，可以缩短产品研发时间，更快的推向市场。而可拓展的分层软件架构可以提供灵活多变的解决方案，适应不同控制器的软件要求。

AUTOSAR 方法论

AUTOSAR的方法论总体设计开发分为三个步骤，系统配置，ECU设计与配置，代码生成。

首先由整车厂完成整个功能架构，系统架构，软件架构，并且定义总线的拓扑结构，以及信号列表。软件组件框架包含每个软件组件之间的交互关系，运行实体等要素。之后将软件组件按功能分配给ECU硬件。

在完成这些设计后，系统描述文件包含了每一个ECU软件框架描述，并且包含了每个ECU的系统信号。这些描述文件将分发给ECU开发商去完成每个ECU具体底层功能配置并生成相应的BSW代码，同时还需开发应用软件的行为模型及代码。

RTE是虚拟功能总线在具体ECU上的实现，它承担着在ECU内运行的应用层软件组件之间互相通信，以及应用软件向通信协议栈发送总线信号的作用。

Classic AUTOSAR 软件架构

这张图就是大家都很熟悉的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，以及已经在航空航天中使用的到的光纤通信技术等。

汽车电子软件未来发展如何，让我们拭目以待吧！