航空发动机FADEC系统全数字模型协同开发与配置管理

（中国航发商用航空发动机有限责任公司 设计研发中心控制系统部，上海 200241）

0 引言

航空发动机FADEC（Full Authority Digital Electronic Control）系统主要由发动机电子控制器（EEC，Electronic Engine Control）、发动机监视装置（EMU，Engine Monitoring Unit）、燃油液压部件、控制传感器、执行机构等组成。FADEC是一种典型的复杂嵌入式系统，具有控制任务多，功能逻辑复杂、控制难度大等特点，其设计安全等级为A类[1,2]，具有极高的可靠性和安全性要求。为提高研发效率和质量，降低研发成本，基于模型的设计（Model Based Design，MBD）[3,4]为航空发动机FADEC系统的设计提供了一种有效的途径。所谓MBD，是将设计过程表述为可执行的规约，使用全数字模型作为载体验证设计的符合性和准确性，MBD有助于更好地权衡FADEC系统设计方案，更早地发现设计缺陷，降低后期设计反复和试验风险，最终缩短产品定型周期。

FADEC系统设计初期，设计人员需要根据航空发动机工作特点和工作方式制定可行的控制规律、诊断与处理算法、故障安全逻辑与策略等。目前广泛采用的设计方法是基于MBD设计流程，借助计算机仿真技术开展需求迭代、功能分析和设计方案权衡，因此，在仿真工作开展之前，开发具有相似度很高的全数学模型就显得尤为重要。当前，FADEC系统全数字模型开发具有如下特点：1）模型开发由单学科演变成多学科人员共同完成；2）模型开发由串行开发过渡为并行开发；3）模型迭代频繁，版本和配置管理要求苛刻；4）模型可移植性，可重用性，易更换性要求高；5）模型开发过程规范化，并逐步向自动化过渡。针对上述特点，如何保证多学科人员并行开展工作，如何有效控制模型配置项技术状态，如何帮助设计人员将精力聚焦于设计工作本身，而不是工具使用和流程流转上，是全数字模型开发和配置管理过程中面临的新问题。本文基于IBM Rational配置管理工具ClearCase和变更管理工具ClearQuest开展了FADEC系统全数字模型的协同开发和配置管理方法探讨，从多方面解决了上述问题。

1 FADEC全数字模型

根据国内外航空发动机FADEC系统研制经验，基于MBD的FADEC原型软件研制过程至少包括全数字模型仿真、全数字软件仿真、软硬件集成仿真，不同层级的被调对象逐步逼近真实机载软件及其运行环境，以保证在所有状态下系统功能、性能得到了严格地确认验证。为实现不同仿真过程中采用同一用例，结果曲线一致的仿真效果，各阶段的数字模型需保持严格的继承关系，如图1所示。为保证模型追溯关系和代码一致性，在全数字模型开发过程中高效协同和配置管理就显得尤为重要。

图1 基于MBD的FADEC系统研制流程

全数字模型仿真发生在软件代码集成仿真之前，借助系统建模与仿真软件（如Simulink）完成对FADEC系统建模、集成与仿真验证。全数字模型主要包括系统环境（被控对象）模型（如飞机、发动机、燃滑油模型）、部件模型（如传感器模型）、控制模型等，主要用于模拟FADEC系统外部环境和控制逻辑。多个型号项目中共用模型、算法、逻辑，可提炼形成通用全数字模型，一般地，其最小单元是系统部件及控制逻辑建模时考虑的最小逻辑单元；型号仿真上使用的全数字模型称为实例化全数字模型，一般地，其最小单元对应型号上每一个具体物理部件，此时FADEC系统方案已确定；基于型号的控制仿真全数字模型除了包括型号实例化模型，还包含控制规律、诊断算法、故障安全策略等在内的控制仿真模型，主要用于模拟型号FADEC系统接收外部指令和各种故障情况下，控制逻辑规律与控制对象之间的交互。通用模型、实例化模型、基于型号的控制仿真模型之间的关系如图2所示。

图2 FADEC系统全数字模型关系

2 协同开发策略

2.1 UCM流

为追踪、管理和控制软件开发过程中的变更，IBM Rational提出了一种基于流（Stream）的软件变更管理方法，解决了不同地域和规模的开发团队对软件变更的控制要求，是用于软件变更管理的“最佳实践”流程，航空发动机FADEC系统全数字模型协同开发和配置管理活动也是基于该“最佳实践”上开展的。

