孫濤宋安王輝
(1.中汽研汽車工業工程(天津)有限公司;2.李斯特技術中心(天津)有限公司)

隨著新能源汽車的快速發展和新能源汽車應用要求的不斷提高,整車電控系統軟件開發的要求也越來越高。基礎軟件的重復性開發勢必會造成整車成本提高,不利于車企的長足發展。因此現代車企越來越多地要求將產品進行平臺化,以便于不同產品之間可以沿用。基于以上問題,文章主要參照國際Autosar軟件標準,結合項目實際要求,提出了新基礎軟件架構,并通過MATLAB的命令行工具LegacyCode Tool及S-function等功能,將底層驅動源代碼封裝成Simulink模塊庫,形成平臺化產品。采用一鍵式集成的方式對其進行編譯,生成可執行文件。經過開發測試驗證,平臺化開發的基礎軟件安全可靠。
Autosar是面向汽車領域的嵌入式軟件體系結構標準[1]。該體系結構采用了分層模型,每一層只能使用下一層的接口,并向上一層提供服務接口。這樣對于不同的硬件平臺具有更大的靈活性,使得硬件和軟件更大程度地彼此獨立,同時分層獨立開發可以縮短開發周期和減少開發成本。
按照Atuosar標準分層的架構體系[1],自上而下分別是應用層(Application Layer)、運行時環境(Runtime Environment)、基礎軟件層(Basic Software Layer)及微控制器層,即硬件。
而基礎軟件分為3個層次,分別為:微控制器抽象層(Microcontroller Abstraction Layer)、ECU抽象層(ECU Abstraction Layer)、服務層(Services Layer)。另外,在Autosar軟件架構中將復雜驅動(Complex Drivers)獨立出來,這部分并沒有標準化,主要用于對復雜的傳感器執行器進行操作。Autosar標準軟件架構具體分層結構,如圖1所示。

圖1 Autosar標準軟件架構顯示界面
整車控制器(VCU)是純電動汽車的核心控制部件之一,主要功能是解析駕駛員需求,監視汽車行駛狀態,協調控制單元(如 BMS,MCU,EMS,TCU等)工作,實現整車的上下電、驅動控制、能量回收、附件控制和故障診斷功能。
整車控制器基礎軟件需要實現開關量輸入/輸出模塊(DI/DO)、模擬量輸入模塊(ADC)及通信模塊(包括SPI通信及CAN通信)的功能,負責整車控制器信號的采集和傳遞,并通過CAN總線傳遞到其他控制單元或驅動繼電器來使執行器工作[2]。整車控制器的系統功能結構,如圖2所示。

圖2 整車控制器的系統功能結構圖
開關量輸入模塊接收的信號主要有鑰匙信號、擋位信號及制動開關信號等;輸出信號主要是控制繼電器信號,如水泵繼電器控制信號等。
模擬量輸入模塊采集加速踏板和制動踏板開度信號及小蓄電池電壓信號。
SPI通信模塊主要負責電路板上不同芯片之間數據的交互,包括功能安全的問答機制;CAN通信模塊負責整車控制器內部通信及與整車其他設備(主要有車載充電機(OBC)、電機控制器(MCU)、電池管理系統(BMS)及網關(GW)等)的通信。
根據整車控制器對底層的要求,劃分基礎軟件的結構形式及各個功能模塊,對芯片的RAM及Flash存儲器等進行內存分配,定義各模塊的功能要求并規定各模塊之間的接口,最終形成基礎軟件架構,如圖3所示。

圖3 整車控制器基礎軟件架構顯示界面
為了便于理解,將基礎軟件分層內容進行了重新定義,分為驅動層、ECU抽象層及服務層。
1)驅動層是基礎軟件的最底層,它主要對硬件提供驅動和診斷,并對接口層提供硬件資源調用服務的支持。該層主要由I/O驅動模塊、存儲驅動模塊、通信驅動模塊及MCU驅動模塊組成。
2)ECU抽象層封裝了驅動層以及外圍設備的驅動,主要包括IO硬件抽象單元及CAN接口單元等。
3)服務層包含了操作系統、系統服務(模式管理)、存儲器服務、通訊服務及診斷通訊等。它為應用軟件和基礎軟件模塊提供基礎服務。服務層的實現和運行與驅動層、ECU抽象層及應用軟件息息相關。對各個功能模塊的描述,如表1所示。
在軟件架構定義完成之后,根據Autosar軟件模塊的功能規范,軟件需要編寫各模塊的設計文檔,設計文檔需要明確該模塊的編碼手段(C/C++匯編語言),并定義函數功能接口包括的類型參數、原型聲明、外部聲明及函數返回值等內容。
根據完成的設計文檔及編程規范來編寫各功能模塊的源代碼,并進行動靜態測試及功能測試。
由于應用軟件是基于MATLAB中的Simulink來搭建完成的,要想使應用層軟件與基礎軟件相集成,首先需要將應用層模型生成C代碼,然后編寫中間層代碼,使得應用層的接口與底層接口進行匹配交互。這樣在軟件開發過程中每一版軟件都需要不斷維護中間層代碼,勢必造成很大的工作量,并增加了開發周期,耗費了人力資源。
為了更快更方便地將基礎軟件與應用層軟件相集成,通過使用MATLAB中的LegacyCode Tool命令行工具、S-function函數及m文件工具,將基礎軟件各個功能模塊的源代碼封裝成Simulink模塊,并將封裝完成的各個子功能模塊集成到模型中,稱其為BSW Library,形成平臺化產品[3]。
Legacy Code Tool可以很方便地將已有的源代碼(C/C++代碼)與模型結合起來[4]。通過將源代碼編譯生成用于仿真的S-Funciton,也可以生成一個封裝了外部C代碼參數化的S-function模塊。
通過S-function可以定義每個功能模塊與應用層的接口。具體封裝流程,如圖4所示。
1)首先將要封裝的源代碼(包括頭文件等)放到指定目錄下;
2)生成一個特定的Legacy Code Tool參數集,參數集制定了要包含的C代碼、頭文件,以及生成S-func-tion的名稱等諸多信息;
3)通過Legacy Code Tool的命令行語句,調用第1步配置好的參數集變量,生成相應的S-function源文件;
4)將生成的S-function源文件變為可動態加載的執行文件,即mexw32文件;
5)通過Legacy Code Tool的命令行語句將上面生成的S-function執行文件封裝成Simulink模塊。
封裝完成后的I/O模塊程序界面,如圖5所示。

圖5 封裝完成后的I/O模塊程序界面
對源代碼封裝完成后,在開發應用層模型時,可以在Simulink BSW Library庫中直接調用基礎軟件的模型,將其與應用層模塊進行集成,這樣將大大提升集成的效率,并且能夠保證集成的質量[4]。
將集成好的模型通過運行編寫好的m文件并使用MATLAB的Embedder Coder功能來生成源代碼(*.c及*.h)。最后在編譯器中運行makefile文件,將所有的源代碼及芯片中固化的lib文件進行編譯連接,生成可執行文件及A2L文件。
對集成后的可執行文件按照定義的測試項進行測試驗證后,測試全部通過。從而得出:基于Autosar架構定義的基礎軟件架構使得當底層硬件升級時不需要更改整個系統,只需要將部分內容做一定程度的修改,即可重復利用,有利于未來整車系統的更新。通過對開發的基礎軟件源代碼進行封裝,變成平臺化的產品,可以提高軟件集成的可靠度并降低維護成本,進而降低開發費用。