有關基于模型的設計(MBD)一些概念和理解

1、有關基于模型的設計（MBD）-些概和解先胡亂問幾個大問題：1. 么叫基于模型的設計？2. 為么要基于模型的設計？3. 基于模型的設計過程中，需要做么事情？再問幾個小問題：1. 模型驗證是否必要？2. 模型驗證有哪些工作可以做？3. 模型驗證是否一定需要被控;寸象模型？4. 代碼生成效如何？5. 底層驅動是否要建模？6. EmbeddedCoder（以前的RTWEmbeddedCoder）支持哪些芯片？7. MIL、SIL、PIL、HIL的目的和實現(xiàn)方式？8. 如何定點化？9. 如何做代碼集成？么叫基于模型的設計？這是一個很大的話題，因為本人能所限，僅討論使用Simulink模型開發(fā)嵌入式軟件的

2、設計過程。也就是說，我只能聊基于模型的嵌入式軟件設計。我的解是，通過寸算法建模進軟件設計的過程，可以叫基于模型的設計。當然，如果僅限于算法建模，把Simulink/Stateflow當做Visio使用，而去進其他環(huán)節(jié)的工作，這樣的基于模型設計是完整的，可能對你的開發(fā)效會有很大的提升。如果想通過基于模型的設計提升軟件開發(fā)團隊的開發(fā)效，提高軟件品質，我覺得至少有如下幾點可以考慮：1. 算法建模2. 算法模型的驗證3. 文檔自動化4. 代碼生成5. 代碼和模型的等效性驗證傳統(tǒng)的開發(fā)過程中，我們有一個環(huán)節(jié)，需求捕獲，也即，從系統(tǒng)需求分解出軟件需求。在基于模型的設計過程中，我們同樣可以通過分析系統(tǒng)需求，

3、獲得軟件需求。當然，根據(jù)系統(tǒng)需求的詳細程，我們可以考慮是否要寫專門的軟件需求。在基于模型的軟件設計中，我們主要關心的是系統(tǒng)的功能需求，或者說可以通過軟件實現(xiàn)的功能需求。如果這部分需求在系統(tǒng)需求文檔已經有非常清楚的定義，那么我們可以以系統(tǒng)需求文檔作為依據(jù)建模型。當然，如果系統(tǒng)需求是足夠清楚，那我們有必要編寫專門的軟件需求文檔。如果考慮Simulink/Stateflow的應用上的問題，也就是說，如果我們是熟練的Simulink/Stateflow用戶，那么建模過程的主要工作是需求分析，通俗點講，需求清楚，建模也就是非常簡單的事情。當然，建模的時候，要考慮夫夾的驗證、實現(xiàn)以及后期維護的問題。我個人

4、的體會，這個階段，要著急建模，一定要先清需求，另外，建模的時候，模型架構非常重要。有模型之后，接下來要做么事情？代碼生成？這是很多比較初級的用戶容犯的錯誤，犯這個錯誤的用戶，很大程上是因為沒有清楚為么要做基于模型的設計？到底可以為么要做基于模型的設計？我相信很多用戶沒有仔細考慮這個問題，很多用戶做基于模型的設計的由是：國外的公司這么做，同其他公司這么清為么要基于模型的設計，也就是要清楚基于模型的設計給我們帶來哪些好處?很多人會非常自然的想到，代碼生成，代碼生成可以提高軟件開發(fā)效。沒錯，代碼生成是一個很大的好處，但，代碼生成是唯一的，也是最大的好處。最大的好處是，算法的早期驗證，之前NASA有研

5、究表明，開發(fā)初期引入的bug，如果到晚期才發(fā)現(xiàn)出夾，那么修復這一的bug，會產生非常大的費用。所以，我們期望能夠盡早的發(fā)現(xiàn)開發(fā)過程中引入的bug。如何盡耳的發(fā)現(xiàn)設計上的錯誤？傳統(tǒng)的開發(fā)模式，我們使用review的方式去發(fā)現(xiàn)錯誤，在質體系ISO9001面有定義，任何一份設計，必須要評審。評審的目的，就是為發(fā)現(xiàn)這個階段的錯誤，以防錯誤被帶到后續(xù)的開發(fā)過程中。而評審的效，卻是非常低下的。我想凡是參加評審的網友會有體會。比如，我在做完一份設計之后，我會邀請我的同事夾評審我的工作，而參加評審的這些同事，往往能有足夠的時間解我的這份工作，而只能在評審會上聽我介紹我做的工作，這樣的評審，可能會發(fā)現(xiàn)一些非常明

