基于故障注入技术的航天器系统级软件测试方法研究

(北京空间飞行器总体设计部，北京 100094)

随着我国航天技术的快速发展，航天器在轨任务越来越复杂，航天器智能自主功能变得越来越强大，星载软件的质量和可靠性直接影响航天器在轨使用寿命。航天器自主运行能力是考核航天器可靠性的重要标准，星载软件故障防护模式测试是直接检验星载软件自主故障恢复能力和冗余设计的关键手段，如何对航天器系统级星载软件故障模式进行安全、有效、准确、全面的测试设计成为航天器系统级测试设计的关键因素。

航天器系统级星载软件测试涉及航天器全生命周期的总装集成测试阶段，即组装、集成、试验与测试(Assembly Integration Test，AIT)阶段。如果把测试实施前的准备工作分为：测试用例设计、测试文件编写、测试设备研制、测试系统调试四部分，测试用例设计约占总工作量的40%[1-2]。星载软件故障模式测试设计是利用故障注入测试技术，对软件的容错性和健壮性进行测试验证，系统级星载软件故障模式测试不仅是针对软件本身逻辑正确性进行验证，还要在系统级层面对输入故障激励后的执行机构动作进行确认。

目前，软件工程理论中故障注入技术(针对晶体管故障、门级故障等)已经在航天器单机级软件故障模式验证中得到广泛应用[3-4]，但碍于航天器系统级测试阶段中无法提供基于上述技术的故障注入接口及故障模式验证环境，需要研究适用于系统级故障防护模式测试验证技术来满足航天器系统级星载软件故障防护模式测试需求。本文根据现有工程实践经验，结合系统级故障模式测试设计理论，从基于原型的故障注入技术及故障注入实现方式两方面进行分析，总结了3种系统级故障注入技术的适用场景及优缺点，可为航天器电测中的软件测试设计提供参考。

1 系统级软件故障注入测试分析

1.1 软件故障注入测试特点及难点

由于被测对象的已知性以及测试需求的明确性，系统级软件故障注入测试广泛采用“面向对象”和“自下而上”的测试设计理念。利用地面测试设备产生的模拟故障信号作为输入激励注入被测系统中，通过观察被测系统的响应动作或报警信息验证系统级软件故障模式设计的正确性。系统级软件故障模式测试与单机级、分系统级测试验证不同点在于故障注入点的选取。针对系统级软件故障模式测试中整星提供特定测试点的约束，故障信号激励注入点仅能从系统设备采集终端、激励信号传输总线及系统软件内部程序进行选择。

系统级软件故障模式测试的难点在于以下四方面：

(1)整星测试结构状态对故障注入点的影响：整星合板状态下，故障注入点在星体内，通过外接测试电缆引入故障激励受到限制。

(2)故障时序性对故障注入技术的影响：对于强时序故障逻辑验证，一个判读周期的延时就有可能影响系统对故障响应的判断。

(3)故障模型复杂度对故障注入技术的影响：对于复杂系统故障逻辑验证往往涉及多个激励信号长时间相互作用，系统会采集多个信号的变化趋势作为响应动作的依据，单一故障激励的变化难以满足系统故障模拟需求。

(4)故障注入安全性的影响：整星测试期间，响应部件均为真实产品，当系统做出故障响应动作之前需要识别响应部件的转动、摆动以及切备份等动作是否会对整星状态带来影响。

软件故障模式测试验证设计的核心是对故障注入技术的研究。

所谓故障注入是指：向被测目标系统注入人为设置的故障，该故障能够触发系统失效或者进行冗余设置，通过监测被测系统，提取系统接收故障激励后的动作与故障模式发生后设计预想动作进行比对，从而检查被测系统容错机制的正确性[5]。

航天器系统级软件故障注入原理如图1所示[6]。

图1 航天器系统级软件故障注入原理Fig.1 Principle diagram of software fault injection for spacecraft system-level

1.2 软件故障注入技术分类

故障注入技术分类方式可以从故障抽象级别、实验所处系统开发阶段、故障类型、实现方法等不同方面进行划分[7]。本文从故障注入对象角度出发，分为基于仿真的故障注入技术及基于原型的故障注入技术，如图2所示。

基于仿真的故障注入技术主要适用于航天器单机级软件故障模式验证，该类技术需要对被测点、被测逻辑、被测功能建立软件仿真模型，在模型中加入故障机制[8]。

基于原型的故障注入技术适用于航天器系统级软件故障模式验证，该类技术是在原有系统的基础上，通过各种手段将故障激励输入被测系统，通过检测实际系统的响应动作完成故障模式的验证。基于原型的故障注入技术可分为3类：采集终端实现、总线介质实现、软件实现。

图2 故障注入技术分类

2 基于原型的故障注入技术

采集终端实现的故障注入技术是指选取系统参数采集终端作为故障激励的引入点，通过硬件设备或者工具直接模拟导致系统故障模式发生的电阻量、电压量、电流量等。应用此方法，需要将原有系统的采集终端接插件或者可插拔引脚与被测系统断开，通过特定的转接插头及电缆将被测系统与故障模拟硬件设备连接，达到将故障引入被测系统的目的，如图3所示。

