本文翻譯的是Mathworks公司撰寫的Development of AUTOSAR Software Components with Model-Based Design，希望與大家一起共同學習進步，如有錯誤請大家指出。
摘要
本文展示了工程師如何在已有模型的情況下，在不需要進行模型修改的情況下，創建符合Autosar標準的件模型以及通過軟件組件的描述來創建Simulink模型。在介紹之前，本文介紹了基於模型的設計Model-Based-Design（以下使用MBD）與Autosar概念，並建立了一些術語來解釋爲什麼我們要將Autosar與Simulink相結合。
介紹
隨着整車內ECU數量以及單個ECU內軟件的複雜度的逐步增高，汽車軟件行業需要一個開放，標準的軟件架構來將未來整車、單個ECU內軟件的複雜程度限定在一個可以控制的範圍內。Autosar （Automotive Open System Architecture，汽車開放系統架構）就是這樣的一個組織，目前組織已經聯合了超過100個整車廠、零配件供應商、工具鏈供應商、半導體電子公司來爲未來的ECU共同建立一個標準架構。目前已經許多OEMS以及供應商已經開始在部分車內開發、整合、集合符合Autosar標準的功能組件。
Autosar2.1標準已經被許多公司視爲是一個較爲成熟的標準，其中對於指定的應用層軟件組件的概念與信息的定義已經成熟。許多工具鏈供應商紛紛開始結合自己的技術爲Autosar架構開發新的商業工具鏈。在2006年大衆公司已經成功使用MBD方法來設計符合Autosar標準的ECU並整合在已有的E/E電子電氣環境中。
爲了應對軟件、算法的複雜程度指數增加，汽車工程師開始使用MBD方法，這個已經在業內被廣泛接受。MBD可以在軟件早期開發階段提供明確、可執行的規範，自動V&V（Verification、Validation）以及自動代碼生成這些額外的優點使得開發效率顯著提高。
作爲ECU網絡的標準架構，Autosar在汽車行業變得越來越重要，儘管現階段大家只是將關注點放在標準的定義與完善，但許多OEMS以及供應商已經開始將Autosar納入未來軟件開發流程中。這就需要一系列完整的工具鏈，從上到整車級別的ECU的架構設計，下到使用MBD方法設計符合Autosar標準的功能組件，以及開發運行環境與基礎軟件。
基於模型設計
傳統的嵌入式軟件開發包括書面設計、手工編碼，以及如代碼檢查，單元集成測試等驗證工作。其中許多流程缺少工具的自動化需要手工完成，因此既耗時又容易產生錯誤。工具鏈的集成的缺失是另一個容易產出錯誤的方面，此類錯誤在軟件開發過程中往往探測較晚而且需要花費很大代價。
爲了應隊這些挑戰，MBD已經成爲汽車行業廣泛使用與認可的方法，仿真測試不僅可以洞悉系統的動態、算法方面，而且模型還有如下優點：
（1）作爲可執行規範
（2）交流軟件需求規範，爲顧客與供應商之間提供接口定義
（3）爲開發算法提供汽車系統以及駕駛員、環境、路況條件等模型提供虛擬原型
（4）產品的自動生成
這些MBD的活動使工程流程更加專注於防查錯以及錯誤的早期檢測。項目早期的V&V可以降低晚期發生錯誤帶來的風險。正如圖1所示，MBD使得模型位於開發流程中的核心，這樣工程師可以創建可執行規範，自動生成嵌入式代碼，在模型中執行V&V活動。
需求與代碼追溯
使用MBD開發嵌入式軟件始於客戶對軟件需求要求的大幅提高，工程師必須確保模型以及最終生成的代碼滿足系統需求。因此，需要關聯每一個需求至相應的模型部分，這種追溯能力是十分重要的。工程師搭建一個詳細的軟件設計模型，並通過持續不斷的V&V流程來確保所搭建的模型是滿足需求的！由狀態機以及基礎模塊組成的模型可以雙向直接鏈接到需求文檔或者需求管理工具中。測試用例（由工程師定義或者自動生成）也可以被直接鏈接到對測試覆蓋率的需求中。在開發的後期階段，生成模型代碼後，Mathworks公司的Embedded Coder可以產生代碼聲明與模型之間的鏈接，正如工業標準IEC61508、Aspice所規定的。
可執行規範，V&V
將需求文檔上的有關要求轉換成爲涵蓋所有相關功能模型，可以避免需求文檔所可能帶來的二義性，可以得到明確的接口定義。工程師可以在開發的早期階段驗證Concept的正確性。
通過這種方法，工程師可以在項目早期就進行測試與驗證工作。測試案例可以由工程師定義，也可以由工具自動生成MC/DC覆蓋率的測試用例。
另外，可執行規範使得OEM與供應商的交流變得更爲容易，因爲規範是可以執行的，是圖像化的。相比於傳統方法，MBD方法在更早的階段可以讓團隊完成一些重要任務。同時，MBD方法提高了產品質量，在項目早期儘可能得暴露錯誤，減小了修復項目後期錯誤所帶來的巨大成本。圖三爲每個階段修復錯誤所需要的平均成本。
自動代碼生成
例如通過使用Embedded coder可以自動將模型轉化成嵌入式代碼，這種平滑集成的一大優點就是可以重用已經生成與測試過的模型。在連續的V&V過程中，不斷髮現與修復bug，而測試軟件可以重新自動生成。
Autosar
爲了應對汽車行業裏電子電氣應用開發中日益增加的軟件複雜度，世界一流的OEM，供應商公司聯合在一起決定爲ECU定義一個標準架構，來應對未來軟件開發的挑戰。在2002年成立了Autosar組織以實現以下目標：
（1）基本系統功能的實現和標準化，並作爲OEM的標準解決方案
（2）不同的車輛和平臺之間的擴展性
（3）網絡功能傳輸
（4）不同供應商的功能模塊集成
（5）對可用性和安全性的考慮
（6）冗餘功能
（7）整個產品生命週期的可維護性
（8）增加商用現成硬件的使用
（9）整個汽車生命週期的軟件更新和升級
（10）增加商用現成硬件的使用
圖四展示了Autosar軟件架構，一共被分爲三個區域。應用層軟件包含ECU網絡的應用功能，被稱爲Autosar Software Component（後稱爲SC）。RTE層用於將應用層軟件從基礎軟件中解耦。控制器與RTE定義爲基礎軟件包括獨立、依賴於硬件的非功能服務。
正如上面提到的，解耦應用軟件與目標硬件是Autosar的主要目標之一，爲了實現它，引入了Virtual Function Bus（虛擬功能總線，後稱爲VFB）。Autosar軟件組件實現應用層和封裝單個ECU與ECU網絡的功能。這些SC有着定義好的標準接口。每個Autosar SC屬於一個特定的ECU，而ECU可以有多個SC。
VFB實現了不同Autosar SC之間的通信功能，不論他們屬於整車ECU網絡中的哪一部分。在實現階段，生成的運行時環境是虛擬功能總線的一個具體實例。
Autosar SC開發
MBD的概念在Autosar開發中可以發揮更大的優勢，而且應該被更多的使用。一旦公司決定遵循Autosar流程開發ECU，設計或軟件工程師不應該被迫改變他或她的工作流程，以生成符合AUTOSAR標準的軟件。
MATLAB，Simulink和Real-Time Workshop Embedded Coder生成AUTOSAR標準的代碼是透明和直觀的過程，它支持兩種不同的工作流程：自上而下和自下而上。
自上而下
自上而下，從架構模型到Autosar SC。在自上而下的開發流程中，系統工程師使用架構生成工具（如davinci tool suite）來設計整車ECU網絡。當然，工程師也可以使用其他的架構設計工具。架構軟件會輸出一個XML來描述對應的組件，該文件裏包含了組件的一些必要信息比如：runnables，接口，數據類型等等。Matlab軟件可以利用架構軟件生成的XML文件自動創建Simulink架構模型，裏面包含了接口模塊以及相應的Autosar相關設置。之後系統工程師就可以在該框架模型的基礎上，完善內部的控制模塊。
同時該模型可以像普通模型一樣照常進行V&V測試，設計工程師也可以對Autosar模型添加有關的接口或runnables。工程師必須在相應的地方進行設置來保證所生成的代碼滿足標準，來滿足基礎軟件層中的RTE以及與硬件相關組件的要求。這些設置可以在配置參數對話框中設置。
自下而上
自下而上，通過現有的Simulink控制模型來自動生成架構軟件所需的XML文件。因爲汽車產業已經非常成熟，許多公司已經有許都測試好的庫與模型。這些模型能夠重用到不同的平臺，比如Autosar架構中，而不需要對模型進行任何人力修改，這點非常重要。自下而上的工作流程，與自上而下的工作流程都需要相同的Autosar配置， 尤其是接口對象需要被正確設置，來保證SC可以被正確集成。
結 論
隨着汽車ECU軟件程度的複雜性增加，OEM與供應商聯合建立了行業中最大的標準——Autosar標準，這被視爲是應付軟件複雜性挑戰中的最重要的一步。Autosar專注於各SC之間的通信，並解耦了應用層軟件與基礎軟件。使用MBD方法設計功能軟件，由於這兩種方法的雙向性，MBD與Autosar不僅是相互兼容的，也是互補的。這種組合不僅方便了架構設計、系統設計工程師，也方便了OEM與供應商。