基于MBSE思想的航空发动机控制系统设计方法

2021-08-27 06:54崔利丰郝彬彬文彬鹤

航空发动机 2021年4期

李琛，吴新，崔利丰，郝彬彬，左伟，文彬鹤

（1.中国航发沈阳发动机研究所，沈阳110015；2.中国航发控制系统研究所，江苏无锡214063）

0 引言

随着全权限数字电子控制（Full Authority Digital Electronic Control，FADEC）系统的应用，航空发动机控制系统功能不断扩展，控制变量逐渐增多，系统的复杂度不断提升。在以往研制过程中，控制系统暴露出较多技术问题，其中部分原因是系统设计要求不够详细，设计过程缺失，导致在详细设计实现时存在不确定性，造成设计实现与设计目标偏离。这类问题常常在发动机使用过程中不断地暴露，给试车、试飞带来一定风险。现阶段控制系统研制处于向自主研发的转型阶段，建立正向的控制系统设计能力越来越受到中国工程师的重视。基于模型的系统工程（Model-Based System Engineering，MBSE）的设计方法为复杂系统的设计提供了一种有效手段[1-3]，其核心是按照系统工程的分析过程，将系统需求条目化，并采用数字化、图形化、建模等方式描述复杂系统设计过程，将需求量化、可测量、可追溯，将设计过程可视化[4-5]。

NASA是最早将MBSE应用于复杂系统设计中的科研机构之一，并将其研究结果大量应用于工程实践，极大的提升了设计开发能力和产品质量，在航空发动机控制系统设计领域，通过搭建部件级仿真模型，实现了对发动机性能的分析、预估，开展了军用级、民用级控制系统仿真模型的开发和验证，为FADEC系统的快速成功研制奠定了基础[6-8]。近些年，中国高校和航空航天院所才开始使用MBSE方法开展工程设计，初步理解了MBSE设计理念，构建了基础的MBSE设计工作流程和设计方法[9-11]；张天宏等[12]将实时仿真技术应用于控制系统设计中，并指出基于模型的设计方法是开展控制系统正向设计不可缺少的重要手段。目前，中国控制系统设计多基于文本的形式提出，面临的主要问题包括：（1）需求方与承研方对于需求的理解存在偏差，导致某些功能和性能不符合发动机的实际需求；（2）仅包括功能要求和性能概要要求，且每项要求的具体实现方法描述不够清晰；（3）需求零散，无法将需求完整、有机地结合起来。

鉴于中国对MBSE方法研究正处于起步阶段，本文从顶层需求角度出发，结合MBSE的设计思想，探索一种发动机控制系统正向设计方法。

1 MBSE设计思想

1.1 MBSE概述

MBSE是近年系统工程的一种全新探索，基本原理仍然是V字模型，如图1所示。

图1 系统研发V字模型

系统工程国际标准委员会给出的MBSE定义：规范化的应用建模技术来支持系统需求、设计、分析、验证与确认，从概念设计阶段直至生命周期的后期各个阶段，持续贯穿整个产品的开发[13]。其核心思想是通过对系统建模，把待研究系统的特性抽象出来，并用数字化、标准化、图形化等形式，将设计过程描述出来[14-15]。

1.2 MBSE特点

MBSE是区别于传统的基于文本的系统工程（Text-Base System Engineering，TSE）而提出的，目的是为了解决传统系统工程存在的诸多问题。传统的TSE主要是基于文本、语言的形式来描述需求，由于语言描述内容丰富，并多采用形容词等模糊描述，导致需求的一致性和准确性差，需求传递过程中产生偏差，并且基于文档难以实现对需求的追踪，当出现设计变更时，难以对变更进行准确评估。

MBSE相对于TSE优势如下：

（1）需求条目化。需求多依据功能实现提出，如发动机控制系统应具备让发动机停车的能力，内容含义丰富，无法直接用来进行系统设计。MBSE采用将需求中的名词、形容词、动词等通过数字化、程序化的形式表达出来，将顶层需求条目化，从而实现需求的向下分解。

（2）语言量化描述。在以往的设计要求中大量采用描述性语言，无法明确地表达具体的内容含义。例如，发动机高原起动简单描述为：发动机应具备高原起动能力。那么如何才算是具备高原起动能力？将语言量化后，表述为：发动机应具备在不低于2000 m的高原上起动能力，起动时间不超过60 s，起动过程中排气温度不超过500℃，起动成功率不低于98%，如图2所示。将需求量化后才可保证需求无歧义，并且后续可验证。

图2 高原起动能力验证

（3）设计过程显形化。通过系统的输入、输出直接定义系统的行为，被称为“黑盒式”设计，对于简单系统的设计可以这样做，但是对于发动机控制系统这种内部变量多、功能逻辑复杂的系统，若对内部设计过程不关注，一旦出现问题，后果是十分严重的。

