航空发动机FADEC系统数字原型构建技术

■ 高亚辉 王松 朱静 王琴 刘明 / 中国航发控制所

相对于传统的实现方式，基于模型的FADEC系统软件开发可以在前端完成约55%的设计活动，通过更早地发现、解决设计中存在的问题，提高了迭代效率。

航空发动机全权限数字式电子控制（FADEC）系统基于模型的软件开发的工作量大且过程繁复。传统的开发模式是先对主机需求直接进行分解，再传递给软件开发人员进行手工编码和报告，然后在半物理模型上进行验证和调试。这种模式缺少桌面设计过程（即多专业协同，完成信号处理、故障检测、余度管理、故障对策、控制律、健康监视与告警等算法与逻辑的设计建模与模型集成，模型集成前需由各专业设计人员自己完成相应模块的单元测试），在软件完成编码、半物理或台架试验甚至是飞行试验时才会暴露问题，迭代成本和风险都很高；而且手工编码和报告的效率低，无法满足主机日益频繁的变更需求。针对上述问题，创新团队引入了桌面原型技术，如图1所示。通过构建系统级的详细设计数字原型，借助建模仿真手段，将设计与验证活动前移，在软件开发之前先进行设计验证与迭代，从而更早发现设计问题，提高研发效率，具体如图2所示。

图1 桌面原型流程

模型构建

为了降低建模门槛、提高建模效率，创新团队从底层的基准模块库、顶层的通用模型架构和中间层的应用算法共用基础模块（CBB）等3个维度构建基础模型。

基准模块库

创新团队基于Simulink建模元素和Stateflow建模工具，针对FADEC系统的特点开发了基准模块库，主要包括基准逻辑库和基准动态库。基准逻辑库包括若干逻辑建模模块，具备一定复杂度的独立逻辑功能。基准动态库包括各类动态算法，与Simulink自带的传递函数相比，考虑了软件离散化的特性，并增加了状态量的过程控制接口。用基准动态库建模带来的好处是能支持自动代码生成，仿真状态与实际FADEC系统的产品状态更接近，能实现Simulink自带模型库无法实现的工程应用中碰到的各类变种算法。

图2 原路径与基于模型的FADEC系统软件开发技术实施路径对比

通用模型架构

根据FADEC系统的特点，项目构建了通用模型架构。项目研发时，只需在确定的模型架构下设计局部的算法，节省了模型架构的设计时间，保证了不同项目结构的一致性，便于设计结果和设计人员的高效复用。通用模型架构的顶层结构包括飞机模块（plane）、电子控制器模块（EEC）、执行机构模块（actuator）、发动机模块（engine）和传感器模块（sensor）。

应用算法CBB

对于FADEC系统中信号处理、故障检测、余度管理、控制律等一些通用算法，可以整理、封装，形成应用算法CBB库。

仿真验证

建模规范与检测工具

开发FADEC系统建模规范主要出于以下几个方面考虑：一是减少模型及基于模型生成自动代码的缺陷；二是增加模型的可读性；三是规避Matlab工具本身存在的一些缺陷；四是更好地支持验证与确认、报告自动生成等工具的使用；五是专业层面的特殊约束要求。

建模规范主要包括如下几类内容：命名规范、模型体系架构设计、Simulink建模规范和Stateflow建模规范。

为了确保设计人员按照建模规范进行模型构建，创新团队开发了与建模规范对应的模型规则检查工具，设计人员完成建模后，运用该工具对模型进行自动分析检查，对检查出的不符合项进行更改完善。

形式化模型验证

对于集成后的FADEC系统模型，创新团队采取如下分级测试的方式：一是将模型按照系统功能划分为几大部分，如主燃油控制、风扇导叶控制、压气机导叶控制等，借助Matlab自带形式化验证工具（design verifier）对每个功能模块进行修正判定条件（MC/DC）100%覆盖度测试；二是系统模型整体测试，以满足系统需求为主，不要求MC/DC 100%覆盖度。

