ISA-18.2-Alarm-Konnektor

Übersicht

Der ISA-18.2-Konnektor implementiert den Alarmmanagement-Lebenszyklus, der durch den Standard ANSI/ISA-18.2 (Management of Alarm Systems for the Process Industries) definiert ist. Es handelt sich um einen Prozessor, der Meddle-Payloads konsumiert, benutzerdefinierte Alarmbedingungen auswertet und jedes Mal, wenn ein Alarm seinen Zustand ändert, eine neue Payload ausgibt — angereichert mit Alarm-Metadaten wie Priorität und aktuellem Zustand.

Konnektor-Typen:

• Isa182 - Zustandsbehafteter Alarmprozessor (wertet Bedingungen aus, verfolgt den Zustand pro Alarm)

Der Konnektor ist in der Kategorie industrial/ platziert, da das Alarmmanagement eine grundlegende Anforderung für Prozesssteuerung, Batch-Fertigung und SCADA-gesteuerte Anlagen ist.

Funktionen

• ✅ ISA-18.2-Alarm-Zustandsmaschine (normal, unbestätigt, bestätigt, Rückkehr-unbestätigt)
• ✅ MXL-Ausdruckssprache für beliebige Alarmbedingungen
• ✅ Priorität pro Alarm (low, medium, high, urgent)
• ✅ Totband-Hysterese zur Unterdrückung von Flattern an einem Schwellenwert
• ✅ Konfigurierbare On-Delay- und Off-Delay-Timer (in Millisekunden)
• ✅ Gibt eine Payload nur bei Zustandsübergängen aus (vermeidet Rauschen)
• ✅ Standard-_alarm_*-Metadatenschlüssel für nachgelagerte Weiterleitung/Alarmierung

Grundkonfiguration

Einfacher Schwellenwert-Alarm

{
  "type": "Isa182",
  "config": {
    "alarms": [
      {
        "name": "high_temperature",
        "condition": "temperature > 80",
        "priority": "high"
      }
    ]
  }
}

Mit Totband und Verzögerungen

{
  "type": "Isa182",
  "config": {
    "alarms": [
      {
        "name": "high_temperature",
        "condition": "temperature > 80",
        "priority": "high",
        "setpoint": 80,
        "deadband": 2.0,
        "delayOn": 5000,
        "delayOff": 10000
      }
    ],
    "shelveTimeout": 3600000,
    "maxShelves": 25
  }
}

Mehrere Alarme

{
  "type": "Isa182",
  "config": {
    "alarms": [
      {
        "name": "high_pressure",
        "condition": "pressure > 10.0",
        "priority": "urgent",
        "delayOn": 2000
      },
      {
        "name": "low_flow",
        "condition": "flow_rate < 5.0",
        "priority": "medium",
        "delayOn": 10000
      },
      {
        "name": "tank_overflow",
        "condition": "tank_level > 95",
        "priority": "high",
        "setpoint": 95,
        "deadband": 1.0
      }
    ]
  }
}

Konfigurationsparameter

Alarms

Ein erforderliches Array von Alarmdefinitionen. Mindestens ein Alarm ist erforderlich.

{
  "alarms": [
    {
      "name": "high_temp",
      "condition": "temperature > 80",
      "priority": "high"
    }
  ]
}

Alarm: Name

Eine eindeutige Kennung für den Alarm. Wird als _alarm_name-Wert in ausgegebenen Payloads verwendet.

{
  "name": "compressor_1_high_temp"
}

Empfohlene Konvention: <asset>_<messung>_<bedingung> (z.B. pump_3_low_pressure).

Alarm: Condition

Ein MXL-Ausdruck, der gegen jede eingehende Payload ausgewertet wird. Wenn das Ergebnis true ist, gilt der Alarm als aktiv.

{
  "condition": "temperature > 80 AND pressure < 5"
}

Beispiele:

{ "condition": "temperature > 80" }
{ "condition": "vibration_rms >= 0.7" }
{ "condition": "tank_level < 10 OR tank_level > 95" }
{ "condition": "(motor_running == true) AND (current > 12.5)" }

