面向火箭數據分析和故障診斷的數據倉庫設計

陳 卓，汪 灝，平佳偉，鄧 闖，彭炳峰，徐 昕，4

(1.上海航天電子技術研究所，上海 201109；2.上海交通大學 計算機科學與工程系，上海 200240；3.上海宇航系統工程研究所，上海 201109；4.南京航空航天大學 航天學院，南京 210016)

0 引言

運載火箭系統是一項極為復雜的大規模系統工程，橫跨計算機、電子、通信、控制、材料、結構以及機械等領域，每一枚火箭的研制均需數以千計的單位參與，其發射以及飛行過程中會經歷高溫、強沖擊、以及復雜惡劣的太空環境，任何一部分構件的異常都可能導致發射失利，這對于需要高投入、長周期研制的火箭損失難以承受，其上所搭載的航天器及衛星價值更是難以估量[1]。2010年12月，印度GSLV-F06運載火箭在“薩迪什·達萬”航天中心執行發射，在發射兩分鐘后偏離軌道爆炸，帶來數億美元的損失，2013年2月，俄羅斯運載三顆“格洛納斯-M”導航衛星的質子-M運載火箭在發射升空后一分鐘內墜落并爆炸，事故原因是關鍵的角速度傳感器被顛倒安裝[2]，2016年9月，獵鷹9號在執行靜態點火測試時發生爆炸，價值2億美元的衛星損毀，在國內，長征系列多款運載火箭均出現過較為嚴重的航天事故。因此，可靠性的提升是運載火箭領域最為關注的重點工作之一，其中，最為重要的手段就是故障診斷，通過前期的測試和監測發現潛在的故障，及時進行處理，避免災難性的損失出現，其中火箭的長期測試數據以及專家知識是進行數據分析和故障診斷的重要依據[3]。

火箭在長期測試過程中，產生了大量的原始數據和各種業務數據，這些數據分散在各承制單位，各試驗現場，數據包括全箭各系統數據及單機數據。但是長期以來，運載火箭試驗過程中所采集的數據只是作為型號任務的產品，各型號任務所獲取的數據之間是隔離的，大量的歷史數據處于脫機狀態，絕大多數以原始數據或文本形式存儲于型號電腦或光盤中，缺乏集中的存儲和管理，設計師在數據分析過程中無法方便的獲得歷史數據[4-5]無法通過一套軟件快速的進行各階段數據統計、分析，使得對產品的穩定性和包絡分析較困難。

隨著型號任務的持續增加和新型火箭的不斷開發，火箭系統硬件設備逐漸呈現出設備配套數量多、種類多、部署場地多的特點，火箭系統測試數據呈現出格式不統一、數據種類多樣的特點[6]。現階段對于火箭的數據分析僅限于同型號有限批次的比對，比對分析方式以理論知識為主，歷史數據為輔，跨型號、跨時間的數據分析較少、不夠全面，這樣導致火箭產品在設計階段缺乏足夠的先驗數據支撐；另一方面火箭測試數據的分散存儲和格式不統一，給數據進行的全面的分析和利用帶來了困難，使得火箭的故障診斷成為無源之木[7]。

運載火箭領域歷史積累的測試數據量是巨大的，具備很大的潛藏價值，但目前這些數據只是被分散存儲起來，沒有形成完整的數據資源目錄、數據視圖和數據共享機制，在數據資源深層次分析開發上也缺乏必要的手段，試驗數據未能進行有效的統計、分析和評估，無法將這些測試和發射數據轉換成對火箭有用的信息，這些寶貴的試驗和發射數據價值未能發揮。

基于現狀，為了解決運載領域測試數據利用率不高的問題，提高分析和決策效率和有效性，有必要對數據進行組織和管理，發揮運載領域測試數據應有的價值，為后續的任務服務，數據倉庫正是為了構建這種新的分析型環境而出現的一種數據存儲和組織技術[8-11]，本文提出將數據倉庫技術應用于運載領域的數據匯總，對火箭測試發射數據的進行綜合管理和深層次的挖掘分析，輔助型號任務工作，為火箭的故障診斷工作打下基礎。