ClearCase提供的统一变更管理（UCM，Unified Changed Management）流功能，一方面将个人工作空间和团队集成空间隔离，减少个人工作对项目技术状态的影响和相互干扰；另一方面，提供了数据的手动提交和自动同步功能，实现个人工作空间和团队集成空间的数据交互，并记录不同空间的数据关联关系。

全数字模型协同开发基于UCM流开展，如图3所示，分三个层级，第一级为集成流，用于存储和发布模型正式版本数据集、建立模型推荐基线，不开展任何研制活动；第二级为调试或测试流，在开发阶段为调试流，在验证阶段为测试流，主要应用于模型集成与测试；第三级为调试或测试子流，主要给开发测试人员使用，可按需设置。

图3 基于UCM流的协同开发策略

各流的研制活动和数据迁移关系如下：调试流从集成流同步数据，用于模型集成以及过程数据的存储和提交，并最终将过程数据提交至集成流受控；调试流可设置多条子流，最终由集成人员将不同子流上的成果手动更新到调试流；测试流用于模型验证、软/硬件集成测试等过程的开展，如果测试中发现模型缺陷，在测试流完成模型修复并将数据同步到测试子流，继续开展后续测试，直到缺陷修复。测试完成后，集成人员提交变更申请，将更改后的模型数据提交至集成流受控。

图4 全数字实例化模型数据结构

为控制全数字模型数据状态，帮助设计人员将精力聚焦于设计工作本身，对相关人员流操作权限进行约束，涉及项目负责人、配置管理人员、集成人员、开发和测试人员。项目负责人申请模型开发代号，由配置管理员根据代号创建工作空间；一级目录由配置管理员创建，二级目录由集成人员创建并由配置管理员检入受控，不允许开发人员修改目录结构；正式基线的建立由集成人员提交基线建立申请，经配置管理员合规性审核，项目负责人审批，最终由配置管理员建立；集成人员负责非正式基线的创建及各流数据的提交和同步；开发和测试人员只对所负责的文件进行数据检入、检出操作，不需额外的工具和流程操作。

2.2 流数据结构

数据在工作空间中合理组织和存放有利于版本追溯与变更控制，也是模型协同开发的基础，通过层次化的协同开发目录结构实现模型数据统一存放和管理。数据结构分类原则：1）按功能划分文件夹类别，不同子模型开发过程的数据隔离；2）不同的配置管理对象（配置项）数据完整，数据可追溯。实例化全数字模型数据结构示意如图4所示。其中，全数字模型的配置项按功能划入不同文件目录，重要配置项（如模型程序、需求文档、设计文档等核心输出物）版本通过在文件夹上加上版本号进行区分，整个全数字模型的升版，不影响其中一个配置项的版本变更。其他配置项如测试用例、测试报告、版本使用说明等只纳入存储范畴，不在数据结构中做版本标识。

3 配置管理

3.1 配置库管理

图5 配置库管理示意图

FADEC系统全数字模型功能逻辑复杂，需要在开发过程中对不同稳定程度的数据版本进行区别控制，以防止重要版本的丢失或肆意篡改。参考国家军用标准[11]要求，航空发动机机载软件配置库分为开发库、受控库和产品库三库，通过配置管理工具，通过基线创建和权限控制实现三库逻辑上的分离。考虑到全数字模型为非机载软件产品，模型配置库分开发库和受控库两库管理，如图5所示。开发库是开发人员进行模型开发、测试、验证的空间，用于收集所有模型开发过程中电子数据（模型、代码、详细设计说明、测试数据等），集成人员可自行建立非正式基线；受控库保存正式基线数据，不开展任何研制活动，配置管理员有操作权限，其他人员仅有只读权限，模型出、入库和配置更改须遵守严格的控制流程。

开发库的工作主要在子流和集成流上开展，通过流功能保持开发人员空间的隔离性，集成人员根据模型开发进展适时地创建推荐基线；开发人员通过复原（Rebase）操作，使各开发子流的基线同推荐基线保持一致，从而使开发成员在同一基础上进行变更活动，当开发人员完成全部开发任务并经过严格测试与验证后，集成人员以流上的稳定版本发起入库流程，审批通过后，配置管理员建立此版本受控流，更新受控库台账，建立模型推荐基线和读写权限，以维护受控数据的安全性与稳定性。为保持数据追溯性，后续的软件仿真和软硬件集成等应用中如需用到受控的全数字模型，需提交出库申请，并在相关文档中说明引用全数字模型版本和及其追溯关系。

