IIoT-Alarmflut vermeiden: Hysterese und Verzögerung richtig parametrieren

→ Produktkategorie: IIoT-Lösungen

 

Ein Drucksensor überwacht einen Filter und soll bei 2,0 bar Differenzdruck einen Alarm auslösen. Der reale Messwert schwankt jedoch zwischen 1,98 und 2,03 bar. Ohne geeignete Alarmparametrierung kann daraus innerhalb weniger Minuten eine Folge aus:

Alarm → Rückkehr zu Normal → Alarm → Rückkehr zu Normal

entstehen.

Das Problem liegt dabei häufig weder am Sensor noch an der IIoT-Plattform. Ursache ist vielmehr eine Alarmgrenze ohne ausreichend Totband beziehungsweise Hysterese, eine ungeeignete Verzögerung oder eine Rücksetzlogik, die nicht zur Dynamik des überwachten Prozesses passt.

In größeren Condition-Monitoring-Systemen kann sich dieser Effekt vervielfachen. Wenn hunderte Messstellen Temperatur, Druck, Füllstand, Vibration oder andere Zustandsgrößen überwachen, können einzelne unruhige Sensoren tausende Ereignisse erzeugen. Werden diese ungefiltert über Edge, MQTT, SCADA und Cloud weitergegeben, entstehen unnötige Meldungen, Datenbankeinträge und Benachrichtigungen. Kritische Alarme können dadurch zwischen unbedeutenden Meldungen untergehen.

Eine zuverlässige Alarmierung benötigt deshalb mehr als einen Grenzwert. Alarmgrenze, Hysterese, Einschaltverzögerung, Ausschaltverzögerung, Rücksetzbedingung, Priorität und Eskalationslogik müssen gemeinsam zur Prozessdynamik und zur erforderlichen Reaktion passen.

ICS Schneider unterstützt bei der herstellerübergreifenden Integration von Sensorik, Edge-Gateways und IT/OT-Systemen. Die IIoT-Lösungen von ICS Schneider verbinden beispielsweise Feldgeräte über Modbus RTU, HART, IO-Link oder Ethernet mit Edge-Systemen und übertragen Daten über MQTT beziehungsweise HTTPS in SCADA-, Historian- oder Cloud-Anwendungen.

Warum Alarmfluten im Condition Monitoring entstehen

Ein moderner Sensor kann innerhalb kurzer Zeit sehr viele Messwerte bereitstellen.

Die Anzahl der Messwerte ist jedoch nicht gleichbedeutend mit der Anzahl sinnvoller Alarme.

Typische Ursachen für unnötig viele Alarmmeldungen sind:

• Alarmgrenze liegt zu nahe am normalen Arbeitspunkt,
• kein beziehungsweise zu kleines Totband,
• keine zeitliche Verzögerung,
• stark schwankendes Messsignal,
• ungeeignete Abtastrate,
• instabiler Prozess,
• ungeeignete Sensorposition,
• fehlende Betriebszustandslogik,
• mehrere Folgealarme für dieselbe Ursache,
• Kommunikationsfehler werden wie Prozessalarme behandelt,
• Alarm wird nach kurzer Normalisierung sofort erneut freigegeben.

Ein häufiger Denkfehler lautet

Jede Grenzwertüberschreitung muss sofort einen Alarm erzeugen.

Für bestimmte sicherheitsrelevante Funktionen kann eine sehr schnelle Reaktion notwendig sein.

Bei Condition Monitoring geht es dagegen häufig darum, einen Zustand zu erkennen, der:

• relevant,
• anhaltend,
• reproduzierbar und
• handlungsbedürftig

ist.

Eine Schwankung von wenigen Millisekunden oder ein einzelner Ausreißer ist nicht automatisch ein sinnvoller Alarm.

Alarm, Event und Messwertänderung unterscheiden

Für eine saubere IIoT-Architektur sollte zwischen unterschiedlichen Informationsarten unterschieden werden.

Information	Bedeutung	Typische Reaktion
Messwert	normaler Prozesswert	speichern, visualisieren oder verdichten
Event	relevantes Ereignis ohne zwingende Bedieneraktion	protokollieren
Warnung	Zustand entwickelt sich ungünstig	beobachten oder Wartung planen
Alarm	abnormaler Zustand erfordert eine definierte Reaktion	Bediener beziehungsweise Verantwortlichen informieren
Störung	Mess- oder Kommunikationskette funktioniert nicht korrekt	Diagnose beziehungsweise Instandhaltung

Nicht jede Information, die technisch übertragen werden kann, sollte als Alarm behandelt werden.

Diese Trennung ist besonders in IIoT-Systemen wichtig, weil Sensor, Edge-Gateway, Broker, Datenbank, Dashboard und Benachrichtigungsdienst jeweils weitere Meldungen erzeugen können.

Was bedeutet Alarm Flapping oder Chattering?

Als Alarm Flapping beziehungsweise Chattering wird ein Verhalten bezeichnet, bei dem ein Alarm innerhalb kurzer Zeit wiederholt zwischen:

aktiv

und:

normal

wechselt.

Typisches Beispiel

Alarmgrenze:

80 °C

Messwerte:

79,9 → 80,1 → 79,8 → 80,2 → 79,9 °C

Ohne Hysterese könnte daraus entstehen:

Normal → Alarm → Normal → Alarm → Normal

Innerhalb weniger Sekunden kann somit eine Vielzahl von Ereignissen entstehen, obwohl sich der reale Anlagenzustand praktisch nicht verändert hat.

Das Problem betrifft nicht nur die Anzeige

Jeder Zustandswechsel kann zusätzlich:

• einen MQTT-Alarm erzeugen,
• einen Historian-Eintrag schreiben,
• eine E-Mail versenden,
• eine Push-Nachricht erzeugen,
• ein Ticket erstellen,
• eine Eskalation starten.

Aus einer kleinen Messwertschwankung kann dadurch eine betriebliche Alarmflut entstehen.

Alarmgrenze richtig festlegen

Bevor über Hysterese oder Verzögerungen gesprochen wird, muss zunächst die Alarmgrenze selbst sinnvoll gewählt werden.

Sie sollte nicht einfach aus dem normalen Arbeitspunkt abgeleitet werden.

Unterschieden werden sollten beispielsweise

normaler Betriebsbereich

zulässige Schwankung

Bereich mit erhöhtem Verschleiß

Handlungsgrenze

technische beziehungsweise sicherheitsrelevante Grenze

Beispiel Lagertemperatur

Normal:

55 … 65 °C

zeitweise zulässig:

bis 70 °C

Wartungshinweis:

75 °C

Alarm:

85 °C

Eine Alarmgrenze von:

66 °C

wäre in diesem Beispiel möglicherweise technisch messbar, würde aber den normalen Prozessbetrieb ständig als abnormal melden.

Hysterese und Totband richtig einsetzen

