![\"Choosing](\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-communication-protocol-selection-guide.svg\")
Pick an industrial protocol by the job it must do (cyclic control, device access, plant data, or telemetry), then match timing, data model, and security to that job.
A plant rarely runs one protocol. A single packaging line can combine a fieldbus for drives, point-to-point links for sensors, an OPC UA server for supervisory systems, and an MQTT feed for cloud analytics. The question \"which protocol should we use?\" is therefore several smaller questions, each tied to a layer of the architecture and a specific consumer of the data.
This guide gives a four-question method, a comparison table, and the selection mistakes that most often lead to polling storms, unmaintainable tag lists, and fragile gateway chains. Protocol descriptions stay at the level of the published specifications; confirm details against the specification owners listed in the references and against your device documentation.
Industrial protocols were designed for different jobs, and most selection problems come from using one for a job it was not designed to do. Name the job first. Almost every link in a plant fits one of four categories.
The table summarizes the design intent of widely used protocols. It is a starting filter, not a ranking; real products implement subsets, and the supplier's conformance documentation decides what a specific device can do.
| Protocol | Primary job | Model and transport | Main caution |
|---|---|---|---|
| Modbus RTU / TCP | Simple register access to devices | Request/response; registers and coils; serial or TCP | No built-in information model or security; meaning lives in a register map |
| PROFINET | Cyclic control I/O and drives | Ethernet-based real-time exchange; device description files (GSDML) | Needs planned network topology and tooling aligned with the controller family |
| EtherNet/IP | Cyclic control I/O and drives | CIP objects over standard Ethernet; implicit and explicit messaging; EDS files | Multicast and connection planning matter on larger networks |
| EtherCAT | Fast, synchronized motion and I/O | Master-driven frames processed by each device in turn; distributed clocks | Topology and master choice constrain the architecture |
| OPC UA client/server | Plant-wide data access with context | Information model, browse, read/write, subscriptions; certificates and encryption | Does not by itself provide hard real-time control timing |
| OPC UA PubSub | One-to-many data distribution | Publisher/subscriber over UDP or through a broker | Requires agreed data-set definitions and key management |
| MQTT with Sparkplug | Telemetry to many consumers | Broker-based publish/subscribe; Sparkplug defines topics and payloads | Plain MQTT defines no payload; without Sparkplug or a data contract, every consumer guesses |
| HART | Digital data on analog loops | Digital signal carried on the 4-20 mA current loop | Slow; needs a HART-capable I/O or multiplexer path to reach the host |
| IO-Link | Sensor and actuator parameters and diagnostics | Point-to-point link between a device and an IO-Link master | Needs a master and a fieldbus or Ethernet uplink for the data |
Work through these questions for each link in the architecture. Write the answers down; the record becomes the rationale for the network design and the first page of the interface specification.
Choose the real-time Ethernet protocol that your controller family supports natively; see PROFINET and EtherNet/IP compared. Use IO-Link where many simple sensors need parameter management, and HART where existing loops already carry digital diagnostics. Avoid forcing a telemetry protocol into this layer.
Expose data to SCADA, historians, and MES through an information-oriented interface. OPC UA fits when the consumer needs browsing, typed values, quality, and security. Use Modbus TCP only when the device offers nothing better, and document the register map as an interface artifact.
Many consumers, intermittent links, and one-way data flows favor publish/subscribe. MQTT with Sparkplug or OPC UA PubSub distributes data without each consumer opening its own session to the source. Agree the topic structure and payload definitions as a governed contract, as discussed in unified namespace governance.
Record the decision per link in a short table: the consumer, the protocol, the data owner, the timing requirement, the security control, and the test that proves it. A reviewer should be able to challenge each row without reading the whole design.
Follow an ASP project guide to connect the fundamentals with implementation and acceptance.
Not as a general rule. The protocols serve different jobs. Control protocols exchange process images with deterministic timing, Modbus provides simple register access, and OPC UA provides described, secured information access. Plants usually run several together, and OPC UA often sits above the control layer rather than replacing it.
Both can work. MQTT with Sparkplug suits many consumers and intermittent links with a lightweight broker. OPC UA suits rich information models and built-in security. Many designs use OPC UA locally and publish selected data through MQTT. Decide by consumer needs, governance, and who maintains each interface.
MQTT is designed for telemetry and event distribution through a broker, with no timing guarantees suitable for closed-loop control. Use it for monitoring, commands that tolerate delay, and data distribution. Keep timing-critical control on the control network and its real-time protocol.
Specify by interface: a real-time protocol compatible with the plant's controller family for control, an OPC UA server with an agreed information model for supervisory data, and clear security and documentation deliverables. Avoid naming a single protocol for everything, and require device description files and a tested interface list.
No. A gateway adds a translation point, a failure mode, and a mapping to maintain. Use one when a device cannot speak the required protocol, and keep it as the only translation between the two sides, with documented mappings and preserved quality and timestamps.
Browse the related technical library or follow an ASP project guide to plan the implementation sequence.
![\"A](\"https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-context.svg\")
Use the original specifications and product documentation for implementation details. Examples in this guide are illustrative engineering scenarios, not published project results.