現今大部分開發工程應用軟體的團隊逐漸意識到傳統瀑布型（waterfall）軟體開發方法存在的一些缺陷。其中包含在計畫開發週期較後面的階段才能發現瑕疵與設計問題、無法對設計要求進行變更、可能有做出一個並不符合客戶需求的系統的風險等等。

為了克服這些缺陷，許多團隊已經開始採用結合了敏捷方法（agile methods）與模型化基礎設計（Model-Based Design）的開發途徑。

模型化基礎設計與靈活方法的檢驗結果顯示模型化基礎設計可以補足敏捷方法，並甚至在工程應用啟發了敏捷方法。如同敏捷方法，模型化基礎設計的出發點在於支援快速疊代。它也能夠因應不能僅依賴敏捷方法來處理的系統工程挑戰：

* 如何在不需連結到設備的情況下執行早期測試

* 如何管理工程系統的複雜性

* 如何減輕在昂貴的硬體上測試未經驗證軟體的風險

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

本文將透過一個模型化基礎設計結合了敏捷方法與Scrum架構的主動式定速巡航控制（adaptive cruise control）的範例，說明模型化基礎設計如何支援敏捷開發的核心價值。

=====================================================================

敏捷與模型化基礎設計：基本資訊

敏捷軟體開發方法（Agile software development methods）

建立在2001年發布的敏捷宣言（Agile Manifesto）中所闡述的的核心價值與原則。Scrum為現在最為廣泛使用的敏捷開發架構之一。在Scrum，開發會經過一系列被稱為sprints的循環，團隊成員在這裡面處理專案計畫一段時間限制內（通常是一到兩週，或者一個月）所累積（backlog）下來的功能子集。團隊在每一個sprint進行軟體的開發、測試、整合、建立文件（圖1）。

圖1 : 利用Scrum架構進行敏捷開發。

模型化基礎設計（Model-Based Design）

一個以模型為中心的系統開發方法。相較於傳統仰賴實體原型與文本規格來進行溝通，模型化基礎設計藉由模型來貫穿整個開發流程。模型包含了所有與系統行為相關的元件—演算法、控制邏輯、物理元件、以及環境。當模型開發（加工）完成，它可以用來產生程式碼（C/C++、HDL、或結構化文本）、報告、及其他類型的文件。模型化基礎設計的核心元件為系統層級和元件層級的設計與模擬、自動產生程式碼、持續的測試與驗證。

=====================================================================

將敏捷開發的核心價值映射到模型化基礎設計

敏捷宣言定義了軟體開發的四大核心價值：

* 個人與互動重於流程與工具

* 可用的軟體重於詳盡的文件

* 與客戶合作重於合約協商談判

* 回應變化重於遵循計畫

宣言的編寫人指出「重於」前者並不等同「捨棄」後者。他們所指的是重心的調整：「雖然後者（右方）項目具有其價值，不過我們更加重視前者（左方）項目。」

讓我們來看看如何將敏捷價值映射到模型化基礎設計。

著重於個人與互動

在模型化基礎設計的流程與工具—特別是建模與模擬—促進了個人與團隊之間有效的互動。模型可以直接在Simulink、報告、或網頁共享，讓所有利害關係人能夠將其作為共同的參考點和單一的事實來源使用。模擬結果不但清楚且顯而易見，能夠幫助進行設計決策、Scrum規劃、與利害關係人的討論。

著重於與客戶的合作

與客戶的合作是敏捷方法的中心。每一個sprint都會由一個計畫會議開始，並以檢討會議結束，客戶時常被邀請到這些會議來提供意見。建模與模擬不只支援有效的客戶合作，也增進各團隊、領域範圍、規範紀律之間的合作。硬體設計、系統設計、功能與元件開發工程師有了一種共同的語言，可以專注在合作上，而不用擔心使用工具的差異。

著重於可用的軟體

模型化基礎設計對於使用敏捷方法的團隊最重要的優點之一，就是即使嵌入式目標、受控體、感測器、或其他硬體還沒有準備好，也可以從最初的sprints開發出系統的可行版本。一個經由模擬驗證的Simulink模型，可以在整個專案計畫中做為有效軟體（working software）。模型在開發階段充當一個系統的可執行規格。在早期的sprints，硬體可能尚未準備好，模擬結果可以代替硬體測試結果與客戶分享，並用來評判進度、請求接受、或計劃下一個sprint。模型亦提供清楚且方便的途徑來衡量進度。隨著模型變得更加詳盡，還可以被用來產生執行軟體迴圈（software-in-the-loop, SIL）、處理器迴圈（processor-in-the-loop, PIL）、硬體迴圈（hardware-in-the-loop, HIL）測試，以及即時原型化與生產系統的程式碼。

