航天发射场故障信息管理与系统设计

方世源等＊ /北京特种工程设计研究院

质量是航天发射场设备的生命线，科学有效的故障信息管理方法是提高航天发射场设备质量管理水平的重要基础。同时，故障信息是航天发射场地面设施以及火箭、卫星、测控通信等各类设备研制、生产、试验和使用全生命周期各项质量保证活动的重要资源，是进行质量管理的重要依据。没有高质量的故障信息，质量与可靠性分析、设计、评价和改进就成了无源之水。因此，做好对航天发射场设备的故障信息收集以及相关流程的规范化管理对促进航天发射场设备质量提高有重要作用。本文重点分析了航天发射场各类设备的故障信息及其管理现状，设计并规定了故障信息标准化格式要求，最后借助故障信息管理原型系统实现了应用。

一、航天发射场故障信息及其管理现状

根据GJB 451A的定义，故障是指产品不能执行规定功能的状态，通常指功能故障。据统计，航天发射场各单位在日常维护及执行任务时发生的各类故障涵盖了火箭、卫星、测控、通信以及发射场地面设施等各类型设备。从故障信息的统计分析情况看，航天发射任务故障数量仍处于较高水平，影响任务成败的重大问题时有发生。另一方面，故障信息的要素不全面，故障原因和处理解决措施内容方面的标准化程度还有待加强，故障信息管理的模式还未完全有效建立。

1.航天发射场故障信息现状

（1）故障要素不全面

目前的故障统计表格中包括任务名称、发射工位、时间、问题名称、责任单位/部门、问题现象、问题原因、归零情况、任务影响等要素，初步对不同时间内各类设备的故障情况进行了汇总。根据故障信息标准化的设计要求以及故障信息管理系统的建设需要，还应该添加部分故障要素，如处置措施、原因分类、严重程度、发生阶段等，并且规范目前要素中需要填写的内容。如：归零情况规定包括任务中归零、事后归零、未归零、无需归零，并应明确是技术归零还是管理归零；任务影响应包括影响任务成败、推迟发射和无影响。

（2）故障描述不规范

故障统计表格中对于故障描述的方式不尽统一。如对于故障现象的描述，有的详细描述了故障事件，包括执行任务时的具体过程，有的可能仅有一句话，没有前后因果，难以体现故障的真实现象，再如对于故障解决措施的描述中，没有体现出处置措施和解决措施的区别，有的是把归零中的信息直接照搬，有的则是仅有临时的处置措施，不能体现出解决故障的根本措施是什么，不利于后续的信息利用。

（3）故障原因分类不清晰

目前，统计的故障中没有列明某个故障具体的原因分类，在以往对故障统计分析的过程中，也是以简单的技术原因或管理原因进行分类，而技术原因也简单地归类为设计、生产制造、安装调试、维修、操作使用、软件，虽然进行了分类，但是缺乏科学规范的故障原因分类定义。

（4）故障严重程度缺乏判据

GJB 5711中规定，对于质量问题的严重程度定义为重大、严重和一般，目前的故障统计中也沿用了这一概念，但是标准里的定义较为模糊和宽泛，不能体现航天发射场设备故障严重等级的特点，因此，需要对发射场各类设备进行故障严重程度的定义，细化管理要求，从而更加有效精确地判定某故障的严重程度，且要体现出不同类别设备的差异性。

2.航天发射场故障信息管理现状

（1）故障信息管理机制不健全

经过多年建设发展和任务实践，航天试验各方质量责任基本得到固化，但是在故障信息管理机制的健全与优化方面还需加强。从各级机关和各单位的职责来看，目前没有专门的故障信息管理部门，有时分工界面和责任不清，各级机构不能很好地履行故障信息管理职能。同时，尚未形成定期收集发射场设备故障信息的机制，以及设计需求与质量信息闭环反馈机制，需求获取不及时、变化不受控的现象还客观存在，参与主体之间的故障信息管理工作协同还不够有力，信息交互向上流动还比较迟缓，综合利用效率不高。

（2）故障信息管理缺乏共享性和延续性

近年来各级单位都组织开展过对于故障的统计工作并做了一定程度的分析，但是仍未完全建立起系统性、定期性的信息共享和上报制度，导致故障信息及其管理缺乏共享性和延续性。一方面，在实际工作中，发射场各单位对于试验设备的质量管理和使用情况没有及时与设计、生产单位交流和沟通，故障信息不能充分共享；另一方面，出现故障时，只是组织解决具体问题，对设备的技术状态、可靠性程度等没有总体把握，对故障信息的分析不够深入，对应用统计技术做深入细致的分析与预测不够，导致故障信息管理没有延续性，不利于设备的全系统全寿命管理和持续改进。

