IoT Integration in Manufacturing: Brownfield Reality

What is IoT integration in manufacturing?

IoT integration in manufacturing is the practical work of getting reliable, timestamped data out of every machine on the shop floor and into a system where it can be used — for KPIs, alarms, scheduling, quality, or any downstream process. The word "IoT" makes it sound like a greenfield exercise of installing smart sensors on new equipment. In a real European mid-market plant, that is 10 to 20 percent of the job. The other 80 to 90 percent is connecting the machines that already exist, most of which were built before industrial Ethernet was a standard feature.

I have been doing this specific job since 1989 — first with Simatic S5 warehouse controllers and paint-line automation, then through the retrofit wave from S5 to S7 and TIA, and since 2000 at SYMESTIC building the machine-connectivity layer that feeds today's cloud platform. In 36 years of this work I have never yet encountered a machine that truly could not be connected. The belief that old equipment cannot provide useful data is the single most common reason manufacturers delay IoT projects, and it is almost always wrong. This article is about what IoT integration actually looks like in a real plant, which protocols matter, and how to avoid the engineering traps that make these projects drag.

Industrial IoT is not consumer IoT — and the difference is everything

The first source of confusion in nearly every IoT conversation with a new customer is that "IoT" is being used as a single word for two radically different engineering problems. The consumer IoT world — smart thermostats, voice assistants, connected doorbells — runs on protocols, lifecycles and security assumptions that do not apply to a factory floor. Assuming they transfer is the shortest path to a failed industrial IoT project.

The practical consequence is that consumer-IoT design patterns do not transfer. Anything that requires cloud-direct device connectivity, anything that treats an outage as tolerable, anything that pushes firmware updates unsupervised, anything that assumes a replacement cycle shorter than a decade — none of that survives first contact with a real factory floor. Industrial IoT is its own discipline, and recognising that is the entry ticket.

The brownfield reality: 80 % of the real job

When I walk into a plant to scope an IoT integration, I count the machines by age and connectivity class. The distribution is remarkably consistent across every mid-market industry I have worked in — automotive, food and beverage, metal, wood, consumer goods. Roughly 10-20 percent of the machines are recent enough to expose modern IoT-ready interfaces like OPC UA out of the box. The other 80-90 percent are older, and the engineering question is what to do with them.

That distribution is the honest baseline of industrial IoT in Europe in 2026. Articles that start from the assumption that every machine already has OPC UA or MQTT built in are describing a factory that does not yet exist. The engineering that matters — and the engineering that decides whether an IoT integration project succeeds or fails — is almost entirely on the older 80 percent. Everything else is easy.

The four machine tiers — and the right retrofit strategy for each

After connecting several thousand machines in the last two decades, I classify every machine I see into one of four connectivity tiers, and each tier has a predictable answer. The cost and time per machine differ by roughly a factor of ten between the easiest and hardest tier, which means getting the classification right upfront is the difference between a project that runs on schedule and one that runs six months long.

Tier 1: Modern, OPC UA-capable. Post-2015 machines from major OEMs frequently ship with an OPC UA server built into the PLC or the HMI. Connection is hours of work: configure the address space on the machine side, point the cloud gateway at it, validate the data model. Typical effort: half a day to a day per machine. Cost per machine is minimal.

Tier 2: Ethernet-capable PLC without OPC UA. A Simatic S7-300 or S7-1500 without native OPC UA, a Rockwell ControlLogix, a Beckhoff CX — all Ethernet-based, but the PLC does not expose OPC UA directly. An OPC UA server is added as a bridge, either by a PC-based server reading the PLC or by a protocol-converting gateway. Typical effort: 1-2 days per machine. The tag list becomes the real work — agreeing with the customer on exactly which PLC variables need to be exposed.

Tier 3: Serial or pre-Ethernet PLC. Simatic S5, older Mitsubishi, older Allen-Bradley — these machines predate industrial Ethernet as a standard. A protocol gateway bridges from the legacy fieldbus (Profibus, serial, Modbus RTU) to Ethernet and OPC UA. The engineering itself is routine; the cabling and commissioning are where the time goes. Typical effort: 2-4 days per machine, sometimes more if the PLC program needs minor changes to expose the right signals.

Tier 4: No digital interface, or the PLC cannot be touched. This is the tier where most IoT projects either find a way or quietly give up — and where the greatest engineering value sits. The machine has no exportable digital data at all, or the PLC program is frozen for regulatory reasons, or the OEM support contract prohibits any modification. The right answer is a digital-I/O gateway that taps existing physical signals: cycle-count pulses, stop-status relays, alarm-output contacts, sometimes a 4-20 mA process signal. No PLC intervention. No production interruption. Typical effort: 2-8 hours per machine.

The signature insight from 36 years of this work: in every plant I have ever worked in, Tier 4 connectivity was possible. Every single time. The belief that an old machine cannot provide data is almost always a belief about which interfaces exist on the control cabinet door, not about which signals exist in the wiring. Cycle counts exist — the machine counts its own cycles internally. Stop status exists — the machine knows when it is running and when it is not. The data is already there; the job is to tap it. This is why "our machines are too old for IoT" is almost never a real reason to delay an integration project.

