Comparison · Digital twins

Digital twin vs SCADA: what each one does, and why plants need both.

SCADA runs and watches the equipment. A plant digital twin reads SCADA alongside orders, stock, lab results and trucks, and shows the whole site in one model. One does not replace the other.

SCADA supervises and controls equipment in real time; a plant digital twin models the whole site and how material, orders and trucks move through it. SCADA tells the operator that a pump has tripped. The twin tells the plant head that the trip will leave tomorrow's dispatch short, who owns the decision, and what the options are. A twin reads from SCADA; it does not replace it.

We see the two confused often, partly because both show a picture of the plant with live values on it. The difference is in the question each one answers, and in who is asking.

What does SCADA do that a twin should not?

SCADA (supervisory control and data acquisition) sits close to the machines. It reads tags from PLCs every second or faster, shows them on HMI screens, raises alarms, and lets operators send setpoints and commands back to the equipment. It is built for the control room operator who has to act within seconds.

That control path is safety-relevant and engineered for it. A digital twin should never sit in that path. It should read from SCADA, usually through the historian that stores the tags as time series, and leave control exactly where it is.

What does a digital twin add on top of SCADA?

A plant digital twin joins data that SCADA never sees. Orders and stock come from ERP. Chemistry and holds come from the lab. Trucks come from gate passes and the weighbridge. Shift logs, maintenance tickets and the registers people keep by hand all add context. The twin places all of it on a 3D model of the site and runs rules across it.

It also works across time in a way SCADA screens usually do not. Live mode shows the plant now. Replay lets a shift review scrub back through the last 24 hours. Forecast projects bin levels, stock against orders and queue length over the next 72 hours.

How do digital twin and SCADA compare side by side?

SCADAPlant digital twin
Main jobMonitor and control equipmentShow the whole site's state and what needs a decision
Main userControl room operatorPlant head, shift controller, operations and supply-chain teams
Time scaleSeconds, nowShift and day: live, last 24 hours, next 72 hours
DataPLC tags in its own scopeSCADA or historian plus ERP, lab, gate, weighbridge, logs
Controls equipmentYesNo; reads only
AlertsEquipment alarms to operatorsBusiness-impact alerts to the owner, with the next step
ViewHMI screens per unit or areaOne 3D model of the site, alerts pinned where they happen
Typical questionIs this motor overheating?Will we ship tomorrow's orders, and what is in the way?

How does one event look in each system?

Take an illustrative steel melt shop, not a customer plant. A ladle furnace transformer trips at 10:40.

In SCADA, the operator sees the alarm, the tag values and the trip reason. The operator follows the procedure to make the unit safe and restart it. That is exactly what SCADA should do.

In the twin, the same trip is one input. Say the restart takes 50 minutes and each heat spends 40 minutes at the ladle furnace. The two heats waiting there are now late. If the caster needs a new heat every 45 minutes to keep the sequence, the twin can see that a 50 minute delay on two heats puts the sequence at risk around 11:30. It flags that to the shift controller with the heats, the grades and the sales orders they belong to. The controller can decide to slow the caster, change the order of heats, or accept a break, with the cost of each shown.

SCADA saw a trip. The twin saw a delivery problem forming. Both views are correct, and the plant needs both.

SCADA protects the machine in the next ten seconds. The twin protects the order in the next ten hours.

Why is joining SCADA with other systems the hard part?

The difficulty is not reading SCADA tags. It is joining them to everything else. A tag is named after an instrument; an order is named after a customer. To link them you need a common key, such as the heat number in a steel plant or the batch number in a food plant, and every event needs its own source timestamp.

In Steel Twin, for example, PLC and SCADA stream temperatures, flows, speeds and equipment states from Level 1, the historian keeps them for replay, and heat_id is the key that joins them to MES, LIMS and ERP. Every event keeps its source timestamp and a quality flag, so stale data is never hidden. That pattern, one key and honest timestamps, matters more than the 3D picture.

Can't we just extend SCADA instead?

It is a fair question, and in some plants the answer is partly yes. Modern SCADA platforms can show more, connect to more and draw nicer screens. If the only goal is a better operator view of one unit, extending SCADA may be enough.

The limit is scope and ownership. SCADA is usually owned by instrumentation and controls, changed under strict procedures, and kept away from ERP and office networks for good reasons. Pulling sales orders, lab holds and truck queues into it adds risk to a system that should stay simple. A twin that reads from the historian keeps the control layer untouched and gives the business data a place of its own. For the MES side of the same argument, see our guide on steel plant MES vs a digital twin.

Which one does your plant need?

If equipment cannot be monitored or controlled reliably today, fix SCADA first; a twin built on missing tags will be guesswork. If SCADA works but the plant head still learns about shortages, holds and truck queues the next morning, that is the gap a twin fills. Many smaller Indian plants have no SCADA at all, only PLC counters and registers. They can still start a twin from those, and treat SCADA as a later input rather than a precondition. The plant digital twin page shows the same idea across eight industries, from steel and ferro-alloys to flour mills, warehouses and plant gates.

What to do this week

  1. List the last five problems that reached the plant head late. Note which system first knew.
  2. Check whether SCADA tags are kept in a historian, and for how long.
  3. Find the key that links a process event to an order: heat, batch or lot number.
  4. Agree with the controls team that any twin reads only and never writes to SCADA.

Keep SCADA doing what it does well, and give the rest of the plant its own view.

Questions

What is the difference between a digital twin and SCADA?

SCADA monitors and controls equipment in real time for operators. A plant digital twin reads SCADA together with ERP, lab, gate and weighbridge data and models the whole site to show what needs a decision.

Does a digital twin replace SCADA?

No. A plant digital twin reads from SCADA, usually through the historian, and never sends commands to equipment, so the control layer stays as it is.

Is SCADA a digital twin?

Not in the usual sense. SCADA shows live equipment values for control, while a digital twin models the whole site across live, replay and forecast views with data from many systems.

How does a digital twin connect to SCADA?

Usually by reading tags from the plant historian, then joining them to other systems on a common key such as heat or batch number, with each event keeping its source timestamp.

Do we need SCADA before building a digital twin?

Not always. Plants without SCADA can start a twin from PLC counters, ERP, weighbridge and lab registers; where SCADA exists, it becomes one of the richest inputs.

See it on your own data. Steel Twin — Every heat, traced to the coil. Book a 30-minute working session with an engineer.

General guidance, current as of the date above. Figures and examples are illustrative unless a source is linked.