面向航天信號數據的柔性分析平臺設計與實現

姜 南，史梅花，姚 遠，戴 偉

(1.北京控制工程研究所，北京 100080；2.北京途瑪勝遠科技有限公司，北京 100195；3.北京航空航天大學，北京 100191)

0 引 言

航天器是一類由機械、電子、材料、控制、能源、通訊、計算機技術等多學科協同工作的大型多功能復雜系統，具有結構復雜、故障危害性大、意外干擾因素難以把握、星上資源配置約束條件苛刻、地面人工干預的機會和能力受限制等特點[1]。因此，目前知識系統中欠缺的“黑盒子”機理使得設計師無法對產品進行充分的認知，也就難以進行有效的故障預測，在航天器研制和使用中會造成不可估量的損失。在航天產品研制及飛行過程中，隨著自動化技術的持續發展，采樣頻率的提高，計算技術及存儲容量的改善，地面試驗和在軌飛行已經積累了海量的數據(該文統稱為信號數據)，這些數據反映了產品功能和性能的各種突發的或規律性的變化，是了解產品性能、開展故障預測的重要依據。若能獲得這些參數的緩慢變化特點并對其趨勢進行分析預測，便能夠逐步實現對航天器健康狀態的有效管理[2]。

目前國內外已開展了大量的關于趨勢分析及參數預測等故障預測和健康管理研究[3-5]，“基于狀態信息、基于異常現象信息、基于使用環境信息、基于損傷標尺、數據融合及綜合診斷”、“統計預測、數字預測、智能預測、信息融合”[6]等分類方法可見諸文獻。無論如何分類，基于數據的故障預測方法的基本思想都是在一定代價函數的約束下，對對象的歷史數據進行學習，逼近數據中所隱含的映射機制，得到對象的數學模型關系，從而對故障進行預測。時間序列分析方法[7]、機器學習(概率趨勢、神經網絡、支持向量機)技術[8-10]都要基于一定的分析目的而設計和應用，不能直接復制已有的算法程序。另一方面，航天產品往往是一個產品族，同一產品族下的產品數據分析有其相通之處，并不能一事一議地臨時編寫算法獲得分析結果，而必須要實現組織層面的分析算法共享。

該文研究了面向航天產品信號數據的分析平臺的技術特點，構造了系統的架構，從而在組織層面進行算法的靈活管理與應用。

1 航天產品信號數據分析面臨的技術問題

1.1 多階段、長時空跨度的數據規范問題

航天產品從開展力學、溫度等地面試驗到在軌飛行，跨越了極大的時間尺度和空間尺度。雖然是小樣本，但數據產生在不同的測試設備、不同傳感器中，呈現典型的高維度、多源特征。主要表現在：

(1)不同測試設備對產品的定義不同。容易造成即使是同一個產品，由于經歷不同測試設備開展的試驗測試，其數據文件在數據庫中也是一個個的孤島；

(2)測試設備形成的數據文件存儲格式也各不相同。測試設備形成的文件有Txt文件、Excel文件、Access文件等，讀取這些不同格式的數據文件，需要采用不同的文件讀取技術，降低了數據使用的效率；

(3)不同傳感器的采集頻率各有不同，時間格式不同，造成不同應力環境下的信號數據無法進行有效的融合；

(4)數據解析方式不同，采集數據中有十進制數據，也有十六進制數據。系統無法自動識別十進制解碼表示或是十六進制源碼表示。

這些不規范、不標準的數據散落在各個測試系統中，會對后續的數據融合與分析造成極大的困擾。

1.2 高采集頻率的數據存儲和使用問題

航天產品經歷眾多試驗，且設計壽命往往高達10年以上，在試驗和在軌飛行階段采集頻率一般為毫秒級，因此會在較短的時間內生產海量的數據。以1 k/s的采樣率計算，連續采集一天，一個參數的數據量將達到7億行。而這些數據必須能夠及時地進行存儲和管理。

在使用數據時，往往是以一個參數為單位獲取數據，需要獲取一個參數在一個大時間尺度的數據。傳統的數據庫存儲方式是將數據按照表的結構進行存儲，表的每一列是一個參數，每一行則是對應具體的參數值。但是這個表結構的存儲方式在行數大于一億行以后，存儲和查詢的效率將會急劇降低。導致的結果就是，將一個幾GB的數據文件存進去速度就很慢，當要把其中某一個參數的數值全部獲取出來時將更慢，時間將長達十分鐘以上。

