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

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

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

如何管理工程系統的復雜性

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

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

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

敏捷開發和基于模型的設計——基礎

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

基于 Scrum 框架的敏捷開發

基于模型的設計是一種以模型為中心的系統開發方法。基于模型的設計在整個開發過程中使用模型作為設計載體，而不是依賴物理原型和文本規范的在團隊內傳遞。模型包含了與系統行為相關的所有組件——包括算法、控制邏輯、物理組件和環境組件。一旦模型被開發(細化)出來，就可以用其來生成代碼(C/C++、HDL或結構化文本)、報告和其他類型的文檔。基于模型設計的核心要素包括系統級和組件級的設計和仿真、自動代碼生成，以及持續測試與驗證。

將敏捷開發的核心價值體系映射至基于模型的設計

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

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

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

客戶合作高于合同談判

響應變化高于遵循計劃

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

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

專注個體和互動

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

注重客戶合作

客戶合作是敏捷方法的核心。每個sprint以計劃會議開始，以評審會議結束，在會議上，客戶經常被邀請提供輸入。建模和仿真不僅支持高效的客戶合作，還支持跨團隊、跨領域和跨學科的合作。采用MathWorks公司基于模型的設計工具，來自硬件設計、系統設計、功能和組件開發的工程師們使用共同的語言/平臺，可以集中精力在一起工作，而不必擔心工具兼容問題。

關注可工作的軟件

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

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

注重響應變化

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

案例——

將敏捷開發與基于模型的設計相結合

開發自適應巡航控制器

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

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

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

帶傳感器融合算法的自適應巡航控制系統的Simulink模型

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

自適應巡航控制模型的仿真結果

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

隨著項目的進行，客戶需求可能會發生變化。例如，客戶可能要求模型使用預測控制，而不是經典的控制算法，因為先進的MPC（模型預測控制）控制器使車輛能夠對場景中其他車輛的激進動作更好地做出反應。由于在這個項目中使用了系統模型，算法團隊可以很容易地用新開發的模型預測控制器替換原來的控制算法，并保持模型的其余部分不變。團隊重新運行仿真并與客戶分享結果，進而就是否繼續進行設計更改還是恢復到原先的控制算法設計做出更好的決定。

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