基于MBSE的民機系統功能建模方法

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

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

0 引 言

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

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

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

1 基于MBSE的民機系統研制流程

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

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

通過反復迭代將更新后的需求與相應的系統設計參數相結合,定義系統需求并展開用例場景分析,建立描述系統黑盒視圖的活動功能流和狀態機視圖。繼而開展系統架構的分析與設計,將選取的系統架構方案與相應的跨學科和子系統接口轉交下游工程,通過反復迭代最終得到符合客戶需求的產品。

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

圖2 MBSE設計中間產出物Fig.2 Intermediate output of MBSE design process

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

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

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

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

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

圖3 系統運行環境與服務請求Fig.3 System operating environment and service request

基于場景的功能建模方法就是以這種請求集和響應集(場景流)為出發點,模擬系統的實際運行階段,對每一個用例構建一個可執行的模型,然后通過執行或仿真,演示系統執行用例的輸出結果是否滿足設計需求。基于場景的功能建模流程如圖4所示,主要分為以下5個步驟。

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

(1) 識別系統用例

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

圖5 民機系統需求種類Fig.5 Classification of civil aircraft system requirements

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

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

(1)

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

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

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

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

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

(2) 定義用例場景

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

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

(2)

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

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

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

(4) 定義接口與端口

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

(5) 導出用例狀態機

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

圖9 系統狀態之間的轉移Fig.9 Transition between system states

3 民用飛機系統級功能驗證

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

3.1 AFCS用例建模

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

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

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

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

3.2 AFCS場景活動流建模

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

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

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

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

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

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

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

3.3 AFCS狀態機建模

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

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

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

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

其中,事件event是在狀態機中觸發狀態轉移的事件。轉移上的事件是可選的;若省略,則一進入該狀態就會發生轉移。守衛guard用來判斷是否滿足狀態轉移條件,若滿足則執行動作集action_list,并完成系統狀態之間的轉移過程。

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

4 結 論

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