嵌入式線控駕駛系統(tǒng)開發(fā)過程中設(shè)計(jì)和測試考慮
[導(dǎo)讀]由于有了基于模型的設(shè)計(jì)，使得開發(fā)大量的汽車嵌入式系統(tǒng)時，可以由模型自動生成最終編譯的軟件。不過，這項(xiàng)工作需要一個軟件工程框架的支持。本文使用線控駕駛系統(tǒng)(steer-by-wire system)作為實(shí)例，給出了設(shè)計(jì)汽車嵌入式系統(tǒng)的過程、方法和測試工具的一個框架。 近來，有報道稱包括Denso、Mo
由于有了基于模型的設(shè)計(jì)，使得開發(fā)大量的汽車嵌入式系統(tǒng)時，可以由模型自動生成最終編譯的軟件。不過，這項(xiàng)工作需要一個軟件工程框架的支持。本文使用線控駕駛系統(tǒng)(steer-by-wire system)作為實(shí)例，給出了設(shè)計(jì)汽車嵌入式系統(tǒng)的過程、方法和測試工具的一個框架。
近來，有報道稱包括Denso、Motorola和Toyota在內(nèi)的不同行業(yè)的多家公司都在產(chǎn)品代碼方面取得了成功。這項(xiàng)技術(shù)正日益成為軟件下一波演進(jìn)發(fā)展中的一個重要組成部分。雖然總體而言，它對軟件工程化過程的影響已為業(yè)界所了解，但卻并沒有十分清楚地確立起來。對于早前類似演進(jìn)發(fā)展(包括從機(jī)器代碼發(fā)展到匯編代碼，再發(fā)展到源代碼)的參與者而言，這一點(diǎn)尤為明顯。
隨著抽象與自動化程度的日益提高，新的過程、方法和工具接踵而來。瀑布式過程已讓位于螺旋式方法和迭代方法。實(shí)時方法已經(jīng)出現(xiàn)并正在取代靜態(tài)流程設(shè)計(jì)。新的工具也出現(xiàn)了，如包含有調(diào)試器、優(yōu)化編譯器和自動測試工具的IDE(集成開發(fā)環(huán)境)。
不過，由于難以使用、缺乏了解或是工具支持不足的原因，并非每一種好的思想都能開花結(jié)果。有跡象表明，這些方法和工具對于主流產(chǎn)品應(yīng)用并非總是實(shí)用。例如，用驗(yàn)證來確保軟件正確性的正規(guī)方法是使用一種全世界只有極少數(shù)專家才真正懂得的語言編寫的。此外，1980年代的實(shí)時用例工具可以輔助設(shè)計(jì)，但并未提供一條產(chǎn)生最終代碼的簡便途徑。
在早期應(yīng)用階段，產(chǎn)品代碼生成的效果相當(dāng)不錯，這主要是由于其實(shí)用性。不過，其進(jìn)一步的發(fā)展還需要依靠集成過程、方法和工具的支持。一種新的過程只有在具備了所需支持方法和工具的條件下才會成功。如果這些條件有所欠缺，那么對一個公司成熟的嵌入式系統(tǒng)進(jìn)行重新設(shè)計(jì)的努力就不會是可行和實(shí)用的。
本文給出了主要面向產(chǎn)品代碼生成的這樣一個框架：
* 基于模型的設(shè)計(jì)
* 建模、仿真、快速原型、產(chǎn)品代碼生成、模型測試和覆蓋、在環(huán)測試
* 開發(fā)工具、驗(yàn)證與生效(V&V)工具、集成工具
模型的設(shè)計(jì)過程
通過提供一個共同的圖形規(guī)范和分析環(huán)境，基于模型的設(shè)計(jì)可以支持控制/DSP系統(tǒng)工程師和軟件開發(fā)人員的需要。在這個過程中，模型被創(chuàng)建并用來規(guī)定系統(tǒng)數(shù)據(jù)、接口、反饋控制邏輯、離散/狀態(tài)邏輯和實(shí)時行為。
基于模型的設(shè)計(jì)被應(yīng)用在幾乎每個需要嵌入式控制系統(tǒng)的行業(yè)之中。而在大型汽車電子控制單元(ECU)等嵌入式應(yīng)用的開發(fā)過程中，其應(yīng)用更為廣泛。DSP和通信應(yīng)用也采用這種方法，但它們更強(qiáng)調(diào)建模和原型，而不是產(chǎn)品代碼生成。
為了滿足這些不同的應(yīng)用，基于模型的設(shè)計(jì)過程必須解決線控駕駛系統(tǒng)等安全關(guān)鍵系統(tǒng)的需求。它還必須產(chǎn)生最終的、可執(zhí)行的代碼，而且必須特別緊湊、快速和能夠追蹤。這是由于在大批量生產(chǎn)的ECU中，必須使用低成本的定點(diǎn)微控制器部件和DSP。
基于模型的設(shè)計(jì)適合任何過程框架環(huán)境，包括那些在IEEE軟件工程化標(biāo)準(zhǔn)中描述過的過程框架。
IEEE Std. 730適用于任何通用軟件項(xiàng)目。為了很好地理解它的過程框架，有必要回顧一下它對“關(guān)鍵性”項(xiàng)目文檔所列出的需求。
IEEE Std. 730需求包括：
* 軟件需求規(guī)范(SRS)
* 軟件設(shè)計(jì)描述(SDD)
* 軟件驗(yàn)證與生效計(jì)劃(SVVP)
* 軟件驗(yàn)證與生效報告(SVVR)
* 用戶文檔
* 軟件配置管理計(jì)劃(SCMP)
* 包括軟件項(xiàng)目管理計(jì)劃(SPMP)在內(nèi)的其他文檔
* 開發(fā) (需求、設(shè)計(jì)、編碼和集成)
* 驗(yàn)證和生效(V&V)
* 集成 (軟件配置管理、需求可追蹤性和文檔)
基于模型的設(shè)計(jì)非常注重過程迭代、早期測試和開發(fā)過程中的重用，這使得它既獨(dú)特而又功能強(qiáng)大。這一過程的內(nèi)在實(shí)用性體現(xiàn)在V形圖的底部，產(chǎn)品代碼生成是來自設(shè)計(jì)的一種自動過渡。
在基于模型的設(shè)計(jì)中，方框圖或狀態(tài)圖模型可以用作系統(tǒng)和軟件需求、軟件設(shè)計(jì)，或者在稍作假設(shè)變換之后，用作源代碼。這個過程的另外一個獨(dú)特之處是，它在最終編譯之前要進(jìn)行廣泛的驗(yàn)證和生效操作。早期驗(yàn)證和生效的好處很明顯：它將大大減少在最終系統(tǒng)集成和測試期間發(fā)現(xiàn)的bug數(shù)目，返工次數(shù)也會更少。
開發(fā)方法與工具
在軟件工程化過程中，采用了基于模型的設(shè)計(jì)方法
開發(fā)方法包括：1. 行為建模；2. 詳細(xì)軟件設(shè)計(jì)；3. 分布式結(jié)構(gòu)設(shè)計(jì)；4. 產(chǎn)品代碼生成；5. 嵌入式目標(biāo)集成。驗(yàn)證與生效方法包括：1. 仿真與分析；2. 快速原型；3. 模型測試與覆蓋；4. 代碼追蹤與檢查；5. 硬件在環(huán)(HIL，Hardware-In-the-Loop)測試。集成方法包括：1. 源控制接口；2. 需求管理接口；3. 報告生成。
下面給出了對各種開發(fā)方法的簡潔描述，并提供有例子和工具支持信息。注意這里給出的所有工具都是商業(yè)上可以獲得的。其后的部分討論了開發(fā)行為，并包含有關(guān)鍵的驗(yàn)證與生效方法。最后，本文將通過集成組件來進(jìn)行總結(jié)。
1. 行為建模
模型用來為單個子系統(tǒng)(如線控駕駛)的各個方面規(guī)定需求和設(shè)計(jì)。
一個典型的系統(tǒng)包括：
* 輸入(如方向盤傳感器)
* 控制器或DSP模型
* 設(shè)備模型(直流馬達(dá)、齒條和小齒輪、車輪)
* 輸出(方向的改變)
然后，通過使用基于時間或基于事件的仿真以及頻域分析等方法，可以執(zhí)行和分析模型，以確保其滿足需求。例如，一個線控駕駛系統(tǒng)必須對傳感器故障進(jìn)行響應(yīng)，并“將高頻響應(yīng)衰減到3db以下，同時指令傳輸速率不能低于1.5Mbps”。
圖4A和B*中對線控駕駛系統(tǒng)的建模與仿真,可以確定這些需求是相互沖突的還是有效的。仿真是一個核心驗(yàn)證行為，它確?？梢詫?shí)現(xiàn)一個系統(tǒng)來滿足這些需求。
要在產(chǎn)品的芯片上實(shí)現(xiàn)一個可以工作的解決方案，設(shè)備模型還不夠精確，處理能力也不滿足要求，因此建模本身并不能提供完整的解決方案。
快速原型對于克服這些缺陷非常有用，因?yàn)樗梦锢碓O(shè)備來代替設(shè)備模型。在線控駕駛的例子中，設(shè)備有可能是一輛汽車，這時就使用一輛實(shí)際的汽車。不過，因?yàn)橄到y(tǒng)并未建立起來，一個實(shí)時或嵌入式平臺將負(fù)責(zé)運(yùn)行控制器軟件并與設(shè)備進(jìn)行交互作用。
有兩種形式的快速原型：功能性快速原型和目標(biāo)性快速原型。功能性原型使用一臺功能強(qiáng)大的實(shí)時計(jì)算機(jī)，如多處理器浮點(diǎn)PowerPC或DSP系統(tǒng)，目的在于確定系統(tǒng)對物理汽車的控制是否如對模型汽車的控制一樣好。如果真的是這樣，則設(shè)備模型的不精確性就顯得無關(guān)緊要，并且控制策略也得到了驗(yàn)證。
目標(biāo)性快速原型在相同或相似的產(chǎn)品MCU或DSP，而不是高端PowerPC內(nèi)核或其他專用高端快速原型硬件中執(zhí)行軟件。目的是將代碼下載到實(shí)際產(chǎn)品目標(biāo)之中，以便用物理設(shè)備進(jìn)行快速測試。如果執(zhí)行良好，則控制器不僅看似有效，而且可以在產(chǎn)品中加以實(shí)現(xiàn)。
軟件設(shè)計(jì)行為包括定點(diǎn)數(shù)據(jù)規(guī)范、實(shí)時任務(wù)、數(shù)據(jù)輸入、內(nèi)建測試和診斷。通過基于模型的設(shè)計(jì)，用于算法規(guī)范和驗(yàn)證的同一模型被軟件工程師加以改進(jìn)和約束，作為產(chǎn)品代碼生成過程的一部分。
4. 模型測試
與將模型部署到硬件上去編譯和集成相比，在桌面計(jì)算機(jī)上測試模型具有更大的優(yōu)勢?；谠创a的測試已經(jīng)存在許多年了，但是最近的方法允許進(jìn)行模型測試和結(jié)構(gòu)覆蓋。使用的場景假定是開發(fā)人員對控制器施加滿負(fù)荷壓力，以便用仿真和覆蓋來驗(yàn)證其設(shè)計(jì)完備性。另一種測試類型是故障模式效應(yīng)分析(Failure Mode Effect Analysis)，用來確保故障情況下線控駕駛的救生操作，參見圖5*。
模型覆蓋用來評估一個測試件的累積結(jié)果，以確定哪些功能模塊未被執(zhí)行，或者哪些狀態(tài)未被到達(dá)。源代碼語言(如C和C++)中建立了某些類型的覆蓋，但現(xiàn)在模型也可以進(jìn)行覆蓋了。這項(xiàng)工作要求C語言所不需要(或不可能有)的新理論和新工具，因?yàn)檫@些語言沒有功能模塊或狀態(tài)這樣的構(gòu)造。
修改條件/決策覆蓋(MC/DC)被FAA(美國聯(lián)邦航空管理局)認(rèn)為是滿足安全關(guān)鍵系統(tǒng)所必需的最嚴(yán)格的覆蓋水平。現(xiàn)在，這種覆蓋在一種基于模型的設(shè)計(jì)框架和許多需要線控設(shè)計(jì)的場合中已經(jīng)得到了實(shí)現(xiàn)。
5. 分布式結(jié)構(gòu)設(shè)計(jì)
現(xiàn)代嵌入式系統(tǒng)包含一些分布式ECU，它們相互間通過一個象FlexRay這樣的容錯通信系統(tǒng)進(jìn)行實(shí)時通信。寶馬(BMW)最新的DSC(動態(tài)穩(wěn)定性控制)包含ABS作為其15個子功能之一。通過從DECOMSYS向單個子系統(tǒng)增加主機(jī)、任務(wù)和信號等網(wǎng)絡(luò)部件，嵌入式功能可以連接和映射到一個ECU結(jié)構(gòu)之上。此外，它方便了OSEKtime/OS等時間觸發(fā)操作系統(tǒng)的任務(wù)激活時間行為的仿真。集群、主機(jī)、任務(wù)和連接是在MATLAB/Simulink環(huán)境下進(jìn)行設(shè)計(jì)和仿真的。最后，整個設(shè)計(jì)與DECOMSYS::DESIGNER產(chǎn)品實(shí)現(xiàn)了無縫集成，可以與FlexRay xCDEF設(shè)計(jì)數(shù)據(jù)倉庫進(jìn)行互動。
Vector公司和Cadence公司提供的分布式網(wǎng)絡(luò)設(shè)計(jì)解決方案(分別為DaVinci和SysDesign)集成了Simulink/Stateflow的Real-Time Workshop/Real-Time Workshop Embedded Coder，由子系統(tǒng)產(chǎn)生代碼，并將它們映射到結(jié)構(gòu)上進(jìn)行驗(yàn)證。
產(chǎn)品代碼生成 模型經(jīng)過驗(yàn)證并且生效之后，就該產(chǎn)生代碼了。使用編譯器時，這個過程是簡單的。這里存在著各種不同的優(yōu)化設(shè)置和用戶配置選項(xiàng)。關(guān)鍵之處在于保持代碼的高效、精確并與原有的代碼或其他工具進(jìn)行集成。另一個要點(diǎn)是保持代碼相對框圖的可追蹤性，以便進(jìn)行檢查和驗(yàn)證。
圖7顯示了一個自動鏈接的HTML報告。當(dāng)開發(fā)人員選擇代碼中的求和模塊時，它將把該模塊在框圖中進(jìn)行高亮顯示。
圖6*中的應(yīng)用使用了速率轉(zhuǎn)換模塊。不過，它與商用RTOS之間也存在著直接的聯(lián)系，包括VxWorks 和各種OSEK產(chǎn)品。如圖7*所示，還需要集成設(shè)備驅(qū)動程序。
3. 硬件在環(huán)測試
控制器建立起來之后，就可以在環(huán)路中使用實(shí)時設(shè)備模型來執(zhí)行一系列開環(huán)和閉環(huán)測試了。有一種測試僅涉及處理器，稱作“處理器在環(huán)”測試。另一種測試使用實(shí)際建立的ECU硬件，叫做“硬件在環(huán)”測試。在這兩種測試中，都使用設(shè)備模型來對物理控制器進(jìn)行測試。通過這一系列測試(或許與需求驗(yàn)證中所用的是同種測試)，控制器必須看來對于消費(fèi)者是可以接受的。
4. 集成組件
在開發(fā)過程中，大部分軟件標(biāo)準(zhǔn)都要求需求追蹤能力，這或許源于其他需求工具。此外，還需要軟件配置管理(SCM)來對開發(fā)過程中的各種工件(artifact)進(jìn)行存儲、版本維護(hù)和查找。由報告生成工具產(chǎn)生的文檔將確保管理者、消費(fèi)者和供應(yīng)商能夠看到模型。SCM的接口如圖8*所示。
當(dāng)整個軟件工程化過程行為得到支持時，將會推動軟件的進(jìn)步。但是，僅僅進(jìn)行局部的、支離破碎的改進(jìn)是不足夠。本文介紹了基于模型的設(shè)計(jì)和產(chǎn)品代碼生成的一個完整的軟件工程化框架，并且還給出了具體的方法和工具，意在表明它并非僅僅是一種理論，而是既實(shí)用又有效。
近來，有報道稱包括Denso、Motorola和Toyota在內(nèi)的不同行業(yè)的多家公司都在產(chǎn)品代碼方面取得了成功。這項(xiàng)技術(shù)正日益成為軟件下一波演進(jìn)發(fā)展中的一個重要組成部分。雖然總體而言，它對軟件工程化過程的影響已為業(yè)界所了解，但卻并沒有十分清楚地確立起來。對于早前類似演進(jìn)發(fā)展(包括從機(jī)器代碼發(fā)展到匯編代碼，再發(fā)展到源代碼)的參與者而言，這一點(diǎn)尤為明顯。
隨著抽象與自動化程度的日益提高，新的過程、方法和工具接踵而來。瀑布式過程已讓位于螺旋式方法和迭代方法。實(shí)時方法已經(jīng)出現(xiàn)并正在取代靜態(tài)流程設(shè)計(jì)。新的工具也出現(xiàn)了，如包含有調(diào)試器、優(yōu)化編譯器和自動測試工具的IDE(集成開發(fā)環(huán)境)。
不過，由于難以使用、缺乏了解或是工具支持不足的原因，并非每一種好的思想都能開花結(jié)果。有跡象表明，這些方法和工具對于主流產(chǎn)品應(yīng)用并非總是實(shí)用。例如，用驗(yàn)證來確保軟件正確性的正規(guī)方法是使用一種全世界只有極少數(shù)專家才真正懂得的語言編寫的。此外，1980年代的實(shí)時用例工具可以輔助設(shè)計(jì)，但并未提供一條產(chǎn)生最終代碼的簡便途徑。
在早期應(yīng)用階段，產(chǎn)品代碼生成的效果相當(dāng)不錯，這主要是由于其實(shí)用性。不過，其進(jìn)一步的發(fā)展還需要依靠集成過程、方法和工具的支持。一種新的過程只有在具備了所需支持方法和工具的條件下才會成功。如果這些條件有所欠缺，那么對一個公司成熟的嵌入式系統(tǒng)進(jìn)行重新設(shè)計(jì)的努力就不會是可行和實(shí)用的。
本文給出了主要面向產(chǎn)品代碼生成的這樣一個框架：
* 基于模型的設(shè)計(jì)
* 建模、仿真、快速原型、產(chǎn)品代碼生成、模型測試和覆蓋、在環(huán)測試
* 開發(fā)工具、驗(yàn)證與生效(V&V)工具、集成工具
模型的設(shè)計(jì)過程
通過提供一個共同的圖形規(guī)范和分析環(huán)境，基于模型的設(shè)計(jì)可以支持控制/DSP系統(tǒng)工程師和軟件開發(fā)人員的需要。在這個過程中，模型被創(chuàng)建并用來規(guī)定系統(tǒng)數(shù)據(jù)、接口、反饋控制邏輯、離散/狀態(tài)邏輯和實(shí)時行為。
基于模型的設(shè)計(jì)被應(yīng)用在幾乎每個需要嵌入式控制系統(tǒng)的行業(yè)之中。而在大型汽車電子控制單元(ECU)等嵌入式應(yīng)用的開發(fā)過程中，其應(yīng)用更為廣泛。DSP和通信應(yīng)用也采用這種方法，但它們更強(qiáng)調(diào)建模和原型，而不是產(chǎn)品代碼生成。
為了滿足這些不同的應(yīng)用，基于模型的設(shè)計(jì)過程必須解決線控駕駛系統(tǒng)等安全關(guān)鍵系統(tǒng)的需求。它還必須產(chǎn)生最終的、可執(zhí)行的代碼，而且必須特別緊湊、快速和能夠追蹤。這是由于在大批量生產(chǎn)的ECU中，必須使用低成本的定點(diǎn)微控制器部件和DSP。
基于模型的設(shè)計(jì)適合任何過程框架環(huán)境，包括那些在IEEE軟件工程化標(biāo)準(zhǔn)中描述過的過程框架。
IEEE Std. 730適用于任何通用軟件項(xiàng)目。為了很好地理解它的過程框架，有必要回顧一下它對“關(guān)鍵性”項(xiàng)目文檔所列出的需求。
IEEE Std. 730需求包括：
* 軟件需求規(guī)范(SRS)
* 軟件設(shè)計(jì)描述(SDD)
* 軟件驗(yàn)證與生效計(jì)劃(SVVP)
* 軟件驗(yàn)證與生效報告(SVVR)
* 用戶文檔
* 軟件配置管理計(jì)劃(SCMP)
* 包括軟件項(xiàng)目管理計(jì)劃(SPMP)在內(nèi)的其他文檔
圖1：查看一個軟件過程的普通方法是借助于V形圖
* 開發(fā) (需求、設(shè)計(jì)、編碼和集成)
* 驗(yàn)證和生效(V&V)
* 集成 (軟件配置管理、需求可追蹤性和文檔)
基于模型的設(shè)計(jì)非常注重過程迭代、早期測試和開發(fā)過程中的重用，這使得它既獨(dú)特而又功能強(qiáng)大。這一過程的內(nèi)在實(shí)用性體現(xiàn)在V形圖的底部，產(chǎn)品代碼生成是來自設(shè)計(jì)的一種自動過渡。
在基于模型的設(shè)計(jì)中，方框圖或狀態(tài)圖模型可以用作系統(tǒng)和軟件需求、軟件設(shè)計(jì)，或者在稍作假設(shè)變換之后，用作源代碼。這個過程的另外一個獨(dú)特之處是，它在最終編譯之前要進(jìn)行廣泛的驗(yàn)證和生效操作。早期驗(yàn)證和生效的好處很明顯：它將大大減少在最終系統(tǒng)集成和測試期間發(fā)現(xiàn)的bug數(shù)目，返工次數(shù)也會更少。
開發(fā)方法與工具
在軟件工程化過程中，采用了基于模型的設(shè)計(jì)方法
開發(fā)方法包括：1. 行為建模；2. 詳細(xì)軟件設(shè)計(jì)；3. 分布式結(jié)構(gòu)設(shè)計(jì)；4. 產(chǎn)品代碼生成；5. 嵌入式目標(biāo)集成。驗(yàn)證與生效方法包括：1. 仿真與分析；2. 快速原型；3. 模型測試與覆蓋；4. 代碼追蹤與檢查；5. 硬件在環(huán)(HIL，Hardware-In-the-Loop)測試。集成方法包括：1. 源控制接口；2. 需求管理接口；3. 報告生成。
下面給出了對各種開發(fā)方法的簡潔描述，并提供有例子和工具支持信息。注意這里給出的所有工具都是商業(yè)上可以獲得的。其后的部分討論了開發(fā)行為，并包含有關(guān)鍵的驗(yàn)證與生效方法。最后，本文將通過集成組件來進(jìn)行總結(jié)。
1. 行為建模
模型用來為單個子系統(tǒng)(如線控駕駛)的各個方面規(guī)定需求和設(shè)計(jì)。
一個典型的系統(tǒng)包括：
* 輸入(如方向盤傳感器)
* 控制器或DSP模型
* 設(shè)備模型(直流馬達(dá)、齒條和小齒輪、車輪)
* 輸出(方向的改變)
圖2：用控制系統(tǒng)方框圖來表示反饋控制
圖3：創(chuàng)建一個系統(tǒng)模型來表示所需的行為特性
然后，通過使用基于時間或基于事件的仿真以及頻域分析等方法，可以執(zhí)行和分析模型，以確保其滿足需求。例如，一個線控駕駛系統(tǒng)必須對傳感器故障進(jìn)行響應(yīng)，并“將高頻響應(yīng)衰減到3db以下，同時指令傳輸速率不能低于1.5Mbps”。
圖4A和B*中對線控駕駛系統(tǒng)的建模與仿真,可以確定這些需求是相互沖突的還是有效的。仿真是一個核心驗(yàn)證行為，它確?？梢詫?shí)現(xiàn)一個系統(tǒng)來滿足這些需求。
圖4：線控駕駛系統(tǒng)
要在產(chǎn)品的芯片上實(shí)現(xiàn)一個可以工作的解決方案，設(shè)備模型還不夠精確，處理能力也不滿足要求，因此建模本身并不能提供完整的解決方案。
快速原型對于克服這些缺陷非常有用，因?yàn)樗梦锢碓O(shè)備來代替設(shè)備模型。在線控駕駛的例子中，設(shè)備有可能是一輛汽車，這時就使用一輛實(shí)際的汽車。不過，因?yàn)橄到y(tǒng)并未建立起來，一個實(shí)時或嵌入式平臺將負(fù)責(zé)運(yùn)行控制器軟件并與設(shè)備進(jìn)行交互作用。
有兩種形式的快速原型：功能性快速原型和目標(biāo)性快速原型。功能性原型使用一臺功能強(qiáng)大的實(shí)時計(jì)算機(jī)，如多處理器浮點(diǎn)PowerPC或DSP系統(tǒng)，目的在于確定系統(tǒng)對物理汽車的控制是否如對模型汽車的控制一樣好。如果真的是這樣，則設(shè)備模型的不精確性就顯得無關(guān)緊要，并且控制策略也得到了驗(yàn)證。
目標(biāo)性快速原型在相同或相似的產(chǎn)品MCU或DSP，而不是高端PowerPC內(nèi)核或其他專用高端快速原型硬件中執(zhí)行軟件。目的是將代碼下載到實(shí)際產(chǎn)品目標(biāo)之中，以便用物理設(shè)備進(jìn)行快速測試。如果執(zhí)行良好，則控制器不僅看似有效，而且可以在產(chǎn)品中加以實(shí)現(xiàn)。
軟件設(shè)計(jì)行為包括定點(diǎn)數(shù)據(jù)規(guī)范、實(shí)時任務(wù)、數(shù)據(jù)輸入、內(nèi)建測試和診斷。通過基于模型的設(shè)計(jì)，用于算法規(guī)范和驗(yàn)證的同一模型被軟件工程師加以改進(jìn)和約束，作為產(chǎn)品代碼生成過程的一部分。
4. 模型測試
與將模型部署到硬件上去編譯和集成相比，在桌面計(jì)算機(jī)上測試模型具有更大的優(yōu)勢?；谠创a的測試已經(jīng)存在許多年了，但是最近的方法允許進(jìn)行模型測試和結(jié)構(gòu)覆蓋。使用的場景假定是開發(fā)人員對控制器施加滿負(fù)荷壓力，以便用仿真和覆蓋來驗(yàn)證其設(shè)計(jì)完備性。另一種測試類型是故障模式效應(yīng)分析(Failure Mode Effect Analysis)，用來確保故障情況下線控駕駛的救生操作，參見圖5*。
圖5：故障模式效應(yīng)分析用來確保線控駕駛的救生操作
模型覆蓋用來評估一個測試件的累積結(jié)果，以確定哪些功能模塊未被執(zhí)行，或者哪些狀態(tài)未被到達(dá)。源代碼語言(如C和C++)中建立了某些類型的覆蓋，但現(xiàn)在模型也可以進(jìn)行覆蓋了。這項(xiàng)工作要求C語言所不需要(或不可能有)的新理論和新工具，因?yàn)檫@些語言沒有功能模塊或狀態(tài)這樣的構(gòu)造。
修改條件/決策覆蓋(MC/DC)被FAA(美國聯(lián)邦航空管理局)認(rèn)為是滿足安全關(guān)鍵系統(tǒng)所必需的最嚴(yán)格的覆蓋水平。現(xiàn)在，這種覆蓋在一種基于模型的設(shè)計(jì)框架和許多需要線控設(shè)計(jì)的場合中已經(jīng)得到了實(shí)現(xiàn)。
5. 分布式結(jié)構(gòu)設(shè)計(jì)
現(xiàn)代嵌入式系統(tǒng)包含一些分布式ECU，它們相互間通過一個象FlexRay這樣的容錯通信系統(tǒng)進(jìn)行實(shí)時通信。寶馬(BMW)最新的DSC(動態(tài)穩(wěn)定性控制)包含ABS作為其15個子功能之一。通過從DECOMSYS向單個子系統(tǒng)增加主機(jī)、任務(wù)和信號等網(wǎng)絡(luò)部件，嵌入式功能可以連接和映射到一個ECU結(jié)構(gòu)之上。此外，它方便了OSEKtime/OS等時間觸發(fā)操作系統(tǒng)的任務(wù)激活時間行為的仿真。集群、主機(jī)、任務(wù)和連接是在MATLAB/Simulink環(huán)境下進(jìn)行設(shè)計(jì)和仿真的。最后，整個設(shè)計(jì)與DECOMSYS::DESIGNER產(chǎn)品實(shí)現(xiàn)了無縫集成，可以與FlexRay xCDEF設(shè)計(jì)數(shù)據(jù)倉庫進(jìn)行互動。
Vector公司和Cadence公司提供的分布式網(wǎng)絡(luò)設(shè)計(jì)解決方案(分別為DaVinci和SysDesign)集成了Simulink/Stateflow的Real-Time Workshop/Real-Time Workshop Embedded Coder，由子系統(tǒng)產(chǎn)生代碼，并將它們映射到結(jié)構(gòu)上進(jìn)行驗(yàn)證。
產(chǎn)品代碼生成 模型經(jīng)過驗(yàn)證并且生效之后，就該產(chǎn)生代碼了。使用編譯器時，這個過程是簡單的。這里存在著各種不同的優(yōu)化設(shè)置和用戶配置選項(xiàng)。關(guān)鍵之處在于保持代碼的高效、精確并與原有的代碼或其他工具進(jìn)行集成。另一個要點(diǎn)是保持代碼相對框圖的可追蹤性，以便進(jìn)行檢查和驗(yàn)證。
圖6：圖3中電源管理設(shè)計(jì)的測試覆蓋
圖7顯示了一個自動鏈接的HTML報告。當(dāng)開發(fā)人員選擇代碼中的求和模塊時，它將把該模塊在框圖中進(jìn)行高亮顯示。
圖7：代碼回放
圖6*中的應(yīng)用使用了速率轉(zhuǎn)換模塊。不過，它與商用RTOS之間也存在著直接的聯(lián)系，包括VxWorks 和各種OSEK產(chǎn)品。如圖7*所示，還需要集成設(shè)備驅(qū)動程序。
3. 硬件在環(huán)測試
控制器建立起來之后，就可以在環(huán)路中使用實(shí)時設(shè)備模型來執(zhí)行一系列開環(huán)和閉環(huán)測試了。有一種測試僅涉及處理器，稱作“處理器在環(huán)”測試。另一種測試使用實(shí)際建立的ECU硬件，叫做“硬件在環(huán)”測試。在這兩種測試中，都使用設(shè)備模型來對物理控制器進(jìn)行測試。通過這一系列測試(或許與需求驗(yàn)證中所用的是同種測試)，控制器必須看來對于消費(fèi)者是可以接受的。
4. 集成組件
在開發(fā)過程中，大部分軟件標(biāo)準(zhǔn)都要求需求追蹤能力，這或許源于其他需求工具。此外，還需要軟件配置管理(SCM)來對開發(fā)過程中的各種工件(artifact)進(jìn)行存儲、版本維護(hù)和查找。由報告生成工具產(chǎn)生的文檔將確保管理者、消費(fèi)者和供應(yīng)商能夠看到模型。SCM的接口如圖8*所示。
圖8：器件驅(qū)動模塊庫
當(dāng)整個軟件工程化過程行為得到支持時，將會推動軟件的進(jìn)步。但是，僅僅進(jìn)行局部的、支離破碎的改進(jìn)是不足夠。本文介紹了基于模型的設(shè)計(jì)和產(chǎn)品代碼生成的一個完整的軟件工程化框架，并且還給出了具體的方法和工具，意在表明它并非僅僅是一種理論，而是既實(shí)用又有效。
下載文檔
