IIoT-Datenmodellierung: Von Tags zu Informationsmodellen

IIoT-Datenmodellierung bedeutet, Tausende kryptischer SPS-Tags in strukturierte, selbstbeschreibende Informationen zu verwandeln, die jede Anwendung nutzen kann, ohne daneben eine Tag-Tabelle zu benötigen. In diesem Leitfaden lernen Sie die drei Schichten eines guten industriellen Datenmodells kennen, erfahren, wie ISA-95, Sparkplug-B-Templates und OPC UA zusammenspielen, und publizieren ein modelliertes Asset über MQTT, sodass das Ergebnis in wenigen Minuten sichtbar und testbar ist.

Warum flache Tags nicht mehr skalieren

Jedes Werk beginnt mit Tags. Eine SPS stellt N7:42, DB10.DBW4 oder Line2_Mtr3_Amps bereit, und jemand pflegt eine Tabelle, die erklärt, was jeder Tag bedeutet. Das funktioniert für ein HMI, das mit einer Steuerung spricht. Es bricht zusammen, sobald ein zweiter Consumer hinzukommt.

Die Probleme zeigen sich auf vorhersehbare Weise:

Die Bedeutung liegt außerhalb der Daten. Der Tag T_204 ist nur deshalb eine Temperatur, weil ein Dokument das sagt. Einheit, gültiger Bereich und zugehöriges Asset stehen nicht in der Payload.
Jede Integration wiederholt das Mapping. Das MES-Team, das Historian-Team und das Analytics-Team bauen jeweils dasselbe Tag-Verzeichnis neu auf, und jede Version driftet auseinander.
Identische Maschinen sehen unterschiedlich aus. Fünf Abfüllmaschinen von drei Herstellern liefern fünf Namensschemata, sodass ein Dashboard für eine Maschine nicht für die anderen wiederverwendet werden kann.
Änderungen brechen Consumer stillschweigend. Wenn ein Steuerungstechniker einen Tag umbenennt, erfahren die nachgelagerten Anwendungen nichts davon.

Ein Datenmodell behebt das, indem es Struktur, Kontext und Identität in die Daten selbst legt. Es ist das Fundament eines Unified Namespace (UNS) und sorgt dafür, dass die Daten eines Werks wiederverwendbar und nicht bloß verfügbar sind. Im UNS liegt das modellierte Asset an genau einer Stelle auf dem MQTT-Broker, und MES, ERP, Historian und Analytics lesen es dort, statt jeweils eigene SPS-Anbindungen zu pflegen.

Die drei Schichten eines IIoT-Datenmodells

IIoT-Datenmodellierung lässt sich gut in drei Schichten denken. Jede beantwortet eine andere Frage, und jede kann unabhängig entworfen werden.

Schicht	Beantwortete Frage	Typischer Standard oder Werkzeug	Beispiel
Ort (wo)	Zu welchem Standort, Bereich, welcher Linie und Zelle gehört das?	ISA-95-Anlagenhierarchie	`acme/werk-berlin/abfuellung/linie-2/fueller-1`
Typ (was)	Welche Art von Asset ist das, und welche Attribute hat es immer?	Sparkplug-B-Templates, OPC-UA-ObjectTypes	`Filler` mit Geschwindigkeit, Zustand, Zählerstand, Ausschuss
Instanzdaten (Wert)	Was ist der aktuelle Wert, mit welcher Einheit, Qualität und welchem Zeitstempel?	Payload-Schema (JSON oder Protobuf)	`{"value": 118.4, "unit": "bpm", "ts": ...}`

Ort: der ISA-95-Pfad

Die Ortsschicht gibt jedem Datenpunkt eine Adresse, die Menschen wiedererkennen. ISA-95 definiert eine Hierarchie aus Unternehmen, Standort, Bereich, Produktionslinie oder Arbeitszentrum und Arbeitseinheit. Wird sie als Topic-Pfad verwendet, verrät die Adresse eines Werts zugleich, woher er physisch stammt. Genau diese Abbildung macht die ISA-95-Hierarchie zur Topic-Struktur des Unified Namespace: Unternehmen → Standort → Bereich → Linie → Zelle wird zum Beispiel zu acme/werk-stuttgart/montage/linie-1/zelle-3, und darunter hängen die Attribute des Assets. Der Artikel zur ISA-95-Anlagenhierarchie vertieft die Wahl der Ebenen, und ISA-95-MQTT-Topics zeigt, wie sie sich auf Topic-Ebenen abbilden.

Halten Sie die Ortsschicht stabil. Das physische Layout ändert sich selten und ist daher ein gutes Rückgrat. Vermeiden Sie veränderliche Dinge wie Produktcodes oder Schichtnamen im Pfad.

Typ: wiederverwendbare Asset-Definitionen

In der Typschicht findet die eigentliche Modellierung statt. Sie definieren eine Pump einmal, mit ihren Attributen (Durchfluss, Förderdruck, Motorstrom, Betriebszustand), Einheiten und zulässigen Bereichen, und jede Pumpeninstanz folgt dieser Definition, unabhängig davon, welche SPS oder welcher Hersteller darunter liegt.

