Fast jede Maschine oder produktionstechnische Anlage besitzt gegenwärtig eine Vielzahl von Sensoren um ihre Funktion zu gewährleisten, die Qualität zu überwachen oder auf Änderungen reagieren zu können. Vielleicht haben Sie auch im Rahmen eines Retrofit Bestandsanlagen mit erweiterter Sensorik ausstatten lassen, um zusätzliche Betriebsdaten zu erheben. Zusätzlich stehen oftmals auch Sensordaten aus der Gebäudetechnik oder von Logistikmitteln zur Verfügung. Neben der primären Verwendung der Daten innerhalb der Anlage können sich durch deren Speicherung, Auswertung und vor allem Kombination mit anderen Daten eine Vielzahl von Zusatznutzen ergeben, die Sie in Ihrem Unternehmen nicht ignorieren sollten.

Steht eine Rollenbahn wiederkehrend still, ist dieses Wissen nicht allein an dieser Anlage von Interesse. Im besten Fall würden nicht nur vor- oder nachgelagerte Prozesse automatisiert gedrosselt, sondern sogar ein Wartungsmitarbeiter informiert. Mehrere Stillstände summieren sich, doch quantitative Aussagen über die Stillstandzeiten lassen sich nur treffen, wenn die Sensordaten auch gespeichert wurden und anschließend analysiert werden können. Was hat zum Stillstand geführt? Das Erkennen von Mustern in den Daten ist ein Paradebeispiel für die Anwendung von KI-Software. Ist die Anzahl der Anlagen oder der Störungen überschaubar und ist, wie in vielen KMU, Personal mit Expertenwissen durch langjährige Erfahrung mit der Anlage vorhanden, lässt sich durch manuelle Sichtung der Sensordaten neues Wissen erzeugen. Wie sah der Verlauf der Stromaufnahme der Antriebsmotoren oder deren Temperaturverlauf kurz vor den Störungen in der letzten Woche aus?

Sensordaten lassen sich hier als Zeitreihendaten klassifizieren. Wir verstehen eine Zeitreihe als zeitlich geordnete Sequenz diskreter Datenpunkte^[1]. Zusammen mit den Datenpunkten sollte auch der genaue Zeitpunkt ihrer Aufnahme erfasst werden. Die nötige Genauigkeit ist aus der jeweiligen Anwendung abzuleiten. Für einige Anwendungsfälle sollten die Zeitstempel unter Angabe von Millisekunden abgelegt werden. Es sollte ebenfalls darauf geachtet werden, die Uhren der beteiligten IT-Systeme über einen Zeitserver (NTP) miteinander zu synchronisieren. Sollten die Systeme aus Sicherheitsgründen nicht mit dem Internet verbunden sein, kann ein NTP-Server auch im unternehmenseigenen Netz betrieben werden.

Dieses Nachgelesen veranschaulicht die Thematik im weiteren Verlauf an dem praktischen Beispiel der Erfassung, Speicherung und Visualisierung von Energiedaten, die in der Experimentier- und Digitalfabrik am Mittelstand 4.0-Kompetenzzentrum Chemnitz an Anlagen und Gebäuden anfallen.

Daten sammeln

Im betrachteten Szenario kommen als Sensorik zehn Siemens SENTRON Multifunktionsgeräte PAC4200 zum Einsatz (Abbildung 1). Diese verfügen über eine Ethernet-Schnittstelle, über welche 12 elektroenergiebezogene Messwerte gleichzeitig mittels des Modbus- Protokolls abgefragt werden. Diese Abfrage erfolgt zyklisch, im Intervall von 1 Sekunde. Bei Modbus handelt es sich um ein offenes Protokoll zur Kommunikation bspw. mit speicherprogrammierbaren Steuerungen und es stehen Implementierungen in den gängigen Programmiersprachen zur Verfügung. Um später viele Datenströme aus unterschiedlichen Quellen in unterschiedlichen Formaten und Protokollen verarbeiten und kombinieren zu können, bietet sich die Verwendung einer an Datenstrom orientierten Entwicklungsplattform an.

Unsere Umsetzung wurde mit der Open-Source-Software Node-RED implementiert. Diese Umgebung ist durch Plugin-Module erweiterbar. So lassen sich bspw. das Modbus-Protokoll sowie Module für die Kommunikation mit SPS- oder PC-basierten Steuerungen wie S7^[2] oder Twincat ADS^[3] integrieren.

Wohin mit den Daten?

Der folgende Abschnitt gibt einen Überblick über verschiedene Datenbanksysteme, die zur Ablage von Sensordaten genutzt werden können. Innerhalb des Anwendungsbeispiels zeigen wir, was bei der Installation und Konfiguration des Datenbanksystems zu beachten ist.

Grundsätzlich wird bei Datenbanksystemen zwischen

