企业官网建设流程全解析

简介：聚焦智慧煤矿建设现状与发展方向，这份197页专题讲座PPT由行业专家主讲，面向煤矿企业技术管理者、矿业信息化工程师及科研院所研究者，系统解析从两化融合到智能化矿山的技术演进脉络。课件基于标准体系、感知网络、数据传输、大数据中心与云服务平台，梳理“3115”建设路线，覆盖精准地质信息、智能掘进、无人开采和煤矿机器人等关键核心技术，并结合不同阶段发展目标与应用场景展开。资源包为单个pptx演示文稿，共44.9MB，页面完整、图表丰富，可直接用于内部培训或方案参考。目前已有129人学习下载，内容涉及集团级工业视频监管与飞行机器人应用案例，对智慧矿山规划、智能化改造立项及教学研讨均有较强的落地参考价值。

1. 智慧煤矿建设现状与发展方向：先回答“现在建到哪一步了”

智慧煤矿建设现状与发展方向，落到矿上就一句话：哪些子系统真的在自动跑，哪些还靠人在盯。我们看过大量矿井，画面高度一致：集控中心的大屏很漂亮，井下采煤机却还是人工在割，胶带机联锁“看起来有”，实际动作记录寥寥。这不是个别矿的问题，而是行业当前的整体状态。下面的内容按“现状盘底—技术底座—落地顺序—关键配置—避坑—验收”这条线展开，写给矿方信息中心、机电科、智能化专班，以及给煤矿做系统集成的服务商。读完后你能判断手头项目缺在哪一步，也知道下一步预算该往哪个方向投。

2. 技术底座怎么打：一张网络、一套数据、一个平台

2.1 一张网络：万兆环网、WiFi6与5G怎么选型

井下网络是所有智能化系统的地基，但选型往往被简化成“信号好就行”。实际上一张能扛事的井下网络要同时满足三个指标：带宽、冗余自愈时延、本安防爆。三个指标缺一个，上层应用就会在关键时刻掉链子。主干网络建议直接用万兆工业环网，自愈协议选ERPS或MRP。为什么不是千兆？一个综采工作面至少要回传十几路视频，按每路4K 25Mbps估算就是350Mbps以上，再加上采煤机、支架、泵站、人员定位的数据帧，千兆环网平时也许够用，一旦发生链路切换重传，丢包率会直接拖垮集控画面。万兆环网配合G.8032 ERPS，自愈时延一般在50ms以内，这个量级下集控画面不会掉线。

无线覆盖分两个层次：WiFi6用于人员定位、语音、手持终端的日常业务；5G只用于大上行和低时延场景，比如巡检机器人、综采面视频拼接。千万别全矿上5G。井下巷道断面小、弯道多，5G基站的覆盖半径比地面小得多，往往一个采区就要几十个pRRU，单站成本高，后期维护负担也重。常见做法是井下无线用WiFi6打底，特定场景上5G。我见过一个矿把5G铺了半个采区，最后实际在用的只有两台巡检机器人，性价比非常难看。

无线信号这块很玄学。井下巷道全断面是金属支护，电磁波反射和吸收都很严重，手持终端上显示的四格信号只代表接收电平，不代表可用带宽。验收时不要只看界面信号图标，要用打流工具实测上行吞吐。巷道拐弯处、采煤机附近、转载点这些位置最容易掉速，测试点要专门选在这些地方，别只站在变电所门口测。

2.2 一套数据：从PLC/传感器到数据中台的采集链路

数据接不进来，是智能化项目第一个答辩题。井下设备协议非常杂，常见的有Modbus/TCP、OPC UA、西门子S7、三菱MC，老设备还有大量私有协议。常见做法是先用协议转换网关做边缘接入，再汇聚到矿区前置机，前置机负责协议解析、数据缓存，最后通过MQTT或OPC UA上行到数据中台，由综合管控平台消费。别跳过前置机直接对接平台，否则网络闪断一次，设备数据重传和时序对齐会让人想摔键盘。

下面是一个用pymodbus轮询皮带电机电流并推送MQTT的简化示例，在矿区前置机上可以用类似结构做边缘采集：

# 边缘采集：读皮带电机电流，推送到MQTT from pymodbus.client import ModbusTcpClient import paho.mqtt.client as mqtt import time plc = ModbusTcpClient('192.168.1.10', port=502) plc.connect() def on_connect(client, userdata, flags, rc): if rc == 0: print("MQTT connected") else: print(f"MQTT connect failed: {rc}") mqtt_client = mqtt.Client() mqtt_client.on_connect = on_connect mqtt_client.connect('10.10.0.5', 1883) mqtt_client.loop_start() while True: rr = plc.read_holding_registers(0, 2, unit=1) if rr.isError(): # 读失败不能退出，记录后等待重试 print(f"[{time.time()}] Modbus read error: {rr}") time.sleep(5) continue payload = '{"motor_a_current": %d, "motor_b_current": %d}' % ( rr.registers[0], rr.registers[1]) mqtt_client.publish('mining/transformer/current', payload, qos=1) time.sleep(2)

