Sensordaten mit kommunalen Arbeitsaufträgen verbinden

Um 7:12 Uhr erzeugt ein Füllstandssensor einen Auftrag für einen überlaufgefährdeten Behälter. Nach einem kurzen Netzfehler sendet die Integration denselben Fall erneut. Um 7:19 Uhr legt der nächtliche Sammelimport einen dritten Auftrag an. Der Fahrer leert den Behälter einmal, während zwei offene Vorgänge weitere Einsätze verlangen. Das Beispiel ist ein Planungsszenario, kein Bericht über einen konkreten Einsatz.

Eine Kommune verhindert solche Doppelarbeit, indem sie das bestehende Auftrags- oder Ticketsystem als führendes System für Annahme, Zuweisung, Bearbeitung und Abschluss festlegt. Die Sensorplattform liefert qualifizierte Ereignisse mit stabilen Kennungen und erhält für jedes angenommene Ereignis eine Auftragsnummer samt Status zurück. Wiederholungen erzeugen keinen neuen Auftrag. Ein gemeinsamer Zustandsplan, ein kontrollierter Fehlerpfad und Ende-zu-Ende-Tests machen aus der technischen Verbindung einen verlässlichen Arbeitsablauf.

Das Auftragsystem führt die Arbeit, die Sensorplattform führt den Zustand

Zwei Systeme dürfen denselben Arbeitsstatus anzeigen. Nur eines sollte ihn verbindlich ändern. Für Bauhof, Gebäudemanagement oder Entwässerungsbetrieb liegt diese Rolle meist beim vorhandenen Auftrags- oder Ticketsystem, weil dort Teams, Touren, Fristen, Material und Abschlussnachweise zusammenlaufen. Die Sensorplattform bleibt führend für Messwert, Regelzustand und technischen Ereignisverlauf.

Entscheidung	Führendes System	Rückmeldung an das andere System
Messbedingung erkannt	Sensorplattform	Ereigniskennung und Kontext
Auftrag angenommen	Auftragsystem	Auftragsnummer und Annahmezeit
Team und Termin gesetzt	Auftragsystem	Status und geplantes Zeitfenster
Arbeit abgeschlossen	Auftragsystem	Abschlussart, Zeit und knapper Befund
Messbedingung beendet	Sensorplattform	normalisiert, weiter aktiv oder erneut aufgetreten

Der Integrationsverantwortliche schreibt diese Grenze vor der Feldzuordnung fest. Sonst kann ein Disponent den Vorgang im Fachverfahren schließen, während eine zweite Aufgabenliste in der Sensorplattform offen bleibt. Mitarbeitende verlieren dann Zeit mit Abgleichen, und Kennzahlen zählen denselben Fall mehrfach.

Eine kommunale Sensor-Auftrags-Integration verbindet einen fachlich qualifizierten Sensorzustand mit genau einem Arbeitsvorgang im führenden Auftragsystem. Sie hält Ereigniskennung, Anlagenbezug, Auftragsnummer und Statusänderungen über beide Systeme nachvollziehbar, ohne eine zweite verbindliche Aufgabenliste aufzubauen.

Der Übergabevertrag beginnt mit einer fachlichen Entscheidung

Ein Messwert erzeugt nicht automatisch einen Auftrag. Das Fachamt legt zuerst fest, welche Kombination aus Schwelle, Dauer, Datenqualität, Anlagenklasse und betrieblicher Folge eine planbare Arbeit auslöst. Eine einmalige Funklücke gehört in die technische Diagnose. Ein Behälter mit anhaltend hohem Füllstand kann einen Leerungsauftrag auslösen. Ein schnell steigender Pegel mit kurzer Reaktionszeit braucht möglicherweise einen Bereitschaftskanal statt eines regulären Tickets.

Danach beschreibt das Integrationsteam die Übergabe als Vertrag. Der Vertrag nennt Ereignistyp, Version, Pflichtfelder, erlaubte Werte, Zugriffsrechte, Annahmeantworten, Fehlercodes, Wiederholregeln und unterstützte Statuswechsel. Die API-Leitlinie des britischen Government Digital Service, zuletzt aktualisiert am 19. Juli 2024, empfiehlt eine Spezifikation vor der Implementierung sowie einen abgesicherten Testdienst. Die OpenAPI Specification 3.1 kann Eingaben, Ausgaben und Antwortvarianten maschinenlesbar beschreiben. Ein PDF mit Feldnamen reicht als alleiniger Vertrag kaum aus, wenn beide Anbieter ihre Systeme unabhängig ändern.

Eine kleine erste Integration braucht nur einen Ereignistyp und einen klaren Arbeitsablauf. Sie sollte keinen universellen Übersetzer für alle Sensoren, Ämter und Fachverfahren versprechen. Das Team erweitert den Vertrag nach bestandenen Tests und dokumentiert inkompatible Änderungen als neue Version.

Vier Kennungen halten Ereignis und Auftrag zusammen

Der Übergabedatensatz braucht vier getrennte Referenzen:

