煤矿应急救援可视化现场指挥系统的设计和实现

马尊云

（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 结 语

设计实现的应急救援现场指挥系统，将救援现场视频信息、现场环境参数和救护员体征参数一体化集成在指挥界面，并进行双向语音沟通，为救援提供了第一手救援现场信息，通过本系统，救援指挥人员实时掌握整个救援情况并进行可视化的管理和调度。该系统具有稳定、可靠和实时性强的特点，已经被神华宁煤、沈阳煤业和国投新集等多个煤矿集团救护队救援演练使用，实践表明，该系统提高了救灾工作的安全性、可靠性和灵活性，对防止二次灾害的发生提供了有效的预防途径，最大限度降低了事故造成的损失，增强了煤矿救援决策能力。