Die Hysterese sorgt dafür, dass für das Aktivieren und Rücksetzen eines Alarms unterschiedliche Messwerte gelten.

Bei einem High-Alarm kann beispielsweise gelten:

Alarm EIN bei ≥ 100 bar

und:

Alarm AUS erst bei ≤ 95 bar

Die Hysterese beträgt dann:

5 bar

Vereinfacht

für einen High-Alarm:

Rücksetzgrenze = Alarmgrenze − Hysterese

Für einen Low-Alarm:

Rücksetzgrenze = Alarmgrenze + Hysterese

Hysterese verhindert Grenzwertflattern

Der Messwert darf nach einer Alarmierung innerhalb des Totbandes schwanken, ohne dass der Alarm sofort zurückgesetzt wird.

Dadurch wird aus:

99,9 → 100,1 → 99,8 → 100,2 bar

nicht zwangsläufig eine wiederholte Folge von Alarmmeldungen.

Totband und Hysterese werden häufig synonym verwendet

In vielen Alarmfunktionen beschreibt das Alarmtotband die notwendige Signaländerung vom Alarmgrenzwert zurück in Richtung Normalzustand, bevor der Alarm wieder normal wird.

Die genaue Parametrierung hängt jedoch von der verwendeten SPS, Edge-Plattform oder Software ab.

Praxisbeispiel für einen High-Alarm mit Hysterese

Ein Hydrauliksystem besitzt einen High-Alarm bei:

250 bar

Hysterese:

10 bar

Alarmierung

Sobald der Messwert:

≥ 250 bar

erreicht, wird der Alarm aktiv.

Rücksetzung

Der Alarm wird erst wieder normal, wenn der Druck auf:

≤ 240 bar

zurückgeht.

Zwischen 240 und 250 bar

bleibt der zuletzt erreichte Zustand bestehen.

Damit können kleine Druckschwankungen direkt an der Alarmgrenze keinen ständigen Zustandswechsel erzeugen.

Delay-On: Einschaltverzögerung richtig verwenden

Eine Einschaltverzögerung bedeutet, dass der Messwert eine Alarmbedingung für eine bestimmte Mindestzeit erfüllen muss, bevor tatsächlich ein Alarm erzeugt wird.

Beispiel

Alarmgrenze:

80 °C

Delay-On:

10 s

Dann wird nicht sofort bei:

80,1 °C

alarmiert.

Der Wert muss zunächst für:

10 s

durchgehend in der Alarmbedingung bleiben.

Ein kurzzeitiger Ausschlag

von beispielsweise:

3 s

wird nicht als Alarm ausgegeben.

Delay-On ist sinnvoll

wenn kurzzeitige Grenzwertüberschreitungen:

• prozessbedingt auftreten,
• keine Bedieneraktion erfordern,
• für den überwachten Zustand nicht relevant sind.

Delay-On darf jedoch nicht verwendet werden

um eine erforderliche schnelle Reaktion künstlich zu verzögern.

Die Verzögerung muss immer kürzer sein als die Zeit, innerhalb derer eine notwendige Reaktion noch wirksam erfolgen kann.

Delay-Off: Ausschaltverzögerung richtig verwenden

Bei einer Ausschaltverzögerung bleibt ein bereits aktiver Alarm noch für eine definierte Zeit aktiv, nachdem die eigentliche Alarmbedingung nicht mehr erfüllt ist.

Beispiel

Alarm:

Druck > 10 bar

Delay-Off:

20 s

Sinkt der Druck kurzzeitig auf:

9,9 bar

wird der Alarm nicht sofort zurückgesetzt.

Erst wenn der Normalzustand ausreichend lange besteht, erfolgt die Rücksetzung.

Delay-Off kann sinnvoll sein

wenn ein erkannter Zustand als relevant gilt, auch wenn das Messsignal kurzzeitig wieder in den Normalbereich zurückkehrt.

Dadurch lässt sich insbesondere wiederholtes An- und Abmelden eines bereits relevanten Alarms vermeiden.

Hysterese, Delay-On und Delay-Off vergleichen

Funktion	Wirkt auf	Typischer Nutzen
Hysterese / Deadband	Messwert	verhindert Flattern um eine analoge Grenze
Delay-On	Zeit bis Alarmaktivierung	ignoriert kurze Grenzwertverletzungen
Delay-Off	Zeit bis Alarmrücksetzung	verhindert zu schnelles Rücksetzen und erneutes Alarmieren
Messwertfilter	Eingangssignal	reduziert hochfrequentes Rauschen

Die vier Funktionen sind nicht austauschbar.

Ein verrauschtes Sensorsignal sollte beispielsweise nicht ausschließlich durch eine minutenlange Alarmverzögerung kaschiert werden.

Rücksetzlogik festlegen

Eine Alarmstrategie benötigt neben der Einschaltbedingung immer eine eindeutig definierte Rücksetzbedingung.

Mögliche Varianten sind

• automatische Rücksetzung bei Rückkehr in den Normalbereich,
• Rücksetzung erst nach Hysterese,
• Rücksetzung erst nach Ablauf einer Mindestzeit,
• manuelle Rücksetzung,
• manuelle Rücksetzung erst nach beseitigter Ursache.

Automatische Rücksetzung

ist für viele normale Condition-Monitoring-Alarme geeignet.

Manuelle Rücksetzung

kann sinnvoll sein, wenn ein einmal aufgetretener Zustand auch dann bewusst geprüft werden soll, wenn der aktuelle Messwert bereits wieder normal ist.

Beispielsweise:

• Überdrehzahl,
• extreme Temperaturüberschreitung,
• kritischer Druckstoß,
• Trockenlauf,
• einmalige Schutzabschaltung.

Quittierung und Rücksetzung nicht verwechseln

Die Quittierung bestätigt:

Die Meldung wurde vom Bediener wahrgenommen.

Sie bedeutet nicht:

Die Ursache ist beseitigt.

Beispiel

Ein Lager überschreitet die Alarmtemperatur.

Der Bediener quittiert den Alarm.

Die Temperatur bleibt jedoch weiterhin zu hoch.

Der Zustand sollte deshalb weiterhin als:

Alarm aktiv

sichtbar bleiben.

Erst wenn die Rücksetzbedingung erfüllt ist, wechselt der Prozesszustand zurück auf normal.

Wann eine speichernde Alarmfunktion sinnvoll ist

Bei einer speichernden beziehungsweise latched Alarmfunktion bleibt der Alarmzustand gespeichert, auch wenn die ursprüngliche Auslösebedingung bereits verschwunden ist.

Das kann sinnvoll sein

wenn kurzzeitige kritische Ereignisse später nachvollzogen werden müssen.

Beispiel:

Drehzahl > maximal zulässige Drehzahl

Die Überdrehzahl tritt nur für:

0,5 s

auf.

Anschließend steht die Maschine.

Eine rein automatisch rücksetzende Anzeige könnte danach nur noch:

0 rpm

anzeigen.

