區域交通基礎設施群監測系統設計及應用關鍵技術研究

王代君，傅俊敏，周天圖，陳 星

(江西省交通科學研究院，江西 南昌 330052)

0 引言

近年來，國內交通基礎設施數量日益增加、密度不斷加大，分布范圍更加廣泛、病害層出不窮，橋梁坍塌、邊坡坍塌、路基下沉、隧道塌方等突發事件時有發生。如何統籌兼顧地確保數量龐大且地理分散的交通基礎設施安全、高效地運營，發揮最大的服務能力，成為當前我國交通基礎設施管養中面臨的一個重大課題[1-3]。

交通基礎設施數量巨大、地理分散、種類眾多、生命周期跨度不同，這些特征都決定了交通基礎設施的運營期管養具有很大的難度。采用物聯網技術的基本思路，通過在橋梁、公路、邊坡、隧道等關鍵的交通基礎設施上安裝各類傳感器對其進行監測，及時掌握其結構安全狀態，可以為管養計劃的制訂提供重要依據[4-6]。同時，采用信息化手段將城市范圍內的交通基礎設施納入統一的平臺，形成邏輯意義上的橋梁群、公路群、邊坡群、隧道群，進行集群化的監測和管養，可以克服地理分散性給管養工作帶來的不便[7-9]。

本研究旨在開發一套突破地理空間局限的區域交通基礎設施群監測系統，通過信息化手段和集群式監測技術的應用，將市、縣等區域內的普通公路和高速公路上的關鍵基礎設施納入統一的監測平臺中，包括橋梁、公路、邊坡、隧道等，實現集中管理，提供及時、可靠的安全預警和高質、高效的監測服務，保證交通基礎設施長期穩定運營。

1 交通基礎設施結構健康監測現狀

隨著我國交通事業的飛速發展，橋梁、邊坡、隧道、道路等交通基礎設施數量日益增多， 在公路運輸系統中發揮著重要作用，其運營期的安全對于保障交通運輸通暢、促進社會經濟發展具有重要意義。同時，數量龐大而分散的交通基礎設施管養難度變得越來越大，傳統的分散管理方式很難對交通基礎設施的運營狀態進行精確而及時的檢測和評估，從而使各類交通基礎設施的管養效率很難繼續提高。

我國的交通基礎設施監測起步較晚但發展迅速，許多研究院所、高校和企業對結構安全監測技術進行了理論研究，部分成果已應用在大壩、橋梁和隧道等設施上，取得了一定的成果[10-14]。東南大學、哈爾濱工業大學、重慶交通大學等高校成立了專門研究橋梁健康監測的團隊。目前，國內的絕大多數大型橋梁均配備了結構安全監測系統，例如著名的杭州灣跨海大橋[15]、港珠澳大橋，九江長江大橋[16]等等。除此之外，智能監測系統也成為許多邊坡、隧道運營管理的標配[17-18]。

盡管目前國內已有許多橋梁健康監測系統、邊坡隧道監測系統、路面沉降監測系統、道路管養系統的實際應用，但這些系統大多針對某個獨立的結構實體進行監測，并且每個實體的監測系統的承包單位都不同，系統架構不一致，數據也難以共享，而這些系統之間的功能基本上都是類似的，存在明顯的重復建設問題。實際上，橋梁、公路、邊坡、隧道等關鍵的交通基礎設施在監測技術方面均有很多共性，因而可以納入統一的平臺實現集群化管理。

隨著信息技術和物聯網技術的發展，北斗高精度定位、4G/5G等高新技術在交通基礎設施監測中的應用日益廣泛[19-20]，國產北斗系統逐步替代美國GPS，我國5G技術也達到了國際領先水平，大量關鍵的智能型傳感器也實現了國產化，為我國“平安交通”建設提供了良好的技術條件。

2 系統需求分析

2.1 城市級的統一監測

大區域范圍的交通基礎設施在監測和管養的具體要求上具有較大的不同，且分屬不同的部門進行管理，因此需要在滿足實際管理的組織原則的基礎上，通過信息化平臺的應用實現城市級的交通基礎設施群統一監測，從市級層面實現對交通基礎設施群的統一監測和管養。

