煤礦應急救援可視化現場指揮系統的設計和實現

馬尊云

（1.煤炭科學技術研究院有限公司，北京 100013；2.煤礦應急避險技術裝備工程研究中心，北京 100013；3.北京市煤礦安全工程技術研究中心，北京 100013）

自煤炭產業的誕生至今，就伴隨著瓦斯突出、礦井火災、粉塵爆炸、透水和頂板事故這5 大自然災害，近年來，這些災害事故頻發，奪去了許多人寶貴的生命，給國家財產造成了巨大的損失。這些災害的發生往往具有突發性和偶然性，發生災害的煤礦往往信息化設施破壞嚴重，井下災害現場對地面救援人員是個盲點，災害現場被困人員及環境信息也無法有效地傳遞到地面救援人員，有效的救援成了最后一個減少事故傷亡，降低損失的重要措施。目前也有些文獻對此展開研究，文獻［1］對井下應急救援交通指揮系統進行了研究；文獻［2］研究了地理信息系統在煤礦事故應急救援中的應用；文獻［3］研究了在煤礦事故發生時，對全礦井進行廣播，通知人員撤離。但這些系統應用前提是礦山應具有完備的救援體系，對于井下信息化設施破壞嚴重時，就無法有效組織井下救援及現場指揮。文獻［4－6］系統研究了無線Mesh 網絡的原理和拓撲結構，指出了在該網絡下構建煤礦應急救援指揮系統涉及的關鍵技術。但如何將救援現場的第一手信息：救援時直觀的現場音視頻、環境信息及救護隊員體征信息實時傳輸到地面,供指揮人員決策，并建立指揮人員與救護人員的有效溝通渠道，現有文獻沒給出具體的設計方案和實現。為此，在Mesh 網絡環境下，基于視頻及音頻技術，構建基于音視頻的應急救援現場指揮系統，并將救援現場環境參數、救護隊員體征參數融合在一體化指揮界面，地面指揮人員通過本系統如親臨井下災害現場，實時把握現場形勢和制定救援應對措施，對井下救援人員下達各種救援指令，進行可視化的救援指揮調度。

1 系統總體結構

系統總體上分井下系統和地面系統構成，井下系統主要由硬件部分構成，實現音視頻數據采集上傳，體征數據和環境數據采集上傳。地面系統主要是地面服務器和地面指揮客戶端2 部分。服務器部分建立5 個服務，分別是DHCP 動態地址服務、音視頻數據中轉服務、語音服務、業務服務和體征及環境數據采集服務。系統總體結構如圖1。

如圖1，井下救援數據采集由救護人員攜帶的數據采集儀完成，數據采集儀數據通過臨時搭建的無線Mesh 網絡與地面交互。DHCP 服務用于為參與救援的救護人員攜帶的數據采集儀動態分配IP 地址，事先指定一個地址段及子網掩碼，數據采集儀進入無線Mesh 網絡時，在指定地址段內為采集儀分配IP 地址，通過該地址與地面服務器建立TCP 或UDP 通信連接；音視頻服務用于為PC 指揮客戶端中轉采集儀采集的實時視頻和音頻，語音服務用于救護員、指揮人員之間的語音對講及調度。業務服務用于PC 客戶端的登錄、指揮人員和救護人員之間的指令下達及救護員報警及SOS 求救等信息的處理。數據服務用于接收救護員體征數據和救援現場環境數據，對數據進行解析存儲等處理。PC 指揮客戶端實現可視化指揮的系統核心功能，其接收服務器中轉數據，實現井下采集的視頻數據及體征環境數據在客戶端的可視化呈現和展示，指揮人員和井下救護人員間的語音交互，通過客戶端做出救援決策及下達救援指令。

圖1 系統總體結構Fig.1 Overall structure of the system

2 救援現場數據采集

