圖1 : 富豪（Volvo）XC90插電式混合動力車具有電池管理系統（BMS）效能。(source:Carwow)

LG Chem的團隊在開發富豪（Volvo）XC90插電式混合動力車的電池管理系統（battery management system，BMS）時，Volvo要求我們必須使用AUTOSAR，而開發方法與工具可以由我們自行選擇。我們將這項專案視為一個可以利用模型化基礎設計（Model-Based Design）來建立工作流程的機會。藉由這樣的工作流程，我們可以把基礎軟體層級內特定硬體模組的開發工作交給專業的供應商，我們自己則專注在應用層級中控制邏輯的模型建立、模擬與驗證。

透過MATLAB與Simulink的模型化基礎設計功能，使我們設計元件的再利用性增加，減少人工編寫程式碼，改善與客戶的溝通，最後開發出了更高品質的電池管理系統（BMS）。導入模型化基礎設計，得以讓我們在每一次軟體發布後發現的問題數量從22個減少至9個以下，這比我們對這項計畫所定下的目標還要更少、更好。

為什麼使用模型化基礎設計？

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

我們開發的演算法需要結合具多種專業背景和訓練的工程師們的努力，包含電化學、數學、控制設計，以及軟體工程。我們知道模型化基礎設計可提供一個共同開發的平臺以及語言，讓參與設計的工程師們在這個平臺上進行協同設計。

可重複使用性也是我們決定採用模型化基礎設計的另一個關鍵因素。我們當時已經組構了一個元件函式庫，希望能把它們應用到Volvo BMS專案之內，同時也繼續開發這個函式庫，希望能重複利用並加速其他OEMs專案的開發。

到目前為止，這個核心函式庫已經被使用到Volvo開發專案中的五個各異的模型之中。有了這個核心函式庫，使我們花上比以往更短的時間，就能夠開發出一個不一樣的新模型，或甚至一個新的開發設計案。

開發AUTOSAR軟體元件

我們使用從上而下（top-down）的方法開始，在AUTOSAR編輯工具中進行系統架構建模以及定義軟體元件描述。隨後，把這些元件描述（以ARXML檔案匯出）匯入至Simulink中。

在Simulink和Stateflow裡面，利用稍早匯入過程中自動建立的骨幹模型，建立了BMS控制邏輯以及演算法行為的模型。我們也把Simulink模型裡面的訊號映射到在AUTOSAR元件描述中的訊號。在這個階段，藉由之前的專案組裝而來的核心函式庫，把Simulink元件重複使用在SoC（state-of-charge，充電狀態）估計、SoH（state-of-health，健康狀態）估計、控制邏輯、診斷邏輯等地方。接下來再加入客製邏輯以符合Volvo對這項特定計畫的要求，像是PHEV馬達仲裁邏輯（motor arbitration logic）等等。

在Simulink開發控制器模型時，我們頻繁地使用Model Advisor這項功能，來檢查模型是否符合AUTOSAR規範指南和建模標準的要求。也使用Simulink設計驗證工具來檢查模型裡面是否出現死邏輯（dead logic）、除以零錯誤，或者其他可能出現的設計錯誤。

LG Chem的電化學模擬團隊建立了一個電池組之電化學電池的數學模型，也把這個團隊的MATLAB程式碼整合到我們的Simulink受控體模型中，用來模擬控制器模型。

產生程式碼與自動化測試

最初的設計完成之後，接下來的目標是要讓程式碼實現、測試執行等剩下的工作流程盡可能地自動化，於是我們利用嵌入式程式碼轉碼器（Embedded CoderR）和嵌入式程式碼轉碼器中的AUTOSAR標準軟體支援套件，從控制器模型去產生符合AUTOSAR的C程式碼。

為了要驗證產生的程式碼，執行了SIL（軟體迴圈）測試的測試案例，強調三個部分：核心函式庫的元件、映射訊號、客製化的邏輯。

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

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

之後，我們把產生的程式碼佈署到目標嵌入式處理器中接著進行HIL測試，在此進行了整臺車輛的完整電子動力系統模擬。這些最終測試結果，也會導向客戶由他們去執行有效性測試。如果客戶的測試發現錯誤，我們可以利用測試log檔在Simulink重現問題，藉由模擬找出根本原因，並調整模型來解決問題。我們把廣泛的測試納入為工作流程的一部分，讓軟體問題的件數有效降低（圖1）。

圖2 : 採用模型化基礎設計前/後的軟體發布問題件數比較。

下一步

我們使用AUTOSAR和模型化基礎設計為Volve開發的電池管理系統，已經完成了ISO 26262功能安全—車輛安全完整性等級C（Automotive Safety Integrity Level C，ASIL C）的基礎認證。在開發專案的認證初期，我們手動完成大部份的認證任務，但將許多任務自動化之後，減少許多為了產生認證報告所耗費的寶貴資源。

現在，我們的團隊使用我們為Volve BMS建立的工作流程來為更多的汽車OEM客戶開發AUTOSAR軟體元件。

（本文作者Duck Young Kim、Won Tae Joe、Hojin Lee任職於LG Chem公司）