Der relevante Vorfall wäre damit für den Bediener möglicherweise nicht mehr unmittelbar erkennbar.

Alarmprioritäten sinnvoll vergeben

Nicht alle Alarme besitzen dieselbe Dringlichkeit.

Eine sinnvolle Priorisierung orientiert sich insbesondere an:

• möglichen Folgen,
• verfügbarer Reaktionszeit,
• notwendiger Bedieneraktion.

Beispielhafte Einteilung

Priorität	Beispiel	Reaktion
Hinweis	Filterverschmutzung beginnt	bei nächster Wartung prüfen
Warnung	Trend zeigt deutliche Verschlechterung	Wartung einplanen
Alarm	Betriebsgrenze überschritten	zeitnah reagieren
Kritisch	unmittelbare Anlagengefährdung	sofortige Reaktion erforderlich

Wenn nahezu jede Meldung die höchste Priorität besitzt, verliert die Priorisierung ihren Nutzen.

Eskalation zeitlich staffeln

Nicht jeder Alarm muss sofort gleichzeitig an:

• Bediener,
• Schichtleiter,
• Instandhaltung,
• Betriebsleiter,
• externen Service

versendet werden.

Eine Eskalationslogik kann beispielsweise lauten

Alarm tritt auf

→ lokale Anzeige

→ nach 5 min ohne Reaktion Meldung an Instandhaltung

→ nach weiteren 15 min bei weiterhin bestehendem Alarm Eskalation

Die konkreten Zeiten müssen zur Anwendung passen.

Wichtig

Eine Eskalationsverzögerung ist keine Alarmverzögerung.

Der Alarm kann bereits eindeutig aktiv sein, während lediglich seine Weiterleitung stufenweise erfolgt.

Sensorrauschen nicht mit Alarmparametern verstecken

Wenn ein Sensor stark schwankt, sollte zuerst geprüft werden, ob das Signal physikalisch plausibel ist.

Mögliche Ursachen für unruhige Signale sind

• elektrische Störungen,
• schlechte Schirmung,
• unzureichende Erdung,
• mechanische Vibrationen,
• Druckpulsationen,
• ungünstige Sensorposition,
• Luftblasen,
• Turbulenzen,
• instabiler Prozess,
• falscher Messbereich.

Eine große Hysterese kann das daraus resultierende Alarmflattern reduzieren.

Sie behebt aber nicht die eigentliche Ursache des instabilen Messwerts.

Alarmparameter sollten einen realen Prozess sinnvoll bewerten – nicht fehlerhafte Messtechnik unsichtbar machen.

Messwertfilter und Alarmhysterese unterscheiden

Ein Messwertfilter verändert das Signal, auf dessen Basis später möglicherweise ein Alarm berechnet wird.

Eine Hysterese verändert dagegen lediglich die Umschaltbedingungen des Alarms.

Beispiel gleitende beziehungsweise tiefpassartige Glättung

Rohsignal:

49 → 55 → 48 → 52 → 50 bar

Gefiltertes Signal:

49 → 51 → 50 → 51 → 50 bar

Damit wird bereits der ausgewertete Prozesswert geglättet.

Problem bei zu starker Filterung

Reale schnelle Änderungen können verzögert dargestellt werden.

Deshalb sollten:

• Sensorfilter,
• SPS-Filter,
• Edge-Filter,
• Alarmverzögerung

nicht unkontrolliert hintereinander geschaltet werden.

Die resultierende Gesamtverzögerung muss bekannt sein.

Rate-of-Change-Alarme richtig einsetzen

Nicht nur ein absoluter Messwert kann auf einen kritischen Zustand hinweisen.

Auch die Änderungsgeschwindigkeit kann relevant sein.

Vereinfacht:

Änderungsrate = ΔMesswert / ΔZeit

Beispiel

Eine Lagertemperatur steigt von:

55 °C

auf:

70 °C

innerhalb von:

5 min

Dann beträgt die mittlere Änderung:

3 °C/min

Der absolute Alarmgrenzwert von:

85 °C

ist noch nicht erreicht.

Der steile Temperaturanstieg kann trotzdem auf ein sich entwickelndes Problem hinweisen.

Rate-of-Change-Alarme benötigen ebenfalls Entprellung

Bei verrauschten Signalen kann die numerische Ableitung stark schwanken.

Deshalb sind:

• geeignete Zeitfenster,
• Plausibilitätsgrenzen,
• Filterung,
• Mindestdauer

besonders wichtig.

Warnung, Alarm und kritischen Alarm trennen

Ein einzelner Grenzwert reicht für Condition Monitoring häufig nicht aus.

Beispiel Differenzdruck eines Filters

< 1,5 bar → normal

≥ 1,5 bar → Wartungshinweis

≥ 1,8 bar → Warnung

≥ 2,0 bar → Alarm

Damit kann eine Wartung geplant werden, bevor der Prozess tatsächlich eine kritische Grenze erreicht.

Die einzelnen Stufen benötigen nicht zwangsläufig dieselbe Logik

Ein Wartungshinweis kann beispielsweise:

• große Verzögerung,
• größere Hysterese,
• keine sofortige Push-Nachricht

verwenden.

Ein kritischer Alarm kann dagegen:

• kleine oder keine Verzögerung,
• klare Eskalation,
• speichernde Meldung

erfordern.

Zustandsabhängige Alarmierung

Ein Sensorwert ist nicht in jedem Maschinenzustand gleich zu bewerten.

Beispiel Pumpendruck

Während normalem Betrieb:

Druck < 3 bar → möglicher Alarm

Bei ausgeschalteter Pumpe:

Druck = 0 bar → normal

Eine Alarmregel, die ausschließlich:

Druck < 3 bar

auswertet, würde bei jedem regulären Maschinenstillstand einen Alarm erzeugen.

Deshalb kann eine zusätzliche Bedingung erforderlich sein

Pumpe läuft UND Druck < 3 bar

erst dann:

Low-Pressure-Alarm

Weitere relevante Betriebszustände können sein

• Anfahren,
• Abfahren,
• Produktion,
• Reinigung,
• Wartung,
• Standby,
• Produktwechsel.

Eine zustandsabhängige Alarmierung kann in komplexen Anlagen erheblich mehr unnötige Meldungen verhindern als eine immer größere Hysterese.

Alarmunterdrückung gezielt einsetzen

Bestimmte Alarme können in definierten Anlagenzuständen irrelevant sein.

Beispielsweise benötigt eine stillgesetzte Maschine keine:

Drehzahl zu niedrig

-Alarmierung.

Eine geplante Unterdrückung kann deshalb sinnvoll sein

Typische Fälle:

• Maschine außer Betrieb,
• Sensor in Wartung,
• Anfahrphase,
• bekannter Testbetrieb,
• übergeordnete Störung macht Folgealarme bedeutungslos.

Unterdrückung darf nicht zum dauerhaften Verstecken problematischer Alarme werden

