AUTOSAR現在已成為車用軟體的設計與實現的產業實際標準（de facto industry standard）。有鑑於AUTOSAR的開放、標準化的軟體架構能幫助OEMs與供應商們在專案上進行合作，因為大部分的應用邏輯可以實現在應用層內的軟體元件（software components，SW-C）上，並與標準的運行環境層（run-time environment，RTE）介接，而不是在ECU硬體上實現（圖1）。
當我們團隊進行的某些AUTOSAR專案，其中一組須在RTE上層的應用層執行SW-C，而其他專案可能會需要通過在RTE層內運作的複雜裝置驅動（complex device driver，CDD），直接介接到ECU微控制器。
從過往歷史來看，CDD的開發代表著更大的工程挑戰，因為CDD的程式碼除了必須與RTE互動之外，還需要與RTE下層的基礎軟體（basic software，BSW）層互動。
我們使用模型化基礎設計（Model-Based Design）來進行SW-C的開發已經有一段時間了。模型化基礎設計支援了完善且成熟的工作流程，在這裡面，由AUTOSAR認可編寫工具產生的軟體元件描述ARXML檔案被用來建立初步的Simulink設計呈現。我們最近和MathWorks進行顧問服務專案合作，將我們在這方面的能力擴展至CDD開發。現在，與其用人工手動編寫CDD軟體程式碼，我們改採用模型化基礎設計來進行SW-C和CDD的開發。
使用相同的工作流程和工具組進行兩種不同型態的AUTOSAR軟體開發，不僅能降低成本、訓練時間、和花在其上的經常性維護資源，也讓我們能夠很容易地在SW-C和CDD團隊之間進行工程師的調度。更重要的是，使用模型化基礎設計於所有AUTOSAR專案，我們已縮短了至少50%開發時間，同時在設計早期階段能夠發現的設計瑕疵數量也增加了，且在硬體測試階段之後所發現的瑕疵數量也因此減少。
一個由上而下的元件設計方法
利用AUTOSAR編寫工具－DaVinci Developer，我們定義出軟體元件架構及介面，接著匯出軟體元件描述的ARXML檔。接下來，我們採取由上而下的開發方法，將這些檔案匯入至Simulink中，建立一個包含所有如同在DaVinci Developer定義的介面設置的骨幹模型。
我們以這個骨幹模型作為基礎，在Stateflow中建立應用控制邏輯的模型和進行模擬（圖2）。把Simulink模型中的元素連結到相關的設計規格，該設計規格係由IBMR Rational DOORS進行管理。這種方法能夠建立可追蹤性，能夠支援衝擊分析（impact analysis）和認證所需要的文件活動。
程式碼生成與驗證
在執行模擬來檢查初始的設計之後，我們會執行正式的測試。從前，若單單只用MATLABR程式腳本作為AUTOSAR專案的驗證套件，雖然這一個內部的架構能夠良好地運作，不過仍會需要花費相當大的心力來開發和維護。
現在透過MathWorks顧問的協助，我們評估以Simulink測試工具箱（Simulink Test?）作為另一種設計選擇，我們發現，Simulink測試工具箱不但提供了和MATLAB程式腳本相同的測試功能，還能減輕維護上的負擔。
我們現在利用Simulink測試工具箱來定義測試套件及測試案例，並且將產生測試器具的過程自動化（圖3）。首先執行基礎測試，在這裡將模擬結果與期望的結果作比較。但是，仍然會執行搭配軟體迴圈（software-in-the-loop，SIL）版本模型的等效測試來做進一步的驗證。
| 圖3 : 透過Simulink測試工具箱產生的測試器具樣本。 |
|
接下來執行的以模擬為基礎的測試，我們會透過嵌入式程式碼轉碼器（Embedded Coder）從我們的模型產生符合MISRAR的C程式碼。所產生出來的是已經準備好、且可在目標硬體RenesasR微控制器上使用的程式碼，而且不需要任何的後處理。作為驗證流程的一部分，我們會利用PolyspaceR靜態和動態的程式碼分析工具收集程式碼度量，並且檢查是否出現除以零、溢出、以及其他執行階段錯誤。
開發時間更短、品質改善、還有其他優勢
使用模型化基礎設計來進行AUTOSAR CDDs和SW-Cs的開發，對我們帶來顯著的改善，從而為IDNEO公司的事業各方面帶來很大的商機，例如與客戶的合作。如果我們的客戶也在使用Simulink，我們可以直接透過模型來合作，這樣能夠消除自然語言既定會存在的模棱兩可，而且可以將開發時間縮短至一半。
除此之外，當具備使用模型化基礎設計來開發CDDs的能力，而不是以人工撰寫程式碼來開發，我們能夠有更大的彈性去符合客戶的需求，因為我們可以視特定的使用案例來決定要單獨使用SW-C、CDD，或者兩起一起使用來進行功能的實現。
有的時候，客戶提供已開發的AUTOSAR元件給我們，並且希望我們可以把這些元件整合至更大的系統，而這個系統可能還包含其他第三方元件。在這種情況，我們使用元件介面的ARXML定義來簡化整合的流程，也讓開發時間縮短了70%。
比起以往領域相似、但未使用AUTOSAR和模型化基礎設計的專案，現在我們產品開發到上市的時間縮短了許多—以某些例子來說，可從一年縮短為六個月。此外，我們可以更早偵測到錯誤，讓我們可以在設計階段找出並修正80%的錯誤，而不是到了硬體測試階段才發現。
我們現在準備要更精煉模型化基礎設計的工作流程，藉由持續的整合與採用最佳實踐方式，讓此工作流程變得更為敏捷。我們在將Polyspace測試合併到Jenkins持續整合（continuous integration，CI）中獲得很大的進展，未來也計畫要在近期之內將測試套件從Simulink測式工具箱整合至我們的Jenkins CI管道。
（本文由鈦思科技提供；作者Enric Valencia、Joan Albesa任職於IDNEO公司）
