張玉金，黃 博，廖文和

(1.南京航空航天大學(xué) 機(jī)電學(xué)院，江蘇 南京 210016；2.西北工業(yè)大學(xué) 機(jī)電學(xué)院，陜西 西安 710072;3.中國航發(fā)商用航空發(fā)動機(jī)有限責(zé)任公司，上海 200241)

0 引言

航空發(fā)動機(jī)體現(xiàn)了一個國家的工業(yè)基礎(chǔ)和科技水平，被譽為現(xiàn)代工業(yè)“皇冠上的明珠”。作為重要的應(yīng)用領(lǐng)域，商用航空發(fā)動機(jī)全球年產(chǎn)量超過5 600臺，年總產(chǎn)值超過360億美元，具有廣闊的市場前景和市場價值。然而，由于商用航空發(fā)動機(jī)為典型的復(fù)雜系統(tǒng)，具有產(chǎn)品復(fù)雜性高、研發(fā)成本高昂、研發(fā)周期長等特點，迫切需要研究高效的研發(fā)模式，以提高其研發(fā)過程的集成化和協(xié)同化[1]。為此，國際先進(jìn)航空航天國防企業(yè)提出基于模型的系統(tǒng)工程(Model Based System Engineering, MBSE)方法。該方法采用結(jié)構(gòu)化模型和語言，實現(xiàn)了“需求—功能—邏輯—物理”設(shè)計和驗證過程的貫通。與傳統(tǒng)的基于文檔的系統(tǒng)工程相比，MBSE突破了文件的自然語言描述歧義性、文件傳遞的靜態(tài)非結(jié)構(gòu)性等限制，促進(jìn)了集成化研發(fā)模式的發(fā)展[2-3]。

Harmony-SE是IBM公司推出的一套MBSE方法論，在航空航天、汽車、醫(yī)療行業(yè)經(jīng)過一定試點,其流程和建模工具也被認(rèn)為具備一定的實踐可行性。中國航空工業(yè)集團(tuán)為持續(xù)提升航空產(chǎn)品的研發(fā)能力和水平，以適應(yīng)航空型號工程數(shù)字化和管理信息化的發(fā)展趨勢，于2013年引入Harmony-SE方法論，先后在40多家單位開展了MBSE試點應(yīng)用，在飛機(jī)整機(jī)、航電、飛控、慣導(dǎo)、地面站、機(jī)電等多個領(lǐng)域開展了應(yīng)用研究，逐步探索出一條適合航空產(chǎn)品研制MBSE應(yīng)用的路線[4]。IBM公司的Harmony-SE方法采用支持模型驅(qū)動開發(fā)的增量迭代式周期活動流，經(jīng)過需求分析、系統(tǒng)功能分析、系統(tǒng)設(shè)計綜合3個階段協(xié)同開發(fā)，能夠較好地適用于機(jī)載軟件的開發(fā)設(shè)計。然而經(jīng)過探索實踐證明，在航空發(fā)動機(jī)整機(jī)級和系統(tǒng)級設(shè)計方面，Harmony-SE方法仍存在以下局限性：

(1)在需求分析階段，系統(tǒng)用例的抽取方法存在模糊性，而后續(xù)工作的開展都基于系統(tǒng)用例，用例選取的完整性和顆粒度直接影響功能分析和設(shè)計綜合的全面準(zhǔn)確性。

(2)在功能分析階段，缺乏明確的功能分層分解方法，而且功能層級不明確，無法生成適航要求以及支撐系統(tǒng)安全性分析的功能層級圖(functional hierarchy)。

(3)在設(shè)計綜合階段，架構(gòu)分析過程的候選方案效能評估依賴大量的仿真和計算分析；架構(gòu)權(quán)衡與備選方案效能評估部分的模型和數(shù)據(jù)與前期功能分析過程模型和數(shù)據(jù)脫節(jié)，造成架構(gòu)權(quán)衡工作與SysML建模過程脫節(jié)，使設(shè)計過程不可回溯。

