本文主要总结了目前汽车电子开发的大致过程，以及对Classic AutoSAR（汽车开放系统架构）的基本介绍，目的是让读者对汽车电子开发建立全局的感性认知、入门Classic AutoSAR的基础内容。理解汽车电子开发以及其软件架构，是实现车辆自动驾驶的基础，是将自动驾驶算法及应用运行在车辆上的前提。

下图为目前汽车电子开发的关键词词云，图中框出的关键词（部分）为本文介绍的重点： 

1 汽车电子开发概览

 随着整车内ECU数量以及单个ECU内软件的复杂度的逐步增高，汽车软件行业需要一个开放，标准的软件架构来将未来整车、单个ECU内软件的复杂程度限定在一个可以控制的范围内。Autosar （Automotive Open System Architecture，汽车开放系统架构）就是这样的一个组织，目前组织已经联合了超过100个整车厂、零配件供应商、工具链供应商、半导体电子公司来为未来的ECU共同建立一个标准架构。目前已经许多OEM以及供应商已经开始在部分车内开发、整合、集合符合Autosar标准的功能组件。

       Autosar2.1标准已经被许多公司视为是一个较为成熟的标准，其中对于指定的应用层软件组件的概念与信息的定义已经成熟。许多工具链供应商纷纷开始结合自己的技术为Autosar架构开发新的商业工具链。在2006年大众公司已经成功使用MBD方法来设计符合Autosar标准的ECU并整合在已有的E/E电子电气环境中。为了应对软件、算法的复杂程度指数增加，汽车工程师开始使用MBD方法，这个已经在业内被广泛接受。MBD可以在软件早期开发阶段提供明确、可执行的规范，自动V&V（Verification、Validation）以及自动代码生成这些额外的优点使得开发效率显著提高。

       作为ECU网络的标准架构，Autosar在汽车行业变得越来越重要，尽管现阶段大家只是将关注点放在标准的定义与完善，但许多OEMS以及供应商已经开始将Autosar纳入未来软件开发流程中。这就需要一系列完整的工具链，从上到整车级别的ECU的架构设计，下到使用MBD方法设计符合Autosar标准的功能组件，以及开发运行环境与基础软件。

基于模型的开发，MBD

传统的嵌入式软件开发包括书面设计、手工编码，以及如代码检查，单元集成测试等验证工作。其中许多流程缺少工具的自动化需要手工完成，因此既耗时又容易产生错误。工具链的集成的缺失是另一个容易产出错误的方面，此类错误在软件开发过程中往往探测较晚而且需要花费很大代价。

      为了应队这些挑战，MBD已经成为汽车行业广泛使用与认可的方法，仿真测试不仅可以洞悉系统的动态、算法方面，而且模型还有如下优点：

        （1）作为可执行规范

        （2）交流软件需求规范，为顾客与供应商之间提供接口定义

        （3）为开发算法提供汽车系统以及驾驶员、环境、路况条件等模型提供虚拟原型

        （4）产品的自动生成

生命周期管理，V模型

       下图取自VECTOR官方宣传册，所谓的V模型，是一种用图像表示系统发展生命周期的模式，可以产出严谨的发展生命周期模型。图中V模型列出了在产品开发时需进行的各个阶段，以及各阶段对应的产出，并且描述了产品开发中需进行的活动，以及各活动产出的资料或是文件。而这些文件也是后面阶段需要的资料输入。

        V模型的左侧是需求的分解，并且产生系统的规格，V模型的右侧是各部份的整合以及确认（validation）。

Autosar SWC开发

 MBD的概念在Autosar开发中可以发挥更大的优势，而且应该被更多的使用。一旦公司决定遵循Autosar流程开发ECU，设计或软件工程师不应该被迫改变他或她的工作流程，以生成符合AUTOSAR标准的软件。MATLAB，Simulink和Real-Time Workshop Embedded Coder生成AUTOSAR标准的代码是透明和直观的过程，它支持两种不同的工作流程：自上而下和自下而上。

自上而下 Top-Down

自上而下，从架构模型到Autosar SWC。在自上而下的开发流程中，系统工程师使用架构生成工具（如davinci tool suite）来设计整车ECU网络。当然，工程师也可以使用其他的架构设计工具。架构软件会输出一个XML来描述对应的组件，该文件里包含了组件的一些必要信息比如：runnables，接口，数据类型等等。Matlab软件可以利用架构软件生成的XML文件自动创建Simulink架构模型，里面包含了接口模块以及相应的Autosar相关设置。之后系统工程师就可以在该框架模型的基础上，完善内部的控制模块。

