基于多視角的民機正向設計建模方法

畢文豪，范秋岑李德林，張安

1.西北工業大學 航空學院，西安 710072

2.中國航空研究院，北京 100029

隨著信息科學、系統科學、計算機科學、管理科學等學科，以及復雜系統建模技術、模型仿真技術、決策技術等關鍵技術的迅速發展，民用飛機的設計已經逐漸成為一個大型的多學科交叉、多領域融合、多種技術高度集成的復雜系統工程［1-2］。系統工程理論和方法已用于工業、農業、航空航天、社會等多個領域，并取得了重要應用成果［3-4］。

民機正向設計是指以利益相關方需要/需求為驅動，自上而下地進行分解，通過構建民機功能網絡結構進行詳細功能設計，并基于此建立邏輯及物理架構，形成各級系統、子系統及部件設計方案的系統工程活動。傳統的民機正向設計過程是基于文檔管理的，以自然語言為主要語言、圖表為主要承載形式，對民用飛機設計中產生的項目文檔、技術規范、管理條例等進行描述，不同領域的設計人員從文檔中讀取信息很容易產生理解偏差，從而導致在設計過程中需要反復迭代修正，嚴重影響了復雜系統的開發效率。這導致了設計文檔變更難度大、工程模型可讀性差、工程數據追溯性差、設計周期不斷拉長、設計成本增大且版本難以控制等問題［5-7］。正向設計能力較弱已經成為制約中國航空產業實現自主創新、增強市場競爭力的重要因素［8］。

目前，民機設計在型號設計上逐漸推廣基于模型的系統工程（Model Based Systems Engineering， MBSE）方法［9］來構建涵蓋需求、功能、邏輯和物理層面的設計架構和邏輯關聯，與民機產業發展亟需推進的正向設計趨勢不謀而合。中國商飛在C919大飛機研制中探索正向設計與研制方法，在工程設計研制實踐中力爭完全掌握自主知識產權，在研制過程中基于異地協同機制，采用基于模型的定義（Model Based Definition， MBD）的方法，實現產品設計與制造高度并行、廣域協同，無紙數字化制造技術得以落地實施［10］。美國國家航空航天局（National Aeronautics and Space Administration， NASA）將MBSE方法應用于培養超高效、低排放的航空動力（Fostering Ultra-Efficient， Low Emitting Aviation Power， FUELEAP）項目，構建了利益相關方之間規范的溝通途徑，包括功能和物理架構的所有主要方面進行建模并實現需求追溯［11］。

國內外研究機構和眾多學者對MBSE在復雜體系和系統建模中的應用進行了較為深入的研究，尤其是在航空［12-14］、航天［15-16］、車輛工程［17-19］等涉及復雜體系及系統的領域內并行實施了理論研發與技術實踐，在開發周期和質量水平方面都取得了較為顯著的提升［20-21］。

在當前的民機正向設計建模中，存在利益相關方與設計需求脫節、需求到功能的映射關系解耦難度較大、系統級系統之間功能耦合關系復雜、系統和子系統之間層次架構不清晰、子系統之間功能流和數據接口定義不明確等眾多問題，亟需解耦民機正向設計體系，從多視角描述民機正向設計過程中的工作流、信息流和任務流。

本文面向民用飛機正向設計流程，詳細梳理民機正向設計中的建模要素和邏輯關系，從多視角對民機設計建模過程進行抽象描述，提出一套基于多視角的民機正向設計建模方法。

1 民機正向設計架構構建

1.1 MBSE方法論架構分析

截至目前，系統工程國際委員會（International Council on Systems Engineering， INCOSE）已公布了6種MBSE方法論［22］，分別為IBM Rational Telelogic Harmony-SE［23］、OOSEM（INCOSE Object-Oriented System Engineering Method）、Vitech MBSE Methodology、RUP-SE（IBM Rational Unified Process for System Engineering）、Dori OPM（Dori Object-Process Methodology）、SA（JPL State Analysis）。此外，法國Thales公司提出的Arcadia方法論［24］和Dassault公司提出的MagicGrid方法論［25-26］的應用也較為廣泛。MBSE方法論對比分析如表1所示。

表1 MBSE方法論對比Table 1 Comparison of MBSE methodology

通過對比分析不難發現，MBSE方法論大多以需求/目標為導向，采取自上而下的正向分解，以迭代化開發的方式，將需求/目標逐層分解，并通過以SysML［27］為代表的建模語言構建自頂向下分解產生需求、功能、邏輯、物理層級的權威真相源模型［28］。但是現有的如Harmony SE、MagicGrid、Arcadia等方法論，都是設計者從自身熟悉的實際設計領域出發，往往都是直接針對系統級的設計對象進行設計，如配套Arcadia方法論而開發的專業建模工具Capella被廣泛應用于Thales公司所設計的航電、軌道交通、航天、雷達系統等［29］。

隨著民機各系統的不斷發展和改進，這些方法論已經不足以全面、清晰地描述民機作為復雜巨系統所面臨的內部系統之間交互的設計架構，在設計中往往難以描述在不同視角下的各民機系統及子系統的耦合交互關系。同時，系統工程方法在實踐中隨著建模對象的復雜性越來越強、模型精細度越來越高，對工程設計人員的專業知識、過往經驗、建模水平都有較高的要求，很難將MBSE建模方法在設計部門進行廣泛推廣實踐。另外，MBSE方法論的嚴格實施對工程設計人員的知識儲備要求較高，尤其是對于民機正向設計缺乏足夠歷史機型設計數據的現狀，迫切需要一套建模詳細流程范式，以輔助設計人員在MBSE方法論的指導下更好地進行民機正向設計的建模設計工作。

