五种工业通信协议各司其职：从 PROFINET 到 MQTT

简要结论：

当 PLC 或运动控制器需要与机器人、驱动器、I/O 设备周期性地交换时序可预测的过程数据时，通常考虑

PROFINET、EtherNet/IP 或 EtherCAT

。当上层软件需要带有清晰结构和含义的设备信息时，考虑

OPC UA

；当多个应用需要通过发布/订阅消息代理接收事件和遥测数据时，考虑

MQTT

。这五种技术并非互相替代：同一座工厂完全可以同时使用多种协议。选型首先要看现有控制器、已安装的通信选件与许可证、实际数据流以及通信中断的后果，而不是宣传资料中的单一速度指标。

工程指南更新于 2026 年 10 月 13 日。本文依据标准组织和技术文档进行比较，不包含实验室性能测试，也不构成对任何具体 PLC 与机器人型号组合的兼容性认证。

快速选择：五种工业通信技术分别适合什么？

实用原则：

不要试图给整座工厂只选一种协议，而应当

逐个接口决定

。例如，PLC 通过 PROFINET 控制机器人；边缘网关读取 OPC UA 信息，再把选定的生产事件发布到 MQTT。

都使用以太网，为什么还不能相互替换？

工业以太网是多种技术的统称，不是一套可以直接混用的通信语言。即使设备使用类似 RJ45 的接口、相同类型的网线，甚至部分共享网络基础设施，也不代表彼此能够通信。设备角色、协议栈、定时机制、寻址方式和应用数据格式可能完全不同。

关键区别是

周期性控制数据

和

上层监控信息

。前者需要不断刷新，让控制器根据当前输入输出执行设备动作顺序。后者主要用于需要历史记录、上下文和数据含义的软件，例如制造执行系统（MES）、SCADA、维护平台和分析系统。

机器人可能在每个配置好的 I/O 更新周期内接收新的 PLC 命令字；而生产看板通常只关心机器人何时开始工作、何时完成一个零件以及何时发生故障。把所有生产事件强行放入周期性 I/O 映射，会增加不必要的集成成本；反过来，把普通 MQTT 消息当作时间关键型设备联锁的唯一依据，则是架构错误。

确定性不等于单纯的高速度。

对控制系统而言，时间行为是否可预测、延迟是否有明确边界，与平均吞吐量同样重要。实际响应时间还包括网络更新、PLC 任务调度、机器人控制器处理和应用逻辑。一张速度很快的网络无法弥补设计不合理的控制流程。

1. PROFINET：PLC 自动化系统中的周期性控制

PROFINET

由 PROFIBUS & PROFINET International（PI）维护，面向工业自动化的周期性过程数据交换、诊断与工程配置。常见架构中，PLC 充当

IO-Controller

，机器人控制器或远程 I/O 站充当

IO-Device

，双方按配置交换输入和输出数据。

PROFINET 如何工作？

PROFINET 支持用于周期 I/O 的实时通信。常见类别包括适用于许多一般自动化任务的

RT（Real Time）

，以及在设备支持时面向更严格同步需求的

IRT（Isochronous Real Time）

。PI 还在推进与时间敏感网络（TSN）相关的 PROFINET 能力。这些功能不能只凭产品介绍上的勾选项判断：控制器、设备、固件以及实际网络设计都必须明确支持相应能力。

除周期 I/O 外，工程师还会使用设备识别、报警、诊断和参数设置功能。设备集成通常需要

GSDML

文件，这是基于 XML 的 PROFINET 设备描述，向工程软件说明模块、数据长度和支持的能力。

示例：通过 PROFINET 连接 PLC 和机器人

PLC 可以发送运行许可条件、程序号和启动请求；机器人返回就绪、忙碌、完成和故障信息。接口信号协议需要明确每个比特的含义、归属方以及中断后如何恢复。PROFINET 负责传输字节，

但不会替机器人厂家定义应用层握手逻辑

。

何时选 PROFINET：

当工厂控制系统已经采用 PROFINET、机器人控制器具备所需 IO-Device 角色，并且 PLC 工程环境支持其确切 GSDML 与 I/O 配置时。支持 PROFINET 并不表示自动具备 PROFIsafe、IRT 或运动控制功能。

