基于多视角的民机正向设计建模方法

毕文豪，范秋岑李德林，张安

1.西北工业大学 航空学院，西安 710072

2.中国航空研究院，北京 100029

随着信息科学、系统科学、计算机科学、管理科学等学科，以及复杂系统建模技术、模型仿真技术、决策技术等关键技术的迅速发展，民用飞机的设计已经逐渐成为一个大型的多学科交叉、多领域融合、多种技术高度集成的复杂系统工程［1-2］。系统工程理论和方法已用于工业、农业、航空航天、社会等多个领域，并取得了重要应用成果［3-4］。

民机正向设计是指以利益相关方需要/需求为驱动，自上而下地进行分解，通过构建民机功能网络结构进行详细功能设计，并基于此建立逻辑及物理架构，形成各级系统、子系统及部件设计方案的系统工程活动。传统的民机正向设计过程是基于文档管理的，以自然语言为主要语言、图表为主要承载形式，对民用飞机设计中产生的项目文档、技术规范、管理条例等进行描述，不同领域的设计人员从文档中读取信息很容易产生理解偏差，从而导致在设计过程中需要反复迭代修正，严重影响了复杂系统的开发效率。这导致了设计文档变更难度大、工程模型可读性差、工程数据追溯性差、设计周期不断拉长、设计成本增大且版本难以控制等问题［5-7］。正向设计能力较弱已经成为制约中国航空产业实现自主创新、增强市场竞争力的重要因素［8］。

目前，民机设计在型号设计上逐渐推广基于模型的系统工程（Model Based Systems Engineering， MBSE）方法［9］来构建涵盖需求、功能、逻辑和物理层面的设计架构和逻辑关联，与民机产业发展亟需推进的正向设计趋势不谋而合。中国商飞在C919大飞机研制中探索正向设计与研制方法，在工程设计研制实践中力争完全掌握自主知识产权，在研制过程中基于异地协同机制，采用基于模型的定义（Model Based Definition， MBD）的方法，实现产品设计与制造高度并行、广域协同，无纸数字化制造技术得以落地实施［10］。美国国家航空航天局（National Aeronautics and Space Administration， NASA）将MBSE方法应用于培养超高效、低排放的航空动力（Fostering Ultra-Efficient， Low Emitting Aviation Power， FUELEAP）项目，构建了利益相关方之间规范的沟通途径，包括功能和物理架构的所有主要方面进行建模并实现需求追溯［11］。

国内外研究机构和众多学者对MBSE在复杂体系和系统建模中的应用进行了较为深入的研究，尤其是在航空［12-14］、航天［15-16］、车辆工程［17-19］等涉及复杂体系及系统的领域内并行实施了理论研发与技术实践，在开发周期和质量水平方面都取得了较为显著的提升［20-21］。

在当前的民机正向设计建模中，存在利益相关方与设计需求脱节、需求到功能的映射关系解耦难度较大、系统级系统之间功能耦合关系复杂、系统和子系统之间层次架构不清晰、子系统之间功能流和数据接口定义不明确等众多问题，亟需解耦民机正向设计体系，从多视角描述民机正向设计过程中的工作流、信息流和任务流。

本文面向民用飞机正向设计流程，详细梳理民机正向设计中的建模要素和逻辑关系，从多视角对民机设计建模过程进行抽象描述，提出一套基于多视角的民机正向设计建模方法。

1 民机正向设计架构构建

1.1 MBSE方法论架构分析

截至目前，系统工程国际委员会（International Council on Systems Engineering， INCOSE）已公布了6种MBSE方法论［22］，分别为IBM Rational Telelogic Harmony-SE［23］、OOSEM（INCOSE Object-Oriented System Engineering Method）、Vitech MBSE Methodology、RUP-SE（IBM Rational Unified Process for System Engineering）、Dori OPM（Dori Object-Process Methodology）、SA（JPL State Analysis）。此外，法国Thales公司提出的Arcadia方法论［24］和Dassault公司提出的MagicGrid方法论［25-26］的应用也较为广泛。MBSE方法论对比分析如表1所示。

表1 MBSE方法论对比Table 1 Comparison of MBSE methodology

通过对比分析不难发现，MBSE方法论大多以需求/目标为导向，采取自上而下的正向分解，以迭代化开发的方式，将需求/目标逐层分解，并通过以SysML［27］为代表的建模语言构建自顶向下分解产生需求、功能、逻辑、物理层级的权威真相源模型［28］。但是现有的如Harmony SE、MagicGrid、Arcadia等方法论，都是设计者从自身熟悉的实际设计领域出发，往往都是直接针对系统级的设计对象进行设计，如配套Arcadia方法论而开发的专业建模工具Capella被广泛应用于Thales公司所设计的航电、轨道交通、航天、雷达系统等［29］。

随着民机各系统的不断发展和改进，这些方法论已经不足以全面、清晰地描述民机作为复杂巨系统所面临的内部系统之间交互的设计架构，在设计中往往难以描述在不同视角下的各民机系统及子系统的耦合交互关系。同时，系统工程方法在实践中随着建模对象的复杂性越来越强、模型精细度越来越高，对工程设计人员的专业知识、过往经验、建模水平都有较高的要求，很难将MBSE建模方法在设计部门进行广泛推广实践。另外，MBSE方法论的严格实施对工程设计人员的知识储备要求较高，尤其是对于民机正向设计缺乏足够历史机型设计数据的现状，迫切需要一套建模详细流程范式，以辅助设计人员在MBSE方法论的指导下更好地进行民机正向设计的建模设计工作。

