基于MBSE的民機系統(tǒng)功能建模方法

王文浩, 畢文豪, 張 安, 范秋岑

(西北工業(yè)大學航空學院, 陜西 西安 710072)

0 引 言

民機研制是一個涉及多學科、多領(lǐng)域的高度集成復(fù)雜的系統(tǒng)工程[1]。傳統(tǒng)的民機研制都是基于文檔管理的,一方面由系統(tǒng)設(shè)計師人工鏈接設(shè)計成果與需求之間的關(guān)系,迭代開發(fā)周期長;另一方面,不同領(lǐng)域的設(shè)計人員從文檔中讀取信息很容易產(chǎn)生理解偏差,從而導(dǎo)致在設(shè)計過程中需要反復(fù)迭代修正,嚴重影響了復(fù)雜系統(tǒng)的開發(fā)效率[2-3]。

系統(tǒng)工程是一種自上而下的綜合、開發(fā)和運行的一個真實系統(tǒng)的迭代過程,以接近于最優(yōu)的方式滿足系統(tǒng)的全部需求[4]。系統(tǒng)工程革新的推動力來自克服已知缺陷和不利的需求,這些因素會對系統(tǒng)體系結(jié)構(gòu)設(shè)計產(chǎn)生不利影響。近年來,在需求牽引和模型化技術(shù)的推動下,基于模型的系統(tǒng)工程(model-based systems engineering, MBSE)應(yīng)運而生[5-6]。2007年國際系統(tǒng)工程學會在《系統(tǒng)工程遠景2020》中將MBSE定義為“支持以概念設(shè)計階段開始并持續(xù)貫穿開發(fā)和后期的生命周期階段的系統(tǒng)需求、設(shè)計、分析、驗證和確認活動的正規(guī)化建模應(yīng)用”,用于解決具有跨平臺、跨領(lǐng)域、高綜合性等特點的復(fù)雜系統(tǒng)開發(fā)中遇到的系統(tǒng)問題,并聯(lián)合對象管理組織(object management group, OMG)在統(tǒng)一建模語言(unified modeling language, UML)的基礎(chǔ)上開發(fā)了用于描述大型復(fù)雜系統(tǒng)的系統(tǒng)建模語言(system modeling language, SysML)可以支持民機系統(tǒng)全壽命周期內(nèi)的需求分析與管理、功能設(shè)計與分配、模型架構(gòu)與管理、系統(tǒng)建模與仿真以及測試評估與計劃管理工作[4-7]。

敏捷系統(tǒng)工程的意義在于控制系統(tǒng)和流程所展示出來的不可預(yù)見性、不確定性和變化的條件下能夠保持有效的運行。敏捷的價值主張是增量式的迭代和風險的管控,根據(jù)需求演進的可能成本進行權(quán)衡分析,并針對不同情形和變化做出適應(yīng)和響應(yīng),能夠在系統(tǒng)設(shè)計早期,推動持續(xù)的驗證和測試驅(qū)動的開發(fā),從而降低系統(tǒng)研發(fā)的風險[8-9]。本文引入MBSE理論和敏捷系統(tǒng)工程設(shè)計方法,研究敏捷系統(tǒng)工程框架下的民機MBSE設(shè)計方法,針對關(guān)鍵子系統(tǒng)用例展開基于場景的用例分析,采用循環(huán)迭代的方式構(gòu)建描述子系統(tǒng)行為的活動流和黑盒狀態(tài)機,并將需求與場景交互請求即功能相鏈接。

1 基于MBSE的民機系統(tǒng)研制流程

基于系統(tǒng)工程方法論和敏捷系統(tǒng)相關(guān)概念[5-10],構(gòu)建基于敏捷系統(tǒng)工程的民機系統(tǒng)研制流程,如圖1所示。首先開展運行分析,深入剖析民機市場運行與系統(tǒng)概念設(shè)計的內(nèi)在機理,然后將捕獲到的需求定義進行分析和管理,定義利益相關(guān)方需求。將其作為設(shè)計研發(fā)的目標與約束,進行利益相關(guān)方需求用例場景分析,提高利益相關(guān)方在系統(tǒng)設(shè)計早期的參與程度。在這一過程中,以文本需求和基于順序圖的場景來捕獲利益相關(guān)方需求,深入剖析需求與系統(tǒng)服務(wù)請求之間的鏈接關(guān)系,將需求聚集成相關(guān)集合,稱為用例,用以描述系統(tǒng)的運行能力。