2. EtherNet/IP：基于 CIP 的工业通信

EtherNet/IP

由 ODVA 维护，通过标准以太网和互联网协议传输

Common Industrial Protocol（CIP）

，用于交换设备 I/O 与诊断信息。虽然名称相似，EtherNet/IP 既不是泛指任何以太网连接，也不能自动与 PROFINET 互通。

周期 I/O 与显式消息有什么区别？

CIP 将 I/O 数据交换（通常称为

Implicit Messaging，隐式消息

）与通过请求/响应访问设备对象（

Explicit Messaging，显式消息

）区分开来。周期性 I/O 通常使用 UDP，显式消息通常使用 TCP。I/O 连接传输的是一组组字节（Assembly），其含义由设备发布的数据模型和具体配置决定。

在典型 PLC–机器人连接中，PLC 是

I/O Scanner

，机器人侧接口是

Adapter

。具体名称和支持的连接方式可能因厂商与产品代际不同而变化。

EDS（Electronic Data Sheet）

文件有助于工程配置，但还应核对 Assembly 实例、输入输出长度、连接路径和请求数据包间隔（

RPI

）。有 EDS 并不代表可以完全自动完成集成。

ODVA 还定义了 CIP Safety、CIP Motion、CIP Sync 和 CIP Security 等相关服务。

这些能力属于 CIP 技术家族，不代表某台机器人控制器一定支持。

何时选 EtherNet/IP：

当 PLC 与网络架构以 CIP 为基础，机器人或末端执行器支持正确的 Adapter 角色，并且已经确认数据尺寸、Assembly 映射和更新要求时。能 Ping 通只能证明 IP 可达，不能证明周期 I/O 连接已经建立。

3. EtherCAT：帧经过设备时直接处理数据

EtherCAT

由 EtherCAT Technology Group（ETG）推动，采用不同的过程数据交换机制。

MainDevice

向通信段发送 EtherCAT 帧，各个

SubDevice

在帧经过时读取分配给自己的输出数据，同时写入输入数据。这种

On-the-fly

（边通过边处理）方法减少对每台设备反复单独通信的开销，适合要求较高的分布式控制。

EtherCAT 为什么不是普通 TCP/IP？

标准 EtherCAT 过程数据帧使用以太网帧格式，通常通过 EtherType

0x88A4

标识；

它们不是普通 TCP 或 UDP 数据包

。办公网络交换机、IP 路由器或 MQTT Broker 不能想当然地放入 EtherCAT 实时通信段。网络拓扑和硬件必须符合设备及应用要求。

Distributed Clocks（DC，分布式时钟）

机制可以让兼容设备进行时间同步，尤其适合多个伺服驱动器之间的协调。但有同步时钟并不意味着任意机器人之间就能自动实现协调运动。

工程配置通常使用

ESI（EtherCAT SubDevice Information）

XML 文件。集成时必须检查过程数据对象、支持的运行状态、同步模式、物理端口和固件兼容性；部分功能还需要厂商专有实现。

何时选 EtherCAT：

当设备平台本身基于 EtherCAT，确实需要同步或分布式运动，并且所有设备（包括可能接入的机器人接口）都支持所需角色和功能时。不要因为某个宣传周期时间很短就直接选用。

4. OPC UA：让机器数据不仅有数值，还有含义

OPC Unified Architecture（OPC UA）

由 OPC Foundation 维护，是一种跨平台工业通信架构。它可以用信息模型表示设备、属性、关系与方法，让应用程序能够浏览并理解数据。常见模式为客户端/服务器；具备相应实现时也可使用发布/订阅。标准还定义了身份认证、加密和授权机制。

信息模型为什么重要？

假设 MES 需要获取机器人的运行模式、当前程序、激活的报警以及累计产量。一个原始 PLC I/O 数组可能只给出字节偏移和位号。OPC UA 服务器则可以提供有名称的对象、数据类型和对象关系。集成商仍需理解具体模型，但不必只能面对缺乏语义的字节表。

针对机器人，

OPC 40010-1：OPC UA for Robotics – Part 1: Vertical Integration

