面向特種車輛狀態監控和故障診斷的數據庫索引結構構建

樊輝錦，歐陽中輝，陳青華,胡道暢

(1.海軍航空大學岸防兵學院,山東 煙臺 264001；2. 92635部隊,山東 青島 266001)

1 引言

隨著軍事裝備的發展，特種車輛已經發展成為集機械、電子、液壓和武器系統于一體的信息化作戰系統，其組成結構十分復雜，作戰環境涉及沙灘、海島、荒漠和高原等，使得維護與故障診斷較普通車輛也更為復雜[1]。隨著特種車輛可靠性、維修性和安全性等技戰術指標不斷提高，對車輛維護保障和故障診斷提出更高的要求[2]。故障診斷技術利用各種先進傳感器和智能診斷模型算法對車輛及部件進行診斷、監控和預測，其準確性和實效性在裝備保障體系中尤為重要，而且特種車輛故障診斷系統中數據庫系統性能的好壞對診斷結果的準確性和診斷效率產生直接影響。

國內車輛故障診斷技術及其數據庫設計的相關文獻中，盧玉傳等[3]對無人車類特種車輛的故障預測與健康管理進行了可行性分析，給出了數據庫總體設計原則；陳偉等[4]針對特種車輛液壓系統建立綜合診斷和健康管理系統，運用SOM神經網絡進行故障的診斷，給出了數據中心功能；王威杰等[5]改進車輛故障維修數據庫中數據查詢算法，采用模糊粗糙集方法提高查詢效率并仿真驗證；吳婷婷等[6]針對特種車輛機電系統故障提出了一套測試方法，支持全壽命周期的故障診斷和監控管理，給出了數據庫功能分類；趙媛媛等[7]對國外特種車輛故障預測系統最新發展給出了介紹，并展示了各類車載系統解決方案(包括數據庫組成)。上述研究主要針對狀態監控和故障診斷中各類系統架構設計或診斷方法模型的研究，在實現過程中部分給出了數據庫功能設計，并未結合車輛狀態監控和故障實際進行數據庫系統深入研究。

本文分析了特種車輛狀態監控和故障診斷的底層數據需求特點，利用統一建模語言(unified modeling language，UML)對數據庫系統整體功能進行描述[8]，給出以特種車輛和故障診斷為中心的E-R圖模型[9]及關鍵實體字段示例；在索引結構方面，對時空R樹進行改進，并結合B*樹構建索引數據庫，并利用MySQL5.6完成數據庫系統搭建和測試。

2 數據庫系統設計

在特種車輛遠程狀態監控管理和故障診斷系統中，故障診斷不僅需要故障點時刻的數據，還需要故障點附近相關數據來判斷故障。本節主要從數據庫系統功能分析、E-R模型設計和索引結構等3個方面進行研究。

2.1 基于UML的系統功能設計

數據庫系統主要為各功能模塊提供數據存儲、共享和快速查詢，利用UML語言對系統功能進行描述，如圖1所示。狀態監測終端主要將各傳感器采集到的數據存入數據庫，并為指揮員提供車輛狀態實時顯示，包括任務執行狀態、健康狀態、位置信息和武器系統信息等；故障診斷功能從數據庫中查詢預先建立的各類故障診斷模型(神經網絡模型、專家系統、故障樹和SVM等)[10]，并根據相關狀態監控信息做出判斷，得出故障結論并進行報警提醒；維修保障人員根據故障報警和保養提醒進行故障排除和定期保養，將故障處理過程和結果反饋存儲到數據庫系統中。

圖1 數據庫系統功能模塊框圖

不同用戶角色擁有不同的數據庫操作權限。專家可更新維護故障診斷模型相關表；維修保障人員可以查詢調用故障診斷模型給出診斷結論，并錄入處理過程；指揮員可以實時查看車輛狀態，掌握裝備完好率和執行任務情況；系統管理員分配角色維護用戶信息；兵工廠人員針對返回廠維修的車輛制定針對性維修計劃。整個業務流程核心以數據庫操作為中心，各項功能運行效率取決于數據庫操作的性能。

存儲的數據主要分為以下幾個方面：

1) 特種車輛狀態數據。車載狀態信息采集終端主要對車輛動力系統、底盤總成、電氣系統和武器系統等進行監控，監控產生大量實時數據，采用不同的傳輸方式和采樣頻率添加到數據庫中。