火箭的故障診斷技術已經經過多年長期的發展，取得了不少理論成果并得到了實際應用，從20世紀70年代開始，美國開始在運載火箭上應用健康管理系統，監測發動機運行狀態，此后，故障診斷和狀態監測的理論和技術得到了迅猛的發展[12].可以將目前主流的故障診斷方法分為如下三類：基于信號處理的故障診斷方法、基于專家的故障診斷方法和基于數據挖掘的故障診斷方法。其中，基于信號處理的故障方法通過對采樣信號進行降維升維和時頻域變換提取特征信號進行故障診斷，常見的有小波變換和傅里葉變換[13]，不需要了解設備的工作原理，但在面對故障模式多樣的火箭系統存在局限性；基于專家的故障診斷方法是根據火箭的理論知識以及經驗知識，對可能出現的故障模式進行預測，常見的有知識庫和知識圖譜[14]，此種方法對于知識庫內已有的故障模式有著較好的識別效果，但對于知識庫外的故障是無法識別和預測的；基于數據挖掘的故障診斷方法成為近年來的主流研究方向，以大量的測試數據為基礎，通過深度學習對數據樣本進行訓練，對于復雜系統具有較高的適應性，但火箭的故障樣本較少使其診斷精準度不高[15]。

針對復雜運載火箭系統在故障數據不充分、故障模式不確定情況下的故障診斷需求，提出了一種基于數據挖掘與專家知識相結合的故障診斷方法，以專家知識作為深度學習的約束條件解決數據挖掘方法的結果不穩定問題，面向火箭數據分析和故障診斷的數據倉庫是火箭故障診斷的基礎。

1 數據倉庫方案總體設計

數據倉庫由數據庫發展而來，但兩者在很多方面都存在很大的差異性，數據倉庫已經脫離了軟件產品的范疇，是一種綜合性的解決方案[16]。數據倉庫是面向分析主題的、歷史數據、多維的數據集合[17-18]，主要面向數據分析以及管理決策，需要對數據根據主題進行清洗、加工、匯總，形成規范、統一的全局信息；而數據庫則是面向業務的、來源單一、查詢量小，可以進行實時的數值處理，主要用于面向局部業務的數據查詢處理工作[19]。

具體到運載火箭領域，數據庫更多的面向于火箭系統某一任務，某一型號，為具體的某一發測發業務提供查詢、判讀、存儲等服務；數據倉庫則是多維度的，可以綜合管理運載火箭領域的測試數據，將不同型號、不同發次的數據，抽取數據特征信息，進行統一的治理，為火箭的數據分析和故障診斷等業務提供服務。

運載火箭數據倉庫主要功能是根據數據的不同來源和信息特征，形成多維數據存儲空間，為用戶提供一個綜合的、面向分析決策的支持環境，結合數據倉庫一般結構和運載領域測試數據的特點，數據倉庫采用六層分層框架進行設計，如圖1所示。

圖2 運載火箭數據倉庫主題

1)基礎層部分：由于火箭數據物理來源多樣，位于各分系統實驗室、綜合測試廠房、試驗場，各來源地之間硬件平臺的多樣性，因此數據倉庫基礎層不僅要包含支撐運行的計算資源和存儲資源，還要包含網絡資源，預留數據持續維護更新的接口，為數據的自動錄入奠定基礎。

2)源數據層部分：數據的來源不局限于測試發射生成的數據，還包含產品在設計過程中的圖紙、文檔、記錄等數據，其來源可以從數據類型和格式兩個維度進行分類。按數據類型分，可以分為電氣數據、測量數據、動力數據等；按照數據格式可以分為結構化和非結構化數據，結構化數據主要包括存儲在光盤、硬盤中的“dat”格式源數據文件，“txt”格式文本文件及SqlServer、Mysql數據庫中的測試數據，非結構化數據包括文檔數據、圖像數據。

