汽车电控系统代码自动生成技术的功能实现

冯吉涛

(烟台汽车工程职业学院 车辆运用工程系， 烟台 265500)

0 引言

随着人们对汽车性能要求的不断提高，汽车电控技术逐渐发展起来，为解决传统封闭式汽车电控系统结构所带来的问题，正逐步展开开放式汽车电控系统的研究，汽车电控系统为满足不断增加的需求复杂程度越来越高，针对特定问题不同制造商提供的解决方案也不尽相同，软硬件系统难以兼容问题凸显，为改善E/E复杂性管理问题，增强可移植性、可扩展性，成为研究的重点。

1 电控系统开发流程

汽车开放系统架构标准 ( AUTOSAR)包括架构、方法学(在对软件架构信息进行描述时采用标准化的数据交换格式)和应用接口，由制造商、供应商及工具开发商联合开发，为车辆系统提供了通用软件架构(基于标准接口)。由SWC组成应用层，采用虚拟功能总线(VFB，由RTE和BSW共同完成)实现SWC的独立性，SWC间及其同底层的通信则通过RTE完成(通过提供一致的接口和服务)，底层细节的屏蔽及SWC服务的提供由BSW负责。

结合Matlab并以AUTOSAR方法学的开发流程为依据，需先完成系统级设计(在Authoring Tool中)，再通过在Matlab/Simulink中导入系统描述文件完成SWC的提取，Runnable(SWC中)的设计则采用Stateflow完成，代码生成后将SWC描述文件导出，在Authoring Tool中重新导入SWC描述文件，Runnable到BSW任务中的映射在RTE中完成，对Runnable进行设计，并设置BSW各模块(通过Authoring Tool完成)，实现底层驱动代码的生成，在此基础上对代码进行融合，电控系统的具体开发流程如图1所示[1]。

2 电控系统代码自动生成技术的生成

2.1 车灯系统SWC设计

本文主要以以汽车车灯控制系统为例，对汽车电控系统代码自动生成技术的功能实现进行研究，车灯系统主要包括信号和照明灯，将车灯系统分为5个SWC(根据功能划分)具体如表1所示。

其中转向灯通过CAN调试终端完成参数的发送、报文的修改(包括跳转频率和最小跳转次数)及车门状态信息(四个车门的状态由报文第1字节低4位分别表示)的查看。分配完SWC功能后，完成SWC、接口和数据类型的建立(在ORIENTAIS中)，本文不设计SWC Behavior(SWC的行为无法被Simulink读取)，最后再导出系统描述文件[2]。

图1 电控系统开发流程

SWCRunnable 功能描述Beam Lamp Control Beam Lamp Runnable近/远光控制Turn Lamp ControlTurn Lamp Runnable Get Cal Data Runnable转向灯控制参数设置Fog Lamp Control Fog Lamp Runnable雾灯控制Interior Lamp Control Interior Lamp Runnable内灯控制State Display State Display Runnable状态显示

2.2 Runnable代码生成

由于在概念上Simulink同 AUTOSAR具备较多的相通性，而得以在AUTOSAR开发过程中应用，在AUTOSAR设计流程中，模型的逻辑功能的建立及模型逻辑功能正确性的仿真验证主均需由Simulink负责完成，在汽车电控系统的设计过程中二者的对应关系(常用术语)，如表2所示。

表2 常用术语对应关系

各SWC在将SWC封装到部件的情况下则只能用虚拟子系统表示，SWC在Simulink模型中在配置SWC端口为服务器操作的情况下只能用模型表示[3]。

(1)在Simulink中运行实体Runnable的实现

本文以转向灯应用组件为例，介绍SWC逻辑功能的实现细节(在Simulink中)，在Simulink中导入系统描述文件(由ORIENTAIS生成)后，需对应用组件SWC端口做出相应的修改，具体的层次化实现结构如图2所示。转向灯应用组件的内部实现细节会对外屏蔽，输入口和输出口的预留个数分别为7个、3个，各SWC的首个端口均需预留给RTE触发事件，运行时的环境(RTE)触发事件控制信号连接其中前2个输入口，内部包含的2个由状态图实现的Runnable公用两个输入端口信号(GetMincycle和GetFlashFrm)，转向灯逻辑状态如图2所示。

图2 SWC的层次化实现结构

(2)Simulink仿真