In industriellen MQTT-Systemen gibt es zwei gängige Wege, Typen auszudrücken:

Sparkplug-B-Templates erlauben es einem Edge-Node, eine Template-Definition in seinem Birth Certificate zu publizieren und anschließend Instanzen zu publizieren, die darauf verweisen. Die Mechanik erklärt der Leitfaden zu Sparkplug-Templates.
OPC-UA-ObjectTypes und Companion Specifications definieren umfangreiche, standardisierte Typen für viele Maschinenklassen. Wenn Ihre Maschinen bereits OPC UA sprechen, verwenden Sie diese Typen wieder, statt neue zu erfinden. Der Vergleich OPC UA vs. MQTT erklärt, wie beide nebeneinander bestehen.

Wenn keines von beiden zutrifft, genügt für den Anfang ein einfaches JSON Schema pro Asset-Typ in der Versionsverwaltung.

Instanzdaten: eine konsistente Payload

Die Werteschicht ist die Payload. Egal welches Format Sie wählen, jeder Wert sollte denselben Umschlag tragen: den Wert, die technische Einheit, einen Zeitstempel aus der Quelle und einen Qualitätsindikator. Ohne Quellzeitstempel können Consumer eine verspätete Nachricht nicht von einem neuen Messwert unterscheiden. Ohne Qualitätsangabe sieht ein eingefrorener Sensor wie ein stabiler Prozess aus.

Ein IIoT-Datenmodell Schritt für Schritt entwerfen

Die folgende Checkliste funktioniert für eine erste Linie oder eine erste Maschinenklasse. Arbeiten Sie sie auf Papier durch, bevor Sie eine Gateway-Konfiguration schreiben.

Wählen Sie eine Asset-Klasse mit mehreren Instanzen. Pumpen, Motoren oder Abfüller sind gute Kandidaten, weil sich die Wiederverwendung sofort auszahlt.
Listen Sie die Fragen der Consumer auf. „Läuft sie?“, „Wie viel hat sie in dieser Stunde produziert?“, „Driftet sie in Richtung Ausfall?“ Das Modell sollte diese Fragen direkt beantworten.
Definieren Sie den Typ. Benennen Sie jedes Attribut in Klartext und legen Sie Einheit, Datentyp und erwarteten Bereich fest. Entscheiden Sie, welche Attribute Telemetrie (ändern sich oft), Zustand (ändern sich bei Ereignissen) und Metadaten (ändern sich selten) sind.
Bilden Sie Tags pro Hersteller auf Attribute ab. Das ist die einzige Stelle, an der herstellerspezifische Tag-Namen auftauchen sollten, typischerweise im Edge-Gateway.
Legen Sie den Ortspfad fest. Wählen Sie die benötigten ISA-95-Ebenen und notieren Sie die zulässigen Namen für jede Ebene.
Wählen Sie den Payload-Umschlag. JSON mit Wert, Einheit, Zeitstempel und Qualität lässt sich am leichtesten debuggen. Sparkplug-B-Protobuf ist kompakter und bringt Birth- und Death-Semantik mit.
Versionieren Sie das Modell. Ergänzen Sie ein Attribut modelVersion oder halten Sie Typdefinitionen in einem Repository, damit Consumer Änderungen erkennen.
Publizieren Sie eine Instanz und prüfen Sie sie mit den Consumern, bevor Sie auf den Rest der Flotte ausrollen.

Ein modelliertes Asset über MQTT publizieren

Hier ein minimales Python-Beispiel, das einen modellierten Abfüller publiziert: Metadaten als Retained Message, Telemetrie als periodische Nachrichten, alles unter einem ISA-95-Pfad im Stil eines UNS. Es nutzt den kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com. Er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten: Senden Sie keine echten Werksdaten dorthin, denn der öffentliche Bereich ist für alle lesbar.

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"

# Typdefinition: so sieht jeder Filler aus
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()

# Das Modell einmal retained publizieren, damit spätere Subscriber es finden
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()

Beobachten Sie das Ergebnis mit dem Mosquitto-Client:

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

Beachten Sie die Tiefe: Der öffentliche Broker erlaubt bis zu 8 Topic-Ebenen, daher behält die Demo unter dem Demo-Präfix nur Standort, Linie und Maschine (das tiefste Topic, .../filler1/telemetry/speed, hat genau 8 Ebenen). In Ihrem eigenen Namespace würden Sie zusätzlich Unternehmen und Bereich ergänzen. In der Produktion auf einem verwalteten MQTT-Broker verwenden Sie eigene Zugangsdaten und sind nicht auf ein gemeinsames Demo-Präfix beschränkt.

Wie ConnectMQ Ihnen hilft, das Modell zu sehen

