Aufgaben des Alarm-Aggregations-Servers

Hinweis: Historisch wird dieser Server auch als Summenalarm-Server bezeichnet.

Alarme aggregieren

Prozessvariable (PVs) können mit Hilfe des Alarm-Trees hierarchisch angeordnet werden. Diese Anordnung ist im LDAP gespeichert.

In dem Tree ist der Alarm-Zustand jeder PV farblich dargestellt. Knoten der höheren Ebenen aggregieren dabei die Werte der unter ihnen liegenden PVs. Aus fachlichen Gründen kann es sinnvoll sein, nicht jeden individuellen Alarm mitgeteilt zu bekommen, sondern Mengen von Alarmen zusammenzufassen und nur diese Zusammenfassung zu betrachten. Damit kann eine Übersicht über z.B. Gebäude oder funktional zusammenhängende Gewerke erstellt werden.
Beispiel für ein Gebäude: Alle Leckmelder aus einem Gebäude werden zusammengefasst. Beim Auftreten des aggregierten Alarms kann der Operateur im Alarm-Tree sehen, welcher konkrete Leckmelder angeschlagen hat.
Beispiel für eine Funktionalität: Alle für den Betrieb eines Kompressors notwendigen Baugruppen werden zusammengefasst. Beim Auftreten des aggregierten Alarms sieht der Operateur im Alarm-Tree, welche Baugruppe das Problem verursacht hat.
Eine aggregierte Alarm-Meldung kann so gestaltet werden, dass sie ohne Detail-Kenntnisse (Leck im Gebäude X statt Leck in Besenkammer Y oder Kompressor X ist ausgefallen statt Sicherung beim Kühlwasserkreislauf Y hat ausgelöst) verstanden wird. Weiterhin wird die Zahl der Alarm-Meldungen reduziert: Bei einem Stromausfall werden ggf. viele Baugruppen gleichzeitig Störungen melden. In einem solchen Fall wird der Operateur nicht mit den Details behelligt.

Technische Umsetzung

Aggregierte Alarme

Im Alarm-Tree können Knoten einer höheren Ebene als aggregierte Alarme (auch als Summenalarme bezeichnet) gekennzeichnet werden. Ein als Summenalarm gekennzeichneter Knoten aktualisiert bei einer Veränderung seines Alarm-Zustands eine an dem Knoten hinterlegte PV.

Diese PV wiederum kann in SDS-Grafiken visualisiert werden oder zur Versand von Alarm-Meldungen auf einer hohen fachlichen Ebene benutzt werden. Dies ermöglicht eine Arbeitsweise, bei der nicht jeder einzelne Alarm versandt werden muss (z.B. per SMS), sondern fachliche Strukturen gebildet werden können, die erlauben, Alarm-Mengen zu beherrschen.

Obwohl der Alarm-Tree Editierfunktionen besitzt, ist es aktuell nicht über den Alarm-Tree möglich, Knoten zu Summenalarmen zu machen, dies muss direkt im LDAP eingetragen werden. Der Grund dafür liegt in der Verwendung dieses neuen Servers durch MKK, hier wird die Tree-Konfiguration mittels .ldif-Datei aus dem Oracle-System erzeugt und direkt ins LDAP geschrieben. Editierfunktionen im Alarm-Tree werden erst hinzugefügt, wenn dieses Konzept auch bei den Kryo-Operateuren verwendet werden soll.

Der Summenalarm-Server liest die Alarme aus dem Alarm-Server (Dal2jms). Vom Dal2jms werden die aktuell auftretenden Alarme empfangen, weiterhin werden bei einem Neustart des Summenalarm-Servers die aktuell vorliegenden Alarme gelesen. Dadurch ist der Summenalarm-Servers stets aktuell.

Summenalarm-IOC

Die an einem Summenalarm-Knoten als Schreibziel hinterlegte PV bildet auf einen Record auf dem sog. Summenalarm-IOC ab. Dieser muss eine dazu passende EPICS-Database enthalten.

Der verwendete IOC ist aktuell mkklxioc05.desy.de.

Damit das Schreibziel einen Alarm an das JMS (und damit auch an das AMS) schicken kann, muss der dal2jms-Server eine entsprechende Konfiguration enthalten, siehe dazu weiter unten beim Stichwort Konfiguration der Schreibziele.

Management-Befehle

Nach einer Änderung der Konfiguration des Alarm-Trees im LDAP kann aus einer CSS-Station heraus die Aktualisierung des Alarm-Servers (Dal2jms) ausgelöst werden. Details dazu finden sich im Manual des Dal2jms-Servers.

Bei dieser Akutalisierung wird der Summenalarm-Server ebenfalls aktualisiert, d.h. dass die LDAP-Konfiguration erneut eingelesen wird und die Änderungen an den aggregierten Alarmen verarbeitet werden. Das Ergebnis der Aktualisierung kann im Log eingesehen werden, siehe hier.

