The DSS Back-end Giulio Morpurgo, IT/CO Outcome of the hands-on exercise The hands-on exercise The User was required to perform realistic operations Act as a GLIMOS, creating and configuring a few DSS entities (I/O channels, Alarm Conditions, Alarm-Action relations) Act as an OPERATOR, acknowledging Alarms, resetting Actions, and getting access to more detailed information This practical exercise gave the DSS community the opportunity of discussing both the Back-end functionality and its User Interface, identifying the areas that require improvements. Who took part (1) People representing the different experiments came separately and performed the exercise. After every visit I tried to implement improvements following their comments and suggestions. Therefore each new group was interacting with an interface already improved compared with the one seen by the previous group. In the following slides, I will try to summarize the comments from the different people, and I will show and explain most of the modifications originating from these comments. Who took part (2) Gianpaolo (ATLAS) Rolf & Clara (LHCb) Clara Lennart, Andre`, Marc Tavlet (ALICE) Helfried (ATLAS) I also received additional input from Christoph & Frank (CMS) Helfried again ! Many thanks to all of them for their patience & time. It was a very useful exercise for me, and the Back-end User Interface has benefited a lot from it. Feedback & Modifications Interface Issues Cosmetics & General User friendliness Front Panel Main Configuration panel Alarm Condition creation and visualization Alarm-Action relations Functionality Issues Alarm Location & Subsystem ? Safety issues Logging of events Synoptic system Alarm-Action Matrix insights AS AN EXAMPLE, WE LOOK AT THE PANEL TO CONFIGURE ANALOGUE INPUT CHANNELS THE OLD PANEL AS IT INITIALLY APPEARED. The appearance of a configuration panel (old) THE USER IS CONFUSED BY THE AMOUNT OF UNNECESSARY INFORMATION DISPLAYED THE HISTORY AND THE FOR YOUR INFORMATION PARTS ARE DISPLAYED, DESPITE THE FACT THAT AT THIS STAGE THEY DO NOT CONTAIN ANY MEANINGFUL INFORMATION. THE USER DOES NOT HAVE A CLEAR IDEA ON WHERE TO START (ADD NEW or SELECT FROM THE LIST) SOME INFORMATION IS ONLY MEANINGFUL FOR A DSS EXPERT NOW ONLY MEANINGFUL INFORMATION ARE DISPLAYED AT ANY STAGE. NOW ONLY MEANINGFUL INFORMATION ARE DISPLAYED. (notice also how frames are used to better visually identify the different logical parts of the panel) The appearance of a configuration panel (new) THE NEW PANEL WHEN IT STARTS, OR AFTER THE DELETION OF AN ITEM. Notice the short instructions to guide the User through the different options. THE PANEL AFTER THE USER CLICKS ON ADD NEW. AS THE NEW CHANNEL DOES NOT YET EXIST, NO HISTORY OR ONLINE INFORMATION ARE SHOWN AFTER AN EXISTING ITEM HAS BEEN SELECTED, IT MAKES SENSE TO DISPLAY THE HISTORY AND THE ONLINE INFORMATION FOR THAT ITEM. The usage of colors in the Configuration Interface I had originally used colors in an attempt to identify the different parts of a panel (e.g. green header labels) or to distinguish between new and already existing items. This was found to be counterproductive and confusing. So now I removed (most of) the colors and I used frames instead, trying to be consistent and to use them as containers of components logically linked. EXCEPTION : YELLOW and CYAN PUSH BUTTONS YELLOW BUTTONS -> DATAPOINT MODIFICATION (->EFFECT ON FRONT-END) CYAN BUTTONS->NO DATAPOINT MODIFICATION Cosmetics & Low Level User friendliness It was not always evident for the User where to click Remove borders from the labels, to better distinguish them from push buttons or input fields. Make the labels such that, when clicked, they transfer the focus to the corresponding input field. Explicitly state that all the fields with orange label must be filled. Cosmetics & Low Level User friendliness The TAB problem. In the panels used to configure DSS entities the TAB order from one input field to the next is not properly set. This is due to the fact that these input fields were not created in the order they appear on the panels (as the panels evolved quite a lot) This will be fixed by going through the panels and recreating the input fields in the right order In theory, it should also be possible to specify the Tab Order directly in PVSS, using the panel editor. But this feature seems to work properly only on simple panels. Cosmetics and Low Level User friendliness Some parameter names werent very intuitive TOO_LOW (HIGH) replaced by ALARM_LOW (HIGH) REASONABLE MIN (MAX) replaced by CREDIBLE MIN (MAX) SAMPLING TIME replaced by LATENCY TIME (secs) ON FAILURE : (IGNORE, OPTIMISTIC,PESSIMISTIC) replaced by (INHIBIT,USE VALUE, TRIGGER) Cosmetics and Low Level User friendliness Add CLOSE button Both the CLOSE button and the X exit button now check if anything might need to be saved Cosmetics and Low Level User friendliness Creation of a DSS Expert User profile Maintenance panels and information non relevant for the Glimos or the Operator will be only shown to Users configured as Experts. For instance, the Channel Index or Alarm Index information, showing the position of an item in the PLC Datablocks, will be only shown to Expert Users Front Panel : as it was MAJOR REMARKS : 1) THE PANEL CONTAINS TOO MANY THINGS 2) THE PANEL CONTAINS YELLOW AND RED COMPONENTS EVEN WHEN THERE ARE NO ALARMS OR ACTIONS 3) IT IS CONFUSING TO HAVE ALARMS AND ACTIONS IN THE SAME TABLE 4) THE TABLE EXTERNAL SYSTEMS IS NOT NEEDED Front Panel : as it is now MAJOR MODIFICATIONS : 1) ALL GREEN AND CYAN WHEN SITUATION IS NORMAL 2) NON-VITAL INFORMATION IS AVAILABLE BY SINGLE CLICK 3) TWO SEPARATE AND SIMPLER TABLES FOR ALARMS AND ACTIONS 4) PANEL COMPONENTS CHANGE COLOR WHEN SOMETHING HAPPENS 5) THE TABLE EXTERNAL SYSTEMS HAS BEEN SUPPRESSED Front Panel : why it is like it is THE ALARM AND ACTION TABLES REFLECT WHAT THE F-E HAS DONE TO PROTECT THE EXPERIMENT. THE F-E DOES NOT WARN: IT DOES. THE LESS IMPORTANT EVENTS, THAT DO NOT REQUIRE ANY SAFETY ACTION, ARE EASILY AVAILABLE, AND WILL ALSO BE SHOWN ON THE SYNOPTIC. THEY ARE NOT MIXED WITH THE MOST IMPORTANT STUFF THE BUTTON TO ACCESS THE SEQUENCE OF EVENTS Main Configuration Panel : as it was MAJOR REMARK : THE PANEL DISPLAYS TOO MANY THINGS. IT IS NOT EASY TO FIND WHICH BUTTON OPENS THE PANEL THAT CONTAINS THE SPECIFIC OPERATION WANTED BY THE USER Main Configuration Panel : as it is now SPLITTING THE PANEL AMONG DIFFERENT TABS MAKES IT MORE USER-FRIENDLY Alarm Condition definition panel (1) The general feeling is that the panel is very complex. The sequence of clicks needed to create/modify an alarm condition is not intuitive enough. Also the visualization of the Alarm Condition structure is not intuitive enough. Consider alternative methods. On the other hand despite the complexity, it is useful to simultaneously display all the components of a given Alarm Condition. The crowdedness of the panel derives from the amount of information possibly related to a complex Alarm Condition. If the complexity is not needed, the panel can be simplified. Alarm Condition definition panel (2) Attempts to improve the situation Separate panels for Simple Alarms and Simple Compare Alarms (next slides). Possible introduction of a panel to create Alarms using only two Sub-condition blocks. (Planned) redesign of the Complex Alarm Condition panel. Try different ways of representing the same information ? Use a popup panel to edit the Sub-condition blocks ? Simple Alarm Condition panel THE PANEL DURING THE EDITING OF AN EXISTING ALARM CONDITION NOTICE THE MORE EXPLICIT NEGATION TOGGLES, WHERE IS AND IS NOT HAVE REPLACED + AND - THE PANEL, WHEN A NEW ALARM IS BEING CREATED FIRST THE USER SELECTS A SENSOR, AND ONLY THEN HE CAN SPECIFY A CONDITION (IF REQUIRED) Simple Compare Alarm Condition panel Simple Alarm detail panel WHEN THE ALARM IS NOT TRUE . WHEN IT BECOMES TRUE AND WHEN IT IS MASKED (AS THE SENSOR PT_8195 IS INHIBIT) Simple Compare Alarm detail AS IT IS NOW WHEN IT STARTS AS IT WAS Alarm-Action relations REMARK : DISTINCTION BETWEEN ALARMS AND ACTIONS WAS NOT CLEAR ENOUGH AND WHEN AN ALARM IS SELECTED Instructions have been added New Set/Reset Inhibit panel THE SET/RESET TOGGLE BUTTON HAS BEEN SPLIT INTO TWO SEPARATE BUTTONS THE PANEL COMPONENTS HAVE BEEN REORGANIZED COLORS ARE USED WITH MORE PRECAUTION. HERE THEY DRAW THE USERS ATTENTION ON THE PART WHERE HE CAN INTERACT New Modify Thresholds panel THE PANEL COMPONENTS HAVE BEEN REORGANIZED Other remarks (1) wizard-like panels : why I do not like it The GLIMOS will repeat the configuration of items (inputs, outputs, alarms) hundreds of times. He will be an expert, not a newcomer that does it one time in his life. The current approach is much more effective. PVSS Alert/event display I have nothing against it. Simply I hadnt yet learned how to use it. If this is what you want, I will try to use it although, after a first try, and after investigating its functionality together with Joachim, it appears that the handling for the Actions cannot be implemented in the same simple and logical way as in the present system. PVSS Alert/Event screen A FEW PROBLEMS : IN THE DSS THE ACKNOWLEDGE OF AN ALARM AND THE RESET OF AN ACTION ARE COMMUNICATED TO THE F-E (via OPC, by writing on a datapoint element). WHEN THE USER CLICKS ON THE ACKNOWLEDGE (or RESET) FIELD, A PVSS FUNCTION HAS TO BE CALLED, AND IT SHOULD KNOW THE ALARM (or ACTION) NAME. THIS CAN BE READ FROM THE TABLE, BUT IF THE TABLE CHANGES MEANWHILE, THERE IS NO GUARANTEE THAT THE ALARM (or ACTION) NAME IS THE CORRECT ONE. THE CONTENTS OF THE TABLES IS NOT UNDER DIRECT CONTROL OF THE DSS APPLICATION THERE IS NO WAY OF DYNAMICALLY MODIFYING THE CONTENTS OF A CELL. IT WILL BE IMPOSSIBLE TO UPDATE THE ALARM COUNT OF AN ACTION, TO SHOW THE USER WHEN HE CAN SUCCESSFULLY RESET THE ACTION ITSELF. Other remarks (2) It is now possible to recall the Front Panel in front without closing the Configuration Panel or the Dynamic Info Panel. The Summary panels, which display the state of all input channels, alarms and actions, were too overloaded with colors. Now the colors are only used to indicate abnormalities. Also the contents of these panels could be modified in the future, when experience will say which fields are useful and which are not. NEW Other remarks (3) Getting rid of the AI_, DI_, PT_ etc. prefix The prefix could be hidden (it would still exist, but it would not be shown) Exception: when creating Alarm conditions, the User often has to select a channel from a list that contains all the input channels (analogue and digital) defined in his DSS. Here 1) the prefix would help him in selecting the right sensor, 2) if the prefix is not shown, three channels named DI_junk, PT_junk and AI_junk will appear in the list as three junk entries. To fix this, the B-E should forbid to create channels of different type with the same postfix (junk in the example). This will be less intuitive, as the User will not have under his eyes the three lists of DI_xxx, AI_xxx and PT_xxx when he is defining a channel of one of these types. Alarm Location & Subsystem At the moment, Location and Subsystem must be specified for the Alarms The reasons for this choice are The possibility of implementing a check on the Location of the sensors used to defined an Alarm (to avoid using the wrong sensor by mistake). This check is not yet implemented. The same for the Subsystems The decision to show, on the synoptic system, the Location of an Alarm Of course, this strategy can be changed, and we should discuss and decide what is the best solution. Default : enable a newly created Alarm At the moment, a newly created Alarm has to be enabled by hand. This can be easily changed, with no implication for the DSS functionality However Should we disable the Actions of an Alarm when it is modified ? This could avoid unwanted execution of Actions, in case the GLIMOS makes a mistake when modifying the Alarm Safety issues : avoiding false triggers but not the real ones Be careful in automatic sensor failure detection Handling of Max Jump, Credible Min, Credible Max Default Latency values ? Disable actions after alarm modification ? Clearly explain the danger of triggering unwanted Actions when testing Alarms Logging of Events Alarms and Actions coming and going should be logged Should we also log Inputs crossing thresholds or becoming True? The Operator should be able to add a comment to the log-book when acknowledging an Alarm But the acknowledge operation is done on the spot, to stop the siren. Perhaps the Operator could input a comment by clicking the entry in the Past History that he wants to comment. Or he could enter a comment when resetting the Actions. By that time, he should know why the Alarm came and what he had to do to fix the situation. Synoptic system (1) The Synoptic tree will be configured by the Experiment, via the definition of Geographical Locations One Geographical Location == One Synoptic page (or maybe two, a Top View and a Side View). The Experiment will provide the Graphical background corresponding to the different Synoptic pages Every page will contain active spots giving access to Synoptic pages with increased levels of details Synoptic system (2) Should we visualize the different sensors belonging to each Synoptic page as active elements of the Interface (such that, for instance, they show a color corresponding to their state)? If this is the case, we should introduce coordinate fields for each sensor, to be able to draw them on in the right position on the Synoptic page. (next slide) A Synoptic page will then contain two kinds of active spots : Pointers to other Synoptic pages. Click to navigate ! THIS WAS ALREADY IMPLEMENTED Pointers to sensors. Click to see the details of the sensor. YES ! Sensor Synoptic Coordinates Definition A POSSIBLE IMPLEMENTATION : 1) SELECT LOCATION 2) EDIT X,Y,Z FOR ALL SENSORS ATTACHED TO THAT LOCATION. THESE WILL BE USED TO POSITION SENSORS ON THE SYNOPTIC PAGES. THE Z COORDINATE IS NEEDED AS A LOCATION COULD HAVE A TOP VIEW AND A SIDE VIEW SYNOPTIC PAGES REMINDER: SENSORS INHERIT BUILDING AND OTHER PROPERTIES FROM THE LOCATION TO WHICH THEY ARE ATTACHED. Geographical Location (==Synoptic) definition WHICH FIELDS SHOULD WE KEEP ? THESE COOORDINATES DETERMINE THE POSITION OF THE ACTIVE SPOT ON THE PARENT SYNOPTIC. DO WE NEED ALSO A Z COORDINATE ? WE SHOULD USE A STANDARD NAME FOR THE GRAPHICAL FILE(S) ASSOCIATED TO THE LOCATION By the way THE DYNAMIC AND ACTIVE REPRESENTATION OF SENSOR HAS BEEN ADDED TO THE SYNOPTIC PAGES THE LAST BITS MISSING ARE THE GRAPHICAL LAYOUT PAGES (TO BE PROVIDED BY THE EXPERIMENTS) BY CLICKING ON A SENSOR, A PANEL WITH ITS STATE WILL POP UP. AT THE MOMENT, A TOOLTIP IS USED TO SHOW THE NAME OF A SENSOR PT_8193 Alarm-Action Matrix insights : an easier way to look inside the Alarm-Action Matrix. Three new panels were developed, to let the User examine the mutual influence of Input Channels, Alarms and Actions through the Alarm-Action Matrix. They are accessible from the Dynamic Info panel, via a two-level tab. Alarm-Action Matrix insights (1) : Input THIS PANEL SHOWS THE INFLUENCE OF A GIVEN INPUT CHANNEL ON THE ALARMS AND ACTIONS Alarm-Action Matrix insights (2) : Alarm THIS PANEL SHOWS 1) THE CURRENT STATUS OF A GIVEN ALARM 2) THE LIST OF THE INPUTS USED BY THE ALARM, AND THEIR STATUS 3) THE LIST OF THE ACTIONS THAT THE ALARM CAN TRIGGER Alarm-Action Matrix insights (3) : Action THIS PANEL SHOWS 1) THE CURRENT STATUS OF A GIVEN ACTION 2) THE LIST OF THE ALARMS THAT CAN TRIGGER THE ACTION, AND THEIR STATUS 3) THE LIST OF THE INPUT CHANNELS USED BY THOSE ALARMS, AND THEIR STATUS As already mentioned in the previous presentation, several things are still to be done in particular, we still plan to work on Oracle logging of configuration modifications Reading back the parameters sent to the Front-end, to be sure they arrived Definition of operational procedures in different scenarios AOB Conclusions From my point of view, the exercise was very successful. I got a lot of independent and useful suggestions, and I already implemented many of them, with the result of improving both the functionality and the user interface. It was also possible to identify areas where the work should continue, where requirements have to be more explicitly defined, where the functionality or the user interface need improvements. We shall continue to profit from the fact that the software is made in-house. It therefore can continue to flexibly evolve to integrate new requirements, and to fix weaknesses only discovered with usage and experience.