對民機正向設計而言，CCAR-25（中國民用航空規章運輸類飛機適航標準）［30］、SAE ARP4754A（民用飛機和系統的開發指南）［31］、ISO ISO/IEC/IEEE 15288： 2015（系統和軟件工程-系統生命周期過程）［32］等適航條款和行業標準中隱含著大量產品設計要求［33］。在需求捕獲階段，這些產品設計要求應當盡可能地被有效識別和捕獲，以設計約束或利益相關方需要的形式進入民機正向設計的迭代流程，以進一步確定正向設計流程各階段所涉及的規范、功能、物理結構要求，指導民機正向設計中相關應用、能力、功能的設計工作。

為了更好地滿足適航和市場需求，民機產品主制造商需要向適航局方提供更加嚴謹詳實的適航符合性證據，因此在構建民機正向設計架構時，充分結合適航條款、行業標準、規范就顯得非常重要和必要。目前國內已經基于適航取證的要求，在民機航電系統的研制中采用了正向設計的思路。

基于MBSE方法論的設計邏輯，遵循適航條款和行業標準的規定，提出的民機正向設計流程如圖1所示。按照流程，大致可以將正向設計流程劃分為體系交互、需求、功能、邏輯、物理、關聯回溯等6個模塊。

圖1 民機正向設計流程Fig.1 Civil aircraft forward design process

體系交互模塊是在現代民機以需求驅動為導向的設計背景下逐漸衍生出來的，其主要作用有以下3點：① 在設計初期對利益相關方需要/需求進行捕獲，作為正向設計流程中需求分析階段的輸入，確保民機設計是以需求為驅動，且能夠隨著需求變更而進行改型等工作；② 全面把控民機正向設計的各階段，對各階段下產生的模型、文檔、數據開展過程管理，綜合把握項目開展的迭代周期和模型構建的性能度量；③ 對設計流程中出現的設計沖突和矛盾進行權衡與控制，對現有設計階段下的方案進行評估與決策。

需求分析階段的主要工作是對MBSE流程的初始輸入——利益相關方需求進行分析，產生系統需求，并將利益相關方需求與系統需求相關聯，產生的系統需求定義了系統所需要實現功能的頂層描述。在此基礎上定義系統用例，用于描述操作者（也稱用戶，具體指代可以是人、系統，也可以是任意可產生“主動”行為的部件）的行為、操作者與用例之間的信息流。系統用例不對應功能的結構化，不能按照功能分解，但是系統用例需要覆蓋所有的功能需求、性能需求，并建立起系統用例與功能性需求、性能需求之間的追溯鏈接關系。

功能分析階段的主要工作是基于用例模型對功能進行進一步分析和分解，梳理分析功能之間的依賴關系、改善關系等，產生功能網絡結構，并基于此細化分解功能，用連貫的各系統/子系統的功能描述或連續的功能流來關聯系統功能性需求，形成功能和需求的映射關系。在功能分析中新識別的需求或在用例分析中細化的需求，都需要建立新增需求與用例或上級需求之間的追溯鏈接關系，并進入下一層次的需求分析階段。

邏輯架構分析和物理架構分析階段的主要工作任務是，在規定的設計約束下，對承載所需實現功能的邏輯架構和物理架構進行綜合開發。邏輯架構分析階段是將需求分析階段、功能分析階段中輸出的功能性需求、系統需求、非功能性需求以面向用例的迭代設計方式，分配落實在邏輯架構中，以螺旋前進、逐層向下的正向設計方法推進系統架構完善，實現將功能分析階段的黑盒視圖解白的用例實現過程。在物理架構分析階段，以自底向上的設計思路，面向底層用例/功能實現，將實際物理元件嵌入邏輯架構，建立起物理世界的架構，并與邏輯架構對應關聯。

關聯回溯貫穿于正向設計的全生命周期，主要是對設計過程中提出的需求變更申請、需求確認、功能確認、面向功能架構和系統需求的設計確認、面向最終用戶的試驗與評價進行關聯，確保設計過程中的設計迭代能夠形成閉環并促進后續的迭代設計過程。

1.2 基于多視角的架構分析建模方法

民機設計過程中涉及的利益相關方眾多，耦合關系復雜，難以通過簡單的、線性的“分解-集成”系統工程方法實現對復雜系統模型的抽象構建和描述。歐美在探索體系化構建指揮信息系統的過程中，逐漸形成了美國國防部架構框架（United States Department of Defense Architecture Framework， DODAF）［34］、英國國防部體系結構框架（Ministry of Defense Architecture Framework， MODAF）、北約體系結構框架（North Atlantic Treaty Organization Architecture Framework， NAF）、統一架構框架（Unified Architecture Framework， UAF）［35］等為代表的體系結構框架理論成果，實踐證明該類結構框架的理論能夠對存在復雜內聯及外聯關系的事物進行多角度抽象，是有序解耦復雜事物并指導抽象建模的重要科學方法理論［36］。

