作為一個小的知識拓展，這里先給出常見的開發流程（或稱為開發方法，Development Methodologies）：

• 瀑布流方法（Waterfall）
• V型方法（V-model）
• 迭代式開發（Iterative and incremental development, IID）
• 螺旋開發（Spiral）
• 敏捷開發（Scrum）
• 極限編程（Extreme programming, XP）

據我的了解，很多互聯網大廠使用的就是敏捷開發，敏捷開發現在在國內也越來越火熱。當然非管理崗位，很少會了解這些開發方法的細節，有興趣的讀者可以去學習一下。

從本質上來講，MBD可以使用所有的這些流程來開展工作。但實際中，V型開發流程用的最多。簡單的檢索一下，我們就能得到很多V型開發流程，就像下面這樣的：

V型開發流程 - From Internet

有一個問題可能很少有人去考慮過，那就是介紹MBD的時候，為什么大家都不約而同的選擇了“V型”？雖然沒有很嚴謹地查證過，但有一個較為可靠的解釋是，V型開發流程是來源于ISO26262的4、5、6部分，分別對應系統層、軟件層和硬件層，見下圖：

Overview of the ISO 26262 series of standards - From ISO26262

“V型”其實是相對于更加傳統的瀑布方法（Waterfall Methodology）而言的，MBD也可以使用瀑布方法來開展，瀑布方法一般長這樣：

The waterfall methodology in MBD - From MathWorks

但是瀑布流程并不符合MBD的開發思想，MBD有一個很重要的特征，那就是以模型為中心，反復驗證、測試和迭代，這一過程在瀑布流程中是難以實現的。*（MBD的這一特征和敏捷開發有點相似了，感興趣的讀者可以去了解一下） *

2 V型開發流程

MBD的V型流程形式有很多種，包括先后順序不同，執行內容不同等等。這種形式差異是正常的，實際項目開發中，擁有的資源和開發目標都不相同，是需要這種合理的調整和取舍。我認為ST的這張V型圖能較好的描述MBD的開發流程：

V-model with MBD - From ST

MBD V型流程的核心要素有以下幾點：

**1. **需求定義

—— Requirements & Specifications

• 項目開始的第1個階段是需求定義，需求定義要求詳細、具體，每一項需要有明確的驗證和測試方法。同時需求定義還要求可記錄，可追蹤，所以要求和模型建立硬聯系，即每一項需求有對應的模型來實現。要實現需求的追蹤管理，就需要借助工具了（例如MathWorks的Simulink Requirements工具）。

**2. **系統架構設計

—— System & Architecture Design

**3. **組件設計

—— Components Design

• 上述第2、3點即分層級的建模過程，在這個階段實現相應的算法，或者狀態機，或者其他函數API。這個階段還可以實施的是MIL（Model In the Loop），即沒有生成代碼之前驗證模型的有效性。
• 如果有足夠的資源，還可以在代碼生成之前進行RCP（Rapid Control Prototyping）。RCP使用的是原型控制器（非最終形態的產品），一般情況下原型機的性能會高于落地的產品，所以它的驗證能力有限，比不上HIL（Hardware In the Loop）。

**4. **自動代碼生成

—— Code Generation

**5. **代碼測試和驗證

—— Code Verification & Validation

• 第4、5點是代碼的生成和驗證，Verification和Validation的中文都可以翻譯成驗證，但它們的著重點不同：Verification是過程，Validation是結果，表示是否有效。具體地，Verification就是SIL（Simulation In the Loop）和PIL（Processor In the Loop）；Validation就是SIL和PIL的驗證報告。
• 如果算法中需要用到定點數，那么在SIL和PIL之前需要對模型進行定點化。一般來說PIL的驗證能力能覆蓋SIL，如果控制系統不復雜，可以只進行PIL。

**6. **系統集成測試

—— Integration Testing

• 第6點的系統集成測試即HIL（Hardware In the Loop）測試，關于HIL，以后再開新的文章具體談一談。

**7. **驗收測試

—— Acceptance Testing

• 最后，HIL測試通過以后，就可以給客戶驗收了。

關于V型開發流程中會使用到的一些工具和工具鏈，后續會專門文章介紹。

3 MBD的模型迭代

如果一帆風順的話，上述V流程只走一遍就可以了。但往往事與愿違，在項目前期很難考慮得非常周全，前期的需求有遺漏或者錯誤，就需要及時修正，我們知道越在后期，修改前期錯誤的成本就越大。

這時就能體現出MBD相比于手寫代碼的巨大優勢。因為MBD是圍繞模型展開的，所以修復遺漏和錯誤也是通過模型修改來實現的。由于模型的圖形化和結構化，使得能很方便、直觀地進行需求更新和算法修改，而不用一行一行的檢查代碼。越是項目規模大，越能體現這種優勢。

為了更好的說明MBD的模型迭代，這里把V型流程分為兩個階段：

• 代碼生成前——建模階段；
• 代碼生成后——驗證階段。

那么MBD模型的迭代是如下進行的：

MBD模型迭代 - From autoMBD

從上圖可以看到，算法迭代和需求的更新都是是圍繞著模型展開的，而將需求定義、建模和測試驗證串聯起來的是需求追蹤。這樣就在模型和需求之間打通了回路，形成了良好的反饋糾錯和正向促進。

4 資源更新

資源中更新了ISO26262的英文文檔（2018版part 1~12）和中文文檔（2011版），聊天界面點擊MBD->資源即可獲得。