图3 采集终端实现故障注入示意

数据总线实现故障注入技术是指通过采用特定的总线接入技术，在接收原总线数据的基础上，通过故障注入激励控制机制将需要的故障转换成总线数据的形式再注回系统总线数据中，达到将故障引入被测系统的目的，如图4所示。

软件实现的故障注入技术是指通过可编辑脚本或者程序从系统应用层入手，直接将故障注入系统软件中；或者通过系统应用层修改故障门限，达到满足触发故障模式的条件，不通过物理手段进行实现。

图4 总线介质实现故障注入示意Fig.4 Schematic diagram of fault injection in bus media

3 基于原型的航天器系统级故障模式测试技术应用

3.1 采集终端实现故障注入技术应用

采集终端实现故障注入技术为利用地面测试终端模拟发生故障情况下的输入激励，通过星上遥测采集设备将故障激励通过数据总线直接送给星务软件处理，不通过中转，不存在故障注入时延问题，适用于强时序性故障测试验证。目前在热控分系统、控制分系统等测试中被广泛使用。

3.1.1 热控分系统故障模式测试应用

以热控分系统热敏电阻故障模式测试为例，蓄电池加热回路有2个控温热敏电阻，蓄电池加热回路故障要求是当前控温热敏电阻大于+80 ℃或小于-35 ℃时切换至另一控温热敏电阻进行控温，如果另一个热敏电阻也发生故障则停止切换，向地面发出报警信号。

对于热敏电阻故障模式类型可以选择采集终端实现技术也可以选择总线介质实现技术，本节介绍选用采集终端实现技术的设计验证方式。

热敏电阻反映当前测温点温度，模拟温度故障即可以此为切入点，断开遥测输入端即采集终端接插件，利用热敏电阻等效器对当前故障模式电阻值进行模拟注入。

热敏电阻等效器连接示意图如图5所示，断开星上遥测采集设备与热敏电阻的接插件，将遥测采集设备与热敏电阻等效器通过测试电缆连接。该设备通过工控机控制数控电阻阻值变化，达到模拟星上热敏电阻故障模式的目的。在实际故障测试验证中，分别设置等效器中主份控温点为大于+80 ℃或小于-35 ℃时，观察星上自主控温热敏电阻选择是否切换为备份控温热敏电阻，然后再设置等效器中备份控温热敏电阻为大于+80 ℃或小于-35 ℃时，是否停止切换并且下传报警信号，即完成此故障模式测试验证工作。

图5 热敏电阻等效器连接示意图

3.1.2 控制分系统故障模式测试应用

以控制分系统惯性姿态敏感器故障模式测试为例，某卫星中配置4个陀螺，只要保证3个陀螺能够正常工作，即可进行姿态控制。陀螺故障主要有陀螺电机、力矩器、传感器故障或者控制线路失效，导致陀螺漂移增大、输出常零、加速度超差、饱和超差和陀螺数据不变化等[9]。

控制分系统故障模式测试时采用闭环测试，动力学仿真软件是地面系统的核心，完成卫星的姿态及轨道动力学计算、敏感器模型计算、控制接口信号采集及发送功能；姿态敏感器模拟部件设置驱动陀螺仪的激励源，模拟陀螺仪输出的陀螺信号源，模拟太阳敏感器输出的太阳敏感器信号源等功能；执行部件模拟器在地面测试中由于执行机构不能实际动作，因此采用动量轮模拟器等进行模拟，其主要作用是采集姿态控制计算机(Attitude Control Computer，ACC)给出的姿态调整信号。控制地面测试系统如图6所示。

图6 控制地面测试系统Fig.6 Ground test system for attitude and orbit control subsystem

通过敏感器模拟部件设置常值输出角度及输出周期，模拟常零故障及饱和超差故障，对4个陀螺分别叠加随机噪声输出，模拟加速度超差，可以验证卫星对陀螺数据有效性自主诊断和重构，当诊断出某一陀螺出现故障时，剔除该陀螺，采用其它3个陀螺进行姿态轨道控制。

通过动力学仿真软件计算出的陀螺输出信息上叠加常值漂移输出，可以验证卫星陀螺漂移算法的正确性，当设置多个陀螺故障时，控制系统自主进入安全模式。

3.2 总线介质实现故障注入技术应用

总线介质实现故障注入技术与采集终端实现在故障注入方式上有本质区别，将故障输入激励由遥测采集设备端转移到星载数据总线，将真实输入激励的模拟转移为总线传输数据的模拟，来实现满足星载软件故障防护触发条件，验证星载软件故障防护处理的能力，本节以1553B总线故障注入系统为例进行介绍。

1553B总线故障注入系统可以对1553B总线的协议层进行故障注入，协议层故障包括同步头错误、校验位错误、消息替换故障注入3种类型，系统结构和信息流如图7所示。

图7 1553B总线故障注入系统结构及信息流Fig.7 Structural and signal flow of 1553B bus fault injection system