3)數據交換層部分：設置數據交換平臺，采取松耦合連接方式，將本應在數據倉庫進行的數據清洗、轉換工作轉移到數據交換平臺，避免源數據與數據倉庫的直接交互，提升數據獲取、加載效率。

4)數據架構層部分：主要是完成數據的加載工作，實現對各種同構、異構試驗數據的整合，以靈活、高效的方式進行存儲，以數據標簽的方式對數據進行分類，數據管控從元數據管理、數據質量和數據標準等三個方面統一對存入的數據進行標準化處理。其中HDFS(hadoop-distributed-file-system)為整個平臺存儲數據的基礎，用來存儲導入進來的原始數據；HIVE為火箭數據提供的基于大數據的數據倉庫，用來存儲清洗后、數據映射后的范式化數據；Spark平臺為離線的數據分析與處理提供底層支撐。

5)應用層部分：主要負責具體業務邏輯的實現，對數據進行清洗、映射，實現數據倉庫的維護和管理，避免用戶對數據倉庫直接訪問，提供多維度數據分析、查詢、數據統計等服務，支持定制化統計分析以及更進一步的數據挖掘。

6)顯示層部分：主要實現統一的交互界面，將查詢報表、統計分析、數據挖掘的結果展示在用戶面前。

2 運載火箭數據倉庫主題及模型設計

2.1 業務層主題

數據倉庫的建立是為業務層的分析和決策提供服務的[20]，對業務需求和特點的充分理解是后續數據模型是否準確和有效的關鍵，根據運載火箭數據倉庫的業務類型，設計了三大主題，如圖1。

專家知識主題：運載火箭在產品研制過程中會產生大量的設計數據，包括原理圖、源代碼、文檔報告等原始知識，可以分為硬件和軟件兩大類，硬件包含圖紙、物料和結構等內容，軟件包含源碼、工程化文檔和等內容，這些知識對于新產品的設計以及現有產品的優化改進有著重要的參考意義[21]，通過查閱功能相似的產品設計圖紙、軟件功能模塊和相關產品文檔，能夠有效提高新設計產品的可靠性、功能完備性。

歷史測發數據分析主題：火箭在不同批次和不同階段試驗中產生了大量的測發原始數據，這些數據全面記錄了火箭在不同批次、不同流程、不同地點下的狀態，這些數據對于現有火箭產品的設計、狀態分析和發射決策具有重要的指導意義。運載火箭的原始數據分散存儲于各個系統，數據格式未統一，有必要將數據提取出來以變數據挖掘分析，可以跨時間維度、跨型號維度、跨靶場維度等多角度對測發數據進行比對分析，對火箭設備的狀態把控以及產品設計提供數據支撐。

故障數據分析主題：在火箭測發過程中，會對各單機電壓、電路和加注過程中的壓力、液位、流量等數據進行關注，在不同的測試階段其數值會呈現規律性變化，當火箭系統設備故障或者環境變化時，這些參數會出現異常數值，往往代表著火箭設備隱藏的異常，需要對其發生機理進行分析和確定，判斷是否繼續執行發射，因此需要建立故障數據分析主題，實現故障機理分析和故障趨勢分析，根據故障類別，可以分為供配電故障、控制單機故障、電纜故障、軟件故障、庫房故障、配氣臺故障等多個細分子主題。

2.2 面向火箭生命周期的數據模型

數據模型的建立是對火箭進行數據抽取以及主題分析的基礎。能否充分理解和透徹分析火箭數據以及業務需求直接影響到后面數據模型的設計是否合理、有效，面向火箭生命周期建模，構建統一的數據表示模型，模型需要能夠表征專家知識主題、歷史測發主題和故障分析主題所需要的多個維度信息，這些維度信息對應原始數據映射后的存儲結構。