2.2 多種類的監測對象

關鍵的交通基礎設施主要是指對其結構安全有嚴格要求的硬件設施，例如橋梁、邊坡、隧道、地質不穩定路段的路面路基等。這些基礎設施通常沿著道路分布，或直接作為道路的一部分而存在，在行政管轄上比較統一，因而在管理層面上具備集成化監測和管養的基本條件。因此要求集成化監測平臺具有規范的數據接口，使不同種類的監測對象所產生的監測數據可以統一接入平臺，避免重復建設，節約管理成本，提高管理效率。

2.3 豐富的業務功能

監測平臺的應用后，可根據實際需求構建出一系列實用的業務功能，通過信息化系統輔助管理的方式代替大量繁瑣的人工勞動。本系統需提供包括數據采集、數據展示、自動巡檢、預警分析、數據統計、報表生成、報告下載、在線運維等豐富的業務功能，以滿足區域交通基礎設施群的集中管養需求。

2.4 自動化的系統運維

隨著交通信息化系統數量日益增加，平臺規模進一步擴大，人工維護成本不斷提高，運維人員必須每天通過遠程桌面的形式逐個系統進行人工檢查，浪費大量時間和精力。為此，應根據系統維護需要，自主開發一套系統運維平臺，實現各系統狀態信息的自動上報，實現自動化運維。

3 系統總體架構設計

3.1 平臺架構分析

根據區域交通基礎設施群監測的業務特征，結合信息化系統建設的一般要求，嚴格遵守《公路橋梁結構安全監測系統技術規程》(JT/T 1037—2016)，本研究設計了如圖1所示的區域交通基礎設施群監測系統架構。

圖1 系統總體架構Fig.1 Overall architecture of system

本系統架構由下至上分別為感知層、近場傳輸層、采集控制層、遠場傳輸層、業務邏輯層和應用層。感知層由安裝在現場基礎設施群的各類傳感器構成，負責感知交通基礎設施的各個物理量，是整個系統的數據源。近場傳輸層負責將感知層產生的數據傳輸到采集站，包括RS-485總線、RS-232總線、GPRS無線傳輸、RJ45接口通信等方式，但最終均統一轉換為網絡信號進入采集站的交換機。采集控制層由分布式部署的工控機構成，在其上運行采集軟件，對各橋梁邊坡的數據進行集成和預處理。預處理后的傳感器數據通過運營商提供的專網鏈路傳輸至遠程監控中心，遠程監控中心機房內的應用服務器、數據處理服務器和數據存儲服務器中分別部署了WEB服務、大數據分析服務和數據庫存儲服務，這些服務正是在業務邏輯層實現的。用戶在應用層通過各類客戶端設備對系統進行訪問。

(1)數據傳輸設計

當前絕大多數傳感器都以串口輸出方式為主，考慮到傳感器與采集站之間的距離一般不遠，因此采用近場傳輸技術即可，通過串口服務器設備將串口轉換為以太網接口，從而可通過交換機對各采集站的所有傳感器數據進行統一集成。在采集站與遠程數據中心機房之間，由于距離較遠，因此采用光纖傳輸技術，通過運營商提供的專網鏈路完成采集站到遠程數據中心機房的數據傳輸。數據上傳采用自定義通信協議，以TCP方式上傳，由于各路數據上傳的數據包包含了基礎設施ID、傳感器ID、物理量ID等標識字段，因此數據服務端程序可以進行有效的識別。

(2)交互模式設計

用戶界面與后臺的交互采用瀏覽器/服務器(Browser/Server)模式，用戶只需要1個瀏覽器即可隨時訪問系統平臺。而采集站和服務器之間的數據傳輸則采用客戶端/服務器(Client/Server)模式，這要求在每個采集站中安裝客戶端軟件，在服務器中安裝服務端軟件，由于客戶端和服務端都是對用戶不可見的，因此不會給用戶帶來使用的不便。

