载人航天器在轨自主健康管理系统体系结构及关键技术探讨

梁 克，邓凯文，丁 锐，张 森

(中国空间技术研究院载人航天总体部，北京100094)

1 引言

目前载人航天器健康管理以地面飞行控制为主，飞控人员开展数据监视、故障诊断和处置工作。对于影响航天员生命安全以及整船(器、站)能源、姿态、天地通信等平台安全，且实时性处理要求高的故障，载人航天器设计了相应的安全模式，可在轨自主处置，为地面处理争取时间［1］。

但是载人航天器组合体构造复杂化、任务多样化、在轨运行长期化的发展趋势对航天器在轨自主健康管理的能力提出了更迫切的需求。主要体现在:

1)为了支持多个载人航天器在轨构造复杂的组合体，同时开展越来越丰富的科学任务，航天器的设计变得复杂［2］。相应地，航天器的故障模式也迅速增长。传统的健康管理模式对飞控人员的数量配置、业务素质要求高，导致航天器运营成本居高不下;

2)载人航天器在轨运行时间越来越长，地基、海基、中继等宝贵的测控资源不可能为载人航天器长期独占［3］。这也需要航天器能自主地开展健康监测、故障定位、故障处置等健康管理工作;

3)航天员在轨驻留时间更长，当发生舱压异常、失火等影响航天员生命安全故障时，需要及时发现并自主开展应急处置，以确保航天员安全，为地面处理争取时间;

4)在故障发生时，航天器本身应具有一定的判断和自动维护能力，以减少航天员的工作量，使航天员有更多的时间完成更复杂的工作;同时，在航天员参与故障诊断和处置的情况下，航天器具备在轨自主健康管理的能力可以降低航天员开展故障诊断、处置工作的难度和复杂度。

本文提出了一种载人航天器自主健康管理系统的体系结构，并进一步研究了相关关键技术。

2 在轨自主健康管理定义

航天器自主健康管理是指航天器能够对自身状态进行监控和感应，对出现的故障能够自主进行检测、隔离和恢复［4-5］，是航天器自主运行的重要保障。

和其他类型的航天器相同，载人航天器健康管理包括船(器、站)载健康管理系统和地面健康管理系统两部分［4-5］。对于判据明确且有可自主实施的处置预案的故障，由船(器、站)载健康管理系统负责;对于不能由船(器、站)载健康管理系统自动检测或无处置预案或处置预案不可自主实施的故障，由地面健康管理系统负责。

与卫星等无人航天器不同，载人航天器在轨自主健康管理系统将考虑航天员的参与性，在航天员驻留期间，航天员可按照预先设定的故障诊断策略参与故障的定位，也可开展故障处置的工作。即载人航天器自主完成或者由航天员参与完成的健康监测、诊断和处置都属于在轨自主健康管理的范畴。

3 在轨自主健康管理系统体系结构

借鉴现有航天器自主健康管理系统的设计思想［6-7］，本文提出的层次式载人航天器在轨自主健康管理系统体系结构如图1所示，包含基础服务层和自主健康管理层。其中基础服务层提供支撑在轨自主健康管理所需要的基本功能，自主健康管理层包含了实现在轨自主健康管理所需要的健康监测、故障定位、故障处置(决策和执行)功能。不同的服务部署在不同的硬件设备中，比如仪表分系统相关设备提供人机交互服务，各分系统计算设备都提供网络通信服务，自主健康管理层的功能主要由自主健康管理主机和各分系统的主控计算机完成。

图1 载人航天器在轨自主健康管理系统体系结构Fig.1 On-orbit health management architecture for manned spacecraft

3.1 基础服务层

基础服务层所提供的服务描述如下［6-7］:

1)天地通信服务。提供载人航天器与地面之间通信的手段，既可以将航天器的健康信息、故障诊断以及处置的过程和结果下行地面，地面也可以通过上行指令或注入数据来禁止、使能在轨自主健康管理功能，并随时中止自主健康管理过程。该服务由测控通信分系统提供［8］。