2) 狀態數據索引庫?？紤]到建立索引會降低數據入庫效率，將索引更新與數據更新采用分布式的方式分開，并引入緩存機制，這部分將在后文重點闡述。

3) 故障診斷模型庫。主要存儲經過訓練的智能診斷算法模型，算法模型再利用收集到的各類故障狀態數據進行自身更新和不斷完善。

4) 專家系統知識庫。專家系統運用產生式規則作為主要表示形式，存儲的數據主要包括事實庫和規則庫。事實庫存儲現象和故障結論，規則庫分為規則前件庫和規則結論庫[11]。

2.2 E-R模型

數據庫系統性能的優劣關鍵在于數據庫實體關系模型(E-R模型)建立，根據系統功能需求的設計，分析業務邏輯，本節給出系統全局E-R圖模型表述實體與實體的關系，如圖2所示，2.1節實現部分通過表結構示例表述部分關鍵實體與屬性之間的關系。以故障診斷模型和狀態監控為中心表述與其他實體之間的關系，更有利于故障診斷的準確性，同時，模型可根據實際需求數據和診斷模型的不同進行調整。

圖2 系統全局E-R模型框圖

2.3 基于R樹和B*樹的索引構建

數據庫索引的設計不僅要結合數據本身特點，更要緊貼查詢需求，創建效率、存儲利用率、查詢效率和緩存機制等都是設計索引結構需要考慮的因素[12]。目前，MySql數據庫自帶的索引類型主要包括全文索引、哈希索引、B樹索引和R樹索引等4種，其并未提供混合索引機制，在處理時空特性較強的車輛數據和故障的能力較弱[13-15]。

本文數據庫系統主要為特種車輛的狀態監測和故障診斷提供索引支持，實現快速高效的查詢，針對數據時空特性較為明顯、種類較多的特點，利用改進的時空R樹+B*樹的混合索引方法。其中，主體索引結構為改進的時空R樹，用于實現時空范圍內故障信息的高效查詢；B*樹為次要索引，主要實現對單一目標的時序一維索引[16]，可以用于故障點數據精確查詢，如圖3所示。

圖3 改進的時空R樹和B*樹混合索引原理框圖

改進的時空R樹是N+1維的R樹，其中N是指空間維數、1指時間維，R樹中葉子節點最小包圍盒MBR(minimal bounding rectangle)是其孩子集合的時空坐標軸最小范圍[17]，以此來改進R樹的結構。

具體為:利用節點插入算法優化特征車輛實時狀態信息時空R樹結構，同時引入節點分裂算法改進時空R樹結構。改進的時空R樹對某范圍的車輛監控狀態集合、車輛軌跡，或者某時刻的車輛狀態合集(或故障點狀態)、車輛位置等有較好的支持。

采用節點對象標識符OID和Start-Time組成一維關鍵碼構建B*樹，高效精確定位特種車輛在某時刻的狀態信息，進而利用B*樹節點雙向指針進行車輛軌跡追溯[18]，相比于不采用樹結構的索引,能節約75%的存儲空間。

2.4 索引緩存機制

在應用過程中，由于車輛狀態信息和故障表象與時間空間緊密相關，索引的創建同樣按照數據元組的有效時間順序進行。故障點是查詢訪問的重點，被查詢的故障點時刻數據及其附近時刻數據,近期被再次訪問的幾率較大，將這部分數據加入緩存中可減少從外存調入時間。狀態數據和故障診斷模型庫的元組數目龐大，很難在內存中構建全部索引。利用LRU算法(近期最少使用算法)設計索引的緩存實現機制，根據數據量大小設定一個時間閾值T，一個時間周期T內被訪問到的數據維持在緩存中，將一個時間周期T內未被訪問的數據從緩存中釋放，當再次需要時從外存中調取，如圖4所示。

圖4 時空R樹+B*樹索引緩存機制框圖

在索引節點結構中，定義變量TL記錄該節點最近被訪問的時刻，被訪問時更新變量TL為被訪問時刻[19]。樹形索引的查詢通常以根節點或父節點起始，訪問子節點的同時一定已訪問父節點，若父節點在緩存中超時，其子樹中的所有節點也均超時，與父節點一同釋放[19]，TLRU置為0。

3 系統實現和關鍵技術

3.1 故障診斷關鍵表字段示例

3.1.1狀態監控字段

車輛狀態數據是故障診斷的基礎，狀態監控信息如表1所示。

