(一）ECU和域控制器

本次文章不show me the code，对一些汽车基础问题进行梳理。首先我们讲的这套AS平台的代码https://github.com/thatway1989/as，实现了AUTOSAR cp的功能，但是这套代码跟汽车有什么关系？整天AUTOSAR、诊断、CAN什么的，但是不知道在车上怎么用，就像只听见过猪叫，没见过猪跑一样。

首先AS这个平台模拟了一个域控制器，并且上面跑的代码就是AUTOSAR cp的代码。那么什么是域控制器，在汽车软件演进的过程中又扮演了什么角色，AUTOSAR的软件框架又是什么，跟汽车业务又有什么关系？这些将在文中一步一步分析。

1. 什么是ECU？

电子电路相对于机械控制的优点在于精细化和自动化，是智能化的基础。

首先，要精细化的控制，就需要在传统机械设备上引入电子电路。1968 年电子设备首次出现在汽车中，当时大众汽车在大众1600轿车的发动机中安装了电子控制单元 (ECU)，以帮助控制燃油喷射。

另外，在当今智能化汽车对控制要求更加严格，内燃机提供的动力比较奔放，不利于进行细微的控制，而电机，特别是步进电机，转动一圈360度可以按角度进行控制，极其精密，这样给智能驾驶提供了可能，智能驾驶需要非常细微的控制，复杂难控制的燃油发动机是不具备精细控制的条件的，不然把人撞死就完了。除却新能源，这就是电动车将要取代燃油车一个重要原因。

上面提到ECU（Electronic Control Unit）电子控制器单元，它们的用途就是控制汽车的行驶状态以及实现其各种功能，是一块独立的电路板。主要是利用各种传感器、总线的数据采集与交换，来判断车辆状态以及司机的意图并通过执行器来操控汽车。

随着汽车智能化的发展，汽车里面ECU逐渐增多，达到了100+。这么多ECU，汽车软件这时候的构架是分布式的，汽车里的各个ECU都是通过CAN和LIN总线连接在一起，如下图：

下面罗列一些主要的ECU：

EMS（Engine Mangement System）发动机管理系统，应用在包括汽油机PFI（如上图）、GDI，柴油机，混合动力系统等，主要控制发动机的喷油、点火、扭矩分配等功能。

TCU（Transmission Control Unit）自动变速箱控制单元，常用于AMT、AT、DCT、CVT等自动变速器中，根据车辆的驾驶状态采用不同的档位策略。

BCM（Body Control Module）车身控制模块，主要控制车身电器，比如整车灯具、雨刮、洗涤、门锁、电动窗、天窗、电动后视镜、遥控等。

ESP（Electronic Stability Program）车身电子稳定控制系统，车身电子稳定控制系统。ESP可以使车辆在各种状况下保持最佳的稳定性，在转向过度或转向不足的情形下效果更加明显。ESP是博世公司的专门叫法，譬如日产的车辆行驶动力学调整系统VDC（Vehicle Dynamic Control ），丰田的车辆稳定控制系统VSC（Vehicle Stability Control ），本田的车辆稳定性控制系统VSA（Vehicle Stability Assist Control），宝马的动态稳定控制系统DSC（Dynamic Stability Control ）等。现如今很多中高端合资车、国产车都会配备这个模块。

BMS（Battery Management System）电池管理系统，顾名思义这个控制器是专门针对配备有动力电池的电动车或者混合动力车准备的。主要功能就是为了能够提高电池的利用率，防止电池出现过度充电和过度放电，延长电池的使用寿命，监控电池的状态。

VCU（Vehicle Control Unit）整车控制器，用于混合动力/纯电动汽车动力系统的总成控制器，负责协调发动机、驱动电机、变速箱、动力电池等各部件的工作，提高新能源汽车的经济性、动力性、安全性并降低排放污染。

2. 什么是域控制器？

当出现了这么多ECU，首先从成本上来说，这么多电路板，每个电路板上都有芯片，成本非常的高，并且这么多ECU要连线，线束的总长度很大，成本很高。这些电路板很多功能都是一样的，完全可以一个电路板把活干完，但是由于汽车不同零部件的供应商不一样，很难协调。另外这些ECU如果需要交互，在一起协调工作就变的很困难，满足不了智能控制的需求。

为了解决分布式EEA（Electrical ElectronicArchitecture电子电气架构）的这些问题，人们开始逐渐把很多功能相似、分离的ECU功能集成整合到一个比ECU性能更强的处理器硬件平台上，这就是汽车“域控制器（Domain Control Unit，DCU）”。域控制器的出现是汽车EE架构从ECU分布式EE架构演进到域集中式EE架构（如下图）的一个重要标志。

域控制器是汽车每一个功能域的核心，它主要由域主控处理器、操作系统和应用软件及算法等三部分组成。平台化、高集成度、高性能和良好的兼容性是域控制器的主要核心设计思想。依托高性能的域主控处理器、丰富的硬件接口资源以及强大的软件功能特性，域控制器能将原本需要很多颗ECU实现的核心功能集成到进来，极大提高系统功能集成度，再加上数据交互的标准化接口，因此能极大降低这部分的开发和制造成本。

对于功能域的具体划分，各汽车主机厂家会根据自身的设计理念差异而划分成几个不同的域。比如BOSCH划分为5个域：

动力域（PowerTrain）、

底盘域（Chassis）、

车身域（Body/Comfort）、

座舱域（Cockpit/Infotainment）、

自动驾驶域（ADAS）。

这也就是最经典的五域集中式EEA，如上图所示。也有的厂家则在五域集中式架构基础上进一步融合，把原本的动力域、底盘域和车身域融合为整车控制域，从而形成了三域集中式EEA，也即：

车控域控制器（VDC，Vehicle Domain Controller）、

智能驾驶域控制器（ADC，ADAS\AD Domain Controller）、

智能座舱域控制器（CDC，Cockpit Domain Controller）。

大众的MEB平台以及华为的CC架构都属于这种三域集中式EEA。

后记：

前面说到域控制器是由域主控处理器、操作系统和应用软件及算法等三部分组成，而这三部分正式AUTOSAR软件构架所规范的内容，可以这么说AUTOSAR规范了域控制器的实现方式。下节介绍AUTOSAR软件框架。

（二）AUTOSAR的组成和演进

前文了解了汽车ECU和域控制器，从汽车功能上进行了说明。这些功能的具体实现还是需要电路板+软件来实现的。AS这个平台（代码路径：https://github.com/thatway1989/as）通过qemu虚拟机可以模拟了一个域控制器的硬件，并且上面跑的代码就是AUTOSAR CP的代码。硬件这里不去研究，上面运行的AUTOSAR软件结构是什么样的，怎么进行编程实现？本文将进行说明。

1. ECU到域控制器的变化

上图中列举了两个功能：车门ECU和车顶灯ECU ECU的软件框架。可以看到，除了最上面的一层控制逻辑的SWC，下面的部分是可以共用的，也就是软件是可以复用的。

融合的思路很简单，第一步把相同的部分找出来，第二步部分规定一个接口规范，如果有不同的部分就按照接口去跟相同的部分对接。这样就拼接成一个整体了。如下：

复用就涉及到统一接口的问题，大家都按照统一的一个规范搞，就可以兼容互换，以此诞生了AUTOSAR（AutomotiveOpen System Architecture）组织，中文是“汽车开放系统架构”，如下图中应用软件层是根据不同的需求会变化的，同样对于底层硬件根据供应商价格和性能的不同也是会不断更换。可以把中间的这一层不变的东西抽取出来，任你上下面怎么变，我都不用动，一次做好就不需要投入人力去开发这一部分，这样就节省了软件开发成本。

相同的部分，抽取出来如下图所示：

2. AUTOSAR的分层结构

分层架构是AUTOSAR的一个核心，是实现软硬件分离的关键。

这个过程比如做菜的话，SWC就是炒菜，RTE就是锅，那BSW就是切好的菜包括洗菜、切菜等，硬件就是未加工的菜。如果要做不同菜，未加工的菜（Hardware）和炒菜的方法（SWC）可以根据客人的需求变化，但是锅（RTE）和洗菜切菜（BSW）就不用变化了。

SWC（SoftwareComponent）

as中代码路径：as/com/as.application/common/test

对于应用来说每个车的功能都不同，千变万化又有创新性，比如车灯控制，每个车的车灯个数和位置都不一样，车顶控制的软件肯定不一样。

应用软件层（Application Software Layer，ASW）包含若干个软件组件（Software Component，SWC），软件组件间通过端口（Port）进行交互。

RTE（RuntimeEnvironment）

as中代码路径：as/com/as.application/common/rte

当SWC变化的时候，下面的软件都不变，这时候就需要一个软总线，就好像一条高速公路，不管你从什么类型的路上这条高速都按照高速公路的规则运行。这个高速公路就是RTE。

运行时环境（Runtime Environment，RTE）作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现。

BSW（Basic SoftwareLayer）

as中代码路径：as/com/as.infrastructure

基础软件层（Basic Software Layer，BSW）又可分为四层，即服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers），如下图：

AUTOSAR基础软件层上述各层又由一系列基础软件组件构成，包括系统服务（System Services）、存储器服务（Memory Services）、通信服务（Communication Services）等，如下图所示。它们主要用于提供基础软件服务，包括标准化的系统功能和功能接口。

AUTOSAR基础软件层结构

（1）服务层服务层（Services Layer）提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务（System Services）、存储器服务（Memory Services）以及通信服务（Communication Services）三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统（Real Time Operating System，RTOS）等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。

（2）ECU抽象层ECU抽象层（ECU Abstraction Layer）包括板载设备抽象（Onboard Devices Abstraction）、存储器硬件抽象（MemoryHardware Abstraction）、通信硬件抽象（Communication HardwareAbstraction）和I/O硬件抽象（Input/OutputHardware Abstraction）。该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。该层与ECU平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。

（3）微控制器抽象层微控制器抽象层（MicrocontrollerAbstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动（Microcontroller Drivers）、存储器驱动（MemoryDrivers）、通信驱动（Communication Drivers）以及I/O驱动（I/O Drivers），如下图所示。

（4）复杂驱动层由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在AUTOSAR规范中这部分没有被标准化，统称为复杂驱动（Complex Drivers）。

SWC拓展知识：

服务软件组件（Service SWC）。

应用软件组件（Application SWC）主要用于实现应用层控制算法。

传感器/执行器软件组件（Sensor/ActuatorSWC）用于处理具体传感器/执行器的信号，可以直接与ECU抽象层交互。

标定参数软件组件（Parameter SWC）主要提供标定参数值。

ECU抽象软件组件（ECUAbstraction SWC）提供访问ECU具体I/O的能力。该软件组件一般提供引用C/S接口的供型端口，即Server端，由其他软件组件（如传感器/执行器软件组件）的需型端口（Client端）调用。此外，ECU抽象软件组件也可以直接和一些基础软件进行交互。

复杂设备驱动软件组件（Complex Device Driver SWC）推广了ECU抽象软件组件，它可以定义端口与其他软件组件通信，还可以与ECU硬件直接交互。所以，该类软件组件灵活性最强，但由于其和应用对象强相关，从而导致其可移植性较差。

服务软件组件（Service SWC）主要用于基础软件层，可通过标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互。

3. AUTOSAR方法论

这里的方法论见我之前的评价：AUTOSAR入门-江湖

软件提供商（外国的）感觉有点居心叵测，把软件做成，能多傻瓜化就多傻瓜，做成了工具链，车厂的人在界面傻瓜点点配置下就自动生成软件了，一行代码也看不到，给的代码全是宏就不是让人看的。让你啥都不会，然后涨价爱用不用，不用没了，反正你自己也不会也搞不出来。--这就是AUTOSAR的方法论，这里好像解释成阴谋论了。下面就来说说怎么在界面上点一点这个过程。

1)ECU提取文件生成