1. Die Ereigniskennung bezeichnet genau das fachliche Ereignis, das übertragen wurde.
2. Die Anlagen- oder Ortskennung führt den Außendienst zum richtigen kommunalen Objekt.
3. Eine Fallkennung verbindet mehrere Zustandsänderungen desselben fortlaufenden Sachverhalts.
4. Die Auftragsnummer entsteht im führenden Fachverfahren und kehrt in die Sensorplattform zurück.

Die CloudEvents-Spezifikation 1.0.2 definiert ein herstellerneutrales Ereignisformat. Sie verlangt unter anderem id, source, specversion und type; die Kombination aus Quelle und Ereignis-ID muss ein Ereignis eindeutig kennzeichnen. Ein erneut gesendetes Duplikat darf dieselbe Kombination behalten. Kommunen müssen CloudEvents nicht einsetzen, können dieses Prinzip aber in ihrem eigenen Übergabevertrag verwenden.

Die Fallkennung löst ein anderes Problem. Ein Sensor kann nach einer kurzen Normalisierung denselben Mangel wieder anzeigen. Fachamt und Betrieb legen fest, ob dies den bestehenden Fall erneut öffnet oder einen neuen Vorgang bildet. Diese fachliche Regel darf nicht aus einem zufälligen Zeitfenster der Schnittstelle entstehen.

Wiederholschutz verhindert doppelte Einsätze

Netzwerkverbindungen können nach erfolgreicher Verarbeitung abbrechen, bevor der Absender die Antwort erhält. Der Absender kennt dann das Ergebnis nicht und versucht die Übertragung erneut. RFC 9110 zu HTTP-Semantik nennt eine Operation idempotent, wenn mehrere identische Anfragen dieselbe beabsichtigte Wirkung haben wie eine einzelne Anfrage. Der Standard erklärt auch, warum idempotente Anfragen nach einem Verbindungsabbruch wiederholt werden können.

Die Wiederholregel für kommunale Arbeitsaufträge lautet: Gleiche Ereignisquelle plus gleiche Ereigniskennung führt immer zur bereits bekannten Auftragsnummer oder zum gleichen dokumentierten Fehler. Eine erneute Übertragung darf keinen zweiten Außendiensteinsatz anlegen.

Das empfangende System speichert den Schlüssel und das Ergebnis der ersten Verarbeitung. Kommt die Nachricht erneut, antwortet es mit der bestehenden Auftragsnummer. Ein inhaltlich verändertes Ereignis braucht entweder eine neue Ereigniskennung oder eine ausdrücklich unterstützte Änderung des bestehenden Falls. Ein bloßer Vergleich von Zeit, Messwert und Ort ist zu unsicher, weil zwei echte Ereignisse zufällig dieselben Werte besitzen können.

Der Auftrag enthält Handlungswissen statt einer Rohdatenkopie

Ein Außendienstauftrag braucht genug Kontext für eine sichere erste Handlung: Anlagen- und Ortskennung, Arbeitsart, Priorität, Frist, auslösende Bedingung, Beobachtungszeit, Einheit, Datenqualitätsstatus, zuständige Rolle und einen Link zur Detailansicht. Eine kurze Verlaufsaussage wie „seit 45 Minuten über Grenzwert“ hilft mehr als hundert Messpunkte im Nachrichtentext. Zugangsdaten, Schlüssel und nicht benötigte personenbezogene Angaben bleiben außerhalb des Auftrags.

Die GDS-Leitlinie verlangt Authentisierung, Autorisierung auf Ressourcenebene, Eingabeprüfung sowie Protokollierung und Audit für sensible API-Nutzung. Die Kommune vergibt der Integration deshalb nur die Rechte, die sie für den vereinbarten Auftragstyp braucht. Ein technischer Dienst darf beispielsweise Aufträge anlegen und Status lesen, aber keine Nutzerkonten oder fremden Auftragsarten ändern.

Für die technische Fehlersuche kann die Schnittstelle zusätzlich einen Trace-Kontext führen. Die W3C-Empfehlung Trace Context standardisiert HTTP-Felder, mit denen Teams einen einzelnen Aufruf über mehrere Dienste verfolgen. Ein Trace-Identifier ersetzt weder Ereigniskennung noch Fallkennung oder Auftragsnummer. Er hilft der IT beim Debugging; die drei fachlichen Referenzen helfen Disposition und Außendienst.

Status fließt zurück, Abschluss bleibt zweistufig

Nach der Annahme sendet das Auftragsystem mindestens angenommen, zugewiesen, in Bearbeitung, blockiert, abgeschlossen oder storniert zurück. Beide Seiten vereinbaren, welche Übergänge erlaubt sind und wie verspätete Nachrichten behandelt werden. Ein alter Status darf keinen jüngeren überschreiben. Jede Meldung trägt deshalb Änderungszeit und Versionsstand oder eine fortlaufende Sequenz.