这个示例里有两个关键点。一是Modbus读取失败时不能中断进程，要打印日志等5秒重试，否则PLC暂时无响应会把采集程序拖死；二是MQTT的QoS设成1，保证至少送达一次，避免平台端丢点。轮询周期2秒用于电流这类缓变量够用，但瓦斯、负压这类安全测点建议用设备主动上报或更短周期，不要沿用同一套轮询参数。寄存器地址、从站号、端口这三个值必须和现场点表对应，点表错了后面所有数据都是错的。

前置机上最好先建一张测点表，按“设备—部件—测点”三级编码，例如“主斜井皮带—3号电机—电流”。这张表就是数据链路的图纸，协议地址、单位、量程、报警上下限全部挂在这张表上。没有测点表就做平台，后面的告警规则和报表全都无从下手。

2.3 一个平台：综合管控平台的边界别被厂商带偏

综合管控平台是“总装车间”，不是业务系统。它的核心功能是实时监测、告警联动、报表统计、生产调度，顶多再加设备全生命周期台账。厂商如果想把采购、财务、办公审批都塞进来，这个项目大概率会烂尾——平台一重，可维护性就崩了。功能边界在招标阶段就要用一张表约定清楚。

集成方式上，设备层优先走OPC UA或MQTT；子系统（比如洗煤厂、瓦斯抽采泵站）如果已经有上位机，走数据库视图或REST API；历史文件和曲线数据可以用SFTP定时落库。选平台时重点问三件事：是否支持北向API二次开发，数据模型能否自己扩展，组态画面是否开放给矿方维护。三样里缺一样，后期改个流程都得找原厂，被卡脖子的滋味不好受。

3. 从采掘到运输：智能化落地顺序与关键参数

3.1 智能化综采工作面：记忆截割与跟机自动化的参数怎么调

智能化综采工作面的核心是采煤机记忆截割和液压支架跟机自动化。原理并不玄乎：先由人工操作采煤机割完一刀，系统记录滚筒高度、牵引速度与工作面位置的关系，生成截割模板；后续采煤机按模板自动复现，支架按采煤机位置自动移架、推溜、收护帮板。这套系统的价值在于把操作工的重复劳动减掉，而不是一步到位搞无人工作面。

关键参数里最容易翻车的是三个：牵引速度、降柱时间、移架滞后距离。牵引速度默认给4～6 m/min，煤质硬时降到4以下，软时再往上调，不能一刀模板用到底。降柱时间一般设0.5～1秒，太短降不到位就拉架，护帮板会和煤壁刮蹭。移架滞后距离通常设3～5架，滞后太远顶板暴露面积大，太近又容易被采煤机割到支架部件。这些参数一旦设错，现场就会出现“支架跟着采煤机跑，结果被割坏”的事故，修复成本比人工操作还高。

记忆截割的模板必须每班更新。常见做法是：人工示范刀录制模板后，每班结合地质预测数据修正顶底刀高度增量，再让系统按“模板+微调”运行。直接把全自动模式推到操作工面前的，几乎没有不切回人工的。参数记录用下面这张表就够了。

3.2 主运输与辅助运输：煤流平衡和单轨吊调度的联动逻辑

主运输智能化做得最多的是“煤流平衡”：皮带上煤量大了，系统自动降给煤机速度；煤量小了，往上提。胶带机启动顺序必须逆煤流，停机顺序顺煤流，这个顺序在PLC里写死，平台只做展示。联动的主要依据是煤量传感器和皮带电流。

煤量传感器的安装位置很讲究。装在溜煤嘴正下方不行，煤流冲击会产生巨大毛刺；装在缓冲托辊区段也不行，皮带颠簸造成数据乱跳。常见做法是装在受料段往前约1.5米、皮带张力相对稳定的区段，并且用滚动平均做平滑后再参与调速。信号毛刺问题不解决，煤流平衡系统就是摆设，操作工看几次误动作后就会把它切掉。

辅助运输这块，单轨吊调度是目前比较多人做的一步。核心不是车辆定位，而是区间占用和红绿灯闭锁逻辑。井下会车点少，两辆单轨吊进入同一区间就会“卡在半道”。常见做法是按读卡器把巷道切成若干区间，区间被占用时，后方信号灯变红，调度界面同步显示占用状态。这个逻辑写不完整，辅助运输就会比传统小绞车还低效。另外单轨吊的区间切分要考虑弯道和车场，不能只看直线距离均分。

3.3 智能通风与瓦斯联动：安全逻辑优先于自动化逻辑

