基于模型的設計 （MBD） 通過仿真測試執行驗證和確認。盡管許多組織使用某種形式的建模，但太多的組織以不利用潛在驗證優勢的特殊方式應用模擬（參見圖 1）。

圖 1：整個開發階段的故障傳播成本說明了一些組織如何沒有利用仿真的驗證優勢。

為了最大限度地發揮 MBD 的優勢，成功的組織實施了四種有助于完成早期驗證的關鍵實踐：

· 在規范階段創建和模擬高級系統模型。在 MBD 中，系統模型用作可執行規范。該模型的早期模擬突出了不完整和不一致的要求和規范。

· 從第一天開始就使用多域模擬進行測試。通過開發多域模型和執行閉環仿真，工程師可以在產品創意成型的同時開始測試。這些仿真使工程師能夠研究系統的所有方面，包括算法、組件、工廠模型和環境。

· 創建對系統施加壓力的虛擬測試套件。仿真使工程師能夠進行一系列難以或不可能在嵌入式系統本身上執行的測試。像所有測試一樣，這些測試應該盡早運行。

· 在整個開發過程中使用模型和測試套件作為參考設計。構建良好的模型可以在整個開發過程中使用，然后再用于未來的增強和衍生設計。

這些實踐應作為四個維度并行使用，以成功使用 MBD 進行早期驗證。

創建和模擬高級系統模型

作為可執行規范，高級系統模型必須反映系統的抽象行為。該模型可能不包括完整的接口定義，但它必須指定系統的動態行為。在需求規范階段模擬系統行為有助于確保團隊對系統需要做什么有一個完整和共享的理解。

使用 MBD，工程師首先使用子系統或離散狀態組裝架構。這些子系統內的動力學最初應使用最簡單的方法進行建模。在此活動的同時，其他工程師可以創建場景或形式化需求，為盡早測試動態做準備。

運行第一次測試時，建模功能行為的工程師將更多地了解系統和需求的真正含義。同樣，創建測試場景或形式化需求的工程師將了解需求是否一致和完整。每一組應將他們的發現傳達給另一組，以確保沒有誤解。

從第一天開始使用多域模擬進行測試

系統行為不僅由嵌入式控制軟件定義，還由電子和機械組件定義，包括連接的傳感器和執行器。執行架構的早期模擬在使用工廠或環境模型在閉環中執行時提供了更多的洞察力。

與開環仿真或在實際工廠硬件上進行測試相比，帶有工廠模型的閉環仿真具有多個優勢。一個優點是模型比金屬、電線和 C 代碼更容易更改。帶有工廠和環境模型的閉環仿真降低了多個開發階段的成本。與由鋼、電線、電路和其他硬件構建的機械和電氣設備相比，模型更容易重新配置和復制。工程師可以在物理模型的版本之間快速切換，而不會產生制造成本。通過簡單地更改桿的長度或電動驅動器的最大扭矩等參數，團隊可以評估權衡并針對成本、速度、功率和其他要求優化整個系統。

系統級優化需要多域仿真。通過一次調整一個參數來優化當今復雜的系統是不可能的。為了以最低的材料成本提供最高的能源效率和最高的性能，工程師必須優化整個系統，而不僅僅是嵌入式軟件。

工廠模型提供了系統的另一個視角。對系統的非軟件部分進行建?？梢宰尮こ處煆牧硪粋€角度了解系統行為。工程師通?？梢酝ㄟ^仿真而不是從真實系統中了解更多關于系統動力學的信息，因為仿真提供了力、扭矩、電流和其他在實際硬件上難以或不可能測量的值的詳細信息。

創建工廠模型需要工程努力，但這種努力往往被高估，而工廠建模提供的價值卻被低估了。在開發工廠模型時，最佳實踐是從高級抽象開始并根據需要添加細節。選擇一個足夠詳細以產生所需結果的抽象級別可以節省建模工作和仿真時間（參見圖 2）。

圖 2：作為基于模型的設計一部分的早期驗證通過建模、仿真和自動代碼生成簡化了嵌入式控制設計。

創建對系統施加壓力的虛擬測試套件

高效的測試需要關注點分離。組織應該在不同的開發階段測試軟件實施的不同方面。在測試算法之前測試通信和硬件效果會導致難以隔離和識別設計中的缺陷來源。

