一种控制系统故障处理中的互斥设计方法

2021-04-25吴培亚陈志华周中泽李光旭

空间控制技术与应用 2021年1期

王裙，吴培亚，陈志华，周中泽，李光旭

北京控制工程研究所,北京 100190

0 引言

随着航天器控制系统故障诊断和容错技术的不断发展，针对各敏感器和执行机构的已知故障、未知故障，基于解析模型、知识驱动、数据驱动等的故障诊断与处理算法在不断更新[1-4]，算法数量在增加.故障诊断算法数量的增加，能更好地为控制系统保驾护航的同时，也带来了多种故障诊断交叉耦合触发的情况，导致故障诊断和处理变得复杂.

推力器是航天器控制系统重要的执行机构，是保证航天器正常工作的关键部件，一般在硬件上采用冗余备份[5]设计来保证系统的可靠性.推力器有两类常见故障：推力损失和推进剂泄漏，故障处理均为切换到备份[5].使用故障的推力器会对航天器的稳定运行、安全和寿命造成严重后果[6-8].

本文以控制系统故障诊断与处理中的推力器切换为研究对象，分析了多种故障交叉耦合触发和处理可能导致的推力器切换错误甚至航天器失控的情况，并提出了一种软件互斥设计方法，能有效解决故障交叉耦合触发的互斥处理问题，为后续航天器故障诊断与处理设计提供参考.

1 故障诊断与处理简介

1.1 故障诊断类型与处理原则

控制系统中故障分为两大类：部件级故障、系统级故障.部件级故障是指能够快速将故障定位到明确部件的故障模式，包含敏感器和执行机构的故障情况.部件级故障通常是通过部件自身状态异常或几种不同类型部件之间多方比对诊断出来.系统级故障是指系统指标出现超差或系统出现无法准确定位到明确部件的故障.系统级故障中的系统指标一般为航天器姿态、角速度、喷气量等，在恶劣情况下，多种系统级故障类型会交叉触发.系统级故障检测保证在部件诊断出现漏诊或者误诊情况下的系统安全.

故障处理原则为切换当前的敏感器或执行机构，分为主备份部件之间切换、高精度向低精度部件切换，即尽量切除当前使用的部件，进行统一的系统异构.例如，推力器本身故障造成的故障处理为推力器由主份切换为备份.以姿态角或角速度为系统指标的系统级故障处理，如果当前处于动量轮作为执行机构的控制模式运行，则切换为使用推力器作为执行机构的控制模式运行；如果当前处于推力器作为执行机构的控制模式运行，则推力器由主份切换为备份.以喷气量为系统指标的系统级故障处理，如果推力器切换过一次之后，故障仍未停止，则直接停控，即关闭所有推力器的自锁阀.

1.2 推力器切换流程

推力器作为航天器控制系统的重要执行机构，无论是因推力器本身部件故障触发的故障诊断，还是因系统指标异常触发的故障诊断，对应的故障处理中均涉及到推力器切换.

切换推力器涉及到开关自锁阀和开关电源，开关自锁阀前提条件是推力器电源状态为开.因此，在关闭推力器电源之前，应先关闭推力器自锁阀；在开推力器电源之后，再开推力器自锁阀.基于推力器本身的部件特性，推力器切换操作需要多个控制周期操作才能执行完毕，具体执行流程如表1示例.

表1 推力器切换流程Tab.1 Thruster switching process

表1示例中，航天器搭载的推力器有A、B两份，Ts代表控制周期，一般为几十至几百毫秒.第20Ts开启哪份推力器的具体逻辑依航天器方案设计不同而不同.可见推力器的切换操作需要多步骤才能完成，每步操作依据均为上一步骤的操作结果，总共需要消耗35个软件控制周期才能彻底完成.

通常来说，在航天器控制系统软件设计中，每种类型的故障诊断方法均设置相应的故障诊断允许标志CW和故障告警标志W，在故障诊断允许标志CW=1的情况下，才进行故障诊断，当诊断出故障时，会置故障告警标志W=1.在故障诊断允许标志CW=1且故障告警标志W=1的情况下，才进行相应的故障处理.以推力器切换为例，故障处理调用关系如图1所示.

随着对航天器在轨故障问题的举一反三以及控制系统可靠性、健壮性要求的不断提高，航天器控制系统故障诊断算法也随之不断更新和增加，导致涉及推力器切换操作的故障类型不再是一种，而是多种，且多种类型故障可能同时触发.当多种故障交叉耦合触发和处理时，如图1所示的软件设计方法存在着推力器切换时序冲突和推力器切换错误的问题.

图1 推力器切换调用关系图Fig.1 Call relationship of thruster switching process

2 系统级故障处理耦合分析