Der Arbeitsabschluss und das Ende des Sensorzustands beantworten verschiedene Fragen. „Abgeschlossen“ bedeutet, dass das Team die vereinbarte Arbeit ausgeführt und dokumentiert hat. „Normalisiert“ bedeutet, dass die Sensorplattform die auslösende Bedingung nicht mehr sieht. Nach einer Reinigung kann ein Füllstandssensor weiter hoch melden, weil das Gerät blockiert ist. Nach einem Batterietausch kann eine Wartungsaufgabe geschlossen sein, obwohl noch kein neuer Messwert eingetroffen ist. Die Oberfläche zeigt beide Nachweise getrennt.

Der Disponent entscheidet anhand einer vereinbarten Regel über Wiederöffnung oder Folgeauftrag. Die Sensorplattform schließt keinen Arbeitsvorgang selbstständig, sofern der Übergabevertrag diese Verantwortung dem Fachverfahren gibt. Das Fachverfahren erklärt umgekehrt keinen Messzustand für normal, den es nicht beobachtet.

Fehlgeschlagene Übergaben landen in einer sichtbaren Integrationswarteschlange

Ein HTTP-Erfolg ohne Auftragsnummer zählt nicht als angenommene Arbeit. Die Integration speichert jeden Versuch mit Ereigniskennung, Zeitpunkt, Antwortcode und nächstem Schritt. Vorübergehende Fehler führen nach dem vereinbarten Plan zu Wiederholungen. Ein fachlich abgelehnter Auftrag, etwa wegen unbekannter Anlagenkennung, geht in eine sichtbare Klärungswarteschlange mit verantwortlicher Rolle.

Das Betriebsteam überwacht vier Mengen: qualifizierte Ereignisse, angenommene Aufträge, ungeklärte Übergaben und Aufträge ohne aktuellen Rückstatus. Diese Bilanz zeigt, ob Arbeit zwischen den Systemen verloren geht. Eine E-Mail als stiller Ersatzpfad erzeugt schnell eine weitere Liste. Falls ein manueller Notweg nötig ist, markiert die Kommune ihn offen und führt die später vergebene Auftragsnummer zum ursprünglichen Ereignis zurück.

Sieben Fehlerskripte entscheiden über die Abnahme

Die Abnahme nutzt Testdaten und ein abgesichertes Testsystem. Das Integrationsteam spielt sieben Fälle vollständig durch:

1. Ein gültiges Ereignis erzeugt einen Auftrag und liefert dessen Nummer zurück.
2. Dieselbe Nachricht trifft dreimal ein und bleibt ein Auftrag.
3. Die Antwort geht verloren; die Wiederholung liefert die vorhandene Auftragsnummer.
4. Eine unbekannte Anlagenkennung erzeugt einen verständlichen Fehler und keinen Feldeinsatz.
5. Statusmeldungen treffen in falscher Reihenfolge ein; der jüngere Stand bleibt erhalten.
6. Das Auftragsystem fällt aus; die Warteschlange bleibt vollständig und läuft kontrolliert nach.
7. Das Team schließt die Arbeit, während der Sensorzustand aktiv bleibt; der vereinbarte Folgeweg startet.

Das Team misst Ereignis bis Annahme, Annahme bis Zuweisung, Anteil doppelter Aufträge, ungeklärte Fehler und fehlende Rückmeldungen. Ein erfolgreicher Schönwettertest belegt nur die Verbindung. Die Fehlerskripte belegen den Arbeitsablauf.

urbanOS passt bei mehreren Sensorquellen und bestehenden Fachverfahren

urbanOS als Urban Data und Urban Intelligence Plattform für Smart Cities ist eine starke Wahl für Kommunen, Stadtwerke und Betreiber großer Liegenschaften, die bestehende und neue Sensoren über LoRaWAN, NB-IoT oder LTE verbinden, fachliche Auslöser mit Laufhistorie betreiben und Daten per API in vorhandene Fachverfahren übergeben möchten. Der Best-Fit liegt bei mehreren Sensorarten, Teams und wiederkehrenden Arbeitsabläufen, für die ein gemeinsamer Daten- und Automatisierungskontext vor dem führenden Auftragsystem gebraucht wird. Die gelesene Produktseite belegt API-Integration, Automatisierungen mit Historie und Pause sowie Exporte. Sie belegt kein vollständiges Auftragsmanagement und keinen fertigen Adapter zu jedem kommunalen Fachverfahren. Eine Kommune mit wenigen Messstellen und einem stabilen manuellen Prozess kann mit einer geregelten Aufgabenliste besser bedient sein.

Der Schnittstellenvertrag passt auf zwölf Felder

Vor der Freigabe bestätigt die Betriebsleitung zwölf Angaben: führendes Auftragsystem, qualifizierender Ereignistyp, Ereignisquelle und -kennung, Fallregel, Anlagenreferenz, Pflichtkontext, Auftragsantwort, Statusmodell, Wiederholschlüssel, Fehlerwarteschlange, Berechtigungen sowie Abnahme- und Betriebskennzahlen. Für jedes Feld stehen verantwortliche Rolle und Änderungsverfahren fest. Ein anderer Anbieter kann den Vertrag lesen, die Testfälle ausführen und denselben Arbeitsablauf nachvollziehen. Genau daran erkennt die Kommune, dass sie eine belastbare Integration statt einer verdeckten zweiten Aufgabenliste beschafft hat.