如今，大多數(shù)為工程應(yīng)用開發(fā)軟件的團隊都意識到了傳統(tǒng)開發(fā)方法（瀑布式）的缺點。這包括在項目后期發(fā)現(xiàn)缺陷和設(shè)計問題，無法適應(yīng)需求的更改，以及交付的系統(tǒng)不滿足客戶需求的風險。為了克服這些缺點，許多團隊采用了將敏捷方法與基于模型的設(shè)計相結(jié)合的開發(fā)流程。

有關(guān)基于模型的設(shè)計和敏捷方法的研究表明，對工程應(yīng)用而言，基于模型的設(shè)計不僅是敏捷開發(fā)的有效補充，甚至有時使敏捷開發(fā)成為可能。像敏捷開發(fā)一樣，基于模型的設(shè)計最初是為了支持快速迭代，其還滿足了系統(tǒng)工程方面的挑戰(zhàn)，而這些挑戰(zhàn)不是敏捷開發(fā)單獨能夠解決的：

如何在不使用設(shè)備的情況下進行早期測試

如何管理工程系統(tǒng)的復(fù)雜性

如何降低在昂貴的硬件上測試未經(jīng)驗證的軟件的風險

如何滿足功能安全及其他標準的要求，包括 DO-178B/C 和 ISO 26262

本文通過一個自適應(yīng)巡航控制示例，解釋基于模型的設(shè)計是如何支持敏捷開發(fā)的核心價值體系。該示例結(jié)合了基于模型的設(shè)計、敏捷方法和 Scrum 框架。

敏捷開發(fā)和基于模型的設(shè)計——基礎(chǔ)

軟件敏捷開發(fā)方法建立在2001年出版的《敏捷宣言》中概述的核心價值體系和原則之上。如今，敏捷開發(fā)最廣泛使用的框架之一是Scrum。在Scrum中，開發(fā)以稱為sprint的一系列周期進行，在每個周期中，開發(fā)團隊在項目待辦事項列表中的一個子集上工作一段時間(通常是一到兩個星期或者一個月)。在每個sprint中，開發(fā)團隊對軟件進行開發(fā)、測試、集成，最后對可工作的軟件設(shè)計文檔(圖1)。

基于 Scrum 框架的敏捷開發(fā)

基于模型的設(shè)計是一種以模型為中心的系統(tǒng)開發(fā)方法?；谀Ｐ偷脑O(shè)計在整個開發(fā)過程中使用模型作為設(shè)計載體，而不是依賴物理原型和文本規(guī)范的在團隊內(nèi)傳遞。模型包含了與系統(tǒng)行為相關(guān)的所有組件——包括算法、控制邏輯、物理組件和環(huán)境組件。一旦模型被開發(fā)(細化)出來，就可以用其來生成代碼(C/C++、HDL或結(jié)構(gòu)化文本)、報告和其他類型的文檔?；谀Ｐ驮O(shè)計的核心要素包括系統(tǒng)級和組件級的設(shè)計和仿真、自動代碼生成，以及持續(xù)測試與驗證。

將敏捷開發(fā)的核心價值體系映射至基于模型的設(shè)計

敏捷宣言定義了軟件開發(fā)的四個核心價值觀：

個體和互動高于流程和工具

工作的軟件高于詳盡的文檔

客戶合作高于合同談判

響應(yīng)變化高于遵循計劃

宣言作者指出，“高于”并不意味著“否定”。他們所倡議的是開發(fā)要素要有所側(cè)重：“雖然右邊的開發(fā)要素也有價值，但我們更注重左邊的要素?！?/p>

讓我們看看這些敏捷方法的價值觀如何映射到基于模型的設(shè)計：

專注個體和互動

基于模型設(shè)計的流程和工具——特別是建模和仿真——能夠促進個人和團隊之間進行高效的交互。模型可以直接通過Simulink，報告或web頁面進行共享, 使所有相關(guān)人員能夠使用模型作為一個共同的工作參考點，避免產(chǎn)生分歧。仿真結(jié)果清晰可見，有助于設(shè)計決策、Scrum規(guī)劃以及促進相關(guān)人員的討論。

注重客戶合作

客戶合作是敏捷方法的核心。每個sprint以計劃會議開始，以評審會議結(jié)束，在會議上，客戶經(jīng)常被邀請?zhí)峁┹斎?。建模和仿真不僅支持高效的客戶合作，還支持跨團隊、跨領(lǐng)域和跨學(xué)科的合作。采用MathWorks公司基于模型的設(shè)計工具，來自硬件設(shè)計、系統(tǒng)設(shè)計、功能和組件開發(fā)的工程師們使用共同的語言/平臺，可以集中精力在一起工作，而不必擔心工具兼容問題。

關(guān)注可工作的軟件

對于采用敏捷開發(fā)的團隊來說，基于模型設(shè)計的主要優(yōu)勢之一是，即使沒有嵌入式目標硬件、被控對象實物、傳感器或其他硬件，也能夠在最初的sprint中開發(fā)出一個可工作的系統(tǒng)。通過仿真驗證后的Simulink模型可以作為可工作的軟件服務(wù)于整個項目的開發(fā)。模型作為系統(tǒng)開發(fā)過程中的可執(zhí)行規(guī)范，在早期的sprint中，當硬件還不存在時，作為硬件測試結(jié)果的替代，也可以與客戶共享模型的仿真結(jié)果，以用于評估項目進度、尋求支持或計劃下一次sprint。模型還提供了一種清晰而便捷的方法來評估項目進度。隨著模型的細化，可以用其生成代碼，用于軟件在環(huán)(SIL)、處理器在環(huán)(PIL)和硬件在環(huán)(HIL)測試，以及用于實時原型和生產(chǎn)系統(tǒng)。