建立數據模型的目的是幫助對離散獨立的原始數據進行規范統一的處理，以清洗的數據邏輯關系實現主題分析工作。結合火箭的分析需求，以歷史測發主題分析為例，當要對某一單機設備特性進行分析的時候，該單機的歷史數據反映的是該關于該單機設備方方面面的信息，能夠對該單機的特性、質量和極限情況做出評估，可以從9個維度對數據倉庫中的信息進行分類，分別是設備參數、時間、任務、階段、地點、流程、型號、設計信息和故障信息維度。

1)設備參數維度包含該單機設備對應的可表征該設備狀態的信息，如單壓、電流、溫度和壓力等信息。

2)時間維度包含該設備歷史參數記錄的日期。

3)任務維度包含該單機設備歷史測發數據分別對應的某一型號的發次信息。

4)階段維度包含歷史測發數據所對應的研制階段，比如分系統階段、集成試驗階段、合練階段和正式任務階段。

5)地點維度指當前歷史測發記錄生成的地點，包含分系統實驗室、總裝廠房以及各大靶場。

6)流程維度包含當前記錄所對應的試驗流程，不同的試驗流程對單機的工作特性影響比較大，包含總檢II、總檢I等測試流程。

7)型號維度包含了當前測試記錄所對應的型號，多數單機設備可通用于各個型號，通過比對單機設備在不同型號中的表現對于單機特性分析具備很大的意義。

8)設計信息維度包含單機設備的原理圖、結構、物料和軟件等信息，可以從頂層統籌了解單機設備特性。

9)故障信息維度包含單機設備相關的軟硬件歸零信息，以及各項更改和偏離設計。

3 系統軟件設計

3.1 數據清洗方案設計

運載火箭試驗數據資源相對穩定，在不同階段的測試數據均存在備份，但這些數據未經整理，來自于不同型號、不同階段的試驗，存在著格式不統一、重復數據、無效數據等問題，需要通過數據集成之后傳輸進數據倉庫。數據集成的一般過程主要是將異構分布式數據源數據通過一定的規則映射復制到數據倉庫，如圖3所示，將不同來源的數據按統一的格式處理，主要完成的工作包括數據的抽取、轉換和加載，即數據的ETL(extract-transform-load)過程[22-25]。

圖3 數據清洗流程

ETL過程就是將火箭試驗過程中產生的數據轉化為能夠存儲在數據倉庫的決策支持型數據，設計到多個數據源的數據清洗及合并。對于試驗數據的清洗，分為結構化數據和非結構化數據兩類，對于已經結構化的數據，比如火箭各測試階段源數據、存儲在數據庫中的數據，可以通過制定ETL規則，直接抽取所需要的數據，對于文檔，圖紙、圖像等非結構化的數據，可以人工預定分類和編碼準則，對文件進行梳理，提取有用信息。

數據去重和無效數據剔出后，需要抽取有效數字字段并進行數字映射到數據倉庫中，主要是根據試驗數據的分析和故障診斷需求，對數據字段進行拆分，建立數據字段之間的映射[26]，進行相關字段的合并和補充，對于運載測試數據，建立時間序列、數據來源等多維度視角對數據進行梳理合并。

3.2 數據倉庫應用層設計

運載火箭數據倉庫系統采用分布式軟件架構，建成一個以數據存儲、管理、統計分析為核心功能的分布式數據管理系統，如圖4所示，它基于Hadoop 分布式系統進行架構使用Hive 數據倉庫、Flume 數據采集工具、Spark 分布式計算框架形成后臺計算系統，前端可視化系統，最后進行聯合開發，以滿足數據可視化顯示，數據存儲、分析任務管理等功能。

圖4 測發控數據倉庫軟件結構

應用層軟件架構主要分為三個模塊，數據倉庫模塊、應用顯示模塊、統計分析模塊。