可見，要實現高速的數據吞吐能力，會對數據庫的建設提出非常高的要求。

1.3 算法復雜且專業

事實上，無論是航天產品還是其他任何領域的工業產品，簡單地去應用某種發布的成熟算法進行聚類或異常檢測等分析是不現實的。在專業領域的數據分析中，面向產品的物理或者機理知識不可或缺，因此分析算法往往并不能依賴于數據分析專家。航天企業設計師一般具有較高的綜合素質與能力，往往可以獨立編寫分析算法；即使數據分析專家不可或缺，也是要與設計人員的工程知識結合，協同定制地編寫算法并驗證。因此，算法往往由專業領域人員編寫并驗證，其編寫工具可以是C，可以是Python，也可以是R、MATLAB等等，在調用時需要能夠調用不同的軟件接口。而在一個分析項目中，也往往需要將多個算法用一個流程來管理和驅動。從另一方面看，不同規格的產品在數據分析中往往具有相似性，因此算法在一個組織內往往需要共享使用。

所以，對不同工具開發的算法進行封裝、管理和調用也成為解決信號數據分析的關鍵技術之一。

2 信號數據分析平臺的設計與實現

2.1 總體架構設計

為實現信號數據在不同目的和場景的數據分析功能，數據分析平臺設計包括運行支撐環境層、數據層、應用支撐層、業務應用層和前臺展現層，采用.NET框架技術設計，如圖1所示。

在運行環境支撐層中，配置工業海量數據分析所需的網絡、應用服務器、數據庫服務器、數據備份設備等硬件及用于存儲的Oracle 10g數據庫。

數據層則是數據庫中存儲的所有數據，包括各類測試設備產生的多源數據和封裝的數據分析算法庫。

應用支撐層是數據層與應用層之間的功能組件，包括數據預處理組件、數據存儲組件和算法執行引擎。根據用戶需求操作數據層中的數據，并將需要數據反饋給應用界面。

業務應用層是系統中實現的業務功能，包括算法庫管理、算法分析接口、產品數據管理等，用于對數據分析的業務進行規范性管理。

圖1 信號數據分析平臺的總體架構

前臺展現層則是用戶使用和操作的系統軟件界面，根據每個用戶的特點、喜好和角色的不同，為特定用戶提供量身定做的訪問關鍵業務信息的安全通道和個性化應用界面。

2.2 關鍵技術的實現

2.2.1 數據預處理規范的設計

數據預處理規范的設計目的是使不同測試設備、不同階段產生的信號數據相互握手，數據能夠規范管理。通過對航天產品信號數據的分析，數據預處理規范設計包括編碼、文件格式、時間格式、缺省值標識、數據解析方式等內容。

(1)編碼規范。

為使在不同業務系統、不同測試設備中產生的數據能夠握手，需要在組織層面建立包括產品代號規范、版本編碼規范、編號規范在內的各種編碼規范。當信號數據文件存儲到數據庫時，便可自動解析該數據文件所屬的型號及階段、所屬產品及版本，并將數據文件中測試結果與數據字典中的產品參數相關聯，實現統一產品源下的數據存儲。

(2)數據文件格式標準化處理。

將來自于不同試驗設備的不同格式的文件，如Access文件、Txt文件、Csv文件等統一為Txt格式數據文件，作為標準數據文件的文件格式。

(3)時間格式標準化。

針對多源數據在采集時間、頻率上的不一致，如時間格式多種多樣，“2018-09-08 12:06:07.245”、“2018/09/08 12:06:07”、“2016-10-09 11:17:37”各不相同。以典型航天執行機構為例，其數據文件至少包括十幾種時間格式，因此也需要進行標準化，形成一個統一的時間格式。本平臺設計將所有的時間格式標準化為“2018-09-08 12:06:07.245”形式。

(4)缺失值標識標準化。

試驗數據和在軌數據往往存在缺失值，而不同來源的數據文件缺失值有“ ”(空格)和“-”兩種標識。由于在文件格式標準化處理中采用txt格式的數據文件，不能直觀看到空格，因此將采用“-”作為數據缺省值的標準標識方式。

(5)數據解析方式可配置。