自下而上 Bottom-Up

      自下而上，通过现有的Simulink控制模型来自动生成架构软件所需的XML文件。因为汽车产业已经非常成熟，许多公司已经有许都测试好的库与模型。这些模型能够重用到不同的平台，比如Autosar架构中，而不需要对模型进行任何人力修改，这点非常重要。自下而上的工作流程，与自上而下的工作流程都需要相同的Autosar配置， 尤其是接口对象需要被正确设置，来保证SWC可以被正确集成。

随着汽车ECU软件程度的复杂性增加，OEM与供应商联合建立了行业中最大的标准——AutoSAR标准，这被视为是应付软件复杂性挑战中的最重要的一步。Autosar专注于各SWC之间的通信，并解耦了应用层软件与基础软件。使用MBD方法设计功能软件，由于这两种方法的双向性，MBD与AutoSAR不仅是相互兼容的，也是互补的。这种组合不仅方便了架构设计、系统设计工程师，也方便了OEM与供应商。

2 汽车ECU及MCU

2.1 ECU

ECU（Electronic Control Unit）全称电子控制单元，ECU的功能是根据各种传感器输入的信号进行处理、运算、判断等操作，然后输出结果，执行器则根据ECU输出的电信号驱动执行机构完成整个控制流程。

在汽车领域，ECU又称为行车电脑，它和单片机一样，由微处理器（MCU）、存储器（RAM、ROM）、输入输出接口（I/O）、数模转换（A/D）以及整型、驱动等大规模集成电路组成。

       下图截取自《瑞萨–汽车电子》中的一个典型ECU：

目前在一些中高级轿车上，不但在发动机上应用ECU，在其它许多地方都可发现ECU的踪影，如防抱死制动系统、4轮驱动系统、电控自动变速器、主动悬架系统、安全气囊系统、多向可调电控座椅等都配置有各自的ECU。随着汽车工业的发展和自动化程度的提高，ECU将日益增多，线路也愈发复杂。为了简化电路和降低成本，汽车上多个ECU之间的信息传递就要采用一种称为多路复用通信网络技术，将整车的ECU形成一个网络系统，也就是CAN数据总线。

       目前，汽车内部主要包括以下控制模块，其中各控制模块可能包括一个或多个ECU：

·         发动机控制模块（ECM）

·         动力总成控制模块（PCM）

·         变速箱控制模块（TCM）

·         制动控制模块（BCM或EBCM）

·         中央控制模块（CCM）

·         中央计时模块（CTM）

·         通用电子模块（GEM）

·         车身控制模块（BCM）

·         悬架控制模块（SCM）

2.2 MCU

MCU（Microcontroller Unit）微控制单元，又称微型计算机或单片机。其特点为将中央处理器规格适当裁剪，并将内存、计数器、A/D、USB、UART等周边接口集成在单一芯片是，形成芯片级的计算机，为不同的应用场合做不同组合控制（微处理器发展出来的3个分支：DSP、MCU、MPU，其中DSP运算能力强，适合做信号处理，而MCU集成了多种片上外围器件，适合进行控制）。

一般通用的MCU，片上包括RAM、ROM等常见资源。在车载ECU中，MCU是其最为核心的部分，可以理解为片上集成了各种资源后的MCU即我们所说的ECU。根据ECU的功能不同，片上资源的集成情况也不同，除了通用的RAM、ROM等常见资源外.

如复杂的燃油发动机系统：

      变速箱控制系统：

      和简单的雨刮器系统：

3 AutoSAR Classic

3.1 简介

什么是AutoSAR？（官网地址：https://www.autosar.org/）

            AUTOSAR – AUTomotive Open Systems ARchitecture

            AUTOSAR（汽车开放系统架构）联盟成立于 2003 年，联盟中的各个成员保持着汽车业内的开发合作关系。该联盟致力于为汽车电子控制装置开发一个开放的、标准化的软件架构。

      为什么需要AutoSAR？

           • AUTOSAR致力于解决硬件平台不同带来的软件开发的困难，使开发者能够专注于汽车软件功能上的创新

           • AUTOSAR提供标准的软件接口定义，工程师可以根据实际需求将所需要的软件组件分配到汽车的ECU中，实现标准软件组件的可重用性

           • 应用层软件组件是独立于硬件的，应用开发者可以在应用软件中指定各个车辆功能的细节，而不用担心底层软件服务和硬件接口