另外，遵循適航要求，商用航空發(fā)動機(jī)研發(fā)必須從預(yù)期的運行場景出發(fā)，針對不同場景下的運行要求和使用限制進(jìn)行合理的功能性能設(shè)計，保證系統(tǒng)預(yù)期的行為皆在可接受的安全范圍之內(nèi)[5]。因此，為解決將Harmony-SE方法運用于商用航空發(fā)動機(jī)研發(fā)存在的問題，需要結(jié)合商用航空發(fā)動機(jī)型號設(shè)計的實踐需求，以及適航當(dāng)局對設(shè)計過程追溯性、發(fā)動機(jī)產(chǎn)品適用場景完備性等要求。為此，本文提出一種面向運行場景的商用航空發(fā)動機(jī)MBSE設(shè)計方法，實現(xiàn)了從航空發(fā)動機(jī)全生命周期運行場景出發(fā)，進(jìn)行需求捕獲、功能分析、邏輯架構(gòu)定義和物理設(shè)計的完整MBSE過程，同時采用基于可擴(kuò)展標(biāo)記語言(eXtensible Markup Language，XML)的元數(shù)據(jù)交換格式，打通基于SysML的功能邏輯模型和基于Modelica的物理性能模型，實現(xiàn)模型傳遞和設(shè)計過程數(shù)據(jù)的可追溯性。

1 面向運行場景的商用航空發(fā)動機(jī)MBSE設(shè)計方法

1.1 商用航空發(fā)動機(jī)設(shè)計過程的適航要求

適航的定義和內(nèi)涵指出，民用航空產(chǎn)品研發(fā)必須遵循系統(tǒng)工程的方法，識別復(fù)雜產(chǎn)品在各類運行場景下需提供的能力，即保證問題域的完整性和正確性[5]；另外，《民用飛機(jī)及系統(tǒng)研發(fā)指南》(編號SAE ARP 4754，當(dāng)前版本A)在分析全球航空產(chǎn)品研發(fā)最佳實踐的基礎(chǔ)上，提出“概念—功能—架構(gòu)—設(shè)計—實現(xiàn)”研發(fā)生命周期模型，強(qiáng)調(diào)功能分析和架構(gòu)定義正向設(shè)計過程的重要性。航空發(fā)動機(jī)作為典型復(fù)雜系統(tǒng)，一方面，其運行的外界環(huán)境具有多樣性和多變性，會導(dǎo)致系統(tǒng)在非預(yù)期的運行環(huán)境中出現(xiàn)混沌的行為模式，進(jìn)而產(chǎn)生無周期、非規(guī)律和難以預(yù)知的系統(tǒng)失效模式[6]；另一方面，發(fā)動機(jī)產(chǎn)品全生命周期運行場景識別不全導(dǎo)致產(chǎn)品設(shè)計階段缺失關(guān)鍵需求，例如未充分考慮產(chǎn)品的維修性、通用性、成本控制等因素，導(dǎo)致喪失發(fā)動機(jī)產(chǎn)品的市場競爭力。

因此，商用航空發(fā)動機(jī)研發(fā)需要面向發(fā)動機(jī)全生命周期的運行場景，正向定義復(fù)雜航空產(chǎn)品架構(gòu)，保證航空發(fā)動機(jī)產(chǎn)品的高可靠性和安全性。建立從場景建模到“需求—功能—架構(gòu)”建模，規(guī)范地應(yīng)用建模(及仿真)支持“運行場景—系統(tǒng)需求—設(shè)計—分析—驗證與確認(rèn)活動”的復(fù)雜航空產(chǎn)品設(shè)計鏈的高效協(xié)同，保證模型和數(shù)據(jù)持續(xù)貫穿整個產(chǎn)品研發(fā)階段和后續(xù)生命周期階段。

1.2 面向運行場景的商用航空發(fā)動機(jī)MBSE設(shè)計流程

基于適航要求，結(jié)合型號研制的實踐經(jīng)驗，本節(jié)在對Harmony-SE流程進(jìn)行細(xì)化和完善的基礎(chǔ)上，提出一種面向運行場景的MBSE(Scenario Oriented-MBSE，OS-MBSE)商用航空發(fā)動機(jī)設(shè)計流程，能夠滿足工程研制的要求。OS-MBSE設(shè)計流程如圖1所示，主要包括8個關(guān)鍵技術(shù)環(huán)節(jié)：①定義運行場景；②識別用例，建立與場景的關(guān)聯(lián)；③分析用例場景，提取頂層功能和外部接口；④確認(rèn)并分解功能，建立功能層級；⑤定義功能邏輯流和對象流，建立功能邏輯；⑥將功能分配給邏輯實體，建立系統(tǒng)邏輯架構(gòu)；⑦定義系統(tǒng)接口和接口要求；⑧基于系統(tǒng)邏輯架構(gòu)，開展物理性能建模和仿真驗證評估。下面詳細(xì)闡述OS-MBSE設(shè)計流程的主要實施流程及其與傳統(tǒng)Harmony-SE相比所具有的優(yōu)勢。