1)數據倉庫模塊：負責管理火箭數據的存儲、查詢和計算，將大量的設計數據和測試數據進行科學的保存和管理，讓設計人員能夠便捷的獲取全面多維度的測試數據和設計數據，對數據進行分析利用。包括Hadoop、Hive、Spark、Kafka、Flume等組件，使用Mysql進行元數據管理。

該模塊主要提供以下功能點：①歷史火箭原始數據的存儲、新增測試數據的導入；②結構化和非結構化數據的存儲與關聯；③完成清洗合并后的數據上載；④元數據的底層操作管理。

2)應用顯示模塊：負責數據顯示、導入和任務管理等與用戶直接交互的功能。前端顯示界面包括數據展示、數據導入導出接口、數據定制化分析界面、故障預測界面。后端處理負責數據查詢、計算、傳輸和前端渲染工作。此外該模塊還將通過服務通訊接口與數據倉庫模塊，統計分析模塊通訊，以實現數據交互和任務交互功能。

應用層軟件采用B/S架構設計，因此本模塊主體分為兩個部分，一個網頁端、一個是服務端，網頁端作為與用戶的主要交互界面，服務端則負責網頁的渲染，數據傳輸、緩存以及與外部通訊的功能。網頁端則，位于上層，通過網頁展示相關性分析等數據展示、故障預測功能，進行導入數據和分析任務管理等。

3)統計分析模塊：負責具體的數據模擬，預處理、統計分析、特征工程，建模分析、故障診斷等功能，是數據分析應用的核心模塊。統計分析模塊是發揮火箭寶貴的數據價值的關鍵所在，通過深層次的數據分析，挖掘不同測試參數之間存在大量的內在的、潛在的數據和信息[27]，為火箭的設計和測試工作提供幫助。

該模塊主要提供以下功能點：①具備相關性分析能力，可自由選擇測試參數進行分析并生成結果；②具備基于歷史數據學習的故障診斷能力，能夠實現對火箭常規參數的拐點識別，異常識別；③具備數據包絡分析能力，可跨型號、跨時域對參數實現包絡分析④提供定制化數據分析模塊，滿足不同的數據分析需求。

3.3 基于數據和知識融合的故障診斷方法

現有基于統計學習的模型在獨立同分布的情況下有不錯的結果，但是火箭的數據樣本大多不滿足獨立同分布的樣本且數量較少，診斷結果就會變得不穩定，缺乏可解釋性，即使診斷結果是正確的，也無法將該結果作為火箭決策的依據，為了提高統計模型診斷的效果，需要進行數據和知識融合的故障診斷，以知識因果關系訓練統計學習模型，充分利用專家知識庫。

首先對數據和知識進行相關性分析以確定數據的因果方向，針對時序數據、非時序數據和獨立同分布數據的每一對節點進行獨立性檢驗，將其中一個節點去掉保持其余不變，計算因果圖的性能，如果性能接近保持不變，則認為該邊可以被去掉，重復這一過程，直至任何相連的節點都不獨立，隨后對圖的方向進行檢驗，確保因果圖的方向是由因到果，針對得到的因果圖，使用干預推理對遺漏的因果關系進行調整補全，最后采用反事實推理方法找出給定結果的原因，最后得到基于因果理論的結構因果模型。

隨后進行基于強化學習的因果建模，使用結構因果模型對數據倉庫切片數據得到因果圖，使用合適的評價函數進行訓練，尋找最優的因果圖。

將因果推理嵌入到機器學習模型中，通過數據倉庫中的知識因果關系，使得機器學習模型在受到因果關系約束的情況下對樣本數據進行學習，從而提升模型的準確率和穩定性。

4 實驗結果與分析

4.1 實驗環境及驗證方法

