OPC UA、Modbus、MQTT 和 WebSocket 应该怎么选?
四者常处于不同链路位置,不必四选一。OPC UA 适合带语义、订阅和安全能力的工业互操作,Modbus 常用于按设备寄存器或功能码读写,MQTT 适合经代理发布与订阅遥测消息,WebSocket 适合浏览器与服务端保持双向连接。项目应按设备支持、数据语义、网络区域、可靠性和安全要求组合选用。
Industrial Data Integration
直接答案:工业实时数据接入不是“协议连通”就结束,而是把 PLC、SCADA、MES 或 IoT 平台中的数据,经过采集、传输、缓冲、清洗、语义映射和接口服务,稳定送到业务应用。验收应同时核对点位、时间戳、质量状态、端到端时效、断线补传、权限审计和恢复证据。所有频率、延迟、容量及恢复目标都应按具体业务与现场条件书面定义,不能套用未经验证的固定数字。
本文聚焦工业侧的实时或准实时数据链路。若项目仍在梳理 Excel、数据库、API 与设备平台等通用数据源,可先阅读企业数据大屏数据接入方法;工业项目还应把权限、审计与终端边界纳入数据大屏安全验收。
典型链路可以表示为:现场仪表或设备 → PLC / RTU → 边缘网关或 SCADA → 消息代理、工业数据平台或集成服务 → 数据存储与指标服务 → API / WebSocket → 数据大屏、业务系统或数字孪生界面。MES 和 IoT 平台可能位于中间层,也可能作为业务数据源或消费端;实际拓扑取决于既有系统和网络分区。
ISA-95 官方介绍提供了企业系统与控制系统集成的通用分层视角。项目可借此澄清 PLC、SCADA、MES、ERP 与分析应用各自承担什么职责,但不应机械照搬层级来替代现场架构调查。
| 链路环节 | 需要确认 | 建议保留的验收证据 |
|---|---|---|
| 现场与控制层 | 设备型号、点位地址、量程、单位、读写属性、质量码、采样能力 | 点位表、设备或驱动文档、现场值与读取值对照 |
| 网关与采集层 | 协议、轮询或订阅策略、时间戳来源、断线队列、重连与补传 | 配置导出、运行日志、断网与恢复测试记录 |
| 平台与存储层 | 消息持久化、去重、顺序、数据模型、质量规则、保留与归档 | 样例消息、表结构或主题清单、异常数据处理记录 |
| 应用与展示层 | 指标口径、接口刷新、缓存、告警状态、权限、页面降级 | 接口日志、页面与源端对照、权限反向测试 |
这些技术往往位于不同链路位置,并非同层替代关系。一个项目可以使用 Modbus 从设备读取寄存器,网关再通过 MQTT 上送平台,平台通过 WebSocket 向浏览器推送;也可以由 OPC UA 客户端订阅 SCADA 或设备服务器中的变量。
| 技术 | 适合解决的问题 | 验收重点 |
|---|---|---|
| OPC UA | 工业互操作、信息模型、读写、订阅、事件与受控访问 | 节点命名空间、数据类型、读写权限、采样与发布参数、源时间戳、质量状态、证书和会话 |
| Modbus | 基于功能码与地址访问线圈、离散量和寄存器,常见于设备或网关侧 | 设备点表、站号、地址偏移、字节序、数据类型、缩放、轮询节奏、异常码和连接恢复 |
| MQTT | 经消息代理发布与订阅遥测或事件,便于多生产者和多消费者解耦 | 主题、载荷 Schema、QoS、会话与保留消息、持久化、积压、权限、重复和消费确认 |
| WebSocket | 在浏览器与服务端之间保持双向连接,适合页面消息推送 | 鉴权、心跳、断线检测、重连退避、缺口补拉、消息版本、背压和降级方案 |
OPC Foundation 的 OPC UA 介绍说明了信息建模、访问、订阅、事件和安全等能力;其中采样间隔描述服务器对数据源进行采样的节奏,不能直接等同于页面端到端延迟。实施时还应结合OPC UA 规范中的 SamplingInterval 说明与产品实现核对。
Modbus Organization 的规范目录提供应用协议与 TCP 消息实现资料。Modbus 不会自动说明每台设备的地址、数据类型、缩放和单位,因此厂家点表与现场验证仍是接入前提。
OASIS MQTT 5.0 规范定义了发布订阅和 QoS 等协议行为;QoS 0 可能丢失,QoS 1 可能重复,QoS 2 约束协议会话内的交付,不能替代消费端幂等与整条链路恢复设计。IETF RFC 6455定义 WebSocket 协议,但应用层重连、补历史、去重和消息语义仍由系统实现。
采集频率回答“源端多长时间产生或读取一次数据”,端到端延迟回答“一个已发生的变化多久能被目标应用看见”。两者之间还有网关轮询、订阅发布、网络排队、平台处理、数据库写入、接口缓存和页面渲染。只验收页面刷新动画,无法证明源数据足够新。
目标值应由生产、自动化、信息化、安全与应用负责人按场景共同确认。例如趋势看板、班组运营、故障告警和闭环控制的后果不同,不能共用一个“实时”数字。
网络恢复不代表数据自动完整。应先约定断线期间是丢弃、边缘缓存还是平台补拉;缓存满后如何处理;恢复后按原顺序补传还是优先发送最新值;实时流与历史补传如何区分。每条数据最好带可追溯的点位标识、源时间戳、序列或唯一键和质量状态,消费端再按业务规则去重。
同一条数据可能包含设备事件时间、网关采集时间、平台接收时间和数据库写入时间。项目应确定哪一个用于趋势和告警,其他时间用于排障,并统一时区、夏令时处理、精度和格式。现场时钟同步方案可根据环境选择 NTP、PTP 或既有时间服务,但必须记录时钟来源、漂移监测和失步处置。
数据质量至少要让应用识别正常、无效、离线、超量程、人工替代或来源不明等状态,不应仅以零值代替缺失值。国家标准全文公开系统中的GB/T 36344-2018《信息技术 数据质量评价指标》可作为建立质量评价维度的参考;具体字段、规则、阈值和责任仍需结合项目数据定义。
| 质量问题 | 需要定义 | 可验证证据 |
|---|---|---|
| 缺失 | 哪些点位应周期到达,事件型点位如何判断缺口 | 期望记录与实际记录对账、缺口清单 |
| 异常值 | 物理范围、业务范围、变化率及例外场景 | 越界样本、规则版本、处置日志 |
| 重复与乱序 | 唯一键、序列规则、迟到窗口和覆盖策略 | 重复注入、乱序注入后的存储与展示结果 |
| 时间不一致 | 时间戳来源、时区、同步方式和允许偏差 | 同一事件跨层时间对照、时钟状态记录 |
| 语义错误 | 单位、缩放、小数位、枚举和设备层级 | 点位字典、现场仪表与应用值对照 |
数据大屏、经营看板和数字孪生展示默认应按只读监控设计。协议具备写能力,不等于应用应该获得写权限。线圈或保持寄存器等可写对象、OPC UA 的写入或方法调用,都必须由设备、工艺与安全责任人确认。
如果业务确需反向控制,应单独开展风险评估和验收:控制命令白名单、身份和最小权限、网络区域与通道、操作确认、条件校验、超时与撤销、完整审计、通信失效行为、现场/远程优先级,以及与 PLC、DCS、SIS 等控制和安全逻辑的关系。展示系统不得替代现场安全联锁或安全仪表功能。
NIST SP 800-82 Rev. 3针对运营技术环境讨论了性能、可靠性和安全约束。ISA/IEC 62443 系列官方介绍强调工业自动化和控制系统在全生命周期中的角色与安全要求。项目可参考这些框架梳理网络分区、资产、身份、远程访问、日志、补丁和事件响应,但最终控制项要结合现场风险及适用要求确认。
验收表应包含指标定义、测试前提、目标值、采样方法、证据位置和责任人。下列项目提供结构,不提供通用固定阈值。
| 验收维度 | 定义方式 | 证据与注意事项 |
|---|---|---|
| 点位覆盖 | 已通过核验的点位数 ÷ 应接点位数,并按关键等级分组 | 签字版点位表、现场值对照;数量通过不代表语义正确 |
| 端到端新鲜度 | 源事件时间至应用可见时间的分布,可记录 P50、P95、P99 与最大值 | 统一时钟或校正误差;绑定负载、网络与测试时段 |
| 周期完整性 | 在约定周期和有效运行窗口内,实际有效记录与期望记录对比 | 区分停机、维护、事件型点位和质量无效记录 |
| 断线与恢复 | 离线识别、重连、缓存范围、补传完成和积压消化过程 | 断网脚本或记录、链路日志、恢复前后对账 |
| 重复与顺序 | 按唯一键、序列和业务时间统计重复、乱序及迟到处理结果 | 故障注入样本、消费端处理日志、最终存储结果 |
| 吞吐与突发 | 在约定点位、消息大小、频率和消费者数量下测试持续与突发负载 | 资源使用、积压、错误、降级及恢复曲线 |
| 稳定运行 | 按项目约定时长持续运行,统计断连、错误、积压、资源趋势与数据缺口 | 监控曲线、日志、巡检记录;时长由项目风险定义 |
| 安全反向测试 | 未授权读取、越权点位、无效证书、凭据失效、非白名单写入等应被拒绝 | 测试账号、请求与拒绝日志;不得影响生产安全 |
| 备份与恢复 | 从约定备份恢复配置、数据和服务,并核对可用性与缺口 | 恢复演练记录、校验结果、恢复依赖和人工步骤 |
| 适合 | 不适合或需另行评估 |
|---|---|
| 设备状态、能耗、产量、质量、报警等数据的监控与分析 | 需要确定性硬实时响应的闭环控制或安全联锁 |
| SCADA、MES、IoT 平台向数据大屏或业务系统提供数据 | 设备归属、数据使用权或网络接入授权尚不明确 |
| 智能工厂、园区、能源与数字孪生项目的数据底座验收 | 没有点位表、协议资料且拒绝开展现场验证 |
| 内网或私有化环境中的只读监控、历史趋势和异常追溯 | 把展示页面当作 PLC、DCS、SIS 的替代控制系统 |
| 需要明确交接、运维、断线恢复和数据质量责任的项目 | 只做一次性视觉演示且不承诺连接真实数据的原型 |
若目标是工厂经营、生产、设备与能耗信息的统一呈现,可结合智能工厂数据大屏方案定义业务层指标;若要落地界面与前端应用,可查看数据可视化大屏开发服务边界。涉及水质、过滤和泵阀状态时,可用净水工艺的数据与控制边界页面核对点位、质量状态和只读原则;涉及数据中心冷却循环时,可参考液冷系统循环、设备与告警页面梳理温度、压力、流量和设备对象。水务能源与储能一体化监控平台及前述页面均用于说明对象分层、监测指标与交付思路,不应解读为未经披露的已交付客户成果。
可先使用数据接口、样例数据与联调准备清单核对通用 API 资料,再补充本节的工业协议、点位和现场边界。接口未齐备时,可以先用少量真实点位完成技术验证,不能用长期模拟数据代替最终接入验收。
四者常处于不同链路位置,不必四选一。OPC UA 适合带语义、订阅和安全能力的工业互操作,Modbus 常用于按设备寄存器或功能码读写,MQTT 适合经代理发布与订阅遥测消息,WebSocket 适合浏览器与服务端保持双向连接。项目应按设备支持、数据语义、网络区域、可靠性和安全要求组合选用。
不一定。实时目标应由业务动作和风险决定,并区分源端采样、传输、处理、接口推送和页面刷新。趋势分析、经营看板、故障告警与闭环控制的时效要求不同,不能用一个固定数字覆盖全部场景。验收值应由项目各方书面约定。
不能把单段 MQTT 交付语义直接等同于整条业务链路保证。MQTT QoS 2 约束协议会话中的消息交付,但采集端、代理持久化、消费端处理、数据库写入和补传仍需分别设计。端到端验收还要检查唯一键、幂等、确认、重试、积压和故障恢复。
不会自动获得完整的业务级恢复能力。WebSocket 解决双向连接与消息传输,重连退避、会话恢复、缺口识别、离线缓存、历史补拉、去重和顺序处理需要由应用另行实现并测试。
技术上某些协议和设备支持写入,但展示系统不应默认拥有控制权。只读监控与反向控制应分开评估;如确需控制,应由业主的工艺、安全和自动化责任人确定隔离、授权、联锁、确认、审计和失效处理,且大屏不能替代 PLC、DCS 或 SIS 的现场安全逻辑。
应先区分设备事件时间、网关采集时间、平台接收时间和入库时间,再约定时区、精度、时钟同步、缺失值和漂移处理。验收时用可追溯事件对比各层时间戳,并同时检查乱序、迟到数据和跨系统时间差。
不是。内网和私有化部署只是边界条件,仍需按项目风险设计网络分区、身份认证、最小权限、凭据与证书、传输保护、日志审计、补丁、备份恢复和运维访问。是否适用等级保护或行业专项要求,应由建设方和安全专业人员判断。
可以先做调研和验证,但不宜直接承诺完整接入范围。项目应先取得设备与系统清单、点位表、协议资料、网络条件、样例报文、测试账号和责任人,并通过少量真实点位验证读取、时间戳、质量码、异常和权限,再确定计划与验收基线。
可先准备设备清单、点位表、网络拓扑、样例数据和责任人,再核对数据接入、展示与移交边界。