1.2.1 OS-MBSE設(shè)計流程的主要實施流程

(1)運行場景定義 航空發(fā)動機(jī)運行場景指人員行為、飛行階段、內(nèi)外部環(huán)境(著火、大氣、地形、電磁等)和發(fā)動機(jī)內(nèi)部狀態(tài)的組合，具有多維度耦合性[7]。因此，本文從生命周期運營階段、發(fā)動機(jī)狀態(tài)模式和內(nèi)外部環(huán)境3個維度定義完整的運行場景，如圖2所示。通過3個維度組合，可以識別2 000多個商用航空發(fā)動機(jī)運行場景，每個運行場景相應(yīng)地定義一個系統(tǒng)用例，從而有效保證用例定義的完整性。

(2)分析用例場景 指站在用戶的視角，針對某個運行場景提出對系統(tǒng)頂層的能力(服務(wù))要求。場景主要包括以下活動：①場景時序分析，將被設(shè)計系統(tǒng)作為一個整體(黑盒)，通過時序圖分析某個場景的典型運行過程；②與外部系統(tǒng)交互分析，基于時序圖識別出被設(shè)計系統(tǒng)的外部接口系統(tǒng)(黑盒內(nèi)部塊圖(Internal Block Diagram，IBD))；③定義系統(tǒng)頂層功能需求和功能接口，通過時序圖中的外部接口輸入輸出關(guān)系和系統(tǒng)內(nèi)的運行過程識別系統(tǒng)頂層功能。通過全面的場景分析可以確保系統(tǒng)頂層功能識別的完整性。

(3)功能分析 功能分析是針對用例場景得到的系統(tǒng)頂層功能，通過活動圖對每個頂層功能進(jìn)行功能分析，得到下一層級的功能以及功能之間的邏輯關(guān)系；在此基礎(chǔ)上，采用塊定義圖(Block Definition Diagram，BDD)描述功能分層分級的關(guān)系，形成功能層級架構(gòu)(functional hierarchy)。

(4)系統(tǒng)邏輯架構(gòu)模型構(gòu)建 在系統(tǒng)功能分析的基礎(chǔ)上，通過劃分泳道將功能分配給系統(tǒng)元素或邏輯實體，構(gòu)建系統(tǒng)的邏輯架構(gòu)模型。該模型利用SysML模型中的塊定義圖和內(nèi)部塊圖展示航空發(fā)動機(jī)各系統(tǒng)、部件的架構(gòu)信息，以及與其他使能系統(tǒng)的關(guān)系和接口，準(zhǔn)確描述系統(tǒng)功能和狀態(tài)所涉及的子系統(tǒng)內(nèi)部以及子系統(tǒng)間的關(guān)系。

(5)系統(tǒng)架構(gòu)分析 指在綜合考慮成本、性能、安全性、可靠性等諸多因素的基礎(chǔ)上，權(quán)衡多種方案并獲取最優(yōu)方案的過程。在權(quán)衡分析商用航空發(fā)動機(jī)設(shè)計方案時，需要考慮推力、耗油量、發(fā)動機(jī)重量和計劃成本等關(guān)鍵影響因素，從可選系統(tǒng)設(shè)計方案中篩選出最佳方案。為解決基于SysML的功能邏輯架構(gòu)只能通過模型表達(dá)系統(tǒng)的功能和行為，無法支持對系統(tǒng)性能、可靠性、安全性等量化的參數(shù)特性進(jìn)行分析的缺陷，OS-MBSE設(shè)計流程的架構(gòu)權(quán)衡分析過程在依托物理性能模型的基礎(chǔ)上，采用基于XML的元數(shù)據(jù)中間交換技術(shù)，構(gòu)建邏輯模型和物理模型之間的轉(zhuǎn)換方法，并建立基于統(tǒng)一架構(gòu)的建模和仿真驗證過程，實現(xiàn)架構(gòu)權(quán)衡分析過程數(shù)據(jù)和架構(gòu)設(shè)計結(jié)果的可追溯性。在架構(gòu)權(quán)衡分析過程中，物理性能模型仿真分析可以評估系統(tǒng)邏輯架構(gòu)的合理性和對需求的滿足度，而且航空發(fā)動機(jī)的系統(tǒng)功能/邏輯架構(gòu)和物理架構(gòu)的設(shè)計是不斷迭代和逐步分解的過程。系統(tǒng)邏輯架構(gòu)模型與物理性能模型的關(guān)系如圖3所示。