2)人机交互服务。为航天员提供监视自主健康管理过程甚至参与其中的手段。航天员利用该服务可获知航天器的健康信息、故障处置的过程和结果。同时，采用一种人机互动的方式，让航天员参与故障诊断和故障处置(航天员依据自主生成的诊断和处置策略，实施需要其配合完成的操作)。人机交互支持声、光、电等多种形式。该服务由仪表分系统提供［9］。

3)网络通信服务。提供航天器内部(舱段内、舱段间)信息交互的手段。载人航天器采用多层1553B总线网络，自主健康管理主机要实现多条总线上的设备的健康管理，而分系统的主控计算机既要通过高层次总线接收自主健康管理主机的管理，也要通过下一层次的总线实现区域内设备的健康监测和部分管理功能。载人航天器采用以太网通信技术实现音频、视频、载荷等设备之间的大流量数据交互。

4)遥测处理服务。提供设备健康信息，并对故障诊断过程和结果中的遥测数据进行采集、组帧和存储。该服务由1553B总线和以太网总线终端提供。遥测数据建议由专门的大容量存储设备集中存储，以减少分散存储带来的管理代价。

5)指令处理服务。根据故障处置策略，执行相应的指令序列，实现设备开、关、工作模式转换等。分系统的各主控计算机均应能提供故障处置策略中可能涉及的指令的处理能力。

6)在轨维护服务。提供自主健康管理系统在轨升级的功能。通过在轨维护，可更改或增加新的诊断策略、故障模式及处置策略。该服务由分系统各主控计算机提供，包含2个层次:①参数级维护，如更改故障的判断门限;②函数级维护，如增加新的故障预案。

3.2 自主健康管理服务层

与现有自主健康管理系统［6-7］不同的是，本文运用了Boyd所提出的OODA(Observe-Orient-Decide-Act)循环［10］思想构建自主健康管理服务层，将在轨自主健康管理分解为健康监测、故障定位、故障处置决策、故障处置执行四项子行为。

1)健康监测

在船(器、站)载产品测试性设计的基础上，能够利用先进传感器及其它检测手段，检查部件、分系统或系统的功能和性能，充分获取航天器健康状态信息。当发生故障时，调用“遥测处理服务”将健康信息实时(测控条件允许)或延时(无测控条件)下行地面。必要时，调用“网络通信服务”、“人机交互服务”告知航天员。

2)故障定位

利用先进的故障诊断数据处理与分析算法，在发生故障时及时定位或者隔离故障。定位的过程可由航天员配合完成。若在航天员参与情况下仍不能完成故障定位时，则退出自主健康管理的模式，交由地面飞控人员处理。

3)故障处置决策

故障处置过程按照故障类型采取分级处置的策略。处置策略包括:①单机功能降级、复位或重新加载;②切换备份部件;③分系统功能降低、单机设备切换实现功能重组;④切换应急模式、系统降级或重构。

4)故障处置执行

故障处置执行由分系统主控计算机以及各设备终端配合完成。按照故障处置的方案、故障诊断的需求完成对指令序列的处理，实现设备的开、关、工作模式转换等操作。

5)基于OODA循环的交互模型

采用OODA循环的思想设计健康监测、故障定位、故障处置决策、故障处置执行四项子行为的交互模型。应用多价π演算采用自顶向下的方法对其进行形式化建模［11］。

(1)自主健康管理的模型

即自主健康管理行为由“健康监测”、“故障定位”、“故障处置决策”和“故障处置执行”四个子行为通过并发算子合成，并且无限循环。

(2)“健康监测”子行为的模型

通过sense通道获取参数数据，通过observed将融合后的健康信息输出给“故障定位”;其他行为通过通道fbob将其反馈输入到“健康监测”。

