基于MBSE的通用質量特性建模分析技術研究

李嬌，敖亮，任文明

（中國航空綜合技術研究所裝備服務產品部，北京101400）

0 引 言

隨著航空裝備復雜程度日益增加、任務多樣化、容錯機制復雜化等，可靠性、安全性、測試性（以下簡稱“三性”）等通用質量特性對整機的約束程度越來越大，對“三性”要求也越來越高。但研制周期越來越短，航空裝備設計分析與評估驗證的難度也越來越大，傳統的系統工程方法已無法滿足現代高度復雜的航空裝備的設計需求。實際上僅僅依靠經驗、文檔以及部分模型等形式的設計已經造成了設計需求迭代頻次增加、分析工作重復、驗證不充分、隱蔽性問題等諸多問題。

故障模式影響分析（Failure Mode Effect Anal‐ysis，簡稱FMEA）［1］是通用質量特性設計分析的主要方法，也是“三性”工作的共用方法，需從FMEA著手解決問題［2］，然而在FMEA實際工程應用中存在很多管理和技術上的問題。

（1）“三性”工作孤立且重復

FMEA是開展“三性”工作的基礎，可作為可靠性建模、測試性建模、功能危險性分析（Function Hazard Assessment，簡稱FHA）等工作的輸入，然而目前“三性”工作是獨立開展的，工程中存在大量重復工作。

（2）總體與成品單位工作缺乏協同

裝備主機與各層級承研單位“三性”工作過程與分析數據缺乏有效協同，甚至各單位表格的表頭都不一樣、報告繁冗低效、FMEA各約定層次產品的故障傳遞關系不對應等。

（3）“三性”與設計工作“兩張皮”

由于可靠性人員對產品功能結構不夠了解，導致分析結果與實際不符，故障改進措施未落實或簡化設計改進措施（如加強篩選等），故障設計改進措施只限于紙上，并未真正在產品中落實。

（4）不能實現動態分析

由于作戰方式的轉變，裝備完成任務的能力逐漸受到關注，當底層器件發生故障時，裝備可通過一系列的檢測、備份、重構等機制實現容錯，保證任務的正常執行［3］。傳統FMEA不方便對產品功能重構過程進行分析，不能有效支持產品任務可靠性分析。

（5）無法實現多因素分析

GJB/Z 1391—2016中指出“FMEA是分析產品所有可能的故障模式及其可能產生的影響，并按每個故障模式產生影響的嚴重程度及其發生概率予以分類的一種歸納分析方法，是屬于單因素的分析方法”［4］。然而隨著產品復雜程度的增加、自主保障模式的推進，很多情況下，多種原因共同作用導致某種故障模式，以及對于影響任務完成的故障模式采取了冗余、容錯等保障措施。

（6）沒有從系統工程角度出發

對于層級較低的成品，無法從裝備安全、任務的功能故障角度開展硬件故障模式的影響分析，導致嚴酷度等級分析無依據，關鍵故障模式識別的準確性無法校核。因為沒有從系統工程角度出發，無法突出成品影響整機完成任務的重要性，造成大量無效果的工作。

胡曉義等［5］對基于系統結構模型和系統行為模型的兩種安全性、可靠性分析方法進行了優缺點分析，但沒有將同樣依靠故障邏輯模型進行分析評估的測試性納入進來；陳松［6］指出傳統可靠性安全性分析工具FTA、Markov和Petri等很難對系統進行設計，而由達索、空客與波爾多大學在20世紀90年代末合作開發的AltaRica語言則可更好地表現系統的功能和物理架構，但是僅進行了安全性分析，沒有考慮可靠性和測試性，依然無法全面解決“三性”重復工作的難題。

在此基礎上，本文以功能需求為牽引，在早期需求分析與系統架構設計階段，實現裝備功能架構權衡設計與優化；以故障邏輯為核心，加強系統功能與通用質量特性設計之間的數字化模型集成，推動基于模型的同源數據傳遞、分析評估、設計反饋等工作模式，實現航空裝備基于模型的系統工程（Model Based System Engineer，簡稱MB‐SE）研制模式下基于數字化平臺的多專業協同設計與分析評估。

1 分析過程

1.1 基于MBSE的產品設計分析過程

MBSE是通過形式化的建模手段，從概念設計階段開始就能夠支持系統需求、設計、分析、驗證和確認等活動，并持續貫穿整個開發過程和后續的生命周期階段［7］。

國外，NASA實驗室、空客、波音、羅羅、洛克希德·馬丁公司等早已在數字化樣機建模過程中應用MBSE技術，可用于產品全壽命周期需求捕獲，表達與產品定義相關的信息，提供與產品行為全方位的交互機制，實現多學科多領域協同設計［8］，具體過程如圖1所示。目前，國內航空、航天部分重點單位也已初步開展MBSE相關工作。