圖1 基于敏捷系統(tǒng)工程的民機系統(tǒng)研制流程Fig.1 Civil aircraft system development process based on agile system engineering

通過反復(fù)迭代將更新后的需求與相應(yīng)的系統(tǒng)設(shè)計參數(shù)相結(jié)合,定義系統(tǒng)需求并展開用例場景分析,建立描述系統(tǒng)黑盒視圖的活動功能流和狀態(tài)機視圖。繼而開展系統(tǒng)架構(gòu)的分析與設(shè)計,將選取的系統(tǒng)架構(gòu)方案與相應(yīng)的跨學科和子系統(tǒng)接口轉(zhuǎn)交下游工程,通過反復(fù)迭代最終得到符合客戶需求的產(chǎn)品。

MBSE的核心是采用模型驅(qū)動的方式進行系統(tǒng)設(shè)計,對設(shè)計中每一階段的中間產(chǎn)出物進行統(tǒng)一的模型化管理,提供可追溯性的連接,保持數(shù)據(jù)在工作產(chǎn)品和工作活動間的一致性[5-6]。如圖2所示,在基于模型的系統(tǒng)研發(fā)過程中,系統(tǒng)模型的中間產(chǎn)出物主要由功能模型(一系列可執(zhí)行的狀態(tài)機和活動流)、架構(gòu)模型(系統(tǒng)及子系統(tǒng)模塊定義)、需求模型(用例場景)和參數(shù)模型(系統(tǒng)的設(shè)計約束)所構(gòu)成[4,11-12]。在正向設(shè)計和反向迭代的過程中,子系統(tǒng)模型的主要內(nèi)容也可以從這4個視角去描述。

圖2 MBSE設(shè)計中間產(chǎn)出物Fig.2 Intermediate output of MBSE design process

其中,功能模型是表達功能之間依賴關(guān)系的靜態(tài)描述和功能實現(xiàn)過程的動態(tài)模擬,從SysML語言規(guī)范出發(fā),通過分析各種模型元素的特點,構(gòu)建出可重用的SysML功能模型庫。需求模型則是以用例(以及相關(guān)案例敘述)的形式來代替?zhèn)鹘y(tǒng)基于文字的功能性描述,或者以SysML需求圖的形式來顯示系統(tǒng)需求和系統(tǒng)模型的依賴元素及追溯關(guān)系[13-14]。

值得注意的是,在利益相關(guān)方需求分析、系統(tǒng)需求分析和系統(tǒng)架構(gòu)階段,對于設(shè)計過程中需求演進的可能成本進行增量式的迭代更新,克服會對系統(tǒng)體系結(jié)構(gòu)產(chǎn)生不利影響的需求。同時,項目的風險控制、研發(fā)的過程管理、需求與模型的變更管理和基線管理等將貫穿系統(tǒng)的整個開發(fā)過程。

2 基于場景的功能建模方法研究

作為民機系統(tǒng)研發(fā)的關(guān)鍵任務(wù),功能建模[15-18]是建立技術(shù)系統(tǒng)功能模型的設(shè)計活動。1969年Simon在《人工科學》雜志中提出系統(tǒng)具有內(nèi)部和外部環(huán)境,而功能則視為是內(nèi)部環(huán)境的抽象,位于內(nèi)部和外部環(huán)境的接口處[19]。1998年Chakrabarti提出了行為和目的兩種函數(shù)視圖,將功能視為滿足目的所做的行為,并提出了本體論的目的論建模。2007年Gero建立功能-行為-結(jié)構(gòu)(function-behavior-structure,FBS)本體[16-17],從語義的角度介紹了功能、行為、結(jié)構(gòu)的概念及其與主觀和客觀領(lǐng)域需求之間的關(guān)系。國內(nèi)陳勇等人[20-21]在FBS本體理論的基礎(chǔ)上提出狀態(tài)-行為-功能(state-behavior-function, SBF)的觀念,旨在解決技術(shù)系統(tǒng)的多狀態(tài)分析問題,并將其用于機械系統(tǒng)的功能建模中。除此以外,IDEFO[22]和功能方法樹等方法也都分別用在系統(tǒng)功能建模中,但只有SysML被應(yīng)用于基于Harmony-SE的民機研制領(lǐng)域,并得到了廣泛驗證[23-28]。

