2. 车间监控系统数据采集与通信基础

车间监控系统要能远程运维，第一步不是“连上网络”，而是把现场设备的数据以正确的协议、正确的点位、正确的节奏采集出来，再经边缘网关整理后送到云端。协议决定“怎么问、怎么答”，点位规划决定“采什么、采多细”，边缘网关决定“怎么缓存、怎么转换、怎么断点续传”，上云路径决定“数据最终落到哪里、被谁使用”。这四件事任何一环出问题，远程诊断都会变成“看得到画面、查不到根因”。

一、四类常见工业协议在远程运维中的角色

Modbus（RTU/TCP）结构简单、生态广，大量电表、温控器、变频器、老式PLC都支持。它采用主从问答，主站发功能码和寄存器地址，从站返回数据。远程运维中它常承担“低层设备数据搬运”的角色，优点是接入快，缺点是语义弱——寄存器0x0001到底是温度还是频率，完全依赖点表约定，且无内建时间戳与类型信息。

OPC UA是面向信息建模的协议，带地址空间、类型系统和安全通道。它不只是“读寄存器”，而是把设备抽象成对象、变量、方法，变量自带数据类型和语义。远程运维中它适合做跨厂商、跨层级的数据汇聚，也便于把设备状态、报警、参数统一表达。缺点是配置比Modbus重，需要证书、端点、会话管理。

Profinet是西门子主导的实时工业以太网，常用于PLC与远程IO、驱动器之间的循环通信，周期可到毫秒级。它本身不是为跨公网远程访问设计的，远程运维中通常不直接穿透Profinet，而是通过边缘网关在车间侧读取PLC数据，再转成MQTT/OPC UA上传。理解这一点很关键：Profinet负责“现场实时控制”，不负责“远程广域传输”。

EtherNet/IP基于CIP，常见于罗克韦尔体系，用生产者/消费者模型传输I/O和显式消息。它和Profinet类似，属于现场控制网络，远程运维时同样建议在边缘侧做协议转换，而不是把控制网直接暴露到公网。

二、数据采集点位规划：从“能读”到“有用”

点位规划不是把PLC里所有地址都抄一遍。远程诊断真正需要的是三类点：状态点（运行/停止/故障/手自动）、过程点（温度、压力、速度、电流）、诊断点（通信质量、模块状态、报警字、累计运行时间）。规划时先按设备类型建模板，再按设备实例展开，避免每个设备单独配一遍。

以一台变频风机为例，可规划如下点位（示例参数，非实测）：

采集周期要分级：故障字、急停状态用500 ms～1 s；温度、压力用1～5 s；累计量、电能用30～60 s。全部点都按100 ms采集，会把网关和网络压垮，也会让云端存储成本失控。另一个关键是死区与变化上报：温度变化小于0.2 ℃不必上报，状态字变化必须立即上报，这样既保留诊断细节，又减少无效流量。

三、边缘网关配置与数据上云路径

边缘网关位于车间网络与公网之间，典型配置流程是：先配南向采集（协议、IP、站号、寄存器、周期），再配北向输出（MQTT Broker、Topic、QoS、JSON格式），最后配本地缓存与断网续传。南向要设置超时和重试，例如Modbus超时800 ms、重试2次，避免单点无响应拖死整个轮询。北向建议用MQTT，Topic按“厂区/车间/设备/点位”分层，例如：

factory1/workshopA/fan01/status
factory1/workshopA/fan01/freq
factory1/workshopA/fan01/alarm

数据上云路径通常有三段：现场设备 → 边缘网关（协议转换、缓存、边缘计算）→ 云平台（时序库、报警引擎、远程画面）。网关本地要保留至少24～72小时缓存，断网时数据写本地队列，恢复后按时间顺序补传，并带原始时间戳，否则云端看到的曲线会出现“时间塌陷”。若现场有多个网关，建议统一时钟源（NTP），否则跨设备关联分析会失真。

四、远程运维中容易踩的坑与判断依据

第一，把控制网直接映射到公网。Profinet、EtherNet/IP本身缺少面向广域的安全机制，正确做法是网关只读采集，控制指令不穿越公网。第二，点位地址与数据类型不匹配。Modbus寄存器是16位，32位累计量要读两个寄存器并注意高低字顺序，否则会出现“数值跳变”。第三，时间戳缺失。网关补传时必须带采集时刻，而不是上传时刻，否则断网恢复后曲线顺序错乱。第四，只看通信通不通，不看数据质量。远程诊断要同时观察通信状态字、超时计数、重试次数，例如网关日志中某站连续超时3次，就应优先排查该站物理链路，而不是怀疑云端。

判断采集是否健康，可以看三个指标：点位在线率（应≥99%）、数据新鲜度（最新值时间与当前时间差，正常应小于2个采集周期）、断点续传积压量（应长期接近0）。若新鲜度持续增大而在线率正常，通常是北向链路或Broker问题；若在线率下降且超时计数上升，则优先查南向现场网络。

把协议角色分清、点位规划做细、网关缓存与时间戳配好、上云Topic规范统一，远程运维才有可靠的数据底座。后续的远程诊断、报警分析和预测维护，都建立在这一层数据质量之上。