圖1 基于MBSE的產品設計分析過程Fig.1 Product design analysis process based on MBSE

MBSE的設計、分析、驗證目前多應用于產品設計領域，但針對通用質量特性相關研究內容較少，目前軍民機的通用質量特性設計分析不能有效的結合產品的實際物理結構，在工程中存在嚴重的“兩張皮”現象。

1.2 MBSE模式下通用質量特性需求分析過程

MBSE模式下通用質量特性需求分析過程的目標是分析用戶需求，是整個研制流程的輸入。本文引入Harmony SE方法［7］進行需求分析，需求分析階段的目的是分析整個項目的輸入，即飛機頂層需求，包括功能需求、性能需求、約束和接口需求［9］。基于Rhapsody等軟件工具建立用例圖、活動圖、時序圖等，通過建立活動圖并關聯利益攸關者進行黑盒設計，主要用于分析系統與外部功能的交聯關系；然后權衡功能設計架構，基于泳道分配進行白盒設計，主要用于分析系統內部功能模塊，具體過程如圖2所示。

圖2 基于Harmony SE開展功能需求分析Fig.2 Function requirement analysis based on Harmony SE

通過需求分析，用戶需求被翻譯為系統需求。需求分析的關鍵步驟是定義系統用例，詳細描述角色（利益攸關者）的行為、角色與用例之間的信息流。

然后，開展功能分析，系統功能分析階段的重點是把系統功能需求轉換為系統功能描述。功能分析是基于用例進行的，該階段建模利用3個Sys‐ML圖來展現用例行為：活動圖、序列圖、狀態圖，把每個需求分析階段確認的用例翻譯成可執行模型。

最后，進行設計綜合，包括架構分析和機構設計兩個方面，通過設計綜合，采用“自頂向下”的工作思路，利用SysML的模塊定義圖和內部模塊圖來描述，把功能架構“映射”成物理架構，最終完成方案設計，具體過程如圖3所示。

圖3 需求分析開展過程Fig.3 Requirements analysis development process

2 功能故障邏輯建模方法

2.1 建模技術方法

本文建立“功能需求—功能架構—硬件設計”和“功能架構—故障邏輯—故障分析”兩層關系，第一部分是產品正向研制過程，第二部分是故障邏輯分析過程，兩者通過功能架構緊密結合，使得通用質量特性與產品的物理結構緊密結合，可有效解決“兩張皮”問題，形成基于功能故障邏輯模型的協同設計。

（1）功能與故障結合建模思路的由來

為解決“三性”與設計工作“兩張皮”這一問題，采用功能與故障結合建模思路，功能是實現各研制階段產品設計逐步細化和定義上下層級間接口關系的中間橋梁，功能需求分析是假設工作狀態正常基礎上開展的，然而實際工程中，總會存在功能故障的情況，因此將功能與故障邏輯結合起來，將可靠性、安全性和測試性重復開展的故障邏輯關系分析統一建模，實現模型復用。

此外，裝備級、系統級和模塊級各層次產品FMEA一體化，具體過程如圖4所示，即模型語言，方便總體與成品單位協同。從系統角度出發，方案設計、初步設計和詳細設計階段各設計階段數據一體化分析。

圖4 基于功能故障邏輯一體化過程Fig.4 Logical integration based on functional failure

（2）功能故障邏輯建模原理分析

將功能封裝起來看作一個黑盒，黑盒間通過輸入輸出端口連接，各個黑盒連接起來構成整個系統。黑盒內部是實現該物理功能的硬件結構，通過對輸入輸出端口進行故障定義，功能交互路徑可構建故障邏輯的傳遞關系，具體過程如圖5所示。

圖5 故障邏輯模型形成過程Fig.5 Failure logic model formation process

（3）建模語言的選擇分析

選好建模語言是實現建模的必要工具，目前存在兩種主流建模語言：

SysML是一種通用的針對系統工程應用的圖形化建模語言［10］，適用于系統早期的功能架構與物理架構設計，但不能支持可靠性分析、性能仿真。

AltaRica語言是事件驅動，安全性和可靠性研究的主要目標是檢測出導致系統從正常狀態轉變到故障狀態的事件，并對事件進行量化。AltaRica定義了控制轉換系統（Guarded Transitions Sys‐tems，簡稱GTS）［11］：系統狀態用變量描述，只有相應的事件發生時，系統狀態才會發生轉變，但是不對事件和狀態的物理含義進行假設。GTS可封裝到分層“黑盒”里，“黑盒”設置輸入輸出端口，“黑盒”間通過“線”進行連接，這些“線”代表封裝變量之間的約束條件，通過故障判據，激發狀態變遷，可靠性、安全性就是和故障做斗爭的學科。AltaR‐ica語言非常適合用來描述復雜系統的安全性、可靠性并進行計算分析。

