利用多目標建模技術降低ECU軟件成本

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

                                 圖2：數據字典例子。

                                 圖3：通用模型例子。

　　在建立通用模型后，Visteon公司的軟件工程師就要為他們需要的目標架構創建并換成特定的數據字典，然后使用這個數據字典進行仿真和代碼生成。然而，創建一個優秀的定點數據字典需要花很長的時間，這是因為在確定換算系數時需要做多方面的折衷考慮。工程師需要選擇能夠提供足夠精度但在已知范圍內的換算系數。如果換算系數的選擇不夠充分，那么當結果超過字長時可能發生數字上溢或下溢。

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

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

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

　　產品ECU程序的結果

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

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

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