控制系统多采用闭环控制方式，其原理如图3所示。在以往的研制过程中，通常直接交由下游设计单位开展设计，若不了解内部的设计过程，在发动机试车验证时出现问题，会造成设计反复，影响研制进度。

图3 闭环起动原理

MBSE采用“白盒”设计思想，将内部设计过程显形化，设计流程清晰PID参数设计技术路径如图4所示。

图4 PID参数设计技术路径

对上述过程进行参数化建模，如图5所示。把闭环参数设计黑盒子解耦，将每项设计过程通过建模的形式展现，当在使用中出现问题时可以及时追溯，并快速开展仿真验证。

图5 参数设计过程建模

（4）逻辑功能完整。正常状态的功能逻辑实现简单明了，通常也可满足预期的要求。但完整的系统设计应包含正常、非正常和故障工作状态下的表现行为，且后2种情况下系统的工作状态决定了系统设计能否满足顶层的安全性要求。MBSE通过建模可将系统的各种工作状态（如对信号故障表决过程）均定义完整，信号表决模型见表1。

表1 信号表决模型

2 基于MBSE的控制系统设计

本文主要针对需求分析、功能分解、功能描述等过程开展基于MBSE思想的设计方法研究。采用DOORS、Matlab/Simulink、Amesim等软件进行需求管理和参数建模。

2.1 需求分析

需求分析包含对利益攸关者需求的捕获和对需求的确认，以保证需求的无二意性。目前国际上多使用IBM Rational Doors工具来开展需求分析，如图6所示。建立贯穿整个系统生命周期的需求符合性矩阵，，当需求发生更改时，需要更新需求符合性矩阵，保证需求变更可追溯。

图6 需求分析过程

发动机控制系统利益攸关方需求主要包含“Re⁃quirements”和“Domain Knowledge”2方面。“Require⁃ments”可以理解为系统需求文件，应由具备相应工程研制经验的控制系统工程师编制，应包含所有利益攸关方的需求、意见和期望，必须进行跟踪、追溯和控制，需要经发动机和飞机方认可，并且未经允许不得擅自更改；“Domain Knowledge”为领域知识，包括前期工程研究中的设计经验、对故障的分析归零报告、设计体系规范等及发动机的控制要求等，需求内涵见表2。

表2 需求内涵

此阶段将利益攸关方需求转化为系统设计需求，并基于需求管理工具进行需求数字化管理，建立系统设计需求条目，实现利益攸关方-控制系统-子系统各级关键功能、性能指标的100%传递、关联与追溯。

2.2 系统界面确定

界面也可以理解为上下游之间或互相之间开展设计工作的分界线。清晰、合理的界面划分可提升工作效率，避免由于工作界面模糊而造成设计上的推诿。在发动机的FADECs系统设计中，电子控制单元（Electronic control unit，ECU）是整个控制系统的中枢，如图7所示。不仅包含硬件设计，也包含软件设计，而软件在程序、逻辑的执行及系统的运行中都起着关键作用，本文开展设计的核心是依托于电子控制单元对系统软件提出要求。

图7 ECU外部交联关系

把系统设计界面放在ECU上，并定义界面上的输入、输出信号关系，如图8所示。依据在界面上的输入、输出，开展系统设计，并对输入、输出信号进行管理，实现系统设计的完整统一。对于传感器、电缆和液压执行机构等部件，一般是货架产品，成熟度较高，可交下游供应商自行设计完成后提供给主机确认。

图8 输入、输出信号定义

2.3 功能分解

2.3.1 功能定义

按照MBSE的设计思想，对于复杂的多功能系统，需开展功能分析，基于功能将复杂的系统划分为不同模块，要保证功能相对独立，并按照设计使用方便的角度来划分。参考ATA 100美国航空运输协会规范[16]与GJB 4855-2003军用飞机系统划分及编码[17]中对子系统的定义，控制系统可分解为起动、点火、燃油与操纵、发动机控制、发动机指示系统。

基于子系统划分和需求分析，将需求整合划分，定义出不同的功能模块，主要有起动点火停车、控制规律、状态监控、系统保护、电源、维护、热管理、反推控制以及向飞机输入等基础功能模块，如图9所示。而各功能模块的运行都离不开信号的串联，因此将输入、输出独立定义为功能模块。单独定义ECU内部模块用于描述硬件相关需求。依据系统运行模式不同，具体实现功能要求也有差异，基于此考虑定义顶层工作模块“模式模块”，用于控制系统不同使用场景切换。对于不同的系统功能模块划分可依据具体的功能要求增加或减少。

图9 功能模块

2.3.2 功能要求的具体描述