DoDAF是面向美軍不斷發展的聯合作戰需求而提出的一體化框架，繼承了被廣泛實踐驗證的C4ISR（Command， Control， Communication，Computer， Intelligence， Surveillance， Reconnaissance）體系結構框架，并逐漸完善而形成現行標準，其不僅可用于指導國防指揮控制系統和武器裝備研制，還能廣泛運用到各種商業運作過程中的管理和研發活動［37］。2017年，為了弱化現存各體系結構框架如DoDAF、MoDAF、NAF的視角，解決各體系結構框架概念定義不統一的問題，以進一步提高框架兼容性，對象管理組織（Object Management Group， OMG）發布了統一體系結構框架（Unified Architecture Framework， UAF），其豐富的領域模型和統一元模型語義為體系結構開發提供了更為規范的方法［38-39］，為描述復雜系統及其內外交互關系提供科學的建模支撐。

目前，DoDAF、UAF目前已經被廣泛應用于各類面向復雜體系交互的作戰場景描述、體系能力描述、活動描述等需要依賴多視角描述的工程實踐中，得到了業界廣泛認可，并在民機設計領域得到了初步應用［40-42］。

1.3 基于多視角的正向設計建模流程

民機的正向設計基本上遵循“需求-功能-邏輯架構-物理架構”設計脈絡，利用需求模型到系統模型關鍵設計信息的逐步映射，實現原先傳統飛機設計由概念到詳細的逐步設計。

但是在這類實踐中，各系統之間的交互是以民用飛機利益相關方需求的形式進入設計迭代的。如何理解這樣的需求，準確把握缺少工程視角的利益相關方實際需要，并逐步落實到后續具體設計中，往往還需要結合以往的設計經驗和統一化、模型化、標準化的描述方式。

為了更好地解決民用飛機在多視角下充分解耦的設計需要，使得民機正向設計邏輯能夠科學地從多視角進行解構，本文吸取了DoDAF及UAF在體系分析上的顯著優勢，基于全景視角（All Viewpoint， AV）、能力視角（Capability Viewpoint， CV）、運行視角（Operational View，OV）和系統視角（Systems View， SV）等4個視角，提出了如圖2所示的基于多視角的民機設計建模流程，利用具有一致性的模型將多視角下的設計流程以SysML進行歸納與表達。

圖2 基于多視角的民機設計建模流程Fig.2 Modeling process of civil aircraft design based on multiple perspectives

通過全景視角下的設計綜述與概要信息AV-1、民機設計體系交互概要模型AV-UAF來解耦正向設計流程中的需求分析和體系交互；構建能力視角下的能力愿景CV-1、能力分級描述CV-2、能力依賴關系CV-4以實現功能分析，建立起需求和功能的映射關系、功能分類、功能依賴的邏輯關系；依托運行視角下的高層運行概念OV-1、運行資源流活動OV-2、運行活動模型OV-5a/b、運行狀態轉換OV-6b、事件順序模型OV-6c來描述功能映射到邏輯架構層面時各層級對象的運行目標、資源流活動、活動轉換邏輯及實現順序；以系統視角下的系統功能描述SV-4、系統接口描述SV-1、系統資源流SV-2、活動-系統關系SV-5、部件系統關系SV-3來描述邏輯架構層面映射到物理架構層面的具體實施形式，建立起領域設計內的部件級功能描述和資源流關系，形成邏輯與物理層級的鏈接關系。通過不同視角間的逐層映射，可以保證在每一個設計階段下各利益相關方需求與體系的其他需要的落實與追溯。

2 民機正向設計建模流程

為了進一步詳細梳理民機設計建模流程，以抽象的建模范式為表達形式，對民機正向設計建模中涉及的建模要素進行詳細分析與抽象表達，分析各建模要素之間的內在、外在邏輯聯系關系，形成一套自頂向下的民機正向設計抽象建模范式。

自頂向下不僅僅是實現“需求-功能-邏輯架構-物理架構”的邏輯自洽過程，也是充分繼承了傳統民機系統工程中飛機級、系統級、子系統級、部件級等不同邏輯架構層級的逐層分解與開發過程。

2.1 面向需求的全景視角（AV）建模流程

設計綜述與概要信息模型（AV-1）是對民用飛機待設計系統的雛形概念進行匯總與解析，主要歸納民機待設計系統的構想、目的、范圍、預計成果等關鍵初始設計信息。

AV-1主要利用包圖（Package）構建，其模型中每個包視為民機待設計系統的1個信息集合，在各個包中創建SysML定義的需求圖（Requirement Diagram）來反映最初的工程需要。

設計綜述與概要信息模型ΣAV-1的關鍵概念定義為

式中：I為項目信息包圖；P為目的包圖；R為范圍包圖；Sc為場景包圖；So為系統資源包圖；So-template為需求模板信息；So-alphabet為需求術語表信息；So-type為以往型號設計資料。

AV-1包括項目信息包圖（I）、目的包圖（P）、范圍包圖（R）、場景包圖（Sc）和系統資源包圖（So）5部分。項目信息包圖中，在需求圖中撰寫項目層面的參與設計研發的各部門、設計任務的分配、項目起始、成本投入方面的信息；在目的包圖（P）中，捕獲利益相關方初步形成的原始需求，從設計角度描述系統預期的功能、對系統的非功能性（可靠性、維護性、保障性）要求、多種設計方案下的決策流程與決策方法；在范圍包圖（R）中，指出系統預期的運行范圍與功能執行范圍，明確系統的運行概念與功能邊界；在場景包圖（Sc）中，根據已定義的運行范圍，結合民機及系統任務剖面，定義出該民機待設計系統需要適應的各種場景以及場景狀態信息；除此之外，應繪制系統資源包圖（So），以記錄所有設計過程可能需要的設計資源，基本的系統資源包括需求模板So-template、需求術語表So-alphabet、以往型號設計資料So-type。其中

