Alarmmanagement in der Fertigung ist die Disziplin, die sicherstellt, dass jeder Alarm, den ein Bediener sieht, echt, relevant und handlungsrelevant ist. Dieser Leitfaden erklärt, warum Alarmfluten entstehen, was der ISA-18.2-Lebenszyklus von Ihnen verlangt, wie Sie Prioritäten und Totbänder festlegen und wie Sie Alarmereignisse über MQTT veröffentlichen, damit Dashboards, Benachrichtigungen und Analysewerkzeuge dieselbe Wahrheit sehen.
Warum Alarmmanagement wichtig ist
Ein Alarm soll einem Bediener mitteilen, dass etwas innerhalb einer begrenzten Zeit eine Reaktion erfordert. Wird dieses Versprechen gebrochen, lernen die Menschen, Alarme zu ignorieren. Typische Symptome in Werken ohne Alarmmanagement:
- Daueralarme, die tagelang aktiv bleiben, weil niemand die Ursache beheben kann oder will.
- Flatternde Alarme, die rund um einen Grenzwert viele Male pro Minute kommen und gehen.
- Alarmfluten nach einer Störung, bei denen eine einzige Grundursache Dutzende Folgealarme auslöst und der wichtige Alarm aus dem Sichtfeld scrollt.
- Alles hat hohe Priorität, sodass die Priorität keine Information mehr trägt.
- Alarme ohne definierte Reaktion, die bei der Inbetriebnahme „sicherheitshalber“ konfiguriert wurden.
Das Ergebnis ist Alarmmüdigkeit. Bediener quittieren, ohne zu lesen, und wenn ein wirklich kritischer Alarm eintrifft, konkurriert er mit Rauschen. Untersuchungen mehrerer bekannter Industrieunfälle haben überforderte Bediener als mitverursachenden Faktor benannt, weshalb Alarmmanagement zu einer formalen Disziplin wurde.
ISA-18.2-Grundlagen
ANSI/ISA-18.2 (und das internationale Pendant IEC 62682) ist die Referenznorm für Alarmmanagement in der Prozessindustrie, und ihre Konzepte lassen sich ebenso gut auf die diskrete Fertigung übertragen. Kernidee ist ein Lebenszyklus des Alarmmanagements:
| Phase | Was passiert | Ergebnis |
|---|---|---|
| Philosophie | Festlegen, was ein Alarm ist, Prioritäten, Farben, Reaktionszeiten, KPIs | Alarmphilosophie-Dokument |
| Identifikation | Kandidaten für Alarme aus Gefährdungsanalysen, Qualitäts- und Instandhaltungsanforderungen finden | Kandidatenliste |
| Rationalisierung | Jeden Alarm begründen: Ursache, Folge, Reaktion, Reaktionszeit, Priorität | Master-Alarmdatenbank |
| Detailplanung | Grenzwerte, Totbänder, Verzögerungen, Unterdrückungslogik festlegen | Konfigurierte Alarme |
| Implementierung | Ausrollen, testen, Bediener schulen | Laufendes System |
| Betrieb | Bediener reagieren; Zurückstellen und Außerbetriebnahme per Verfahren | Alarmereignisse |
| Instandhaltung | Instrumente reparieren, Alarme testen | Gewartetes System |
| Überwachung und Bewertung | Alarmraten, Fluten, häufigste Verursacher messen | Verbesserungsmaßnahmen |
| Änderungsmanagement | Hinzufügen, Löschen und Grenzwertänderungen kontrollieren | Audit-Trail |
| Audit | Regelmäßige Überprüfung gegen die Philosophie | Auditbericht |
Der wertvollste Schritt für die meisten Werke ist die Rationalisierung. Fragen Sie bei jedem Alarm: Was ist die Ursache, was passiert, wenn niemand handelt, was genau soll der Bediener tun und wie viel Zeit hat er dafür? Ein Alarm ohne klare Antwort auf die dritte Frage ist kein Alarm, sondern ein Ereignis oder eine Benachrichtigung und gehört in ein Protokoll, nicht auf den Bildschirm des Bedieners.
ISA-18.2 liefert außerdem gängige Richtwerte für die Alarmlast pro Bediener und definiert eine Alarmflut als einen Alarmschwall, der übersteigt, was ein Bediener bewältigen kann, typischerweise mehr als zehn Alarme in zehn Minuten. Verwenden Sie in Ihrer Philosophie die Werte der Norm, statt eigene zu erfinden.
Alarmmanagement in der Fertigung, das Teams dauerhaft tragen können: Prioritäten und Auslegung
Prioritäten festlegen
Die Priorität sollte sich aus zwei Faktoren ergeben: der Schwere der Folge und der verfügbaren Reaktionszeit. Eine einfache Matrix genügt:
| Folge | Reaktion innerhalb von Minuten nötig | Reaktion innerhalb einer Stunde oder länger nötig |
|---|---|---|
| Sicherheit, Umwelt oder schwerer Anlagenschaden | Hoch | Mittel |
| Produktverlust oder Qualitätssperre | Mittel | Niedrig |
| Geringer Effizienzverlust | Niedrig | Kein Alarm (Ereignis oder Benachrichtigung) |
Halten Sie den Anteil hoher Priorität klein. Wenn mehr als eine kleine Minderheit der konfigurierten Alarme hohe Priorität hat, überarbeiten Sie die Rationalisierung.
Totbänder und Verzögerungen
Die meisten flatternden Alarme sind ein Auslegungsproblem, kein Prozessproblem:
- Totband (Hysterese): Ein Alarm, der oberhalb von 80 °C auslöst, geht erst unterhalb von beispielsweise 78 °C zurück.
- Einschaltverzögerung: Die Bedingung muss eine festgelegte Zeit erfüllt sein, bevor der Alarm aktiv wird, und filtert so kurze Spitzen heraus.
- Ausschaltverzögerung: Die Bedingung muss eine festgelegte Zeit nicht mehr erfüllt sein, bevor der Alarm in den Normalzustand zurückkehrt, und verhindert schnelles erneutes Auslösen.
Unterdrückung und Zurückstellen
Während eines geplanten Stillstands sind Alarme für zu geringen Durchfluss an einer gestoppten Pumpe erwartbar und nutzlos. Zustandsbasierte Unterdrückung blendet Alarme aus, die im aktuellen Maschinenzustand bedeutungslos sind. Das Zurückstellen (Shelving) erlaubt einem Bediener, einen Störalarm im Rahmen eines kontrollierten Verfahrens mit automatischem Zeitlimit vorübergehend zu entfernen, damit er nicht vergessen werden kann.
Alarmereignisse über MQTT veröffentlichen
Alarme entstehen meist in SPS, Prozessleitsystemen (DCS) oder SCADA. Werden sie über MQTT veröffentlicht, können weitere Abnehmer (Andon-Tafeln, mobile Benachrichtigungen, Instandhaltungssysteme, Analysen) dieselben Ereignisse ohne separate Integrationen nutzen. In einem Unified Namespace (UNS) folgt die Topic-Struktur dabei der ISA-95-Hierarchie (Unternehmen → Werk → Bereich → Linie → Zelle), sodass jeder Alarm eindeutig einer Anlage zugeordnet ist. Zwei Topic-Typen ergänzen sich gut:
acme/plant1/press/line3/press2/alarm/HYD_TEMP_HI retained: current state of this alarm
acme/plant1/press/line3/alarm-events not retained: every transition, for history
Das retained Topic pro Alarm liefert jedem Client die aktuelle Liste aktiver Alarme, indem er einfach .../alarm/# abonniert. Der Ereignisstrom speist eine Datenbank für Alarm-KPIs wie Alarme pro Stunde, die zehn häufigsten Verursacher und Flutperioden.
Das folgende Python-Beispiel implementiert einen Alarm mit Totband und Einschaltverzögerung auf einem Temperaturwert und veröffentlicht beide Topics. Es nutzt paho-mqtt 2.x und den kostenlosen öffentlichen MQTT-Broker zum Testen.
import json
import time
import uuid
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/alm-2e7b/press2"
ALARM_ID = "HYD_TEMP_HI"
HIGH, CLEAR, ON_DELAY_S, PRIORITY = 80.0, 78.0, 5.0, "HIGH"
active = False
pending_since = None
def publish_alarm(client, state, value):
event = {"alarm": ALARM_ID, "state": state, "priority": PRIORITY,
"value": value, "limit": HIGH, "ts": time.time()}
client.publish(f"{BASE}/alarm/{ALARM_ID}", json.dumps(event), qos=1, retain=True)
client.publish(f"{BASE}/alarm-events", json.dumps(event), qos=1)
print(event)
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/hydraulic/temp", qos=1)
def on_message(client, userdata, msg):
global active, pending_since
value = json.loads(msg.payload)["tempC"]
now = time.time()
if not active:
if value > HIGH:
pending_since = pending_since or now
if now - pending_since >= ON_DELAY_S:
active = True
publish_alarm(client, "ACTIVE", value)
else:
pending_since = None
elif value < CLEAR:
active, pending_since = False, None
publish_alarm(client, "CLEARED", value)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"alarm-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
Senden Sie länger als fünf Sekunden Werte über 80, wird der Alarm aktiv; er geht erst unter 78 wieder zurück. Eine Quittierung lässt sich auf dieselbe Weise ergänzen: Das HMI veröffentlicht ein Quittierungsereignis, und der Alarmdienst setzt den retained Zustand auf ACTIVE_ACKED.
Checkliste Alarmmanagement
- Schreiben Sie eine einseitige Alarmphilosophie, bevor Sie etwas Neues konfigurieren.
- Exportieren Sie die aktuelle Alarmliste und sortieren Sie die Alarme nach Häufigkeit; die zehn häufigsten verursachen meist den Großteil der Last.
- Rationalisieren Sie diese zuerst: Ursache, Folge, Reaktion, Zeit, Priorität.
- Versehen Sie jeden flatternden Alarm mit Totband und Verzögerungen.
- Stufen Sie Alarme ohne Bedienerhandlung zu Ereignissen oder Benachrichtigungen herab.
- Implementieren Sie zustandsbasierte Unterdrückung für gestoppte Maschinen oder Maschinen in der Umrüstung.
- Messen Sie wöchentlich die Alarmrate pro Bediener und die Flutperioden.
- Steuern Sie Änderungen an Grenzwerten und Prioritäten über das Änderungsmanagement.
Wo ConnectMQ ins Spiel kommt
ConnectMQ ist ein verwalteter MQTT-Broker, der Alarmereignisse zwischen Steuerungen, Dashboards und Benachrichtigungsdiensten transportiert, mit MQTT 5, retained Messages, TLS und sicherem WebSocket für browserbasierte Andon-Bildschirme. Das Portal enthält außerdem Schwellenwert-Alarmregeln und ein Alarmprotokoll, die sich für einfache Überwachungsbenachrichtigungen eignen, etwa wenn ein Kühlraum oder eine Lagertemperatur einen festen Grenzwert überschreitet. Sie ergänzen rationalisierte Prozessalarme und Sicherheitssysteme in Ihrer SPS oder Ihrem SCADA, ersetzen sie aber nicht; dort bleiben die Alarme, die eine Bedienerhandlung erfordern.
Um Alarme an der Linie sichtbar zu machen, kombinieren Sie sie mit einem digitalen Andon-System und der Überwachung des Maschinenstatus. Der Smart-Manufacturing-Leitfaden zeigt, wie Alarmdaten in die gesamte Datenarchitektur des Werks passen.
Leiten Sie Ihre Alarmereignisse über ConnectMQ
Erstellen Sie unter app.connectmq.com kostenlos und ohne Kreditkarte einen Serverless-Broker, veröffentlichen Sie Ihre ersten Alarm-Topics und verfolgen Sie im Topic-Explorer live, wie sich die Liste aktiver Alarme aktualisiert.
Häufig gestellte Fragen
Was ist eine Alarmflut?
Eine Alarmflut ist ein Zeitraum, in dem Alarme schneller eintreffen, als ein Bediener reagieren kann, oft nachdem eine einzelne Störung viele Folgealarme ausgelöst hat. ISA-18.2 verwendet häufig mehr als zehn Alarme in zehn Minuten pro Bediener als Schwelle.
Was ist Alarmrationalisierung?
Die systematische Überprüfung jedes Alarms, bei der Ursache, Folge, erforderliche Bedienerhandlung, zulässige Reaktionszeit und Priorität dokumentiert werden. Alarme, die diese Prüfung nicht bestehen, werden entfernt oder in Ereignisse umgewandelt.
Ist ISA-18.2 nur für die Prozessindustrie gedacht?
Die Norm wurde für die Prozessindustrie geschrieben, doch ihr Lebenszyklus, die Rationalisierung und die Leistungsüberwachung gelten ebenso für Linien der diskreten Fertigung.
Kann MQTT für Sicherheitsalarme verwendet werden?
Sicherheitsfunktionen gehören in zertifizierte Sicherheitssysteme und Sicherheits-SPS. MQTT eignet sich gut, um Alarminformationen an Dashboards, Benachrichtigungen und Analysen zu verteilen, nicht aber, um Sicherheitsaktionen auszuführen.
