Smart Manufacturing Leitfaden: Von vernetzten Maschinen zum datengetriebenen Werk

Dieser Smart Manufacturing Leitfaden zeigt, wie Sie isolierte Maschinen in ein Werk verwandeln, das sich selbst in Echtzeit misst. Sie erfahren, welche Anwendungsfälle sich zuerst auszahlen, wie Daten von einer SPS zu einem Dashboard fließen sollten, wie Sie sie in einem Unified Namespace (UNS) nach ISA-95 benennen, damit sie nutzbar bleiben, und wie Sie an einem Nachmittag mit MQTT eine funktionierende Pipeline aufbauen. Der Leitfaden richtet sich an Fertigungsunternehmen, Maschinenbauer und den produzierenden Mittelstand, die Industrie 4.0 pragmatisch und Linie für Linie umsetzen wollen.

Was Smart Manufacturing wirklich bedeutet

Smart Manufacturing ist kein Produkt, das man kauft. Es ist die Praxis, kontinuierlich Daten von Maschinen, Prozessen und Menschen zu erfassen, sie allen zur Verfügung zu stellen, die sie brauchen, und damit bessere Entscheidungen schneller zu treffen, als es eine wöchentliche Tabelle erlaubt.

Die meisten Werke erzeugen die Daten bereits. SPS wissen, ob sich eine Spindel dreht, Energiezähler wissen, wie viele Kilowattstunden ein Kompressor verbraucht hat, und Qualitätsstationen wissen, welche Teile die Prüfung nicht bestanden haben. Das Problem: Diese Informationen sind in einzelnen Maschinen, proprietären HMIs und Punkt-zu-Punkt-Integrationen eingeschlossen, die niemand anfassen will. Ein intelligentes Werk bricht diese Silos mit drei Zutaten auf:

1. Konnektivität: Jedes relevante Signal verlässt die Maschine in einem standardisierten, offenen Format.
2. Ein gemeinsames Daten-Backbone: ein Ort, an dem Erzeuger veröffentlichen und Abnehmer abonnieren, statt Dutzender individueller Verbindungen.
3. Kontext: Daten, die ihre Bedeutung mit sich tragen, sodass aus „Temperatur 71,2“ die „Lagertemperatur der Spindel in Grad Celsius, Linie 2, CNC 4“ wird.

Der Rest dieses Leitfadens behandelt jede Zutat und wie sie sich zu konkreten Projekten verbinden. Das gemeinsame Daten-Backbone und der Kontext verschmelzen dabei im UNS: Der Broker ist der Ort, die ISA-95-Hierarchie liefert die Bedeutung. Wenn Sie zuerst den größeren Branchenrahmen möchten, erklärt der Industrie-4.0-Leitfaden, wo Smart Manufacturing im breiteren Technologiespektrum steht.

Smart-Manufacturing-Anwendungsfälle mit hohem Nutzen

Das beste erste Projekt ist das, das eine Frage beantwortet, die Ihr Produktionsleiter ohnehin jeden Morgen stellt. Die folgende Tabelle listet die Anwendungsfälle, die den Aufwand am häufigsten rechtfertigen, welche Daten jeder braucht und wo Sie tiefer einsteigen können.

Beachten Sie, dass die ersten beiden Zeilen sehr wenige Daten benötigen. Ein einziges digitales Signal „läuft oder läuft nicht“ plus ein Stückzähler reichen aus, um Verfügbarkeit und Durchsatz zu berechnen. Deshalb ist die Stillstandserfassung der klassische Einstieg: günstig zu instrumentieren, sofort nützlich, und sie baut die Infrastruktur auf, die jedes spätere Projekt wiederverwendet.

Der Datenfluss im Werk: von der Maschine zur Entscheidung

Jede Smart-Manufacturing-Architektur folgt, wie auch immer sie vermarktet wird, denselben vier Schichten. Wer sie versteht, vermeidet den teuersten Fehler der Werksdigitalisierung: Einzelintegrationen, die sich nicht erweitern lassen.

Schicht 1: Datenquellen

