MQTT-Themenbenennung für OEE: Ein Muster für jede Linie

Wichtigste Erkenntnisse

• Benennen Sie Themen von der Anlage abwärts: site, area, line, machine, dann der Wert.
• Verwenden Sie stabile IDs, keine Anzeigenamen, in Kleinbuchstaben und ohne Leerzeichen.
• Plain MQTT lässt Ihnen die Wahl der Baumstruktur. Sparkplug B legt seine eigene Form fest, wobei Ihre Hierarchie in die IDs geht.
• Halten Sie den Zeitstempel in der Nachricht, gestempelt an der Quelle, nicht im Topic.
• Publizieren Sie nur Änderungen, damit der Broker Ereignisse und nicht Rauschen transportiert.

MQTT überträgt Produktionsdaten als Nachrichten auf benannten Topics. Für OEE ist der Topic-Name der Weg, wie jedes nachfolgende System den Zustand einer Maschine und Zähler findet. Wählen Sie ein Muster von der Anlage abwärts, verwenden Sie es auf jeder Linie und benennen Sie ein Topic niemals um, sobald Daten darüber fließen.

Fabrico, OEE- und leichtes MES-Software mit KI-Kameras, protokolliert Ausfälle automatisch aus dem Maschinensignal, egal wie dieses Signal übertragen wird. Wie Daten Fabrico in Ihrem Netzwerk erreichen, wird mit dem technischen Team von Fabrico vereinbart. Dieser Leitfaden behandelt die lieferantenneutrale Seite der Namensgebung.

Warum ist die MQTT-Topic-Benennung für OEE wichtig?

• Subscriber filtern nach Topic. Ein guter Baum erlaubt es, mit einem einzigen Subscription jeden Filler in einem Site zu sammeln.
• Berichte verknüpfen über Namen. Line- und Maschinen-IDs in Topics müssen mit denen im Schichtkalender übereinstimmen.
• Historie folgt dem Topic. Benennen Sie ein Topic um, und die Daten vom letzten Monat scheinen zu einer anderen Maschine zu gehören.

Ein MQTT-Broker prüft Namen nicht für Sie. Welches Muster das erste Gateway verwendet, wird zum Muster der Anlage — entscheiden Sie es also, bevor die erste Linie live geht.

Welchem Muster sollten OEE-Topics folgen?

Die meisten Anlagen folgen den ISA-95-Ebenen, die auch die Idee eines einheitlichen Namespace prägen: ein gemeinsamer Baum für die gesamte Site. Edge-Gateways bauen häufig genau diesen Baum aus PLC-Daten auf.

Also lebt der Zustand des fillers auf Linie 4 unter plant2/packaging/line4/filler/state. Unser Leitfaden zum unified namespace behandelt die weitergehende Idee.

Welche Regeln halten Topic-Namen sauber?

• Nur Kleinbuchstaben. MQTT-Topics sind case-sensitive, also sind Line4 und line4 zwei verschiedene Topics.
• Keine Leerzeichen und keine Sonderzeichen. Verwenden Sie Buchstaben, Ziffern und Unterstrich.
• Verwenden Sie niemals + oder # in einem Namen. Das sind die Wildcards, die Subscriber verwenden.
• Beginnen Sie nicht mit einem Slash oder mit $. Topics, die mit $ beginnen, sind für den Broker reserviert.
• Verwenden Sie IDs, die sich nie ändern. "filler" bleibt "filler", wenn die Maschine ersetzt wird.
• Halten Sie Einheiten aus dem Namen heraus. Setzen Sie die Einheit in die Nachricht oder in die Tag-Liste, damit sich das Topic nicht ändert, wenn eine Einheit wechselt.
• Schreiben Sie das Muster auf auf eine Seite und geben Sie es jedem Integrator, bevor er ein Gateway anschließt.

Plain MQTT oder Sparkplug B?

Mit plain MQTT entwerfen Sie den gesamten Baum selbst, wie oben. Sparkplug B fügt eine feste Topic-Form, ein Payload-Format und Session-State hinzu. Seine Topics folgen spBv1.0/group_id/message_type/edge_node_id/device_id, und der Namespace-Teil muss spBv1.0 sein.

In Sparkplug kommt Ihre Anlagenhierarchie in die IDs. Die Gruppe könnte plant2_packaging sein, der Edge-Node line4_gw und das Device filler. Die Werte reisen als Metriken innerhalb der Nachricht, nicht als separate Topics. Unser Leitfaden zu Sparkplug B erklärt seine birth- und death-Nachrichten.

Beispiel: Topics für eine Linie

Beispiel-Linie (illustrierende Zahlen, kein Kunde). Linie 4 hat drei Maschinen: einen filler, einen capper und einen labeller. Jede veröffentlicht fünf Werte: state, total_count, reject_count, fault_code und sku. Das sind 3 x 5 = 15 Topics.