在功能建模的過程中,場景是特定條件下系統(tǒng)某一部分的執(zhí)行樣例[29],是執(zhí)行用例的系統(tǒng)與系統(tǒng)所在環(huán)境中參與者間的特定交互。而用例則是系統(tǒng)功能的頂層描述,是外部執(zhí)行者能夠直接觸發(fā)或者參與的系統(tǒng)行為[8,30]。通常情況下,用例與場景之間的關(guān)系是一對多的映射關(guān)系。如圖3所示,在系統(tǒng)運行過程中,其功能體現(xiàn)在與系統(tǒng)交互的參與者與所感興趣之系統(tǒng)的交互請求,在特定的運行環(huán)境中,通過按照特定值和特定時間順序執(zhí)行的請求集和響應(yīng)集來滿足系統(tǒng)設(shè)計需求。

圖3 系統(tǒng)運行環(huán)境與服務(wù)請求Fig.3 System operating environment and service request

基于場景的功能建模方法就是以這種請求集和響應(yīng)集(場景流)為出發(fā)點,模擬系統(tǒng)的實際運行階段,對每一個用例構(gòu)建一個可執(zhí)行的模型,然后通過執(zhí)行或仿真,演示系統(tǒng)執(zhí)行用例的輸出結(jié)果是否滿足設(shè)計需求?；趫鼍暗墓δ芙Ａ鞒倘鐖D4所示,主要分為以下5個步驟。

圖4 基于場景的功能建模流程Fig.4 Scenario-based function modeling process

(1) 識別系統(tǒng)用例

首先是識別系統(tǒng)用例,根據(jù)系統(tǒng)需求即復(fù)雜系統(tǒng)的功能描述建立頂層用例視圖,并將系統(tǒng)需求分配到對應(yīng)的用例中[31]。對于民機系統(tǒng)來說,其系統(tǒng)需求的類型主要由運行需求、設(shè)計需求、服務(wù)品質(zhì)需求(quality of service,QoS)和后勤保障等需求構(gòu)成,如圖5所示。值得注意的是,將飛機置于其運營體系也就是航空運輸系統(tǒng)中,其體系需求主要體現(xiàn)在與空中交通控制系統(tǒng)、燃油分配系統(tǒng)、機場系統(tǒng)和票務(wù)系統(tǒng)的交互過程中。根據(jù)飛機級需求種類構(gòu)建飛機級功能如圖6所示,在識別系統(tǒng)用例的過程中,需要考慮系統(tǒng)的狀態(tài)和模式、信息的一致性、產(chǎn)品的領(lǐng)域背景、技術(shù)的局限性等。需要注意的是,對于圖5中所列出的系統(tǒng)功能并不是都需要使用用例來描述,例如結(jié)構(gòu)完整性功能、升力和阻力控制等。用例是外部執(zhí)行者能夠直接觸發(fā)或者參與的系統(tǒng)行為,只有這部分行為(功能)才需要使用用例進行建模。

圖5 民機系統(tǒng)需求種類Fig.5 Classification of civil aircraft system requirements

圖6 民機飛機級功能Fig.6 Aircraft level functions of civil aircraft

假設(shè)一個系統(tǒng)S一共包含n個系統(tǒng)需求,記為SR={R1,R2,…,Ri,…,Rn},1≤i≤n,建立l個用例SUC=(UC1,UC2,…,UCj,…,UCl),1≤j≤l,第j個用例包含的需求個數(shù)為tj,則滿足

(1)

理想情況下式(1)為等式,用例之間滿足獨立性原則的同時與系統(tǒng)行為緊密耦合,能夠單獨對系統(tǒng)行為進行推斷。一般來說,用例包含用例名稱、目的、描述、前置條件和后置條件,如表1所示。

