Störmeldungen statt Rauschen: Von rund 110 Alarmen in zwei Tagen waren etwa 5 echt

Warum eine Überwachung mit zu vielen Meldungen im Alltag abgeschaltet wird – und wie sich Fehlalarme zerlegen lassen, bevor der Service aufhört hinzusehen

· 4 Min. · Automatisierung, Architektur, TypeScript

Störmeldungen verlieren ihren Wert nicht durch einen großen Fehler, sondern durch viele kleine: Jede unnötige Meldung bringt dem Empfänger bei, die nächste zu überlesen. Abhilfe schafft kein strengerer Filter, sondern ein Schwellenwert, der sich aus dem bisherigen Verhalten des jeweiligen Objekts berechnet, und eine Überwachung, die an einem einzelnen Datenfehler nicht scheitert.

Wenn Störmeldungen niemand mehr liest

Wer Geräte oder Anlagen beim Kunden aus der Ferne überwacht, steht früher oder später vor derselben Abwägung. Meldet das System jede Abweichung, entsteht eine Liste, die morgens im Postfach des Service wartet. Anfangs wird sie gelesen, dann überflogen, schließlich per Regel in einen Ordner verschoben. Die entscheidende Meldung kommt in diesem Zustand nicht zu spät – sie kommt pünktlich und wird nicht beachtet.

Meldet das System zu wenig, erfährt der Hersteller von der Störung durch den Anruf des Kunden. Beide Fehler kosten Vertrauen, aber der erste ist tückischer: Auf dem Papier ist die Überwachung vorhanden, im Betrieb ist sie abgeschaltet – nur hat das niemand beschlossen.

Rund 110 Meldungen in zwei Tagen, etwa 5 davon zutreffend

Wir haben diese Lage nicht an einer Maschine erlebt, sondern an Datenwächtern. In einer Unternehmensgruppe aus Lebensmittelproduktion und Filialhandel prüfen automatische Wächter die laufenden Datenflüsse und melden Auffälligkeiten an die zuständigen Mitarbeiter. Einer von ihnen bekam in zwei Tagen rund 110 Meldungen und hörte auf, sie überhaupt zu lesen. Nachgezählt waren etwa 5 davon zutreffend. Eine echte Störung wäre in diesem Rauschen untergegangen.

Naheliegend wäre gewesen, die lautesten Wächter stummzuschalten. Damit wäre das Postfach leer geworden, die Überwachung aber auch. Stattdessen haben wir sechs Rauschquellen einzeln zerlegt und für jede entschieden, ob die Daten, die Regel oder der Ablauf falsch waren. Übrig bleiben heute die Meldungen, die stimmen. Das Postfach ist dadurch nicht leiser geworden, weil jemand weniger wissen will, sondern weil jede verbliebene Meldung einen Grund hat, gelesen zu werden.

Drei Muster, die Störmeldungen vervielfachen

Sechs Quellen sind ein einzelner Fall. Drei Muster daraus halten wir für allgemein genug, um sie bei jeder Überwachung zuerst zu prüfen:

  • Eine feste Grenze für ungleiche Objekte. Ein Wert, der für ein Objekt vernünftig ist, wird bei einem anderen ständig überschritten, weil es sich schlicht anders verhält. Die Schwellenwerte berechnen sich deshalb jetzt aus dem historischen Verhalten des jeweiligen Objekts statt aus einer festen Zahl. Übertragen auf Anlagen hieße das: Eine Maschine im Dauerbetrieb und eine, die nur tagsüber läuft, bekommen nicht dieselbe Grenze für Stillstand.
  • Ein Datenfehler reißt den ganzen Lauf mit. Ein einzelner nicht angelegter Geschäftspartner brachte zuvor einen kompletten Prüflauf zum Absturz, und der Abbruch erzeugte selbst wieder Meldungen. Heute scheitert der Lauf daran nicht mehr; der fehlende Datensatz ist ein Befund, kein Grund, alle anderen Prüfungen auszulassen.
  • Eine Ursache, hundertfach gemeldet. In der Wochenbetrachtung stammten 151 von 179 Fehlern aus einer einzigen Ursache, 145 davon hintereinander. Wer diese Liste liest, sieht keine 179 Probleme, sondern eines, das so lange wiederholt wird, bis niemand mehr hinsieht. Die Ursache ist beseitigt.

Was sich auf Fernwartung übertragen lässt und was nicht

Die Grenze dieses Beispiels gehört an den Anfang: Datenwächter sind keine Sensoren. An einer Anlage kommen Messrauschen, schwankende Verbindungen beim Kunden und Umgebungseinflüsse hinzu, die in diesem Projekt keine Rolle spielten. Wir behaupten deshalb nicht, dass sich die Quote aus dem Beispiel auf eine Maschinenflotte übertragen lässt.

Übertragbar ist das Vorgehen. Erstens: Grenzen je Objekt statt je Gerätetyp. Zweitens: Die Überwachung darf an einem fehlerhaften Datensatz nicht als Ganzes ausfallen. Drittens: Wiederholungen derselben Ursache werden zu einer Meldung gebündelt. Und viertens, am wenigsten technisch: Der Anteil zutreffender Meldungen ist eine eigene Kennzahl, die jemand regelmäßig ansieht. Wie Zugriff und Diagnose aus der Ferne grundsätzlich organisiert werden, beschreibt der Lexikonartikel zur Fernwartung; wo die Messwerte vieler Geräte zusammenlaufen, der Artikel zur IoT-Plattform.

Wie wir eine Überwachung mit wenigen, richtigen Meldungen bauen

Bevor wir eine Regel ändern, zählen wir: Welche Meldungen sind in einem überschaubaren Zeitraum entstanden, welche davon waren zutreffend, und auf welche Ursachen verteilen sie sich? Erst diese Liste zeigt, ob das Problem in den Daten, in den Grenzwerten oder im Ablauf liegt. Danach wird jede Rauschquelle einzeln behandelt und ihr Effekt nachgemessen.

Was eine Überwachung leisten soll, beschreiben wir als Abnahmekriterien im Angebot: welche Zustände gemeldet werden, wie Wiederholungen gebündelt sind und woran der Anteil zutreffender Meldungen abgelesen wird. Gebaut wird in Teillieferungen auf TypeScript und PostgreSQL. Mehr zu Vertragsform und Ablauf steht auf der Seite Softwareentwicklung.

Weitere Beiträge

Welcher Servicefall läuft bei Ihnen noch über Telefon und Excel?

Beschreiben Sie einen typischen Fall, etwa eine Störungsmeldung, einen Wartungstermin oder eine Ersatzteilanfrage, und die Systeme, durch die er heute wandert. Wir sagen Ihnen, welche Etappe sich als Werkvertrag mit Abnahme abgrenzen lässt.

Gespräch vereinbaren