• plant2/packaging/line4/filler/state
• plant2/packaging/line4/capper/fault_code
• plant2/packaging/line4/labeller/total_count

Ein Subscription auf plant2/packaging/+/+/state sammelt den Zustand jeder Maschine im packaging. Das + Wildcard entspricht genau einem Level.

Nun das Volumen. Das Abfragen aller 15 Werte jede Sekunde sendet 15 x 3,600 = 54.000 Nachrichten pro Stunde.

Stattdessen publizieren Sie Zustände, Fehler und SKUs nur bei Änderung, etwa 100 Nachrichten pro Stunde. Senden Sie die beiden Zähler jeder Maschine alle 10 Sekunden: 3 x 2 x 360 = 2.160 Nachrichten. Das sind ungefähr 2.260 Nachrichten pro Stunde, rund 96% weniger.

Welche Benennungsfehler bereiten später Probleme?

• Anzeigenamen in Topics, wie "Filler (new)", die sich ändern, wenn jemand einen Bildschirm bearbeitet.
• Umbenennung einer Linie nach einer Layoutänderung, so dass deren Historie in zwei Teile zerfällt.
• Gemischte Sprachen oder Schreibweisen über Anlagen hinweg, so dass ein Gruppenbericht sie nicht zusammenführen kann.
• Ein riesiges Topic, das die ganze Anlage in einer Nachricht trägt, das niemand filtern kann.
• Kein Zeitstempel in der Nachricht, sodass Ereignisse die Zeit des Eingangs statt der Entstehungszeit erhalten.

Nur Änderungen zu publizieren ist die Idee hinter report by exception. Unser Artikel zu report by exception vs polling behandelt das, und MQTT in manufacturing behandelt das Protokoll.

Wo passt Fabrico hinein?

Fabrico ist eine Manufacturing Performance Platform mit Computer Vision. OEE und light MES stehen an erster Stelle, auf einem Satz von Linien- und Maschinennamen.

• Automatische Stillstandsprotokollierung aus dem Maschinensignal.
• Der Bediener bestätigt den Grund mit einem Tipp, weil ein Topic einen Zustand trägt, nicht die Ursache.
• OEE live nach Linie und Schicht, wobei jeder Verlust in Geld bewertet wird.
• Eine Ansicht über Anlagen hinweg, die nur funktioniert, wenn Namen übereinstimmen.

Es ist die OEE-Schicht eines light MES. Sie starten an einer Linie, mit einer Basislinie und einem vorab vereinbarten Entscheidungsdatum. Es gibt keinen Gratisplan und keine Stufen: Jede Anlage erhält ein Angebot.

Häufig gestellte Fragen

Was ist eine MQTT-Topic-Benennungs-Konvention?

Das ist die feste Regel der Anlage dafür, wie Topics gebaut werden, z. B. site, area, line, machine und value, in dieser Reihenfolge. Jedes Gateway folgt ihr. So kann jedes System die Daten einer Maschine per Name finden und ein Bericht kann Linien und Anlagen ohne manuelle Zuordnung zusammenführen.

Sollten MQTT-Topics ISA-95 folgen?

Für OEE ist das eine sinnvolle Wahl. Die ISA-95-Ebenen site, area, line und machine entsprechen der Art, wie Anlagen betrieben und berichtet werden. Die meisten Unified-Namespace-Designs verwenden diese Reihenfolge. Entscheidend ist, ein Muster zu wählen und es überall anzuwenden.

Wie ist das Sparkplug B Topic-Format?

Sparkplug B Topics folgen spBv1.0, dann der group ID, dem message type, der edge node ID und der device ID. Der Namespace-Teil muss spBv1.0 sein. Ihre Anlagenhierarchie kommt in die group-, node- und device-IDs, und die Werte werden als Metriken in der Nachricht transportiert.

Wie funktionieren MQTT-Wildcards?

Subscriber können zwei Wildcards verwenden. Ein Pluszeichen entspricht genau einem Level, also passt plant2/packaging/+/filler/state zum filler auf jeder packaging-Linie. Ein Hash-Zeichen entspricht allen verbleibenden Levels, also passt plant2/# zu allem in diesem Site.

Sollte der Zeitstempel in das Topic oder in die Nachricht?

In die Nachricht. Topics benennen, woher Daten kommen; sie sollten sich nicht mit jedem Ereignis ändern. Stempeln Sie jedes Ereignis mit der PLC- oder Gateway-Uhr zum Zeitpunkt des Geschehens. Setzen Sie diese Zeit in das Payload, sodass eine verzögerte Nachricht ihre echte Zeit behält.

Bringen Sie Ihren Topic-Baum zu einer Demo

Bringen Sie die Linienliste Ihrer Anlage mit. Wir zeigen die Stopps und Zähler einer Linie, benannt so, wie Ihre Anlage arbeitet.

Request a demo · Contact us