Folgendes ist zu beachten: Wenn ein neuer aggregierter Alarm definiert wird (d.h. ein Knoten wird zu einem Summenalarm gemacht), muss die Database in dem Summenalarm-IOC neu erstellt und geladen werden; ebenso wenn ein Summenalarm-Knoten entfernt wird.
Bei MKK erfolgt die Erzeugung des LDAP-Updates sowie der Database für den Summenalarm-IOC durch das Oracle-System.

Funktionskontrolle

Metriken

Während des Betriebs des Summenalarm-Servers werden Metriken erstellt und die Ergebnisse auf einem Soft-IOC veröffentlicht. Dabei handelt es sich im Wesentlichen um Datenraten für die verarbeiteten Alarme.

((noch nicht implementiert, August 2019))

Logging

Der Summenalarm-Server schreibt Log-Meldungen in rollend organisierten Dateien. Diese finden sich im Verzeichnis …/logs neben dem Executable. Weiterhin werden die Streams Standard-Out und Standard-Err gelogged.

Ausgewählte Log-Meldungen werden auch per JMS verschickt und können in der Log-Table auf dem Topic DAL2JMS_LOG eingesehen werden. Mit der Wahl dieser Topic sind alle für die Alarm-Server relevanten Logs übersichtlich zusammengefügt.

Log-Meldungen sind nicht für die Operateure gedacht, sondern für die Entwickler. Die nächsten beiden Abschnitte erläutern, wie Fehler in der Verarbeitungskette für die Operateure sichtbar gemacht werden.

Überwachung des Summenalarm-IOCs

((fehlt: was passiert, wenn der Ziel-IOC weg ist?))

Darstellung von Fehlern im Summenalarm-IOC

Im Summenalarm-Server können unterschiedliche Verarbeitungsfehler auftreten:

• Die LDAP-Konfiguration ist nicht lesbar, z.B. auch nach einem Update
• Die Verbindung zum JMS-Server ist gestört.

Da der Summenalarm-Server selbst keine Benutzungsschnittstelle besitzt, wird der Summenalarm-IOC zur Ausgabe verwendet. Der Summenalarm-Server setzt alle Records in den Zustand Disconnected, um den Operateur aufmerksam zu machen.

Einbindung des Alarm-Aggregations-Servers

Grafik mit dem Datenfluss

LDAP

Der LDAP-Server ist unter der fachlichen Adresse krykldap.desy.de zu erreichen. Dort ist der Alarm-Tree gespeichert.

• Der Alarm-Tree enthält die hierarchische Anordnung der PVs
• und die Kennzeichnung derjenigen Knoten, die als Summenalarme dienen.
• Weiterhin werden die PVs, die als Schreibziele dienen, hier konfiguriert.

Konfiguration der Schreibziele

Der Summenalarm-IOC enthält die PVs, die als Schreibziele dienen. Damit dort konfigurierte Alarme auch zu JMS-Nachrichten werden, müssen sie ebenfalls im Alarm-Tree konfiguriert werden.

Dafür gibt es den technischen Hauptknoten Beacons. In diesem Knoten werden die sog. Beacon-Records definiert, diese dienen der Überwachung des dal2jms-Servers. Außerdem werden hier die PVs aufgelistet, die als Schreibziele für den Summenalarm-Server genutzt werden.

IOCs

Die Prozessleitrechner sind die Quelle für die Alarme. Sie laufen i.d.R. ebenso wie der Summenalarm-Server im Kontrollnetz.

Ein ausgewählter IOC (Summenalarm-IOC) enthält die Database für die Summenalarm-Records und wird vom Summenalarm-Server als Schreibziel verwendet.

JMX-Server

Der Summenalarm-Server kann über die JMX-Management-View einer CSS-Installation administriert werden (nicht in obigen Diagramm dargestellt). Dazu meldet sich der Summenalarm-Server beim Start beim JMX-Management-Server unter dem Namen AlarmAggregation an. In der JMX-Management-View stehen nun verschiedene Befehle zur Verfügung:

• Statusabfrage
• Statistikabfrage
• Möglichkeit zum Restart

Der fachliche DNS-Name des JMX-Management-Servers lautet krykmars.desy.de.

((Preferences für JMX fehlen))

Installation

((fehlt: Endgültige Installation auf einer virtuellen Maschine inkl. fachlichem Alias))

Preferences für den Summenalarm-Server

Preferences für CSS-Stationen

CSS-Stationen müssen so konfiguriert werden, dass sie den Alarm-Server (Dal2jms) für die Fachgruppe MKK nutzen. Diese Einstellungen sind im Handbuch des Dal2jms-Servers im Abschnitt Preferences für CSS-Stationen beschrieben.