(3)“故障定位”子行为的模型

“故障定位”子行为通过通道observed得到“健康监测”结果，并将定位的结果通过通道oriented输出;通过通道fbob，可以根据故障定位的需要指导“健康监测”子项开展更深入、更有针对性的检测;通过通道ctrla，可以根据故障定位的结果指导“故障处置执行”。

(4)“故障处置决策”子行为的模型

“故障处置决策”子行为通过oriented通道得到“故障定位”的结果;通过decided将生成的故障处置方案输出;通过通道fbob对“健康监测”行为进行调整，使其更新监测健康的对象和操作顺序等。比如按照故障处置方案增加检测的参数。

(5)“故障处置执行”子行为的模型

“故障处置执行”通过通道decided接收“故障处置决策”行为输出的故障预案;通过通道interact输出故障预案执行后对系统的影响;通过通道fbob向“健康监测”输出反馈信息。

上述交互模型包含了在轨自主健康管理过程中的多个循环，这些循环的动态演变并行开展，相互交互，最终实现准确、高效的自主健康管理。

4 关键技术研究

基于第3节提出的在轨自主健康管理体系结构，以空间站为例，结合任务要求和特点，本节研究了相应的关键技术。

4.1 分级分层的服务部署技术

空间站站载健康信息的采集、传输以及处置指令的分发、执行主要依靠系统网实现。空间站系统网采用全总线的设计思路，每个舱段使用多条1553B总线作为系统网主总线，主总线挂接了各分系统的主控设备，且分系统内部采用了二级1553B总线，完成分系统内指令、遥测、注入数据等通信数据的传输［12］。

空间站健康状态包括能源、热管理、载人环境、姿轨控、信息、舱体结构等各功能系统的信息，每个功能系统的健康信息需要包含各个设备的工作状态。因此空间站健康信息的种类及数量多，且故障模式复杂。

针对上述特点，空间站将在轨自主健康管理的服务分级分层地部署在各类计算设备上:

1)对于影响局限于分系统内部的故障，相应的监测、定位、处置等服务由各分系统负责实现;对于需要多个分系统配合完成或者影响平台及航天员安全的重大故障，相应的健康管理服务由整站的自主健康管理计算机(数管分系统的核心处理单元)完成。

2)在轨自主健康管理各服务部署在分系统各类计算机中，其中数管分系统的核心处理单元实现了系统级的健康监测服务、关键故障的定位及处置服务;各个分系统的控制器实现了分系统级的健康监测服务、分系统内部故障的定位及处置服务，并将健康信息传递给核心处理单元;区域/专用控制器实现了底层的采集功能，为上层健康监测提供信息，同时实现指令控制功能，以执行故障处置的决策。如图2所示。

分级分层的服务部署使得空间站自主健康管理系统具有更快的故障响应速度，减轻了核心处理单元的计算负荷以及主干网络的通信负荷。同时各类计算机采用了不同处理速度的处理器芯片，提高了系统资源的利用率，节省了设计成本。

图2 在轨自主健康管理服务在各类计算机上的部署Fig.2 Deployment of health management service on different types of computers

4.2 分类故障诊断技术

根据故障的类别，采用分类故障诊断技术。

对于影响平台及航天员安全的紧急重大故障，如座舱失压失火、能源故障、姿态翻滚、推进管路泄露等，宜采用极限检查的方式进行故障监测(判断关键参数是否处于正常工作范围)［13］，以提高故障判断的可靠性以及故障发现速度。故障发生后快速设置，进入安全模式。故障定位以及后续处置由地面负责。

对于非紧急重大故障，可采用基于模型的检测方法。将系统当前状态同预先设定的数学或解析模型进行对比，发现故障后，采取分层诊断的策略。对于不涉及与其他分系统接口的故障，或者通过健康信息可以在本分系统内定位的故障，由分系统的主控计算机或者航天员参与完成故障诊断;对于需要其他分系统配合完成的故障诊断，由分系统主控计算机交给自主健康管理主机完成。

