03-一个开放标准的身世

1.3 一个开放标准的身世

本节摘要：1979 年出生的私有协议，凭什么在四十五年后仍是工业默认选项？本节讲 Modbus 从 Modicon 内部协议到公开文档、再到标准化组织的历程，并澄清"免费"与"标准"两个概念。位置：1.2 讲清了工作模型，本节补上"合法性"这一课——为什么可以放心用它做产品。

从 Modicon 车间到公共文档

1979 年，Modicon（莫迪康，PLC 发明者之一）在自己的可编程控制器上定义了这套通信协议，用于 PLC 与编程器、HMI 之间的数据交换。当时它完全是私有协议——别的厂商的设备无法接入，这是那个年代的常态：协议即护城河。

转折发生在协议公开之后。Modicon 把规范以公开文档形式发布，任何厂商都可以免费实现。对设备厂商来说，给自己的产品加一个 Modbus 口，等于瞬间获得与市场上绝大多数 PLC/HMI/组态软件互通的能力；对用户来说，多厂商设备可以挂在同一条线上，不再被单一供应商锁死。开放的早期红利让 Modbus 的装机量滚雪球式增长，等到后来者想用收费协议取代它时，存量市场的惯性已经无法撼动。

标准化组织的接力

Modbus 的"标准身份"经过了三代接力：先是 Modicon 持有并公开文档；2000 年前后 Modbus-IDA（Modbus 用户组织）接手维护，推动协议从"公开文档"走向"组织化标准"；如今由 Modbus Organization（modbus.org）管理，规范在官网免费下载，包括 Modbus Application Protocol V1.1b3 与 Modbus Messaging on TCP/IP 两份核心文档。

需要澄清的一个常见误解："免费"不等于"无治理"。Modbus 有明确的规范版本、功能码分配表（如 100-110 用户自定义区）与一致性测试（Conformance Test），厂商声称"支持 Modbus"前最好先跑一致性测试，否则可能出现"能通但不标准"的野实现。

为什么简单成了护城河

工程师对 Modbus 的第一印象往往是"这也叫协议"——没有复杂的握手、没有状态机、没有对象模型。但正是这份简单构成了三重护城河：实现门槛低（一颗 8 位单片机加个串口就能跑，几乎所有芯片都有现成库）；排查直观（报文就是"地址+功能码+数据+校验"，示波器与串口助手就能看）；迁移成本为零（从 8 位 MCU 到工业 PC，同一套报文语义不变）。

对比同期协议的结局更有说服力：Profibus 功能更强但有授权费用与配置工具门槛；FF 基金会现场总线理想更丰满但生态封闭；Modbus 用"够用"换来了"无处不在"。工业界的演进规律是：能解决 90% 问题且人人都会用的方案，会打败能解决 99% 问题但只有专家用得起的方案。

一致性测试：声称支持与真正支持的鸿沟

Modbus 的开放性带来一个副作用：谁都可以声称"支持 Modbus"，实现质量参差不齐。为此 Modbus Organization 提供一致性测试（Conformance Test），验证设备的实现是否符合规范。测试覆盖：帧格式、地址范围、功能码支持矩阵、异常码行为、广播处理、CRC/LRC 正确性等。

对设备采购方，一致性测试报告是重要的选型依据——没有报告的设备，接口"看起来能通"，但可能在边界行为上埋雷（例如地址越界时该回异常却沉默、写线圈值传 0x0001 时该拒绝却接受）。对设备厂商，通过一致性测试是进入主流 HMI/组态软件兼容列表的前提。工程建议：采购关键仪表前索要一致性测试报告；自研从站设备时用官方工具或社区工具（如 Modbus conformance tester）自测。

版本与兼容性：老协议的新麻烦

Modbus 规范本身也在演进：功能码分配在扩展（43/MEI 封装接口、用户自定义区 100-110 的规范管理）、Modbus/TCP 的 MBAP 与安全扩展（Modbus/TLS）陆续补充。向后兼容是 Modbus 的立身之本——1990 年的从站设备今天仍能被新主站正确读写。但兼容不等于"随便实现"：新功能码（如 43/14 读设备标识）老设备可能不支持，程序要按设备能力矩阵降级处理，不能假设所有设备都支持所有功能码。

从协议到生态：配套工具的价值

Modbus 的长寿还在于它长出了一个完整生态：调试工具（Modbus Poll/Slave、串口助手）、抓包分析（Wireshark 对 Modbus TCP 有完整解析）、网关产品（串口转 TCP、Modbus 转 OPC UA/MQTT）、开源库（libmodbus、pymodbus、ModbusMaster for Arduino）。生态意味着学习资料、现成代码与可替代供应商——一个协议有三十年的工具积累与多家开源实现，企业才敢把它写进十年期的产品路线图。

一份时间线速览

把时间线压缩成一句话：从私有到公开，从串口到以太网，治理一直在、免费从未变。

易错点补充

• 拿旧文档当规范：Modbus Application Protocol V1.1b3 是现行主文档，网上流传的早期翻译与附录可能过时；
• 忽略厂商私有扩展：很多设备在标准之外加了私有寄存器区（地址 0x8000+ 等），读私有区要按厂商文档，别用标准语义硬套；
• 不跑一致性测试就验收：验收阶段用一致性测试用例过一遍设备，能在"上产线前"而不是"出事故后"发现实现缺陷。

易错点清单

• 以为 Modbus 有专利费：规范免费、实现免费、无需授权，这是它与很多"开放"标准最实质的区别；
• 拿旧版本文档开发：功能码分配与一致性测试按当前规范版本走，用网络流传的旧译文可能与新设备不兼容；
• 把"支持 Modbus"当免检标签：不同厂商对数据模型、字节序、地址方言的实现有差异（第 2 章展开），声称支持不等于互联互通。

要点回顾：私有协议公开化赢得存量；标准化组织接力保证治理；简单构成三重护城河；免费不等于免检。身世清楚后，下一章进入第一张实战地图——寄存器点表，看设备的数据到底存在哪里、怎么读。

实战复盘：采购谈判桌上的"协议税"

某项目招标，供应商 A 报价里含"Profibus 授权费与配置工具许可"，供应商 B 说"支持 Modbus，免费无授权"。同样的设备、同样的功能，B 便宜了约 15%。甲方技术负责人据此把协议选型写进评标条款：必须支持 Modbus，可选支持其他总线——理由是 Modbus 免授权、开源库多、后续替换供应商零迁移成本。这个案例说明：协议的"身世"不只是历史故事，它直接换算成采购成本与供应链自由度，是选型时真实的加分项。

从规范到实现：一份迷你规范怎么读

Modbus 规范文档（Application Protocol V1.1b3）大约几十页，比大多数工业协议薄得多。读规范的正确姿势不是通读，而是按功能码查表：需要实现 03 读保持寄存器时，翻到对应章节看请求/响应的字节布局、边界条件（地址范围、数量上限）与异常行为。规范里最容易被忽略的是"实现须知"部分——比如写线圈必须用 0xFF00/0x0000、广播地址 0 不应得到应答。把实现须知逐条对照自己的代码，能避免大量"按主流通用库写但设备不理你"的兼容性问题。