Protocols
Protocols
Section titled “Protocols”Protocol choices often reshape the hardware shortlist more than teams expect. This section explains how protocol fit affects interoperability, data handling, engineering effort, and long-term architecture boundaries.
The expensive protocol mistake is not choosing an unpopular standard. It is putting the wrong protocol at the wrong boundary. A serial device may still be perfectly useful if the boundary is a converter or gateway. OPC UA may be the right plant-side integration layer but the wrong cloud delivery pattern. MQTT may be excellent for publish-style telemetry but weak if the team still has not modeled the machine states it wants to publish.
Quick protocol boundary
Section titled “Quick protocol boundary”| Protocol or pattern | Best-fit boundary | Weak-fit boundary |
|---|---|---|
| Modbus RTU / TCP | Simple register access, meters, drives, legacy devices, straightforward polling | Rich semantic data models or broad enterprise context |
| OPC UA | PLC, SCADA, historian, and structured plant data integration | Ultra-light remote telemetry where overhead and configuration burden dominate |
| MQTT | Publish/subscribe telemetry, edge-to-cloud movement, event delivery | Raw device interrogation without an event or topic model |
| Serial bridging | Preserving useful RS-232/RS-485 assets without replacing equipment | Complex multi-consumer data architecture |
| Polling | Stable low-frequency reads where freshness expectations are modest | High-speed event capture or loss analysis |
| Publish/report-by-exception | State changes, alarms, and bandwidth-aware telemetry | Workloads that still need broad historical sweeps |
The shortlist should be driven by where translation happens and who owns it after commissioning.
Core paths
Section titled “Core paths”What to define before choosing hardware
Section titled “What to define before choosing hardware”Before a gateway, converter, or edge device belongs on the shortlist, define these protocol facts:
- Machine-side protocol burden: serial, Modbus TCP, EtherNet/IP, Profinet, OPC UA, vendor driver, file export, or mixed.
- Upstream consumer: historian, SCADA, MES, OEE tool, cloud broker, maintenance system, or custom application.
- Freshness requirement: seconds, minutes, shift-level summaries, or event-first capture.
- Data shape: raw tags, calculated states, event records, alarm sequence, batch context, or traceability evidence.
- Ownership: controls team, plant IT/OT, integrator, enterprise platform team, or vendor support.
Those facts decide whether the device class should be a protocol converter, industrial gateway, edge computer, remote I/O layer, or something smaller.
Common protocol-selection failure modes
Section titled “Common protocol-selection failure modes”| Failure mode | What it looks like | Better approach |
|---|---|---|
| Protocol-first buying | A gateway is bought because it supports many protocols | Start with the two or three protocols actually crossing the boundary |
| Cloud-first abstraction | MQTT is chosen before machine states are modeled | Define event and state semantics before topic design |
| Historian sprawl | Every readable register becomes a tag | Separate durable signals from diagnostic noise |
| Serial replacement bias | Legacy serial devices are replaced before their value is understood | Bridge or convert if the device is stable and useful |
| OPC UA overreach | OPC UA is expected to solve ownership, naming, and context by itself | Treat OPC UA as transport and information modeling, not governance |
Protocol review flow
Section titled “Protocol review flow”- Confirm which systems must talk to each other and who owns each endpoint.
- Separate field protocol needs from upstream data delivery needs.
- Decide where translation should happen and which device class should own it.
- Compare the operational consequences before locking into vendor-specific hardware.