对民机正向设计而言，CCAR-25（中国民用航空规章运输类飞机适航标准）［30］、SAE ARP4754A（民用飞机和系统的开发指南）［31］、ISO ISO/IEC/IEEE 15288： 2015（系统和软件工程-系统生命周期过程）［32］等适航条款和行业标准中隐含着大量产品设计要求［33］。在需求捕获阶段，这些产品设计要求应当尽可能地被有效识别和捕获，以设计约束或利益相关方需要的形式进入民机正向设计的迭代流程，以进一步确定正向设计流程各阶段所涉及的规范、功能、物理结构要求，指导民机正向设计中相关应用、能力、功能的设计工作。

为了更好地满足适航和市场需求，民机产品主制造商需要向适航局方提供更加严谨详实的适航符合性证据，因此在构建民机正向设计架构时，充分结合适航条款、行业标准、规范就显得非常重要和必要。目前国内已经基于适航取证的要求，在民机航电系统的研制中采用了正向设计的思路。

基于MBSE方法论的设计逻辑，遵循适航条款和行业标准的规定，提出的民机正向设计流程如图1所示。按照流程，大致可以将正向设计流程划分为体系交互、需求、功能、逻辑、物理、关联回溯等6个模块。

图1 民机正向设计流程Fig.1 Civil aircraft forward design process

体系交互模块是在现代民机以需求驱动为导向的设计背景下逐渐衍生出来的，其主要作用有以下3点：① 在设计初期对利益相关方需要/需求进行捕获，作为正向设计流程中需求分析阶段的输入，确保民机设计是以需求为驱动，且能够随着需求变更而进行改型等工作；② 全面把控民机正向设计的各阶段，对各阶段下产生的模型、文档、数据开展过程管理，综合把握项目开展的迭代周期和模型构建的性能度量；③ 对设计流程中出现的设计冲突和矛盾进行权衡与控制，对现有设计阶段下的方案进行评估与决策。

需求分析阶段的主要工作是对MBSE流程的初始输入——利益相关方需求进行分析，产生系统需求，并将利益相关方需求与系统需求相关联，产生的系统需求定义了系统所需要实现功能的顶层描述。在此基础上定义系统用例，用于描述操作者（也称用户，具体指代可以是人、系统，也可以是任意可产生“主动”行为的部件）的行为、操作者与用例之间的信息流。系统用例不对应功能的结构化，不能按照功能分解，但是系统用例需要覆盖所有的功能需求、性能需求，并建立起系统用例与功能性需求、性能需求之间的追溯链接关系。

功能分析阶段的主要工作是基于用例模型对功能进行进一步分析和分解，梳理分析功能之间的依赖关系、改善关系等，产生功能网络结构，并基于此细化分解功能，用连贯的各系统/子系统的功能描述或连续的功能流来关联系统功能性需求，形成功能和需求的映射关系。在功能分析中新识别的需求或在用例分析中细化的需求，都需要建立新增需求与用例或上级需求之间的追溯链接关系，并进入下一层次的需求分析阶段。

逻辑架构分析和物理架构分析阶段的主要工作任务是，在规定的设计约束下，对承载所需实现功能的逻辑架构和物理架构进行综合开发。逻辑架构分析阶段是将需求分析阶段、功能分析阶段中输出的功能性需求、系统需求、非功能性需求以面向用例的迭代设计方式，分配落实在逻辑架构中，以螺旋前进、逐层向下的正向设计方法推进系统架构完善，实现将功能分析阶段的黑盒视图解白的用例实现过程。在物理架构分析阶段，以自底向上的设计思路，面向底层用例/功能实现，将实际物理元件嵌入逻辑架构，建立起物理世界的架构，并与逻辑架构对应关联。

关联回溯贯穿于正向设计的全生命周期，主要是对设计过程中提出的需求变更申请、需求确认、功能确认、面向功能架构和系统需求的设计确认、面向最终用户的试验与评价进行关联，确保设计过程中的设计迭代能够形成闭环并促进后续的迭代设计过程。

1.2 基于多视角的架构分析建模方法

民机设计过程中涉及的利益相关方众多，耦合关系复杂，难以通过简单的、线性的“分解-集成”系统工程方法实现对复杂系统模型的抽象构建和描述。欧美在探索体系化构建指挥信息系统的过程中，逐渐形成了美国国防部架构框架（United States Department of Defense Architecture Framework， DODAF）［34］、英国国防部体系结构框架（Ministry of Defense Architecture Framework， MODAF）、北约体系结构框架（North Atlantic Treaty Organization Architecture Framework， NAF）、统一架构框架（Unified Architecture Framework， UAF）［35］等为代表的体系结构框架理论成果，实践证明该类结构框架的理论能够对存在复杂内联及外联关系的事物进行多角度抽象，是有序解耦复杂事物并指导抽象建模的重要科学方法理论［36］。

