MATLAB 簡化了線性控制設計，但是在實際應用中，系統很少是線性的。因此，即使在設計了控制器后，對其進行測試和調整仍然意味著需要構建系統的硬件原型，并對算法進行編碼。或者，因為沒有樣機而無法進行測試，只有等到開發流程后期才能開展測試活動。

    為了將算法應用到硬件之前驗證這些算法，工程師們借助數值技術來仿真控制算法對系統（也稱為“對象”）的控制行為。控制工程師們學習編寫 C 或 Fortran 程序來嘗試構建系統模型，借用他們認為可能會適用于其系統類型的數值積分例程，在系統模型程序中復制其控制算法，并仿真整個系統。如果要使系統完全正常工作，那么整個仿真-開發流程需要耗費大量時間并且極具挑戰性。

    The MathWorks 在 1990 年發布了Simulink，一種用于對動態系統進行建模和仿真的軟件環境。在控制設計中使用 Simulink 可帶來兩大好處。首先，該軟件提供了一種直觀的框圖環境，可用于對算法和對象以及可能影響系統行為的非線性實際效果進行建模。其次，該軟件包括一個基于一流數值積分方法創建的仿真引擎。這些核心功能極大地簡化了控制工程師通過仿真來驗證控制算法的工作。但是控制工程師們仍然必須在較后對算法進行編碼，以在硬件樣機或實際系統上測試這些算法。

    大約五年后，隨著 Simulink 模型自動代碼生成的推出，此流程變得簡單得多。對于調試和測試在原型系統中運行的代碼，控制工程師們不必再擔心將算法模型轉換為代碼時出現錯誤。

控制工程發展的下一步曾是個很大的挑戰：產品級的代碼生成。快速原型代碼通常包含許多調試例程、數據收集代碼、主機-目標通信代碼以及用于交互測試的其他補充代碼。一般而言，這些代碼的優化程度不足以將其運用在可交付使用的系統中。代碼生成工具經過改進后，可以生成高效率的代碼，足以部署到產品級嵌入式系統中。今天，許多行業都認為從控制模型自動生成產品級代碼是較佳的做法。

Model-Based Design（基于模型的設計）

     處理器速度和內存的快速增加有助于在桌面上開發建模、仿真和代碼生成工具，同樣也使嵌入式軟件開發人員可以改進嵌入式控制器的功能和復雜性。此步驟繼而推動了這樣一種需求：即使用文本編輯器和調試器的傳統代碼開發技術不再是一種局限，未來的設計將以模型為中心。這種以模型為中心的開發方法稱為 Model-Based Design（基于模型的設計）（圖 1）。

圖1：以模型為中心的開發方法稱為 Model-Based Design（基于模型的設計）。

     通過基于模型的設計，團隊可根據書面需求使用模型開發其設計。由于采用了仿真引擎，因此這些模型成為“可執行的規范”。對于開發和檢查規范的團隊而言，“規范可執行”是個極大的好處。檢查完高級模型后，可使用設計詳細信息修改模型，以便將其轉換為代碼。從詳細設計模型自動生成代碼極大優化了實現過程，并避免了從設計到代碼轉換過程中引入錯誤的可能。

     傳統的嵌入式控制系統的開發過程和V 型圖一致（圖 2）。

圖2：傳統的嵌入式控制系統的開發過程和V 型圖一致。

        此過程使所有驗證和測試都位于 V 型圖右側，即完成設計和實現之后。對于基于 C 代碼的傳統嵌入式控制開發流程，集成測試通常在其他形式且級別逐漸提高的測試（例如硬件在環測試以及全系統測試）之前。雖然此開發順序有助于組織復雜的系統設計，但還是有一些缺點：該順序直到開發末期才考慮驗證和測試，而此時修復所找到的任何錯誤都要付出較高代價且較耗時；用戶必須實現所有組件后才能測試系統；并且該順序未能考慮開發過程中的迭代。

      通過基于模型的設計，可以將驗證作為并行活動，貫穿整個開發流程（圖 3）。

圖3：通過基于模型的設計，可以將驗證作為并行活動，貫穿整個開發流程。

       在開發流程的每一步進行測試和驗證，意味著可在引入錯誤之處發現這些錯誤。與傳統的 V 型圖流程相比，可以更快地重復、修復和驗證設計。那么該如何著手實現早期驗證，從而減少在開發末期花費在測試和調試設計上的時間呢？下文概述了一些較佳做法。

