汽車電控系統(tǒng)代碼自動(dòng)生成技術(shù)的功能實(shí)現(xiàn)

馮吉濤

(煙臺(tái)汽車工程職業(yè)學(xué)院 車輛運(yùn)用工程系， 煙臺(tái) 265500)

0 引言

隨著人們對(duì)汽車性能要求的不斷提高，汽車電控技術(shù)逐漸發(fā)展起來，為解決傳統(tǒng)封閉式汽車電控系統(tǒng)結(jié)構(gòu)所帶來的問題，正逐步展開開放式汽車電控系統(tǒng)的研究，汽車電控系統(tǒng)為滿足不斷增加的需求復(fù)雜程度越來越高，針對(duì)特定問題不同制造商提供的解決方案也不盡相同，軟硬件系統(tǒng)難以兼容問題凸顯，為改善E/E復(fù)雜性管理問題，增強(qiáng)可移植性、可擴(kuò)展性，成為研究的重點(diǎn)。

1 電控系統(tǒng)開發(fā)流程

汽車開放系統(tǒng)架構(gòu)標(biāo)準(zhǔn) ( AUTOSAR)包括架構(gòu)、方法學(xué)(在對(duì)軟件架構(gòu)信息進(jìn)行描述時(shí)采用標(biāo)準(zhǔn)化的數(shù)據(jù)交換格式)和應(yīng)用接口，由制造商、供應(yīng)商及工具開發(fā)商聯(lián)合開發(fā)，為車輛系統(tǒng)提供了通用軟件架構(gòu)(基于標(biāo)準(zhǔn)接口)。由SWC組成應(yīng)用層，采用虛擬功能總線(VFB，由RTE和BSW共同完成)實(shí)現(xiàn)SWC的獨(dú)立性，SWC間及其同底層的通信則通過RTE完成(通過提供一致的接口和服務(wù))，底層細(xì)節(jié)的屏蔽及SWC服務(wù)的提供由BSW負(fù)責(zé)。

結(jié)合Matlab并以AUTOSAR方法學(xué)的開發(fā)流程為依據(jù)，需先完成系統(tǒng)級(jí)設(shè)計(jì)(在Authoring Tool中)，再通過在Matlab/Simulink中導(dǎo)入系統(tǒng)描述文件完成SWC的提取，Runnable(SWC中)的設(shè)計(jì)則采用Stateflow完成，代碼生成后將SWC描述文件導(dǎo)出，在Authoring Tool中重新導(dǎo)入SWC描述文件，Runnable到BSW任務(wù)中的映射在RTE中完成，對(duì)Runnable進(jìn)行設(shè)計(jì)，并設(shè)置BSW各模塊(通過Authoring Tool完成)，實(shí)現(xiàn)底層驅(qū)動(dòng)代碼的生成，在此基礎(chǔ)上對(duì)代碼進(jìn)行融合，電控系統(tǒng)的具體開發(fā)流程如圖1所示[1]。

2 電控系統(tǒng)代碼自動(dòng)生成技術(shù)的生成

2.1 車燈系統(tǒng)SWC設(shè)計(jì)

本文主要以以汽車車燈控制系統(tǒng)為例，對(duì)汽車電控系統(tǒng)代碼自動(dòng)生成技術(shù)的功能實(shí)現(xiàn)進(jìn)行研究，車燈系統(tǒng)主要包括信號(hào)和照明燈，將車燈系統(tǒng)分為5個(gè)SWC(根據(jù)功能劃分)具體如表1所示。

其中轉(zhuǎn)向燈通過CAN調(diào)試終端完成參數(shù)的發(fā)送、報(bào)文的修改(包括跳轉(zhuǎn)頻率和最小跳轉(zhuǎn)次數(shù))及車門狀態(tài)信息(四個(gè)車門的狀態(tài)由報(bào)文第1字節(jié)低4位分別表示)的查看。分配完SWC功能后，完成SWC、接口和數(shù)據(jù)類型的建立(在ORIENTAIS中)，本文不設(shè)計(jì)SWC Behavior(SWC的行為無法被Simulink讀取)，最后再導(dǎo)出系統(tǒng)描述文件[2]。

圖1 電控系統(tǒng)開發(fā)流程

SWCRunnable 功能描述Beam Lamp Control Beam Lamp Runnable近/遠(yuǎn)光控制Turn Lamp ControlTurn Lamp Runnable Get Cal Data Runnable轉(zhuǎn)向燈控制參數(shù)設(shè)置Fog Lamp Control Fog Lamp Runnable霧燈控制Interior Lamp Control Interior Lamp Runnable內(nèi)燈控制State Display State Display Runnable狀態(tài)顯示

