前言：寻找写作灵感？中文期刊网用心挑选的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流程
飞机的开发设计流程，通常按照飞机级－系统级－子系统级等对需求功能进行层层分解，在物理架构层所实现的功能需要在系统层级就完成划分。基于Arcadia方法的顶层活动流程，针对民用客机机载信息系统，先对系统进行了运行分析，确定用户需求与系统的任务与范围；然后对系统级功能与飞机级功能（飞机根据需求赋予系统的功能）进行分配，得到系统架构和系统任务功能链；最后通过逻辑架构、物理架构进行继承和细化，完成架构分析设计。功能的类别主要分为两类：内部功能和交互功能。在进行功能分解的时候需统筹考虑这两类功能，具体功能类别定义见表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所示。依旧以“文件导入导出服务”功能为例，访问服务层给外部施动者提供不同的用户界面视图和操作。基础服务层整合了平台的各种资源。利用这些基础功能搭建起来的不同业务的处理流程构成了应用服务层。
3．4物理架构
物理架构设计则是为了识别系统的物理组件以及组件之间的关系和各自特性，并包括其实现和技术问题。首先创建节点物理组件，然后部署具体分配系统功能的行为物理组件。三个节点物理组件分别代表了机载信息系统的通用信息子系统、驾驶舱信息子系统和视频监视子系统三个子系统。其中通用信息子系统包含的三个行为物理组件分别为通用信息处理计算机、驾驶舱打印机和机场无线通信天线，视频监视子系统包括视频监视摄像头和视频监视单元，驾驶舱信息子系统则是信息系统显示终端。接下来需要完成行为功能组件之间的交互关系以及物理组件之间的物理链接和端口，这里仅使用一个特定示例来说明应用于整个物理架构层的方法。以“文件导入导出服务”的“文件输出模式”功能链为例，信息系统与其他机载系统的通信与数据传输是以航电核心网络交联机为中介，主要采用ARINC664总线、ARINC429总线和离散接口。信息系统内部各个子系统以及与地面支持系统之间的接口均为以太网。淡蓝色“文件输出模式”功能链标志着数据在物理组件中的传递途径，功能端口与物理端口的连接关系用虚线表示。在通用信息处理计算机收到舱门、轮载信号后，即确认飞机停驻在地面，维护人员使用信息系统显示终端通过无线或有线（以太网）方式将信息系统存储器中的数据传输至地面支持系统。对其他T1级功能重复上述物理构建过程，将其进行归纳整理最终得到机载信息系统的物理架构白板图，如图5所示。这里为了简化线条隐藏了功能端口与物理端口的连接虚线。至此，关于飞机停驻地面时机载信息系统架构设计基本完成。由于本文只选取了飞机停驻地面时涉及的功能进行分析建模，所得到的系统架构模型以及端口并不完整，需要采用同样的方法对所有的能力进行分析建模，最终整合成一个完整的机载信息系统模型。
4结束语
本文采用Arcadia这种MBSE方法，选取民用飞机机载信息系统作为主建模对象，根据机载信息系统与其他机载系统交联多、传输数据种类丰富，并结合建模方法灵活的特点，研究飞机停驻地面场景下的机载信息系统，基于Arcadia实现其架构设计的可行性，为基于MBSE的机载系统的设计研发打下基础，提高效率。
作者：张哲林 黄素娟 陈斌 单位：上海大学通信与信息工程学院 上海飞机设计研究院