基于MATLAB的AUTOSAR自动代码生成技术

张丽萍,国云飞

(辽宁工业大学汽车与交通工程学院，辽宁锦州 121001)



基于MATLAB的AUTOSAR自动代码生成技术

张丽萍,国云飞

(辽宁工业大学汽车与交通工程学院，辽宁锦州 121001)

在系统介绍汽车开放系统架构AUTOSAR体系结构的基础之上，以汽车大灯控制模块的嵌入式软件应用层开发为实例，描述了符合AUTOSAR架构标准的控制系统嵌入式软件应用层的开发流程，以MATLAB/Simulink软件为起点，叙述了从建模仿真到代码生成的过程，为开发符合AUTOSAR标准框架的汽车电子控制系统的标准化软件、规范ECU的内部软件及其相应的接口提供了有力的实证。

AUTOSAR；MATLAB/Simulink；自动代码生成技术

0 引言

随着汽车电子技术的飞速发展，现代汽车厂商正面临着整车功能需求不断增长和汽车的电控系统变得越来越复杂的挑战。各汽车生产厂商和各种汽车零部件供应商对自己的产品有各自的解决方案，使得车辆软件及硬件系统的不可移植性和应用软件的复杂程度成为汽车电子电气架构的重要问题[1]。为解决问题，可进行统一性管理，加强不同汽车生产厂商之间不同软硬件的相互兼容性，提高效率，降低开发成本。由全球汽车生产厂商、各种零部件供应商以及一些半导体和软件开发公司联合推出的汽车开放性软件系统架构标准AUTOSAR(Automotive Open System Architecture)，目的是为了建立标准化的开放性汽车嵌入软件架构。 日前，开发符合AUTOSAR标准框架的汽车控制系统的标准化软件、标准化ECU的内部软件以及对应的软件接口，简化ECU开发的流程，并使得软件具有可移植性，实现车辆电控系统的软件和硬件通用功能模块的标准化，缩短汽车的研发周期，从而降低生产开发成本，提高效率以及市场竞争力和企业经济效益[2]。

作者在系统介绍汽车开放式系统框架AUTOSAR的基础上，以汽车大灯控制模块开发为实例，主要对大灯控制模块嵌入式软件应用层进行开发，开发的起点有两种：一种是从已有的MATLAB/Simulink模型起步；另一种是从包含AUTOSAR组件的描述文件ARMLXL文件起步。具体介绍了从MATLAB/Simulink映射到AUTOSAR的流程，并描述了如何进行系统配置和生成代码文件。

1 AUTOSAR系统

汽车开放式系统架构AUTOSAR分为应用层(Application Layer)、RTE层(运行环境)、基础软件层(Basic Software Layer)和微控器抽象层 (Microcontroller)4层，如图1所示。

图1 AUTOSAR软件结构

其中基础软件层(BSW)又包含4个层：服务层(Service)、ECU抽象层(ECU Abstraction)、微控制器抽象层(Microcontroller Abstraction)和复杂驱动模块(Complex Drivers)。每一层的BSW中，分别含有不同的功能模块。例如Service层包括系统服务、内存服务、通信服务。

在AUTOSAR框架中，应用层的软件是由一系列相互交互的软件组件构成的。在以AUTOSAR为基础的汽车上层应用软件设计流程中，软件组件开发是全部开发应用软件的核心，其他软件设计开发工作比如配置和映射等，都是以软件组件为中心展开的[3]。

软件组件SWC是Software Component的英文缩写，在AUTOSAR中具有非常重要的地位。软件组件封装了几乎全部汽车电子功能的模块。软件组件主要是具体实现功能以及对相应功能的描述。软件组件之间通过虚拟功能总线进行交互，构成一个完整的AUTOSAR应用软件。

虚拟功能总线(Virtual Function Bus，VFB)是AUTOSAR中相对重要概念。VFB描述AUTOSAR所有通信机制，对其进行抽象，也是每个软件组件之间进行信息交互的桥梁。虚拟功能总线具体有以下功能：(1)可以抽象地描述软件组件之间的通信细节，软件组件可以通过AUTOSAR接口的定义对通信进行描述，即尽可能最大限度地独立于具体的通信体制，完成软件组件和硬件的通信。(2)对于应用软件的开发者来说，不管软件组件使用的是ECU与ECU之间的外部通信还是单独ECU的内部通信，没有本质区别。系统配置阶段完成之后，将各软件组件分配到各个相应的ECU之后，内部和外部通信的区别才得以表现出来。在这种情况下，虚拟功能总线的通信可以由实时运行环境(RTE)和基础软件(BSW)来实现。所以可以这样理解，在VBF的作用下，无需关注应用层软件的各个软件组件通信区别，因此能独立地设计开发软件组件，而且可以独立于具体的ECU进行设计开发[4]。