無線Mesh 網絡具有快速部署和易于安裝、非視距傳輸、自愈能力強、組網靈活和擴展性強等特點[4-6]，這些特點使得無線Mesh 網絡非常適于在煤礦災難發生后，井下基礎設施破壞嚴重的情況下，由救護隊員臨時搭建應急通信網絡，作為救援信息傳輸通道。地面指揮人員通過該網絡實時了解井下現場環境及態勢，造成的人員傷亡情況及設施破壞情況，下達救援指令等信息。

要對煤礦井下災難現場組織有效的救援行動，最有效的方式就是獲得現場實時視頻，與救護人員直接進行語音對講溝通，了解現場環境參數信息以及救護隊員自身的體征信息。災變現場環境參數主要是溫度、甲烷體積分數、一氧化碳體積分數、氧氣體積分數，環境參數幫助指揮人員了解災變現場環境，為制定應對措施提供參考；救護隊員的體征信息包括體溫、心率、姿態、呼吸頻率及活動度，這些信息幫助地面指揮人員了解救護人員身體狀況，是否適于繼續救援行動。

利用KJ30-C（A）礦用本安型數據采集儀來實現現場音視頻數據以及救護隊員體征數據的采集，該采集儀輕便小巧，由救護隊員隨身攜帶。采集儀有線連接KBA5X（A） 礦用本安型頭盔攝像儀及XHG3 礦用本安型骨傳導聽說器，通過藍牙連接GSMD3 礦用生命體征傳感器。CD3 多參數環境參數測定器有線連接KJ30-WJ（A）無線接收器，通過無線Mesh 網絡，采集的環境數據實時傳輸到地面服務器。

數據采集儀內嵌Android 系統[7]，采集APP 實現救護隊員音視頻數據和體征數據的實時采集。視頻數據采集時按照CIF（通用影像傳輸格式）進行采集，并進行H264 編碼，音頻數據通過Speex 進行編碼。再將編碼后的音視頻數據通過無線Mesh 網絡傳輸到地面服務器。

3 音視頻實時傳輸

利用RTP（Real-time Transport Protocol）實時傳輸協議[8]來實現音視頻數據的實時傳輸，具體是采用基于C++、面向對象的RTP 開源封裝庫jrtplib，該庫支持定義于RFC3550 中的RTP 協議。 其不僅實現了RTP，而且實現了配套的相關實時傳輸控制協議RTCP（Real-time Transport Control Protocol），它使得發送和接收RTP 報文變得異常簡單，用戶不用擔心SSRC 沖突，也不用考慮如何傳輸RTCP 數據，因為RTCP 功能完全在內部實現，不需用戶手動操作。當發送RTP 報文時，用戶只需簡單的給發送函數提供負載數據；當接收數據時，jrtplib 提供了訪問傳入的RTP 和RTCP 數據的接口。由于該庫的使用，本文專注于系統業務功能的實現。音頻和視頻數據通過RTP 報文頭結構中的載荷類型PT 進行區分，統一進行RTP 報文的收發處理。由于在特殊的救援環境下，公網、衛星網絡、局域網和臨時搭建的無線網絡可能并存，源地址和目的地址不固定，客戶端與客戶端之間，采集儀與指揮客戶端之間不進行直接通信，而是通過服務器端中轉，服務器端中轉時根據客戶端用戶編號和采集儀設備編號進行RTP 報文分發。RTP 協議報文的頭結構中提供了個擴展數據區，擴展區數據結構可以由用戶根據需要自行設計，因此，將如下業務數據結構的數據作為RTP 報文頭結構的擴展數據和實時音視頻RTP 報文一起傳輸：

DataType 是業務數據類型，比如通信過程中，數據包是請求包還是響應包等；UserID 為用戶編號，即是客戶端登錄用戶編號，用于表示語音通話時，語音數據包的來源或目的地；DeviceID 為設備編號，數據采集儀上傳的音視頻數據包中，通過該編號識別該采集儀對應的救護隊員，以便客戶端系統界面視頻播放網格進行相應的播放顯示處理，比如對應設備的視頻播放或語音處理。