為了驗證面向火箭數據的數據倉庫實際使用性能，數據倉庫的構建包括4臺服務器(CPU：Intel Xeon E5-2640 六核心，主頻2.5 GHz，內存32 G，存儲4 T)和多臺顯示終端。數據倉庫的構建需要以Hadoop大數據平臺為基礎，使用3臺服務器作為Hadoop節點組成數據倉庫，1臺服務器作為應用服務器負責應用顯示模塊和數據分析模塊，4臺服務器配置相同，數據倉庫系統通過交換機與外部訪問終端連接，訪問終端以網頁的形式與數據倉庫進行交互，進行數據的導入、導出，數據的分析處理。

原始數據選用某型號10發火箭歷史數據，數據包含老的測發控系統測試發射數據和新型一體化測發控系統測試發射數據，數據生成周期包含集成實驗、發射場實驗數據，數據維度包含電氣數據、測量數據、動力數據。

為測試運載火箭數據倉庫能力，從數據導入和歷史測發數據查詢兩個方面對數據倉庫進行測試。

4.2 數據導入測試

新型一體化測發控系統在軟件設計和通信協議上較老的測發控系統有很大不同，對應的火箭歷史數據也有很大不同，需要對火箭數據從頂層結構上進行預處理，將同單機同硬件結構所產生的數據進行數據抽取，映射到同一數據標簽下，將同單機不同硬件結構所產生的數據之間進行關聯，映射到不同的數據標簽下。在進行數據導入工作時，設計師需選擇導入的數據類型以及對應的測試屬性，如圖5所示，上傳成功后，ETL工具會對數據進行抽取映射，按統一的數據格式存儲于數據倉庫中。

圖5 數據導入界面

為驗證數據倉庫對于火箭原始數據的導入速度，選擇某型號3組原始測試數據進行測試，測試數據均選用在相同測試流程下生成的原始記錄數據，三組測試數據分別包含1條測試流程、5條測試流程和10條測試流程，數據導入測試結果如表1所示。

表1 數據導入測試結果

表2 歷史數據查詢響應結果

從上數試驗結果可以看出，導入數所需要的時間并非線性隨數據大小而增長，而是逐步減少的，因為在數據導入過程中伴隨著清洗與合并操作，當數據量較大時，該部分工作所占用時間會被均攤。

4.3 歷史測發數據查詢測試

對于數據的統計分析功能，數據倉庫支持對數據的單任務多參數、多任務單參數、跨型號參數查詢、不同參數關聯查詢，支持多個維度的定義查詢規則，同時支持參數的包絡分析，拐點識別等功能。

以地面電源參數為例進行數據查詢和分析，地面電源是火箭系統的重要設備之一，為火箭的測試和發射提供能源支持和保障，其穩定性是整個火箭能否正常工作的關鍵，通過電壓和電流等參數間接判斷地面電源狀態是每次測試必做的內容之一。在本型號直流電源共計4臺，選擇“D96-1電源電壓”作為查詢參數，如圖6所示，數據倉庫提供了“D96-1電源電壓”參數的全周期可視化展示，藍色的曲線為電壓變化情況，綠色曲線為數據分析服務自動計算出在該測試周期的參數包絡值，黃色數據點為數據分析服務識別到的參數拐點。

圖6 “D96-1電源電壓”數據查詢

為驗證歷史數據查詢性能，使用“D96-1電源電壓”參數，分別選擇查詢不同時間區域的參數，觀察其結果響應時間。

從上述查詢結果可以看出，數據倉庫對于歷史測發主題的參數查詢響應時間為秒級，該響應時間可以支撐在實際型號任務中的應用。

5 結束語

本文研究了面向火箭數據分析和故障診斷的數據倉庫設計。對火箭數據進行了跨型號、跨批次的整合和管理，為火箭測試和設計數據的長期維護搭建了框架，目前已在某型號的數據管理中實現應用，能夠對火箭測試數據進行分析和展示。但本文在對火箭的數據利用方面只進行了相關性分析、簡單故障識別，后續將通過機器學習等手段，進一步挖掘火箭歷史數據中的價值。