在最合適的地點和時間應用測試，使團隊能夠在每個開發階段的正確級別上評估設計。在每個階段，測試結果都應立即反饋給開發人員，以使設計能夠持續改進。

功能測試涉及使用多域環境模型模擬控制器模型。功能測試中使用的測試向量基于形式化要求或記錄的駕駛操作等場景。這些測試向量可以重復用于回歸測試和完整的模型覆蓋測試。

快速控制原型 （RCP） 為測試方案增加了實時驗證和用戶體驗。RCP 可幫助工程師快速部署算法并在車輛中對其進行測試，以確定功能是否正確。在目標快速原型設計和功能快速原型設計平臺的支持下，RCP 可以成為設計理念的豐富來源，但不應作為驗證功能的主要方法。

穩健性測試旨在評估系統在軟件參數變化、制造過程差異、機械和電氣硬件在系統生命周期內退化以及類似影響的情況下的穩健性。最佳實踐是在虛擬系統（包括控制器和環境）上運行參數掃描。隨著對系統在邊界條件下的性能有了更透徹的了解，工程師可以選擇縮小硬件供應商的規格范圍，或者得出結論認為具有稍高差異的較便宜的部件可以滿足他們的設計需求。

硬件在環 （HIL） 測試使工程師能夠在實驗室而不是在真實環境中測試真實的控制器或控制器網絡。HIL 測試可用于測試穩健性（例如，通過插入故障）或診斷大型控制器網絡中的控制器間通信。它涵蓋了無法輕松建模的硬件和通信效果。

與 RCP 一樣，HIL 測試是系統驗證所必需的，但不應將其用作功能測試的主要手段。這是因為 HIL 測試是在非常低的抽象級別上進行的——接近真實系統——因此結合了許多不同的影響，阻礙了有效的功能測試。

HIL 測試需要對硬件進行投資，范圍從帶有專用數據卡的標準 PC 到高端硬件機架。在這樣的系統上執行的測試比在純軟件中執行的測試更少，因為軟件測試可以更容易地在多臺計算機上復制。這是確保在 HIL 測試之前驗證功能的另一個原因。如果工程師在 HIL 測試中發現算法缺陷，那么上游驗證過程可能是不夠的。

使用模型和測試套件作為參考設計

在 MBD 中，所有關鍵開發任務都在模型級別執行。這意味著對生成的代碼所做的任何修改也必須在模型中進行。在整個開發過程中使用模型和測試套件作為單一的事實來源，可以促進模型和測試的清晰溝通和有效重用，不僅適用于當前項目，而且適用于未來的增強和衍生設計。

將所有工件置于配置管理之下

軟件工程師認識到配置管理系統 （CMS） 中版本控制代碼的價值。MBD 中的關鍵工件——模型、測試和模擬結果——也應該在 CMS 中維護。在 CMS 中管理工件使團隊可以輕松地重新運行虛擬測試并將當前測試工具與以前的模型狀態或以前的測試向量進行比較。

當模型結構是模塊化的而不是單一的時，版本控制模型效果最好。模塊化模型結構還可以通過允許多個工程師并行處理同一系統的不同部分并啟用并行代碼生成來加速開發。

執行回歸測試

軟件工程師使用夜間構建來編譯和測試源代碼的最新版本。這種方法也應該應用于建模和仿真。一旦工程師定義了一個新的測試來驗證特定的模型行為，該測試應該集成到夜間構建中，以確保特定行為在所有后續建模迭代中仍然有效。如果測試在某個時間點失敗，則要么已識別出缺陷，要么功能已從根本上改變，并且測試不再適用。

盡早并經常驗證

本文中概述的最佳實踐使工程師能夠實現早期驗證，減少在開發周期結束時花費的時間測試和調試他們的設計。此過程的關鍵是 MBD，它可以將驗證用作在整個開發過程中發生的并行活動。在開發過程的每個步驟中執行測試和驗證意味著在引入錯誤時發現錯誤。與傳統流程相比，可以更快地重復、修復和驗證設計。

作者：Guido Sandmann，Joachim Schlosser，Brett Murphy

審核編輯：郭婷