由于測試設備輸出文件有十進制解碼表示方式和十六進制源碼表示方式，面臨著不宜解析的問題，而XML可以為解決各種類型的數據共享、交換和使用問題提供一種行之有效的技術解決方法[11]。并且，Oracle XML DB數據庫管理系統對XML(extensible markup language)文檔提供了強大的支持[12]。因此，系統基于可擴展標記語言對文檔和數據進行結構化處理，設計了一個XML配置文件(Setting.xml)作為用戶對參數的數值表示類型進行配置的文件，如圖2所示。

圖2 setting.xml文件示意圖

2.2.2 高效率的數據吞吐技術

各類測試設備獲取的信號數據均以文件形式傳輸。這些文件具有特定的格式和數據存儲方式，在數據庫系統內屬于BLOB數據類型，這是一種用于存儲無邊界數據的數據類型，將大數據以BLOB方式存在數據庫中便于管理且具有高可用性[13-14]。為實現高效率的數據吞吐，在數據層采用Oracle 10g數據庫管理軟件作為基礎，利用大對象技術(Blob)，采用自定義數據存儲結構存儲產品數據。

系統在存儲數據時，首先在內存中對數據進行緩存和聚集，將不同種類的參數的全部參數值進行分類聚集，如圖3所示。然后再將聚集好的數據塊，以數據塊Blob技術存儲到數據庫中劃分好的磁盤空間。

經測試，以Blob形式進行數據存儲的速度大于10 M/s；以Blob形式獲取100 M數據，并繪制可視化時序圖的時間小于1 s。

圖3 內存中參數值聚集示意圖

2.2.3 柔性的算法配置

鑒于算法是由不同設計師采用不同的開發工具開發并驗證，然后在平臺上加載，因此需要在軟件中實現算法接口調用的多樣性，從而具備在一個分析項目中組合多種算法的柔性能力。

經調研，目前設計師進行算法編寫的工具一般是C#、Python、R、Matlab。因此解決方案是在.NET平臺上由C#編程語言編寫的軟驅動。C#是以事件為驅動

的可視化編程語言，可用于方便快捷地開發運行在.NET公共語言庫上的應用[15]。其實現的軟驅動便可天然地兼容調用C#編寫的數據分析算法dll文件。當調用Python算法和MATLAB算法時，則使用混合編程技術來實現算法執行引擎。以Python算法為例，可以使用IronPython開發執行引擎。IronPython是一個.NET平臺上的Python實現，包括了完整的編譯器、執行引擎與運行時支持，能夠與.NET已有的庫無縫整合到一起，所以IronPython和C#的交互也得以實現[16]。

通過數據分析引擎，系統就可以直接調用不同設計師采用不同工具開發的算法。在實際分析工作中，并不可能只用一個算法來實現分析，即便如簡單的時間序列分析，也需要進行野值剔除、數據拼接、可視化等不同算法。數據分析引擎的實現使得用戶得以對不同算法進行友好的組合，實現柔性的算法配置。

3 應用案例

信號數據柔性分析平臺在筆者所在單位進行了良好的應用。以典型航天執行機構為例，其試驗數據來自于多個測試設備，具有Excel格式、Access格式、Csv格式等，這些不同格式的數據文件經規范處理后，能夠在系統中進行有效的管理，如圖4所示。

圖4 不同測試設備的不同格式文件數據規范化存儲

目前在系統中已經對各類常用數學函數、常用的機器學習算法(異常檢測、聚類等)實現了算法封裝，設計師可以進行靈活的組合和調用。圖5所示為系統對算法的管理，圖6為某產品使用基于動態窗口的異常監測算法進行異常判讀的結果。

圖5 算法管理窗口

圖6 基于動態窗口的異常監測

4 結束語

針對航天產品信號數據多源長時空跨度的特點，分析了將來使用機器學習等人工智能技術進行應用所必須解決的軟件平臺的關鍵技術，設計并實現的柔性分析平臺解決了數據規范、數據吞吐和算法配置的關鍵技術。

此平臺是應用人工智能技術進行各種目的的數據利用的基礎。目前算法雖只包含較為基礎的相關分析、聚類分析等，主要用于產品的健康管理。但平臺提供的算法引擎有效支持了設計師系統提供智慧的工作，算法也將不斷積累和完善，信號數據的分析將為航天產品的不斷改進發揮更多的作用。