基于MATLAB的AUTOSAR自動代碼生成技術

張麗萍,國云飛

(遼寧工業(yè)大學汽車與交通工程學院，遼寧錦州 121001)

?

基于MATLAB的AUTOSAR自動代碼生成技術

張麗萍,國云飛

(遼寧工業(yè)大學汽車與交通工程學院，遼寧錦州 121001)

在系統(tǒng)介紹汽車開放系統(tǒng)架構AUTOSAR體系結構的基礎之上，以汽車大燈控制模塊的嵌入式軟件應用層開發(fā)為實例，描述了符合AUTOSAR架構標準的控制系統(tǒng)嵌入式軟件應用層的開發(fā)流程，以MATLAB/Simulink軟件為起點，敘述了從建模仿真到代碼生成的過程，為開發(fā)符合AUTOSAR標準框架的汽車電子控制系統(tǒng)的標準化軟件、規(guī)范ECU的內部軟件及其相應的接口提供了有力的實證。

AUTOSAR；MATLAB/Simulink；自動代碼生成技術

0 引言

隨著汽車電子技術的飛速發(fā)展，現(xiàn)代汽車廠商正面臨著整車功能需求不斷增長和汽車的電控系統(tǒng)變得越來越復雜的挑戰(zhàn)。各汽車生產(chǎn)廠商和各種汽車零部件供應商對自己的產(chǎn)品有各自的解決方案，使得車輛軟件及硬件系統(tǒng)的不可移植性和應用軟件的復雜程度成為汽車電子電氣架構的重要問題[1]。為解決問題，可進行統(tǒng)一性管理，加強不同汽車生產(chǎn)廠商之間不同軟硬件的相互兼容性，提高效率，降低開發(fā)成本。由全球汽車生產(chǎn)廠商、各種零部件供應商以及一些半導體和軟件開發(fā)公司聯(lián)合推出的汽車開放性軟件系統(tǒng)架構標準AUTOSAR(Automotive Open System Architecture)，目的是為了建立標準化的開放性汽車嵌入軟件架構。 日前，開發(fā)符合AUTOSAR標準框架的汽車控制系統(tǒng)的標準化軟件、標準化ECU的內部軟件以及對應的軟件接口，簡化ECU開發(fā)的流程，并使得軟件具有可移植性，實現(xiàn)車輛電控系統(tǒng)的軟件和硬件通用功能模塊的標準化，縮短汽車的研發(fā)周期，從而降低生產(chǎn)開發(fā)成本，提高效率以及市場競爭力和企業(yè)經(jīng)濟效益[2]。

作者在系統(tǒng)介紹汽車開放式系統(tǒng)框架AUTOSAR的基礎上，以汽車大燈控制模塊開發(fā)為實例，主要對大燈控制模塊嵌入式軟件應用層進行開發(fā)，開發(fā)的起點有兩種：一種是從已有的MATLAB/Simulink模型起步；另一種是從包含AUTOSAR組件的描述文件ARMLXL文件起步。具體介紹了從MATLAB/Simulink映射到AUTOSAR的流程，并描述了如何進行系統(tǒng)配置和生成代碼文件。

1 AUTOSAR系統(tǒng)

汽車開放式系統(tǒng)架構AUTOSAR分為應用層(Application Layer)、RTE層(運行環(huán)境)、基礎軟件層(Basic Software Layer)和微控器抽象層 (Microcontroller)4層，如圖1所示。

圖1 AUTOSAR軟件結構

其中基礎軟件層(BSW)又包含4個層：服務層(Service)、ECU抽象層(ECU Abstraction)、微控制器抽象層(Microcontroller Abstraction)和復雜驅動模塊(Complex Drivers)。每一層的BSW中，分別含有不同的功能模塊。例如Service層包括系統(tǒng)服務、內存服務、通信服務。

在AUTOSAR框架中，應用層的軟件是由一系列相互交互的軟件組件構成的。在以AUTOSAR為基礎的汽車上層應用軟件設計流程中，軟件組件開發(fā)是全部開發(fā)應用軟件的核心，其他軟件設計開發(fā)工作比如配置和映射等，都是以軟件組件為中心展開的[3]。

軟件組件SWC是Software Component的英文縮寫，在AUTOSAR中具有非常重要的地位。軟件組件封裝了幾乎全部汽車電子功能的模塊。軟件組件主要是具體實現(xiàn)功能以及對相應功能的描述。軟件組件之間通過虛擬功能總線進行交互，構成一個完整的AUTOSAR應用軟件。