1.2.2 OS-MBSE設(shè)計流程的優(yōu)勢

OS-MBSE設(shè)計流程在用例定義、功能分析和系統(tǒng)架構(gòu)分析3個方面對Harmony-SE設(shè)計流程進(jìn)行了改進(jìn)，使其更適用于航空發(fā)動機(jī)研發(fā)。兩種設(shè)計流程的比較如表1所示。

表1 OS-MBSE設(shè)計流程與Harmony-SE的比較

續(xù)表1

1.3 基于XML的統(tǒng)一建模技術(shù)

在OS-MBSE設(shè)計流程的架構(gòu)分析階段，將功能分配給系統(tǒng)元素構(gòu)建系統(tǒng)邏輯架構(gòu)后，采用白盒內(nèi)部塊圖(IBD)建模。為了在物理性能設(shè)計中基于同一架構(gòu)開展建模(文中物理性能模型基于Modelica語言)，必須將SysML的系統(tǒng)邏輯架構(gòu)模型(內(nèi)部塊圖)轉(zhuǎn)換為Modelica物理性能架構(gòu)模型，本文采用XML元數(shù)據(jù)交換(XML-based Metadata Interchange，XMI)標(biāo)準(zhǔn)規(guī)范進(jìn)行模型轉(zhuǎn)換。目前主流的SysML建模工具Rhapsody,Enterprise Architech,MagicDraw等均支持XMI的導(dǎo)入導(dǎo)出接口，因此不用具體的建模工具，僅依賴XMI標(biāo)準(zhǔn)規(guī)范即可滿足主流SysML模型工具的轉(zhuǎn)換需求。

XMI采用標(biāo)準(zhǔn)化的文檔格式，并基于文檔類型定義(Document Type Definition，DTD)或XML大綱定義(XML Schema Definition，XSD)為統(tǒng)一建模語言(Unified Modeling Language，UML)元模型和其他模型定義了一種基于XML的數(shù)據(jù)交換格式。XMI中SysML模型部分的層級關(guān)系為XMI→Model→packageElment(可嵌套)→Property，Port，Connector，其他元數(shù)據(jù)引用SysML標(biāo)準(zhǔn)庫中的元數(shù)據(jù)描述和工具擴(kuò)展數(shù)據(jù)，模型轉(zhuǎn)換所需要的數(shù)據(jù)(模型組成及結(jié)構(gòu)、各類圖)均在Model中存儲。將SysML系統(tǒng)邏輯架構(gòu)模型轉(zhuǎn)換為Modelica物理架構(gòu)模型主要包括以下兩項關(guān)鍵技術(shù)：

(1)基于XMI對象映射的仿真模型框架生成技術(shù)

SysML設(shè)計模型在XMI文件中采用Model，packagement，ownedAttribute，ownedConnector，End等元素以及各元素對象間的組織關(guān)系描述模型的組織關(guān)系、Block、端口、IBD等對象，仿真模型則采用Modelica語法規(guī)則描述其參數(shù)、接口、內(nèi)嵌對象、方程等對象，因此將XMI表達(dá)的SysML模型轉(zhuǎn)換為Modelica仿真模型時，建立XMI元素對象和Modelica元素對象的對應(yīng)關(guān)系是實現(xiàn)模型轉(zhuǎn)換的關(guān)鍵技術(shù)。結(jié)合XMI模型元素的表達(dá)和組織關(guān)系以及Modelica語法語義，定義如圖4所示的兩者模型元素的對應(yīng)關(guān)系。

