Digital twin vs digital shadow is not a branding debate; it is a precise distinction about which direction data flows between a physical asset and its digital counterpart. In this article you will learn the three levels of integration (digital model, digital shadow, digital twin), see each one expressed as concrete MQTT topics, and get a checklist to classify your own project honestly.
The digital twin technology guide covers the broader concept; here we focus on the data flow.
The Three Levels at a Glance
The classification widely used in manufacturing research distinguishes three levels by how data moves between the physical object and the digital object:
| Level | Physical to digital | Digital to physical | Example |
|---|---|---|---|
| Digital model | Manual | Manual | CAD model of a press, updated by an engineer after a retrofit |
| Digital shadow | Automatic | Manual | Dashboard showing live press force; an operator decides what to do |
| Digital twin | Automatic | Automatic | Twin detects die wear and adjusts the press setpoint through the controller |
"Manual" here means a human carries the information, by typing values, exporting files or walking to a panel. "Automatic" means data moves through a system without human intervention. The level is set by the weakest link: if one direction is manual, it is not a full twin.
Level 1: The Digital Model
A digital model is a static or offline representation. A CAD assembly, a spreadsheet of nominal parameters or a simulation set up from datasheets are all digital models. Nothing connects them to the running asset, so they describe the design, not the current condition.
Digital models are still valuable. They are the foundation the other levels build on: geometry for 3D views, nominal values for comparison, and the structure that later becomes a topic hierarchy. But they age the moment the physical asset changes and nobody updates the file.
In MQTT terms: there are no topics. If you exported a value once and published it by hand, you are still at this level.
Level 2: The Digital Shadow
A digital shadow receives an automatic, continuous flow of data from the asset. The digital object always reflects the current state, but any action in response still goes through a person.
This is where most "digital twin" projects actually sit, and that is fine. A live view of every machine, alarms when a value crosses a threshold, and a history for root-cause analysis deliver a lot of value without any automated control.
In MQTT terms: the asset or its gateway publishes telemetry and state, and consumers subscribe. Data flows one way.
connectmq/demo/shd-4q2/press/line3/press07/telemetry (asset -> shadow)
connectmq/demo/shd-4q2/press/line3/press07/state (asset -> shadow, retained)
connectmq/demo/shd-4q2/press/line3/press07/status (Last Will: online/offline)
Try it on the public MQTT test broker, replacing shd-4q2 with your own random ID:
mosquitto_sub -h broker.connectmq.com -p 1883 -i shd-4q2-shadow \
-t "connectmq/demo/shd-4q2/#" -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i shd-4q2-press07 -q 1 \
-t "connectmq/demo/shd-4q2/press/line3/press07/telemetry" \
-m '{"force_kn":812,"stroke_rate_spm":28,"die_temp_c":61.5}'
The subscriber is a digital shadow: it knows what press 07 is doing, but cannot influence it.
Level 3: The Digital Twin
A digital twin adds the automatic return path. The digital object can change the physical asset's behavior, by adjusting a setpoint, scheduling a stop, or changing a recipe, without someone re-keying the decision.
In MQTT terms: you add command topics that the gateway subscribes to, and acknowledgement topics that confirm what was actually applied.
connectmq/demo/shd-4q2/press/line3/press07/cmd/setpoint (twin -> asset)
connectmq/demo/shd-4q2/press/line3/press07/cmd/ack (asset -> twin)
Here is a minimal gateway that closes the loop. It accepts a stroke rate setpoint within limits, applies it, and reports back. The twin logic itself, the part that decides the new setpoint, could be a rules script, an optimization model or an operator-approved recommendation.
import json
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/shd-4q2/press/line3/press07"
current = {"stroke_rate_spm": 28}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/cmd/setpoint", qos=1)
def on_message(client, userdata, msg):
cmd = json.loads(msg.payload)
rate = cmd.get("stroke_rate_spm")
if isinstance(rate, (int, float)) and 10 <= rate <= 35:
current["stroke_rate_spm"] = rate # on a real line: write to the PLC here
result = "applied"
else:
result = "rejected"
client.publish(f"{BASE}/cmd/ack",
json.dumps({"id": cmd.get("id"), "result": result, **current}), qos=1)
client.publish(f"{BASE}/state", json.dumps(current), qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="shd-4q2-press07-gw")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
Send a command and watch the acknowledgement and new retained state arrive in your subscriber:
mosquitto_pub -h broker.connectmq.com -p 1883 -i shd-4q2-twin -q 1 \
-t "connectmq/demo/shd-4q2/press/line3/press07/cmd/setpoint" \
-m '{"id":"sp-17","stroke_rate_spm":24}'
Notice the twin does not assume its command worked. It waits for the asset to report the applied value, and the shadow side of the system displays the measured state. That discipline keeps the twin truthful even when commands are rejected or delayed.
Why the Distinction Matters in Practice
Security scope changes. A shadow only needs read access for consumers and write access for the gateway on telemetry topics. A twin introduces clients that can change physical behavior. That raises the bar on authentication, credential separation and audit logging. The MQTT security best practices guide covers TLS, credentials and least privilege.
Reliability requirements change. Losing a telemetry sample in a shadow is a gap in a chart. Losing or duplicating a command in a twin can mean a wrong setpoint. Use QoS 1 for commands, include IDs for deduplication and add expiry so late commands are ignored. MQTT 5 message expiry intervals are built for exactly this.
Ownership changes. Shadows usually belong to IT or a data team. Twins that write back need sign-off from controls engineering and safety, because the automated path must respect interlocks in the PLC and safety system.
Expectations change. Calling a shadow a twin sets stakeholders up for disappointment. Naming the level honestly lets you plan the next step deliberately.
Classify Your Project: A Checklist
Work through these questions for each asset in scope:
- Is the digital representation tied to one specific, identifiable asset? If not, it is a generic model or simulation.
- Does data from the asset arrive without anyone typing or exporting it? If not, you have a digital model.
- Is the data fresh enough for the decisions you make with it, and do you show when it is stale?
- Can the digital side change the asset's behavior through a system path, such as a command topic consumed by a gateway?
- Does every command get an acknowledgement that reflects what the asset actually applied?
- Are command paths authenticated separately from read-only consumers, and logged?
Answers 1 to 3 positive make a solid digital shadow. Positive answers to 4 to 6 as well make a digital twin. If you are in between, it is common and sensible to run as a shadow first, prove the data quality, and enable the return path one use case at a time.
A related comparison worth reading is device shadow vs digital twin, which looks at the "device shadow" pattern from cloud IoT platforms, and digital twin vs simulation, which separates live twins from offline models.
The Broker in Each Level
From the shadow level upward, everything rests on reliable messaging. The MQTT broker in the cloud becomes the hub through which telemetry flows in and commands flow out, so its availability and security set the ceiling for the whole twin. For anything beyond a demo, use private credentials and TLS on a hosted MQTT broker rather than a public test endpoint.
With ConnectMQ, each gateway and each twin service gets its own credentials and client ID from the portal, and the live topic explorer shows telemetry, commands and acknowledgements in one view while you commission. Threshold alert rules in the portal also cover a common shadow-level need: being told when a value goes out of range.
Move from Shadow to Twin with ConnectMQ
Start with the one-way telemetry of a digital shadow, then add command and acknowledgement topics when you are ready to close the loop. Both run on the same broker. Create a free ConnectMQ Serverless broker, no credit card needed, and connect your first gateway today.
Frequently Asked Questions
What is a digital shadow?
A digital shadow is a digital representation that receives data from a physical asset automatically, but any action back on the asset is taken manually by a person. It reflects reality without influencing it.
Is a digital shadow worse than a digital twin?
Not necessarily. Many monitoring, analytics and maintenance use cases need only a shadow, and it carries lower risk. Move to a twin when automated feedback creates clear value.
How do MQTT topics reflect the difference?
A shadow uses telemetry and state topics flowing from the asset. A twin adds command topics flowing to the asset and acknowledgement topics confirming what was applied.
Does a digital twin have to control the asset directly?
The return path must be automatic, but it can still require approval steps or safety checks in the gateway and controller. What matters is that no one re-keys the decision by hand.
