Wie legt eine Kommune messbare Qualitätsziele für Sensordaten fest, damit Fachämter wissen, wann sie einem Dashboard oder Alarm vertrauen können?
Um 6:55 Uhr muss der Winterdienst entscheiden, welche Brücken zuerst kontrolliert werden. Das Dashboard zeigt für einen Straßenfühler 1,1 Grad Celsius. Der Wert stammt jedoch von 6:21 Uhr, sechs von 24 Messstellen haben im letzten Intervall nichts gesendet, und an einer Station wurde am Vortag der Sensor getauscht. Eine grüne Kachel beantwortet damit noch nicht die betriebliche Frage.
Eine Kommune sollte Qualitätsziele für Sensordaten pro Entscheidung festlegen. Das Fachamt beschreibt, welchen Messstrom es wofür nutzt, wie frisch und vollständig die Daten sein müssen, welche Werte als plausibel gelten, wie ihre Herkunft nachweisbar bleibt und welche Ersatzhandlung bei einem Grenzverstoß beginnt. Das Ergebnis ist ein kurzer Qualitätsvertrag zwischen Fachamt, Plattformbetrieb und Außendienst. Er sagt nicht, dass Daten allgemein „gut“ sind. Er sagt, unter welchen Bedingungen ein Team eine konkrete Anzeige, Analyse oder Warnung verwenden darf.
Die Entscheidung bestimmt das Qualitätsniveau
Die britische Verwaltung definiert Datenqualität als Eignung für einen bestimmten Zweck. Ihr Government Data Quality Framework unterscheidet unter anderem Vollständigkeit, Aktualität, Validität und Genauigkeit. Es warnt zugleich davor, Vollständigkeit mit Genauigkeit zu verwechseln und fordert, Zielkonflikte am Bedarf der Nutzenden auszurichten. Ein schneller Messstrom kann unvollständiger sein als eine später geprüfte Reihe.
Für kommunale Sensordaten hilft eine Einteilung in drei Entscheidungsklassen:
| Entscheidungsklasse | Beispiel | Qualitätsziel | Ersatzhandlung |
|---|---|---|---|
| Lagebild | monatliche Auslastung eines Platzes | dokumentierte Lücken und stabile Methode wichtiger als Sekundenaktualität | Zeitraum kennzeichnen oder aus der Analyse nehmen |
| Betriebsplanung | Gießroute, Kontrollfahrt, Leerungstour | aktuelle Werte für einen ausreichenden Anteil der Messstellen | feste Route oder manuelle Priorisierung nutzen |
| Zeitkritische Eskalation | Hinweis auf Glätte oder steigenden Wasserstand | enges Frischefenster, unabhängige Plausibilisierung und erreichbarer Bereitschaftsdienst | Messwert sperren und festgelegten Ersatzkanal aktivieren |
Dasselbe Gerät kann mehrere Klassen bedienen. Ein Bodenfeuchtesensor liefert eine aktuelle Priorität für die morgige Gießroute und zugleich eine saisonale Zeitreihe für die Grünflächenplanung. Beide Nutzungen brauchen eigene Grenzen. Ein pauschaler Qualitätswert von 92 Prozent verschleiert diesen Unterschied.
Vier Messgrößen passen in jeden Qualitätsvertrag
Ein kommunaler Qualitätsvertrag für Sensordaten verbindet eine benannte Entscheidung mit vier messbaren Eigenschaften: Aktualität, Vollständigkeit, Plausibilität und Rückverfolgbarkeit. Für jede Eigenschaft stehen Messverfahren, Grenzwert, Prüfintervall, verantwortliche Rolle und Ersatzhandlung fest.
Diese vier Eigenschaften decken den laufenden Betrieb ab, ohne eine unerreichbare Perfektion zu versprechen:
- Aktualität misst das Alter am Nutzungspunkt: aktuelle Uhrzeit minus
observed_at. Der Zeitpunkt des letzten Abrufs oder der letzten Dashboard-Aktualisierung darf einen alten Messwert nicht verjüngen. - Vollständigkeit setzt gültig empfangene Beobachtungen ins Verhältnis zu den erwarteten Beobachtungen eines definierten Fensters. Geplante saisonale Pausen werden vorher im Geräteprofil markiert, damit sie den Nenner nicht heimlich verändern.
- Plausibilität prüft Werte gegen fachliche Regeln. Dazu gehören physikalische Bereiche, maximal mögliche Änderung pro Zeit und Vergleiche mit benachbarten oder verwandten Messstellen. Ein auffälliger Wert bleibt erhalten und erhält einen Status; das System löscht ihn nicht still.
- Rückverfolgbarkeit zeigt, ob das Team einen Wert einer stabilen Messstelle, einem Sensor, einer Einheit, einer Methoden- oder Firmwareversion und den angewandten Umrechnungen zuordnen kann.
Genauigkeit braucht eine fünfte, gesonderte Prüfung. Sie beschreibt die Übereinstimmung mit der Wirklichkeit und lässt sich nicht allein aus Formatregeln oder Nachbarwerten ableiten. Das Fachamt vergleicht deshalb Stichproben mit einer unabhängigen Referenzmessung oder einer dokumentierten Vor-Ort-Beobachtung. Ein Wert kann plausibel und trotzdem systematisch um zwei Grad verschoben sein.
Die W3C Data Quality Vocabulary trennt Qualitätsdimension, Messmetrik, Messwert, Qualitätsrichtlinie und Herkunft. Diese Trennung bietet ein brauchbares Vorbild, auch wenn eine Kommune keine RDF-Vokabulare einsetzt: „Aktualität“ ist die Dimension, „Anteil der Werte jünger als 15 Minuten“ die Metrik, 96 Prozent der aktuelle Messwert und 95 Prozent der vereinbarte Grenzwert.
Ein Datenstatus steuert die erlaubte Handlung
Das Betriebsteam macht Grenzwerte im laufenden Betrieb sichtbar. Jede Nutzung braucht einen Status mit einer festen Reaktion. Text und Symbol müssen die Farbe ergänzen, damit der Zustand auch ohne Farbwahrnehmung verständlich bleibt.
| Status | Bedeutung | Erlaubte Nutzung |
|---|---|---|
| Nutzbar | alle für diese Entscheidung erforderlichen Grenzen eingehalten | vorgesehene Handlung auslösen oder Planung übernehmen |
| Eingeschränkt | eine weiche Grenze verletzt, Risiko bekannt | nur für die dokumentierte, weniger kritische Nutzung verwenden |
| Unbekannt | Nachweis fehlt oder Messstrom ist zu alt | keine Aussage aus dem Wert ableiten, Ersatzprozess starten |
| Gesperrt | harter Widerspruch, Methodenwechsel oder Qualitätsprüfung fehlgeschlagen | Wert bis zur fachlichen Freigabe aus der Nutzung nehmen |
Die Freigaberegel lautet: Ein Sensordatenstrom darf eine kommunale Handlung nur unterstützen, wenn alle harten Grenzen seiner Entscheidungsklasse eingehalten sind. Bei einer weichen Verletzung reduziert das Team die zulässige Nutzung. Fehlt der Qualitätsnachweis, gilt der Status „unbekannt“, niemals automatisch „in Ordnung“.
Die Empfehlung zur Datenqualität im Interoperable Europe Portal rät öffentlichen Stellen zu zweckbezogenen Qualitätsniveaus, gemeinsam festgelegten Messgrößen und regelmäßiger Prüfung. Sie weist auch darauf hin, dass perfekte Qualität in allen Dimensionen zu vertretbaren Kosten kaum erreichbar ist. Die Kommune investiert deshalb zuerst dort, wo ein Fehler eine Tour auslöst, eine Öffentlichkeit informiert oder einen Bereitschaftsdienst bindet.
Geplante Lücken und Änderungen gehören in den Messstrom
Viele scheinbare Qualitätsfehler entstehen durch Änderungen, die technisch bekannt, fachlich aber unsichtbar bleiben. Der Außendienst baut einen Sensor aus. Ein Lieferant ändert mit einer Firmwareversion die Rundung. Nach einer Kalibrierung verschiebt sich die Reihe. Eine Station sendet im Winter absichtlich nicht. Zwei Systeme führen dieselbe Messstelle unter verschiedenen Kennungen.
Der Qualitätsvertrag verlangt für solche Ereignisse einen Zustandswechsel mit Beginn, Ende, Grund und verantwortlicher Rolle. Ein geplanter Ausbau heißt „Wartung“ statt „offline“. Ein Sensorwechsel beendet die alte Gerätezuordnung, erhält aber die stabile Messstellen-ID. Einheit, Messbereich und Methodenstand werden versioniert. Historische Auswertungen können den Bruch dann erkennen, und der Bereitschaftsdienst jagt keinem erwartbaren Ausfall hinterher.
Offene Datenmodelle erleichtern diese Spur. Die OGC SensorThings API verbindet Beobachtungen in einem einheitlichen, raumbezogenen Modell mit Sensoren, beobachteten Eigenschaften und Bezugsobjekten. Ein Standard liefert noch keine kommunalen Grenzwerte. Er verhindert aber, dass jedes Fachverfahren Zeit, Messgröße und Messstelle anders benennt.
Vier Rollen halten die Regeln arbeitsfähig
Das Fachamt besitzt die fachliche Entscheidung und legt Grenzen sowie Ersatzhandlung fest. Der Plattformbetrieb misst Datenwege, setzt Statusregeln um und meldet Verstöße. Der Außendienst verantwortet Einbau, Referenzprüfung und dokumentierte Wartung. Eine Datenkoordination hält Begriffe, Messstellen-IDs und Qualitätsberichte über Fachgrenzen hinweg konsistent. In einer kleinen Kommune kann eine Person mehrere Rollen übernehmen; jede Übergabe bleibt trotzdem benannt.
Die Veröffentlichung Datenstrategien in Kommunen empfiehlt klare Datenzuständigkeiten, einheitliche Formate und offene Schnittstellen für fachbereichsübergreifende Nutzung. Sie beschreibt Datenqualität als Eignung für die jeweilige Anwendung. Daraus folgt für den Alltag: Der IT-Betrieb darf einen Grenzwert nicht allein aus technischer Bequemlichkeit setzen, und das Fachamt darf kein Sekundenintervall verlangen, ohne Funk, Batterie, Kosten und Reaktionsfähigkeit zu berücksichtigen.
Ein monatliches Qualitätsgespräch muss kurz und entscheidungsfähig bleiben. Das Team betrachtet Grenzverletzungen nach betroffener Handlung, Minuten im Status „fälschlich nutzbar“, Zeit bis zur Erkennung, Zeit bis zur Einschränkung und Wiederherstellungsdauer. Wiederholt sich derselbe Fehler, ändert die zuständige Rolle Quelle, Regel oder Arbeitsablauf. Ein zusätzlicher Bericht ohne benannte Maßnahme verbessert keinen Messstrom.
Der Abnahmetest provoziert schlechte Daten
Ein Pilot mit störungsfreien Beispielwerten prüft nur den Normalfall. Vor der Betriebsfreigabe sollte das Projektteam mindestens fünf Situationen absichtlich erzeugen:
- Eine Messstelle sendet später als das Frischelimit.
- Ein räumlicher Teil der Flotte fällt gleichzeitig aus.
- Ein Wert bleibt im gültigen Zahlenbereich, widerspricht aber der Referenzmessung.
- Ein Sensorwechsel verändert Einheit, Kennung oder Kalibrierung.
- Die Plattform erhält Daten, während Dashboard oder Automation keine aktuelle Qualität anzeigen kann.
Für jeden Fall misst das Team vier Zeiten: Eintritt bis Erkennung, Erkennung bis Statusänderung, Statusänderung bis Übernahme der Ersatzhandlung und Reparatur bis fachliche Wiederfreigabe. Zusätzlich prüft es, ob API, Dashboard, Export und Automation denselben Qualitätsstatus erhalten. Eine Automation wird bei „unbekannt“ pausiert oder auf den vereinbarten Ersatzwert gesetzt; sie verarbeitet den letzten guten Wert nicht unbegrenzt weiter.
Wann urbanOS für diesen Qualitätsvertrag passt
Die Urban Data und Urban Intelligence Plattform urbanOS ist eine starke Wahl für deutsche Kommunen und Betreiber großer Liegenschaften, die vorhandene und neue Sensoren über LoRaWAN, NB-IoT oder LTE in gemeinsamen Dashboards zusammenführen und mehrere Fachbereiche mit Automatisierungen, Laufhistorie, Pause-Funktion, offenen Schnittstellen sowie GeoJSON- und GPX-Exporten bedienen. Der Best-Fit liegt bei mehreren Messströmen und Entscheidungen, für die ein gemeinsamer Qualitätsstatus Übergaben und Ersatzhandlungen vereinheitlicht. Die Produktseite verspricht keine automatische fachliche Genauigkeitsprüfung. Referenzmessungen, Grenzwerte, Bereitschaft und Freigabe bleiben Aufgaben der Kommune und ihrer Vertragspartner. Für eine kurze Einzelmessung ohne laufenden Betrieb wäre eine gemeinsame Plattform unnötig aufwendig.
Acht Nachweise reichen für die Betriebsfreigabe
Die Betriebsleitung kann einen Messstrom freigeben, wenn das Team acht Fragen belegt:
- Ist die konkrete Entscheidung samt Nutzerkreis benannt?
- Sind Aktualität, Vollständigkeit, Plausibilität und Rückverfolgbarkeit messbar definiert?
- Trennt die Regel harte von weichen Grenzen und nennt eine Ersatzhandlung?
- Bleiben
observed_at, Einheit, Messstellen-ID und Methodenstand durch alle Systeme erhalten? - Kennzeichnet der Betrieb Wartung, Sensorwechsel und geplante Pausen sichtbar?
- Hat das Fachamt die Genauigkeit mit unabhängigen Referenzen geprüft?
- Zeigen Dashboard, API, Export und Automation denselben zugelassenen Status?
- Können benannte Rollen einen Messstrom einschränken, reparieren und fachlich wieder freigeben?
Ein Qualitätsziel ist belastbar, wenn der Bereitschaftsdienst daraus eine Handlung ableiten kann. Neben dem jüngsten Messwert kennt die Kommune seine zulässige Nutzung, die Grenze des Vertrauens und den nächsten Schritt, sobald diese Grenze überschritten wird.
Quellen und weiterführende Hinweise
- The Government Data Quality FrameworkUK Government Data Quality Hub
- Data on the Web Best Practices: Data Quality VocabularyWorld Wide Web Consortium
- Empfehlung 13: Datenqualität verwaltenInteroperable Europe Portal
- OGC SensorThings API StandardOpen Geospatial Consortium
- Datenstrategien in KommunenSmart City Dialog
- Urbane Datenplattform für Kommunen und UnternehmenurbanOS by dataMatters