表1 用例的基本屬性Table 1 Basic attributes of use cases

對于民用飛機而言,根據(jù)飛機的任務(wù)剖面構(gòu)建其頂層用例如圖7所示,以下降用例為例,其使命表達式如圖8所示。

圖7 民機飛機級用例Fig.7 Aircraft level use cases of civil aircraft

圖8 下降用例使命表達式Fig.8 Mission expression of altitude descent use case

(2) 定義用例場景

其次是定義用例場景,對于上一階段定義的系統(tǒng)用例,結(jié)合用例的接口和端口以塊的形式描述參與者與用例之間的輸入輸出流數(shù)據(jù),使用順序圖展示特定條件下系統(tǒng)某一部分的執(zhí)行樣例(俗稱場景),通常單個順序圖表示單個場景,用例由多個場景所構(gòu)成,包括正常場景和雨天場景。

假設(shè)第j個用例包含m個場景,記為SCEj={Scej1,Scej2,…,Sceji,…,Scejm}。第k個場景中包含的需求個數(shù)為rk,則滿足

(2)

理想情況下式(2)為等式,用例滿足獨立性原則且需求在用例場景中唯一顯示,能夠單獨對系統(tǒng)的運行場景進行約束。一般來說,場景包含所屬用例、場景ID、描述、前置條件和后置條件。場景的意義在于識別對系統(tǒng)可能產(chǎn)生不利影響的需求,在圖4中場景分析的內(nèi)容是定義執(zhí)行用例的系統(tǒng)與系統(tǒng)所在環(huán)境中參與者間的特定交互,從中發(fā)現(xiàn)對系統(tǒng)產(chǎn)生不利影響的需求并最終導(dǎo)致需求變更。在這一過程中,敏捷系統(tǒng)工程體現(xiàn)在系統(tǒng)需求的反復(fù)迭代中,用例包含的每一個需求與參與者和所感興趣之系統(tǒng)的服務(wù)請求相關(guān)聯(lián),并按照時間的先后順序排列。

(3) 定義用例活動功能流

活動圖是描述系統(tǒng)功能的黑盒視圖,用來展示系統(tǒng)在有限范圍內(nèi)的行為和功能流(物質(zhì)、能量)[8,30]。在這一階段中,將主要場景作為備選流來添加(決策)或者合并(匯合)運行,使用活動圖對系統(tǒng)的行為特性進行建模。通常用例與活動圖一一對應(yīng),活動圖中每一個平行的流構(gòu)成一個單獨的場景集,場景集內(nèi)決策點的每個流構(gòu)成一個不同的場景。

(4) 定義接口與端口

系統(tǒng)用例和參與者之間的服務(wù)請求是基于事件的,在這一過程中,根據(jù)迭代完成的場景時序圖和活動圖中流的信息,迭代更新系統(tǒng)用例的端口和接口,用來導(dǎo)出用例的狀態(tài)機視圖。

(5) 導(dǎo)出用例狀態(tài)機

狀態(tài)機圖是一種行為圖,和活動圖以及順序圖一樣是系統(tǒng)的一種動態(tài)視圖,不同之處在于其關(guān)注的是系統(tǒng)如何根據(jù)隨時間發(fā)生的事件改變狀態(tài)[8,30]。在這一步驟中,根據(jù)所構(gòu)建的場景順序圖和活動圖,逐步迭代構(gòu)建用例的完整狀態(tài)機,用來描述系統(tǒng)隨事件的變化過程。通常情況下,狀態(tài)機由狀態(tài)、事件、守衛(wèi)和動作集構(gòu)成,如圖9所示。狀態(tài)之間的轉(zhuǎn)移過程由事件觸發(fā),守衛(wèi)判斷是否滿足狀態(tài)轉(zhuǎn)移條件,如果滿足則執(zhí)行預(yù)設(shè)的動作集,并完成系統(tǒng)狀態(tài)之間的轉(zhuǎn)移過程。

圖9 系統(tǒng)狀態(tài)之間的轉(zhuǎn)移Fig.9 Transition between system states

3 民用飛機系統(tǒng)級功能驗證

