Warum klassische Grenzwerte nicht immer ausreichen
Unterschied zw. physischen Sensoren und Softsensoren
Autoencoder zur Anomalieerkennung
Aufbau und Training eines Autoencoders
KI-basierte Softsensoren werten vorhandene Mess-, Schwingungs- oder Audiodaten aus und erkennen damit Zustände, für die einfache Grenzwerte nicht ausreichen. Dieser Beitrag erläutert anhand eines Serverraums, wie Autoencoder trainiert werden, Anomalien an eine Leitstelle melden und welche Anforderungen dabei an Datenqualität, Kommunikation und Sicherheit gelten.
Als Beispiel dient ein Fabrikgebäude in der Innenstadt von Hannover, in dem Anfang des vergangenen Jahres ein Heizkessel explodiert ist. Der Personenschaden blieb laut Presse gering, es entstand jedoch erheblicher Sachschaden. Die Ursache ist mir nicht bekannt. Es liegt aber nahe, dass Messwerte vorhanden waren und nicht richtig gedeutet wurden.
Bildquelle: Frank Tunnat/RND
Ein Heizkessel ist mit Sensorik ausgestattet. Dennoch reicht es nicht immer aus, nur einen einzelnen Messwert mit einem festen Grenzwert zu vergleichen. Wasser kocht bei normalem Luftdruck in Hannover bei rund 100 °C. Auf dem Mount Everest mit wesentlich niedrigerem Luftdruck liegt der Siedepunkt dagegen bei gut 70 °C. Die Temperatur kann deshalb nur im Zusammenhang mit weiteren Größen bewertet werden, etwa mit dem Luftdruck.
Ein weiteres Beispiel ist der COP-Wert einer Wärmepumpe. Der Coefficient of Performance beschreibt das Verhältnis von eingesetzter elektrischer Energie zu erzeugter Wärme. Ein einzelner Tages- oder Wochenwert (links im folgenden Bild) ist kaum aussagekräftig. Erst die Betrachtung über eine längere Zeitachse (rechts im folgenden Bild) und mit weiteren Einflussgrößen ermöglicht eine belastbare Bewertung.
Links: COP-Wert einer Wärmepumpe eines einzelnen Tages, rechts: gleitender COP-Wert über mehrere Monate
Das gilt auch für Schwingungsdaten eines Lüfters. Ein Beschleunigungssensor misst dabei Bewegungen in X-, Y- und Z-Richtung. Einzelne Messwerte lassen sich nicht sinnvoll mit einem einfachen Grenzwert bewerten. Erst ein geeignetes mathematisches Verfahren kann aus dem zeitlichen Verlauf erkennen, ob eine Unwucht oder ein anderer ungewöhnlicher Zustand vorliegt.
Ein physischer Sensor misst eine Größe direkt. Ein Temperatursensor oder Drucksensor liefert beispielsweise einen Messwert, der auf einem physikalischen Messprinzip beruht. Die dafür notwendige Hardware muss eingebaut und regelmäßig kalibriert werden.
Ein Softsensor errechnet dagegen zusätzliche Informationen aus vorhandenen Daten. Er kann als Software auf einem System laufen und benötigt nicht zwingend eigene Hardware. Ein mögliches Beispiel ist ein Luftfilter: Anstatt den Differenzdruck vor und hinter dem Filter mit zwei zusätzlichen Drucksensoren zu messen, kann ein Softsensor bereits vorhandene Werte wie Umgebungstemperatur, Drehzahl einer Pumpe und weitere Steuerungsdaten kombinieren. Daraus lässt sich der Zustand oder die Durchlässigkeit des Filters ableiten.
| Merkmal | Physischer Sensor | Softsensor |
|---|---|---|
| Messprinzip | Direkte physikalische Messung | Mathematisches oder KI-basiertes Verfahren |
| Grundlage | Physikalische Eigenschaften, etwa Widerstandsänderung eines Halbleiters | Vorhandene Messdaten und Modelle des maschinellen Lernens |
| Ergebnis | Gemessene physikalische Größe | Errechnete Größe oder abgeleiteter Zustand |
| Hardware | Eigene Hardware erforderlich | Kann reine Software sein |
| Entwicklung | Auswahl, Einbau und Kalibrierung | Datenerfassung; Modellierung, Training und Validierung des Modells |
| Wartung | Nachkalibrierung bei Alterung oder Drift | Überwachung der Modellgüte und ggf. Nachtraining |
| Grenzen | Messbereich, Genauigkeit und Verschleiß | Datenqualität, Veränderungen an überwachter Anlage, unbekannte Zustände |
Vergleich physischer Sensor und Softsensor/virtueller Sensor
Beide Ansätze haben Grenzen. Beim physischen Sensor sind Messbereich, Genauigkeit und Verschleiß zu beachten. Beim Softsensor spielen insbesondere Datenqualität und Veränderungen an der überwachten Anlage eine Rolle.
Ein anschauliches Beispiel für einen Softsensor ist der Schrittzähler einer Fitnessuhr. Die Uhr beobachtet nicht direkt die Beine, sondern wertet Beschleunigungsdaten aus. Ein Modell erkennt darin typische Muster und leitet daraus die Zahl der Schritte ab. Auch im physischen Sensor wird gerechnet, etwa wenn Strom oder Spannung in einen Temperaturwert umgerechnet werden. Beim Softsensor werden jedoch meist mehrere Datenquellen mit aufwendigeren Verfahren zu einer zusätzlichen Aussage verknüpft.
Ein wichtiger Anwendungsfall im Facility Management ist die Anomalieerkennung. Beispiele sind ungewöhnliche Geräusche einer Pumpe, ein ausfallender Lüfter oder das Warnsignal einer unterbrechungsfreien Stromversorgung in einem unbeaufsichtigten Serverraum. Auch ein Sturz könnte bei einer Fitnessuhr als Anomalie erkannt werden.
Für solche Aufgaben eignen sich Autoencoder. Sie sind ein Verfahren des maschinellen Lernens und werden seit Langem beispielsweise auch zur Datenkompression eingesetzt. Ein Autoencoder besteht aus zwei Teilen:
Prinzip eines Autoencoders
Als Eingangsdaten eignen sich Messwerte mehrerer Sensoren, Zeitreihen, Kameraaufnahmen, Audiodaten oder Radardaten. Encoder und Decoder sind neuronale Netze, die mit Daten trainiert werden.
Der entscheidende Punkt für die Anomalieerkennung ist der Rekonstruktionsfehler. Das Modell wird mit Daten aus dem Normalzustand trainiert. Kann es ein neues Eingangssignal gut rekonstruieren, entspricht dieses vermutlich dem bekannten Normalzustand. Ist der Fehler deutlich größer als üblich, kann eine Anomalie vorliegen. Der erlaubte Fehler wird über einen Schwellwert festgelegt.
Ein Autoencoder kann beispielsweise lernen, wie sich ein Lüfter im normalen Betrieb verhält. Unwuchten, Schleifgeräusche oder andere ungewohnte Schwingungen führen dann zu einem auffälligen Rekonstruktionsfehler. Wie ein physischer Sensor muss auch ein Softsensor über seine Lebensdauer überwacht und bei veränderten Bedingungen nachtrainiert werden.
Ob ein Autoencoder eine virtuelle Messung liefern oder einen Zustand als normal beziehungsweise auffällig bewerten soll, hängt vom konkreten Anwendungsfall ab. Das Grundvorgehen ist jedoch ähnlich.
Zunächst werden die relevanten Signale über einen ausreichend langen Zeitraum aufgezeichnet. Je nach Aufgabe können das Daten von Mikrofonen, Beschleunigungssensoren, Druck- oder Gassensoren sowie weitere Prozess- oder Umgebungsdaten sein. Auch externe Datenquellen, etwa Wetterdaten, können einfließen.
Die Datenaufzeichnung läuft automatisiert, beispielsweise mit einem Datenlogger. Das Abtastintervall hängt vom Signal ab und kann von Sekunden bis zu deutlich längeren Zeiträumen reichen.
Für das Training werden möglichst nur Daten aus dem Normalbetrieb verwendet. Offensichtliche Ausreißer und Störungen werden entfernt. Bei Schwingungsdaten lassen sich ungewöhnliche Verläufe mit Fachwissen und Visualisierungen erkennen. Bei Audiodaten kann etwa eine geöffnete oder zugeschlagene Tür als für das Zielmodell irrelevantes Ereignis herausgeschnitten werden.
Das Ergebnis ist eine Datei oder eine Sammlung von Dateien mit repräsentativen Normalzustandsdaten. Je mehr geeignete Daten vorliegen, desto belastbarer kann das Modell werden.
Der Aufbau des neuronalen Netzes muss zu den Eingangsdaten passen. Einfache Messreihen aus Temperatur, Stromaufnahme und Luftfeuchte benötigen ein anderes Modell als Bilder, Audiodaten oder IMU-Daten.
Beschleunigungsdaten werden beispielsweise häufig zunächst mittels Fourier-Transformation in ein Frequenzspektrum überführt. Audiodaten lassen sich als Mel-Spektrogramme aufbereiten. Die gewählte Datenaufbereitung, die Schichten des Encoders und Decoders sowie die Ausgabe des Modells müssen zusammenpassen. Ein formal lauffähiger Code führt nicht automatisch zu einem guten Modell.
Beim Training werden die Gewichte des neuronalen Netzes an die Normalzustandsdaten angepasst. Dafür werden üblicherweise Softwarebibliotheken für maschinelles Lernen und ein ausreichend leistungsfähiger Rechner oder ein Cloud-Dienst eingesetzt. Das Ergebnis ist ein trainiertes Modell, das als ausführbare Software in den Softsensor integriert werden kann.
Im laufenden Betrieb erzeugt der Softsensor Status- oder Anomaliewerte. Diese können an eine Leitstellen-Software übertragen werden. Denkbar ist ein Softsensor auf einem Gabelstapler, der den Zustand von Batterie oder Hydraulik überwacht. Ebenso kann eine Kamera in einer Produktionsumgebung Rauch, austretenden Dampf, Funken, unerlaubte Personen oder Gegenstände im Arbeitsbereich erkennen.
Ein Softsensor hat in der Regel zwei Kommunikationsrichtungen:
Der Softsensor benötigt daher die passenden Protokolle für beide Seiten. In Gebäudetechnik und Facility Management kann das beispielsweise BACnet sein. Für den Zugriff auf Steuerungsdaten kann Modbus TCP vorkommen. Anbindungen an IT- und Fertigungsumgebungen können OPC UA, MQTT, HTTPS beziehungsweise REST-APIs oder in Einzelfällen SNMP verwenden. Auch ein Zugriff auf Datenbanken ist denkbar, aber nicht immer empfehlenswert.
Beschleunigungsdaten werden beispielsweise häufig zunächst mittels Fourier-Transformation in ein Frequenzspektrum überführt. Audiodaten lassen sich als Mel-Spektrogramme aufbereiten. Die gewählte Datenaufbereitung, die Schichten des Encoders und Decoders sowie die Ausgabe des Modells müssen zusammenpassen. Ein formal lauffähiger Code führt nicht automatisch zu einem guten Modell.
Bei der Auswahl der Protokolle ist Sicherheit wesentlich. Modbus TCP bietet selbst keine angemessenen Sicherheitsmechanismen und sollte nicht ungeschützt über größere Entfernungen eingesetzt werden. Innerhalb einer einzelnen Maschine lässt sich ein solcher Einsatz unter Umständen begrenzen, bleibt aber in Bezug auf die Sicherheit kritisch. Für die Verbindung zur Leitstelle sollten Verschlüsselung, Integritätsschutz und Authentifizierung vorhanden sein. Bei BACnet ist dafür die sichere Variante BACnet/SC relevant.
| Schnittstelle/Protokoll | Typische Anwendung |
|---|---|
| BACnet/IP | Kommunikation mit Gebäudeautomation und GLT. Eignet sich sehr gut für eine FM-Leitstellenverbindung. |
| OPC UA | Standardisierte Kommunikation zwischen Automatisierungs- und IT-Systemen. Sehr verbreiteter, ausgereifter Standard. |
| Modbus TCP | Auslesen von Messwerten aus Sensoren, Steuerungen, Energiezählern und technischen Anlagen. Einfaches Master/Slave-Konzept. |
| MQTT | Übertragung von Sensordaten und KI-Ergebnissen über einen Message Broker. Sehr verbreitet für IoT und Edge AI. |
| HTTPS, REST API | Integration in FM-Software, Dashboards und Wartungsmanagement. Sehr verbreitet in der IT-Welt. |
| SQL (Datenbank) | Zugriff auf historische Messdaten und Zeitreihen. Zusätzliche Schnittstelle für große Datenbestände in der IT-Welt. |
| SNMP | Überwachung von Netzwerkgeräten und IT-Infrastruktur. Spezielle Managementschnittstelle aus der IT-Welt. |
Gänginge Protokolle/Schnittstellen zur Sensor-Kommunikation
Ein Serverraum ist meist abgeschlossen und wird nur selten betreten. Dennoch enthält er kritische Komponenten, deren Ausfall Schäden oder Stillstände verursachen kann. Ein Softsensor kann hier mehrere Überwachungsaufgaben verbinden.
An einem Lüfter wird ein Beschleunigungssensor angebracht. Er misst Schwingungen in drei Achsen (x, y, z). Der Softsensor überführt diese Daten zyklisch per FFT (Fast-Fourier-Transformation) in ein Frequenzspektrum und bewertet sie mit einem trainierten Autoencoder. So lassen sich Unwuchten, Schleifgeräusche oder andere Veränderungen erkennen. Aus dem Frequenzspektrum kann häufig auch die Drehzahl abgeleitet werden.
Rohdaten eines Beschleunigungssensors werden von Softsensor per FFT in Frequenzspektrum überführt
Ziel ist, Wartungsbedarf oder einen drohenden Ausfall der Lüftung frühzeitig zu erkennen. Ein Totalausfall kann zur Überhitzung von IT-Komponenten oder zu einer Abschaltung führen.
Zusätzlich kann ein Mikrofon am Softsensor angeschlossen werden. Viele Komponenten in einem Serverraum signalisieren Probleme akustisch, zum Beispiel eine USV bei erforderlicher Batteriewartung. Solche Warnungen werden in einem unbesetzten Raum sonst möglicherweise nicht wahrgenommen.
Für die Auswertung werden Audiodaten in Mel-Spektrogramme überführt. Ein Autoencoder kann damit unterschiedliche Piepsequenzen erkennen und gegebenenfalls sogar zwischen zwei USVs unterscheiden. Auch andere Geräusche wie Glasbruch wären grundsätzlich als Anomalien erfassbar.
Umwandlung von Audiodaten in Mel-Spektrogramm
Akustische Anomalieerkennung am Beispiel von Glasbruch
Die Leitstelle kann die überwachten Zustände übersichtlich darstellen: Grün steht für den Normalbetrieb, Rot für eine Auffälligkeit. Damit werden Vibrationen des Lüfters und akustische Anomalien gemeinsam sichtbar.
Gerade wenn der Softsensor auch für die Überwachung sicherheitsrelevanter technischer Anlagen eingesetzt wird, sollte die Kommunikation von Anfang an sicher gestaltet werden (Security by Design). Im NIS-2-Kontext kann ein solcher Ansatz erheblich zur Umsetzung geeigneter technischer Maßnahmen beim Risikomanagement beitragen.
| Maßnahme | Zweck |
|---|---|
| TLS | Verschlüsselung und Schutz der Datenübertragung. |
| Zertifikatsbasierte Authentifizierung | Eindeutige Identifikation der Kommunikationspartner. |
| Netzwerksegmentierung | Trennung von OT, Edge AI und IT. |
| Rollen- und Rechtekonzept | Beschränkung auf erforderliche Daten und Funktionen. |
| Read-only-Zugriff | Vermeidung unbeabsichtigter Eingriffe in die Anlagensteuerung. |
| Protokollierung | Nachvollziehbarkeit von Zugriffen und Ereignissen. |
Maßnahmen für sichere Kommunikation von Softsensoren
Die Verbindung zwischen Softsensor und Leitstelle muss also unbedingt verschlüsselt sein. Vertraulichkeit, Integritätsschutz und Authentifizierung sind erforderlich. Eine falsche oder manipulierte Alarmmeldung verursacht Aufwand und Kosten, wenn Personal oder externe Dienstleister einen Serverraum prüfen müssen.
In diesem Zusammenhang ist auch die Sicherheit von Steuerungen wichtig. Sicherheitsbehörden in den USA haben auf Schwachstellen und exponierte, mit dem Internet verbundene SPSen hingewiesen. Direkt erreichbare Steuerungen sind ein erhebliches Risiko und sollten vermieden werden.
CISA-Meldung zu Gefahren bei Siemens-SPSen
Autoencoder können nicht nur Anlagenzustände, sondern auch Kommunikationsverbindungen überwachen. Ungewöhnliche Zugriffe oder Änderungen an einer SPS-Software können als Anomalie erkannt und an die FM-Leitstelle gemeldet werden. Damit ergänzt die Anomalieerkennung technische Schutzmaßnahmen, ersetzt sie jedoch nicht.
| Schutzmaßnahme | Umsetzung |
|---|---|
| Vollständige Asset-Inventarisierung | Alle installierten SPS-Baugruppen einschließlich ihrer Firmwarestände, Netzwerkschnittstellen und Kommunikationsbeziehungen erfassen. |
| Sicherheitsupdates einspielen | Kritische Sicherheitslücken durch zeitnahe Installation verfügbarer Patches schließen. |
| Netzwerkzugriffe absichern | SPS-Baugruppen dürfen nicht direkt aus dem Internet erreichbar sein. Netzwerksegmentierung und restriktive Kommunikationsregeln konsequent umsetzen. |
| Zugriffskontrollen verstärken | Authentifizierung, Berechtigungen und administrative Zugänge überprüfen und absichern. |
| Anomalien erkennen | Ungewöhnliche Zugriffe, nicht autorisierte Änderungen an SPS-Konfigurationen und verdächtige Aktivitäten kontinuierlich überwachen. |
| SPS-Dienste und Steuerungslogik härten | Nicht benötigte Dienste und Protokolle deaktivieren und die Integrität der Steuerungsprogramme sicherstellen. |
Schutzmaßnahmen für den sicheren Betrieb von SPSen
Ein klassischer Sensor misst eine physikalische Größe direkt, etwa Temperatur, Druck oder Beschleunigung. Ein Softsensor leitet zusätzliche Informationen aus bereits verfügbaren Daten ab. Dafür kombiniert er Messwerte, Zeitverläufe oder weitere Datenquellen mit einem mathematischen Modell oder einem KI-Verfahren.
Entscheidend sind ausreichend viele Daten aus dem normalen Betrieb der Anlage. Je nach Aufgabe können das beispielsweise Schwingungsdaten, Audiodaten, Temperaturen, Stromaufnahmen oder Prozesswerte sein. Die Daten müssen die üblichen Betriebszustände abdecken und vor dem Training auf offensichtliche Störungen und unpassende Ausreißer geprüft werden.
Nicht automatisch. Ein Autoencoder meldet zunächst, dass ein neues Signal deutlich vom bekannten Normalzustand abweicht. Die Fachanalyse klärt anschließend, ob etwa eine Unwucht, ein Schleifgeräusch, eine verschlissene Komponente oder ein betrieblicher Sonderfall die Ursache ist. Für bestimmte, gut bekannte Fehlerbilder lässt sich die Auswertung gezielt erweitern.
Ein Nachtraining ist sinnvoll, wenn sich die überwachte Anlage, ihre Umgebung oder ihr normaler Betrieb dauerhaft verändert. Das kann nach einem Umbau, einem Komponententausch oder bei neuen Betriebsarten der Fall sein. Regelmäßige Prüfungen der Modellgüte helfen, solche Änderungen rechtzeitig zu erkennen.
Die Verbindung braucht Verschlüsselung, Integritätsschutz und eine zuverlässige Authentifizierung der beteiligten Systeme. Unsichere Protokolle wie Modbus TCP sollten nicht ungeschützt über größere Entfernungen eingesetzt werden. Je nach Infrastruktur kommen beispielsweise BACnet/SC, OPC UA, MQTT mit TLS oder abgesicherte HTTPS-Schnittstellen infrage.
Er ist bei SSV unter anderem für die Geschäftsführung zuständig und beschäftigt sich intensiv mit innovativen technischen Themen. Er ist durch zahlreiche Vorträge auf internationalen Veranstaltungen, Seminaren, Workshops und Artikel in Fachzeitschriften bekannt. Klaus-Dieter Walter hat vier Bücher zu den Themen Embedded Linux, Embedded Internet und ARM-basierte Mikrocontroller veröffentlicht.

SSV SOFTWARE SYSTEMS
Dünenweg 5
30419 Hannover
Fon: +49(0)511 · 40 000-0
Fax: +49(0)511 · 40 000-40
Impressum · Datenschutz · AGB
© 2026 SSV SOFTWARE SYSTEMS GmbH // Alle Rechte vorbehalten.
ISO 9001:2015