Das sind SPS, CNC-Steuerungen, Roboter, intelligente Sensoren, Energiezähler, Barcodescanner und Bedienterminals. Sie sprechen einen Mix aus Protokollen: Modbus TCP oder RTU, OPC UA, EtherNet/IP, Profinet, herstellerspezifische CNC-Schnittstellen oder einfach digitale E/A. Für ältere Maschinen ohne jede Schnittstelle ist ein kleiner Nachrüstsensor wie eine Stromzange oder ein Abgriff an der Signalsäule oft der schnellste Weg zu einem Laufsignal. Der Artikel zur Betriebsdatenerfassung in der Fertigung vergleicht diese Optionen im Detail.

Schicht 2: Edge-Gateways

Ein Edge-Gateway sitzt nahe an den Maschinen, liest die nativen Protokolle und übersetzt Messwerte in MQTT-Nachrichten. Das kann ein Industrie-PC mit Node-RED sein, ein Raspberry Pi mit einem Python-Skript, ein ESP32 für einfache Sensoren oder ein kommerzieller Protokollwandler. Im Gateway puffern Sie auch Daten, wenn das Netzwerk ausfällt, ergänzen Zeitstempel und wandeln rohe Registerwerte in technische Einheiten um.

Schicht 3: Das MQTT-Daten-Backbone

Alle Gateways veröffentlichen an einen zentralen MQTT-Broker, und alle Anwendungen abonnieren ihn. Dieses Publish/Subscribe-Muster ist die entscheidende Architekturentscheidung. Ein neues Dashboard, ein Historian oder ein Wartungsmodell lässt sich später durch Abonnieren bestehender Topics ergänzen, ohne eine einzige SPS anzufassen. Die Maschinen müssen nicht wissen, wer ihre Daten konsumiert. Ist die Topic-Struktur nach ISA-95 aufgebaut, wird dieses Backbone zum UNS des Werks: der eine Ort, an dem der aktuelle Zustand jeder Maschine, jeder Linie und jedes Bereichs abgelesen werden kann.

MQTT eignet sich hier gut, weil es schlank ist, unzuverlässige Netze toleriert, Quality-of-Service-Stufen unterstützt und Client-Bibliotheken für praktisch jede Sprache und Plattform bietet. Den Broker selbst zu betreiben bedeutet, ein kritisches Infrastrukturelement zu patchen, zu überwachen und abzusichern; ein verwalteter MQTT-Broker nimmt Ihnen diese Betriebslast ab, sodass sich das Werksteam auf die Daten konzentrieren kann.

Schicht 4: Abnehmer

Abnehmer sind die Werkzeuge, die aus Nachrichten Entscheidungen machen: Dashboards in der Fertigung, eine Zeitreihendatenbank wie InfluxDB, gespeist von Telegraf, ein MES, Alarmlogik, Wartungsmodelle oder eine 3D-Ansicht der Linie. Jeder davon ist nur ein weiterer MQTT-Client. Wie diese Schicht an Produktionsplanungssysteme angebunden wird, zeigt MES- und MQTT-Integration.

Einen skalierbaren Topic-Namespace entwerfen

Ein Topic-Namespace ist das Adressbuch Ihres Werks. Machen Sie ihn früh richtig, und jeder neue Abnehmer findet Daten, ohne jemanden fragen zu müssen. Machen Sie ihn falsch, und Sie landen bei Topics wie data/plc7/reg40012, die nur ein einziger Ingenieur versteht.

Der weit verbreitete Ansatz folgt der ISA-95-Anlagenhierarchie (IEC 62264), die das Rückgrat des Unified Namespace ist:

<enterprise>/<site>/<area>/<line>/<cell>/<category>

acme/werk-stuttgart/machining/line2/cnc4/state
acme/werk-stuttgart/machining/line2/cnc4/telemetry
acme/werk-stuttgart/machining/line2/cnc4/counters
acme/werk-stuttgart/utilities/compressors/comp1/energy

Der Unified Namespace als Rückgrat des Werks

