有關(guān)基于模型的設(shè)計(jì)(MBD)一些概念和理解

有關(guān)基于模型的設(shè)計(jì)（MBD）一些概念和理解先胡亂問(wèn)幾個(gè)大問(wèn)題：什么叫基于模型的設(shè)計(jì)？為什么要基于模型的設(shè)計(jì)？基于模型的設(shè)計(jì)過(guò)程中，需要做什么事情？

再問(wèn)幾個(gè)小問(wèn)題：

模型驗(yàn)證是否必要？模型驗(yàn)證有哪些工作可以做？模型驗(yàn)證是否一定需要被控對(duì)象模型？代碼生成效率如何？底層驅(qū)動(dòng)是否要建模？EmbeddedCoder（以前的RTWEmbeddedCoder）支持哪些芯片？MIL、SIL、PIL、HIL的目的和實(shí)現(xiàn)方式？如何定點(diǎn)化？如何做代碼集成？什么叫基于模型的設(shè)計(jì)？這是一個(gè)很大的話題，因?yàn)楸救四芰λ蓿瑑H討論使用Simulink模型開(kāi)發(fā)嵌入式軟件的設(shè)計(jì)過(guò)程。也就是說(shuō)，我只能聊基于模型的嵌入式軟件設(shè)計(jì)。

我的理解是，通過(guò)對(duì)算法建模進(jìn)行軟件設(shè)計(jì)的過(guò)程，都可以叫基于模型的設(shè)計(jì)。當(dāng)然，如果僅限于算法建模，把Simulink/Stateflow當(dāng)做Visio使用，而不去進(jìn)行其他環(huán)節(jié)的工作，這樣的基于模型設(shè)計(jì)是不完整的，可能對(duì)你的開(kāi)發(fā)效率不會(huì)有很大的提升。

如果想通過(guò)基于模型的設(shè)計(jì)提升軟件開(kāi)發(fā)團(tuán)隊(duì)的開(kāi)發(fā)效率，提高軟件品質(zhì)，我覺(jué)得至少有如下幾點(diǎn)可以考慮：算法建模算法模型的驗(yàn)證文檔自動(dòng)化代碼生成5.代碼和模型的等效性驗(yàn)證傳統(tǒng)的開(kāi)發(fā)過(guò)程中，我們有一個(gè)環(huán)節(jié)，需求捕獲，也即，從系統(tǒng)需求分解出軟件需求。在基于模型的設(shè)計(jì)過(guò)程中，我們同樣可以通過(guò)分析系統(tǒng)需求，獲得軟件需求。當(dāng)然，根據(jù)系統(tǒng)需求的詳細(xì)程度，我們可以考慮是否要寫專門的軟件需求。在基于模型的軟件設(shè)計(jì)中，我們主要關(guān)心的是系統(tǒng)的功能需求，或者說(shuō)可以通過(guò)軟件實(shí)現(xiàn)的功能需求。如果這部分需求在系統(tǒng)需求文檔里已經(jīng)有非常清楚的定義，那么我們可以以系統(tǒng)需求文檔作為依據(jù)建立模型。當(dāng)然，如果系統(tǒng)需求不是足夠清楚，那我們有必要編寫專門的軟件需求文檔。如果不考慮Simulink/Stateflow的應(yīng)用上的問(wèn)題，也就是說(shuō)，如果我們都是熟練的Simulink/Stateflow用戶，那么建模過(guò)程的主要工作是需求分析，通俗點(diǎn)講，需求弄清楚了，建模也就是非常簡(jiǎn)單的事情了。當(dāng)然，建模的時(shí)候，要考慮未來(lái)的驗(yàn)證、實(shí)現(xiàn)以及后期維護(hù)的問(wèn)題。我個(gè)人的體會(huì)，這個(gè)階段，不要著急建模，一定要先弄清需求，另外，建模的時(shí)候，模型架構(gòu)非常重要。

有了模型之后，接下來(lái)要做什么事情？代碼生成？

這是很多比較初級(jí)的用戶容易犯的錯(cuò)誤，犯這個(gè)錯(cuò)誤的用戶，很大程度上是因?yàn)闆](méi)有弄清楚為什么要做基于模型的設(shè)計(jì)？為什么要做基于模型的設(shè)計(jì)？我相信很多用戶沒(méi)有仔細(xì)考慮這個(gè)問(wèn)題，很多用戶做基于模型的設(shè)計(jì)的理由是：國(guó)外的公司都這么做，同行其他公司都這么做......

