在工业自动化领域，经常能看到一串名词：MQTT、Modbus、PLC、TCP、RS-485。
有人说设备采用 Modbus 通信，有人说通过 RS-485 接线，有人说数据走 TCP，还有人说通过 MQTT 把数据上传到平台。
这些说法都没错，但它们并不是同一类东西。
PLC 是设备，RS-485 是一种电气接口标准，TCP 是传输层协议，Modbus 和 MQTT 则是不同用途的通信协议。
如果把它们混在一起理解，就很容易出现一个问题：明明知道每个名词是什么意思，却还是看不懂一套工业通信系统究竟是怎么工作的。
我们不妨从一条实际的数据链路说起。
一、先看懂一条工业数据是怎么传出去的
假设一座工厂里有一台温度仪表，需要把测量值发送到 PLC，再由网关把数据上传到监控平台。
这条链路可能是这样的：
温度仪表 → RS-485 → Modbus RTU → PLC 或网关 → TCP/IP 网络 → MQTT → 监控平台
这里需要先说明：这只是一种常见的示例架构，实际项目中，设备可能直接通过以太网通信，也可能由 PLC、网关或其他系统完成数据转发，不一定每个环节都会出现。
这条链路里，每个技术解决的问题不同：
-
温度仪表：产生温度数据。
-
PLC：读取数据、执行控制逻辑，并与其他设备通信。
-
RS-485：提供设备之间传输电信号的物理接口。
-
Modbus RTU：规定设备如何请求数据、返回数据，以及数据如何组织。
-
TCP/IP：为以太网环境中的数据传输提供网络寻址和可靠传输等能力。
-
MQTT：让设备或网关能够通过发布/订阅机制，把数据发送给相应的订阅者。
理解这几个角色，就能看懂大部分工业通信方案的基本结构。
二、PLC：不是协议，而是执行控制任务的设备
PLC，全称可编程逻辑控制器，是工业自动化系统中的核心控制设备之一。
它可以采集传感器信号，执行程序逻辑，再控制电机、阀门、气缸等执行设备。
例如，温度超过设定值后，PLC 可以根据控制程序发出报警，或者控制相关设备动作。
但 PLC 本身并不等于某一种通信协议。
一台 PLC 可以支持多种通信方式和协议，例如 Modbus TCP、Modbus RTU、PROFINET 等，具体取决于设备型号、通信模块和软件配置。
因此，当有人说"这台 PLC 使用 Modbus 通信"时，意思是这台设备通过 Modbus 规则与其他设备交换数据，而不是说 PLC 本身就是 Modbus。
还有一点需要区分：PLC 负责执行控制逻辑，通信协议负责设备之间的数据交换。两者可以协同工作，但不能相互替代。
三、RS-485：解决的是"电信号怎么传"
RS-485 经常出现在工业仪表、变频器、PLC 和各种串口设备的技术参数里。
它规定了一种差分信号电气接口的相关特性，常用于工业现场的串行通信。
它的价值主要体现在电气传输方式上，能够适应较长距离、多节点等工业通信需求，但实际距离、速率和节点数量仍然受线缆、拓扑、终端匹配、干扰等因素影响。
关键是：RS-485 不规定数据代表什么，也不规定设备应该发送什么指令。
它只解决电气接口层面的部分问题。
举个例子，两台设备都使用 RS-485 接口，并不意味着它们就一定能够互相通信。
原因很简单：它们可能采用不同的通信协议，也可能使用不同的波特率、校验方式、数据位和停止位。
即使这些串口参数一致，如果双方对报文格式和指令含义的理解不同，通信仍然无法正常进行。
所以，看到设备标注"RS-485 接口"，还需要继续确认它支持什么协议。
四、Modbus：规定"双方怎么说话"
Modbus 是工业领域非常常见的一种通信协议，广泛用于 PLC、仪表、变频器和其他自动化设备之间的数据交换。
它规定了如何组织请求和响应、如何读取或写入数据，以及不同功能码的含义。
例如，某台温度仪表把测量值放在一个寄存器中。上位设备按照 Modbus 规则读取这个寄存器，再根据设备手册解释返回的数据，就可以得到温度值。
这里有两个容易混淆的概念：Modbus RTU 和 Modbus TCP。
Modbus RTU 通常用于串行通信，常见的物理接口是 RS-485；Modbus TCP 则运行在 TCP/IP 网络上，常见于以太网环境。
因此，Modbus 并不等于 RS-485。
前者规定通信报文及其含义，后者提供电气接口。Modbus 可以运行在不同的通信承载方式上，具体取决于它的实现形式。
这也解释了为什么工业现场经常会出现"Modbus RTU 转 Modbus TCP"的需求：转换设备需要在串行侧和以太网侧分别处理相应的通信机制，让原本使用串行 Modbus 的设备能够接入 TCP/IP 网络。
不过，协议转换不一定意味着所有数据语义都能自动统一，具体还要看设备寄存器定义和转换设备的功能。
五、TCP：解决的是网络中的可靠传输问题
TCP 是传输层协议，常见于以太网和 IP 网络通信。
它的主要作用是为应用程序提供可靠、有序的字节流传输，并处理丢失数据的重传等问题。
但 TCP 不知道一段数据究竟代表温度、压力，还是电机转速。
它只负责在通信两端之间传输字节流，不负责解释这些字节对应的工业业务含义。
这就像一辆运输车：它可以把货物送到目的地，却不负责决定货物是什么，也不负责决定收货人拿到货物之后如何使用。
Modbus TCP 就是一个典型例子：Modbus 定义工业数据请求和响应的规则，TCP 负责传输这些报文，IP 则承担网络寻址与转发相关的职责。
所以，TCP 和 Modbus 不是竞争关系，而是可以分层配合的关系。
当然，TCP 的可靠传输也不意味着工业控制一定具有确定性。重传、排队、网络拥塞和设备处理时间都可能影响实际时延。如果业务有严格的实时性要求，还需要从整个系统的角度评估时间性能。
六、MQTT：解决的是数据如何发布和分发
如果说 Modbus 常见的通信方式是"你来问，我来答"，那么 MQTT 更典型的特点就是"我发布，你订阅"。
MQTT 是一种轻量级的发布/订阅消息协议，通常通过 MQTT Broker（消息代理）分发消息。
举个例子，网关采集到温度数据后，可以向某个主题发布消息，例如：
factory/line1/temperature
监控平台订阅了这个主题，就可以接收相应的消息。其他获准订阅该主题的应用，也可以接收同一份数据。
这样一来，数据生产者不必为每一个接收系统分别建立一套业务通信逻辑，消息分发由 Broker 协助完成。
这也是 MQTT 常用于工业物联网、设备数据上云和平台数据分发的原因之一。
但要注意，MQTT 本身并不负责采集现场仪表数据，也不会自动知道某个寄存器代表什么。通常需要 PLC、网关或应用程序先读取、解析和组织数据，再通过 MQTT 发布。
另外，MQTT 的消息服务能力不等于实时控制能力。即使使用 MQTT 的消息交付服务质量机制，也不能仅凭 QoS 等级就保证消息在固定时间内到达。对于严格的闭环控制，仍然需要根据控制周期、时延和故障处理要求选择合适的通信架构。
七、把这些概念放在一起，就不容易混淆了
可以用下面这张表快速区分：
| 名称 | 属于什么 | 主要解决什么问题 |
|---|---|---|
| PLC | 控制设备 | 执行控制逻辑、采集与控制 |
| RS-485 | 电气接口标准 | 电信号如何在设备间传输 |
| Modbus RTU | 串行通信协议 | 串行设备如何请求和交换数据 |
| Modbus TCP | 工业应用协议在 TCP/IP 上的实现 | 如何通过 TCP/IP 网络交换 Modbus 数据 |
| TCP | 传输层协议 | 提供可靠、有序的字节流传输 |
| MQTT | 消息协议 | 如何通过发布/订阅机制分发消息 |
这里还有一个容易忽略的区别：Modbus 和 MQTT 都是应用层相关协议，但它们解决的通信问题并不相同。
Modbus 更常见于设备之间读取、写入寄存器等操作；MQTT 更常见于消息发布、订阅与分发。它们可以出现在同一套系统的不同环节，而不是非此即彼。
八、真正做项目时，应该按什么顺序排查？
理解概念的最终目的，是遇到通信问题时能够找到正确的排查方向。
例如，现场仪表的数据无法上传到平台，不要一上来就怀疑 MQTT 或 TCP。可以按数据链路逐层检查：
-
现场设备是否正常？ 仪表是否供电，测量值是否正常。
-
物理连接是否正常？ RS-485 的接线、极性、终端匹配及串口参数是否正确。
-
设备协议是否匹配？ 双方是否使用相同的 Modbus 模式，地址、功能码和寄存器定义是否正确。
-
网络连接是否正常？ 如果使用 Modbus TCP 或 MQTT，检查 IP 地址、路由、端口和网络连通性。
-
应用层是否正常？ MQTT 是否成功连接 Broker、主题是否正确、权限是否允许发布和订阅，数据格式是否符合平台要求。
这套顺序的核心，是先确认数据在哪一段出问题，再沿着链路向上排查。
如果 RS-485 接线错误，调整 MQTT 主题没有用；如果设备寄存器地址读错，TCP 连接正常也不能保证数据正确；如果 MQTT 连接正常，但发布的数据格式不符合平台要求，平台仍然可能无法正确解析。
工业通信排障，最怕的就是把不同层次的问题混在一起。
最后
理解 MQTT、Modbus、PLC、TCP、RS-485，不需要死记硬背每个名词的定义。
只要抓住它们各自解决的问题：
PLC 负责控制，RS-485 负责电气连接，Modbus 负责工业数据交换规则，TCP 负责可靠传输，MQTT 负责消息发布与分发。
它们不是同一层面的技术，也不是互相替代的关系。
当你看到一份工业通信方案时，先问三个问题就够了：
设备是谁？数据通过什么方式传输？双方按照什么规则理解这些数据？
把这三个问题理清楚，工业通信里那些看似复杂的缩写，就会逐渐变成一条能够看懂、能够排查的数据链路。