前言：尋找寫作靈感？中文期刊網用心挑選的Arcadia方法的民機信息系統架構分析，希望能為您的閱讀和創作帶來靈感，歡迎大家閱讀并分享。
摘要：傳統的基于文檔的系統工程是目前民機研制的主要研制方法，存在需求獲取不清晰、不同層級的需求與設計不一致、難以追溯以及設計方案更改難度大等問題。結合arcadia方法和Capella建模工具，提出基于Arcadia的民機機載系統基于模型的系統工程研究方法。通過集成運行、系統、邏輯和物理的視景，構建了特定場景下的機載系統模型。研究表明，基于Arcadia的民機機載系統能夠有效避免傳統的基于文檔式需求的風險和問題，保證了系統架構與需求分析的緊密融合。
關鍵詞：基于模型的系統工程；Arcadia；民機信息
系統民用客機研制是一項涉及多學科、多專業并具有任務周期長、技術風險高、高可靠性和經濟性相結合等特點的復雜系統工程。因此復雜系統工程往往受到許多需求和約束性的限制，包括功能需求（用戶期望的服務）和非功能需求（安保性、運行安全性、質量、可拓展性、成本等），它們通常同時存在，有時候還互相沖突［1］。傳統的基于文檔的系統工程（Text－BasedSystemEngineering，TSE）中，項目的需求捕獲以及設計方案以自然語言編制成文檔并存儲，并且后續設計過程中經過計算、評估、分析對設計方案甚至需求的更改都需要手動轉換和維護。因此在項目的周期中會有需求捕獲不清晰、設計不可追溯性和方案更改難度大等問題。目前基于MBSE的建模語言中，系統建模語言（SystemModelingLanguage，SysML）是應用最廣的語言之一［2］，SysML是Harmony系統工程方法的建模語言。此外，SysML不提供建模指導，也沒有約束特定的建模方法和工具，這往往會造成建模方法的不一致性［3］。
1MBSE建模語言概述
國際系統工程學會（INCOSE）在2007年發布的《系統工程愿景2020》中，定義MBSE是建模方法的形式化應用，以支持系統從概念設計階段開始一直持續到開發階段和后續生命周期階段的需求、設計、分析、驗證和確認活動［4］。系統工程師長期以來一直使用建模技術去解決工程設計的問題，早在20世紀80年代，結構化分析與設計技術和實時結構化分析就是最為主流的方法［5］。但這些方法在應用范圍和表達能力上均有短板，已無法應對日益復雜的多學科、多專業的系統工程。泰雷茲公司在SysML的基礎上依照自己項目需求創造了Arcadia方法論以及對應的開發工具Capella，Arcadia在繼承了SysML的模型元素和視圖同時，補充了運營理念、目標和系統任務分析等功能。
2Arcadia方法論概述
Arcadia是眾多MBSE方法中的一種，旨在定義和驗證復雜系統架構［6］。Arcadia工程階段分為四層。第一層負責運行分析（OperationAnalysis，OA），即未來系統的用戶需要完成什么，通過識別必須和系統進行交互的參與方，包括它們的活動以及它們之間的相互作用，來分析運行用戶的問題。第一層構建了一個捕獲并描述了以上需求的運營架構，包括參與者／用戶，相對應的運營能力和活動以及運營場景圖等；第二層為系統分析（SystemAnalysis，SA），它關注識別滿足運行需要的系統能力及功能，此階段的輸出是識別出與用戶的交互以及滿足外部系統和外部系統的需求的功能分析；邏輯架構（LogicalAnalysis，LA）層旨在識別系統內部的邏輯組件，即系統如何工作以達成期望，包括它們的關系即組成等，不考慮此層級內的所有技術性考慮或實現選擇；物理架構（PhysicalAnalysis，PA）層的目標與LA一致，只是它定義了必須創建的系統最終架構，并可以參考技術性選擇等。Capella軟件是Arcadia的專用建模工作臺。它提供了一種特定域建模語言和一個專用的工具集。Capella在工具內部嵌入了Arcadia活動瀏覽器，為使用者提供有效的方法論指導。
3基于Arcadia的民機機載信息系統MBSE流程
飛機的開發設計流程，通常按照飛機級－系統級－子系統級等對需求功能進行層層分解，在物理架構層所實現的功能需要在系統層級就完成劃分?；贏rcadia方法的頂層活動流程，針對民用客機機載信息系統，先對系統進行了運行分析，確定用戶需求與系統的任務與范圍；然后對系統級功能與飛機級功能（飛機根據需求賦予系統的功能）進行分配，得到系統架構和系統任務功能鏈；最后通過邏輯架構、物理架構進行繼承和細化，完成架構分析設計。功能的類別主要分為兩類：內部功能和交互功能。在進行功能分解的時候需統籌考慮這兩類功能，具體功能類別定義見表1。需要注意的是，Arcadia從本質上講并非必須自上而下，也完全可以自下而上，可先進行系統場景的定義再對系統需求功能進行分解和劃分［7］。民用飛機機載信息系統在飛機運行的整個過程中都會使用，包括飛機在滑行、爬升、巡航、降落、維修和停留機場。本文只針對飛機停留機場地面時的場景進行機載信息系統架構設計。
3．1運行分析
地面階段，首先定義利益相關者和系統，接著再定義系統運行能力。利益相關者和系統統稱為運行實體，其屬于真實世界的實體，如組織機構、已存在系統或用戶等。運行能力則是為實現運行目標而提供高層級服務的能力。針對飛機駐留在地面階段時信息系統，分析可得運行實體有：飛機各個機載系統、飛行員和維護人員；運行活動則有：提供飛機與地面的通信、提供飛機維護、提供飛機內外視景、提供打印功能。一項能力的實現需要飛機和其他多個系統共同協作，飛機停留在地面階段，地面支持系統可以自動獲取飛機飛行過程中采集記錄的系統和設備運行狀態數據，用于進行飛機的健康管理。同時飛機機組或乘客可以通過飛機的機場無線網絡實現與地面網絡的數據通信。飛行員和維護人員可以使用飛機駕駛艙打印功能方便飛行或維修日志讀取。通過飛機艙內外攝像頭獲取內外視景不僅可在飛機停留地面階段，在起飛、巡航階段飛行員均可以進行查看。
3．2系統分析
為了解決系統“必須做什么”這個問題，需要將系統在OA層捕獲的運行能力轉化為功能并細化。對于系統的外部接口，必須先識別出所有外部運行實體及數據流，系統架構白板圖的使用，可以清楚地顯示系統與執行方之間的輸入輸出信息，很好地展現系統的外部接口。OA層捕捉的運行能力為用戶希望飛機具有的功能，即飛機級能力，也稱為T0能力。信息系統的系統級功能，稱為T1級能力。并識別了飛機能力外部施動者。其中，Capella具有“轉換”功能，允許用戶在保持流程的同時從每個運行層的實體／活動中獲取系統層的實體／功能等［8］。但往往T1級功能無法滿足功能交互的顆粒度要求，并且只有最小葉功能具有端口。系統功能之間通過功能交換關聯在一起，系統和系統之間通過組件交互關聯在一起。以文件導入導出服務功能為例，信息系統收到艙門信號和輪載信號，表明飛機停留在地面階段，通過有線和無線方式將地面的加載數據導入信息系統存儲器或反方向導出。其功能流程圖如圖1所示，對于描述系統在給定情景中的預期行為，功能數據流圖可以進行很好的描述，它所描述的功能鏈表示全局數據流中的一組路徑。根據場景和數據流圖的詳細分析，“提供文件導入導出服務”此T1級功能可分解為“判斷飛機狀態”、“用戶認證和授權”、“選擇文件導入導出方式”、“選擇文件導入導出模式”和“向地面導出數據”五個Tc級功能。自此對提供文件導入導出服務T1級功能的功能分解以及功能交互的關系已經分析完畢，余下的T1級功能均按照此流程進行分析，最終可得出圖2系統功能分解白板圖。所示的系統功能在LA層，功能只能分配給被認為是“黑盒”的系統本身或外部施動者，最終由圖3系統架構圖表示。Capella會自動將所有已交互功能自動聯結，保證功能關系的一致性。
3．3邏輯架構
邏輯架構設計開始“打開黑盒”以識別系統的邏輯組件和組件之間的相關特性。在識別過程中，并不考慮相關技術性要求及實現。保持邏輯架構在整個項目期間的穩定是十分重要的，因為對與長生命周期的系統來說，由于技術革新和物理組件的迭代升級，會導致難大部分物理架構出現問題［9］。為了在SA層工作基礎上開始設計LA層，通過使用Capella的轉換功能把系統功能直接轉換為邏輯功能，同時保留功能交互和功能鏈。邏輯架構設計通過分析系統的功能，進行分類和整合，形成最優的功能組合。邏輯架構設計從邏輯上定義系統的邏輯單元組成、邏輯單元之間的互聯關系、邏輯單元外部接口關系和邏輯功能的實現方式［10］。對機載信息系統功能進行分解、分析，在LA層將信息系統細分為訪問服務、應用服務和基礎服務三個層次，SA層T1級功能分解為最小葉功能，根據功能的互聯關系與服務特性，與上面三個層次一一對應，建立起面向服務的邏輯架構。如圖4所示。依舊以“文件導入導出服務”功能為例，訪問服務層給外部施動者提供不同的用戶界面視圖和操作?；A服務層整合了平臺的各種資源。利用這些基礎功能搭建起來的不同業務的處理流程構成了應用服務層。
3．4物理架構
物理架構設計則是為了識別系統的物理組件以及組件之間的關系和各自特性，并包括其實現和技術問題。首先創建節點物理組件，然后部署具體分配系統功能的行為物理組件。三個節點物理組件分別代表了機載信息系統的通用信息子系統、駕駛艙信息子系統和視頻監視子系統三個子系統。其中通用信息子系統包含的三個行為物理組件分別為通用信息處理計算機、駕駛艙打印機和機場無線通信天線，視頻監視子系統包括視頻監視攝像頭和視頻監視單元，駕駛艙信息子系統則是信息系統顯示終端。接下來需要完成行為功能組件之間的交互關系以及物理組件之間的物理鏈接和端口，這里僅使用一個特定示例來說明應用于整個物理架構層的方法。以“文件導入導出服務”的“文件輸出模式”功能鏈為例，信息系統與其他機載系統的通信與數據傳輸是以航電核心網絡交聯機為中介，主要采用ARINC664總線、ARINC429總線和離散接口。信息系統內部各個子系統以及與地面支持系統之間的接口均為以太網。淡藍色“文件輸出模式”功能鏈標志著數據在物理組件中的傳遞途徑，功能端口與物理端口的連接關系用虛線表示。在通用信息處理計算機收到艙門、輪載信號后，即確認飛機停駐在地面，維護人員使用信息系統顯示終端通過無線或有線（以太網）方式將信息系統存儲器中的數據傳輸至地面支持系統。對其他T1級功能重復上述物理構建過程，將其進行歸納整理最終得到機載信息系統的物理架構白板圖，如圖5所示。這里為了簡化線條隱藏了功能端口與物理端口的連接虛線。至此，關于飛機停駐地面時機載信息系統架構設計基本完成。由于本文只選取了飛機停駐地面時涉及的功能進行分析建模，所得到的系統架構模型以及端口并不完整，需要采用同樣的方法對所有的能力進行分析建模，最終整合成一個完整的機載信息系統模型。
4結束語
本文采用Arcadia這種MBSE方法，選取民用飛機機載信息系統作為主建模對象，根據機載信息系統與其他機載系統交聯多、傳輸數據種類豐富，并結合建模方法靈活的特點，研究飛機停駐地面場景下的機載信息系統，基于Arcadia實現其架構設計的可行性，為基于MBSE的機載系統的設計研發打下基礎，提高效率。
作者：張哲林 黃素娟 陳斌 單位：上海大學通信與信息工程學院 上海飛機設計研究院