4. 产线数据源接入方式

在多产线时序数据汇聚工程中，接入层决定了后续数据质量、实时性与系统扩展成本。产线现场的数据源形态差异很大：PLC、CNC、机器人、传感器、SCADA、边缘网关、MES 接口等，各自支持的协议不同。常见接入方式包括 OPC UA、Modbus（RTU/TCP）、MQTT 以及 Kafka。它们并非同一层面的替代品：Modbus 和 OPC UA 更偏“设备/控制系统通信”，MQTT 偏“轻量消息传输”，Kafka 偏“高吞吐数据管道”。选型时不能只问“哪个协议更好”，而应问“这条产线的数据从哪来、要传多远、对实时性和可靠性要求如何、下游是谁”。

四类协议的本质差异

Modbus 是典型的请求/响应式主从协议，结构简单、成本低，广泛存在于老产线和仪表中。它把数据映射为线圈、离散输入、输入寄存器、保持寄存器四类地址空间。主站轮询从站，从站被动应答。优点是几乎任何 PLC、仪表都支持；缺点是语义弱、无原生类型系统、无订阅机制、无安全认证，且轮询周期受从站数量和串行链路限制。它适合“采集少量寄存器值、实时性要求不高、设备老旧”的场景。

OPC UA 是面向工业自动化的信息模型协议，具备地址空间、类型系统、订阅/发布、方法调用、安全策略和会话管理。它既能做设备级通信，也能做服务器间汇聚。相比 Modbus，OPC UA 能表达“这个值是温度、单位是摄氏度、来自哪台设备、质量码是什么”，语义完整。其订阅机制可在数据变化时主动上报，降低无效轮询。缺点是栈较重，对嵌入式设备资源要求高，配置和证书管理有一定门槛。

MQTT 是轻量级发布/订阅消息协议，基于主题（Topic）路由，支持 QoS 0/1/2、保留消息和遗嘱消息。它非常适合边缘网关到云端的“多对一”汇聚：每条产线一个网关，网关把采集到的数据发布到 factory/lineA/plc1/temp 这类主题，平台按主题订阅。MQTT 不负责数据持久化和大规模回放，通常需要配合消息中间件或时序数据库。

Kafka 是分布式提交日志，按主题分区、顺序追加、可持久化、可回放，吞吐量高。它适合作为汇聚后的“数据主干”：所有产线数据先进入 Kafka，再由流处理或消费程序写入时序库、数据湖或实时看板。Kafka 不直接面向现场设备，通常位于 MQTT 网关、OPC UA 服务器或采集程序之后。

选型依据：从五个维度判断

第一，数据源支持什么。如果设备只支持 Modbus，强行要求 OPC UA 需要更换硬件或加网关，成本高。此时应保留 Modbus 采集，在边缘侧转换为统一模型。如果设备原生支持 OPC UA，优先用 OPC UA，因为语义完整、可订阅、可安全传输。

第二，实时性与数据变化频率。Modbus 轮询周期通常为 100ms～1s，适合温度、压力等慢变量；OPC UA 订阅可做到 10ms～100ms 级，适合运动控制、高速计数；MQTT 端到端延迟通常在几十毫秒到几百毫秒，适合秒级汇聚；Kafka 吞吐高但单条延迟不占优，适合“先落盘再消费”的管道。若产线要求 50ms 内闭环，不应把 MQTT 或 Kafka 放在控制回路中，而应让 OPC UA 或现场总线承担实时控制，MQTT/Kafka 只做旁路汇聚。

第三，可靠性与数据完整性。Modbus 无确认重传之外的保障，断线即丢数；OPC UA 有会话和订阅保持，但断线期间数据可能丢失；MQTT QoS 1/2 可保证至少一次/恰好一次，但需要 Broker 和客户端配合；Kafka 通过副本、ISR、acks 配置提供持久化保证。对于质量追溯、能耗结算等不能丢数的场景，应在边缘侧加本地缓存，再通过 MQTT QoS 1 或 Kafka acks=all 上传。

第四，网络与部署条件。车间网络常有不稳定、带宽受限、NAT 隔离等情况。MQTT 适合低带宽、长连接、穿透 NAT；OPC UA 二进制模式比 XML 更省带宽，但配置复杂；Modbus TCP 简单但无加密；Kafka 需要较稳定的集群网络和磁盘。若产线分布在多个厂区，建议边缘 MQTT 汇聚到中心 Kafka，而不是让 Kafka 直接跨广域网连接现场设备。

第五，数据语义与后续治理。如果下游需要按设备、产线、工序、质量码做多维分析，OPC UA 的信息模型最有利；Modbus 需要额外维护寄存器映射表；MQTT 需要约定 Topic 命名规范；Kafka 需要约定消息 Schema。选型时应把“元数据从哪来”一并考虑，否则汇聚后会出现“有数据、无含义”的问题。

典型组合与配置示例

实际工程中很少只用一种协议，常见组合是：Modbus 采集老旧设备 → 边缘网关转换为 MQTT → 中心 Kafka → 流处理写入时序库；对支持 OPC UA 的新产线，则用 OPC UA 订阅 → 边缘程序 → Kafka，减少中间转换。下面给出一个边缘 MQTT 主题与 QoS 配置示例，用于说明接入约定：

# 产线 A 的 MQTT 主题约定（示例）
factory/lineA/plc01/temperature     QoS 1   单位: ℃   采样: 1s
factory/lineA/plc01/status          QoS 1   枚举: 0停机 1运行 2报警
factory/lineA/robot02/cycle_time    QoS 1   单位: ms  采样: 每周期
factory/lineA/energy/meter03/power  QoS 0   单位: kW  采样: 5s

# 边缘网关关键参数（示例）
轮询周期: 200ms
本地缓存: 断线后保留 30min
时间戳: 网关统一打 UTC 毫秒时间戳
质量码: 0=正常 1=超时 2=越限 3=维护

判断接入是否成功，不能只看“消息有没有到”。应检查四项：时间戳是否单调、质量码是否可解释、断线重连后是否有补传、Topic 或 Schema 是否与下游约定一致。若发现同一产线数据在 Kafka 中重复，优先检查 MQTT QoS 1 与消费端幂等；若发现时序库中时间乱序，优先检查边缘网关是否使用了本地时间而非统一时钟。

选型决策表

最终选型不是选一个“最强协议”，而是设计一条从设备到平台的合理链路：现场协议负责取数，边缘网关负责统一时间戳、质量码和缓存，MQTT 或 Kafka 负责可靠传输与汇聚，下游按 Schema 消费。把这条链路画清楚、把每个接口的约定写清楚，比单纯比较协议参数更能保证多产线汇聚工程落地。