弄清為什么要基于模型的設(shè)計(jì)，也就是要弄清楚基于模型的設(shè)計(jì)到底可以給我們帶來(lái)哪些好處？很多人會(huì)非常自然的想到，代碼生成，代碼生成可以提高軟件開(kāi)發(fā)效率。沒(méi)錯(cuò)，代碼生成是一個(gè)很大的好處，但，代碼生成不是唯一的，也不是最大的好處。最大的好處是，算法的早期驗(yàn)證，之前NASA有研究表明，開(kāi)發(fā)初期引入的bug，如果到了晚期才發(fā)現(xiàn)出來(lái)，那么修復(fù)這一的bug，會(huì)產(chǎn)生非常大的費(fèi)用。所以，我們期望能夠盡早的發(fā)現(xiàn)開(kāi)發(fā)過(guò)程中引入的bug。

如何盡早的發(fā)現(xiàn)設(shè)計(jì)上的錯(cuò)誤？傳統(tǒng)的開(kāi)發(fā)模式里，我們使用review的方式去發(fā)現(xiàn)錯(cuò)誤，在質(zhì)量體系ISO9001里面有定義，任何一份設(shè)計(jì)，都必須要評(píng)審。評(píng)審的目的，也就是為了發(fā)現(xiàn)這個(gè)階段的錯(cuò)誤，以防錯(cuò)誤被帶到后續(xù)的開(kāi)發(fā)過(guò)程中。而評(píng)審的效率，卻是非常低下的。我想凡是參加評(píng)審的網(wǎng)友都會(huì)有體會(huì)。比如，我在做完一份設(shè)計(jì)之后，我會(huì)邀請(qǐng)我的同事來(lái)評(píng)審我的工作，而參加評(píng)審的這些同事，往往不能有足夠的時(shí)間了解我的這份工作，而只能在評(píng)審會(huì)上聽(tīng)我介紹我做的工作，這樣的評(píng)審，可能會(huì)發(fā)現(xiàn)一些非常明顯的問(wèn)題，除此之外的，很難發(fā)現(xiàn)問(wèn)題。評(píng)審作為一種非常傳統(tǒng)的驗(yàn)證方式，并不能及時(shí)發(fā)現(xiàn)設(shè)計(jì)過(guò)程中引入的各種錯(cuò)誤。而仿真，從效率上講，要遠(yuǎn)高于評(píng)審，仿真更容易發(fā)現(xiàn)設(shè)計(jì)中的問(wèn)題。仿真是可以運(yùn)行的，如果我們?cè)O(shè)定一些輸入，運(yùn)行模型之后，我們會(huì)得到相應(yīng)的輸出，我們很容易觀測(cè)到此時(shí)的輸出是否是我們期望的輸出。另外還有好處，仿真的結(jié)果是確定的，給定輸入，就會(huì)得到確定的輸出，當(dāng)然，期望輸出也是確定的。而不像評(píng)審，同樣的文字，對(duì)于不同人，可能理解成不同的含義。代碼生成和早期驗(yàn)證之外，基于模型的設(shè)計(jì)，還可以給我們帶來(lái)其他好處，比如文檔自動(dòng)化。我們經(jīng)常聽(tīng)到這樣的說(shuō)法：

我們終于把軟件發(fā)布出去了，現(xiàn)在可以有時(shí)間補(bǔ)文檔了...下個(gè)月要audit了，所有同事都在補(bǔ)文檔....

這里我要問(wèn)：為什么要補(bǔ)文檔？

補(bǔ)文檔，我們可以從中得到兩個(gè)方面的信息：

1.文檔很重要，不能沒(méi)有，至少?gòu)馁|(zhì)量體系上要求我們必須有文檔

2.工程師都不愿意寫文檔，是啊，如果愿意寫文檔的話，在開(kāi)發(fā)過(guò)程中自然會(huì)把各類文檔寫起來(lái)的。好，工程師不愿意寫，開(kāi)發(fā)過(guò)程中又不能少，如果計(jì)算機(jī)可以幫我們寫，豈不是很美好的事情。基于模型的設(shè)計(jì)，可以幫助我們實(shí)現(xiàn)文檔自動(dòng)化，至少有相當(dāng)大的一部分文檔可以讓計(jì)算機(jī)替我們寫。