(3)高效訪存設計

為滿足海量數據的高效存儲和訪問，架構中集成了Redis緩存組件，將計算參數、基礎信息、當天的實時數據等常用的數據放到Redis緩存組件中，避免頻繁訪問數據庫造成過度的資源消耗。對于未放入Redis緩存組件的數據訪問，綜合運用數據索引、事務操作、多線程等技術，提升系統訪存綜合性能。

(4)擴展功能設計

對于區域交通基礎設施群監測系統而言，監測點眾多，數據量大，系統結構復雜，為實現高效運維，系統單獨部署了1臺運維服務器用于部署自動化運維平臺，提升運維效率。為提升系統的可靠性，在架構中設計了1臺災備服務器，用于定時備份重要數據，同時在云端備份關鍵數據。為滿足系統平臺與第三方系統的交互，最大程度利用監測數據，平臺設計了對外數據接口，可以向指定的公網設備推送數據。

3.2 平臺功能分析

以《公路橋梁結構安全監測系統技術規程》(JT/T 1037—2016)為依據，結合平臺架構的特點，本系統可實現以下功能：

(1)數據采集?？蓪崿F實時采集、自動存儲、緩存管理、即時反饋和自動傳輸等功能。可與數據庫系統和服務端穩定可靠地通信，運行參數均實現配置化管理，可本地或遠程調整各項配置參數?？梢詫崟r監測傳感器和軟件運行狀態，異常時可及時報警。

(2)數據傳輸。數據傳輸綜合運用了近場通信技術、遠場通信技術、有線傳輸、無線傳輸方式，數據傳輸具有一致性、完整性、可靠性和安全性，滿足系統開放性和可擴展性要求。各類數據均通過自定義通信協議以包為單位進行傳輸，基于TCP/IP 協議進行數據交換和傳輸。

(3)數據處理。可以實現數據預處理和數據后處理功能，預處理采用數字濾波、去噪、截取和異常點處理等，數據后處理方式根據數據分析要求確定?？梢詽M足平穩信號和非平穩信號處理。具備數據備份、清除和故障恢復等功能。

(4)評估分析。根據實時監測數據，通過統計分析、算法處理、大數據計算等手段提取各監測點的狀態信息，分析數據變化趨勢，對監測點的當前和未來一段時間的狀態進行評估，一旦出現異?；蚩赡艹霈F異常，立即向管養部門發送預警信息。系統定期生動生成評估報告，經人工審批確認后生效。

系統功能菜單如圖2所示。

圖2 系統功能菜單圖Fig.2 Function menu diagram of system

3.3 平臺關鍵技術分析

本系統設計開發的關鍵點在于如何對大量的傳感器數據進行統一的采集、傳輸和存儲，以及如何對系統進行高效的運維管理。要實現以上功能，系統設計過程中必然要解決數據量估算、數據流控制、異構數據的結構化處理、大規模信息化系統的自動化運維等關鍵技術問題，下面進行詳細闡述。

3.3.1 數據量估算

數據量估算可為硬件設備選型和軟件架構設計提供重要依據，一般來說，基礎設施群的監測會包括動態數據的監測，因而數據量較大。在硬件設備的選型過程中，必須關注存儲容量和網絡帶寬等指標，根據估算的數據量采購硬件設備，并要求設計時留有一定的余量。在軟件架構設計過程中，同樣要關注數據量的大小，對于數據量大的系統，應相應采取多線程、多級緩存、分布式存儲等設計方案，保證整套系統能夠穩定可靠地運行。數據量估算公式為：

(1)

式中，M為總數據量；T為時間長度；H為數據庫中每行記錄的空間占用率；si為第i類傳感器的數量；pi為第i類傳感器的物理量個數；fi為第i類傳感器的采集頻率；i為第i類傳感器類別序號，i=1, 2, 3,…,n；α為設計預留的余量系數，一般取1.3～1.5之間，太大會浪費存儲資源，實際上，當前的信息化系統普遍采用磁盤陣列技術進行數據存儲，此時應以磁盤陣列的實際存儲容量為準，而不是各塊硬盤的容量之和。