Ein unterdrückter Alarm sollte nachvollziehbar:

• begründet,
• zeitlich beziehungsweise zustandsabhängig definiert,
• protokolliert

sein.

Warum Alarmierung möglichst nahe am Prozess erfolgen sollte

In einer typischen IIoT-Architektur können die Daten folgenden Weg nehmen:

Sensor → Feldbus → Edge-Gateway → MQTT → Broker → Cloud → Alarmservice

Wenn eine kritische Alarmentscheidung erst in der Cloud erfolgt, hängt die Reaktionszeit zusätzlich von:

• Feldbuszyklus,
• Gateway-Verarbeitung,
• Netzwerkverbindung,
• Broker,
• Cloud-Verarbeitung

ab.

Für zeitkritische Funktionen

ist deshalb eine lokale Alarmverarbeitung im:

• Sensor,
• IO-Link-Master,
• SPS beziehungsweise Steuerung oder
• Edge-Gateway

oft sinnvoll.

Die Cloud kann anschließend für:

• Visualisierung,
• Historie,
• Analyse,
• Reporting,
• Eskalation

verwendet werden.

Sicherheitstechnische Abschaltungen dürfen nicht von einer gewöhnlichen Cloud-Verbindung abhängig gemacht werden, wenn dafür eine dafür vorgesehene lokale Schutzfunktion erforderlich ist.

Zeitstempel im IIoT-System richtig behandeln

Für eine spätere Ursachenanalyse ist nicht nur der Alarm selbst wichtig.

Entscheidend ist auch:

Wann ist der Zustand tatsächlich aufgetreten?

Problem

Eine Netzwerkverbindung fällt für zehn Minuten aus.

Das Edge-Gateway puffert Messwerte lokal.

Nach Wiederverbindung werden alle Werte übertragen.

Würde die Cloud lediglich den Empfangszeitpunkt verwenden, könnten zehn Minuten alte Ereignisse scheinbar gleichzeitig auftreten.

Deshalb sollte ein Datensatz möglichst einen eindeutigen Messzeitpunkt besitzen

Beispielsweise:

timestamp = Zeitpunkt der Erfassung am Edge

und zusätzlich gegebenenfalls:

received_at = Zeitpunkt des Empfangs im Zielsystem

Für mehrere Geräte ist eine synchronisierte Zeitbasis wichtig

Damit lässt sich beispielsweise feststellen:

Pumpe fällt aus → Druck sinkt → Durchfluss sinkt → Temperatur steigt

und nicht nur, in welcher Reihenfolge die Daten zufällig über das Netzwerk eingetroffen sind.

Kommunikationsausfall nicht als Prozessalarm behandeln

Ein fehlender Messwert kann verschiedene Ursachen besitzen:

• Sensor defekt,
• Kabelbruch,
• Feldbus gestört,
• Gateway offline,
• Mobilfunkverbindung ausgefallen,
• Broker nicht erreichbar.

Das ist nicht automatisch dasselbe wie

Prozesswert = 0

.

Ein ausgefallener Füllstandsensor darf beispielsweise nicht automatisch als:

Tank leer

interpretiert werden.

Messwert und Qualitätsstatus sollten deshalb getrennt übertragen werden

Beispielsweise:

value = 62.3

quality = good

oder:

quality = bad

Damit können getrennte Alarme entstehen

Füllstand zu niedrig

und:

Füllstandsmessung nicht verfügbar

Diese beiden Meldungen besitzen völlig unterschiedliche Ursachen und Reaktionen.

MQTT-Ereignisse und Alarme sinnvoll trennen

In MQTT-basierten Systemen kann eine klare Datenstruktur die spätere Auswertung erheblich vereinfachen.

Beispielsweise

site/werk1/line1/device/pump01/pressure/value

site/werk1/line1/device/pump01/status

site/werk1/line1/device/pump01/alarm

Messwerttelegramme

können regelmäßig oder bei relevanter Änderung übertragen werden.

Alarmereignisse

sollten dagegen einen eindeutigen Zustandswechsel dokumentieren.

Beispielsweise:

alarm_state = active

alarm_state = acknowledged

alarm_state = cleared

Damit muss die Cloud nicht aus jedem einzelnen Rohmesswert erneut rekonstruieren, welcher Alarmzustand am Edge bestanden hat.

Ereignisrate und Datenvolumen reduzieren

Eine hohe Abtastrate bedeutet nicht automatisch, dass jeder Messwert übertragen werden muss.

Beispiel

Sensorabtastung:

10 Hz

Das entspricht:

864.000 Messwerten pro Tag

pro Messstelle.

Für einen langsam veränderlichen Tankfüllstand wäre diese Datenmenge häufig unnötig.

Mögliche Strategien sind

• größeres Abtastintervall,
• Publish-on-Change,
• Delta-Schwelle,
• periodischer Heartbeat,
• Min-/Max-/Mittelwertbildung,
• lokale Trendberechnung.

Beispiel Publish-on-Change

Messwert wird übertragen, wenn:

|xneu − xzuletzt| ≥ Δx

oder wenn:

maximale Übertragungszeit erreicht

ist.

Dadurch bleiben Änderungen sichtbar, ohne identische oder nahezu identische Werte ständig zu übertragen.

Alarmqualität mit Kennzahlen überwachen

Ein Alarmkonzept ist nach der Inbetriebnahme nicht abgeschlossen.

Die tatsächlich auftretenden Meldungen sollten ausgewertet werden.

Sinnvolle Kennzahlen können sein

• Alarme pro Stunde beziehungsweise Schicht,
• Anzahl wiederkehrender Alarme,
• häufigste Alarmquellen,
• Anzahl kurzzeitiger Alarme,
• mittlere Alarmdauer,
• Anzahl nicht quittierter Alarme,
• Anzahl unterdrückter Alarme,
• Alarmrate während Anlagenstörungen.

Besonders interessant sind sogenannte Bad Actors

Wenn beispielsweise:

5 von 500 Messstellen

mehr als die Hälfte aller Alarmereignisse verursachen, sollte zuerst untersucht werden, warum gerade diese Messstellen auffällig sind.

Die Ursache kann sein:

• schlechte Parametrierung,
• instabiler Prozess,
• Sensorproblem,
• fehlende Betriebszustandslogik.

Praxisbeispiel: Differenzdruck am Filter

Ein Filter wird über einen Differenzdrucksensor überwacht.

Normaler Betrieb

0,4 … 1,4 bar

Wartungsgrenze

1,6 bar

Alarmgrenze

2,0 bar

Problem

Durch pulsierenden Volumenstrom schwankt der Messwert kurzfristig um:

±0,08 bar

Ungeeignete Parametrierung

Alarm EIN bei 2,00 bar

Alarm AUS bei 1,99 bar

keine Verzögerung

Der Alarm kann dadurch mehrfach pro Minute wechseln.

Robustere Strategie

Beispielsweise:

Alarm EIN bei ≥ 2,00 bar

Delay-On = 10 s

Hysterese = 0,15 bar

Alarm AUS bei ≤ 1,85 bar

Damit

werden kurze Druckspitzen ignoriert und ein aktiver Alarm erst nach einer deutlichen Verbesserung des Filterzustands zurückgesetzt.

Die konkreten Werte müssen anhand der tatsächlichen Prozessdynamik, zulässigen Filterbelastung und erforderlichen Reaktionszeit festgelegt werden.

Praxisbeispiel: Temperaturüberwachung

Ein Elektromotor wird über einen Temperatursensor überwacht.

Normal:

60 … 75 °C

Warnung:

≥ 85 °C

Alarm:

≥ 95 °C

Temperatur besitzt eine vergleichsweise langsame Dynamik

Ein einzelner kurzzeitiger Messwert von:

95,1 °C

kann beispielsweise durch einen elektrischen Störimpuls entstehen.

Eine Alarmbedingung wie:

Temperatur ≥ 95 °C für 15 s

kann in einer entsprechenden Anwendung robuster sein.

Zusätzlich kann eine Trendwarnung sinnvoll sein

wenn die Temperatur beispielsweise ungewöhnlich schnell steigt, obwohl die absolute Alarmgrenze noch nicht erreicht ist.

Praxisbeispiel: Füllstand mit unruhiger Oberfläche

Ein Radar- oder Ultraschallsensor misst den Füllstand eines Behälters.

Durch:

• Rührwerk,
• Wellenbewegung,
• Befüllstrahl,
• Schaum

kann der Messwert schwanken.

High-Level-Alarm

90 %

Ohne Totband könnte:

89,8 → 90,2 → 89,7 → 90,1 %

zu wiederholten Alarmen führen.

Mögliche Strategie

Alarm EIN ≥ 90 %

Alarm AUS ≤ 88 %

zusätzlich beispielsweise:

Delay-On = 5 s

Die Werte sind nur beispielhaft und müssen zur zulässigen Füllhöhe und Dynamik des Tanks passen.

Praxisbeispiel: Condition Monitoring an einer Maschine

Bei einer Vibrationsüberwachung können einzelne Peaks durch:

• Lastwechsel,
• Anfahren,
• Abfahren,
• mechanischen Schlag

entstehen.

Eine reine Momentangrenze

kann dadurch sehr viele Warnungen erzeugen.

Je nach Messgröße kann stattdessen relevant sein

• RMS-Wert,
• Peak-Wert,
• Trend über mehrere Messungen,
• Änderungsrate,
• Betriebszustand der Maschine.

Eine Grenzwertverletzung während des regulären Hochlaufs kann beispielsweise anders bewertet werden als dieselbe Vibrationsamplitude bei stationärer Drehzahl.

Condition Monitoring benötigt deshalb häufig eine Kombination aus Messwert, Zeit und Maschinenzustand.

Typische Fehlerbilder bei IIoT-Alarmen

Beobachtung	Mögliche Ursache	Sinnvolle Prüfung
Alarm schaltet ständig ein und aus	Hysterese zu klein	Messwertstreuung um Grenzwert analysieren
Sehr kurze Alarme treten häufig auf	fehlendes Delay-On	Dauer realer Grenzwertverletzungen auswerten
Alarm kommt unmittelbar nach Rücksetzung erneut	fehlendes Totband oder Delay-Off	Rücksetzlogik prüfen
Alarm erscheint deutlich zu spät	zu große Filterung oder Verzögerung	Gesamtreaktionszeit der Messkette bestimmen
Viele Alarme beim Maschinenstart	Betriebszustand nicht berücksichtigt	zustandsabhängige Freigabelogik verwenden
Bei Kommunikationsausfall erscheinen Prozessalarme	fehlender Qualitätsstatus	Messwert und Kommunikationsstatus trennen
Nach Netzwerkausfall kommen viele Alarme gleichzeitig	Zeitstempel erst in Cloud erzeugt	Timestamp an Sensor beziehungsweise Edge erzeugen
Ein einzelner Sensor erzeugt sehr viele Meldungen	Bad Actor	Signal, Grenzwert, Hysterese und Sensorzustand prüfen
Alle Meldungen besitzen hohe Priorität	fehlende Alarmrationalisierung	Folge und Reaktionszeit je Alarm bewerten
Alarm wird quittiert und verschwindet trotz weiter bestehender Störung	Quittierung und Rücksetzung gekoppelt	Alarmzustand und Quittierstatus trennen
Cloud zeigt andere Ereignisreihenfolge als SPS	unterschiedliche Zeitbasen	NTP/PTP beziehungsweise Zeitstempelkonzept prüfen
Messwert wirkt stabil, Alarm reagiert trotzdem spät	mehrere Filter und Verzögerungen in Reihe	gesamte Signalkette analysieren
Alarmgrenze muss ständig angepasst werden	unterschiedliche Betriebszustände	zustandsabhängige Alarmgrenzen prüfen

Alarmparameter systematisch auslegen

1. Messgröße definieren: Druck, Temperatur, Füllstand, Vibration oder andere Zustandsgröße eindeutig festlegen.
2. Normalbereich bestimmen: Messdaten aus stabilem Anlagenbetrieb auswerten.
3. Messwertstreuung erfassen: Rauschen und normale Prozessschwankung voneinander unterscheiden.
4. Handlungsbedürftigen Zustand definieren: Nicht jede Abweichung zum Alarm erklären.
5. Alarmgrenze festlegen: Grenze aus Prozess- und Anlagenanforderung ableiten.
6. Reaktionszeit festlegen: Bestimmen, wie schnell auf den Alarm reagiert werden muss.
7. Hysterese dimensionieren: Größer als typische kleine Schwankungen um den Grenzwert wählen, ohne relevante Zustandsänderungen zu verschleiern.
8. Delay-On prüfen: Nur einsetzen, wenn kurzzeitige Grenzwertverletzungen keine Aktion erfordern.
9. Delay-Off prüfen: Ein schnelles Rücksetzen und erneutes Alarmieren verhindern, wenn dies für die Anwendung sinnvoll ist.
10. Rücksetzbedingung definieren: Automatisch, zeitverzögert oder manuell.
11. Quittierlogik festlegen: Wahrnehmung und Prozesszustand getrennt behandeln.
12. Priorität vergeben: Konsequenz und verfügbare Reaktionszeit bewerten.
13. Betriebszustände berücksichtigen: Start, Stopp, Wartung und Produktion getrennt bewerten.
14. Qualitätsstatus integrieren: Sensor- beziehungsweise Kommunikationsfehler getrennt erfassen.
15. Zeitstempel definieren: Ereigniszeit möglichst nahe an der Quelle erzeugen.
16. Benachrichtigung festlegen: Dashboard, E-Mail, Push, SMS oder Ticket nur bei entsprechendem Nutzen.
17. Eskalationsstufen definieren: Nicht jede Person bei jedem Alarm gleichzeitig informieren.
18. Alarmhistorie auswerten: Häufige und flatternde Alarme identifizieren.
19. Bad Actors beseitigen: Ursachen statt nur Symptome behandeln.
20. Änderungen dokumentieren: Grenzwerte, Hysterese, Zeiten und Verantwortlichkeiten nachvollziehbar halten.

