| 圖1 : 富豪（Volvo）XC90??電式混合動(dòng)力車具有電池管理系統(tǒng)（BMS）效能。(source:Carwow) |
|
LG Chem的團(tuán)隊(duì)在開發(fā)富豪（Volvo）XC90插電式混合動(dòng)力車的電池管理系統(tǒng)（battery management system，BMS）時(shí)，Volvo要求我們必須使用AUTOSAR，而開發(fā)方法與工具可以由我們自行選擇。我們將這項(xiàng)專案視為一個(gè)可以利用模型化基礎(chǔ)設(shè)計(jì)（Model-Based Design）來建立工作流程的機(jī)會。藉由這樣的工作流程，我們可以把基礎(chǔ)軟體層級內(nèi)特定硬體模組的開發(fā)工作交給專業(yè)的供應(yīng)商，我們自己則專注在應(yīng)用層級中控制邏輯的模型建立、模擬與驗(yàn)證。
透過MATLAB與Simulink的模型化基礎(chǔ)設(shè)計(jì)功能，使我們設(shè)計(jì)元件的再利用性增加，減少人工編寫程式碼，改善與客戶的溝通，最后開發(fā)出了更高品質(zhì)的電池管理系統(tǒng)（BMS）。導(dǎo)入模型化基礎(chǔ)設(shè)計(jì)，得以讓我們在每一次軟體發(fā)布后發(fā)現(xiàn)的問題數(shù)量從22個(gè)減少至9個(gè)以下，這比我們對這項(xiàng)計(jì)畫所定下的目標(biāo)還要更少、更好。
為什么使用模型化基礎(chǔ)設(shè)計(jì)？
我們選擇模型化基礎(chǔ)設(shè)計(jì)有一部分的原因是，它可以幫助建立模型、模擬復(fù)雜的演算法和構(gòu)成BMS核心的行為。我們希望可以自動(dòng)地進(jìn)行品質(zhì)檢查，并且透過軟體回圈（software-in-the-loop，SIL）和硬體回圈（hardware-in-the-loop，HIL）測試，在客戶的驗(yàn)收測試之前就先徹底驗(yàn)證我們的設(shè)計(jì)。
我們開發(fā)的演算法需要結(jié)合具多種專業(yè)背景和訓(xùn)練的工程師們的努力，包含電化學(xué)、數(shù)學(xué)、控制設(shè)計(jì)，以及軟體工程。我們知道模型化基礎(chǔ)設(shè)計(jì)可提供一個(gè)共同開發(fā)的平臺以及語言，讓參與設(shè)計(jì)的工程師們在這個(gè)平臺上進(jìn)行協(xié)同設(shè)計(jì)。
可重復(fù)使用性也是我們決定采用模型化基礎(chǔ)設(shè)計(jì)的另一個(gè)關(guān)鍵因素。我們當(dāng)時(shí)已經(jīng)組構(gòu)了一個(gè)元件函式庫，希望能把它們應(yīng)用到Volvo BMS專案之內(nèi)，同時(shí)也繼續(xù)開發(fā)這個(gè)函式庫，希望能重復(fù)利用并加速其他OEMs專案的開發(fā)。
到目前為止，這個(gè)核心函式庫已經(jīng)被使用到Volvo開發(fā)專案中的五個(gè)各異的模型之中。有了這個(gè)核心函式庫，使我們花上比以往更短的時(shí)間，就能夠開發(fā)出一個(gè)不一樣的新模型，或什至一個(gè)新的開發(fā)設(shè)計(jì)案。
開發(fā)AUTOSAR軟體元件
我們使用從上而下（top-down）的方法開始，在AUTOSAR編輯工具中進(jìn)行系統(tǒng)架構(gòu)建模以及定義軟體元件描述。隨后，把這些元件描述（以ARXML檔案匯出）匯入至Simulink中。
在Simulink和Stateflow里面，利用稍早匯入過程中自動(dòng)建立的骨干模型，建立了BMS控制邏輯以及演算法行為的模型。我們也把Simulink模型里面的訊號映射到在AUTOSAR元件描述中的訊號。在這個(gè)階段，藉由之前的專案組裝而來的核心函式庫，把Simulink元件重復(fù)使用在SoC（state-of-charge，充電狀態(tài)）估計(jì)、SoH（state-of-health，健康狀態(tài)）估計(jì)、控制邏輯、診斷邏輯等地方。接下來再加入客制邏輯以符合Volvo對這項(xiàng)特定計(jì)畫的要求，像是PHEV馬達(dá)仲裁邏輯（motor arbitration logic）等等。
在Simulink開發(fā)控制器模型時(shí)，我們頻繁地使用Model Advisor這項(xiàng)功能，來檢查模型是否符合AUTOSAR規(guī)范指南和建模標(biāo)準(zhǔn)的要求。也使用Simulink設(shè)計(jì)驗(yàn)證工具來檢查模型里面是否出現(xiàn)死邏輯（dead logic）、除以零錯(cuò)誤，或者其他可能出現(xiàn)的設(shè)計(jì)錯(cuò)誤。
LG Chem的電化學(xué)模擬團(tuán)隊(duì)建立了一個(gè)電池組之電化學(xué)電池的數(shù)學(xué)模型，也把這個(gè)團(tuán)隊(duì)的MATLAB程式碼整合到我們的Simulink受控體模型中，用來模擬控制器模型。
產(chǎn)生程式碼與自動(dòng)化測試
最初的設(shè)計(jì)完成之后，接下來的目標(biāo)是要讓程式碼實(shí)現(xiàn)、測試執(zhí)行等剩下的工作流程盡可能地自動(dòng)化，于是我們利用嵌入式程式碼轉(zhuǎn)碼器（Embedded CoderR）和嵌入式程式碼轉(zhuǎn)碼器中的AUTOSAR標(biāo)準(zhǔn)軟體支援套件，從控制器模型去產(chǎn)生符合AUTOSAR的C程式碼。
為了要驗(yàn)證產(chǎn)生的程式碼，執(zhí)行了SIL（軟體回圈）測試的測試案例，強(qiáng)調(diào)三個(gè)部分：核心函式庫的元件、映射訊號、客制化的邏輯。
在自動(dòng)化SIL測試過程中，利用Simulink程式碼覆蓋率測試工具（Simulink Coverage）測量執(zhí)行的覆蓋程度、變更條件/決策覆蓋（modified condition/decision coverage，MC/DC）、查找表覆蓋、以及循環(huán)復(fù)雜度等。這些量測值可幫助確保測試是否確實(shí)涵蓋了整個(gè)設(shè)計(jì)。
在過去，在仰賴人工編寫程式碼的開發(fā)流程中，幾乎不可能去診斷出那些在整合測試中可能發(fā)現(xiàn)的難以除錯(cuò)的問題，特別是有些系統(tǒng)內(nèi)的軟體元件（software component，SWC）輸出是由第二個(gè)SWC來處理之后再提供回原本的SWC。透過模型化基礎(chǔ)設(shè)計(jì)，可以在模擬中展示每一個(gè)層級的訊號，來看看錯(cuò)誤如何通過回饋回路中的SWC來傳遞，這讓潛在的問題可以更容易地被發(fā)現(xiàn)和修正。
之后，我們把產(chǎn)生的程式碼布署到目標(biāo)嵌入式處理器中接著進(jìn)行HIL測試，在此進(jìn)行了整臺車輛的完整電子動(dòng)力系統(tǒng)模擬。這些最終測試結(jié)果，也會導(dǎo)向客戶由他們?nèi)?zhí)行有效性測試。如果客戶的測試發(fā)現(xiàn)錯(cuò)誤，我們可以利用測試log檔在Simulink重現(xiàn)問題，藉由模擬找出根本原因，并調(diào)整模型來解決問題。我們把廣泛的測試納入為工作流程的一部分，讓軟體問題的件數(shù)有效降低（圖1）。
| 圖2 : 采用模型化基礎(chǔ)設(shè)計(jì)前/後的軟體發(fā)布問題件數(shù)比較。 |
|
下一步
我們使用AUTOSAR和模型化基礎(chǔ)設(shè)計(jì)為Volve開發(fā)的電池管理系統(tǒng)，已經(jīng)完成了ISO 26262功能安全—車輛安全完整性等級C（Automotive Safety Integrity Level C，ASIL C）的基礎(chǔ)認(rèn)證。在開發(fā)專案的認(rèn)證初期，我們手動(dòng)完成大部份的認(rèn)證任務(wù)，但將許多任務(wù)自動(dòng)化之后，減少許多為了產(chǎn)生認(rèn)證報(bào)告所耗費(fèi)的寶貴資源。
現(xiàn)在，我們的團(tuán)隊(duì)使用我們?yōu)閂olve BMS建立的工作流程來為更多的汽車OEM客戶開發(fā)AUTOSAR軟體元件。
（本文作者Duck Young Kim、Won Tae Joe、Hojin Lee任職于LG Chem公司）
