简介面向煤矿信息化建设与安全管理人员的综合安全管控平台建设方案系统梳理了魏墙煤业机电、通防、洗煤、销售、地测、运转、综采等部门的现状调研与需求分析解决煤矿生产过程中数据孤岛、预警滞后、跨部门协同不足等实际问题。文档以word格式呈现共1个文件包体约67.25MB内含完整建设方案正文目录结构涵盖项目建设背景、需求分析、建设原则、推进思路及建设目标等章节。目前已有55人学习参考。方案不仅包含基于调研数据的现状梳理还细化到十余个部门的调研记录表并提出统一数据标准、数据治理、资源共享与决策支持等建设目标可作为煤矿智能化改造、安全管控平台立项或方案设计的直接参考模板。1. 综合安全管控平台煤矿想建的不只是一块大屏提到综合安全管控平台很多矿方的第一反应是“上一块带三维地图的大屏”但真正在井下待过的人都知道大屏解决不了瓦斯超限后找不到现场负责人、报警没人确认、处置完不闭环的尴尬。这一份“魏墙煤业有限公司综合安全管控平台建设方案”想做的是把安全监测、人员定位、AI视频、应急广播揉成一条可执行的业务流程核心是从“能看到”变成“能联动”。它适合煤矿安全副总、信息中心主任和总包项目经理在立项前反复读方案落不落地先看数据底座和联动设计而不是看可视化效果。2. 先别谈AI和三维安全平台的数据底座怎么搭才不返工我见过太多项目第一版效果图很漂亮进入实施后才发现瓦斯监控系统的数据只存不下发人员定位基站覆盖有盲区广播系统根本不会自动触发。所以拿到方案后的第一步不是选大屏厂商而是盘清楚矿上已有的设备、接口和数据协议。数据底座不牢后面所有“综合”都是纸上谈兵。2.1 平台该有哪几大子系统别被方案清单带偏方案里列出的子系统往往会超过十个其中有一半是供应商为了“看起来完整”硬塞进去的。一个能落地的综合安全管控平台通常只需要分清哪些是刚需、哪些可以二期再做。我一般会把子系统按这张表过滤一遍子系统主要数据来源建设优先级说明安全监控瓦斯/火灾/水害/通风KJ系列监控系统、分站、传感器高必须接入数据质量和断线告警最核心人员定位标识卡、读卡分站、UWB基站高用于区域超员、外来人员闯入、应急救援AI视频识别防爆摄像机、边缘AI盒子中识别未戴安全帽、皮带异物、区域入侵但误报要控制融合通信与应急广播广播系统、扩音电话、调度台高联动时要能自动喊话和通知责任人应急联动应急预案、流程引擎高一键启动预案派单、跟踪、销警闭环双重预防风险清单、隐患排查APP高与实时报警结合形成日常安全管理闭环设备点检手持终端、二维码/NFC低可以二期再上先手工台账不影响联动判断标准很简单这个子系统如果断了数据调度员会不会立刻发现问题安全监控、人员定位、应急广播会设备点检不会。所以我给这个方案定下的原则是先把“会要命”的接进来再把“要管好”的接进来最后处理“要好看”的。2.2 感知层选型哪些传感器必须冗余哪些用矿用隔爆型就够了感知层是整个平台的数据源头也是最容易在预算表里被砍的部分。选型前必须确认每一类传感器都持有煤矿安全标志MA这是硬门槛没有MA的传感器再便宜也不能进矿。在这个基础上我习惯把测点分成“联动类”和“记录类”两类。瓦斯、一氧化碳、风速、风向、温度以及主要通风机、局部通风机的开停状态属于联动类因为它们直接决定断电、撤人和启动应急联动。这类传感器必须做冗余设计采掘工作面回风侧至少布置两台同类型传感器一台进安全监控系统一台进综合平台独立通道避免单点失效导致误判或漏判。烟雾、粉尘、液位、压差等属于记录类可以按规程要求的最低密度布置选矿用隔爆型即可信号统一给到采集网关。测点类型安装位置冗余要求传输方式瓦斯传感器采掘工作面、回风巷、上隅角高双通道RS485或CAN接入安全监控分站一氧化碳传感器带式输送机、回风巷高RS485风速/风压传感器主要进回风巷、测风站低RS485烟雾传感器胶带机头、电气设备处低RS485人员定位读卡分站巷道交叉口、工作面两端中覆盖重叠光纤环网这里有一个隐蔽的坑很多传感器自带显示屏和报警灯但没有数字通信口只有干接点。干接点只能表示“超限/正常”拿不到实时数值。我建议方案里明确要求全部测点必须支持RS485、Modbus或OPC UA中的至少一种数字协议并把“无协议、无法接入平台”写进验收条款。2.3 网络与协议环网断链后还能不能“综合”下去平台网络我一般分成三层设计地面核心层、井下环网层、接入末端层。地面机房放两台核心交换机做双机热备井下按采区划分环网每个环上接安全监控分站、人员定位分站和工业摄像仪末端设备通过接入交换机连进环网。这样设计的目的是把单点故障限制在末端不让某一段光纤断掉后整个采区变成信息孤岛。VLAN用途网段示例说明VLAN 10安全监控数据192.168.10.0/24独立vlan优先保证不丢包VLAN 20人员定位192.168.20.0/24与监控分开VLAN 30视频流192.168.30.0/24大流量避免挤占控制数据VLAN 40办公管理192.168.40.0/24终端管理、填报隐患视频流单独划VLAN是关键一步。曾经有一个矿把所有设备放在同一个二层网络里视频一旦发生网络风暴监控数据也连带着超时调度室所有画面全卡住。VLAN分开后即使视频链路拥塞安全监控数据依然能稳定上传。协议接入是这个环节最花时间的地方。老旧的KJ安全监控系统往往只提供私有协议厂商只给一个串口数据转发盒。我的做法是在井下接入层增加一台协议转换网关把Modbus RTU、RS485、干接点统一转成MQTT或OPC UA再送往地面平台。网关配置里要特别注意死区和数据质量位gateway: id: SJCJ-01 source: - type: modbus-tcp host: 192.168.10.21 port: 502 slave_id: 1 - type: mqtt topic: kj/analog mapping: - tag: WS_SW01 address: 40001 data_type: float scale: 0.1 deadband: 0.2 quality_bit: good这段配置的核心是deadband: 0.2。它表示只有当监测值变化超过0.2时才向平台发送数据否则沿用上次值。这个参数不能设得太大否则真实超限时变化会被过滤掉也不能设为0否则传感器自身的抖动会把带宽和数据库写爆。对瓦斯浓度这类测点我一般按量程的0.1%到0.2%设置死区同时让网关把超过量程上限的数据标记为quality_bit: bad这样平台就知道这是无效数据而不是直接弹出真实报警。3. 把“综合”落到联动从接口、画面到一键启动的工作流数据接进来之后综合安全管控平台才刚开始真正变得“综合”。很多厂商把各子系统画面嵌到同一个网页里就宣布大功告成这其实是“假综合”。真正的综合是让一个报警事件能自动串起画面、定位、广播和责任人值班主任在一个工作台里完成确认、处置、销警和记录。3.1 调度工作台的设计不能用“打开八个系统”来值班我建议把调度员的操作流固定成四个连续动作。第一步是统一告警列表所有子系统的报警按时间顺序进入同一条队列按级别用红黄蓝标色并显示“是否已确认”。第二步是联动弹窗点击某条报警后系统自动弹出对应区域的视频画面、最近的人员定位分布和广播按钮不再需要手工去另一个系统里搜摄像机。第三步是派单值班主任可以把处置任务推给指定的区队长或安监员系统记录派单时间。第四步是销警确认现场反馈后值班员核对结果并关闭工单整个过程可回溯。这块落地的阻力通常来自权限习惯。区队长不愿意让人觉得“每件事都在系统里留痕”所以工作台必须按角色裁剪矿领导只看到趋势和未闭环数量值班主任看全部实时事件区队长只看自己责任区的任务。按钮少一半使用率能高一倍。我在项目里强制要求前端同事把所有角色不需要看到的菜单隐藏掉而不是做权限上的“禁点”因为灰按钮和隐藏按钮给人心理压力完全不同。3.2 人员定位与AI视频两套最容易做成“假集成”的系统人员定位和AI视频是综合安全管控平台里最容易做演示、最难做实效的两个子系统。常见做法是定位数据单独一屏、视频识别单独一屏最多在报警列表里各占一行。真正有效的联动是当区域人数超过上限系统自动截取该区域广播列表并发起语音提醒当AI视频识别到有人跨越皮带或在转载点逗留系统自动在三维地图上定位最近的人员标识卡并把附近摄像头画面推到值班员面前。联动场景触发条件联动动作响应时间要求区域超员定位系统统计人数超过阈值弹窗、广播喊话、通知区队长小于3秒重点区域闯入AI识别到人形进入电子围栏抓拍、弹窗、定位最近卡号小于5秒未戴安全帽AI识别到人员头部无帽抓拍、记录违章、推送安监员小于10秒皮带异物AI识别到超大块煤或锚杆暂停皮带、通知集控员小于2秒这里最容易翻车的是视频识别与定位系统的坐标映射。摄像机和定位基站不在同一坐标系下导致“弹出最近摄像机”总是弹错位置。我的解法是方案阶段就要求实施方做一次联合标定给每台摄像机的视野范围配置对应的地理围栏再用人员定位卡实测几次定位坐标把误差压到巷道实际可能发生的范围。不要依赖厂家默认的“就近匹配”井下巷道弯弯曲曲空间距离最近不代表实际路线最近。3.3 双预控与应急一键启动让方案文档变成可执行清单双重预防机制不能只是把隐患清单导进Excel。我建议在平台上把风险点与实时监测数据绑定某区域的水害风险等级高那么该区域水文监测传感器一旦出现异常数据系统自动在隐患管理模块生成一条待排查任务而不是等人工发现。隐患排查用手机端录入拍照、定位、负责人、整改期限一次填完后台自动更新风险四色图。应急一键启动则需要特别强调“预案编排”。不要把所有逻辑都写死在代码里应该由系统管理员在平台上画出流程报警触发→自动发广播→通知应急小组组长→对应门禁解锁→井下人员定位数据实时汇总到指挥屏→每5分钟刷新一次人员当前位置。这里的关键参数是“自动动作等待时间”我一般配置为报警确认后等待5秒既不误触发又不会因为人工反应慢错过最佳联动时间。emergency: event: CH4_ALARM confirm_timeout: 5 actions: - type: broadcast target: [working_face, main_roadway] voice: 瓦斯超限请暂停作业并按避灾路线撤离 - type: notify users: [safety_duty, team_leader] channel: phone_call - type: unlock doors: [emergency_exit_01, emergency_exit_02] - type: tracking refresh_interval: 5 show_on_map: trueshow_on_map这个参数看起来不起眼但它决定了指挥屏上能不能实时看到人员位置动态更新。很多平台声称支持应急救援实际上只是播放了一条历史路径动画。真实的一键启动必须从告警触发时开始记录所有人员定位数据并以5秒为周期刷新救援人员进场后再叠加一个标识图层标明“已搜救区域”。我习惯在方案里把这个细节写成验收项因为没有它应急指挥就是一块计时器加一部电话。4. 落地避坑五条从现场带回来的血泪经验方案文档写得再厚也要到井下走一遍才知道哪里会断。我盘点一下过去几年做同类项目时踩过的坑每一条都是先看到现象再找到原因最后给出解决动作。4.1 井下交换机环网断链后平台里设备显示“假在线”现象井下某采区光纤被铲车挂断调度室大屏上安全监控数据仍在刷新但实际数据已经十几分钟没变。原因很多监控分站在通信中断后会保持最后一条有效数据不置为“坏质量”平台只判断“有数据进来”就显示在线没有判断数据是否鲜活。解决在数据接入层增加“最近上报时间”字段要求网关持续上报心跳超过3个周期未上报即判定为离线同时把环网交换机的断纤告警接入平台告警列表。另外井下环网必须开启RSTP否则断点后整个环网要等40秒以上才能恢复而综合安全管控平台的联动要求秒级。4.2 老系统只给一个“黑匣子”数据拿到了但没法用现象集成商反馈“安全监控系统已经接了”但平台上看到的瓦斯值始终是同一个数。原因老系统厂商提供了一个反向收费的协议转换盒只输出实时数据不输出传感器量程、单位和有效质量位平台只能按固定系数解析一旦井下改造换量程数据全部失真。解决在合同阶段把“开放数据协议并提供数据字典”列为付款条件实施时要求厂商提供每个测点的量程、单位、报警值和设备台账由集成商在采集网关里逐点核对。对实在不肯开放协议的我一般会加一道物理隔离的独立采集通道把关键传感器并接一台带485口的数据记录仪绕过原系统直接进平台备份数据兼做校验。4.3 AI误报太多导致值班室直接关闭弹窗现象AI视频识别上线第一周每天弹上百条“未戴安全帽”“区域入侵”值班主任直接关掉弹窗功能。原因摄像机安装在煤尘大的位置镜头脏污导致误判算法置信度阈值设得过低把矿车影子和防爆灯当成人员。解决把分析目标区域用ROI框住只识别人员活动通道和作业点忽略顶板、煤流等背景置信度阈值从0.5提高到0.85并让现场人员在手机端给误报图片打标积累一周后再微调模型。镜头防护罩加装气动吹扫装置每天交班时清洁一次。误报率降到每天不超过5条系统才真正会被值班员信任。4.4 时钟不同步联动日志对不上现象瓦斯超限报警时间是14:32:10广播记录是14:33:05人员定位记录显示14:32:00时人员已经撤离前后矛盾。原因井下多数设备没有接入统一的时钟同步源各设备时间漂移平台拿到的是“多枚表”的数据。解决在中心交换机上架设一台NTP服务器井下环网支持的话开启SNTP客户端对不支持同步的老设备由采集网关在接入时打上“网关采集时间戳”与设备原始时间一并入库。联动规则里以平台时钟为准所有子系统的流转时间统一使用平台生成的毫秒级时间戳避免拿设备自己的时间做先后判断。4.5 系统上线后没有人用后台数据全是空的现象平台正式运行一个月双预控模块只录了3条隐患应急演练流程跑了1次其余系统全部在看监控。原因使用流程没有和矿方现有制度绑定工人感觉“又多了一套要做记录的活儿”管理人员又看不到自己绩效相关的统计数据。解决调整方案让每日班前会必须通过平台完成安全确认风险交底拍照上传隐患整改按照“谁录入、谁负责”的规则自动抄送到工资结算系统并把隐患整改及时率纳入区队月度考核。技术上把最常用的三个功能页做成默认桌面实时报警、我的待办、今日统计让使用者打开系统就能开始工作。系统不是让工人多干活而是让工人少跑腿、干部少催表这个产品逻辑必须贯彻到每个按钮。5. 用验收指标证明方案有效数据质量、联动时延和闭环率方案交付时不能只写“已完成”要用指标说话。我最看重的三个指标是数据质量、联动时延和工单闭环率。指标名称计算方法验收标准数据上报成功率平台实际收到测点数 / 现场应上报测点数超过99.5%且无连续3分钟缺失数据鲜活率最近5分钟内有更新的测点比例不低于99%“假在线”为0联动时延从传感器超限到广播喊话出声的时长平均小于5秒最大不超过10秒工单闭环率已销警工单 / 应处置工单达到90%以上且超时工单有原因记录误报率人工确认为误报的事件 / 总报警事件低于3%否则需要调模型或阈值联动时延的测试不能只在调度室模拟要在井下实测。我的习惯是安排两名测试人员一个带标准气样触发传感器一个在巷道另一端听广播和手机通知后台再看平台日志时间戳。连续测五次取平均第五次往往比第一次快很多本质上不是系统变快了而是操作人员熟练了所以我会把前两次的数据剔除。闭环率是衡量系统有没有真正用起来的核心。如果报警弹出来没人认领工单派下去没人办结那这个平台仍是一个“看板”。我最后给项目组保留了一条黄金配置每周一早上由系统自动生成上一周“未闭环事件清单”直接推送给矿长和安全副矿长。再好的技术方案也离不开管理者的持续推动。我个人的教训是不要把验收放在上线当天而是放到上线后第30天。第一天所有设备都通向平台但第30天还能保持数据鲜活率99%以上才说明这套综合安全管控平台真正立住了。这个“第30天复查”的习惯帮我挡住了很多供应商交接后就不管的项目。希望帮到你。本文还有配套的精品资源点击获取