RT21－ISCS綜合監控系統中實時歷史數據庫的設計與實現

劉佳寶 梁 奕 陳天浩

（國電南瑞科技股份有限公司，210061，南京∥第一作者，工程師）

RT21－ISCS綜合監控系統是針對軌道交通和工業控制領域特點，集先進的計算機技術、網絡通信技術和自動控制技術于一體的大容量、多專業、高性能的計算機軟件系統。它是第一套應用廣泛的國產軌道交通綜合監控軟件，目前已成功中標北京地鐵9號線、北京房山線、重慶軌道交通3號線、廣州珠江新城APM（旅客自動輸送系統）等的綜合監控系統和南京地鐵2號線綜合信息系統。

對于綜合監控系統而言，歷史數據的存儲以及方便、快速的檢索具有重要意義。然而，軌道交通的現場設備多種多樣，每天將產生大量數據（如南京地鐵2號線RT21－ISCS系統每天產生500萬～1 000萬條采樣數據），普通的關系型數據庫如ORACLE根本無法滿足存儲和檢索的效率要求。國外一些成熟的實時歷史數據庫如PI，INSQL價格昂貴，可以處理的點數少。而軌道交通綜合監控系統具有海量信息，如北京房山線全線預期約有50萬點，因此，必須針對軌道交通綜合監控的特點，設計開發自己的實時歷史數據庫來處理海量的采樣信息。

1 跨平臺和C/S結構的設計

RT21－ISCS綜合監控系統整體上都要求是跨平臺的，支持所有主流的操作系統。因此，其實時歷史數據庫軟件FVDB（Full View Data Base）的設計必須滿足跨平臺要求。這就要求在具體的開發中采用跨平臺的開發語言以及跨平臺的第三方庫，保證的平臺無關性。

為滿足RT21－ISCS綜合監控系統的分布式架構及實際工程的需要，FVDB必須是C/S（客戶端/服務器）的結構設計。C/S結構提供了充分的開放性和靈活性。如圖1，由于采用了雙機熱備份的方式（控制中心需要保存全線各個車站的數據），每個車站的數據提交程序fvdb＿commit＿server至少要同步四臺FVDB服務器（本車站的主、備FVDB服務器和控制中心的主、備FVDB服務器）。

2 FVDB核心模塊的設計

FVDB的核心模塊主要包括點管理、實時數據管理、歷史數據管理等三個模塊。

圖1 RT21－ISCS綜合監控系統中采樣數據的存儲同步過程

2.1 點管理模塊

“點”（記為point）是對不同數據流唯一性的表示，如電壓電流值、開關狀態、溫度計示數等。任何可測量的設備屬性都可以被定義成“point”。點類型主要包括數字量和模擬量。在軌道交通綜合監控系統中，數字量變化頻率較低，模擬量變化頻率較高，因此，其歷史數據大部分為模擬量。

在FVDB中，點用一個18位的字符串來唯一標識，稱之為點標簽。單點信息一般包括點標簽、類型、單位、描述、死區值、是否保存歷史數據、B＋樹根結點等。其中，點標簽是唯一標識一組點信息的關鍵字。所有點信息的集合構成了一張點表，全部放到內存中。點管理主要指對點表的維護，包括點的增加或刪除、點信息的修改、點的快速查找等。

點是數據管理的基本單位，對數據的各種操作都是以點為單位進行的。因而，快速的點查詢對提高系統性能具有重要意義。FVDB采用HASH表的索引方式進行點查詢，可快速查找到指定點信息。

2.2 實時數據的管理

實時數據是點在最近某一時刻的瞬時值，是與時間有關的數據。每一個實時數據記錄上都有一個時間戳，記錄實時數據的采樣時間。一條實時數據記錄包括點標簽、時間戳、狀態、數值等四個組成部分。

根據軌道交通監控系統中數字量多、模擬量少，以及數字量變化慢、模擬量變化快的特點，為更好地將實時數據轉化為歷史數據，本文設計了雙緩存的方法。具體如下：

