Wer hat MQTT erfunden? Die Geschichte von Ölpipelines bis zum IoT

Wer hat MQTT erfunden? Andy Stanford-Clark von IBM und Arlen Nipper von Arcom Control Systems entwickelten es 1999, um Ölpipelines über teure Satellitenverbindungen zu überwachen. Dieser Artikel verfolgt MQTT von dieser industriellen Nische bis zum offenen OASIS- und ISO-Standard und zum Standardprotokoll des IoT und erklärt, wie die ursprünglichen Designziele noch heute prägen, wie Sie es einsetzen.

Das Problem 1999: Pipelines, Satelliten und Bandbreite

Ende der 1990er-Jahre mussten Öl- und Gasbetreiber Telemetriedaten von entlegenen Pipeline-Anlagen erfassen: Drücke, Durchflüsse, Ventilstellungen, Pumpenzustände. Viele Standorte hatten kein terrestrisches Netz, daher liefen die Daten über Satellitenverbindungen, die langsam, unterbrochen und nach Byte abgerechnet waren. Bestehende Ansätze fragten jedes Gerät nach Zeitplan ab (Polling), verschwendeten Bandbreite für unveränderte Werte und gerieten jedes Mal ins Straucheln, wenn die Verbindung abbrach.

Zwei Ingenieure näherten sich dem Problem von unterschiedlichen Seiten:

• Andy Stanford-Clark bei IBM, der an Messaging-Middleware arbeitete und sich stark für Pervasive Computing interessierte.
• Arlen Nipper bei Arcom Control Systems (später Teil von Eurotech), der umfassende SCADA- und Embedded-Hardware-Erfahrung aus der Praxis mitbrachte.

Gemeinsam entwarfen sie ein Protokoll, das Daten nur bei Änderungen pushen, unzuverlässige Verbindungen überstehen und auf bescheidener Hardware laufen sollte.

Die ursprünglichen Designziele

Ihre Ziele lesen sich wie eine moderne IoT-Checkliste:

1. Einfach zu implementieren auf kleinen Geräten mit begrenztem Speicher und wenig CPU.
2. Minimaler Overhead, damit jedes Byte über Satellit nützliche Daten transportiert.
3. Publish/Subscribe, damit entfernte Geräte nicht wissen mussten, wer ihre Daten konsumiert.
4. Quality-of-Service-Stufen, damit der Sender für jede Nachricht Zuverlässigkeit gegen Bandbreite abwägen konnte.
5. Toleranz gegenüber unterbrochener Konnektivität, einschließlich einer Möglichkeit, allen mitzuteilen, wenn ein Gerät unerwartet wegfiel.
6. Datenunabhängigkeit, also beliebige Payload-Formate, ohne dass sich das Protokoll darum kümmert.

Jedes Ziel entspricht direkt Funktionen, die Sie noch heute nutzen: der minimal zwei Byte große feste Header, das brokerzentrierte Publish/Subscribe-Modell, QoS 0/1/2, Keep-Alive und Last Will sowie undurchsichtige Payloads.

Wofür steht MQTT?

Das „MQ“ stammt von IBMs Messaging-Produktfamilie MQSeries, und das Protokoll hieß ursprünglich MQ Telemetry Transport. Dieser Name sorgte jahrelang für Verwirrung, denn MQTT ist keine Message Queue im Sinne von MQSeries. Mit der Standardisierung wurde der Name schlicht zu „MQTT“ und gilt offiziell nicht mehr als Akronym.

Zeitleiste der MQTT-Geschichte: Wer MQTT erfunden hat und was danach kam

Die Spezifikationsdokumente selbst sind beim OASIS-Komitee erhältlich und auf mqtt.org zusammengefasst.

Von proprietär zu offen: Warum 2010 der Wendepunkt war

In seinem ersten Jahrzehnt war MQTT vor allem eine IBM-Technologie. Die lizenzgebührenfreie Freigabe der Spezifikation 3.1 im Jahr 2010 änderte das. Entwickler konnten nun Clients und Broker ohne Lizenzsorgen schreiben, und genau das taten sie:

• Eclipse Paho stellte Client-Bibliotheken in vielen Sprachen bereit und gab Entwicklern einen gemeinsamen Ausgangspunkt.
• Mosquitto, ein schlanker Open-Source-Broker, machte es trivial, MQTT auf einem Laptop oder Raspberry Pi zu betreiben.
• Bastler und Start-ups setzten es für Hausautomation und vernetzte Produkte ein und entdeckten es oft über Arduino- und Linux-Projekte.

Dieser Zeitpunkt fiel mit dem Aufstieg günstiger WLAN-Mikrocontroller und Smartphones zusammen. Ein für Satellitenverbindungen entworfenes Protokoll erwies sich als ideal für batteriebetriebene Sensoren und mobile Apps in wackeligen Mobilfunknetzen.

Standardisierung: OASIS und ISO

Offene Implementierungen sorgten für Schwung, doch Unternehmen wollten einen herstellerneutralen Standard. IBM und andere brachten MQTT zu OASIS, wo ein Technical Committee Version 3.1 zu MQTT 3.1.1 weiterentwickelte, mehrdeutige Bereiche klärte und das Protokoll in der Praxis kompatibel hielt. 2014 wurde es OASIS-Standard und 2016 von ISO/IEC als 20922 übernommen.

Anschließend nahm sich das Komitee die Lehren aus großen Deployments vor. MQTT 5.0, verabschiedet 2019, behielt das Kernmodell bei, ergänzte aber, was Betreibern gefehlt hatte: Reason Codes zur Fehlerdiagnose, Session und Message Expiry, Shared Subscriptions zur Lastverteilung, Topic Aliases, User Properties und Request/Response-Metadaten. Unser Überblick über die MQTT-5-Funktionen erklärt jede Neuerung.