上面图中就是OEM提供ECU提取文件的过程，这里面用到SWC 描述文件、系统约束描述文件、ECU 资源描述文件。

过程如下：三种文件导入系统配置的编辑工具中，生成系统配置描述文件，就是整车的描述文件。整车的描述文件导入系统配置提取工具中，得到每个 ECU 的提取文件，包含了每个 ECU 需要用到的信息。

ECUEX：ECU Extractof System Description，即前面的 ECU 提取文件，由 OEM 交给 TIER1，TIER1 根据这个文件设计和开发 ECU。ECUEX 是 arxml 文件，但如果只做通信矩阵，DBC 也可以。

2）arxml文件生成

首先根据需求，对硬件进行配置，也就是使用EB工具配置MACL，生成MACL信息文件的arxml文件。

3）代码生成

根据arxml文件，这里生成的代码分为两类，给BSW用的和给SWC用的。

a）首先给BSW系统服务用的，这部分生成的是配置代码，可以理解为C语言的全局变量，可以作为函数执行的参数，另一方面是生成宏，控制程序的执行流程，然后跟BSW中不动的代码一块参与编译。as中代码路径：as/com/as.tool/config.infrastructure.system/argen

b）给SWC用的代码一般是智能化方面的代码，比如智能驾驶深度学习的参数，需要一些工具比如matlab生成。

