The Protocol Conversion Problem in Manufacturing
Why your plant's machines can't talk to each other and what an industrial protocol converter actually does about it.
Written by Ketsol Manufacturing Suite
Industrial Data & AI Practitioners | OT/IT Convergence Specialists.
Ketsol is an industrial technology firm specialising in data infrastructure for manufacturing environments. With over 15 years of experience across discrete and process industries, the team has delivered large-scale data architecture and IIoT implementations, including work with Tier-1 manufacturers.
Core expertise includes Unified Namespace (UNS) architecture, industrial data modelling, and AI readiness for production systems. Ketsol combines deep operational understanding with modern data engineering practices to bridge the gap between OT and enterprise systems.
Published: Jul 2026
Walk onto almost any manufacturing floor in India and you’ll find the same scene. A Siemens S7 PLC running the packaging line. A bank of Modbus energy meters tracking power draw. A BACnet system controlling the HVAC. Each one works perfectly on its own. None of them talk to each other.
This isn’t a hardware failure. It’s not even a software bug. It’s a translation problem — and it’s quietly costing manufacturers visibility, uptime, and decision-making speed every single day.
If you’ve ever wondered why your “digital transformation” project stalled at the data integration stage, this is usually why. Let’s break down what protocol conversion actually means, why it matters more than most plants realise, and how to solve it without tearing out equipment that still works fine.
What Is an Industrial Protocol Converter?
An industrial protocol converter is a device or software layer that translates data between different communication standards used by industrial equipment. Think of it as a universal interpreter sitting between your machines and the systems that need their data.
Most factories run a mix of protocols because equipment gets added over years, not all at once:
- Modbus RTU/TCP: common on PLCs, meters, and legacy devices
- Siemens S7: native to Siemens controllers
- EtherNet/IP: used heavily in Allen-Bradley and Rockwell environments
- BACnet: standard for building automation and HVAC
- OPC DA: an older Windows-based standard still common on the floor
None of these speaks to each other by default. A protocol converter sits in the middle, reads each device in its native language, and outputs everything in a standard format, typically OPC UA, that modern SCADA, historian, or analytics systems can actually consume.
Why Do Manufacturing Plants Have So Many Protocols?
It’s rarely a planning failure. It’s the natural result of running a plant for ten, fifteen, twenty years.
A line gets automated in 2014 with whatever PLC was available then. A new packaging machine arrives in 2019 with a different controller built in. An energy monitoring retrofit happened in 2022 using yet another protocol. Each decision made sense in isolation. Together, they create a shopfloor where five systems are all generating valuable data and none of it reaches the people who need it in real time.
This is especially common in brownfield plants facilities that were never designed for unified data architecture in the first place. Sugar mills, chemical plants, and discrete manufacturing units across India fit this pattern almost universally.
How Do You Convert Modbus to OPC UA Without Replacing Your PLC?
This is the question most automation engineers actually want answered. The short version: you don’t need to replace anything.
A protocol converter connects to your existing Modbus devices exactly as they are. It polls the registers at the device’s native rate, maps the values to OPC UA tags, and exposes them on a standard OPC UA server. Your SCADA, historian, or analytics platform connects to that OPC UA server instead of talking to each device individually.
The practical result:
- No firmware changes on the PLC
- No production downtime during setup
- No custom driver development
- Data available in a standard format within hours, not weeks
The same logic applies to EtherNet/IP to OPC UA conversion, Siemens S7 to OPC UA, and BACnet integration. The protocol changes; the approach doesn’t.
What Happens When Protocol Conversion Is Missing?
The cost of fragmented protocols rarely shows up as a single dramatic failure. It shows up as a thousand small inefficiencies that compound:
- Plant managers rely on yesterday’s report instead of today’s reality
- Engineers write one-off custom drivers for every new device, then maintain them forever
- Downtime investigations take hours because data lives in five different systems
- Energy and OEE numbers get manually compiled instead of measured live
- Every new integration project starts from zero instead of building on existing infrastructure
None of this looks like a crisis day to day. But over a year, it’s the difference between a plant that can see itself clearly and one that’s always reacting a step behind.
How Does Bi-Directional Protocol Conversion Work?
Most protocol converters only read data; they pull values out of a device and pass them along. That’s useful, but incomplete.
A bi-directional protocol converter also writes back. If a SCADA system needs to send a setpoint change, a start/stop command, or an alarm acknowledgement, the converter translates that command into the target device’s native protocol and confirms execution. This matters for any plant that wants remote control, not just remote visibility.
Practically, this means engineers can issue commands centrally, adjusting a setpoint on a remote tank farm, for instance, without dispatching someone to the site or relying on a phone call to confirm it happened.
Is Protocol Conversion Practical for Brownfield Plants?
Yes, and this is precisely where it matters most. Greenfield plants can standardise on one protocol from day one. Brownfield plants can’t go back in time and redo their wiring.
An industrial protocol gateway built for brownfield environments is designed to sit alongside legacy equipment, not replace it. It doesn’t require a forklift upgrade of your control systems. It requires a single device that understands every protocol already running on your floor and translates it into something modern systems can use.
This is also why standalone protocol converters have become popular as a first step in modernisation, they deliver immediate value without committing to a full platform replacement.
Key Takeaways
- Protocol fragmentation is normal, most plants run 4 to 6 protocols simultaneously without realising it
- An industrial protocol converter translates Modbus, S7, EtherNet/IP, and BACnet into a standard format like OPC UA
- Conversion can happen without replacing existing PLCs, SCADA, or historians
- Bi-directional conversion enables both monitoring and remote control
- Brownfield plants benefit the most, since they can modernise without ripping out working equipment
Where to Go From Here
If your plant is running multiple protocols and you’re curious what a unified view would actually look like, KMS Gateway is built specifically for this, a standalone industrial edge gateway that converts 50+ protocols into OPC UA, IEC-104, or DNP3 without touching your existing infrastructure. You can also explore how protocol-level data feeds into broader plant visibility through KMS, Ketsol’s manufacturing intelligence platform.
Frequently Asked Questions:
What is the difference between a protocol converter and a gateway?
A protocol converter focuses specifically on translating between communication standards (e.g. Modbus to OPC UA). A gateway is often a broader term that can include protocol conversion plus additional functions like data buffering, archiving, or edge-to-cloud connectivity. Most modern industrial gateways include protocol conversion as one of several capabilities.
2. Can a protocol converter work with legacy PLCs from the 1990s and 2000s?
Yes, provided the device supports a known protocol like Modbus RTU, which most legacy industrial equipment does. The converter polls the device using its existing communication method — no firmware or hardware changes are required on the legacy equipment itself.
3. Does protocol conversion require taking the plant offline?
No. Protocol converters typically connect alongside existing systems without interrupting production. Installation and configuration happen in parallel with normal plant operations, and most setups go live within days rather than weeks.
4. Is OPC UA the only output format protocol converters support?
OPC UA is the most common output standard because of its broad compatibility with modern SCADA and historian systems, but many converters also support IEC-104 (common in utilities and substations), DNP3 (common in energy and remote sites), and direct MSSQL archiving for plants that want data stored straight into a SQL database.
5. How long does it take to see value after installing a protocol converter?
Most plants see usable, unified data within the first week of installation, since no custom development is required for standard protocols. Full integration into dashboards, alerts, or historian systems typically follows within two to four weeks depending on the complexity of the existing setup.
Published Jul 2026 | OPC UA| Protocol Converter | Industry 4.0 | KMS Gateway | Edge Gateway | PLC Integration | Modbus, BACnet, EtherNet/IP | Siemens PLC | Industrial Networking