IIoT-Lösungen bei ICS Schneider

ICS Schneider bietet IIoT-Lösungen von der Feldmessung bis zur Anbindung an IT- und Cloud-Systeme.

Typische Architektur

Sensor → Edge-Gateway → MQTT/HTTPS → SCADA / Cloud / BI

Je nach Messstelle können Feldgeräte beispielsweise über:

• RS-485 / Modbus RTU,
• HART,
• IO-Link,
• OPC UA,
• Ethernet

eingebunden werden.

Für drahtlose beziehungsweise standortferne Anwendungen können abhängig von der Architektur unter anderem:

• LoRaWAN,
• WLAN,
• LTE,
• 5G

eingesetzt werden.

Edge-Verarbeitung ist für Alarmmanagement besonders interessant

Ein Edge-System kann Messwerte beispielsweise:

• skalieren,
• mit Zeitstempeln versehen,
• filtern,
• auf Plausibilität prüfen,
• lokal alarmieren,
• bei Kommunikationsausfall puffern.

Damit muss nicht jeder einzelne Rohmesswert ungefiltert in die Cloud übertragen werden.

IIoT-Drucküberwachung

Unter IIoT-Drucküberwachung bietet ICS Schneider Lösungen zur Integration von Druck- und Differenzdrucksensoren in Edge-, SCADA- und Cloud-Systeme.

Typische Anwendungen sind:

• Filterüberwachung,
• Pumpenüberwachung,
• Druckluftmonitoring,
• Prozessdruck,
• Differenzdruck.

IIoT-Temperaturüberwachung

Die IIoT-Temperaturüberwachung verbindet beispielsweise RTD-, Thermoelement- und Transmitterlösungen mit Edge- beziehungsweise Cloud-Systemen.

Gerade bei:

• Motoren,
• Lagern,
• Ölen,
• Schaltschränken,
• Prozessanlagen

können Kombinationen aus absolutem Grenzwert und Trendbewertung für Condition Monitoring sinnvoll sein.

IIoT-Füllstandüberwachung

Bei Tank- und Behälteranwendungen lassen sich kontinuierliche Füllstandwerte, Grenzwerte und Statusinformationen in eine übergeordnete IIoT-Architektur integrieren.

Auch hier sollten Messwert, Warnung, Alarm und Sensorstatus klar voneinander getrennt werden.

Fazit

Alarmfluten entstehen häufig nicht deshalb, weil zu viele Sensoren installiert sind, sondern weil aus zu vielen Messwertänderungen ungefiltert Alarme erzeugt werden.

Die Alarmgrenze allein reicht nicht

Eine robuste Alarmfunktion berücksichtigt zusätzlich:

• Hysterese,
• Verzögerung,
• Rücksetzlogik,
• Betriebszustand,
• Priorität.

Hysterese verhindert Flattern an der Alarmgrenze

Für einen High-Alarm kann beispielsweise gelten:

Alarm EIN bei 100

und:

Alarm AUS erst bei 95

Damit führen kleine Schwankungen nicht ständig zu neuen Alarmwechseln.

Delay-On unterdrückt kurze, nicht relevante Grenzwertüberschreitungen

Der Alarm wird nur aktiviert, wenn die Bedingung ausreichend lange bestehen bleibt.

Delay-Off verhindert zu schnelles Rücksetzen

Ein bereits erkannter Alarm bleibt aktiv, bis der Normalzustand stabil genug besteht.

Quittierung und Rücksetzung sind unterschiedliche Funktionen

Die Quittierung bestätigt die Wahrnehmung des Alarms. Die Rücksetzung bestätigt dagegen, dass die Alarmbedingung nicht mehr besteht beziehungsweise die definierte Reset-Bedingung erfüllt wurde.

In IIoT-Systemen gehört auch die Datenarchitektur zum Alarmmanagement

Zeitstempel, Datenqualität, Messwertstatus, Kommunikationsfehler und Betriebszustände müssen korrekt modelliert werden, damit aus einer Sensormeldung eine belastbare Information entsteht.

Alarmierung sollte möglichst nahe am Prozess erfolgen

Edge-Gateways können Messwerte lokal verarbeiten, Alarmbedingungen prüfen und Daten bei Kommunikationsausfall zwischenspeichern. Cloud- und SCADA-Systeme können darauf aufbauend Historie, Visualisierung und Eskalation übernehmen.

Für die Praxis gilt

Normalbetrieb analysieren → Messwertstreuung bestimmen → handlungsbedürftigen Zustand definieren → Alarmgrenze festlegen → erforderliche Reaktionszeit bestimmen → Hysterese passend zur Prozessschwankung wählen → Delay-On nur für nicht relevante Kurzzeitüberschreitungen einsetzen → Delay-Off beziehungsweise Rücksetzlogik festlegen → Quittierung und Reset trennen → Betriebszustände berücksichtigen → Sensor- und Kommunikationsstatus getrennt behandeln → Alarm lokal beziehungsweise am Edge auswerten → Zeitstempel an der Quelle erzeugen → Priorität und Eskalation definieren → Alarmhistorie auswerten → häufige Bad Actors gezielt beseitigen.

FAQ: Alarmflut im Condition Monitoring vermeiden

Was ist eine Alarmflut?

Eine Alarmflut ist eine Situation, in der so viele Alarmmeldungen innerhalb kurzer Zeit auftreten, dass ihre sinnvolle Bearbeitung und Priorisierung erschwert wird.

Was bedeutet Alarm Flapping?

Alarm Flapping bezeichnet den wiederholten schnellen Wechsel eines Alarms zwischen aktiv und normal.

Was bedeutet Chattering Alarm?

Der Begriff beschreibt einen Alarm, der aufgrund kleiner Signaländerungen oder ungeeigneter Parametrierung häufig ein- und ausschaltet.

Was verursacht Alarm Flapping?

Typische Ursachen sind eine zu kleine Hysterese, ein verrauschtes Messsignal, eine ungünstige Alarmgrenze oder fehlende zeitliche Verzögerungen.

Was ist die Hysterese eines Alarms?

Die Hysterese definiert den Abstand zwischen der Alarmgrenze und der Grenze, bei der ein aktiver Alarm wieder in den Normalzustand zurückkehrt.

Was ist ein Alarmtotband?

Das Alarmtotband beschreibt den Bereich, in dem eine kleine Signaländerung nach dem Erreichen der Alarmgrenze nicht sofort zu einem erneuten Zustandswechsel führt.

Sind Totband und Hysterese dasselbe?