3.2 整体架构

      AutoSAR架构区分了在MCU上运行的3个软件层之间的最高抽象级别：应用软件层（AL）、运行时环境（RTE）和基础软件（BSW），其中第0层（最外层）架构如图下图所示：

      AL将软件划分为一个Software Component（SWC），包括硬件无关的Application Software Component、Sensor Software Component、 Actuator Software Component等。

RTE提供基础的通信服务，支持Software Component之间和Software Component到BSW的通信（包括ECU内部的程序调用、ECU外部的总线通信等情况），RTE使应用层的软件架构完全脱离于具体的单个ECU和BSW。

       BSW分为服务层、ECU抽象层、微控制器抽象层、复杂驱动，第1层架构如下图所示：

每层BSW中，都包括不同的功能模块，如Services包括系统服务、内存服务、通信服务等，如下图所示（第2层架构）：

      根据AutoSAR 4.3.1最新标准，BSW层里进行了相应扩展，最新架构如下图所示（第3层架构）：

其中：

• 服务层（Service Layer）位于BSW的最上面，将各种基础软件功能以服务的形式封转起来，供应用层调用。

• 服务层包括了RTOS、通信与网络管理、内存管理、诊断服务、状态管理、程序监控等服务。

• ECU抽象层（ECU Abstraction Layer)封转了微控制器层以及外围设备的驱动。

• 将微控制器内外设的访问进行了统一，使上层软件应用与ECU硬件相剥离。

      • 微控制器抽象层(Microcontroller Abstraction Layer) 是在BSW的最底层，它包含了访问微控制器的驱动。

      • 微控制器抽象层使上层软件与微控制器相分离，以便应用的移植。

      • 为了满足实时性等要求，可以利用复杂驱动（Complex Drivers），让应用层通过RTE直接访问硬件。

3.3  应用层

       • 应用层由各种AUTOSAR Software Component（SWC）组成

       • 每个SWC都封转了各种应用的功能集，可大可小

       • 每个SWC只能运行在一个ECU中，也可称为Atomic SWC

3.3.1 对外表现形式

Port

软件组件通过端口（Port）来进行不同软件组件间或者软件组件与硬件间的通讯或者交互。每个软件组件都需要定义端口。端口代表了软件组件间通信内容及其方向，分为两类，一类是供型端口（P-Port），一类是需型端口（R-Port）。

供型端口用于对外提供某种数据或者某类操作，需型端口用于从其他软件组件获得所需数据或者所请求的操作。将一个软件组件的供型端口与另外一个软件组件的需型端口进行连接，即实现了两个软件组件直接的通信，如下图所示：

Interface

每个端口虽然定义了软件组件间通信内容及其方向，但是通信内容以及用于交互的操作却仍不得而知。AUTOSAR中使用端口接口（Port-Interface）来描述端口之间的供需关系。端口接口有3种，分别为发送者/接收者接口（Sender-Receiver Interface，S-R）、客户端/服务器接口（Client-Server Interface，C-S）和标定接口（Calibration Interface），如下表所示：

      S/R接口定义了一系列的数据元素用于在虚拟功能总线上进行接收和发送，如Port图的ISignalPeriod所示，该接口定义了一个命名为duration，类型为无符号16位整数的数据元素（即全局变量的读写）。

C/S接口定义了一系列的操作，这些由包含该接口的供型端口所在的软件组件来实现，并提供给包含该接口的需型端口所在的软件组件调用，如Port图的ILeverPos所示，该接口定义了一个命名为getAngle，有一个输出类型（即值可以被函数修改）的有符号12位整数参数的操作（即函数调用）。

3.3.2 内部行为

SWC的功能是通过运行实体（Runable Entity）来表现的，SWC被分为若干个可执行单元（即运行实体），运行实体软件是组件中的一组指令序列，一个或者多个运行实体实现了其所在软件组件对外提供的功能。每个运行实体都与一个特定的RTE事件（RTEEvent）绑定，当绑定的事件发生时，对应的运行实体就会被触发。

在AUTOSAR操作系统中，运行实体将会运行在操作系统的任务的上下文中，任务需要给运行实体提供必需的资源，例如栈空间等。运行实体通过访问端口的数据或者操作来完成自身的功能，并把数据处理的结果或者提供的操作通过端口对外提供。因为端口上的通信机制是由虚拟功能总线进行抽象过的，因此运行实体的实现中，涉及到访问端口数据或操作的时候，需要使用RTE提供的API来进行访问。这样，使得运行实体的实现是与平台无关的，从而软件组件也是与平台无关的，进而增强了软件组件的移植性和可重用性。运行实体可以通过建模工具进行建模设计并自动生成代码，也可以手工编写代码。

