Factories have been full of sensors and controllers for decades. What Industrial IoT adds is not sensing but connection: getting the data that already lives inside PLCs, drives and instruments out of isolated control networks and into systems that can store, analyze and act on it across machines, lines and plants. The umbrella term for that shift is Industry 4.0, but the engineering is more concrete than the slogan.
Industrial deployments differ from consumer IoT in almost every constraint. Equipment runs for decades, downtime is measured in money per minute, networks are physically segmented for safety, and the people who own the machines are not the people who own the IT. A good IIoT project respects all of that.
This guide covers the architecture that works in practice, the protocols you will meet, the use cases with a clear return, and the reasons projects get stuck.
The brownfield reality
Most IIoT work is brownfield: the machines already exist, and the job is to connect them without disturbing them. A line commissioned fifteen years ago has PLCs that speak Modbus or PROFINET, a SCADA system watching it, maybe a MES above that, and an HMI panel per station. Some data is reachable through the PLC’s communication ports; some is only visible on an analog gauge.
The first decisions are therefore about access. Can the PLC expose tags over OPC UA or Modbus TCP without a firmware change? Does the SCADA historian already have the data? For older machines with no digital interface, retrofit sensors (current clamps on motor feeds, vibration sensors on bearings, a camera on the counter display) are often faster and safer than touching the control program. Treat the control network as read-only unless the automation team agrees otherwise.
Architecture: from cell to cloud
Industrial networks are traditionally organized in levels, often described with the Purdue model: field devices and controllers at the bottom, supervisory control above, site operations above that, and enterprise systems at the top, with firewalls between levels. IIoT does not abolish this; it adds a path for data to flow upward safely.
The practical shape is:
- At the cell level, sensors and PLCs stay on their fieldbus or industrial Ethernet, untouched.
- An edge gateway or industrial PC in the cell polls or subscribes to the controllers over OPC UA or Modbus, normalizes the data, runs local logic, and buffers it.
- The gateway publishes upward over MQTT, usually to a plant-level broker, using a topic and payload convention such as Sparkplug so every consumer understands the metrics without custom parsing.
- Plant-level systems (historian, analytics, a local digital twin) subscribe to what they need. A one-way or tightly controlled connection forwards selected data to the cloud for fleet-wide analysis.
This “unified namespace” pattern, where a single broker holds the current state of the plant and every system publishes and subscribes rather than integrating point-to-point, has become the default for new projects. It decouples producers from consumers and makes adding a new consumer a subscription rather than a project.
The protocols you will meet
OPC UA is the standard for machine-to-system communication in modern automation: a rich information model, built-in security, and support from every major controller vendor. It is heavier than MQTT, so it is typically used between the gateway and the controllers, not for cloud transport. OPC UA also defines a publish-subscribe profile that can run over MQTT.
Modbus remains everywhere because it is simple and old. It has no security and a flat register model, so the gateway does the work of giving registers names and units. EtherCAT and PROFINET handle the deterministic cycle-level traffic between controllers and drives; IIoT reads from them rather than joining them. In buildings and utilities you will meet BACnet, KNX and DDS in specific niches.
MQTT with Sparkplug is the glue upward. Sparkplug adds a defined topic structure, a birth and death certificate for each device so consumers know what is online, and a compact protobuf payload with typed metrics. It is what turns a generic broker into a plant data bus.
Use cases that pay
Condition monitoring and predictive maintenance. Vibration, temperature and current on rotating equipment reveal bearing wear, imbalance and electrical faults weeks before failure. The payoff comes from avoided unplanned downtime and from replacing calendar-based maintenance with condition-based scheduling. This is the most common first project because the value is easy to measure.
OEE and production visibility. Counting good parts, bad parts and stoppages automatically, with reasons captured from the controller, replaces clipboards and gives supervisors a live view of availability, performance and quality. Often the biggest early win is simply knowing where the time goes.
Energy monitoring. Submetering lines and machines shows which assets consume what, when, and at what cost, and reveals idle consumption that can be switched off. It also feeds demand response and sustainability reporting.
Quality and traceability. Linking process parameters to each unit produced lets a plant trace a defect back to its conditions and prove compliance to customers and regulators.
Digital twins and simulation. Once data flows, a model of the line can test schedule changes, detect bottlenecks and support operators, which is covered in Digital twins explained.
Security in the industrial setting
Operational technology was secured by isolation. Connecting it removes that, so the security model must be rebuilt rather than bolted on. IEC 62443 provides the framework: zones with defined security levels, conduits between them, and requirements for components and for the processes of the vendors who build them. Network segmentation between the control network and the rest of the plant is non-negotiable. Data flows upward through gateways with authenticated, encrypted connections; nothing on the internet reaches a PLC directly. Device identities, signed firmware and disclosure processes apply as they do anywhere, and the Cyber Resilience Act now makes several of them mandatory for industrial products sold in the EU.
Why projects stall
The pattern called pilot purgatory is common: a monitoring pilot on one machine works, and then nothing scales. The usual causes are organizational rather than technical. Automation and IT teams have different owners, tools and risk tolerances; a project without a sponsor on both sides stalls at the firewall. Data from a pilot is not actionable because nobody defined who would act on an alert and how. The business case was “insight” rather than a specific cost avoided. And the pilot was built with bespoke integrations that cannot be repeated on the next line.
Projects that scale start with one measurable outcome, pick a repeatable architecture (gateway, broker, namespace, consumers) on the first line, involve maintenance and operations staff in defining alerts, and plan the roll-out to the second and tenth line before the first one is finished.
Where to go next
- Edge computing explained covers the gateway tier that makes brownfield connection possible.
- MQTT explained explains the transport beneath the unified namespace.
- Predictive maintenance with IoT and AI goes deeper on the most common first IIoT project.
- AI agents on the factory floor looks at what connected plant data makes possible next.
Topics: industrial IoT, IIoT, OPC UA, Industry 4.0, predictive maintenance