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

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

據(jù)我的了解，很多互聯(lián)網(wǎng)大廠使用的就是敏捷開發(fā)，敏捷開發(fā)現(xiàn)在在國內(nèi)也越來越火熱。當然非管理崗位，很少會了解這些開發(fā)方法的細節(jié)，有興趣的讀者可以去學(xué)習(xí)一下。

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

V型開發(fā)流程 - From Internet

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

Overview of the ISO 26262 series of standards - From ISO26262

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

The waterfall methodology in MBD - From MathWorks

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

2 V型開發(fā)流程

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

V-model with MBD - From ST

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

**1. **需求定義

—— Requirements & Specifications

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

**2. **系統(tǒng)架構(gòu)設(shè)計

—— System & Architecture Design

**3. **組件設(shè)計

—— Components Design

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

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

—— Code Generation

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

—— Code Verification & Validation

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

**6. **系統(tǒng)集成測試

—— Integration Testing

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

**7. **驗收測試

—— Acceptance Testing

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

關(guān)于V型開發(fā)流程中會使用到的一些工具和工具鏈，后續(xù)會專門文章介紹。

3 MBD的模型迭代

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

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

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

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

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

MBD模型迭代 - From autoMBD

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

4 資源更新

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