定义了面向上层系统的标准信息模型。官方参考资料列出的是

2025 年 9 月 8 日发布的 1.02 版

。机器人厂家声称支持 OPC UA，并不保证已经实现这套 Companion Specification，更不意味着所有可选对象都具备。

OPC UA 只能用于监控吗？

不能这样理解。OPC UA 支持读、写、方法调用和发布/订阅。OPC Foundation 的

Field Level Communications / OPC UA FX

工作还将其扩展到现场层通信，包括实时需求。因此，在传统机器人工作站中，OPC UA 虽然经常位于控制网络之上，但不能笼统地说它不具备工业控制能力。要承担具体控制任务，仍必须核实设备所支持的配置文件和经过验证的时序表现。

何时选 OPC UA：

当不同平台需要可发现、可理解且受保护的设备数据时。应配置证书、认证方式、用户权限、安全 Endpoint，以及明确的读写边界。存在 OPC UA 接口不等于 MES 被允许直接命令机器人运动。

5. MQTT：向多个系统分发生产事件

MQTT

是 OASIS 标准化的发布/订阅消息协议。设备或边缘应用向一个

Topic（主题）

发布消息，消息代理（Broker）将它分发给订阅者。发布端不需要分别连接每一个看板、数据库和分析服务。

一个实际可读的 Topic 与 JSON 示例

例如，网关可以向

factory/bilbao/cell-03/robot-01/status

发布如下示例数据：

{
  "schema_version": 1,
  "asset_id": "robot-01",
  "timestamp_utc": "2026-10-13T12:00:00Z",
  "state": "running",
  "program_id": "job-024",
  "parts_completed": 1842,
  "source_quality": "good"
}

以上仅为说明性数据，不是实际设备测量结果。

MQTT 本身没有定义

state

、

program_id

或

parts_completed

的含义。集成协议必须规定单位、数据类型、时间戳、事件 ID、数据责任方、Schema 版本，以及订阅者如何识别过期数据。

MQTT 的 QoS 到底保证什么？

• 
  QoS 0：
  
  在 MQTT 投递层面最多一次；消息可能丢失。
• 
  QoS 1：
  
  在 MQTT 投递层面至少一次；消息可能重复。
• 
  QoS 2：
  
  针对相关 MQTT 消息交换实现恰好一次投递，但有更大的协议开销。它
  
  不保证
  
  下游数据库事务或机器人实际动作恰好执行一次。

保留消息（Retained Message）便于显示最后一次发布的状态，但这个状态可能已经过期。持久会话、重试和消息有效期也需要谨慎设置。建议结合时间戳、新鲜度规则，并在需要时使用事件 ID 或幂等键。安全方面，应使用认证客户端、适用时启用 TLS、为 Topic 配置访问控制列表，并限制对 Broker 的连接。

何时选 MQTT：

当需要将设备事件、维护报警或历史遥测数据分发给多个系统时。云平台能向某个 Topic 发消息，并不能替代经过验证的 PLC–机器人周期命令接口及安全功能。

五种技术如何在一套机器人工作站中协同工作

以一套包括工业机器人、PLC、夹爪、传感器和生产看板的包装工作站为例。合理的方案会划清职责：

1. 
   机器控制：
   
   PLC 通过支持的周期性现场总线接口与机器人交换命令和状态；机器人控制器执行经过验证的机器人程序。附加驱动器与 I/O 可以使用同一现场总线，也可以使用其他现场网络。
2. 
   功能安全：
   
   独立设计的安全系统监控防护设备和安全停止功能。根据风险评估，可采用经过安全认证的硬接线 I/O 或受支持的安全通信协议。
3. 
   结构化运行数据：
   
   机器人控制器、PLC 或工业网关通过 OPC UA 对外提供选定的状态与诊断信息，写入权限受到控制。
4. 
   事件分发：
   
   获授权的网关将选定的状态变化转换成 MQTT 事件并发送给 Broker，不让 Broker 成为机器正常控制闭环的必要环节。
5. 
   业务应用：
   
   MES、维护和分析平台利用这些数据进行追溯、OEE 分析及故障排查。

