Sensordaten für das digitale Bergwerksmonitoring

Im Forschungsprojekt DIETER hat EXWE das Backend für die Verarbeitung und Darstellung von Bergwerksmessdaten aufgebaut. Die Symfony-Anwendung verbindet den Datenabruf aus InfluxDB mit einer kommunalen Verwaltungsstruktur, Zeitreihendiagrammen und konfigurierbaren Warnregeln.

Die Entwicklung setzt den im Oktober 2024 vorgestellten Ansatz für ein kommunales Dashboard um. Ein Schwerpunkt lag darauf, Herkunft, Bedeutung und zeitlichen Verlauf der Messwerte in einem gemeinsamen Datenmodell abzubilden.

Datenmodell trennt Sensoren und Messgrößen

Die relationale Datenstruktur bildet Kommunen, Bergwerke, Sensoren und Datentypen ab. Der Sensor steht dabei für die Datenquelle; ein Datentyp beschreibt die zugehörige Messgröße. Messdaten werden dem jeweiligen Datentyp zugeordnet.

Diese Trennung ist relevant, wenn eine Datenquelle mehrere Messgrößen liefert. Jede Messreihe kann eigenständig dargestellt und in Warnregeln verwendet werden, während ihre Zuordnung zum Sensor und zum Bergwerk erhalten bleibt.

An diese Struktur knüpft auch die Zugriffskontrolle an. Benutzerrollen regeln die zulässigen Verwaltungsaktionen. Zusätzlich begrenzt die kommunale Zuordnung, welche Bergwerke, Sensoren und Datentypen ein Benutzer einsehen oder bearbeiten darf. Rollen und Datenzugehörigkeit erfüllen damit unterschiedliche Aufgaben innerhalb der Berechtigungsprüfung.

Periodischer Datenabruf mit Fehlerstatus und Sperre

Die Messreihen werden über einen PHP-Client aus InfluxDB abgerufen. Eigene Dienste übernehmen den Abruf und die Aktualisierung der Sensordaten. Verbindungsparameter werden über die Anwendungskonfiguration beziehungsweise Umgebungsvariablen bereitgestellt.

Die Aktualisierung ist als Konsolenkommando umgesetzt. Eine Sperre, technisch ein Lock, verhindert gleichzeitig laufende Update-Aufrufe. Das ist beispielsweise relevant, wenn ein vorheriger Abruf noch nicht abgeschlossen ist, während bereits die nächste Aktualisierung gestartet wird.

Abruffehler werden am betroffenen Sensor gespeichert. Dadurch bleibt ein fehlgeschlagener Zugriff bei der anschließenden Prüfung nachvollziehbar. Die Aktualität der Anzeige hängt unter anderem davon ab, in welchen Abständen Messdaten vorliegen und vom Backend abgerufen werden.

Warnregel und Warnereignis sind getrennte Objekte

Für die Überwachung wurde ein eigenes Symfony-Bundle entwickelt. Es unterscheidet zwischen der konfigurierten Warnregel und den daraus entstehenden Ereignissen: Die Regel wird als „Alert“ verwaltet, einzelne Warnereignisse als „AlertInstance“.

Die Regel legt die überwachten Datentypen und Schwellenwerte fest. Eine Instanz hält unter anderem den Ereignistyp, den Bezug zur Regel und den aktiven Status fest. So lassen sich die Konfiguration einer Überwachung und ihre Ereignishistorie getrennt verwalten.

Bei Warnungen und Fehlern können E-Mails an konfigurierte Empfänger verschickt werden. Im Dashboard werden Statusinformationen angezeigt; die zugehörigen Schwellenwerte erscheinen als Orientierungslinien im Diagramm. Damit lässt sich eine Meldung im Zusammenhang mit der betroffenen Messreihe betrachten.

Zeitreihendarstellung und zeitliche Auflösung

Das Dashboard stellt Messwerte als Wertkarten und mit Chart.js erzeugte Zeitreihendiagramme dar. Zeitraumfilter begrenzen die angezeigten Daten auf das benötigte Intervall.

Um die verarbeitete Datenmenge zu reduzieren, wurde Downsampling mit ungefähr einem Datenpunkt pro Minute ergänzt. Hinzu kommt Caching, also die Zwischenspeicherung bereits ermittelter Ergebnisse.

Die zeitliche Auflösung beeinflusst, welche Veränderungen in einer Darstellung erkennbar sind. Eine reduzierte Punktzahl kann für längere Betrachtungszeiträume ausreichen, während kurze Ereignisse eine feinere Auflösung erfordern können. Bei der Auswertung muss deshalb berücksichtigt werden, welchen Zeitraum ein dargestellter Datenpunkt repräsentiert und welche Fragestellung mit der Messreihe untersucht wird.