基于上述元素的對應(yīng)關(guān)系，按照Modelica語法依次提取XMI模型(class)信息生成對應(yīng)的仿真模型，并建立兩者模型之間的映射關(guān)系，在此基礎(chǔ)上提取IBD模型的內(nèi)嵌對象、接口、連接關(guān)系信息等，分別實例化生成對應(yīng)的系統(tǒng)仿真模型框架，如圖5所示。

(2)基于交互式的原理模型封裝技術(shù)

將SysML模型基于映射方式轉(zhuǎn)換成Modelica系統(tǒng)性能模型框架后，需要進(jìn)一步細(xì)化性能模型，包括各類接口定義、零組件模型參數(shù)定義等，然后才能進(jìn)行動態(tài)仿真驗證，而且XMI文件缺乏對布局信息的描述，生成系統(tǒng)模型的布局與原有模型布局不對稱。因此，如何使SysML模型到Modelica模型的轉(zhuǎn)換過程滿足布局和可驗證要求是第二項關(guān)鍵技術(shù)。

針對SysML模型轉(zhuǎn)換生成的Modelica系統(tǒng)仿真模型不可用于仿真驗證的問題，在抽象Modelica模型表達(dá)規(guī)則的基礎(chǔ)上，采用人工交互方式將模型框架封裝成可運行的模型原理，并建立原理和外部接口的連接關(guān)系，從而在保證架構(gòu)關(guān)系不變的同時填充模型的內(nèi)部邏輯，使整個系統(tǒng)仿真模型生成后即可進(jìn)行仿真驗證；針對XMI文件缺少對象布局描述信息的問題，采用交互方式指定接口、內(nèi)嵌對象、連接關(guān)系等布局信息，在生成模型的過程中將布局信息附于相關(guān)對象，即可實現(xiàn)轉(zhuǎn)換后模型的對稱布局。

1.4 基于模型的需求閉環(huán)驗證

在復(fù)雜系統(tǒng)的開發(fā)過程中，驗證用于保障各級系統(tǒng)和部件的功能與性能滿足指標(biāo)。因此在完成系統(tǒng)功能邏輯架構(gòu)設(shè)計和物理建模后，需要針對各運行場景下利益攸關(guān)方的需求開展仿真驗證。虛擬驗證與確認(rèn)是縮短研制周期、降低研制成本的有效手段，因此商用航空發(fā)動機(jī)MBSE設(shè)計方法不僅包括需求驅(qū)動的設(shè)計流程，還包括需求閉環(huán)驗證的流程，如圖6所示。

在虛擬仿真閉環(huán)測試階段，根據(jù)需求定制仿真測試的業(yè)務(wù)流程。虛擬測試與驗證流程包括定義需求驗證方法、驗證測試工況及測試執(zhí)行目標(biāo)、創(chuàng)建測試執(zhí)行、定義工作流及任務(wù)分配、指定實例化模板及執(zhí)行仿真流程、工作流程審查、完成工作流程、完成最終的評審和處理，通過該流程對商用航空發(fā)動機(jī)研制需求進(jìn)行閉環(huán)驗證。

2 應(yīng)用實例分析

本章以某型號大涵道比渦扇商用航空發(fā)動機(jī)地面起動這一典型場景為分析對象，對所提OS-MBSE設(shè)計流程的實施過程進(jìn)行實例分析，以驗證所提設(shè)計流程的有效性和可行性。主要驗證的設(shè)計流程包括需求建模、功能分析、邏輯架構(gòu)建模、性能建模和系統(tǒng)聯(lián)合仿真驗證5部分。最后分析商用航空發(fā)動機(jī)MBSE設(shè)計方法在某型號大涵道比渦扇商用航空發(fā)動機(jī)研發(fā)設(shè)計過程的應(yīng)用效果，表明所提方法可以促進(jìn)航空發(fā)動機(jī)“預(yù)測式”研發(fā)模式的創(chuàng)新發(fā)展。

2.1 需求建模

在地面起動場景下，發(fā)動機(jī)主要與飛機(jī)系統(tǒng)、飛行員(間接)和外部大氣環(huán)境產(chǎn)生輸入、輸出的交互關(guān)系(上述交互對象是發(fā)動機(jī)在該場景下的利益攸關(guān)方)，然后采用用例圖識別在該場景下的發(fā)動機(jī)外部交互對象，并定義其系統(tǒng)邊界，如圖7所示。