3.3.2 數據流控制

在交通基礎設施群監測系統中，幾乎每時每刻都在產生數據，根據這些數據的作用，主要可以分為調試數據、業務數據和運維數據3種類型，其中業務數據又包括原始數據、統計數據、WEB數據和歷史數據。這些數據不僅數據量大，而且其來源、作用、傳輸方式、和數據量都各不相同，因此軟件內部的數據流控制具有一定的難度，因而成為系統設計和開發的難點之一[21]。本研究設計的數據流控制方案如圖3所示。

圖3 數據流控制示意圖Fig.3 Schematic diagram of data flow control

由于區域交通基礎設施群在地理上是分散的，因此采集工控機相應采用分布式采集方案，通過工控機在各監測點進行近場采集。而服務器則均安裝在遠程中心機房，通過專網接收各工控機上傳的運維數據和業務數據。

各類數據存儲方式見表1，具體說明如下：

表1 數據存儲方案設計表Tab.1 Scheme design table of data storage

(1)業務數據流

原始數據是指采集客戶端軟件從傳感器數據接口直接采集到的數據，主要用于問題追溯。例如，當對數據處理結果有疑問時，可以調取原始數據進行分析并確認問題。原始量很大，且不經任何處理直接保存在工控機硬盤中。與大型數據庫相比，SQLite屬于輕量級的文件型數據庫，支持SQL語句查詢功能，所以本系統在工控機中通過SQLite數據庫來存儲原始數據。

WEB監測數據是用戶通過瀏覽器登錄平臺后可查看到的數據，其主要目的是監測傳感器數據的有無和數據變化趨勢，因此不需要顯示所有原始數據。對于采集頻率在1 Hz以上的數據按1 Hz重采樣作為WEB監測數據。

在采集客戶端中將原始數據按每10 min、每小時和每天3個尺度進行統計，得到各尺度的最大值、最小值、平均值、眾值、均方差等參數，并將這些參數發送至數據服務中心。這樣就將大量數據轉化為少數幾個特征參數，從而大大減少存儲空間的占用。

(2)調試數據流

調試數據的作用是便于現場安裝人員在施工階段調試和校準傳感器，因此需要將傳感器數據以表格、圖形或曲線的形式動態、直觀地顯示出來。這些調試數據的保存價值不高，因此不需要保存到硬盤里的，只需暫存在內存中。對于采集頻率在1 Hz以上的傳感器，對其原始數據進行1 Hz的重采樣再顯示出來，滿足系統調試要求即可。

(3)運維數據流

運維數據由傳感器、工控機和服務器產生，包括主機硬件性能指標、傳感器狀態、軟件運行狀態等信息，主要用于運維人員監視系統平臺的運行情況，及時發現并解決故障問題。運維數據不參與監測平臺的WEB展示，因此運維功能單獨部署在運維服務器中，并由單獨的MySQL數據庫進行運維數據的存儲。

3.3.3 結構化存儲

從數據處理的角度看，區域交通基礎設施群監測系統的數據采集與存儲實際上是一個多源異構數據的集成問題。由于不同類型的傳感器所產生的數據在結構上是不同的，在傳統的數據存儲方案中，通常需要為每類傳感器都根據其物理量設計獨特的數據表。其實這種設計只是一種分類存儲方式，還不是真正意義上的結構化存儲。本研究提出一種新的結構化存儲方案，使不同類型的傳感器數據都可以存儲在同一個數據表中，保持數據結構的一致性，進一步提高數據的集成度，如表2所示。

表2 傳感器數據結構Tab.2 Sensor data structure

在表2中同時存儲了溫濕度計和風速儀2類傳感器的實時數據，雖然這2類傳感器所采集的物理量完全不同，但是通過物理量ID字段的設計，使這些物理量與表3和表4的信息建立了關聯關系，從而可在保持數據結構一致的情況下同時將多類傳感器的數據存儲在1張數據表中，實現了多源異構數據的結構化和集成化存儲。

表3 物理量定義Tab.3 Physical quantity definitions

