Smart City IoT: Architektur mit MQTT erklärt

Smart-City-IoT-Projekte beginnen meist als getrennte Pilotprojekte, eines für Straßenlaternen, eines für Abfallbehälter, eines für Luftqualität, und tun sich dann schwer, Daten miteinander zu teilen. Dieser Leitfaden erklärt eine Architektur im Stadtmaßstab, in der jede Fachdomäne an eine gemeinsame MQTT-Messaging-Schicht veröffentlicht, sodass Sie neue Dienste hinzufügen können, ohne jedes Mal ein neues Datensilo zu bauen. Sie lernen die Schichten, eine praxistaugliche Topic-Hierarchie, Konnektivitätsoptionen sowie die entscheidenden Sicherheits- und Skalierungsfragen kennen.

Das Problem isolierter Pilotprojekte

Eine typische Stadt hat am Ende ein Portal des Beleuchtungsanbieters, ein Dashboard für die Abfallsammlung und eine Umweltmessplattform, jeweils mit eigenem Datenmodell, eigenem Login und eigenem Exportformat. Sie zu kombinieren, etwa um Laternen bei schlechter Luftqualität zu dimmen oder Sammelfahrzeuge um Baustellen herumzuleiten, wird jedes Mal zum Integrationsprojekt.

Eine gemeinsame Messaging-Schicht ändert die Ausgangslage. Wenn jedes System seine Ereignisse und Zustände unter einem gemeinsamen Namensraum an einen Broker veröffentlicht, kann jede neue Anwendung genau das abonnieren, was sie braucht. Anbieter liefern weiterhin Geräte und Spezialsoftware; sie verpflichten sich lediglich, an das Backbone der Stadt zu veröffentlichen und daraus zu lesen. Wenn Sie die Rolle des Brokers auffrischen möchten, lesen Sie, was ein MQTT-Broker macht.

Smart-City-IoT-Architektur in fünf Schichten

Schicht	Was dort angesiedelt ist	Typische Technologien
Geräte	Leuchtensteuerungen, Füllstandsensoren, Luftqualitätsstationen, Parkplatz-Pucks	Mikrocontroller, NEMA/Zhaga-Leuchtenknoten, Ultraschall- und optische Sensoren
Feldnetze	Stromsparende Funk- und Mobilfunkverbindungen	LoRaWAN, NB-IoT, LTE-M, WLAN in Gebäuden, Glasfaser zu Schaltschränken
Gateways und Netzwerkserver	Funk-Payloads dekodieren, Protokolle übersetzen	LoRaWAN-Netzwerkserver, Edge-Gateways, Protokollkonverter
Messaging-Backbone	Leitet Ereignisse zwischen Erzeugern und Verbrauchern weiter	MQTT-Broker mit TLS, strukturierte Topics
Anwendungen	Dashboards, Analysen, Steuerlogik, Open Data	Node-RED, Zeitreihendatenbanken, GIS-Karten, eigene Dienste

Der Broker sitzt bewusst in der Mitte. Feldnetze und Anwendungen ändern sich in unterschiedlichem Tempo; die Entkopplung über Publish/Subscribe bedeutet, dass ein neues Analysewerkzeug für Luftqualität keinerlei Änderung an den Sensoren erfordert.

Drei Beispieldomänen

Intelligente Straßenbeleuchtung

Leuchtensteuerungen melden Leistungsaufnahme, Brennstunden und Störungen und nehmen Dimmbefehle entgegen. Typische Topics sind ein retained state mit dem aktuellen Dimmwert und ein set-Befehls-Topic, das der Zeitplandienst nutzt. Störungsereignisse, etwa ein ausgefallenes Vorschaltgerät, werden automatisch zu Wartungstickets, sobald ein Subscriber sie aufgreift. Unser Artikel zu intelligenter Beleuchtung mit MQTT behandelt die Befehls- und Zustandsmuster im Detail.

Füllstände von Abfallbehältern

