Structuring an ISA-95 Digital Twin with the Equipment Hierarchy

An ISA-95 digital twin uses the equipment hierarchy from the ISA-95 standard (enterprise, site, area, line, cell) as the backbone of the twin model and of the MQTT topic tree that feeds it. In this guide you will learn how the levels map to twin objects and topics, how to name things consistently, how Sparkplug B data fits in, and how to validate that your plant actually publishes the structure your twin expects.

Why Digital Twins Need a Hierarchy

A twin of a single machine is easy to organize. A twin of a plant with hundreds of machines, or a company with several plants, quickly turns into a tangle of ad-hoc names unless there is an agreed structure. Without one:

• Each team invents its own naming, so the same press is Press_07, L2-P7 and press7 in three systems.
• Twin viewers need custom code per data source.
• Aggregations such as "OEE for all lines in area Assembly" require manual mapping tables.

ISA-95 (IEC 62264) already defines a widely recognized equipment hierarchy for manufacturing. Using it for the twin means the model matches how plant people think about their operation, and it aligns with MES and ERP concepts. For twin fundamentals, see the digital twin technology guide.

The ISA-95 Equipment Hierarchy Levels

The standard distinguishes several kinds of work centers (production lines, process cells, production units, storage zones) depending on the type of manufacturing. For MQTT topics you rarely need that distinction in the path; store it as metadata on the twin object instead.

Do not confuse the equipment hierarchy with the ISA-95 functional levels (Level 0 physical process up to Level 4 business planning). Both appear in discussions about "ISA-95 levels". The twin hierarchy described here uses the equipment hierarchy.

Mapping the Hierarchy to MQTT Topics

The Unified Namespace pattern publishes all plant data to a broker under a topic tree that mirrors the equipment hierarchy:

<enterprise>/<site>/<area>/<line>/<cell>/<data-type>

acme/izmir/machining/line2/cnc3/telemetry
acme/izmir/machining/line2/cnc3/state
acme/izmir/machining/line2/robot1/telemetry
acme/izmir/utilities/compressors/comp1/energy

This gives the twin three useful properties:

1. Structure from topics. A twin service can build its object tree by parsing topic paths, with no separate configuration for each asset.
2. Scope by wildcard. A line twin subscribes to acme/izmir/machining/line2/#; a plant overview subscribes to acme/izmir/+/+/+/state.
3. Stable addressing. Every value has one canonical address that dashboards, historians and analytics all share.

For more about this approach, read MQTT Sparkplug B and the Unified Namespace.

Naming rules that prevent pain later