通用模型、实例化模型、控制仿真模型的管理过程遵守配置库管理相关要求，模型追溯关系如图6所示。当模型完成全部开发任务，具备入库条件，集成人员需提交入库申请，完成入库受控，入库单中需指明组成全数字模型各子模型版本，用以保持数据追溯关系。实例化模型开发中，对通用模型不做修改，通过增加可调特征参数方式或者新增逻辑模块完成实例化建模；在控制仿真模型开发中，以实例化模型为基本单元，新增定义数据结构，构建相互连接的FADEC系统框架模型，以此框架模型与控制模型联合开展控制仿真。

图6 全数字模型追溯关系

3.2 配置流程管理

航空发动机FADEC系统的复杂性使得模型变更活动越来越频繁，如果对全数字模型变更活动不加控制和管理，会大大增加原型软件设计和验证风险。基于流的开发活动同ClearQuest定义的流程模板关联，保证了全数字模型开发过程中版本控制、基线管理、变更管理、出入库流转等重要技术活动真实有效，保证了数据的一致性和可追溯性。全数字模型配置管理相关流程如图7所示。为保证每次变更在实施前都经过授权，配置流程建立了配置管理委员会（Configuration Control Board，CCB）作为集中管控机构，委员会成员由专业副总设计师、项目负责人、模型集成人员、配置管理员等人员组成，配置流程的操作权限和人员职责由配置管理员统一发布和监督执行。

图7 全数字模型配置管理流程

ClearQuest与UCM流集成的常见流程有：项目建立申请、基线建立申请、变更申请、出、入受控库申请等流程，如图8所示。

图8 ClearQuest与UCM流集成常见流程

项目建立申请：全数字项目需求提出后，触发项目建立申请。项目负责人按需发起项目建立申请，通过审批后，配置管理员建立配置管理项目代号和工作空间。如需调整项目描述、人员等信息，或增减项目子代号，项目负责人需发起项目变更流程。

基线建立申请：基线标志着模型开发过程一个阶段工作的结束，是重要的模型数据集。全数字模型项目通过评审，由模型集成人员发起基线建立申请，通过审批后，配置管理员在集成流上建立稳定版本的模型基线，作为后续模型使用的推荐基线。

入库申请：全数字仿真模型已完成建立第一个基线，为便于后续变更管理和出库使用需要，保证此版不被最新数据同步，需提交入受控库申请。在库中的版本为可提供后续使用的正式有效版本。

变更申请：模型已入库受控，由于需求变化，在重新完成模型修复并测试通过后，集成人员提交变更申请，该流程自动触发基线建立流程和入库流程，在完成变更申请后，模型新版数据集再此作为推荐基线入受控库管理。

出库申请：全数字模型应用于软件仿真或软硬件集成仿真时，模型使用者需办理出库申请；通用模型库可直接调用，无需办理出库申请。

4 应用效果

中国航发商用航空发动机有限责任公司控制系统部较早的开展FADEC系统全数字模型协同开发和配置管理的研究与探索，根据全数字模型开发和仿真特点，公司制定了体系化的模型开发和配置管理方法，支持多学科人员分工合作协同开发全数字模型，保证全数字模型整个生命周期过程产生的所有配置项的完整性、一致性、可追溯性。经过多个全数字模型项目的检验，公司已初步形成了FADEC系统全数字模型通用库、专业库、控制仿真模型库，通过模型分层管理和逐级引用，使得原来开发一套全数字模型需要数月时间大幅减少到几周内即可完成，大幅提高全数字模型仿真工作效率和质量。实践证明该方法在FADEC系统全数字模型开发和配置管理中切实可行，一方面，显著提高了复杂模型开发的分工协作能力，加快模型开发进度，另一方面，通过模型配置管理，提升模型技术状态管控能力，提高模型技术成熟度，有助于知识的积累和传承，显著降低开发和管理成本。

5 结束语

本文针对航空发动机FADEC系统全数字模型开发与管理难题，提出了一种模型协同开发和配置管理方法，并在民用航空发动机FADEC系统研制中取得了初步应用效果。由于篇幅所限，本文只选取了几个方面进行了介绍，实际的管理方法更加流程化和体系化，确保管理方法的合理性和可操作性。后续将进一步研究FADEC系统全数字模型协同开发和配置管理特点，对协同开发和配置管理方法进行持续改进和优化，通过已有工具的二次开发及与其他工具的集成，改善模型数据的交互策略，提高模型协同开发自动化程度和过程管控质量；通过模型仿真与需求符合性验证，持续提高全数字模型技术成熟度。