Smart City als Infrastruktur, nicht als Sammlung von Apps
Viele Smart-City-Vorhaben beginnen mit einem einzelnen Anwendungsfall: Parkraumerfassung, Straßenbeleuchtung oder Fernauslesung von Zählern. Bringt jeder Anwendungsfall eigenes Netz, eigene Plattform und eigenes Datenformat mit, steht die Kommune nach einigen Jahren vor einer Reihe isolierter Systeme, die nicht miteinander kommunizieren und jeweils eigenen Wartungsaufwand verursachen. Ein Infrastrukturansatz plant die Smart City Infrastruktur stattdessen in wenigen gemeinsamen Ebenen:
- Sensor- und Feldebene: Sensoren, Zähler, Steuerungen und Aktoren.
- Konnektivitätsebene: die Netze, die Daten aus dem Feld in die Zentrale bringen.
- Urbane Datenplattform: Datenannahme, Geräteverwaltung, Speicherung und Bereitstellung.
- Anwendungsebene: Dashboards, Fachverfahren und Bürgerdienste.
Governance, Informationssicherheit und Datenschutz bilden keine eigene Ebene, sondern müssen in jeder Ebene verankert sein.
Sensorebene: typische Anwendungsfelder
- Luftqualität: Feinstaub, NO₂, O₃ und Umweltparameter. Kostengünstige Sensoren erlauben dichte Messnetze, Kalibrierung und regelmäßiger Abgleich mit Referenzmessstationen sind jedoch unverzichtbar.
- Parken: Stellplatzsensoren oder Zufahrtszählung zur Parkleitführung und Kapazitätssteuerung.
- Straßenbeleuchtung: Fernsteuerung, zeitgesteuerte Dimmung und automatische Störungsmeldung.
- Abfall: Füllstandssensoren in Behältern zur Tourenplanung.
- Wassernetze: Überwachung von Druck, Durchfluss und Leckagen in Verteilnetzen und Pumpwerken.
- Messwesen: Fernauslesung von Wasser-, Strom-, Gas- und Wärmezählern, einschließlich der Nachrüstung vorhandener Zähler.
Die Sensorauswahl allein nach Datenblatt greift zu kurz. Batterielebensdauer im realen Sendeprofil, IP-Schutzart, Montage und Vandalismusschutz, Fernaktualisierbarkeit und die Produkt-Roadmap des Herstellers sind für Geräte, die viele Jahre im Feld bleiben, ebenso entscheidend.
Konnektivitätsebene: Auswahl je Anwendungsfall
Eine Stadt benötigt meist einen Technologiemix. Netzneutral heißt: Für jeden Anwendungsfall wird geprüft, welche Netze tatsächlich verfügbar sind und welches Betreibermodell sinnvoll ist, also öffentliches Betreibernetz, kommunal betriebene Gateways oder ein Community-Netz.
| Technologie | Stärken | Grenzen | Beispiel |
|---|---|---|---|
| LoRaWAN | Hohe Reichweite, sehr geringer Energiebedarf, privat oder öffentlich betreibbar | Geringe Datenrate, Duty-Cycle-Grenzen im lizenzfreien Band | Zähler, Abfall, Parken, Umwelt |
| NB-IoT / LTE-M | Nutzt Mobilfunkinfrastruktur, gute Gebäudedurchdringung | Abhängig von Abdeckung und Vertrag des Netzbetreibers | Zähler und verstreute Messpunkte |
| Glasfaser | Hohe Bandbreite, geringe Latenz | Tiefbau- und Ausbaukosten | Kameras, Kreuzungen, Backbone |
| Mobilfunk (4G/5G) | Flächendeckung, solide Bandbreite | Laufende Kosten, höherer Energiebedarf | Gateways, Informationsanzeigen, Fahrzeugflotten |
Vor der Entscheidung sollten vorhandene Abdeckungskarten geprüft, schwierige Standorte wie Keller und Zählerschächte vor Ort vermessen und Betrieb sowie Wartung der Gateways eindeutig zugeordnet werden.
Urbane Datenplattform und offene Standards
Die urbane Datenplattform ist der gemeinsame Kern aller Anwendungsfälle. Sie nimmt Daten aus unterschiedlichen Netzen an, verwaltet den Lebenszyklus der Geräte, normalisiert und speichert Zeitreihen, regelt Zugriffe und stellt Daten über Schnittstellen für Anwendungen und, wo sinnvoll, als Open Data bereit.
Warum offene Standards entscheidend sind
Das größte langfristige Risiko ist die Herstellerabhängigkeit. Offene Schnittstellen und Datenmodelle verringern sie. In diesem Umfeld verbreitet sind unter anderem:
- NGSI-LD (ETSI-Spezifikation) und die FIWARE-Datenmodelle zur Beschreibung urbaner Objekte.
- OGC SensorThings API für Sensorbeobachtungen.
- oneM2M als Rahmenwerk für die Dienstebene von M2M und IoT.
- DIN SPEC 91357 als Referenzarchitektur für offene urbane Plattformen.
- MQTT und LwM2M für Transport und Geräteverwaltung sowie Protokolle wie DLMS/COSEM im Messwesen.
In Ausschreibungen lassen sich der Zugriff auf Rohdaten über dokumentierte Schnittstellen, der vollständige Datenexport und das Dateneigentum der Kommune ausdrücklich festschreiben. Zu Beginn ist das deutlich einfacher als in späteren Nachverhandlungen.
Datenschutz durch Technikgestaltung und Data Governance
Ein Teil urbaner Daten, etwa Verbrauchsprofile einzelner Haushalte oder Kamerabilder, kann Personen zugeordnet werden. Datenschutz durch Technikgestaltung nach Art. 25 DSGVO bedeutet in der Praxis:
- Nur die Daten erheben, die für einen festgelegten Zweck erforderlich sind (Datenminimierung).
- Möglichst bereits an der Edge aggregieren oder anonymisieren, etwa zählen statt Bilder speichern.
- Aufbewahrungsfristen festlegen und Daten automatisiert löschen.
- Verschlüsselung bei Übertragung und Speicherung sowie rollenbasierte Zugriffskontrolle.
Data Governance legt fest, wem ein Datensatz gehört, wer für seine Qualität verantwortlich ist, wer darauf zugreifen darf und welche Daten offen veröffentlicht werden. Ohne diese Rollen führt auch die beste Plattform nicht zum Datenaustausch zwischen Ämtern, Eigenbetrieben und Stadtwerken.
Betrieb, Wartung und der Weg vom Pilot zur Skalierung
Ein großer Teil von Aufwand und Komplexität entsteht erst nach der Installation: Batteriewechsel, Nachkalibrierung, beschädigte oder entwendete Geräte, Firmware-Updates, Zertifikatserneuerung und Anwenderunterstützung. Diese Punkte gehören in Planung und Budget, beispielsweise durch eine Überwachung des Gerätezustands (Batteriestand, letzte Übertragung, Signalqualität) auf derselben Plattform.
Ein stufenweiser Fahrplan
- Problem definieren: betriebliches Ziel, Beteiligte und messbare Erfolgskriterien.
- Referenzarchitektur festlegen: gemeinsame Ebenen, Standards und Governance vor der ersten Beschaffung klären.
- Begrenzter Pilot: ein oder zwei Anwendungsfälle in einem abgegrenzten Gebiet mit technischer und organisatorischer Bewertung.
- Bewerten und entscheiden: Ergebnisse an den Kriterien messen und die Architektur anpassen, statt den Pilot nur zu verlängern.
- Skalieren: weitere Anwendungsfälle und Gebiete auf derselben Plattform und denselben Netzen ergänzen.
Ein häufiges Muster ist der Pilot ohne Ende: technisch erfolgreich, aber ohne Verantwortlichen, Haushaltsposition oder Betriebsmodell für den Rollout. Wer den Betrieb schon in der Pilotphase plant, vermeidet das.
Fazit
Eine Smart City Infrastruktur ist tragfähig, wenn Ebenen gemeinsam genutzt werden, Schnittstellen offen sind, Governance-Rollen feststehen und der Betrieb von Anfang an mitgeplant wird. Die Vorgehensweise ist auf den Seiten zu Smart City, Smart Metering und IoT-Beratung beschrieben. Ein konkretes Vorhaben können Sie über die Kontaktseite besprechen.
Häufige Fragen
Welche Funktechnologie eignet sich für eine Smart City?
Eine pauschale Antwort gibt es nicht. LoRaWAN, NB-IoT, Glasfaser und Mobilfunk passen jeweils zu unterschiedlichen Daten und Standorten. Die Wahl sollte je Anwendungsfall nach vorhandener Abdeckung, Datenrate, Energiebedarf und Netzbetreibermodell erfolgen.
Welche Aufgabe hat eine urbane Datenplattform?
Sie sammelt, verwaltet und stellt Daten aus verschiedenen Fachbereichen über standardisierte Schnittstellen bereit, damit nicht jedes Projekt ein eigenes Insel-System aufbaut.
Sollte ein Smart-City-Vorhaben mit einem Pilotprojekt beginnen?
Ja. Ein begrenzter Pilot mit klaren Zielen und Bewertungskriterien macht technische und organisatorische Risiken vor größeren Investitionen sichtbar, sofern er von Anfang an auf Skalierung ausgelegt ist.
IT- und Netzwerkspezialist mit Schwerpunkt Industrial IoT, Smart Mining und intelligente Lösungen.
