The digital twin in manufacturing is a family of live models that mirror products, processes and production systems so teams can monitor, analyze and improve them with data rather than guesswork. This guide explains the three main twin types, the use cases that deliver value soonest, and a concrete plan to build the MQTT data foundation every manufacturing twin depends on.
Three Kinds of Digital Twin in Manufacturing
The term covers several different things. Separating them prevents confusion when vendors, engineers and managers talk past each other.
| Twin type | What it mirrors | Main users | Typical data | Example question |
|---|---|---|---|---|
| Product twin | A product design, or an individual unit in service | Design engineers, service teams | CAD, simulation results, field usage data | How does this design behave under real loads? |
| Process twin | A manufacturing process step | Process and quality engineers | Process parameters, quality measurements | Which parameters drive scrap on this weld? |
| Production twin | Machines, lines and the plant | Operations, maintenance, planning | Machine states, counts, alarms, energy | Where is the line losing capacity right now? |
The three connect. A process twin of an injection molding step uses data from the production twin's machines; a product twin may receive as-built data from the process twin. But you do not need all three to start. Most manufacturers begin with the production twin, because the data is already in PLCs and the value is visible quickly. For the underlying concepts and terminology, see the digital twin technology guide.
High-Value Use Cases
Production visibility and OEE
A production twin that shows state, counts and downtime reasons for every machine makes availability, performance and quality losses visible in real time. It is the foundation for most other use cases. The factory digital twin article describes line-level and plant-level designs.
Process optimization and quality
A process twin correlates parameters (temperatures, pressures, speeds, dwell times) with quality outcomes. Engineers can see which parameter windows produce good parts and spot drift before it produces scrap.
Maintenance
Condition data and operating context in one model enable condition-based and predictive maintenance, covered in digital twin predictive maintenance.
Energy
Linking energy meters to production state reveals idle consumption and energy per part, often a quick win.
Commissioning and changeover
A process or line twin can be used to test PLC logic, robot paths or changeover sequences virtually before touching the real equipment, shortening commissioning. This often uses simulation models connected to the same data interfaces as the real line.
Training
A synchronized 3D or schematic view helps new operators understand line behavior without stopping production.
The Data Foundation: Why MQTT
Every manufacturing twin needs the same thing underneath: reliable, structured, real-time data from the shop floor. Point-to-point integrations (each dashboard polling each PLC) do not scale and break whenever something changes. The pattern that has become common in modern plants is a publish/subscribe backbone:
- Edge gateways publish machine data to an MQTT broker once.
- Every twin, dashboard, historian and analytics service subscribes to what it needs.
- The topic tree follows the plant's ISA-95 hierarchy, forming a Unified Namespace.
MQTT suits this role because it is lightweight, event-driven, supported by most modern PLCs and gateways, and offers features twins rely on: retained messages for current state, QoS levels for important events, and in MQTT 5 message expiry, session expiry and shared subscriptions. These features are what keep a twin accurate when devices reconnect or data goes stale.
Where the broker runs is a practical question. Self-hosting means patching, certificates, monitoring and scaling are your job. A managed MQTT broker moves that work to the provider. ConnectMQ offers shared Serverless plans, Dedicated isolated clusters, BYOC deployments in your own cloud account managed by ConnectMQ, and a Self Managed Enterprise option for plants that must keep everything on premises.
Getting Started: A Step-by-Step Plan
- Pick one line and one problem. For example, unexplained downtime on Line 2. A focused scope gets a working twin in weeks rather than a roadmap that runs for years.
- Inventory signals. For each machine, list the PLC tags for state, part count, reject count, active alarm and cycle time. Confirm they can be read by a gateway.
- Define the topic hierarchy. Use ISA-95 levels:
<enterprise>/<site>/<area>/<line>/<cell>/<data-type>. The ISA-95 digital twin guide explains naming rules. - Define payloads. JSON with explicit units and source timestamps is easy to start with. If your edge uses Sparkplug B, ConnectMQ can decode it and republish into ISA-95 topics.
- Connect the edge. Use a gateway such as Node-RED, the PLC's native MQTT client, or a Sparkplug edge node. Publish over TLS with one credential per gateway.
- Verify the data in the broker's topic explorer before building any visuals.
- Store history with a separate subscriber writing to a time-series database.
- Build the twin view: a simple line schematic or 3D scene subscribing to live topics.
- Review with operators after two weeks, fix what is confusing, then extend to the next line.
Hands-On: Publish Production Data in Minutes
Before connecting a real PLC, you can prove the data flow with the public MQTT test broker at broker.connectmq.com. Use a unique topic prefix and simulated values only, since the public area is readable by everyone.
Publish a machine state and a part count from the command line:
ID=$(head -c4 /dev/urandom | od -An -tx1 | tr -d ' \n')
BASE="connectmq/demo/$ID/acme/line2/press1"
mosquitto_pub -h broker.connectmq.com -p 1883 -i "press1-$ID" -r -q 1 \
-t "$BASE/state" -m '{"state":"running","ts":"2026-10-16T08:00:00Z"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i "press1c-$ID" -q 0 \
-t "$BASE/counts" -m '{"good":1520,"reject":12,"ts":"2026-10-16T08:00:05Z"}'
echo "Subscribe with: mosquitto_sub -h broker.connectmq.com -p 1883 -i viewer-$ID -t \"connectmq/demo/$ID/#\" -v"
A Node-RED gateway reading a PLC would publish the same messages using an mqtt out node with an mqtt-broker config pointing at broker.connectmq.com on port 1883, or at your private broker on port 8883 with TLS and your YOUR_USERNAME, YOUR_PASSWORD and YOUR_CLIENT_ID credentials.
A minimal twin service in Python can then compute a live reject rate per machine and publish it back:
import json
import uuid
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/REPLACE_ID" # use the id printed above
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{PREFIX}/+/+/+/counts", qos=1)
def on_message(client, userdata, msg):
counts = json.loads(msg.payload)
total = counts["good"] + counts["reject"]
rate = round(100 * counts["reject"] / total, 2) if total else 0.0
kpi_topic = msg.topic.rsplit("/", 1)[0] + "/kpi"
client.publish(kpi_topic, json.dumps({"rejectRatePct": rate}), qos=1, retain=True)
print(kpi_topic, rate)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"kpi-svc-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
The pattern scales: twin services subscribe to raw topics and publish derived KPIs to sibling topics, so every consumer sees consistent numbers.
Common Mistakes When Starting
- Starting with the 3D model. Visuals impress in demos but depend entirely on data. Build the data foundation first.
- Boiling the ocean. A plant-wide program with no first use case rarely survives budget reviews.
- Ignoring OT security. Gateways should connect outbound over TLS; PLC networks stay segregated.
- No owner for the topic hierarchy. Without governance, naming drifts and the twin breaks.
- Confusing simulation with a twin. A simulation without live data is valuable, but it is not a twin; see digital twin vs simulation.
Start Your Manufacturing Digital Twin on ConnectMQ
ConnectMQ gives your plant an MQTT 5 backbone with TLS, ISA-95 aware device views and Sparkplug B decoding, from a free shared broker up to dedicated and BYOC deployments. Sign up at app.connectmq.com for the free Serverless plan, no credit card required, and connect your first line this week.
Frequently Asked Questions
What is a digital twin in manufacturing?
It is a live digital model of a product, process or production system that is kept synchronized with real data, used to monitor, analyze and improve manufacturing operations.
Which digital twin should a manufacturer build first?
Usually a production twin of one line, because machine state and count data are readily available from PLCs and the value from visibility and downtime analysis appears quickly.
Why use MQTT for manufacturing digital twins?
MQTT decouples data producers from consumers, is lightweight and event-driven, and offers retained messages and QoS levels that keep twin state accurate and current.
Do I need Sparkplug B for a manufacturing twin?
No. Plain JSON on ISA-95 topics works well. If your devices already use Sparkplug B, ConnectMQ can decode it and republish the data into ISA-95 topics.
