引言

汽車自誕生百余年來,已經(jīng)從純粹的機械時代逐漸進化到了如今的智能、網(wǎng)聯(lián)、電動、自動化時代,軟件、芯片、計算能力等正變得越來越重要。當前汽車行業(yè)上的創(chuàng)新和發(fā)展趨勢,絕大部分也都體現(xiàn)在電子電氣領(lǐng)域。軟件在汽車的總體價值中,所占比重正在逐步增長。對0EM而言,軟件的可重用性、代碼質(zhì)量和開發(fā)效率顯得至關(guān)重要,它可以幫助更好地平衡車型研發(fā)成本、開發(fā)周期和質(zhì)量之間的關(guān)系。

AUT0SAR作為汽車電子行業(yè)的標準,致力于解決硬件平臺不同帶來的軟件開發(fā)的困難。通過提供標準的軟件接口定義,將應用層軟件（SWC)和硬件平臺解耦,軟件組件可以按需分配到不同的ECU中,實現(xiàn)軟件組件的可重用性,大幅提高開發(fā)效率,已被主機廠廣泛采用。

1基于模型的功能開發(fā)

汽車上控制系統(tǒng)的軟件架構(gòu)包含運行環(huán)境和應用軟件,運行環(huán)境包括操作系統(tǒng)、驅(qū)動程序、通信協(xié)議棧以及網(wǎng)絡管理、診斷應用等服務。對主機廠而言,關(guān)心的是和功能掛鉤的應用軟件。為保證應用軟件開發(fā)質(zhì)量,盡快達到可靠的成熟度以及實現(xiàn)功能可重用性,同時減少功能開發(fā)對供應商的依賴性,通常采用以模型為基礎(chǔ)（MOdel-BaSed)的功能軟件架構(gòu)開發(fā)方式。在功能模型的基礎(chǔ)上,獲得系統(tǒng)描述規(guī)范,進一步獲得自動軟件代碼生成器。

以泊車輔助功能為例,利用內(nèi)嵌在車后保險杠上的4個接近傳感器（超聲波傳感器)探測后方障礙物,根據(jù)車輛接近障礙物的距離,發(fā)出不同頻率的警告聲。后視攝像頭提供倒車可視畫面,整個輔助系統(tǒng)可以由駕駛員使能（選擇激活或者不激活)。采用基于模型的功能開發(fā)思路,將系統(tǒng)的功能拆解為各個小功能塊,如傳感器數(shù)據(jù)預處理模塊、數(shù)據(jù)融合模塊、泊車輔助算法等,分別對應不同的軟件組件（SWC),各功能塊之間通過AUT0SAR標準接口（如S/R、C/S接口等)進行數(shù)據(jù)交互。泊車輔助系統(tǒng)的功能模型如圖1所示。

2控制器AUTOSAR軟件開發(fā)

2.1AUTOSAR軟件開發(fā)流程

功能模型開發(fā)是控制器軟件開發(fā)的基礎(chǔ),控制器最終的軟件開發(fā)取決于功能塊的部署。一種基于AUT0SAR的車用控制器軟件開發(fā)流程如圖2所示。

第一步,采用基于模型的E/E架構(gòu)開發(fā)工具PREEviSiOn進行功能模型開發(fā),并部署到硬件控制器?；诠δ苣Ｐ?提取AUT0SAR系統(tǒng)描述文件和ECU抽取文件。

第二步,將系統(tǒng)描述文件（.arxml)導入MATLAB/Simulink中搭建功能控制算法模型,完成控制器應用層軟件組件開發(fā)。

