Anlagenüberwachung statt Handarbeit
Ein Betreiber technischer Sende- und Empfangsanlagen überwachte seine Anlagen von Hand und erfuhr von Störungen erst, wenn jemand hinsah oder anrief. Wir haben die Erfassung, die Sollwertprüfung, die Bewertung und die Alarmierung gebaut, dazu einen Konfigurator, mit dem der Betreiber seine Anlagen selbst abbildet.
- Branche
- Funknetz-Infrastrukturbetreiber, technische Sende- und Empfangsanlagen
- Zeitraum
- Zusammenarbeit von Februar 2023 bis Juli 2025
- Gebaut
- Überwachungs- und Alarmierungssystem mit Sollwertprüfung, Redundanzverfolgung, Alarmverwaltung, Dashboard und Konfigurator
- Technik
- OPC UA, SNMP und SQL über Telegraf, InfluxDB 2, MongoDB, PostgreSQL, MQTT, REST-Schnittstelle, Websocket-Server, Flutter, Python, Grafana, CheckMK
- Betrieb
- Docker Compose auf virtuellen Maschinen des Betreibers, im eigenen Haus
- Stand
- In Betrieb seit 2023, über 16 Sprints ausgebaut, monatliche Abrechnung von Mai 2024 bis April 2025. Weiterhin in Betrieb, unsere Mitarbeit endete im Juli 2025
Ausgangslage
Ein Betreiber technischer Sende- und Empfangsanlagen überwachte seine Anlagen von Hand. Die Geräte liefern permanent Werte: Antennenstellung, Verstärkerpegel, Schaltzustände, Temperaturen, Lüfter- und Spannungsmeldungen aus Switches, Umsetzern und Racks. Durchgängig gegen Sollwerte geprüft wurde nichts, eine zentrale Alarmierung gab es nicht. Der Betrieb erfuhr von einer Störung, wenn jemand hinsah. Oder wenn jemand anrief.
Zwei Dinge machen den Fall schwerer, als er klingt, und beide hängen an Wissen, das in Köpfen und in Excel-Tabellen stand. Dort wurden auch Messwerte, Sollwerte und Geräteabhängigkeiten von Hand gepflegt.
Der große Ausschlag rechts in der Zeichnung ist genau der Fall, der unbemerkt bleibt, weil gerade eine andere Stelle unter der Lupe liegt.
Warum eine Meldung allein nicht reicht
- An jedem Signal hängt ein Dienst, nicht nur ein Gerät. Eine Meldung sagt also noch nicht, ob ein Kunde etwas merkt.
- Die Strecken sind redundant aufgebaut. Fällt ein Gerät aus, muss jemand wissen, ob es eine Ersatzstrecke gibt und ob sie greift.
Was wir gebaut haben
Ein Überwachungs- und Alarmierungssystem, kein Dashboard über den vorhandenen Anlagen. Telegraf-Importer holen die Werte über OPC UA, SNMP und SQL in eine Zeitreihendatenbank, InfluxDB 2. Bei jedem eingehenden Wert vergleicht der Dienst Ist gegen Soll, gegen konfigurierbare Grenzen.
Registerwerte werden dafür binär zerlegt und bitweise geprüft, analoge Werte gegen Min- und Max-Grenzen, dazu Flankenwechsel und Abhängigkeiten zwischen Komponenten. Wahrheitstabellen je Streckenabschnitt entscheiden, welcher Fehlertyp ausgelöst wird, in vier Schweregraden von Info bis Critical. Der Zustand pflanzt sich nach oben fort, vom Element über Abschnitt und Strecke zum Dienst.
Fällt ein Gerät aus, geht eine rekursive Funktion den Sende- und Empfangsweg entlang, sucht das nächste Koppelfeld und schaltet die Ersatzstrecke im Modell aktiv. Findet sie keine, wird der Dienst als kritisch geführt.
Fehler gehen als Arbeitsaufträge über MQTT an das vorhandene Workflow-System des Betreibers. Das ist ratenbegrenzt, Zykluszeit ein bis zwei Sekunden, und kein Auftrag darf verloren gehen. Davor sitzt deshalb ein eigener Scheduler, der alle zwei Sekunden genau einen Vorgang abgibt, Kritisches zuerst.
Bedient wird das System über ein Flutter-Dashboard, dazu kommt ein Konfigurator, mit dem der Betreiber seine Anlagen selbst abbildet. Was dabei Schritt für Schritt passiert, steht unter KI-Implementierung.
In der Zeichnung hat die Suche den unteren Weg gefunden und im Modell aktiv geschaltet, während der obere Weg am ausgefallenen Gerät unterbrochen bleibt.
Was der Betreiber selbst bedient
- Störungsansicht, Quittieren einzelner und aller Vorfälle, Ticketerstellung mit Rückfrage-Dialog, Notizen, Signalton
- Anlagenteile als Objekte anlegen, mit Vererbung: ein Port erbt Spannungsversorgung des Racks und Lüfteralarm des Switches
- Strecken grafisch zusammenstecken, geprüft auf Vollständigkeit, Medienbrüche und Reihenfolgen
- Aus einer geprüften Strecke erzeugt das System die Aufzeichnungskonfiguration und den Diagnosepfad selbst
| Baustein | Aufgabe |
|---|---|
| InfluxDB 2 | Zeitreihen aus OPC UA, SNMP und SQL |
| MongoDB | Zustände, Alarme und Arbeitsaufträge |
| PostgreSQL | Konfiguration |
| REST und Websocket-Server | Schnittstelle und Echtzeit-Updates |
| CheckMK | Selbstüberwachung |
| Docker Compose auf virtuellen Maschinen des Betreibers | Betrieb im eigenen Haus, mandantenfähig für mehrere Kunden je Dienst |
Was heute läuft
In Betrieb seit 2023. Ausgebaut in mehr als 16 Sprints, Sprint 17 lief im März 2025. Im April 2025 kam ein eigener Arbeitsstrang für den Konfigurator dazu. Der Auftragsumfang wuchs mit, von Mai 2024 bis April 2025 arbeiteten wir durchgehend jeden Monat daran.
Das System ist weiterhin in Betrieb. Es prüft jeden eingehenden Wert gegen den Sollwert und gibt Fehler als Arbeitsaufträge an das Workflow-System des Betreibers weiter.
Was das im Betrieb heißt, zeigt die Skizze: Solange die Werte im Sollband bleiben, passiert nichts. Der eine Ausreißer löst den Alarm aus, und zwar bevor jemand anruft.
Das Sollband in der Zeichnung ist je Wert und Gerät konfigurierbar, und der Ausschlag darüber wird nicht nur angezeigt, sondern als Arbeitsauftrag weitergereicht.
Das beweist
Anlagenwissen, das in Köpfen und Tabellen steckt, lässt sich in Regeln überführen, die eine Maschine bei jedem Messwert prüft, samt Redundanzwegen und Übergabe an die Systeme, die schon im Haus sind. Aus einem eng umrissenen Überwachungsauftrag wurde ein System, das der Betreiber zwei Jahre lang mit uns ausgebaut hat und seit Juli 2025 ohne uns weiterführt.
Jeden Satz können Sie im Gespräch nachrechnen. Wie aus denselben Maschinendaten ein geprüftes Modell wird, steht im Bericht zu den Lenkzeiten.