表4 傳感器類型定義Tab.4 Sensor type definitions

3.3.4 自動化運維

自動化運維系統架構如圖4所示，由以下10大模塊組成：運維客戶端(Agent)、采集客戶端(Client)、運維服務端(SOCSever)、內網數據庫(Local DB)、遠程數據庫(Remote DB)、WEB/APP服務端、運維APP、運維WEB平臺、業務平臺、短信平臺。其中Agent、Client和SOCSever屬于后臺采集部分，手機APP和WEB屬于前臺展示部分。

圖4 自動化運維系統原理示意圖Fig.4 Schematic diagram of automatic operation and maintenance system

Agent和Client是工作在最底層的數據采集模塊，通過TCP協議將各類狀態參數傳輸給SOCSever進行匯總和分析。目標系統在內網服務器上部署1個MySQL數據庫用于存儲運維基礎信息和實時數據，當系統具有對外公網IP時，在遠程監控中心設置MySQL數據庫，2個數據庫的表結構完全相同，內網數據庫定期與外網數據庫進行數據同步。用戶可通過瀏覽器或手機APP與系統進行交互，瀏覽器或手機APP經過后臺的服務程序訪問數據庫。自動化運維系統與業務系統相互獨立，互不影響，但業務系統可通過直接訪問運維數據庫獲得部分狀態參數。

在自動化運維系統的幫助下，系統運維人員可完成遠程性能監測及程序升級、數據匯總與指令控制、可移動終端實時訪問控制、WEB實時訪問控制、信息實時推送等功能，可極大地提升運維效率。

4 系統的應用

4.1 工程概況

婺源縣位于江西省東北部，面積2 967 km2，地形地貌素有“八分半山一分田，半分水路和莊園”之稱，是我國著名的旅游休閑度假勝地。本項目涉及G237，G351，S302，S303國、省道，共計95.3 km，均位于婺源縣核心景區中心地帶。近年來，該區域自然災害頻發，例如邊坡塌陷、路面沉降、橋梁結構異常等，如何解決公路的災害防治及預警、改善大眾道路出行體驗、提高游客出行滿意度，成為影響本地公路建設和經濟發展的重大課題。本項目利用智能化、信息化技術手段打造“暢安舒美”的災害防治示范路，對縣域內的8座中小型橋梁和8處自然邊坡進行監測，是一個典型的區域交通基礎設施群監測系統。

4.2 監測對象

婺源景區的旅游線路旁多為自然土質邊坡，遇水易軟化，在降雨作用下易發生滑移破壞。為了防止災害的發生，需要對典型的高邊坡進行不間斷、實時的穩定性監測。在婺源景區的4條旅游線路上，橋梁以配筋混凝土橋梁為主體，橋齡低于20 a的中小跨徑橋梁占大多數，婺源縣旅游業的發展，行車密度及車輛荷載的增大，導致橋梁的負擔日趨嚴重，安全度日益下降。同時，由于超載現象，加之雨水及化冰鹽等自然及人為條件的不斷侵蝕作用，導致橋梁的部分構件混凝土剝落、鋼筋銹蝕的現象十分嚴重，嚴重危及橋梁的正常使用，運營狀況堪憂。經現場踏勘，有8座橋梁需進行結構健康監測，7處邊坡需要進行穩定性監測，具體信息如表5所示。

表5 監測對象信息Tab.5 Information of monitoring objects

4.3 傳感器類型及數量

根據各橋梁、邊坡的結構特征和運營現狀，分別在結構體上安裝各種傳感器，對結構物的應變、傾斜、位移、氣象環境、振動等物理量進行實時監測。各結構物安裝的傳感器類型及數量如表6所示。

表6 傳感器數量及種類Tab.6 Quantity and types of sensors

4.4 數據量計算及設備選型

對數據量進行合理估算是設備選型的重要依據。根據公式不難發現，整個工程的數據量與傳感器的數量、采集頻率、物理量個數、保存的時間長短等因素有關。根據各類傳感器性能以及業主的實際管養需求，各類傳感器的采集頻率和數據量如表7所示。