其實(shí)，基于模型的設(shè)計(jì)，還有一個(gè)天然的優(yōu)勢(shì)：圖形化設(shè)計(jì)。對(duì)于工程師來(lái)講，圖形化的東西，本身就比文字更容易理解，否則我們?cè)谲浖_(kāi)發(fā)過(guò)程中也不會(huì)去畫流程圖和狀態(tài)機(jī)了所以總結(jié)一下，基于模型的設(shè)計(jì)可以從以下方面給我們提供便利：

1.圖形化設(shè)計(jì)

2.早期驗(yàn)證

3.代碼生成

4.文檔自動(dòng)化前面我大概論述了為什么要做基于模型的設(shè)計(jì)，或者說(shuō)基于模型的設(shè)計(jì)可以給我們帶來(lái)哪些好處。這些好處，最終會(huì)大大提高開(kāi)發(fā)效率，并且改善軟件品質(zhì)。

下面，我在說(shuō)說(shuō)基于模型的設(shè)計(jì)里有哪些事情要做，劉博士說(shuō)的沒(méi)錯(cuò)，基于模型的設(shè)計(jì)，自然模型最重要，如何建模，毫無(wú)疑問(wèn)是最為重要的環(huán)節(jié)。在軟件產(chǎn)品開(kāi)發(fā)中，建模活動(dòng)里，耗時(shí)最多的，就應(yīng)該是需求分析了，需求分析不僅包括如何正確理解軟件需求，而且要考慮如何通過(guò)模型實(shí)現(xiàn)，真正的畫模型的時(shí)間，相比之下并不多，如果Simulink/Stateflow用的熟的話，真正打開(kāi)MATLAB畫模型的時(shí)間占建模階段總時(shí)間的1/3都不到。建模之后，接下來(lái)就是模型驗(yàn)證，驗(yàn)證，英文單詞Verification，英文里面還有另外一個(gè)詞Validation，確認(rèn)，很多人不清楚這兩個(gè)詞之間的區(qū)別，通俗點(diǎn)講：Verification是考察你是否正確的做了一件事，而Validation，則是考察你是否做出了正確的東西。一個(gè)強(qiáng)調(diào)的是過(guò)程，一個(gè)在乎的是結(jié)果。

閑話少說(shuō)，咱們繼續(xù)回到模型驗(yàn)證上來(lái)，通常模型驗(yàn)證包含如下活動(dòng)：建模標(biāo)準(zhǔn)的檢查、評(píng)審、單元測(cè)試、快速原型。（如果說(shuō)的不完善，歡迎大家補(bǔ)充）建模標(biāo)準(zhǔn)的檢查，可以通過(guò)模型檢查工具自動(dòng)完成，建模標(biāo)準(zhǔn)檢查的意義，和傳統(tǒng)開(kāi)發(fā)模式里C編碼標(biāo)準(zhǔn)的意義一致，這里不展開(kāi)了。模型驗(yàn)證之后，接下來(lái)就可以做代碼生成了，有關(guān)代碼生成，也專門討論吧。代碼生成之后，需要做代碼驗(yàn)證，基于模型的開(kāi)發(fā)過(guò)程里面，SIL、PIL都是常用的代碼驗(yàn)證方式。在代碼做完SIL或者PIL測(cè)試之后，要考慮軟件集成了，即應(yīng)用層軟件，也就是通過(guò)Simulink模型生成的軟件，和底層驅(qū)動(dòng)軟件之間的集成。軟件集成之后，后面的事情，基本上和傳統(tǒng)的開(kāi)發(fā)模式差不多了，當(dāng)然，相對(duì)于傳統(tǒng)的開(kāi)發(fā)模式，你可以多一個(gè)HIL環(huán)節(jié)出來(lái)，不過(guò)話又說(shuō)回來(lái)，即便是傳統(tǒng)的開(kāi)發(fā)模式，也一樣可以有HIL這個(gè)環(huán)節(jié)的。

有關(guān)HIL的實(shí)現(xiàn)及目的，以后再說(shuō)。