Ultraschall- oder Radarsensoren in den Behältern melden den Füllstand in Prozent einige Male am Tag über LoRaWAN oder NB-IoT. Ein Routenplanungsdienst abonniert alle Behälter eines Bezirks und plant Leerungen für Behälter oberhalb eines Schwellenwerts. Der Nutzen von MQTT liegt hier weniger in der Latenz als in der Entkopplung: Routenplaner, Open-Data-Portal und Sauberkeits-Dashboard lesen alle dieselben retained Füllstände.

Luftqualitätsüberwachung

Stationen messen Feinstaub, Stickstoffdioxid, Temperatur und Luftfeuchtigkeit. Die Daten speisen öffentliche Karten, Gesundheitswarnungen und Forschung. Derselbe Mess- und Veröffentlichungsansatz, der in Innenräumen in einem Raumluftqualitäts-Messgerät zum Einsatz kommt, lässt sich auf Straßenebene übertragen, mit mehr Augenmerk auf Kalibrierung, Gehäuseheizung und Datenvalidierung.

Parken ist eine vierte verbreitete Domäne, die in unserem Bauplan für Smart Parking IoT von Anfang bis Ende beschrieben wird.

Eine stadtweite Topic-Hierarchie

Ein gemeinsamer Namensraum ist die wertvollste Vereinbarung im gesamten Projekt. In der Industrie heißt dieses Konzept Unified Namespace (UNS): Alle Systeme veröffentlichen ihren aktuellen Zustand in einer einzigen, verbindlichen Topic-Struktur auf dem Broker, und in Fabriken liefert die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) diese Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Für eine Stadt übernehmen Fachdomäne, Bezirk und Objekt die Rolle der ISA-95-Ebenen; das Prinzip eines UNS bleibt gleich. Bewährt hat sich ein Aufbau nach dem Muster: zuerst die Domäne, dann die Geografie, dann das Objekt:

city/<domain>/<district>/<asset-type>/<asset-id>/<signal>

city/lighting/north/lamp/L-10442/state          retained {"on":true,"dim":60,"watts":38}
city/lighting/north/lamp/L-10442/state/set      {"dim":30}
city/lighting/north/lamp/L-10442/fault          {"code":"DRIVER_FAIL","ts":1760600000}
city/waste/centre/bin/B-2210/fill               retained {"pct":82,"ts":1760600000}
city/air/harbour/station/AQ-07/pm25             retained {"ugm3":14.2,"ts":1760600000}
city/parking/old-town/summary                   retained {"free":112,"total":420}

Warum die Domäne zuerst? Weil die Zuständigkeit den Domänen folgt. Das Beleuchtungsamt ist für city/lighting/# verantwortlich, was die Eingrenzung von Zugangsdaten, Audits und Anbieterverträge leichter nachvollziehbar macht. Anwendungen, die Geografie benötigen, können trotzdem domänenübergreifend abonnieren: city/+/harbour/# liefert alles im Hafenbezirk.

Regeln, die Sie gleich zu Beginn festhalten sollten:

Jeder Payload ist JSON mit Zeitstempel und expliziten Einheiten in den Schlüsselnamen.
Zustände sind retained; Ereignisse und Befehle nicht.
Objekt-IDs entsprechen dem Anlagenregister der Stadt, nicht den Seriennummern der Anbieter.
Befehle verwenden immer das Suffix /set, und nur dafür vorgesehene Dienste veröffentlichen sie.

Konnektivität: Wie Daten zum Broker gelangen

Die meisten städtischen Sensoren sind batteriebetrieben und weit entfernt von WLAN, daher ist das Feldnetz in der Regel LoRaWAN oder zellulares IoT. Keines von beiden verlangt, dass jeder Sensor selbst MQTT spricht:

LoRaWAN-Sensoren senden kleine binäre Payloads an Gateways auf Dächern; ein Netzwerkserver dekodiert sie und veröffentlicht sie per MQTT. Ein eigener Betrieb mit ChirpStack und MQTT ist eine verbreitete Wahl für Kommunen, die die Kontrolle über ihr Netz behalten wollen.
NB-IoT- und LTE-M-Geräte können direkt eine MQTT-Verbindung über TLS öffnen, was zu netzbetriebenen Anlagen wie Leuchtensteuerungen oder Luftmessstationen passt.
Kabelgebundene Anlagen in Schaltschränken und Gebäuden werden über Edge-Gateways angebunden, die Modbus oder herstellerspezifische Protokolle übersetzen.

Der Broker erhält so oder so saubere, dekodierte Daten. Ein nützlicher Nebeneffekt: Die Zahl der Verbindungen bleibt überschaubar, denn Tausende LoRaWAN-Sensoren können über eine Handvoll Netzwerkserver-Verbindungen eintreffen.

Städtische Daten nutzen: Ein kleines Beispiel

Jede Anwendung ist einfach ein weiterer MQTT-Client. Dieser Python-Subscriber mit paho-mqtt 2.x beobachtet jede Luftqualitätsstation und markiert Messwerte oberhalb eines Schwellenwerts. Probieren Sie ihn mit Ihrem eigenen Präfix gegen den öffentlichen MQTT-Broker aus, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten:

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/c9d1e4"   # Ihre eigene zufällige ID
LIMIT = 25.0                       # Beispiel-Schwellenwert für PM2.5 in ug/m3

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/air/+/station/+/pm25", qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    district, station = parts[-4], parts[-2]
    reading = json.loads(msg.payload)
    if reading["ugm3"] > LIMIT:
        print(f"High PM2.5 in {district} at {station}: {reading['ugm3']}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="air-watch-c9d1e4")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

mosquitto_pub -h broker.connectmq.com -p 1883 -i aq-c9d1e4 -r -q 1 \
  -t connectmq/demo/c9d1e4/air/harbour/station/AQ-07/pm25 -m '{"ugm3":31.5,"ts":1760600000}'

Das Demo-Präfix belegt bereits drei Ebenen, daher verzichtet das Beispiel auf die Wurzel city, um innerhalb der Grenze von acht Ebenen des öffentlichen MQTT-Brokers zu bleiben; auf einem privaten Broker würden Sie den vollständigen Pfad city/air/... verwenden. Im Produktivbetrieb können Alarmschwellen auch im Broker-Portal hinterlegt werden: ConnectMQ bietet Regeln für Schwellenwertalarme und ein Alarmprotokoll, während komplexere Logik in Node-RED oder in Ihre eigenen, als Clients verbundenen Dienste gehört.

Sicherheit und Governance

Städtische Infrastruktur ist kritische Infrastruktur, und die Messaging-Schicht muss entsprechend behandelt werden. Für Stadtwerke und kommunale Betreiber im DACH-Raum kommen je nach Größe und Sektor Pflichten aus NIS2 hinzu, und sobald Daten Rückschlüsse auf Personen erlauben, etwa bei Parken oder Kameras, gilt die DSGVO:

TLS überall. Port 8883 für Geräte und Gateways, 8084 für sicheren WebSocket bei Browser-Dashboards.
Eigene Zugangsdaten pro Gateway oder Dienst. Teilen Sie niemals ein Login zwischen Anbietern. An Zugangsdaten gebundene Client-IDs erschweren Identitätsdiebstahl.
Getrennte Befehlswege. Nur der Zeitplandienst sollte Beleuchtungsbefehle veröffentlichen; Anbieter und Dashboards sollten Zustände lesen.
Isolation, wo nötig. Sensible Domänen können auf einem separaten Broker oder einem Dedicated-Cluster laufen, statt sich einen Broker mit öffentlichen Daten zu teilen.
Open Data durch Veröffentlichung, nicht durch Zugriff. Veröffentlichen Sie kuratierte Datensätze im Open-Data-Portal, statt Broker-Zugangsdaten herauszugeben.

Unser Leitfaden zu Best Practices für MQTT-Sicherheit vertieft Zugangsdaten, TLS und Monitoring.

Entscheidungen zu Skalierung und Hosting

Städtische Projekte wachsen über Jahre von einem Pilotbezirk zur ganzen Stadt, wählen Sie also ein Hosting-Modell, das mitwächst. Ein eigener Broker-Cluster ist möglich, macht die Stadt aber für Patches, Zertifikate, Monitoring und Kapazität verantwortlich. Ein verwalteter MQTT-Broker verlagert diese Arbeit zum Anbieter. ConnectMQ bietet gemeinsam genutzte Serverless-Tarife für Pilotprojekte, isolierte Dedicated-Cluster für den Produktivbetrieb und BYOC-Bereitstellungen, die im eigenen Cloud-Konto der Stadt laufen, wenn Vorgaben zur Datenresidenz dies erfordern. Einen breiteren Vergleich der Hosting-Modelle finden Sie im Leitfaden zum Cloud-MQTT-Broker.

Verwandte Anwendungsfälle wie die Kühlkettenüberwachung für kommunale Lebensmittel- und Impfstofflogistik folgen demselben Muster, und der Leitfaden zur IoT-Automatisierung sammelt Projekte für Gebäude, Landwirtschaft und Energie.

Checkliste für Smart-City-IoT-Bereitschaft

Ein schriftlich festgelegter Topic-Namensraum mit Domäne, Bezirk, Objekttyp und ID.
Eine Payload-Konvention mit Zeitstempeln und Einheiten.
Ein Anlagenregister, das IDs Standorten und Verantwortlichen zuordnet.
Feldnetze pro Domäne ausgewählt und über Gateways an MQTT angebunden.
Zugangsdaten pro Gateway und Dienst, TLS auf jeder Verbindung.
Eine klare Liste, welche Dienste Befehle veröffentlichen dürfen.
Überwachung von Geräteverfügbarkeit und Batterieständen.
Ein Hosting-Plan, der vom Pilotprojekt bis zur ganzen Stadt skaliert.

Bauen Sie Ihr städtisches Daten-Backbone auf ConnectMQ

Starten Sie einen Pilotbezirk auf einem kostenlosen Serverless-Broker, erproben Sie das Topic-Modell mit echten Sensoren und wechseln Sie dann für den Produktivbetrieb zu einer Dedicated- oder BYOC-Bereitstellung. Registrieren Sie sich unter app.connectmq.com, ganz ohne Kreditkarte, und sehen Sie zu, wie Ihre ersten städtischen Topics im Live-Topic-Explorer erscheinen.

Häufig gestellte Fragen

Müssen Smart-City-Sensoren MQTT direkt unterstützen?

Nein. Die meisten batteriebetriebenen Sensoren nutzen LoRaWAN oder NB-IoT, und ein Netzwerkserver oder Gateway dekodiert ihre Payloads und veröffentlicht sie stellvertretend an den MQTT-Broker.

Warum steht die Domäne im Topic vor dem Bezirk?

Zuständigkeit und Zugriff folgen in der Regel den Domänen, etwa Beleuchtung oder Abfall. Topics mit der Domäne an erster Stelle erleichtern die Zuordnung von Verantwortlichkeiten und erlauben dennoch bezirksweite Wildcard-Abonnements.

Kann ein Broker alle städtischen Ämter bedienen?

Ja, solange jedes Amt eigene Zugangsdaten und einen eigenen Topic-Teilbaum verwendet. Hochsensible Systeme können trotzdem auf einem separaten Broker oder Dedicated-Cluster betrieben werden.

Wie sollte eine Stadt Open Data aus ihren Sensoren veröffentlichen?

Betreiben Sie einen Subscriber, der Datensätze kuratiert, aggregiert und im Open-Data-Portal veröffentlicht. Geben Sie keine Broker-Zugangsdaten an die Öffentlichkeit heraus.

Smart-City-IoT-Architektur mit MQTT: Beleuchtung, Abfall, Luftqualität und die Messaging-Schicht