MBSE工具的案例
系統工程大講堂——實施MBSE，如何選擇建模工具？MBSE建模平臺的選擇和使用
目前市場上MBSE或SysML建模工具眾多（圖4），下面的討論主要涉及項目中使用頻率頭三名、特別是頭兩名的工具。
圖4 MBSE-SysML建模工具在國外項目中的使用頻度[5]
2
MBSE建模工具選擇過程
http://mbse.tools/網站給出了MBSE建模工具選型過程的一般步驟[6]：
1) 確定目標和需求；
2) 定義工具選型評價準則；
3) 為評價指標分配相對權重；
4) 識別候選建模工具；
5) 評測候選建模工具；
6) MBSE建模工具選型決策。
并給出MBSE建模工具常用的評價指標[7]：
1) 易用性Usability
2) 模型繪制功能Functional features: Drawing
3) 模型仿真和執行功能Functional features: Simulation & Execution
4) 符合標準及互操作性Standards Compliance & Interoperability
5) 技術支持和團隊建模協作Technical & Team Modeling Support
6) 綜合考慮軟件功能、質量和價格得出的建模工具價值Value
一些歐美SysML/UML建模專家給出了建模工具評價指標的權重分布（表1）。
展開 MBSE開源軟件學習——Capella使用體會兼談SE工具
但是，毫無疑問的是，在進行設計流程中各元素跨多個層級的追溯與管理的時候，采用一款得心應手的工具無疑會事半功倍。
本文想談到的就是目前作者在用的Capella兼談對SE工具的一些看法。
1. Capella簡介
Capella是目前在工業界（特別是歐洲航空航天界）廣泛應用的一種開源MBSE工具。其最早由Thales于2007年開始開發，并于2015年轉交由PolarSys（Eclipse的一個工作組）組織繼續維護。其目的在于提供一種針對高安全性要求的復雜系統進行開發建模的圖形化環境。
目前，Capella的主要用戶包括Thales，Ariane Group， DassaultAviation，Rolls-Royce，SIEMENS等歐洲工業巨頭。總的來說，由于有Thales這種業內巨頭牽頭使用，Capella在歐洲工業界，特別是航空航天業內的使用是相當廣泛的。同時，由于系統工程軟件目前還處于一個群雄割據的階段，并沒有像CAD領域一樣天下鼎定，所以，Capella后續成為一種主流也是很有可能的。
（順便說一句，基于Eclipse開發的MBSE工具還遠不止于一個Capella，還包括ObeoDesigner等。其它非Eclipse開發的就更多了IBM的Rhapsody，Ansys的SCADE Architect等等。在我看來，現在根本談“主流的系統工程軟件”為時尚早，這個市場基本上還處于春秋混戰階段。至于誰能脫穎而出，這取決于誰能構造最完善的生態環境，這一點后面細說。）
2. Capella的優勢
說實話，我是不喜歡談一個工具是好工具或者差工具的，是不是好工具實際上取決于握著它的那之手。
展開 MBSE架構設計分析方法和工具：使用ARCADIA方法和Capella工具的MBSE
然后，需要一個軟件工具來創建和管理ARCADIA模型。第一個實驗是使用現有的UML工具完成的，比如Rational Software Modeler、Objecteering和Rhapsody，并在它們上面定義UML文件。在這些第一次嘗試時，商業工具根本不容易定制，特別是很難刪除未使用的命令或菜單。因此，Thales決定創建自己的工具，專門用于ARCADIA。ARCADIA定義實際上可以看作是Capella建模工具的規范。
如果我們試圖與另一種可能的解決方案進行比較，即使用標準建模語言（如SysML）和現有的商業工具（如Rhapsody），我們可以發現幾個重要的區別。SysML和Rhapsody（作為其他的商業SysML工具）是基于UML的，這對于那些沒有接觸到面向對象概念的系統工程師來說是一個缺點，這些面向對象的起源顯然是不熟悉軟件開發世界的系統工程師采用的障礙。
另一個大問題是，SysML只是一種語言，每個公司都需要制定一個適應的建模策略。但是，如何將該方法傳授給建模工具呢？每一個商業工具都聲稱它提供了一個API來構建特定的附加組件，但這顯然代表了大量的工作。IBM提供了一個帶有Harmony for SE工具包的原型，但在泰雷茲的實驗證明，這個工具包僅僅是一個概念證明，很難在實際項目中使用。例如，建模階段之間的自動轉換并不像Capella那樣是迭代和增量的，而僅僅是一次。
圖20 MBSE三大支柱的實現比較
結論：
基于ARCADIA方法的Capella工具自2008年開發后，目前已廣泛應用于全球多個領域的項目（國防、航空航天、航天、交通、身份和安全等）。
展開 MBSE咨詢服務與工具——MBSE在汽車行業的應用
將基于模型的系統工程（Model Based System Engineering, MBSE）方法應用于整車開發過程中，可解決傳統整車研發過程中的工程數據一致性、可驗證性、可追溯性的問題，降低整車產品開發難度、盡早發現和避免潛在風險，進而提升開發效率和降低開發成本以及后期維護成本。
MBSE在功能開發和驗證中的應用
咨詢服務
MBSE流程咨詢與實施:車載嵌入式軟件流程、需求管理、需求采集、需求分析、功能設計、架構設計、需求形式化驗證、功能驗證、架構驗證、需求發布和復用過程和工具咨詢及實施
MBSE相關培訓:用例分析、基于模型的需求分析、SysML/UML建模語言、基于Rhapsody的系統工程仿真等方法培訓
MBD流程咨詢及服務:嵌入式高性能多核異構平臺的前沿智能算法快速驗證咨詢,基于模型的嵌入式軟件國產化平臺快速驗證定制服務
相關工具
展開 
Maple—多領域系統級建模仿真和科學計算軟件
面向特定任務和基于Excel的視圖，僅向每個用戶顯示他們需要查看的內容；MapleMBSE 在熟悉MBSE 方法的系統工程師與不熟悉MBSE方法的參與者之間建立一個橋梁，使MBSE 的方法應用于相關部門和人員，并貫穿于系統開發過程中
? 容易使用的基于Excel界面的系統工程工具，減少使用MBSE工具常犯的錯誤：MapleMBSE提供了一個直觀的、基于Excel界面的使用環境，可輕松輸入系統定義，即使用戶不是一個MBSE工具專家
? 主要的系統工程工具不具有的強大的電子表格功能：靈活的剪切和粘貼操作、數據驗證和重復驗證、基于Excel表的公式功能、可編輯幾乎所有的系統模型，而不僅僅是依賴項、使用雙向查詢路徑表達式 (QPE) 語言靈活地查詢模型元素、只需添加新行或列即可創建新的模型元素
? 減少錯誤和成本：簡化信息輸入，降低出錯風險，MapleMBSE允許您使用自然的語言和數字輸入，從而減少與MBSE工具復雜輸入機制相關的錯誤
? 提供模型視圖和數據集成的快速定制：由于每個系統工程項目各不相同，MapleMBSE允許面向不同用戶定制模型任務視圖
MapleMBSE促進整個企業應用MBSE
展開 MBSE開源軟件Capella 到 SysML 橋梁：一種用于 MBSE 互操作性的工具化方法
Capella to SysML Bridge: A Tooled-up Methodology for MBSE Interoperability，Nesrine BADACHE, ARTAL Technologies, nesrine.badache@artal.fr，Pascal ROQUES, PRFC, pascal.roques@prfc.fr
模型到模型的轉換是基于模型的系統工程 (MBSE) 中的一項關鍵任務。事實上，越來越需要遷移現有模型，例如在 UML 或 SysML 中，以適應新的建模方法，例如 Arcadia/Capella。反過來也是可取的，因為組織長期以來一直在這些標準之上的模型和工具上投入時間和金錢。在許多情況下，新工具的順利集成需要符合就地標準。
Capella 是一種基于模型的工程解決方案，已成功部署在各種工業環境中。它基于圖形建模工作臺，為系統架構師提供豐富的方法論指導，依賴于 Arcadia，這是一種基于模型的綜合工程方法。
SysML在系統生命周期的不同階段支持系統工程應用的復雜建模。 SysML 為架構師和系統工程師提供了一種使用獨特的通用語言進行協作的簡便方法。它支持在具有許多建模功能的不同開發團隊中管理日益復雜的系統：需求、行為和結構定義。
為了利用 Capella 工具的強大功能，以及與標準化 SysML 語言的一致性，本文描述了 Capella 到 SysML 映射的首次嘗試以及作為概念驗證的轉換工具原型。
動機
模型到模型的轉換是基于模型的系統工程（MBSE）中的一項關鍵任務。事實上，越來越需要遷移現有模型，例如UML或SysML，以適應新的建模方法，如Arcadia/Capella。反過來也是可取的，因為組織長期以來一直在這些標準之上的模型和工具上投入時間和金錢。
展開 MBSE的能與不能???
由于某些項目的復雜性，MBSE確實非常出色，因為很難想象在沒有MBSE類型工具的情況下能夠管理復雜性。用戶、開發人員以及其它利益相關方等可以通過MBSE更好地了解系統、內部系統之間的交互（接口）以及系統外部的系統。同樣在復雜的系統中，有許多需求具有依賴性——既有消極的，也有積極的——其中一個需求的改變需要另一個需求改變。對于復雜的系統，MBSE幫助您開發一組完整、正確和一致的需求。
同樣對于復雜的系統，如果您已經對系統和相應的需求進行了建模，那么該工具是能夠管理更改的先決條件。改變發生了。MBSE工具使您能夠更好地訪問更改對其余需求和系統的影響。如果有人更改了性能需求，該更改如何影響需求集和最終設計？對于復雜系統，MBSE工具確實是準確評估這些類型影響的唯一方法。對于具有較小需求集的簡單系統，這不是一個大問題。
圖出處：參考文獻3
“一次性”使用是這個問題的焦點。一次性指的是在項目期間和產品交付后使用該工具。誠然，傳統的項目具有明確的起點和終點。那就是項目可能是開發和交付產品。然而，在一些項目中，一旦產品交付，團隊將不再參與產品。在這種情況下，與MBSE方法相關的成本、投入精力等可能體現不出太多好處，特別是對于小型和簡單的項目。當然，對大型項目和復雜項目而言，很少有團隊能夠成為甩手掌柜，不再參與產品以及后續的相關工作。
從項目投資的考量
采用MBSE需
要大量的前期投資，特別是如果以前沒有考慮過的話。
這還包括確定一個有效的投資策略，準確的成本估計和量化其投資回報。
并不是所有的公司都有所需的預算和時間。也有可能是
為運行項目引入了額外的MBSE成本。
選擇錯誤的策略可能會抵消掉使用MBSE帶來的好處。
從使用MBSE的目的和范圍考量
采用MBSE的關鍵基礎之一是明確的目的和范圍（原因和什么）。
展開 Rhapsody — MBSE 開發工具
產品介紹
-產品家族功能介紹
??Rhapsody Architect for Systems Engineer: 是一個面向復雜系統工程項目的基于模型的系統工程 (MBSE) 環境
??Rhapsody Architect for Software: 一個集成嵌入式軟件開發環境，使用基于UML的建模功能來設計和開發嵌入式軟件并使其可視化
??Rhapsody Model Manager: 整個工程團隊協作、共享、審查和管理設計與模型環境
??Rhapsody Designer for Systems Engineers: 將模擬和模型執行添加至MBSE環境，幫助啟用對需求、架構和行為的早期驗證功能
??Rhapsody Developer: 通過模擬、行為代碼生成和實時系統集成，開發和驗證嵌入式軟件應用程序環境
-產品組成
?? 支持從 DOORS 工具導入、管理并追蹤需求。分析需求并追蹤至設計、實現以及測試工件，有助于提交適合的產品并及時對需求變更做出響應
?? 需求影響分析，覆蓋度分析
?? 提供Synergy、RTC、CC等配置管理工具集成接口，支持并行開發與協作。
展開 Rhapsody — MBSE 開發工具
產品介紹
1.產品家族功能介紹
? Rational Rhapsody Architect for Systems Engineers: 是一個面向復雜系統工程項目的基于模型的系統工程 (MBSE) 環境
? Rational Rhapsody Architect for Software: 一個集成嵌入式軟件開發環境，使用基于UML的建模功能來設計和開發嵌入式軟件并使其可視化
? Rational Rhapsody Design Manager: 整個工程團隊協作、共享、審查和管理設計與模型環境
? Rational Rhapsody Designer for Systems Engineers: 將模擬和模型執行添加至MBSE環境，幫助啟用對需求、架構和行為的早期驗證功能
? Rational Rhapsody Developer: 通過模擬、行為代碼生成和實時系統集成，開發和驗證嵌入式軟件應用程序環境
2.產品組成
? 支持從 DOORS 工具導入、管理并追蹤需求。分析需求并追蹤至設計、實現以及測試工件，有助于提交適合的產品并及時對需求變更做出響應
? 更先進的需求影響分析，覆蓋度分析
? 提供Synergy、RTC、CC等配置管理工具集成接口，支持并行開發與協作。
展開 MBSE | MathWorks 工具在基于模型系統工程中的應用
前文回顧：MBSE | 基于模型的系統工程系列之基礎篇
◆ ◆ ◆ ◆
從上一篇文章我們可以看到，系統工程的活動種類比較多，包括了技術過程的相關活動、技術管理過程相關的活動，以及項目使能過程相關的活動。
這些活動的概念和內容我們已經有了基本的了解，
接下來我們看一看，怎樣使用 MathWorks 提供的工具鏈執行這些活動。
大家知道，MathWorks 在 2019 年推出了一個面向系統工程應用的工具——System Composer，從 2019a 版本發展到今天的 2020b 版本，經過多個版本的迭代，功能更加完備，和 MATLAB/Simulink 的其他工具集成的越來越好，正在得到越來越多系統工程師的關注和使用。
但在這里有必要強調一下，正如前面所說，
系統工程涉及的工程活動非常多，這些工程活動的實施不僅需要 System Composer，還需要 MATLAB 和 Simulink 以及其他 Tooblox/Blockset 的支持。
總體來說，System Composer 在系統層面的描述能力、MATLAB 提供的分析能力以及 Simulink 提供的系統級建模仿真能力，讓使用 MathWorks 的工具鏈開展的系統工程活動，在
“定性”
和
“定量”
方面均有更好的工具基礎。
下面我們通過一個實例來看一看，采用 MathWorks 提供的工具鏈怎么開展系統工程的各項活動。
◆ ◆ ◆ ◆
假設我們接收到的任務是開發一個實時跟蹤綠色球的系統。
任務/目標定義 和 需求工程
首先，基于這個任務定義，我們需要細化這項任務需求，比如回答下列問題：
目標球的材質是什么？
目標球有多大？
目標球向幾方向運動？
展開 CatiaMagic — 基于MBSE的產品創新和正向開發工具
軟件依據MagicGrid方法論，提供設計向導、流程模板，通過實踐，幫助MBSE在研發各階段落地實施。
? 仿真分析功能
提供模型執行框架（OMG fUML、W3C SCXML、JSR223等）；支持模型調試和執行動畫環境；支持用戶交互界面建模和執行；內嵌求解器，支持與多學科專業分析工具（如Matlab/Simulink、MatheMatics、Maple、FMU等）集成。通過執行仿真，可以在系統設計的早期發現系統的設計問題并進行修正。
? Simulink / Modelica 轉換插件
提供轉換插件，實現SysML到Simulink/Modelica的模型導出，用于后端專業設計與仿真。
? 二次開發方式
具備豐富的API函數，可根據特殊使用場景定制與特定工具之間的交互，可根據用戶使用習慣定制相關向導界面；支持豐富的腳本語言，可支持相關腳本開發；支持OCL規則，可定制模型規范檢查方式，用于模型合規性測試；支持報告模板定制，可實現設計產物的自動報告生成。
? 自動代碼生成
支持Java、C++、CORBA IDL、DDL、XML Schema、WSDL和C#語言，為合并代碼和UML模型提供了一個簡單直觀的圖形界面，同時也為UML模型和代碼中的模型準備了代碼框架。UML模型可以被轉換為這些語言中的任何一種，或者可以從用這些語言編寫的源代碼創建UML模型。
? 團隊協同
支持多個用戶在同一個項目的團隊協作，包括成員之間數據同步及消息發送；支持項目權限管理、項目變更管理；支持將項目發布到服務器，供全球分布的項目團隊成員校對、審核、審定和批準等工作。
展開 
技術交流 | MBSE技術及其在航天產品領域的應用建議
總體和分系統研制人員基于這些共性的基礎模型庫來進行MBSE模型的構建，從根本上保證設計術語的統一。
（5）培育自主可控生態，掌握核心發展競爭力
MBSE工具軟件在工業軟件領域屬于新興板塊，目前國內具備一些功能完善的MBSE建模工具。立足長遠，從工具語言的原生適用性、安全性和自主定制的可控性等方面，自主軟件都有著超越國外軟件的優勢。建議在MBSE系統建模與仿真領域，結合行業應用，在使用國際主流工具的同時，支持和培育國產自主可控工具生態，加強自主工具的應用驗證和型號應用，通過工具固化工程知識經驗。
作者簡介：
1 范松濤，中國空間技術研究院總體設計部，型號副總師，研究員；
2 魏平，中國空間技術研究院總體設計部，主任設計師，高級工程師。
文章來源：航天軟件和數字化
展開 [論文賞析]基于MBSE的衛星通信系統建模與仿真
為了加強MBSE在航天器研制生產中的推廣落地，這篇論文從基于 MBSE 的開發流程和方法入手，對火災衛星航天器的任務分析、任務上下文、需求、接口、行為等方面進行了詳細的建模分析。最后，通過對模型的集成仿真驗證，驗證了模型的邏輯合理。結果表明，相較傳統DBSE方法，MBSE可以更好地確保航天器設計過程中設計信息的一致性，提高工作效率，降低航天器研發成本，加速推廣應用。
01
補充介紹
NASA長期致力于提高小型航天器的能力和可靠性，特別是在深空環境下。小型航天器有助于NASA通過新型的和成本更低的任務架構實現科學和探索目標，包括基于小型航天器集成的架構，或用小型航天器增強大型常規航天器的架構。NASA期望通過MBSE方法和工具實現這一目標。具體包括以下方面：
定義、設計、開發、分析、執行和驗證未來的小型航天器任務。
通過開發先進的方法和工具，實現更快速、全面、深入和集成的航天器設計，貫穿整個項目生命周期，從概念到系統操作和任務結束處理。這些功能應該利用正在NASA中進行試驗的MBSE方法，并支持不同模型類型和各種規程工具的敏捷集成。
為未來任務的設計提供跨學科系統分析。
這包括對這些任務的決策建模和規劃支持。這種模型也可用于評估技術替代方案和影響、科學評估方法以及規劃和/或建筑貿易，包括由多艘航天器組成的潛在任務架構。
具體感興趣的領域列出如下。鼓勵強調或處理多個領域的方法。
展開 Ansys推出Moxie以改進系統模型的驗證流程
Moxie在虛擬環境中執行一個SysML狀態機，以評估系統架構在任務場景中的功能
Moxie通過將SysML編輯工具與任務建模工具，例如AGI的系統工具套件（STK）進行集成，降低了編程風險并減少了成本高昂的返工。在虛擬操作環境中運行SysML行為架構，有助于工程師按照任務級要求驗證系統模型，無需等到物理系統可用時再去執行驗證。使用Moxie，工程師還能獲得獨特功能，對于一個潛在的新用例，可以直接在虛擬環境中進行評估，而同樣的工作對于真實物理系統而言，不僅成本高昂，而且不可能完成。
Parsons技術總監Stephen Thomas表示：“Moxie幫助我們團隊使用狀態機和活動圖在MBSE工具Cameo中為動態功能建模，并在STK中評估這些流程。這進一步擴展了我們當前的需求追蹤能力，并完善了我們的Phoenix Model Center MBSE功能。我們一直在展示這種能力，以對所有與導彈防御有關的活動建模，并評估這些流程如何影響傳感器、攔截器和命令控制系統的性能要求。”
Ansys高級副總裁Shane Emswiler指出：“收購AGI并推出Moxie后，Ansys助力工程師使用時間同步、基于事件的可執行架構，在現實環境中虛擬地評估和改進其SysML行為模型。通過在產品生命周期的早期階段根據任務級要求分析和驗證其系統模型，工程師可以信心十足且以較低成本預測任務結果，并評估功能性能。”
Ansys中國推出豪華技術盛宴——Ansys 2021 R1新品發布系列網絡研討會，周周都有多個精彩議題與大家見面，多達30+場線上分享會將持續至5月，目前全系列網絡研討會已開放報名通道，快點加入我們，開啟你的2021學習計劃吧！
點擊查看直播
展開 我們是否需要統一產品線工程的標準——如果需要，有哪些標準？
SysML V2的范圍是基于模型的系統工程，而VEL將作為PLE工廠配置器（ISO26580定義的術語，指的是像pure-systems的pure::variants和Biglever Gears這樣的工具）和共享超集資產的工具（如需求管理或MBSE工具）之間交換可變性信息。
與ISO的PLE標準相反，上面提到的所有其他標準都側重于為數據交換和流程提供具體手段，但缺乏ISO標準中的方法論。
沒有一個標準可以統治所有其他標準
所有這些標準實際上都有其在大環境中的作用。如果我們看一下汽車行業，未來的汽車和相關的基礎設施（如智能高速公路）是使用基于模型的系統工程開發的，然后被用作基于AUTOSAR的軟件開發的輸入。變體貫穿于這些不同的模型/數據域，需要以整體的方式進行控制，其中VEL作為通用語言，將用于在不同的工具之間交換可變性信息，如SysML V2建模工具、AUTOSAR工具和PLE工廠配置工具。ISO標準幫助我們建立一種方法，并了解工具和組織必須滿足哪些要求。
考慮到這一點，我們必須將不同的標準統一起來，在不妨礙演變和創新的情況下進行合作。值得說的一點是，不會有一個標準來統治它們。
PLE社區正走在正確的道路上
我認為PLE社區正走在正確的道路上，因為我們中的許多人參與了各種標準化活動，并花了很多精力與系統工程領域的專家、工具制造商等溝通，了解開放一致的概念對合作的重要性。
如果我們把PLE看作是一個真正的整體方法（確實如此），我們也必須接受機械工程及其標準（特別是數字表示領域的標準，如ISO 10303）。這就是為什么我們很可能看到未來會出現更多與PLE有關的標準或現有標準的演變。
展開 