模型驗證和確認

       基于模型的設計實現驗證和確認的主要方式是通過在仿真的過程中進行測試。雖然許多組織都進行某種形式的建模，但是大多是以專門的方式應用仿真，因此無法在較大程度上實現潛在的驗證好處。單靠仿真無法發現所有錯誤；但這是一個巨大的進步，您幾乎在開始設計模型時就可以進行仿真。建模環境中的迭代快速且方便。

      對各個組件進行建模非常有用，可能是完成復雜設計所必需的；然而，不要因為這種優勢，就不再對將在其中運行組件的系統或環境進行建模。通過在單一環境中對整個系統進行建模，您可以快速了解組件功能與其他組件的交互方式，以及集成組件在已部署的系統或環境中的行為方式。可能會發現對組件或其他方面的遺漏需求。通過使系統模型還原為迭代一個組件時的狀態，可以評估設計迭代對系統功能的影響。

       與設計和開發同時進行測試有助于檢測出潛在問題，并可顯著減少修復這些問題的成本和時間。通過在開發模型期間考慮測試，可使設計更適合于進行測試，從而確保可對設計進行完整測試。此原則的應用范圍遠不止嵌入式系統領域，但是嵌入式系統開發人員卻常常忽視了此原則。原因是用戶以為可以在軟件中完成任何事情，也可能是文檔化的開發流程忽視了此原則。然而，與新型靈活的軟件開發流程一樣，在設計模型之前或與設計模型并行開發測試是較佳做法。

       幾乎每種測試方案都涉及到某些變數：輸入、對象參數、環境因素或其他要素。時間和開支通常限制了測試方案的靈活度；然而，通過在仿真環境中進行測試，您可以更加快速且并行（如果處理能力夠用）地仿真測試案例。在仿真中探查整個參數空間還可以縮小要實時運行的關鍵測試的范圍。

      每個組織都有針對設計和實現的標準或較佳做法。這其中有許多標準并未形成文檔，但是卻被關鍵人員銘記在心。使標準書面化并將標準檢查加入模型開發流程是很簡單的做法，但卻可以產生巨大的影響，因為這樣做可盡早減少“愚蠢”錯誤的數量，確保模型在團隊成員之間共享時更具可讀性，并且更加容易在將來進行維護。對標準進行建模可以非常簡單（如驗證所有輸入和輸出是否已連接），也可以非常復雜（如是否滿足行業標準）。關鍵在于開發一致的檢查，然后在整個組織中推動對這些檢查的遵從性。

       確定測試組件何時能夠滿足需要通常不僅是一門科學，更是一門藝術，因為您通常要根據設計或測試工程師的判斷來確定。對于軟件組件，許多團隊使用代碼覆蓋率作為更客觀的標準來衡量測試的完整性。您同樣可以將模型覆蓋率用于模型測試。覆蓋率用于衡量您在測試過程中測試了模型中（或源代碼中）的多少邏輯。修改的條件/決策覆蓋率是一種針對覆蓋率的嚴格衡量標準，得到廣泛接受。

     大多數質量標準的核心原則是進行文檔化。把需求，流程。結果記錄下來。如果不進行記錄，則不可能跟蹤做過的事情；不可能向別人（如客戶）證明您滿足了他們的需求；也不可能重復您的結果。雖然記錄通常很單調乏味，但是有許多工具可通過生成標準報告，來幫助自動記錄活動。在您以后發現問題或希望重復使用設計時，良好的記錄可幫助您節省時間，這也是非常重要的。

代碼驗證

       這些做法是在模型級別開始早期驗證的良好起點。較后，需要實現并部署到產品化硬件上。此時，代碼驗證成為重點。基于模型的設計可以提供哪些幫助呢？

       自動代碼生成是一種非常有用的方法。通過在模型級別驗證您的設計，然后直接從模型生成代碼，您只需要驗證模型和代碼是否等效。這是一種理想狀態的工作流程。在實際情況中，有時不可能從模型生成需要的所有代碼。您可能使用傳統流程開發了一些中間件和設備驅動程序代碼，或是可能將舊有代碼用于某些功能。對于這些情況，可通過一些其他的較佳做法來驗證代碼。

      用戶幾乎可以在任何位置測試硬件；然而，硬件通常沒有與仿真中的測試有連接。許多因素都可能導致這種沒有聯系的情況：在硬件上運行測試的小組與對設計建模的小組不是同一批人，在實驗室中運行的軟件與設計中的軟件也不相同。然