再說(shuō)說(shuō)模型驗(yàn)證的必要性。我在進(jìn)入MathWorks之后，接觸過(guò)很多客戶，不少客戶在最初引入基于模型設(shè)計(jì)的時(shí)候，根本不在意模型驗(yàn)證工作，他們經(jīng)常在模型編譯通過(guò)之后就拿去生成代碼，有了代碼之后將代碼下載到各種快速原型設(shè)備上去測(cè)試算法，Simulink的仿真功能基本上成了擺設(shè)。并且在這個(gè)階段，不管我如何苦口婆心的給他們介紹模型驗(yàn)證的重要性，在他們那邊，卻總有各種各樣的借口去省略模型驗(yàn)證環(huán)節(jié)，“項(xiàng)目時(shí)間太緊，模型來(lái)不及測(cè)”，“我們知道規(guī)范的開(kāi)發(fā)流程，但是現(xiàn)在人手不夠”。當(dāng)然，這類用戶經(jīng)常在這樣折騰了一段時(shí)間之后，還是要回到模型測(cè)試上來(lái)，他們最終會(huì)發(fā)現(xiàn)，在HIL設(shè)備上測(cè)試算法，實(shí)在太難，當(dāng)然，也有堅(jiān)持的，堅(jiān)持的結(jié)果就是他們所謂的基于模型的設(shè)計(jì)，開(kāi)發(fā)效率比傳統(tǒng)的開(kāi)發(fā)模式高不了多少。其實(shí)，這個(gè)問(wèn)題我們可以這么去看，模型階段的測(cè)試，我們是可以分模塊進(jìn)行的，而HIL上測(cè)試，基本上是集成之后的軟件。比如，一個(gè)軟件有10個(gè)模塊，在HIL設(shè)備上，你很難分離出每個(gè)模塊的bug，而如果是按模塊做單元測(cè)試，則就是針對(duì)的一個(gè)具體的模塊。打一個(gè)不算恰當(dāng)?shù)谋确?，我們都知道一塊2克拉的鉆石，價(jià)格肯定不是一塊1克拉鉆石的兩倍。類似的，如果每個(gè)軟件模塊有2個(gè)bug，那么你從集成好的軟件里去消除這20個(gè)bug，耗費(fèi)的精力肯定不是從每個(gè)單元模塊里去消除bug所耗精力的總和。

說(shuō)白了，早期驗(yàn)證是非常重要的，很多軟件工程的教材里都有相關(guān)的統(tǒng)計(jì)數(shù)據(jù)說(shuō)明早期驗(yàn)證的重要性，對(duì)應(yīng)到基于模型的開(kāi)發(fā)過(guò)程，能在模型級(jí)別做的驗(yàn)證，一定不要拖到后續(xù)的環(huán)節(jié)中。中國(guó)有句老話，“心急吃不了熱豆腐”，“項(xiàng)目時(shí)間緊”或者“人手不夠”不能成為我們忽略模型測(cè)試的借口。

