1. 1 Detector Monitoring requirements ( V.Dattilo for the EGO Operations Group ) ( with the collaboration of S.Braccini)  Short history  Current status  Requirements VIRGO Collaboration Meeting Cascina, June 6-8th, 2005

2. 2 Short history 1/4 Since the beginning of my work on the Detector Operation commissioning activity, I have supported and presented the following statement: The efficiency of the operator during the shift is expected to be increased by adopting the following solutions: to provide the operator with a dedicated console (new Control Room) to define and install on the ‘operator’ console two purposely made Graphical Operator Interfaces (GOIs): - one for controlling & acting on the Detector - one for monitoring the Detector status

3. 3 Short history 2/4 In the Control Room there are tools for status monitoring at the level of some sub-systems (SuspMoni panel, Cl, …). These are spread over several consoles, not integrated. Big Brother provides info on the daemons and computing infrastructures status, only. Often it is needed to check the signal level by opening dataDisplays. Since the number of channels to be displayed for quality purposes is quite large (~hundreds), the dataDisplay is not particularly suitable in this case. A dedicated on-line quality monitoring system was needed. It is intended to summarize in a single graphical interface the status & quality of the whole ITF, giving a warning / alarm notification to operators once signals exceed the standard values.  We adopted a software tool available at that time and under development by LAPP: the Virgo Data Quality Monitor

4. 4 Short history 3/4 Early version (summer 04):

5. 5 Short history 4/4 Subsequent work on the Virgo Data Quality Monitor: Sub-systems triggered to configure and tune the related section (Alignment, Injection, Vacuum, Enviromental, …) From the interaction with the DO, simplification of the web display by Didier and Benoit (removal of the hexadecimal content of the flags, graphical representation of the flag instead of text, hyperlink to the error message in case of red flag) Recent work of two operators ( R.Spagnoli, D.Vannozzi ) to tune thresholds and to add further flags to the existing sections Temporary solution by Didier to the web page refresh problem and to allow hyperlink reading (introduction of the static/dynamic button) Introduction of the BRMS tool by Didier and Benoit A screen in control room dedicated to the permanent displaying of Quality Monitor web page

6. 6 Current status 1/2 To date version (June 05):

7. 7 Current status 2/2 Notwithstanding the above mentioned work and efforts on the Virgo Data Quality Monitor, it is still not really used as a complete GOI for monitoring the Detector. The main identified reasons for this are: There are too many flags in red (ie denoting an error) even if the sub- system is in the required state (but different from the standard state): this depreciates the attention paid to the red flags. The configuration of some sub-systems is still missing. But, on the other hand, for some sub-systems, like Locking, the configuration should be “dynamic” instead of a “static” one. Sometimes the information provided is apparently not reliable: the involved flag not becoming red (due to a bug or to the page erroneously left in “static mode”) Lack of instructions concerning a well defined operator’s action associated to a given red flag The complementary monitoring with Big Brother scatters the operator’s attention

8. 8 Requirements 1/4 Based also on the experience gained during the DO activity and from the work and usage of the Quality Monitor tool, the requirements for the future improvements have been better identified and clarified. 1. The GOI for Detector Monitoring should display (and store) on-line information on the status of the Detector. The main page should be split into two panels: - one panel (Main panel) displaying sections that when outside the standard/required state triggers an operator’s action (for instance a loop opened, a server crashed, the onset of an oscillation, etc) - one panel (Additional panel) displaying sections that when outside the standard state the operator cannot undertake any action (for instance, wind too strong, earthquake, etc), but the info is useful to the operator for a better understanding of the situation. Ultimately, this additional panel could be embedded in the logic of the the Main panel flags.

9. 9 Requirements 2/4 2. A set of colors denotes the message level. Proposal: Flag colorDenoted messageaction Green Standard state o.k., no action YellowWarning! Check situation when possible and undertake operator’s action if necessary RedError! Immediately undertake well pre-defined operator’s action Grey Flag not available At least one channel used to compute the flag is missing. Operator’s action to recover the situation Blue Requested state The state is different from the standard one, but is in compliance with the requested one* * Concept of “smart” flag

10. 10 Requirements 3/4 3. Information should be provided in a hierarchical way and with more features: by clicking on each flag, link to a page displaying additional info on the related sub-system. The page is split into 3 panels: - one panel displaying the on-line content of channels related to flags outside the green state. - one panel providing the help / procedure related to that event - one panel as part of an embedded logbook where the operator can enter notes and undertaken actions 4.Some kind of efficient notification of the event, besides the displaying on the screen: -at least a simple beep to the operator during their shift -an sms to persons on call during shifts without operators -message to Alp in case it is possible to undertake some automatic action -e-mail to interested persons -…

11. 11 Requirements 4/4 5. The provided information should cover all the Detector parts: all the sub-systems, but also the related servers and CPUs 6.At least during the commissioning phase, during which changes are taking place almost everyday, the Detector Monitoring System should be configurable in a flexible way by the Operations Group (as well as Moni processes having the same syntax for all the sub-systems). This should preferably include the capacity to debug and make improvements to the system. 7.…