航天發射場故障信息管理與系統設計

方世源等＊ /北京特種工程設計研究院

質量是航天發射場設備的生命線，科學有效的故障信息管理方法是提高航天發射場設備質量管理水平的重要基礎。同時，故障信息是航天發射場地面設施以及火箭、衛星、測控通信等各類設備研制、生產、試驗和使用全生命周期各項質量保證活動的重要資源，是進行質量管理的重要依據。沒有高質量的故障信息，質量與可靠性分析、設計、評價和改進就成了無源之水。因此，做好對航天發射場設備的故障信息收集以及相關流程的規范化管理對促進航天發射場設備質量提高有重要作用。本文重點分析了航天發射場各類設備的故障信息及其管理現狀，設計并規定了故障信息標準化格式要求，最后借助故障信息管理原型系統實現了應用。

一、航天發射場故障信息及其管理現狀

根據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.用戶層

用戶層是系統的最終用戶，通過系統提供的功能進行故障數據管理，也為系統提出實際使用過程中存在的問題，提供反饋意見。主要包括普通用戶、單位管理員、機關管理員、系統管理員等。普通用戶主要是發射場各專業直接負責故障信息錄入的人員；單位管理員主要是發射場各系統負責設備故障信息管理的人員；機關管理員主要是各發射場負責設備故障信息管理的人員；系統管理員主要是機關主管參謀/負責數據維護的技術人員。

航天發射場故障信息管理作為質量管理活動的一項重要內容，在提高發射場設備質量方面發揮著重要作用。本文詳細分析了航天發射場各類設備的故障信息及管理現狀，結合發射場現行故障信息收集、存儲和管理模式，開展發射場設備故障信息格式標準化設計工作，給出故障信息管理系統的總體架構設計方案，明確故障信息管理流程，實現了信息快速、準確、全面傳遞和共享。同時，后續隨著數據的積累，可以在此系統基礎上開展故障診斷、知識管理等模塊的研究和開發，進一步提高故障信息利用效能，不斷提升發射場精細化質量管理水平。