Der UNS ist mehr als eine Namenskonvention. Er ist die Vereinbarung, dass jedes System, ob SPS, Edge-Gateway, MES oder ERP-Anbindung, seinen aktuellen Zustand an genau einer Stelle der ISA-95-Hierarchie auf dem Broker veröffentlicht und dort liest, was es braucht. Enterprise, Site, Area, Line und Cell werden so zur gemeinsamen Sprache von OT und IT. Für den Mittelstand hat das einen ganz praktischen Vorteil: Ein zweites Werk, eine neue Linie oder ein weiteres Analysewerkzeug fügt sich in die bestehende Struktur ein, statt ein neues Integrationsprojekt auszulösen. Der UNS passt auch zum Denkmodell von RAMI 4.0 aus der Plattform Industrie 4.0, das die Hierarchieebenen nach IEC 62264 ebenfalls als eine Achse nutzt.

Einige Regeln halten den Namespace sauber:

• Verwenden Sie Kleinbuchstaben, keine Leerzeichen und keinen führenden Schrägstrich.
• Halten Sie die Hierarchie physisch (wo sich etwas befindet) und legen Sie die Art der Daten in die letzte Ebene.
• Veröffentlichen Sie den aktuellen Zustand als Retained Messages, damit ein neuer Subscriber sofort den letzten Wert sieht.
• Legen Sie Einheiten und Zeitstempel in den JSON-Payload, nicht ins Topic.
• Legen Sie niemals Geheimnisse, personenbezogene Daten oder als sensibel eingestufte Seriennummern in Topic-Namen ab.

ConnectMQ erkennt ISA-95- und Unified-Namespace-Topics automatisch und zeigt verbundene Geräte im Portal gruppiert nach Unternehmen, Standort, Bereich, Linie und Zelle. Wenn ein Teil Ihrer Anlagen bereits Sparkplug B spricht, dekodiert ConnectMQ die Protobuf-Payloads und veröffentlicht sie in lesbaren ISA-95-Topics neu, sodass eine Nachricht auf spBv1.0/factory1/DDATA/line1/cnc1 auf connectmq/factory1/production/line1/cnc1/telemetry verfügbar wird. Der Artikel zu Sparkplug B und dem Unified Namespace erklärt die Abwägungen zwischen beiden Konventionen.

Eine Smart-Manufacturing-Roadmap Schritt für Schritt

Diese Roadmap ist bewusst inkrementell. Jeder Schritt liefert für sich genommen etwas Nützliches, und keiner erfordert einen werksweiten Stillstand oder ein mehrjähriges Budget.

1. Wählen Sie eine Linie und eine Frage. Zum Beispiel: „Warum hat Linie 2 letzte Woche 15 Prozent weniger produziert als geplant?“ Eine eng gefasste Frage hält den Umfang ehrlich.
2. Inventarisieren Sie die Signale. Listen Sie auf, was jede Maschine der Linie bereits liefern kann und was einen Nachrüstsensor braucht. Meist reichen für den Anfang ein Laufsignal, ein Stückzähler und ein Alarmcode.
3. Definieren Sie den Unified Namespace. Notieren Sie den ISA-95-Pfad für jede Anlage der Linie und das Payload-Format. Einigen Sie sich darauf, bevor Code geschrieben wird.
4. Prototyp auf einem öffentlichen MQTT-Broker. Nutzen Sie den öffentlichen MQTT-Broker, um Payloads und Dashboards mit simulierten oder unkritischen Daten zu validieren; Produktionsdaten gehören nicht dorthin.
5. Edge-Gateways ausrollen. Installieren Sie Gateways, die die Maschinen über OPC UA, Modbus oder S7-Kommunikation auslesen und in den UNS veröffentlichen. Ergänzen Sie lokale Pufferung für Netzausfälle.
6. Wechseln Sie zu einem privaten Broker mit Zugangsdaten und TLS. Produktionsdaten gehören auf eine authentifizierte, verschlüsselte Verbindung.
7. Bauen Sie den ersten Abnehmer. Eine Statustafel für die Linie oder einen Stillstandsbericht. Zeigen Sie ihn Bedienern und Schichtleitern und sammeln Sie Feedback.
8. Ergänzen Sie Kontext. Lassen Sie Bediener Stillstandsgründe per Tablet zuordnen, wie in Stillstandsgrund-Codes beschrieben. Daten ohne Gründe sagen Ihnen, dass Sie Zeit verloren haben, aber nicht warum.
9. Messen und ausweiten. Verfolgen Sie die in Schritt 1 gewählte Kennzahl einige Wochen lang. Wenn sie sich bewegt, übertragen Sie das Muster auf die nächste Linie und ergänzen einen zweiten Anwendungsfall wie Energie- oder Zustandsüberwachung.

