Smart-City-Architektur: Best Practices für MQTT, ChirpStack, LoRaWAN, Kubernetes und Terraform

Die kurze Version: eine Smart-City-Plattform ist nicht eine Plattform. Sie ist eine Kette aus nüchternen Architekturentscheidungen, die Wetter, Funklöcher, Vergaberecht, Datenschutz, Vendor-Wechsel und Geräte aushalten muss, die niemand zweimal anfassen will. Die robuste Architektur ist geschichtet: Geräte am Edge, LoRaWAN oder Mobilfunk für die Fläche, MQTT für Telemetrie, Device Registry und Command Path, ein kanonisches Datenmodell für Interoperabilität, Time-Series Storage für Messwerte, Event Stream für Konsumenten, APIs für Anwendungen und Infrastructure as Code darunter. Kubernetes und Terraform helfen, wenn das Team reif genug für DevOps ist. Sie schaden, wenn sie selbst zum Projekt werden.

Die Entscheidung vor dem Stack

Die meisten Smart-City-Diskussionen starten zu tief. Soll es MQTT, Kafka, LoRaWAN, Kubernetes, FIWARE, AWS IoT Core, Azure IoT Hub, ThingsBoard oder ein eigener Backend-Stack sein? Alles relevante Fragen. Aber zuerst musst du das Betriebsmodell klären. Genau an dieser Stelle beginnen wir auch in IoT-Projekten: nicht beim Lieblingswerkzeug, sondern beim Betrieb.

Eine Stadtplattform hat mehrere Eigentümer: die Verwaltung, die zahlt; das Betriebsteam, das Störungen tragen muss; Vendoren, die Geräte warten; Bürger, deren Daten indirekt betroffen sein können; und spätere App-Teams, die die Daten wiederverwenden wollen. Wenn du nur für den Pilot baust, bekommst du Integrationsarchäologie. Wenn du nur für den universellen Datenraum baust, geht der erste Pilot oft nie live.

Die erste Architekturfrage lautet deshalb: baust du ein isoliertes Betriebssystem für einen Use Case, eine mehrere Abteilungen tragende City-Data-Plattform oder einen föderierten Datenraum? Für das erste reichen MQTT plus sauberes Backend. Für das zweite brauchst du Identity, Metadaten, Governance, Standard-APIs, Langzeit-Storage und Anwendungsgrenzen. Für das dritte brauchst du semantische Interoperabilität und explizite Data-Sharing-Verträge.

Referenzarchitektur, die Produktion aushält