DoDAF是面向美军不断发展的联合作战需求而提出的一体化框架，继承了被广泛实践验证的C4ISR（Command， Control， Communication，Computer， Intelligence， Surveillance， Reconnaissance）体系结构框架，并逐渐完善而形成现行标准，其不仅可用于指导国防指挥控制系统和武器装备研制，还能广泛运用到各种商业运作过程中的管理和研发活动［37］。2017年，为了弱化现存各体系结构框架如DoDAF、MoDAF、NAF的视角，解决各体系结构框架概念定义不统一的问题，以进一步提高框架兼容性，对象管理组织（Object Management Group， OMG）发布了统一体系结构框架（Unified Architecture Framework， UAF），其丰富的领域模型和统一元模型语义为体系结构开发提供了更为规范的方法［38-39］，为描述复杂系统及其内外交互关系提供科学的建模支撑。

目前，DoDAF、UAF目前已经被广泛应用于各类面向复杂体系交互的作战场景描述、体系能力描述、活动描述等需要依赖多视角描述的工程实践中，得到了业界广泛认可，并在民机设计领域得到了初步应用［40-42］。

1.3 基于多视角的正向设计建模流程

民机的正向设计基本上遵循“需求-功能-逻辑架构-物理架构”设计脉络，利用需求模型到系统模型关键设计信息的逐步映射，实现原先传统飞机设计由概念到详细的逐步设计。

但是在这类实践中，各系统之间的交互是以民用飞机利益相关方需求的形式进入设计迭代的。如何理解这样的需求，准确把握缺少工程视角的利益相关方实际需要，并逐步落实到后续具体设计中，往往还需要结合以往的设计经验和统一化、模型化、标准化的描述方式。

为了更好地解决民用飞机在多视角下充分解耦的设计需要，使得民机正向设计逻辑能够科学地从多视角进行解构，本文吸取了DoDAF及UAF在体系分析上的显著优势，基于全景视角（All Viewpoint， AV）、能力视角（Capability Viewpoint， CV）、运行视角（Operational View，OV）和系统视角（Systems View， SV）等4个视角，提出了如图2所示的基于多视角的民机设计建模流程，利用具有一致性的模型将多视角下的设计流程以SysML进行归纳与表达。

图2 基于多视角的民机设计建模流程Fig.2 Modeling process of civil aircraft design based on multiple perspectives

通过全景视角下的设计综述与概要信息AV-1、民机设计体系交互概要模型AV-UAF来解耦正向设计流程中的需求分析和体系交互；构建能力视角下的能力愿景CV-1、能力分级描述CV-2、能力依赖关系CV-4以实现功能分析，建立起需求和功能的映射关系、功能分类、功能依赖的逻辑关系；依托运行视角下的高层运行概念OV-1、运行资源流活动OV-2、运行活动模型OV-5a/b、运行状态转换OV-6b、事件顺序模型OV-6c来描述功能映射到逻辑架构层面时各层级对象的运行目标、资源流活动、活动转换逻辑及实现顺序；以系统视角下的系统功能描述SV-4、系统接口描述SV-1、系统资源流SV-2、活动-系统关系SV-5、部件系统关系SV-3来描述逻辑架构层面映射到物理架构层面的具体实施形式，建立起领域设计内的部件级功能描述和资源流关系，形成逻辑与物理层级的链接关系。通过不同视角间的逐层映射，可以保证在每一个设计阶段下各利益相关方需求与体系的其他需要的落实与追溯。

2 民机正向设计建模流程

为了进一步详细梳理民机设计建模流程，以抽象的建模范式为表达形式，对民机正向设计建模中涉及的建模要素进行详细分析与抽象表达，分析各建模要素之间的内在、外在逻辑联系关系，形成一套自顶向下的民机正向设计抽象建模范式。

自顶向下不仅仅是实现“需求-功能-逻辑架构-物理架构”的逻辑自洽过程，也是充分继承了传统民机系统工程中飞机级、系统级、子系统级、部件级等不同逻辑架构层级的逐层分解与开发过程。

2.1 面向需求的全景视角（AV）建模流程

设计综述与概要信息模型（AV-1）是对民用飞机待设计系统的雏形概念进行汇总与解析，主要归纳民机待设计系统的构想、目的、范围、预计成果等关键初始设计信息。

AV-1主要利用包图（Package）构建，其模型中每个包视为民机待设计系统的1个信息集合，在各个包中创建SysML定义的需求图（Requirement Diagram）来反映最初的工程需要。

设计综述与概要信息模型ΣAV-1的关键概念定义为

式中：I为项目信息包图；P为目的包图；R为范围包图；Sc为场景包图；So为系统资源包图；So-template为需求模板信息；So-alphabet为需求术语表信息；So-type为以往型号设计资料。