Protocols — what to use, and what not to

The industrial IoT protocol landscape looks more complicated than it is. There is a small list of protocols that matter, a smaller list that matter for very specific jobs, and a list of consumer-IoT protocols that have no role on a factory floor. Here is the short version.

OPC UA is the default for machine-to-system communication in industrial IoT. It is vendor-neutral, carries semantic models (not just raw tags), supports authentication and encryption natively, and is supported by every major industrial control vendor. For new deployments and retrofits, OPC UA is the answer unless there is a specific reason to deviate.

MQTT is the default for gateway-to-cloud telemetry. It is lightweight, publish-subscribe, tolerates intermittent connectivity, and scales well. A typical SYMESTIC architecture uses OPC UA inside the plant (machine → gateway) and MQTT from the gateway to Azure — OPC UA for semantic depth at the machine layer, MQTT for scalable transport to the cloud. MQTT Sparkplug B adds a semantic layer on top of MQTT where that is useful.

Proprietary fieldbuses — Profinet, Profibus, EtherNet/IP, Modbus, CC-Link — typically terminate at the PLC. The job of an IoT gateway is to bridge from them to OPC UA, not to carry their traffic outside the OT network. Trying to route fieldbus traffic directly to the cloud is a category error.

Consumer IoT protocols — CoAP, Zigbee, BLE, LoRaWAN for short-range — have essentially no role inside industrial IoT integration. LoRaWAN has niche uses for wide-area low-power sensors (energy monitoring, environmental sensing), but not for machine connectivity.

Edge versus cloud — and the bandwidth physics nobody talks about

The marketing of "real-time cloud IoT" usually glosses over a simple number. At 15,000 connected machines reporting at 1-second resolution — the operational scale of the SYMESTIC platform in 2026 — the raw event rate is roughly 54 million events per hour. Sending all of that raw to the cloud is not a real engineering option. It is not a bandwidth limit at the cloud side; it is a bandwidth limit at the plant side, where upstream connections are shared with everything else the factory does.

The pragmatic pattern in every production-scale industrial IoT deployment is two-layer: edge gateways do the first-level aggregation (cycle counts become cycle events, continuous signals become state transitions, raw measurements become summaries), and only the condensed event stream is shipped to the cloud. This is not a design choice — it is a physical constraint. Anyone selling "send everything raw to the cloud in real time" at factory scale is either working at a scale where the physics does not bite yet, or is not telling the full story. Edge for compression and control, cloud for analytics and visibility, and a clean boundary between the two, is the working architecture.

Security: OT segmentation is not optional

The single most common security failure I see in industrial IoT integrations is a flat network between the IT side and the OT side. In 2026, after years of ransomware attacks explicitly targeting manufacturing, this is no longer a defensible position. Proper IoT integration requires a segmented architecture with a DMZ between the OT network (PLCs, machines, gateways) and the IT network (ERP, office, internet). The IoT gateway lives at the boundary and authenticates in both directions.

The practical minimums are: the OT network is not directly reachable from the internet, ever; the IoT gateway uses authenticated, encrypted outbound connections only; credentials are managed per device and rotated; firmware updates happen during scheduled windows with validation; and there is a documented incident-response plan if a gateway is compromised. Consumer-IoT security patterns — cloud-direct device connectivity, vendor-pushed updates, shared credentials — do not meet this bar.

A real case: Brita

Brita is a global leader in drinking-water optimisation with production sites in Germany, the UK, Italy and China. The engagement is a textbook case of the mixed-tier connectivity that any real plant has to handle — modern, highly-automated assembly lines alongside older equipment, both feeding the same operational view.

The starting point was the Taunusstein plant. Unusually, there was no formal proof-of-concept phase — instead a targeted evaluation that moved directly into scoping, because the success criteria and the machine landscape were well understood from the start. The scope expanded to include downtime capture and a plant monitor, then scaled within the first year to include the Bicester (UK) site, with the Brita team operating the modular feature catalogue themselves for subsequent site expansions.

The connectivity pattern combines both ends of Martin's playbook in a single plant: for the modern lines, OPC UA connections into the existing line-controller systems to capture alarm streams and performance data; for the older equipment, digital-signal tapping via DI gateways to capture actual output and stop signals without any PLC intervention. Same data model, same dashboards, two different connectivity tiers feeding them — which is the realistic shape of industrial IoT in any mid-market plant.

The measured outcomes on the connected lines:

• 5 % reduction in stop time, through visibility and categorisation of stop signals that had previously been invisible
• 7 % improvement in output, from the operational decisions that became possible once both modern and older lines reported into the same data layer
• 3 % improvement in availability, through structured action on recurring loss categories

The detail that matters for the IoT integration argument: none of this required replacing or upgrading any machine. The older equipment contributed just as cleanly to the data layer as the modern lines, via digital-signal tapping. That is the practical proof of the "every machine can be connected" claim — and the reason waiting for a fleet refresh before starting an industrial IoT programme is almost never the right call.

