基于模型的系統工程（MBSE）是一種對系統建模經濟高效的應用，它通過在系統開發早期進行測試和驗證，提升對系統屬性和行為的了解，并實現需求和設計決策的快速反饋，從而探索和記錄系統特性。模型提供了一種高效的，可以探索、更新和傳達系統各個方面信息的方式，還能減少對傳統文檔的依賴。

MBSE歷來注重表達和記錄需求、設計、分析和驗證信息[1]，隨著建模技術的成熟，它通過加速學習（例如仿真）和更好地了解物理世界（例如數字孿生）從而提供更多價值[2]，這兩者對于持續完善系統和實現企業解決方案都非常重要。

盡管模型并不能完美地展示系統，但它能比直接實施系統建設更早、更經濟地提供知識和反饋。模型還能基本準確地模擬出復雜系統和系統間的互動來加速學習。在實踐中，工程師使用模型獲取知識，并作為系統實施的指南。在某些情況下，他們會在實際執行過程中直接使用模型（例如電氣CAD、機械CAD）。

01

細節

精益實踐支持通過持續的開發工作流程快速學習，以獲得對決策的快速反饋。MBSE是一門學科同時也是精益工具，在使用過程中能夠讓工程師快速了解正在開發的系統而不會使成本變得過高。

模型用于探索系統元素的結構、行為和操作特性，評估備選設計方案，并在系統生命周期中更早、更快速地驗證假設。這對于大型、復雜的系統來說特別重要（如衛星、飛機、醫療系統等），在這些系統中，解決方案必須提前進行可行性驗證，如火箭發射升空或治療首個病人。模型還記錄和傳達對其他人有用的決策。這些信息可用作合規性文件、影響分析文件以及滿足其他需求的文檔。在SAFe（ScaledAgile Framework：大規模敏捷框架）中，模型信息被視為解決方案意圖的一部分，通常由Enablers創建。

下面的章節提供了MBSE的使用指導。

圖 1 MBSE加速學習

02

探索替代方案并加快學習速度 

建模可以支持快速學習周期（參見SAFe原則＃4- 快速穩步建立集成學習周期）并幫助產品在生命周期的早期降低風險。通過測試和驗證特定的系統特性、屬性或行為，模型促進早期學習，從而在能夠在實際決策時快速獲取反饋。

模型有多種型態，如動態、實體、圖形、方程、模擬和原型等。如圖2所示，每種形式提供了一個或多個不同視角的系統特征，并能夠創建新的功能和特性。

圖 2. 模型和學習周期

模型可以預測性能（響應時間、可靠性）或者物理屬性（熱量、輻射、強度），也可以根據用戶體驗或外部刺激設計備選方案。當然，在探索設計備選方案時，除了使用模型之外，也可以采用設計思維和以用戶為中心的設計思想與MBSE協同作用來更快地驗證假設。

03

模型連接現實與虛擬世界 

數字孿生技術支持MBSE。數字孿生是物理系統的虛擬實例，與性能、功能、維護、NFRs（Nonfunctional Requirements：非功能需求）和系統運行狀況等操作數據同步。通過結合物理和虛擬世界的數據可以驗證虛擬的模型，并協助工程師改進系統分析，預測故障或停機時間，提供更準確的維護計劃。

數字孿生通過更準確地預測未來增強和升級產品的時機，從而支持業務的敏捷性，并提供更精確的解決方案。此外，由于其學習速度快、成本低廉且可靠性高，在發現新商機方面也具有潛力。關于數字孿生的概述，請參見[3]。

04

支持合規性和影響分析

在過去，系統開發中的需求、設計、測試和接口分配等決策通常需要在不同來源中維護，如文件、電子表格和特定領域使用的設計工具。這使得系統文檔難以維護和理解。而MBSE采用整體系統方法來管理系統信息和數據關系，將所有信息視為模型。圖3展示了一種鏈接多類模型信息的通用結構。

圖 3. 鏈接跨域模型

可追蹤性有助于快速準確地了解需求調整對系統的影響，或在域層次的變動對系統其他部分和需求的影響。例如，在Epic審查流程中，敏捷團隊和系統架構師可以利用模型信息進行審查。此外，可追蹤性還提供客觀證據來處理許多法規和合同遵從性問題，并將數字孿生集成到數字化線程中，從而實現跨系統生命周期內的連接。

精益、不斷變化的環境增加了對相關模型的需求。在階段式的項目中，用手動的方式還能夠管理覆蓋范圍和合規性方面的相關信息，但在鼓勵不斷變化的敏捷環境中，手動解決方式將難以應對。