1. Device- und Feld-Layer. Sensoren, Gateways, Controller, Kameras nur mit gutem Grund, PLCs für industrielle Assets und eine echte Geräteidentität. Das Gerät muss reconnecten, puffern, Credentials rotieren, Firmware melden und bei Netzverlust kontrolliert ausfallen.
2. Konnektivität. LoRaWAN für kleine, seltene, batteriebetriebene Nachrichten; NB-IoT oder LTE-M, wenn Carrier-Abdeckung und SIM-Betrieb passen; Ethernet oder industrielle Netze, wenn Strom und Zuverlässigkeit wichtiger sind als Batterielaufzeit.
3. Ingestion. MQTT Broker oder Managed IoT Broker für Telemetrie, Command Topics, Device Lifecycle Events und Bridge Topics. Hier setzt du TLS, Zertifikate, Topic-Autorisierung, Quotas und Payload-Limits durch.
4. LoRaWAN Network Server. ChirpStack, The Things Stack oder ein Managed Network Server übernimmt Join, Deduplication, ADR, Downlink Scheduling, Frame Counter und Routing. Packe diese MAC-Logik nicht in dein App-Backend.
5. Normalisierung und Validierung. Payloads decodieren, Device-Metadaten anhängen, Einheiten prüfen, unmögliche Werte abweisen, Schema-Versionen setzen und idempotent schreiben. Hier werden Bytes zu vertrauenswürdigen Events.
6. Kontext- und Datenmodell. NGSI-LD/FIWARE oder OGC SensorThings, wenn mehrere Abteilungen, Vendoren oder Open-Data-Konsumenten dieselbe Entität verstehen müssen. Für isolierte Systeme reicht oft ein einfacheres internes Modell, aber Einheiten, Standort, Ownership, Retention und Quality Flags müssen dokumentiert sein.
7. Storage. Time-Series DB für Messwerte, Object Storage für Rohdaten, relationale DB für Registry und Konfiguration, Geospatial Index für Karten und unveränderliche Logs für auditrelevante Aktionen.
8. Event- und Integrationslayer. Validierte Events gehen an Analytics, Alerts, Dashboards, Work-Order-Systeme, Open-Data-Portale und KI-Systeme. MQTT ist oft das Edge-Protokoll; Kafka, NATS, Redpanda, Pulsar oder Cloud Queues passen nach der Validierung häufig besser.
9. Anwendungen. Dashboards, Operator-Konsolen, Bürgerdienste, Anomalieerkennung, Wartungsplanung und APIs. Halte sie austauschbar. Die Plattform darf nicht von einem Dashboard-Vendor abhängen.
10. Betrieb. Terraform für Infrastruktur, Kubernetes oder Managed Services für Workloads, GitOps für Deploys, Metrics, Traces, Logs, Backups, Restore-Tests, SBOMs, Vulnerability Management und ein Runbook, das auch ohne Originalarchitekt funktioniert.

MQTT: sehr guter Telemetrie-Default, nicht die ganze Architektur

MQTT.org beschreibt MQTT als OASIS-Standard für IoT Connectivity: Publish/Subscribe, leichtgewichtig, für eingeschränkte Geräte und unzuverlässige Netze gemacht. Genau deshalb passt es für Smart-City-Telemetrie. Ein Gerät publisht auf ein Topic; Anwendungen abonnieren, ohne dass das Gerät sie kennen muss. Der Broker entkoppelt.

• Topic Design ist API-Design. city/{tenant}/{site}/{device}/telemetry ist nicht nur Naming. Es wird zum Vertrag.
• QoS bewusst wählen. QoS 0 reicht für häufige Umweltmessungen. QoS 1 passt für Statuswechsel, Alarme und operative Events, sofern du Duplikate idempotent behandelst.
• Retained Messages sind kein Verlauf. Sie sind gut für Last-known State, aber keine Time-Series DB.
• Der Broker besitzt nicht die Wahrheit. Registry, Kontextmodell und Storage besitzen Wahrheit. Der Broker transportiert Events.
• Unordnung einplanen. Nutze Device-Zeitstempel, Server-Receive-Zeit, Sequenznummern, Counter und monotone Validierung.

Der häufigste Fehler: MQTT wird gleichzeitig Broker, Datenbank, Integrationsplattform, Permissions Engine und Analytics-System. Es ist die Pipe. Eine gute Pipe, aber immer noch eine Pipe.

LoRaWAN und ChirpStack: wo sie hingehören

LoRaWAN ist für Städte attraktiv, weil die Physik passt: große Reichweite, wenig Strom, kleine Bandbreite, niedrige Gerätekosten und private Netze, wenn du Gateways selbst betreibst. Die LoRaWAN-Spezifikation beschreibt eine Star-of-Stars-Topologie: Gateways leiten Nachrichten von Endgeräten an einen zentralen Network Server weiter, der an Application Server routet.

ChirpStack ist der Open-Source-LoRaWAN-Network-Server, den wir zuerst evaluieren würden, wenn eine Stadt ein privates LoRaWAN-Netz kontrollieren will. Es liefert Gateway-, Device-, Tenant- und Integrationsmanagement plus gRPC API. Die Konfiguration zeigt die Betriebsrealität: PostgreSQL, Redis, MQTT Integration, Regionen, Device Classes, Deduplication Delay, Downlink Timing und Monitoring Endpoints.

