mystar3323的部落格

多目標建模是一種電子控制單元(ECU)開發技術，它採用了基於模型的設計方法和自動嵌入式程式碼產生技術。利用多目標建模技術可以為各種嵌入式DSP、微處理器和微控制器設立算術模型，並實現程式碼的自動產生。軟體開發人員也因此可以節省許多時間和精力，因為他們不再需要為每個嵌入式目標元件編寫、測試和重編程式碼。

在這方面，Visteon公司正使用多目標建模技術開發動力控制系統。他們的方法以數據字典的製作為基礎，而數據字典用來控制模型模擬和嵌入式程式碼產生時使用的數據類型。利用這種方法可以模擬設計考量，並根據各種嵌入式處理器選項試驗各種處理器的演算法功能。模擬環境有助於設計師在軟體實現前就確定數據解析度和量化對系統性能的影響。一旦選好了合適的嵌入式處理器，程式碼就能自動產生和製作，並被整合進產品ECU。模擬和程式碼產生環境由MathWorks公司的Simulink及Real-Time Workshop Embedded Coder提供。本文將介紹使用多目標建模方法開發動力ECU的技術、工具以及因此帶來的好處。

人工多目標實現方法

支援各種硬體架構的傳統方法是人工開發程式碼。這些程式碼介面方便，並且很容易從一種架構改成另一種架構。這種方法的挑戰是，工程師很難將他們的浮點演算法轉換成定點設計。轉換過程要求提供各種變量和參數的換算係數和其它定點資訊。另外，也很難製作和維持這樣一種軟體層，它能以一種易用的方式提供高層演算法和定點軟體實現之間的足夠的抽象(abstraction)。

圖1：Visteon公司動力系統的多目標建模架構。

從浮點到定點架構的軟體設計和介面會給開發過程帶來其它問題，包括：

1. 設立換算資訊要花很長時間；

2. 測試定點上溢和下溢是一件很繁瑣的工作。每次數學運算都要求用最小和最大值進行分析和測試，才能滿足上溢和下溢檢查的需求；

3. 人工設計和編碼技術很容易出錯。

基於模型的多目標實現方法

在20世紀90年代，Visteon公司開始研究模型和自動程式碼產生在動力傳動系統中的應用。調查結果使Visteon公司決定從人工開發方法轉向模型設計方法。這種方法的轉換在過去六年中一直在進行，因為已有的手工編碼生產模組需要根據要求逐步轉換成Simulink模型。在這段時間內也導入了Real-Time Workshop Embedded Coder的自動程式碼產生功能。該功能已在ECU實現中用來從模型中自動產生程式碼。

目前模型設計方法已在汽車工業中得到廣泛使用，使用建模、模擬和自動程式碼產生的好處也已眾所周知。Visteon公司設立了完整的建模環境，可以協助設計師使用多目標、自動程式碼產生方法快速部署不同的硬體架構。該方法需要利用外部數據字典來約束從模型架構產生的程式碼的格式和結構。

模型設計環境

多目標模型與數據類型無關。最初模型使用的數據類型是主機執行模擬時可用的最大字長度(例如雙精密度實數)。這樣就提供了被建議演算法的理想行為。如果行為能令人滿意，就可以再增加特定的目標實現，使模型適合產品ECU的要求。

為了使模型符合特定目標要求，需要將數據字典和特定硬體資訊裝載進MATLAB工作區。同時提供數據字典和基準通用模型的鏈接機制。自動化換算工具可以使轉換和驗證過程更加便利。自動化程式碼產生就是將定點設計翻譯成產品程式碼的過程。接著Visteon公司工程師將軟硬體組件整合進最終的產品ECU中，以便今後進一步的驗證和確認作業。

圖2：數據字典例子。

圖1為Visteon公司動力系統使用的通用模型架構，並說明了如何使用多個數據字典實現特定目標細節。

一旦行為令人滿意，通用模型就被納入Visteon公司的配置管理系統中，並作為動力演算法庫中的一個組件放置在知識架上。工程師可以隨時透過再使用儲存在演算法庫中的模型組件製作新的演算法。

模型設計工具

Simulink公司透過使用訊號和參數數據對象支援針對數據字典的數據規格。可以利用加載進MATLAB工作區的外部數據字典確定數據對象。一旦開始模擬或程式碼產生，Simulink或Real-Time Workshop Embedded Coder就開始檢查模型中已被命名的訊號或參數在工作區中是否有對應的數據對象。如果工作區中存在對象，就可以在模擬和程式碼產生過程中使用數據對象的屬性。

圖3：通用模型例子。

圖2就是具有數據對象的工作區例子。可以賦於數據對象的數據屬性包括了初始值、數據類型、儲存類、描述、最小和最大值等。除此之外，還可以賦於定點屬性，如字長度、小數長度或二進制小數點、有符號或無符號等等。使用數據對象進行模擬和程式碼產生的通用模型如圖3所示。這些例子描述的技術並不代表Visteon公司專有的產品數據或模型。

在設立通用模型後，Visteon公司的軟體工程師就要為他們需要的目標架構製作並換成特定的數據字典，然後使用這個數據字典進行模擬和程式碼產生。然而，製作一個優秀的定點數據字典需要花很長的時間，這是因為在確定換算係數時需要做多方面的折衷考慮。工程師需要選擇能夠提供足夠精密度但在已知範圍內的換算係數。如果換算係數的選擇不夠充分，那麼當結果超過字長時可能發生數位上溢或下溢。

在選擇換算係數時自動換算工具被證明是非常有用的。這些工具能夠非常容易地確定模擬期間是否會發生上溢或下溢。圖4是來自Simulink定點用戶介面工具的輸出例子。在這個例子中，數據記錄顯示了模擬過程中訊號獲得的最小和最大值。在這種情況下，所有訊號都在範圍之內。如果發生上溢或飽和，數據記錄會標誌這一事件，因而促使設計工程師調查問題原因，並選擇新的正確的換算係數。

如果需要額外的保護，設計師可以使用由Simulink在模組參數對話框中提供的飽和設置在運算中增加上溢保護。飽和檢查對產生程式碼的效率來說非常重要，下面的結論部份將提到這一點。

產品ECU程式的結果

Visteon動力系統實現了用於發動機管理系統的產品化浮點和定點的應用。對開發過程來說最大的好處是顯著減少了時間和成本。在有個案例中，Visteon公司在三個月內就完成了ECU軟體的開發，如果採用手工編碼方案的話起碼要6個月。

圖4：自動換算工具和記錄結果例子。

與人工編碼相較，浮點自動程式碼的效率也有所提高，使用的RAM和ROM空間要少5%左右。定點自動程式碼效率幾乎接近手工編碼效率。在對導航程式中定點程式碼的初始分析過程中，Visteon公司將對前面討論過的飽和檢查進行確認，這將對定點程式碼效率起關鍵作用。如果每次定點運算都啟動了飽和檢查，那麼程式碼長度會有顯著增加。然而，如果像在手工編碼中做的那樣只在需要時做飽和檢查，那麼產生程式碼所需的RAM和ROM空間基本上等於手工編碼所需的空間。

另外需要注意的是，為了確保獲得高品質的程式碼，開發人員仍要使用靜態分析工具和MISRA檢查器對自動程式碼進行檢查。

作者：Walt Stuart

動力傳動嵌入式軟體經理

Visteon公司

Tom Erkkinen

嵌入式應用經理

MathWorks公司