Bei vielen analogen Alarmfunktionen werden beide Begriffe sehr ähnlich verwendet. Die genaue Umsetzung hängt jedoch vom jeweiligen Steuerungs- oder Softwaresystem ab.

Wie funktioniert eine Hysterese bei einem High-Alarm?

Der Alarm wird beispielsweise bei 100 aktiviert, aber erst bei 95 wieder zurückgesetzt. Der Bereich von 95 bis 100 bildet dann das Rücksetz-Totband.

Wie funktioniert die Hysterese bei einem Low-Alarm?

Ein Low-Alarm wird bei Unterschreiten der Alarmgrenze aktiv und erst bei einem um die Hysterese höheren Wert wieder zurückgesetzt.

Wie groß sollte die Hysterese sein?

Sie sollte die normalen kleinen Messwertschwankungen ausreichend übersteigen, darf aber relevante Prozessänderungen nicht unnötig verdecken. Ein universeller Prozentwert ist deshalb nicht sinnvoll.

Was bedeutet Delay-On?

Delay-On ist eine Einschaltverzögerung. Die Alarmbedingung muss für eine definierte Zeit durchgehend bestehen, bevor der Alarm aktiviert wird.

Wann ist Delay-On sinnvoll?

Wenn kurze Grenzwertüberschreitungen prozessbedingt auftreten und keine Bediener- beziehungsweise Wartungsaktion erfordern.

Kann eine lange Einschaltverzögerung gefährlich sein?

Ja. Wenn eine schnelle Reaktion erforderlich ist, kann eine zu lange Verzögerung dazu führen, dass ein relevanter Alarm zu spät ausgegeben wird.

Was bedeutet Delay-Off?

Delay-Off hält einen bereits aktiven Alarm noch für eine definierte Zeit aktiv, nachdem die eigentliche Alarmbedingung nicht mehr erfüllt ist.

Wann ist Delay-Off sinnvoll?

Wenn ein erkannter Zustand nicht sofort als normal gelten soll, nur weil der Messwert kurzzeitig wieder unter beziehungsweise über die Rücksetzgrenze fällt.

Was ist besser: Hysterese oder Delay-On?

Sie lösen unterschiedliche Probleme. Hysterese bewertet die Signalhöhe, Delay-On die Dauer einer Grenzwertüberschreitung. Häufig werden beide kombiniert.

Kann ich Hysterese und Verzögerung gleichzeitig verwenden?

Ja. Für viele Condition-Monitoring-Aufgaben ist eine Kombination aus sinnvoller Alarmgrenze, Hysterese und zeitlicher Persistenz besonders robust.

Was bedeutet Alarmpersistenz?

Damit wird die Forderung beschrieben, dass eine Alarmbedingung für eine bestimmte Zeit bestehen muss, bevor sie als gültiger Alarm behandelt wird.

Was ist eine speichernde Alarmfunktion?

Ein speichernder beziehungsweise latched Alarm bleibt gespeichert, auch wenn die ursprüngliche Grenzwertverletzung bereits verschwunden ist.

Wann ist ein latched Alarm sinnvoll?

Bei relevanten einmaligen Ereignissen, die auch nach ihrer Beendigung eindeutig sichtbar bleiben müssen, beispielsweise einer Überdrehzahl.

Was ist der Unterschied zwischen Alarm quittieren und Alarm zurücksetzen?

Quittieren bedeutet, dass die Meldung wahrgenommen wurde. Zurücksetzen bedeutet, dass die definierte Bedingung für die Rückkehr zum Normalzustand erfüllt ist.

Soll ein Alarm nach Quittierung verschwinden?

Nicht, wenn die eigentliche Alarmbedingung weiterhin besteht. Quittierstatus und Prozesszustand sollten getrennt behandelt werden.

Warum sind Alarmprioritäten wichtig?

Sie helfen dem Bediener zu erkennen, welche Meldungen besonders dringend beziehungsweise folgenschwer sind.

Sollte jeder Alarm eine hohe Priorität besitzen?

Nein. Wenn nahezu jeder Alarm höchste Priorität erhält, verliert die Priorisierung ihre Funktion.

Was ist Alarmeskalation?

Alarmeskalation bedeutet, dass eine weiterhin bestehende oder nicht bearbeitete Meldung nach definierten Kriterien an weitere Personen oder Systeme weitergegeben wird.

Ist Eskalationszeit dasselbe wie Alarmverzögerung?

Nein. Bei der Eskalation ist der Alarm bereits aktiv. Lediglich die Weiterleitung an weitere Empfänger wird zeitlich gestaffelt.

Was ist ein Bad Actor im Alarmmanagement?

Damit wird häufig eine Alarmquelle bezeichnet, die überproportional viele Meldungen erzeugt und deshalb gezielt untersucht werden sollte.

Warum sollte ich die häufigsten Alarme auswerten?

Oft verursacht eine kleine Anzahl problematischer Messstellen einen großen Anteil der gesamten Alarmereignisse. Deren Optimierung kann die Alarmrate deutlich reduzieren.

Sollte ich bei einem verrauschten Sensor einfach die Hysterese erhöhen?

Nicht ohne Ursachenanalyse. Starke Signalunruhe kann beispielsweise durch EMV-Probleme, Montage, Pulsationen oder einen ungeeigneten Messbereich entstehen.

Was ist der Unterschied zwischen Messwertfilter und Alarmhysterese?

Ein Filter verändert beziehungsweise glättet das Eingangssignal. Die Hysterese verändert nur die Schaltbedingungen des Alarms.

Kann eine zu starke Filterung problematisch sein?

Ja. Sie kann reale schnelle Prozessänderungen verzögern und dadurch die tatsächliche Alarmreaktionszeit verlängern.

Warum muss die gesamte Verzögerungskette betrachtet werden?

Sensorfilter, SPS-Zyklus, Edge-Verarbeitung, Alarm-Delay und Netzwerk können sich zeitlich addieren.

Was ist ein Rate-of-Change-Alarm?

Er überwacht nicht nur den absoluten Messwert, sondern wie schnell sich dieser innerhalb einer bestimmten Zeit verändert.

Wann ist ein Rate-of-Change-Alarm sinnvoll?

Wenn eine ungewöhnlich schnelle Veränderung bereits auf eine Störung hinweist, obwohl die absolute Alarmgrenze noch nicht erreicht wurde.

Warum sind Rate-of-Change-Alarme empfindlich gegen Rauschen?

Weil kleine schnelle Messwertänderungen bei einer Ableitung große Änderungsraten erzeugen können. Deshalb sind geeignete Zeitfenster und Filter besonders wichtig.

Warum sollte ein Condition-Monitoring-System Warnung und Alarm unterscheiden?

Eine Warnung kann eine Verschlechterung frühzeitig anzeigen, während ein Alarm einen bereits handlungsbedürftigen Zustand kennzeichnet.

Was bedeutet zustandsabhängige Alarmierung?