即通過對記錄在目的包圖（P）中的民機待設計系統的初始需求進行解析，將其進一步拆解為范圍包圖（R）與場景包圖（Sc）中的數據信息。其中功能性及非功能性需求分解為范圍包圖（R）中的系統運行的性能指標與場景包圖（Sc）中的既定運行條件和場景；構建的包圖與包中的設計信息共同構成了待設計系統的AV-1模型。

民機設計內外交互關系如圖3所示。在需求捕獲與分析階段，民用航空體系下例如航空公司、生產制造商、試飛試驗部門都存在反復的需求變更、需求確認等迭代環節；在進入概念設計和詳細設計階段時，各飛機級系統和系統級系統交互關系復雜導致的需求變更與捕獲階段的各交互主體密不可分，需要從多方面建立起利益相關方同架構和基于場景的交互之間的關系，保證系統設計開發過程并非獨立存在，而是與設計流程下的復雜交互息息相關，且能夠隨著需求變更對建立的模型進行動態調整，在迭代修正中以模型更迭的方式實現設計方案的逐步完善及對設計需求的逐步覆蓋。

圖3 民機設計內外交互關系Fig.3 Internal and external interaction of civil aircraft design

民機設計體系交互概要模型（AV-UAF）是在待設計系統上層系統或體系層面，分析待設計系統的功能定位與可能的交互關系，由此確定該系統設計之初的利益相關方及需求來源，初步明確可能存在的接口去向與相應要求。AV-UAF主要包括體系內系統架構關系（St）、基于場景的交互關系（Op）、涉及的利益方（Pr），即

體系內架構關系（St）是基于上層系統（SV）分解的，主要涉及在上層系統/體系內部的結構構成與分類，需要明確待設計系統的功能及結構邊界；基于場景的交互關系（Op）是根據AV-1模型中分類完成的場景（Sc）確定體系內各組成部分的初步交互關系與傳遞的資源或信息類別；涉及的利益相關方（Pr）是對Op中以人為構成主體的體系結構進行進一步歸納細分，補足體系視角下潛在利益相關方的全部捕獲來源。

上述AV-1、AV-UAF模型的建立順序并非逐步進行的，一般來說，這是一個相互迭代逐漸完善的過程。

2.2 面向功能的能力視角（CV）建模流程

在能力視角（CV）下定義的CV-1能力愿景、CV-2能力分級描述、CV-4能力依賴關系3種子視圖作為待設計系統能力描述的3個層次，即

式中：CVision為能力愿景；CTaxonomy為能力分級描述；CDependencies為能力依賴關系。

在系統設計過程中先定義能力愿景CVision，然后根據已定義的CVision分解出能力分級描述CTaxonomy與能力依賴關系CDependencies，其中CDependencies是對CTaxonomy的修飾，即在CDependencies中定義并表示CTaxonomy中的子能力之間的相互關系，即

建立用例圖（Use Case Diagram）描述民機待設計系統的CV-1能力愿景，CV-1能力愿景反映該系統的功能執行期望，用例圖中包括基于系統運行目的（全景視角定義）的基本運行環境與可能的運行模式；在每一種用例圖中反映一個通用場景或者某一特定場景下的系統邊界與運行情況，繪制的要素如下：

1） 系統的交互對象（外界）Cobject，包括系統操作人員Cpeople和其他系統Csystem。

2） 該交互對象情況下，系統能夠執行的功能活動，即系統能力Ccapability。

3） 交互對象與系統內預期功能的關聯關系Crelation。

4） 運行環境與運行場景Cenvironment，即

然后用需求圖、用例圖建立描述CV-2能力分級描述CTaxonomy、CV-4能力依賴關系CDependencies；在CV-2中首先明確民機待設計系統對應的系統運行能力，與已建立的CV-1中反映對應運行場景的用例模型之間建立鏈接，根據CV-1的用例圖，使用用例圖、需求圖或用例圖與需求圖的組合繪制描述CV-1中定義的系統能力愿景的子能力CSubcapability，子能力的撰寫依據為AV-1系統需求信息概要模型中目的包圖模型中所定義的利益相關方需求與非功能性要求；在CV-4中基于CV-2撰寫出的系統功能模塊的子能力之間的協作關系Crelationship，構建待設計系統的子能力模型之間的關聯關系，關聯關系包括依賴（Dependency）、擴展（Extend）、包含（Include），即

2.3 面向邏輯架構的運行視角（OV）建模流程

基于運行視角（OV）的系統功能分析模型，包括OV-1高層運行概念模型、OV-2活動資源流模型、OV-5b運行活動模型、OV-6c事件追蹤描述模型、OV-6b狀態轉換描述模型，即

繪制內部模塊圖（Internal Block Diagram）描述民用飛機待設計系統的OV-2視圖，即活動資源流模型OResource，在繪制的活動或動作之間，定義不同資源和信號的傳遞方式或數據格式，活動或動作之間的流向關系使用信息流（Information Flow）連接器描述

