1)需求分析

一般寫成需求文檔，系統工程師據此進行概念和算法研究，評估技術可行性。

缺點：由于每個系統工程師對需求和技術規范的理解難免存在偏差，因此會對后期的項目開發帶來諸多隱患。NASA的研究報告指出：在需求分析階段產生的錯誤占整個開發錯誤的50%以上。

2)設計階段

硬件開發工程師根據系統工程師的評估報告，設計制作原型樣機(如汽車、電路板等)。

缺點：項目前期投入巨大、開發周期長，且不能保證原型樣機一定能滿足技術指標要求。

3)實現階段

軟件開發工程師根據需求和技術規范，在原型樣機上，手工編寫C代碼或匯編代碼，實現技術指標要求。

缺點：需精通編程人員花大量時間來編程、差錯、調試、驗證，工作量大，研發周期長，此外，代碼良莠不齊，降低了程序可靠度。

4)測試與驗證

原型樣機開發完成后，對產品進行測試與驗證。

由上面四個步驟可以看出，只有任何一個過程出現偏差都會導致產品開發失敗，這也是傳統項目開發方法的最大弊端。因此，難免重復多次才能成功，開發風險巨大。

為解決上述缺點，工程師需找到一種速度更快、效率更高的產品開發方法，基于模型的設計方法就是一種選擇。它始于20世紀90年代初的汽車制造和航空航天工業，這些行業需要使用大量微處理器單元，因此工程師們發現采用建模與仿真的方法來開發嵌入式系統有著巨大優勢;到90年代中期，控制算法仿真技術的發展催生了自動代碼生成技術。模型仿真和自動代碼生成技術在這些行業得到成功應用，使人們清楚地認識到它在嵌入式系統開發中的經濟和高效。

基于模型的設計為工程師們提供了一種通用的開發與測試平臺，使具有不同工程背景的工程師之間建立起更好的聯系，使開發具有高集成度的復雜系統成為可能。

MathWorks的Simulink/Stateflow/Embedded Matlab等工具使工程師可以在一個可視化的交互開發測試平臺上進行基于模型的設計，用直觀的模塊圖對系統模型和子系統設計進行可視化處理。

1)可執行、跟蹤的技術規范

在基于模型的設計中，系統工程師先建立一個系統模型，即通過數學模型來精確描述用戶需求，創建一個可執行、跟蹤的技術規范。工程師可以通過這個系統模型，動態地確認系統性能。使每個工程師無歧義地理解并運行系統模型，專注開發模型各個部分，不會因理解不同造成需求丟失、冗余或沖突。

2)生成定點模型

系統模型與需求之間可建立雙向鏈接，在整個開發過程中，軟件工程師可對模型進行需求追蹤和測試，將產品缺點暴露在開發初期。根據具體嵌入式器件和實現條件，對系統模型進行細化和功能分區，進行系統測試、設計測試和模型助手測試，驗證是否滿足需求與技術規范，判斷是否還存在缺失的需求，驗證是否符合行業標準(如DO-178B、IEC-61508、MAAB等)，之后再對模型做定點轉換，形成簡潔、高效的定點模型。

3)嵌入式代碼自動生成

MathWorks的Real-Time Workshop Embedded Coder可以將Simulink/Stateflow中的模型自動轉換為嵌入式C代碼，大大降低嵌入式系統的開發門檻。開發人員可以在Simulink/Stateflow、Embedded Matlab中建立系統模型、構思解決方案，然后使用RTW-EC自動生成優化的、可移植的、自定義的產品級C代碼，并根據特定目標配置自動生成嵌入式系統實時應用程序。縮短開發周期，避免人為引入的錯誤。

4)連續測試和驗證

基于模型的設計在整個設計過程中都在不斷進行測試和驗證，工程師利用測試案例追蹤系統級模型和需求，檢測設計變更導致的系統輸出變化，并快速追蹤變更來源，通過測試案例還可以了解模型的功能覆蓋度。

對于嵌入式系統，還需要測試其實時性，工程師可以使用硬件在環測試嵌入式代碼的實時性。通過測試，收集實時數據，相應修改代碼參數。硬件在環檢測能確保在開發初期就完成嵌入式軟件測試，這樣在系統整合時，比傳統方法檢測得更徹底、更全面，從而及早發現問題，降低解決問題的成本。