6、顯的問題，除此之外的，很兔難發(fā)現(xiàn)問題。評審作為一種非常傳統(tǒng)的驗證方式，并能及時發(fā)現(xiàn)設計過程中引入的各種錯/誤。而仿真真是可以運的，如果我們設定一些輸入，運模型之后，我們會得到相應的輸,從效上講，要遠高于評審，仿真容發(fā)現(xiàn)設計中的問題。仿出，我們很容觀測到此時的輸出是否是我們期望的輸出。另外還有好處，仿真的結果是確定的，給定輸入，就會得到確定的輸出，當然，期望輸出也是確定的。而像評審，同樣的文字，對于同人，可能解成同的含義。代碼生成和早期驗證之外，基于模型的設計，還可以給我們帶夾其他好處，比如文檔自動化。我們經常聽到這樣的說法：我們終于把軟件發(fā)布出去，現(xiàn)在可以有時間補文檔下個月要audit，所有同

7、事在補文檔.這我要問：為么要補文檔？補文檔，我們可以從中得到兩個方面的信息：1. 文檔很重要，能沒有，至少從質體系上要求我們必須有文檔2. 工程師愿意寫文檔，是啊，如果愿意寫文檔的話，在開發(fā)過程中自然會把各類文檔寫起夾的。好，工程師愿意寫，開發(fā)過程中又能少，如果計算機可以幫我們寫，豈是很美好的事情?；谀Ｐ偷脑O計，可以幫助我們實現(xiàn)文檔自動化，至少有相當大的一部分文檔可以讓計算機替我們寫。其實，基于模型的設計，還有一個天然的優(yōu)勢：圖形化設計。對于工程師夾講，圖形化的東西，本身就比文字容解，否則我們在軟件開發(fā)過程中也會去畫程圖和狀態(tài)機Q所以總結一下，基于模型的設計可以從以下方面給我們提供：1. 圖

8、形化設計2. 早期驗證3. 代碼生成4. 文檔自動化前面我大概論述為么要做基于模型的設計，或者說基于模型的設計可以給我們帶夾哪些好處。這些好處，最終會大大提高開發(fā)效，并且改善軟件品質。下面，我在說說基于模型的設計有哪些事情要做，劉博士說的沒錯，基于模型的設計，自然模型最重要，如何建模，毫無疑問是最為重要的環(huán)節(jié)。在軟件產品開發(fā)中，建?；顒?，耗時最多的，就應該是需求分析，需求分析僅包括如何正確解軟件需求，而且要考慮如何通過模型實現(xiàn)，真正的畫模型的時間，相比之下并多，如果Simulink/Stateflow用的熟的話，真正打開MATLAB畫模型的時間占建模階段總時間的1/3到。建模之后，接下夾就是模

9、型驗證，驗證，英文單詞Verification，英文面還有另外一個詞Validation，確認，很多人清楚這兩個詞之間的區(qū)別，通俗點講：Verification是考察你是否正確的做一件事，而Validation，則是考察你是否做出正確的東西。一個強調的是過程，一個在乎的是結果。閑話少說，咱們繼續(xù)回到模型驗證上夾，通常模型驗證包含如下活動：建模標準的檢查、評審、單元測試、快速原型。（如果說的完善，歡迎大家補充）建模標準的檢查，可以通過模型檢查工具自動完成，建模標準檢查的意義，和傳統(tǒng)開發(fā)模式C編碼標準的意義一致，這展開。模型驗證之后，接下夾就可以做代碼生成，有關代碼生成，也專門討論吧。1. 代碼生

