IT/OT Integration for Manufacturing: Why It Keeps Stalling, and How to Fix It
IT/OT integration stalls, almost always, for the same reason: operational technology (OT) and information technology (IT) were built by different teams, on different timelines, with different priorities, uptime and safety on the OT side, security and standardisation on the IT side, and no one is responsible for bridging the gap.
The fix isn’t a bigger platform. It’s a small, well-defined boundary layer that speaks OT’s language on one side and IT’s on the other. That’s what an edge gateway is built for.
What “IT/OT integration” actually means in practice
Strip away the buzzword and the task is concrete: get data that currently lives on a factory-floor network, PLC registers, sensor readings, machine alarms, into systems that IT already runs and trusts: a SCADA historian, an ERP system, a cloud dashboard, a BI tool. And, in some cases, let those systems send commands back the other way.
The reason this is hard isn’t the data itself. It’s that OT networks run protocols IT tooling was never built to understand (Modbus, CAN, proprietary serial links), while IT systems expect standardised, secure, well-documented interfaces (REST, MQTT, OPC UA, SQL).
Where integration projects go wrong
Three patterns show up repeatedly in stalled projects:
- Connecting everything directly
Point-to-point connections create a fragile network where a single update breaks the system. - Forcing IT security onto old hardware
Legacy machinery wasn’t built to support modern security tools like TLS or patch management. - Treating it as a one-time project
Without ongoing maintenance, data mappings quickly decay and break down over time.
The boundary-layer approach
A dedicated edge gateway sitting between OT and IT solves all three at once, because it’s the one thing that’s allowed to speak both languages:
1. On the OT side, it connects using the protocols the floor already speaks, RS-485/Modbus, CAN, direct digital and analogue I/O, without asking legacy equipment to change.
2. In the middle, it normalises the data: converts registers and raw signals into named, typed values with units, and can apply basic logic or filtering before anything leaves the plant.
3. On the IT side, it exposes that normalised data over standard, secure interfaces, OPC UA for SCADA and MES integration, MQTT for lightweight telemetry, TLS for anything leaving the site, so IT teams get an interface they already know how to secure and consume.
SENSBLUE ATLAS is built specifically for this middle position: RS-485, CAN and dual Ethernet for the OT side; Wi-Fi, BLE and LTE plus TLS-secured, EU-hosted cloud connectivity for the IT side; and enough local compute (Raspberry Pi CM4, quad-core) to normalise and filter data before it ever leaves the building.
What good IT/OT integration looks like once it’s working
OT engineers keep their existing equipment and workflows untouched.
- IT teams get one documented, secured interface per site, not fifteen undocumented ones.
- New machines or sensors can be added by extending the gateway’s mapping, not by re-architecting the integration.
- The data model, tag names, units, update frequency, is defined once, centrally, and stays consistent as the plant grows.
FAQ´S
Does IT/OT integration mean putting the OT network directly on the internet?
No, and it shouldn’t. The gateway acts as the only point of contact between the two networks, so OT equipment never needs a direct external connection.
How long does a typical IT/OT integration project take with a gateway approach?
Because the OT-side equipment isn’t being modified, most single-line pilots go from install to live dashboard data within days, not months, the main variable is how many distinct devices need mapping.
Do we need OPC UA specifically, or is MQTT enough?
It depends on what’s consuming the data. SCADA and MES platforms generally expect OPC UA’s structured, self-describing data model; lightweight cloud dashboards and alerting are usually well served by MQTT. A capable gateway supports both simultaneously.