首先，從飛機(jī)制造方輸入的頂層需求中識別飛機(jī)對發(fā)動機(jī)在該場景下的功能、性能、接口、環(huán)境等不同類型的需求；其次，捕獲適航、國際標(biāo)準(zhǔn)等對發(fā)動機(jī)在地面起動的相關(guān)需求，形成第一輪的利益攸關(guān)方需求，如表2所示。

表2 航空發(fā)動機(jī)地面運行需求

根據(jù)利益攸關(guān)方需求建立發(fā)動機(jī)地面起動場景時序圖，基于時序圖定義發(fā)動機(jī)起動過程以及飛機(jī)、大氣環(huán)境之間的詳細(xì)交互關(guān)系與交互時序。首先，飛機(jī)給發(fā)動機(jī)提供上電信號，發(fā)動機(jī)進(jìn)行上電自檢測并將其狀態(tài)反饋給飛機(jī)，自檢測通過后，接收來自飛機(jī)的下一步指令，包括發(fā)動機(jī)起動按鈕、油門桿角度、其他傳感器信號(如大氣狀態(tài)、輪載信號等)；然后，發(fā)動機(jī)確定其起動模式，打開起動空氣閥門接收來自飛機(jī)的壓縮空氣，帶轉(zhuǎn)渦輪進(jìn)而帶動發(fā)動機(jī)轉(zhuǎn)動；完成發(fā)動機(jī)供油點火后，發(fā)動機(jī)轉(zhuǎn)速達(dá)到地面慢車并穩(wěn)定運行，退出地面起動場景。

通過時序圖可以清晰地識別發(fā)動機(jī)的外部交互對象，并分析識別外部接口和參數(shù)，模型的執(zhí)行過程可以驗證相關(guān)邏輯是否自洽。如圖8所示，在基于時序圖識別出地面起動場景下，發(fā)動機(jī)與飛機(jī)的電氣接口、機(jī)械接口和電源接口形成發(fā)動機(jī)整體(黑盒)與飛機(jī)系統(tǒng)之間的功能邏輯架構(gòu)(內(nèi)部塊圖)，基于XMI標(biāo)準(zhǔn)將該架構(gòu)轉(zhuǎn)換為系統(tǒng)性能架構(gòu)，就可以進(jìn)一步開展詳細(xì)的性能建模。內(nèi)部塊圖中可以定義詳細(xì)的接口參數(shù)類型和閾值范圍，例如飛機(jī)電源給發(fā)動機(jī)提供28 V直流電和115 V三相交流電。

另一方面，通過時序圖可以分析發(fā)動機(jī)在各種場景中的功能性需求，包括外部接口功能和系統(tǒng)內(nèi)部的頂層功能等。如圖9所示，時序圖中將發(fā)動機(jī)作為黑盒，可以識別出發(fā)動機(jī)在地面起動場景下需要具備接收飛機(jī)信號(IBD圖中可以定義詳細(xì)信號類型)、飛機(jī)供電等接口功能，還要具備自檢測、確定起動模式、起動發(fā)動機(jī)等頂層功能。

通過以上過程完成需求建模，并建立需求與模型間的追溯關(guān)系，保障從需求到設(shè)計再到測試階段的活動不失真。為了實現(xiàn)需求追溯及驗證，可以在研制平臺的需求管理模塊中為需求條目創(chuàng)建相關(guān)視圖，并增加驗證方法、驗證結(jié)果、實現(xiàn)期限等屬性，同時為需求條目與SysML模型中的用例圖建立關(guān)聯(lián)和追溯。

2.2 功能分析

針對需求建模過程中通過時序圖已經(jīng)識別的發(fā)動機(jī)頂層功能，采用活動圖進(jìn)行功能分解，詳細(xì)描述系統(tǒng)執(zhí)行功能的過程流程，如圖10所示。在活動圖中，進(jìn)一步將起動功能分解為起動機(jī)帶轉(zhuǎn)、點火、燃油計量、燃油分配、壓縮氣體分配等功能，然后采用行為事件(action)表示上述功能，采用對象流描述功能之間的關(guān)系，同時采用數(shù)值類型(valuetype)詳細(xì)定義活動圖的對象流中詳細(xì)的交互對象，最終形成發(fā)動機(jī)功能分解和功能架構(gòu)的基本結(jié)構(gòu)。

