In einer Industrieanlage überwacht ein IIoT-System den Druck einer Pumpe. Überschreitet der Prozessdruck den eingestellten Grenzwert, erscheint im Dashboard eine Alarmmeldung.
Ein Mitarbeiter erkennt die Meldung und quittiert sie. Daraufhin verschwindet der Alarm aus der Liste der unquittierten Meldungen. Der Druck liegt jedoch weiterhin über dem zulässigen Grenzwert.
Bei einer späteren Auswertung entsteht ein Problem: Im Ereignisprotokoll steht lediglich „Alarm quittiert“. Wann die Störung tatsächlich begonnen hat und wann der Druck wieder normal war, lässt sich nicht mehr eindeutig feststellen.
Eine Alarmquittierung ist eine Bedienhandlung. Sie bestätigt nicht automatisch, dass die Prozessursache beseitigt wurde.
Für nachvollziehbare IIoT- und SCADA-Systeme müssen deshalb Prozessereignisse, Alarmzustände und Bedienhandlungen getrennt erfasst werden.
Dieser Beitrag erklärt die erforderlichen Zustände, Zeitstempel und Datenstrukturen. Ein Praxisbeispiel zeigt, wie eine vollständige Alarmhistorie aufgebaut und anschließend korrekt ausgewertet wird.
Inhaltsverzeichnis
- Alarmierung und Ereignisdokumentation
- Prozessereignis, Alarm und Quittierung
- Alarmzustände getrennt abbilden
- Was eine Quittierung tatsächlich bedeutet
- Aufbau eines Ereignisprotokolls
- Ereignis-ID und Messstellen-ID
- Zeitstempel und Zeitquellen
- Praxisbeispiel: Alarmdauer und Quittierungszeit
- Rückkehr zum Normalzustand
- Wiederholte und überlappende Alarme
- Benutzeridentifikation und Berechtigungen
- Lokale Alarmverarbeitung am Edge
- MQTT, OPC UA und Datenübertragung
- Pufferung bei Kommunikationsausfällen
- Datenqualität und doppelte Ereignisse
- Historian und langfristige Speicherung
- Alarmanzeige und Ereignisliste
- Alarmmanagement und ISA-18.2
- IT/OT-Sicherheit und Audit-Trail
- Prüf- und Inbetriebnahmeablauf
- Typische Fehler und Diagnose
- Passende ICS-Produkte und IIoT-Lösungen
- Fazit
- Häufig gestellte Fragen
1. Alarmierung und Ereignisdokumentation
In industriellen Anlagen werden Druck, Temperatur, Füllstand und weitere Messgrößen kontinuierlich überwacht.
Wird eine festgelegte Bedingung erfüllt, kann die Steuerung oder ein IIoT-System einen Alarm auslösen.
Für die spätere Auswertung reicht eine aktuelle Alarmanzeige nicht aus. Zusätzlich muss nachvollziehbar bleiben, wann die Bedingung auftrat, wann sie endete und welche Bedienhandlungen durchgeführt wurden.
2. Prozessereignis, Alarm und Quittierung
Ein Prozessereignis beschreibt eine beobachtete Zustandsänderung, beispielsweise das Überschreiten eines Druckgrenzwerts.
Ein Alarm ist eine entsprechend konfigurierte Meldung, die eine Aufmerksamkeit oder Handlung des Bedienpersonals erfordert.
Die Quittierung bestätigt, dass die betreffende Meldung zur Kenntnis genommen wurde. Eine tatsächliche Fehlerbehebung oder erfolgreiche Prüfung ist damit nicht automatisch verbunden.
3. Alarmzustände getrennt abbilden
Eine wichtige Grundlage ist die getrennte Speicherung von Alarmaktivität und Quittierungsstatus.
Das OPC-UA-Informationsmodell für Alarms & Conditions verwendet hierfür unter anderem die Zustände ActiveState und AckedState.
| Alarm aktiv | Quittiert | Bedeutung |
|---|---|---|
| Nein | Ja | Normalzustand; keine offene Quittierung |
| Ja | Nein | Prozessalarm aktiv und noch nicht quittiert |
| Ja | Ja | Prozessalarm weiterhin aktiv, aber quittiert |
| Nein | Nein | Prozess normalisiert; Quittierung eines früheren Alarmzustands noch offen, sofern das System diesen Zustand unterstützt |
Die genaue Zustandsfolge hängt vom implementierten Alarmmodell ab. Nicht jedes System unterstützt alle Kombinationen oder die nachträgliche Quittierung inaktiver Alarme.
4. Was eine Quittierung tatsächlich bedeutet
Eine Quittierung dokumentiert eine Bedienhandlung an einer bestimmten Alarmmeldung.
Sie sollte mindestens den betroffenen Alarm, den Zeitpunkt und den verantwortlichen Benutzer referenzieren.
Die Prozessbedingung muss unabhängig davon weiter überwacht werden.
Ein aktiver Alarm darf nicht allein deshalb als behoben gelten, weil ein Mitarbeiter die Meldung quittiert hat.
5. Aufbau eines Ereignisprotokolls
Ein Ereignisprotokoll speichert einzelne Zustandsänderungen als zeitlich zuordenbare Datensätze.
Typische Ereignistypen sind Alarmaktivierung, Alarmquittierung, Rückkehr zum Normalzustand und gegebenenfalls eine zusätzliche Bedienerbestätigung.
Die einzelnen Einträge sollten erhalten bleiben, auch wenn sich der aktuelle Alarmstatus später ändert.
Eine historische Alarmaktivierung darf daher nicht durch die nachfolgende Quittierung überschrieben werden.
6. Ereignis-ID und Messstellen-ID
Für die eindeutige Zuordnung sind verschiedene Identifikatoren sinnvoll.
Die Messstellen-ID bezeichnet den physikalischen Überwachungspunkt, beispielsweise PRESS-P101.
Eine Alarmdefinition bezeichnet die überwachte Bedingung, etwa HIGH-PRESSURE. Eine Alarmfall-ID verbindet die Zustandsänderungen eines zusammengehörigen Alarmverlaufs.
Zusätzlich erhält jeder einzelne Protokolleintrag eine eindeutige Ereignis-ID.
Damit können mehrere Quittierungen, Alarmaktivierungen und Statusänderungen nachvollziehbar verknüpft werden, ohne ihre zeitliche Reihenfolge zu verlieren.
7. Zeitstempel und Zeitquellen
Jedes Ereignis benötigt einen nachvollziehbaren Zeitbezug.
Besonders wichtig ist die Unterscheidung zwischen dem Zeitpunkt der Ereignisentstehung und dem Zeitpunkt des Empfangs im zentralen System.
Bei Netzwerkverzögerungen können diese Zeitpunkte auseinanderliegen.
Die beteiligten Geräte sollten deshalb über geeignete Verfahren wie NTP oder bei entsprechend hohen Anforderungen PTP synchronisiert werden.
Für die Speicherung sind eindeutige UTC-Zeitstempel mit ausreichender Auflösung zweckmäßig. Die lokale Anlagenzeit kann zusätzlich in der Benutzeroberfläche angezeigt werden.
8. Praxisbeispiel: Alarmdauer und Quittierungszeit
Eine Pumpe wird über einen Drucktransmitter überwacht. Das System erzeugt einen Hochdruckalarm, wenn der Druck mindestens drei Sekunden lang einen definierten Grenzwert überschreitet.
Die Quittierung erfolgt über das Bedienpanel. Die Rückkehr zum Normalzustand wird unabhängig davon protokolliert.
8.1 Ausgangsdaten
- Messstellen-ID: PRESS-P101.
- Alarmgrenzwert: 8,0 bar.
- Rücksetzgrenzwert: 7,5 bar.
- Aktivierungsverzögerung: 3 Sekunden.
- Rücksetzverzögerung: 1 Sekunde.
- Alarmquittierung durch Benutzer OP-17.
- Alle Zeiten beziehen sich auf dieselbe synchronisierte Anlagenzeit.
Die folgenden Werte sind frei gewählte Beispielannahmen und keine gerätespezifischen Grenzwerte.
8.2 Ereignisse chronologisch erfassen
| Zeit | Ereignis | Alarmstatus | Quittierung |
|---|---|---|---|
| 10:00:00 | Druck überschreitet 8,0 bar | Aktivierung ausstehend | – |
| 10:00:03 | Alarm wird aktiv | Aktiv | Offen |
| 10:00:07 | Benutzer OP-17 quittiert | Weiterhin aktiv | Quittiert |
| 10:00:14 | Druck unterschreitet 7,5 bar | Rücksetzung ausstehend | Quittiert |
| 10:00:15 | Alarm wird inaktiv | Inaktiv | Quittiert |
8.3 Quittierungszeit berechnen
Der Alarm wird um 10:00:03 aktiv und um 10:00:07 quittiert.
tQuittierung = 7 s – 3 s = 4 s
Die Bedienerreaktion erfolgt somit vier Sekunden nach der protokollierten Alarmaktivierung.
8.4 Alarmdauer berechnen
Der Alarm bleibt von 10:00:03 bis 10:00:15 aktiv.
tAlarm = 15 s – 3 s = 12 s
Die aktive Alarmdauer beträgt zwölf Sekunden.
8.5 Prozessdauer getrennt betrachten
Die beobachtete Überschreitung beginnt um 10:00:00. Das Rücksetzkriterium wird um 10:00:14 erreicht.
Die betrachtete Zeitspanne zwischen diesen beiden Prozessereignissen beträgt 14 Sekunden.
Aufgrund der Hysterese und Verzögerung entspricht sie nicht automatisch der Dauer, während der der Druck tatsächlich oberhalb von 8,0 bar lag.
8.6 Ergebnis interpretieren
Die Quittierung nach vier Sekunden bestätigt eine Bedienhandlung, während der Druck noch zu hoch ist.
Der Alarm endet erst, nachdem das festgelegte Rücksetzkriterium erfüllt wurde.
Würde das System die Quittierung als Alarmende speichern, wäre die dokumentierte Alarmdauer fälschlich um acht Sekunden verkürzt.
Für eine belastbare Bewertung müssen Alarmaktivierung, Bedienhandlung und Prozessnormalisierung deshalb getrennt erhalten bleiben.
9. Rückkehr zum Normalzustand
Ein Alarm darf erst entsprechend der festgelegten Rücksetzlogik als inaktiv bewertet werden.
Bei einem Hochdruckalarm kann beispielsweise eine Hysterese verhindern, dass der Status bei kleinen Druckschwankungen ständig wechselt.
Eine zusätzliche Rücksetzverzögerung stellt sicher, dass der Prozess ausreichend lange innerhalb des vorgesehenen Bereichs liegt.
Die Quittierung verändert diese Bedingungen nicht.
10. Wiederholte und überlappende Alarme
Eine Messstelle kann innerhalb kurzer Zeit mehrfach zwischen Alarm- und Normalzustand wechseln.
Bei geeigneten Systemen erhält jeder neue Alarmfall eine eigene Kennung.
Dadurch wird verhindert, dass eine Quittierung versehentlich auf einen später erneut ausgelösten Alarm übertragen wird.
OPC UA Alarms & Conditions kann hierzu auch ältere, noch nicht quittierte Zustände getrennt verwalten.
11. Benutzeridentifikation und Berechtigungen
Eine nachvollziehbare Quittierung sollte einem authentifizierten Benutzer zugeordnet sein.
Gemeinsam genutzte Benutzerkonten erschweren die spätere Feststellung, wer eine Meldung quittiert hat.
Ein rollenbasiertes Berechtigungskonzept kann zwischen Lesen, Quittieren, Parametrieren und administrativen Änderungen unterscheiden.
Bei kritischen Alarmen können zusätzliche Bestätigungen oder Begründungen erforderlich sein.
12. Lokale Alarmverarbeitung am Edge
In IIoT-Architekturen können Messwerte zunächst von einem Edge-Gateway erfasst und verarbeitet werden.
Die lokale Alarmbewertung ermöglicht eine vom Cloud-Dashboard unabhängige Erkennung der konfigurierten Prozessbedingungen.
Das Edge-System sollte Ereigniszeitpunkte, Messstellen-IDs und Zustandsänderungen eindeutig erfassen.
Eine lokale Alarmfunktion ist jedoch nicht automatisch eine sicherheitsgerichtete Schutzfunktion.
13. MQTT, OPC UA und Datenübertragung
OPC UA Alarms & Conditions besitzt ein standardisiertes Zustands- und Quittierungsmodell.
Bei MQTT müssen die erforderlichen Ereignisfelder und Quittierungsabläufe dagegen innerhalb der Anwendung beziehungsweise des verwendeten Datenmodells festgelegt werden.
Jede Nachricht sollte eine eindeutige Identifikation und einen Entstehungszeitpunkt besitzen.
Eine reine Übertragung des aktuellen Booleschen Alarmstatus reicht für eine vollständige Alarmhistorie nicht aus.
14. Pufferung bei Kommunikationsausfällen
Bei einem Ausfall der Netzwerkverbindung können Prozessalarme lokal weiterhin auftreten.
Geeignete Edge-Systeme speichern die Ereignisse deshalb vorübergehend in einem persistenten Puffer.
Nach Wiederherstellung der Verbindung werden die gespeicherten Ereignisse mit ihren ursprünglichen Zeitstempeln übertragen.
Wichtig sind ausreichende Speicherkapazität, Wiederanlaufverhalten und eine zuverlässige Übertragung ohne Datenverlust.
15. Datenqualität und doppelte Ereignisse
Bei der wiederholten Übertragung können Ereignisse mehrfach im zentralen System eintreffen.
Eine eindeutige Ereignis-ID ermöglicht es, solche Duplikate zu erkennen.
Auch ungültige Messwerte, Kommunikationsausfälle oder unplausible Zeitstempel müssen entsprechend gekennzeichnet werden.
Ein Messwert mit ungültigem Qualitätsstatus darf nicht ungeprüft als normale Prozessbedingung interpretiert werden.
16. Historian und langfristige Speicherung
Ein Historian speichert zeitbezogene Prozessdaten zur späteren Analyse.
Für die Alarmhistorie müssen neben Messwerten auch Zustandsübergänge und zugehörige Bedienhandlungen verfügbar sein.
Eine saubere Architektur kann Messwertarchiv, Ereignisprotokoll und Audit-Trail logisch getrennt führen und über stabile Identifikatoren verknüpfen.
Dadurch lassen sich Druckverlauf, Alarmdauer und Bedienerreaktion später gemeinsam auswerten.
17. Alarmanzeige und Ereignisliste
Eine aktuelle Alarmanzeige beantwortet die Frage, welche Meldungen momentan Aufmerksamkeit benötigen.
Die Ereignisliste dokumentiert dagegen, welche Änderungen in der Vergangenheit aufgetreten sind.
Beide Ansichten sollten deutlich unterscheidbar sein.
Ein quittierter, weiterhin aktiver Alarm muss gemäß dem gewählten Anzeige- und Alarmkonzept weiterhin als bestehende Prozessbedingung erkennbar bleiben.
18. Alarmmanagement und ISA-18.2
Die Normenreihe ISA-18.2 und die internationale IEC 62682 behandeln das Management industrieller Alarmsysteme.
Dazu gehören Alarmphilosophie, Prioritäten, Bedienerreaktionen, Prüfung, Überwachung und Dokumentation.
Eine vollständige Ereignishistorie unterstützt die Bewertung von Alarmhäufigkeit, Reaktionszeiten und wiederkehrenden Störungen.
Welche Anforderungen verbindlich sind, hängt von Anlagentyp, anzuwendenden Normen und Betreiberfestlegungen ab.
19. IT/OT-Sicherheit und Audit-Trail
Ein Audit-Trail dokumentiert relevante Änderungen und Bedienhandlungen einschließlich Benutzerbezug und Zeitstempel.
Quittierungen und Änderungen von Alarmgrenzen sollten nachvollziehbar und gegen unberechtigte Manipulation geschützt sein.
Hierfür sind geeignete Benutzerrechte, geschützte Kommunikation und ein kontrollierter Zugriff auf historische Daten wichtig.
Aufbewahrungsfristen und Anforderungen an die Unveränderbarkeit müssen anwendungsspezifisch festgelegt werden.
20. Prüf- und Inbetriebnahmeablauf
Für die Einrichtung einer nachvollziehbaren Alarmhistorie empfiehlt sich folgender Ablauf:
- Messstelle, Alarmbedingung und Rücksetzkriterium definieren.
- Aktivierungs- und Quittierungszustände getrennt modellieren.
- Eindeutige Alarmfall- und Ereignis-IDs festlegen.
- Zeitquellen und Zeitstempel synchronisieren.
- Benutzerrollen und Quittierungsrechte konfigurieren.
- Alarmaktivierung und Rückkehr zum Normalzustand testen.
- Quittierung bei weiterhin aktivem Alarm prüfen.
- Kommunikationsausfall und Ereignisnachlieferung simulieren.
- Duplikaterkennung und Historian-Einträge kontrollieren.
- Ergebnisse und Konfiguration dokumentieren.
21. Typische Fehler und Diagnose
Alarm verschwindet nach Quittierung vollständig: Anzeige- und Zustandsmodell auf vermischte Aktiv- und Quittierungsstatus prüfen.
Alarmdauer wird zu kurz berechnet: Quittierungszeitpunkt möglicherweise als Alarmende verwendet.
Ereignisse erscheinen in falscher Reihenfolge: Zeitquellen, Zeitzonen und Empfangszeitstempel kontrollieren.
Nach Netzwerkausfall fehlen Ereignisse: Persistente Pufferung und Wiederholübertragung prüfen.
Quittierung erscheint mehrfach: Ereignis-IDs und Duplikaterkennung überprüfen.
Benutzer nicht nachvollziehbar: Authentifizierung, Rollenmodell und Audit-Protokoll kontrollieren.
22. Passende ICS-Produkte und IIoT-Lösungen
ICS Schneider Messtechnik bietet IIoT-Lösungen zur Vernetzung industrieller Sensoren, Messumformer und Steuerungen.
Die konkrete Trennung von Alarmzustand, Quittierung und Ereignishistorie muss dabei im verwendeten Edge-, SCADA- oder Cloud-System implementiert beziehungsweise nachgewiesen werden.
| Produkt / Lösung | Wichtige Eigenschaften | Beitrag zur Alarmarchitektur |
|---|---|---|
| ICS IIoT-Lösungen | Edge-Gateways, MQTT/HTTPS, OPC UA, Datenmodellierung | Integration von Prozessdaten und Alarmereignissen |
| Siemens SITRANS P320 | Druck- und Differenzdruckmessung, HART, NE107-Diagnose | Messwert- und Diagnosequelle für die Alarmbewertung |
| WIKA NETRIS®2 | LoRaWAN, zwei eigensichere 4–20-mA-Eingänge | Drahtlose Übertragung geeigneter Messwerte |
| WIKA NETRIS®3 | LoRaWAN-Übertragung kompatibler digitaler WIKA-Messgeräte | Drahtlose Datenanbindung für die Zustandsüberwachung |
22.1 ICS IIoT-Lösungen
Die IIoT-Lösungen von ICS Schneider Messtechnik verbinden industrielle Messgeräte über geeignete Schnittstellen mit Edge-Gateways und übergeordneten Systemen.
Unterstützte Integrationswege umfassen je nach Projekt RS-485/Modbus RTU, HART, IO-Link, OPC UA, Ethernet sowie MQTT oder HTTPS.
ICS unterstützt bei Geräteauswahl, Datenmodell, Register-Mapping, Übertragung und Inbetriebnahme.
Die Anforderungen an Alarmquittierung, Historisierung und Audit-Trail werden im konkreten Integrationsprojekt festgelegt.
ICS IIoT-Lösungen – Produktübersicht
22.2 Siemens SITRANS P320 – Prozesstransmitter
Der Siemens SITRANS P320 ist ein digitaler Prozesstransmitter zur Messung von Relativdruck, Absolutdruck, Differenzdruck und weiteren abgeleiteten Prozessgrößen.
Er bietet HART-Kommunikation und umfangreiche Diagnosefunktionen gemäß NAMUR NE107.
Für eine IIoT-Alarmarchitektur kann der Transmitter Messwerte und Gerätezustände bereitstellen. Die übergeordnete Quittierung und Ereignishistorie werden im entsprechenden Auswertesystem realisiert.
Siemens SITRANS P320 – Produktinformationen
22.3 WIKA NETRIS®2 – LoRaWAN-Funkeinheit
Die WIKA NETRIS®2 überträgt Messwerte über LoRaWAN und besitzt zwei eigensichere analoge Eingänge mit 4–20 mA.
Sie eignet sich zur drahtlosen Einbindung geeigneter Messumformer in IIoT-Systeme, auch in entsprechend zugelassenen explosionsgefährdeten Bereichen.
Durch Übertragungsintervalle und Funklatenzen ist die konkrete Eignung für zeitkritische Alarme sorgfältig zu prüfen.
Ein vollständiges OPC-UA-Alarmquittierungsmodell ist aus der Messwertübertragungsfunktion allein nicht abzuleiten.
WIKA NETRIS®2 – Produktinformationen
22.4 WIKA NETRIS®3 – LoRaWAN-Funkeinheit
Die WIKA NETRIS®3 ist eine Funkeinheit zur Anbindung geeigneter digitaler WIKA-Messgeräte.
Sie überträgt Messdaten über LoRaWAN und ist für entsprechende industrielle Fernüberwachungsaufgaben vorgesehen.
Die Funkeinheit unterstützt die Bereitstellung von Messdaten für eine übergeordnete IIoT-Anwendung. Alarmverarbeitung, Quittierung und langfristige Ereignisspeicherung müssen dort passend umgesetzt werden.
WIKA NETRIS®3 – Produktinformationen
Weitere IIoT-Lösungen bei ICS Schneider Messtechnik
23. Fazit
Eine Alarmquittierung und das Ende einer Prozessstörung sind zwei unterschiedliche Ereignisse.
Wer beide Zustände vermischt, riskiert unvollständige Alarmhistorien, falsche Alarmdauern und nicht nachvollziehbare Bedienhandlungen.
Für eine saubere IIoT-Architektur sind getrennte Zustandsvariablen, eindeutige Ereignis-IDs und synchronisierte Zeitstempel erforderlich.
Auch Kommunikationsausfälle, Pufferung, Benutzerrechte und Datenqualität müssen berücksichtigt werden.
Die wichtigste Regel lautet: Prozessereignisse dokumentieren, Bedienhandlungen separat protokollieren und beide Informationen über eindeutige Identifikatoren nachvollziehbar miteinander verknüpfen.
24. Häufig gestellte Fragen
24.1 Was ist eine Alarmquittierung?
Eine Bedienhandlung, mit der ein Benutzer die Kenntnisnahme einer bestimmten Alarmmeldung bestätigt.
24.2 Beendet die Quittierung einen Prozessalarm?
Nein. Der Prozessalarm bleibt entsprechend seiner Aktivierungs- und Rücksetzbedingungen bestehen.
24.3 Was ist der Unterschied zwischen Alarm und Ereignis?
Ein Ereignis dokumentiert eine Zustandsänderung. Ein Alarm ist eine Meldung, die gemäß Alarmkonzept eine Reaktion erfordert.
24.4 Was muss ein Ereignisprotokoll enthalten?
Mindestens Ereignistyp, eindeutige Kennung, betroffene Messstelle, Zeitstempel und die für die Bewertung relevanten Zustandsinformationen.
24.5 Warum benötigt jeder Protokolleintrag eine Ereignis-ID?
Damit einzelne Ereignisse eindeutig identifiziert, übertragen und bei Bedarf von Duplikaten unterschieden werden können.
24.6 Was ist eine Alarmfall-ID?
Eine Kennung, die zusammengehörige Zustandsänderungen eines Alarmverlaufs miteinander verknüpft.
24.7 Warum muss der Benutzer bei der Quittierung gespeichert werden?
Damit später nachvollzogen werden kann, wer die entsprechende Bedienhandlung durchgeführt hat.
24.8 Was bedeutet ActiveState bei OPC UA?
Er beschreibt den Aktivitätszustand einer entsprechenden Alarmbedingung.
24.9 Was bedeutet AckedState bei OPC UA?
Er beschreibt, ob der betreffende quittierungspflichtige Zustand bereits quittiert wurde.
24.10 Können Alarme nach der Rückkehr zum Normalzustand unquittiert bleiben?
Ja. Entsprechend konfigurierte Alarmmodelle können auch frühere, inzwischen inaktive Zustände zur Quittierung vorhalten.
24.11 Welche Zeitstempel sind für die Alarmhistorie wichtig?
Insbesondere Ereignisentstehung, Quittierung, Normalisierung und gegebenenfalls der Empfangszeitpunkt im zentralen System.
24.12 Warum sollten Zeitquellen synchronisiert werden?
Damit Ereignisse verschiedener Geräte zeitlich korrekt zugeordnet und ausgewertet werden können.
24.13 Kann MQTT Alarmquittierungen übertragen?
Ja, wenn geeignete Nachrichtenformate, Berechtigungen und eine entsprechende Quittierungslogik implementiert sind.
24.14 Sind OPC UA und MQTT bei Alarmen gleichwertig?
Nein. OPC UA Alarms & Conditions besitzt ein standardisiertes Informationsmodell. Bei MQTT wird die benötigte Alarmsemantik anwendungsspezifisch definiert.
24.15 Was passiert bei einem Netzwerkausfall?
Bei geeigneter Architektur können Ereignisse lokal gepuffert und nach Wiederherstellung der Verbindung übertragen werden.
24.16 Muss ein quittierter Alarm weiterhin sichtbar sein?
Solange die Alarmbedingung aktiv ist, muss sie entsprechend dem festgelegten Alarm- und Bedienkonzept erkennbar bleiben.
24.17 Ist eine IIoT-Alarmfunktion automatisch sicherheitsgerichtet?
Nein. Sicherheitsgerichtete Funktionen benötigen eine eigenständige Bewertung und eine dafür geeignete technische Ausführung.
24.18 Welche Angaben benötigt ICS für ein IIoT-Angebot?
Benötigt werden Anzahl und Art der Messstellen, vorhandene Schnittstellen, Alarmbedingungen, Quittierungsabläufe, gewünschte Zeitauflösung, Netzwerkarchitektur, Speicherfristen, Benutzerrollen und Anforderungen an die Ereignisdokumentation.