虛擬功能總線(Virtual Function Bus，VFB)是AUTOSAR中相對重要概念。VFB描述AUTOSAR所有通信機制，對其進行抽象，也是每個軟件組件之間進行信息交互的橋梁。虛擬功能總線具體有以下功能：(1)可以抽象地描述軟件組件之間的通信細節(jié)，軟件組件可以通過AUTOSAR接口的定義對通信進行描述，即盡可能最大限度地獨立于具體的通信體制，完成軟件組件和硬件的通信。(2)對于應用軟件的開發(fā)者來說，不管軟件組件使用的是ECU與ECU之間的外部通信還是單獨ECU的內部通信，沒有本質區(qū)別。系統(tǒng)配置階段完成之后，將各軟件組件分配到各個相應的ECU之后，內部和外部通信的區(qū)別才得以表現(xiàn)出來。在這種情況下，虛擬功能總線的通信可以由實時運行環(huán)境(RTE)和基礎軟件(BSW)來實現(xiàn)。所以可以這樣理解，在VBF的作用下，無需關注應用層軟件的各個軟件組件通信區(qū)別，因此能獨立地設計開發(fā)軟件組件，而且可以獨立于具體的ECU進行設計開發(fā)[4]。

不同軟件組件之間或者軟件組件與硬件之間通過端口(Port)來實現(xiàn)通信和交互，所以各個軟件組件都應預先定義端口[5]。端口具體描述軟件組件間通信內容及其應用。一般端口有兩類：一類是供型端口(P-Port)，用于對其他組件提供數(shù)據(jù)信息或者服務操作；一類是需型端口(R-Port)，用來從其他軟件組件獲得數(shù)據(jù)信息或者所請求服務操作。例如兩個軟件組件直接通信的實現(xiàn)，可以將一個軟件組件的P-Port請求型端口與另外一個軟件組件的服務型端口連接起來，如圖 2所示。

圖2 基于軟件組件的VFB通信

雖然每個AUTOSAR端口都定義了軟件組件之間通信方向和內容，但是不知道具體通信的內容以及用于交互的操作服務。端口之間的供需關系是用AUTOSAR中的端口接口(Port-Interface)來描述的。AUTOSAR端口接口有3種形式：分別為客戶端/服務器接口(Client-Server Interface，C-S)、發(fā)送者/接收者接口(Sender-Receiver Interface，S-R)和標定接口(Calibration Interface)，具體的描述如表 1所示。

表1 端口接口的類型

發(fā)送/接收(S/R)接口定義了全部在虛擬功能總線上進行接收和發(fā)送的數(shù)據(jù)元素和類型。例如圖 2中的ISignalPeriod所示的接口，一個命名為duration、類型為UINT16位整數(shù)的數(shù)據(jù)元素。S/R端口作用是發(fā)送或接收數(shù)據(jù)，可以用RTE_IWrite_pinvalue()和RTE_IRead_pinvalue()來實現(xiàn),主要是用于端口數(shù)據(jù)的讀寫,兩個函數(shù)為庫函數(shù)。

客戶端/服務器(C/S)接口用來定義全部的操作，由對應供型端口所在的軟件組件來具體實現(xiàn)這一系列的操作，而且能被包含供型接口的需型端口所在的軟件組件調用。例如圖2中的ILeverPos所示，一個命名為getAngle、有一個輸出類型為INT12位整數(shù)參數(shù)的操作。參數(shù)可以任意命名。C/S用于實現(xiàn)調用和服務。例如可以用庫函數(shù)實現(xiàn)：

Rte_Call_Tester_Calculator_Multiply()

Std_ReturnTypeRte_Call_Tester_Calculator_Multiply(constUInt8 arg1,

constUInt8 arg2, UInt16* result) {

return Rte_Multiply(arg1, arg2, result);

}

在定義時，每個端口只能定義一種接口類型，在應用時通信只能在相同的接口類型或者兼容接口類型的端口之間相互進行。

軟件組件的對外表現(xiàn)形式為端口以及與其對應的端口接口類型。軟件組件中的運行實體還有一些內部行為。

運行實體(Runable Entity)是體現(xiàn)軟件組件的具體運用功能的。運行實體是軟件組件中可執(zhí)行程序單元。運行實體是軟件組件中的一些序列指令，一個或者多個運行實體表現(xiàn)出了軟件組件對外提供的功能。每個運行實體都綁定一個RTE事件(RTEEvent)。綁定事件發(fā)生時，對應運行實體就會被觸發(fā)運行。

例如例程中的StepTask函數(shù)屬于定時觸發(fā)的函數(shù),其程序實現(xiàn)如下所示：

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個運行實體，分別實現(xiàn)不同的功能：Rte_PRE_TesterRunnable()實現(xiàn)讀取端口數(shù)據(jù)的功能，TesterRunnable()實現(xiàn)將讀取的端口數(shù)據(jù)調用乘法操作的功能，Rte_POST_TesterRunnable()實現(xiàn)將相乘的結果發(fā)送出去的功能。