表7 采集頻率Tab.7 Acquired frequencies

對每類傳感器的數據量進行求和，可得本工程每天可產生數據1.34×108個，即1.34億個。除了數據存儲所需硬盤空間之外，考慮到還有其他固定資源開銷，在這里余量系數α取1.5，監測數據要求存儲1 a，那么：

(1)對于工控機中的原始數據存儲而言，采用的是SQLite存儲，經過前期測試，每插入1行記錄約增長50字節，則1 a共需占用2.19 GB硬盤空間，考慮余量系數時需要配備3.3 TB硬盤空間。注意此處計算的是工控機所需總容量，分配到各工控機的具體容量稍有區別。

(2)對于數據庫服務器中的數據存儲而言，由于采用Oracle存儲，經過前期測試，每插入1行記錄約增長246字節，則1 a共需占用11 TB硬盤空間。考慮余量系數時需要配備16.5 TB硬盤空間。

根據以上估算結果，主要設備選型清單如表8所示。

表8 設備及技術參數Tab.8 Equipment and technical parameters

4.5 系統的實現

根據本研究設計的系統架構，開發完成了區域交通基礎設施群監測系統(婺源公路綜合平臺)。系統首頁通過卡片顯示了不同橋梁、邊坡、隧道等基礎設施監測子系統的入口，卡片上的背景顏色和右上角的“優良中差危”代表該基礎設施的健康狀態評價等級。點擊相應的卡片可進入相應的子系統界面。在各監測子系統中，主要包括狀態監測、結構物信息、實時數據、數據對比、數據統計、設備信息、參數配置、系統管理等菜單，為用戶提供了豐富的業務功能。狀態監測頁面，可以實時顯示各傳感器的工作狀態，如有預警，可及時顯示預警的傳感器類型、物理量、編號、預警級別、預警值、觸發時間等信息。

圖5為本平臺配套開發的自動化運維平臺，通過一個集成界面，可以一覽所有工控機和服務器的工作狀態，如CPU、內存、硬盤空間等占用率過高，或進程占用資源過多，會及時顯示紅色并閃爍，提醒運維人員及時處理。運維平臺還具有故障記錄、報表生成、遠程更新等一系列功能，給運維工作帶來了極大的便利。

圖5 自動化運維服務端界面Fig.5 Interface of automatic operation and maintenance server

4.6 應用效果

在當前的路網運行監測管理模式下，管理主體為縣(市)公路分局。其中，縣公路分局、道班等基層管養部門履行路況巡查、交通量監測等日常路網運行信息的收集、處理、報送職責。

信息化系統應用后，用戶通過自己的賬號登錄系統平臺即可查看相應權限范圍內的監測數據，系統預警模塊會實時列出異常傳感器的信息，用戶可調取任意傳感器的實時數據和歷史數據，也可調取攝像頭查看現場的畫面，如需現場處置可指派相關人員前往，而不再需要頻繁到現場巡查，不僅節省了人力物力，也提高了數據的準確性。在縣級路網管理中心，值班人員通過運維系統還可方便地監測整個系統軟、硬件運行情況，及時發現離線設備和性能瓶頸，提高系統維護的自動化水平。具體對比效果如表9所示。

表9 系統應用效果對比Tab.9 Comparison of system application effects

5 結論

交通基礎設施數量巨大、地理分散、種類眾多、生命周期跨度不同。本研究采用了信息化手段將區域內的所有重要的橋梁、公路、邊坡、隧道等交通基礎設施進行集群化監測，為管養單位的決策提供重要依據。根據本研究提出的系統架構設計了婺源公路綜合平臺，實現了對8橋、8坡的實時監測，且婺源縣域內的其他基礎設施還在持續接入中。結果表明，系統的實時采集、自動存儲、緩存管理、即時反饋和自動傳輸等功能穩定可靠運行，日常巡檢工作量顯著減少，監測數據更加全面準確，系統運維效率大大提高，該系統在區域交通基礎設施群監測中發揮了重要作用。