张亚琳,李 浩,胡 骁,赵晨希

(中国运载火箭技术研究院,北京 100076)

1 引言

随着计算机技术的飞速发展,航空和航天飞行器等系统的复杂化程度不断提高。在这些系统中,计算机一旦失效,将导致巨大的经济损失。飞行器控制系统是其计算机的核心,要求能够克服外界干扰环境的影响把飞行器的运动控制在相应的速度和相应的轨迹,对控制的精度、稳定性及鲁棒性要求非常高。飞行控制系统作为一个对安全可靠苛求的系统,其安全性测试具有极其重要的意义。然而,飞行器在实际中发生的故障种类繁多,有些故障是内部故障,有些却是外界干扰所致,且这些故障具有一定的潜伏期,其产生的破坏性效果可能波及到系统的多个部分,传统的测试方法已难以确保系统准确快速地检测故障。

故障注入技术是一种通过引入外部故障,观测系统运行状态来提高测试覆盖性的测试方法,该技术可以有效发现目标系统中的潜伏故障,缩短故障暴露时间,以改进系统架构,目前已广泛应用于各类容错系统中[1,2]。因此,研究飞行器控制系统的故障注入技术,对于提高飞行器航行的安全性与可靠性具有重要意义。

本文根据飞行器控制系统的运行特性,通过特定的技术模拟实际运行中发生的各类故障,人为地将其注入到系统中,监控并分析系统的运行情况,使系统能够快速检测故障、隔离故障和修复故障。

现有国内外故障注入技术的具体实现方式多种多样,其实现形式分为硬件实现和软件实现[3]。硬件实现的故障注入方法通常利用特殊的设备或工具直接连接到目标系统上实施故障注入。软件实现的故障注入方法通常采用程序或者脚本来控制故障注入全过程,以避免额外的硬件开销,并且具有更大的灵活性。飞行器整个控制系统涉及的产品众多,且功能各异、链路复杂以及集成方式多样。硬件故障注入方法开销太大,测试周期长,且无法覆盖全面[4]。典型的软件故障注入工具有卡内基梅隆大学开发的FIAT,该工具可以模拟各种分布式系统体系结构,向系统内存和CPU注入故障[5];美国德克萨斯大学提出的FERRARI通过修改进程的控制进程,使用陷阱和系统调用以实现故障注入[6];伊利诺伊大学与美国宇航局合作开发的FINE主要分析UNIX的内核故障传播[7];葡萄牙科英布拉大学提出的Xception要求处理器具有硬件编程接口,通用性不强[8];密歇根大学提出的DOCTOR主要是针对集成的软件环境进行瞬时、间歇或永久性故障注入。但这些系统都只能解决某一个方面的问题,无法覆盖系统的全部,而且均是通用型的,并未考虑结合领域背景,而往往结合领域背景的故障才是系统最需要的。

本文提出了一种高效的、可构建领域背景的、支持多种异构平台和接口的实时故障注入系统,构建了从故障产生、故障注入、故障监控、数据分析挖掘、故障预测的全链路故障管理平台。

2 系统概述

系统分为应用层、服务器层和目标系统三大部分,应用层负责完成故障加载、故障生成、系统参数配置、接口参数配置和智能分析与预测等,支持用户自定义的故障录入;服务器层负责故障管理、故障注入、故障存储、故障分析、结果数据收集;目标系统完成状态监控等功能,目标系统也会驻留部分功能代码,包括数据收集模块和综合控制功能模块。故障注入模块可以支持不同的故障类型、故障位置和故障注入时间,系统架构如图1所示。

图1 系统架构

3 故障生成方法

为保证故障测试的覆盖性,本文采用经典案例故障库、面向任务定制的故障和用户自定义故障相结合的方式生成故障。经典故障案例录来源于结合领域背景知识的故障启示录,充分考虑可能出现的接口、中断、并发处理、数据和计算以及控制流错误等各种问题,从多种角度充分考核系统的可靠性。

本文将每种具体的故障抽象为故障模型,系统通过故障注入器,根据故障模型在故障注入时刻实现对特定故障的模拟。故障模型用故障的公共属性来表征,本文采用四个属性来描述目标系统的故障模型,即故障位置、故障类型、故障持续时间和故障注入时刻。在故障注入时刻可以选择以上几种模型的任意组合作为注入条件,对每一种故障类型进行了说明。

表1 故障模型

表2 故障注入实例

4 故障注入机制

本文从系统的优化性、灵活性和可重用性等方面出发,结合动态注入和静态注入的特点,提出了一种动态生成-静态存储-动态触发的故障注入模型,架构图见图2。

图2 故障注入架构图

服务器端负责将用户设定的各种故障场景依次注入到目标端,故障描述信息以线性表的方式存放在主机的缓冲区中。目标端程序添加扫描故障描述信息表的语句块,并加载故障描述符,进行故障模式解析,根据故障类型生成故障注入决策,内容包括故障注入时机、故障注入位置和故障内容,如生成多个决策,需依次注入执行。故障的生成是动态的,故障的存储是静态的,故障是运行时动态触发的,从而实现了系统的灵活性和可重用性。

5 故障触发机制