Sobald modellierte Daten fließen, brauchen Sie eine Möglichkeit, sie zu überprüfen. ConnectMQ erkennt Topics im Stil von ISA-95 und UNS und zeigt verbundene Geräte im Portal nach ISA-95-Ebenen gruppiert an, sodass eine falsche Ebene oder ein falsch geschriebener Linienname sofort auffällt. Der Live-Topic-Explorer zeigt die Retained-Nachrichten für Modell und Zustand neben der Telemetrie – ein schneller Weg, um zu bestätigen, dass der Umschlag über alle Instanzen hinweg konsistent ist.

Wenn Ihre Edge-Nodes Sparkplug B publizieren, dekodiert ConnectMQ die Protobuf-Payloads und kann sie in ISA-95-Topics erneut publizieren; so wird zum Beispiel spBv1.0/factory1/DDATA/line1/cnc1 zu connectmq/factory1/production/line1/cnc1/telemetry. Damit erhalten Sie kompakten Sparkplug-Transport ab der Edge und lesbare, modellierte Topics für die Consumer. Der Beitrag Sparkplug B und der Unified Namespace behandelt dieses Muster im Detail.

Typische Fallstricke bei der IIoT-Datenmodellierung

Die SPS statt des Prozesses modellieren. Wenn Ihr Attribut DB10_Word4 heißt, haben Sie den Tag nur verschoben. Modellieren Sie, worüber Bediener und Ingenieure sprechen.
Zu viele Hierarchieebenen. Jede zusätzliche Ebene ist eine Quelle für uneinheitliche Namen. Verwenden Sie die Ebenen, die sich in Ihrem Werk unterscheiden, und lassen Sie den Rest weg.
Einheiten in Attributnamen. temperature_degC koppelt den Namen an die Einheit. Legen Sie die Einheit in die Payload oder in die Typdefinition.
Keine Quellzeitstempel. Die Ankunftszeit am Broker ist nicht die Messzeit, besonders wenn Gateways bei Ausfällen puffern.
Zustand und Telemetrie in einem Strom vermischen. Zustandsänderungen sind selten und sollten retained sein; hochfrequente Telemetrie in der Regel nicht.
Keine Verantwortlichkeit. Ein Modell ohne Owner driftet. Weisen Sie jedem Asset-Typ eine Person oder ein Team zu.

Wie es mit dem Modell weitergeht

Ein gutes Datenmodell ist kein Selbstzweck. Über den UNS speist es Historian, MES, ERP, OEE-Dashboards und Machine Learning, etwa für Predictive Maintenance. Der Leitfaden zu Industrial IoT mit MQTT zeigt die übergreifende Architektur, und wenn Sie verstehen möchten, wie Nachrichten zwischen all diesen Consumern geroutet werden, beginnen Sie mit was ein MQTT-Broker macht. Wenn ein einzelnes Werk nicht mehr ausreicht, ermöglicht ein Cloud-MQTT-Broker, dass mehrere Standorte in einen konsistenten Namespace publizieren.

Starten Sie mit ConnectMQ

Modellieren Sie eine Asset-Klasse, publizieren Sie sie und sehen Sie sie sich in einem echten Broker an. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, richten Sie Ihr Gateway oder das obige Python-Skript auf Ihre eigenen Zugangsdaten aus (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID) und prüfen Sie in der ISA-95-Geräteansicht, ob Ihre Hierarchie so aussieht, wie Sie sie entworfen haben.

Häufig gestellte Fragen

Was ist IIoT-Datenmodellierung?

IIoT-Datenmodellierung ist die Praxis, industriellen Daten eine konsistente Struktur zu geben: einen Ort in einer Asset-Hierarchie, einen Typ, der festlegt, welche Attribute ein Asset hat, und ein Payload-Format mit Einheiten, Zeitstempeln und Qualität. Sie ersetzt Tag-Tabellen durch selbstbeschreibende Daten.

Sollte ich Sparkplug-B-Templates oder OPC-UA-Typen verwenden?

Verwenden Sie OPC-UA-Typen, wenn Ihre Maschinen sie bereits bereitstellen oder für Ihre Anlagenklasse eine Companion Specification existiert. Verwenden Sie Sparkplug-B-Templates, wenn Ihre Edge-Architektur MQTT-nativ ist und Sie Birth- und Death-Semantik möchten; beide können denselben ISA-95-Namespace speisen.

Wo sollte das Mapping von Tags auf das Modell stattfinden?

Im Edge-Gateway oder Connector, der der SPS am nächsten ist. So bleiben herstellerspezifische Namen an einer Stelle, und jeder Consumer oberhalb des Gateways sieht nur das saubere Modell.

Brauche ich ein Datenmodell, bevor ich einen Unified Namespace starte?

Sie brauchen mindestens die Ortsschicht, also die ISA-95-Ebenen als Topic-Struktur des UNS, und einen Payload-Umschlag. Asset-Typen können Sie Klasse für Klasse ergänzen, aber wer sich zuerst auf Pfade und Umschlag einigt, vermeidet später teure Umbenennungen.

IIoT-Datenmodellierung: Von flachen Tags zu Informationsmodellen