MBSE要求对每项单一功能进行详细地描述，如何通过MBSE思想完整全面地描述系统的功能要求，是本文研究的重点。将功能具体描述为10方面，保证每项功能都可以完整描述，见表3。这样既可以强制要求设计人员在编制要求时更完整地考虑问题，又可以避免设计要求不完整或缺失。

表3 10方面描述内容

通过10方面要求的提出，使得系统设计之初就必须考虑该项功能与系统间的交互影响，详细描述了具体逻辑与计算需求、参数设定等，并明确面对未来可能需要的功能扩展和问题，实现单项功能清晰、准确地描述。

2.4 数据流管理

将各功能模块的输入、输出信号整合为数据字典，定义了系统需要关注的变量，通过数据字典管理输入、输出数据流向，将各功能模块完整、有机地串联，如图10所示。

图10 数据字典

3 设计应用

结合发动机信号模块设计，对上述设计过程进行详细阐述，以N1转速测量为例。

3.1 需求分析

在控制系统顶层的需求中通常描述为：控制系统应准确、可靠地测量发动机的低压转子转速用于发动机的推力控制。

该项需求可分解为几个核心的关键词：低压转子（名词）、转速测量（动词）、准确（形容词）、可靠（形容词）。低压转子，传递了测量对象是发动机的低压转子转速；转速测量，需要考虑转速测量方法，工程上常用测量发动机转速的方法是采用磁电式转速传感器测量；准确测量转速，说明对测量精度有相应要求；可靠地测量，表明测量应具备相应的可靠性，在应考虑故障状态的处置逻辑。通过对关键词的进一步分析，将顶层的军方需求转化为对系统的需求，如图11所示。最后将需求分析过程录入DOORS系统中，用于需求管理和追溯。

图11 需求分解过程

3.2 功能分解

完成需求分解后，对功能实现过程进行定义。转速测量过程可详细分解为产生-测量-使用3个过程，主要包含发动机、传感器、电子控制单元3部分，采用泳道图的形式对功能需求进行定义，如图12所示。前2项仅需把定量的要求向下游传递即可，而其核心复杂的要求在于数字电控制器对信号的处理过程。

试验组45（100.00）的满意度对比对照组满意程度35（77.78）更高，差异有统计学意义（P＜0.05）。

图12 功能定义

3.3 功能描述

完成功能需求分析、功能分解后，按照上文的10项内容对功能进行详细描述。

3.3.1 输入信号定义传感器输入信号如图13所示。信号是传感器直接测量的，未经处理的原始信号。

图13 输入信号定义

3.3.2 输出信号此部分无ECU向外部输出，因此无输出信号。一般在驱动模块才有输出信号定义。

3.3.3 模块间输入信号

定义来自其它模块的输出，如图14所示。信号来自模式模块，因此在模式模块的输出部分一定存在该变量。需注意的是，若这2个模块是由不同工程师设计的，相互之间需要协同定义。

图14 模块间输入信号定义

3.3.4 模块间输出信号

与模块间输入信号相似，模块间输出信号也是本模块产生的，在其它模块中使用，如图15所示。

图15 模块间输出信号定义

3.3.5 单步周期规定了信号处理的最小计算周期要求，应在尽量节省运算资源的前提下保证计算速度满足功能要求。需要注意的是在相同的功能模块内，对于不同信号，计算周期要求可能也不同。选取50 ms作为N1信号的计算周期。

3.3.6 前序要求

N1信号不存在前序信号的处理，无前序要求。

3.3.7 精度要求

精度要求应与具体的工程项目要求相关，并依据顶层的性能指标分解。针对本文研究内容定义采集精度为±0.3%，控制精度为±0.5%。

3.3.8 模块工作要求

N1转速信号从测量采集到最终被转化为可用的控制系统信号，需经过双余度发动机信号处理过程，如图16所示。数字电子控制器采集N1传感器的2个余度，供A、B通道使用，使用前需进行传感器硬件处理、传感器信号验证、真值表计算等3步。

图16 双余度发动机信号处理过程

（1）硬件处理要求。

a.机内检测（Build-in Test，BIT）：该模块包含必要的BIT检测功能（断路、短路、电路参数偏离），并提供诊断结果；

b.信号调理：供应商需保证ECU硬件和软件设计可满足信号采集精度和运算速率的要求；

c.N1信号测量：测量N1传感器的频率信号，将其转化为相对物理转速形式描述的数字信号；

d.最高转速：N1传感器可测最高转速不低于发动机实际正常最大工作转速的160%。

（2）N1信号验证及真值表表决要求。

采用软件对双通道测量信号进行验证，包括双通道极值检测、交叉检测、积分检测等。根据BIT诊断结果和极值诊断结果，给出通道验证状态信息；根据通道验证状态信息进行故障积分诊断，并且将故障积分后的状态反馈给真值表进行信号表决；真值表表决后输出N1信号表决结果及缺省值状态。将文字描述为功能逻辑，如图17所示。