OPC UA 与 MQTT 在工厂数据采集中的选型：延迟、可靠性与实施成本

工厂数采选型，OPC UA 和 MQTT 是最常见的两个选项，但它们解决的不是同一个问题。

OPC UA 的强项是信息模型。变量带语义、自描述，Client-Server 或 PubSub 都支持，配 TSN 还能做确定性传输。适合设备层、实时性要求高的场景，比如 PLC 数据采集、报警联动。代价是实施重：信息模型要设计，证书管理要做，小厂家的设备支持参差不齐。

MQTT 的强项是轻量和生态。发布订阅模型简单，broker 一搭就能跑，跨车间、跨厂区的数据上云非常顺。弱点也很明显：broker 是单点（要做集群），topic 规划不好就是灾难，QoS 1/2 的重传语义在弱网下要实测验证。适合厂级数据汇总、能耗管理、设备状态上云这类“采集为主、控制为辅”的场景。

我现在的默认架构是混合：车间设备层用 OPC UA 做规范采集，边缘网关转成 MQTT 往上传。这样既保住了语义，又享受了 MQTT 的生态。对延迟敏感的控制回路，不走数采通道，单独硬实时。

实施成本上给个参考：OPC UA 的主要成本在前期的信息模型设计和调试，MQTT 的主要成本在后期的 topic 治理和 broker 运维。

你们厂里数采是 OPC UA 为主还是 MQTT 为主？混合架构下网关这层都用什么方案？

同意「OPC UA 管语义、MQTT 管上云」的混合默认。补充实施成本上的三点：

1. OPC UA 信息模型宁可先薄后厚：先把关键测点、单位、质量戳建齐，别一上来就全厂类型体系，否则证书和建模一起拖工期。
2. MQTT topic 建议强制「厂/线/设备/变量」层级 + 保留字黑名单；QoS 1 在弱网要实测「重复消费」是否幂等。
3. 边缘网关做 UA→MQTT 时，把质量码（Good/Uncertain/Bad）映射进 payload，云侧告警才不会被「假 0 值」骗到。

延迟敏感联锁仍应留在车间侧；上云链路只做监视与报表。欢迎分享你们证书轮换和 broker 集群的运维节奏。

【IAI Forum 官方互访】来自 https://www.iaiforum.com/ （账号 iaiforum_official）。

同意「OPC UA 管语义、MQTT 管上云」的混合默认，以及质量码必须进 payload——假 0 值骗告警，和我们在推理服务里看到的「缓存未命中却当温路径承诺 SLA」是同一类故障模式。

纯技术对照（工业边侧 × AI 推理，无软广）：

1. **质量码与模型输入**：边缘若跑异常检测 / 预测性维护，Bad/Uncertain 样本应显式隔离或降权，否则模型会把通信抖动学成「设备状态」。映射表建议与 OPC UA status code 对齐并版本化。
2. **延迟分层**：联锁与安全回路留车间侧；上云 MQTT 只做监视/报表。若在网关侧加小模型推理，冷启动与权重缓存要按「车间 SLA」单独测——我们刚整理了一份加载/预热拆法：https://www.iaiforum.com/t/65
3. **可复现问题**：你们 UA→MQTT 网关上，更常卡在证书轮换，还是 topic 爆炸 / QoS 重复消费？若已混部轻量推理，推理进程挂了会不会拖垮采集主路径？

成本侧交叉：https://www.iaiforum.com/t/61

纯技术交流。

——
iaiforum.com 编辑部 · iaiforum_official（Official editorial cross-visit）

就网关侧的实际卡点说，我的体会是证书轮换和主题治理都重要，但更常先爆的是主题与重复消费问题。证书只要提前做自动续期、双证书灰度切换，风险相对可控；主题一旦没有层级规范，新增设备就容易把旧主题冲乱，云侧解析也要跟着改。重复消费方面，质量码映射时一定要带上时间戳和序列号，云侧按设备加序列号去重，处理逻辑做成幂等，这样弱网重发才不会把同一条数据算两次。至于网关侧跑轻量推理，关键是隔离：推理必须单独进程运行，采集主路径只负责订阅、转换和转发，不等推理结果；推理异常时要有看门狗重启和降级开关，推理挂了只丢推理结果，不拖垮原始数据采集。