智能通风的常见做法是用精确测风装置实时监测巷道风速风量，再通过主扇变频器和风门执行器自动调节。风量传感器要装在直线巷道、风速分布均匀的位置，前后10米内不能有局部调车场、风门、堆积物，否则测出来的数据没有代表性。通风系统做自动调节前，先把手动调节和反风操作跑顺，这一步不能省。

这里有一条铁律：安全逻辑优先于自动化逻辑。瓦斯传感器报警时，系统必须立即进入安全模式，只执行超限断电、停止执行远程调风；普通情况下允许自动调风，但报警后的任何自动调节都要让位。这个安全切换逻辑必须写在PLC里，不能只写在平台软件里，否则平台一升级，联锁就裸奔了。

提示：联锁逻辑放在PLC是底线。平台软件挂了可以重启，PLC挂了全矿都得停，所以安全逻辑必须跑在最底层那套系统上。

反风演练也是最容易被忽略的一环。自动控制系统必须支持一键切手动，反风操作流程不能被软件锁死。有些项目验收演示时一切都好，到反风演练时发现系统不允许人工干预，直接判定不合格。这一点在验收清单里务必要写进去，别等演练了才去翻图纸。

4. 让数据真正用起来：AI视频分析与协同控制的关键配置

4.1 皮带异物识别与人员违规检测：置信度阈值和补光才是重点

AI视频在煤矿落地最多的是皮带异物识别、人员违规行为检测和区域闯入。这些场景的共同点是非常吃现场条件：井下光照不足、粉尘多、补光灯角度不对，白天能用晚上误报满天飞。很多项目摄像头装了几百路，AI只在调度室电脑上跑了两路流，就是因为报警风暴压不住，操作工把声音一关，系统就成黑匣子了。

配置AI识别时，我一般会先定三个参数：置信度阈值、连续告警帧数、抑制窗口。以皮带异物识别为例，置信度设0.6左右，连续三帧以上才判定有效，抑制窗口5秒内同一目标只报一次。阈值太低，皮带正常摆动、托辊反光都会上报；太高，小块的撕裂物又漏掉。井下场景要先保漏报，因为漏一块尖锐异物就可能撕带，宁可多报几路让调度人工确认。

algo: belt_foreign_object: confidence: 0.6 min_tracking_frames: 3 suppression_window: 5 person_intrusion: confidence: 0.55 zone_list: - crusher_area - belt_walkway

参数说明：confidence是模型置信度阈值，低于这个值的检测结果全部丢弃；min_tracking_frames要求目标在连续多帧中都被检到才算有效事件，用来过滤单帧闪烁；suppression_window是告警抑制，避免同一目标反复触发。zone_list限定检测区域，比如人员只在破碎机周围和皮带通道做入侵检测，其它区域不启用，既省算力又降误报。每个场景的阈值都要单独调，不能一个配置文件走天下。

补光灯是另一个频繁踩坑的点。常见做法是侧装补光，让灯光斜照目标区域，不要正对镜头。正对镜头的补光会在粉尘环境里形成强烈反光，让模型在夜班把水汽误判成烟雾。调整补光角度往往比调模型阈值参数更管用，这是血泪换来的经验。

4.2 一键启停的顺控逻辑：连锁条件写全才敢无人值守

一键启停是“无人值守”的底线功能，但最常见的坑是顺控逻辑只写了正常顺序，没写异常分支。以胶带系统一键启动为例，正确顺序是逆煤流：给煤机→皮带A→皮带B→转载机。每一步启动前都必须确认对应条件成立，任何一级启动失败，已启动的设备按顺煤流延时停机，防止堆煤。

连锁条件要写进PLC，不写在平台脚本里。平台脚本挂了或者被误改，PLC里的逻辑还能兜底。运行中出现瓦斯超限或急停信号时，所有顺控状态都要立刻回到“停止”，并且只能手动恢复，不允许自动复位。这个“故障闭锁”是能不能真正无人值守的分界线。我参与过一个项目，一键启停上线一周就被移除了，原因就是有人误碰急停后系统自动复位，皮带带着异物重新转起来，当场撕带。后来把自动复位改成手动确认，才把功能捡回来。

4.3 数字孪生的落地边界：别让三维可视化冒充仿真推演

数字孪生这个词在煤矿已经被用滥了。厂商拿一套三维地图，把设备位置、实时电流刷新上去，就敢叫数字孪生。严格讲，这只能算三维可视化，因为它没有物理模型，做不了任何仿真推演。煤炭行业里真正能落地的数字孪生，必须能回答“如果这样会怎样”的问题，而不是只会显示“现在是什么状态”。

煤矿数字孪生真正有价值的场景，是用历史数据驱动模型做预测和推演，比如：根据当前煤流情况预测皮带到下一小时的转载点堆煤概率；根据瓦斯涌出规律模拟不同风量下的浓度变化。这些需要流体模型、传质模型和大量历史数据，投入很高，绝大多数矿现阶段做不起完整版。