第三步,將ECU抽取文件(arxm1）導入到協(xié)議棧配置工具VectOrDaVinciCOnfiguratOr中,配置AUTOSAR運行環(huán)境,包括RTE、操作系統(tǒng)、通信協(xié)議棧、底層驅(qū)動程序、網(wǎng)絡管理/診斷等服務模塊。

四步,兩部分代碼集成編譯以及調(diào)試,之后下載到控制器中,完成整個AUTOSAR軟件開發(fā)過程。

2.2系統(tǒng)功能模型開發(fā)

針對泊車輔助功能,按圖1在PREEviSiOn中搭建泊車輔助功能軟件架構(gòu)模型（SWC、端口、Interface/DE、數(shù)據(jù)類型等）,并進一步詳細定義各SWC的內(nèi)部行為,如RTEEvent、Runnab1e、變量等。這些軟件組件屬于AUTOSAR應用層,完全獨立于硬件,可在不同項目、不同平臺中實現(xiàn)復用。之后,將各功能部署到對應控制器并進行信號路由,完成通信層設計。表1是泊車輔助系統(tǒng)功能軟件組件定義,圖3是泊車輔助控制器（PAC）的功能部署實例。

2.3應用軟件開發(fā)

MATLAB/Simu1ink提供了一個動態(tài)系統(tǒng)建模、仿真和分析的集成環(huán)境,在該環(huán)境中,無需大量手寫程序,只需通過直觀地構(gòu)建算法模型便可構(gòu)造出復雜的系統(tǒng)。EmbeddedCOder具有生成可讀、緊湊且高效的C和C++代碼的功能,以便用于各種嵌入式處理器和量產(chǎn)微處理器,同時,EmbeddedCOder支持生成AUTOSAR和ASAP2軟件標準的代碼?；谏鲜鰞蓚€工具,可以實現(xiàn)控制器應用層軟件控制算法的圖形化設計和代碼自動生成。

基于Simu1ink的軟件組件開發(fā)主要是對AUTOSAR軟件組件內(nèi)部行為（Interna1BehaviOr）的實現(xiàn),即實現(xiàn)運行實體（Runnab1eEntity）中的內(nèi)部控制算法。PREEviSiOn/AUTOSAR中模型元素和MATLAB/Simu1ink元素對照如表2所示。

在PREEviSiOn中已經(jīng)定義了泊車輔助控制系統(tǒng)中所有的軟件組件（SWC）及其內(nèi)部行為（如運行實體、RTE事件、運行實體間變量、變體等）,這些內(nèi)容通過AUTOSAR標準接口arxm1文件直接轉(zhuǎn)換為Simu1ink模型,這是一種"自上而下"的正向開發(fā)流程。其中,導入MATLAB中的語句如下:

//讀取本地arxm1文件

impOrterObj=arxm1.impOrter('PAC)V2.l.arxm1'）

//創(chuàng)建SOftWareCOmpOSitiOn的Simu1ink模型impOrterObj.createCOmpOSitiOnASMOde1

('/SOftWareTypeS/COmpOnentTypeS/xCUEcuCOmp','MOde1PeriOdicRunnab1eSAS','FunctiOnCa11SubSyStem'）

圖4是PAC中的數(shù)據(jù)融合軟件組件導入到Simu1ink中生成的模型示意,其他軟件組件模型類似。

在該模型的基礎(chǔ)上,進一步完成各函數(shù)調(diào)用子系統(tǒng)的內(nèi)部控制算法的實現(xiàn),然后即可通過Bui1dMOde1生成符合AUTOSAR規(guī)范的軟件組件代碼（*.c和*.h文件）及arxm1描述文件。生成代碼之前需要配置以下內(nèi)容:

(1）AUTOSARPrOpertieS以及Simulink-AUTOSARMapping設置:

(2）系統(tǒng)目標文件設置為autOSar.tlc:

(3）配置求解器(SOlver）步長模式為定步長(Fixe4-Step）。

通過Simulink生成的AUTOSAR描述文件,反過來,也可以重新導入至PREEviSiOn中從而將軟件開發(fā)人員在Simulink中對軟件組件做出的修改同步到PREEviSiOn中完善功能架構(gòu)模型。二者之間的數(shù)據(jù)傳遞交互過程如圖5所示。

2.4基礎(chǔ)軟件及RTE開發(fā)

AUTOSAR軟件體系架構(gòu)中,在應用層(ApplicatiOnLayer）之下是與硬件相關(guān)的基礎(chǔ)軟件層(BaSicSOftWareBSW）,兩者之間設立了一個運行時環(huán)境(RunTimeEnvirOnment,RTE）,從而形成分層體系架構(gòu)。OEM專注于RTE上層和功能相關(guān)的應用層軟件,而基礎(chǔ)軟件層則得到了標準化,可以由底層軟件配置工具生成實現(xiàn)。

ECU底層軟件配置包含RTE和基礎(chǔ)軟件層模塊的配置。DaVinciCOnfiguratOrPrO是一個專門用于AUTOSAR規(guī)范ECU級的開發(fā)工具可以很方便地搭建符合AUTOSAR規(guī)范的實時操作系統(tǒng),并對諸如通信、診斷、網(wǎng)絡管理、硬件I/O等進行配置、驗證和代碼生成。

對于PAC控制器在DaVinciCOnfiguratOr新建一個AUTOSAR工程,加載從PREEviSiOn中導出的ECU提取文件(*.arxml）以CAN模塊為例,其配置參數(shù)如下:

(1）CanCOntrOllerS通用配置。

BuSOffPrOceSSing:用于處理BuSOff事件中斷或者輪詢:

ClOckFreQuency[MqH]:設置CAN模塊的時鐘:

PzySicalNO4e:CAN節(jié)點:

Rx/TxPrOceSSing:接收/發(fā)送數(shù)據(jù)的處理方式,中斷或者輪詢。

(2）CanCOntrOllerS波特率配置。

COntrOllerBau4Rate:設置CAN波特率的值:

BRP:波特率預分頻因子:

COntrOllerPrOpSeg/Seg1/Seg2:設置傳播端時間/采樣點時間:

COntrOllerSynchumpWi4tz:設置同步跳躍寬度,用于重同步。

(3）CanCOntrOllerS過濾器配置。

FilterCO4e/MaSkValue:過濾器設計成CO4e和MaSk兩個部分通過條件為Receive4CANID&MaSk==CO4e。

(4）Canqar4WareObjectS配置。

COntrOllerRef:硬件MO所屬的CAN節(jié)點:

I4Type:標準幀或者擴展幀:

I4Value:CANID:

ObjectType:設置接收還是發(fā)送。

(5）CanGeneral配置。

BaSeA44reSS:寄存器的基地址:

ClOckDivi4er:時鐘分頻器:

ClOckDivi4erMO4e:時鐘分頻器的模式,NOrmal:fCAN=fSYS*1/n。

PAC控制器中其他模塊配置,如DCM&DEM(診斷模塊）、EcuM(ECU管理模塊）、RTE以及OS(Runnable和TaSk映射）等,此處不展開。

AUTOSARBSW中,微控制器抽象層(MCAL）是跟硬件強相關(guān)的。MCAL主要包含了硬件驅(qū)動程序,用來訪問內(nèi)存、通信和I/O這部分代碼一般由芯片供應商提供MCAL配置工具生成.c和.z文件,如英飛凌MACL配置工具。

2.5編譯與調(diào)試

在完成AUTOSAR系統(tǒng)級、ECU級以及軟件組件相關(guān)開發(fā)與代碼生成工作之后需進行代碼集成與調(diào)試。完整的符合AUTOSAR規(guī)范的ECU代碼包含以下四部分:

(1）應用層軟件組件代碼(由Simulink生成）:

(2）運行時環(huán)境RTE代碼(由DaVinciCOnfiguratOr生成）:

(3）基礎(chǔ)軟件BSW代碼(不含MCAL由DaVinciCOn-figuratOr生成的動態(tài)代碼＋部分靜態(tài)代碼）:

(4）MCAL代碼(由芯片供應商MCAL配置工具生成）。

代碼集成編譯的過程如圖6所示,需要選擇跟硬件匹配的編譯器比如PAC控制器用的是AURIx系列單片機,可選擇TASKING或者qigzTec。代碼編譯通過之后,使用調(diào)試器將可執(zhí)行文件燒寫到硬件中進行軟件調(diào)試和優(yōu)化。

3系統(tǒng)仿真

在前期系統(tǒng)功能設計過程中,可以輔助以仿真工具進行模擬及驗證確保前期功能邏輯以及通信矩陣設計的正確性。仿真的通信數(shù)據(jù)庫arxml文件由PREEviSiOn導出,導入CANOe中可自動生成整個網(wǎng)絡模型。前期的功能邏輯可以由CAPL進行編寫,也可以利用Simulink中搭建好的算法模型,轉(zhuǎn)化為d11庫文件。將d11文件導入CANOe仿真工程中對應的節(jié)點便可進行功能仿真,驗證算法邏輯正確性。CANOe中系統(tǒng)仿真示意如圖7所示。

4結(jié)語

本文提出了一種基于AUTOSAR的車用控制器軟件開發(fā)流程和實現(xiàn)方法,結(jié)合當前最主流的基于模型的開發(fā)思路,從功能模型開發(fā)到應用軟件設計、基礎(chǔ)軟件開發(fā)、集成與調(diào)試以及系統(tǒng)開發(fā)過程中的仿真驗證,基于這一整套完善的方法和流程可以實現(xiàn)車內(nèi)各功能應用的跨車型、跨平臺的可重用性。同時,在充分的AUTOSAR工具鏈的支持下,可以大幅提高符合AUTOSAR標準的軟件開發(fā)效率,同時保證軟件開發(fā)的質(zhì)量。