（1）為每個點設立一個相對較大的緩存（如100條記錄的緩存），記為cache＿1。數據庫服務端接收到實時數據后，并不直接存入B＋樹，而是根據點名直接寫入該點對應的cache＿1中；當cache＿1存儲的記錄數達到最大限度后，統一打包存入B＋樹（如圖2所示）。這種以點為單位的批量存儲，極大地減少了B＋樹的寫入次數，降低了B＋樹的高度，提高了寫入和查詢的速度，并且在得到點的一組數據后，也能進行有效的數據壓縮處理。在點數特別多（如50萬點）的情況下，可事先開辟一定大小的緩存區max＿cahche1s。當該緩沖區全部被占滿后，在調入新的點的cache＿1時，采用最近最久未使用的置換算法把那些久未使用的點調出內存。由于數字量變化慢、模擬量變化快，故模擬量更頻繁地訪問cache＿1。但軌道交通監控系統中數字量占絕對比例而模擬量相對較少，因此在系統允許的情況下，把 max＿cahche1大小設為接近模擬量點數×sizeof（cache＿1），即可具有較好的命中率。

（2）根據內存大小，為每個點設立一個相對較小的緩存，記為cache＿2，保證所有點的cache＿2都能放到內存中。實時數據過來后首先存入相應點的cache＿2緩存中，當cache＿2存儲的記錄數達到上限后，再寫入cache＿1（見圖2）。設置緩存cache＿2的目的同樣是為了提高速度。由于數字量多但變化慢（一天可能只有幾條數據），這個較小的緩存對數字量而言足夠應付很久。通過cache＿2批量處理，極大地減少了訪問cache＿1的次數，也就減少了程序訪問磁盤的次數，提高了寫入速度。

圖2 FVDB的數據流

綜上所述，所謂雙緩存技術，即為每個點分別設立一個相對較大和較小的記錄存儲緩沖。小緩沖始終在內存；而大緩沖可以在內外存間調入調出，采用最近最久未使用的置換算法。這種緩存技術的使用，極大地提高了數據庫處理歷史數據的性能，進而可以支持更多的點數。

2.3 歷史數據的管理

當實時數據的存在超過一定期限后，即被認為是歷史數據，存放在磁盤中，如圖3所示。

圖3 實時和歷史數據的關系

保存歷史數據具有重要的實際意義。通過分析過程歷史數據，不僅可以優化企業生產，也為故障分析提供了有力的工具。FVDB能夠保存所有點的歷史數據，而且可以保存3年以上。

2.3.1 采用B＋樹索引結構

FVDB采用B＋樹來組織文件數據。這是因為在工作集有序的情況下，B＋樹具有較好效率，而FVDB存儲的歷史數據由實時數據產生，所以處理的基本都是時序數據。

當點的一組實時數據過期后就需要存儲它在B＋樹中。每個點都擁有一棵以時間為索引的B＋樹，B＋樹的葉結點就是一組歷史數據的壓縮包。

2.3.2 歷史數據的壓縮方法

為了能夠在有限存儲空間中保存長期的歷史數據，FVDB采用了Huffman壓縮算法（如圖4），分別對數值、時間戳、狀態進行壓縮，從而大大減少歷史數據存儲占用的磁盤空間。當需要查詢某個點的一段歷史數據時，先把滿足條件的壓縮包按時間順序依次讀到內存，然后在內存中解壓縮，還原成原始數據，返回給查詢用戶。

圖4 壓縮算法的應用

3 結語

本文根據軌道交通綜合監控的特點設計了實時歷史數據庫FVDB，它具有數據保存時間長、存儲和檢索快速的特點。FVDB已經在南京地鐵2號線的RT21－ISCS綜合監控系統中應用，驗證了本文設計的可行性。

［1］劉孟覺.RT21－ISCS綜合監控數據模型功能設計［C］∥2008江蘇省電機工程學會自動化及計算機應用專業委員會學術年會論文集.南京：江蘇省電機工程學會自動化及計算機應用專業委員會，2008：587.

［2］劉云生，盧炎生，王道忠.實時數據庫系統（RTDBS）及其特征［J］.華中理工大學學報，1994，31（6）：66.

［3］錢笑宇，張彥武.工業實時數據庫的研究和設計［J］.計算機工程，2005，31（1）：98.

［4］朱健，王盛明，盧秉亮.基于實時數據庫的實時數據處理研究［J］.微處理機，2010，31（1）：83.