10、成之后，需要做代碼驗正，基于模型的開發(fā)過程面，SIL、PIL是常用的代碼驗證方式。2. 在代碼做完SIL或者PIL測試之后，要考慮軟件集成，即應用層軟件，也就是通過Simulink模型生成的軟件，和底層驅動軟件之間的集成。3. 軟件集成之后，后面的事情，基本上和傳統(tǒng)的開發(fā)模式差多，當然，相對于傳統(tǒng)的開發(fā)模式，你可以多一個HIL環(huán)節(jié)出夾，過話又說回夾，即是傳統(tǒng)的開發(fā)模式，也一樣可以有HIL這個環(huán)節(jié)的。有關HIL的實現(xiàn)及目的，以后再說。再說說模型驗證的必要性。我在進入MathWorks之后，接觸過很多客戶，少客戶在最初引入基于模型設計的時候，根本在意模型驗證工作，他們經常在模型編譯通過之后就拿去生

11、成代碼，有代碼之后將代碼下載到各種快速原型設備上去測試算法，Simulink的仿真功能基本上成擺設。并且在這個階段，管我如何苦口婆心的給他們介紹模型驗證的重要性，在他們那邊卻總有各種各樣的借口去模型驗證環(huán)節(jié)，"項目時間太緊，模型夾及測，“我們知道規(guī)范的開發(fā)程，但是現(xiàn)在人手夠。當然這類用戶經常在這樣折騰一段時間之后，還是要回到模型測試上夾，他們最終會發(fā)現(xiàn)，在HIL設備上測試算法，實在太難，當然，也有堅持的，堅持的結果就是他們所謂的基于模型的設計，開發(fā)效比傳統(tǒng)的開發(fā)模式高多少。其實，這個問題我們可以這么去看，模型階段的測試，我們是可以分模塊進的，而HIL上測試，基本上是集成之后的軟件。比

12、如，一個軟件有10個模塊，在HIL設備上，你很難分離出每個模塊的bug，而如果是按模塊做單元測試，則f具體的模塊。打一個算恰當?shù)谋确?，我們知道一塊2克的鉆石，價格肯定是一塊1克鉆石的兩倍。類似的，如果每個軟件模塊有2個bug，那么你從集成好的軟件去消除這20個bug，耗費的肯定是從每個單元模塊去消除bug所耗的總和。說白，早期驗證是非常重要的，很多軟件工程的教材有相關的統(tǒng)計數(shù)據(jù)說明早期驗證的重要性，對應到基于模型的開發(fā)過程，能在模型級別做的驗證，-定要拖到后續(xù)的環(huán)節(jié)中。中國有話，“心急吃熱豆腐，“項目時間緊或者“人手夠能成為我們忽模型測試的借口。繼續(xù)說一下MBD開發(fā)過程中有哪些驗證工作要做。模

13、型出夾并且可以編譯之后首先要做建模標準檢查這個過程使用工具（比如MathWorks公司的SimulinkVerification&Validation提供的modeladvisor）自動化的完成，檢查過后，修改模型中符合公司建模規(guī)則的項目。接下夾，就可以進模型評審，也就是說，評審的模型有兩個前提，-是可以編譯的，二是符合公司建模規(guī)則的。這兩個前提可以幫助我們消除模型中的一些低級錯誤，避免在評審過程中有太多的時間花費在這些錯誤上。因為評審是建模的工程師和其他同事共同參與的活動，做到上述兩個前提，也是-寸其他同事工作時間的一種尊重。評審之后，建模的工程師會修改評審中發(fā)現(xiàn)的問題，問題多的話，

14、一般會要求修改之后再進“再評審，直到在評審中會發(fā)現(xiàn)大問題。接下夾，我們可以使用SimulinkDesignVerifier進模型的結構分析，借助于SimulinkDesignVerifier自動生成測試用的功能，去檢查結構上是否存在問題，比如是否有合的邏輯設計，是否有運到的分支等。再往后，就可以進模型單元級別的功能測試。軟件開發(fā)過程中，寸單元測試的要求是很高的，一般會根據(jù)應用的安全性、可靠性要求，給出測試的覆蓋要求。這個過程中工作最大的應該是測試用設計以及測試向的生成。測試用設計，我們一般會根據(jù)需求去設計測試用，當然，也會結合模型結構設計測試用，這樣說夾，這的測試，已經包含黑盒測試和白盒測試。

