編寫代碼太累？試試基于模型的設計

　　前一陣參加了MathWorks公司一個關于基于模型的設計的講座，先介紹了基于模型的設計model based design，然后是親自動手體驗;感覺很有意義，特別是其中的自動代碼生成，所以在此和大家分享一下。

　　聽起來，自動生成代碼好像是專門為不想多動手的工程師準備的工具。其實，自動代碼生成最早是做為基于模型的設計方法的一部分提出的。一般情況下，嵌入式系統(tǒng)軟件的開發(fā)分為需求定義、功能設計、代碼編寫和測試等幾個階段，測試、找bug和解決bug往往要花費很多的精力，特別是越是隱藏的深的bug越難發(fā)現(xiàn)和解決，隱患也很大。所以每次在傳統(tǒng)方法下發(fā)現(xiàn)和解決bug造成的發(fā)布延時都會造成整個修復成本的指數(shù)級上升。而采用基于模型的設計，則可以在設計的早期通過仿真等手段保證模型的正確性，例如在仿真環(huán)境下，我們的模型能夠完全實現(xiàn)我們的意圖，然后自動代碼生成和驗證就是水到渠成的問題了。

　　其次，基于模型的設計在復雜和非常復雜的系統(tǒng)中特別有意義。他們舉了幾個例子，例如在高檔的汽車上，全部代碼預估已經(jīng)達到千萬行、甚至兩千萬行的級別了，這么多代碼要是靠手工編寫和測試，首先需要幾十個幾百個人的編程和測試團隊不說，光是溝通的效率就很難保證了;基于模型的設計方法則可以有效解決這個問題。目前在汽車行業(yè)，這種模式已經(jīng)成為主流的開發(fā)方法了，在航空航天等領域也得到了很廣泛的應用，例如著名的F-22戰(zhàn)斗機和“好奇號”火星車都使用了基于模型的設計方法。例如講座中提到，火星車的開發(fā)中，使用了380000次仿真，這要是按照傳統(tǒng)的測試方法去一遍遍做，估計整個團隊都要吐血身亡了。

　　此外，開發(fā)一個復雜系統(tǒng)要花費大量的時間，新系統(tǒng)開發(fā)時從現(xiàn)有系統(tǒng)中復用現(xiàn)有的代碼是省事實力的?；谀Ｐ偷脑O計方法因為使用模型參考調用的方法引用子系統(tǒng)，所以代碼的移植和復用非常方便。例如例如講座中提到，F(xiàn)35戰(zhàn)斗機有A、B、C三種型號，在開發(fā)過程中，可以重復使用的系統(tǒng)設計模型就顯著提高了開發(fā)效率。

　　接下來講講我所理解的基于模型設計的開發(fā)過程：

　　1. 系統(tǒng)需求

　　不管用啥開發(fā)方法，最終要完成的系統(tǒng)是一樣的，所以系統(tǒng)需求并沒有什么顯著區(qū)別。只不過Simulink開發(fā)工具可以在建模中將模型與需求文檔進行關聯(lián)，方便快速查看模型功能與需求文檔之間是否有偏差。

　　2. 建模

　　就是在Simulink環(huán)境中把我們需要的功能用模塊搭建起來，例如控制系統(tǒng)、通信系統(tǒng)等，基于圖形化的編程還是較為直觀和容易的，并且仿真測試很快就能得到結果了。

　　3. 代碼生成

　　模型有了，這一步就是超級吸引人的了，直接把模型生成C代碼，多方便的功能。當然有一些規(guī)范要定義的，包括一些ISO的標準;而且如果我們使用的處理器被Simulink支持的話，在生成代碼的時候還可以直接針對代碼優(yōu)化，例如我們的目標對象是TI的一個DSP，則一些數(shù)學運算在生成代碼時會直接調用BootROM里的數(shù)學庫，相比于傳統(tǒng)的C語言math.h里面的標準數(shù)學庫，運行速度要強的多;常用的DSP、ARM等基本都是支持的。

　　4. 軟件在環(huán)測試

　　硬件在環(huán)測試HIL大家可能都聽說過，不過軟件在環(huán)測試SIL貌似是個比較新鮮的概念。它的含義就是把生成的c代碼調用到仿真環(huán)境中，輸入是與仿真的那步是一樣的，這樣就能比較生成的代碼和我們的模型是否有結果的差異。當然幾乎是不會出現(xiàn)什么狀況的。

　　5. 硬件在回路測試

　　這一步很多人都不陌生，就是把生成的代碼下載到實際的控制器中，觀測返回的結果是不是和我們的仿真模型是一致的。

　　試驗了一下，生成代碼的效率還不錯，可讀性也很好，如果覺得編程太累了，可以嘗試一下。當然有一些功能在Simulink里面實現(xiàn)還是暫時有困難的，例如實時操作系統(tǒng)的任務調度，目前還很難實現(xiàn)出來，所以可以把功能劃分一下，一部分控制系統(tǒng)、通信系統(tǒng)的代碼使用這種方法，其它的則還需要手工編寫，然后通過接口進行協(xié)同工作。