AV-1包括项目信息包图（I）、目的包图（P）、范围包图（R）、场景包图（Sc）和系统资源包图（So）5部分。项目信息包图中，在需求图中撰写项目层面的参与设计研发的各部门、设计任务的分配、项目起始、成本投入方面的信息；在目的包图（P）中，捕获利益相关方初步形成的原始需求，从设计角度描述系统预期的功能、对系统的非功能性（可靠性、维护性、保障性）要求、多种设计方案下的决策流程与决策方法；在范围包图（R）中，指出系统预期的运行范围与功能执行范围，明确系统的运行概念与功能边界；在场景包图（Sc）中，根据已定义的运行范围，结合民机及系统任务剖面，定义出该民机待设计系统需要适应的各种场景以及场景状态信息；除此之外，应绘制系统资源包图（So），以记录所有设计过程可能需要的设计资源，基本的系统资源包括需求模板So-template、需求术语表So-alphabet、以往型号设计资料So-type。其中

即通过对记录在目的包图（P）中的民机待设计系统的初始需求进行解析，将其进一步拆解为范围包图（R）与场景包图（Sc）中的数据信息。其中功能性及非功能性需求分解为范围包图（R）中的系统运行的性能指标与场景包图（Sc）中的既定运行条件和场景；构建的包图与包中的设计信息共同构成了待设计系统的AV-1模型。

民机设计内外交互关系如图3所示。在需求捕获与分析阶段，民用航空体系下例如航空公司、生产制造商、试飞试验部门都存在反复的需求变更、需求确认等迭代环节；在进入概念设计和详细设计阶段时，各飞机级系统和系统级系统交互关系复杂导致的需求变更与捕获阶段的各交互主体密不可分，需要从多方面建立起利益相关方同架构和基于场景的交互之间的关系，保证系统设计开发过程并非独立存在，而是与设计流程下的复杂交互息息相关，且能够随着需求变更对建立的模型进行动态调整，在迭代修正中以模型更迭的方式实现设计方案的逐步完善及对设计需求的逐步覆盖。

图3 民机设计内外交互关系Fig.3 Internal and external interaction of civil aircraft design

民机设计体系交互概要模型（AV-UAF）是在待设计系统上层系统或体系层面，分析待设计系统的功能定位与可能的交互关系，由此确定该系统设计之初的利益相关方及需求来源，初步明确可能存在的接口去向与相应要求。AV-UAF主要包括体系内系统架构关系（St）、基于场景的交互关系（Op）、涉及的利益方（Pr），即

体系内架构关系（St）是基于上层系统（SV）分解的，主要涉及在上层系统/体系内部的结构构成与分类，需要明确待设计系统的功能及结构边界；基于场景的交互关系（Op）是根据AV-1模型中分类完成的场景（Sc）确定体系内各组成部分的初步交互关系与传递的资源或信息类别；涉及的利益相关方（Pr）是对Op中以人为构成主体的体系结构进行进一步归纳细分，补足体系视角下潜在利益相关方的全部捕获来源。

上述AV-1、AV-UAF模型的建立顺序并非逐步进行的，一般来说，这是一个相互迭代逐渐完善的过程。

2.2 面向功能的能力视角（CV）建模流程

在能力视角（CV）下定义的CV-1能力愿景、CV-2能力分级描述、CV-4能力依赖关系3种子视图作为待设计系统能力描述的3个层次，即

式中：CVision为能力愿景；CTaxonomy为能力分级描述；CDependencies为能力依赖关系。

在系统设计过程中先定义能力愿景CVision，然后根据已定义的CVision分解出能力分级描述CTaxonomy与能力依赖关系CDependencies，其中CDependencies是对CTaxonomy的修饰，即在CDependencies中定义并表示CTaxonomy中的子能力之间的相互关系，即

建立用例图（Use Case Diagram）描述民机待设计系统的CV-1能力愿景，CV-1能力愿景反映该系统的功能执行期望，用例图中包括基于系统运行目的（全景视角定义）的基本运行环境与可能的运行模式；在每一种用例图中反映一个通用场景或者某一特定场景下的系统边界与运行情况，绘制的要素如下：

1） 系统的交互对象（外界）Cobject，包括系统操作人员Cpeople和其他系统Csystem。

2） 该交互对象情况下，系统能够执行的功能活动，即系统能力Ccapability。

3） 交互对象与系统内预期功能的关联关系Crelation。

4） 运行环境与运行场景Cenvironment，即

然后用需求图、用例图建立描述CV-2能力分级描述CTaxonomy、CV-4能力依赖关系CDependencies；在CV-2中首先明确民机待设计系统对应的系统运行能力，与已建立的CV-1中反映对应运行场景的用例模型之间建立链接，根据CV-1的用例图，使用用例图、需求图或用例图与需求图的组合绘制描述CV-1中定义的系统能力愿景的子能力CSubcapability，子能力的撰写依据为AV-1系统需求信息概要模型中目的包图模型中所定义的利益相关方需求与非功能性要求；在CV-4中基于CV-2撰写出的系统功能模块的子能力之间的协作关系Crelationship，构建待设计系统的子能力模型之间的关联关系，关联关系包括依赖（Dependency）、扩展（Extend）、包含（Include），即

2.3 面向逻辑架构的运行视角（OV）建模流程

基于运行视角（OV）的系统功能分析模型，包括OV-1高层运行概念模型、OV-2活动资源流模型、OV-5b运行活动模型、OV-6c事件追踪描述模型、OV-6b状态转换描述模型，即

绘制内部模块图（Internal Block Diagram）描述民用飞机待设计系统的OV-2视图，即活动资源流模型OResource，在绘制的活动或动作之间，定义不同资源和信号的传递方式或数据格式，活动或动作之间的流向关系使用信息流（Information Flow）连接器描述

