MQTT in der Fertigung: Warum das IoT‑Protokoll den Produktionsbereich eroberte Kernaussagen - MQTT ist ein leichtgewichtiges Pub/Sub‑Nachrichtenprotokoll. Ursprünglich für Telemetrie mit niedriger Bandbreite entwickelt, inzwischen weit verbreitet in der Fertigung. - Es entkoppelt Publisher (PLCs, Sensoren, Maschinen) von Subscriber (OEE‑Plattformen, Cloud, Analytics) über einen Broker.
- Das Standardmuster in modernen Werken ist Sparkplug B, eine MQTT‑Spezifikation, die Datenmodellierung, Birth/Death‑Nachrichten und Zustandsverfolgung hinzufügt. - MQTT skaliert auf Tausende Geräte bei minimaler Bandbreite, weshalb Edge‑IIoT‑Lösungen darauf zusammenlaufen. - Es ergänzt OPC UA, ersetzt es nicht. Viele Stacks nutzen beides.
Kurzantwort: MQTT ist ein Pub/Sub‑Nachrichtenprotokoll, das für IoT mit niedriger Bandbreite entwickelt wurde, aber in der Fertigung in großem Umfang übernommen wurde, weil es Datenproduzenten (Maschinen) von Datenkonsumenten (OEE‑Plattformen, Cloud, Analytics) entkoppelt. Moderne industrielle Deployments verwenden die Sparkplug B‑Spezifikation auf MQTT, um die Datenmodellierung und Zustandsverfolgung hinzuzufügen, die reines MQTT nicht bietet.
MQTT und OPC UA lösen sich überschneidende Probleme; viele Stacks verwenden beide. Siehe auch OEE für Chargenfertigung. Was MQTT ist MQTT (Message Queuing Telemetry Transport) ist ein Publish/Subscribe‑Nachrichtenprotokoll, das 1999 bei IBM für Telemetrie in der Öl‑ und Gasbranche mit niedriger Bandbreite entwickelt wurde.
Die Architektur ist einfach: - Publisher senden Nachrichten an Topics (benannte Kanäle) auf einem Broker. - Subscriber fragen den Broker nach Nachrichten zu den Topics, die sie interessieren. - Der Broker leitet Nachrichten von Publishern an Subscriber weiter, ohne dass beide einander kennen müssen. Die Entkopplung ist der Mehrwert.
Eine SPS veröffentlicht ihren Laufzustand in ein Topic; wer sich anmeldet, erhält die Daten. Die SPS weiß nicht und muss nicht wissen, wer der Konsument ist. Warum MQTT die Fertigungstelemetrie übernommen hat Drei Gründe: - Bandbreiteneffizienz. Geringer Nachrichtenoverhead, persistente Verbindungen, minimaler Handshake. Funktioniert über Mobilfunk und eingeschränkte Netzwerke. - Skalierbarkeit.
Ein einzelner Broker kann Tausende gleichzeitig publishender Geräte verarbeiten. - Entkopplung. Subscriber hinzufügen oder entfernen, ohne die Datenquellen anzutasten. Versuchen Sie das mit Punkt‑zu‑Punkt‑Integrationen. Für eine OEE‑Plattform, die Daten von 50+ Maschinen in einem Werk konsumiert, ist MQTT eine natürliche Wahl. Ein Broker, viele Publisher, viele Subscriber.
Warum reines MQTT nicht ausreicht Roher MQTT hat keine Meinung zum Nachrichteninhalt. Eine SPS, die "423" im Topic "line5/cycle" veröffentlicht, ist in Ordnung, bis zwei verschiedene SPS unterschiedliche Topic‑Konventionen, Einheiten oder Nachrichtenformate verwenden. Die Integration wird zum Chaos.
Die Lösung ist Sparkplug B, eine offene Spezifikation auf MQTT, die Folgendes hinzufügt: - Einen standardisierten Topic‑Namespace (group/edge node/device/metric). - Birth‑ und Death‑Nachrichten, sodass Subscriber wissen, wann ein Gerät beitritt oder verlässt. - Zustandsverfolgung und Wertpersistenz (der Broker speichert den zuletzt bekannten Wert). - Starke Typisierung von Metriken (int, float, boolean, datetime).
Die meisten modernen industriellen MQTT‑Deployments nutzen Sparkplug B. Rohes MQTT funktioniert bei Greenfield‑Installationen mit strikter Topic‑Disziplin, skaliert aber selten. MQTT vs. OPC UA Sie überschneiden sich, lösen aber unterschiedliche Probleme: - MQTT ist Pub/Sub, brokerbasiert, leichtgewichtig, ideal für Telemetrie im Many‑to‑Many‑Szenario bei großer Skalierung.
- OPC UA ist Client‑Server (mit optionalem Pub/Sub), Punkt‑zu‑Punkt, strukturiert, ideal für zuverlässigen Datenaustausch mit starker Typisierung und Sicherheit. Viele moderne Stacks nutzen beides: OPC UA für strukturierten Datenaustausch auf Linienebene (SPS → Gateway), MQTT/Sparkplug B für hochskalierende Telemetrie vom Gateway in die Cloud oder zu einer zentralen OEE‑Plattform.
Was „Unified Namespace“ bedeutet und warum MQTT ihn ermöglicht Unified Namespace (einheitlicher Namensraum) ist ein Architekturprinzip, bei dem jedes System in einen gemeinsamen MQTT‑Broker publiziert. Der Broker wird so zur einzigen Quelle der Wahrheit für alle Echtzeit‑Anlagendaten. ERP, MES, OEE‑Plattform, Historian, Analytics, sie abonnieren alle die Topics, die sie benötigen, ohne Punkt‑zu‑Punkt‑Integrationen.
UNS ersetzt die starre PLC → SCADA → MES → ERP‑Hierarchie durch einen flachen Pub/Sub‑Bus. Es passt gut zu Greenfield‑Digitalisierungsprojekten und zur Modernisierung (Lift‑and‑Shift) von Anlagen mit legacy SCADA. Was das für die Auswahl einer OEE‑Plattform bedeutet - Unterstützt die OEE‑Plattform MQTT nativ? - Unterstützt sie Sparkplug B (nicht nur rohes MQTT)?
- Kann sie vor Ort gegen einen bestehenden Broker betrieben werden? - Kann sie auch als Publisher fungieren (berechnete OEE‑Werte zurückschreiben) zusätzlich zum Subscriber‑Betrieb? Für KMU ohne bestehenden Broker ist OPC UA‑only oft einfacher. Für größere oder standortübergreifende Betriebe gewinnt MQTT + Sparkplug B in der Regel hinsichtlich langfristiger Skalierbarkeit.
Fabrico’s OEE‑Modul unterstützt sowohl OPC UA als auch MQTT/Sparkplug B als Datenquellen und kann berechnete OEE‑Metriken zurück in MQTT für nachgelagerte Verbraucher publizieren. Sehen Sie, wie Fabrico das automatisch erfasst, erkunden Sie OEE für die Fertigung oder buchen Sie eine Demo. Weiterführende Lektüre - OEE für Chargenfertigung - Pareto‑Diagramm in der Fertigung - KPI vs.
OKR in der Fertigung - Manufacturing Data Lake vs. Data Warehouse Häufig gestellte Fragen Sollte ich MQTT oder OPC UA für OEE verwenden? Für die meisten KMU‑Anlagen ist OPC UA ausreichend und einfacher. Für Multi‑Site‑ oder Unified‑Namespace‑Strategien ist MQTT/Sparkplug B die bessere langfristige Wahl. Was ist Sparkplug B?
Eine offene Spezifikation auf MQTT, die standardisierte Topic‑Benennung, Birth/Death‑Nachrichten, Zustandsverfolgung und typisierte Metriken hinzufügt. Der De‑facto‑Standard für industrielles MQTT. Brauche ich einen separaten Broker? Ja. MQTT ist um einen Broker herum aufgebaut. Häufige Optionen: HiveMQ, EMQX, Mosquitto (Open Source) oder Cloud‑Broker (AWS IoT, Azure IoT Hub). Ist MQTT sicher? Ja, mit TLS‑Verschlüsselung und Authentifizierung.
Anonyme, unverschlüsselte MQTT‑Verbindungen sind in Produktionsumgebungen nicht sicher. Wie vergleicht sich MQTT mit REST/HTTP für Telemetrie? MQTT ist für kontinuierliche Telemetrie deutlich effizienter. HTTP ist für gelegentliche API‑Aufrufe in Ordnung. Bei Maschinendaten, die alle paar Sekunden von Tausenden Geräten fließen, gewinnt MQTT deutlich.
Anmeldung
Blog
