IIoT Data Modeling: From Flat Tags to Information Models

IIoT data modeling is the work of turning thousands of cryptic PLC tags into structured, self-describing information that any application can consume without a tag spreadsheet next to it. In this guide you will learn the three layers of a good industrial data model, how ISA-95, Sparkplug B templates and OPC UA fit together, and how to publish a modeled asset over MQTT so the result is visible and testable in minutes.

Why Flat Tags Stop Scaling

Every plant starts with tags. A PLC exposes N7:42, DB10.DBW4 or Line2_Mtr3_Amps, and someone maintains a spreadsheet that explains what each one means. That works for one HMI talking to one controller. It breaks down the moment you add a second consumer.

The problems show up in predictable ways:

• Meaning lives outside the data. The tag T_204 is a temperature only because a document says so. The unit, the valid range and the asset it belongs to are not in the payload.
• Every integration repeats the mapping. The MES team, the historian team and the analytics team each rebuild the same tag dictionary, and each version drifts.
• Identical machines look different. Five filling machines from three vendors expose five naming schemes, so a dashboard built for one cannot be reused for the others.
• Changes break consumers silently. When a controls engineer renames a tag, nothing tells the downstream applications.

A data model fixes this by putting structure, context and identity into the data itself. It is the foundation of a unified namespace, and it is what makes a plant's data reusable rather than merely available.

The Three Layers of an IIoT Data Model

A useful way to think about IIoT data modeling is in three layers. Each answers a different question, and each can be designed independently.

Location: the ISA-95 path

The location layer gives every data point an address that humans recognise. ISA-95 defines a hierarchy of enterprise, site, area, production line or work center, and work unit. Using it as the topic path means the address of a value also tells you where it physically comes from. The ISA-95 equipment hierarchy article goes deeper into choosing the levels, and ISA-95 MQTT topics shows how they map to topic levels.

Keep the location layer stable. Physical layout changes rarely, so it is a good backbone. Avoid putting volatile things such as product codes or shift names into the path.

Type: reusable asset definitions

The type layer is where real modeling happens. You define a Pump once, with its attributes (flow, discharge pressure, motor current, running state), units and allowed ranges, and every pump instance follows that definition regardless of which PLC or vendor sits underneath.

There are two common ways to express types in industrial MQTT systems:

• Sparkplug B templates let an edge node publish a template definition in its birth certificate and then publish instances that reference it. See the Sparkplug templates guide for the mechanics.
• OPC UA ObjectTypes and companion specifications define rich, standardised types for many machine classes. If your machines already speak OPC UA, reuse those types rather than inventing new ones. The OPC UA vs MQTT comparison explains how the two coexist.

If neither applies, a simple JSON Schema per asset type, stored in version control, is enough to start.

Instance data: a consistent payload

The value layer is the payload. Whatever format you choose, every value should carry the same envelope: the value, the engineering unit, a timestamp from the source, and a quality indicator. Without a source timestamp, consumers cannot tell a late message from a new reading. Without quality, a frozen sensor looks like a stable process.

Designing an IIoT Data Model Step by Step

The following checklist works for a first line or a first machine class. Do it on paper before writing any gateway configuration.

1. Pick one asset class with several instances. Pumps, motors or fillers are good candidates because reuse pays off immediately.
2. List the questions consumers ask. "Is it running?", "How much did it produce this hour?", "Is it drifting toward failure?" The model should answer these directly.
3. Define the type. Name each attribute in plain language, assign a unit, a data type and an expected range. Decide which attributes are telemetry (change often), state (change on events) and metadata (rarely change).
4. Map tags to attributes per vendor. This is the only place where vendor-specific tag names should appear, typically in the edge gateway.
5. Fix the location path. Choose the ISA-95 levels you need and write down the allowed names for each level.
6. Choose the payload envelope. JSON with value, unit, timestamp and quality is the easiest to debug. Sparkplug B Protobuf is more compact and carries birth and death semantics.
7. Version the model. Add a modelVersion attribute or keep type definitions in a repository so consumers can detect changes.
8. Publish one instance and review it with consumers before rolling out to the rest of the fleet.

Publishing a Modeled Asset over MQTT

Here is a minimal Python example that publishes a modeled filler: metadata as a retained message, telemetry as periodic messages, all under an ISA-95 path. It uses the free public MQTT test broker at broker.connectmq.com, so do not send real plant data to it; the public area is readable by everyone.

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/berlin/line2/filler1"