如前所述，每个软件组件必须提供其代码的具体实现以及描述文件。代码实现即运行实体的实现，以C源文件或者目标文件的方式提供。而描述文件必须描述软件组件的属性，包括所使用的端口、端口接口、运行实体、以及运行实体所对应的RTE事件等，以XML（eXtensible Markup Language）文件形式提供：

3.3.3 SWC的主要类型

3.4 VFB与RTE层

VFB - Virtual Functional Bus，虚拟功能总线，是对Autosar提供的所有通信机制的一种抽象，是所有软件组件进行交互的桥梁。通过虚拟功能总线，软件组件之间的通讯细节被抽象出来，软件组件通过Autosar定义的接口对通讯进行描述，即可最大程度地独立于具体的通讯机制，实现与其他软件组件和硬件的交互：

      前面提到过，将软件设计与硬件决策分离使得OEM能够基于所需功能对汽车ECU进行自上而下的设计，而VFB使得在软件设计阶段，所有的ECU都能实现互联并得到测试。这种分离方法使得在定义相关硬件之前实现所有车辆软件功能和接口的交互验证成为可能。

3.4.1 基于VFB的通信方式

Client/Server通信

·         同一ECU内部， CS通信为函数调用

·         ECU之间， CS通信为远程接口调用

·         CS通信分为同步和异步通信

Sender/Receiver通信

·         同一ECU内， SR通信为变量传递

·         ECU间， SR通信为数据传输

·         SR通信为异步的数据传输， Sender端不会收到Receiver的任何响应

3.4.2 RTE

RTE - Runtime Environment，运行时环境，充当系统级通信中心，用于ECU之间和内部的信息交换。RTE为SWC提供统一的运行环境用于实现SWC独立于具体通信机制。

RTE对应用层的软件组件封装了下层的基础软件，并利用下层的基础软件比如操作系统、COM等的功能实现向上层软件组件提供运行、组件间通信和生命周期控制，类似于向应用层提供基础软件的接口。

·         RTE是VFB在具体一个ECU中的实例

·         RTE实现了应用层SW-C之间、应用层SW-C与BSW之间的具体通信

·         RTE通过划分RTOS的任务、资源、事件等， 提供给组件一个隔离底层中断的运行时环境

      VFB中定义的通信最终映射到RTE提供的具体交互实现接口上，如下图中，当两个SWC实现的是不同ECU间的通信，则他们的通信接口就会映射为ECU间的物理通信，例如通过CAN/LIN等方式。

生命周期管理

RTE向软件组件提供运行环境，负责管理软件组件的运行实体的运行。RTE按照软件组件的内部行为中定义的RTE事件，在适当的情况下触发某个RTE事件以激活相对应的运行实体运行。所有软件组件的运行实体都必须由RTE事件激活才能运行。此外，RTE还向ECU状态管理器提供控制整个RTE运行的开关接口，以便在系统停机或睡眠状态下开启和关闭RTE。

组件通信实现机制

软件组件的运行实体在通过端口与其他软件组件通信是通过调用RTE API函数而非直接实现的，都在RTE的管理和控制之下。每个API遵循统一的命名规则且只和软件组件自身的描述有关，比如图 1中软件组件“SWC1”的运行实体“A”通过供型端口“switch”的向外发送名为“a”的数据元素，软件组件“SWC2”的运行实体“B”通过需型端口“cmd”接收这个数据，则运行实体“A”实现时调用的RTE API是Rte_Write_switch_a，运行实体“B”实现时调用的RTE API是Rte_Read_cmd_a。由此可见软件组件在实现与其他软件组件通信时，不依赖于具体的ECU软件平台，也不依赖于它所处的网络环境和与它通信的对方的位置。软件组件可以独立地实现其功能算法，并且从一个ECU迁移到其他ECU上时，无需修改实现代码，从而真正实现虚拟功能总线的概念。

      软件组件的实现假定RTE能够保证提供唯一的上述RTE API。软件组件感知的RTE API仅由端口和通信内容决定其函数名格式，如果不同软件组件恰好有同名端口，并且端口的类型也一致的情况下，RTE无法保证API的唯一。所以RTE在实现API的时候会在函数名上加上软件组件的类型名以保证不同类型的软件组件的RTE API不会冲突。RTE通过在由软件组件确定的RTE API和RTE实际实现的API做个映射来关联它们：

