污染源自動監控數據傳輸技術研究

趙永輝

河南省環境監控中心

污染源自動監控數據傳輸技術研究

趙永輝

河南省環境監控中心

為增強污染源自動監控數據傳輸的可靠性、上傳數據的完整性，解決實際工作中遇到的數據傳輸和接收問題，對污染源自動監控數據采集和傳輸、接收平臺的數據接收和入庫進行了技術研究、探討分析與實施改造。

污染源；自動監控；數據傳輸；數據庫

引言

河南省環保廳投資6.7億，以“覆蓋全省、功能完備、技術先進、全國一流”為目標，建設了全省環境自動監控系統，利用現代化環境自動監測技術和信息網絡技術，對環境質量、污染源排污情況等實行全過程監控，提升了全省環境管理的科學化、數字化和現代化水平。

污染源自動監控系統是全省環境自動監控系統的重要組成部分，如圖4所示是在全省幾百個重點污染企業建立上千個監控基站，通過監控基站的自動監測設備對企業污染物排放狀況進行自動分析，并將分析結果數據通過網絡上傳到省、市環境監控機構的監控平臺上，環境監控機構通過對數據進行監控和分析，為環境決策和管理執法提供依據。

圖1

為規范污染源自動監控數據傳輸，保證污染源監控基站、傳輸網絡和監控平臺之間的連通，環保部制定了《污染源在線自動監控（監測）系統數據傳輸標準》（HJ/ T212-2005，以下簡稱《傳輸標準》），規定了污染源監控基站和監控平臺接收程序之間數據通訊、控制和報警等信息的傳輸通訊協議，此協議對應于 ISO/OSI 定義的 7層協議的應用層，通常在TCP/IP協議基礎上實現。

1.存在的問題

筆者所在單位在省環境監控平臺部署了上級部門下發的污染源自動監控系統軟件，用于接收污染源監控基站上傳數據并進行監控管理。此系統中監控基站與接收程序之間的數據通訊使用《傳輸標準》規定的傳輸協議。經過將近1年的使用，隨著數據庫中數據量的累積，頻繁出現數據堵塞無法入庫的數據接收故障。具體表現為數據庫服務器長時間持續高吞吐量訪問磁盤，達到每秒幾十不高問題，對污染源監控基站數據上傳采取了下列措施。

3.1.1 污染源監控基站發送的數據指令要嚴格遵照相關標準。要求監控基站上傳的數據指令要嚴格遵守《傳輸標準》，并按照如下格式順序，以利于提高接收程序解析數據包的效率：

ST=xx;CN=xx;QN=xx;PW=xx;M N=xx;CP=&&DataTime=xx;各因子監測值=xx... &&。

其中：ST=系統編號、CN=命令編號、QN=請求編號、PW=訪問密碼、MN=數據采集儀編號, CP=數據區標識。

3.1.2 嚴格規范污染源監控基站上傳的數據類型、污染因子。禁止多余和無用的數據上傳，例如廢氣監控基站只上傳下列數據類型：二氧化硫濃度、氮氧化物濃度、煙塵濃度、煙氣流量、煙氣含氧量、煙氣溫度、煙氣壓力等因子的10分鐘數據和小時數據。接收程序接收數據時同時進行判斷，不符合要求的數據一律丟棄，不予入庫，減少數據庫操作和存儲壓力。

3.2 實現污染源自動監控數據的可靠傳輸

通過擴展傳輸協議，實現污染源自動監控數據傳輸的確認重發和自動補傳機制，增強數據上傳的可靠性，避免因網絡或接收平臺故障造成的數據缺失。

3.2.1 實現污染源監控基站上傳數據的確認重發機制。要求污染源監控基站上傳數據后，需等待接收程序返回的入庫成功確認信息。接收程序接收到數據并入庫成功后，會向監控基站返回一條確認信息。監控基站如果收不到確認信息，則重發這條數據（有一定時間間隔），數據重發最多2次，如果仍未成功，則把此條數據放到補傳隊列中，通過“數據自動補傳”機制來傳輸此條數據。

以廢水監控基站向監控平臺上傳一條10分數據為例介紹確認重發指令的交互過程。

（1）監控基站向接收程序上傳一條數據：

ST=32;CN=2051;QN=2011021011 4012001;PW=123456;MN=01523160184 009;CP=&&DataTime=20110210114000 ;B01-Cou=22.10,B01-Avg=36.83,B01-Min=35.95,B01-Max=37.59&&