采用“基于故障树的故障诊断方法”［13］。故障诊断时，以故障树为依据逐层进行准确的故障定位。一种简化的办法是，可以在故障发生时首先与最小割集比较，以期实现快速定位。

准确的故障诊断要求系统设计时要充分开展可测试性设计，力争可认知故障的故障检测率和故障隔离率达到100%。

以能源系统的故障为例，当出现太阳电池翼、驱动机构、配电系统故障等紧急重大故障时，发电能力将降低，电池放电深度增加。核心处理单元采用极限检查的方式进行故障的监测，选取电池放电深度超过门限值作为判决条件。故障发生后，核心处理单元自主清除后续飞行程序，并关闭负载来降低空间站的功耗，使飞行器进入平台能源安全模式，等待地面进一步处置。

当出现其他非紧急重大故障时，某一时段功率通道能量不平衡，即储能电池在阴影区的放电容量不能在阳照区得到有效充满。由总体电路分系统的能源管理器采用基于模型的方法进行故障监测。故障发生后，将未达到能量平台的功率通道上的双母线供电设备切换到另一通道上，或者按照负载优先级列表依次关断该功率通道上的负载。

能源管理器采用“基于故障树的故障诊断方法”，进一步确定故障的位置，并按照策略进行处置。需要航天员参与的，由航天员按照既定的方法和操作步骤开展诊断和处置。

4.3 基于在轨维护的故障模型配置技术

由于空间站系统复杂，且计算存储能力、通信带宽有限，考虑到可靠性、安全性的原则，在空间站运行初期在轨自主健康管理系统只处理故障判据明确，且处置较为简单的故障。但随着在轨飞行数据的积累及地面充分验证，对于故障模型及诊断、处置策略可以确定的故障，可移交给在轨自主健康管理系统完成。

综合考虑灵活性可知，自主健康管理系统对故障模型的配置需求至少体现在以下方面:

1)故障的判据、故障诊断的方法、故障处置的策略应支持在轨更改;

2)应支持地面飞控人员对任一自主故障管理功能的使能和禁止;

3)应支持增加新的故障模式。

按照4.1节描述，健康监测、故障诊断等服务主要部署在核心处理单元及各分系统控制器中，因此要求上述计算机具备软件在轨维护功能，可采用的方法包括［14-15］:

1)固定地址参数的维护方法。将需要在轨修改的参数分类整理，通过设计地面注入数据块的方式，在需要时对这些参数进行更改。这种方法简单实用，适用于故障判据的配置;

2)基于模块地址划分的方法。适用于EEPROM/FLASH+SRAM架构。维护对象是软件构件或模块。这种方法需要在软件设计阶段就充分考虑结构化和模块化设计，尽可能使软件结构低耦合、高内聚;

3)基于钩子函数的方法。适用于PROM+SRAM架构的系统，在软件中预埋钩子，在SRAM的程序注入区上注入一段代码，钩子函数在执行时通过指定的地址跳转到注入区运行注入的函数，运行完毕后再返回/退出原函数继续执行，这样就可替换原函数的功能。

其中“固定地址参数的维护方法”适用于故障判据的配置，后两者适用于故障诊断方法、处置策略的配置，以及新型故障模式的添加。

4.4 基于构件的软件实现技术

构件是被标准化的可重用的软件资源［16］。基于构件的开发是在一定构件模型的支持下，复用一个或多个软件构件，通过组合的方法高效率、高质量地构造应用软件系统的过程。

以“健康监测”为例，一种简化的构件定义如图3所示。健康监测构件(HealthMonitor)包含了三个外部可访问的接口:

1)GetHealthInfo()，获取当前的状态信息;

2)CtrObjList()，更改健康检测的设备列表;

3)ModifyMonitorParam()，更改健康检测的参数，如检测周期、检测算法等。