• relationalen (bspw. MySQL, PostgreSQL) und
• nicht-relationalen Systemen (NoSQL, „Not only SQL“ wie bspw. MongoDB, Redis)

unterschieden. Relationale Datenbanken speichern die Informationen in strukturierten Tabellen, die zueinander in festgelegten Relationen stehen. Bekannte Vertreter der nicht-relationalen Systeme, wie die dokumentenorientierte Datenbank MongoDB, speichern die Daten als Dokumente (Documents) innerhalb von Sammlungen (Collections). Dabei müssen die Datensätze nicht in einer festen Relation stehen und auch nicht dem gleichen Schema folgen. Denken Sie dabei vielleicht an eine Sammlung von Büchern in einem Bücherregal. Jedes Dokument in einer Sammlung kann andere Informationen enthalten und in der Größe variieren. Dies bringt Flexibilität gegenüber den relationalen Modellen und kann in der Praxis eine schnellere Implementierung bedeuten, was wiederum nützlich für eine Prototypenentwicklung sein kann.

Bei der kontinuierlichen Erfassung und Speicherung von Sensordaten besteht die größte Herausforderung in der Skalierbarkeit der beteiligten Systeme. Betrachten wir bspw. ein System mit 20 Sensoren, die sekündlich einen Datenwert liefern. In 30 Tagen liefert dieses System also 51,8 Millionen Datensätze, die nicht nur auf den Speicher geschrieben werden müssen, sondern auch indexiert werden, um möglichst schnell bei Abfragen wieder gefunden werden zu können. Systeme wie MongoDB können hier im Vergleich mit relationalen Systemen ihre Vorteile nicht ausspielen. Selbst bei speziell auf die Systeme angepassten Implementierungen, etwa dem Zusammenfassen von mehreren Datensätzen in einem Dokument, hängt die Performance im Vergleich zurück^[4]. Zudem ist der Speicherverbrauch nicht aus dem Fokus zu verlieren. Im Gegensatz zu relationalen Modellen, bei denen der Datentyp für jede Spalte einer Tabelle im Voraus definiert wird und somit optimal abgelegt werden kann, ist bei der Ablage der gleichen Daten in ein NoSQL-System ein Mehrverbrauch um den Faktor 10 möglich.

Selbst relationale Datenbanksysteme wie PostgreSQL brechen in der Performance ein, sobald der Datenbestand zu groß wird^[5]. Beim Schreiben jedes neuen Datensatzes müssen Indizes angepasst werden. Dies ist nur mit hoher Geschwindigkeit möglich, wenn der Index im Arbeitsspeicher (RAM) gehalten werden kann. Wächst jedoch der Datenbestand und damit auch der Index zu stark, so kann dieser nicht mehr im flüchtigen Speicher gehalten werden. An dieser Stelle setzen auf Zeitreihendaten spezialisierte Systeme mit weiteren Optimierungen und zusätzlichen Strategien an.

TimescaleDB, eine Erweiterung für PostgreSQL spezialisiert auf den Umgang mit Zeitreihendaten, implementiert das Konzept von Hypertabellen (Hypertables), welche die eigentliche Datentabelle im Hintergrund für den Nutzer unbemerkt in kleinere Tabellen partitioniert. Somit ist es möglich, den Index zu jeder Zeit im Arbeitsspeicher zu halten.

Im Anwendungsbeispiel haben wir die Erweiterung TimescaleDB in ein PostgreSQL 12 installiert. Danach ist jede Tabelle einmalig durch das Ausführen einer Anweisung in eine Hypertabelle zu überführen (Abbildung 2). Den Rest der Arbeit erledigt TimescaleDB von nun an im Hintergrund.

Von Datensätzen zur Visualisierung

In den vorangegangenen Absätzen haben Sie erfahren, welche Voraussetzungen an ein Datenhaltungssystem für Zeitreihendaten gestellt werden und wie eine praktische Umsetzung aussehen kann. Im Folgenden betrachten wir die Visualisierung der Daten näher.

Unsere Node-Red-Anwendung schreibt die über Modbus ausgelesenen Daten der Multifunktionsmessgeräte in jeweils eine Tabelle pro Gerät. Der Vorteil: Indizes wachsen nicht unnötig an.

Um die Daten zu analysieren und bspw. Stillstandszeiten, Muster, Zusammenhänge mit anderen Daten, möglichen Verschleiß oder Abweichungen zu erkennen, eignet sich eine grafische Visualisierung der Daten. Auch für diesen Schritt greifen wir auf freie Software zurück.

Die plattformübergreifende Anwendung Grafana ist ein Werkzeug zur Visualisierung von Rohdaten in verschiedene grafische Anzeigeformen und eignet sich perfekt für die Abfrage und Visualisierung von Zeitreihendaten.