同時，功能活動流OFunctionflow是基于運行視角（OV ）的系統功能分析模型的核心內容，包括輸入OInput、輸出OOutput、動作（活動）OAction、消息流OMessage、狀態OState、時間（序列）OTime、事件分支點ODecision等核心要素，即

式中：OConcept為OV-1高層運行概念模型；OResource為OV-2活動資源流模型；OActivity為OV-5b運行活動模型；OEvent為OV-6c事件追蹤描述模型；OState為OV-6b狀態轉換描述模型。

OV-1高層運行概念OConcept，包括待設計系統的任務OTask、功能活動流OFunctionflow、場景（運行狀態）OScenes；在OV-1視圖中引用CV-1中建立的反映不同運行狀態的用例場景，繪制活動圖（Activity Diagram）以描述該系統應適用的不同場景狀態及其下的系統預期可執行的不同功能活動流，活動圖中以活動或動作（Activity/Action）為單元，定義功能執行過程中的各個功能活動或動作，同時在活動或動作單元之間建立依賴（Dependency）或關聯（Association）的鏈接關系，完成功能活動間的邏輯梳理，即

建立運行活動模型OActivity，即建立該系統的OV-5b視圖。在OV-5b視圖中繪制活動圖以定義該系統的功能活動的運行流程；針對CV-1與OV-1中定義的各場景與系統狀態OScenes，分別對應各用例場景繪制活動圖模型以反映系統不同功能運行活動流，每一個活動圖中繪制活動事件或動作事件作為基本元素OAction，通過構建控制流（Control Flow）或對象流（Object Flow）描述活動事件或動作事件的先后順序與關聯關系OTime，建立判斷點（Decision）表明功能流遇到的條件判斷分支ODecision，同時指示運行活動流的前進方向或者合并功能分支流。一個完整的活動圖，應反映包含輸入OInput、輸出OOutput在內的目標系統的一個功能活動流。不同場景和運行狀態下的所有的活動圖即構成OV-5b運行活動模型，即

繪制時序圖來反映各功能活動的執行周期，通過建立生命線（Lifeline）表明各功能活動OAction的開始與終結，以及功能活動的交互對象Cobject、Cenvironment（在面向功能的能力視角建模流程中定義），建立消息序列（Message）反映功能活動之間消息流OMessage的交流方向與時段；時序圖描述該系統功能活動之間消息發送的先后順序OTime與輸入OInput、輸出OOutput，所有的時序圖構成該系統的OV-6c事件追蹤描述模型OEvent，即

將OV-5b運行活動模型與OV-6c事件追蹤描述模型的信息匯總，繪制狀態機圖（State Machine Diagram）描述基于該系統的不同運行狀態OScenes下的功能活動流程OAction與時序OTime；以狀態（State）或狀態機（State Machine）反映該系統的運行狀態OScenes，以轉變（Transition）連接器及轉變連接器的屬性（Trigger、Guard、Effect）建立不同運行狀態之間的切換關系ODecision，同時反映切換過程中的消息流，每一個狀態機元素中可繼續擴展下層系統狀態，以起始點（Initial）和終點（Final）表明每個運行狀態的執行過程，即完成構建OV-6b狀態轉換描述模型OState；OV-6b狀態轉換描述模型是一個多層迭代的狀態機模型，提供了功能模型設計的一個可執行的功能完整性驗證，即

2.4 面向物理架構的系統視角（SV）建模流程

系統視角用于闡明待設計系統的組成結構和內部接口，以及其他系統在運行和能力視角（CV）和運行視角（OV）中與待設計系統交互的接口組成信息。

基于系統視角（SV）的系統架構模型，包括SV-4系統功能描述模型SFunctionDes、SV-1系統接口描述模型SInterfaceDes、SV-5活動-系統關系模型SActivity-Sys、SV-3系統-部件關系模型SSys-Part，即

在SV-4視圖即系統功能描述模型SFunctionDes中，繪制模塊定義圖（Block Definition Diagram），將該系統的OV-5b運行活動模型、OV-6c事件追蹤描述模型、OV-6b狀態轉換描述模型分配到具體的實體SPart上，通過定義模塊（Block）并撰寫模塊特性SPartFeature，表明該系統內部的物理架構組成及部件模塊的結構特性、行為特性，表達式為

在SV-1視圖中的系統接口描述模型SInterfaceDes中繪制內部模塊圖，用以描述系統部件的接口SPartInterface、數據傳輸格式信息SResource。建立零件圖（Part）與接口單元（Port），并根據基于運行視角（OV）的活動資源流模型OResource撰寫數據傳輸格式信息SResource，結合SV-4系統功能描述模型中定義的實體SPart，完成系統部件接口SPartInterface的定義

構建矩陣表格定義SV-5活動-系統關系模型SActivity-Sys、SV-3系統-部件關系模型SSys-Part。在SV-5活動-系統關系模型SActivity-Sys中，根據SV-4系統功能描述模型中定義的部件SPart，結合在OV-5b中定義的運行活動模型OActivity描述的目標系統的功能活動流，明確系統功能分析（OV）模型中定義的各功能活動流OFunctionflow執行所需要或涉及的各系統部件SPart（SPart應在SV-4中已定義，若未定義則應補充定義），表明各功能活動OAction與其執行對應的部件SPart之間的關系。在SV-3系統-部件關系模型SSys-Part中，結合OV-2活動資源流模型OResource，定義SV-4系統功能描述模型中定義的部件SPart與其他系統SOtherSys的包含關系，表明該部件重復用于其他系統，或該部件引用于其他系統，表達式為

