The Protocol Wars: The Factory Floor's Fragmentation Problem
In June, Matter released its latest update to make smart home devices truly plug-and-play. As a result, a smart light can now be commissioned before it's even screwed into a ceiling fixture. Such easy interoperability across consumer devices is in stark contrast to the factory floor.
Operational technology (OT) still doesn't have a unified protocol or a single spec that makers are racing to support. A programmable logic controller (PLC) installed 20 years ago isn't getting a firmware update that makes it speak the same language as a sensor installed last quarter. More likely, it speaks Modbus while the sensor speaks Message Queuing Telemetry Transport (MQTT), with a gateway somewhere in between doing the work that Matter's NFC-based commissioning just made obsolete in the living room.
Admins are still dealing with the reality of competing protocols that require different expertise and management tools. Unfortunately, this fragmentation compounds into alert fatigue and missed red flags at the very same moment bad actors are using automation to scale their attacks.
The good news is we don't need to rip and replace legacy systems that interact differently. Rather, we need to find a better way to communicate in concert and ensure the ongoing protocol wars don't open the door to inefficiency or weakness.
The roadblocks to protocol unification
Admins may look to the consumer side with jealousy but there are real blockers that prevent industrial environments from such standardization.
For example, Matter only ever had to govern application-layer commands for a defined set of consumer devices. Smart "things" like lights, locks, and thermostats don't need a response time measured in milliseconds. In industrial control, however, latency is operational, with safety interlocks that fire a few milliseconds late translating into a machine that doesn't stop when it should. Add to that an installed base measured in decades rather than upgrade cycles and there's a much narrower path to a single standard.
For the moment, admins have no choice but to operate within a United Nations of protocols: Modbus data must pass through Open Platform Communications Unified Architecture (OPC UA) before reaching MQTT, which then needs to connect to the SNMP-based informational technology (IT) monitoring system. Three protocols can result in three dashboards, where problems are more easily hidden.
The resulting complexity can and does lead to real-world losses. Fortune Global 500 companies lose approximately $1.4 trillion annually, or 11% of their revenue, due to unplanned production pauses.
However, organizations with comprehensive OT visibility detect and contain ransomware incidents in an average of 5 days compared with the industry-wide average of 42 days. Clearly, teams can't unify the protocols overnight, but they can stop letting the gaps between them go unwatched.
Teams and protocols need to be on the same page
The above is thrown into relief by network convergence. Historically divided yet increasingly interconnected, IT and OT too often lose sight of operations (and one another) thanks to protocol misalignment.
The two worlds were separate by design for decades: OT focused solely on keeping machines up and running while IT handled connectivity, data, and security for everything else. That division made sense when neither side ever had to touch the other's systems.
Today, however, data generated on the factory floor needs to reach upstream systems for analytics and predictive maintenance, production decisions, and security insights. The two sides need a single source of truth and newfound teamwork to make this possible. If there's a production issue like a misconfigured PLC, a saturated switch, or a malfunctioning sensor, isolated and protocol-specific reporting makes troubleshooting a process of elimination rather than diagnosis.
Conventional IT tooling simply wasn't built to read OT's signals. That blind spot is exactly where attackers operate-and where teams need to redouble their efforts.
Compensating for variation and building universality
Beyond our own "Matter moment," industrial teams need to compensate for variation and build universality. Those that can natively read Modbus, OPC UA, and MQTT, and then bridge that data into the same view as standard IT protocols like SNMP, will be the ones who unite internal divisions and gauge issues as they arise.
Centroflora Group shows what this looks like in action. The Brazilian manufacturer of botanical and pharmaceutical ingredients counted three separate production segments running on Siemens PLCs, each generating its own protocol-specific data with no shared view. Diagnosing a problem required physically sending someone to the floor in a process that could take six to seven hours.
After consolidating their monitoring into a single platform, the diagnostic window dropped to minutes. Better yet, the same unified view also revealed equipment running inefficiently around the clock, resulting in a 4% reduction in power costs.
The same principle-that unified visibility surfaces problems isolated tooling simply can't-applies across other plants and stacks. It's caught misconfigured PLCs through anomalous Modbus traffic on aerospace production lines and traced server failures back to a single root cause in petrochemical plants. The common thread is less about the specific protocol and more about whether it's possible to oversee several at once.
In the protocol wars, the three-dashboard problem won't be solved by picking a fourth. It gets solved by collapsing the three views back into one on top of whatever is already running.
About the author
David Montoya is the presales director at Paessler GmbH, the network monitoring company behind Paessler PRTG. With deep expertise in IT/OT convergence, Montoya helps teams deliver proactive issue-prevention and monitoring solutions that deploy quickly and scale on their terms.
The post The Protocol Wars: The Factory Floor’s Fragmentation Problem appeared first on Embedded.