这只是示例，而非唯一架构。有些工厂直接将 PLC 数据送到 MES，有些使用工业 Historian，也有些仅用 OPC UA 而不使用 MQTT。网关必须解决实际集成问题，不应只是增加一个可能故障的服务。

PLC–机器人握手：一个可以落地的设计示例

协议负责传输信号，而

接口契约

决定设备应如何行动。以下以一次机器人抓取和放置循环为例。信号名和方向仅用于解释，并非通用标准，也不是任何厂商的实际 I/O 表。

可能的流程：

PLC 先确认普通运行前提，选择程序，给出新的命令 ID，然后提出循环请求。机器人确认接受了哪个 ID，进入 Busy，完成后再用同一个 ID 报告结果。PLC 在核对上一个命令及结果之前，不会请求新一轮循环。上电、超时和断线都不能把旧请求悄悄转化成新的机器人运动命令。

此外必须明确断电恢复、急停、防护停止、控制器重启、程序切换、多个故障同时发生及手动模式下的处理规则。

Ready

或

Heartbeat

等应用层信号

不属于安全等级信号

，除非它们被专门纳入适当的安全架构并完成验证。普通现场总线的状态本身不能证明设备处于安全状态。

普通 I/O、运动协调、功能安全是三件不同的事

工程设计经常混淆三类需求：

• 
  标准 I/O 握手：
  
  交换启动请求、状态位、程序号和诊断数据，通常一个较小的周期性数据区就足够。
• 
  运动协调：
  
  同步多个轴、执行输送带跟踪或多机器人协同运动。可能需要厂商专用运动选件、同步时钟、兼容配置文件或专有接口，而不只是更短的 I/O 更新周期。
• 
  功能安全：
  
  检测危险条件并执行经过验证的安全功能。可能采用
  
  PROFIsafe、CIP Safety
  
  或
  
  Safety over EtherCAT（FSoE）
  
  ，前提是两端设备均具备兼容的安全能力，并按要求完成设计和验证。

安全逻辑、安全通信、Safe Torque Off（安全扭矩关断）、防护停止和急停不能等同。具体用途、所需性能等级和恢复行为，必须依据机器风险评估及适用标准决定，不能从普通通信协议对比中推导。

选型的六步工程方法

1. 
   列出实际设备。
   
   记录 PLC CPU、机器人控制器、I/O 模块、驱动器、固件版本、通信板卡和已安装软件许可证。不能假设同一机器人品牌永远具有相同接口。
2. 
   定义每项数据的用途。
   
   区分周期命令/状态、运动数据、安全相关通信、诊断与业务遥测。
3. 
   核实通信角色。
   
   检查 PROFINET IO-Controller/IO-Device、EtherNet/IP Scanner/Adapter、EtherCAT MainDevice/SubDevice。两个产品即使标有同一种协议，角色不匹配也可能无法直接连接。
4. 
   要求提供集成证据。
   
   PROFINET 索取 GSDML；EtherNet/IP 索取 EDS 和连接参数；EtherCAT 索取 ESI；OPC UA 核实 Endpoint、Namespace 和安全配置文件；MQTT 则确认 Broker 与 Payload 约定。
5. 
   规定时间与故障行为。
   
   明确更新间隔、数据多久失效、超时定义、断线和重启后的机器状态；分别考虑 PLC 扫描、机器人处理和安全功能。
6. 
   先做最小化台架验证。
   
   建立连接，交换代表性输入输出，检查类型和字节顺序，然后主动模拟断线与重启，再确定整体方案。

三种常见采购场景

场景 A：现有工厂采用 PROFINET。

如果机器人控制器具有兼容的 PROFINET IO-Device 选件，沿用现有现场总线可能降低工程、备件和维护复杂度。但要检查实际安装了什么，不能只看宣传册。

场景 B：PLC 系统以 CIP 为主。

机器人侧的 EtherNet/IP Adapter 可能是最直接的方案。编写 PLC 程序前，应确定 Assembly、数据长度、RPI 和故障时的行为。

场景 C：多伺服轴 EtherCAT 设备。

EtherCAT 可能非常适合驱动器与分布式 I/O；但一台独立的工业机器人仍可能需要通过另一种现场总线完成程序级握手，因为那才是其控制器实际支持的方案。一台机器完全可以存在多个合理的现场层网络。