同时，功能活动流OFunctionflow是基于运行视角（OV ）的系统功能分析模型的核心内容，包括输入OInput、输出OOutput、动作（活动）OAction、消息流OMessage、状态OState、时间（序列）OTime、事件分支点ODecision等核心要素，即

式中：OConcept为OV-1高层运行概念模型；OResource为OV-2活动资源流模型；OActivity为OV-5b运行活动模型；OEvent为OV-6c事件追踪描述模型；OState为OV-6b状态转换描述模型。

OV-1高层运行概念OConcept，包括待设计系统的任务OTask、功能活动流OFunctionflow、场景（运行状态）OScenes；在OV-1视图中引用CV-1中建立的反映不同运行状态的用例场景，绘制活动图（Activity Diagram）以描述该系统应适用的不同场景状态及其下的系统预期可执行的不同功能活动流，活动图中以活动或动作（Activity/Action）为单元，定义功能执行过程中的各个功能活动或动作，同时在活动或动作单元之间建立依赖（Dependency）或关联（Association）的链接关系，完成功能活动间的逻辑梳理，即

建立运行活动模型OActivity，即建立该系统的OV-5b视图。在OV-5b视图中绘制活动图以定义该系统的功能活动的运行流程；针对CV-1与OV-1中定义的各场景与系统状态OScenes，分别对应各用例场景绘制活动图模型以反映系统不同功能运行活动流，每一个活动图中绘制活动事件或动作事件作为基本元素OAction，通过构建控制流（Control Flow）或对象流（Object Flow）描述活动事件或动作事件的先后顺序与关联关系OTime，建立判断点（Decision）表明功能流遇到的条件判断分支ODecision，同时指示运行活动流的前进方向或者合并功能分支流。一个完整的活动图，应反映包含输入OInput、输出OOutput在内的目标系统的一个功能活动流。不同场景和运行状态下的所有的活动图即构成OV-5b运行活动模型，即

绘制时序图来反映各功能活动的执行周期，通过建立生命线（Lifeline）表明各功能活动OAction的开始与终结，以及功能活动的交互对象Cobject、Cenvironment（在面向功能的能力视角建模流程中定义），建立消息序列（Message）反映功能活动之间消息流OMessage的交流方向与时段；时序图描述该系统功能活动之间消息发送的先后顺序OTime与输入OInput、输出OOutput，所有的时序图构成该系统的OV-6c事件追踪描述模型OEvent，即

将OV-5b运行活动模型与OV-6c事件追踪描述模型的信息汇总，绘制状态机图（State Machine Diagram）描述基于该系统的不同运行状态OScenes下的功能活动流程OAction与时序OTime；以状态（State）或状态机（State Machine）反映该系统的运行状态OScenes，以转变（Transition）连接器及转变连接器的属性（Trigger、Guard、Effect）建立不同运行状态之间的切换关系ODecision，同时反映切换过程中的消息流，每一个状态机元素中可继续扩展下层系统状态，以起始点（Initial）和终点（Final）表明每个运行状态的执行过程，即完成构建OV-6b状态转换描述模型OState；OV-6b状态转换描述模型是一个多层迭代的状态机模型，提供了功能模型设计的一个可执行的功能完整性验证，即

2.4 面向物理架构的系统视角（SV）建模流程

系统视角用于阐明待设计系统的组成结构和内部接口，以及其他系统在运行和能力视角（CV）和运行视角（OV）中与待设计系统交互的接口组成信息。

基于系统视角（SV）的系统架构模型，包括SV-4系统功能描述模型SFunctionDes、SV-1系统接口描述模型SInterfaceDes、SV-5活动-系统关系模型SActivity-Sys、SV-3系统-部件关系模型SSys-Part，即

在SV-4视图即系统功能描述模型SFunctionDes中，绘制模块定义图（Block Definition Diagram），将该系统的OV-5b运行活动模型、OV-6c事件追踪描述模型、OV-6b状态转换描述模型分配到具体的实体SPart上，通过定义模块（Block）并撰写模块特性SPartFeature，表明该系统内部的物理架构组成及部件模块的结构特性、行为特性，表达式为

在SV-1视图中的系统接口描述模型SInterfaceDes中绘制内部模块图，用以描述系统部件的接口SPartInterface、数据传输格式信息SResource。建立零件图（Part）与接口单元（Port），并根据基于运行视角（OV）的活动资源流模型OResource撰写数据传输格式信息SResource，结合SV-4系统功能描述模型中定义的实体SPart，完成系统部件接口SPartInterface的定义

构建矩阵表格定义SV-5活动-系统关系模型SActivity-Sys、SV-3系统-部件关系模型SSys-Part。在SV-5活动-系统关系模型SActivity-Sys中，根据SV-4系统功能描述模型中定义的部件SPart，结合在OV-5b中定义的运行活动模型OActivity描述的目标系统的功能活动流，明确系统功能分析（OV）模型中定义的各功能活动流OFunctionflow执行所需要或涉及的各系统部件SPart（SPart应在SV-4中已定义，若未定义则应补充定义），表明各功能活动OAction与其执行对应的部件SPart之间的关系。在SV-3系统-部件关系模型SSys-Part中，结合OV-2活动资源流模型OResource，定义SV-4系统功能描述模型中定义的部件SPart与其他系统SOtherSys的包含关系，表明该部件重复用于其他系统，或该部件引用于其他系统，表达式为

