由于有了基于模型的設(shè)計，使得開發(fā)大量的汽車嵌入式系統(tǒng)時，可以由模型自動生成最終編譯的軟件。不過，這項工作需要一個軟件工程框架的支持。本文使用線控駕駛系統(tǒng)(steer-by-wire system)作為實例，給出了設(shè)計汽車嵌入式系統(tǒng)的過程、方法和測試工具的一個框架。

近來，有報道稱包括Denso、Motorola和Toyota在內(nèi)的不同行業(yè)的多家公司都在產(chǎn)品代碼方面取得了成功。這項技術(shù)正日益成為軟件下一波演進發(fā)展中的一個重要組成部分。雖然總體而言，它對軟件工程化過程的影響已為業(yè)界所了解，但卻并沒有十分清楚地確立起來。對于早前類似演進發(fā)展(包括從機器代碼發(fā)展到匯編代碼，再發(fā)展到源代碼)的參與者而言，這一點尤為明顯。

隨著抽象與自動化程度的日益提高，新的過程、方法和工具接踵而來。瀑布式過程已讓位于螺旋式方法和迭代方法。實時方法已經(jīng)出現(xiàn)并正在取代靜態(tài)流程設(shè)計。新的工具也出現(xiàn)了，如包含有調(diào)試器、優(yōu)化編譯器和自動測試工具的IDE(集成開發(fā)環(huán)境)。

不過，由于難以使用、缺乏了解或是工具支持不足的原因，并非每一種好的思想都能開花結(jié)果。有跡象表明，這些方法和工具對于主流產(chǎn)品應(yīng)用并非總是實用。例如，用驗證來確保軟件正確性的正規(guī)方法是使用一種全世界只有極少數(shù)專家才真正懂得的語言編寫的。此外，1980年代的實時用例工具可以輔助設(shè)計，但并未提供一條產(chǎn)生最終代碼的簡便途徑。

在早期應(yīng)用階段，產(chǎn)品代碼生成的效果相當不錯，這主要是由于其實用性。不過，其進一步的發(fā)展還需要依靠集成過程、方法和工具的支持。一種新的過程只有在具備了所需支持方法和工具的條件下才會成功。如果這些條件有所欠缺，那么對一個公司成熟的嵌入式系統(tǒng)進行重新設(shè)計的努力就不會是可行和實用的。

本文給出了主要面向產(chǎn)品代碼生成的這樣一個框架：

* 基于模型的設(shè)計
* 建模、仿真、快速原型、產(chǎn)品代碼生成、模型測試和覆蓋、在環(huán)測試
* 開發(fā)工具、驗證與生效(V&V)工具、集成工具

模型的設(shè)計過程

通過提供一個共同的圖形規(guī)范和分析環(huán)境，基于模型的設(shè)計可以支持控制/DSP系統(tǒng)工程師和軟件開發(fā)人員的需要。在這個過程中，模型被創(chuàng)建并用來規(guī)定系統(tǒng)數(shù)據(jù)、接口、反饋控制邏輯、離散/狀態(tài)邏輯和實時行為。

基于模型的設(shè)計被應(yīng)用在幾乎每個需要嵌入式控制系統(tǒng)的行業(yè)之中。而在大型汽車電子控制單元(ECU)等嵌入式應(yīng)用的開發(fā)過程中，其應(yīng)用更為廣泛。DSP和通信應(yīng)用也采用這種方法，但它們更強調(diào)建模和原型，而不是產(chǎn)品代碼生成。

為了滿足這些不同的應(yīng)用，基于模型的設(shè)計過程必須解決線控駕駛系統(tǒng)等安全關(guān)鍵系統(tǒng)的需求。它還必須產(chǎn)生最終的、可執(zhí)行的代碼，而且必須特別緊湊、快速和能夠追蹤。這是由于在大批量生產(chǎn)的ECU中，必須使用低成本的定點微控制器部件和DSP。

基于模型的設(shè)計適合任何過程框架環(huán)境，包括那些在IEEE軟件工程化標準中描述過的過程框架。

IEEE Std. 730適用于任何通用軟件項目。為了很好地理解它的過程框架，有必要回顧一下它對“關(guān)鍵性”項目文檔所列出的需求。