4. AUTOSAR从CP到AP过渡

上面讲的都是AUTOSAR CP的功能。CP里面首先做到了硬件的复用即用一块电路板实现多块的功能，然后功能上进行了复用，比如里面对CAN的服务就一个模块。但是在软件资源方面，比如内存和CPU并没有进行复用。这里先说一个静态系统和动态系统的概念：

静态系统：系统的资源在运行前就已经分配好了，就像10块钱，5个人分，每人2块，多少就这样了。

动态系统：系统的资源运行起来后了按需分配，比如还是5个人，但是不会同时需要用钱，一共准备5块钱就够用了，谁需要就给谁，这样就节省了资源。

CP就是静态系统，所有的数据通道内存资源都是分好的，并且CPU是单片机时间片也是分好的，优点就像计划经济，稳定。但是这样一个系统的规模是有瓶颈的，当需要分配的单位越来越多的时候，硬件已经不堪重负了。不复用不变通，整个系统就会走向灭亡。

上图中可以看到AP中有了操作系统和服务，采用的面向对象的语言C++，当有服务请求的时候就从服务类里面new一个对象，现用现分资源，用完立即资源回收。从整个系统通信角度看，也从面向信号到面向服务转变。

汽车智能化，构件越来越复杂是推动CP到AP的根本因素，在这个过程中有两个方面尤为突出就是基于以太网的组网和复杂CPU的发展。

