隨著大型、復雜系統的發展，系統工程方法被用于管理系統的復雜性，并確保交付的系統能滿足所有需求。MBSE是一種通過使用系統模型改善傳統的基于文檔的系統工程的方法。SysML是一種圖形化的建模語言，作為一種國際標準支持MBSE。使用SysML定義的系統工程模型本質上是描述性的，不直接產生分析結果，將導致系統工程活動和工程分析之間存在著巨大的差異。因為系統工程師和工程分析師使用不同的模型、工具、方法和術語，他們不得不依靠特別的通訊和人工翻譯的設計規范和數據。這種差異導致了效率低下并需要花費昂貴代價去修復質量問題。因此，迫切需要將SysML模型與分析模型連接起來。

圖1 系統模型與領域分析模型的差異

目前， SysML建模工具內部的系統級分析通常僅限于對簡單參數方程式的評估。這意味著盡管SysML模型能夠詳細地描述一個給定的系統配置，卻很難恰當地評估設計與需求的契合度或對性能、成本和風險執行重要的權衡分析。因為缺乏便利地可獲取的分析能力，使得系統工程師很難快速地了解需求和系統配置不可避免的變化帶來的后果，并采取必要的行動。

另一方面，域/多學科工程師(結構、熱力、電力、軟件、成本等)通常使用各種先進的分析工具來分析和設計系統。因為這些工具沒有連接到系統模型，很難使用系統模型設置分析問題或使用分析結果更新系統模型。如果可以填補這個空檔，域/多學科工程師可以使用MBSE數據存儲庫獲取所需的設計信息去創建他們的分析模型，并進行分析以支持系統開發。使用此功能，域/多學科工程師可以減少多學科建模和分析活動中由于手工數據轉換和失效信息的使用所導致的常見錯誤和修正工作。

將建模和分析集成的功能彌補了以上缺陷。這種技術方法是將SysML建模工具與過程集成和優化設計框架（Process Integration and Design Optimization，PIDO），如Model Center，進行集成。這種方法的優點是使用PIDO框架提供的通用接口將SysML與各種工程分析工具連接，如CAD / CAE，遺留代碼，數學解算器和電子表格等。此方法具有從系統模型自動生成分析模型，然后執行分析模型的能力。集成的工具套件允許工程師使用現實的分析模型快速評估系統配置并自動檢查需求的一致性。

本方案旨在開發集成的建模和分析功能，它將支持系統工程師和領域/多學科工程師的不同視角。系統工程師主要關注系統架構和系統級的權衡，并不一定對工程分析的細節感興趣。另一方面，領域/多學科工程師負責創建工程分析模型，它可以準確地代表當前設計但不需要理解SysML模型的細節。集成的工具套件使用一種常見的圖形用戶界面，可以從SysML工具(為系統工程師)或者從PIDO框架(領域/多學科工程師)運行，允許工程師用他們熟悉的工具和環境進行工作。它允許設計團隊在整個設計過程中執行連續的設計、分析和權衡研究，并且可以對需求和設計配置的變化做出快速響應。下圖給出了整體方案架構及流程。

圖2 整體MBSE集成方案架構

此方案從需求出發（需求可以來自Excel或者Doors等），將需求導入到Sysml建模工具（如IBM Rational Rhapsody或NO Magic Magic Draw等），使用Rhapsody或Magic Draw創建系統架構，使用領域專業工具建立分析模型，在SysML參數圖中將系統模型與分析模型建立連接，使用Model Center的MBSE Pak建立中間連接層，執行權衡分析等，并將分析后的結果反饋到描述模型以更新模型。

2

集成建模和多學科分析的方案需要基于一些通用的原則。首先，需要具備支持不同抽象級別的模型。SysML提供了許多建模構圖來支持抽象模型，但模型的抽象需要包含多學科分析模型。第二，需要尋求通用系統工程模型和領域特定模型之間適當的平衡，因為他們有各自的優缺點。SysML在定義系統架構和關系時非常有用，也需要結合很多專門特定領域的建模和分析工具。相比通用的SysML模型，領域特定模型可以更有效地準確地描述系統的特定方面。第三，工程分析需要更好的與整體系統開發的上下文關聯。因為當執行一個復雜的系統的分析時，不能很好的把握大局。第四， 在創建模型時需要結合自頂向下和自底向上的方法。SysML模型通常使用自頂向下方法創建，從高度抽象演變到更多細節。但SysML模型可能基于負責創建分析模型的領域/多學科工程師的輸入去做更新。

3

