聊聊MBD開(kāi)發(fā)流程

作為一個(gè)小的知識(shí)拓展，這里先給出常見(jiàn)的開(kāi)發(fā)流程（或稱為開(kāi)發(fā)方法，Development Methodologies）：

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

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

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

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

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

Overview of the ISO 26262 series of standards - From ISO26262

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

The waterfall methodology in MBD - From MathWorks

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

2 V型開(kāi)發(fā)流程

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

V-model with MBD - From ST

MBD V型流程的核心要素有以下幾點(diǎn)：

**1. **需求定義

—— Requirements & Specifications

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

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

—— System & Architecture Design

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

—— Components Design

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

**4. **自動(dòng)代碼生成

—— Code Generation

**5. **代碼測(cè)試和驗(yàn)證

—— Code Verification & Validation

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

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

—— Integration Testing

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

**7. **驗(yàn)收測(cè)試

—— Acceptance Testing

• 最后，HIL測(cè)試通過(guò)以后，就可以給客戶驗(yàn)收了。

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

3 MBD的模型迭代

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

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

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

• 代碼生成前——建模階段；
• 代碼生成后——驗(yàn)證階段。

那么MBD模型的迭代是如下進(jìn)行的：

MBD模型迭代 - From autoMBD

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

4 資源更新

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