圖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ī)會(huì)。藉由這樣的工作流程，我們可以把基礎(chǔ)軟體層級(jí)內(nèi)特定硬體模組的開發(fā)工作交給專業(yè)的供應(yīng)商，我們自己則專注在應(yīng)用層級(jí)中控制邏輯的模型建立、模擬與驗(yàn)證。

透過MATLAB與Simulink的模型化基礎(chǔ)設(shè)計(jì)功能，使我們?cè)O(shè)計(jì)元件的再利用性增加，減少人工編寫程式碼，改善與客戶的溝通，最後開發(fā)出了更高品質(zhì)的電池管理系統(tǒng)（BMS）。導(dǎo)入模型化基礎(chǔ)設(shè)計(jì)，得以讓我們?cè)诿恳淮诬涹w發(fā)布後發(fā)現(xiàn)的問題數(shù)量從22個(gè)減少至9個(gè)以下，這比我們對(duì)這項(xiàng)計(jì)畫所定下的目標(biāo)還要更少、更好。

為什麼使用模型化基礎(chǔ)設(shè)計(jì)？

我們選擇模型化基礎(chǔ)設(shè)計(jì)有一部分的原因是，它可以幫助建立模型、模擬複雜的演算法和構(gòu)成BMS核心的行為。我們希望可以自動(dòng)地進(jìn)行品質(zhì)檢查，並且透過軟體迴圈（software-in-the-loop，SIL）和硬體迴圈（hardware-in-the-loop，HIL）測(cè)試，在客戶的驗(yàn)收測(cè)試之前就先徹底驗(yàn)證我們的設(shè)計(jì)。

我們開發(fā)的演算法需要結(jié)合具多種專業(yè)背景和訓(xùn)練的工程師們的努力，包含電化學(xué)、數(shù)學(xué)、控制設(shè)計(jì)，以及軟體工程。我們知道模型化基礎(chǔ)設(shè)計(jì)可提供一個(gè)共同開發(fā)的平臺(tái)以及語言，讓參與設(shè)計(jì)的工程師們?cè)谶@個(gè)平臺(tái)上進(jìn)行協(xié)同設(shè)計(jì)。

可重複使用性也是我們決定採(cǎi)用模型化基礎(chǔ)設(shè)計(jì)的另一個(gè)關(guān)鍵因素。我們當(dāng)時(shí)已經(jīng)組構(gòu)了一個(gè)元件函式庫(kù)，希望能把它們應(yīng)用到Volvo BMS專案之內(nèi)，同時(shí)也繼續(xù)開發(fā)這個(gè)函式庫(kù)，希望能重複利用並加速其他OEMs專案的開發(fā)。

到目前為止，這個(gè)核心函式庫(kù)已經(jīng)被使用到Volvo開發(fā)專案中的五個(gè)各異的模型之中。有了這個(gè)核心函式庫(kù)，使我們花上比以往更短的時(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模型裡面的訊號(hào)映射到在AUTOSAR元件描述中的訊號(hào)。在這個(gè)階段，藉由之前的專案組裝而來的核心函式庫(kù)，把Simulink元件重複使用在SoC（state-of-charge，充電狀態(tài)）估計(jì)、SoH（state-of-health，健康狀態(tài)）估計(jì)、控制邏輯、診斷邏輯等地方。接下來再加入客製邏輯以符合Volvo對(duì)這項(xiàng)特定計(jì)畫的要求，像是PHEV馬達(dá)仲裁邏輯（motor arbitration logic）等等。

在Simulink開發(fā)控制器模型時(shí)，我們頻繁地使用Model Advisor這項(xiàng)功能，來檢查模型是否符合AUTOSAR規(guī)範(fàn)指南和建模標(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)化測(cè)試

最初的設(shè)計(jì)完成之後，接下來的目標(biāo)是要讓程式碼實(shí)現(xiàn)、測(cè)試執(zhí)行等剩下的工作流程盡可能地自動(dòng)化，於是我們利用嵌入式程式碼轉(zhuǎn)碼器（Embedded CoderR）和嵌入式程式碼轉(zhuǎn)碼器中的AUTOSAR標(biāo)準(zhǔn)軟體支援套件，從控制器模型去產(chǎn)生符合AUTOSAR的C程式碼。

為了要驗(yàn)證產(chǎn)生的程式碼，執(zhí)行了SIL（軟體迴圈）測(cè)試的測(cè)試案例，強(qiáng)調(diào)三個(gè)部分：核心函式庫(kù)的元件、映射訊號(hào)、客製化的邏輯。

在自動(dòng)化SIL測(cè)試過程中，利用Simulink程式碼覆蓋率測(cè)試工具（Simulink Coverage）測(cè)量執(zhí)行的覆蓋程度、變更條件/決策覆蓋（modified condition/decision coverage，MC/DC）、查找表覆蓋、以及循環(huán)複雜度等。這些量測(cè)值可幫助確保測(cè)試是否確實(shí)涵蓋了整個(gè)設(shè)計(jì)。

在過去，在仰賴人工編寫程式碼的開發(fā)流程中，幾乎不可能去診斷出那些在整合測(cè)試中可能發(fā)現(xiàn)的難以除錯(cuò)的問題，特別是有些系統(tǒng)內(nèi)的軟體元件（software component，SWC）輸出是由第二個(gè)SWC來處理之後再提供回原本的SWC。透過模型化基礎(chǔ)設(shè)計(jì)，可以在模擬中展示每一個(gè)層級(jí)的訊號(hào)，來看看錯(cuò)誤如何通過回饋迴路中的SWC來傳遞，這讓潛在的問題可以更容易地被發(fā)現(xiàn)和修正。

之後，我們把產(chǎn)生的程式碼佈署到目標(biāo)嵌入式處理器中接著進(jìn)行HIL測(cè)試，在此進(jìn)行了整臺(tái)車輛的完整電子動(dòng)力系統(tǒng)模擬。這些最終測(cè)試結(jié)果，也會(huì)導(dǎo)向客戶由他們?nèi)?zhí)行有效性測(cè)試。如果客戶的測(cè)試發(fā)現(xiàn)錯(cuò)誤，我們可以利用測(cè)試log檔在Simulink重現(xiàn)問題，藉由模擬找出根本原因，並調(diào)整模型來解決問題。我們把廣泛的測(cè)試納入為工作流程的一部分，讓軟體問題的件數(shù)有效降低（圖1）。

圖2 : 採(cǎi)用模型化基礎(chǔ)設(shè)計(jì)前/後的軟體發(fā)布問題件數(shù)比較。

下一步

我們使用AUTOSAR和模型化基礎(chǔ)設(shè)計(jì)為Volve開發(fā)的電池管理系統(tǒng)，已經(jīng)完成了ISO 26262功能安全—車輛安全完整性等級(jí)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公司）