Your Shop Floor Speaks Five Dialects: Why OPC UA Doesn’t Solve Protocol Fragmentation

Somewhere in every plant that’s been running for more than a decade, there’s a control engineer who has said some version of: "just standardize everything on OPC UA and this all goes away."

It doesn’t go away. It’s the same advice that’s been given for fifteen years, and the plants that took it still have three protocols on the floor and a spreadsheet bridging the rest.

The fleet you actually have, not the one the whitepaper assumes

OPC UA is a genuinely good unifying standard — vendor-neutral, secure by design, built for exactly this problem. The trouble isn’t the standard. It’s the assumption baked into "just use OPC UA": that every device on your floor can speak it.

A real plant floor, especially one that’s grown by acquisition, expansion, or a decade of "we’ll deal with it later," looks more like this:

• A CNC line from eight years ago running Siemens S7, native to its own protocol stack
• An older stamping cell on Allen-Bradley, talking EtherNet/IP
• A handful of legacy PLCs on Modbus RTU over serial, because the machine predates Ethernet ports
• One or two newer cells that shipped with OPC UA servers built in
• A scale, a label printer, and a barcode scanner that speak none of the above

Retrofitting OPC UA onto the older half of that list means new firmware, new licenses, or new hardware — on machines that are otherwise running fine and have another decade of useful life left. For most plants, that’s not a protocol migration. That’s a capital project nobody budgeted for, to solve a data-access problem that doesn’t need it.

Why the "just standardize" advice keeps getting given anyway

It’s not bad-faith advice. It’s advice that’s true in isolation and wrong in practice, for three reasons:

It assumes a greenfield floor. Standardizing on one protocol is straightforward when you’re specifying new equipment. It’s a different problem entirely when the equipment is already installed, running production, and not due for replacement for years.

It treats the protocol as the whole problem. Even a floor that is fully OPC UA still needs routing, buffering, and context — which reading belongs to which work order, which machine state maps to which OEE bucket, what happens when the network drops for four minutes during a shift change. The protocol gets you the bytes. It doesn’t organize them.

It ignores who actually owns the fix. IT wants one clean interface. OT owns machines that can’t always be touched without a change-control process and a maintenance window. The protocol conversation happens at the IT layer; the constraint lives at the OT layer. Nobody standardizes their way past that gap — it has to be bridged.

The layer that actually does the work

The fix isn’t picking the "right" protocol. It’s a bridging layer that sits between whatever the machines already speak and whatever the rest of the stack needs — one that reads OPC UA where it’s available, Modbus and S7 where it isn’t, and normalizes all of it into a single stream before anything downstream has to care.