SV-5活动-系统关系模型矩阵表格的行是运行视角下系统功能分析模型中的主要功能活动OActivity-Function，SV-5活动-系统关系模型矩阵表格的列是系统视角下的部件SPart；SV-3系统-部件关系模型的行是运行视角下系统功能分析模型中所有其他系统SOtherSys，SV-3系统-部件关系模型矩阵表格的列是基于系统视角的部件SPart；SV-5活动-系统关系模型矩阵表格中每一个元素分别反映了基于系统视角定义的部件与基于运行视角定义的运行活动之间的关联，SV-3系统-部件关系模型矩阵表格中每一个元素分别反映了基于系统视角的部件与其他系统的交联关系，SV-5活动-系统关系模型矩阵表格将OV与SV模型关联起来，SV-3系统-部件关系模型矩阵表格则能快速浏览系统资源之间的交互。

3 舱压控制系统建模实例

民用飞机舱内压力控制是飞机环境控制的重要组成部分，其作用是保证民用飞机座舱内空气的压力及其变化速率在整个飞行包线内满足规范要求。根据控制器的类型，民机舱内压力控制系统可以分为气动式、电子式、数字式；根据其执行机构可以分为气动式、电动式；控制器和执行机构的不同组合形成不同的舱压控制系统［43］。

民机舱内压力控制系统的发展经历了纯气动式、电子气动式、电子电动式、数字电动式等阶段。数字电动式舱内压力控制系统作为一种先进的座舱压力控制系统，具有适应性强、控制精度较好、易与飞控计算机及大气数据计算机配合、可实现全航程座舱压力按程序的自动控制等优点，已在民用大型客机、公务机、军用教练机等领域得到广泛应用［44-45］。

以数字电动式舱内压力控制的设计逻辑为例，在第2节民机正向设计建模流程指导下，面向民机飞机级系统，构建具有高冗余度民用飞机舱内压力控制系统模型。

3.1 面向需求的全景视角（AV）模型建立

本步骤包括：获取利益方需求集，梳理项目信息，记录舱压控制系统初步设计规划方法、设计规范、决策准则等，可选地获取以往系统相关设计经验，整合建立AV-1设计综述与信息概要模型、AV-UAF民机设计体系交互概要模型。

舱压控制系统设计综述与信息概要模型示例如图4所示。项目情况包图是对舱压控制系统设计的概述，目的包图为舱压控制系统设计提供了最初期望与利益方需求，范围与场景包图定义了舱压控制系统的初始边界与运行场景。系统资源包图用于了解辅助设计人员进行设计决策的资源。

图4 AV-1包视图Fig.4 Package of AV-1

在AV-UAF视图中，建立民用飞机舱压控制系统交互的架构关系（St），捕获民用飞机舱压控制系统所有的交互单位，以捕获与民机设计时交互的对象，在设计初期尽可能全面地捕获利益相关方需要/需求，如图5所示。民机设计中需要考虑到与外界环境存在的交互关系，在场景分析中需要转化为需求进入设计迭代环节；后勤维护人员对民机设计的维护性、易检性会产生关联关系，可由此捕获民机设计的非功能性需求；乘客对民机乘坐的舒适性、经济性会提出合理的诉求，这也将被纳入民机设计交互中；研发团队、生产制造、供应商之间通常会产生关于民机设计的接口、易装配程度、可加工性等方面的冲突交互。

图5 舱压控制系统体系内架构关系模型（St）Fig.5 Model of architecture relationship within cabin pressure control system （St）

众多显性的、潜在的基于场景的交互关系（Op）可以借助AV-UAF视图进行迭代式的细化与完善，最终更加全面地开展民机正向设计的工程实践活动。

其中以人为构成主体的交互单位即是系统设计的利益相关方，如图6所示，一般包括机组成员、设计团队、供应商、生产制造商、后勤维护人员（包括负责运营的航空公司）、乘客等。在利益相关方模型（Pr）视图中，可以进一步明确可初步采集的利益方需求来源与具体对象，以便后续需求验证时进行确认与反馈。AV-UAF通过与不同类别的利益相关方建立交互关系，从而尽可能完备地捕获在不同场景下、不同利益相关方对民机设计提出的利益相关方需要/需求。

图6 舱压控制系统涉及的利益相关方模型（Pr）Fig.6 Stakeholder model involved in cabin pressure control system （Pr）

3.2 面向功能的能力视角（CV）模型建立

本步骤包括：将舱压控制系统需求转化为完成民机飞行任务的所需要的系统能力；将能力与相应需求进行关联；验证能力对全部需求的完整覆盖；对主要能力进行结构分解，并分析子能力间的依赖关系。

CV-1能力愿景模型主要反映了舱压控制系统的初步期望，需要通过全景视角中捕获的舱压控制系统需求，明确系统应有运行状态与交互对象。其中运行状态包含飞机运行阶段，如起飞、爬升、巡航、下降、进近、停机，以及系统运行状态，如正常状态、应急状态。舱压控制系统交互对象主要是外界大气、座舱环境、驾驶员。建立用例图反映舱压控制系统的CV-1能力愿景模型，如图7所示。