下面以民機自動飛行控制系統(tǒng)(automatic flight control system, AFCS)為例,來驗證上述基于場景的功能建模方法?，F(xiàn)代民機上的AFCS主要在飛行管理計算機的統(tǒng)一管理下,配合自動油門系統(tǒng)實現(xiàn)飛機的自動控制和對發(fā)動機推力的控制,實現(xiàn)飛機的起飛、爬升、巡航、下降、進近和著陸階段的自動控制。本節(jié)針對民機AFCS的基本功能描述構(gòu)建其頂層用例視圖,使用黑盒順序圖、活動流和狀態(tài)機對高度控制用例展開功能分析,迭代更新其系統(tǒng)需求。

3.1 AFCS用例建模

AFCS的功能主要包含飛機的姿態(tài)控制、空速與馬赫數(shù)控制、航跡控制(結(jié)合飛行管理計算機系統(tǒng))、高度與側(cè)向偏離控制、協(xié)調(diào)轉(zhuǎn)彎控制、自動油門控制和自動配平。根據(jù)民機AFCS的功能描述,構(gòu)建其頂層用例視圖,如圖10所示。其中,馬赫數(shù)配平是為了防止跨音速飛行時飛機進入馬赫下俯姿態(tài),系統(tǒng)應(yīng)在俯仰通道中設(shè)置自動抬頭補償來克服這種危險。當縱向AFCS脫離對飛機的控制時,為了減小或完全抵消舵機上產(chǎn)生的鉸鏈力矩,系統(tǒng)應(yīng)能夠進行俯仰自動桿力配平,維持飛機縱向力矩的平衡。

圖10 民機AFCS用例Fig.10 Use case of civil aircraft AFCS

以高度控制用例為例,根據(jù)中國民用航空規(guī)章CCAR-25-R4定義其部分系統(tǒng)需求如圖11所示,對其展開基于場景的用例分析,在分析過程中對需求進行增量式的迭代更新,克服會對系統(tǒng)體系結(jié)構(gòu)產(chǎn)生不利影響的需求,降低系統(tǒng)研發(fā)的風險。

圖11 高度控制用例系統(tǒng)需求Fig.11 System requirements of altitude control use case

3.2 AFCS場景活動流建模

定義高度控制用例的接口與端口,表示參與者與系統(tǒng)用例之間的交互請求,如圖12所示。

圖12 高度控制用例的接口和端口Fig.12 Interface and port of altitude control use case

選擇正常飛行場景如圖13所示,飛行員選擇目標爬升高度和爬升率,確認后飛機開始爬升或下降至指定高度,由高度保持系統(tǒng)維持目標高度巡航。在該場景中,前置條件是飛機處于巡航狀態(tài),自動駕駛儀、自動航向、自動速度均已打開,后置條件是飛機到達指定高度,重新回到巡航狀態(tài)。

圖13 高度控制用例正常操作場景Fig.13 Normal operation scenario of altitude control use case

通過對該場景進行分析,可以發(fā)現(xiàn)當飛機處于爬升狀態(tài)或者巡航(高度保持)狀態(tài)時,AFCS應(yīng)該具有相應(yīng)的指示燈提示駕駛員,所以AltitudeLight()和ClimbRateLight()又可以衍生出更多的合理系統(tǒng)需求。例如，在爬升過程中,爬升指示燈常亮、高度保持等熄滅,爬升結(jié)束后高度保持燈常亮、爬升指示燈熄滅。同時,在飛行過程中,儀表盤需要顯示當前的速度、航向和機內(nèi)自檢狀態(tài)等信息。對所有可能的場景進行建模,逐步迭代構(gòu)建高度控制用例活動流。在這一過程中,假設(shè)飛機高度調(diào)整精度為100 ft,如果飛行員對飛機高度進行微調(diào),則采用內(nèi)置爬升率,每次高度變化為100 ft。如圖14所示,飛機從默認高度的巡航狀態(tài)開始,飛行員選擇指定高度和爬升率,確認爬升后自動飛行控制系統(tǒng)產(chǎn)生高度控制指令,從而改變飛行高度。

圖14 高度控制用例活動流Fig.14 Activity flow of altitude control use case

