基于模型和產(chǎn)品代碼生成的汽車(chē)嵌入式系統設計

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

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

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

圖1：查看一個(gè)軟件過(guò)程的普通方法是借助于V形圖。

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

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

圖2：用控制系統方框圖來(lái)表示反饋控制。

本文給出了主要面向產(chǎn)品代碼生成的這樣一個(gè)框架：
* 基于模型的設計
* 建模、仿真、快速原型、產(chǎn)品代碼生成、模型測試和覆蓋、在環(huán)測試
* 開(kāi)發(fā)工具、驗證與生效(VV)工具、集成工具

模型的設計過(guò)程

圖3：創(chuàng )建一個(gè)系統模型來(lái)表示所需的行為特性。

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

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

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

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

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

IEEE Std. 730需求包括：

圖4：線(xiàn)控駕駛系統。

* 軟件需求規范(SRS)

* 軟件設計描述(SDD)

* 軟件驗證與生效計劃(SVVP)

* 軟件驗證與生效報告(SVVR)

* 用戶(hù)文檔

* 軟件配置管理計劃(SCMP)

* 包括軟件項目管理計劃(SPMP)在內的其他文檔

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

* 開(kāi)發(fā) (需求、設計、編碼和集成)

圖4B：對線(xiàn)控駕駛系統的建模與仿真。

* 驗證和生效(VV)

* 集成 (軟件配置管理、需求可追蹤性和文檔)

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

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

開(kāi)發(fā)方法與工具

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

圖5：故障模式效應分析用來(lái)確保線(xiàn)控駕駛的救生操作。

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

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

1. 行為建模

模型用來(lái)為單個(gè)子系統(如線(xiàn)控駕駛)的各個(gè)方面規定需求和設計。

一個(gè)典型的系統包括：

* 輸入(如方向盤(pán)傳感器)

* 控制器或DSP模型

* 設備模型(直流馬達、齒條和小齒輪、車(chē)輪)

* 輸出(方向的改變)

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

2. 仿真與分析

圖6：圖3中電源管理設計的測試覆蓋。

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

圖4A和B*中對線(xiàn)控駕駛系統的建模與仿真,可以確定這些需求是相互沖突的還是有效的。仿真是一個(gè)核心驗證行為，它確?？梢詫?shí)現一個(gè)系統來(lái)滿(mǎn)足這些需求。

3. 快速原型

要在產(chǎn)品的芯片上實(shí)現一個(gè)可以工作的解決方案，設備模型還不夠精確，處理能力也不滿(mǎn)足要求，因此建模本身并不能提供完整的解決方案。

快速原型對于克服這些缺陷非常有用，因為它用物理設備來(lái)代替設備模型。在線(xiàn)控駕駛的例子中，設備有可能是一輛汽車(chē)，這時(shí)就使用一輛實(shí)際的汽車(chē)。不過(guò)，因為系統并未建立起來(lái)，一個(gè)實(shí)時(shí)或嵌入式平臺將負責運行控制器軟件并與設備進(jìn)行交互作用。

有兩種形式的快速原型：功能性快速原型和目標性快速原型。功能性原型使用一臺功能強大的實(shí)時(shí)計算機，如多處理器浮點(diǎn)PowerPC或DSP系統，目的在于確定系統對物理汽車(chē)的控制是否如對模型汽車(chē)的控制一樣好。如果真的是這樣，則設備模型的不精確性就顯得無(wú)關(guān)緊要，并且控制策略也得到了驗證。

圖7：代碼回放。

目標性快速原型在相同或相似的產(chǎn)品MCU或DSP，而不是高端PowerPC內核或其他專(zhuān)用高端快速原型硬件中執行軟件。目的是將代碼下載到實(shí)際產(chǎn)品目標之中，以便用物理設備進(jìn)行快速測試。如果執行良好，則控制器不僅看似有效，而且可以在產(chǎn)品中加以實(shí)現。

軟件設計行為包括定點(diǎn)數據規范、實(shí)時(shí)任務(wù)、數據輸入、內建測試和診斷。通過(guò)基于模型的設計，用于算法規范和驗證的同一模型被軟件工程師加以改進(jìn)和約束，作為產(chǎn)品代碼生成過(guò)程的一部分。

4. 模型測試

與將模型部署到硬件上去編譯和集成相比，在桌面計算機上測試模型具有更大的優(yōu)勢?；谠创a的測試已經(jīng)存在許多年了，但是最近的方法允許進(jìn)行模型測試和結構覆蓋。使用的場(chǎng)景假定是開(kāi)發(fā)人員對控制器施加滿(mǎn)負荷壓力，以便用仿真和覆蓋來(lái)驗證其設計完備性。另一種測試類(lèi)型是故障模式效應分析(Failure Mode Effect Analysis)，用來(lái)確保故障情況下線(xiàn)控駕駛的救生操作，參見(jiàn)圖5*。

設計完備性不佳的例子是數值溢出和死碼(dead code)。使用最小或最大數值的模型壓力測試可以確保不發(fā)生溢出情況。使用仿真很容易進(jìn)行這種測試，但死碼就沒(méi)有這么容易檢測出來(lái)了，因為檢測需要結構覆蓋。死碼與失效代碼不同，其區別在于后者是開(kāi)發(fā)人員已知，并且出于某種原因而使其失效的。實(shí)際情況中的死碼意味著(zhù)在確定規范期間遺漏了什么。

圖8：器件驅動(dòng)模塊庫。

