編寫代碼太累?試試基于模型的設計
前一陣參加了MathWorks公司一個關于基于模型的設計的講座,先介紹了基于模型的設計model based design,然后是親自動手體驗;感覺很有意義,特別是其中的自動代碼生成,所以在此和大家分享一下。
本文引用地址:http://www.ex-cimer.com/article/192595.htm聽起來,自動生成代碼好像是專門為不想多動手的工程師準備的工具。其實,自動代碼生成最早是做為基于模型的設計方法的一部分提出的。一般情況下,嵌入式系統(tǒng)軟件的開發(fā)分為需求定義、功能設計、代碼編寫和測試等幾個階段,測試、找bug和解決bug往往要花費很多的精力,特別是越是隱藏的深的bug越難發(fā)現(xiàn)和解決,隱患也很大。所以每次在傳統(tǒng)方法下發(fā)現(xiàn)和解決bug造成的發(fā)布延時都會造成整個修復成本的指數級上升。而采用基于模型的設計,則可以在設計的早期通過仿真等手段保證模型的正確性,例如在仿真環(huán)境下,我們的模型能夠完全實現(xiàn)我們的意圖,然后自動代碼生成和驗證就是水到渠成的問題了。
其次,基于模型的設計在復雜和非常復雜的系統(tǒng)中特別有意義。他們舉了幾個例子,例如在高檔的汽車上,全部代碼預估已經達到千萬行、甚至兩千萬行的級別了,這么多代碼要是靠手工編寫和測試,首先需要幾十個幾百個人的編程和測試團隊不說,光是溝通的效率就很難保證了;基于模型的設計方法則可以有效解決這個問題。目前在汽車行業(yè),這種模式已經成為主流的開發(fā)方法了,在航空航天等領域也得到了很廣泛的應用,例如著名的F-22戰(zhàn)斗機和“好奇號”火星車都使用了基于模型的設計方法。例如講座中提到,火星車的開發(fā)中,使用了380000次仿真,這要是按照傳統(tǒng)的測試方法去一遍遍做,估計整個團隊都要吐血身亡了。
此外,開發(fā)一個復雜系統(tǒng)要花費大量的時間,新系統(tǒng)開發(fā)時從現(xiàn)有系統(tǒng)中復用現(xiàn)有的代碼是省事實力的。基于模型的設計方法因為使用模型參考調用的方法引用子系統(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,則一些數學運算在生成代碼時會直接調用BootROM里的數學庫,相比于傳統(tǒng)的C語言math.h里面的標準數學庫,運行速度要強的多;常用的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é)同工作。
linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解(linux不再難懂)c語言相關文章:c語言教程
評論