2.2 Runnable代碼生成

由于在概念上Simulink同 AUTOSAR具備較多的相通性，而得以在AUTOSAR開發(fā)過程中應(yīng)用，在AUTOSAR設(shè)計(jì)流程中，模型的邏輯功能的建立及模型邏輯功能正確性的仿真驗(yàn)證主均需由Simulink負(fù)責(zé)完成，在汽車電控系統(tǒng)的設(shè)計(jì)過程中二者的對(duì)應(yīng)關(guān)系(常用術(shù)語)，如表2所示。

表2 常用術(shù)語對(duì)應(yīng)關(guān)系

各SWC在將SWC封裝到部件的情況下則只能用虛擬子系統(tǒng)表示，SWC在Simulink模型中在配置SWC端口為服務(wù)器操作的情況下只能用模型表示[3]。

(1)在Simulink中運(yùn)行實(shí)體Runnable的實(shí)現(xiàn)

本文以轉(zhuǎn)向燈應(yīng)用組件為例，介紹SWC邏輯功能的實(shí)現(xiàn)細(xì)節(jié)(在Simulink中)，在Simulink中導(dǎo)入系統(tǒng)描述文件(由ORIENTAIS生成)后，需對(duì)應(yīng)用組件SWC端口做出相應(yīng)的修改，具體的層次化實(shí)現(xiàn)結(jié)構(gòu)如圖2所示。轉(zhuǎn)向燈應(yīng)用組件的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)會(huì)對(duì)外屏蔽，輸入口和輸出口的預(yù)留個(gè)數(shù)分別為7個(gè)、3個(gè)，各SWC的首個(gè)端口均需預(yù)留給RTE觸發(fā)事件，運(yùn)行時(shí)的環(huán)境(RTE)觸發(fā)事件控制信號(hào)連接其中前2個(gè)輸入口，內(nèi)部包含的2個(gè)由狀態(tài)圖實(shí)現(xiàn)的Runnable公用兩個(gè)輸入端口信號(hào)(GetMincycle和GetFlashFrm)，轉(zhuǎn)向燈邏輯狀態(tài)如圖2所示。

圖2 SWC的層次化實(shí)現(xiàn)結(jié)構(gòu)

(2)Simulink仿真

在設(shè)計(jì)好SWC邏輯功能的基礎(chǔ)上，需在部件(composition)中封裝5個(gè)SWC，封裝組件系統(tǒng)結(jié)構(gòu)的提供由Composition負(fù)責(zé)，SWC和VFB間的通信不受影響，各Runnable RTE觸發(fā)事件的提供由Function Call Generator和Event Chart共同負(fù)責(zé)，各Runnable的RTE觸發(fā)事件相互獨(dú)立，同一Runnable禁止不同的 Runnable共用；實(shí)際環(huán)境的模擬則由Simulation Environment負(fù)責(zé)完成，信號(hào)輸入由其為車燈控制系統(tǒng)(各個(gè)車燈皆由開關(guān)控制)提供，同時(shí)輸出信號(hào)通過使用示波器觀察，采用脈沖發(fā)生器(周期為50 s、占空比為20%)代替開關(guān)，以便實(shí)現(xiàn)對(duì)輸出信號(hào)隨輸入信號(hào)變化情況的較為直觀的觀察，修改轉(zhuǎn)向燈閃爍頻率(通過CAN調(diào)試終端)采用以[3 1 4 2 1]為矢量輸出值的任意信號(hào)發(fā)生器(采樣周期為40 s)表示，仿真結(jié)果如圖3所示，觀察轉(zhuǎn)向燈狀態(tài)輸出波形可知，其疏密度隨著閃爍頻率數(shù)值的更改而發(fā)生了變化，證明轉(zhuǎn)向燈閃爍頻率已改變。

圖3 仿真結(jié)果

(3)應(yīng)用代碼自動(dòng)生成

自動(dòng)生成應(yīng)用層代碼通過使用Matlab/Embedded Coder(作為Matlab和Simulink 的功能補(bǔ)充主要負(fù)責(zé)為目標(biāo)系統(tǒng)創(chuàng)建C 代碼)工具完成，選擇系統(tǒng)目標(biāo)代碼文件為 autosar.tlc以確保為生成的代碼與AUTOSAR兼容，汽車車燈控制系統(tǒng)應(yīng)用代碼的生成通過Embedded Coder工具完成，生成的文件主要包括system.arxml(對(duì)內(nèi)部行為特征、SWC的接口、數(shù)據(jù)類型進(jìn)行描述)，system.c(主要由模型代碼、模型初始化及終止操作代碼等構(gòu)成)、system.h(負(fù)責(zé)模型函數(shù)的外部聲明，由模型輸入、模型數(shù)據(jù)結(jié)構(gòu)與全局接口等構(gòu)成)。