图7 CV-1舱压控制系统能力愿景模型Fig.7 CV-1 vision of cabin pressure control system

在CV-1定义的能力愿景基础上，对舱压控制系统主要能力进行分解与梳理，将数据监控、数据处理与判断、压差调节、舱压显示与控制等4个能力划分为12个子能力，建立的CV-2能力分级描述模型如图8所示。

图8 CV-2舱压控制系统能力分级描述模型Fig.8 CV-2 capability taxonomy of cabin pressure control system

需要说明的是，某些能力会覆盖多种运行场景。例如，无论在正常状态还是应急状态，舱压控制能力均依靠作动机构调节压差。能力与相应需求的对应关系，记录在CV-2能力分级描述模型的各能力属性中。

根据能力的分解逻辑，梳理出舱压控制系统各能力之间的依赖关系，实例中建立的能力依赖关系模型如图9所示。例如：作动机构调节压差能力依赖于控制信号识别与控制执行能力；控制信号识别与控制执行能力依赖于参数计算与控制判断能力、模式选择能力、人工控制能力；参数计算与控制判断能力需要获取经过调理后的压力信号与空地信号，并需要选择相应的座舱压力制度进行计算。

图9 CV-4舱压控制系统能力依赖关系模型Fig.9 CV-4 capability dependencies of cabin pressure control system

3.3 面向逻辑架构的运行视角（OV）模型建立

本步骤包括：舱压控制系统能力概念到系统功能活动概念的转化、追溯，功能活动流程中资源流的定义，全部系统功能执行流程的活动模型的设计。

舱压控制系统的功能活动流程概念需要依据上述步骤中建立的需求概念与能力分级描述模型。以系统需求为主体，结合能力分解关系，分析舱压控制系统的主要功能活动，并明确系统的主要运行场景，即包括起飞、爬升、巡航、下降、进近、停机6个正常飞行阶段与自动控制故障时的应急状态。

实例将舱压控制活动视作由飞行信息检测、增压控制（正常与应急状态）、舱压显示等子活动集成功能活动。绘制的OV-1舱压控制系统高层运行概念图如图10所示。

图10 OV-1舱压控制系统高层运行概念图Fig.10 OV-1 high level operational concept graphic of cabin pressure control system

OV-2舱压控制系统活动资源流负责描述舱压控制系统不同功能执行活动之间的资源流流向。在OV-1分解出的多项子活动基础上，定义各个活动之间的资源交互情况。需要说明的是，应考虑子活动与其他系统（非舱压控制系统）之间的资源流向与资源种类，定义系统范围（Region）界定舱压控制系统边界。

实例中定义的OV-2舱压控制系统活动资源流如图11所示。舱内外压力检测会持续将采集到的大气压力与座舱压力信息传递给增压控制活动所需部件，然后将计算得出的增压信号传递给作动机构，执行座舱增压；座舱压力信号同时传递给座舱显示系统完成舱压显示活动，为驾驶员实时更新舱内外压力情况并在应急状态下发出警报，其中舱压控制活动中需要的空地信号来源于通信系统。

图11 OV-2舱压控制系统活动资源流模型Fig.11 OV-2 operational resource flow description of cabin pressure control system

通过建立OV-5b运行活动模型、OV-6c事件追踪描述模型、OV-6b运行状态转换模型来完成系统功能执行流程的活动模型的设计。OV-5b舱压控制系统运行活动模型针对OV-1中提出的多种功能活动分别进行建模。

需要说明的是，运行活动模型OV-5b应覆盖OV-1中定义的所有运行场景与运行状态下的每一种功能活动。比如舱压控制系统正常运行状态下存在自动控制、人工控制2种活动流程，也应考虑不同阶段控制活动模型存在的差异，以及自动控制失效情况下切换到备用模式或人工模式的活动流程等。

实例中，建立的巡航状态下的舱压系统自动控制活动模型如图12所示，巡航状态下舱压控制活动首先测量大气与座舱压力，经过信号调理后与设定的压力制度进行对比解算，判定是否满足乘员需求，若不满足，则发出驱动信号控制活门开闭，执行座舱压力控制。

图12 OV-5b舱压控制系统运行活动模型Fig.12 OV-5b operational activity model of cabin pressure control system

根据相应的OV-5b运行活动模型，定义OV-6c舱压控制系统事件追踪描述模型，时序图主要以活动之间的信息流动为节点，表明参与者与系统内部的活动顺序，以及每一个活动执行的数据内容和流向。

图13为巡航状态下的舱压自动控制模式下的OV-6c事件追踪描述模型：环境信息检测活动贯穿整个运行周期，增压控制活动依次完成压力信号调理、压力制度比对与计算、发出作动信号等活动，最终控制活门开闭完成增压控制。

图13 OV-6c舱压控制系统事件追踪描述模型Fig.13 OV-6c event-trace description of cabin pressure control system

