 |
圖4：線控駕駛系統(tǒng)。 |
* 軟件需求規(guī)范(SRS)
* 軟件設計描述(SDD)
* 軟件驗證與生效計劃(SVVP)
* 軟件驗證與生效報告(SVVR)
* 用戶文檔
* 軟件配置管理計劃(SCMP)
* 包括軟件項目管理計劃(SPMP)在內的其他文檔
查看一個軟件過程的普通方法是借助于圖1所示的V形圖。這個圖對應著大部分工程化過程，不過在開發(fā)生命周期中，這個過程是迭代性的，有許多反復的步驟。圖中的軟件過程包括以下幾個組成部分：
* 開發(fā) (需求、設計、編碼和集成)
 |
圖4B：對線控駕駛系統(tǒng)的建模與仿真。 |
* 驗證和生效(V&V)
* 集成 (軟件配置管理、需求可追蹤性和文檔)
基于模型的設計非常注重過程迭代、早期測試和開發(fā)過程中的重用，這使得它既獨特而又功能強大。這一過程的內在實用性體現(xiàn)在V形圖的底部，產(chǎn)品代碼生成是來自設計的一種自動過渡。
在基于模型的設計中，方框圖或狀態(tài)圖模型可以用作系統(tǒng)和軟件需求、軟件設計，或者在稍作假設變換之后，用作源代碼。這個過程的另外一個獨特之處是，它在最終編譯之前要進行廣泛的驗證和生效操作。早期驗證和生效的好處很明顯：它將大大減少在最終系統(tǒng)集成和測試期間發(fā)現(xiàn)的bug數(shù)目，返工次數(shù)也會更少。
<!--StartFragment -->
開發(fā)方法與工具
在軟件工程化過程中，采用了基于模型的設計方法。
 |
圖5：故障模式效應分析用來確保線控駕駛的救生操作。 |
開發(fā)方法包括：1. 行為建模；2. 詳細軟件設計；3. 分布式結構設計；4. 產(chǎn)品代碼生成；5. 嵌入式目標集成。驗證與生效方法包括：1. 仿真與分析；2. 快速原型；3. 模型測試與覆蓋；4. 代碼追蹤與檢查；5. 硬件在環(huán)(HIL，Hardware-In-the-Loop)測試。集成方法包括：1. 源控制接口；2. 需求管理接口；3. 報告生成。
下面給出了對各種開發(fā)方法的簡潔描述，并提供有例子和工具支持信息。注意這里給出的所有工具都是商業(yè)上可以獲得的。其后的部分討論了開發(fā)行為，并包含有關鍵的驗證與生效方法。最后，本文將通過集成組件來進行總結。
1. 行為建模
模型用來為單個子系統(tǒng)(如線控駕駛)的各個方面規(guī)定需求和設計。
一個典型的系統(tǒng)包括：
* 輸入(如方向盤傳感器)
* 控制器或DSP模型
* 設備模型(直流馬達、齒條和小齒輪、車輪)
* 輸出(方向的改變)
在圖2和圖3中，通過使用控制系統(tǒng)方框圖來表示反饋控制、使用狀態(tài)圖來表示離散事件和條件邏輯，以及使用DSP模塊來表示濾波器，可以創(chuàng)建一個系統(tǒng)模型來表示所需的行為特性。
2. 仿真與分析
 |
圖6：圖3中電源管理設計的測試覆蓋。 |
然后，通過使用基于時間或基于事件的仿真以及頻域分析等方法，可以執(zhí)行和分析模型，以確保其滿足需求。例如，一個線控駕駛系統(tǒng)必須對傳感器故障進行響應，并“將高頻響應衰減到3db以下，同時指令傳輸速率不能低于1.5Mbps”。
圖4A和B*中對線控駕駛系統(tǒng)的建模與仿真,可以確定這些需求是相互沖突的還是有效的。仿真是一個核心驗證行為，它確�？梢詫崿F(xiàn)一個系統(tǒng)來滿足這些需求。
3. 快速原型
要在產(chǎn)品的芯片上實現(xiàn)一個可以工作的解決方案，設備模型還不夠精確，處理能力也不滿足要求，因此建模本身并不能提供完整的解決方案。
快速原型對于克服這些缺陷非常有用，因為它用物理設備來代替設備模型。在線控駕駛的例子中，設備有可能是一輛汽車，這時就使用一輛實際的汽車。不過，因為系統(tǒng)并未建立起來，一個實時或嵌入式平臺將負責運行控制器軟件并與設備進行交互作用。
有兩種形式的快速原型：功能性快速原型和目標性快速原型。功能性原型使用一臺功能強大的實時計算機，如多處理器浮點PowerPC或DSP系統(tǒng)，目的在于確定系統(tǒng)對物理汽車的控制是否如對模型汽車的控制一樣好。如果真的是這樣，則設備模型的不精確性就顯得無關緊要，并且控制策略也得到了驗證。
 |
圖7：代碼回放。 |
目標性快速原型在相同或相似的產(chǎn)品MCU或DSP，而不是高端PowerPC內核或其他專用高端快速原型硬件中執(zhí)行軟件。目的是將代碼下載到實際產(chǎn)品目標之中，以便用物理設備進行快速測試。如果執(zhí)行良好，則控制器不僅看似有效，而且可以在產(chǎn)品中加以實現(xiàn)。
軟件設計行為包括定點數(shù)據(jù)規(guī)范、實時任務、數(shù)據(jù)輸入、內建測試和診斷。通過基于模型的設計，用于算法規(guī)范和驗證的同一模型被軟件工程師加以改進和約束，作為產(chǎn)品代碼生成過程的一部分。
4. 模型測試
與將模型部署到硬件上去編譯和集成相比，在桌面計算機上測試模型具有更大的優(yōu)勢。基于源代碼的測試已經(jīng)存在許多年了，但是最近的方法允許進行模型測試和結構覆蓋。使用的場景假定是開發(fā)人員對控制器施加滿負荷壓力，以便用仿真和覆蓋來驗證其設計完備性。另一種測試類型是故障模式效應分析(Failure Mode Effect Analysis)，用來確保故障情況下線控駕駛的救生操作，參見圖5*。
<!--StartFragment -->
設計完備性不佳的例子是數(shù)值溢出和死碼(dead code)。使用最小或最大數(shù)值的模型壓力測試可以確保不發(fā)生溢出情況。使用仿真很容易進行這種測試，但死碼就沒有這么容易檢測出來了，因為檢測需要結構覆蓋。死碼與失效代碼不同，其區(qū)別在于后者是開發(fā)人員已知，并且出于某種原因而使其失效的。實際情況中的死碼意味著在確定規(guī)范期間遺漏了什么。