SV-5活動-系統關系模型矩陣表格的行是運行視角下系統功能分析模型中的主要功能活動OActivity-Function，SV-5活動-系統關系模型矩陣表格的列是系統視角下的部件SPart；SV-3系統-部件關系模型的行是運行視角下系統功能分析模型中所有其他系統SOtherSys，SV-3系統-部件關系模型矩陣表格的列是基于系統視角的部件SPart；SV-5活動-系統關系模型矩陣表格中每一個元素分別反映了基于系統視角定義的部件與基于運行視角定義的運行活動之間的關聯，SV-3系統-部件關系模型矩陣表格中每一個元素分別反映了基于系統視角的部件與其他系統的交聯關系，SV-5活動-系統關系模型矩陣表格將OV與SV模型關聯起來，SV-3系統-部件關系模型矩陣表格則能快速瀏覽系統資源之間的交互。

3 艙壓控制系統建模實例

民用飛機艙內壓力控制是飛機環境控制的重要組成部分，其作用是保證民用飛機座艙內空氣的壓力及其變化速率在整個飛行包線內滿足規范要求。根據控制器的類型，民機艙內壓力控制系統可以分為氣動式、電子式、數字式；根據其執行機構可以分為氣動式、電動式；控制器和執行機構的不同組合形成不同的艙壓控制系統［43］。

民機艙內壓力控制系統的發展經歷了純氣動式、電子氣動式、電子電動式、數字電動式等階段。數字電動式艙內壓力控制系統作為一種先進的座艙壓力控制系統，具有適應性強、控制精度較好、易與飛控計算機及大氣數據計算機配合、可實現全航程座艙壓力按程序的自動控制等優點，已在民用大型客機、公務機、軍用教練機等領域得到廣泛應用［44-45］。

以數字電動式艙內壓力控制的設計邏輯為例，在第2節民機正向設計建模流程指導下，面向民機飛機級系統，構建具有高冗余度民用飛機艙內壓力控制系統模型。

3.1 面向需求的全景視角（AV）模型建立

本步驟包括：獲取利益方需求集，梳理項目信息，記錄艙壓控制系統初步設計規劃方法、設計規范、決策準則等，可選地獲取以往系統相關設計經驗，整合建立AV-1設計綜述與信息概要模型、AV-UAF民機設計體系交互概要模型。

艙壓控制系統設計綜述與信息概要模型示例如圖4所示。項目情況包圖是對艙壓控制系統設計的概述，目的包圖為艙壓控制系統設計提供了最初期望與利益方需求，范圍與場景包圖定義了艙壓控制系統的初始邊界與運行場景。系統資源包圖用于了解輔助設計人員進行設計決策的資源。

圖4 AV-1包視圖Fig.4 Package of AV-1

在AV-UAF視圖中，建立民用飛機艙壓控制系統交互的架構關系（St），捕獲民用飛機艙壓控制系統所有的交互單位，以捕獲與民機設計時交互的對象，在設計初期盡可能全面地捕獲利益相關方需要/需求，如圖5所示。民機設計中需要考慮到與外界環境存在的交互關系，在場景分析中需要轉化為需求進入設計迭代環節；后勤維護人員對民機設計的維護性、易檢性會產生關聯關系，可由此捕獲民機設計的非功能性需求；乘客對民機乘坐的舒適性、經濟性會提出合理的訴求，這也將被納入民機設計交互中；研發團隊、生產制造、供應商之間通常會產生關于民機設計的接口、易裝配程度、可加工性等方面的沖突交互。

圖5 艙壓控制系統體系內架構關系模型（St）Fig.5 Model of architecture relationship within cabin pressure control system （St）

眾多顯性的、潛在的基于場景的交互關系（Op）可以借助AV-UAF視圖進行迭代式的細化與完善，最終更加全面地開展民機正向設計的工程實踐活動。

其中以人為構成主體的交互單位即是系統設計的利益相關方，如圖6所示，一般包括機組成員、設計團隊、供應商、生產制造商、后勤維護人員（包括負責運營的航空公司）、乘客等。在利益相關方模型（Pr）視圖中，可以進一步明確可初步采集的利益方需求來源與具體對象，以便后續需求驗證時進行確認與反饋。AV-UAF通過與不同類別的利益相關方建立交互關系，從而盡可能完備地捕獲在不同場景下、不同利益相關方對民機設計提出的利益相關方需要/需求。

圖6 艙壓控制系統涉及的利益相關方模型（Pr）Fig.6 Stakeholder model involved in cabin pressure control system （Pr）

3.2 面向功能的能力視角（CV）模型建立

本步驟包括：將艙壓控制系統需求轉化為完成民機飛行任務的所需要的系統能力；將能力與相應需求進行關聯；驗證能力對全部需求的完整覆蓋；對主要能力進行結構分解，并分析子能力間的依賴關系。

CV-1能力愿景模型主要反映了艙壓控制系統的初步期望，需要通過全景視角中捕獲的艙壓控制系統需求，明確系統應有運行狀態與交互對象。其中運行狀態包含飛機運行階段，如起飛、爬升、巡航、下降、進近、停機，以及系統運行狀態，如正常狀態、應急狀態。艙壓控制系統交互對象主要是外界大氣、座艙環境、駕駛員。建立用例圖反映艙壓控制系統的CV-1能力愿景模型，如圖7所示。

