煤矿综合安全管控平台建设：从数据接入到智能告警的落地实践

简介这份文档是魏墙煤业有限公司综合安全管控平台的建设方案面向煤矿企业信息化负责人、安全管理人员及智慧矿山方案设计者用于指导煤矿安全生产的智能化管控平台从调研到落地的全过程。方案围绕项目建设背景、需求分析、建设原则与推进思路展开涵盖数据平台、机电队、通防队、洗煤厂、智能信息化部、销售部、地测部、运转队、综采队、安质部等多部门调研记录并给出联通原有业务系统、完善数据治理、建设统一数据标准、形成数据管控体系、全域数据分析支撑智能决策等目标。资源包为1个doc文档压缩包约67.25MB内容完整、目录层级清晰便于按章节检索与引用。已有55人学习适合需要撰写煤矿安全管控平台方案或了解智慧矿山建设路径的读者参考借鉴。1. 从一份煤矿安全管控平台建设方案说起这套东西到底解决什么问题如果你手里正躺着一份《魏墙煤业有限公司综合安全管控平台建设方案.doc》或者你所在的煤矿企业正准备上马类似的安全管控平台那你大概率面临这几个现实问题井下人员定位数据、瓦斯监测数据、视频监控数据、设备运行数据各自躺在不同的系统里调度室墙上挂了七八块屏幕真出了事还得靠电话挨个问安监部门来检查要一份“某月某日某区域人员进出记录”你得翻三个系统拼数据领导想看全矿安全态势你只能临时做PPT。这套综合安全管控平台要干的事就是把这些散落的子系统数据统一接入、统一存储、统一展示、统一告警让调度指挥从“人找信息”变成“信息找人”。它适合煤矿信息化负责人、安全副总、调度室主任以及做煤矿智能化项目的集成商工程师。下面我按实际落地路径把这份方案拆成能照着做的步骤。2. 综合安全管控平台的技术架构怎么搭从数据接入到应用层2.1 为什么不能直接买一套现成的安全监控系统很多煤矿已经有一套KJ系列的安全监控系统也有人员定位系统、工业视频系统。但这些都是“垂直系统”——每个系统只管自己那一摊数据格式不同、通信协议不同、告警逻辑不同。综合安全管控平台的核心价值不是替代它们而是在它们之上做一层“数据总线应用门户”。常见做法是采用“边缘接入中心汇聚”的两级架构。边缘侧在井下或井口部署接入网关把不同子系统的协议转成统一格式比如MQTT或OPC UA再通过工业环网上传到中心机房。中心侧部署数据中台做数据清洗、关联、存储最后通过Web门户和移动端呈现。我一般会建议把平台分成四层接入层、数据层、服务层、应用层。接入层负责协议适配数据层负责时序库和关系库的选型服务层负责告警引擎和权限管理应用层负责大屏、报表、移动端。这个分层不是为了好看而是为了后期扩展——比如以后要接AI视频分析只需要在接入层加一个视频分析网关不用动数据层和应用层。2.2 接入层把七八个子系统的数据接进来接入层是第一个要啃的硬骨头。魏墙煤业这类矿井通常要接入的系统包括安全监控系统瓦斯、一氧化碳、风速、温度、人员定位系统精确到分站和读卡器、工业视频系统井上下关键点位、广播系统、水文监测、顶板压力监测、主运输集控等。每个系统的接口方式不一样。老一点的安全监控系统可能只提供OPC DA接口人员定位系统可能是私有TCP协议视频系统一般是RTSP或GB28181。接入网关要能同时支持这些协议。下面是一个用Python写的协议适配示例把Modbus TCP的瓦斯传感器数据转成MQTT消息发到中心平台。实际项目中网关软件通常用C或Go写但用Python做原型验证很快。# modbus_to_mqtt_gateway.py # 功能读取Modbus TCP从站的瓦斯浓度寄存器转成JSON通过MQTT上报 import time import json import paho.mqtt.client as mqtt from pymodbus.client import ModbusTcpClient # --- 参数配置 --- MODBUS_HOST 192.168.10.21 # 井下瓦斯分站IP MODBUS_PORT 502 # Modbus TCP默认端口 SLAVE_ID 1 # 从站地址 REGISTER_ADDR 0x0000 # 瓦斯浓度寄存器起始地址 MQTT_BROKER 10.0.0.100 # 中心平台MQTT Broker MQTT_TOPIC mine/safety/gas/zone1 PUBLISH_INTERVAL 5 # 上报间隔秒 def read_gas_concentration(): client ModbusTcpClient(MODBUS_HOST, portMODBUS_PORT) if not client.connect(): return None # 读保持寄存器瓦斯浓度通常占1个寄存器单位0.01%CH4 rr client.read_holding_registers(REGISTER_ADDR, 1, slaveSLAVE_ID) client.close() if rr.isError(): return None return rr.registers[0] / 100.0 # 转成百分比 def main(): mqtt_client mqtt.Client(client_idgateway_zone1) mqtt_client.connect(MQTT_BROKER, 1883, 60) mqtt_client.loop_start() while True: value read_gas_concentration() if value is not None: payload { sensor_id: GAS-Z1-001, zone: zone1, ch4_percent: value, ts: int(time.time() * 1000) } mqtt_client.publish(MQTT_TOPIC, json.dumps(payload), qos1) time.sleep(PUBLISH_INTERVAL) if __name__ __main__: main()这段代码的逻辑很直白每5秒去Modbus从站读一次寄存器把原始值除以100得到百分比浓度打包成JSON发到MQTT主题。参数说明REGISTER_ADDR要根据实际分站的点表改不同厂家的寄存器映射不一样PUBLISH_INTERVAL不要低于1秒否则井下网关CPU扛不住QoS用1保证至少送达一次但要注意中心平台要做去重。注意Modbus TCP在井下环网里跑一定要设超时和重试。我见过因为一个分站掉线导致网关线程阻塞整个接入层数据延迟超过3分钟的情况。建议每个从站独立线程或异步IO。2.3 数据层时序库和关系库怎么分工数据接进来之后存哪里是个关键选型。安全监控数据是典型的时序数据——每秒都在产生写多读少按时间范围查询。人员定位数据也是时序的但还需要关联人员信息、区域信息。视频数据一般不存平台只存视频管理系统的索引和告警截图。我的建议是时序数据用TDengine或InfluxDB关系型数据用PostgreSQL或MySQL。TDengine对煤矿场景很友好因为它支持超级表可以把不同分站、不同传感器的数据放在一张超级表里按标签查询。下面是一个建表和数据写入的示例。-- 创建瓦斯传感器超级表 CREATE STABLE gas_reading ( ts TIMESTAMP, ch4_percent FLOAT, status TINYINT ) TAGS ( sensor_id NCHAR(32), zone NCHAR(16), location NCHAR(64) ); -- 为每个传感器创建子表实际由接入程序自动创建 CREATE TABLE gas_z1_001 USING gas_reading TAGS (GAS-Z1-001, zone1, 回风巷); -- 查询最近1小时zone1区域瓦斯最大值 SELECT MAX(ch4_percent) FROM gas_reading WHERE zone zone1 AND ts NOW - 1h;超级表的好处是写入时自动按标签分片查询时可以按标签过滤不用扫全表。参数说明TAGS里的字段是标签列适合做维度过滤ts是时间戳列TDengine会自动建索引。注意TDengine的NCHAR长度要按实际传感器编号长度设设太小会截断。关系库这边主要存人员信息、区域定义、告警规则、用户权限、报表模板。比如人员定位系统里读卡器上报的是卡号需要关联到人员姓名、工种、所属区队。这些数据用PostgreSQL存通过外键和时序库的传感器ID做关联查询。2.4 服务层告警引擎和权限管理怎么做告警引擎是安全管控平台的心脏。它要能处理三类告警阈值告警瓦斯超限、逻辑告警人员进入禁入区域、统计告警某区域超员。告警引擎的输入是实时数据流输出是告警事件和通知。常见做法是用规则引擎比如Drools或自研的简单规则匹配。我一般会建议把规则配置化让安全员自己能在界面上配而不是每次改代码。规则的基本结构是数据源条件持续时间动作。# alarm_rule_engine.py # 简化版告警规则匹配瓦斯浓度超过0.8%持续10秒触发告警 import time from collections import defaultdict # 规则定义 RULES [ { id: R001, sensor_pattern: GAS-*, condition: lambda v: v[ch4_percent] 0.8, duration: 10, # 秒 action: trigger_alarm }, { id: R002, sensor_pattern: GAS-*, condition: lambda v: v[ch4_percent] 1.0, duration: 0, # 立即触发 action: trigger_alarm } ] # 记录每个传感器满足条件的起始时间 condition_start defaultdict(dict) def evaluate(data): sensor_id data[sensor_id] for rule in RULES: # 简单通配符匹配 if not sensor_id.startswith(rule[sensor_pattern].replace(*, )): continue if rule[condition](data): key (sensor_id, rule[id]) if key not in condition_start: condition_start[key] time.time() elif time.time() - condition_start[key] rule[duration]: trigger_alarm(rule, data) # 触发后重置避免重复告警 condition_start.pop(key, None) else: condition_start.pop((sensor_id, rule[id]), None) def trigger_alarm(rule, data): print(f[ALARM] rule{rule[id]} sensor{data[sensor_id]} value{data[ch4_percent]})这段代码的核心逻辑是对每条规则检查数据是否满足条件如果满足就记录起始时间持续超过duration才触发。参数说明duration设为0表示立即触发适合一级报警sensor_pattern用通配符匹配传感器ID避免为每个传感器写一条规则。实际项目中规则要存数据库支持热加载不能写死在代码里。权限管理这块煤矿企业通常要求分级分区域。矿领导看全矿区队长看本区队调度员看全矿但只能操作调度相关功能。建议用RBAC模型角色绑定区域权限和功能权限。不要用简单的“管理员/普通用户”两级后期一定不够用。3. 大屏和移动端怎么落地从数据到界面的最后一公里3.1 大屏不是把数据堆上去就行调度室大屏是给领导看的也是给调度员用的。很多项目做出来大屏上密密麻麻全是数字领导看一眼就头晕。我的经验是大屏要分区域、分层级、有重点。常见做法是分三个区域中间是矿井平面图或3D模型上面叠加人员位置、传感器状态、告警闪烁左侧是实时告警列表按时间倒序右侧是关键指标卡片比如当前井下人数、瓦斯最大值、今日告警次数。底部可以放趋势图但不要放太多。技术实现上大屏一般用Web技术Vue或React加ECharts。地图部分可以用SVG或Canvas画矿井巷道图也可以用Three.js做简单3D。关键是数据要实时推送用WebSocket而不是轮询。// dashboard_websocket.js // 大屏WebSocket客户端接收实时数据并更新ECharts const ws new WebSocket(wss://10.0.0.100:8080/realtime); // 初始化ECharts实例 const gasChart echarts.init(document.getElementById(gas-chart)); let gasData []; ws.onmessage function(event) { const msg JSON.parse(event.data); // 只处理瓦斯数据 if (msg.type gas_reading) { const now new Date(); gasData.push([now, msg.ch4_percent]); // 保留最近100个点 if (gasData.length 100) gasData.shift(); gasChart.setOption({ series: [{ data: gasData }] }); } // 处理告警消息 if (msg.type alarm) { showAlarmPopup(msg); } }; ws.onclose function() { // 断线重连5秒后重试 setTimeout(() { window.location.reload(); }, 5000); };这段代码的逻辑是建立WebSocket连接收到消息后按类型分发。瓦斯数据追加到数组并更新图表告警消息弹窗提示。参数说明gasData保留最近100个点是为了防止内存泄漏断线重连用setTimeout简单处理实际项目中建议用指数退避。注意WebSocket在煤矿内网里可能被防火墙拦截要提前确认端口开放。3.2 移动端要解决的是“人不在调度室”的场景煤矿领导经常不在调度室但需要随时知道井下情况。移动端不是把大屏缩小而是聚焦三件事看告警、看人员、看视频。告警要能推送到手机人员要能按区域筛选视频要能调取关键点位。常见做法是用微信小程序或企业微信H5不要做原生App因为煤矿用户不愿意装App。小程序里集成告警列表、人员分布、视频调阅三个页面。告警推送用企业微信机器人或短信网关。注意移动端的数据权限要单独控制。我见过一个项目移动端直接复用了大屏的接口结果普通区队长能看到全矿所有数据。后来加了区域过滤才解决。4. 避坑与排查综合安全管控平台建设中最容易翻车的5个地方4.1 数据接入丢包现象是曲线断断续续原因是网关缓冲区太小现象大屏上瓦斯曲线每隔几分钟就断一段但安全监控系统自己的软件显示正常。原因接入网关的缓冲区设得太小井下环网抖动时数据被丢弃。解决把网关的发送队列长度从100调到1000并增加本地缓存断网时先存本地恢复后补传。4.2 告警风暴现象是5分钟内收到200条告警原因是规则没有收敛现象瓦斯超限时同一个区域的所有传感器都触发告警调度员手机被轰炸。原因规则没有做区域收敛每个传感器独立告警。解决在告警引擎里加一层“区域聚合”同一区域同一类型告警在60秒内只发一条后续告警合并到第一条里。4.3 人员定位数据漂移现象是人员位置在地图上乱跳原因是多读卡器信号冲突现象井下人员位置在地图上频繁跳动有时显示在相邻两个区域之间来回切换。原因人员同时被两个读卡器读到定位算法没有做迟滞处理。解决在定位数据入库前加一层过滤如果新位置和上次位置距离小于阈值比如20米且时间间隔小于10秒则保持上次位置不变。4.4 视频调阅卡顿现象是点开视频要等十几秒原因是流媒体服务器没有做转码现象大屏上点开井下视频要等十几秒才出画面有时还花屏。原因直接调了摄像头的RTSP流没有经过流媒体服务器转码成WebRTC或HLS。解决部署流媒体网关把RTSP转成WebRTC延迟从十几秒降到1秒以内。注意煤矿井下带宽有限要设码率上限。4.5 数据库写入瓶颈现象是数据延迟越来越大原因是时序库没有做分区现象平台运行三个月后实时数据延迟从1秒涨到30秒。原因时序库没有做自动分区单表数据量过大写入性能下降。解决TDengine默认按天分区但如果没设KEEP参数数据会一直保留。建议设KEEP 365并定期清理过期数据。InfluxDB要设retention policy。5. 进阶技巧用历史数据做安全态势预判平台跑起来之后积累的历史数据就是金矿。我一般会建议做两件事一是瓦斯涌出趋势预测二是人员违规行为分析。瓦斯趋势预测可以用简单的移动平均或ARIMA不需要上深度学习。把过去7天同一时段的瓦斯浓度取平均和当前实时值对比如果当前值比历史均值高20%以上即使没超限也提前预警。这个功能在魏墙煤业这类矿井很实用因为瓦斯涌出有周期性。# gas_trend_warning.py # 基于历史同期数据的瓦斯趋势预警 import pandas as pd from datetime import datetime, timedelta def load_history(sensor_id, days7): # 从时序库读取过去7天同一时段的数据 # 实际项目中用SQL查询这里用模拟数据 pass def trend_warning(sensor_id, current_value): history load_history(sensor_id) if history is None or len(history) 10: return None # 计算历史同期均值和标准差 mean history[ch4_percent].mean() std history[ch4_percent].std() # 如果当前值超过均值2倍标准差触发趋势预警 if current_value mean 2 * std: return { sensor_id: sensor_id, current: current_value, history_mean: mean, threshold: mean 2 * std, level: trend_warning } return None这段代码的逻辑是取过去7天同一时段的历史数据算均值和标准差当前值超过均值2倍标准差就预警。参数说明days可以根据数据量调整数据少就取3天2 * std是经验值也可以改成1.5倍。注意这个预警要和阈值告警区分开阈值告警是“已经危险”趋势预警是“可能危险”通知级别要低一些。人员违规行为分析更简单统计每个人员进入禁入区域的次数、每次停留时长生成违规排行榜。这个数据不用实时算每天凌晨跑一次批处理就行。调度室早上开会时看一眼该谈话的谈话该处罚的处罚。我自己的习惯是平台上线后前三个月每周导一次告警数据人工看哪些是误报、哪些是漏报然后回去调规则。没有哪个平台的规则是一次配对的都是磨出来的。希望帮到你。本文还有配套的精品资源点击获取