flowchart LR
 classDef src fill:#0b1220,stroke:#334155,color:#e2e8f0
 classDef acq fill:#083344,stroke:#22d3ee,color:#cffafe
 classDef bridge fill:#3a1f0a,stroke:#f97316,color:#fed7aa
 classDef data fill:#082f49,stroke:#38bdf8,color:#e0f2fe
 classDef office fill:#052e16,stroke:#22c55e,color:#dcfce7

 subgraph FLOOR["Shop floor as it actually exists"]
 direction TB
 S7[Siemens S7 CNC line]:::src
 AB[Allen-Bradley stamping cell]:::src
 RTU[Legacy Modbus RTU PLCs]:::src
 OPCUA[Newer OPC UA native cells]:::src
 PERIPH[Scales, printers, scanners]:::src
 end

 subgraph BRIDGE["Bridging layer"]
 direction TB
 ADAPT["Protocol adapters  
S7 · EtherNet/IP · Modbus TCP/RTU · OPC UA"]:::bridge
 BUFFER["Store and forward  
offline tolerant"]:::bridge
 NORM["Normalize to one event stream  
tag map · timestamp · unit context"]:::bridge
 end

 subgraph DOWN["Everything downstream"]
 direction TB
 DB[("Time series / Postgres")]:::data
 MES[MES core]:::office
 SPC[Real time SPC]:::office
 ERP[ERP lot release]:::office
 end

 S7 --> ADAPT
 AB --> ADAPT
 RTU --> ADAPT
 OPCUA --> ADAPT
 PERIPH --> ADAPT
 ADAPT --> BUFFER --> NORM
 NORM --> DB
 DB --> MES
 DB --> SPC
 DB --> ERP

Three things that layer has to do, regardless of which protocols it’s bridging:

Speak the dialect, not just the standard. Adapters for S7, EtherNet/IP, Modbus TCP/RTU, and OPC UA side by side — so a fifteen-year-old stamping cell and a brand-new CNC line land in the same stream without either one being replaced.

Tolerate the network you actually have. Shop-floor networks drop. Store-and-forward buffering at the edge means a four-minute outage during a shift change is a gap that gets backfilled, not data that’s gone.

Normalize before anything downstream sees it. MES, SPC, and ERP shouldn’t each need their own protocol knowledge. They should see one clean event stream — tagged, timestamped, and mapped to work order and machine context — regardless of what produced it.

What this looks like in the two places we build it

This bridging layer isn’t a hypothetical middle step — it’s a named piece of both of the systems we deliver.

In simpliFactory, it’s simpliInterface: the connectivity layer that speaks RS-232, USB, Ethernet, Modbus, and OPC UA across mixed-vendor floors, feeding IMCS for measurement routing and, from there, real-time SPC and ERP lot release — without touching the machines that are already running fine.

In a custom MES build, it’s the Tier 3 edge layer: offline-tolerant Python gateways, an MQTT/OPC UA broker, and custom adapters for Modbus TCP/RTU, Siemens S7, and Allen-Bradley — built for exactly the mixed-vintage fleets and unreliable network conditions that make "just use OPC UA" the wrong answer on its own.

Which one fits depends on what you’re actually trying to solve. If the immediate pain is measurement data — calipers, gauges, scales — stuck in spreadsheets before it reaches SPC or ERP, that’s a simpliFactory conversation. If the pain is broader — work orders, machine state, OEE, and traceability across a full line or plant — that’s an MES conversation, and the protocol adapter layer is one piece of a larger build.

The honest test before you build anything

Before any adapter gets written, walk the floor and answer three questions plainly:

1. What does each machine actually speak, today — not what its spec sheet claims, not what the PLC could theoretically support if reflashed. Pull the manual, check the port, confirm it.
2. What’s genuinely unreadable. Some machines — older sealed injection molders, some imported equipment where the vendor is long gone — can’t be read without a retrofit. Know which ones those are before promising a timeline.
3. What’s the network actually like at each station. Wireless dead zones, shared industrial Ethernet, PLCs on a network segment IT doesn’t control — all of it changes whether store-and-forward is a nice-to-have or the thing that keeps the whole system honest.

That protocol inventory is the first deliverable in both an architecture review and an MES pilot, for the same reason: it’s the difference between a bridging layer that works on your actual floor and one that works on the floor the whitepaper assumed you had.

FAQ

Does this mean we shouldn’t bother with OPC UA at all?
No — OPC UA is still the right target for anything new you specify, and it’s the cleanest source to bridge from where it already exists. The point isn’t to avoid OPC UA. It’s to stop treating it as a migration plan for equipment that isn’t moving.

How long does a protocol inventory actually take?
On a single line, a day or two of floor walking plus manual-checking for anything undocumented. On a full plant with mixed vintages, closer to a week — which is why it’s scoped as an explicit first phase rather than an assumption baked into a proposal.

What happens with machines that genuinely can’t be read?
They get flagged, not ignored. Manual entry through an operator HMI covers the gap in the short term, and the machine goes on a list for a PLC retrofit if and when it makes sense — rather than blocking the rest of the rollout.

Is this a simpliFactory problem or an MES problem?
Often both, and the honest answer depends on scope — which is exactly what an architecture review or a 30-minute technical call is for.

Have a shop floor with more protocols than anyone wants to admit to? Book a simpliFactory architecture review if the pain is measurement data stuck in spreadsheets, or book a 30-minute MES technical call if it’s broader than that. Either way, hello@simplico.net gets you to an engineer, not a sales deck.