音視頻數據實時傳輸流程如圖2。

圖2 音視頻數據實時傳輸流程Fig.2 Real time audio and video data transmission process

圖2 中，音頻數據的接收處理流程和視頻流程類似，從RTP 接收的緩存列表中取出RTP 報文載荷數據，加入設備或用戶對應的緩存列表，供指揮客戶端播放處理。

4 集群語音對講

通過實現SIP 協議[9-11]，來對集群內語音通話進行管理和調度。SIP（Session Initiation Protocol）是1個應用層的信令控制協議，用于創建、修改和釋放1個或多個參與者的會話。

指揮人員和救護隊員之間通過語音溝通，缺省情況下，語音信息在系統網內進行廣播。系統提供分組功能，即將選定的指揮人員或救護隊員組成1 個組，即構成1 個集群，集群內成員的語音信息僅本集群內的成員可以聽到，即語音集群廣播，該功能對于執行不同救援任務時，各任務組分別進行語音溝通，互不干擾。

集群分普通群和SOS 群，普通群由指揮人員或救護隊員創建，SOS 群由救護隊員發起創建，救護隊員攜帶的采集儀，有通話和求救按鈕。連續按住通話按鈕時，即發起通話請求，指揮客戶端自動建立該救護員的語音群并鎖定該救護員，指揮人員也可以將其他人員加入該群，進行群內相互通話，救護員松開通話按鈕，其通話結束。當收到求救消息時，客戶端建立SOS 群，SOS 群權限最高，該群建立通話時，客戶端禁止其它群的通話，鎖定SOS 群內的通話。SOS 結束后，由指揮人員解除對該群的鎖定。

在語音通話權限上，指揮客戶端高于救護隊員，救護員鎖定通話時，客戶端可以強行解鎖該通話，由指揮人員接過話語權。

5 指揮客戶端音視頻播放

5.1 語音收發處理

音頻數據采用開源的語音引擎Speex 進行編碼和解碼，Speex 具有壓縮后的比特率低（2～44 kbps）的特點，并支持多種比特率，這個特點使其適于在低帶寬網絡上進行傳輸，再結合VAD（（Voice Activity Detection）靜音檢測，減少了無效音頻數據在網絡上的傳輸，節省了寶貴的帶寬資源。

系統采用DirectSound 技術實現語音的捕獲和播放。DirectSound 是微軟DirectXAudio 的一個較底層的部件，通過實現IDirectSoundCapture8 接口，實現本地聲音的捕獲，通過實現IDirectSound8 接口，將接收的音頻數據加入該接口對象播放緩沖區，播放模式采用混音模式，接收到的音頻數據實時混音播放，語音播放流程如圖3。

圖3 語音播放流程Fig.3 Voice playing process

如果當前有語音對講，則對采集的音頻信號做AGC 自動增益控制處理和VAD 靜音檢測，再進行Speex 編碼，打包為RTP 報文，交由RTP 庫的發送函數進行發送。

5.2 視頻播放處理

常用的視頻圖像有MPEG-2、MPEG-4 和H264標準的圖像壓縮格式，在相同分辨率的情況下，H264 要求的傳輸帶寬最小，因此采用H264 協議對采集的視頻進行編解碼，具體是采用開源的FFMPEG[12-14]中H264 編解碼庫。FFMPEG 是一套可以用來記錄、轉換數字音頻、視頻，并能將其轉換為流的開源計算機程序，采用LGPL 或GPL 許可證。它提供了錄制、轉換以及流化音視頻的完整解決方案。它包含了非常先進的音頻/視頻編解碼庫。井下救護隊員攜帶的數據采集儀中基于Android 系統的視頻采集APP 對采集的視頻進行H264 編碼，指揮客戶端利用其中H264 解碼庫對采集的視頻數據進行解碼。視頻播放流程如圖4。

圖4 視頻播放流程Fig.4 Video playing process