05

生成文檔

許多產品領域需要應對監管的合規性文檔（例如，FAA、FDA）或合同義務文檔（例如，政府合同中的CDRL）。通過MBSE系統開發方法，模型將包含大部分合規性文檔所需要的信息，并可用于生成必要的客觀證據。模型作為唯一事實來源，可以確保各個文檔之間的一致性。此外，模型可以根據不同利益相關者創建相應的文檔，這些利益相關者可能具有各自的系統視角，或者只能查看子視角信息（例如，供應商）。

盡管所有產品和程序都可能需要正式文件，但建議系統工程師直接向客戶/監管機構提供模型，以節省成本。因為工程模型中包含大多數甚至全部信息，足夠用于檢查和正式審查。

06

構建模型質量

在編輯人員眾多、提供信息種類多樣的情況下，模型可能會面臨一個問題：缺乏適當監管時，多人不斷調整導致模型質量下降。因此，系統架構師和團隊應該合作定義質量實踐（包括模型標準和測試），并確保所有人都能遵守。

以下討論的質量實踐有助于早期學習周期。正如SAFe所指出，“你無法擴展糟糕的代碼”，對于系統模型也是如此。通過采用質量實踐和強大的版本管理，工程師可以自信地頻繁調整模型，并積極參與到實現系統目標的進程中。

07

模型標準

模型標準有助于控制質量并指導團隊如何進行最佳建模，包括：

需要捕獲的信息（包括合規性所需的信息）

要使用或排除的建模符號（例如SysML）和部分建模符號（例如用例）

解決方案和子系統模型元素的放置位置

應與不同類型的模型元素一起存儲的元信息

模型內部或與其他跨學科模型之間的鏈接

系統中使用的常見類型和維度 

建模工具的屬性和配置

協作實踐和正確使用不同版本的控制系統

如果需要從模型中生成文檔，應盡早定義文檔模板，因為它會影響進程中的很多決策。系統設計人員需要知道在哪里存儲模型元素，以及可用于查詢、文檔生成或合規性的所有元數據或鏈接。最好的做法是盡早創建頂層的、全系統的框架模型，以驗證這些使用方案。然后，隨著系統的發展，團隊再填充模型。

08

創建可測試和可執行的模型

在敏捷軟件開發過程中，測試優先的方式可以幫助團隊盡早將質量控制融入產品中，不斷促進軟件迭代。測試優先創建了一套豐富的案例，使開發人員能可靠地進行調整，而不會在系統中的其他位置導致錯誤。豐富的自動化測試對于構建持續交付流程至關重要。

精益實踐鼓勵可測試和可執行的模型（如果可行），以減少與下游錯誤相關的浪費。模型應根據領域或學科所存在的評估標準進行測試： 

用于檢測物理和環境問題的機械模型

用于邏輯測試的電氣模型

用于邊界條件和異常情況測試的軟件模型

用于測試系統行為的可執行系統模型

大多數工具提供檢查模型或創建腳本的功能來跨模型迭代并識別異常。

需求測試模型

幾乎所有系統都采用文本式的需求，而且目前通常需要手動審核。敏捷方法中的行為驅動開發（BDD）定義了功能和故事的自動驗收測試。這些測試會一直存在，并在解決方案出現時持續進行驗證。雖然BDD對于測試敏捷積壓項很有幫助，但其在大規模應用方面還具有一定局限性。不過，還是建議在可能的情況下實現自動驗收測試，并確保測試結果與需求一致。

分析和設計測試模型

設計模型可以使用具有靜態分析器或“檢查器”的工具進行測試，這些工具可以識別偏離標準、常規或預期的內容。團隊可以添加自己的規則——模型組織、建模約定和標準、所需的元信息等。如果沒有這類工具，可以采用腳本循環檢查模型以查找靜態模型中的問題。模型也可以動態測試，工程學科的模型會有自己的解決方案來評估質量，也應作為測試實踐的一部分加以利用。

可追蹤性測試

為確保正確的查詢、文檔生成和合規性，模型必須符合鏈接結構的要求。

文檔生成

盡管文檔生成可能與上述的檢查腳本有重疊之處，但文檔生成的腳本主要用于確保模型結構適當，并且所有數據都存在，以支持所有文檔模板的生成。對于大多數模型而言，調試腳本通常比調試或更新文檔模板更容易一些。

文章來源：創景科技