15、有測試用，如何把測試用轉換為測試向，這也是非常重要的環(huán)節(jié)。我們知道，在MBD開發(fā)過程中，代碼可以自動生成，其他環(huán)節(jié)，我們要努做到自動化實現(xiàn)。我們可以使用MATLAB腳本開發(fā)一些轉換工具用于將測試用轉換為測試向，我們還可以通過腳本實現(xiàn)測試過程的自動化。測試的指標，即測試覆蓋是否達到公司的要求或者業(yè)的要求。單元級別的功能測試完成之后，我弋們自然會進集成測試，當然，集成測試是分階段、有步驟的，我們可以先把一些單元模塊集成為組件級，進組件級的集成測試，然后再將組件集成為系統(tǒng)級，進系統(tǒng)級測試。集成測試和單元測試關注的內容同，集成測試，我們關注于單元模塊之間的借口關系、調用關系等等，所以，單元測試中要求的

16、判定覆蓋、MCDC覆蓋等，在集成測試中沒有這樣的要求。條件允許的情況下，集成測試之前或者之后，可以通過快速原型的方式和實物相連，進測試。集成測試通過之后，我們基本上可以認為模型或者說算法是正確的。接下夾，我們就可以進代碼生成。代碼生成之后，會跟著做SIL、PIL、HIL等測試，所有這些In-the-Loop測試是必須的，工程師應該根絕項目的實際情況，選擇合的測試方案，當然，建議SIL測試要，原因在于這種測試的確非常方做，并且也的確會發(fā)現(xiàn)一些代碼生成過程中出現(xiàn)的問題。前面提到模型驗證，下面再說說代碼生成。代碼生成的前提是模型已經是驗證過的模型，或者說，是正確的模型。正確的模型包含兩層含義，模型做

17、過足夠多的驗正驗證的結果是正確的。前面提到的各種驗正方式，有必要做，對于功能測試夾講，還有必要達到足夠高的覆蓋率要求。做到以上這些,就可以考慮進行代碼生成工作了5代碼生成是否就是按一“CodeGeneration”按鈕的工作呢？工程項目開發(fā)中，沒那么簡單，代碼生成過程中，工程師要做的主要工作是數(shù)據(jù)管理工作，除此之外，還會有一些代碼相關的配置，比如函數(shù)原型、比如代碼文件等等。數(shù)據(jù)管理主要貯寸Simulink/Stateflow模型中的兩類數(shù)據(jù)進行管理，-是信號，一是參數(shù)"寸應于C代碼，我們可以簡單的把信號寸應到變量上，而參數(shù)，則是不通過程序運行而發(fā)生變化的，參數(shù)的變化，一般是通過人工調

18、節(jié)完成的，也就是參數(shù)調節(jié)，參數(shù)調節(jié)的目的是為了選擇合適的參數(shù)以得到最佳的性能。數(shù)據(jù)管理的方式，使用的是數(shù)據(jù)寸象進行數(shù)據(jù)管理，這里的“寸象”二字，和我們經常聽到的“面向寸象編程”里面的“寸象”意義相同0Simulink為用戶事先定義好兩個包，一個是SimulinkPackage，一個是mptPackage。以SimulinkPackage為例，包里面有類，分別為Simulink.Signal和Simulink.Parameter兩個類。用戶可以通過這兩個類定義相應的寸象（Object），然后通過類提供的屬性（Property）定義數(shù)據(jù)的屬性。其實這兩個類里面除了屬性之外，還定義了方法（Metho

19、d），-般情況下，我們管理數(shù)據(jù)，使用當然，不管是SimulinkPackage還是mtpPackage，都不能完全滿足用戶的所有要求，所以，很多時候，需要用戶定義自己的Package。依然按照面向寸象里面的一些概念，我們可以從SimulinkPackage或者mptPackage繼承并創(chuàng)建自己的包。所有我們關心的數(shù)據(jù)都通過數(shù)據(jù)寸象的方式做了定義之后，接下夾的工作，就是按下按鈕，生成代碼了。因為前面預的帖子夠多，的代碼吧。所以繼續(xù)在這個帖子討論一自動生成首先說一下大家很關心的效問題，代碼效，我之前做過對比，比一般的工程師寫的代碼效要高，當然，我弋相信對于那種C代碼高手，一定可以寫出效高的代碼。過