根據圖2給出的整體MBSE集成方案架構，將通過以下六個主要步驟完成整個建模與分析過程。此模型框架建模步驟包括：

1) 生成需求圖及系統架構；

圖3 創建需求和系統架構

a) 最初的需求規格可以是用DOORS/Excel進行描述，將早期的需求規格說明導入到Rhapsody/MagicDraw中，創建需求圖，在需求圖中包含相應指標的上下限以及需求目標。

圖4 建立需求圖

b) 基于需求生成系統架構，定義SysML原型，使用SysML的BDD圖對系統架構進行描述。

本方案中，將SysML進行了擴展來描述建模分析組件，這些組件運行在ModelCenter框架。下圖給出了配置屬性中定義的原型。MC_Component原型用于指定一個約束模塊(例如，分析塊)的可執行的分析模型的位置。MC_Variable 原型來創建SysML端口(例如，參數)和分析模型變量之間的映射。InOut枚舉來指定由MC_Variable原型實例化參數(輸入或輸出)的因果關系。在這個功能中，工程分析被用于自動檢查需求的一致性。為了達到這個目的，RequirementVerification模板可以應用于需求塊。

圖5  定義SysML 原型用于連接SysML模型和工程分析

下面通過一個汽車剎車片設計的示例來描述這種方法。我們的目標是設計一個剎車片，需要滿足幾個性能需求，如剎車距離、生命周期、剎車過程中產生的熱量等。下圖是系統分解的SysML塊定義圖。用SysML中的blocks代表系統的物理實體，每個block都可以有值屬性。圖中箭頭代表整體與部件的關系。例如，brake包含rotor，caliper和pad這些部件。在這個示例中， c++程序和Excel電子表格被用來計算性能和剎車片的成本。

圖6  系統分解(SysML BDD)

2) 將系統架構與需求進行連接，在參數圖中建立屬性與分析模型的連接。

a) 先將系統架構與需求進行連接，建立可追溯性，連接系統性能屬性與需求，在Rhapsody/MagicDraw中建立satisfy關系。

圖7 設置使用Model Center提供的擴展屬性

將需求模塊的Applied Stereotype設置為PropertyBasedRequirement，這些是MBSE Analyzer對SymML 的擴展屬性。

圖8 使用“satisfy”關系關聯系統屬性和需求

本方案的目標之一是利用工程分析來檢查需求規格合規性。該方案使用的方法是，用文本描述需求，然后給每個需求附加上下限。SysML 標簽被用來給需求添加上下限。圖8給出了剎車片生命周期的需求，標有一個LowerBound的標簽。該需求通過satify關系連接到“life”參數。如果“life”參數的值比下限低，則不滿足需求。此方法具備自動檢測需求一致性的功能。如果需求不滿足，則會在圖中自動高亮顯示一個紅色的“X”。

b) 創建SysML參數圖

SysML參數圖用于指定系統屬性之間的定量關系。參數圖使用分析模塊(即約束塊)，表示模型中系統屬性之間的物理或邏輯關系。然而，約束塊的原有功能是有限的代數方程。為了克服這個限制，SysML約束塊被擴展，使它們指向一個黑盒分析模型，這些分析模型可以是腳本、電子表格、CAD / CAE工具，或遺留分析代碼。本方案中，分析模型分布在分析服務器上，它能夠共享工程分析并遠程運行它們。每個分布在分析服務器的黑盒分析模型通過一個URL識別。

下圖展示了剎車片成本分析的約束塊。該成本分析是基于一個使用Analysis Server封裝的Excel電子表格。MC_Component原型的url標記制定了封裝分析的位置。

圖9 使用SysML原型定義一個黑盒分析的URL位置

每個約束塊都帶有參數，如下圖參數分隔區所示。代數方程通常用來定義參數之間的約束。在此案例中，約束塊是用黑盒分析替代方程。每個黑盒分析有一組輸入和輸出參數。除了簡單的分析關系，想要改變黑盒分析參數的因果關系(輸入/輸出)是不容易的。因此，每個參數的因果關系是在相應的黑盒分析中顯式地定義的。如上圖所示，MC_Variable原型是用來定義參數的因果關系以及默認值。

圖10 在SysML參數圖中建立屬性與分析模型的關系

約束模塊是SysML中可重用的分析模塊。參數圖可能使用多種約束塊來定義更加復雜的解析關系。上圖是一個剎車片示例的參數圖。該圖使用了四個約束塊包括基于Excel電子表格的成本分析和剎車片的分析，卡尺， 和基于c++程序的剎車距離。每個約束塊通過MC_Component原型實例化，并使用一個圖標，表明此約束塊隱藏的分析模型的類型。

