編寫代碼太累？試試基于模型的設計
發布時間：2014-8-25 16:50
發布者：看門狗
|
作者：paradoxfx 前一陣參加了MathWorks公司一個關于基于模型的設計的講座，先介紹了基于模型的設計model based design，然后是親自動手體驗;感覺很有意義，特別是其中的自動代碼生成，所以在此和大家分享一下。 聽起來，自動生成代碼好像是專門為不想多動手的工程師準備的工具。其實，自動代碼生成最早是做為基于模型的設計方法的一部分提出的。一般情況下，嵌入式系統軟件的開發分為需求定義、功能設計、代碼編寫和測試等幾個階段，測試、找bug和解決bug往往要花費很多的精力，特別是越是隱藏的深的bug越難發現和解決，隱患也很大。所以每次在傳統方法下發現和解決bug造成的發布延時都會造成整個修復成本的指數級上升。而采用基于模型的設計，則可以在設計的早期通過仿真等手段保證模型的正確性，例如在仿真環境下，我們的模型能夠完全實現我們的意圖，然后自動代碼生成和驗證就是水到渠成的問題了。 其次，基于模型的設計在復雜和非常復雜的系統中特別有意義。他們舉了幾個例子，例如在高檔的汽車上，全部代碼預估已經達到千萬行、甚至兩千萬行的級別了，這么多代碼要是靠手工編寫和測試，首先需要幾十個幾百個人的編程和測試團隊不說，光是溝通的效率就很難保證了;基于模型的設計方法則可以有效解決這個問題。目前在汽車行業，這種模式已經成為主流的開發方法了，在航空航天等領域也得到了很廣泛的應用，例如著名的F-22戰斗機和“好奇號”火星車都使用了基于模型的設計方法。例如講座中提到，火星車的開發中，使用了380000次仿真，這要是按照傳統的測試方法去一遍遍做，估計整個團隊都要吐血身亡了。 此外，開發一個復雜系統要花費大量的時間，新系統開發時從現有系統中復用現有的代碼是省事實力的�；谀Ｐ偷脑O計方法因為使用模型參考調用的方法引用子系統，所以代碼的移植和復用非常方便。例如例如講座中提到，F35戰斗機有A、B、C三種型號，在開發過程中，可以重復使用的系統設計模型就顯著提高了開發效率。 接下來講講我所理解的基于模型設計的開發過程： 1. 系統需求 不管用啥開發方法，最終要完成的系統是一樣的，所以系統需求并沒有什么顯著區別。只不過Simulink開發工具可以在建模中將模型與需求文檔進行關聯，方便快速查看模型功能與需求文檔之間是否有偏差。 2. 建模 就是在Simulink環境中把我們需要的功能用模塊搭建起來，例如控制系統、通信系統等，基于圖形化的編程還是較為直觀和容易的，并且仿真測試很快就能得到結果了。 3. 代碼生成 模型有了，這一步就是超級吸引人的了，直接把模型生成C代碼，多方便的功能。當然有一些規范要定義的，包括一些ISO的標準;而且如果我們使用的處理器被Simulink支持的話，在生成代碼的時候還可以直接針對代碼優化，例如我們的目標對象是TI的一個DSP，則一些數學運算在生成代碼時會直接調用BootROM里的數學庫，相比于傳統的C語言math.h里面的標準數學庫，運行速度要強的多;常用的DSP、ARM等基本都是支持的。 4. 軟件在環測試 硬件在環測試HIL大家可能都聽說過，不過軟件在環測試SIL貌似是個比較新鮮的概念。它的含義就是把生成的c代碼調用到仿真環境中，輸入是與仿真的那步是一樣的，這樣就能比較生成的代碼和我們的模型是否有結果的差異。當然幾乎是不會出現什么狀況的。 5. 硬件在回路測試 這一步很多人都不陌生，就是把生成的代碼下載到實際的控制器中，觀測返回的結果是不是和我們的仿真模型是一致的。 試驗了一下，生成代碼的效率還不錯，可讀性也很好，如果覺得編程太累了，可以嘗試一下。當然有一些功能在Simulink里面實現還是暫時有困難的，例如實時操作系統的任務調度，目前還很難實現出來，所以可以把功能劃分一下，一部分控制系統、通信系統的代碼使用這種方法，其它的則還需要手工編寫，然后通過接口進行協同工作。 |
網友評論