在AUTOSAR的操作系統(tǒng)中，運行實體將會運行在操作系統(tǒng)任務的上下文中。完成任務需要給運行實體提供必要的資源。運行實體自身的功能是通過具體的操作或者訪問端口的數(shù)據(jù)來完成的，并且把數(shù)據(jù)處理后的結果以及提供的操作服務通過端口對外提供。由于端口上的通信機制是經(jīng)過虛擬功能總線抽象過的，所以在運行實體的運行中，使用RTE提供的API函數(shù)來訪問端口數(shù)據(jù)或操作服務。這樣，運行實體的運行實現(xiàn)就獨立于工作平臺，因而軟件組件的設計也是與開發(fā)平臺無關的，因此軟件組件的可移植性和可重用性得到加強。運行實體的運行實現(xiàn)有兩種形式：可以通過建模工具比如MATLAB進行設計建模并自動生成代碼，也可以手工編寫代碼[6]。

前文所述，每個軟件組件必須提供具體實現(xiàn)的代碼以及描述文件。代碼運行實現(xiàn)即運行實體的實現(xiàn)，以C源文件或者目標文件的方式提供。而描述文件是描述軟件組件的屬性，包括所有的端口、端口接口、運行實體以及運行實體所對應的RTE事件等，以XML(eXtensible Markup Language)文件形式提供。

綜上所述，在AUTOSAR架構中的軟件組件使用如圖3所示的示例圖來表示。

圖3 AUTOSAR軟件組件示例

2 MATLAB/Simulink到AUTOSAR的映射

目前，MATLAB/Simulink軟件因擴展性能好、描述能力強、能夠很好地貫通到整個開發(fā)到生產(chǎn)的研發(fā)過程中，成為汽車電控軟件研發(fā)比較重要的開發(fā)工具之一。MATLAB/Simulink 具有的自動代碼生成技術大大提高了軟件的開發(fā)效率和質量，從而減輕了軟件開發(fā)人員的工作量。MATLAB/Simulink從2006a版本開始已經(jīng)可以實現(xiàn)與AUTOSAR兼容的MATLAB/Simulink 自動代碼生成的功能。

根據(jù)AUTOSAR開發(fā)流程的介紹，MATLAB/Simulink在全部應用軟件設計開發(fā)過程中的任務是建立功能模型并生成應用軟件代碼和模型描述性文件。MATLAB/Simulink之所以能生成與AUTOSAR標準兼容的代碼，主要是因為MATLAB/Simulink模型元素與AUTOSAR元素之間存在對應的映射關系，如表2所示。

表2 MATLAB/Simulink元素與AUTOSAR元素的映射關系

另外，MATLAB/Simulink軟件在代碼生成階段的同時也會生成文件格式為.arxml的軟件組件的描述性文件，可以為下一步的系統(tǒng)配置做前期的準備。這樣就能保證不需要增加多余的模塊的可運行實體。因為每個軟件組件都有特定功能，因此，AUTOSAR軟件組件有時也被稱為原子，它不能再分，一個軟件組件不能被分割配置到不同的電子控制單元中。在AUTOSAR中，每個軟件組件可有一個或多個可運行的實體。

3 以MATLAB/Simulink為起點的AUTOSAR軟件開發(fā)流程

文中以汽車大燈控制模塊嵌入式軟件應用層的開發(fā)為實例，開發(fā)的起點有兩種：一種是從已有的Simulink模型起步，另一種是從包含AUTOSAR組件的描述文件ARMLXL起步。

3.1 基于MATLAB/Simulink進行行為建模

依據(jù)AUTOSAR的建模規(guī)范，使用MATLAB中的Simulink與Stateflow模塊建立了汽車大燈控制模塊模型，如圖4所示。

圖4 汽車大燈控制模型

有限狀態(tài)機的圖形工具Stateflow用于解決復雜的邏輯狀態(tài)問題，可以通過圖形化工具實現(xiàn)在不同狀態(tài)之間的轉換。Stateflow可以直接嵌入到Simulink模型中，并且在進行仿真的初始化階段，Simulink會通過內部代碼生成功能把Stateflow繪制的邏輯圖通過內部編譯語音轉換成C語言程序。

如圖4所示，用Stateflow做了一個選擇模塊、一個汽車近光控制模塊、一個汽車遠光控制模塊, 即用圖形化的方式完成控制系統(tǒng)的內部邏輯。選擇模塊連接的是燈光控制系統(tǒng)的模塊，由兩個子系統(tǒng)構成。如圖5所示， 為近光控制子系統(tǒng)，為遠光控制子系統(tǒng)。

圖5 汽車大燈內部子系統(tǒng)

3.2 自動代碼的生成