FAQ

What is the difference between IoT, IIoT and Industry 4.0?
IoT (Internet of Things) is the broad concept of connecting physical objects to networks, including consumer products. IIoT (Industrial IoT) is the subset specific to industrial and manufacturing environments, with the lifecycle, security and reliability requirements that implies. Industry 4.0 is a broader strategic programme that encompasses IIoT but also covers cyber-physical systems, digital twins, autonomous logistics and data-driven business models. For a factory-floor engineer, IIoT is the relevant term; Industry 4.0 is what the executive committee calls it.

Can old machines without digital interfaces be included in an IoT integration?
Yes, and the belief that they cannot is the single most common reason plants delay these projects. A machine from 1995 without any native digital interface can almost always be connected through a digital-I/O gateway that taps existing cycle-count pulses, stop-status relays and alarm-output contacts. No PLC intervention, no production interruption, typical effort is 2-8 hours per machine. In 36 years of this work I have not yet encountered a machine where this approach did not work.

What is the right IoT protocol for a factory?
OPC UA for machine-to-gateway communication and MQTT for gateway-to-cloud transport is the working pattern for almost every new deployment. OPC UA provides semantic data modelling and is supported by every major industrial control vendor; MQTT provides lightweight, reliable cloud transport that tolerates intermittent connectivity. Proprietary fieldbuses (Profinet, Profibus, EtherNet/IP) stay inside the OT network and are bridged to OPC UA at the gateway. Consumer IoT protocols (Zigbee, BLE, CoAP) have no meaningful role in manufacturing.

How long does IoT integration actually take per machine?
It depends on the tier. Modern OPC UA-capable machines: half a day to a day. Ethernet-capable PLCs without OPC UA: 1-2 days. Serial or pre-Ethernet PLCs: 2-4 days. Digital-I/O retrofit on machines with no digital interface: 2-8 hours. For a typical mixed-tier plant with 30-50 machines, the full connectivity rollout is measured in weeks, not months. If a vendor quotes 6+ months for basic machine connectivity, the architecture is the bottleneck.

Should IoT data be processed at the edge or in the cloud?
Both, for different jobs. Time-critical control and safety decisions must be handled at the edge — no cloud architecture will beat physics on sub-100-millisecond latency. Analytics, KPIs, cross-plant visibility and historical analysis belong in the cloud. The working pattern is edge gateways for first-level aggregation (reducing raw event rates to manageable event streams) and cloud for analytics, visualisation and enterprise integration. Trying to do everything in the cloud fails on bandwidth physics at any real factory scale.

What are the security minimums for industrial IoT?
The OT network is not directly reachable from the internet; the IoT gateway is the only component that crosses the boundary, and it uses authenticated, encrypted outbound connections only. Gateway credentials are managed per device and rotated on a defined schedule. Firmware updates happen during scheduled windows with validation. The architecture includes a DMZ between OT and IT networks. No shared credentials, no direct machine-to-internet connectivity, no unauthenticated protocols on the OT side. Consumer-IoT security patterns do not meet the manufacturing bar.

Do we need to upgrade our PLCs to get IoT-ready?
Almost never. The engineering belief that legacy PLCs are a barrier to IoT integration is about 10 years out of date. Modern gateways bridge from virtually any PLC family — Simatic S5/S7, Rockwell, Beckhoff, Mitsubishi, Omron, Keyence — to OPC UA without requiring PLC replacement. Where the PLC exposes no digital data at all, digital-I/O tapping provides a complete fallback path. PLC upgrades should be driven by machine lifecycle and production needs, not by IoT connectivity requirements.

How does SYMESTIC support IoT integration?
A gateway library covering OPC UA, MQTT, digital-I/O, and protocol bridges for legacy PLC families; retrofit-friendly hardware for brownfield plants with no PLC intervention required; Azure-based ingestion with MQTT at the transport layer; edge pre-aggregation to keep cloud bandwidth and latency under control; segmented architecture with authenticated gateway-only connectivity from OT to cloud; bidirectional integration with SAP, Infor, proAlpha, Microsoft Dynamics and Navision. Go-live on the first line in days, full plant in weeks, currently running 15,000+ machines across 18 countries. See SYMESTIC Process Data.

Related: MES · Cloud MES · Machine Data Acquisition · Real-Time Monitoring · OPC UA · Industry 4.0 · Edge Computing · SYMESTIC Process Data

About the author

Martin Brandel

MES Consultant & Project Lead at SYMESTIC. 36+ years in industrial automation and machine connectivity — Simatic S5 warehouse and material-flow control from 1989, paint-line commissioning in Eastern Europe and China with Hermos AG, and since 2000 at SYMESTIC building the OT-integration layer that feeds the cloud-MES platform. Since 2019 leading end-to-end MES projects from first enquiry to go-live. Dipl.-Ing. Nachrichtentechnik. · LinkedIn