工业通信协议：Modbus、OPC UA 解析

Modbus 之所以能活到今天，靠的是极致的简单。它只有一主多从的问答模型：主站发一帧请求，从站回一帧响应，没有握手协商，也不存在从站主动上报。协议本身定义了四种数据区：线圈（可读写位）、离散输入（只读位）、输入寄存器（只读 16 位）、保持寄存器（可读写 16 位）。所有读写操作都围绕这四个区展开，地址在报文中以零基偏移表示，而厂商手册里常常写成 40001 这样的“五位数地址”——40001 对应保持寄存器的第 0 个，这个换算关系是新手最容易踩的坑之一。

传输形态上，Modbus 有 RTU、ASCII 和 TCP 三种。RTU 走在 RS-485 双绞线上，二进制编码、报文紧凑、抗干扰好，是目前现场最常见的一种；TCP 则把 RTU 帧前面套上 7 字节的 MBAP 头，跑在以太网上，端口号固定为 502。下面这段 Python 代码是现场调试最常用的脚手架，用 pymodbus 读一组保持寄存器并把它还原成 32 位浮点数。

from pymodbus.client import ModbusSerialClient

# 串口参数与现场仪表对齐：9600 波特率、8 数据位、无校验、1 停止位
client = ModbusSerialClient(
    port="COM3", baudrate=9600, bytesize=8,
    parity="N", stopbits=1, timeout=1
)
client.connect()

# 从站地址 1、起始寄存器 0、连续读取 10 个保持寄存器
rr = client.read_holding_registers(address=0, count=10, slave=1)

if not rr.isError():
    regs = rr.registers
    # 常见约定：一个 32 位浮点占用两个寄存器，高字在前
    for i in range(0, len(regs) - 1, 2):
        value = client.convert_from_registers(
            regs[i:i + 2], client.DATATYPE.FLOAT32, word_order="big"
        )
        print(f"偏移 {i} 的浮点值 = {value:.3f}")
else:
    print("读取失败：", rr)

client.close()

这段代码能跑通，说明四件事同时对了：串口参数一致、从站地址正确、寄存器地址没有偏移错位、字节序符合厂商约定。反过来说，现场采集失败的原因九成也落在这四项里。特别提醒：Modbus 协议本身不定义数据类型，寄存器里装的是整数、浮点、还是十几个布尔量的位组合，全靠厂商手册约定。因此点表（tag table）就是工程落地的核心资产，它把“偏移 12 的两个寄存器”翻译成“1 号反应釜夹套温度”，这张表错一行，数据就错一路。

Modbus 的时代使命是让设备能被读写，它从来没有打算承担信息建模的职责。于是当工厂希望把数据交给 MES、能源管理系统或算法平台时，问题就集中暴露出来：协议只回答“第几个寄存器现在是多少”，不回答“这是什么、单位是什么、是否可信、什么时候采到的”。

• 没有内建认证与加密。任何能连上 502 端口的人都可以写保持寄存器，一个格式正确的报文就能改动设定值。
• 没有数据类型定义。32 位整数的高低位顺序、浮点的字序，各厂商各有习惯，甚至同一厂商不同型号都不一致。
• 没有订阅机制。数据只能靠主站轮询获取，采集周期越短，总线负载与从站 CPU 压力越大。
• 没有时间戳与质量码。采集到的值是一个“现在的快照”，没有采集时刻，也无法表达“通信中断，值不可信”这类状态。

这四条不是 Modbus 的缺陷，而是它的定位。正因为协议轻，它才能在只有几 KB 内存的仪表里跑得又快又稳。但也正因为这四条，当系统规模从“一台设备接一个触摸屏”扩展到“上千点位接入统一平台”时，就必须引入一层更强的语义层。

OPC UA 与 Modbus 的最大区别，是它把“值”升级成了“节点”。每个数据点都是地址空间树上的一个 NodeId，形如 ns=2;s=Device1.Temperature。这里的 ns 是命名空间索引，标准定义的内容放在 ns=0，厂商自定义的内容放进自己的命名空间，从根本上避免了“同一个名字在不同设备上含义不同”的冲突。节点不只带值，还带数据类型、工程单位、访问权限、最小采样间隔、时间戳与状态码。

更关键的是订阅机制。客户端可以告诉服务端“这个节点变化超过阈值就通知我”，服务端在采样周期内发现变化才推送，带宽占用与 CPU 消耗从“定时炸弹”变成“按需唤醒”。下面这段代码用 asyncua 客户端浏览服务端节点并订阅一个温度点的变化事件。

import asyncio
from asyncua import Client

ENDPOINT = "opc.tcp://192.168.1.20:4840"

class SubHandler:
    # 数据变化回调：只有值真正变化时才会被触发
    def datachange_notification(self, node, val, data):
        print("变化推送:", node, val)

async def main():
    async with Client(url=ENDPOINT) as client:
        # i=2258 是标准定义的 ServerStatus 节点，用来确认连接可用
        print("ServerState:", await client.get_node("i=2258").read_value())

        # i=85 是 Objects 目录，向下浏览即可找到设备节点
        objects = client.get_node("i=85")
        for child in await objects.get_children():
            print(await child.read_browse_name())

        # 500ms 采样周期，仅在变化时推送
        node = client.get_node("ns=2;s=Device1.Temperature")
        sub = await client.create_subscription(500, SubHandler())
        await sub.subscribe_data_change(node)
        await asyncio.sleep(30)

asyncio.run(main())

需要强调的是，OPC UA 提供的是语义与安全，而不是实时的运动控制。它的安全通道基于 X.509 证书，支持签名与加密，这解决了 Modbus 完全裸奔的问题；但它的报文开销远大于 Modbus，典型往返时延在毫秒级，用来做伺服轴的同步控制并不合适。工程上的惯例是：现场层继续用实时协议，把 OPC UA 放在设备层与信息层之间。

没有人会为了统一协议而停掉一条正在赚钱的产线。现实中最可行的路径是在中间加一台协议网关：南向用 Modbus RTU/TCP 采集现场设备，北向用 OPC UA Server 暴露标准化的节点树。网关自带缓冲区，网络抖动时先落地，恢复后补传，避免因为一次断网丢掉整段时间序列。

网关的实施顺序值得固定下来，按这个流程走能避免大半返工：

• 点位梳理：把厂商手册里的地址、数据类型、字节序、量程、单位整理成点表，先在 Excel 里对齐，再进网关配置。
• 类型映射：把 Modbus 的裸寄存器组装成 INT16、INT32、FLOAT32、BOOL 等类型，并明确字序与字节序。
• 命名空间规划：按产线—设备—点位的层级设计 NodeId，避免后期点位增加导致结构混乱。
• 质量码与时间戳补齐：通信失败时置质量码为 Bad，而不是继续沿用上一次的值，否则上层会拿旧数据做决策。
• 采集周期分级：温度、液位这类慢变量 1～5 秒一次即可，报警与联锁信号必须 100～500 毫秒级。