表1 特種車輛狀態信息

3.1.2故障診斷模型

專家系統利用專家知識對故障進行定性的診斷，故障診斷模型準確定位故障發生的具體部位，算法所涉及參數需要結合具體的診斷對象存儲在數據庫中，且保持特征提取、特征降維、診斷模型之間參數的一致性。以神經網絡為例，設計一個故障診斷模型和一系列子實體(神經網絡、支持向量機等)[20]，如表2～3所示。

表2 神經網絡數據

表3 神經網絡權值

3.2 分布式主從架構

將索引結構單獨存儲在獨立從服務器上，利用MySQL的binlog功能實現主從同步和讀寫分離，提高查詢效率，架構設計如圖5所示。主庫Master在執行完SQL語句之后會把語句記錄在binlog中，當從庫Slave連接主庫Master時，將得到主庫中的binlog文件并存于本地，然后從中讀取上次同步時的位置節點，執行SQL語句[21]。

圖5 分布式主從架構框圖

4 實驗測試及性能分析

4.1 測試環境

數據庫系統平臺選用MySQL版本為5.6，操作系統為64位Windows Server 2012，服務器硬件配置信息如表4所示。車輛狀態數據庫選用現役某型裝甲車真實數據集，專家系統和故障診斷模型庫均經過該型車故障數據集的訓練。索引方面，葉節點采用雙向鏈表指針[22]。

表4 數據庫服務器配置信息

4.2 壓力測試及分析

在數據存儲過程中，考慮處理器線程阻塞、存儲器緩存、網絡延遲等多種因素的影響，測試數據存儲或讀取速度為在持續存儲請求壓力下系統單位時間內處理存儲或讀取請求的能力[23]，即：

Zmax=Qs/T

(1)

式(1)中：Qs為存儲或讀取成功的數據點數量；T為總耗時。

通過編寫腳本，測試本文設計的數據庫系統插入10、100、1 000、10 000、100 000條數據的耗時(數據結構參考數據庫設計部分)，對于因阻塞超時未能成功存儲的數據記錄，再次發出存儲請求，根據機器性能發出存入系統的請求后，統計存儲全部數據耗時[24]，將結果與同樣實驗條件下Mysql自帶索引結構相關性能進行對比(見圖6)，計算每秒處理速度，如圖7所示。數據庫的讀取測試，在100 000條數據集中分別查詢1、10、100、1 000、10 000條數據的查詢耗時如圖8所示。

圖6 數據庫寫入速度直方圖

圖7 數據庫處理速度直方圖

圖6、圖7表明本文索引結構數據庫寫入速度、處理速度與Mysql相差不大。圖8表明，在數據量較大時，在數據庫查詢耗時上，以本文索引結構構建的數據庫性能要優于Mysql自帶索引結構。

圖8 數據庫讀取時間直方圖

4.3 索引創建的時間性能和存儲效率

目前，TB*樹在時空數據索引方面綜合性能較優，選擇將其與本文索引方法(索引創建和時空查詢處理方面)進行對比分析[25]。以1 000數據樣本為例，兩者均采用經典R樹的平方級分裂策略，設索引樹的創建算法時間復雜度均為O(N/M)，其中，M是葉子節點的扇出參數，N是故障時刻點數量[26]，索引創建的試驗結果如表5所示，其中包括時間開銷和存儲代價。

表5 索引創建試驗結果

時間開銷方面，改進的時空R樹在創建和插入葉子節點時包括節點選擇和節點分裂等2個操作[27]。創建改進的時空R樹過程中節點選擇與節點分裂算法使得時間開銷較高，如圖9所示。

存儲代價方面，本文索引結構數據量為R樹和B*樹二者之和，改進的時空R樹節點中，絕大多數超過83.7%的是葉節點，結合了B*數據，并采用獨立數據庫后，在數據集為 100 000數據量時存儲空間為865.3MByte，其存儲代價遠小于TB*樹。

5 結論

本文數據庫系統為特種車輛的狀態監控和故障診斷提供支持，從系統功能模型出發，利用UML完成功能建模，建立實體關系模型，并設計了索引結構實現高效快速查詢檢索。在系統實現上，結合故障診斷需求和特點,給出數據庫字段示例，引入索引緩存機制，并設計主從服務器集群實現讀寫分離。測試結果表明,數據庫系統整體性能可滿足故障診斷需求，可提高裝備保障效率，適用于工程實踐。