基于以上功能故障邏輯建模原理，AltaRica模型的主要構成元素包括模塊、輸入/輸出端口、狀態、事件和轉換［12］，以參量化的狀態定義為核心，通過事件的觸發描述系統或組件的工作模式或故障狀態變化，并進一步采用函數調用的方式實現對系統架構層級、組件交互邏輯（正常/故障狀態的傳遞及影響）的定義。AltaRica可以更好的表現系統的功能和物理架構，可滿足復雜系統關于系統架構、故障邏輯信息建模工作［13］。

2.2 功能建模過程分析

功能建模用于構建在理想的環境條件下系統的正常工作過程，功能模型用來表征產品架構組成關系、輸入/輸出端口及各層級交互關系，建模對象可以覆蓋整機、系統、分系統、設備、功能電路、元器件等。系統功能建模的過程如圖6所示。

圖6 功能建模過程Fig.6 Functional modeling process

系統功能建模的主要步驟為

（1）創建頂層功能

選用輸出端口，按照系統設計要求，定義系統功能，端口的交互信息用于定義當前功能的具體描述。

（2）創建物理端口

根據系統設計要求和功能原理，不考慮系統內部組成，以系統為最小分析單元考慮其與外部交互的實際輸出，以輸出端口的形式進行定義，物理端口的交互信息用于詳細說明當前端口的實際輸出對象，主要包括能量、數據、信號等。

（3）功能與物理的關系映射

構建系統的實際物理輸出與系統功能之間的邏輯關系，具體是指本層級的物理輸出端口與上層級的功能端口，如圖7所示。

圖7 功能與物理的關系映射Fig.7 Mapping between function and physics

（4）創建系統內部架構

創建下一層級直至最底層的內部功能架構。①創建下一層單元實際物理輸出。

針對各單元模塊，采用輸出端口創建各單元的實際輸出，端口的交互信息用于詳細說明當前端口的實際輸出對象，如電壓、控制信號等。

②系統內部的連接關系構建。

依據系統功能框圖或功能原理圖，按照系統實際的工作過程和功能流向，將各單元的輸出端口連至相應單元作為后者的輸入，不限制該項操作，可解決傳統FMEA中的技術缺陷，實現多因素故障原因分析。

③系統內部與系統輸出的關系構建。

確定完成系統輸出的最底層單元和相應模塊的輸出端口，將各層單元物理端口與相對應的系統功能輸出端口進行匹配，并分別連至相應端口，如圖8所示。

圖8 某層級所有單元與系統功能交互定義Fig.8 All units at a level interact with the system function definition

2.3 故障邏輯建模過程

系統故障邏輯關系的建模［14］過程是以功能建模的結果為基礎，首先定義系統級與單元的功能失效，其次以功能建模中的單元交互為故障傳遞路徑，構建單元對系統功能的故障影響關系［15］，其建模的主要對象包括系統的功能失效狀態定義、單元的功能故障模式定義、單元輸出對象的故障類型定義、系統功能失效的局部故障原因分析、單元故障輸出的局部故障原因分析以及單元動態故障邏輯定義，如圖9所示。

圖9 故障邏輯建模過程Fig.9 Fault logic modeling process

具體建模方法及過程如下：

（1）頂層功能失效狀態定義

在系統頂層功能的輸出端口上，定義系統功能失效狀態［16］，失效狀態來自系統各研制階段下的故障模式數據，如組件的功能故障模式。

（2）系統物理端口失效狀態定義

針對其相對應的中間模塊的輸出端口失效狀態定義，通常是按照當前輸出的相關故障判據閾值進行劃分和定義。對于不對應任何實際硬件單元的功能邏輯模塊，則虛擬成一個硬件單元，并進行物理端口失效狀態定義。

（3）功能與物理映射

故障邏輯建模過程包括系統內部故障邏輯和功能與物理映射，是一個先外部再內部的順序。首先，將各層功能與物理端口進行匹配的過程機功能與物理映射［17］，如圖10所示。

圖10 故障邏輯建模過程Fig.10 Fault logic modeling process

（4）系統內部故障邏輯

系統內部故障邏輯包括局部故障和底層故障邏輯兩種，將輸出端口的功能失效狀態作為頂事件，故障原因既包括自身原因也包括輸入端相關因素。

①中間層故障邏輯。

頂事件是中間模塊功能輸出端口失效狀態，底事件僅為中間模塊的功能輸入端口失效狀態。