模型覆蓋用來(lái)評估一個(gè)測試件的累積結果，以確定哪些功能模塊未被執行，或者哪些狀態(tài)未被到達。源代碼語(yǔ)言(如C和C++)中建立了某些類(lèi)型的覆蓋，但現在模型也可以進(jìn)行覆蓋了。這項工作要求C語(yǔ)言所不需要(或不可能有)的新理論和新工具，因為這些語(yǔ)言沒(méi)有功能模塊或狀態(tài)這樣的構造。

修改條件/決策覆蓋(MC/DC)被FAA(美國聯(lián)邦航空管理局)認為是滿(mǎn)足安全關(guān)鍵系統所必需的最嚴格的覆蓋水平?，F在，這種覆蓋在一種基于模型的設計框架和許多需要線(xiàn)控設計的場(chǎng)合中已經(jīng)得到了實(shí)現。

5. 分布式結構設計

現代嵌入式系統包含一些分布式ECU，它們相互間通過(guò)一個(gè)象FlexRay這樣的容錯通信系統進(jìn)行實(shí)時(shí)通信。寶馬(BMW)最新的DSC(動(dòng)態(tài)穩定性控制) 包含ABS作為其15個(gè)子功能之一。通過(guò)從DECOMSYS向單個(gè)子系統增加主機、任務(wù)和信號等網(wǎng)絡(luò )部件，嵌入式功能可以連接和映射到一個(gè)ECU結構之上。此外，它方便了OSEKtime/OS等時(shí)間觸發(fā)操作系統的任務(wù)激活時(shí)間行為的仿真。集群、主機、任務(wù)和連接是在MATLAB/Simulink環(huán)境下進(jìn)行設計和仿真的。最后，整個(gè)設計與DECOMSYS::DESIGNER產(chǎn)品實(shí)現了無(wú)縫集成，可以與FlexRay xCDEF設計數據倉庫進(jìn)行互動(dòng)。

Vector 公司和Cadence公司提供的分布式網(wǎng)絡(luò )設計解決方案(分別為DaVinci和SysDesign)集成了Simulink/Stateflow的 Real-Time Workshop/Real-Time Workshop Embedded Coder，由子系統產(chǎn)生代碼，并將它們映射到結構上進(jìn)行驗證。

產(chǎn)品代碼生成

模型經(jīng)過(guò)驗證并且生效之后，就該產(chǎn)生代碼了。使用編譯器時(shí)，這個(gè)過(guò)程是簡(jiǎn)單的。這里存在著(zhù)各種不同的優(yōu)化設置和用戶(hù)配置選項。關(guān)鍵之處在于保持代碼的高效、精確并與原有的代碼或其他工具進(jìn)行集成。另一個(gè)要點(diǎn)是保持代碼相對框圖的可追蹤性，以便進(jìn)行檢查和驗證。

1. 代碼追蹤和檢查

圖7顯示了一個(gè)自動(dòng)鏈接的HTML報告。當開(kāi)發(fā)人員選擇代碼中的求和模塊時(shí)，它將把該模塊在框圖中進(jìn)行高亮顯示。

2. 嵌入式目標集成

圖6*中的應用使用了速率轉換模塊。不過(guò)，它與商用RTOS之間也存在著(zhù)直接的聯(lián)系，包括VxWorks 和各種OSEK產(chǎn)品。如圖7*所示，還需要集成設備驅動(dòng)程序。

3. 硬件在環(huán)測試

控制器建立起來(lái)之后，就可以在環(huán)路中使用實(shí)時(shí)設備模型來(lái)執行一系列開(kāi)環(huán)和閉環(huán)測試了。有一種測試僅涉及處理器，稱(chēng)作“處理器在環(huán)”測試。另一種測試使用實(shí)際建立的ECU硬件，叫做“硬件在環(huán)”測試。在這兩種測試中，都使用設備模型來(lái)對物理控制器進(jìn)行測試。通過(guò)這一系列測試(或許與需求驗證中所用的是同種測試)，控制器必須看來(lái)對于消費者是可以接受的。

4. 集成組件

在開(kāi)發(fā)過(guò)程中，大部分軟件標準都要求需求追蹤能力，這或許源于其他需求工具。此外，還需要軟件配置管理(SCM)來(lái)對開(kāi)發(fā)過(guò)程中的各種工件(artifact)進(jìn)行存儲、版本維護和查找。由報告生成工具產(chǎn)生的文檔將確保管理者、消費者和供應商能夠看到模型。SCM的接口如圖8*所示。

本文小結

當整個(gè)軟件工程化過(guò)程行為得到支持時(shí)，將會(huì )推動(dòng)軟件的進(jìn)步。但是，僅僅進(jìn)行局部的、支離破碎的改進(jìn)是不足夠。本文介紹了基于模型的設計和產(chǎn)品代碼生成的一個(gè)完整的軟件工程化框架，并且還給出了具體的方法和工具，意在表明它并非僅僅是一種理論，而是既實(shí)用又有效。

參考文獻

[1]www.mathworks.com
[2] www.ieee.org
[3] B. Aldrich, "Using model coverage analysis to improve the controls development process," AIAA 2002
[4] "Software considerations in airborne systems and equipment certification," RTCA/DO-178B, RTCA Inc., Dec. 1992
[5] Dr. Michael von der Beeck, ARTIST Industrial Seminar, Paris, 23.4.2002 http://www.artistembedded.org/PastEvents/Kickoffs/BMW.pdf
[6] www.decomsys.com
[7] Paul Yih, Jihan Ryu, J. Christian Gerdes, Modification of Vehicle Handling Characteristics via Steer-by-Wire, Dept. of Mechanical Engineering, Stanford University