Nimm ChirpStack, wenn du Kontrolle brauchst: eigene Gateways, eigene Mandantenstruktur, eigener Integrationspfad. Nimm Managed LoRaWAN, wenn niemand das Funknetz betreiben kann. Nimm NB-IoT oder LTE-M, wenn Carrier-Abdeckung, Mobilität oder mehr Durchsatz wichtiger sind und SIM-Lifecycle okay ist. Die Funkökonomie rechnen wir im LoRaWAN-vs-NB-IoT-vs-Sigfox-Kostenvergleich durch.

FIWARE, NGSI-LD und SensorThings: Interoperabilität statt Vendor-Dialekt

Smart-City-Systeme scheitern langsam, wenn jeder Vendor sein eigenes Datenmodell mitbringt. Ein Vendor nennt einen Parkplatz ein Device, der nächste ein Asset, der dritte speichert Belegung als occupied: true, der vierte als status: 1. Im ersten Jahr versteckt das Dashboard die Unterschiede. Im dritten Jahr will die Stadt Wiederverwendung, Open Data und abteilungsübergreifende Auswertung.

Die FIWARE Catalogue positioniert FIWARE rund um Context Data Management und eine gemeinsame NGSI API. NGSI-LD ist JSON-LD-basierte Interoperabilität für Föderationen und Datenräume. Die FIWARE-Tutorials bringen es pragmatisch auf den Punkt: NGSI-v2 für einfachere isolierte Systeme, NGSI-LD für Data Spaces und Systems of Systems.

OGC SensorThings passt besonders gut, wenn dein Kern Observations sind: Things, Sensors, Datastreams, Observed Properties, Features of Interest und Observations. Die OGC SensorThings API definiert sogar eine MQTT Extension für Observations und Updates. Wenn die Stadt stark GIS- und Messwert-getrieben arbeitet, ist SensorThings oft sehr sauber. Wenn du breiteren Kontext über Assets, Organisationen und Beziehungen modellierst, ist NGSI-LD/FIWARE meist passender.

Terraform und Kubernetes: nützlich, aber keine Magie

Terraform ist Infrastructure as Code für Cloud- und On-Prem-Ressourcen. In Smart-City-Projekten ist das wertvoll, weil Umgebungen lange leben, geprüft werden und oft mehrfach existieren. Nutze Terraform für Netzwerke, DNS, Datenbanken, Buckets, IAM, Cluster, Queues und Monitoring. Halte State remote, gelockt, verschlüsselt und aus Git; die HashiCorp-Dokumentation warnt selbst vor lokalem State und unsicherem State Storage.

Kubernetes ist ein Workload-Control-Plane. Es hilft bei vielen Services, Umgebungen, Autoscaling, GitOps und Teams, die Deployments, Probes, Resource Limits, Secrets, Network Policies und Recovery wirklich verstehen. Für einen 20-Geräte-Pilot kann Kubernetes Theater sein. Für eine Plattform mit mehreren Abteilungen und Dutzenden Services kann es genau richtig sein. Wenn diese Betriebserfahrung intern fehlt, ist ein Fractional-CTO-Review vor der Vergabe billiger als ein Rebuild nach dem Rollout.

Ansätze im Vergleich

Best Practices gegen teure Rebuilds