模型還可以作為文檔的載體。在基于模型的設(shè)計中，文檔是模型設(shè)計過程的輸出，而不是一個單獨的任務(wù)，文檔和報告可以根據(jù)需要從模型直接生成。

注重響應(yīng)變化

瀑布開發(fā)的一個主要障礙是不能對不斷演化的需求和條件做出足夠的反應(yīng)。敏捷開發(fā)和基于模型的設(shè)計解決了這一缺陷，使團隊能夠更有效地應(yīng)對變化。對于工程應(yīng)用軟件中的任何重大更改，使用基于模型設(shè)計的工程師可以修改模型，然后簡單地重新生成代碼。在實現(xiàn)任何更改之前，開發(fā)團隊可以執(zhí)行假設(shè)分析來確定適應(yīng)特定更改請求的最佳方法。對模型進行更改后，工程師可以進行回歸測試，以確保更改不會為系統(tǒng)引入意外行為。當模型與需求相鏈接后，開發(fā)團隊還可以進行影響分析，以了解對模型其中一個部分的更改將如何影響其他部分。

案例——

將敏捷開發(fā)與基于模型的設(shè)計相結(jié)合

開發(fā)自適應(yīng)巡航控制器

在這個例子中，某汽車工程團隊正在開發(fā)一套具有傳感器融合算法的自適應(yīng)巡航控制系統(tǒng)軟件。該系統(tǒng)融合了車載雷達和視覺傳感器的輸入數(shù)據(jù)，識別出最重要的目標及其與當前車輛的距離，以調(diào)整車速并保持安全距離。

項目中，其中一組工程師負責開發(fā)控制算法，另一組工程師負責開發(fā)駕駛場景和傳感器數(shù)據(jù)綜合算法。這些合成數(shù)據(jù)將使工程師能夠在獲得實際的傳感器數(shù)據(jù)之前開發(fā)和測試算法。在開發(fā)的早期階段，使用合成數(shù)據(jù)進行仿真可以為設(shè)計決策提供信息，例如車內(nèi)傳感器的類型、數(shù)量和位置。

在第一個sprint中，每個子團隊(或工程團隊)都對各自負責的子系統(tǒng)進行建模，使用共享的系統(tǒng)級的Simulink模型來協(xié)調(diào)各自的工作(圖2)。甚至在這個初期階段，工程師們可以運行仿真以觀察在不同工況下控制器的行為。在編寫或生成代碼之前，工程師們可以調(diào)試控制器，識別出要優(yōu)化的參數(shù)，并利用可工作的系統(tǒng)模型來可視化關(guān)鍵性能指標。

帶傳感器融合算法的自適應(yīng)巡航控制系統(tǒng)的Simulink模型

在隨后的sprint中，開發(fā)團隊基于客戶反饋對模型進行改進或增強——例如，通過調(diào)整安全跟蹤距離或改變車輛加速或減速的速率——對這些參數(shù)進行優(yōu)化，并生成代碼，部署到ECU上。生成的代碼可以按照原樣使用，也可以作為較大系統(tǒng)的一部分與已有代碼集成。Jenkins提供的持續(xù)集成(CI)功能可以用來不斷檢查生成代碼與手工代碼的集成活動, 比如運行模型測試，檢查建模規(guī)范的符合性，對生成的代碼進行測試等。所有這些活動的結(jié)果都會被自動報告，以跟蹤進度，并且提供給不使用開發(fā)工具的相關(guān)人員。

自適應(yīng)巡航控制模型的仿真結(jié)果

在之后的sprint中，開發(fā)團隊加入了更嚴格的驗證和確認活動，包括SIL、PIL或HIL測試，以確保設(shè)計滿足需求。此外，開發(fā)人員還檢查模型和代碼是否符合已建立的標準和指南，使用靜態(tài)分析和形式化方法來證明軟件不存在嚴重的運行時錯誤，并為標準的認證生成認證報告及其他所需文件。

隨著項目的進行，客戶需求可能會發(fā)生變化。例如，客戶可能要求模型使用預(yù)測控制，而不是經(jīng)典的控制算法，因為先進的MPC（模型預(yù)測控制）控制器使車輛能夠?qū)鼍爸衅渌囕v的激進動作更好地做出反應(yīng)。由于在這個項目中使用了系統(tǒng)模型，算法團隊可以很容易地用新開發(fā)的模型預(yù)測控制器替換原來的控制算法，并保持模型的其余部分不變。團隊重新運行仿真并與客戶分享結(jié)果，進而就是否繼續(xù)進行設(shè)計更改還是恢復(fù)到原先的控制算法設(shè)計做出更好的決定。

該團隊在其敏捷開發(fā)工作流中使用了基于模型的設(shè)計，并且在涉及到具體硬件之前就交付了可以工作的軟件。建模和仿真使得團隊能夠根據(jù)客戶反饋不斷改進設(shè)計，甚至在項目后期適應(yīng)重大的需求更改。