繼續(xù)說(shuō)一下MBD開(kāi)發(fā)過(guò)程中都有哪些驗(yàn)證工作要做。模型出來(lái)并且可以編譯之后，首先要做建模標(biāo)準(zhǔn)檢查，這個(gè)過(guò)程使用工具（比如MathWorks公司的SimulinkVerification&Validation提供的modeladvisor）自動(dòng)化的完成，檢查過(guò)后，修改模型中不符合公司建模規(guī)則的項(xiàng)目。接下來(lái)，就可以進(jìn)行模型評(píng)審了，也就是說(shuō)，評(píng)審的模型有兩個(gè)前提，一是可以編譯的，二是符合公司建模規(guī)則的。這兩個(gè)前提可以幫助我們消除模型中的一些低級(jí)錯(cuò)誤，避免在評(píng)審過(guò)程中有太多的時(shí)間花費(fèi)在這些錯(cuò)誤上。因?yàn)樵u(píng)審是建模的工程師和其他同事共同參與的活動(dòng)，做到上述兩個(gè)前提，也是對(duì)其他同事工作時(shí)間的一種尊重。評(píng)審之后，建模的工程師會(huì)修改評(píng)審中發(fā)現(xiàn)的問(wèn)題，問(wèn)題多的話，一般會(huì)要求修改之后再進(jìn)行“再評(píng)審”，直到在評(píng)審中不會(huì)發(fā)現(xiàn)大量問(wèn)題。接下來(lái)，我們可以使用SimulinkDesignVerifier進(jìn)行模型的結(jié)構(gòu)分析，借助于SimulinkDesignVerifier自動(dòng)生成測(cè)試用例的功能，去檢查結(jié)構(gòu)上是否存在問(wèn)題，比如是否有不合理的邏輯設(shè)計(jì)，是否有運(yùn)行不到的分支等。再往后，就可以進(jìn)行模型單元級(jí)別的功能測(cè)試了。軟件開(kāi)發(fā)過(guò)程中，對(duì)單元測(cè)試的要求是很高的，一般會(huì)根據(jù)應(yīng)用的安全性、可靠性要求，給出測(cè)試的覆蓋率要求。這個(gè)過(guò)程中工作量最大的應(yīng)該是測(cè)試用例設(shè)計(jì)以及測(cè)試向量的生成。測(cè)試用例設(shè)計(jì)，我們一般會(huì)根據(jù)需求去設(shè)計(jì)測(cè)試用例，當(dāng)然，也會(huì)結(jié)合模型結(jié)構(gòu)設(shè)計(jì)測(cè)試用例，這樣說(shuō)來(lái)，這里的測(cè)試，已經(jīng)包含了黑盒測(cè)試和白盒測(cè)試。有了測(cè)試用例，如何把測(cè)試用例轉(zhuǎn)換為測(cè)試向量，這也是非常重要的環(huán)節(jié)。我們知道，在MBD開(kāi)發(fā)過(guò)程中，代碼都可以自動(dòng)生成，其他環(huán)節(jié)，我們要努力做到自動(dòng)化實(shí)現(xiàn)。我們可以使用MATLAB腳本開(kāi)發(fā)一些轉(zhuǎn)換工具用于將測(cè)試用例轉(zhuǎn)換為測(cè)試向量，我們還可以通過(guò)腳本實(shí)現(xiàn)測(cè)試過(guò)程的自動(dòng)化。測(cè)試的指標(biāo)，即測(cè)試覆蓋率是否達(dá)到公司的要求或者行業(yè)的要求。單元級(jí)別的功能測(cè)試完成之后，我們自然會(huì)進(jìn)行集成測(cè)試，當(dāng)然，集成測(cè)試是分階段、有步驟的，我們可以先把一些單元模塊集成為組件級(jí)，進(jìn)行組件級(jí)的集成測(cè)試，然后再將組件集成為系統(tǒng)級(jí)，進(jìn)行系統(tǒng)級(jí)測(cè)試。集成測(cè)試和單元測(cè)試關(guān)注的內(nèi)容不同，集成測(cè)試，我們更關(guān)注于單元模塊之間的借口關(guān)系、調(diào)用關(guān)系等等，所以，單元測(cè)試中要求的判定覆蓋率、MCDC覆蓋率等，在集成測(cè)試中沒(méi)有這樣的要求。條件允許的情況下，集成測(cè)試之前或者之后，可以通過(guò)快速原型的方式和實(shí)物相連，進(jìn)行測(cè)試。集成測(cè)試通過(guò)之后，我們基本上可以認(rèn)為模型或者說(shuō)算法是正確的了。接下來(lái)，我們就可以進(jìn)行代碼生成了。代碼生成之后，會(huì)跟著做SIL、PIL、HIL等測(cè)試，所有這些In-the-Loop測(cè)試都不是必須的，工程師應(yīng)該根絕項(xiàng)目的實(shí)際情況，選擇合理的測(cè)試方案，當(dāng)然，建議SIL測(cè)試不要省略，原因在于這種測(cè)試的確非常方便做，并且也的確會(huì)發(fā)現(xiàn)一些代碼生成過(guò)程中出現(xiàn)的問(wèn)題。前面提到模型驗(yàn)證，下面再說(shuō)說(shuō)代碼生成。代碼生成的前提是模型已經(jīng)是驗(yàn)證過(guò)的模型，或者說(shuō)，是正確的模型。正確的模型包含兩層含義，模型做過(guò)足夠多的驗(yàn)證，驗(yàn)證的結(jié)果都是正確的。前面提到的各種驗(yàn)證方式，都有必要做，對(duì)于功能測(cè)試來(lái)講，還有必要達(dá)到足夠高的覆蓋率要求。做到以上這些，就可以考慮進(jìn)行代碼生成工作了，代碼生成是否就是按一下“CodeGeneration”按鈕的工作呢？工程項(xiàng)目開(kāi)發(fā)中，沒(méi)那么簡(jiǎn)單，代碼生成過(guò)程中，工程師要做的主要工作是數(shù)據(jù)管理工作，除此之外，還會(huì)有一些代碼相關(guān)的配置，比如函數(shù)原型、比如代碼文件等等。數(shù)據(jù)管理主要是對(duì)Simulink/Stateflow模型中的兩類數(shù)據(jù)進(jìn)行管理，一是信號(hào)，一是參數(shù)。對(duì)應(yīng)于C代碼，我們可以簡(jiǎn)單的把信號(hào)對(duì)應(yīng)到變量上，而參數(shù)，則是不通過(guò)程序運(yùn)行而發(fā)生變化的，參數(shù)的變化，一般是通過(guò)人工調(diào)節(jié)完成的，也就是參數(shù)調(diào)節(jié)，參數(shù)調(diào)節(jié)的目的是為了選擇合適的參數(shù)以得到最佳的性能。數(shù)據(jù)管理的方式，使用的是數(shù)據(jù)對(duì)象進(jìn)行數(shù)據(jù)管理，這里的“對(duì)象”二字，和我們經(jīng)常聽(tīng)到的“面向?qū)ο缶幊獭崩锩娴摹皩?duì)象”意義相同。Simulink為用戶事先定義好兩個(gè)包，一個(gè)是SimulinkPackage，一個(gè)是mptPackage。以SimulinkPackage為例，包里面有類，分別為Simulink.Signal和Simulink.Parameter兩個(gè)類。用戶可以通過(guò)這兩個(gè)類定義相應(yīng)的對(duì)象（Object），然后通過(guò)類提供的屬性（Property）定義數(shù)據(jù)的屬性。其實(shí)這兩個(gè)類里面除了屬性之外，還定義了方法（Method），一般情況下，我們管理數(shù)據(jù)，使用屬性就夠了。當(dāng)然，不管是SimulinkPackage還是mtpPackage，都不能完全滿足用戶的所有要求，所以，很多時(shí)候，需要用戶定義自己的Package。依然按照面向?qū)ο罄锩娴囊恍└拍?，我們可以從SimulinkPackage或者mptPackage繼承并創(chuàng)建自己的包。所有我們關(guān)心的數(shù)據(jù)都通過(guò)數(shù)據(jù)對(duì)象的方式做了定義之后，接下來(lái)的工作，就是按下按鈕，生成代碼了。因?yàn)榍懊骖A(yù)留的帖子不夠多，所以，就繼續(xù)在這個(gè)帖子里討論一下自動(dòng)生成的代碼吧。首先說(shuō)一下大家很關(guān)心的效率問(wèn)題，代碼效率，我之前做過(guò)對(duì)比，比一般的工程師寫的代碼效率要高，當(dāng)然，我相信對(duì)于那種C代碼高手，一定可以寫出效率更高的代碼。不過(guò)我想強(qiáng)調(diào)的是，自動(dòng)生成的代碼，是可以用的，不要有任何心理障礙，畢竟，我們項(xiàng)目開(kāi)發(fā)中的多數(shù)工程師也不是絕對(duì)的C語(yǔ)言高手。另外，關(guān)于效率，我最近也做過(guò)一次對(duì)比，就在這個(gè)帖子最開(kāi)頭提到的那個(gè)貼子里，雖然代碼沒(méi)有人去做編譯，但從代碼行數(shù)來(lái)看，和一個(gè)寫了6年C代碼的工程師的代碼基本差不多。再說(shuō)說(shuō)代碼可讀性的問(wèn)題，很多人和我強(qiáng)調(diào)代碼的可讀性不如手寫的好，我有條件的承認(rèn)這一點(diǎn)。為什么是有條件的承認(rèn)呢，我想說(shuō)，如果你對(duì)模型做足夠多的配置，生成的代碼可讀性基本上可以和手寫的差不多。當(dāng)然，我更想強(qiáng)調(diào)，在基于模型的開(kāi)發(fā)過(guò)程中，我們是不讀代碼的（如果一定要讀，那也是讀那個(gè).h文件），我們有其他方式保證代碼是正確的，無(wú)須讀代碼。再有一個(gè)問(wèn)題，就是代碼的集成問(wèn)題，很多人也比較關(guān)心自動(dòng)生成的代碼如何集成到底層代碼或者如何與其他手寫代碼做集成的問(wèn)題，我一般會(huì)問(wèn)他，如果這個(gè)模塊的代碼是手寫的，你會(huì)怎么集成？他當(dāng)然知道手寫代碼該怎么集成，好，自動(dòng)生成的代碼也同樣可以集成。做代碼集成的時(shí)候，我們關(guān)心的就是那個(gè).h文件。有關(guān)底層驅(qū)動(dòng)的建模，我一直認(rèn)為在產(chǎn)品化項(xiàng)目開(kāi)發(fā)中，底層驅(qū)動(dòng)是沒(méi)有必要建模的。原因如下：

