Types of Digital Twins: Component, Asset, System and Process Twins Explained

The types of digital twins are usually grouped by scope: component, asset, system and process twins. Each answers different questions and needs data at a different granularity, from high-frequency vibration readings to hourly order throughput. This guide explains the four types with concrete examples and shows how to design MQTT topics and payloads so one broker can feed all of them.

For definitions and history, see the digital twin technology guide.

Why Scope Matters

Picking the wrong scope is one of the most common reasons twin projects stall. Teams aim for a "factory twin" on day one, discover that they lack reliable data from individual machines, and spend months on plumbing before showing value. Others build an excellent bearing model that nobody uses because the decisions are made at line level.

Thinking in types helps you pick the level where the decision lives, then collect exactly the data that level needs. The levels also nest: a process twin is built from system twins, which are built from asset twins, which contain component twins. Good data design lets you climb that ladder without rebuilding everything.

The Four Types of Digital Twins

Some frameworks add a fifth layer for whole organizations or cities, but it follows the same logic as a process twin at larger scale.

Component Twins

A component twin models one part whose behavior is critical to its parent asset. Bearings, gearboxes, seals and heating elements are typical candidates because their degradation is gradual and measurable.

Data needs: component twins want the richest data. Vibration analysis may require sampling thousands of times per second. Sending that raw stream over MQTT is rarely sensible; instead, an edge device computes features such as RMS velocity, peak frequency bands or temperature gradients, and publishes those every few seconds.

Payload example:

{
  "ts": "2026-10-16T08:15:00Z",
  "rms_velocity_mm_s": 2.4,
  "peak_freq_hz": 147.5,
  "kurtosis": 3.1,
  "bearing_temp_c": 58.2
}

Topic: .../utilities/cooling/pump104/bearing-de/features

Keep raw waveforms at the edge or upload them on demand to file storage; use the broker for the features and alarms that drive decisions. On the public test broker messages are capped at 64 KB, and even on private plans small, frequent messages are healthier than large blobs.

Asset Twins

The asset twin is where most projects should start. It represents a whole machine: its operating state, key process values, alarms and counters. It is the natural unit for 3D visualization, maintenance and remote support, as in a robot arm digital twin that mirrors joint angles.

Data needs: status changes as events, process values every one to ten seconds, and the current state retained on the broker so new viewers see it immediately.

mosquitto_pub -h broker.connectmq.com -p 1883 -i tdt-8k3-pump104 -r -q 1 \
  -t "connectmq/demo/tdt-8k3/site1/utilities/cooling/pump104/state" \
  -m '{"mode":"running","rpm":1480,"flow_m3h":42.1,"alarms":[]}'

Asset twins benefit enormously from a consistent hierarchy. If every asset publishes under site/area/line/cell, which mirrors ISA-95, then system and process twins can subscribe with wildcards instead of a hand-maintained tag list. The Sparkplug B and Unified Namespace guide explains how that hierarchy is built.

System Twins

A system twin combines several assets to understand their interaction. A cooling loop twin, for example, needs pump flow, chiller load, valve positions and temperatures at several points, because the interesting behavior emerges between machines rather than inside any one of them.

Data needs: a system twin subscribes to many asset topics, aligns them in time and often computes derived values like total flow, balance errors or line efficiency. It typically publishes those results back to the broker under the system's own node in the hierarchy:

import json

import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/tdt-8k3/site1/utilities/cooling"
flows = {}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{ROOT}/+/state", qos=1)


def on_message(client, userdata, msg):
    asset = msg.topic.split("/")[-2]
    if asset == "system":
        return
    data = json.loads(msg.payload)
    if "flow_m3h" in data:
        flows[asset] = data["flow_m3h"]
        summary = {"total_flow_m3h": round(sum(flows.values()), 1),
                   "pumps_reporting": len(flows)}
        client.publish(f"{ROOT}/system/state", json.dumps(summary), qos=1, retain=True)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="tdt-8k3-cooling-system")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()

The single-level wildcard + picks up every asset in the loop, so adding a pump means no code change. Publishing the system result under its own topic lets dashboards and the process twin consume it without recomputing.

Process Twins

A process twin represents a whole operation, such as a production run from raw material to finished goods. It blends machine data with business context: orders, recipes, quality results, energy and labor. Questions shift from "is this machine healthy" to "will we ship on time" and "what does each unit really cost".

Data needs: low-frequency, high-context events. Order started, batch completed, quality hold, shift total. Much of this comes from MES and ERP systems rather than sensors, which is why integration patterns matter: a small service reads from those systems and publishes events into the same topic tree, so everything lives in one namespace.

Process twins rarely need sub-second data, but they need it to be complete and trustworthy. Missed "batch completed" events skew every KPI downstream, so use QoS 1 for business events and design consumers to be idempotent.

Choosing the Right Type

Use this sequence when scoping a new initiative:

1. Name the decision you want to improve and who makes it.
2. Identify the level where that decision lives: part, machine, group of machines or whole operation.
3. List the data that decision needs and the freshness it requires.
4. Check whether the lower levels already produce that data reliably. If not, start one level lower.
5. Design topics so the next level up can subscribe by wildcard.
6. Deliver one asset or system end-to-end before widening scope.

Most teams find that asset twins deliver the quickest wins and create the data foundation for everything else. The how to build a digital twin guide walks through that first build step by step, and the digital twin maturity model shows how capability grows over time.

One Broker, Every Type

All four types can share one MQTT infrastructure, as long as it handles high-rate component features, retained asset state and reliable business events side by side. That is the role of a cloud MQTT broker: one secure endpoint that edge devices, twin services and browser viewers all connect to.

ConnectMQ detects ISA-95 and Unified Namespace topic structures and shows devices by hierarchy level in its portal, which makes it easy to see where each twin type sits. It also decodes Sparkplug B and can republish it into readable ISA-95 topics, so legacy Sparkplug edge nodes can feed asset and system twins without custom decoding. To experiment first, the free public MQTT broker is fine for non-sensitive demo data.

Start Your First Twin on ConnectMQ

Pick one asset, publish its state under a clean hierarchy, and build up from there. Sign up for a free ConnectMQ Serverless broker, no credit card required, and you will have private credentials and TLS endpoints ready for every type of twin you build.

Frequently Asked Questions

What are the main types of digital twins?

The common classification by scope is component, asset, system and process twins. Some models add product, organization or city twins, which follow the same idea at different scales.

Which type of digital twin should I build first?

An asset twin is usually the best first step. It delivers visible value quickly and produces the clean, structured data that system and process twins depend on.

Do component twins need special hardware?

Often they need sensors with higher sampling rates, such as accelerometers, plus an edge device that converts raw signals into features before publishing them.

Can one MQTT broker serve all twin types?

Yes. With a consistent topic hierarchy, component features, asset states and process events coexist in one namespace, and each twin subscribes only to what it needs.