# Type definition: what every Filler looks like
FILLER_MODEL = {
    "type": "Filler",
    "modelVersion": "1.2.0",
    "attributes": {
        "speed": {"unit": "bpm", "dataType": "float", "min": 0, "max": 200},
        "state": {"dataType": "string", "enum": ["RUNNING", "IDLE", "FAULT"]},
        "goodCount": {"unit": "units", "dataType": "int"},
        "rejectCount": {"unit": "units", "dataType": "int"},
    },
    "metadata": {"vendor": "ExampleVendor", "serial": "F-2291", "commissioned": "2024-03-11"},
}


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"model-demo-{RUN_ID}")
client.on_connect = on_connect
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()

# Publish the model once, retained, so late subscribers can discover it
client.publish(f"{BASE}/model", json.dumps(FILLER_MODEL), qos=1, retain=True)

good, rejects = 0, 0
try:
    while True:
        ts = int(time.time() * 1000)
        speed = round(random.gauss(120, 4), 1)
        good += int(speed / 60 * 5)
        rejects += 1 if random.random() < 0.05 else 0
        for name, value, unit in [
            ("speed", speed, "bpm"),
            ("goodCount", good, "units"),
            ("rejectCount", rejects, "units"),
        ]:
            payload = {"value": value, "unit": unit, "ts": ts, "quality": "GOOD"}
            client.publish(f"{BASE}/telemetry/{name}", json.dumps(payload), qos=0)
        client.publish(f"{BASE}/state", json.dumps({"value": "RUNNING", "ts": ts}), qos=1, retain=True)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Watch the result with the Mosquitto client:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM -t "connectmq/demo/+/berlin/#" -v

Note the depth: the public broker allows up to 8 topic levels, so the demo keeps only site, line and machine under the demo prefix (the deepest topic, .../filler1/telemetry/speed, is exactly 8 levels). In your own namespace you would add enterprise and area as well. In production on a managed MQTT broker you use your own credentials and are not limited to a shared demo prefix.

How ConnectMQ Helps You See the Model

Once modeled data flows, you need a way to verify it. ConnectMQ detects ISA-95 and Unified Namespace style topics and shows connected devices grouped by ISA-95 levels in the portal, so a wrong level or a misspelled line name stands out immediately. The live topic explorer shows the retained model and state messages next to the telemetry, which is a quick way to confirm that the envelope is consistent across instances.

If your edge nodes publish 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. That gives you compact Sparkplug transport from the edge and readable, modeled topics for consumers. The Sparkplug B and unified namespace post covers that pattern in detail.

Common Pitfalls in IIoT Data Modeling

• Modeling the PLC instead of the process. If your attribute is called DB10_Word4, you have only moved the tag. Model what operators and engineers talk about.
• Too many hierarchy levels. Every extra level is a place for naming inconsistency. Use the levels that differ in your plant and skip the rest.
• Units in attribute names. temperature_degC couples the name to the unit. Put the unit in the payload or the type definition.
• No source timestamps. Broker arrival time is not measurement time, especially when gateways buffer during outages.
• Mixing state and telemetry in one stream. State changes are rare and should be retained; high-rate telemetry usually should not be.
• No ownership. A model without an owner drifts. Assign one person or team per asset type.

Where the Model Goes Next

A good data model is not an end in itself. It feeds the historian, the MES, dashboards and machine learning. The industrial IoT with MQTT guide shows the broader architecture, and if you want to understand how messages are routed between all these consumers, start with what an MQTT broker does. When you outgrow a single plant, a cloud MQTT broker lets multiple sites publish into one consistent namespace.

Get Started with ConnectMQ

Model one asset class, publish it, and look at it in a real broker. Create a free Serverless broker at app.connectmq.com, no credit card required, then point your gateway or the Python script above at your own credentials (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID) and use the ISA-95 devices view to check that your hierarchy looks the way you designed it.

Frequently Asked Questions

What is IIoT data modeling?

IIoT data modeling is the practice of giving industrial data a consistent structure: a location in an asset hierarchy, a type that defines which attributes an asset has, and a payload format with units, timestamps and quality. It replaces tag spreadsheets with self-describing data.

Should I use Sparkplug B templates or OPC UA types?

Use OPC UA types if your machines already expose them or a companion specification exists for your equipment class. Use Sparkplug B templates when your edge architecture is MQTT-native and you want birth and death semantics; both can feed the same ISA-95 namespace.

Where should tag-to-model mapping happen?

In the edge gateway or connector closest to the PLC. That keeps vendor-specific names in one place and lets every consumer above the gateway see only the clean model.

Do I need a data model before starting a unified namespace?

You need at least the location layer and a payload envelope. Asset types can be added class by class, but agreeing on paths and the envelope first prevents costly renames later.