简介煤矿信息化技术专题PPT源自中国矿业大学丁恩杰教授的报告适合煤矿自动化、信息化相关从业者、研究人员及高校学生参考学习使用。内容围绕工业以太网技术、数字化变电所、WI-FI无线通信技术等关键模块展开并引入基于WI-FI的新一代井下救灾监控指挥系统研究课题。其中对工业以太网的概念、现场应用关键技术、Modbus TCP/IP、ProfiNet等协议做了系统讲解有助于把握煤矿井下通信、监控与供电系统的技术要点与选型思路。资源为单一pptx文件共1份大小约3.68MB重点集中便于移动端或电脑端直接查看。目前已有54人学习页面编排以报告提纲呈现层次分明适合作为技术培训、课件制作或方案汇报时的直接参考素材。1. 煤矿信息化技术一张PPT背后的系统选型与落地路径煤矿信息化技术这个概念在很多矿上落地的第一形态其实不是系统而是一份PPT。无论你是要立项汇报、招标技术方案还是给领导讲“智慧矿山”蓝图最后拿出手的都是几十页的pptx。但PPT画得再漂亮井下采掘工作面装了多少传感器、环网链路断了有没有人管、数据采上来是不是真能出报表这些才是煤矿信息化技术值不值得信的关键。这篇文章不打算教你做PPT而是从一份典型的《煤矿信息化技术》汇报材料出发把它拆成可落地的东西架构怎么搭、子系统怎么接、数据怎么管、现场哪些坑容易翻车以及验收前怎么验证。适合正在做矿井信息化方案设计、集成实施或运维的从业者。先立一个反直觉的结论煤矿信息化最大的瓶颈往往不在技术本身而在数据源头和接口协议。2. 从PPT到井下先把信息化架构的四层骨架搭对一份煤矿信息化技术的PPT几乎都会画那张“四层架构”图感知层、传输层、平台层、应用层。这张图人人都能画但真正把它落到井下每一层都有各自的选型逻辑和实施边界。我见过不少项目PPT阶段四层画得很顺畅到了井下验收却层层卡壳原因多半是每一层都掺杂了“想当然”。2.1 感知层井下数据不是想采就能采感知层是煤矿信息化技术的底座包括瓦斯、一氧化碳、温度、风速、粉尘、液位、电流电压、振动、图像等各类传感器。PPT上往往只画一个图标“传感器集群”但现场要回答的问题很具体供电怎么来、信号怎么传、精度够不够、断线了怎么判断、有没有矿用本安或隔爆认证。常见做法是感知层按“环境监测类、设备工况类、视频图像类”三组分别选型。环境监测类传感器瓦斯、一氧化碳、温度等必须接入矿井安全监控系统优先选用有矿用产品安全标志MA标志的设备通信方式以RS485或CAN总线为主少数新设备支持以太网。设备工况类传感器比如皮带秤、振动、电流大部分来自各子系统自带PLC不需要单独布点而是通过子系统接口上送。视频类则单独走工业以太网或视频专网避免和监控分站抢带宽。关键参数需要注意几个传感器量程和精度比如瓦斯传感器量程通常0-4%CH4报警点设置要按煤矿安全规程定不能按说明书默认值输出信号类型4-20mA、RS485 Modbus RTU、数字量开关直接决定采集器选型本安电源的带载能力单路本安电源一般带2-4个传感器总线供电要算总电流否则井下电压降会玄学掉线。很多矿在感知层容易翻车的点是“传感器装上了但没校准”。尤其瓦斯传感器需要定期调校否则数据漂移后平台上看曲线是好的实际值和便携仪差了十万八千里。所以感知层实施时我一般会建议在合同里写明“调校周期和谁负责”否则后期运维全部推到集成商头上。2.2 传输层工业环网与5G专网的取舍传输层最常见的选择有两个矿井工业以太环网和5G专网。PPT上通常写“万兆工业环网5G全覆盖”但井下环网覆盖的是主巷道、采区变电所、主要机电硐室工作面内部往往只有有线网络5G则主要解决移动场景比如掘进机远程控制、巡检机器人、无线视频回传。两者不是替代关系而是按业务需求分区部署。工业环网实施时核心参数是环网自愈时间。一般要求小于50ms实际项目中某矿的环网由12台矿用隔爆型交换机组成用RSTP或MRP协议自愈时间在20-50ms之间都能满足。但如果用了STP生成树协议且没有调优自愈时间可能到秒级自动化系统画面会长时间灰屏这就是常说的“链路断了没人知道知道了也切不过来”。5G专网的取舍要看业务是否真的需要井下5G覆盖成本高、基站数量多井下巷道直线覆盖半径一般300-500米弯道更多、井下防爆改造难度大。如果业务只是调度语音和定位用WiFi6或UWB反而更成熟。5G适合的是远程掘进、无人驾驶辅助这类大带宽低时延场景。另外5G核心网是下沉到矿侧还是上移到集团直接影响时延和数据安全边界这个决策要在方案阶段定不能等设备到货再改。传输层的落地习惯是“先有线后无线、先主干后分支”。环网光缆敷设要避开积水巷段和频繁拉移区域井下交换机要留足备用光口否则新增子系统时又要重新熔接既耽误时间又增加故障点。还有一条血泪经验环网协议要统一不同品牌交换机混用如果不用标准协议环网自愈时可能出现环路风暴直接打挂整个自动化网络。2.3 平台层与应用层一张图、一朵云、一个门户平台层在PPT里经常画成一个“云平台”或者“数据中台”但落地时真正发挥作用的是三个东西实时数据库/时序数据库、GIS一张图、统一门户含报表和告警。应用层则是在这个底座上跑的安全监控、人员定位、应急广播、排水自动化、皮带集控、视频AI等业务系统。平台层的选型原则是“能统一的不单独建”。比如时序数据库如果每个子系统都自带一个库最后数据分散成孤岛报表要登五个系统去手工抄数。常见做法是部署一套工业时序数据库如基于通用开源时序库二次开发的平台把安全监控、人员定位、电力监控、排水、皮带等实时数据统一接入按“测点ID时间戳质量戳”存储。应用层的集成方式比选型更重要。很多矿上了十几个“智慧子系统”每个子系统一套账号、一个IP、一张网页这种“门户堆砌”不算信息化。我一般会按统一身份认证LDAP/OAuth统一待办统一告警来收敛。告警尤其要收敛井下本来的报警就多如果不做去重和分级调度员会被告警轰炸到麻木真正的高值报警反而没人看。这一层的另一个重点是指标口径统一。PPT里很好看的“万吨煤能耗”“设备开机率”这类指标如果底层数据口径不一致比如开机率是按运行时间/日历时间还是按运行时间/计划生产时间不同子系统算出来的结果能差20个百分点。所以平台层上线前要拉上机电、调度、安全各部门把指标定义签字确认这是很多人忽略但后期吵架最多的事。3. 让PPT里的系统真跑起来几个绕不开的落地模块PPT上的架构图、大屏截图、数据流向图都很完整但让系统“真跑起来”通常会卡在三个模块子系统协议对接、GIS一张图的坐标统一、数据治理与指标计算。这三个模块做扎实了煤矿信息化技术才从“展示型”变成“生产型”。3.1 综合自动化子系统集成协议对接的现实做法综合自动化集成是煤矿信息化实施中最耗时的部分。井下子系统品牌杂、年代跨度大协议有Modbus RTU/TCP、OPC DA/UA、S7通信、DL/T 645电表规约甚至还有纯干接点。集成不是“写个接口”那么简单先要盘点每个子系统的接入方式、寄存器表和点位表。我比较常用的做法是分层接入先做一个“接入适配层”每个子系统对应一个采集驱动统一把数据上送到时序数据库。驱动用Python或C#写常见伪代码逻辑如下以Modbus TCP为例import time from pymodbus.client import ModbusTcpClient # 子系统接入配置IP、端口、从站号、轮询周期 client ModbusTcpClient(192.168.1.50, port502, timeout3) if not client.connect(): print(f[{time.time()}] 连接失败: 皮带集控PLC) # 这里要做重连退避不能死循环 else: # 读取保持寄存器从地址0开始读20个寄存器 rr client.read_holding_registers(address0, count20, slave1) if rr.isError(): print(读取异常检查点位表地址) else: # 现场数据往往是16位整数注意大小端和缩放系数 for i, val in enumerate(rr.registers): # 例如电流: 原始值650对应65.0A缩放系数0.1 scaled val * 0.1 tag_id fbelt_1_current_{i} write_to_tsdb(tag_id, scaled, time.time()) client.close()这段代码的逻辑说明先按子系统IP建连超时设3秒避免某个从站无响应时阻塞整条采集链路连接失败不能立刻重试要退避否则多个驱动同时重试会把PLC网络拖垮寄存器地址必须和现场点位表核对大小端字节序和缩放系数是常见错误源。参数方面轮询周期一般设备工况类设为1-5秒环境监测类数据变化慢可以放到10-30秒如果子系统点位很多要分批读取不能一次读几百个寄存器会超过报文长度限制。另一个现实问题是老设备的OPC DA接口。OPC DA基于COM/DCOM跨机器配置DCOM权限很麻烦井下上位机如果是Win7老系统还好新装的Win10/11机器跑OPC DA经常黑匣子式闪断。我的建议是能上OPC UA的就优先OPC UA连不上的用独立的OPC DA转UA网关不要图省事直接在上位机装DA客户端否则后面每次重启都得调DCOM。3.2 一张图与GIS坐标统一是第一步“一张图”是煤矿信息化PPT里最吸睛的部分井上下对照、采掘工程平面图、设备实时状态叠加。但落地时最大的坑不是GIS平台选型而是坐标系统一。煤矿图纸常见的有1954北京坐标系、1980西安坐标系、2000国家大地坐标系还有矿区自定义的独立坐标系。如果一张图要叠加井下测绘数据、地表沉陷数据、钻孔数据坐标系不一致就是灾难。实施时我一般按这套流程走先确定底图坐标系新建项目优先用CGCS2000老矿区如果没有转换参数就沿用原独立坐标系并在平台里标注然后把各来源数据统一转换。具体操作的第一步是拿矿方提供的采掘工程平面图一般是DWG做坐标配准在GIS软件里选控制点至少要选均匀分布的4-6个点不能只在图幅角落选。配准之后还要处理“设备测点坐标如何落到图上”。井下传感器和设备在子系统里的位置往往是文字描述如“南翼皮带机头”没有经纬度或平面坐标。我见过一个项目把井下定位基站坐标搞错了一个数量级结果一张图上的人员位置全跑到地表河流里去了。正确的做法是由矿地测科出具设备安装点的矿图坐标X、Y、Z集成方据此上图而不是依据现场人员口述“大概在哪个硐室”。一张图平台里还要定义图层规范。比如“安全监控测点”图层用红色圆点、“人员定位基站”用蓝色三角、“排水泵”用绿色方块每个图层挂接属性表至少包含设备ID、子系统来源、安装位置、投运日期。这样做的好处是后期做告警联动比如瓦斯超限自动关联周围人员分布时查询效率高也方便运维人员排查。3.3 数据治理与指标口径PPT画得再好也怕脏数据煤矿信息化技术做到后期拼的不是平台功能而是数据质量。脏数据来源主要有几类传感器断线后存的“旧值重复”、PLC停机时的“0值假数据”、网关重启后的“时间戳跳变”、多个系统重复采集导致的“同一测点多值”。我一般会在平台里建三层数据质量规则。第一层是完整性规则比如某个测点连续N分钟没有新数据要生成“数据中断”告警而不是等用户发现第二层是有效性规则比如瓦斯浓度不可能为负瞬时值超过量程上限要标记为“可疑”而不是直接入库展示第三层是稳定性规则比如电流在1秒内从10A跳到200A再跳回多半是采集抖动或信号干扰要用死区滤波或突变抑制处理。这些规则落到实现上可以用流处理任务也可以直接用时序数据库的连续查询。以常见开源时序库为例SQL格式大致是这样-- 对每个测点做突变检测和上一条记录比变化率超过阈值则标记质量戳 SELECT tag_id, timestamp, value, CASE WHEN ABS(value - LAG(value) OVER (PARTITION BY tag_id ORDER BY timestamp)) threshold THEN spike ELSE good END AS quality FROM raw_measurements WHERE timestamp now() - INTERVAL 5 minutes;这段SQL的逻辑说明用窗口函数LAG取同一测点的上一条值差值绝对值超过阈值就标记为“spike”。参数方面threshold按测点类型分别配置电流电压类变化快阈值可以放宽瓦斯等环境参数变化慢阈值要收紧比如超过0.2%CH4/5秒就值得怀疑。质量戳要在展示和应用层做过滤不能只是标记在库里不处理否则大屏上还是会闪一个异常值。指标口径这块最典型的是“设备故障率”。机电科的口径是“故障时间/日历时间”生产科的口径是“故障时间/计划运行时间”两者差多少取决于检修时长。我的做法是建一个“指标字典”每个指标写清楚公式、数据来源、更新频率、责任部门评审通过后作为系统配置写死任何部门要改口径都要走变更流程。这听起来笨但能避免验收后三天两头为了报表数字吵架。4. 煤矿信息化避坑指南PPT上没写的五个现场问题煤矿信息化技术的PPT不会写这些但它们决定了系统能不能稳定用下去。以下五条都是现场高频踩坑点按“现象→原因→解决”展开几乎每个矿都会遇到至少两条。4.1 现象环网断链后自动化画面全灰现象某矿综合自动化系统运行正常某天井下一条巷道的光缆被拉断按说环网应该自动切换到备用路径但调度中心的大屏上所有相关画面全部变灰持续了好几分钟才恢复。原因交换机虽然组了环但使用的生成树协议没有开启快速收敛或协议不一致默认的STP收敛时间是30-50秒加上参数老化时间和上层平台的重连时间用户体验就是“断链几分钟没人管”。另外部分交换机默认启用了环路保护断链后把端口阻塞了反而切不回来。解决统一使用RSTP或MRP协议并开启快速迁移。万兆骨干环建议用MRP收敛时间能做到20ms级分支环用RSTP也能做到秒级以下。实施时把“环网自愈时间”写进测试项验收时专门做一次人为断纤测试拿秒表计时不达标不签字。4.2 现象GIS一张图坐标对不上测点飘到地面现象一张图平台部署完成后安全监控测点叠加到底图上瓦斯传感器位置显示在巷道外面甚至地表人员定位轨迹横穿煤柱完全不符合实际。原因两个来源的数据用了不同坐标系叠加井下定位基站坐标未经过地测科核准用了施工方的手持GPS粗采数据误差达几十米还有DWG图纸配准控制点选得太少底图本身就已经扭曲。解决统一坐标系优先CGCS2000所有上图数据必须附带“坐标系采集方法责任人”元数据基站和传感器坐标由矿地测科正式出具不用施工队手持设备数据DWG配准至少选4-6个均匀控制点配准后抽查已知点误差超过图上0.5m就要返工。4.3 现象数据采集到了但时序数据库磁盘暴涨现象平台上线一个月后时序数据库所在磁盘从30%涨到95%查询变慢甚至导致采集服务写不进去。排查发现大量测点每秒钟写入一次但很多数据是不需要秒级存储的。原因采集驱动配置时把所有测点都设成了1秒轮询和1秒存储忽略了数据分层。比如环境监测数据5秒变化一次没必要每秒存设备工况数据平时稳定秒级存储只在故障诊断时有价值。解决实行“采集频率和存储频率分离”。采集可以1秒存储按测点类型设置死区变化超过死区才写库否则沿用旧值或完全不写查询时用最后值填充。实际项目里环境类测点存储周期设为5-10秒工况类稳定测点设3-5秒死区磁盘占用能下降70%以上历史数据完整度不受影响。4.4 现象OPC UA打通了但画面刷新慢现象某皮带集控子系统通过OPC UA接入综合自动化平台数据能读到但组态画面上数值刷新延迟5-10秒操作指令下发反应也慢。原因OPC UA订阅参数没调。服务器端采样间隔设成了1秒但发布间隔PublishingInterval默认可能设成了1秒或更大客户端订阅队列长度太小数据变化快时丢弃另外会话数太多也会拖慢服务器响应。解决把OPC UA服务器发布间隔设为100-200ms采样间隔保持100ms客户端Session超时设长一些避免频繁断连重建订阅队列长度至少设为服务器节点数的2倍。还有一点容易被忽略不要用同一个OPC UA连接同时订阅几百个节点按子系统拆成多个订阅避免单连接负载过高。4.5 现象信息安全等保测评不通过现象矿业集团统一做网络安全等级保护测评某矿信息化平台被查出大量问题主机默认口令未改、数据库任意IP可访问、审计日志未启用、通信未加密。整改周期紧张影响验收。原因项目实施时重视功能实现忽视安全合规。井下网络和地面办公网没有有效隔离平台服务暴露在矿区局域网但访问控制策略宽松上位机和服务器直接使用默认Administrator口令的案例并不少见。解决开工就把网络安全要求写进技术协议按等保二级或三级取决于系统定位做设计。具体动作所有服务器/上位机改强口令并关闭默认共享数据库绑定内网IP并限制来源启用操作审计日志保留至少6个月远程维护通道走堡垒机不直接映射端口。这条虽然不是业务功能却是验收卡点早做比临期整改省钱得多。5. 从汇报PPT到可验收系统验证方法与一个实用技巧前面四章解决的是“怎么建”最后一章讲“怎么证明建成了”。煤矿信息化项目验收最怕的就是PPT里承诺的功能现场演示时各种理由推脱。我习惯用一套可执行的验证清单把每个承诺变成可操作的动作。5.1 验收前先自己打一遍的验证清单验证清单建议分四类连通性验证每台采集设备能通、数据能入库、正确性验证现场仪表读数与平台读数对比误差在允许范围、联动性验证瓦斯超限→断电→广播→人员定位联动是否触发、稳定性验证连续运行72小时采集无中断、无重复告警。每项验证要有记录截图存档作为验收附件。5.2 用PPT反向驱动实施页面级需求追踪这里有一个实用技巧把汇报PPT当作需求基线来用。实施过程中每周对照PPT逐页核对这一页画的功能当前做到什么程度了哪些是“示意”、哪些是“已实现”把页面编号维护到需求追踪表里状态分为“已实现/部分实现/未开始”。这样做到验收阶段不会出现“PPT上有的功能领导记得但没人做”的尴尬。以我经历过的一个项目为例某矿的PPT里画了“掘进面视频AI违章识别”页面实施团队一直以为那是远期规划结果验收前一周领导要求演示视频接入还没做只能连夜补。后来我都养成习惯方案评审时明确要求甲方在PPT上圈出哪些是本期必须交付的页面哪些是规划页。这个动作成本极低但能避免太多返工。还有一个小习惯验收演示前把演示用的数据提前恢复到一个干净的测试库不要把生产实时数据直接拿来演示。生产数据可能有异常值或断线区间演示时露出一个脏数据点整套系统可信度就打折扣了。煤矿信息化技术说到最后建的不是系统是数据的流转和责任的边界。每一层选型、每一个接口、每一条测点规则都对应着矿上一个具体的部门和岗位。希望这份从PPT到落地的拆解对你有用也希望你项目里那些图上没画的坑都能在实施之前被发现。希望帮到你。本文还有配套的精品资源点击获取 煤矿信息化技术落地：从PPT到井下系统选型与避坑指南
简介煤矿信息化技术专题PPT源自中国矿业大学丁恩杰教授的报告适合煤矿自动化、信息化相关从业者、研究人员及高校学生参考学习使用。内容围绕工业以太网技术、数字化变电所、WI-FI无线通信技术等关键模块展开并引入基于WI-FI的新一代井下救灾监控指挥系统研究课题。其中对工业以太网的概念、现场应用关键技术、Modbus TCP/IP、ProfiNet等协议做了系统讲解有助于把握煤矿井下通信、监控与供电系统的技术要点与选型思路。资源为单一pptx文件共1份大小约3.68MB重点集中便于移动端或电脑端直接查看。目前已有54人学习页面编排以报告提纲呈现层次分明适合作为技术培训、课件制作或方案汇报时的直接参考素材。1. 煤矿信息化技术一张PPT背后的系统选型与落地路径煤矿信息化技术这个概念在很多矿上落地的第一形态其实不是系统而是一份PPT。无论你是要立项汇报、招标技术方案还是给领导讲“智慧矿山”蓝图最后拿出手的都是几十页的pptx。但PPT画得再漂亮井下采掘工作面装了多少传感器、环网链路断了有没有人管、数据采上来是不是真能出报表这些才是煤矿信息化技术值不值得信的关键。这篇文章不打算教你做PPT而是从一份典型的《煤矿信息化技术》汇报材料出发把它拆成可落地的东西架构怎么搭、子系统怎么接、数据怎么管、现场哪些坑容易翻车以及验收前怎么验证。适合正在做矿井信息化方案设计、集成实施或运维的从业者。先立一个反直觉的结论煤矿信息化最大的瓶颈往往不在技术本身而在数据源头和接口协议。2. 从PPT到井下先把信息化架构的四层骨架搭对一份煤矿信息化技术的PPT几乎都会画那张“四层架构”图感知层、传输层、平台层、应用层。这张图人人都能画但真正把它落到井下每一层都有各自的选型逻辑和实施边界。我见过不少项目PPT阶段四层画得很顺畅到了井下验收却层层卡壳原因多半是每一层都掺杂了“想当然”。2.1 感知层井下数据不是想采就能采感知层是煤矿信息化技术的底座包括瓦斯、一氧化碳、温度、风速、粉尘、液位、电流电压、振动、图像等各类传感器。PPT上往往只画一个图标“传感器集群”但现场要回答的问题很具体供电怎么来、信号怎么传、精度够不够、断线了怎么判断、有没有矿用本安或隔爆认证。常见做法是感知层按“环境监测类、设备工况类、视频图像类”三组分别选型。环境监测类传感器瓦斯、一氧化碳、温度等必须接入矿井安全监控系统优先选用有矿用产品安全标志MA标志的设备通信方式以RS485或CAN总线为主少数新设备支持以太网。设备工况类传感器比如皮带秤、振动、电流大部分来自各子系统自带PLC不需要单独布点而是通过子系统接口上送。视频类则单独走工业以太网或视频专网避免和监控分站抢带宽。关键参数需要注意几个传感器量程和精度比如瓦斯传感器量程通常0-4%CH4报警点设置要按煤矿安全规程定不能按说明书默认值输出信号类型4-20mA、RS485 Modbus RTU、数字量开关直接决定采集器选型本安电源的带载能力单路本安电源一般带2-4个传感器总线供电要算总电流否则井下电压降会玄学掉线。很多矿在感知层容易翻车的点是“传感器装上了但没校准”。尤其瓦斯传感器需要定期调校否则数据漂移后平台上看曲线是好的实际值和便携仪差了十万八千里。所以感知层实施时我一般会建议在合同里写明“调校周期和谁负责”否则后期运维全部推到集成商头上。2.2 传输层工业环网与5G专网的取舍传输层最常见的选择有两个矿井工业以太环网和5G专网。PPT上通常写“万兆工业环网5G全覆盖”但井下环网覆盖的是主巷道、采区变电所、主要机电硐室工作面内部往往只有有线网络5G则主要解决移动场景比如掘进机远程控制、巡检机器人、无线视频回传。两者不是替代关系而是按业务需求分区部署。工业环网实施时核心参数是环网自愈时间。一般要求小于50ms实际项目中某矿的环网由12台矿用隔爆型交换机组成用RSTP或MRP协议自愈时间在20-50ms之间都能满足。但如果用了STP生成树协议且没有调优自愈时间可能到秒级自动化系统画面会长时间灰屏这就是常说的“链路断了没人知道知道了也切不过来”。5G专网的取舍要看业务是否真的需要井下5G覆盖成本高、基站数量多井下巷道直线覆盖半径一般300-500米弯道更多、井下防爆改造难度大。如果业务只是调度语音和定位用WiFi6或UWB反而更成熟。5G适合的是远程掘进、无人驾驶辅助这类大带宽低时延场景。另外5G核心网是下沉到矿侧还是上移到集团直接影响时延和数据安全边界这个决策要在方案阶段定不能等设备到货再改。传输层的落地习惯是“先有线后无线、先主干后分支”。环网光缆敷设要避开积水巷段和频繁拉移区域井下交换机要留足备用光口否则新增子系统时又要重新熔接既耽误时间又增加故障点。还有一条血泪经验环网协议要统一不同品牌交换机混用如果不用标准协议环网自愈时可能出现环路风暴直接打挂整个自动化网络。2.3 平台层与应用层一张图、一朵云、一个门户平台层在PPT里经常画成一个“云平台”或者“数据中台”但落地时真正发挥作用的是三个东西实时数据库/时序数据库、GIS一张图、统一门户含报表和告警。应用层则是在这个底座上跑的安全监控、人员定位、应急广播、排水自动化、皮带集控、视频AI等业务系统。平台层的选型原则是“能统一的不单独建”。比如时序数据库如果每个子系统都自带一个库最后数据分散成孤岛报表要登五个系统去手工抄数。常见做法是部署一套工业时序数据库如基于通用开源时序库二次开发的平台把安全监控、人员定位、电力监控、排水、皮带等实时数据统一接入按“测点ID时间戳质量戳”存储。应用层的集成方式比选型更重要。很多矿上了十几个“智慧子系统”每个子系统一套账号、一个IP、一张网页这种“门户堆砌”不算信息化。我一般会按统一身份认证LDAP/OAuth统一待办统一告警来收敛。告警尤其要收敛井下本来的报警就多如果不做去重和分级调度员会被告警轰炸到麻木真正的高值报警反而没人看。这一层的另一个重点是指标口径统一。PPT里很好看的“万吨煤能耗”“设备开机率”这类指标如果底层数据口径不一致比如开机率是按运行时间/日历时间还是按运行时间/计划生产时间不同子系统算出来的结果能差20个百分点。所以平台层上线前要拉上机电、调度、安全各部门把指标定义签字确认这是很多人忽略但后期吵架最多的事。3. 让PPT里的系统真跑起来几个绕不开的落地模块PPT上的架构图、大屏截图、数据流向图都很完整但让系统“真跑起来”通常会卡在三个模块子系统协议对接、GIS一张图的坐标统一、数据治理与指标计算。这三个模块做扎实了煤矿信息化技术才从“展示型”变成“生产型”。3.1 综合自动化子系统集成协议对接的现实做法综合自动化集成是煤矿信息化实施中最耗时的部分。井下子系统品牌杂、年代跨度大协议有Modbus RTU/TCP、OPC DA/UA、S7通信、DL/T 645电表规约甚至还有纯干接点。集成不是“写个接口”那么简单先要盘点每个子系统的接入方式、寄存器表和点位表。我比较常用的做法是分层接入先做一个“接入适配层”每个子系统对应一个采集驱动统一把数据上送到时序数据库。驱动用Python或C#写常见伪代码逻辑如下以Modbus TCP为例import time from pymodbus.client import ModbusTcpClient # 子系统接入配置IP、端口、从站号、轮询周期 client ModbusTcpClient(192.168.1.50, port502, timeout3) if not client.connect(): print(f[{time.time()}] 连接失败: 皮带集控PLC) # 这里要做重连退避不能死循环 else: # 读取保持寄存器从地址0开始读20个寄存器 rr client.read_holding_registers(address0, count20, slave1) if rr.isError(): print(读取异常检查点位表地址) else: # 现场数据往往是16位整数注意大小端和缩放系数 for i, val in enumerate(rr.registers): # 例如电流: 原始值650对应65.0A缩放系数0.1 scaled val * 0.1 tag_id fbelt_1_current_{i} write_to_tsdb(tag_id, scaled, time.time()) client.close()这段代码的逻辑说明先按子系统IP建连超时设3秒避免某个从站无响应时阻塞整条采集链路连接失败不能立刻重试要退避否则多个驱动同时重试会把PLC网络拖垮寄存器地址必须和现场点位表核对大小端字节序和缩放系数是常见错误源。参数方面轮询周期一般设备工况类设为1-5秒环境监测类数据变化慢可以放到10-30秒如果子系统点位很多要分批读取不能一次读几百个寄存器会超过报文长度限制。另一个现实问题是老设备的OPC DA接口。OPC DA基于COM/DCOM跨机器配置DCOM权限很麻烦井下上位机如果是Win7老系统还好新装的Win10/11机器跑OPC DA经常黑匣子式闪断。我的建议是能上OPC UA的就优先OPC UA连不上的用独立的OPC DA转UA网关不要图省事直接在上位机装DA客户端否则后面每次重启都得调DCOM。3.2 一张图与GIS坐标统一是第一步“一张图”是煤矿信息化PPT里最吸睛的部分井上下对照、采掘工程平面图、设备实时状态叠加。但落地时最大的坑不是GIS平台选型而是坐标系统一。煤矿图纸常见的有1954北京坐标系、1980西安坐标系、2000国家大地坐标系还有矿区自定义的独立坐标系。如果一张图要叠加井下测绘数据、地表沉陷数据、钻孔数据坐标系不一致就是灾难。实施时我一般按这套流程走先确定底图坐标系新建项目优先用CGCS2000老矿区如果没有转换参数就沿用原独立坐标系并在平台里标注然后把各来源数据统一转换。具体操作的第一步是拿矿方提供的采掘工程平面图一般是DWG做坐标配准在GIS软件里选控制点至少要选均匀分布的4-6个点不能只在图幅角落选。配准之后还要处理“设备测点坐标如何落到图上”。井下传感器和设备在子系统里的位置往往是文字描述如“南翼皮带机头”没有经纬度或平面坐标。我见过一个项目把井下定位基站坐标搞错了一个数量级结果一张图上的人员位置全跑到地表河流里去了。正确的做法是由矿地测科出具设备安装点的矿图坐标X、Y、Z集成方据此上图而不是依据现场人员口述“大概在哪个硐室”。一张图平台里还要定义图层规范。比如“安全监控测点”图层用红色圆点、“人员定位基站”用蓝色三角、“排水泵”用绿色方块每个图层挂接属性表至少包含设备ID、子系统来源、安装位置、投运日期。这样做的好处是后期做告警联动比如瓦斯超限自动关联周围人员分布时查询效率高也方便运维人员排查。3.3 数据治理与指标口径PPT画得再好也怕脏数据煤矿信息化技术做到后期拼的不是平台功能而是数据质量。脏数据来源主要有几类传感器断线后存的“旧值重复”、PLC停机时的“0值假数据”、网关重启后的“时间戳跳变”、多个系统重复采集导致的“同一测点多值”。我一般会在平台里建三层数据质量规则。第一层是完整性规则比如某个测点连续N分钟没有新数据要生成“数据中断”告警而不是等用户发现第二层是有效性规则比如瓦斯浓度不可能为负瞬时值超过量程上限要标记为“可疑”而不是直接入库展示第三层是稳定性规则比如电流在1秒内从10A跳到200A再跳回多半是采集抖动或信号干扰要用死区滤波或突变抑制处理。这些规则落到实现上可以用流处理任务也可以直接用时序数据库的连续查询。以常见开源时序库为例SQL格式大致是这样-- 对每个测点做突变检测和上一条记录比变化率超过阈值则标记质量戳 SELECT tag_id, timestamp, value, CASE WHEN ABS(value - LAG(value) OVER (PARTITION BY tag_id ORDER BY timestamp)) threshold THEN spike ELSE good END AS quality FROM raw_measurements WHERE timestamp now() - INTERVAL 5 minutes;这段SQL的逻辑说明用窗口函数LAG取同一测点的上一条值差值绝对值超过阈值就标记为“spike”。参数方面threshold按测点类型分别配置电流电压类变化快阈值可以放宽瓦斯等环境参数变化慢阈值要收紧比如超过0.2%CH4/5秒就值得怀疑。质量戳要在展示和应用层做过滤不能只是标记在库里不处理否则大屏上还是会闪一个异常值。指标口径这块最典型的是“设备故障率”。机电科的口径是“故障时间/日历时间”生产科的口径是“故障时间/计划运行时间”两者差多少取决于检修时长。我的做法是建一个“指标字典”每个指标写清楚公式、数据来源、更新频率、责任部门评审通过后作为系统配置写死任何部门要改口径都要走变更流程。这听起来笨但能避免验收后三天两头为了报表数字吵架。4. 煤矿信息化避坑指南PPT上没写的五个现场问题煤矿信息化技术的PPT不会写这些但它们决定了系统能不能稳定用下去。以下五条都是现场高频踩坑点按“现象→原因→解决”展开几乎每个矿都会遇到至少两条。4.1 现象环网断链后自动化画面全灰现象某矿综合自动化系统运行正常某天井下一条巷道的光缆被拉断按说环网应该自动切换到备用路径但调度中心的大屏上所有相关画面全部变灰持续了好几分钟才恢复。原因交换机虽然组了环但使用的生成树协议没有开启快速收敛或协议不一致默认的STP收敛时间是30-50秒加上参数老化时间和上层平台的重连时间用户体验就是“断链几分钟没人管”。另外部分交换机默认启用了环路保护断链后把端口阻塞了反而切不回来。解决统一使用RSTP或MRP协议并开启快速迁移。万兆骨干环建议用MRP收敛时间能做到20ms级分支环用RSTP也能做到秒级以下。实施时把“环网自愈时间”写进测试项验收时专门做一次人为断纤测试拿秒表计时不达标不签字。4.2 现象GIS一张图坐标对不上测点飘到地面现象一张图平台部署完成后安全监控测点叠加到底图上瓦斯传感器位置显示在巷道外面甚至地表人员定位轨迹横穿煤柱完全不符合实际。原因两个来源的数据用了不同坐标系叠加井下定位基站坐标未经过地测科核准用了施工方的手持GPS粗采数据误差达几十米还有DWG图纸配准控制点选得太少底图本身就已经扭曲。解决统一坐标系优先CGCS2000所有上图数据必须附带“坐标系采集方法责任人”元数据基站和传感器坐标由矿地测科正式出具不用施工队手持设备数据DWG配准至少选4-6个均匀控制点配准后抽查已知点误差超过图上0.5m就要返工。4.3 现象数据采集到了但时序数据库磁盘暴涨现象平台上线一个月后时序数据库所在磁盘从30%涨到95%查询变慢甚至导致采集服务写不进去。排查发现大量测点每秒钟写入一次但很多数据是不需要秒级存储的。原因采集驱动配置时把所有测点都设成了1秒轮询和1秒存储忽略了数据分层。比如环境监测数据5秒变化一次没必要每秒存设备工况数据平时稳定秒级存储只在故障诊断时有价值。解决实行“采集频率和存储频率分离”。采集可以1秒存储按测点类型设置死区变化超过死区才写库否则沿用旧值或完全不写查询时用最后值填充。实际项目里环境类测点存储周期设为5-10秒工况类稳定测点设3-5秒死区磁盘占用能下降70%以上历史数据完整度不受影响。4.4 现象OPC UA打通了但画面刷新慢现象某皮带集控子系统通过OPC UA接入综合自动化平台数据能读到但组态画面上数值刷新延迟5-10秒操作指令下发反应也慢。原因OPC UA订阅参数没调。服务器端采样间隔设成了1秒但发布间隔PublishingInterval默认可能设成了1秒或更大客户端订阅队列长度太小数据变化快时丢弃另外会话数太多也会拖慢服务器响应。解决把OPC UA服务器发布间隔设为100-200ms采样间隔保持100ms客户端Session超时设长一些避免频繁断连重建订阅队列长度至少设为服务器节点数的2倍。还有一点容易被忽略不要用同一个OPC UA连接同时订阅几百个节点按子系统拆成多个订阅避免单连接负载过高。4.5 现象信息安全等保测评不通过现象矿业集团统一做网络安全等级保护测评某矿信息化平台被查出大量问题主机默认口令未改、数据库任意IP可访问、审计日志未启用、通信未加密。整改周期紧张影响验收。原因项目实施时重视功能实现忽视安全合规。井下网络和地面办公网没有有效隔离平台服务暴露在矿区局域网但访问控制策略宽松上位机和服务器直接使用默认Administrator口令的案例并不少见。解决开工就把网络安全要求写进技术协议按等保二级或三级取决于系统定位做设计。具体动作所有服务器/上位机改强口令并关闭默认共享数据库绑定内网IP并限制来源启用操作审计日志保留至少6个月远程维护通道走堡垒机不直接映射端口。这条虽然不是业务功能却是验收卡点早做比临期整改省钱得多。5. 从汇报PPT到可验收系统验证方法与一个实用技巧前面四章解决的是“怎么建”最后一章讲“怎么证明建成了”。煤矿信息化项目验收最怕的就是PPT里承诺的功能现场演示时各种理由推脱。我习惯用一套可执行的验证清单把每个承诺变成可操作的动作。5.1 验收前先自己打一遍的验证清单验证清单建议分四类连通性验证每台采集设备能通、数据能入库、正确性验证现场仪表读数与平台读数对比误差在允许范围、联动性验证瓦斯超限→断电→广播→人员定位联动是否触发、稳定性验证连续运行72小时采集无中断、无重复告警。每项验证要有记录截图存档作为验收附件。5.2 用PPT反向驱动实施页面级需求追踪这里有一个实用技巧把汇报PPT当作需求基线来用。实施过程中每周对照PPT逐页核对这一页画的功能当前做到什么程度了哪些是“示意”、哪些是“已实现”把页面编号维护到需求追踪表里状态分为“已实现/部分实现/未开始”。这样做到验收阶段不会出现“PPT上有的功能领导记得但没人做”的尴尬。以我经历过的一个项目为例某矿的PPT里画了“掘进面视频AI违章识别”页面实施团队一直以为那是远期规划结果验收前一周领导要求演示视频接入还没做只能连夜补。后来我都养成习惯方案评审时明确要求甲方在PPT上圈出哪些是本期必须交付的页面哪些是规划页。这个动作成本极低但能避免太多返工。还有一个小习惯验收演示前把演示用的数据提前恢复到一个干净的测试库不要把生产实时数据直接拿来演示。生产数据可能有异常值或断线区间演示时露出一个脏数据点整套系统可信度就打折扣了。煤矿信息化技术说到最后建的不是系统是数据的流转和责任的边界。每一层选型、每一个接口、每一条测点规则都对应着矿上一个具体的部门和岗位。希望这份从PPT到落地的拆解对你有用也希望你项目里那些图上没画的坑都能在实施之前被发现。希望帮到你。本文还有配套的精品资源点击获取