简介煤矿信息化技术专题讲座PPT出自中国矿业大学丁恩杰教授的报告面向煤矿信息化建设人员、自动化与通信工程师以及矿业类院校师生。内容围绕工业以太网、数字化变电所、Wi-Fi无线通信及基于Wi-Fi的新一代井下救灾监控指挥系统等课题展开重点剖析工业以太网在煤矿现场应用中的通信实时性、可靠性、安全性、总线供电及主流协议选型帮助读者理解煤矿井下特殊环境对网络设备的防爆与抗干扰要求。资源共1个pptx文件压缩包大小3.68MB文件为可编辑的演示文稿便于按章节阅读、筛选和二次整理。已有51人学习浏览。PPT结构清晰包含概念讲解、关键技术对比和应用方案既可作为煤矿智能化、信息化培训课件也可用于相关专业课程教学或技术汇报素材。1. 煤矿信息化技术的真正门槛稳定采数比华丽平台更迫切煤矿信息化建设的常规路径是先把传感器布下去把井下环网和设备数据接入地面控制中心再在中心做监测平台和数据展示。多数矿走到中间就开始遇到麻烦甲烷监测曲线会在某些时段变成一段段缺口顶板压力传感器的数据突然跳变视频画面频繁卡顿让人分不清是网的问题还是设备的问题。煤矿井下环境对电子设备的损耗、对传输链路的腐蚀以及电磁干扰对RS485总线的冲击都远比地面机房严重。信息化平台哪怕做得再漂亮只要数据采集成功率低于98%值班人员就会丧失对系统的信任最后退回人工记录。煤矿信息化技术的核心不是算法或大屏而是把数据从井下稳定地送到地面。这篇文章按“架构选型、链路配置、数据落地、系统验证”的顺序把项目里最常踩的几个坑和对应处理参数逐一列出适合负责煤矿智能化改造的IT工程师、系统集成商和矿端信息化管理员阅读。2. 煤矿信息化技术架构怎么选感知、传输、平台三层的取舍煤矿信息化项目一做起来企业很容易往大平台方向走但实际动手之后会发现平台能承载多少数据不是瓶颈感知设备的稳定性和传输链路的可用性才是。架构设计上我习惯先按“感知—传输—平台—应用”四个环节拆但真正决定成败的是前两层。选型不是看拓扑图画得有多完整而是看每一层在最恶劣的工况下能不能撑住以及出了问题能不能快速定位。2.1 感知层矿用传感器的接入方式先做减法井下感知设备种类多接口不统一是信息化改造的第一道坎。常见数据源包括甲烷传感器、一氧化碳传感器、风速传感器、风筒开关量、顶板位移计、锚杆应力计、矿用水压计、皮带电机温度和振动传感器。它们大部分走RS485总线少数新的走以太网或Profibus个别老设备只有4-20mA模拟量输出。接入时我先按下面几个参数做筛选参数项建议值/做法原因防护等级不低于IP66井下粉尘和水淋低防护等级设备几周内就会故障通讯方式RS485/Modbus RTU优先兼容老设备Modbus开放程度最高好接入自建平台供电方式本安电源优先其次双路冗余本安是安全前提双路供电防止停电断采量程冗余最大量程覆盖实际工况1.2~1.5倍甲烷量程0-4%实际浓度通常低于1%留量程防止数据截断校准周期每7~15天校准一次矿端执行周期多为7-10天超期数据不建议直接参与预警选型时有一个容易忽略的问题RS485总线上可以挂多台设备但同一总线的轮询时间会随着设备数量线性增长。假设单台设备响应时间200ms一条总线上挂10台设备完整轮询就需要2秒。如果这批数据要参与联动控制这个响应时间必须核算。我在设计接入时会控制每条RS485总线的设备数量在8台以内或者按采集频率需求拆成多条总线。再往下是协议封闭的问题。市面上大部分矿用传感器的通讯协议是公开的但个别品牌为了保护其采集器市场协议不公开或不完整。常见做法是先用品牌的专用采集器把数据采下来再由采集器以Modbus TCP或OPC UA向上开放。这会多一层硬件但比逆向协议稳定得多。2.2 传输层环网、无线和辅助链路怎么选传输层是煤矿信息化项目中改动成本最高的一层因为它和巷道布局、采掘进度绑在一起。主干链路一般用矿用光缆沿巷道形成环网。选择单环还是双环第一取决于链路重要性第二取决于光缆造价。单环是经济方案链路断了断点两侧的节点通过协议协商重构路径但一旦汇聚设备故障可能会有一段5-10分钟的网络不可用对瓦斯监测专线这种业务来说不可接受。双环则每个关键节点都有两条物理链路主链路故障时切换通常在百毫秒级造价约为单环的1.5-2倍。无线部分需要注意井下巷道狭长且弯曲普通WiFi蜂窝漫游会遇到两个问题一是老旧AP的切换延迟在300ms以上对视频会话造成卡顿二是无线信号在拐角处损耗剧烈巷道直角转弯必须额外增补天线或漏泄电缆。做井下无线覆盖时我常用这样的估算方法巷道按500米一段切分每段做一次无线勘测基站间距按200-400米部署。带宽评估则以视频上行码流为主一路1080p实时码流大约需要3-5Mbps一个采面按五路视频计算就是15-25Mbps的上行负载无线回传带宽要按这个方向设计。2.3 平台层数据先本地落库再上送煤矿信息化平台建设行业里已经从“建大平台”转向“边缘侧先落地”。矿端数据采集后先进入本地时序数据库原因是井下网络抖动非常普遍如果数据直接被推到几公里外的集团中心一旦链路闪断几十秒的数据就会丢。更稳妥的做法是矿端网关缓存全部数据再按时间顺序向中心同步同步由中心主动拉取或由矿端网关定时补传。平台层选型看三个关键能力断点缓存时长、协议适配器数量、回放补传性能。缓存至少保留7天原始数据协议适配至少要能覆盖矿里现有的Modbus RTU、Modbus TCP、OPC UA、DL/T645电表协议回传要支持按时间戳自动追平缺口。这些能力比API文档华丽与否重要得多。3. 煤矿信息化技术的井下链路配置ERPS、VLAN 与光功率巡检链路配置是煤矿信息化项目里最容易被低估的部分。井下环网不像办公网络巷道里不会有人蹲在设备旁边盯着指示灯一切都得提前配置好让故障自愈。这一章把三个具体的配置动作拆开讲环网收敛协议怎么选、VLAN和IP如何划分、光链路如何通过巡检提前发现劣化。3.1 环网收敛为什么优先启用ERPS而不是RSTP井下主干环网的收敛时间直接决定业务中断时长。RSTP802.1w是目前矿用环网交换机的标配但它的收敛时间通常在1-3秒对视频业务来说不可见但工业采集和人员定位这类低延迟业务已经能感到明显卡顿。更优的选择是ERPSG.8032收敛时间可以做到50ms以内。前提是环上所有交换机都支持ERPS并且统一使用同一个环实例。以下是一个ERPS配置的通用思路具体命令以设备厂商手册为准# 环网节点上的ERPS配置示例 interface GigabitEthernet0/1 erps ring 1 role owner # Owner节点负责环网开断逻辑 erps ring 1 port primary # 指定主环端口 interface GigabitEthernet0/2 erps ring 1 port secondary # 指定次环端口 erps ring 1 enable逻辑说明owner节点是环网的主控节点它定期从两个方向发送故障检测帧。正常时owner阻塞自己的次环端口形成逻辑断点避免回环风暴。当任一方向检测不到对端帧时owner判定链路断裂立即放开阻塞端口通信路径在环的另一侧重建。环上其它节点只需要加入同一个环编号并配置为普通节点角色。ERPS和RSTP不能混跑启用ERPS前要把该环对应VLAN的STP先关闭否则两种协议会互相干扰。如果设备不支持ERPS退而求其次采用MSTP多实例生成树按业务划分不同实例让不同VLAN走不同路径也可以把部分业务的中断时间控制在300ms以内。但不要在RSTP模式下使用默认配置直接上线默认的STP收敛加上端口迁移延迟在某些老设备上可能达到30秒以上这在煤矿安全监控场景里是不可接受的。3.2 VLAN隔离与IP网段规划的一个可用模板井下环网上同时跑着传感器数据、视频流、人员定位和办公网络如果不做隔离广播风暴和突发流量会直接影响采集数据的时序稳定性。我常用的VLAN划分方式如下业务类型VLAN网段802.1p优先级工业采集实时性最高10010.10.10.0/246人员定位20010.10.20.0/245视频监控30010.10.30.0/244办公及管理网40010.10.40.0/242网段划分的原则是让每个业务广播域足够小避免一个摄像头的中断请求影响整个网络。交换机端口配置上传感器和分站接入端口设为access模式并划入VLAN 100环网链路设trunk并放行所有业务VLAN。配置片段如下vlan 100 name industrial-data vlan 200 name personnel-location interface GigabitEthernet0/10 switchport mode access switchport access vlan 100 spanning-tree bpdufilter enable # 接终端设备的端口不参与STP计算参数说明接入终端设备的端口开启BPDU过滤原因是井下作业面经常有临时的调试终端接入如果这个设备向外发送BPDU有可能改变整环的STP拓扑。把这类单向不稳定因素挡在边缘端口之外是降低故障面的常见做法。同时在环网链路的trunk端口上设置上行带宽保证让VLAN 100的流量优先转发保证传感器数据在环网拥塞时不因视频占用带宽而丢弃。3.3 用SNMP读光模块功率提前发现劣化链路井下光缆故障可以分成两类一类是瞬间断裂另一类是缓慢劣化。缓慢劣化通常由粉尘污染、接头松动、尾纤弯曲过度引起光模块的接收光功率会连续下降直到低于接收灵敏度后产生误码和闪断。这个过程往往持续几周通过定期的光功率巡检完全可以在故障前发现。通用做法是通过SNMP协议读取交换机光口的DDM信息下面是读取光功率值的一条命令snmpwalk -v2c -c public 192.168.10.1 1.3.6.1.4.1.9.9.91.1.1.1.1.4参数说明-c public是交换机SNMP只读社区字符串192.168.10.1是环网交换机的管理IP最后面的OID是实体传感器表中读取传感器数值的节点。输出中会包含光模块的当前温度、发送功率、接收功率等数值。部分厂商OID不同先跑一次完整的SNMP walk把整个MIB树拉下来过滤关键字Rx Power或Temperature即可定位到对应节点。对煤矿场景我建议建立一张光功率基线表每次巡检后记录差值状态接收光功率变化处理动作正常波动小于1dBm记录即可预警连续两次下降超过2dBm安排清洁接头、检查尾纤弯曲半径故障低于设备接收灵敏度阈值立即更换尾纤或重新熔接注意不同光模块的接收灵敏度差异很大矿用千兆模块的典型灵敏度在-20dBm左右但具体以设备手册为准。巡检周期按每两周一次即可重点巡检井下变电所、采区皮带巷等振动较大的区域。4. 煤矿信息化技术的数据采集与预警规则落地网络通了数据能传回来接下来就是采集程序和预警规则的工程实现。这一层的特点是协议杂、格式乱、设备时常离线处理不好会让后台曲线变成“心电图”。我按“采集代码、数据存储、预警规则”三个步骤来说。4.1 一个能跑的Modbus RTU采集最小框架井下瓦斯、一氧化碳、风速等传感器大多走RS485总线上的Modbus RTU协议。用一个Python小脚本就可以完成基础采集以minimalmodbus库为例import minimalmodbus import time instrument minimalmodbus.Instrument(/dev/ttyUSB0, 1) instrument.serial.baudrate 9600 instrument.serial.bytesize 8 instrument.serial.parity N instrument.serial.stopbits 1 instrument.serial.timeout 2 def read_gas_and_wind(): gas instrument.read_register(0, 2) # 寄存器0甲烷浓度保留2位小数 wind instrument.read_register(2, 1) # 寄存器2风速保留1位小数 return gas, wind while True: try: gas, wind read_gas_and_wind() print(fCH4{gas}% Wind{wind} m/s) time.sleep(5) except Exception as e: print(read failed:, e) time.sleep(10) # 失败时延长等待避免频繁占线逻辑说明Instrument(/dev/ttyUSB0, 1)中第二个参数1是RS485总线上从站设备的地址需要和设备上的拨码开关一致。read_register(0, 2)的第一个参数是寄存器地址第二个参数是小数位数具体数值要查传感器的协议映射表不同厂商的寄存器地址完全不通用。超时设置为2秒轮询间隔5秒一条总线上多台设备时会自动串行处理。异常后等待10秒再重试防止设备通讯不稳定时持续占用总线造成其它设备轮询周期被拉长。实际项目中这只是最简框架。除了数值本身还要采集质量标志和在线状态很多传感器支持读取设备状态寄存器返回正常、故障、校准、离线四种状态。把状态寄存器一起读回来落库时给每个数值加一个quality字段是避免误报的关键前置动作。4.2 数据落库用带标签的时序超表替代传统关系表井下数据是天然的时序数据用传统MySQL按行写入也能跑但查询“某台设备某段时间的曲线”时随着数据量增大性能会急剧下降。时序数据库是更稳妥的选型国内矿业项目使用TDengine较多原因之一是它支持SQL建表学习成本低。以下是一个建表SQL示例CREATE STABLE sensor_data ( ts TIMESTAMP, value DOUBLE, quality INT ) TAGS (device_id NCHAR(20), point_type NCHAR(20)); INSERT INTO sensor_data USING sensor_data TAGS (gas01, CH4) VALUES (NOW, 0.65, 1);参数说明STABLE是超级表相当于按标签分类的模板device_id和point_type是标签查询时能按设备编号和测点类型快速过滤。value存数值quality存质量码1表示有效0表示无效采集异常时不要给曲线补零。插入语句通过USING自动创建子表每台设备对应一张子表物理存储按标签聚簇查询一个月的数据只需要扫描对应子表的数据块耗时在毫秒级。这里还有一个非常现实的坑设备时钟漂移。井下很多传感器长期运行后时钟偏差达到数分钟直接使用设备上报时间会造成曲线乱序。我在采集网关层把设备上报的原始时间保存在raw_ts字段另加一个ts字段采用网关收到数据时的服务器时间。这个策略简单可靠既能保证曲线时间轴连续又保留了排查设备时钟问题的原始记录。4.3 预警规则分层阈值、趋势与连续帧确认预警规则是煤矿信息化系统里和安全生产绑得最紧的部分。规则本身不复杂但误报和漏报都会消耗值班人员的信任。常见的做法是把预警分三层硬阈值层、趋势层、联动层。硬阈值层最直接甲烷浓度超过0.8%报警这个标准各矿要求不同趋势层看短时间内的变化斜率用于发现缓慢积聚联动层则结合多个测点做综合判断例如回风巷甲烷浓度上升的同时风速下降会自动关联为“异常通风状态”。写趋势预警时我处理过的问题代码大多败在“只看最新一个点”上。传感器偶发的电磁干扰会让单一数据点偏高如果立即报警就是典型的误报。正确做法是加一个连续帧确认机制def trend_alert(values, threshold0.3): if len(values) 5: return False window_avg sum(values[:4]) / 4 return (values[-1] - window_avg threshold and values[-2] window_avg) # 连续两帧增长才触发参数说明threshold是增长阈值表示最新值与最近4帧均值的差值超过0.3%时才认为异常values[-2] window_avg要求倒数第二帧已经高于均值用连续两帧确认排除单点尖峰。这个写法不复杂但对抑制粉尘干扰、电流浪涌这类瞬时噪声非常有效。联动规则不建议让每个测点独立触发而是在预警引擎里建立“测点-区域”的映射关系把同一段巷道的甲烷、风速、温度传感器归为一组。当组内任意两个测点同时出现正向趋势时才把区域状态置为“重点监视”。这一层逻辑可以用简单的规则引擎也可以直接写成Python脚本关键是要控制误报率让系统报警一次就值得下井核实一次。5. 项目交付前怎么验证和汇报三条实用经验系统联调完成到正式验收之间有几个动作虽然不产生代码但能把工程质量拉高一个档次。这些动作是拔纤测试、传感器交叉复核和指标归拢。5.1 拔纤测试验证链路切换时间不是靠感觉环网验收时很多人默认“断了一根线应该没事”但实际切换表现必须实测。找个生产检修窗口把环网中段的一根光纤拔掉同时让值班室看监控画面和采集时间戳用秒表记录从拔纤到业务恢复的时间。ERPS环网下这个值应当小于100msRSTP下应在3秒以内。测试后保留时间戳日志标注恢复时间和对应的环网设备端口号。这样后续每次升级网络配置都能对比同一组数据判断切换性能是否退化。5.2 传感器交叉复核误差控制在0.1%以内数据质量不能只看平台曲线连续性还要用便携式仪表做现场比对。抽查几个重点测点把标准仪器的读数与监控系统的实时值写在一张表上逐项计算偏差。甲烷传感器的偏差通常要求控制在读数的正负0.1%以内风速传感器偏差控制在正负0.2m/s以内。发现偏差超限先看传感器是否到了校准周期再检查采集程序里的小数位配置是否正确。这一项测试记录要保留到项目验收材料中因为它是数据准确性的直接证据。5.3 汇报时按四个指标排序而不是堆功能截图向矿方管理层汇报煤矿信息化项目效果时多讲业务连续性指标少讲大屏画面和列表功能。我习惯用这组指标排序数据采集率、链路在线率、预警准确率、故障恢复时间。每个指标附一个真实数值和一个典型实例整个汇报只需四张图但每张图都经得起追问。比如“链路在线率99.5%”对应的就是拔纤测试的记录和光功率巡检的基线表。这种输出方式让信息化项目从“做了多少功能”变成“业务连续性达到什么水平”对后续运维预算申请也更有说服力。本文还有配套的精品资源点击获取 煤矿信息化技术：从稳定采数到链路优化的工程实践
简介煤矿信息化技术专题讲座PPT出自中国矿业大学丁恩杰教授的报告面向煤矿信息化建设人员、自动化与通信工程师以及矿业类院校师生。内容围绕工业以太网、数字化变电所、Wi-Fi无线通信及基于Wi-Fi的新一代井下救灾监控指挥系统等课题展开重点剖析工业以太网在煤矿现场应用中的通信实时性、可靠性、安全性、总线供电及主流协议选型帮助读者理解煤矿井下特殊环境对网络设备的防爆与抗干扰要求。资源共1个pptx文件压缩包大小3.68MB文件为可编辑的演示文稿便于按章节阅读、筛选和二次整理。已有51人学习浏览。PPT结构清晰包含概念讲解、关键技术对比和应用方案既可作为煤矿智能化、信息化培训课件也可用于相关专业课程教学或技术汇报素材。1. 煤矿信息化技术的真正门槛稳定采数比华丽平台更迫切煤矿信息化建设的常规路径是先把传感器布下去把井下环网和设备数据接入地面控制中心再在中心做监测平台和数据展示。多数矿走到中间就开始遇到麻烦甲烷监测曲线会在某些时段变成一段段缺口顶板压力传感器的数据突然跳变视频画面频繁卡顿让人分不清是网的问题还是设备的问题。煤矿井下环境对电子设备的损耗、对传输链路的腐蚀以及电磁干扰对RS485总线的冲击都远比地面机房严重。信息化平台哪怕做得再漂亮只要数据采集成功率低于98%值班人员就会丧失对系统的信任最后退回人工记录。煤矿信息化技术的核心不是算法或大屏而是把数据从井下稳定地送到地面。这篇文章按“架构选型、链路配置、数据落地、系统验证”的顺序把项目里最常踩的几个坑和对应处理参数逐一列出适合负责煤矿智能化改造的IT工程师、系统集成商和矿端信息化管理员阅读。2. 煤矿信息化技术架构怎么选感知、传输、平台三层的取舍煤矿信息化项目一做起来企业很容易往大平台方向走但实际动手之后会发现平台能承载多少数据不是瓶颈感知设备的稳定性和传输链路的可用性才是。架构设计上我习惯先按“感知—传输—平台—应用”四个环节拆但真正决定成败的是前两层。选型不是看拓扑图画得有多完整而是看每一层在最恶劣的工况下能不能撑住以及出了问题能不能快速定位。2.1 感知层矿用传感器的接入方式先做减法井下感知设备种类多接口不统一是信息化改造的第一道坎。常见数据源包括甲烷传感器、一氧化碳传感器、风速传感器、风筒开关量、顶板位移计、锚杆应力计、矿用水压计、皮带电机温度和振动传感器。它们大部分走RS485总线少数新的走以太网或Profibus个别老设备只有4-20mA模拟量输出。接入时我先按下面几个参数做筛选参数项建议值/做法原因防护等级不低于IP66井下粉尘和水淋低防护等级设备几周内就会故障通讯方式RS485/Modbus RTU优先兼容老设备Modbus开放程度最高好接入自建平台供电方式本安电源优先其次双路冗余本安是安全前提双路供电防止停电断采量程冗余最大量程覆盖实际工况1.2~1.5倍甲烷量程0-4%实际浓度通常低于1%留量程防止数据截断校准周期每7~15天校准一次矿端执行周期多为7-10天超期数据不建议直接参与预警选型时有一个容易忽略的问题RS485总线上可以挂多台设备但同一总线的轮询时间会随着设备数量线性增长。假设单台设备响应时间200ms一条总线上挂10台设备完整轮询就需要2秒。如果这批数据要参与联动控制这个响应时间必须核算。我在设计接入时会控制每条RS485总线的设备数量在8台以内或者按采集频率需求拆成多条总线。再往下是协议封闭的问题。市面上大部分矿用传感器的通讯协议是公开的但个别品牌为了保护其采集器市场协议不公开或不完整。常见做法是先用品牌的专用采集器把数据采下来再由采集器以Modbus TCP或OPC UA向上开放。这会多一层硬件但比逆向协议稳定得多。2.2 传输层环网、无线和辅助链路怎么选传输层是煤矿信息化项目中改动成本最高的一层因为它和巷道布局、采掘进度绑在一起。主干链路一般用矿用光缆沿巷道形成环网。选择单环还是双环第一取决于链路重要性第二取决于光缆造价。单环是经济方案链路断了断点两侧的节点通过协议协商重构路径但一旦汇聚设备故障可能会有一段5-10分钟的网络不可用对瓦斯监测专线这种业务来说不可接受。双环则每个关键节点都有两条物理链路主链路故障时切换通常在百毫秒级造价约为单环的1.5-2倍。无线部分需要注意井下巷道狭长且弯曲普通WiFi蜂窝漫游会遇到两个问题一是老旧AP的切换延迟在300ms以上对视频会话造成卡顿二是无线信号在拐角处损耗剧烈巷道直角转弯必须额外增补天线或漏泄电缆。做井下无线覆盖时我常用这样的估算方法巷道按500米一段切分每段做一次无线勘测基站间距按200-400米部署。带宽评估则以视频上行码流为主一路1080p实时码流大约需要3-5Mbps一个采面按五路视频计算就是15-25Mbps的上行负载无线回传带宽要按这个方向设计。2.3 平台层数据先本地落库再上送煤矿信息化平台建设行业里已经从“建大平台”转向“边缘侧先落地”。矿端数据采集后先进入本地时序数据库原因是井下网络抖动非常普遍如果数据直接被推到几公里外的集团中心一旦链路闪断几十秒的数据就会丢。更稳妥的做法是矿端网关缓存全部数据再按时间顺序向中心同步同步由中心主动拉取或由矿端网关定时补传。平台层选型看三个关键能力断点缓存时长、协议适配器数量、回放补传性能。缓存至少保留7天原始数据协议适配至少要能覆盖矿里现有的Modbus RTU、Modbus TCP、OPC UA、DL/T645电表协议回传要支持按时间戳自动追平缺口。这些能力比API文档华丽与否重要得多。3. 煤矿信息化技术的井下链路配置ERPS、VLAN 与光功率巡检链路配置是煤矿信息化项目里最容易被低估的部分。井下环网不像办公网络巷道里不会有人蹲在设备旁边盯着指示灯一切都得提前配置好让故障自愈。这一章把三个具体的配置动作拆开讲环网收敛协议怎么选、VLAN和IP如何划分、光链路如何通过巡检提前发现劣化。3.1 环网收敛为什么优先启用ERPS而不是RSTP井下主干环网的收敛时间直接决定业务中断时长。RSTP802.1w是目前矿用环网交换机的标配但它的收敛时间通常在1-3秒对视频业务来说不可见但工业采集和人员定位这类低延迟业务已经能感到明显卡顿。更优的选择是ERPSG.8032收敛时间可以做到50ms以内。前提是环上所有交换机都支持ERPS并且统一使用同一个环实例。以下是一个ERPS配置的通用思路具体命令以设备厂商手册为准# 环网节点上的ERPS配置示例 interface GigabitEthernet0/1 erps ring 1 role owner # Owner节点负责环网开断逻辑 erps ring 1 port primary # 指定主环端口 interface GigabitEthernet0/2 erps ring 1 port secondary # 指定次环端口 erps ring 1 enable逻辑说明owner节点是环网的主控节点它定期从两个方向发送故障检测帧。正常时owner阻塞自己的次环端口形成逻辑断点避免回环风暴。当任一方向检测不到对端帧时owner判定链路断裂立即放开阻塞端口通信路径在环的另一侧重建。环上其它节点只需要加入同一个环编号并配置为普通节点角色。ERPS和RSTP不能混跑启用ERPS前要把该环对应VLAN的STP先关闭否则两种协议会互相干扰。如果设备不支持ERPS退而求其次采用MSTP多实例生成树按业务划分不同实例让不同VLAN走不同路径也可以把部分业务的中断时间控制在300ms以内。但不要在RSTP模式下使用默认配置直接上线默认的STP收敛加上端口迁移延迟在某些老设备上可能达到30秒以上这在煤矿安全监控场景里是不可接受的。3.2 VLAN隔离与IP网段规划的一个可用模板井下环网上同时跑着传感器数据、视频流、人员定位和办公网络如果不做隔离广播风暴和突发流量会直接影响采集数据的时序稳定性。我常用的VLAN划分方式如下业务类型VLAN网段802.1p优先级工业采集实时性最高10010.10.10.0/246人员定位20010.10.20.0/245视频监控30010.10.30.0/244办公及管理网40010.10.40.0/242网段划分的原则是让每个业务广播域足够小避免一个摄像头的中断请求影响整个网络。交换机端口配置上传感器和分站接入端口设为access模式并划入VLAN 100环网链路设trunk并放行所有业务VLAN。配置片段如下vlan 100 name industrial-data vlan 200 name personnel-location interface GigabitEthernet0/10 switchport mode access switchport access vlan 100 spanning-tree bpdufilter enable # 接终端设备的端口不参与STP计算参数说明接入终端设备的端口开启BPDU过滤原因是井下作业面经常有临时的调试终端接入如果这个设备向外发送BPDU有可能改变整环的STP拓扑。把这类单向不稳定因素挡在边缘端口之外是降低故障面的常见做法。同时在环网链路的trunk端口上设置上行带宽保证让VLAN 100的流量优先转发保证传感器数据在环网拥塞时不因视频占用带宽而丢弃。3.3 用SNMP读光模块功率提前发现劣化链路井下光缆故障可以分成两类一类是瞬间断裂另一类是缓慢劣化。缓慢劣化通常由粉尘污染、接头松动、尾纤弯曲过度引起光模块的接收光功率会连续下降直到低于接收灵敏度后产生误码和闪断。这个过程往往持续几周通过定期的光功率巡检完全可以在故障前发现。通用做法是通过SNMP协议读取交换机光口的DDM信息下面是读取光功率值的一条命令snmpwalk -v2c -c public 192.168.10.1 1.3.6.1.4.1.9.9.91.1.1.1.1.4参数说明-c public是交换机SNMP只读社区字符串192.168.10.1是环网交换机的管理IP最后面的OID是实体传感器表中读取传感器数值的节点。输出中会包含光模块的当前温度、发送功率、接收功率等数值。部分厂商OID不同先跑一次完整的SNMP walk把整个MIB树拉下来过滤关键字Rx Power或Temperature即可定位到对应节点。对煤矿场景我建议建立一张光功率基线表每次巡检后记录差值状态接收光功率变化处理动作正常波动小于1dBm记录即可预警连续两次下降超过2dBm安排清洁接头、检查尾纤弯曲半径故障低于设备接收灵敏度阈值立即更换尾纤或重新熔接注意不同光模块的接收灵敏度差异很大矿用千兆模块的典型灵敏度在-20dBm左右但具体以设备手册为准。巡检周期按每两周一次即可重点巡检井下变电所、采区皮带巷等振动较大的区域。4. 煤矿信息化技术的数据采集与预警规则落地网络通了数据能传回来接下来就是采集程序和预警规则的工程实现。这一层的特点是协议杂、格式乱、设备时常离线处理不好会让后台曲线变成“心电图”。我按“采集代码、数据存储、预警规则”三个步骤来说。4.1 一个能跑的Modbus RTU采集最小框架井下瓦斯、一氧化碳、风速等传感器大多走RS485总线上的Modbus RTU协议。用一个Python小脚本就可以完成基础采集以minimalmodbus库为例import minimalmodbus import time instrument minimalmodbus.Instrument(/dev/ttyUSB0, 1) instrument.serial.baudrate 9600 instrument.serial.bytesize 8 instrument.serial.parity N instrument.serial.stopbits 1 instrument.serial.timeout 2 def read_gas_and_wind(): gas instrument.read_register(0, 2) # 寄存器0甲烷浓度保留2位小数 wind instrument.read_register(2, 1) # 寄存器2风速保留1位小数 return gas, wind while True: try: gas, wind read_gas_and_wind() print(fCH4{gas}% Wind{wind} m/s) time.sleep(5) except Exception as e: print(read failed:, e) time.sleep(10) # 失败时延长等待避免频繁占线逻辑说明Instrument(/dev/ttyUSB0, 1)中第二个参数1是RS485总线上从站设备的地址需要和设备上的拨码开关一致。read_register(0, 2)的第一个参数是寄存器地址第二个参数是小数位数具体数值要查传感器的协议映射表不同厂商的寄存器地址完全不通用。超时设置为2秒轮询间隔5秒一条总线上多台设备时会自动串行处理。异常后等待10秒再重试防止设备通讯不稳定时持续占用总线造成其它设备轮询周期被拉长。实际项目中这只是最简框架。除了数值本身还要采集质量标志和在线状态很多传感器支持读取设备状态寄存器返回正常、故障、校准、离线四种状态。把状态寄存器一起读回来落库时给每个数值加一个quality字段是避免误报的关键前置动作。4.2 数据落库用带标签的时序超表替代传统关系表井下数据是天然的时序数据用传统MySQL按行写入也能跑但查询“某台设备某段时间的曲线”时随着数据量增大性能会急剧下降。时序数据库是更稳妥的选型国内矿业项目使用TDengine较多原因之一是它支持SQL建表学习成本低。以下是一个建表SQL示例CREATE STABLE sensor_data ( ts TIMESTAMP, value DOUBLE, quality INT ) TAGS (device_id NCHAR(20), point_type NCHAR(20)); INSERT INTO sensor_data USING sensor_data TAGS (gas01, CH4) VALUES (NOW, 0.65, 1);参数说明STABLE是超级表相当于按标签分类的模板device_id和point_type是标签查询时能按设备编号和测点类型快速过滤。value存数值quality存质量码1表示有效0表示无效采集异常时不要给曲线补零。插入语句通过USING自动创建子表每台设备对应一张子表物理存储按标签聚簇查询一个月的数据只需要扫描对应子表的数据块耗时在毫秒级。这里还有一个非常现实的坑设备时钟漂移。井下很多传感器长期运行后时钟偏差达到数分钟直接使用设备上报时间会造成曲线乱序。我在采集网关层把设备上报的原始时间保存在raw_ts字段另加一个ts字段采用网关收到数据时的服务器时间。这个策略简单可靠既能保证曲线时间轴连续又保留了排查设备时钟问题的原始记录。4.3 预警规则分层阈值、趋势与连续帧确认预警规则是煤矿信息化系统里和安全生产绑得最紧的部分。规则本身不复杂但误报和漏报都会消耗值班人员的信任。常见的做法是把预警分三层硬阈值层、趋势层、联动层。硬阈值层最直接甲烷浓度超过0.8%报警这个标准各矿要求不同趋势层看短时间内的变化斜率用于发现缓慢积聚联动层则结合多个测点做综合判断例如回风巷甲烷浓度上升的同时风速下降会自动关联为“异常通风状态”。写趋势预警时我处理过的问题代码大多败在“只看最新一个点”上。传感器偶发的电磁干扰会让单一数据点偏高如果立即报警就是典型的误报。正确做法是加一个连续帧确认机制def trend_alert(values, threshold0.3): if len(values) 5: return False window_avg sum(values[:4]) / 4 return (values[-1] - window_avg threshold and values[-2] window_avg) # 连续两帧增长才触发参数说明threshold是增长阈值表示最新值与最近4帧均值的差值超过0.3%时才认为异常values[-2] window_avg要求倒数第二帧已经高于均值用连续两帧确认排除单点尖峰。这个写法不复杂但对抑制粉尘干扰、电流浪涌这类瞬时噪声非常有效。联动规则不建议让每个测点独立触发而是在预警引擎里建立“测点-区域”的映射关系把同一段巷道的甲烷、风速、温度传感器归为一组。当组内任意两个测点同时出现正向趋势时才把区域状态置为“重点监视”。这一层逻辑可以用简单的规则引擎也可以直接写成Python脚本关键是要控制误报率让系统报警一次就值得下井核实一次。5. 项目交付前怎么验证和汇报三条实用经验系统联调完成到正式验收之间有几个动作虽然不产生代码但能把工程质量拉高一个档次。这些动作是拔纤测试、传感器交叉复核和指标归拢。5.1 拔纤测试验证链路切换时间不是靠感觉环网验收时很多人默认“断了一根线应该没事”但实际切换表现必须实测。找个生产检修窗口把环网中段的一根光纤拔掉同时让值班室看监控画面和采集时间戳用秒表记录从拔纤到业务恢复的时间。ERPS环网下这个值应当小于100msRSTP下应在3秒以内。测试后保留时间戳日志标注恢复时间和对应的环网设备端口号。这样后续每次升级网络配置都能对比同一组数据判断切换性能是否退化。5.2 传感器交叉复核误差控制在0.1%以内数据质量不能只看平台曲线连续性还要用便携式仪表做现场比对。抽查几个重点测点把标准仪器的读数与监控系统的实时值写在一张表上逐项计算偏差。甲烷传感器的偏差通常要求控制在读数的正负0.1%以内风速传感器偏差控制在正负0.2m/s以内。发现偏差超限先看传感器是否到了校准周期再检查采集程序里的小数位配置是否正确。这一项测试记录要保留到项目验收材料中因为它是数据准确性的直接证据。5.3 汇报时按四个指标排序而不是堆功能截图向矿方管理层汇报煤矿信息化项目效果时多讲业务连续性指标少讲大屏画面和列表功能。我习惯用这组指标排序数据采集率、链路在线率、预警准确率、故障恢复时间。每个指标附一个真实数值和一个典型实例整个汇报只需四张图但每张图都经得起追问。比如“链路在线率99.5%”对应的就是拔纤测试的记录和光功率巡检的基线表。这种输出方式让信息化项目从“做了多少功能”变成“业务连续性达到什么水平”对后续运维预算申请也更有说服力。本文还有配套的精品资源点击获取