汽車電控系統代碼自動生成技術的功能實現

馮吉濤

(煙臺汽車工程職業學院 車輛運用工程系， 煙臺 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生成同底層驅動代碼、實時交互及邏輯層代碼進行融合，實現代碼的無縫連接，進行汽車試驗控制箱實驗，證明了代碼的準確性和可用性，使組件的復用性和軟件兼容性得以有效提升，有助于縮短了產品開發周期，提高不同生產商間產品的互通性。