4. 工业通信协议概览

在 ThingWorx 设备接入工程中，协议选型不是“哪个先进选哪个”，而是由现场设备能力、数据时效、网络拓扑、IT/OT 边界和安全要求共同决定的。ThingWorx 本身并不直接“说”所有工业协议，它通过工业连接组件（Industrial Connectivity，基于 Kepware）或 Edge SDK 把现场协议转换为统一的数据模型，再经 AlwaysOn/WebSocket 或 REST 进入平台。因此理解每种协议“解决什么问题、代价是什么”，是接入方案设计的第一步。

一、六种协议的定位差异

Modbus（RTU/TCP）是最基础的请求—应答式协议，以寄存器地址为核心：线圈（0x）、离散输入（1x）、输入寄存器（3x）、保持寄存器（4x）。它简单、通用、几乎被所有 PLC 和仪表支持，但只有地址没有语义，没有数据类型定义，没有时间戳，也没有安全机制。适合采集点位少、变化慢、对语义要求不高的场景，例如电表、温控器、变频器频率读取。

OPC UA是面向信息建模的协议，自带地址空间、类型系统、时间戳和质量码（Quality），支持订阅（Subscription）与监控项（MonitoredItem），并可通过证书实现加密与身份认证。它适合作为车间级数据汇聚与语义化建模的主干，尤其是需要把设备数据映射为有名称、有单位、有层级的对象时。

MQTT是发布/订阅模型，基于 Broker 解耦生产者和消费者，报文极小，支持 QoS 0/1/2 和遗嘱消息，天然适合带宽受限、连接不稳定的远程场景。它不定义数据语义，需要约定 Topic 结构和 Payload 格式（常用 JSON）。

HTTP/REST是请求—应答的通用协议，适合设备主动上报或平台主动拉取，调试方便、工具链成熟，但轮询开销大、实时性弱，通常用于非实时数据、配置下发或与第三方系统集成。

S7 通信（S7comm/S7comm Plus）是西门子 S7-300/400/1200/1500 的原生协议，可直接访问 DB 块、I/Q/M 区，效率高、无需在 PLC 侧额外编程，但强绑定西门子生态，跨品牌不通用。

EtherNet/IP基于 CIP，运行在 TCP/UDP 之上，采用生产者/消费者模型，支持隐式（I/O）实时报文和显式（配置）报文，是罗克韦尔（Allen-Bradley）体系的主流选择，适合高频、确定性要求较高的控制层数据采集。

二、选型依据：先看设备，再看需求

实际工程中，选型顺序建议是：设备原生协议优先。如果 PLC 是 S7-1500，直接用 S7 驱动比加装 Modbus 网关更省成本、更少故障点；如果是 Allen-Bradley，EtherNet/IP 是自然选择。强行转换协议会引入额外硬件和延迟，也增加排障难度。

当设备支持多种协议时，再按需求排序。以下判断表可作为现场快速决策参考（示例参数，实际以设备手册为准）：

三、接入 ThingWorx 时的关键配置要点

以 Modbus TCP 采集一台电表为例，在 Kepware 中新建通道选择 Modbus TCP/IP Ethernet，设备 IP 设为 192.168.1.50，端口 502，站号 1。然后按电表手册定义标签：电压为 Holding Register 40001，数据类型 Float，字节顺序需按设备实际调整（常见 ABCD 或 CDAB）。若读回值为 1.2e-38 之类的异常数，多半是字节序或寄存器合并方式不对，应优先核对这两项，而不是怀疑网络。

OPC UA 接入时，重点是端点（Endpoint）选择与安全策略。若使用 Basic256Sha256，需要在 Kepware 与设备之间交换并信任证书；调试阶段可临时用 None 策略验证连通性，但生产环境必须启用签名加密。订阅时合理设置 Publishing Interval 和 Sampling Interval，采样过快会显著增加 PLC 负载。

MQTT 接入通常走 Edge SDK 或第三方网关。Topic 建议按 factory/line1/device01/telemetry 分层，Payload 用 JSON 并携带时间戳和质量码。QoS 选择上，遥测数据用 QoS 0 或 1，告警和命令用 QoS 1 或 2。断网时边缘侧应本地缓存，恢复后按时间顺序补传，避免数据空洞。

// MQTT 遥测 Payload 示例（示例数据）
{
  "ts": "2025-03-18T10:23:45.120Z",
  "deviceId": "METER-001",
  "voltage": 220.4,
  "current": 5.12,
  "power": 1128.4,
  "quality": "Good"
}

四、常见误区与排障方向

第一个误区是“协议越新越好”。OPC UA 功能强，但配置复杂、证书管理有运维成本，若只是读几个电表寄存器，Modbus 反而更稳。第二个误区是忽视字节序和数据类型，导致数值完全错误却误判为通信故障。第三个误区是把 MQTT 当作实时协议，实际上 Broker 转发和网络抖动会带来秒级延迟，不适合闭环控制。

排障时建议按“物理层—协议层—数据层”逐级确认：先 ping 通、端口通，再用协议调试工具（如 Modbus Poll、UaExpert、MQTTX）直接读设备，确认原始数据正确后，再检查 Kepware 标签映射和 ThingWorx 属性绑定。这样能把问题定位在正确的层级，避免在平台侧反复修改却找不到根因。

最终，协议选型的落脚点是：让数据以可接受的成本、可维护的方式、满足业务时效地进入 ThingWorx，并在平台内形成统一、可复用的设备模型。协议只是通道，模型才是资产。