Die Bedingung wird beim Start geparst; ein ungültiger Ausdruck lehnt die Konnektor-Konfiguration vor der Laufzeit ab.

Alarm: Priority

Schweregrad für die nachgelagerte Weiterleitung. Muss einer der folgenden sein:

• low
• medium
• high
• urgent

{
  "priority": "urgent"
}

Alarm: Setpoint und Deadband

Hysterese, die um den Alarmschwellenwert angewendet wird, um Flattern zu unterdrücken.

{
  "setpoint": 80,
  "deadband": 2.0
}

• setpoint - Der nominale Schwellenwert (informativ; wird zusammen mit deadband verwendet)
• deadband - Das Hysteresenband. Wenn die Bedingung von inaktiv zu aktiv wechselt, bleibt sie aktiv, bis der zugrundeliegende Wert unter setpoint - deadband fällt

Empfohlene Werte: 1-5% des Betriebsbereichs, um spurious Übergänge bei verrauschten Signalen zu vermeiden.

Alarm: DelayOn

Einschaltverzögerung in Millisekunden. Die Bedingung muss so lange kontinuierlich aktiv sein, bevor der Alarm in den Zustand unacknowledged übergeht.

{
  "delayOn": 5000
}

Empfohlene Werte:

• Schnelle Prozesse: 500-2000ms
• Standard-Prozessalarme: 5000-15000ms
• Trendalarme: 30000ms+ (30s)

Alarm: DelayOff

Ausschaltverzögerung in Millisekunden. Die Bedingung muss so lange kontinuierlich inaktiv bleiben, bevor der Alarm in den Zustand rtn_unacknowledged übergeht.

{
  "delayOff": 10000
}

Eine längere Ausschaltverzögerung hält einen Alarm lange genug sichtbar, damit Bediener ihn bestätigen können.

Shelve Timeout & Max Shelves

{
  "shelveTimeout": 3600000,
  "maxShelves": 25
}

• shelveTimeout - Standarddauer (ms), für die ein Alarm zurückgestellt werden kann
• maxShelves - Maximale Anzahl gleichzeitig zurückgestellter Alarme

Diese Parameter spiegeln die ISA-18.2-Shelving-Einschränkungen wider und werden an nachgelagerte UI-/Verwaltungstools weitergeleitet.

Alarm-Zustandsmaschine

Der Konnektor implementiert die ISA-18.2-Zustandsmaschine. Jeder Alarm hält einen der folgenden Zustände:

Zustand	Bedeutung
normal	Bedingung ist inaktiv; keine Bedienerintervention erforderlich
unacknowledged	Bedingung wurde aktiv; Bediener hat noch nicht bestätigt
acknowledged	Bediener hat bestätigt, während die Bedingung noch aktiv ist
rtn_unacknowledged	Bedingung ist in den Normalzustand zurückgekehrt, der vorherige Alarm wurde aber nie bestätigt

Bei jedem Zustandsübergang wird eine neue Payload ausgegeben.

Ausgabe-Payload

Wenn ein Alarm seinen Zustand ändert, wird die ursprüngliche Payload kopiert und um die folgenden Schlüssel erweitert:

{
  "...originale Felder...": "...",
  "_alarm_name": "high_temperature",
  "_alarm_state": "unacknowledged",
  "_alarm_priority": "high",
  "_alarm_timestamp": "2026-05-20T10:14:33.123456789Z"
}

Feldreferenz:

• _alarm_name - Entspricht dem name aus der Alarmdefinition
• _alarm_state - Aktueller Zustand (normal, unacknowledged, acknowledged, rtn_unacknowledged)
• _alarm_priority - Priorität aus der Alarmdefinition
• _alarm_timestamp - RFC 3339 Nanosekunden-UTC-Zeitstempel des Übergangs

Datenfluss

DataPayload → Isa182 → (bei Zustandsänderung) → DataPayload + _alarm_*-Metadaten
                    → (keine Zustandsänderung) → still verworfen

Beispiel:

Eingangsstream (1Hz):

