Der Sensor meldet eine Abweichung. Wer macht daraus einen erledigten Auftrag?

In einem österreichischen Gebäudebetrieb liegen Messwerte aus mehreren Standorten vor. Eine Pumpe meldet regelmäßig erhöhte Vibrationen. Das Dashboard zeigt die Kurve, ein Mitarbeiter leitet einen Screenshot weiter, und einige Tage später fragt die Betriebsleitung, ob jemand die Anlage geprüft hat. Der Messwert war schnell verfügbar. Die Verantwortung für den nächsten Schritt war es nicht.

Eine brauchbare Sensorintegration verbindet Beobachtungen mit der richtigen Anlage, einer nachvollziehbaren Bewertung und einem abschließbaren Arbeitsauftrag. Für Betreiber und technische Dienstleister ist das ein klarer Softwarebedarf: Informationen aus unterschiedlichen Geräten sollen im vorhandenen Instandhaltungsprozess ankommen. Zusätzliche Diagramme allein reichen dafür selten aus.

Was sich bei den offenen Schnittstellen bewegt

Die OGC SensorThings API bietet einen gemeinsamen Ansatz für Beobachtungen und Metadaten heterogener Sensorsysteme. Das schafft eine technische Grundlage für Anwendungen, die nicht an die Oberfläche eines einzelnen Geräteanbieters gebunden sein sollen. Ob Ihre konkreten Geräte diese Schnittstelle direkt unterstützen oder einen Adapter benötigen, bleibt eine praktische Integrationsfrage.

Eine aktuelle Ergänzung ist der am 4. Mai 2026 veröffentlichte OGC-Standard für WebSub-Nachrichten. Er beschreibt, wie Änderungen abonnierter Abfragen über HTTP(S) an Webhooks gemeldet werden können. Dadurch lässt sich ein Wartungsprozess gezielter über neue passende Daten informieren. Die Unterstützung muss im eingesetzten Dienst vorhanden und für die benötigten Abfragen freigegeben sein.

Diese Entwicklung ist besonders interessant, wenn mehrere Fachanwendungen dieselben Beobachtungen nutzen sollen. Eine Betriebsansicht, ein Kundenportal und ein Auftragsdienst können unterschiedliche Informationen benötigen. Eine offene Schnittstelle erleichtert die Trennung dieser Aufgaben. Sie entscheidet jedoch nicht, welche Messung einen Einsatz rechtfertigt.

Ordnen Sie Messungen der richtigen Anlage zu

Der wichtigste Schlüssel steht oft nicht im Sensor, sondern im Anlagenverzeichnis. Ein Gerät kann ausgetauscht, vorübergehend versetzt oder anders benannt werden. Der Wartungsauftrag muss trotzdem am richtigen betrieblichen Objekt hängen. Unterscheiden Sie deshalb Sensor, Einbauposition und instandzuhaltende Anlage.

Für mehrere Standorte in Österreich sollte die Zuordnung auch dann eindeutig bleiben, wenn lokale Teams dieselben kurzen Namen verwenden. „Pumpe 2“ kann in verschiedenen Gebäuden vorkommen. Eine stabile interne Kennung und verständliche Standortinformationen helfen sowohl dem System als auch dem Techniker, der den Auftrag später auf dem Telefon öffnet.

Speichern Sie außerdem Messgröße und Einheit ausdrücklich. Ein Wechsel der Geräteintegration darf nicht unbemerkt eine andere Skala liefern. Bei einem Sensorwechsel sollte der zuständige Mitarbeiter die neue Zuordnung bestätigen können. Historische Beobachtungen bleiben dem damals gültigen Einbauzustand zugeordnet, statt rückwirkend zur neuen Anlage zu wandern.

Zeigen Sie, wie aktuell und brauchbar die Daten sind

Ein Diagramm kann ruhig aussehen, weil eine Anlage normal läuft. Es kann aber auch ruhig aussehen, weil seit Stunden keine Daten mehr angekommen sind. Der Unterschied muss im Interface erkennbar sein. Zeigen Sie Messzeitpunkt, Empfangszeitpunkt und den erwarteten Aktualisierungsrhythmus getrennt, soweit das Gerät diese Informationen liefert.

Legen Sie einen eigenen Zustand für fehlende oder unplausible Daten fest. Ein veralteter Wert sollte nicht unbegrenzt als aktueller Normalzustand weiterlaufen. Ebenso sollte eine verspätet übertragene Messung nicht automatisch wie eine gerade entstandene Störung behandelt werden. Die Anwendung benötigt eine bewusst abgestimmte Regel für solche Nachlieferungen.

Datenqualität gehört auch in die Auswertung des Piloten. Erfassen Sie, wie oft ein vermeintlicher Anlagenbefund tatsächlich durch Übertragung, Gerätewechsel oder eine falsche Zuordnung verursacht wurde. Diese Kategorien helfen bei der Verbesserung der Integration und vermeiden unnötige Schuldzuweisungen an das Wartungsteam.