推力器切换操作对控制系统而言是个重要操作，需要多个控制周期才能完成，一旦开始执行，必须保证不被打断地执行完成，否则将造成推力器切换错误、整星异常停控的严重影响.

以姿态角过大、角速度过大、喷气量异常等为判断指标的系统级故障，当星上出现某种异常情况时，会导致两种甚至多种系统级故障同时触发或短期内先后触发，即可能存在图2～4所示的故障触发时序.

图2中，当星上某种故障原因导致故障1发生，故障1对应的软件处理是推力器切换.在推力器切换第10Ts～20Ts中，又发生了故障2，故障2对应的软件处理也是推力器切换.由于此时故障1处理中已将推力器A和B电源都关闭，因此故障2推力器切换中保存的推力器电源状态错误，导致故障2推力器切换错误.

图2 推力器切换与其它故障交叉耦合示例1Fig.2 Example 1 of fault disposal triggering during thruster switching

图3中，当星上某种故障原因导致故障1发生，故障1对应的软件处理是推力器切换.在推力器切换第1Ts～30Ts中，又发生了故障2，故障2对应的软件处理是停控(关自锁阀).由于此时故障1处理中第30Ts会将自锁阀打开，因此故障2处理中的停控失败.

图3 推力器切换与其它故障交叉耦合示例2Fig.3 Example 2 of fault disposal triggering during thruster switching

图4中，当星上某种故障原因导致故障1发生，故障1对应的软件处理是推力器切换.在推力器切换第1Ts～35Ts中，又发生了故障2，故障2对应的软件处理是转控制模式.由于转控制模式会重新初始化故障诊断允许标志和故障告警标志，导致执行一半的推力器切换不再被调用，即推力器切换中止，最终推力器切换失败.

图4 推力器切换与其它故障交叉耦合示例3Fig.4 Example 3 of fault disposal triggering during thruster switching

由分析可知，在进行推力器切换过程中，可能存在切换错误、未执行完异常终止、停控执行失败的时序冲突：

1)若先后在短时间内发生两次推力器切换，会导致切换时序错乱；

2)若推力器切换未结束，又发生了停控，则停控失败；

3)若推力器切换未结束，又发生了转控制模式，则推力器切换异常终止.

4)若短时间内发生了三种及以上的故障，则时序分析更加复杂.

3 故障处理中的软件互斥设计

本节提出了一种故障处理中的软件互斥设计，解决故障交叉耦合触发和处理引起的时序冲突问题.

推力器切换需要多个控制周期才能完成，在这过程中不能被打断.软件设计要解决的三个难点问题:

(一)两次推力器切换短时间内先后发生，导致切换错误；

(二)推力器切换过程中又发生了停控，导致停控失败；

(三)推力器切换被异常终止.

为解决问题(一)，软件设计如下：(1)把推力器切换流程操作，单独封装，对外提供接口S、t，S=1表示在正在进行推力器切换流程，S=0表示不在进行推力器切换流程，t为推力器切换程控计数.(2)在故障处理中进行推力器切换时，操作S、t值即可.

推力器切换处理封装模块见图5，当S≠1时，不执行切换处理流程；当S==1时，t++时，当t==1执行推力器切换步骤1，当t==10执行推力器切换步骤2，当t==20执行推力器切换步骤3，当t==30执行推力器切换步骤4，当t==35执行推力器切换步骤5，并置S=0，即退出推力器切换处理流程.

图5 推力器切换处理模块流程图Fig.5 Flow chart of thruster switching process

故障处理中进行推力器切换调用设计如图6，当S==0时，置S=1，t=0，满足推力器切换模块执行条件，当S≠0时，不进行处理，即不会在推力器切换未结束时又开启新的推力器切换.

图6 推力器切换程控的调用流程图Fig.6 Scheme of thruster switching process

为解决问题(二)，软件设计如图7，需在无推力器切换时或等待推力器切换完成后进行停控处理，即当S==0时，才进行停控处理.

图7 停控处理的调用流程图Fig.7 Scheme of stop control dispose

为解决问题(三)，软件设计为，把推力器切换模块，独立于模式控制和故障诊断与处理，每个软件控制周期都能被调用.推力器切换流程一旦被调用，无论故障诊断允许标志、故障告警标志是否变化，推力器切换程控都能被执行完成.

图5～7所示的软件互斥设计，将推力器切换模块，独立于模式控制和故障诊断与处理，推力器切换流程一旦启动，则不受控制模式转换的影响，不会被打断.在推力器切换过程中置S=1，在所有涉及到推力器切换相关的故障处理中先判断S的值，当S=1时，则说明当前有推力器切换，不再重复执行推力器切换，可保证推力器切换正确.