Kleine und mittelständische Hersteller können genau dieselbe Abfolge mit kleinerem Umfang durchlaufen; der Artikel Smart Manufacturing für KMU zeigt, wie das mit Standardhardware gelingt.

Praxis: Eine simulierte Maschine mit Python streamen

Am schnellsten verstehen Sie den Datenfluss, indem Sie ihn bauen. Das folgende Skript simuliert eine CNC-Maschine, die ihren Zustand und ihre Telemetrie an den kostenlosen öffentlichen MQTT-Broker broker.connectmq.com veröffentlicht. Es nutzt paho-mqtt 2.x, ein Retained-Status-Topic und eine Last-Will-Nachricht, also dieselben Bausteine wie ein echtes Gateway.

Installieren Sie zuerst die Bibliothek:

pip install "paho-mqtt>=2.0"

Speichern Sie dann Folgendes als cnc_simulator.py:

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/site1/line1/cnc1"

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=f"cnc1-sim-{RUN_ID}",
)
# Stirbt der Simulator, veröffentlicht der Broker für uns "offline".
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)


def on_connect(client, userdata, flags, reason_code, properties):
    print(f"Connected: {reason_code}. Subscribe with:")
    print(f'  mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-{RUN_ID} -t "{BASE}/#" -v')
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)


client.on_connect = on_connect
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

state = "RUNNING"
parts = 0
try:
    while True:
        # Gelegentlich den Maschinenzustand ändern, um Stillstandsereignisse zu erzeugen.
        if random.random() < 0.1:
            new_state = random.choice(["RUNNING", "RUNNING", "IDLE", "STOPPED"])
            if new_state != state:
                state = new_state
                payload = {"state": state, "ts": int(time.time() * 1000)}
                client.publish(f"{BASE}/state", json.dumps(payload), qos=1, retain=True)

        if state == "RUNNING":
            parts += 1

        telemetry = {
            "ts": int(time.time() * 1000),
            "spindleTempC": round(random.uniform(38.0, 46.0), 2),
            "spindleRpm": 8000 if state == "RUNNING" else 0,
            "partCount": parts,
        }
        client.publish(f"{BASE}/telemetry", json.dumps(telemetry), qos=0)
        time.sleep(2)
except KeyboardInterrupt:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True)
    client.loop_stop()
    client.disconnect()

Starten Sie es mit python cnc_simulator.py und kopieren Sie den ausgegebenen mosquitto_sub-Befehl in ein zweites Terminal. Retained-Status- und Zustandsnachrichten kommen sofort an, gefolgt von Telemetrie alle zwei Sekunden. Beenden Sie das Skript mit Strg+C, und der Status wechselt auf offline; beenden Sie es stattdessen hart, veröffentlicht der Broker den Last Will, nachdem das Keep-Alive abgelaufen ist.

Zwei Details sind auf dem öffentlichen MQTT-Broker wichtig. Die Topic-Tiefe ist auf acht Ebenen begrenzt, daher nutzt die Demo eine verkürzte Hierarchie unter dem eindeutigen Präfix connectmq/demo/<id>; auf einem privaten Broker verwenden Sie den vollständigen UNS-Pfad. Und alles auf dem öffentlichen MQTT-Broker ist für jeden lesbar, dorthin gehören also nur simulierte oder unkritische Werte.

Aus Nachrichten die erste Kennzahl machen

Rohe Nachrichten werden wertvoll, wenn sie eine Frage beantworten. Der folgende Subscriber hört auf das Zustands-Topic und berechnet aus der in jedem Zustand verbrachten Zeit die Verfügbarkeit, den ersten Faktor der OEE. Übergeben Sie die vom Simulator ausgegebene Run-ID als Argument.

import json
import sys
import time
import uuid

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]
STATE_TOPIC = f"connectmq/demo/{RUN_ID}/site1/line1/cnc1/state"

durations = {"RUNNING": 0.0, "IDLE": 0.0, "STOPPED": 0.0}
current = {"state": None, "since": None}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(STATE_TOPIC, qos=1)