（3）故障信息化管理手段不够完善

目前，各单位关于故障信息化的规章制度不完善，定期收集的故障信息基本上都是以简单的excel表格呈现，没有专门的故障信息管理系统。有些单位建立了部站级设备管理系统，但没有形成完善的网络系统，数据库建设还不完善，对信息的收集、分析、传递和利用也不够。

二、航天发射场故障信息标准化设计

故障信息标准化设计的思路是将故障要素分类化管理，将故障从发生到最后归零过程中包含的所有信息按照发生的时间顺序进行分类，包括以下3类信息：

（1）故障基本信息：是指故障发生后，录入人员对故障情况的简要概括描述。

（2）故障分析及处置信息：是指故障发生后，岗位人员或技术人员对故障采取的分析及处置措施，包含现场处置以及事后的分析和处置信息。

（3）故障归零信息：包括故障归零情况、故障归零类型以及归零报告。

航天发射场故障信息标准化设计的总体技术流程如图1所示。

图1 航天发射场故障信息标准化设计流程

1.故障基本信息

故障基本信息主要包括上报单位、故障时间、故障发生阶段、故障名称、故障现象、所属系统/分系统、所属任务、研制单位、发现人员等要素。

（1）上报单位：填写具体的上报单位名称；

（2）故障时间：故障发生/发现的具体时间；

（3）故障发生阶段：包括检测、地面试验、交付验收、技术阵地准备、发射阵地测试、发射、飞行、在轨运行、返回、其他；

（4）故障名称：针对故障事件的概要描述，必须包产品名称、产品工作状态、故障模式或故障现象。故障名称一般与相应的归零报告上的名称一致，应简单清晰明了；

（5）故障现象：详细说明故障现象，包括发生的过程、时机、实际表象等；

（6）所属系统/分系统：包括火箭系统、卫星系统、发射场系统、测控系统、通信系统；

（7）所属任务：如果是任务实施阶段的故障，应注明任务代号；

（8）研制单位：故障所属设施/设备/产品的研制（设计和生产）单位；

（9）发现人员：故障的具体发现人员。

2.故障分析及处置信息

故障分析及处置信息包括故障原因分析、故障原因分类、故障严重程度、处置措施、处置完成时间、处置人员等信息。

（1）故障原因分析：详细说明故障原因分析情况；

（2）故障原因分类：设计缺陷、生产质量、操作不当、设备老化、软件、管理、其他；

（3）故障严重程度：重大、严重、一般；

（4）处置措施：详细说明针对故障的处置措施，包括现场处置以及经事后分析的处置措施信息，以及达到的效果，分为有预案处置和无预案处置；

（5）处置完成时间：故障处置完成的具体时间；

（6）处置人员：故障的具体处置人员。

3.故障归零信息

故障归零信息是对故障定位、故障机理、故障复现、解决措施以及举一反三等信息的详细说明，包含了前两部分的信息。主要包括：

（1）故障归零情况：包括任务中归零、事后归零、未归零、无需归零；

（2）故障归零类型：技术归零、管理归零、技术管理双归零；

（3）对任务的影响：分为任务失败、发射推迟、无影响等；

（4）归零报告：按照相关要求，编写完整的归零报告，详细说明故障原因分析情况。

4.故障原因分类

对发射场发生的各类故障进行精准的原因分类有助于完善质量数据统计信息，挖掘质量问题的共性和深层因素，制定更为合理的预防和控制措施。根据对故障原因和规律的分析，结合现有故障统计情况，对故障原因分类做出定义（见表1）。

表1 故障原因分类说明

5.故障严重程度定义

依据GJB 5711-2006《装备质量问题处理通用要求》的规定，将故障严重程度定义为三级，即重大故障、严重故障、一般故障。针对火箭故障、卫星故障以及发射场相关的故障，分别对3种故障严重程度等级进行了定义和说明，见表2、表3和表4。

表2 火箭故障严重程度分类说明

表3 卫星故障严重程度分类说明

表4 发射场相关故障严重程度分类说明

三、故障信息管理系统总体架构设计

