1 引言
近年来，越来越多的公司采用AUTOSAR工具链进行车载ECU软件开发，这对采用传统手写代码方式设计程序的工程师而言是个不小的挑战，主要体现在以下3个方面。（1）AUTOSAR规范涉及到很多全新的概念，像RTE、SWC、BswM这些概念，很多手写代码多年的老工程师也是不懂的。（2）C语言编程和使用工具链配置的方式进行软件设计，在思路上存在不小的差异，在开发方式切换的过程中可能感到诸多不适应。（3）虽然AUTOSAR规范也是用C语言实现的且源程序可见，但由于模块繁多且每个功能块所含的代码量过于庞大，短期内很难再用“把每行代码搞清楚”的方式保证程序质量，而且在程序执行异常时由于对代码不熟悉，即使是有着多年C编程经验的老工程师，也可能会有“问题查找无从下手”的感觉。针对以上问题，我想从传统的手工编程入手，逐一介绍AUTOSAR的基本概念和使用工具链开发的思路方法，希望对从手写代码切换至工具链开发的车载嵌入式软件工程师有一点点帮助。由于我学习使用AUTOSAR工具链的时间不长，很多概念和方法属于“现学现卖”的阶段，又在文中加入了不少自己的理解和感悟，其中的错误在所难免，恳请广大同行们批评指正，共同进步。2 控制实例
在本文中，我们以应用在某重卡主驾座椅上的“ECAS控制器”为例，说明RTE的实现过程。该控制器的核心功能是“将座椅高度始终保持在设定位置上”，通过控制进气阀和排气阀的开闭调节空气弹簧的充气量，从而实现加载在座椅的重量发生变化时（不坐人或坐不同重量的人）其高度始终不变。表2-1为与之相关的主要部件及其功用。表2-1: 座椅ECAS控制器相关主要部件及其功用序号 | 部件名称 | 功用 |
1 | 高度传感器 | 实时采集座椅当前高度 |
2 | 进气阀和排气阀 | （1）进气阀打开，排气阀关闭：空气弹簧充气，座椅高度上升（2）进气阀关闭，排气阀打开：空气弹簧放气，座椅高度下降（3）进气阀和排气阀都关闭：空气弹簧无动作，座椅高度不变 |
3 基本概念
为表述方便，首先对本文中出现的概念或术语进行说明，文中黑体字为“官方定义”，红体字加入了本人的理解。注：由于AUTOSAR规范本身非本文讨论的范畴，其中的通用知识（如：分层架构、ARXML文件等）文中不再涉及，读者可参照各类资料学习掌握。3.1 车载嵌入式软件概念
（1）基础软件：包括微控制器驱动、外围芯片驱动、嵌入式操作系统、软件整体架构和集成等，部分公司称其为“驱动和架构”。（2）应用层软件：主要涉及到特定ECU的控制逻辑和算法等，部分公司称其为“算法和逻辑”。大多数车载ECU软件的核心由输入、处理和输出3部分组成，基础软件主要负责“输入和输出”部分，应用层软件专注于“处理”部分。3.2 AUTOSAR规范概念
（1）RTE：运行时环境。作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。 此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。举例来说，如果要设计“座椅ECAS控制器”的软件，程序首先要获取座椅的当前高度和目标高度，通过一系列算法处理（如PID算法），计算出当前时刻气囊进气口和出气口的状态，最后控制电磁阀进行座椅高度调节。这里面“采集座椅当前高度”由ADC模块完成，“控制空气弹簧进气口和出气口的电磁阀”由DO模块完成，这两者是基础软件的工作；“通过算法得到空气弹簧进气口和出气口的状态”由应用层软件完成。而“将基础软件采集到的高度传递给应用层”和“将应用层的电磁阀控制指令传递给基础软件层”，就是RTE的任务了。（2）SWC：软件组件。封装了部分或全部汽车电子功能的模块，包括了其具体的功能实现以及对应的描述。软件组件可以理解为“一系列程序文件（函数）的集合”。（3）Port：端口。根据输入输出方向可分为需型端口（Require Port，RPort，用于从其它软件组件获得所需数据或者所请求的操作）、供型端口（Provide Port，PPort，用于对外提供某种数据或者某类操作）与供需端口（Provide and Require Port，PRPort，兼有需型端口与供型端口的特性）。AUTOSAR规范中的“端口”相当于C语言中的“变量”，它的“变量类型”就是下面要介绍的“端口接口”。（4）Interface：端口接口。由于端口仅仅定义了方向，AUTOSAR中用端口接口（Port Interface）来表征端口的属性，常用端口接口包括如下两种类型：①发送者-接收者接口（Sender-Receiver Interface, S/R），用于数据的传递关系；②客户端-服务器接口（Client-Server Interface, C/S） ，用于操作（Operation,OP），即函数调用关系。
对于引用“发送者-接收者”接口的一组端口而言，需型端口为接收者，供型端口为发送者；对于引用“客户端-服务器”接口的一组端口而言，需型端口为客户端，供型端口为服务器。AUTOSAR规范中的“端口接口”相当于C语言中的“结构数据类型”，每个接口由一个或多个“数据元素”组成，相当于结构体的成员。但和数据类型不同的是，除了其包含的每个数据元素分别有一个数据类型之外，每个接口还有一个自己的类型，“S/R”类型表示数据传递，相当于C语言中的“b = a”；“C/S”类型表示函数调用，相当于C语言中的“b = func(a)”。3.3 信号
（1）系统信号：车载CAN网络信号，即某ECU从CAN网络接收和向CAN网络发送的信号。4 手写代码实现方法
这里所说的“手写代码”是指车载ECU程序的基础软件部分，应用层软件使用simulink等工具建模完成，下面以“座椅ECAS控制器”程序为例，介绍基础软件与应用层软件的“RTE”部分如何用手工编程的方式实现。4.1 参数接口
首先需要明确基础软件与应用层软件的参数接口，如表4-1所列。表4-1: 座椅ECAS控制器基础软件与应用层软件的参数接口信号类型 | 信号名称 | 精度 | | 数据范围 | 数据说明 |
| objectLevel | 0.1mm | uint16 | 0-200(mm) | 座椅目标高度，当数据为0时，表示该值无意义，或者程序处在初始化阶段，或者系统上电后驾驶员没有更新请求值；处在该值时，应用层算法不会进行运算 |
| 0.1mm | uint16 | 0-200(mm) | |
level_quality | - | uint8 | 0-255 | 8：初始化（初始化起始或从错误状态恢复），所有源信号合法 |
| 0.1mm | sint16 | 0-100(mm) | 正向精度值 |
| 0.1mm | | | 负向精度值 |
enable | 0/1 | boolean | 0-1 | 表示当前周期是否使能算法控制，若不使能，则输入enable=0，以保证算法控制函数运行的完整性 |
输出信号 | Control_status |
| uint8 | | |
is_Control_Over | 0/1 | boolean | 0-1 | 表示当前的控制算法是否已调节完毕，并达到了给定的precision精度要求。 |
4.2 函数接口
表4-2列出了基础软件与应用层软件之间的函数接口。表4-2: 座椅ECAS控制器基础软件与应用层软件的函数接口4.3 代码实现
这里使用2个源文件标识座椅ECAS控制器RTE手写代码实现方法，图4-1和图4-2分别为logic.c和main.c的代码截图。5 AUTOSAR工具链实现方法
AUTOSAR主流工具链大多由德国公司提供，包括Vector、ETAS、EB等，本文以ETAS公司的ISOLAR-AB工具为例讲述RTE的开发步骤，主要涉及到其中的2个子工具。AUTOSAR工具链中的“架构设计”即应用层软件组件的设计，可分为自上而下和自下而上2种开发方式。“自上而下”是指在ISOLAR-A中创建应用层SWC及其所包含的端口，再在Simulink中导入该SWC的arxml文件，并在此基础上进行逻辑和算法开发；“自下而上”是指在Simulink中创建端口、运行实体等SWC元素，再在ISOLAR-A中导入对应arxml文件生成SWC。本文采用“自上而下”的开发方式。下面介绍如何使用AUTOSAR工具链方式实现座椅ECAS控制器的RTE部分。5.1 工程导入
打开“ISOLAR-AB 4.0.2”环境，选择“File -> Import -> Existing Projects into Workspace”，点击“Next”。5.2 软件组件创建
座椅ECAS控制器需要创建3个软件组件，如表5-1所列。序号 | 软件组件名称 | 软件组件功用 |
1 | Controller_SWC | 控制软件组件，用于运行座椅高度控制的算法 |
| | 算法输入软件组件，用于提供座椅高度控制的输入参数 |
| | 算法执行软件组件，用于执行进气阀和排气阀的开闭动作 |
下面以Controller_SWC为例，介绍软件组件的创建步骤，其余2个软件组件的创建与之类似。5.2.1 文件夹创建
在“...\src\ASW”路径下创建“Controller_SWC”文件夹，再在其中创建“src”和“arxml”两个子文件夹。5.2.2 为控制软件组件创建arxml描述文件
在工程名上右键“New -> AUTOSAR File”，弹出图5-3所示的对话框，这里新建一个名为“Controller_SWC.arxml”的描述文件，并同时创建一个名为“Controller_SWC”的AR Package。 图5-3: 控制软件组件arxml描述文件创建界面
5.2.3 创建控制软件组件
按照图5-4和图5-5所示的方法创建控制软件组件。 5.2.4 文件移动
在“...\src\BSW”路径下找到“Controller_SWC.arxml”，并将其剪切到“...\src\ASW\Controller_SWC\arxml”位置。5.3 接口创建
座椅ECAS控制器需要创建的接口如表5-2所列，下面以“hld_Mw_objectLevel”为例讲述S/R接口的设计步骤，其余接口与之类似。 | | |
接口名称 | | 数据元素名称 | |
| | | hld_Mw_objectLevel | |
| | | | |
| | | | |
4 | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
5.3.1 接口创建
5.3.2 添加接口的数据元素
5.4 软件组件行为设计
下面对表5-1所列3个软件组件的行为进行设计，按照如下步骤进行。5.4.1 创建软件组件内部行为
按照图5-10所示依次创建Controller_SWC、AlgorithmInput_SWC和AlgorithmActuator_SWC的内部行为。5.4.2 添加软件组件端口
控制软件组件、算法输入软件组件和算法执行软件组件须添加的端口分别如表5-3、表5-4和表5-5所列。 | 端口 | 映射接口 | 说明 |
类型 | 名称 | 类型 | 映射接口名 |
|
1 | RPort | C_RP_Mw_objectLevel | S/R | hld_Mw_objectLevel | 座椅目标高度 |
2 | RPort | C_RP_Mw_currentLevel | S/R | hld_Mw_currentLevel | 座椅当前高度 |
3 | RPort | C_RP_Mb_level_quality | S/R | hld_Mb_level_quality | 质量信号 |
4 | RPort | C_RP_Msw_precision_upper | S/R | hld_Msw_precision_upper | 正向精度值 |
5 | RPort | C_RP_Msw_precision_lower | S/R | hld_Msw_precision_lower | 负向精度值 |
6 | RPort | C_RP_Mbl_enable | S/R | hld_Mbl_enable | 算法控制使能标志 |
7 | PPort | C_PP_Mb_Control_status | S/R | hld_Mb_Control_status | 进气阀和排气阀状态 |
8 | PPort | C_PP_Mbl_is_Control_Over | S/R | hld_Mbl_is_Control_Over | 控制算法调节完毕标志 |
5.4.3 添加运行实体
运行实体即在SWC中执行的函数。控制软件组件、算法输入软件组件和算法执行软件组件须添加的运行实体分别如表5-6、表5-7和表5-8所列。 | 运行实体名 | 函数名 | 功用 |
1 | Controller_initialize | Controller_initialize | 控制模块初始化 |
2 | Controller_step | Controller_step | 控制模块执行步骤 |
| 运行实体名 | 函数名 | 功用 |
1 | AlgorithmInput | AlgorithmInput | |
| 运行实体名 | 函数名 | 功用 |
1 | AlgorithmOutput | AlgorithmOutput | |
5.4.4 添加运行实体与所属软件组件的端口访问
本步的目的是添加与SWC中每个运行实体相关的端口，可以简单的理解为添加某个函数（即运行实体）需要用到的变量（即端口）。这里将控制软件组件、算法输入软件组件和算法执行软件组件中的全部端口分别添加到Controller_step、AlgorithmInput和AlgorithmOutput运行实体中。图5-13为添加运行实体与所属软件组件端口访问的方法。图5-13: 添加运行实体与所属软件组件的端口访问
5.4.5 添加运行实体的RTE事件
将Controller_step、AlgorithmInput和AlgorithmOutput运行实体均配置为“周期性事件”，周期0.02s。 5.5 软件组件添加
前面创建了3个软件组件及其内部行为，这里将这些SWC与座椅控制器相关联。5.5.1 将软件组件加入部件
如果把软件组件比作程序的“积木”，“部件”就相当于“积木箱”，图5-15和图5-16为将SWC加入部件的步骤。5.5.2 将软件组件映射到座椅控制器
将前面创建的3个SWC映射到座椅ECAS控制器软件中，如图5-17所示。 5.6 信号连接
由于座椅ECAS控制器仅涉及到3个SWC间信号的传递，故只需要连接“内部信号”即可，如图5-18和图5-19所示。 5.7 运行实体调度
将AlgorithmInput、Controller_step和AlgorithmOutput添加到操作系统20ms周期性执行的任务中，注意次序不要弄反。5.8 代码生成
接下来就是生成代码了，分为软件组件抽取、RTE代码生成和SWC代码生成3个步骤。5.8.1 软件组件抽取
“抽取”的含义就是将属于座椅ECAS控制器软件的3个SWC拿过来用，如图5-20所示（上节的运行实体调度操作应在抽取之后完成）。5.8.2 RTE代码生成
5.8.3 SWC代码生成
座椅ECAS控制器软件仅需按照图5-22和图5-23所示生成算法输入软件组件和算法执行软件组件的代码，控制软件组件在simulink环境下建模完成，只需提交Controller_SWC.arxml给应用层就可以了。5.9 代码添加
最后我们看看用AUTOSAR工具链自动生成的代码是什么样子的，图5-24和图5-25分别为算法输入软件组件和算法执行软件组件的代码截图。 5.10 事项说明
下面针对一些未明确事项进行说明。
5.10.1 系统信号连接
座椅ECAS控制器软件没有涉及到系统信号，但对于大部分车载ECU来说，与车载CAN网络的交互（从CAN网络接收数据和向CAN网络发送数据）是必不可少的，此时可参照图5-26的方法进行系统信号连接。
5.10.2 控制软件组件初始化函数调用
细心的读者可能会注意到，在工具链实现RTE的过程中，并没有涉及算法模块初始化函数Controller_initialize的调用。因为这涉及到AUTOSAR的一个重要的BSW模块 - EcuM的使用，我们留待下篇再讲，可以期待一下。6 结论
综上可以看出，单就RTE实现而言，AUTOSAR工具链方式要比传统手工编程方式复杂，但也体现出了如下优点：软件组件独立，功能划分明确；使用标准化接口设计运行时环境，模块独立开发便于项目组成员协同工作。特别是在大型车载ECU软件中，使用AUTOSAR工具链方式可以极大的保证软件质量、缩短开发周期。聊聊自动驾驶应用层软件开发
一文搞懂CAN收发器TJA1145
车载抬头显示系统(HUD)历史及发展
车身控制器功能规范
小鹏P7的热管理系统详解
大众ID4.X内部ECU技术细节整理
比亚迪海豹整车技术整理
揭秘理想的整车电子电气架构
国内主机整车EEA架构汇总
谈谈Bootloader自更新
谈谈对两家AUTOSAR工具看法
汽车软件需求是如何变成用户功能？
汽车E/E架构的网络安全分析
电子电气架构设计需要考虑哪些方面？
分享不易，恳请点个【👍】和【在看】
