全文約1814字，你將看到以下內(nèi)容：

• MBD開發(fā)流程概述

• V型開發(fā)流程 

• MBD的模型迭代

• 資源更新

1 MBD開發(fā)流程概述  

上一期我們閑聊了MBD的拓?fù)鋱D，這期我們聊聊MBD開發(fā)流程。作為一個(gè)小的知識(shí)拓展，這里先給出常見的開發(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)也越來越火熱。當(dāng)然非管理崗位，很少會(huì)了解這些開發(fā)方法的細(xì)節(jié)，有興趣的讀者可以去學(xué)習(xí)一下。

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

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

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

Overview of the ISO 26262 series of standards - From ISO26262

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

The waterfall methodology in MBD - From MathWorks

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

2 V型開發(fā)流程

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

V-model with MBD - From ST

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

1. 需求定義

—— Requirements & Specifications

• 項(xiàng)目開始的第1個(gè)階段是需求定義，需求定義要求詳細(xì)、具體，每一項(xiàng)需要有明確的驗(yàn)證和測(cè)試方法。同時(shí)需求定義還要求可記錄，可追蹤，所以要求和模型建立硬聯(lián)系，即每一項(xiàng)需求有對(duì)應(yīng)的模型來實(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í)的建模過程，在這個(gè)階段實(shí)現(xiàn)相應(yīng)的算法，或者狀態(tài)機(jī)，或者其他函數(shù)API。這個(gè)階段還可以實(shí)施的是MIL（Model In the Loop），即沒有生成代碼之前驗(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是過程，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)化。一般來說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，以后再開新的文章具體談一談。  
  

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

—— Acceptance Testing

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

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

3 MBD的模型迭代

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

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

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

• 代碼生成前——建模階段；  

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

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

MBD模型迭代 - From autoMBD

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

4 資源更新

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

如果不出意外的話，下期將會(huì)介紹關(guān)于MBD的底層驅(qū)動(dòng)相關(guān)內(nèi)容，歡迎持續(xù)關(guān)注。

版權(quán)歸autoMBD所有，轉(zhuǎn)載請(qǐng)注明作者和來源。