比宣传周期时间更值得关注的指标

厂家公布的理论更新速度可能在特定配置下成立，却不能代表整套机器人工作站的响应。应分别分析：

• 
  现场总线更新间隔：
  
  配置好的过程数据交换频率。
• 
  抖动（Jitter）：
  
  数据到达或任务执行时间的波动。
• 
  PLC 任务周期：
  
  输入采样、逻辑执行和输出更新发生的时机。
• 
  机器人控制器响应：
  
  应用程序何时识别映射输入并改变内部状态。
• 
  物理响应：
  
  实际执行机构在验证过的机器顺序中还需要多少反应时间。

对于普通启动/忙碌/完成握手，时间可预测性、诊断能力和兼容性，往往比把网络周期压低一点点更重要。对于高度耦合的伺服与同步运动，权衡会发生变化。时间如果是关键要求，就在目标硬件上进行测量，而不是凭协议名称推断性能。

网络分区、远程访问与网络安全

OPC UA 和 MQTT 提供更多可观测性，同时增加了访问路径。基本的纵深防御应把机器控制网络与监控、企业系统隔开，仅开放必要流量，避免分析平台故障影响控制。

• 
  网络分区：
  
  划分工作站、监控、企业网络区域，必要时通过路由和防火墙控制跨区通道。
• 
  身份管理：
  
  使用独立的服务身份并限制权限，避免共享默认密码和无限制匿名客户端。
• 
  证书与加密：
  
  配置受支持的 OPC UA 安全模式、受信任证书和 MQTT 安全传输，监控证书到期与更新。
• 
  最小权限：
  
  默认只读提供运行数据；远程写入必须经过评审、授权和可审计的命令流程。
• 
  故障隔离：
  
  云平台、Broker、Historian 或 SCADA 网络中断，不得导致机器出现不安全行为。
• 
  维护：
  
  保存配置备份、网络图、厂商支持信息，并建立受控的固件和凭证维护流程。

任何通用文章都不能证明某家工厂的网络安全已经合格。具体措施取决于威胁建模、生产约束、适用要求和实际设备。

调试验收清单：值得记录的测试

• 
  设备身份：
  
  预期的控制器、固件、模块与选件许可证确实存在。
• 
  配置一致性：
  
  设备描述文件、模块顺序、Assembly 映射以及字节/位序符合批准的接口约定。
• 
  角色和地址：
  
  每个接口都处于指定的 Controller/Device 或 Client/Server 角色。
• 
  正常握手：
  
  程序选择、就绪、请求、接受、忙碌及完成状态在两端一致。
• 
  无效输入：
  
  不支持的程序号、错误数据和互相矛盾的命令被拒绝或安全处理。
• 
  通信中断：
  
  拔掉链路或停止通信进程会触发规定的设备反应和报警；恢复后不会意外启动新循环。
• 
  重新上电：
  
  PLC、机器人和网关重新启动后协调状态并清除过期请求。
• 
  数据新鲜度：
  
  OPC UA/MQTT 消费端能区分当前、断线和过期状态。
• 
  访问控制：
  
  未授权写入、消息发布和跨区连接按照预期失败。
• 
  安全验证：
  
  由具备资质的人员单独验证真实安全功能，包括相关故障和重新启动行为。

将批准的接口矩阵与测试记录一并归档，放在电气图、PLC 软件和机器人备份附近。下一位工程师不应该通过逆向阅读运行中的程序来猜一个比特是什么意思。

常见问题

PROFINET 和 EtherNet/IP 哪个更好？

没有绝对的赢家。两者都适合许多 PLC–机器人周期 I/O 接口。实际选择主要由现有 PLC 生态、机器人选件、工程工具、通信角色和维护支持决定。应验证确切硬件组合，而不是仅比较名义速度。

EtherCAT 一定比 PROFINET 快吗？

EtherCAT 面向高效、确定性的过程数据交换和设备同步。PROFINET 也具有多种实时机制，包括 IRT。若不限定设备、拓扑、配置周期和完整控制任务，简单给出速度排名没有工程意义。

