简介这份文档是魏墙煤业有限公司综合安全管控平台的建设方案面向煤矿企业信息化负责人、安全管理人员及智慧矿山方案设计者用于解决煤矿多业务系统数据孤岛、安全监控分散与决策支撑不足等问题。资源包共1个doc文件约67.25MB内容为完整的项目建设方案文本涵盖背景调研、需求分析、建设原则与推进思路等章节。方案从数据平台、机电队、通防队、洗煤厂、智能信息化部、销售部、地测部、运转队、综采队、安质部等多个业务部门的数据调研入手梳理现状与问题进而提出全面监控、智能预警、数据分析与跨部门协同等核心需求并给出安全性、可靠性、兼容性、可扩展性、易用性等建设原则以及总体规划、分步实施、加强培训、持续优化等推进策略。已有55人学习适合需要参考煤矿安全管控平台整体架构与落地路径的读者研读借鉴。1. 从一份煤矿安全管控平台建设方案说起这套系统到底管什么一份名为“魏墙煤业有限公司综合安全管控平台建设方案”的文档摆在面前很多人第一反应是“这不就是个煤矿信息化项目嘛”。但真正在煤矿一线待过的人知道安全管控平台从来不是装几块大屏、接几个传感器那么简单。它要解决的核心问题是井下几百号人的作业状态、几十台设备的运行工况、瓦斯与粉尘的实时浓度、人员定位与考勤的门禁联动这些数据散落在不同厂家的子系统里彼此不通出了事只能靠电话和喊话。综合安全管控平台要做的就是把这些“信息孤岛”焊成一张网让调度室能看到一个真实的、实时的、可追溯的井下世界。这套方案面向的是煤矿企业的安全副矿长、调度室主任、信息化负责人以及承接这类项目的系统集成工程师。它不追求炫酷的AI概念而是强调“管用”人员进出井是否唯一对应、瓦斯超限是否自动断电并推送到责任人手机、设备检修是否闭环留痕。如果你正在写类似的煤矿安全平台技术方案或者要评估一家供应商的交付能力这份文档的拆解思路可以直接复用。接下来我会按“平台该建什么→数据怎么接→告警怎么联动→验收怎么测”的顺序把这类项目的落地路径讲透。2. 综合安全管控平台的功能模块拆解与选型逻辑2.1 煤矿安全管控平台必须覆盖的六类核心数据煤矿安全管控平台的数据源不像地面工厂那么规整它天然带有“多源、异构、强实时”的特点。根据常见做法我会把接入数据分为六类人员定位数据UWB或ZigBee标签、环境监测数据瓦斯、一氧化碳、氧气、粉尘、温度、风速、设备工况数据主扇、局扇、皮带、水泵的电流与开停状态、视频监控数据井口、变电所、采掘工作面、门禁与考勤数据唯一性检测装置、以及生产调度数据产量、进尺、作业计划。这六类数据里人员定位和环境监测是安全管控的“两条命脉”前者决定应急时能不能点清人数后者决定能不能在瓦斯超限前切断电源。选型时最容易翻车的地方是协议不统一。人员定位厂家用私有TCP协议环境监测用Modbus RTU设备工况用OPC DA视频又是RTSP流。如果平台没有内置协议适配层每接一个子系统就要写一次定制代码后期维护成本极高。我一般会要求平台侧提供三种接入方式OPC UA统一架构、MQTT消息队列、以及RESTful API。对于老设备只有串口的加一台串口服务器转成Modbus TCP再接入。这个选型逻辑在方案里必须写清楚否则验收时甲方问“为什么A厂家的分站接不进来”你只能现场改代码。2.2 从“监”到“控”告警联动逻辑的设计原则很多煤矿安全平台只做到了“监”大屏上数字跳来跳去但超限了不会自动处置。真正的综合管控平台必须实现“监”到“控”的闭环。以瓦斯超限为例标准逻辑是传感器浓度超过预设阈值→平台在500ms内生成告警事件→自动向对应区域的断电仪下发断电指令→同时向该区域人员定位标签发送撤离震动信号→向调度室和矿长手机推送短信/APP通知→记录处置全过程。这个链条里断电指令的下发是硬要求不能只靠人点鼠标确认。设计联动逻辑时参数设置要分区域分级。比如采煤工作面瓦斯报警阈值设0.8%断电阈值设1.0%掘进工作面因为通风条件差报警阈值设0.5%断电阈值设0.8%。这些阈值必须能在平台界面上按区域单独配置不能写死在代码里。另外联动动作要有“后悔药”机制如果传感器故障导致误报平台要允许调度员在10秒内撤销断电指令但撤销操作必须记录操作人和时间防止人为掩盖真实超限。这个设计细节在方案里往往被忽略但现场调试时能省掉大量扯皮。2.3 平台技术栈选型为什么我不推荐一上来就微服务写建设方案时技术架构章节最容易写成“Spring Cloud Kafka Redis InfluxDB”的堆砌。但煤矿安全管控平台的真实负载并不高一个中型矿井人员定位标签约500-2000个环境传感器约200-500个数据上报频率大多是1秒到30秒一次。总并发连接数很少超过5000每秒写入点位不超过2万。这个量级用单体应用加时序数据库完全扛得住。我见过一个项目上了微服务结果运维复杂到矿上信息科三个人根本管不过来最后又退回单体。我的建议是初期用“单体应用 PostgreSQL/TimescaleDB Redis缓存 MQTT Broker”的架构。应用层按模块划分包结构但部署为一个进程。等接入的子系统超过20个、或者需要和集团级平台做数据同步时再把告警服务、数据采集服务拆出来。方案里可以写“支持微服务演进”但别把微服务当成起点。数据库选型上时序数据用TimescaleDB比InfluxDB更合适因为煤矿安全数据经常需要和关系型数据人员信息、设备台账做JOIN查询TimescaleDB基于PostgreSQL省去了跨库同步的麻烦。3. 数据接入与实时处理从传感器到调度大屏的完整链路3.1 用MQTT Broker统一接入异构数据的配置示例数据接入层是整个平台的地基。我通常会在方案里明确所有子系统必须通过MQTT协议向平台推送数据主题Topic按“矿井/区域/设备类型/设备ID”四级命名。比如魏墙煤业一号井采煤工作面的瓦斯传感器主题为mine/weiqiang/area_101/gas/sensor_023。这样平台侧只需要订阅mine/weiqiang/#就能拿到全矿数据新增设备时不用改平台代码。下面是一个用Mosquitto作为MQTT Broker的配置片段以及一个Python写的模拟传感器上报脚本。实际项目中传感器数据由边缘网关转换后上报这里用脚本模拟是为了方便调试。# mosquitto.conf 关键配置 listener 1883 allow_anonymous false password_file /etc/mosquitto/passwd # 开启持久化防止Broker重启丢消息 persistence true persistence_location /var/lib/mosquitto/ # 限制单个客户端最大消息队列防止慢消费者拖垮Broker max_queued_messages 1000# sensor_simulator.py import paho.mqtt.client as mqtt import json import time import random # 连接参数Broker地址、端口、用户名密码 broker 192.168.10.50 port 1883 username mine_platform password WeiQiang2024 client mqtt.Client(client_idsim_sensor_023) client.username_pw_set(username, password) client.connect(broker, port, 60) while True: # 模拟瓦斯浓度正常范围0.2%~0.6%偶尔模拟超限 gas_value round(random.uniform(0.2, 0.6), 2) if random.random() 0.05: gas_value round(random.uniform(0.8, 1.2), 2) # 5%概率超限 payload { sensor_id: sensor_023, type: gas, value: gas_value, unit: %, timestamp: int(time.time() * 1000), status: normal if gas_value 0.8 else alarm } # 主题按四级命名规则 topic mine/weiqiang/area_101/gas/sensor_023 client.publish(topic, json.dumps(payload), qos1) time.sleep(1) # 每秒上报一次这段代码的逻辑很直白模拟一个瓦斯传感器每秒向指定主题发布JSON数据。关键参数有三个qos1表示至少送达一次适合安全数据client_id必须全局唯一否则会互相踢下线timestamp用毫秒级Unix时间戳方便后续做时序查询。实际部署时边缘网关会替代这个脚本但主题命名规则和payload结构要保持一致。平台侧订阅后先做数据校验值是否在合理范围、时间戳是否偏移过大再写入TimescaleDB。3.2 实时告警规则引擎的三种实现方式对比告警规则引擎是平台的大脑。常见实现方式有三种硬编码在业务逻辑里、用Drools等规则引擎、或者用Flink CEP做复杂事件处理。我根据项目规模给过不同建议下面这张表是选型对比。实现方式适用场景优点缺点业务代码硬编码规则少于20条且很少变动开发快调试直观改规则要重新发版矿上等不起Drools规则引擎规则50~200条需要业务人员参与维护规则与代码分离支持热更新学习曲线陡性能一般Flink CEP规则复杂需要跨事件流关联如“瓦斯超限且人员未撤离”吞吐高支持窗口计算运维重小矿用不上对于魏墙煤业这类中型矿井我一般推荐Drools。把规则写成DRL文件放在数据库或配置中心平台启动时加载。比如“瓦斯超限断电”规则可以写成当收到typegas且value 1.0的事件时触发PowerCutAction参数为传感器所在区域。这样安全科的人自己就能在界面上改阈值不用找开发。如果方案预算充足且集团要求统一管控再考虑Flink CEP。3.3 时序数据存储TimescaleDB建表与压缩策略环境监测数据是典型的时序数据写入频繁、查询按时间范围、很少更新。用PostgreSQL原生表也能存但数据量上到千万级后查询会明显变慢。TimescaleDB作为PostgreSQL扩展能把一张表自动分区成多个chunk查询时只扫描相关时间段的chunk。下面是建表语句和压缩策略。-- 创建环境监测数据表 CREATE TABLE env_monitor ( time TIMESTAMPTZ NOT NULL, sensor_id VARCHAR(32) NOT NULL, mine_id VARCHAR(32) NOT NULL, area_id VARCHAR(32) NOT NULL, sensor_type VARCHAR(16) NOT NULL, value DOUBLE PRECISION, unit VARCHAR(8), status VARCHAR(16) ); -- 转换为超表按时间分区每7天一个chunk SELECT create_hypertable(env_monitor, time, chunk_time_interval INTERVAL 7 days); -- 创建复合索引加速按区域和类型的查询 CREATE INDEX idx_env_area_type_time ON env_monitor (mine_id, area_id, sensor_type, time DESC); -- 开启压缩7天前的数据自动压缩节省存储 ALTER TABLE env_monitor SET ( timescaledb.compress, timescaledb.compress_segmentby mine_id, area_id, sensor_type ); SELECT add_compression_policy(env_monitor, INTERVAL 7 days); -- 设置数据保留策略原始数据保留180天之后降采样或删除 SELECT add_retention_policy(env_monitor, INTERVAL 180 days);建表时要注意time字段用TIMESTAMPTZ而不是TIMESTAMP避免时区问题sensor_id和area_id建索引时放在时间字段前面因为查询条件通常是“某区域某类型最近一小时”。压缩策略里的compress_segmentby按矿井、区域、类型分段压缩率通常能到10:1以上。保留策略设180天是煤矿安全规程的常见要求但具体天数要跟矿方确认有些矿要求保存一年。如果存储空间紧张可以先降采样到1分钟粒度再长期保存。4. 避坑与排查煤矿安全管控平台实施中最容易翻车的五件事4.1 人员定位标签漏读导致“井下人数对不上”现象调度室大屏显示井下320人但井口考勤机统计入井325人差5人。应急演练时点不清人数矿长当场发火。原因UWB定位基站在巷道拐角、金属支护密集区域信号衰减严重标签漏读。另外标签电池电量低时发射功率下降也会导致漏读。还有一种情况是人员乘坐猴车快速通过时定位刷新率跟不上。解决在巷道拐角和金属密集区增加定位基站密度一般每200米一个拐角处加密到100米。标签刷新率从1秒调到0.5秒但会增加功耗需要平衡。平台侧做“最后位置保持”逻辑如果标签超过30秒未上报按最后已知位置显示并标记为“信号丢失”而不是直接消失。井口唯一性检测装置要和定位系统做数据比对差异超过3人时自动告警。4.2 瓦斯传感器标校后数据跳变触发误断电现象早班标校瓦斯传感器后平台连续收到几个高值触发断电影响生产。矿方要求给说法。原因标校时通入标准气样传感器输出值会瞬间升高到标气浓度如2.0%如果平台没有识别“标校状态”就会当成真实超限。另外标校结束后传感器需要30-60秒恢复这期间数据可能不稳定。解决在平台侧增加“标校模式”标记。传感器标校时由标校人员在平台或APP上先点击“开始标校”平台收到该传感器数据后不触发告警只记录。标校结束后点击“结束标校”恢复正常判断。如果忘记点结束平台检测到持续高值超过5分钟且无人员撤离动作再触发告警。这个逻辑要写进方案否则每次标校都提心吊胆。4.3 断电指令下发失败但平台显示“已执行”现象瓦斯超限后平台显示“断电指令已下发”但现场设备没停。事后追查发现断电仪通信中断。原因平台和断电仪之间的通信链路没有做心跳检测。平台发出指令后只要TCP连接没报错就认为成功实际上断电仪可能已经掉线。另外有些断电仪是脉冲触发平台发一次指令它动作一次如果指令在传输中丢失就不会再补发。解决平台必须要求断电仪定期上报心跳如每10秒一次心跳超时3次即标记为“通信中断”并告警。断电指令下发后平台要等待断电仪的“动作反馈”信号收到反馈才标记为“已执行”。如果5秒内未收到反馈自动重发重发3次仍失败则触发“断电失败”紧急告警通知调度员手动断电。这个闭环逻辑是安全平台的核心方案里必须明确写。4.4 视频监控与安全告警不同步回放找不到对应片段现象瓦斯超限告警记录时间是14:23:15但调出视频回放14:23:15前后没有任何异常画面矿方怀疑平台造假。原因视频监控系统的时间没有和平台做NTP对时摄像头时间比平台时间慢了2分钟。另外视频存储的索引是按摄像头本地时间建的平台按自己的时间查自然对不上。解决全矿所有接入平台的设备包括摄像头、传感器、断电仪、定位基站必须统一走NTP对时时间源用平台服务器。方案里要写明“平台侧部署NTP服务所有子系统每日凌晨自动对时偏差超过5秒即告警”。视频回放查询时平台按告警时间前后各扩展30秒发起查询避免边界问题。如果摄像头不支持NTP至少要在平台侧记录摄像头的时间偏移量查询时做补偿。4.5 平台上线后矿方信息科不会维护系统逐渐荒废现象平台验收后三个月传感器离线没人管告警记录堆了几万条没人看大屏成了摆设。原因方案里只写了“提供培训”但培训内容是开发视角的操作手册矿方信息科的人看不懂。另外平台没有做“自诊断”功能设备离线了不主动通知维护人员。解决方案里要包含“运维移交”章节明确三类文档设备接入配置手册按厂家分册、日常巡检清单每日/每周/每月、故障处理流程含联系人。平台侧增加“设备健康度”页面离线设备自动生成工单推送给指定维护人员。培训要分角色调度员学告警处置信息科学设备接入和备份恢复安全科学规则配置。培训后做实操考核不合格的重新培训。这一步不做再好的平台也活不过半年。5. 验收测试与持续运行怎么证明平台真的管用5.1 用“模拟故障注入”做验收测试的四个场景平台验收不能只看功能列表打勾要模拟真实故障。我一般会设计四个场景每个场景都要有明确的通过标准。场景一瓦斯超限断电闭环。在采煤工作面释放标准气样让传感器浓度升到1.2%。通过标准从浓度超限到断电仪动作时间不超过2秒平台生成告警记录包含传感器ID、区域、浓度值、断电指令下发时间、断电反馈时间调度员手机收到推送。如果断电仪没动作或者平台记录缺失验收不通过。场景二人员定位漏读补偿。安排5个人携带标签从井口走到采煤工作面其中1个人在拐角处停留30秒后继续走。通过标准平台显示的轨迹连续停留点标记为“信号丢失”而非消失最终井下人数与入井人数一致。如果轨迹出现跳跃或人数对不上需要调整基站密度。场景三通信中断告警。拔掉一台断电仪的网线等待30秒。通过标准平台在40秒内标记该设备为“通信中断”并推送告警给维护人员恢复网线后设备状态自动恢复正常。如果平台一直显示在线说明心跳检测没做。场景四历史数据查询性能。在平台界面上查询“过去30天一号井所有瓦斯传感器每天的最大值”。通过标准查询响应时间不超过5秒返回结果与数据库直接查询一致。如果超过10秒需要检查TimescaleDB的压缩策略和索引。5.2 平台上线后的三个关键运行指标验收通过只是开始持续运行要看三个指标。第一个是“告警处置率”所有告警中有处置记录包括确认、断电、撤离、恢复的比例要求不低于95%。低于这个值说明要么告警太多没人看要么处置流程太复杂。第二个是“设备在线率”所有接入设备中状态为在线的比例要求不低于98%。低于这个值说明通信链路或供电有问题。第三个是“数据完整率”实际存储的数据点数与应上报点数的比例要求不低于99%。低于这个值说明MQTT Broker丢消息或者数据库写入失败。这三个指标要能在平台首页实时显示并且按日、周、月生成报表。矿方安全副矿长每周一看上周报表哪个区域告警处置率低就找那个区域的负责人。这个管理动作比技术本身更重要。我见过一个矿平台技术指标都达标但告警处置率只有60%原因是调度员觉得“反正每次都是传感器误报”。后来把处置率和调度员工资挂钩一个月后升到92%。技术管用不管用最终看人怎么用。5.3 一个具体技巧用“影子模式”验证新规则平台运行一段时间后安全科总会想加新规则比如“皮带机头温度超过60度且持续3分钟就停机”。直接上线新规则有风险万一规则写错了可能导致频繁停机。我一般会建议先用“影子模式”跑一周。影子模式的意思是新规则照常计算但只记录“如果触发会执行什么动作”不真正下发指令。一周后看记录如果触发次数合理比如每天1-2次且每次触发时现场确实有异常再切换到“执行模式”。如果一天触发几十次说明阈值设错了回去改。这个技巧在方案里可以写成“规则灰度发布机制”。实现上很简单规则表加一个mode字段值为shadow或active。规则引擎匹配到shadow规则时只写日志不执行动作。日志表里记录规则ID、触发时间、预期动作、实际未执行原因。安全科的人每天看影子日志确认无误后点“启用”。这个功能开发量不大但能避免很多“新规则上线第一天就搞出生产事故”的翻车现场。我自己在煤矿项目上踩过最深的坑是太相信“技术能解决一切”。早期做的一个平台功能都实现了但矿方调度员嫌告警弹窗太频繁直接拿胶带把报警音箱的线粘住了。后来我学乖了每次方案里都写“告警分级”一级告警瓦斯超限、人员超员用声光短信电话二级告警设备离线、温度偏高只用界面弹窗三级告警数据波动只记日志。调度员不被噪音轰炸才会认真对待一级告警。希望帮到你。本文还有配套的精品资源点击获取