體征數據OSD 疊加[15-16]顯示時，通過字體顏色區分正常數據和報警數據，綠色為正常，紅色為報警。體征報警規則如下：①心率大于140 次/min 或小于40 次/min，報警；②呼吸頻率大于40 次/min 或小于12 次/min，報警；③體溫大于60 ℃或小于10℃，報警；④姿態角度大于150°或小于360°，報警；⑤活動度大于3.3 VMU/s，報警。

救護隊員視頻圖像和體征數據疊加顯示在界面視頻播放網格，可視化集中顯示在一個界面，構成一體化指揮界面。對于救護員視頻圖像網格化顯示播放，系統界面視頻網格劃分提供了9 種劃分模式，網格之間的視頻可以相互拖動，比如周邊小網格，中間大網格，指揮人員可以將小網格視頻圖像拖動到大網格顯示，同時大網格視頻顯示到小網格，即拖動時，網格視頻對換網格播放。當救護員SOS 求救時，對應該救護員的視頻自動單屏模式播放。如果救護隊員在線人數較多，界面提供視頻網格翻屏功能，讓井下救護員視頻人為控制在1 個界面上輪流顯示。該一體化界面提供了環境監控、錄像、抓圖和右鍵語音菜單等功能，讓指揮人員在1 個界面上完成救援的指揮調度。

6 現場應用

系統通過KJ30-Z（A）礦用本安型無線中繼器實現的無線Mesh 網絡下的一種現場應用場景如圖5。

圖5 系統現場應用場景Fig.5 System field application scenarios

井下無線Mesh 網絡提供10 M 左右的帶寬傳輸能力，如加大中繼器的功率和天線增益，帶寬也會相應增加，最多可以達到100 M。井下無線Mesh 網絡通過前端接入采集儀采集的現場數據，經由中繼傳遞到中心端節點，再通過光纖傳輸到地面服務器。煤礦災難發生時，救護隊員下井時，攜帶無線網絡中繼器布設在井下救援巷道，臨時搭建救援用的無線Mesh 通信網絡，救援現場音頻、視頻等數據通過該網絡中心端節點傳輸到地面服務器，前方現場指揮客戶端和后方指揮中心客戶端通過專網、衛星等網絡連接到服務器，可以實現對救援現場的聯合指揮。

救護員視頻采樣幀率和圖像分辨率可以根據實際網絡傳輸能力進行設置，在幀率為25 幅/s，采樣格式為CIF 格式的情況下，視頻通過H264 編碼后，碼率在300 kbps 左右，音頻通過Speex 編碼后，碼率小于44 kbps，以44 kbps 計算，在不考慮其它信息傳輸的情況下，10 M 帶寬可以同時傳輸30 路左右的救護員音視頻數據。即圖5 指揮界面上可以最多達到30 個救護員同時在線。

指揮客戶端由于需要對每一路音視頻實時解碼和視頻圖像實時渲染，在指揮客戶端電腦CPU 主頻1.7～2.4 GHz 及8 G 內存的配置下，經實際應用測試，指揮界面最多能同時顯示8 路視頻，如果救護員多于8 個在線時，則使用指揮界面的翻屏功能輪流顯示救護員視頻，以使系統指揮界面音視頻流暢播放。

7 結 語

設計實現的應急救援現場指揮系統，將救援現場視頻信息、現場環境參數和救護員體征參數一體化集成在指揮界面，并進行雙向語音溝通，為救援提供了第一手救援現場信息，通過本系統，救援指揮人員實時掌握整個救援情況并進行可視化的管理和調度。該系統具有穩定、可靠和實時性強的特點，已經被神華寧煤、沈陽煤業和國投新集等多個煤礦集團救護隊救援演練使用，實踐表明，該系統提高了救災工作的安全性、可靠性和靈活性，對防止二次災害的發生提供了有效的預防途徑，最大限度降低了事故造成的損失，增強了煤礦救援決策能力。