(4)底層驅(qū)動(dòng)代碼生成

BSW各模塊的配置(同SWC設(shè)計(jì)同步進(jìn)行但相互分離)過程：先對(duì)同底層通信的信號(hào)進(jìn)行處理，為其分配相應(yīng)的引腳，接下來在ORIENTAIS 中對(duì)各模塊(包括 I/O，COM，OS，數(shù)據(jù)鏈路層，CAN總線及接口，硬件抽象層等)進(jìn)行配置，在模塊完成配置的基礎(chǔ)上實(shí)現(xiàn)相應(yīng)配置代碼的生成。

2.3 底層與應(yīng)用層代碼整合

系統(tǒng)級(jí)設(shè)計(jì)SWC時(shí)只預(yù)留了通信接口(不顯示內(nèi)部具體行為)，需在ORIENTAIS中導(dǎo)入system.arxml(Embedded Coder的導(dǎo)出文件)完成內(nèi)部行為信息的提取，應(yīng)用層SWC 間及其與BSW間的通信通過RTE實(shí)現(xiàn)，按照具體功能優(yōu)先原則完成Runnable到操作系統(tǒng)任務(wù)的映射，具體的映射關(guān)系如表3所示。

表3 映射關(guān)系表

模塊的完全初始化通過InitTask完成，對(duì)MainFuncTask進(jìn)行周期性的調(diào)度實(shí)現(xiàn)通信功能(設(shè)定周期要求短)，Runnable(與CAN通信)信息對(duì)進(jìn)行不斷讀取和發(fā)送，應(yīng)用層的SWC通過配置完RTE生成的代碼對(duì)下層的基礎(chǔ)軟件進(jìn)行了封裝，并通過OS、COM 等下層基礎(chǔ)軟件功能的應(yīng)用完成同上層SWC組件間通信及周期控制，邏輯代碼同底層代碼最終通過RTE的使用實(shí)現(xiàn)無縫連接。

3 實(shí)驗(yàn)檢測(cè)

為檢測(cè)本文汽車燈控系統(tǒng)自動(dòng)生成代碼的準(zhǔn)確性，在試驗(yàn)控制箱中進(jìn)行了實(shí)驗(yàn)，通過對(duì)車燈開關(guān)進(jìn)行隨機(jī)控制，同時(shí)對(duì)轉(zhuǎn)向燈Flash-Frm(閃爍頻率參數(shù))的更改通CAN調(diào)試終端完成， f( f=Flash Frm×2×0. 3 s)表示程序中轉(zhuǎn)向燈閃爍頻率，具體的實(shí)驗(yàn)結(jié)果如圖4所示。

圖4 實(shí)驗(yàn)結(jié)果

由圖4可知在改變閃爍頻率的過程中(從1.8 s到0.6 s再到2.4s)，轉(zhuǎn)向燈狀態(tài)疏密變化明顯，符合肉眼觀察到的情況，證明了代碼的準(zhǔn)確性和可用性，使組件的復(fù)用性和軟件兼容性得以有效提升，有助于提高不同生產(chǎn)商間產(chǎn)品的互通性。

4 總結(jié)

本文主要研究了汽車電控系統(tǒng)代碼自動(dòng)生成技術(shù)的開發(fā)流程，以汽車車燈控制系統(tǒng)為例，應(yīng)用ORIENTAIS工具對(duì)基礎(chǔ)軟件和運(yùn)行環(huán)境等進(jìn)行配置，實(shí)現(xiàn)底層驅(qū)動(dòng)和實(shí)時(shí)交互層代碼的生成，應(yīng)用軟件組件的運(yùn)行實(shí)體及應(yīng)用層邏輯功能則通過Simulink完成開發(fā)，運(yùn)行實(shí)體內(nèi)部邏輯的設(shè)計(jì)通過運(yùn)用Stateflow完成，并完成了仿真模型的建立，邏輯層代碼采用Em-bedder Coder生成同底層驅(qū)動(dòng)代碼、實(shí)時(shí)交互及邏輯層代碼進(jìn)行融合，實(shí)現(xiàn)代碼的無縫連接，進(jìn)行汽車試驗(yàn)控制箱實(shí)驗(yàn)，證明了代碼的準(zhǔn)確性和可用性，使組件的復(fù)用性和軟件兼容性得以有效提升，有助于縮短了產(chǎn)品開發(fā)周期，提高不同生產(chǎn)商間產(chǎn)品的互通性。