系统工作过程中有上行遥控指令信息流和下行遥测数据信息流2个通道实现信息的流转，遥控指令信息流采取透明转发形式，遥测数据信息流采取截断替换形式[10]，具体如下。

(1)遥控上行数据：总线控制器(BC)端通过总线发出指令→地面系统内仿远程终端(RT)端板卡接收指令→系统内部透明转发→地面系统内仿BC端发出指令→RT端接收总线指令。

(2)遥测下行数据： 星载总线RT端将接收的原始遥测信息发送→地面系统仿BC端接收遥测信息→按照总线通信协议将模拟的故障信息替换原始数据→地面系统仿RT端将注入故障激励的整帧总线数据发出→星载总线BC端接收带有故障的遥测信息，完成故障注入过程。

1553B总线故障注入系统接入整星，需要将原数据总线与远程终端设备断开，将总线故障注入系统输出端与远程终端设备总线接插件电缆端进行连接，将总线故障注入系统输入端与远程终端设备总线接插件设备端进行连接，完成地面系统串入整星系统操作，如图8所示。

对于总线故障注入设备来说，故障转发时延是一个大问题，为了不影响被测系统的正常运行及逻辑处理，需尽可能的将遥测数据转发(包含故障激励)控制在一个周期内，图9为总线故障转发时序逻辑，图中1553B总线周期为T1(单位ms),从总线控制消息发出到故障注入转发完毕全过程需要时间为T2(单位ms)。按照实际应用情况，故障注入全过程可以在2个总线周期内完成，对于强时序性故障逻辑验证有一个总线周期的故障触发误差。

图8 1553B总线故障注入系统Fig.8 1553B bus fault injection system

图9 1553B总线故障注入系统时序逻辑分析Fig.9 Sequential logic analysis diagram of 1553B bus fault injection system

以热控分系统热敏电阻短路断路故障为例，进行实际应用说明。当系统中热敏电阻发生断路或者短路故障时，系统自动将故障热敏电阻剔除，选用备份热敏电阻进行控温。此种故障反映的热敏电阻为极大值或者极小值，采集终端实现技术难以满足该需求，而采用总线介质实现技术则较轻松。通过总线数据注入模拟的热敏电阻断路或者短路遥测源码值，完成热敏电阻断路短路故障功能验证。

3.3 软件实现故障注入技术应用

整星系统级层面软件实现故障模式测试验证有一定的条件限制，此方法主要应用在由于总装流程限制，卫星各舱板闭合，无法连接测试电缆的情况下，通过内存修改指令，将故障模式的系统默认值进行放宽处理，使其在正常信号激励的情况下仍能触发故障逻辑，验证故障模式的正确性。该技术不涉及对遥测采集数据进行修改及中转，能够满足强时序性故障模式验证需求。

以热控分系统热敏电阻断路短路故障为例，该技术实现如图10所示。

图10 内存修改实现故障模式验证逻辑图Fig.10 Logic diagram of memory modification to implement failure mode verification

1个电阻的故障阈值在程序中表现为2个16位无符号整型数，图10中所给的地址为存储2个16位阈值的起始地址，从该地址开始向后的连续4个地址内存放的2个16位数据作为相应的阈值。通过内存修改指令，将故障阈值进行适当放宽，修改后阈值参考常温下热敏电阻温度源码进行选定，就可以不通过外接设备完成热敏电阻故障模式的验证。

3.4 系统级故障注入技术优缺点分析

通过前3节对基于原型的故障注入技术在整星系统级故障模式测试验证的应用分析，本文提出的3种方法优缺点如表1所示。表1中时序性是指被测系统软件对接收故障激励的响应有效周期，在软件测试需求中会明确提出，该指标是反映系统软件故障处理响应速度的关键因素，影响系统级故障注入技术的应用选择。对于采集终端实现的故障注入技术，故障激励直接作用于采集终端，待接收到总线消息控制字后，采集终端将故障激励在一个总线周期内送给被测系统软件，故障注入没有时延，适用于强时序系统功能验证。而总线介质实现的故障注入技术经3.2节分析后得出地面测试系统待接收到总线消息控制字后，被测系统软件接收到故障激励信号会有一个总线周期的延时，适用于弱时序系统功能验证。基于软件实现的故障注入技术，其根本是改变被测系统软件对故障激励的阈值，测试过程中不会带来时延。

表1 系统级故障注入技术优缺点

4 结束语

本文提出了3种适用于航天器系统级的故障注入技术，并对其实现原理和实现方式进行分析总结。以上3种故障注入技术已在各领域航天器整星综合测试阶段实际应用。测试结果表明：3种基于原型的故障注入技术满足航天器系统级软件测试验证需求，符合软件测试覆盖性、有效性、安全性设计要求，可以为整星结构、系统故障响应时序等诸多约束条件下系统级故障注入技术的选择提供参考。对于本课题的进一步深入研究建议如下：①总线介质实现的故障注入技术可以从总线消息控制字与被测BC端消息字同步方面进行突破，降低故障模拟响应延时；②不局限于当前对故障注入点的识别，研究新的故障注入途径，变不可测故障模式为可测故障模式，提高系统级层面软件功能地面验证能力。