"S T=3 2"代表廢水污染源；"C N=2 0 5 1"代表1 0分鐘數據；"QN=20110210114012001"表示本條指令編號；"MN=01523160184009"代表基站數據采集儀序列號。"CP=&&DataTime=20110210114000;B01-Cou=22.10,B01-Avg=36.83,B01-Min=35.95,B01-Max=37.59&&"是數據區內容，包括監測時間、流量的平均值、最大最小值等。

（2）接收程序在收到這條數據指令后，進行解析并將數據存儲到數據庫中，然后向監控基站返回一個確認應答：

ST=91;CN=9014;CP=&&QN=201102 10114012001;CN=2051;&& M甚至上百M字節，服務器幾乎無法響應其它操作，致使接收平臺接收的數據無法入庫，造成數據丟失。同時如果出現網絡或程序故障，監控基站數據無法及時入庫就會造成數據丟失，無法彌補。這些故障和不足對日常管理和監控工作造成很大的不便，急需解決。

2.原因分析

筆者組織專人對污染源自動監控系統軟件、數據庫、服務器、網絡等進行了分析，以期找到故障原因和解決辦法。

污染源自動監控系統軟件完全按照軟件手冊和相關要求進行部署，數據庫和通訊服務器采用高于主流性能配置的服務器，超出系統軟件對于服務器的硬件要求，使用的服務器操作系統、Sql Server數據庫管理系統安裝無誤且進行了優化配置，網絡暢通無阻。因此，數據接收故障可以排除服務器和網絡因素。

通過跟蹤分析，發現造成數據接收故障的原因主要有以下幾方面：

2.1 污染源自動監控系統軟件對海量數據存儲管理存在不足，優化不夠，數據庫性能較低。每天重點污染源數據庫接收數據超過40萬條，幾個主要的數據表均在千萬條紀錄以上，最大的數據表1年的紀錄條數接近5000萬。如此海量數據，數據庫沒有有效的海量數據存儲管理機制，造成單張數據表數據量過于龐大，對數據庫的簡單操作都會造成對磁盤的大量讀寫，數據庫性能低下，隨時間推移數據庫逐漸無法響應監控基站數據入庫的請求，造成堵塞。

2.2 污染源自動監控系統軟件的數據接收程序處理能力較弱，對上千個監控基站同時上傳的大量數據包進行解析和入庫的能力不足。該系統設計初衷是用于省轄市監控平臺直接接收監控基站數據，監控基站數量較少，數據接收程序壓力較小，省轄市監控平臺通過數據交換技術同步到省級監控平臺；根據工作需要，我省環境監控平臺直接接收全省1000多個監控基站數據，數據接收程序壓力很大，超出處理能力。

2.3 污染源監控基站與監控平臺接收程序的數據通訊屬于不可靠傳輸。對于每條監控數據，監控基站只發送一次，數據傳輸和入庫是否成功，接收程序和監控基站均不進行確認；一旦因網絡或數據庫故障等原因造成數據丟失，數據傳輸系統缺乏有效的補救措施，無法進行補傳，造成數據永久缺失。

2.4 污染源監控基站上傳數據不夠規范，沒有嚴格按照相關標準協議和規定傳輸數據，存在大量無用信息上傳的情況，加重了數據堵塞的程度。3.解決方法

針對以上故障原因分析，筆者組織專人對污染源監控基站的數據傳輸與接收進行了有針對性的深入研究，采取了四個方面的一系列技術方法和管理措施，較成功地對重點污染源自動監控數據傳輸與接收進行了性能優化和故障解決。

3.1 規范污染源自動監控數據上傳

針對大量無用數據上傳和數據解析效率

其中"S T=9 1"表示系統交互；"CN=9014"表示數據應答。

"C P=&&Q N=2 0 1 1 0 2 1 0 1 1 4 0 1 2 0 0 1;C N=2 0 5 1;&&"表示是對指令編號為2 0 1 1 0 2 1 0 1 1 4 0 1 2 0 0 1（QN=20110210114012001）的10分鐘數據（CN=2051）所作的確認回應。

（3）監控基站一定時間間隔內收到確認應答后，本次指令交互過程結束；如果一定時間間隔內收不到確認應答，會重復步驟（1），重發這條數據指令。