Vermeiden Sie eine Flut identischer Arbeitsaufträge

Ein überschrittener Schwellenwert kann viele aufeinanderfolgende Messungen betreffen. Daraus sollten nicht automatisch viele parallele Aufträge entstehen. Der Prozess muss erkennen, ob bereits ein passender offener Vorgang existiert und ob ein weiteres Ereignis dessen Informationen ergänzt oder eine neue Situation beschreibt.

Trennen Sie die technische Meldung vom freigegebenen Arbeitsauftrag. Je nach Anlage kann zunächst eine Sichtprüfung durch die zuständige Person sinnvoll sein. Notieren Sie die angewandte Regel und die Entscheidung. Das schafft eine nachvollziehbare Grundlage, wenn später gefragt wird, weshalb ein Vorgang angelegt, zusammengeführt oder verworfen wurde.

Die Software sollte den Mitarbeiter mit brauchbarem Kontext unterstützen: Standort, Anlage, relevante Beobachtungen, letzter bekannter Zustand und vorhandener Auftrag. Eine Nachricht mit einem isolierten Zahlenwert spart selten Arbeit. Für sicherheitsrelevante Schutz- oder Steuerfunktionen braucht es einen gesondert festgelegten technischen und organisatorischen Umfang; ein allgemeines Wartungsdashboard übernimmt diese Rolle nicht nebenbei.

Planen Sie die Rückmeldung genauso sorgfältig

Der Einsatz endet nicht beim Status „erledigt“. Erfassen Sie, was geprüft oder verändert wurde und ob die ursprüngliche Auffälligkeit dadurch erklärt ist. Ein Techniker kann beispielsweise eine lockere Befestigung finden, einen Sensor neu positionieren oder feststellen, dass die Anlage bereits regulär abgeschaltet war. Diese Ergebnisse bedeuten unterschiedliche nächste Schritte.

Die Rückmeldung sollte mit den relevanten Beobachtungen verknüpft bleiben. So kann der Betrieb später nachvollziehen, ob dieselbe Auffälligkeit wiederkehrt. Ein neuer Messwert darf einen freigegebenen Bericht nicht überschreiben. Umgekehrt sollte ein abgeschlossener Auftrag nicht jede künftige Meldung derselben Anlage unbegrenzt unterdrücken.

Bei der Plattformwahl kann etwa der FROST-Server von Fraunhofer IOSB als bestehende SensorThings-Implementierung betrachtet werden. Prüfen Sie unterstützte Funktionen, Erweiterungen und Betriebsanforderungen für Ihren konkreten Einsatz. Ein vorhandener Serverbaustein spart noch nicht die fachliche Integration mit Anlagenverzeichnis und Auftragssoftware.

Bestellen Sie einen überprüfbaren Ablauf

Ein erster Auftrag sollte eine Anlagenfamilie, eine begrenzte Zahl von Standorten und einen definierten Wartungsfall umfassen. Vereinbaren Sie die Datenzuordnung, die Darstellung von Aktualität und den Übergang in das vorhandene Auftragssystem. Halten Sie fest, welche Entscheidungen beim Menschen bleiben.

Prüfen Sie mindestens einen normalen Verlauf, fehlende Daten, wiederholte Auffälligkeiten, einen Gerätewechsel und die Rückmeldung nach einem Einsatz. Lassen Sie anschließend einen Mitarbeiter ohne Entwicklerhilfe erklären, weshalb der jeweilige Auftrag entstanden ist. Diese Probe zeigt schnell, ob das System betrieblich verständlich geworden ist.

Unsere Beiträge zu offlinefähigen Anwendungen und zu Serviceberichten aus Sprache und Bildern beleuchten die Arbeit vor Ort. Innovation T entwickelt Geschäftsanwendungen und Schnittstellen. Beschreiben Sie uns Ihre Sensorquelle, Anlagenliste und den heutigen Wartungsablauf, um einen ersten durchgängigen Pilot zu planen.

Häufige Fragen

Was ergänzt WebSub bei einer SensorThings-Integration?

Die OGC-Erweiterung beschreibt Benachrichtigungen über Änderungen abonnierter Abfragen per HTTP(S). Eine unterstützende Implementierung kann so passende Aktualisierungen an einen Webhook liefern, statt den Empfänger regelmäßig nach neuen Daten fragen zu lassen.

Sollte jede auffällige Messung sofort einen Wartungsauftrag erzeugen?

Nicht automatisch. Legen Sie Regeln für Wiederholungen, vorhandene offene Vorgänge, Datenqualität und menschliche Prüfung fest. Ein Messereignis und ein freigegebener Arbeitsauftrag sollten als unterschiedliche Zustände erkennbar bleiben.

Wie beginnen wir mit mehreren Standorten und verschiedenen Sensoranbietern?

Wählen Sie zunächst eine Anlagenfamilie und einen klaren Wartungsablauf. Vereinheitlichen Sie Anlagenkennungen, Messgrößen und Zeitangaben, bevor weitere Standorte oder automatische Entscheidungen hinzukommen.