模型变更

模型设计与仿真验证完后，需要建立模型与需求的双向追溯关系，追溯颗粒度为最小模型模块（对应软件的单元函数），主要有确认设计与需求的符合性和便于变更域影响分析两个用途。

创新团队开发的变更域影响自动分析工具主要有两个功能：如有模型变更，自动识别并筛选出与该模型相关的需求；如有需求变更，自动识别与该需求相关的模型，生成模型清单并可通过超链接定位到模型。

报告生成

为了使设计人员的精力集中在模型设计本身，将繁复的报告撰写工作交给机器，创新团队开发了桌面原型设计报告自动生成工具。当设计人员完成建模、信息注释、数据定义并建立需求与模型的双向追溯关系之后，文档生成引擎从这些数据源提取信息，自动生成符合归档要求的设计报告。桌面原型设计报告数据源关系如图3所示，其中信息注释为记录的关键设计思路，嵌入在模型中的注释模块中，数据字典为所有模型数据。

桌面原型设计报告自动生成工具主要功能有：开发注释插件；模型注释信息提取；基于链接关系提取需求；模型参数信息生成；通用基础模块识别；模型版本差异信息生成；通用、专属信息分离等。

图3 桌面原型设计报告数据源关系

符合性测试与验收

以模型为基准的软件符合性测试验收的对象包括各个层级，除了软件单元测试，其他层级的软件测试模型均为介入式。对不同层级的软件测试采取不同的手段，包括软件代码仿真测试和目标机系统测试等，如图4所示。

软件代码仿真测试

为了加快研发速度，降低对硬件环境的依赖，大量的软件测试工作在仿真下完成，包括开环测试和闭环测试。开环测试在软件部件测试、集成测试和系统测试都有涉及，闭环测试只在系统测试层级涉及。对于开环测试和部件测试，基于模型进行符合性验收的介入方式不一样。在开环测试中，对于基于模型自动代码生成的项目，应用桌面原型完成模型测试和代码测试，将测试结果传递给软件工程师，纳入整个软件测试结果中，对模型产生的代码部分软件工程师不再额外测试。闭环测试的4种方式中有两种与开环测试的方式相同，即将基于模型产生的测试数据传递给软件仿真测试平台，或者将软件仿真的测试数据传递给模型。此外，还有两种在线符合性测试方法。与离线符合性测试相比，在线符合性测试可以实现随机测试输入的注入，即测试人员可以随机任意给出模型和软件的输入，看二者运行结果是否一致。

图4 以模型为基准的软件符合性测试验收方法

目标机系统测试

软件在真实目标机（电子控制器）中运行时的某些时序特征，如低优先级大周期速率组任务被高优先级小周期速率组任务中断等，在仿真测试模式下无法体现，因此软件代码仿真测试层级主要测试软件逻辑，对于时序的符合性测试主要在目标机系统测试层级进行。

针对软件多速率组任务调度与时序特征，需要在常规模型的基础上，额外增加功能模型模拟，这一部分模型模拟目标机本身的时间机制和操作系统调度机制，不参与应用软件的自动代码生成或手工编码。由于目标机本身的时序运行结果是受自身硬件特征和操作系统特征确定，无法通过任务调度模型的仿真数据控制，因此以模型为基准的软件符合性测试方法可以采用如下离线符合性测试方法：将目标机系统闭环测试数据传递给任务调度模型仿真测试平台，将软件测试用例注入到模型，将模型运行结果与软件运行结果进行一致性对比。

结束语

创新团队聚焦航空发动机FADEC系统详细设计，研究了基于模型进行控制与软件开发的主要过程和关键技术，包括模型构建、仿真验证、模型变更、设计报告生成和软件符合性测试验收等环节，达到了降低建模门槛、提升建模质量、实现MC/DC100%覆盖度测试、自动生成符合归档格式的设计报告和对软件的符合性测试验收的效果，并最终实现了提高FADEC系统软件设计迭代效率的目标。