3.2.2 實現污染源監控基站的數據自動補傳機制。因通訊或程序故障，造成監控基站無法向接收程序發送數據時，監控基站要把故障期間采集的數據進行本地存儲，待故障解決后再向接收程序補傳這些數據。監控基站補傳數據時，如果收不到接收程序發送的確認信息，則要持續重發這條數據，直到收到確認信息。數據重發不能影響補傳隊列中其它數據的正常補傳，避免造成數據補傳的堵塞。

具體實現方式如下（不是唯一實現方式）：

3.2.2.1 監控基站需持續監聽與接收程序的通訊鏈接，一旦通信鏈接中斷，新采集的數據不再向接收程序上傳，而是放入本地補傳數據表。

3.2.2.2 待通訊連接正常后，監控基站向接收程序發送補傳數據表中最新一條數據，并等待接收程序的確認信息。

3.2.2.3 監控基站如果收到確認信息則從補傳數據表中刪除此條數據，開始補傳下一條數據；如果收不到接收程序發送的確認信息，則重發這條數據（有一定時間間隔），數據重發最多2次，如果重發2次后仍然收不到確認信息，此條數據不做處理，開始補傳下一條數據（兩條數據正常補傳也有一定時間間隔）。

3.2.2.4 監控基站對補傳數據表中的所有數據均進行過一遍補傳后（無論成功與否），若補傳數據表中仍然存在需補傳數據，則重復（2）、（3）步驟，直到數據補傳表中不存在需補傳的數據。

3.2.2.5 數據補傳表中只保留最近7日的數據，超過7日的數據要刪除并轉存到其它表中永久保存。

3.3 完善監控平臺數據接收程序功能

為保障接收程序的長期無故障穩定可靠運行，采取了以下完善方法。

3.3.1 優化接收程序性能。接收程序工作時，與前端每個監控基站均建立一個TCP通訊鏈路，即使1000個基站同時上傳數據，則相當于1000個接收程序同時在一對一的接收數據，保證了通訊鏈路的暢通。同時，根據接收程序使用的服務器是16核CPU的現狀，1個核開辟1個線程可達到最佳數據轉發存儲性能，因此接收程序開辟16個線程把接收到的數據存儲到數據庫中，對服務器的CPU利用最大化。

3.3.2 建立備用數據庫。接收程序使用的服務器上建立本地備用數據庫,接收程序時刻監聽與主數據庫的通訊狀況，一旦出現通訊故障，接收到的數據暫時存入本地備用數據庫中，待與主數據庫通訊恢復正常后，再將備用數據庫中的數據補傳到后臺數據庫中。

3.3.3 完善接收程序異常處理機制。通過加強代碼分析、長期壓力測試，分析接收程序的BUG,增強接收程序穩定性；數據接收異常時，利用短信告警功能告知相關工作人員；利用Watchdog守護進程軟件時刻監聽接收程序工作狀況，一旦出現崩潰、中斷等異常情況，Watchdog守護進程軟件會自動重啟數據接收程序，使數據接收程序繼續正常工作。

3.3.4 接收程序實現日志功能。記錄數據接收情況、程序運行情況、與數據庫連接狀態、與監控基站連接狀態等信息，一旦出現故障，可以據此判斷原因和詳情。

3.4 優化自動監控數據庫

數據庫是重點污染源自動監控系統軟件的核心，提高數據庫存儲和查詢的效率對于解決此次數據接收故障至關重要，為此對數據庫進行了下列優化設計。

3.4.1 重新優化設計數據庫。根據實際工作需求，對數據庫進行存儲和應用查詢優化設計，建立合適的索引；并用性能更強ORACLE 11G數據庫替代原平臺使用的SQL SERVER數據庫。

3.4.2 完善海量數據存儲技術。針對數據量龐大的問題，數據的存儲采用數據表空間分區技術，對數據按月進行物理存儲，避免單張數據表紀錄條數過多情況，單張表數據量可控制在500萬條紀錄以內，可根據索引來自如地查詢歷史數據，極大地提高查詢和存儲效率。

以上各種技術方法和措施實施后，污染源監控基站數據傳輸通暢，入庫順利，查詢快捷，出現傳輸故障可進行補傳，基本解決了數據堵塞和缺數的問題，實現了數據可靠傳輸和數據庫性能優化。

[1] 污染源在線自動監控（監測）系統數據傳輸標準，HJ/T212-2005

10.3969/j.issn.1001-8972.2012.06.045