不同软件组件之间或者软件组件与硬件之间通过端口(Port)来实现通信和交互，所以各个软件组件都应预先定义端口[5]。端口具体描述软件组件间通信内容及其应用。一般端口有两类：一类是供型端口(P-Port)，用于对其他组件提供数据信息或者服务操作；一类是需型端口(R-Port)，用来从其他软件组件获得数据信息或者所请求服务操作。例如两个软件组件直接通信的实现，可以将一个软件组件的P-Port请求型端口与另外一个软件组件的服务型端口连接起来，如图 2所示。

图2 基于软件组件的VFB通信

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

表1 端口接口的类型

发送/接收(S/R)接口定义了全部在虚拟功能总线上进行接收和发送的数据元素和类型。例如图 2中的ISignalPeriod所示的接口，一个命名为duration、类型为UINT16位整数的数据元素。S/R端口作用是发送或接收数据，可以用RTE_IWrite_pinvalue()和RTE_IRead_pinvalue()来实现,主要是用于端口数据的读写,两个函数为库函数。

客户端/服务器(C/S)接口用来定义全部的操作，由对应供型端口所在的软件组件来具体实现这一系列的操作，而且能被包含供型接口的需型端口所在的软件组件调用。例如图2中的ILeverPos所示，一个命名为getAngle、有一个输出类型为INT12位整数参数的操作。参数可以任意命名。C/S用于实现调用和服务。例如可以用库函数实现：

Rte_Call_Tester_Calculator_Multiply()

Std_ReturnTypeRte_Call_Tester_Calculator_Multiply(constUInt8 arg1,

constUInt8 arg2, UInt16* result) {

return Rte_Multiply(arg1, arg2, result);

}

在定义时，每个端口只能定义一种接口类型，在应用时通信只能在相同的接口类型或者兼容接口类型的端口之间相互进行。

软件组件的对外表现形式为端口以及与其对应的端口接口类型。软件组件中的运行实体还有一些内部行为。

运行实体(Runable Entity)是体现软件组件的具体运用功能的。运行实体是软件组件中可执行程序单元。运行实体是软件组件中的一些序列指令，一个或者多个运行实体表现出了软件组件对外提供的功能。每个运行实体都绑定一个RTE事件(RTEEvent)。绑定事件发生时，对应运行实体就会被触发运行。

例如例程中的StepTask函数属于定时触发的函数,其程序实现如下所示：

voidStepTask(void) {

EventMaskType eventMask = 0;

while (1) {

WaitEvent(EVENT_MASK_StepEvent);

GetResource(RES_SCHEDULER);

GetEvent(TASK_ID_StepTask, &eventMask);

ClearEvent(EVENT_MASK_StepEvent);

ReleaseResource(RES_SCHEDULER);

if (eventMask & EVENT_MASK_StepEvent) {

Rte_TesterRunnable();

}

}

}

其中Rte_TesterRunnable是一个运行实体。Rte_TesterRunnable包含3个运行实体，分别实现不同的功能：Rte_PRE_TesterRunnable()实现读取端口数据的功能，TesterRunnable()实现将读取的端口数据调用乘法操作的功能，Rte_POST_TesterRunnable()实现将相乘的结果发送出去的功能。

在AUTOSAR的操作系统中，运行实体将会运行在操作系统任务的上下文中。完成任务需要给运行实体提供必要的资源。运行实体自身的功能是通过具体的操作或者访问端口的数据来完成的，并且把数据处理后的结果以及提供的操作服务通过端口对外提供。由于端口上的通信机制是经过虚拟功能总线抽象过的，所以在运行实体的运行中，使用RTE提供的API函数来访问端口数据或操作服务。这样，运行实体的运行实现就独立于工作平台，因而软件组件的设计也是与开发平台无关的，因此软件组件的可移植性和可重用性得到加强。运行实体的运行实现有两种形式：可以通过建模工具比如MATLAB进行设计建模并自动生成代码，也可以手工编写代码[6]。

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

综上所述，在AUTOSAR架构中的软件组件使用如图3所示的示例图来表示。

图3 AUTOSAR软件组件示例

2 MATLAB/Simulink到AUTOSAR的映射