參數圖中的綁定連接器(Binding connectors)代表系統屬性之間的平等關系。可以在系統屬性和參數之間或者參數之間創建綁定連接器的參數。原則上，平等關系是非因果的，綁定連接器在輸入和輸出參數之間沒有區別。為了解決帶有非因果關系的參數圖，需要處理一個系統方程組。然而，這種方法僅限于簡單方程式的使用，當使用黑盒工程分析時是不適用的。在此案例中，因此，每個約束塊的參數根據參數在黑盒分析中的使用，顯式地定義為一個輸入或輸出。上圖中的約束塊使用約定的布局，將輸入和輸出參數分別置于約束塊的左邊和右邊。

3&4) 建立系統模型與分析模型之間的連接層

圖11 從系統層到專業層

圖10中定義的參數圖包含創建一個分析模型所必要的信息，這些分析模型可以通過PIDO框架執行。在Model Center中約束塊被轉換成分析組件，綁定連接器被轉換成分析組件變量之間的鏈接關系。這種功能可以從參數圖自動創建一個分析模型。該功能是PIDO 框架的一種SysML插件。這種轉換是通過使用SysML工具和Model Center的API，而不依賴形式化的模型轉換。SysML插件允許選擇參數圖，并自動生成一個分析模型。圖12顯示了從參數圖生成的多學科分析模型。一旦創建了一個相關聯的分析模型，插件會自動列出參數圖中（圖13）中使用的系統屬性。用戶可以改變輸入值并運行分析不同的系統配置下的性能和成本指標等。

圖12 使用Model Center MBSEPak建立連接關系

圖13 參數圖中使用到的SysML參數列表

值得注意的是，自動生成的模型是連接到SysML模型的。這種方法允許使用SysML模型作為工程分析設計信息的權威來源。輸入參數值使用SysML模型中定義的值進行初始化。這使得領域專家可以迅速建立分析模型，避免了手工數據轉換潛在的錯誤。這種方法還使得它易于使用的工程分析的結果來更新SysML模型。SysML插件提供了一個能夠使用從分析模型計算得出的新值更新SysML模型。另一個優點是，PIDO工具包含權衡分析工具，可以用來評估許多設計方案。當找到一個最優設計后，可以用于更新SysML模型中的當前設計。

圖14 SysML 插件執行從參數圖自動生成的分析模型

5)執行權衡分析及優化空間探索

圖15 執行權衡分析

對于成本、性能、風險等變量，可以使用Model Center進行權衡分析及優化空間探索以找到最優方案。

圖16 使用DOE工具進行權衡分析

圖17 在model center中執行權衡分析

6）基于分析后的新的設計參數更新系統模型

圖18 更新系統模型

通過權衡分析，優化設計參數之后，基于新的設計參數，MBSE Analysizer可以自動更新Rhapsody/MagicDraw系統模型并驗證新的數據是否滿足性能需求。

圖19 自動更新系統模型

4

工具和技術的發展彌補了系統工程模型和工程分析之間的差異。本方案通過執行一個PIDO框架Model Center，將SysML系統模型與工程分析模型相連接實現的。該技術的關鍵是從SysML參數圖自動生成分析模型。使用了 SysML建模技術將相關參數圖與塊聯系起來。可以為SysML模型中選定的對象快速識別適用的分析，并有選擇地同時處理一個或多個參數圖。集成的工具套件允許工程師使用真實的和準確的分析模型快速評估系統配置。通過在SysML模型以及它們的可追溯性系統屬性中指定工程分析，SysML模型提供了一個完整的系統模型和工程分析之間的關系。

該集成方案還可以使用工程分析模型檢查系統需求。不滿足的要求自動高亮顯示，以便工程師可以采取必要的行動。此功能提供了一個在提交設計變更之前檢測到潛在問題的機會。使用這種集成方案，設計團隊可以迅速應對不可避免的需求或設計配置的變化。加上Model Center工具中包含的權衡分析工具，具備執行連續分析，仿真，以及貫穿整個設計過程的權衡分析的能力。

參考資料：

[1] Kima H., D. Frieda, P. Menegaya, G. Soremekuna, C. Osterb,”Application of integrated modeling and analysis to development of complex systems”, Procedia Computer Science   16  ( 2013 )  98 – 107. Available online at www.sciencedirect.com.

[2] Kima H.,” Integrated Model Framework for Concept Development”, Model Center 2015 User’s Conference MBE April 14, 2015.

[3] Phoneix Intergration,Inc.,Model Center Introduction,

See aslo ” https://www.phoenix-int.com”.