Inhaltsverzeichnis

Todo

• Alarm-Management-View (seit CSS 2.2) ergänzen
• Maintenance Phase beschreiben (neue dal2jms-Version)
• Aktuelle Versionen (CSS und dal2jms) benennen

Aufgaben des Dal2Jms-Servers

Alarme weiterleiten

Eine wesentliche Aufgabe des Dal2Jms-Servers besteht darin, eine Reihe von vorkonfigurierten Prozessvariablen (PVs) zu beobachten und beim Auftreten eines Alarms diesen als JMS-Nachricht weiterzuleiten. Das nachfolgende System Alarm-Management-System (AMS, das ist eine Anwendung die auf JMS-Middleware beruht) bietet dann die Möglichkeit, diesen Alarm zu filtern und an unterschiedliche Interessenten (das sind die sog. JMS-Topics) weiterzuleiten. Schließlich können diese Alarme dann auf CSS-Stationen im Alarm-Tree, der Alarm-Table sowie der Log-Table dargestellt werden (siehe Grafik Alarm-Datenfluss).

Die Konfiguration der interessierenden PVs erfolgt außerhalb des hier beschriebenen Systems und wird in diesem Handbuch nicht erläutert, gelesen wird die Konfiguration aus dem LDAP-Server.

Interconnection Server als Alternative

Es gibt einen prinzipiell anderen Weg, um Alarme in das AMS weiterzuleiten. Dieser Weg erfordert eine Komponente auf dem Prozessleitrechner (IOC), die Alarme direkt an den sog. Interconnection-Server sendet, von dort wird dann das AMS befüttert.

((pros und cons erläutern, Unterschiede: EPICS-Version, Maintenance Phase, Disconnect Management))

Acknowledge (Quittung) verwalten

Um anzuzeigen, dass ein Alarm bearbeitet wird, kann ein Operator im CSS mittels Alarm-Tree oder Alarm-Table den anstehenden Alarm quittieren (auf Denglisch: acknowledgen). Dann erscheint ein Häkchen bei dem Alarm, so dass das Acknowledge auf allen CSS-Stationen sichtbar ist.

Dieses Acknowledge wird nicht nur von CSS-Stationen, sondern auch vom Dal2Jms-Server empfangen. Der Dal2Jms-Server führt eine Liste, in der alle quittierten PVs aufgeführt sind. Das ist erforderlich, damit eine neu gestartete CSS-Station den aktuellen Bearbeitungszustand aller PVs erfragen und anzeigen kann.

Siehe dazu die als Ack bezeichneten Pfeile in der Grafik.

Lokal / global quittieren

Manche CSS-Stationen werden nicht direkt für das Operating benutzt, sondern für Entwicklungsaufgaben oder Funktionsprüfungen. Darum ist es möglich, Alarme zwar zu quittieren, dies aber nicht an die anderen Stationen mitzuteilen.

Dies kann mittels einer Preference eingestellt werden:
  Edit -> Preferences… -> CSS-Applications -> Alarm-Service
dort unten auf der Seite wird der Acknowledge mode gewählt.

Die Operator arbeiten mit dem Mode ‚acknowledge‘, wer die Alarme nur lokal quittieren will wählt dort ‚ignore‘.

Statusänderungen des Dal2Jms-Servers

Die Funktion des Dal2Jms-Servers ist für die Alarmierung essentiell. Darum werden wichtige Statusänderungen des Servers an die CSS-Stationen gemeldet.

Sowohl im Alarm-Tree als auch in der Alarm-Table werden diese Meldungen dargestellt (siehe Screenshot). Der rote Pfeil zeigt, wie man das Meldungsfenster schließen und ggf. wieder öffnen kann. Die jeweils aktuelle Meldung bleibt dort erhalten.

Folgende Statusänderungen werden zur Kommunikation vom und zum Dal2Jms-Server gesendet:

• Der Alarm-Server aktualisiert die Konfiguration des Alarm-Trees aus dem LDAP
  Eine CSS-Station hat den Dal2Jms-Server veranlasst, die PV-Konfiguration erneut aus dem LDAP zu lesen und zu aktualisieren. Das geschieht ohne Unterbrechung des Betriebes (siehe auch Management-Befehle).
• Nach der Aktualisierung des Alarm-Servers wurde der Alarm-Tree neu geladen
  Wenn der Server mit der Aktualisierung fertig ist, sendet er den CSS-Stationen einen entsprechenden Hinweis. Die CSS-Stationen laden dann den Alarm-Tree neu aus dem LDAP, da sich dessen Konfiguration ja gerade geändert hat und bleiben so synchron mit dem Server.
• Der Alarm-Server wurde gestartet. Die angezeigten Daten sind wieder aktuell.
  Nach dem Start des Dal2Jms-Servers wird dieser Hinweis gegeben, damit klar ist, dass es eine Unterbrechung in der Versorgung mit Alarmen gegeben hat. Beim Start liest der Dal2Jms-Server den aktuellen Alarm-Zustand aller PVs aus dem Feld ein. Nachdem das erledigt ist, wird mittels dieser Statusmitteilung CSS veranlasst, den Alarm-Tree neu aufzubauen. Dadurch wird erreicht, dass der Alarm-Tree den aktuellen Inhalt hat.
• Der Alarm-Server wurde gestoppt. ALARME WERDEN NICHT MEHR AKTUALISIERT
  Bevor der Dal2Jms-Server sich beendet, teilt er dies seinen Clients mit. Bei einem Crash des Servers wird das i.d.R. nicht zuverlässig funktionieren. Darum gibt es einen weiteren Überwachungsmechanismus (siehe Funktionskontrolle).
  Diese Meldung sollte üblicherweise nur nach Ankündigung durch MKS-2 bei Arbeiten am Server erscheinen. Ist das nicht der Fall, bitte melden!
• ((hier erweitern wg. Maintenance Phase))

Management-Befehle

Zwei Funktionen dienen dem Management des Dal2Jms-Servers. Diese können aus der Toolbar des Alarm-Trees heraus ausgelöst werden, wenn für den aktuell eingeloggten Anwender die entsprechenden Rechte vorliegen. Diese Rechte sind von der CSS-Konfiguration sowie dem Usernamen abhängig und sind an MKS-2- und MKK-4-Entwickler vergeben.

• Der Alarm-Server (dal2jms) aktualisiert die Alarm-Konfiguration aus dem LDAP (blauer Doppelpfeil):
  Dieser Befehl wird benötigt, wenn die Konfiguration der zu beob­achtenden PVs aktualisiert wurde. Dies geschieht üblicherweise durch den Export einer .ldif-Datei aus dem Oracle-System und dem Import dieser Datei in den LDAP-Server (krykldap).
  Danach muss dem Dal2Jms-Server mitgeteilt werden, dass die Konfigurationsänderung erfolgt ist, daraufhin liest der Server die neue Konfiguration ein und entfernt ggf. PVs bzw. baut neue Verbindungen auf. Nicht geänderte PVs sind hiervon nicht betroffen.
• Der Alarm-Server (dal2jms) aktualisiert die Alarme (Brille mit Pfeil)
  Dieser Befehl weist den Dal2Jms-Server an, die Verbindung zu allen PVs zu erneuern. Das ist normalerweise nicht erforderlich und sollte nur verwendet werden, wenn der Verdacht besteht, dass der Server Verbindungen verloren hat, die aber funktionieren müssten. Dies deutet auf jeden Fall auf einen Fehler hin und sollte darum MKS-2 mitgeteilt werden.

Bemerkung zur Implementation: Management-Befehle für Headless-Server werden üblicherweise via JMX-Kommando aus der JMX-Management-View ((Verweis auf das Confluence-Wiki für diese View fehlt)) ausgelöst. Dieser Weg wurde hier nicht gegangen, da MKK selbstständig diese Befehle nutzt und nicht noch ein weiteres Tool dafür angewendet werden sollte.