{ "temperature": 78.0 }
{ "temperature": 81.0 }
{ "temperature": 82.0 }
{ "temperature": 79.0 }
{ "temperature": 78.5 }

Mit Alarm high_temperature: temperature > 80, delayOn: 0, delayOff: 0:

• Sample 1 (78.0): Bedingung falsch, Zustand bleibt normal, keine Ausgabe
• Sample 2 (81.0): Bedingung wahr, Zustand → unacknowledged, Payload ausgegeben
• Sample 3 (82.0): Bedingung weiterhin wahr, keine Zustandsänderung, keine Ausgabe
• Sample 4 (79.0): Bedingung falsch, Zustand → rtn_unacknowledged, Payload ausgegeben
• Sample 5 (78.5): Bedingung weiterhin falsch, keine Zustandsänderung, keine Ausgabe

Häufige Anwendungsfälle

1. Hochtemperatur-Prozessalarm

{
  "type": "Isa182",
  "config": {
    "alarms": [
      {
        "name": "reactor_high_temp",
        "condition": "reactor_temperature > 150",
        "priority": "urgent",
        "setpoint": 150,
        "deadband": 5,
        "delayOn": 3000,
        "delayOff": 10000
      }
    ]
  }
}

2. Multi-Variablen-Kompressor-Gesundheit

{
  "type": "Isa182",
  "config": {
    "alarms": [
      {
        "name": "compressor_overload",
        "condition": "motor_current > 25 AND oil_pressure < 2.0",
        "priority": "urgent",
        "delayOn": 5000
      },
      {
        "name": "compressor_vibration",
        "condition": "vibration_rms > 0.7",
        "priority": "high",
        "setpoint": 0.7,
        "deadband": 0.05,
        "delayOn": 10000
      },
      {
        "name": "compressor_temp_drift",
        "condition": "discharge_temp > 95",
        "priority": "medium",
        "delayOn": 30000
      }
    ]
  }
}

3. Tankfüllstandsüberwachung mit Hysterese

{
  "type": "Isa182",
  "config": {
    "alarms": [
      {
        "name": "tank_low_level",
        "condition": "tank_level < 10",
        "priority": "high",
        "setpoint": 10,
        "deadband": 2,
        "delayOn": 5000,
        "delayOff": 30000
      },
      {
        "name": "tank_high_level",
        "condition": "tank_level > 90",
        "priority": "high",
        "setpoint": 90,
        "deadband": 2,
        "delayOn": 5000,
        "delayOff": 30000
      }
    ],
    "shelveTimeout": 3600000,
    "maxShelves": 10
  }
}

Fehlerbehebung

Alarme werden nie ausgelöst

Problem: Die Bedingung scheint zu falsch ausgewertet zu werden, selbst wenn die zugrundeliegenden Daten sie aktivieren sollten

Lösungen:

1. Bestätigen, dass der Feldname in der Bedingung exakt mit der Payload übereinstimmt (Groß-/Kleinschreibung beachten)
2. Datentyp prüfen — temperature > 80 schlägt fehl, wenn temperature als String ankommt. Fügen Sie einen vorgelagerten Transform ein, um Typen zu konvertieren
3. Überprüfen, ob der vorgelagerte Konnektor tatsächlich Payloads an den Prozessor liefert (Datenfluss mit einem Log- oder Console-Writer prüfen)

Ständiges Re-Triggering (Flattern)

Problem: Ein verrauschtes Signal oszilliert wiederholt um den Schwellenwert und erzeugt viele Übergänge

Lösungen:

1. Ein deadband von 1-5% des Betriebsbereichs hinzufügen
2. delayOn erhöhen, damit kurze Ausreißer ignoriert werden
3. Einen MovingAverage oder EWMA vorgelagert anwenden, um die Eingabe zu glätten

Alarm bleibt in unacknowledged stecken

Problem: Der Alarm ist nicht mehr aktiv, aber der Zustand kehrt nie zu normal zurück

Lösungen:

1. ISA-18.2 erfordert eine explizite Bestätigung, bevor zu normal zurückgekehrt werden kann. Der Zustand rtn_unacknowledged ist der Standardpfad, wenn die Bedingung vor der Bestätigung verschwindet
2. Die Bestätigung wird typischerweise von einem HMI oder Alarmtool gesteuert — verdrahten Sie eines, das den Alarmzustand in Ihrem nachgelagerten System aktualisiert

Ungültiger MXL-Ausdruck beim Start

Problem: Konnektor startet nicht mit ErrIsa182ConditionEval

Lösungen:

1. Überprüfen, ob die Bedingung mit MXL-Syntax geparst werden kann — Vergleiche verwenden >, <, >=, <=, ==, !=
2. Boolesche Verknüpfungen sind AND, OR, NOT
3. Komplexe Teilausdrücke in Klammern setzen

Best Practices

1. Totbänder bei verrauschten Sensoren aggressiv verwenden

Bereits ein kleines Totband (1-2% des Bereichs) reduziert das Alarmaufkommen in realen Anlagen drastisch.

2. Verzögerungen nach Priorität staffeln

[
  { "priority": "urgent", "delayOn": 1000 },
  { "priority": "high", "delayOn": 5000 },
  { "priority": "medium", "delayOn": 15000 },
  { "priority": "low", "delayOn": 30000 }
]

Urgent-Alarme sollten schnell auslösen; Alarme niedrigerer Priorität können längere Bestätigungsfenster tolerieren.

3. Alarmnamen stabil halten

Nachgelagerte Alarmierungen drehen sich oft um _alarm_name. Behandeln Sie Alarmnamen als Teil Ihres öffentlichen Schemas; benennen Sie sie nicht leichtfertig um.

4. Mit einem Router für prioritätsbasierte Eskalation kombinieren

Routen nach _alarm_priority an verschiedene Alarmkanäle (urgent → SMS, high → E-Mail, medium → nur Dashboard).

5. Übermäßige Alarme vermeiden (ISA-18.2 §8)

Der Standard empfiehlt ≤ 6 Alarme pro Stunde pro Bediener im Durchschnitt. Verwenden Sie Totbänder, Verzögerungen und konsolidierte Alarmbedingungen, um innerhalb dieser Grenze zu bleiben.

Beispiel-Workflows

End-to-End-Alarm-Pipeline

OpcuaReader → Isa182 → Router → ┬─ Alert (urgent → SMS)
                                ├─ Alert (high → E-Mail)
                                └─ InfluxDb2Writer (Audit-Log)

1. OpcuaReader: Holt Prozessvariablen von einer SPS im 500ms-Takt
2. Isa182: Wertet alle konfigurierten Alarme aus; gibt Payloads nur bei Zustandsänderung aus
3. Router: Verzweigt nach _alarm_priority
4. Alert (urgent): Sendet SMS über den Benachrichtigungskanal
5. Alert (high): Sendet E-Mail
6. InfluxDb2Writer: Auditiert alle Alarmübergänge zur Compliance

Predictive Maintenance kombiniert mit Alarmauslösung

ModbusReader → Predictive → Isa182 → Alert

1. ModbusReader: Liest Vibration und Temperatur
2. Predictive: Berechnet Trend und verbleibende Nutzungsdauer
3. Isa182: Triggert bei vibration_rms_rul < 168 (weniger als 7 Tage verbleibende Nutzungsdauer)
4. Alert: Benachrichtigt die Wartung

Verwandte Konnektoren

• Trigger - Einfachere bedingungsbasierte Ausgabe ohne Zustandsmaschine
• Alert - Alarm-Payloads an Benachrichtigungskanäle senden
• Router - Verzweigen nach _alarm_priority
• Predictive - Mit prädiktiver RUL für proaktive Alarmierung kombinieren
• Filter - Eingaben vor der Alarmauswertung vorfiltern

Zusätzliche Ressourcen

• ANSI/ISA-18.2 Standard - Management of Alarm Systems for the Process Industries
• EEMUA 191 - Alarm Systems: A Guide to Design, Management and Procurement
• Alarm Management Guidelines (ISA)