针对当前航天发射场故障管理规范性不足、缺乏技术手段的问题，开发发射场故障信息综合管理系统，对发射场设备故障数据进行收集、存储、传递、汇总、分析和处理，实现设备故障数据的规范化和可视化管理。发射场故障信息综合管理系统总体架构分为资源层、数据层、模型层、应用层、用户层5个层次，如图2所示。资源层为数据层提供环境支撑，数据层为资源层提出存储需求；数据层为模型层提供数据支撑，模型层为数据层提出数据要求；模型层为应用层提供模型支撑，应用层为模型层提出功能需求；应用层为目标用户提供服务支撑，目标用户为应用层提出反馈迭代意见。

图2 发射场故障信息综合管理系统总体架构图

1.资源层

资源层主要为整个系统尤其是数据层提供基础运行环境支撑，根据数据层提出的存储规范制定数据格式要求。包括服务器、存储集群、计算集群、安全防护等。其中服务器为系统提供基础应用服务部署环境；存储集群为数据层提供数据存储环境；计算集群为模型层提供模型训练环境；安全防护为整个系统提供等保二级以上的信息系统安全保障，确保相关业务数据、功能需求及应用场景的绝对安全。

2.数据层

数据层主要为整个系统尤其是模型层提供数据支撑，根据数据的类型、格式及内容要求为资源层提出存储需求，根据模型层提出的数据要求进行相应的数据处理操作，主要包括故障数据和基础数据，其中故障数据包括故障基本信息、故障分析处置信息、故障归零信息、故障报告信息；基础数据包括机构数据、用户数据、权限数据、日志数据和规章制度数据。

3.模型层

模型层主要为整个系统尤其是应用层提供模型支撑，根据模型的输入数据规范对数据层提出数据要求，根据应用层所需的功能需求，确定模型的输出数据格式，主要包括统计分析模型与报告生成模型。其中，统计分析模型对数据进行分析挖掘，为表格、饼图、直方图、折线图等常用图表提供标准化的数据输入，并允许用户自定义部分维度属性（时间段、发射场、故障设备、故障类型等），以便从各个角度对设备故障信息进行深入的统计分析，使用户快速而较全面地掌握各发射场当前设备故障总体态势。报告生成模型可按预设规则对汇集的设备故障信息进行分析，结果自动填充至预设的设备故障分析报告模板，形成当期设备故障分析报告，以便向机关报送。

4.应用层

应用层主要为整个系统尤其是用户层提供服务支撑，根据用户层的反馈意见持续迭代应用功能，提供更优质的服务保障，对模型层提出相应的功能需求，确定模型的输出数据格式，主要包括统计分析模块、信息管理模块、规章制度模块等核心功能和用户登录模块、系统管理模块等基本功能。其中，统计分析模块包括数据统计、图表分析、趋势分析、报告生成等，数据统计通过在一个页面中以数字的形式集中展示故障数量、处理进度等重要信息，使用户快速而较全面地掌握各发射场当前设备故障总体态势。统计分析提供表格、饼图、直方图等常用图表，以便从各个角度对设备故障信息进行深入的统计分析。故障报告生成可按预设规则对汇集的设备故障信息进行分析，结果自动填充至预设的设备故障分析报告模板，形成当期设备故障分析报告，以便向主管机关报送。信息管理模块包括信息录入、信息上报、信息审批和信息查询模块，实现对故障基本信息、故障分析及处置信息、故障归零信息的录入，可按照关键信息和多元要素进行信息查询。系统管理实现对机构、权限、用户、日志的集中管理。

5.用户层

用户层是系统的最终用户，通过系统提供的功能进行故障数据管理，也为系统提出实际使用过程中存在的问题，提供反馈意见。主要包括普通用户、单位管理员、机关管理员、系统管理员等。普通用户主要是发射场各专业直接负责故障信息录入的人员；单位管理员主要是发射场各系统负责设备故障信息管理的人员；机关管理员主要是各发射场负责设备故障信息管理的人员；系统管理员主要是机关主管参谋/负责数据维护的技术人员。

航天发射场故障信息管理作为质量管理活动的一项重要内容，在提高发射场设备质量方面发挥着重要作用。本文详细分析了航天发射场各类设备的故障信息及管理现状，结合发射场现行故障信息收集、存储和管理模式，开展发射场设备故障信息格式标准化设计工作，给出故障信息管理系统的总体架构设计方案，明确故障信息管理流程，实现了信息快速、准确、全面传递和共享。同时，后续随着数据的积累，可以在此系统基础上开展故障诊断、知识管理等模块的研究和开发，进一步提高故障信息利用效能，不断提升发射场精细化质量管理水平。