Die Alarmbedingung wird zusätzlich vom aktuellen Maschinen- oder Prozesszustand abhängig gemacht.

Warum ist das beim Maschinenstillstand wichtig?

Ein Druck- oder Drehzahlwert, der während des Betriebs abnormal wäre, kann bei ausgeschalteter Maschine völlig normal sein.

Was bedeutet Alarm Suppression?

Damit wird eine definierte Unterdrückung einer Alarmmeldung bezeichnet, wenn sie im aktuellen Anlagenzustand nicht relevant ist.

Wann kann eine Alarmunterdrückung sinnvoll sein?

Beispielsweise während Wartung, Maschinenstillstand oder bestimmten Anfahrzuständen, sofern die Unterdrückung bewusst definiert und dokumentiert ist.

Darf ein problematischer Alarm einfach dauerhaft unterdrückt werden?

Das sollte nicht als Ersatz für eine Ursachenbehebung dienen. Wiederkehrende unnötige Alarme sollten analysiert und technisch korrigiert werden.

Warum sollte ein Alarm möglichst am Edge verarbeitet werden?

Eine lokale Auswertung reduziert die Abhängigkeit von Netzwerk- und Cloud-Verbindungen und kann eindeutigere Zeitstempel und schnellere Reaktionen ermöglichen.

Muss jeder IIoT-Alarm in der Cloud berechnet werden?

Nein. Abhängig von der Anwendung können Alarmgrenzen bereits im Sensor, in der SPS oder im Edge-Gateway verarbeitet werden.

Kann eine Cloud-Alarmlogik eine sicherheitstechnische Abschaltung ersetzen?

Nicht automatisch. Erforderliche sicherheitstechnische Funktionen müssen entsprechend ihrer vorgesehenen Sicherheitsarchitektur unabhängig bewertet und umgesetzt werden.

Warum sind Zeitstempel im Condition Monitoring wichtig?

Nur mit einer konsistenten Zeitbasis lässt sich zuverlässig rekonstruieren, welcher Prozesszustand zuerst aufgetreten ist.

Soll der Zeitstempel am Sensor oder in der Cloud entstehen?

Für eine genaue Ereignisfolge ist ein Zeitstempel möglichst nahe an der tatsächlichen Erfassung sinnvoll. Die genaue Architektur hängt von den beteiligten Geräten ab.

Was bedeutet Store-and-Forward?

Daten werden bei einer unterbrochenen Verbindung lokal gespeichert und nach Wiederherstellung der Kommunikation mit ihrem ursprünglichen Zeitbezug weitergegeben.

Warum sollte ein Kommunikationsfehler nicht als Messwert null interpretiert werden?

Weil ein fehlender Messwert keine Aussage über den tatsächlichen Prozesswert erlaubt. Kommunikationsstatus und Messwert müssen getrennt behandelt werden.

Was ist ein Quality Flag?

Ein Quality Flag beschreibt, ob ein Messwert beispielsweise gültig, unsicher oder fehlerhaft ist.

Welche Protokolle werden bei IIoT typischerweise verwendet?

Auf der Feldebene kommen beispielsweise Modbus RTU, HART und IO-Link zum Einsatz. Zur IT- beziehungsweise Cloud-Anbindung werden unter anderem MQTT, HTTPS und OPC UA verwendet.

Warum eignet sich MQTT für IIoT?

MQTT arbeitet nach einem Publish/Subscribe-Prinzip und ermöglicht eine leichte, entkoppelte Übertragung von Telemetrie- und Zustandsinformationen.

Muss jeder Sensorwert per MQTT übertragen werden?

Nein. Abhängig von der Prozessdynamik können beispielsweise Publish-on-Change, Delta-Schwellen oder lokale Verdichtung das Datenvolumen reduzieren.

Was bedeutet Publish-on-Change?

Ein neuer Wert wird nur übertragen, wenn sich der Messwert gegenüber dem zuletzt übertragenen Wert um mindestens einen definierten Betrag verändert hat.

Warum sollte zusätzlich ein Heartbeat übertragen werden?

Damit auch bei unverändertem Messwert erkennbar bleibt, dass Gerät und Kommunikationsstrecke weiterhin funktionieren.

Was ist der Unterschied zwischen Sensorabtasthäufigkeit und Übertragungsrate?

Ein Sensor kann intern sehr häufig messen, während nur ein Teil dieser Werte an die Cloud übertragen wird. Dadurch bleiben lokale Reaktionen schnell, ohne unnötig große Datenmengen zu erzeugen.

Wie kann ich feststellen, ob meine Alarmhysterese zu klein ist?

Wenn viele Alarmwechsel entstehen, obwohl sich der Messwert nur geringfügig um den Grenzwert bewegt, sollte die Messwertstreuung analysiert und die Hysterese überprüft werden.

Wie erkenne ich eine zu große Hysterese?

Wenn ein Alarm trotz deutlicher Rückkehr des Prozesses in einen akzeptablen Zustand ungewöhnlich lange aktiv bleibt, kann die Rücksetzgrenze zu weit entfernt sein.

Wie erkenne ich ein zu großes Delay-On?

Wenn relevante Prozesszustände bereits längere Zeit bestehen, bevor der Alarm erscheint, sollte die Einschaltverzögerung überprüft werden.

Wie erkenne ich ein zu kleines Delay-On?

Wenn viele kurze, nicht handlungsbedürftige Grenzwertüberschreitungen alarmiert werden, kann eine geeignete Mindestdauer fehlen.

Sollte ich für alle Sensoren dieselbe Hysterese verwenden?

Nein. Druck, Temperatur, Füllstand und Vibration besitzen unterschiedliche Dynamik, Messunsicherheit und Prozessschwankung.

Sollte ich Hysterese als festen Wert oder Prozentwert festlegen?

Das hängt von Messbereich und Anwendung ab. Entscheidend ist, dass das resultierende Totband zur tatsächlichen Messwertstreuung und Prozessanforderung passt.

Warum sollte die Alarmhistorie regelmäßig überprüft werden?

Nur der reale Betrieb zeigt, welche Alarmquellen häufig auftreten, flattern oder für den Bediener keinen praktischen Nutzen besitzen.

Welche IIoT-Lösungen bietet ICS Schneider an?

ICS Schneider bietet Lösungen zur Integration von Sensorik, Edge-Gateways und IT/OT-Systemen einschließlich Druck-, Temperatur- und Füllstandüberwachung an.

Wo finde ich die IIoT-Lösungen bei ICS Schneider?

Eine Übersicht finden Sie unter IIoT-Lösungen bei ICS Schneider.

Wo finde ich Lösungen für IIoT-Drucküberwachung?

Weitere Informationen finden Sie unter IIoT-Drucküberwachung bei ICS Schneider.

Wo finde ich Lösungen für IIoT-Temperaturüberwachung?

Weitere Informationen finden Sie unter IIoT-Temperaturüberwachung bei ICS Schneider.