Ein digitaler Zwilling der Smart City ist ein lebendiges geografisches Modell einer Stadt oder eines Stadtteils, das Karten und 3D-Stadtmodelle mit Echtzeit-Sensordaten zu Verkehr, Straßenbeleuchtung und Umwelt verbindet. Dieser Artikel erklärt, wofür Stadtzwillinge genutzt werden, wie Sie Sensordaten auf MQTT so strukturieren, dass viele Ämter und Anbieter sie gemeinsam nutzen können, und wie Sie ein kleines Pilotprojekt durchführen, das das Konzept belegt.
Was ein digitaler Zwilling der Smart City ist
Städte haben bereits reichlich Daten: Verkehrszähler, Steuerungen der Straßenbeleuchtung, Luftmessstationen, Parksensoren, Wetterstationen und Versorgungszähler. Das Problem: Jedes System gehört meist einem anderen Amt und Anbieter, mit eigenem Dashboard. Niemand sieht, wie sie zusammenwirken.
Ein Stadtzwilling legt diese Daten auf ein gemeinsames räumliches Modell, typischerweise eine GIS-Karte oder ein 3D-Stadtmodell auf Basis offener Standards wie CityGML. Planer können dann übergreifende Fragen stellen: Verbessert sich die Luftqualität in einer Straße, wenn der Verkehr umgeleitet wird? Welche Beleuchtungsabschnitte brennen nachts auf leeren Straßen mit voller Leistung? Wo sollten die nächsten Sensoren hin?
Stadtzwillinge decken ein breites Spektrum ab, von einer 2D-Karte mit Live-Sensormarkierungen bis zu detaillierten 3D-Modellen mit Simulation. Erst die Live-Datenverbindung macht aus beiden einen Zwilling statt eines statischen Modells. Die zugrunde liegenden Konzepte finden Sie im Leitfaden zur Digital-Twin-Technologie.
Zentrale Anwendungsfälle
Verkehrsüberwachung
Induktionsschleifen, Radar, Kameras mit Zählung auf dem Gerät sowie Bluetooth- oder WLAN-Sonden liefern Fahrzeugzahlen, Geschwindigkeiten und Belegung. Der Zwilling zeigt Staus, während sie entstehen, und deckt mit der Historie wiederkehrende Muster sowie die Wirkung von Baustellen oder geänderten Ampelschaltungen auf. Datenschutz ist hier wichtig, nicht zuletzt wegen der DSGVO: Veröffentlichen Sie aggregierte Zählungen und Geschwindigkeiten, niemals Identitäten, Kennzeichen oder Rohvideo.
Straßenbeleuchtung
Vernetzte Leuchtensteuerungen melden Lampenstatus, Leistung, Dimmstufe und Störungen. Im Zwilling erscheinen ausgefallene Leuchten sofort auf der Karte, statt auf Bürgermeldungen zu warten, und der Energieverbrauch lässt sich über Stadtteile und Dimmprofile hinweg vergleichen.
Umweltmonitoring
Luftqualitätssensoren messen Feinstaub (PM2.5, PM10), Stickstoffdioxid, Ozon, Temperatur, Luftfeuchte und Lärm. Kostengünstige Sensoren ermöglichen eine dichte Abdeckung, müssen aber gegen Referenzstationen kalibriert werden. Der Zwilling kombiniert beides, markiert Hotspots und korreliert sie mit Verkehr und Wetter.
Weitere Ebenen
Parkplatzbelegung, Füllstände von Abfallbehältern, Druck im Wassernetz, Hochwassersensoren und Positionen des öffentlichen Nahverkehrs passen alle in dasselbe Muster. Beginnen Sie mit zwei oder drei Ebenen und ergänzen Sie weitere, sobald sich die Datenplattform bewährt hat.
| Ebene | Beispielsensoren | Typisches Veröffentlichungsintervall | Zustand als Retained? | Datenschutzrelevanz |
|---|---|---|---|---|
| Verkehr | Schleifen, Radar, Kameras mit Zählung an der Edge | 1 bis 5 Minuten aggregiert | Letztes Aggregat | Hoch, an der Edge aggregieren |
| Straßenbeleuchtung | Leuchtensteuerungen | Bei Änderung, plus stündliche Energie | Ja, Lampenstatus | Gering |
| Luftqualität | PM-, NO2-, O3-Sensoren | 1 bis 15 Minuten | Letzter Messwert | Gering |
| Lärm | Schallpegelmesser | 1 Minute (nur Pegel) | Letzter Messwert | Mittel, niemals Audio veröffentlichen |
| Parken | Bodensensoren oder Kameras | Bei Änderung | Ja | Gering, wenn keine Kennzeichen |
Warum MQTT zu städtischen Sensornetzen passt
Städtische Sensoren sind zahlreich, batterie- oder netzbetrieben, über große Flächen verteilt und oft über Mobilfunk, LoRaWAN-Netzwerkserver oder städtische Glasfaser angebunden. MQTT funktioniert in diesem Umfeld gut:
- Geräte und Gateways verbinden sich ausgehend, sodass Sensoren hinter Mobilfunk-NAT keine eingehenden Ports benötigen.
- Kleine Nachrichten und geringer Overhead passen zu eingeschränkten Verbindungen und Geräten.
- Publish/Subscribe entkoppelt die Anbieter: Der Beleuchtungsanbieter veröffentlicht, während der Zwilling, das Open-Data-Portal und das Energieteam unabhängig voneinander abonnieren.
- Retained Messages liefern jedem neuen Konsumenten sofort den aktuellen Zustand Tausender Sensoren.
Ein Cloud-MQTT-Broker passt gut zu einem städtischen Programm: Ämter und Anbieter an verschiedenen Orten erreichen alle denselben TLS-Endpunkt, und die städtische IT muss keine Broker-Infrastruktur betreiben. Im städtischen Maßstab kommt es auf die Tarife an. Der kostenlose Serverless-Tarif von ConnectMQ reicht für ein Pilotprojekt mit bis zu 25 Verbindungen, der kostenpflichtige Serverless-Tarif unterstützt bis zu 1.000 Verbindungen, und Dedicated- oder BYOC-Optionen bieten einen isolierten Cluster oder ein Deployment im eigenen Cloud-Konto der Stadt. Viele Sensornetze aggregieren zudem über wenige Gateways oder Netzwerkserver, was die Zahl der Verbindungen überschaubar hält.
Topic-Design für einen Stadtzwilling
Strukturieren Sie Topics nach Stadt, Fachbereich, Stadtteil und Gerät:
connectmq/<city>/<domain>/<district>/<device-id>/<data-type>
connectmq/riverton/air/old-town/aq-017/reading
connectmq/riverton/lighting/old-town/lamp-4411/status
connectmq/riverton/traffic/old-town/loop-23/aggregate
connectmq/riverton/parking/harbor/bay-112/status
Legen Sie Koordinaten in einem Metadaten-Topic des Geräts (Retained) ab statt in jedem Messwert:
{
"deviceId": "aq-017",
"lat": 41.0151,
"lon": 28.9795,
"mountHeightM": 3.5,
"sensor": "PM and NO2 low-cost unit",
"calibratedAgainst": "reference-station-2"
}
Der Zwilling abonniert connectmq/riverton/+/+/+/meta, um Geräte auf der Karte zu platzieren, und danach die Daten-Topics für Live-Werte. Weil der Fachbereich zuerst kommt, kann jedes Amt seinen eigenen Zweig mit einer Wildcard abonnieren. Im Kern ist das ein Unified Namespace (UNS) für die Stadt: Was in der Fabrik die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) leistet, übernimmt hier die Gliederung Stadt → Fachbereich → Stadtteil → Gerät. Stadtwerke, die Netze und Erzeugungsanlagen bereits nach ISA-95 strukturieren, können beide Bäume auf demselben Broker zusammenführen; das Prinzip erklärt Sparkplug B und Unified Namespace. Allgemeine Muster finden Sie unter Digitaler Zwilling mit MQTT.
Praxis: simulierte Luftqualitätssensoren auf einer Live-Karte
Probieren Sie den Datenfluss mit dem kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com aus. Er ist für Tests und Prototypen gedacht: Verwenden Sie simulierte Werte und ein eindeutiges Präfix, denn der öffentliche Bereich ist für alle lesbar.
Ein Python-Skript, das drei Luftqualitätssensoren mit Metadaten simuliert:
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
RUN = "city-a19c" # change to your own unique id
BASE = f"connectmq/demo/{RUN}/air/old-town"
SENSORS = {
"aq-017": (41.0151, 28.9795),
"aq-018": (41.0122, 28.9760),
"aq-019": (41.0170, 28.9832),
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"aq-sim-{uuid.uuid4().hex[:6]}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
for sid, (lat, lon) in SENSORS.items():
client.publish(f"{BASE}/{sid}/meta", json.dumps({"deviceId": sid, "lat": lat, "lon": lon}), qos=1, retain=True)
while True:
rush_hour = time.localtime().tm_hour in (7, 8, 17, 18)
for sid in SENSORS:
pm25 = max(0.0, random.gauss(28 if rush_hour else 14, 4))
no2 = max(0.0, random.gauss(45 if rush_hour else 22, 6))
reading = {"pm25": round(pm25, 1), "no2": round(no2, 1), "unit": "ug/m3", "ts": int(time.time())}
client.publish(f"{BASE}/{sid}/reading", json.dumps(reading), qos=1, retain=True)
time.sleep(10)
Eine Browserkarte (zum Beispiel mit Leaflet) verbindet sich über Secure WebSocket und aktualisiert die Markierungen:
import mqtt from "mqtt";
const base = "connectmq/demo/city-a19c/air/old-town";
const markers = {};
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "city-map-" + Math.random().toString(16).slice(2, 10),
protocolVersion: 5,
});
client.on("connect", () => client.subscribe([`${base}/+/meta`, `${base}/+/reading`]));
client.on("message", (topic, payload) => {
const [, , , , , id, kind] = topic.split("/");
const data = JSON.parse(payload.toString());
if (kind === "meta" && !markers[id]) {
markers[id] = L.circleMarker([data.lat, data.lon], { radius: 10 }).addTo(map);
} else if (kind === "reading" && markers[id]) {
const color = data.pm25 > 25 ? "#d94040" : data.pm25 > 15 ? "#e0a030" : "#3fa34d";
markers[id].setStyle({ color, fillColor: color }).bindTooltip(`${id}: PM2.5 ${data.pm25} ${data.unit}`);
}
});
Hier ist map Ihre Leaflet-Karteninstanz. Die Farbschwellen dienen nur der Veranschaulichung; verwenden Sie die Grenzwerte Ihrer örtlichen Luftqualitätsvorgaben.
Checkliste für das Pilotprojekt
- Wählen Sie einen Stadtteil und zwei oder drei Datenebenen mit klaren Verantwortlichen.
- Stimmen Sie Topic-Hierarchie und Payload-Schemata vor der Installation mit jedem Anbieter ab.
- Verpflichten Sie Anbieter, per MQTT über TLS (Port 8883) zu veröffentlichen, oder binden Sie ihre APIs über einen kleinen Adapter an.
- Vergeben Sie eine Zugangskennung pro Anbietersystem oder Gateway; ConnectMQ bindet Client IDs an die ausgegebenen Zugangsdaten und sperrt IPs nach wiederholten fehlgeschlagenen Anmeldungen.
- Aggregieren Sie datenschutzrelevante Daten an der Edge; veröffentlichen Sie niemals personenbezogene Daten.
- Speichern Sie die Historie mit einem Subscriber, der eine Zeitreihendatenbank für Planungsanalysen füttert.
- Konfigurieren Sie einfache Schwellenwertalarme, etwa PM2.5 über einem Grenzwert, im Portal oder in Ihrem eigenen Dienst.
- Veröffentlichen Sie ausgewählte, nicht sensible Aggregate über einen separaten Subscriber in einem Open-Data-Portal.
Stolpersteine
- Anbieterabhängigkeit durch proprietäre Dashboards. Machen Sie die MQTT-Veröffentlichung an den Broker der Stadt zur Vergabeanforderung.
- Unkalibrierte Low-Cost-Sensoren. Platzieren Sie einige neben Referenzstationen und veröffentlichen Sie Korrekturmetadaten.
- Uneinheitliche Uhren. Verlangen Sie UTC-Zeitstempel von jeder Quelle.
- Mit dem 3D-Modell beginnen. Eine 2D-Karte mit zuverlässigen Live-Daten ist nützlicher als ein schönes Modell mit veralteten Daten.
Stadtzwillinge teilen viele Bausteine mit dem digitalen Zwilling für Gebäude und dem digitalen Zwilling für Energie.
Starten Sie Ihr Smart-City-Pilotprojekt auf ConnectMQ
ConnectMQ ist ein verwalteter MQTT-Broker mit TLS, WebSocket-Zugang für Browserkarten und Unterstützung für MQTT 5. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, und verbinden Sie die Sensoren Ihres ersten Stadtteils mit einem Live-Zwilling.
Häufig gestellte Fragen
Was ist ein digitaler Zwilling der Smart City?
Ein lebendiges digitales Modell einer Stadt oder eines Stadtteils, das Karten oder 3D-Stadtmodelle mit Echtzeit-Sensordaten zu Verkehr, Beleuchtung, Umwelt und weiterer Infrastruktur verbindet.
Warum MQTT für Smart-City-Sensoren nutzen?
MQTT ist schlank, funktioniert über ausgehende Verbindungen von Mobilfunk- und LoRaWAN-Gateways und erlaubt vielen Ämtern, dieselben Sensordaten ohne separate Integrationen zu abonnieren.
Wie schützen digitale Stadtzwillinge die Privatsphäre?
Indem sie Daten an der Edge aggregieren und nur Zählungen, Pegel und Messwerte veröffentlichen, niemals Bilder, Audio, Kennzeichen oder personenbezogene Merkmale.
Kann ein digitaler Stadtzwilling klein anfangen?
Ja. Ein Pilotprojekt mit einem Stadtteil und zwei oder drei Datenebenen auf einer 2D-Karte ist ein praktikabler Start, und weitere Ebenen lassen sich ergänzen, sobald die Datenplattform funktioniert.