在设计好SWC逻辑功能的基础上，需在部件(composition)中封装5个SWC，封装组件系统结构的提供由Composition负责，SWC和VFB间的通信不受影响，各Runnable RTE触发事件的提供由Function Call Generator和Event Chart共同负责，各Runnable的RTE触发事件相互独立，同一Runnable禁止不同的 Runnable共用；实际环境的模拟则由Simulation Environment负责完成，信号输入由其为车灯控制系统(各个车灯皆由开关控制)提供，同时输出信号通过使用示波器观察，采用脉冲发生器(周期为50 s、占空比为20%)代替开关，以便实现对输出信号随输入信号变化情况的较为直观的观察，修改转向灯闪烁频率(通过CAN调试终端)采用以[3 1 4 2 1]为矢量输出值的任意信号发生器(采样周期为40 s)表示，仿真结果如图3所示，观察转向灯状态输出波形可知，其疏密度随着闪烁频率数值的更改而发生了变化，证明转向灯闪烁频率已改变。

图3 仿真结果

(3)应用代码自动生成

自动生成应用层代码通过使用Matlab/Embedded Coder(作为Matlab和Simulink 的功能补充主要负责为目标系统创建C 代码)工具完成，选择系统目标代码文件为 autosar.tlc以确保为生成的代码与AUTOSAR兼容，汽车车灯控制系统应用代码的生成通过Embedded Coder工具完成，生成的文件主要包括system.arxml(对内部行为特征、SWC的接口、数据类型进行描述)，system.c(主要由模型代码、模型初始化及终止操作代码等构成)、system.h(负责模型函数的外部声明，由模型输入、模型数据结构与全局接口等构成)。

(4)底层驱动代码生成

BSW各模块的配置(同SWC设计同步进行但相互分离)过程：先对同底层通信的信号进行处理，为其分配相应的引脚，接下来在ORIENTAIS 中对各模块(包括 I/O，COM，OS，数据链路层，CAN总线及接口，硬件抽象层等)进行配置，在模块完成配置的基础上实现相应配置代码的生成。

2.3 底层与应用层代码整合

系统级设计SWC时只预留了通信接口(不显示内部具体行为)，需在ORIENTAIS中导入system.arxml(Embedded Coder的导出文件)完成内部行为信息的提取，应用层SWC 间及其与BSW间的通信通过RTE实现，按照具体功能优先原则完成Runnable到操作系统任务的映射，具体的映射关系如表3所示。

表3 映射关系表

模块的完全初始化通过InitTask完成，对MainFuncTask进行周期性的调度实现通信功能(设定周期要求短)，Runnable(与CAN通信)信息对进行不断读取和发送，应用层的SWC通过配置完RTE生成的代码对下层的基础软件进行了封装，并通过OS、COM 等下层基础软件功能的应用完成同上层SWC组件间通信及周期控制，逻辑代码同底层代码最终通过RTE的使用实现无缝连接。

3 实验检测

为检测本文汽车灯控系统自动生成代码的准确性，在试验控制箱中进行了实验，通过对车灯开关进行随机控制，同时对转向灯Flash-Frm(闪烁频率参数)的更改通CAN调试终端完成， f( f=Flash Frm×2×0. 3 s)表示程序中转向灯闪烁频率，具体的实验结果如图4所示。

图4 实验结果

由图4可知在改变闪烁频率的过程中(从1.8 s到0.6 s再到2.4s)，转向灯状态疏密变化明显，符合肉眼观察到的情况，证明了代码的准确性和可用性，使组件的复用性和软件兼容性得以有效提升，有助于提高不同生产商间产品的互通性。

4 总结

本文主要研究了汽车电控系统代码自动生成技术的开发流程，以汽车车灯控制系统为例，应用ORIENTAIS工具对基础软件和运行环境等进行配置，实现底层驱动和实时交互层代码的生成，应用软件组件的运行实体及应用层逻辑功能则通过Simulink完成开发，运行实体内部逻辑的设计通过运用Stateflow完成，并完成了仿真模型的建立，逻辑层代码采用Em-bedder Coder生成同底层驱动代码、实时交互及逻辑层代码进行融合，实现代码的无缝连接，进行汽车试验控制箱实验，证明了代码的准确性和可用性，使组件的复用性和软件兼容性得以有效提升，有助于缩短了产品开发周期，提高不同生产商间产品的互通性。