Wie auch bei PostgreSQL handelt es sich bei Grafana um eine Server-Anwendung, die Sie einmalig zentral installieren. Danach ist Grafana über den Webbrowser auf anderen Geräten im Netzwerk erreichbar.

Neben Linien- und Flächendiagrammen bietet die Anwendung eine Vielzahl weiterer Visualisierungsoptionen (Abbildung 3).

Diagramme lassen sich bildschirmfüllend darstellen oder in variabler Größe und Anzahl zu ganzen Dashboards kombinieren. Ob mehrere Y-Achsen, das Überschreiben von Datenreihennamen oder die Anzeige von Alarmbereichen – Grafana bietet zahlreiche Möglichkeiten, die eigenen Daten je nach Bedarf abzubilden. Selbst bei Bestandsanlagen kann eine solche Visualisierung ganz neue Betrachtungswinkel eröffnen und helfen, Prozesse zu hinterfragen oder Details besser zu verstehen.

Die Abbildung 4 und Abbildung 5 geben einen Einblick über den Umfang der Funktionalität und sollen Ihnen einen Eindruck vermitteln, wie Sie die eigenen Daten durch geeignete grafische Darstellung neu erleben können.

Die Abfrage der darzustellenden Daten erfolgt über SQL. Neben der Option Ihre Datenbankanfragen direkt in SQL zu formulieren, gibt Ihnen Grafana auch die Möglichkeit, eine Art eingebauten Baustein-Editor zu benutzen, dessen Ausgabe im Hintergrund automatisiert in SQL überführt wird. Die Unterschiede können Sie der folgenden Abbildung 6 entnehmen.

Der Zeitbereich für die Anzeige kann in Grafana frei gewählt werden. Dabei ist zu bedenken, dass das sekündliche Ablegen eines einzigen Messwertes in einer Woche über 600.000 Datensätze erzeugt. Das Datenbanksystem ist in der Lage all diese Datensätze als Abfrageergebnis zurückliefern. Jedoch können Bildschirme aufgrund ihrer Auflösung die Datenpunkte nicht darstellen. Deshalb sollte die Abfrage dahingehend angepasst werden, nur einen Bruchteil der Abb. 6: Optionen für SQL-Abfragen Werte zurückzuliefern, die bspw. aus Mittelwerten von festgelegten Zeitintervallen bestehen.

An dieser Stelle möchten wir wichtige Tipps für Sie zusammenfassen, damit die Speicherung und Auswertung von Sensordaten auch in Ihrem Unternehmen zum Erfolg wird:

• Identifizieren Sie existierende Datenquellen in Ihrem Unternehmen. Nicht immer ist zusätzliche Sensorik nötig.
• Verwenden Sie Aufzeichnungsintervalle, die genau zu Ihrem Szenario passen. Unnötig kurze Intervalle erzeugen immense Datenmengen.
• Wählen Sie das passende Datenbanksystem für Ihren Anwendungsfall. TimescaleDB ist für Zeitreihendaten eine gute Wahl.
• Dimensionieren und konfigurieren Sie den Datenbankserver so, dass benötigte Tabellenindizes im Arbeitsspeicher gehalten werden können.
• Behalten Sie Ausführungszeiten von Datenbankabfragen im Auge. Können Indizes nicht mehr im RAM gehalten werden, sinkt die Performance drastisch.
• Nutzen Sie optimierte Sonderfunktionen Ihres Datenbanksystems.
• Binden Sie erstellte Visualisierungen in schon vorhandene Dashboards und Webanwendungen im Unternehmen ein, um das daraus ableitbare Wissen breit nutzen zu können.
• Behalten Sie den wachsenden Datenbestand im Auge, um beteiligte Systeme frühzeitig skalieren zu können.
• Hinterfragen Sie die angenommenen Parameter zu gegebener Zeit. Gibt es Haupt- und Nebenzeiten mit unterschiedlicher Nutzung der Anlagen? Variable Intervalle für die Datenablage können das Speichervolumen stark reduzieren.
• Erhöhen Sie – wenn möglich – nur die Speicherintervalle, nicht die Abfrageintervalle der Sensoren. So können Sie noch mit der gleichen Geschwindigkeit auf Änderungen reagieren.

Eine solide Datenbasis ist die Grundlage für viele Optimierungen im Unternehmen, wie bspw. genauere Verfügbarkeitsplanung von Ressourcen, verbesserte Prozessplanung und -steuerung sowie jeglicher Einsatz von Anwendungen der Künstlichen Intelligenz. Sie konnten einen Anwendungsfall für den Einsatz von Sensordaten in Ihrem Geschäftsbereich identifizieren und wollen das Gelesene im Selbstversuch umsetzen? Dann stehen wir Ihnen für weiterführende Fragen gerne zur Seite.