A digital twin maturity model gives you a shared language for where a twin initiative stands and what it takes to move forward. This guide defines six practical levels, from a static model to autonomous closed-loop control, and for each one lists the capabilities, the data infrastructure and the MQTT patterns it needs. Use the self-assessment at the end to place your project and plan the next step.
For the fundamentals, see the digital twin technology guide.
Why Use a Maturity Model
Twin projects often stall because stakeholders imagine different end states. Operations expect a live dashboard, management expects predictive maintenance, engineering expects automated optimization. A maturity model makes those differences explicit and turns them into a sequence. It also prevents the most expensive mistake: trying to build level 4 analytics on level 1 data.
Several published frameworks exist, with different numbers of levels and names. The version below is deliberately practical: each level is defined by what the twin can do and what infrastructure it needs, so you can check it against your own system.
The Six Levels
| Level | Name | What the twin does | Key question answered |
|---|---|---|---|
| 0 | Digital model | Static representation (CAD, documentation, nominal data) | What was designed? |
| 1 | Descriptive | Shows live state of assets | What is happening now? |
| 2 | Diagnostic | Adds history, alerts and context | Why did it happen? |
| 3 | Predictive | Forecasts behavior from data and models | What will happen? |
| 4 | Prescriptive | Recommends actions with expected outcomes | What should we do? |
| 5 | Autonomous | Acts on the asset within guardrails | Can the system handle it itself? |
Level 0: Digital Model
You have geometry, drawings, datasheets and perhaps simulation models, but nothing connects them to the running asset. This is the foundation, not a failure: the model provides the structure (asset names, hierarchy, nominal values) that later levels attach data to.
Infrastructure: document management and CAD. Next step: agree on an asset hierarchy, ideally following ISA-95 levels, because it becomes your topic structure.
Level 1: Descriptive Twin
Live data flows automatically from assets into the twin, which shows current state: running or stopped, key values, alarms. This is often a 3D view or dashboard that people actually look at.
Infrastructure: edge gateways that read PLCs or sensors, an MQTT broker, and a viewer. The essential MQTT patterns are:
- A consistent topic hierarchy, for example
site/area/line/cell/asset/state. - Retained state messages so viewers show current values the moment they connect.
- Last Will messages so the twin knows when a gateway goes offline.
# Gateway registers a retained Last Will so the twin learns when it drops offline
mosquitto_sub -h broker.connectmq.com -p 1883 -i dtm-6r2-gw \
--will-topic "connectmq/demo/dtm-6r2/site1/line1/status" --will-payload offline \
--will-retain --will-qos 1 -t "connectmq/demo/dtm-6r2/site1/line1/cmd/#"
You can prototype this level on the free public MQTT broker with demo data. The robot arm digital twin is a complete level 1 example with a 3D view.
Level 2: Diagnostic Twin
The twin now remembers. Time-series history lets engineers scroll back to the moment a fault occurred, correlate signals and compare shifts. Threshold alerts notify people when values leave their normal range, and context such as order, recipe or operator is attached to data.
Infrastructure: a historian or time-series database fed by an MQTT subscriber, alert rules, and context from MES or ERP published into the same namespace. Data quality starts to matter: timestamps at the source, units in payloads, and stale-data detection.
Here is a small subscriber that writes every state message to a local SQLite file for diagnosis. In production you would use a proper time-series database, but the pattern is identical.
import json
import sqlite3
import time
import paho.mqtt.client as mqtt
ROOT = "connectmq/demo/dtm-6r2"
db = sqlite3.connect("history.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS samples (ts REAL, topic TEXT, payload TEXT)")
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{ROOT}/#", qos=1)
def on_message(client, userdata, msg):
try:
json.loads(msg.payload)
except ValueError:
return # skip non-JSON messages such as status strings
db.execute("INSERT INTO samples VALUES (?, ?, ?)",
(time.time(), msg.topic, msg.payload.decode()))
db.commit()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="dtm-6r2-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()
For alerts at this level, you may not need code at all: the ConnectMQ portal includes threshold alert rules and an alerts log, which covers the common "tell me when temperature exceeds X" requirement during early rollout.
Level 3: Predictive Twin
With enough clean history, the twin forecasts: remaining useful life of a component, likely quality deviations, energy demand for the next shift. Models can be physics-based, data-driven or hybrid.
Infrastructure: feature extraction at the edge for high-rate signals, a data platform where models are trained, and an inference service that subscribes to live data and publishes predictions back into the namespace on their own topics, for example .../pump104/predictions/rul. Keeping predictions on separate topics prevents anyone confusing them with measurements. The digital twin predictive maintenance guide goes into model choices.
This level is where data gaps hurt most. Models trained on history with missing intervals or inconsistent units perform poorly, which is why level 2 discipline pays off.
Level 4: Prescriptive Twin
The twin recommends actions and estimates their effect: slow the line by a given amount to protect a worn bearing until the planned stop, change a setpoint to reduce scrap, reschedule an order. Humans still approve and execute.
Infrastructure: what-if simulation driven by live state, optimization logic, and a workflow for recommendations and approvals. In MQTT terms, recommendations are published to topics that an operator interface subscribes to, and approvals produce commands, which leads naturally to level 5.
Level 5: Autonomous Twin
The twin acts directly on the asset within defined guardrails, closing the loop. Typical scope is narrow and well understood: tuning a setpoint within a band, sequencing pumps for energy efficiency, rerouting work between parallel machines.
Infrastructure: command topics consumed by gateways that validate every request against limits and interlocks, acknowledgements that report what was actually applied, message expiry so late commands are discarded, and full audit logging. Safety functions always remain in the PLC and safety system, never in the twin.
{
"id": "cmd-2026-10-16-0042",
"issued_by": "energy-optimizer",
"target": "site1/utilities/cooling/pump104",
"setpoint": { "rpm": 1350 },
"valid_for_s": 30,
"reason": "chiller load low, reduce pump speed within approved band"
}
MQTT 5 helps here with message expiry, response topics and correlation data for request/response; the MQTT 5 features guide explains them.
Infrastructure by Level
| Capability | L1 | L2 | L3 | L4 | L5 |
|---|---|---|---|---|---|
| Topic hierarchy and retained state | Required | Required | Required | Required | Required |
| TLS and per-client credentials | Recommended | Required | Required | Required | Required |
| Time-series history | Optional | Required | Required | Required | Required |
| Alerts and context data | Optional | Required | Required | Required | Required |
| Edge feature extraction | Optional | Optional | Often required | Often required | Often required |
| Prediction and simulation services | No | No | Required | Required | Required |
| Command topics with acknowledgements | No | No | No | For approved actions | Required |
| Audit logging of commands | No | No | No | Required | Required |
Self-Assessment Checklist
Score one point for each statement that is true today:
- Every asset in scope has a unique, hierarchical identifier used in topics.
- Live state reaches the twin automatically and is retained for new viewers.
- The twin shows when data is stale or a gateway is offline.
- At least three months of clean history are stored with source timestamps and units.
- Alerts reach the right people and are logged.
- Predictions are published separately from measurements and are checked against reality.
- Recommendations include their expected effect and an approval record.
- Commands are validated, acknowledged, expire if late and are fully audited.
Zero to two points suggests level 1; three to five, level 2; six, level 3; seven, level 4; all eight, ready for selective level 5 use cases. Move one level at a time and only for use cases with clear value. The digital twin ROI guide helps decide which ones.
The Backbone at Every Level
Every level from 1 upward runs on the same messaging backbone, and its demands grow as you climb: more clients, stricter security, commands that must not be lost. Start on a managed MQTT broker so the backbone is ready for level 5 discipline even while you are at level 1. ConnectMQ supports MQTT 5 features such as message expiry and response topics, TLS and Secure WebSocket endpoints, credentials bound to client IDs, and an ISA-95 device view that makes the hierarchy from level 0 visible in the portal.
Climb the Maturity Ladder with ConnectMQ
Get level 1 working on a solid broker and every later level becomes an addition, not a rebuild. Start free on ConnectMQ with the Serverless plan, no credit card required.
Frequently Asked Questions
What is a digital twin maturity model?
It is a framework that describes stages of twin capability, from static models through live monitoring and prediction to autonomous control, along with what each stage requires.
Which maturity level should we target?
Target the lowest level that delivers the value you need. Many organizations get most of their benefit from levels 1 and 2, then add prediction for specific critical assets.
Can we skip levels?
Rarely. Predictive and prescriptive twins depend on the clean live data and history built at levels 1 and 2, so skipping usually means rebuilding later.
Is autonomous control safe?
It can be when scope is narrow, actions are bounded by validated limits, commands are acknowledged and audited, and safety functions stay in the controller and safety system.
