A factory digital twin is a live, data-driven model of your plant that mirrors what machines, lines and areas are doing right now. In this guide you will learn which use cases justify a twin, how to structure line-level and plant-level models, and how to feed them with ISA-95 structured MQTT data so the twin stays accurate without custom point-to-point integrations.
What a Factory Digital Twin Actually Is
The term gets stretched in marketing, so it helps to be precise. A factory digital twin has three parts:
- A model of the physical assets and their relationships: machines belong to cells, cells to lines, lines to areas, areas to a site.
- A live data connection that keeps the model's state synchronized with reality, usually within seconds.
- A purpose: something people or software do with the synchronized model, such as spotting a stalled conveyor, comparing shift performance or testing a scheduling change.
Without the live data connection you have a 3D drawing or a simulation. Without the purpose you have an expensive screensaver. Most successful projects start with a narrow purpose and grow the model outward. If you are new to the concept, the digital twin technology guide covers the fundamentals and terminology.
Line-Level vs Plant-Level Twins
Factory twins usually exist at two scales, and they answer different questions.
| Aspect | Line-level twin | Plant-level twin |
|---|---|---|
| Scope | One production line or cell | All areas, lines and utilities on a site |
| Typical users | Line operators, maintenance technicians | Plant managers, production planners, energy managers |
| Update rate | Sub-second to a few seconds | Seconds to minutes (aggregated) |
| Key signals | Machine state, cycle time, spindle load, part counts, alarms | OEE per line, throughput, energy per unit, WIP, downtime reasons |
| Visualization | Detailed 3D or 2D schematic of the line | Floor plan or hierarchy tree with drill-down |
| Main questions | Which station is the bottleneck right now? Why did it stop? | Which line is underperforming this week? Where is energy wasted? |
A common mistake is building a plant-level twin with line-level detail everywhere. That multiplies the integration effort and overwhelms users. A better pattern is a plant-level overview that drills down into a handful of detailed line twins where the business case is strongest.
Use Cases That Justify a Factory Digital Twin
Real-time production visibility
The simplest and most common use case: one screen that shows every machine's state (running, idle, stopped, faulted) with colors and counters, so supervisors stop walking the floor to find problems. The value comes from the hierarchy. When the plant view turns red, a supervisor can click into the area, then the line, then the station.
Bottleneck and flow analysis
A line twin that receives cycle-complete events from every station can show where parts queue and which station starves the next. Because the twin keeps the topology (station A feeds conveyor B feeds station C), it can highlight the constraint rather than just listing slow machines.
Downtime and alarm context
When a machine stops, the twin can display the alarm, the last few values of related signals and the state of upstream and downstream equipment. Maintenance gets context before arriving at the machine. For forecasting failures rather than reacting to them, see digital twin predictive maintenance.
Energy and utilities
Compressors, furnaces, chillers and pumps are often the largest energy consumers. Adding metered power to the twin lets you correlate consumption with production state, for example a furnace held at temperature while the line is idle. The energy digital twin article goes deeper on modeling energy flows.
Training and remote support
A synchronized 3D view helps new operators understand how a line behaves and lets remote experts see the same state the local team sees.
Reference Architecture for a Factory Digital Twin
A practical factory twin has four layers. Keeping them decoupled is what lets the twin evolve without rewiring the plant.
- Edge sources. PLCs, CNC controllers, energy meters and sensors. Data is collected by an edge gateway (Node-RED, a PLC-native MQTT client, or a Sparkplug B edge node) and published over MQTT.
- The MQTT broker as the data backbone. Every source publishes once; every consumer subscribes to what it needs. This is the Unified Namespace pattern. A managed MQTT broker removes the burden of patching, securing and scaling this central piece yourself.
- Twin services. Small subscribers that compute derived values (OEE, cycle-time averages, state durations) and write history to a time-series database such as InfluxDB or TimescaleDB.
- Twin clients. 3D web viewers, dashboards and analytics tools that subscribe to live topics and query history.
The broker matters because a twin is only as accurate as its data path. Retained messages give a newly opened twin viewer the last known state of every machine instantly, instead of waiting for the next change. MQTT 5 message expiry lets stale values drop out, so a twin does not show a machine as "running" based on a value from yesterday. The digital twin architecture post covers these layers in more detail.
Structuring Factory Data with ISA-95 Topics
The topic hierarchy is the skeleton of the twin. If topics follow the ISA-95 equipment hierarchy, the twin can build its tree directly from topic names:
connectmq/<site>/<area>/<line>/<cell-or-machine>/<data-type>
connectmq/factory1/production/line1/cnc1/telemetry
connectmq/factory1/production/line1/cnc1/state
connectmq/factory1/production/line1/robot1/telemetry
connectmq/factory1/utilities/compressors/comp1/energy
A twin viewer can then subscribe to connectmq/factory1/production/line1/# for a line twin, or to connectmq/factory1/+/+/+/state for a plant overview of machine states.
ConnectMQ detects ISA-95 and Unified Namespace topics and shows them in a devices view organized by ISA-95 levels, which makes it easy to check that the hierarchy your twin expects is what the plant actually publishes. If your edge uses Sparkplug B, ConnectMQ decodes the Protobuf payloads and can republish them into ISA-95 topics, for example spBv1.0/factory1/DDATA/line1/cnc1 becomes connectmq/factory1/production/line1/cnc1/telemetry. Your twin client then consumes decoded data on readable ISA-95 topics. The ISA-95 digital twin guide explains the hierarchy levels in depth.
Hands-On: Feed a Line Twin from a Simulated Machine
You can prototype a line twin in minutes against the public MQTT test broker at broker.connectmq.com. Remember the public area is readable by anyone, so use a unique topic prefix and simulated data only.
This Python script (paho-mqtt 2.x) simulates a CNC machine publishing state and telemetry with retained state messages:
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}/factory1/production/line1/cnc1"
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"cnc-sim-{uuid.uuid4().hex[:6]}")
def on_connect(client, userdata, flags, reason_code, properties):
print(f"Connected: {reason_code}. Publishing under {PREFIX}")
client.on_connect = on_connect
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
state = "running"
parts = 0
try:
while True:
if random.random() < 0.05:
state = random.choice(["running", "idle", "fault"])
client.publish(f"{PREFIX}/state", json.dumps({"state": state, "ts": time.time()}), qos=1, retain=True)
if state == "running":
parts += 1
telemetry = {
"spindleRpm": random.randint(7800, 8200) if state == "running" else 0,
"spindleLoadPct": round(random.uniform(35, 70), 1) if state == "running" else 0,
"partCount": parts,
"ts": time.time(),
}
client.publish(f"{PREFIX}/telemetry", json.dumps(telemetry), qos=0)
time.sleep(1)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Watch it from another terminal (replace the prefix with the one the script prints):
mosquitto_sub -h broker.connectmq.com -p 1883 -i twin-viewer-4821 -t "connectmq/demo/abcd1234/factory1/#" -v
In a browser-based twin, connect over Secure WebSocket at wss://broker.connectmq.com:8084/mqtt with MQTT.js and map each topic to a 3D object: state drives the color, spindle load drives a gauge. ConnectMQ's own 3D digital twin web demo works exactly this way, with a CNC, robot arm, furnace, tank, conveyor and pump animated live over WSS.
Moving from Prototype to Production
When the prototype convinces stakeholders, move to a private broker. Create one at ConnectMQ and use the generated YOUR_USERNAME, YOUR_PASSWORD and YOUR_CLIENT_ID over TLS on port 8883. Checklist for a production factory twin:
- Freeze the topic hierarchy and document it. Renaming topics later breaks every twin client.
- Use retained messages for state, not for high-rate telemetry.
- Set message expiry on values that should not outlive their relevance.
- Separate live and historical paths: the broker delivers live data; a subscriber writes history to a database.
- Size connections: count edge gateways, twin services and viewer sessions. The free Serverless plan allows up to 25 connections; paid Serverless goes to 1,000 with shared subscriptions for load-balanced twin services; Dedicated gives an isolated cluster.
- Secure the edge: TLS everywhere, one credential per gateway, no shared client IDs.
Common Pitfalls
- Modeling before data exists. Teams spend months on 3D models and then discover the PLC does not expose the needed tags. Inventory signals first.
- Polling instead of event-driven updates. A twin that polls databases every few seconds feels sluggish. Subscribe to the broker directly.
- No timestamps at the source. Without source timestamps you cannot tell network delay from machine behavior.
- One giant payload. Splitting state, telemetry and alarms into separate topics lets clients subscribe narrowly.
Build Your Factory Digital Twin on ConnectMQ
Start with the public broker, then move to a private broker when you connect real equipment. Sign up at app.connectmq.com for the free Serverless plan with no credit card, create a broker, and use the live topic explorer and ISA-95 devices view to verify your factory data before you build the twin on top.
Frequently Asked Questions
What data does a factory digital twin need first?
Start with machine state, part counts and active alarms per machine. These three signals already enable live visibility, downtime context and basic OEE, and they are available from most PLCs and CNC controllers.
Do I need a 3D model for a factory digital twin?
No. Many effective twins use a 2D floor plan or a hierarchy tree. 3D helps for training and spatial reasoning, but the synchronized data model is what makes it a twin.
How does MQTT keep a factory twin up to date?
Edge gateways publish changes to hierarchical topics and twin clients subscribe to them, so updates arrive in near real time. Retained messages give new clients the last known state immediately.
Can I use Sparkplug B devices with a factory twin?
Yes. ConnectMQ decodes Sparkplug B and can republish the data into ISA-95 topics, so twin clients can consume decoded data without implementing Sparkplug themselves.