故障诊断构件FaultDetection可以通过上述接口实现对HealthMonitor的访问。

HealthMonitor同时定义了两个私有的内部接口，DeviceCheck()实现对单台设备的检测，RunOneCycel()定义了一个完整的健康检测周期内需要进行的操作，其中包括了对提供天地通信服务的构件SpaceCommunication、提供在轨维护服务的构件MaintenanceOnorbit的访问。

图3 健康监测构件定义示意图Fig.3 Definition of health monitor component

以往航天软件采用面向过程的软件开发方法，大多数只能实现源代码级别的复用［17］。上述基于构件的实现方法引入了面向对象的思想，可以为航天器应用软件的开发提供体系结构和构件层次的复用，提高了软件的开发效率。

5 结论

为了满足载人航天器长期飞行、承担大量科学试验的任务目标，提升载人航天器在轨自主健康管理的能力变得越来越迫切。本文提出了一种载人航天器在轨自主健康管理系统体系结构，并采用OODA循环的思想定义自主健康管理的交互模型，为实现自主健康管理提供了有利支持。同时，以空间站为例，研究了分级分层的服务部署技术、分类故障诊断技术、基于在轨维护的故障模型配置技术以及基于构件的软件实现技术。

［1］李智勇.“天宫一号”目标飞行器系统级自主安全设计［J］.航天器环境工程，2011，28(6):525-528.

［2］朱毅麟.空间站应用的发展及存在问题［J］.航天器工程，2009，18(1):13-20.

［3］李晴，孙国江，李孝同.基于星务管理系统的小卫星自主健康管理系统［J］.航天器环境工程，2012，29(5):574-578.

［4］Felke T，Hadden G，Miller D，et al.Architectures for Integrated Vehicle Health Management［C］//Proc.2010 IEEE Aerospace Conference，Atlanta，Georgia.2010:20-22.

［5］Benedettini O，Baines T S，Lightfoot H W，et al.State-ofthe-art in integrated vehicle health management［J］.Proceedings of the Institution of Mechanical Engineers，Part G:Journal of Aerospace Engineering，2009，223(2):157-170.

［6］曹国荣.航天器在轨自主健康管理技术的研究和应用［D］.湖南:国防科技大学，2007.

［7］张弓，刘崇华，潘宇倩，等.导航卫星自主健康管理系统的架构实现方案［C］//第二届中国卫星导航学术年会电子文集，2011.

［8］于志坚.载人航天测控通信系统［J］.宇航学报，2004，25(3):247-250.

［9］李卫.神舟飞船仪表与照明系统研制［J］.航天器工程，2004，13(1):111-117.

［10］Boyd J R.A discourse on winning and losing［M］.1987.

［11］仲辉，陈超，王维平，等.基于π演算的指挥决策行为形式化建模研究［J］.系统仿真学报，2007，19(15):3609-3613.

［12］陈志国，张强.国际空间站信息系统架构综述［J］.载人航天，2011，17(001):5-9.

［13］曾声奎，吴际.故障预测与健康管理技术的现状与发展［J］.航空学报，2005，26(5):626-632.

［14］Martelli A，Torchia F，Sarlo L.The on-board software maintenance in the Beppo-SAX mission［C］//IAF，International Astronautical Congress，48 th，Turin，Italy.1997.

［15］Garrido B，Garcia A，Alfaro N，et al.MINISAT01 on-board software maintenance［C］//DASIA 98-Data Systems in Aerospace.1998，422:65.

［16］冯庆，桑楠，熊光泽.嵌入式应用中运行支撑框架的构件化技术研究［J］.计算机科学，2005，32(3):152-155.

［17］Cechticky V，Montalto G，Pasetti A，et al.The AOCS Framework［J］.EUROPEAN SPACE AGENCY-PUBLICATIONS-ESA SP，2003，516:535-540.