1. 矿山PLC数据采集与InfluxDB存储概述

矿山是一个典型的"设备密集、环境恶劣、安全约束强"的工业现场。从井下提升机、通风机、排水泵，到地面的破碎机、皮带运输机、选矿球磨机，大量关键设备由PLC（可编程逻辑控制器）进行本地逻辑控制。这些PLC本身已经"知道"设备的运行状态——电机是否启动、轴承温度多少、皮带是否跑偏、水泵流量是否正常——但这些数据大多停留在控制层，只服务于就地联锁与操作员画面，很少被系统性地汇聚、长期保存并用于分析。本课程要解决的核心问题就是：如何把分散在矿山各处的PLC数据稳定采集上来，并按时间序列的方式存入InfluxDB，形成可查询、可分析、可追溯的数据底座。

为什么矿山需要PLC数据采集

PLC数据采集的意义可以从三个层面理解。第一是安全与合规：井下排水泵若未及时启动，水位上升会直接威胁人员安全；主通风机停机几分钟就可能造成有害气体积聚。把水位、风机电流、风压等参数持续采集并留存，才能在事后追溯"当时到底发生了什么"，也才能支撑安全监测系统的报警联动。第二是设备管理：矿山设备多为重载连续运行，轴承温度、振动、电流是典型的劣化前兆信号。只有按秒级或分钟级持续记录，才能看出温升趋势、识别异常工况，而不是等到设备停机才去翻操作记录。第三是生产优化：皮带机的负载率、球磨机的功率曲线、水泵的启停频次，都是能耗与效率分析的基础数据。

需要强调的是，矿山PLC采集与普通工厂采集有明显差异。井下设备分布分散、网络条件受限，常采用工业以太网加光纤环网的分层结构；采集点往往跨越多个PLC品牌与协议（如西门子S7、Modbus TCP、OPC UA）；现场电磁干扰强，对采集程序的容错与断线重连能力要求高。这些特点决定了采集方案不能简单套用"一个脚本读一个PLC"的做法，而要有清晰的分层与协议适配设计。

时序数据库在矿山场景中的价值

PLC采集上来的数据有一个鲜明特征：带时间戳、按固定周期产生、写多读少、按时间范围查询。一台设备10个测点、1秒采集一次，一天就是86.4万条记录；全矿几百台设备，日增量轻松达到千万级。用传统关系型数据库存储，会面临写入压力大、表膨胀快、按时间聚合查询慢的问题。

InfluxDB正是为这类数据设计的时序数据库。它的数据模型由measurement（类似表）、tag（带索引的标签，如设备编号、测点类型）、field（实际数值）和timestamp组成。把"设备编号""测点名称"设为tag，把"温度值""电流值"设为field，就能高效地按设备、按测点、按时间范围做聚合查询。例如查询某台排水泵过去24小时的平均电流，或统计所有皮带机每5分钟的最大负载率，都能以较小的代价完成。此外，InfluxDB自带保留策略（retention policy）和连续查询/降采样能力，可以把秒级原始数据保留数天、把分钟级聚合数据保留数年，兼顾精度与存储成本。

课程整体项目贯穿设计

本课程不是零散知识点的堆砌，而是围绕一个贯穿全课程的项目展开：为某矿山建设一套"PLC数据采集—时序存储—查询分析"的最小可用系统。项目设定如下（示例场景，参数为教学合理假设）：现场有两台PLC，一台控制井下排水泵站（采集水位、1#/2#泵电流、泵运行状态共5个测点），一台控制地面皮带运输机（采集电机电流、皮带速度、跑偏信号共3个测点）；采集程序以1秒周期轮询，数据写入本地InfluxDB，最终通过查询接口输出设备运行报表。

下图展示了这套系统的整体数据链路与分层关系，后续各章节将逐层展开其中的协议适配、采集程序、数据建模、写入与查询等环节。

从图中可以看到，整条链路分为四层：现场设备层提供原始测点，采集适配层负责协议转换与周期轮询，时序存储层完成建模与持久化，查询应用层面向业务输出结果。每一层都有明确的输入输出边界，这也是后续排障时定位问题的基本依据——数据没上来，先判断是PLC侧、采集侧还是写入侧的问题。

关于贯穿项目的规模，这里给出一个便于估算的示例：8个测点、1秒采集一次，单日记录数为 8 × 86400 = 691200 条，约69万条；若按每条记录含时间戳与少量字段估算，日增数据量在几十MB量级，对单机InfluxDB完全可控。这个估算在后续设计保留策略时会反复用到：秒级数据保留7天约480万条，分钟级降采样后每天仅1.15万条，保留两年也才八百多万条，存储压力大幅下降。

学习本课程时建议始终带着这条链路去理解每个知识点：学到协议时想"它处在采集适配层的哪个位置"，学到数据建模时想"tag和field怎么划分才利于后面的查询"，学到写入时想"失败了怎么保证不丢数据"。把零散技术点挂到这条主链上，才能真正形成可落地的工程能力。