MBSE過程
關注創建者：王靖雯 創建時間：2023-06-02
MBSE過程的實例教程
綜上所述，MBSE在水下航行器設計過程中具有重要的作用。它可以提供全面的設計優化和評估手段，促進不同學科領域的合作，提高水下航行器的性能、可靠性和安全性。
它以圖像化的方式定義了不同類型的視圖表達方式，例如需求視圖，結構視圖，流程視圖，狀態視圖等等，這些視圖相互補充，可以用于表達MBSE設計過程中關注對象的不同側面(View)，進而形成完整的系統架構模型。
但應該如何通過這些視圖將SE方法論中的工作內容盡可能有層次地，可追溯地，完整地統一在一個系統化模型中，實現一體化的模型設計呢？
答案就是RFLP方法。
所謂的RFLP 方法就是：
R: 需求(Requirement)
F: 功能(Function)
L: 邏輯(Logical)
P: 物理(Physical)
RFLP認為我們應該從以上四個角度(Viewpoint)去對待系統，通過建立相應的架構模型，將復雜技術產品的實現過程進行完整映射。關于RFLP進一步內容我會在架構專題中進一步探討。
工具是指在實施MBSE過程中建立，建立及管理模型所使用的軟件工具，它們可能是多個工具，包括了需求定義及管理工具，架構建模工具，測試驗證管理工具等，它們之間通過接口可以進行交互，建立可追溯性，也可以是自主開發的綜合性設計工具，將MBSE過程建模統一在一起。
個人認為，MBSE方法論大家都比較熟悉，MBSE落地實施的關鍵除了思維轉換，擯棄原有基于零部件的開發，以及開發流程匹配外，模型的建立是關鍵，而有效的工具支持是建立及管理模型的必要條件，它能幫助將工程師從繁雜的文檔工作中解放出來，專注于可視化模型的建立，整個產品研發以模型作為驅動，提高產品開發效率。
聊了這么多關于SE或MBSE基本內容，我們現在回過頭來再看下標題中的問題:
為什么MBSE是系統復雜性的應對之道？
展開 2月28日安世亞太系統工程大講堂將邀請No Magic公司專家來華介紹MBSE方法學、產品工具、解決方案和案例。相關消息發布后，引起業內很大關注[1]。大家共同關心的問題包括：No Magic公司的MBSE解決方案與業界其他公司的產品和方案孰優孰劣？在國外的應用情況如何？面對各個供應商的產品和方案，用戶該如何選擇？本文力圖站在盡量客觀的立場上，盡量采用具有公信力的材料，嘗試對上述問題進行簡要回答。敬請各位專家同仁拍磚指正。
1
從系統工程的視角看待MBSE的實施過程
系統工程從傳統的以文檔為中心的模式向現代的基于模型的范式的演變[2]，在國外正方興未艾、日趨成熟，在航空航天國防軍工等傳統系統工程行業開始步入取得巨大收益的階段，并開始進入能源、交通、醫療、建筑、乃至公共安全等幾乎所有人類生產生活相關領域；在國內則剛剛起步，目前還只是復雜裝備研制相關行業有所關注。在這種受客觀規律支配、沒多大中國特色的復雜工業品（既包括硬件、也包括軟件）研發和應用領域，學習國外的最佳實踐是實現望其項背到并駕齊驅的后發超越之路的最有效途徑。
圖1 能力成熟度提升過程
一切能力成熟度提升的過程都是系統工程過程，需要系統工程的方法和過程指導，MBSE的實施過程也是如此。
圖2 MBSE實施四要素[3]
圖3 建模工具三要素[4]
我們選取MBSE實施過程中的一項重要工作（圖2）——建模工具的選擇（圖3），來闡述如何將系統工程的方法和過程應用進來。
展開 當然，如果業務人員去擴展其他領域（例如建模語言）的知識，對業務人員也是有幫助作用的，但是一味地去強調語言，而忽視業務方面知識的了解和提升是我們進行MBSE過程的一個誤區。
當然我們如果了解一下這些語言的發展和演變，對我們了解MBSE的發展過程還是有一定的好處的，那么我們首先需要了解的就是，目前所有主流的系統建模工具都支持系統建模語言，或者可以理解成這些主流工具都是用SysML語言寫出來的。因此，我們在選擇系統建模（MBSE）工具的時候，就無需糾結哪些工具是否支持SysML語言了，我們要做的只是應該基于本企業的歷史和現狀，來選擇適合本企業的工具就足夠了。
對于語言來說，最早的系統建模語言是UML語言。UML為“軟件”系統建立可視化模型，為“軟件”系統建立構件，為“軟件”系統建立文檔。國際系統工程學會（INCOSE）和對象管理組織（OMG）在對UML2.0的子集進行重用和擴展的基礎上，提出一種新的SysML系統建模語言（Systems Modeling Language），SysML語言2006年被采納，2012年發布規范。
SysML 1.0以UML建模語言為基礎，但是SysML 1.0也有一些局限，尤其是在UML語言以“軟件”為主的應用范圍和架構方面。即使更新的SysML 1.6也有同樣類似的問題。因此，SysML 2.0版本于2019年11月結束了征求建議階段，開發工作已經正式提上日程，根據OMG的計劃，大約在2022年正式發布。
SysML 2.0對UML語言有了顛覆性的提升，比較全面地解決了系統工程的軟、硬兩個方面的問題，最重要的是有效利用企業原有知識和經驗，新的語言與歷史語言會實現并存。
展開 行業應用
國外在MBSE的方法及應用方面開展了廣泛研究與實踐：空客公司在A350系列飛機的開發中全面采用MBSE，在飛機研制中逐層細化需求并進行功能分析和設計綜合；洛克希德·馬丁公司采用MBSE統一進行需求管理和系統架構模型，并向后延伸到機械、電子設備以及軟件等的設計與分析之中；羅·羅公司依據 INCOSE系統工程手冊制定了其自身的系統工程能力框架，實現了從航空動力系統到子系統到部件的系統工程迭代；波音公司構建了以任務和需求定義、邏輯和功能集成、功能和邏輯架構設計為核心的、覆蓋產品全生命周期的MBSE過程，從運行概念到需求到設計到生產。
近年來，中國航空航天領域也開展了MBSE的應用研究，中航工業西安航空計算研究所利用基于模型的系統工程需求分析、功能分析、架構設計方法在某型動力電子控制系統設計中得到了初步應用；中國空間技術研究院載人航天總體部將 MBSE方法應用于載人飛船交會對接任務中，提高了設計效率、改善了人員溝通、進一步降低了設計風險；中航工業飛行自動控制研究所對MBSE流程進行了結構化定義，明確了系統工程活動、輸入輸出及相應的崗位角色，并在飛控、慣導等復雜系統開發過程中進行了 MBSE方法論與工具的實踐；中航工業第一飛機設計研究院采用 Rational DOORS進行需求管理，并按照 Harmony-SE 流程，采用Rhapsody工具完成空中交通防撞系統以及航電系統的系統分析、設計與建模。
展開 
MBSE過程的相關專題、標簽、搜索
MBSE過程的最新內容
從目前基于模型的可靠性安全性分析方法的發展和實際工程需要來看，可靠性安全性分析需要與系統正向設計同步，即從需求分析起開展，但又必須有所區別，使可靠性安全性分析作為 MBSE 中的一個重要組成部分，在依賴 MBSE 設計過程的基礎上也能夠獨立進行。
MBSE 過程最終的輸出是一個可重用的系統數據模型。MBSE的落地實施依賴于3個方面：建模語言、建模工具和方法論。
但采用SysML實現MBSE的過程并不輕松，常見的障礙包括：
SysML基于的是軟件工程特性，對于不具備軟件工程背景的、跨行業的工程師難于掌握。使用SysML開發一個系統架構模型，對許多人來說仍然很有挑戰。
SysML缺少模型結構元素和行為元素之間適當的集成，易導致不一致性，從而增加系統開發的復雜度。
當然，如果業務人員去擴展其他領域（例如建模語言）的知識，對業務人員也是有幫助作用的，但是一味地去強調語言，而忽視業務方面知識的了解和提升是我們進行MBSE過程的一個誤區。
圖1 能力成熟度提升過程
一切能力成熟度提升的過程都是系統工程過程，需要系統工程的方法和過程指導，MBSE的實施過程也是如此。
圖2 MBSE實施四要素[3]
圖3 建模工具三要素[4]
我們選取MBSE實施過程中的一項重要工作（圖2）——建模工具的選擇（圖3），來闡述如何將系統工程的方法和過程應用進來。
圖2《Systems Engineering Demystified》封面
在一個組織中實施MBSE時，必須考慮的一個關鍵因素是MBSE活動的成熟度，為此有必要考察MBSE的演變過程。
MBSE的演變可以被認為是從基于文檔的系統工程方法，一直到完全基于模型的系統工程方法。
2 航天領域MBSE實踐
近年來，在航天領域開展了MBSE應用實踐，初期重點圍繞MBSE語言工具培訓、型號試點應用、建模方法研究等方面開展工作，在過程中統一理解和認知；在廣泛調研與理論探索的過程中不斷與現有流程相印證，梳理、總結、提煉出了基于模型的航天器系統設計與驗證過程及MBSE初步工作指南；將MBSE正向設計流程逐步引入型號研制中，
閱讀之前強烈建議參考之前系列文章:
為什么MBSE是系統復雜性應對之道
在上一篇MBSE開篇文章，我們聊到了MBSE基本概念及其重要性，以模型驅動開發過程是MBSE核心內容，為了建立模型我們需要相應的方法論，建模語言以及工具。今天我們主要來聊聊MBSE相關的方法論。
工具是指在實施MBSE過程中建立，建立及管理模型所使用的軟件工具，它們可能是多個工具，包括了需求定義及管理工具，架構建模工具，測試驗證管理工具等，它們之間通過接口可以進行交互，建立可追溯性，也可以是自主開發的綜合性設計工具，將MBSE過程建模統一在一起。
在進行MBSE實踐過程中，雖然在系統設計時引入了基于SysML的系統模型，解決了系統設計表達和邏輯驗證問題，然而針對復雜工程系統的研發，會涉及到多專業學科，在機械、結構、電氣、電子、液壓、控制、軟件等專業設計階段已經積累的比較成熟的模型，面臨如何在MBSE中應用的困擾。
