GFA Controls IT Alain Bertrand Wir schaffen Wissen – heute für morgen Another alarm handler concept GFA Controls IT Alain Bertrand Renata Krempaska, Hubert Lutz, Matteo Provenzano September, 2011

Content Why another alarm handler Design Implementation Current status Question / Answers Why did we need a new alarm handler What’s our design How we made the implementation What’s the current status Epics Collaboration Meeting, fall 2011

Why another alarm handler Issues with the standard Alarm handler: Requires to run all the time Change in configuration requires to restart Configuration is error prone and blocks the load The main issues with the alarm handler are that: It requires to run all the time If we change the configuration it requires a restart of the alarm handler Due to the size of the configuration and the fact there is no real checkers it’s error prone and if it’s not correct, then the alarm handler will not restart Epics Collaboration Meeting, fall 2011

Requirements Our requirements: Should run without any GUI. Should be easy to operate. Change configuration while running (without restart). People should be able to subscribe themselves to events (example: mails / text messages). Define who can edit what (on a branch level and its children). Events should be stored in the database. In case the database is not available events should be buffered. Therefore we need something which doesn’t require any GUI to run all the time (like a demon handling the alarms + a GUI to view the status) Easier to operate (more user friendly / modern GUI) Allows to edit the configuration live without reset Have roles of who can edit which branch Logs should be stored on the database (oracle) Configuration should be stored on the database as well. If the database is down or simply slow, events should be buffered and not lost. Epics Collaboration Meeting, fall 2011

Design Allows multiple clients to connect to the alarm handler server. Allows the server to run in cluster. Our design allows multiple clients to connect to the alarm handler server which is a service under windows. We also made is such that we can run the server part in a cluster and all nodes of the cluster will syncronize. Epics Collaboration Meeting, fall 2011

Multiple GUI front-end We implemented 2 different GUIs, first a standalone windows application and later on we made a web interface using AJAX which is our currently standard and used interface. However both GUI could run at the same time if wished. 2 clients implemented (WEB / Ajax & standalone software) Can be used at the same time Epics Collaboration Meeting, fall 2011

GUI Without login Login Last events Current Groups status Last events for the record Records of the group Everyone is allowed to browse the system as well as subscribe to events without any login requirements. Comments help of the group & record Epics Collaboration Meeting, fall 2011

GUI Logged in Batch Logout commands Groups commands Record commands Once logged in the GUI offers lot more functionalities, like all the editing of the configuration. Record commands Epics Collaboration Meeting, fall 2011

GUI Edit Record Epics Collaboration Meeting, fall 2011 We see here the GUI for the edition of a record. Epics Collaboration Meeting, fall 2011

Batch commands Batch commands in XML with online documentation. Our alarm handler accept also some kind of batch commands in the form of an XML document to be pasted in the web interface. This allows to edit the tree in one shot and can be generated from other scripts. Epics Collaboration Meeting, fall 2011

Implementation Package composed of: Server core component Server as command line Server as windows service ASP.NET / Ajax front-end Windows (WinForms) front-end Our package is composed of… Epics Collaboration Meeting, fall 2011

Implementation -Written in C# (.NET 2.0) Uses .NET Remoting for the server / front-end communication Oracle database as storage for configuration and event logging Synchronization between multiple server instance over Oracle tables (in case of a cluster installation). For the implementation we used… Epics Collaboration Meeting, fall 2011

Current status -All the requirement have been implemented -The web GUI is the official GUI for our alarm handler as it doesn’t require deployment of further software, and runs on any platform. -Used in production for a couple of beamlines at Swiss Light Source -Server side is composed of 2 Windows 2008 R2 server in cluster (share nothing configuration). Overall a success even if we may not stop using the old alarm handler for machine monitoring. Current status Epics Collaboration Meeting, fall 2011

Questions? Software is available “as is” if somebody is willing to test it. Requires Visual Studio to be developed. Could run on Mono if required but not tested. Other? Epics Collaboration Meeting, fall 2011