在完成汽車大燈控制建模工作后，為了生成與AUTOSAR兼容的程序代碼，需要進行如下的系統(tǒng)配置：先配置系統(tǒng)目標文件。在Simulink菜單中依次在Simulation/Configuration Parameters菜單/Real-Time Workshop/System Target File對話框中選擇Autosar.tlc文件。文件類型為.tlc、英文全稱為Target Language Compliler(目標語言編譯器)，用它來控制模型的生成代碼的類型。 這個文件存放在MATLAB系統(tǒng)根目錄下：MATLAB安裝目錄Toolbox tw argetsAUTOSARAUTOSAR。

圖6 接口及類型配置窗口

接下來需要進行應用軟件組件的接口配置。 代碼類型選擇如圖6所示，選擇AUTOSAR目標文件TLC。啟動AUTOSAR配置：code-c/c++ code-Configure Model as AUTOSAR Component。

接下來就要應用Simulink-AUTOSAR映射編輯器，在Simulink Mapping Wiew中執(zhí)行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 輸入輸出映射到接受發(fā)送端口

圖9 生成的代碼文件

4 結束語

在遵循AUTOSAR軟件開發(fā)流程的基礎上，以開發(fā)汽車大燈控制模塊應用軟件為實例，講述了以MATLAB/Simulink為起點的應用軟件的開發(fā)流程，為開發(fā)符合AUTOSAR標準框架的汽車電子控制系統(tǒng)的標準化軟件、規(guī)范ECU的內部軟件及其相應的接口提供了有力的實證。

【1】童年,周三國.整車電氣架構設計方法[J].上海汽車,2010(4):13-15,20.

【2】張威．Stateflow邏輯系統(tǒng)建模[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.

英飛凌攜手天津大學助力卡車滿足未來排放和安全標準

“天津大學-英飛凌汽車電子聯(lián)合實驗室”推出了柴油機管理系統(tǒng)開發(fā)平臺(DEMS-DK)。DEMS-DK是基于英飛凌32位多核微處理器Aurix共同開發(fā)的針對柴油機市場的解決方案。該解決方案將為亞太市場的系統(tǒng)供應商和卡車制造商(OEM)提供參考方案，助力柴油機市場電子控制單元的本地研發(fā)，幫助客戶快速開發(fā)出滿足未來排放和安全標準的柴油機管理系統(tǒng)。

預計從2016年開始，全球重型卡車(6 t以上的卡車)市場將持續(xù)增長。據(jù)市場研究公司LMC Automotive預計，2020年全球重型卡車市場的年銷量將突破350萬臺, 亞太市場將突破200萬臺。這給汽車電子企業(yè)帶來了機遇，但挑戰(zhàn)也隨之而來——譬如各個國家和地區(qū)對車輛排放法規(guī)的要求日趨嚴格。為滿足這些要求，系統(tǒng)設計者需要考慮在實現(xiàn)基本功能的同時滿足排放和安全要求，這使得系統(tǒng)日益復雜，發(fā)動機控制等復雜應用要求微處理器運算速度更快、更安全、更可靠。因此，采用多核微處理器的汽車電子應用為重型卡車帶來了福音，成為全球范圍內勢在必行的趨勢。

Aurix是英飛凌為滿足未來汽車電子控制需求而推出的新一代32位MCU產(chǎn)品家族，同時也滿足ISO 26262 ASIL-D功能安全要求。英飛凌Aurix系列TC275T三核微處理器片內集成高達4M Byte Flash和GTM等特色模塊，工作頻率可達200 MHz，專注于滿足未來動力總成控制系統(tǒng)對高性能的需求。

柴油機管理系統(tǒng)開發(fā)平臺簡化版(DEMS-DK lite)是精簡套件，包括DEMS-DK控制器、優(yōu)盤、此方案采用的半導體器件的技術文檔及控制器原理圖、使用手冊、測試報告等。精簡套件可以為有計劃采用Aurix進行柴油機控制器開發(fā)的客戶提供參考，并在短時間內完成開發(fā)項目。

柴油機管理系統(tǒng)開發(fā)平臺(DEMS-DK Kit)是完整版套件，除了包括精簡套件中的內容，還提供了發(fā)動機臺架實驗所需的線束(含接插件)，殼體及簡易硬件測試板, 可以在硬件電路出現(xiàn)問題的情況下，進行簡易的診斷，判斷控制器故障。完整版套件針對希望可以快速進行臺架實驗，并有計劃進行自主開發(fā)的客戶。

(來源：英飛凌科技股份公司)

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—)，女，博士，副教授，主要研究方向為車輛系統(tǒng)動力學及控制。E-mail:785847517@qq.com。

10.19466/j.cnki.1674-1986.2016.09.008

U461.4

B

1674-1986(2016)09-036-05