依据建立的舱压控制系统OV-5b、OV-6c模型，分析形成舱压控制系统的OV-6b状态转换描述模型，如图14所示。舱压控制系统在开机、待机状态完成后，优先进入自动控制状态，并同步实时执行系统状态检测，主自动控制系统失效后切换至备份自动控制系统，自动控制系统失效即转入人工控制状态，二者皆失效后触发舱压控制系统应急模式。图14中正常运行状态、应急状态、自检状态定义为系统的复合状态，即可在各状态内部继续定义系统子状态。

图14 OV-6b舱压控制系统状态转换描述模型Fig.14 OV-6b state transition description of cabin pressure control system

3.4 面向物理架构的系统视角（SV）模型建立

本步骤包括：功能活动到系统具体部件的映射分析设计，功能活动到系统部件追踪关系表示，舱压控制系统接口信息建模，部件与不同系统交互关系分析。其中，功能活动到系统具体部件的映射由SV-4系统功能描述模型表示，该模型将系统主要活动分配到相应组件上。

需要说明的是，对于一个系统功能执行流程，可能会形成多个SV-4系统功能描述模型，即多种不同的设计方案，此时可以依据AV-1需求概要信息模型中定义的决策准则（也可以在需要时再行补充），经过设计部门组织讨论后进行方案决策。

图15所示为一个舱压控制系统部件的整体架构组成：通过不同传感器实时监视大气与座舱压力情况，利用数字控制器完成信号调理与控制解算、活门完成增压控制，并在座舱显示系统显示舱压信息与警报信号。

图15 SV-4舱压控制系统功能描述模型Fig.15 SV-4 systems functionality description of cabin pressure control system

对于已选定的SV-4系统功能描述模型，其可以存在多个视图，表示系统的不同层次上部件的分解。在实例中，图15建立的系统功能描述模型中可对活门中控制、执行组件进行进一步分解，如控制组件采用电动扭矩马达、执行组件采用作动筒等。根据设计进程，不断补充更多层面的SV-4视图来完善更底层的设计方案。

在SV-4描述的部件架构基础上，撰写SV-1舱压控制系统接口描述模型。SV-1不仅表示了信息内容及传递方向，而且明确了数据传输格式，如数字控制器以电流或电压形式的电信号传输给活门控制组件，舱压告警系统以灯光闪烁、蜂鸣警报提醒机组成员等，如图16所示。

图16 SV-1舱压控制系统接口描述模型Fig.16 SV-1 systems interface description of cabin pressure control system

功能活动到系统部件追踪关系使用SV-5活动-系统跟踪矩阵，如表2所示。

表2 SV-5舱压控制系统的活动-系统跟踪矩阵Table 2 SV-5 operational activity to systems function traceability matrix of cabin pressure control system

同时，定义的各组件并不一定仅参与到座舱压力控制系统中，SV-3系统-部件跟踪矩阵在一定程度上描述了舱压控制系统内部组件参与到其他各系统的情况，例如大气、舱内压力等传感器属于飞行环境监视系统，同时会将监测信息传递给飞行管理系统等完成其他民机系统功能。在民机整体设计中，结合其他相应系统的系统模型，对各组件应实现的功能及民机整体架构有更全面的刻画，舱压控制系统的SV-3系统-部件跟踪矩阵如表3所示。

表3 SV-3舱压控制系统的系统-部件跟踪矩阵Table 3 SV-3 systems-component tracking matrix of cabin pressure control system

需要说明的是，上述步骤并非纯粹的线性步骤。在每一步建模过程中，均可依据该步的实现需要对之前步骤中建立的模型进行增添补充或修改，但是应建立系统基线来完成版本控制，留存变更的历史记录与历史系统模型。

4 结论

首先，对比分析了MBSE方法论的架构特点，考虑了现代民机设计中以需求为驱动、关联众多利益相关方的正向设计趋势，提出了MBSE方法论指导下的民机正向设计流程，建立起“需求-功能-逻辑架构-物理架构”的映射和关联关系。然后，考虑到民机系统在对内对外复杂交互设计体系下各级系统的交错耦合，引入了DoDAF、UAF的多视角，对民机设计过程进行了更为全面的描述，从全景、能力、运行、系统视角等视角深入剖析了各视角下模型构建所需的构成要素和逻辑关系，以抽象建模的方式，总结归纳了各设计阶段所建立模型的构建方式和信息交互关系。最后，以民用飞机座舱压力控制系统为实例，采用SysML为建模语言进行建模，无歧义地将每个设计阶段中各视角下的民机系统模型进行描述，以验证提出的建模方法。验证结果表明：

1） 利益相关方需要/需求信息能够通过民机设计体系交互概要模型反映需求来源、架构、交互信息，并将需求信息映射到后续功能研发设计中并建立已开发功能与需求的链接关系。

2） 全景、能力、运行、系统4个视角能够有效建立起对自顶向下、需求驱动的民机正向设计流程的立体描述，更全面地考虑民机正向设计下的对内对外交互情况。

3） 抽象的建模流程详细定义了各模型构建的构成要素和逻辑关系，能够实现民机系统功能与接口需要的无二义性描述。

本文提出的基于多视角的民机正向设计建模方法面向民机系统研发，清晰描述了民机系统详细建模流程，能够有效指导设计人员进行模型构建，契合民机的设计开发工作。