• Trenne Telemetrie, State und Command. Telemetrie ist Event Stream. State ist die letzte bekannte Sicht. Command ist Absicht mit Ack, Timeout, Autorisierung und Audit.
• Schreibe idempotent. LoRaWAN Deduplication, MQTT QoS 1, Retries und Cloud Rules erzeugen Duplikate. Plane sie ein.
• Versioniere Payloads und Codecs. Decoder sind Produktionscode. Speichere Firmware, Codec-Version, Device Profile und Einheitenannahmen mit.
• Plane späte und fehlende Daten ein. Feldnetze sind keine Büronetze. Analytics muss Lücken, Delay, Clock Drift und Backfills tolerieren.
• Nutze Geräteidentität sauber. LoRaWAN Keys, X.509-Zertifikate, SIM-Identitäten, API Keys und Dashboard-User sind verschiedene Identitäten.
• Bewahre Rohdaten für Replay auf. Wenn ein Decoder falsch war, ist Replay billiger als sechs Monate falsche Messwerte.
• Behandle Standortdaten als sensibel. Mobilität, Auslastung, Kameras und Belegung können kombiniert schnell personenbezogen oder politisch heikel werden.
• Schreibe den Exit-Plan vor dem Vertrag. Datenexport, API-Doku, Credential-Handover, Schema-Doku, Infra-Code und Firmware-Prozess gehören in die Vergabe.

Security und Governance

Smart-City-Systeme liegen nah an öffentlicher Infrastruktur. Sie brauchen keine Paranoia, sondern Disziplin: Least Privilege, Credential Rotation, Command Logs, Downlink Audits, getrennte Tenants, TLS, verschlüsselte Speicherung, Zertifikatsmonitoring, Restore-Tests und klare Regeln, wer Standort- und Belegungsdaten sehen darf. Nutze das NIST Cybersecurity Framework als gemeinsame Sprache für Govern, Identify, Protect, Detect, Respond und Recover. Dieselben Lücken sehen wir bei technischer Due Diligence: keine Owner, keine Runbooks, keine Datenverträge.

Für LoRaWAN respektierst du die Trennung zwischen Network- und Application Keys. Für MQTT nutzt du TLS, Geräte-Credentials, Topic-Autorisierung und Broker-Quotas. Für Kubernetes brauchst du Network Policies, Secret Management, Admission Policy, Image Provenance, Resource Limits und Observability. Für Terraform sicherst und lockst du State. Für Data Sharing definierst du Retention, Rechtsgrundlage, Aggregation und Open-Data-Verzögerung, bevor das Dashboard live geht.

Roadmap: von Pilot zu Plattform

Phase 1: kleinster glaubwürdiger Pilot

Ein Use Case, ein Bezirk oder Standort, eine Gerätefamilie, eine Erfolgsmetrik. Baue Ingestion, Registry, Decoding, Validierung, Storage und eine Operator-Sicht. Beweise Abdeckung, Batterie, Installation, Message Quality, Response-Prozess und Datennutzen. Behandle den Pilot wie ein Minimum Credible Product: klein im Scope, vollständig dort, wo ein Fehler den Test entwertet.

Phase 2: Produktionshärtung

Device Lifecycle, Firmware-Prozess, Monitoring, Alert Routing, Backups, Restore-Tests, Tenant-Grenzen, Payload Replay, Schema Registry und API-Doku. Entscheide jetzt, ob NGSI-LD, SensorThings oder ein internes Modell passt. Das ist der Schritt vom Proof of Concept zur production-ready Infrastruktur.

Phase 3: Interoperabilität

Stabile APIs, Datenverträge, Work-Order-Integration, Analytics, Open Data und KI-Use-Cases. Jetzt wird aus Sensorik wiederverwendbare City Data.

Quellen und Architektur-Hinweis

Smart-City-Stacks leben lange, aber Vendor-Produkte und Managed-Cloud-Features bewegen sich schnell. Behandle die Architekturprinzipien als stabil und Tool-Details als Momentaufnahme vom Juli 2026. Prüfe vor Vergabe oder Budgetfreigabe MQTT.org, die MQTT-Spezifikationsseite, die LoRaWAN-1.1-Spezifikation, ChirpStack, FIWARE, OGC SensorThings, Terraform, Terraform State, Kubernetes Object Management, AWS IoT Core Protocols, AWS IoT Rules und Azure IoT Hub Device Twins erneut.

"Die beste Smart-City-Architektur ist an jeder Schicht langweilig und an jeder Grenze explizit. Sensoren dürfen messy sein. Verträge nicht."