1）底層驅(qū)動(dòng)在Simulink環(huán)境下不能仿真；

2）底層驅(qū)動(dòng)建模需要熟悉另外一種腳本語(yǔ)言——TLC；

3）產(chǎn)品化項(xiàng)目的底層軟件往往很大，有些項(xiàng)目的底層軟件甚至大于應(yīng)用層軟件，如此大的軟件轉(zhuǎn)換成Simulink下的TLC實(shí)現(xiàn)，不容易操作。當(dāng)然，有人會(huì)說(shuō)，一旦有了底層驅(qū)動(dòng)模型，就可以非常方便的實(shí)現(xiàn)Simulink模型到單片機(jī)hex文件的一鍵式實(shí)現(xiàn)，的確這樣做貌似讓整個(gè)開(kāi)發(fā)過(guò)程的自動(dòng)化程度得以提升，但是，不要忘記，你要開(kāi)發(fā)出一個(gè)安全、可靠的底層模塊庫(kù)，會(huì)需要大量的時(shí)間投入，尤其在使用TLC設(shè)計(jì)的時(shí)候，TLC本身就是另外一種新的語(yǔ)言，同時(shí)這種語(yǔ)言所提供的調(diào)試環(huán)境也不盡如人意；相反，如果不使用這種一鍵式的模式，而是采用手工集成的方式實(shí)現(xiàn)自動(dòng)生成的應(yīng)用層代碼與底層代碼做集成，也是非常簡(jiǎn)單，非常輕松的事情?？偨Y(jié)一下，一鍵式的實(shí)現(xiàn)hex文件生成并不能明顯提高開(kāi)發(fā)效率，而開(kāi)發(fā)出這樣一個(gè)底層模塊庫(kù)，卻需要花費(fèi)大量的時(shí)間。到MathWorks工作以來(lái)，經(jīng)常被客戶問(wèn)到這樣的問(wèn)題：MATLAB的代碼生成支持什么芯片？支持什么芯片？MATLAB生成的是ANSIC代碼，支持所有編譯器，也就是支持所有芯片。當(dāng)然，我說(shuō)的是應(yīng)用層代碼的生成，不包括底層驅(qū)動(dòng)代碼。我也知道很多人問(wèn)這個(gè)問(wèn)題的時(shí)候，心里面想著的是TargetSupportPackage這樣一個(gè)工具包，這個(gè)包里面的確提供了一些MCU或者DSP的底層驅(qū)動(dòng)模塊，借助于這些模塊，我們可以生成底層代碼。不過(guò)，繼續(xù)強(qiáng)調(diào)一下，在很多工程化的項(xiàng)目里，這不是一個(gè)產(chǎn)品化的解決方案，這種方案更適合于做算法的快速驗(yàn)證。也正是因?yàn)檫@不是一個(gè)產(chǎn)品化的方案，所以這個(gè)產(chǎn)品的用戶非常少，以至于MATLAB從2011a開(kāi)始，不再單獨(dú)銷售這個(gè)模塊，并不承諾以后會(huì)繼續(xù)更新這個(gè)模塊，這個(gè)模塊連同IDELink被打包到EmbeddedCoder產(chǎn)品中，只有你購(gòu)買了EmbeddedCoder，你就可以使用這個(gè)模塊了。

再說(shuō)說(shuō)In-the-Loop測(cè)試的問(wèn)題吧。我們經(jīng)常聽(tīng)到的有MIL、SIL、PIL、HIL等，在基于模型設(shè)計(jì)的開(kāi)發(fā)過(guò)程中，是否都要做這些In-the-Loop測(cè)試？我認(rèn)為所有的In-the-Loop都不是一定要做的，不過(guò)，我非常建議不