圖7 CV-1艙壓控制系統能力愿景模型Fig.7 CV-1 vision of cabin pressure control system

在CV-1定義的能力愿景基礎上，對艙壓控制系統主要能力進行分解與梳理，將數據監控、數據處理與判斷、壓差調節、艙壓顯示與控制等4個能力劃分為12個子能力，建立的CV-2能力分級描述模型如圖8所示。

圖8 CV-2艙壓控制系統能力分級描述模型Fig.8 CV-2 capability taxonomy of cabin pressure control system

需要說明的是，某些能力會覆蓋多種運行場景。例如，無論在正常狀態還是應急狀態，艙壓控制能力均依靠作動機構調節壓差。能力與相應需求的對應關系，記錄在CV-2能力分級描述模型的各能力屬性中。

根據能力的分解邏輯，梳理出艙壓控制系統各能力之間的依賴關系，實例中建立的能力依賴關系模型如圖9所示。例如：作動機構調節壓差能力依賴于控制信號識別與控制執行能力；控制信號識別與控制執行能力依賴于參數計算與控制判斷能力、模式選擇能力、人工控制能力；參數計算與控制判斷能力需要獲取經過調理后的壓力信號與空地信號，并需要選擇相應的座艙壓力制度進行計算。

圖9 CV-4艙壓控制系統能力依賴關系模型Fig.9 CV-4 capability dependencies of cabin pressure control system

3.3 面向邏輯架構的運行視角（OV）模型建立

本步驟包括：艙壓控制系統能力概念到系統功能活動概念的轉化、追溯，功能活動流程中資源流的定義，全部系統功能執行流程的活動模型的設計。

艙壓控制系統的功能活動流程概念需要依據上述步驟中建立的需求概念與能力分級描述模型。以系統需求為主體，結合能力分解關系，分析艙壓控制系統的主要功能活動，并明確系統的主要運行場景，即包括起飛、爬升、巡航、下降、進近、停機6個正常飛行階段與自動控制故障時的應急狀態。

實例將艙壓控制活動視作由飛行信息檢測、增壓控制（正常與應急狀態）、艙壓顯示等子活動集成功能活動。繪制的OV-1艙壓控制系統高層運行概念圖如圖10所示。

圖10 OV-1艙壓控制系統高層運行概念圖Fig.10 OV-1 high level operational concept graphic of cabin pressure control system

OV-2艙壓控制系統活動資源流負責描述艙壓控制系統不同功能執行活動之間的資源流流向。在OV-1分解出的多項子活動基礎上，定義各個活動之間的資源交互情況。需要說明的是，應考慮子活動與其他系統（非艙壓控制系統）之間的資源流向與資源種類，定義系統范圍（Region）界定艙壓控制系統邊界。

實例中定義的OV-2艙壓控制系統活動資源流如圖11所示。艙內外壓力檢測會持續將采集到的大氣壓力與座艙壓力信息傳遞給增壓控制活動所需部件，然后將計算得出的增壓信號傳遞給作動機構，執行座艙增壓；座艙壓力信號同時傳遞給座艙顯示系統完成艙壓顯示活動，為駕駛員實時更新艙內外壓力情況并在應急狀態下發出警報，其中艙壓控制活動中需要的空地信號來源于通信系統。

圖11 OV-2艙壓控制系統活動資源流模型Fig.11 OV-2 operational resource flow description of cabin pressure control system

通過建立OV-5b運行活動模型、OV-6c事件追蹤描述模型、OV-6b運行狀態轉換模型來完成系統功能執行流程的活動模型的設計。OV-5b艙壓控制系統運行活動模型針對OV-1中提出的多種功能活動分別進行建模。

需要說明的是，運行活動模型OV-5b應覆蓋OV-1中定義的所有運行場景與運行狀態下的每一種功能活動。比如艙壓控制系統正常運行狀態下存在自動控制、人工控制2種活動流程，也應考慮不同階段控制活動模型存在的差異，以及自動控制失效情況下切換到備用模式或人工模式的活動流程等。

實例中，建立的巡航狀態下的艙壓系統自動控制活動模型如圖12所示，巡航狀態下艙壓控制活動首先測量大氣與座艙壓力，經過信號調理后與設定的壓力制度進行對比解算，判定是否滿足乘員需求，若不滿足，則發出驅動信號控制活門開閉，執行座艙壓力控制。

圖12 OV-5b艙壓控制系統運行活動模型Fig.12 OV-5b operational activity model of cabin pressure control system

根據相應的OV-5b運行活動模型，定義OV-6c艙壓控制系統事件追蹤描述模型，時序圖主要以活動之間的信息流動為節點，表明參與者與系統內部的活動順序，以及每一個活動執行的數據內容和流向。

圖13為巡航狀態下的艙壓自動控制模式下的OV-6c事件追蹤描述模型：環境信息檢測活動貫穿整個運行周期，增壓控制活動依次完成壓力信號調理、壓力制度比對與計算、發出作動信號等活動，最終控制活門開閉完成增壓控制。

圖13 OV-6c艙壓控制系統事件追蹤描述模型Fig.13 OV-6c event-trace description of cabin pressure control system