RTE API到实际API的映射，隐藏了API的实现。比如对某个具体的ECU内通信途径，可能实现为直接函数调用；对一个ECU间的通信，则可通过COM实现。RTE可以在API映射时，尤其是ECU内的映射，做一些优化工作。有些ECU内的S/R通信API可以直接映射到赋值语句；有些ECU内的C/S通信API可以直接映射为调用服务运行实体的语句。这些优化可以节省函数调用的开销，提高RTE的实时性。

软件组件不允许绕过RTE直接访问下层基础软件提供的服务。服务、ECU抽象和复杂驱动被抽象成一个同样有端口的软件组件，通过服务连接器与应用层的软件组件组合成ECU组合组件，并且BSW中的组件都具有标准化的AUTOSAR接口。具体通信实现取决于系统设计和配置，都由工具供应商提供的RTE Generator自动生成。

运行实体（Runnable Entity）映射

       SWC中包含一个或多个运行实体，运行实体映射在MCU的实时系统RTOS的任务中调度运行，可以分为两类：

·         无需中间等待的运行实体（Cat 1）：映射为基本任务或扩展任务

·         有等待事件的运行实体（Cat 2）：运行实体在运行中间可能需要等待某个事件发生，比如远程调用等待特定返回值。只能将这类运行实体映射为扩展任务，通过事件机制来实现等待同步功能

3.5 BSW层

直接上图：

3.5.1 MCU抽象层

·         MCU Drivers 微控制器驱动：看门狗、GPT等

·         Memory Drivers 内存驱动：片内EEPROM、Flash等

·         Communication Drivers 通信驱动：SPI、CAN等

·         I/O Drivers 输出输出驱动：ADC、PWM、DIO等

      以通信驱动为例中SPI驱动为例，Autosar规定的SPIHandlerDriver封转了统一访问SPI总线的接口，上层软件可以并发的多个访问，如下图：

      （具体接口规范和细节，可以查阅Autosar官网的Release），以最新的4.3.1为例：

      然后进入Communication章节，每个通信协议都有单独的PDF说明：

3.5.2 Complex Drivers复杂驱动

利用中断、 TPU、 PCP等，复杂驱动可以实现了实时性要求高的传感器采样、执行器控制等功能，如Injection Control（燃油喷射控制）、Electric Valve Control（电动阀控制）、Incremental Position Detection（增量位置检测）等：

3.5.3 I/O硬件抽象

·         可以通过I/O硬件抽象中的信号接口来访问不同的I/O设备

·         将I/O信号都进行了封转，比如电流、电压等

3.5.4 COM硬件抽象

·         COM硬件抽象将微控制器、板上的所有通信通道进行了封装

·         将LIN、 CAN、 FlexRay等通信方式都进行了抽象定义

3.5.5 Memory硬件抽象

      Memory硬件抽象将片内、板上的内存资源进行了统一封装，比如对片内EEPROM和片外的EEPROM都提供了统一的访问机制：

3.5.6 Onboard Device抽象

Onboard Device Abstracion将ECU硬件上特殊的外设（即不是用于传感，也不用于执行的）进行封装，比如Watchdog：

3.5.7 通信服务

通信服务封转了CAN、 LIN、 FlexRay等通信接口

·         提供统一的总线通信接口

·         提供统一的网络网络管理服务

·         提供统一的诊断通信接口

以CAN通信为例，Autosar针对CAN的通信服务封装了具体的协议（J1939TP、CanTP）、消息属性，体统了同一的接口供应用层调用：

3.5.8 系统服务

      System Services提供RTOS服务，主要包中断管理、资源管理、任务管理等，同时提供功能禁止管理、ECU状态管理、看门狗的管理、时钟同步管理、基本软件模式管理等服务。

3.6 示例：车前灯管理系统

完成车前灯管理的应用层涉及到3.3.3节中提到的三种类型的SWC：Application SWC、Sensor SWC、Actuator SWC.

参考文献：

1.    VECTOR – AUTOSAR解决方案

2.    瑞萨 – 汽车电子

3.    https://www.researchgate.net/publication/267374791_Development_of_AUTOSAR_Software_Components_within_Model-Based_Design

4.    https://retis.sssup.it/sites/default/files/lesson19_autosar.pdf

5.    ECU软件的AUTOSAR分层架构 – 浙江大学ESE工程中心