PLC 与机器人能直接通过 OPC UA 通信吗？

可以，前提是双方都实现兼容的 OPC UA 功能，且应用已按此设计。但 OPC UA 服务器并不自动提供合适的周期性机器人 I/O 接口或经过验证的安全链路。必须核对实际控制需求和实现方式。

MQTT 能启动或停止工业机器人吗？

应用程序在技术上可以接收 MQTT 指令，但 MQTT 本身不能提供安全、确定性的运动控制，也不能保证具有安全等级的停止功能。远程命令必须通过明确的授权、PLC 或机器人状态检查以及经过验证的机器控制逻辑。安全功能不得依赖普通 MQTT 消息投递。

PROFINET、EtherNet/IP 和 EtherCAT 可以共用交换机吗？

不能想当然。有些 PROFINET 和 EtherNet/IP 系统可使用合适的托管式工业以太网交换基础设施，但必须满足协议、定时和拓扑限制。EtherCAT 常见的周期通信机制不同，需要兼容的通信段硬件。网线类型相同不代表网络协议互通。

GSDML、EDS 和 ESI 文件有什么作用？

它们向工程工具描述设备功能：

GSDML

用于 PROFINET，

EDS

常用于 EtherNet/IP，

ESI

用于 EtherCAT。它们有助于配置过程数据、参数和设备身份，但不能替代固件兼容性、接口角色及应用信号含义的验证。

结论：先划清控制边界，再选择协议

对于工业机器人工作站，合理的起点是

用周期性现场总线执行机器顺序控制，独立设计并验证安全功能，用 OPC UA 向上层提供结构化数据，仅在确有收益时使用 MQTT 通过 Broker 分发事件

。这是一种常见架构思路，并非唯一标准答案。最终的集成质量取决于真实的控制器接口、无歧义的信号契约，以及故障场景是否得到验证。

在购买通信板卡或软件选件之前，一份一页纸的接口说明可能最有价值：

每个信号由谁负责、经过哪张网络、需要保持多新、信号消失后设备应该怎样响应。

资料来源与进一步核实

本次更新参考的标准组织原始资料：

• 
  PROFIBUS & PROFINET International — PROFINET 技术
  
  ：实时通信类别、诊断与 PROFIsafe。
• 
  PI — PROFINET GSDML 规范
  
  ：PROFINET XML 设备描述与 PROFIBUS GSD 的区别。
• 
  ODVA — EtherNet/IP
  
  ：CIP 架构与基于 UDP 的周期通信。
• 
  EtherCAT Technology Group — EtherCAT 技术
  
  ：边通过边处理、分布式时钟与安全概念。
• 
  ETG — EtherCAT Compendium
  
  ：设备状态、工程配置与系统实现。
• 
  OPC Foundation — OPC Unified Architecture
  
  ：信息模型与安全架构。
• 
  OPC Foundation — OPC UA for Robotics, Part 1
  
  ：2025 年 9 月 8 日发布的 1.02 版。
• 
  OPC Foundation — Field Level Communications / OPC UA FX
  
  。
• 
  OASIS — MQTT Version 5.0
  
  ：2019 年 3 月 7 日的 OASIS 标准。

核实说明：

上述资料用于支持协议原理与已发布规范，不代表任何未指定 PLC–机器人组合的已安装选件或互操作性，也不包括对实际工厂安装的性能测试。资料核查日期为 2026 年 10 月 13 日。

正在规划机器人与 PLC 的集成？

先整理确切的机器人控制器、PLC 型号、固件、现场总线选件及需要交换的信号。你可以在

AYXWORKS Robotics & Automation

阅读更多实用指南，包括

视觉引导抓取的标定、坐标与故障恢复

。项目可行性与职责边界可联系 Eurobots/ReBots 讨论；作者背景可参见

AYXWORKS 作品集

。

欢迎交流：

你的调试经历中，最难处理的是 PROFINET I/O 映射、EtherNet/IP Assembly、EtherCAT 配置、OPC UA 安全设置，还是 MQTT Payload 的一致性？

文章插图：AYXWORKS 原创示意图，不能代替项目专用网络设计图。WordPress 特色图片若另有版权标注，应按其真实许可保留。