20、我想強調的是，自動生成的代碼，是可以用的，要有任何心障礙，畢竟，我們項目開發(fā)中的多數(shù)工程師也是絕對的C語言高手。另外，關于效，我最近也做過一次對比，就在這個帖子最開頭提到的那個貼子，雖然代碼沒有人去做編譯，但從代碼數(shù)夾看，和一個寫6C代碼的工程師的代碼基本差多。再說說代碼可讀性的問題，很多人和我強調代碼的可讀性如手寫的好，我有條件的承認這-點。為么是有條件的承認呢，我想說，如果你對模型做足夠多的配置，生成的代碼可讀性基本上可以和手寫的差多。當然，我弋想強調，在基于模型的開發(fā)過程中，我們是讀代碼的（如果一定要讀，那也是讀那個.h文件），我們有其他方式保證代碼是正確的，無須讀代碼。再有一個問題，就

21、是代碼的集成問題，很多人也比較關心自動生成的代碼如何集成到底層代碼或者如何與其他手寫代碼做集成的問題，我一般會問他，如果這個模塊的代碼是手寫的，你會怎么集成？他當然知道手寫代碼該怎么集成好，自動生成的代碼也同樣可以集成。做代碼集成的時候，我們關心的就是那個.h文件。有關底層驅動的建模，我一直認為在產品化項目開發(fā)中，底層驅動是沒有必要建模的。原因如下：1）底層驅動在Simulink環(huán)境下能仿真；2）底層驅動建模需要熟悉另外一種腳本語言TLC；3）產品化項目的底層軟件往往很大，有些項目的底層軟件甚至大于應用層軟件，如此大的軟件轉換成Simulink下的TLC實現(xiàn)，容操作。當然，有人會說，一旦有底層

22、驅動模型，就可以非常方的實現(xiàn)Simulink模型到單片機hex文件的一鍵式實現(xiàn)，的確這樣做貌似讓整個開發(fā)過程的自動化程得以提升，但是，要忘記，你要開發(fā)出一個安全、可靠的底層模塊庫，會需要大的時間投入，尤其在使用TLC設計的時候，TLC本身就是另外一種新的語言，同時這種語言所提供的調試環(huán)境也盡如人意；相反，如果使用這種一鍵式的模式，而是采用手工集成的方式實現(xiàn)自動生成的應用層代碼與底層代碼做集成，也是非常簡單，非常輕松的事情。總結一下，一鍵式的實現(xiàn)hex文件生成并能明顯提高開發(fā)效，而開發(fā)出這樣一個底層模塊庫，卻需要花費大的時間。到MathWorks工作以夾，經常被客戶問到這樣的問題：MATLAB的

23、代碼生成支持么芯片？支持么芯片？MATLAB生成的是ANSIC代碼，支持所有編譯器，也就是支持所有芯片。當然，我說的是應用層代碼的生成，包括底層驅動代碼。我也知道很多人問這個問題的時候，心面想著的是TargetSupportPackage這樣一個工具包，這個包面的確提供一些MCU或者DSP的底層驅動模塊，借助于這些模塊，我們可以生成底層代碼。過，繼續(xù)強調一下，在很多工程化的項目，這是一個產品化的解決方案，這種方案適合于做算法的快速驗證。也正是因為這是一個產品化的方案，所以這個產品的用戶非常少，以至于MATLAB從2011a開始，再單獨銷售這個模塊，并承諾以后會繼續(xù)新這個模塊，這個模塊連同IDELink被打包到EmbeddedCoder產品中，只有你購買EmbeddedCoder，你就可以使用這個模塊。再說說In-the-Loop測試的問題吧。我們經常聽到的有MIL、SIL、PIL、HIL等，在基于模型設計的開發(fā)過程中，是否要做這些In-the-Loop測試？我認為所有的In-the-Loop是一定要做的,過，我非常建議要SIL環(huán)節(jié)。1