2.3 邏輯架構(gòu)建模

功能模型確定系統(tǒng)的行為，反映系統(tǒng)內(nèi)在行為邏輯如何實現(xiàn)利益攸關(guān)方對系統(tǒng)能力的要求。然而在系統(tǒng)架構(gòu)設(shè)計過程中，系統(tǒng)功能的實現(xiàn)需要具體的物理部件來承載，因此通過泳道劃分來分配起動功能活動圖中不同子功能的功能邏輯，如圖11所示。不同的分配方式為不同的架構(gòu)設(shè)計方案，系統(tǒng)工程師可以通過基于系統(tǒng)性能模型的仿真手段開展系統(tǒng)架構(gòu)權(quán)衡分析，綜合評估系統(tǒng)性能指標(biāo)、可靠性、安全性、成本、開發(fā)周期風(fēng)險、重量等方面的量化指標(biāo)，進(jìn)而獲取最優(yōu)架構(gòu)方案。在完成功能分配后，可以采用IBD圖詳細(xì)定義系統(tǒng)的內(nèi)部架構(gòu)，如定義內(nèi)部各邏輯實體之間的接口，如圖12所示。

2.4 性能建模

完成功能邏輯架構(gòu)設(shè)計后，需要進(jìn)一步進(jìn)行性能建模，開展性能分析評估。SysML語言僅支持系統(tǒng)的功能行為建模，無法對系統(tǒng)性能進(jìn)行仿真，因此需要基于Modelica語言進(jìn)行性能建模，支持氣、電、液等多個專業(yè)的建模和仿真。本文基于XMI格式將SysML模型中的系統(tǒng)邏輯架構(gòu)模型映射為性能架構(gòu)模型，在物理性能架構(gòu)中針對每個系統(tǒng)元素進(jìn)行性能建模和聯(lián)合仿真，從而驗證系統(tǒng)架構(gòu)設(shè)計的合理性和正確性。如圖13所示，圖中左上方的內(nèi)部塊圖是發(fā)動機(jī)為黑盒時建立的發(fā)動機(jī)和飛機(jī)系統(tǒng)等外部接口的功能架構(gòu)，左下方是發(fā)動機(jī)進(jìn)行架構(gòu)定義后的內(nèi)部功能架構(gòu)，右側(cè)分別是在性能樣機(jī)環(huán)境下開展的性能邏輯架構(gòu)，設(shè)計人員可以在性能架構(gòu)基礎(chǔ)上對接口和部件內(nèi)部進(jìn)行詳細(xì)的性能建模。

2.5 系統(tǒng)聯(lián)合仿真驗證

基于邏輯架構(gòu)完成航空發(fā)動機(jī)的控制系統(tǒng)、燃油系統(tǒng)、滑油系統(tǒng)、控制系統(tǒng)和本體模型的性能建模后，開展整機(jī)聯(lián)合仿真以及飛機(jī)模型在各場景下的飛機(jī)—發(fā)動機(jī)聯(lián)合仿真。

根據(jù)利益攸關(guān)方需求，對地面起動場景進(jìn)行仿真驗證。在仿真驗證中設(shè)置不同測試用例，即在不同測試工況下設(shè)置不同的仿真輸入條件，以驗證系統(tǒng)設(shè)計是否滿足需求。最后通過仿真結(jié)果驗證發(fā)動機(jī)起動邏輯和性能的正確性，需求驗證過程如圖14所示。

2.6 應(yīng)用效果

應(yīng)用本文提出的商用航空發(fā)動機(jī)MBSE設(shè)計方法，取得了以下5方面預(yù)期效果：

(1)產(chǎn)品需求質(zhì)量提升 通過MBSE方法捕獲航空發(fā)動機(jī)生命周期超過2 000個運動場景，對不同場景下不同利益攸關(guān)方的需求進(jìn)行了分析和建模，以確保復(fù)雜系統(tǒng)的需求完整性，并且通過運行模型對功能邏輯進(jìn)行驗證，以確保復(fù)雜系統(tǒng)中功能設(shè)計的合理性和接口定義的完整性；以地面啟動場景為例，捕獲發(fā)動機(jī)整機(jī)級需求共52條，識別現(xiàn)有需求問題9項，建立用例圖、時序圖、活動圖、狀態(tài)機(jī)圖、塊定義圖和內(nèi)部塊圖等模型共18個，定義發(fā)動機(jī)級功能7項。在發(fā)動機(jī)起動場景的建模仿真驗證過程中，識別出9項需求問題，1項設(shè)計問題。