故障触发模块主要完成两个功能:运行目标程序和触发故障。具体实现方式为:设计后台监控进程,对故障注入的全过程进行管理;在原执行软件上进行故障插桩改造。

被注入故障软件的插桩方式通过在被测的系统内可能发生故障的位置添加故障提取语句实现。如在某个“查询系统状态是否正常”的分支判断语句前添加查询语句,则可根据用户注入故障的参数执行不同的分支。当程序执行到插桩的这个位置时,会查询故障表内是否有触发型故障,如有,则触发该故障。后台监控进程实时查询故障表内是否有未被注入的故障,如果有,则根据故障类型,则将对应故障触发系统变量置为1,由被测软件根据故障类型来调用不同的故障体。

6 故障监测机制

实时故障监测系统由故障任务生成器、故障任务追踪器、目标系统控制模块和系统状态监控器组成,系统架构图如图3所示。故障生成器生成具体的故障任务并提交给服务器,服务器启动对应的故障任务追踪器,并激活驻留在目标系统中对应该类故障任务的后台追踪进程,随后将任务描述信息传递给目标系统控制模块。由系统控制模块调用对应的系统状态监控进程,由于故障模式不同,对系统的影响域将有极大不同,所以不同的状态监控进程开启的监控项也会不同。在故障的有效作用时间范围内,目标机追踪器会以心跳的方式定期向服务器返回系统运行状态,这样可以保证在目标系统失效的情况下依然可以得到目标机的状态信息,而不是完全依赖于数据收集功能对目标系统状态的监测和传送,这样,当目标系统失效或者数据收集功能出现异常时,服务器还可以得到目标机的状态。

图3 故障触发机制流程图

图4 故障实时监测系统

为维护任务信息的完整性以及保证每个任务的可追踪性,将每个任务的控制信息均存储在数据库中。任务在生成时,会创建任务ID,每个任务将ID向任务追踪器注册,并且在故障注入时,任务ID会随着任务具体信息一起注入到目标系统,并作为任务的唯一标识,关联任务故障信息和运行状态信息。

7 故障预测机制

故障预测部分采用回归和分类结合的方法,回归模型用来学习基于时空维度的多变量之间的关联关系,分类用于对回归结果进行矫正,以获得更准确的预测数据。首先,从飞行器综合试验的大量数据中提取出不同流程和试验条件下的正常数据和异常数据,并提取电量采集值、时序和传感器采集值等大量参数,经过数据特征提取后转化为学习模型的输入;划分训练集和测试集,并进行多轮训练;将训练后的值输入分类模型中,将分类模型的输出值作为最后的预测值;计算损失函数,并调整参数;反复迭代,生成最终的训练模型。

飞行器由成千上万的零部件组成,可提取的参数数量极为庞大。经过大量的参数筛选实验,挑选了与预测飞行器故障相关的动态性能参数,并对不同参数进行了加权处理,使得决定飞行器成败的参数占据较大权重,预测结果更符合实际需要。经过实验验证,该方法能较好的预测系统的表现趋势。

8 试验验证

8.1 系统容错测试

对某飞行器控制系统涉及的所有软硬件进行故障注入测试,全系统分为控制计算机、时序设备、执行机构、信息采集机构和遥测系统。针对每个系统功能和软硬件特性,制定如图5所示故障注入计划。

图5 各系统故障注入测试用例首次不通过率

对每一种故障实例选取的依据是图5的故障分类模式,故障注入的实例和测试运行结果存储在系统日志中,测试的统计结果如图5所示。

各系统软件运行平台和功能差异较大,对于同样的故障,表现出的可靠性差别较大,但是在所有系统中,几乎均是通信过程可靠性程度不高,证明各系统在接口匹配上存在较大问题。对于时序设备和遥测系统此类含FPGA软件的设备,在时序匹配方面存在个别问题。控制计算机软件采用多线程架构,在多线程使用方面存在问题。对嵌入式软件,通常有多中断交互功能,经过强行激发连续中断信号的考核,时序设备和信息采集机构的软件出现中断处理丢失的问题。通过激发链路故障,也测试出系统容错设计的缺陷。

8.2 系统改进测试

对经过初次故障注入系统考核的设备,待改善之后,对其再次进行考核,并且重新生成故障实例,如此迭代多次,直到各设备连续三次通过全部故障用例。在每次迭代测试中,各设备的故障通过率不断提升,平均迭代测试10次,基本可以达到通过全部故障用例。系统能够通过故障用例的个数,反映着系统的可靠度,在前几次测试时,系统可靠度可大幅提升,因为初期测试时发现的都是共性问题,而到后期,能够发现的问题趋于个性化,并且发生的条件较为复杂,所以可测试出问题的个数大幅减少,系统可靠度提升趋于缓慢,最终达到较为稳定的状态。

9 总结

本文设计并实现了面向飞行器控制系统的高实时故障诊断系统,可结合具体应用场景生成定制化的故障用例,并实现动静结合的故障注入机制,通过高效的故障监控手段实现实时性,并能将测试结果存储,用于故障分析和预测。通过试验证明,该故障注入系统可辅助提升飞行器系统的可靠性,对于提升飞行试验的成功率具有重要意义。