What Is a Digital Twin? A Plain Definition

“Digital twin” has been used so widely in recent years that its meaning has blurred. Is it a 3D picture of the factory? A simulation? A dashboard? The short answer: none of those, exactly.

The definition

A digital twin is a virtual copy of a physical asset that is fed by real-time data. It has three parts, and all three are required:

1. The physical asset — a machine, a line, or the whole factory.
2. The virtual model — its digital representation.
3. The live data link between them — what happens on the floor happens in the model.

Without the third, you don’t have a digital twin. You have a nice 3D model.

Why a 3D model isn’t enough

A 3D model of a factory tells you what the plant looks like. It’s impressive in a presentation and genuinely useful in layout discussions. But it won’t tell you that the welding robot stopped at 09:40 on Tuesday morning.

Because a digital twin updates continuously from floor data, it shows what the factory is doing right now. Click a machine in the model and you see its state, its operator, its counter, its cycle time. The difference is the difference between a photograph and a live broadcast.

What data does it need?

Less than people expect. In most factories the required signals are already produced by existing PLC or SCADA infrastructure:

• machine state (running / waiting / stopped)
• cycle and production counters
• downtime reasons
• quality and scrap data

MES, ERP, MQTT and SQL sources can be added to the same picture. The twin’s job is to merge these scattered sources into one model. As long as machine status lives on one screen, production figures on another and alarms on a third, nobody sees the whole.

The idea that you need new hardware is mostly a myth. If your machines produce data, the twin reads it. Extra sensors only come up when a quantity you want to watch isn’t being measured at all.

What is it good for?

The value concentrates in three places:

Visibility. You see a stoppage as it happens, not in the end-of-shift report. The lag is measured in minutes, not days.

A shared language. Operators, engineers and managers look at the same screen. “Which line is slow?” stops being a matter of opinion.

A basis for decisions. Which downtime reason recurs most, which machine costs the most — measured, not guessed.

Where to start

You don’t have to model the entire factory at once. In practice the best starting point is a single line where the problem is most visible: one whose data already flows, whose bottleneck is known, and where improvement can be measured. Spreading out from there is faster and cheaper than trying to cover everything from day one.

If you’d like to see this concretely, the OnoTwin Studio page has live screens, and our digital twin solutions page describes how a rollout runs as a project.