How SCADA differs from IIoT and cloud monitoring

The difference between SCADA and IIoT is the job each one does. SCADA supervises and controls a process: it reads the PLCs on a line, shows operators the live state and sends setpoints and commands back. IIoT collects machine and process data for analysis, often in the cloud, and answers questions about shifts, weeks and whole fleets.

A plant that runs SCADA can keep it and add IIoT beside it. This guide is for plant and controls engineers deciding whether to extend SCADA, add IIoT monitoring or run both. It works one press shift through by hand to show what each system can tell you.

What is SCADA?#

NIST's definition stresses distance: SCADA was designed to gather data and apply controls over long distances, in uses such as power transmission and pipelines.^[1] Inside a factory the same idea runs over a plant network instead of phone lines, microwave or satellite links.

A SCADA system has four parts:

• Controllers. A PLC (programmable logic controller) is the computer that runs a machine; the PLC glossary entry says more. A remote terminal unit (RTU) does the same job at a remote site, such as a pump station.
• A network that carries tag values between the controllers and the SCADA servers. A tag is one named value, such as a tank level or a motor's run state.
• HMI screens. A human-machine interface (HMI) is the screen where operators watch the process and change setpoints.
• A historian, the database that stores every tag value with its timestamp.

For example, on the water-treatment skid of a food plant, the SCADA screen shows tank level, pump state and chlorine dose. An operator in the control room can stop a pump or raise the dose without walking to the skid.

ISA's description of ISA-95 places SCADA at Level 3, beside manufacturing execution systems (MES), above the PLCs and distributed control systems (DCS) at Level 2.^[2] The figure shows the five levels and the path IIoT monitoring takes beside them.

What is IIoT?#

The data gets in two ways. Sensors added to the outside of a machine read what it physically does, such as vibration, sound or units breaking a laser beam. Connections to a machine's controller read what the control reports, such as the program name, alarms and the part count.

Both ways rely on protocols built for this traffic. MQTT is a lightweight publish-and-subscribe messaging protocol and an OASIS standard for the internet of things.^[4] OPC UA runs on anything from an embedded microcontroller to cloud infrastructure.^[5]

The MQTT glossary entry covers how live data travels. For the controller side, machine communication protocols explains MTConnect, OPC UA and Modbus and when you need each. For where IIoT sits beside Industry 4.0 and digital twins, read what Industry 4.0, IIoT and digital twins mean.

IIoT monitoring is not a control system: it reads the machine and leaves control with the PLC. Sensors on the outside also let it measure machines that SCADA never connected.

SCADA and IIoT side by side#

The two overlap at the edges: a SCADA historian stores weeks of data, and an IIoT dashboard shows live status. The rows below show what each one is built around.

Reading data vs controlling a process#

The deepest difference is which way the data flows. SCADA reads values from the PLC and writes setpoints and commands back, so it changes how the process runs. Sensor-based monitoring reads from the outside of the machine and has no path to the controller at all.

That direction decides who signs off on the project. A connection to a controller is a security concern for many plants, and IT usually reviews it first. NIST's guide to operational technology security, SP 800-82 Rev. 3, covers programmable systems that interact with the physical environment, and it names SCADA systems, DCS and PLCs among them.^[3]

Controller connections sit between the two: they read only, or read and write, depending on how they are set up. OPC UA can sign and encrypt each message, and it identifies every client and server with an X.509 certificate.^[5] Even a read-only connection opens a new path into the control network, so plan it with IT.

Sensor-based vs PLC machine monitoring compares what each path can see, row by row.

Is IIoT replacing SCADA?#

No. The two do different jobs, and at least one newer standard is written to serve both. The Sparkplug specification, which defines topics, payloads and session state for MQTT, targets the IIoT market and is written to meet the requirements of real-time SCADA and control HMI solutions.^[6]

The common claim that SCADA "doesn't scale" points at something narrower: the work of adding one machine. To bring a machine into SCADA you need a controller that can be read, a tag map, PLC logic and screens, which is a controls engineering job per machine. A 1990s lathe with no network port gives SCADA nothing to read.

IIoT monitoring changes that unit of work. A sensor reads the same lathe from the outside, so the number of machines you can measure no longer depends on the number of controllers you can reach. The useful framing is coverage, not replacement: SCADA covers the process you control, and IIoT covers the machines and questions SCADA was never set up for.

Uptime from a SCADA historian#

If a machine's PLC already sends a run bit to SCADA, a tag that reads 1 while the machine runs, the historian holds enough to calculate uptime. Count the samples where the bit was 1, then divide by the samples in planned production time.

That count works when the historian stores the bit at a fixed rate. If your historian stores a value only when it changes, add up the time from each change to 1 until the next change to 0 instead.

Remove the break before you count. The run bit reads 0 during the break too, and counting it as a stop would put availability at 337.5 ÷ 480 = 70.3%.

That 75% is the first OEE factor, and how to calculate OEE works through the other two. What the historian can't tell you is why the press stopped: the run bit drops to 0 the same way for a coil change, a jam and a missing operator.

Reasons come from people at the machine. A monitoring system asks the operator to tag each stop, so the 112.5 minutes become 40 minutes of material wait, 35 of changeover, 25 of a jam and 12.5 of a coil change. Now the morning meeting knows to start with material flow.

Monitor machines beside your SCADA#

IoTFlows adds machine monitoring without touching the control system. A SenseAi sensor mounts on each machine with a magnet and reads vibration and sound from the outside, with no connection to the PLC. It decides running or stopped every second on the device, and part counts and cycle times come from the machine's own cycle.

Devices connect out over HTTPS on port 443, or stay off the plant network on the 4G/LTE router. Operators put a reason on each stop in a tap, which fills in the column the historian was missing.

Where you want alarms or process values too, the IoTFlows edge device on Enterprise reads only the controls you choose to connect, over OPC UA, Modbus TCP, MQTT and other protocols. See machine monitoring for the views.

Choose SCADA, IIoT or both#

Extend your SCADA when:

• you need to change the process from a central screen: setpoints, recipes, starts and stops;
• operators must act on process alarms within seconds;
• the machines in question already have PLCs on the SCADA network.

Add IIoT monitoring when:

• the question is about utilization, downtime reasons or OEE across many machines;
• some machines have no readable controller, or a controller connection is waiting on IT review;
• managers and maintenance need the numbers on phones and in weekly reports, off the control network.

Run both when SCADA controls one process, such as compounding or utilities, and standalone machines make parts elsewhere on the floor. Production line monitoring without PLCs shows the IIoT half for a whole line.

You don't need a SCADA system to measure machine utilization or downtime. You don't need to remove a working one to add monitoring either.