Verbreitete Irrtümer über die Ursprünge von MQTT

Einige Mythen tauchen in Foren und Interviews immer wieder auf:

• „MQTT wurde für das Internet der Dinge gebaut.“ Den Begriff IoT gab es 1999 kaum. MQTT wurde für industrielle Telemetrie entwickelt und erst später zum Standardprotokoll des IoT.
• „MQTT ist eine Message Queue.“ Das MQ im ursprünglichen Namen bezieht sich auf eine Produktfamilie, nicht auf Warteschlangensemantik. Jeder passende Subscriber erhält seine eigene Kopie einer Nachricht.
• „MQTT war schon immer offen.“ Es war rund ein Jahrzehnt proprietär, bevor es 2010 lizenzgebührenfrei freigegeben wurde.
• „MQTT 5 hat 3.1.1 ersetzt.“ Beide sind weiterhin weit verbreitet, und die meisten Broker unterstützen beide parallel.

Warum das ursprüngliche Design noch heute zählt

Viele heutige Best Practices sind die Anforderungen von 1999 in neuem Gewand:

1. Verbindungen langlebig halten. MQTT setzt eine dauerhafte Verbindung voraus und verteilt die Aufbaukosten auf viele Nachrichten.
2. Bei Änderung publizieren, nicht nach Timer, wenn Bandbreite oder Batterie kostbar sind.
3. Last Will für Präsenz nutzen, genau die Anforderung „allen mitteilen, wenn ein Gerät wegfällt“.
4. QoS pro Nachrichtentyp wählen und Zuverlässigkeit gegen Kosten abwägen, wie es die Entwickler vorgesehen haben.
5. Das Payload-Format selbst bestimmen, ob JSON, Protobuf oder Sparkplug B.

Diese Geschichte erklärt auch die Grenzen von MQTT. Es wurde nicht als dauerhaftes Log oder Stream-Processing-Plattform entworfen. Deshalb kombinieren Produktionssysteme einen Broker mit Datenbanken, Historians oder Stream-Prozessoren, die als Clients angebunden sind. In der Fertigung sind das typischerweise MES, ERP und Historian, die Maschinendaten aus SPS und OPC-UA-Servern über den Broker beziehen.

Von selbst betriebenen Brokern zum verwalteten MQTT-Broker

Die frühen Anwender betrieben ihre eigenen Broker auf eigenen Servern. Das ist weiterhin möglich, bedeutet aber, dass Patches, Zertifikatserneuerung, Monitoring und Skalierung Ihre Aufgabe sind. Ein wachsender Anteil der Teams wählt heute einen verwalteten MQTT-Broker und verwendet die Zeit stattdessen für Geräte und Anwendungen.

ConnectMQ ist ein solcher MQTT-Broker in der Cloud. Er unterstützt MQTT 3.1.1 und 5.0, bietet TLS auf 8883 und sicheres WebSocket auf 8084 und enthält industrielle Funktionen, die den Ursprüngen des Protokolls in der Pipeline-Überwachung gefallen hätten: Erkennung von ISA-95-Topics und Topics im Unified Namespace (UNS) sowie Dekodierung von Sparkplug B. In Industrie-4.0-Projekten wird die ISA-95-Anlagenhierarchie (Enterprise → Site → Area → Line → Cell) direkt zur Topic-Struktur des UNS, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur; wie das mit Sparkplug B zusammenspielt, zeigt der Beitrag zu Sparkplug B und Unified Namespace. Wenn Sie das Protokoll, wie es die Erfinder entworfen haben, ohne jede Einrichtung erleben möchten, verbinden Sie sich mit dem öffentlichen MQTT-Broker, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten:

mosquitto_sub -h broker.connectmq.com -p 1883 -i history-sub-e41f \
  -t "connectmq/demo/e41f/pipeline/#" -v

mosquitto_pub -h broker.connectmq.com -p 1883 -i history-pub-e41f \
  -t "connectmq/demo/e41f/pipeline/station7/pressure" -m "42.7" -q 1

Eine entfernte Station publiziert einen Wert, der Broker pusht ihn an jeden interessierten Subscriber, und niemand pollt. Das ist die Idee von 1999 in zwei Befehlen. Um tiefer einzusteigen, machen Sie mit dem MQTT-Tutorial weiter oder sehen Sie in MQTT-Anwendungsfälle nach Branche, wo das Protokoll heute eingesetzt wird.

Starten Sie mit ConnectMQ

Erleben Sie MQTT so, wie es seine Erfinder gedacht haben, ohne einen Server zu betreiben. Registrieren Sie sich unter app.connectmq.com, erstellen Sie ohne Kreditkarte einen kostenlosen Serverless-Broker und publizieren Sie mit dem Browser-Client von ConnectMQ in wenigen Minuten Ihre erste Nachricht.

Häufig gestellte Fragen

Wer hat MQTT erfunden?

Andy Stanford-Clark von IBM und Arlen Nipper von Arcom Control Systems (später Eurotech) erfanden MQTT im Jahr 1999.

Warum wurde MQTT entwickelt?

Um Ölpipeline-Anlagen über unzuverlässige, teure Satellitenverbindungen zu überwachen. Dafür brauchte es ein schlankes Protokoll, das nur Änderungen pusht und Verbindungsabbrüche toleriert.

Wofür steht MQTT?

Ursprünglich für MQ Telemetry Transport, nach IBMs MQSeries-Produkten. Heute nennt der Standard es einfach MQTT.

Ist MQTT ein offener Standard?

Ja. MQTT 3.1.1 und 5.0 sind OASIS-Standards, und MQTT 3.1.1 ist zudem ISO/IEC 20922.