Digital Twin Architecture: Data, Model and Visualization Layers Explained

A clear digital twin architecture is what separates a twin that scales to hundreds of assets from a demo that collapses after the first five. This guide walks through a reference architecture layer by layer, from sensors and edge gateways through a messaging backbone to state stores, models and 3D visualization, so you can design a stack where each part has one job and can be replaced independently.

For the concepts behind twins, see our digital twin technology guide.

The Six Layers of a Digital Twin Architecture

Most successful twins, whatever vendor or framework they use, end up with these layers:

The key design rule: layers talk to each other through well-defined contracts (topics and payload schemas), never through private shortcuts. That is what lets you swap a dashboard for a 3D viewer or add an analytics job without touching device firmware.

Layer 1: Device and Edge

Physical assets rarely speak a twin-friendly language. A CNC controller exposes OPC UA or a vendor protocol; an old pump has a 4–20 mA signal into a PLC; a new sensor may run on an ESP32. The edge layer bridges this gap.

Responsibilities at the edge:

• Protocol translation from Modbus, OPC UA or fieldbus into MQTT.
• Normalisation into consistent units and names, so spindle_rpm means the same thing everywhere.
• Deadband and rate control, publishing a value only when it changes meaningfully or at a fixed interval.
• Buffering when the uplink drops, then replaying data with original timestamps.

Put timestamps on at the source. A twin that only knows when the broker received a value cannot tell a slow network from a slow machine.

Layer 2: The Messaging Backbone

The messaging layer is the spine of the digital twin architecture. Every producer publishes to it and every consumer subscribes from it, which means devices never need to know who is watching. An MQTT broker is the most common choice because it gives you:

• Hierarchical topics that mirror the asset hierarchy.
• Wildcards so a line-level viewer subscribes to plant1/line2/# and gets every machine.
• Retained messages that hand new subscribers the latest state immediately.
• QoS levels to trade delivery guarantees against overhead.
• Last will messages so the twin knows when a device disappears.

A good topic design follows the ISA-95 style hierarchy, ending in a message class:

<enterprise>/<site>/<area>/<line>/<asset>/telemetry
<enterprise>/<site>/<area>/<line>/<asset>/state
<enterprise>/<site>/<area>/<line>/<asset>/cmd
<enterprise>/<site>/<area>/<line>/<asset>/cmd/ack

Separate telemetry (a stream, not retained), state (current values, retained) and cmd (commands, never retained). Mixing them is the most common source of twin bugs, such as a stale command replaying to a device after reconnect. Our digital twin MQTT guide goes further into these patterns.

Running the broker yourself means handling TLS certificates, authentication, scaling and monitoring. A fully managed MQTT service such as ConnectMQ removes that work so the team can focus on the twin itself.

Layer 3: State

The state layer answers one question: what is the asset's current value right now? There are three common options:

1. Retained MQTT topics. Each asset or property has a retained message. Simple, no extra infrastructure, and viewers get full state on connect. Detailed in using retained MQTT messages as digital twin state.
2. A twin service. A dedicated service, such as Eclipse Ditto or a custom microservice, subscribes to telemetry and maintains a JSON document per asset, exposing it via API.
3. An in-memory or key-value store fed by a subscriber, useful when many apps query state by API rather than MQTT.

For many teams the right answer is retained topics first, then a twin service once you need queries, access control per asset, or desired vs reported state handling. See digital twin state synchronization for those patterns.

Layer 4: History

Live state is not enough for trends, root-cause analysis or machine learning. A history subscriber listens to telemetry topics and writes to a time-series database. Tools like Telegraf, Node-RED or a small Python service act as normal MQTT clients for this:

import json
import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe("acme/plant1/+/+/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    point = json.loads(msg.payload)
    asset_path = msg.topic.rsplit("/", 1)[0]
    # Replace with a write to your time-series database
    print(asset_path, point)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()

Keep history writers independent from the live path. If the database is slow, the 3D view should not lag.

Layer 5: The Model

The model layer turns numbers into meaning. At minimum it is an asset registry: which assets exist, how they relate (site contains line contains machine), what properties each has and in which units. More advanced twins add:

• Formal schemas such as DTDL interfaces or Asset Administration Shell submodels.
• Derived values like OEE, efficiency or remaining useful life.
• Simulation or ML models that predict behaviour and compare it with reality.

Store the model separately from the data stream, version it, and reference it from topics through stable asset IDs. When a machine is replaced, the model changes but the topic contract can stay the same.

Layer 6: Visualization and Applications

The top layer is what people see: dashboards, 3D scenes, mobile apps and alert consoles. Browser-based 3D viewers connect directly to the broker over secure WebSocket, subscribe to the relevant branch, load retained state on connect and then animate as live messages arrive. With MQTT.js this is a few lines:

import mqtt from "mqtt";

const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId: "twin-viewer-" + Math.random().toString(16).slice(2, 10),
  protocolVersion: 5,
});

client.on("connect", () => {
  client.subscribe("connectmq/demo/a91c/plant1/#");
});

client.on("message", (topic, payload) => {
  const assetPath = topic.split("/").slice(3, -1).join("/");
  updateSceneObject(assetPath, JSON.parse(payload.toString()));
});

function updateSceneObject(path, values) {
  console.log("update", path, values);
}

In production, use credentials scoped for read-only viewers and keep command publishing behind a backend that validates requests.

Digital Twin Architecture Checklist

Before building, confirm each point:

1. Topic hierarchy defined and documented, with separate telemetry, state and command classes.
2. Payload schema per asset type, including units and source timestamps.
3. Retained state for every property a viewer needs on load.
4. Last will messages so offline assets show as offline.
5. History writer decoupled from the live path.
6. Asset model versioned and keyed by stable IDs.
7. TLS everywhere outside the plant network, unique credentials per device or gateway.
8. Command path with acknowledgements and timeouts.

Where ConnectMQ Fits in the Architecture

ConnectMQ fills the messaging layer: a cloud MQTT broker with MQTT 3.1.1 and 5.0, TLS on 8883, secure WebSocket on 8084 for browser viewers, retained messages and shared subscriptions for scaling consumers on paid plans. It also detects ISA-95 topic hierarchies and can decode Sparkplug B and republish it into ISA-95 topics, which simplifies the edge-to-twin contract. State stores, history databases and model services remain your own components connecting as MQTT clients. The ConnectMQ 3D digital twin demo shows the visualization layer of this architecture running live over WSS.

Start Your Digital Twin Architecture on ConnectMQ

Sign up at app.connectmq.com, choose the free Serverless plan with no credit card, create a broker and use the generated credentials to connect your edge gateway and your first viewer. The in-browser client and live topic explorer let you validate your topic design before you write a line of visualization code.

Frequently Asked Questions

What is the most important layer in a digital twin architecture?

The messaging and data contract layer. If topics and payloads are well designed, every other layer can be built, replaced or scaled independently.

Do I need a separate database for twin state?

Not at first. Retained MQTT messages can hold current state for many twins; add a twin service or store when you need queries, per-asset access control or desired state handling.

Should 3D viewers connect directly to the MQTT broker?

For read-only live views, connecting over secure WebSocket is simple and fast. Route commands through a backend that validates and audits them.

How does a digital twin architecture handle offline devices?

Use MQTT last will messages to publish an offline status, buffer data at the edge during outages, and include source timestamps so late data is placed correctly.