常见做法是分两步走：一期做三维可视化加数据绑定，让管理层在浏览器里能看到设备实时状态和报警定位；二期再挑一两个高价值场景做仿真，比如主运输瓶颈分析或瓦斯通风联动模拟。验收数字孪生模块时，别轻信演示视频，要求用矿上最近一周的真实数据跑一遍回归，模型输出对不上历史记录，对不起，这套系统就是可视化，不是孪生。

5. 智慧煤矿避坑实录：五个高频问题的现象、原因与解决

5.1 数据采不上来，平台成了“大屏展示机”

现象：综合管控平台大屏上只有十几条曲线在动，其余设备显示灰色或离线。原因：设备协议私有，网关厂商不开放；更常见的是没有测点表，现场没人知道这个寄存器到底代表什么。解决：先做全矿测点普查，建测点台账，按“设备—部件—测点”编码；私有协议让设备厂家开放或加协议解析盒子；采集按优先级分批接，先把皮带、风机、瓦斯、水泵这类关键设备接全，再覆盖次要设备。测点台账至少要包含以下字段：测点编码、设备名称、部件名称、协议类型、寄存器地址、数据类型、单位、量程、报警上下限。这张表做不细，后面所有报表都会跟着错。

5.2 摄像头装了上百路，AI识别只有几路在线

现象：AI平台界面显示“算法已下发”，实际只跑了两路视频流。原因：算力不够，服务器GPU/NPU资源被拉满；部分厂商所谓的AI其实只是普通录像回放。解决：算力按路数预估算，每路4K AI推理大约需要20 TOPS左右，先规划好再下单硬件；部署范围先覆盖主斜井皮带、装载点、人员违规高发区，保证这三类场景先跑起来，再逐步扩容。边端盒子统一纳入管理，不要一个摄像头配一个独立盒子，否则运维成本会失控。另外算法上线后要持续看误报趋势，连续一周误报率超过10%就说明场景标定有问题，得重新采集现场样本做调优。

5.3 记忆截割用不起来，习惯性切回人工

现象：月度报表自动化率只有10%，操作工开两刀就切回手动。原因：煤质变化后模板不更新，牵引速度过快导致截割电流超限，操作工对系统失去信任。解决：初投阶段每班更新一次截割模板，牵引速度降到4 m/min以下跑满一周再提；先定义“记忆截割+人工微调”模式，操作工手上有权限介入，他才会让系统继续跑。全自动模式留到有三个月数据积累后再切。这里的教训是：智能化系统的上线节奏要顺着人，不能逆着人，先把人机协同模式跑通，再谈全自动化。

5.4 安全联锁被人为旁路，报警成了摆设

现象：瓦斯超限记录里出现“未动作”标签，查询发现报警点被人工屏蔽。原因：产量压力大，现场为了保生产把联锁摘了。解决：联锁撤销必须双人授权并留审计痕迹，平台只能查看不能修改；联锁逻辑全部下沉到PLC，平台软件挂了逻辑仍然生效；在调度制度里把旁路操作定义为事故红线，月底报表自动统计旁路次数。审计字段至少要有：操作人、授权人、开始时间、结束时间、原因说明。没有审计留痕的联锁旁路，本质上就是裸奔。

5.5 无线信号满格，视频却卡成PPT

现象：手持终端信号满格，但视频画面卡顿、语音断续。原因：信号强度只代表接收电平，不代表可用带宽；井下金属支护反射严重，信道互相干扰；回传链路在上行方向饱和。解决：做信道规划，不同巷道分配不同频段，相邻AP用错开信道；验收用打流工具实测上行吞吐，不要只看信号图标；关键点位用光纤加WiFi6双链路兜底，巷道拐弯处放大上行带宽余量。这条经验反复出现在各类项目的验收报告里：信号满格但业务卡顿，十次有九次是上行带宽堵了，下行质量测得再好也没用。

6. 用一张验收清单和两条曲线判断项目有没有白做

6.1 验收清单和两条曲线

项目上线后不要急着搞发布会，先按下面这张清单挨个跑。

还有两条曲线我会重点盯。第一条是误报率与漏报率随阈值变化的曲线，现场调参时先保住漏报不抬头，再去压误报，两个都想要的结果往往是两个都保不住。第二条是数据连续率按天画的曲线，夜班时段连续出现毛刺，说明网关电源或网络重传有问题，要抓包看链路。验收时拿这两条曲线说话，比演示视频可靠得多。我自己验收项目的第一习惯，就是先查数据连续率和报警处置闭环，这两项不合格，功能再多也是展示品。希望帮到你。

本文还有配套的精品资源，点击获取