②底層故障邏輯。

頂事件是底層單元輸出功能端口故障模式，底事件為當前模塊的輸入端口故障模式和自身狀態。

3 案例應用

3.1 飛控系統功能架構需求分析

在某直升機飛控系統的架構權衡過程中，首先進行利益攸關者分析，然后對飛控系統的內部功能分析和外部功能交聯關系進行分析，在功能需求分析和架構形成過程中，充分考慮橫向姿態控制功能、縱向姿態控制功能、航向控制功能和總矩控制功能等關鍵功能需求，以及與液壓系統、導航/大氣系統、供電系統等交互關系，如圖11所示。

圖11 基于Rhapsody功能需求分析Fig.11 Requirement analysis based on Rhapsody

3.2 基于AltaRica語言的功能模型構建

直升機飛控系統主要實現對橫向、縱向、航向和總矩的控制功能，飛控系統與其他系統功能交互模型如圖12所示，將飛控系統功能“映射”到具體的物理架構，進行飛控系統內部功能關系構建，具體功能模型構建過程見2.2節，功能模型如圖13所示。

圖12 飛控系統與其他系統的交互關系功能模型Fig.12 Functional model of interaction between flight control system and other systems

圖13 飛控系統功能與物理映射關系Fig.13 Function and physical mapping of Flight Control System

3.3 飛控系統故障邏輯建模過程

飛控計算機是飛行控制系統的核心部件，本文以飛控計算機為例說明故障邏輯的建模過程，并對其優越性進行分析。飛控計算機完成飛控系統控制律計算功能，并向伺服系統輸出控制指令；同時它還要完成整個系統的管理功能，實現整個系統余度管理計算與邏輯判斷、工作模式轉換，以及系統狀態申報、故障告警和飛控系統的BIT等功能。

基于上述功能模型，結合飛控計算機各種部件的失效模式及狀態轉移關系，對飛控計算機故障信息進行補充，并以所有輸出端口的故障模式為故障樹的頂事件進行故障邏輯建模。

飛控計算機的部分失效模式如圖14所示，并以飛控計算機的核心部件——前主槳舵機、左主槳舵機為例，說明故障邏輯的建模過程以及優越性。

圖14 飛控計算機故障模式Fig.14 Failure mode of flight control computer

在飛控系統中，是存在復雜的冗余機制的，前主槳舵機控制信號故障邏輯關系如圖15所示，如若不考慮冗余，則不能反映真實故障情況，本文在各層級故障邏輯建模中考慮冗余備份，冗余機制下存在多個失效狀態（如正常、降級和失效），是實現動態分析的基礎，更符合真實故障傳遞過程，針對系統的動態可重構特性可開展基于有限狀態機模型的任務可靠性建模分析，可解決傳統FMEA不可進行動態分析的技術缺陷。

圖15 前主槳舵機控制信號_左故障邏輯關系Fig.15 Logic relation of left fault of control signal of steering gear of front main propeller

此外，傳統FMEA分析中，只考慮自身故障原因，本文基于AltaRica語言建模，飛控系統左主槳舵機輸出喪失的故障邏輯除了來自自身的原因，如圖16所示，還包括液壓、電源、舵機控制信號以等故障原因，可解決傳統FMEA中的單因素分析問題。

圖16 飛控系統左主槳舵機輸出喪失故障邏輯Fig.16 Flight control system left main propeller rudder output loss fault logic

3.4 優勢性分析

基于MBSE的通用質量特性建模工作存在以下六方面優點：

（1）模型復用，以上故障邏輯模型，可靠性、安全性和測試性均可復用，避免了大量重復工作。

（2）模型語言，高效簡潔，傳統自底向上進行的FMEA工作過于形式化，分析表格繁冗，分析結果缺乏針對性，糾正措施未有效落實。

（3）功能故障結合，自上下向功能分析與自下向上故障邏輯傳遞緊密結合，解決設計與通用質量特性“兩張皮”現象。

（4）動態分析，可分析存在冗余情況，如圖14所示，可實現四選二的復雜冗余系統，傳統FMEA不考慮冗余情況。

（5）故障原因分析全面，考慮除左主槳舵機自身因，還包括液壓、電源、舵機控制信號以等故障原因。

（6）系統工程角度，以功能需求為驅動，與產品正向研制緊密結合。

4 結 論

本文實現了“功能需求—功能模型—故障邏輯”完整建模過程，基于功能故障邏輯開展“三性”一體化設計分析，避免重復工作。此外，與傳統FMEA故障邏輯建模過程相比，采用AltaRica語言建模，實現了功能與故障邏輯結合，可有效解決“兩張皮”問題。