模型也可做為綜合文件的準則。在模型化基礎設計，文件是設計流程的產出，而不是離散任務，且文件和報告可以依需求從模型產生。

著重於回應變化

瀑布型的開發流程有一塊主要的絆腳石，就是無法充分回應要求與條件的演變。敏捷開發和模型化基礎設計能夠彌補這項缺點，讓團隊可以更有效率地回應變化。針對工程應用之中各種非顯然的變化，使用模型化基礎設計的工程師可以對模型進行變更，接著重新產生程式碼。在任何改變被落實之前，團隊可以執行假設分析（what-if analysis）來決定每個特定變化要求的最佳回應方法。在模型中進行變更之後，工程師可以執行模擬來進行迴歸測試，以確保所做的變更不會造成系統出現非計畫中的行為。當模型連結到設計要求，團隊可以執行影響分析，以了解對部分模型做的變更將對其他部分造成什麼樣的影響。

【使用案例】

結合敏捷方法與模型化基礎設計來開發主動式定速巡航控制器

這裡提供一個車輛工程團隊利用感測器融合開發主動式定速巡航控制系統的軟體的範例。該系統融合來自車載雷達與視覺感測器的資料，來辨別最重要的物件以及其與車輛本身的距離，以調整車速及維持安全距離。

在這項專案，有一組工程師負責開發控制演算法，而另一組開發駕駛情境與合成感測器資料。這些合成資料可以在工程師有辦法取得真實感測器資料之前，幫助他們開發與測試演算法。使用合成資料的早期模擬可以提供設計決策的資訊，像是類型、數量、以及車內感測器的定位。

在第一個sprint，每一個小團隊（或一組工程師）建立其各自的子系統，利用共享的系統層級Simulink模型來協調他們的工作（圖2）。即使是在這個早期階段，他們可以執行模擬觀察控制器在各種條件下的行為。他們為控制器除錯、辨識要進行優化的參數、從可用版本的系統將主要績效指標視覺化—這所有的工作都在開始撰寫或產生程式碼之前完成。

圖2 : 附有感測器融合之主動式定速巡航控制系統的Simulink模型。

在第一個sprint結束、與客戶一同進行的檢討會議中，團隊分享了模型以及模擬結果（圖3）。該模型與結果提供一個可用軟體的具體呈現—舉例來說，透過圖表說明車輛在另外一輛車移動到自己所在車道時該如何進行減速。

圖3 : 主動式定速巡航控制模型的模擬結果。

在接下來的sprint，團隊依客戶的回饋精鍊並改善模型—比如透過調整安全車距或改變車輛在加減速時的速率—並為了程式碼的產生與佈署配置到ECU來對模型進行優化。產生的程式碼可以直接拿來使用，或者做為更大系統的一部分與既有程式碼整合。Jenkins的連續累計（continuous integration, CI）被使用來不間斷地檢查自動產生和手動撰寫程式碼的整合情況、在模型上直行測試、檢查是否遵照建模標準，接下來再以產生的程式碼執行測試。從這些活動所產生的結果會自動地回報，讓沒有使用開發工具的利害關係人也能夠追蹤進度。

在後面的sprints，團隊整合了更嚴格的驗證與有效性檢測活動，包含SIL、PIL、或HIL測試，以確保設計符合要求。他們也檢查模型與程式碼是否確實遵照所建立的標準和方針，使用靜態分析和正式的方法來證明不會出現重大執行階段錯誤，並且產生在準備標準認證時所需要的報告及其他物件。

隨著專案計畫的進行，客戶需求有可能會變動。舉例來說，客戶可能要求模型預測控制，而不是一般的控制演算法，因為進階的MPC控制器讓車輛可以對環境中其他車輛更具侵略性的操縱做出反應。由於在專案計畫中使用了系統模型，演算法團隊可以很容易地以新開發的模型預測控制器替換原本的控制演算法，不用去改變模型的其他部分。團隊接下來再重新執行模擬，並將結果分享給客戶，依據模擬結果，可以決定是否繼續進行設計變更或回復先前的途徑。

這個團隊在他們的敏捷開發工作流程中使用了模型化基礎設計，並且在硬體階段之前即產出運作良好的軟體。建模與模擬讓該團隊可以持續地依據客戶反映來改善設計，即使是在專案計畫的後期的重大要求變更也能夠調適。

（本文由鈦思科技提供，作者Roger Aarenstrup、Gaurav Tomar任職於MathWorks公司）