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

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

0 引言

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

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

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

1 交通基礎設施結構健康監(jiān)測現(xiàn)狀

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

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

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

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

2 系統(tǒng)需求分析

2.1 城市級的統(tǒng)一監(jiān)測

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

2.2 多種類的監(jiān)測對象

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

2.3 豐富的業(yè)務功能

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

2.4 自動化的系統(tǒng)運維

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

3 系統(tǒng)總體架構設計

3.1 平臺架構分析

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

圖1 系統(tǒng)總體架構Fig.1 Overall architecture of system

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

(1)數(shù)據(jù)傳輸設計

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

(2)交互模式設計

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

(3)高效訪存設計

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

(4)擴展功能設計

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

3.2 平臺功能分析

以《公路橋梁結構安全監(jiān)測系統(tǒng)技術規(guī)程》(JT/T 1037—2016)為依據(jù)，結合平臺架構的特點，本系統(tǒng)可實現(xiàn)以下功能：

(1)數(shù)據(jù)采集?？蓪崿F(xiàn)實時采集、自動存儲、緩存管理、即時反饋和自動傳輸?shù)裙δ堋？膳c數(shù)據(jù)庫系統(tǒng)和服務端穩(wěn)定可靠地通信，運行參數(shù)均實現(xiàn)配置化管理，可本地或遠程調(diào)整各項配置參數(shù)?？梢詫崟r監(jiān)測傳感器和軟件運行狀態(tài)，異常時可及時報警。

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

(3)數(shù)據(jù)處理?？梢詫崿F(xiàn)數(shù)據(jù)預處理和數(shù)據(jù)后處理功能，預處理采用數(shù)字濾波、去噪、截取和異常點處理等，數(shù)據(jù)后處理方式根據(jù)數(shù)據(jù)分析要求確定?？梢詽M足平穩(wěn)信號和非平穩(wěn)信號處理。具備數(shù)據(jù)備份、清除和故障恢復等功能。

(4)評估分析。根據(jù)實時監(jiān)測數(shù)據(jù)，通過統(tǒng)計分析、算法處理、大數(shù)據(jù)計算等手段提取各監(jiān)測點的狀態(tài)信息，分析數(shù)據(jù)變化趨勢，對監(jiān)測點的當前和未來一段時間的狀態(tài)進行評估，一旦出現(xiàn)異常或可能出現(xiàn)異常，立即向管養(yǎng)部門發(fā)送預警信息。系統(tǒng)定期生動生成評估報告，經(jīng)人工審批確認后生效。

系統(tǒng)功能菜單如圖2所示。

圖2 系統(tǒng)功能菜單圖Fig.2 Function menu diagram of system

3.3 平臺關鍵技術分析

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

3.3.1 數(shù)據(jù)量估算

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

(1)

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

3.3.2 數(shù)據(jù)流控制

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

圖3 數(shù)據(jù)流控制示意圖Fig.3 Schematic diagram of data flow control

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

各類數(shù)據(jù)存儲方式見表1，具體說明如下：

表1 數(shù)據(jù)存儲方案設計表Tab.1 Scheme design table of data storage

(1)業(yè)務數(shù)據(jù)流

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

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

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

(2)調(diào)試數(shù)據(jù)流

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

(3)運維數(shù)據(jù)流

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

3.3.3 結構化存儲

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

表2 傳感器數(shù)據(jù)結構Tab.2 Sensor data structure

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

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

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

3.3.4 自動化運維

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

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

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

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

4 系統(tǒng)的應用

4.1 工程概況

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

4.2 監(jiān)測對象

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

表5 監(jiān)測對象信息Tab.5 Information of monitoring objects

4.3 傳感器類型及數(shù)量

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

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

4.4 數(shù)據(jù)量計算及設備選型

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

表7 采集頻率Tab.7 Acquired frequencies

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

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

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

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

表8 設備及技術參數(shù)Tab.8 Equipment and technical parameters

4.5 系統(tǒng)的實現(xiàn)

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

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

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

4.6 應用效果

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

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

表9 系統(tǒng)應用效果對比Tab.9 Comparison of system application effects

5 結論

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