依據建立的艙壓控制系統OV-5b、OV-6c模型，分析形成艙壓控制系統的OV-6b狀態轉換描述模型，如圖14所示。艙壓控制系統在開機、待機狀態完成后，優先進入自動控制狀態，并同步實時執行系統狀態檢測，主自動控制系統失效后切換至備份自動控制系統，自動控制系統失效即轉入人工控制狀態，二者皆失效后觸發艙壓控制系統應急模式。圖14中正常運行狀態、應急狀態、自檢狀態定義為系統的復合狀態，即可在各狀態內部繼續定義系統子狀態。

圖14 OV-6b艙壓控制系統狀態轉換描述模型Fig.14 OV-6b state transition description of cabin pressure control system

3.4 面向物理架構的系統視角（SV）模型建立

本步驟包括：功能活動到系統具體部件的映射分析設計，功能活動到系統部件追蹤關系表示，艙壓控制系統接口信息建模，部件與不同系統交互關系分析。其中，功能活動到系統具體部件的映射由SV-4系統功能描述模型表示，該模型將系統主要活動分配到相應組件上。

需要說明的是，對于一個系統功能執行流程，可能會形成多個SV-4系統功能描述模型，即多種不同的設計方案，此時可以依據AV-1需求概要信息模型中定義的決策準則（也可以在需要時再行補充），經過設計部門組織討論后進行方案決策。

圖15所示為一個艙壓控制系統部件的整體架構組成：通過不同傳感器實時監視大氣與座艙壓力情況，利用數字控制器完成信號調理與控制解算、活門完成增壓控制，并在座艙顯示系統顯示艙壓信息與警報信號。

圖15 SV-4艙壓控制系統功能描述模型Fig.15 SV-4 systems functionality description of cabin pressure control system

對于已選定的SV-4系統功能描述模型，其可以存在多個視圖，表示系統的不同層次上部件的分解。在實例中，圖15建立的系統功能描述模型中可對活門中控制、執行組件進行進一步分解，如控制組件采用電動扭矩馬達、執行組件采用作動筒等。根據設計進程，不斷補充更多層面的SV-4視圖來完善更底層的設計方案。

在SV-4描述的部件架構基礎上，撰寫SV-1艙壓控制系統接口描述模型。SV-1不僅表示了信息內容及傳遞方向，而且明確了數據傳輸格式，如數字控制器以電流或電壓形式的電信號傳輸給活門控制組件，艙壓告警系統以燈光閃爍、蜂鳴警報提醒機組成員等，如圖16所示。

圖16 SV-1艙壓控制系統接口描述模型Fig.16 SV-1 systems interface description of cabin pressure control system

功能活動到系統部件追蹤關系使用SV-5活動-系統跟蹤矩陣，如表2所示。

表2 SV-5艙壓控制系統的活動-系統跟蹤矩陣Table 2 SV-5 operational activity to systems function traceability matrix of cabin pressure control system

同時，定義的各組件并不一定僅參與到座艙壓力控制系統中，SV-3系統-部件跟蹤矩陣在一定程度上描述了艙壓控制系統內部組件參與到其他各系統的情況，例如大氣、艙內壓力等傳感器屬于飛行環境監視系統，同時會將監測信息傳遞給飛行管理系統等完成其他民機系統功能。在民機整體設計中，結合其他相應系統的系統模型，對各組件應實現的功能及民機整體架構有更全面的刻畫，艙壓控制系統的SV-3系統-部件跟蹤矩陣如表3所示。

表3 SV-3艙壓控制系統的系統-部件跟蹤矩陣Table 3 SV-3 systems-component tracking matrix of cabin pressure control system

需要說明的是，上述步驟并非純粹的線性步驟。在每一步建模過程中，均可依據該步的實現需要對之前步驟中建立的模型進行增添補充或修改，但是應建立系統基線來完成版本控制，留存變更的歷史記錄與歷史系統模型。

4 結論

首先，對比分析了MBSE方法論的架構特點，考慮了現代民機設計中以需求為驅動、關聯眾多利益相關方的正向設計趨勢，提出了MBSE方法論指導下的民機正向設計流程，建立起“需求-功能-邏輯架構-物理架構”的映射和關聯關系。然后，考慮到民機系統在對內對外復雜交互設計體系下各級系統的交錯耦合，引入了DoDAF、UAF的多視角，對民機設計過程進行了更為全面的描述，從全景、能力、運行、系統視角等視角深入剖析了各視角下模型構建所需的構成要素和邏輯關系，以抽象建模的方式，總結歸納了各設計階段所建立模型的構建方式和信息交互關系。最后，以民用飛機座艙壓力控制系統為實例，采用SysML為建模語言進行建模，無歧義地將每個設計階段中各視角下的民機系統模型進行描述，以驗證提出的建模方法。驗證結果表明：

1） 利益相關方需要/需求信息能夠通過民機設計體系交互概要模型反映需求來源、架構、交互信息，并將需求信息映射到后續功能研發設計中并建立已開發功能與需求的鏈接關系。

2） 全景、能力、運行、系統4個視角能夠有效建立起對自頂向下、需求驅動的民機正向設計流程的立體描述，更全面地考慮民機正向設計下的對內對外交互情況。

3） 抽象的建模流程詳細定義了各模型構建的構成要素和邏輯關系，能夠實現民機系統功能與接口需要的無二義性描述。

本文提出的基于多視角的民機正向設計建模方法面向民機系統研發，清晰描述了民機系統詳細建模流程，能夠有效指導設計人員進行模型構建，契合民機的設計開發工作。