目前，MATLAB/Simulink软件因扩展性能好、描述能力强、能够很好地贯通到整个开发到生产的研发过程中，成为汽车电控软件研发比较重要的开发工具之一。MATLAB/Simulink 具有的自动代码生成技术大大提高了软件的开发效率和质量，从而减轻了软件开发人员的工作量。MATLAB/Simulink从2006a版本开始已经可以实现与AUTOSAR兼容的MATLAB/Simulink 自动代码生成的功能。

根据AUTOSAR开发流程的介绍，MATLAB/Simulink在全部应用软件设计开发过程中的任务是建立功能模型并生成应用软件代码和模型描述性文件。MATLAB/Simulink之所以能生成与AUTOSAR标准兼容的代码，主要是因为MATLAB/Simulink模型元素与AUTOSAR元素之间存在对应的映射关系，如表2所示。

表2 MATLAB/Simulink元素与AUTOSAR元素的映射关系

另外，MATLAB/Simulink软件在代码生成阶段的同时也会生成文件格式为.arxml的软件组件的描述性文件，可以为下一步的系统配置做前期的准备。这样就能保证不需要增加多余的模块的可运行实体。因为每个软件组件都有特定功能，因此，AUTOSAR软件组件有时也被称为原子，它不能再分，一个软件组件不能被分割配置到不同的电子控制单元中。在AUTOSAR中，每个软件组件可有一个或多个可运行的实体。

3 以MATLAB/Simulink为起点的AUTOSAR软件开发流程

文中以汽车大灯控制模块嵌入式软件应用层的开发为实例，开发的起点有两种：一种是从已有的Simulink模型起步，另一种是从包含AUTOSAR组件的描述文件ARMLXL起步。

3.1 基于MATLAB/Simulink进行行为建模

依据AUTOSAR的建模规范，使用MATLAB中的Simulink与Stateflow模块建立了汽车大灯控制模块模型，如图4所示。

图4 汽车大灯控制模型

有限状态机的图形工具Stateflow用于解决复杂的逻辑状态问题，可以通过图形化工具实现在不同状态之间的转换。Stateflow可以直接嵌入到Simulink模型中，并且在进行仿真的初始化阶段，Simulink会通过内部代码生成功能把Stateflow绘制的逻辑图通过内部编译语音转换成C语言程序。

如图4所示，用Stateflow做了一个选择模块、一个汽车近光控制模块、一个汽车远光控制模块, 即用图形化的方式完成控制系统的内部逻辑。选择模块连接的是灯光控制系统的模块，由两个子系统构成。如图5所示， 为近光控制子系统，为远光控制子系统。

图5 汽车大灯内部子系统

3.2 自动代码的生成

在完成汽车大灯控制建模工作后，为了生成与AUTOSAR兼容的程序代码，需要进行如下的系统配置：先配置系统目标文件。在Simulink菜单中依次在Simulation/Configuration Parameters菜单/Real-Time Workshop/System Target File对话框中选择Autosar.tlc文件。文件类型为.tlc、英文全称为Target Language Compliler(目标语言编译器)，用它来控制模型的生成代码的类型。 这个文件存放在MATLAB系统根目录下：MATLAB安装目录Toolbox tw argetsAUTOSARAUTOSAR。

图6 接口及类型配置窗口

接下来需要进行应用软件组件的接口配置。 代码类型选择如图6所示，选择AUTOSAR目标文件TLC。启动AUTOSAR配置：code-c/c++ code-Configure Model as AUTOSAR Component。

接下来就要应用Simulink-AUTOSAR映射编辑器，在Simulink Mapping Wiew中执行Simulink到AUTOSAR的映射，如图7所示。

图7 配置Simulink到AUTOSAR的映射窗口

映射输入端口到AUTOSAR的Sender Ports如图8所示。这样就完成了Simulink输入输出映射到AUTOSAR的工作。

最后的工作是完成代码的生成，依次选择 Real-Time Work-shop→AUTOSAR Multi-Runnable Component Ex-port Functions，在配置窗口中点击“Build”， 或者按Ctrl+B,生成与AUTOSAR兼容的代码和.axml格式的描述性文件，如图9所示。当然，在生成代码时还可以选择进行SIL、PIL代码验证。

图8 输入输出映射到接受发送端口

图9 生成的代码文件

4 结束语

在遵循AUTOSAR软件开发流程的基础上，以开发汽车大灯控制模块应用软件为实例，讲述了以MATLAB/Simulink为起点的应用软件的开发流程，为开发符合AUTOSAR标准框架的汽车电子控制系统的标准化软件、规范ECU的内部软件及其相应的接口提供了有力的实证。

【1】童年,周三国.整车电气架构设计方法[J].上海汽车,2010(4):13-15,20.

【2】张威．Stateflow逻辑系统建模[M]．西安：西安电子科技大学出版社，2007．