圖15 高度控制用例狀態(tài)機Fig.15 State machine of altitude control use case event[guard]/action_list

3.3 AFCS狀態(tài)機建模

從高度控制用例的場景活動流模型中可以看出,AFCS在實現(xiàn)高度控制的過程中有3種狀態(tài):飛行狀態(tài)(高度保持)、爬升狀態(tài)和選擇狀態(tài)。高度控制用例的狀態(tài)機如圖15所示,飛機的默認狀態(tài)就是在當前高度的飛行狀態(tài),由飛行狀態(tài)到選擇狀態(tài)的遷移,由事件“選擇高度和爬升率”觸發(fā),存在最大爬升率和最大爬升高度限制,執(zhí)行的動作集為儀表盤上顯示的預(yù)選高度和爬升率的變化。從選擇狀態(tài)到爬升狀態(tài)的遷移,由事件“確認爬升計劃”觸發(fā),執(zhí)行高度控制指令。由爬升狀態(tài)到飛行狀態(tài)的遷移由事件“爬升正常結(jié)束或中止爬升計劃”觸發(fā),更新之后的用例接口和端口如圖16所示。

圖16 高度控制用例接口與端口(建模后)Fig.16 Interface and port of altitude control use case

在圖15所示的狀態(tài)機中,3個關(guān)鍵的狀態(tài)特性是進入動作(entry)、內(nèi)部執(zhí)行(do)和退出動作(exit)。進入動作是每當進入一種狀態(tài)時執(zhí)行的動作列表;內(nèi)部執(zhí)行是在該狀態(tài)內(nèi)執(zhí)行的動作集;退出動作是每當離開這一狀態(tài)時采取的動作。帶箭頭的實線是轉(zhuǎn)移,表示系統(tǒng)處于前一狀態(tài)且觸發(fā)轉(zhuǎn)移的事件發(fā)生時,通過該路徑進入新狀態(tài)。轉(zhuǎn)移的語法如下所示:

ｅｖｅｎｔ ［ ｇｕａｒｄ ］／ ａｃｔｉｏｎ ＿ ｌｉｓｔ

其中,事件event是在狀態(tài)機中觸發(fā)狀態(tài)轉(zhuǎn)移的事件。轉(zhuǎn)移上的事件是可選的;若省略,則一進入該狀態(tài)就會發(fā)生轉(zhuǎn)移。守衛(wèi)guard用來判斷是否滿足狀態(tài)轉(zhuǎn)移條件,若滿足則執(zhí)行動作集action_list,并完成系統(tǒng)狀態(tài)之間的轉(zhuǎn)移過程。

至此,民機自動飛行控制系統(tǒng)的高度控制用例建模已基本完成,得到可執(zhí)行的狀態(tài)機和對應(yīng)的接口與端口。由于篇幅有限,本文只選取了高度控制用例展開基于場景的用例分析建模,模擬系統(tǒng)的實際運行過程,在系統(tǒng)開發(fā)早期識別系統(tǒng)缺陷,降低系統(tǒng)研發(fā)的風險。在實際的建模工作中,應(yīng)該對圖10中所示的所有用例展開建模分析工作,得到每一項能力的系統(tǒng)模型,將其整合成一個完整的飛機子系統(tǒng)接口模型,為后續(xù)的架構(gòu)設(shè)計工作提供支撐。

4 結(jié) 論

本文將敏捷系統(tǒng)工程概念引入到民機研制過程中,提出了敏捷框架下的民機研制流程,并結(jié)合系統(tǒng)建模語言定義了基于場景的功能建模方法,最后采用該方法對民機AFCS的高度控制用例展開基于場景的用例分析建模工作。在功能建模過程中,使用需求圖分配系統(tǒng)需求到目標用例、使用順序圖和活動圖定義場景活動流、使用塊圖和狀態(tài)機構(gòu)建系統(tǒng)在實現(xiàn)目標用例時的狀態(tài)轉(zhuǎn)移過程和接口控制。該方法模擬了系統(tǒng)的實際運行過程,迭代更新了系統(tǒng)設(shè)計需求,提高了模型的可靠性和可信度,顯著降低了復(fù)雜系統(tǒng)的研發(fā)風險。