• Lowercase, letters, digits and hyphens only. No spaces, no + or #.
• One concept per level; never skip a level. If a machine is not in a line, use a placeholder such as general.
• Use stable IDs (cnc3) in topics and keep display names (DMG Mori NHX 4000 #3) in metadata.
• Keep data type as the last segment with a small fixed vocabulary: telemetry, state, alarm, energy, health, command.
• Document the tree and treat changes like code changes, with review.

How ConnectMQ Supports an ISA-95 Digital Twin

ConnectMQ is built with this structure in mind. It detects ISA-95 and Unified Namespace topics, and the portal's devices view organizes devices by ISA-95 levels, so you can browse enterprise, site, area, line and cell exactly as the twin will. The live topic explorer shows the raw tree and messages for troubleshooting.

Many edge devices use Sparkplug B, whose topics follow a different scheme (spBv1.0/<group>/<message-type>/<edge-node>/<device>) and whose payloads are Protobuf. ConnectMQ decodes Sparkplug B (Protobuf or JSON) and republishes it into ISA-95 topics. For example:

spBv1.0/factory1/DDATA/line1/cnc1   ->   connectmq/factory1/production/line1/cnc1/telemetry

Your twin can subscribe to the ISA-95 side without any Sparkplug decoding of its own, while Sparkplug-aware SCADA clients keep using the original topics. This removes one of the most common integration hurdles when combining brownfield Sparkplug devices with a new twin.

If you do not want to run this backbone yourself, a managed MQTT broker handles availability, TLS and access control, leaving your team to focus on the hierarchy and the twin.

Building the Twin Model from Topics

The twin model is a tree whose nodes carry metadata and live values. A simple JSON representation:

{
  "id": "acme/izmir/machining/line2",
  "level": "line",
  "name": "Line 2 - Housings",
  "children": [
    { "id": "acme/izmir/machining/line2/cnc3", "level": "cell", "name": "CNC 3", "type": "cnc" },
    { "id": "acme/izmir/machining/line2/robot1", "level": "cell", "name": "Loading Robot", "type": "robot" }
  ]
}

Live values attach to the cell nodes from the telemetry and state topics. Aggregates such as line state or line OEE are computed by a twin service and published back to a topic at the line level, for example acme/izmir/machining/line2/kpi, so every viewer reads the same numbers.

Hands-On: Validate Your Topic Hierarchy

Before building the twin, check that what devices publish matches the hierarchy. This script subscribes to a prefix on the free public MQTT broker and reports topics that break the rules. Use a unique prefix and simulated data; the public area is readable by everyone.

import re
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo-isa-3e8f"  # your unique demo prefix
LEVELS = ["enterprise", "site", "area", "line", "cell", "datatype"]
DATA_TYPES = {"telemetry", "state", "alarm", "energy", "health", "command", "kpi"}
SEGMENT = re.compile(r"^[a-z0-9-]+$")
seen = set()


def check(topic):
    parts = topic[len(PREFIX) + 1 :].split("/")
    problems = []
    if len(parts) != len(LEVELS):
        problems.append(f"expected {len(LEVELS)} levels, got {len(parts)}")
    for name, seg in zip(LEVELS, parts):
        if not SEGMENT.match(seg):
            problems.append(f"{name} '{seg}' has invalid characters")
    if parts and parts[-1] not in DATA_TYPES:
        problems.append(f"unknown data type '{parts[-1]}'")
    return problems


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/#")
    print("Validating topics under", PREFIX)


def on_message(client, userdata, msg):
    if msg.topic in seen:
        return
    seen.add(msg.topic)
    problems = check(msg.topic)
    print(("OK   " if not problems else "FAIL ") + msg.topic + ("" if not problems else "  -> " + "; ".join(problems)))


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"isa95-check-{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()

Publish a few test topics to see it work:

mosquitto_pub -h broker.connectmq.com -p 1883 -i isa-pub-1 -t "connectmq/demo-isa-3e8f/acme/izmir/machining/line2/cnc3/telemetry" -m '{"rpm":8000}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i isa-pub-2 -t "connectmq/demo-isa-3e8f/acme/izmir/Machining/cnc3/Telemetry" -m '{"rpm":8000}'

The second topic fails on case and on the missing line level. The demo prefix is deliberately two levels deep: the public broker allows up to 8 topic levels, and the six-level hierarchy plus a two-level prefix fits exactly. On a private broker you do not need a prefix at all.

Implementation Checklist

1. Agree enterprise, site and area names with operations and IT.
2. Inventory lines and cells per area; assign stable IDs.
3. Fix the data-type vocabulary and payload schemas per type.
4. Configure edge gateways or Sparkplug republishing to emit ISA-95 topics.
5. Validate topics with a script and the ISA-95 devices view before building visuals.
6. Build the twin tree from topics plus a metadata file for names and types.
7. Publish aggregates at the level they describe.
8. Version the hierarchy document and review every change.

The structure applies directly to a factory digital twin and to digital twin in manufacturing programs.

Organize Your Plant Data with ConnectMQ

ConnectMQ recognizes ISA-95 and Unified Namespace topics, decodes Sparkplug B and gives you a devices view by ISA-95 levels. Sign up at app.connectmq.com for the free Serverless plan, no credit card required, and see your hierarchy take shape as devices connect.

Frequently Asked Questions

What is an ISA-95 digital twin?

It is a digital twin whose model and data topics are organized according to the ISA-95 equipment hierarchy of enterprise, site, area, line and cell, so the twin matches the structure of the plant.

Is ISA-95 the same as the Unified Namespace?

No. ISA-95 is a standard that defines the hierarchy; the Unified Namespace is an architecture pattern that publishes all data to a broker. A UNS commonly uses the ISA-95 hierarchy for its topic tree.

Can Sparkplug B devices feed an ISA-95 twin?

Yes. ConnectMQ decodes Sparkplug B and republishes the data into ISA-95 topics, so the twin can subscribe to the ISA-95 tree directly.

What if a machine does not belong to a line?

Use a placeholder segment such as general at the line level, so every topic keeps the same depth and wildcard subscriptions keep working.