【3】李震,刘敏.基于Autosar的整车电子电气架构设计方法[J].机电一体化,2012，18(11):73-76.

LI Z,LIU M.Electric & Electrical Architecture Developing Method Based on Autosar[J].Mechatronics,2012，18(11):73-76.

【4】NAVET N,SIMONOT-LION F.Automotive Embedded Systems Handbook[M].Boca Raton:CRC Press,2009.

【5】PRETSCHNER A,BROY M,KRUGER I H,et al.Software Engineering for Automotive Systems:A Roadmap[C]//Proceedings of FOSE’07 Future of Software Engineering.Piscataway[s.n.]，2007:66-82.

【6】冯江波,刘亚军.与AUTOSAR兼容的Matlab/Simulink自动代码生成技术[J].佳木斯大学学报(自然科学版),2011,29(6):833-837.

FENG J B,LIU Y J.Code Generation Technology with Matlab/Simulink Compliant with AUTOSAR[J].Journal of Jiamusi University(Natural Science Edition),2011,29(6):833-837.

英飞凌携手天津大学助力卡车满足未来排放和安全标准

“天津大学-英飞凌汽车电子联合实验室”推出了柴油机管理系统开发平台(DEMS-DK)。DEMS-DK是基于英飞凌32位多核微处理器Aurix共同开发的针对柴油机市场的解决方案。该解决方案将为亚太市场的系统供应商和卡车制造商(OEM)提供参考方案，助力柴油机市场电子控制单元的本地研发，帮助客户快速开发出满足未来排放和安全标准的柴油机管理系统。

预计从2016年开始，全球重型卡车(6 t以上的卡车)市场将持续增长。据市场研究公司LMC Automotive预计，2020年全球重型卡车市场的年销量将突破350万台, 亚太市场将突破200万台。这给汽车电子企业带来了机遇，但挑战也随之而来——譬如各个国家和地区对车辆排放法规的要求日趋严格。为满足这些要求，系统设计者需要考虑在实现基本功能的同时满足排放和安全要求，这使得系统日益复杂，发动机控制等复杂应用要求微处理器运算速度更快、更安全、更可靠。因此，采用多核微处理器的汽车电子应用为重型卡车带来了福音，成为全球范围内势在必行的趋势。

Aurix是英飞凌为满足未来汽车电子控制需求而推出的新一代32位MCU产品家族，同时也满足ISO 26262 ASIL-D功能安全要求。英飞凌Aurix系列TC275T三核微处理器片内集成高达4M Byte Flash和GTM等特色模块，工作频率可达200 MHz，专注于满足未来动力总成控制系统对高性能的需求。

柴油机管理系统开发平台简化版(DEMS-DK lite)是精简套件，包括DEMS-DK控制器、优盘、此方案采用的半导体器件的技术文档及控制器原理图、使用手册、测试报告等。精简套件可以为有计划采用Aurix进行柴油机控制器开发的客户提供参考，并在短时间内完成开发项目。

柴油机管理系统开发平台(DEMS-DK Kit)是完整版套件，除了包括精简套件中的内容，还提供了发动机台架实验所需的线束(含接插件)，壳体及简易硬件测试板, 可以在硬件电路出现问题的情况下，进行简易的诊断，判断控制器故障。完整版套件针对希望可以快速进行台架实验，并有计划进行自主开发的客户。

(来源：英飞凌科技股份公司)

AUTOSAR Automatic Code Generation Technology Based on MATLAB

ZHANG Liping,GUO Yunfei

(College of Automobile & Traffic Engineering, Liaoning University of Technology, Jinzhou Liaoning 121001, China)

The AUTOSAR (automotive open system architecture) was introduced. Taking the embedded software application layer development for an automotive headlight control module as an example, the embedded software application layer development process of the control system accorded with the AUTOSAR standard was described. Using the MATLAB/Simulink software as a starting point, the process from modeling, simulation to code generation was illustrated. In order to develop standardization software for automotive electronic control system accorded with AUTOSAR standard framework, to specify the internal software and corresponding interfaces of ECU, it provides strong empirical evidence.

AUTOSAR; MATLAB/Simulink; Automatic code generation technology

2016-06-09

辽宁省博士启动基金资助项目(20141130)；高校杰出青年学者成长计划资助项目(LJQ2014065)

张丽萍(1975—)，女，博士，副教授，主要研究方向为车辆系统动力学及控制。E-mail:785847517@qq.com。

10.19466/j.cnki.1674-1986.2016.09.008

U461.4

B

1674-1986(2016)09-036-05