def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    now = data["ts"] / 1000
    if current["state"] is not None:
        durations[current["state"]] += now - current["since"]
    current["state"], current["since"] = data["state"], now
    planned = sum(durations.values())
    if planned > 0:
        availability = durations["RUNNING"] / planned * 100
        print(f"state={data['state']:<8} availability={availability:5.1f}% {durations}")


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"oee-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Das ist bewusst einfach gehalten: Die gesamte beobachtete Zeit gilt als geplante Produktionszeit, Schichten und geplante Pausen werden ignoriert. Eine produktive Version speichert Zustandswechsel in einer Datenbank und berechnet Verfügbarkeit, Leistung und Qualität pro Schicht. Der Artikel zu Smart-Factory-Kennzahlen behandelt, welche Metriken Sie als Nächstes ergänzen sollten und wie Sie Schönwetterzahlen vermeiden.

Zuverlässigkeit, Sicherheit und Skalierung in der Fertigung

Ein Prototyp, der auf einem Laptop läuft, ist noch kein Werkssystem. Bevor Sie sich bei Entscheidungen auf die Daten verlassen, kümmern Sie sich um die folgenden Punkte.

Quality of Service. Verwenden Sie QoS 1 für Zustandswechsel, Zähler und Alarme, die nicht verloren gehen dürfen, und QoS 0 für hochfrequente Telemetrie, bei der der nächste Messwert einen verpassten ersetzt. Der Artikel MQTT QoS-Stufen erklärt geht die Zustellgarantien im Detail durch.

Pufferung an der Edge. Netzausfälle kommen vor. Gateways sollten Nachrichten lokal zwischenspeichern und sie nach dem Reconnect mit ihren ursprünglichen Zeitstempeln veröffentlichen, damit die Zeitreihe keine Lücken hat.

Sicherheit. Produktiver Datenverkehr sollte TLS auf Port 8883 mit Zugangsdaten pro Gateway nutzen. Teilen Sie niemals einen Benutzernamen über alle Geräte und stellen Sie Werksnetze niemals direkt ins Internet; Gateways bauen nur ausgehende Verbindungen auf. Das entspricht dem Zonen- und Conduit-Gedanken der IEC 62443 und hilft, wenn Ihr Unternehmen unter NIS2 fällt. Die Checkliste MQTT Security Best Practices ist eine gute Prüfung vor dem Go-live.

Broker-Kapazität. Zählen Sie Ihre Clients und Nachrichtengrößen vorab. Eine Pilotlinie braucht vielleicht ein Dutzend Verbindungen; ein ganzes Werk mit Gateways pro Maschine, Dashboards und Services kann Hunderte benötigen. Bei ConnectMQ deckt der kostenlose Serverless-Plan bis zu 25 Verbindungen mit QoS bis 1 ab, der kostenpflichtige Serverless-Plan erhöht dies auf 1.000 Verbindungen mit QoS 2, Nachrichten bis 1 MB und Shared Subscriptions, und Dedicated- oder BYOC-Pläne bieten Ihnen einen isolierten Cluster oder eine Bereitstellung in Ihrem eigenen Cloud-Konto.

Das Backbone überwachen. Beobachten Sie Verbindungszustände ebenso genau wie Maschinenzustände. Ein Gateway, das sich stillschweigend trennt, sieht genauso aus wie eine Maschine, die angehalten hat. Retained-status-Topics mit Last Will, kombiniert mit Schwellenwert-Alarmen im Portal Ihres Brokers, machen solche Ausfälle sichtbar.

Typische Stolperfallen beim Smart Manufacturing

Die meisten ins Stocken geratenen Projekte scheitern an organisatorischen statt an technischen Gründen. Achten Sie auf diese Muster:

• Mit einer Plattform statt einem Problem beginnen. Eine große Suite zu kaufen, bevor Sie wissen, welche Entscheidungen Sie verbessern wollen, führt zu Dashboards, die niemand öffnet.
• Punkt-zu-Punkt-Integrationen. Das MES direkt an jede SPS anzubinden funktioniert bei einer Maschine und wird bei zwanzig unwartbar. Leiten Sie alles über den Broker.
• Fehlender Kontext. Stillstände ohne Grundcodes, Energie ohne Produktionsmenge und Qualitätsdaten ohne Chargen-IDs lassen sich kaum in Maßnahmen umsetzen.
• Bediener ignorieren. Die Menschen an der Linie wissen, warum die Maschine stand. Geben Sie ihnen eine einfache Möglichkeit, das zu erfassen, und zeigen Sie ihnen die Ergebnisse.
• Kein Verantwortlicher für den UNS. Jemand muss neue Topics und Payload-Formate freigeben, sonst verfällt die Struktur innerhalb weniger Monate.
• Die Cloud als Alles-oder-nichts betrachten. Echtzeit-Regelkreise bleiben auf der SPS. Der Broker transportiert Monitoring-, Analytics- und Koordinationsverkehr, keine Sicherheitsfunktionen.

Wie es weitergeht

Sobald die erste Linie angebunden ist, trägt dasselbe Backbone anspruchsvollere Vorhaben: Wartungsmodelle, die Vibrationsdaten auswerten, 3D-Ansichten der Linie und werksweite Energie-Baselines. Für die industrielle Architektur hinter all dem ist der Leitfaden zu Industrial IoT mit MQTT die naheliegende Ergänzung zu diesem Smart Manufacturing Leitfaden.

Vernetzen Sie Ihr Werk mit ConnectMQ

Sie können die gesamte Pipeline aus diesem Leitfaden aufbauen, ohne Broker-Infrastruktur zu betreiben. Registrieren Sie sich unter app.connectmq.com im kostenlosen Serverless-Plan, ganz ohne Kreditkarte, erstellen Sie einen Broker und kopieren Sie den generierten Benutzernamen, das Passwort und die Client ID in Ihre Gateways. Richten Sie sie auf Port 8883 mit TLS aus und verfolgen Sie mit dem Live-Topic-Explorer, der ISA-95-Geräteansicht und den Schwellenwert-Alarmregeln im Portal, wie Ihre erste Linie online geht. Wenn Sie über das Pilotprojekt hinauswachsen wollen, skaliert ein Plan für einen Cloud-MQTT-Broker mit Ihnen von einer Linie bis zum ganzen Werk.

Häufig gestellte Fragen

Was ist das beste erste Smart-Manufacturing-Projekt?

Die Erfassung von Maschinenstatus und Stillständen auf einer einzelnen Linie ist der häufigste und verlässlichste Einstieg. Sie braucht nur ein Laufsignal und einen Stückzähler, liefert schnell sichtbare Ergebnisse und baut die Dateninfrastruktur auf, die spätere Projekte wiederverwenden.

Muss ich meine alten Maschinen ersetzen, um mit Smart Manufacturing zu beginnen?

Nein. Ältere Maschinen lassen sich mit externen Sensoren wie Stromzangen, Abgriffen an der Signalsäule oder Vibrationssensoren nachrüsten, die an ein Edge-Gateway angeschlossen sind, das über MQTT veröffentlicht. Ein Austausch lohnt sich nur dann, wenn die Maschine selbst der Engpass ist.

Warum MQTT statt einer direkten Verbindung der Systeme?

MQTT entkoppelt Erzeuger von Abnehmern. Maschinen veröffentlichen einmal an den Broker, und beliebig viele Dashboards, Datenbanken oder Modelle können abonnieren, ohne neue Integrationen in der Fertigung, was die Architektur beim Wachsen wartbar hält.

Kann ich den öffentlichen MQTT-Broker für Produktionsdaten nutzen?

Nein. Der öffentliche MQTT-Broker broker.connectmq.com ist für jeden lesbar und für Tests mit simulierten oder unkritischen Daten gedacht. Produktionsdaten gehören auf einen privaten Broker mit Zugangsdaten und TLS.

Wie hängt ISA-95 mit dem Unified Namespace zusammen?

ISA-95 definiert die Hierarchie aus Unternehmen, Standort, Bereich, Linie und Zelle. Der Unified Namespace (UNS) nutzt diese Hierarchie als Topic-Struktur eines zentralen MQTT-Brokers, sodass jedes Datum im Werk eine vorhersehbare, selbstbeschreibende Adresse hat.