1.1 背景与协议定位
1.1 背景与协议定位
本节摘要：工业通信协议的分化源于现场层与系统层完全不同的约束——现场层要确定性，系统层要语义。Modbus 以极简问答扎根现场层，OPC UA 以信息建模统摄系统层，理解这层分化逻辑，是后续一切选型与集成决策的地基。
先讲一段往事
上世纪七十年代末，美国一家做工业控制的公司要解决一个具体烦恼：他们卖的 PLC 需要和别家的面板、仪表通信，每换一个合作伙伴就要重写一套驱动。工程师们的解法不是发明复杂的技术，而是把通信需求砍到不能再砍——规定一问一答的帧格式，让任何设备只要实现十几条指令就能对话。这就是 Modbus 的起点。它后来被公开、被模仿、被移植到无数单片机上，靠的不是标准组织的强力推行，而是"实现它太容易了"这个朴素的理由。
又过了二十多年，工业软件圈被另一个烦恼困住：不同厂商的控制系统各说各话，上层软件要接一个新设备就得重新开发接口。早期方案绑死了 Windows 的组件技术，跨平台无从谈起。于是行业重新立规，把"数据怎么传"和"数据是什么意思"分开对待，用一套与平台无关的架构统一两者——这就是 OPC UA 的由来。它的全名里那几个词经历了换血，但"让工厂数据可被任何软件理解"的目标从未变过。
这两段历史放在一起看，分化逻辑已经浮出水面：**现场层的问题是怎么让便宜、简单、大量的设备可靠对话，系统层的问题是怎么让不同的软件理解同一份数据的含义。**约束不同，答案自然不同。
学习目标
阅读完本节，你应当能够：
- 说出工业通信体系分层（现场控制层、过程监控层、系统集成层）各自的核心约束；
- 解释 Modbus"极简设计"与 OPC UA"语义建模"分别对应哪层约束；
- 画出一次典型数据流从传感器到云平台经过的协议转换链条；
- 用"确定性优先还是语义优先"这把尺子快速判断一个新场景该用哪套协议。
一、工业现场的分层约束
把一座工厂的通信需求摊开，会发现它天然分成三个世界。最底下是现场控制层：传感器、执行器、变频器、远程 IO，它们关心的唯一问题是"这一拍我的值变了没有，命令到了没有"。这里的时间尺度是毫秒级，设备算力以兆赫兹计，任何多余的协议开销都是奢侈品。中间是过程监控层：SCADA、HMI 在这个层面汇聚全厂点位，人要看画面、要设报警，时间尺度放宽到秒级，但数据点数量暴涨。最上面是系统集成层：MES、ERP、数字孪生平台，它们不关心某个寄存器的原始字节，它们关心"三号轧机的实时转速是多少、可信吗、谁有权改"。
三个世界对"通信"的要求完全不同，这正是协议分化的根本原因。现场层要的是确定性——任何一帧问答的耗时必须有上界，否则控制回路会震荡；系统层要的是语义——数据必须自带含义，否则每个软件都要为每种设备配一个翻译。让一套协议同时伺候两个主人，要么把现场层拖垮（语义开销巨大），要么把系统层饿死（只有字节没有含义）。
分层约束还解释了一个反直觉的现象：为什么最新的协议没有淘汰最老的协议？因为四十多年过去，现场层的物理约束几乎没变——传感器依然便宜、总线带宽依然有限、控制周期依然以毫秒计。Modbus 的极简恰好贴合这些约束，它没有过时的理由。
二、Modbus：现场层的极简问答
Modbus 的设计哲学可以压缩成一句话：**通信就是寄存器的问与答。**主站想知道某个温度，就发出一帧"读 3 号从站、功能码 03、起始地址 30011、数量 2"；从站回一帧"这是两个寄存器的原始字节"。没有会话、没有握手、没有元数据，一个数值从 A 设备到 B 设备，中间不附加任何解释。
这种设计带来三个直接后果。第一，实现门槛极低，几十行代码就能在八位单片机上跑起来，这让 Modbus 渗透进了几乎所有带通信口的工业设备。第二，通信开销极小，一帧最短只有几个字节，在 9600 波特率的串口上也能跑出毫秒级响应。第三，也是代价——协议本身不携带任何语义。30011 里是温度还是压力、单位是摄氏度还是华氏度、小数点在哪，协议一概不知，全靠点表文档约定。点表一旦丢失或写错，数据就成了天书。
一次典型的 Modbus RTU 问答（十六进制，人读注释版） 主站问：01 03 02 00 02 B6 09 │ │ └─┴── 起始地址 0x0200（点表写作 40001 偏移） │ └────── 功能码 03：读保持寄存器 └───────── 从站地址 01 从站答：01 03 04 09 C4 0A 8B xx xx │ │ │ └────── └────── 两个寄存器的原始值 │ │ └────────── 字节计数：4 字节 │ └───────────── 功能码回显 └──────────────── 从站地址回显
看懂这段报文不需要任何工具，这正是 Modbus 的美德：一切都在明面上。但你也注意到了，"09 C4"是温度还是电流，报文里没有任何线索——语义缺失的问题在这里已经埋下，第 2 章会正面处理。
三、OPC UA：系统层的语义统摄
OPC UA 对"通信"的理解完全不同。它认为数据不应该裸奔，每个值都应该带着自己的身份证明出场。在 OPC UA 的世界里，数据被组织成一棵地址空间树：一个电机是一个对象，对象下面挂着转速、温度、运行状态等变量，每个变量自带单位、量程、时间戳、质量戳，还有访问权限。客户端读到的不只是"2500"这个数，而是"三号电机转速，单位转每分，当前值 2500，采样时间某时某刻，质量良好"。
为了支撑这种表达，OPC UA 的协议栈比 Modbus 复杂得多：底层要支持多种传输绑定，中间有编码层与安全层，上层是几十种标准化服务（读、写、浏览、订阅、方法调用）。代价是实现门槛和资源开销显著上升——一个完整的 OPC UA Server 需要的内存和算力，是 Modbus 从站的成百上千倍。把它塞进一颗两块钱的温湿度芯片里既不现实也无必要。
于是合理的分工自然形成：**Modbus 在最底层采集，OPC UA 在中间层整合。**边缘网关把成片的 Modbus 设备聚拢，翻译成带语义的 OPC UA 变量，向上暴露给一切需要"懂含义"的软件。翻译过程不只是字节转发，更是语义注入——这正是第 4 章的主题。
图2 三层数据流与协议分工示意
四、用一把尺子做快速判断
日常工作中遇到新场景，可以先用一个最简判断：**这个场景首先怕什么？**怕迟到，选确定性路线；怕不懂，选语义路线。振动 台的控制回路一拍都不能迟——确定性优先；能耗报表要求分清"这是哪台设备的哪个物理量"——语义优先。怕迟到的场景交给 Modbus 或硬实时总线，怕不懂的场景交给 OPC UA，两头都怕的（比如运动控制数据的云端孪生）就做分层设计，各用各的。
这把尺子当然粗糙，但它方向正确。1.2 节会把"怕迟到""怕不懂"拆成实时性、语义、安全、成本等六个维度逐项打分，1.3 再扩展到四协议选型。本章之后的所有章节，都是在为这把尺子提供机理支撑。
本节带走四条
- 分化根源：现场层与系统层的约束不同，前者要确定性，后者要语义，没有万能协议；
- Modbus 定位：极简问答换取超低实现门槛与开销，代价是协议不携带任何语义；
- OPC UA 定位：数据自带单位、量程、权限与时间戳，用复杂度换取跨系统互理解；
- 典型架构：Modbus 设备经边缘网关语义注入后以 OPC UA 形态向上暴露，这是存量产线数字化的主干路径。
下一节把两套协议摆上同一张对照表，逐维度看清差异从何而来。