1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

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

10. 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

11. 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

12. 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

13. 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

14. 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