(2)設(shè)計活動規(guī)范化 通過信息技術(shù)手段約束與規(guī)范設(shè)計流程引導(dǎo)和驅(qū)動整個設(shè)計過程，實現(xiàn)了設(shè)計流程的統(tǒng)一建模和監(jiān)控，在此基礎(chǔ)上對設(shè)計流程進(jìn)行優(yōu)化，實現(xiàn)了產(chǎn)品設(shè)計研發(fā)流程的可視化執(zhí)行和管理，保證設(shè)計過程規(guī)范有序。

(3)設(shè)計數(shù)據(jù)可追溯 相比于基于Harmony-SE方法的航空發(fā)動機(jī)設(shè)計過程，本文提出的統(tǒng)一建模方法可以對不同階段產(chǎn)生的設(shè)計數(shù)據(jù)和模型進(jìn)行結(jié)構(gòu)化管理，實現(xiàn)對數(shù)據(jù)的生命周期管理和有效追溯，從而復(fù)現(xiàn)設(shè)計過程，并重復(fù)利用歷史方案。

(4)設(shè)計過程知識化 對設(shè)計研發(fā)的流程、方法、模型進(jìn)行了固化，從而能夠不斷積累和重用設(shè)計過程的模型和數(shù)據(jù)，持續(xù)增強(qiáng)設(shè)計過程的知識儲備，提高研發(fā)競爭力。

(5)設(shè)計效率高效化 通過規(guī)范化、結(jié)構(gòu)化的模型大大降低文字帶來的理解困難和歧義，降低了人為出錯的可能性，顯著提升了設(shè)計效率。

綜上所述，面向運行場景的建模關(guān)注捕獲復(fù)雜產(chǎn)品研制早期階段的需求；MBSE方法關(guān)注復(fù)雜產(chǎn)品研制早期階段的需求分析與管理，以及系統(tǒng)功能分析和系統(tǒng)設(shè)計綜合，通過應(yīng)用XMI轉(zhuǎn)換模型實現(xiàn)定性與定量的基于同一架構(gòu)統(tǒng)一建模，以及系統(tǒng)的最優(yōu)設(shè)計和最優(yōu)管理，達(dá)到對系統(tǒng)復(fù)雜性的提前識別、仿真、驗證，推進(jìn)航空發(fā)動機(jī)從“仿制式”研發(fā)向“預(yù)測式”研發(fā)轉(zhuǎn)型。

3 結(jié)束語

本文研究了面向運行場景的商用航空發(fā)動機(jī)MBSE設(shè)計方法，主要貢獻(xiàn)如下：①提出商用航空發(fā)動機(jī)基于MBSE系統(tǒng)的設(shè)計流程，面向航空發(fā)動機(jī)生命周期的運行場景開展功能分析和架構(gòu)設(shè)計，確保系統(tǒng)需求捕獲的完整性；②基于XML的元數(shù)據(jù)中間轉(zhuǎn)換技術(shù)，實現(xiàn)從系統(tǒng)功能邏輯架構(gòu)到物理性能模型的貫通，將需求、功能、系統(tǒng)架構(gòu)、物理設(shè)計等各層級信息通過系統(tǒng)模型進(jìn)行關(guān)聯(lián)，實現(xiàn)模型和數(shù)據(jù)的完整閉環(huán)傳遞；③構(gòu)建了基于MBSE的多專業(yè)聯(lián)合仿真環(huán)境，在不同運行場景下，針對利益攸關(guān)方需求進(jìn)行仿真驗證，實現(xiàn)商用航空發(fā)動機(jī)需求的閉合驗證；④通過實例應(yīng)用表明，本文所提方法能夠滿足商用航空發(fā)動機(jī)的設(shè)計研發(fā)需要，可以高效開展復(fù)雜系統(tǒng)設(shè)計，并提前識別設(shè)計問題，減少重復(fù)試驗。