IEEE Std. 730需求包括：

* 軟件需求規(guī)范(SRS)
* 軟件設(shè)計描述(SDD)
* 軟件驗證與生效計劃(SVVP)
* 軟件驗證與生效報告(SVVR)
* 用戶文檔
* 軟件配置管理計劃(SCMP)
* 包括軟件項目管理計劃(SPMP)在內(nèi)的其他文檔

查看一個軟件過程的普通方法是借助于圖1所示的V形圖。

圖1：查看一個軟件過程的普通方法是借助于V形圖
這個圖對應(yīng)著大部分工程化過程，不過在開發(fā)生命周期中，這個過程是迭代性的，有許多反復(fù)的步驟。圖中的軟件過程包括以下幾個組成部分：

* 開發(fā) (需求、設(shè)計、編碼和集成)
* 驗證和生效(V&V)
* 集成 (軟件配置管理、需求可追蹤性和文檔)

基于模型的設(shè)計非常注重過程迭代、早期測試和開發(fā)過程中的重用，這使得它既獨特而又功能強大。這一過程的內(nèi)在實用性體現(xiàn)在V形圖的底部，產(chǎn)品代碼生成是來自設(shè)計的一種自動過渡。

在基于模型的設(shè)計中，方框圖或狀態(tài)圖模型可以用作系統(tǒng)和軟件需求、軟件設(shè)計，或者在稍作假設(shè)變換之后，用作源代碼。這個過程的另外一個獨特之處是，它在最終編譯之前要進行廣泛的驗證和生效操作。早期驗證和生效的好處很明顯：它將大大減少在最終系統(tǒng)集成和測試期間發(fā)現(xiàn)的bug數(shù)目，返工次數(shù)也會更少。

開發(fā)方法與工具

在軟件工程化過程中，采用了基于模型的設(shè)計方法。

開發(fā)方法包括：1. 行為建模；2. 詳細軟件設(shè)計；3. 分布式結(jié)構(gòu)設(shè)計；4. 產(chǎn)品代碼生成；5. 嵌入式目標集成。驗證與生效方法包括：1. 仿真與分析；2. 快速原型；3. 模型測試與覆蓋；4. 代碼追蹤與檢查；5. 硬件在環(huán)(HIL，Hardware-In-the-Loop)測試。集成方法包括：1. 源控制接口；2. 需求管理接口；3. 報告生成。

下面給出了對各種開發(fā)方法的簡潔描述，并提供有例子和工具支持信息。注意這里給出的所有工具都是商業(yè)上可以獲得的。其后的部分討論了開發(fā)行為，并包含有關(guān)鍵的驗證與生效方法。最后，本文將通過集成組件來進行總結(jié)。

1. 行為建模

模型用來為單個子系統(tǒng)(如線控駕駛)的各個方面規(guī)定需求和設(shè)計。

一個典型的系統(tǒng)包括：

* 輸入(如方向盤傳感器)
* 控制器或DSP模型
* 設(shè)備模型(直流馬達、齒條和小齒輪、車輪)
* 輸出(方向的改變)

在圖2和圖3中，通過使用控制系統(tǒng)方框圖來表示反饋控制、使用狀態(tài)圖來表示離散事件和條件邏輯，以及使用DSP模塊來表示濾波器，可以創(chuàng)建一個系統(tǒng)模型來表示所需的行為特性。

圖2：用控制系統(tǒng)方框圖來表示反饋控制

圖3：創(chuàng)建一個系統(tǒng)模型來表示所需的行為特性
2. 仿真與分析

然后，通過使用基于時間或基于事件的仿真以及頻域分析等方法，可以執(zhí)行和分析模型，以確保其滿足需求。例如，一個線控駕駛系統(tǒng)必須對傳感器故障進行響應(yīng)，并“將高頻響應(yīng)衰減到3db以下，同時指令傳輸速率不能低于1.5Mbps”。

圖4A和B*中對線控駕駛系統(tǒng)的建模與仿真,可以確定這些需求是相互沖突的還是有效的。仿真是一個核心驗證行為，它確保可以實現(xiàn)一個系統(tǒng)來滿足這些需求。