智能化要联网协作，节点越来越多，并且可能会通过无线接入Internet网络，实现远程控制。另外联网的设备比如摄像头的数据量激增，汽车上传统的基于信号的通信比如CAN和LIN已经满足不了，需要采用更复杂功能更强的以太网通信，车载以太网为汽车ECU带来了更高的带宽，使得数据的大量传输能够在短时间得以实现。以太网为更加有效地传输长消息和提供点对点通信提供了有效的解决方案。然而，AUTOSAR另一平台CP则是为了传统的车载通信技术CAN设计的，不能很好地兼容以太网，难以支持基于车载以太网的通信。

近些年来汽车变得越来越智能，随之汽车对处理器的性能也提出了更高的要求，诸如自动泊车、环境感知、路径规划等高级功能对处理器的高算力需求远远高于对多核的需求。活多就得一个人都干了，像上图中的一人乐队一样。

上图中可以看出来，由传统观念的一个操作系统用一个CPU，变成多个CPU提供一个服务，一个服务支撑多个操作系统。

就像有地一块种，有饭一起吃一样，这样才能集中力量办大事。

从处理器和半导体的技术角度来看，一个CPU提高性能的唯一方法是多核并行运行，然后如果还不行那就多个CPU再并行起来，以提供更强的算力。

另一方面，不同的操作系统，比如控制系统的实时操作系统，娱乐域的非实时操作系统，控制系统的RTOS等可以满足不同的需求需要在系统中共存。那么所有的软件都运行一个硬件集合上面而不是各自为战这样效率就又可以提升。真是计算机计算的发展就是未来榨取更多的硬件资源。就像很多各种各样的烧煤风力等发电站，现在一个大型核电站就搞定了，所有能源集中供应。

AP和CP的优势不同，在系统上需要同时运行起来。所以AP 不会取代 CP 或非 AUTOSAR 平台。相反，AP 和后端系统以及路边基础设施共同协作，发挥各自的优势，一起工作形成一个完整的系统。