((Management View))

((fehlt, ab CSS 2.2.0)

Operator-Befehle

Der Operator kann jederzeit den aktuellen Alarm-Zustand sowie die aktuellen Quittungen (Acknowledges) vom Dal2Jms-Server abfragen. Diese Operation belastet nicht die IOCs sondern wird komplett vom Server erledigt. Ausgelöst wird dieser Befehl durch die grünen Doppelpfeile.

Dieser Befehl liegt auch für die Alarm-Table vor. Dabei ist zu beachten, dass der Dal2Jms-Server weder die Eventtime noch den Text einer Meldung kennt, darum stehen diese Daten nach einer Aktualisierung nicht zur Verfügung.

Funktionskontrolle

Metriken

Während des Dal2Jms-Server-Betriebs werden Metriken erstellt und die Ergebnisse auf einem Soft-IOC veröffentlicht. Neben der Größe des Acknowledge-Speichers werden Datenraten für die bearbeiteten Alarme erstellt. Mit einiger Betriebserfahrung lassen sich darauf Alarme definieren, die eine Abweichung vom normalen Betrieb erkennen lassen.

Das aktuelle Display für die Dal2Jms-Metriken findet sich unter
  CSS/SDS/system/Metric/Metric_Dal2Jms.css-sds.

Beacon-Durchlauf

Um die Funktion des Dal2Jms-Servers sicherzustellen, wird ein kompletter Alarm-Durchlauf durch den Server in folgender Weise überwacht (siehe Abbildung 3: Umgebung des Dal2Jms-Servers, Legende ‚Command‘):

• Gewisse IOCs senden regelmäßig Alarme, die nur der Überwachung des Dal2Jms-Servers dienen (Beacons from selected IOCs).
• Der Dal2Jms-Server sendet diese Alarme ausschließlich an das BEACON-Topic, somit tauchen diese Alarme nicht in der üblichen Alarm-Verarbeitung auf.
• Der Command-Server (siehe 2.5) empfängt diese Alarme vom BEACON-Topic. Gemäß der Totmann-Metapher passiert nichts weiter, wenn die Beacon-Alarme regelmäßig eingehen.
• Wenn die Beacon-Alarme ausbleiben, wird vom Command-Server ein Restart des Dal2Jms-Servers erzwungen.

Folgende Beacon-Alarme werden aktuell genutzt:

• MKK:K:mkkKlima1_beacon
• MKK:K:mkkPPC02_beacon
• MKK:K:mkkpetra3_a_beacon

Logging

Der Dal2Jms-Server schreibt Log-Meldungen in rollend organisierten Dateien. Diese finden sich im Verzeichnis …/logs neben dem Executable. Weiterhin werden die Streams Standard-Out und –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.

Einbindung des Dal2Jms-Servers

Grafik

LDAP

Der LDAP-Server enthält die jeweils aktuelle PV-Konfiguration, in der festgelegt ist, welche PVs vom Dal2Jms-Server beobachtet werden sollen. Auf einer CSS-Station kann dann eine Teilmenge (natürlich auch alle) davon im Alarm-Tree angezeigt werden. Bei der typischen MKK-Einstellung (siehe 2.8.1) werden dann auch nur Alarme von den konfigurierten PVs in der Alarm-Table angezeigt.

Siehe dazu den gestrichelten Pfeil mit der Bezeichnung Initialization in Grafik (Abbildung 3: Umgebung des Dal2Jms-Servers).

Der LDAP-Server muss sowohl beim Dal2Jms-Server als auch bei allen CSS-Stationen konfiguriert werden. Dazu ist sein fachlicher DNS-Name zu verwenden: krykldap.desy.de.

Acknowledge-Speicher

Der Dal2Jms-Server verwaltet eine einfache Datei, in der die aktuell quittierten Alarme gespeichert werden. Dieser Speicher hat den Zweck, den Quittungszustand bei einem Restart des Dal2Jms-Servers nicht zu verlieren. Die Datei enthält die quittierten Alarme in les- und editierbarer Form.

Aus diesem Speicher fragt eine neu gestartete CSS-Station den aktuellen Quittungszustand ab, es können also die Häkchen in Alarm-Tree und Alarm-Table automatisch so gesetzt werden, wie sie auf einer bereits lang laufenden Station gerade dargestellt sind.

AMS / JMS

Das Alarm-Management-System bietet die Möglichkeit, Alarme zu filtern, zu gruppieren und an verschiedene Ziele zu versenden. Das AMS wird hier nicht weiter beschrieben, es sei nur noch darauf hingewiesen, dass das AMS für MKK und für die Kryogenik in zwei komplett getrennten Systemen läuft.

Technisch setzt das AMS auf dem Java-Message-Service (JMS) auf. Nachrichten werden dort in sog. Topics versandt, das sind benannte Queues, für die sich viele Clients registrieren können. Für den Acknowledge-Versand (namens ACK) und den Alarm-Versand (namens MKK_ALARM) gibt es jeweils eigene Topics. Ein weiteres Topic (namens BEACON) wird für die Funktionskontrolle benutzt, siehe hier.

Command-Server

Der Command-Server ist die Überwachungs-Instanz für den Dal2Jms-Server. Zur Funktionsweise der Überwachung siehe 1.6.2. Um den Dal2Jms-Server neu starten zu können, muss der Command-Server auf der gleichen Server-Hardware laufen wie der Dal2Jms-Server.

IOCs

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

 XMPP-Server

((veraltet, es wird der JMX-Server genutzt))

Der Dal2Jms-Server kann über die Contacts-View einer CSS-Installation administriert werden. Dazu meldet sich der Dal2Jms-Server beim Start beim XMPP-Server unter dem Namen dal2jms an. In der Contacts-View stehen nur verschiedene Befehle zur Verfügung:

• Statusabfrage
• Statistikabfrage
• Möglichkeit zum Restart

Der fachliche DNS-Name des XMPP-Servers lautet krykopenfire.desy.de. Dies ist bei CSS-Stationen unter

  Edit -> Preferences… -> CSS Core -> Remote Management Login

einzustellen.

Installation auf krykdal2jms

Der Dal2Jms-Server ist aktuell auf einem virtuellen Linux-System auf dem HyperV-Cluster installiert. Um Zugriff auf den Server zu bekommen, aber der Administration auch die Möglichkeit zu geben, den Server zu verschieben, soll zur Identifikation des Servers stets nur dessen fachlicher Name verwendet werden. Das ist ein Alias zum jeweiligen konkreten Server (aktuell krykvmlinuxh), der von der Administration vergeben und ggf. angepasst wird.

Der fachliche Name des Dal2Jms-Servers lautet krykdal2jms.

CSS-Stationen

Es gibt verschiedene Einsatzorte für CSS-Stationen:

• Für den Kontrollraum (BKR)
• Für die Entwickler
• Für Tests
• weitere

Dementsprechende müssen die Preferences angepasst werden. Im Weiteren werden die wichtigsten, im Zusammenhang mit dem Dal2Jms-Server stehenden, benannt.

Wichtige Preferences für CSS-Stationen

Unter dem Pfad

  Edit -> Preferences… -> CSS-Applications -> Alarm

finden sich die wichtigsten Preferences. Hier werden die typischen Einstellungen für eine Kontrollraum-Installation beschrieben.

Auf der Seite ‚Alarm-Service‘ ist einzustellen:

• Synchronisation von Alarm-Tree und Alarm-Table
  Edit -> Preferences… -> CSS-Applications -> Alarm -> Message Table -> Alarm Table
  dort in der Tabelle muss eine Zeile mit den Topics ‘MKK_ALARM,ACK’ existieren und dort muss ‘Sync to tree’ angehakt sein.
  Damit wird dafür gesorgt, dass in der Alarm-Table nur Alarme angezeigt werden, die für den Alarm-Tree konfiguriert sind.

Wichtige Preferences für den Dal2Jms-Server