The DSS Back-end

1. The DSS Back-end Design issues & User interface Giulio Morpurgo, IT/CO

2. Table of contents PROPAEDEUTICS • Back-end goals and users • Back-end + Front-end : how does the system work • Configuration • Monitoring • OPC Optimization Strategy • Tools for the Expert • Some Open Issues • Conclusion / Future Developments THE REAL THING WORK IN PROGRESS…

3. Back-end goals and Users : three profiles • Operator • Needs to see, at a glance, what is going on • Needs to react : acknowledge/ reset • Needs tools to get more detailed information • Configurator (“GLIMOS”) • Defines the Safety by configuring and connecting the DSS entities (Sensors, Alarms, Actions) • Has the responsibility for temporarily disabling part of the system • DSS Expert • Assists the Configurator (for instance in testing the Alarm Conditions, but also whenever help is needed) • Needs access to all information to solve possible problems BACK-END GOALS AND USERS

4. PLCDATABLOCKS PVSS DATAPOINTS MONITOR TREND OPC CONFIGURE PVSS ARCHIVE SAFETY PART ARCHIVE MANAGER PVSS CTRL MANAGER SMS/EMAIL Data Flow between Front-end and Back-end MAPPING B-E + F-E: HOW DOES THE SYSTEM WORK

5. DSS Dataflow (2) THE USERS CONFIGURE - MONITOR PLC DATABLOCKS PVSS DATAPOINTS THE HARDWARE OPC CTRL MANAGER SAFETY PART B-E + F-E: HOW DOES THE SYSTEM WORK

6. The DSS PVSS Control Script : event driven • 1) Define all “queries” and “connections” (dpConnnect, dpQueryConnectSingle) • 2) Sleep until a datapoint element referred by the queries or the dpConnect is modified • Start • Find who called and why • Perform necessary action (modify some datapoint) • Go back to sleep • 2bis) In some cases, 2) will modify another datapoint element associated with another query or dpConnect, and therefore 2) is repeated again. B-E + F-E: HOW DOES THE SYSTEM WORK

7. One complex datapoint element, one handler • Be careful with “parallel threads”: do not use two handlers to update the same “list”. CONTROL SCRIPT EVERY MODIFICATION OF A DPE REQUIRING AN UPDATE OF THE ALARM_ACTION_LIST (NEW ALARM, NEW ACTION, ACKNO, RESET, ETC…) HAS TO PASS THROUGH THE SAME HANDLER (ROUTINE 1) QUERY INITIALISATION EVENT HANDLERS PVSS VARIABLE ROUTINE 1 read modify write DATAPOINT ELEMENT (Ex. ALARM_ACTION_LIST) ROUTINE 2 read write ROUTINE n modify B-E + F-E: HOW DOES THE SYSTEM WORK

8. CONFIGURATION Defining the safety

9. PLC DATABLOCKS OPC Configuration General Principles(1/3) • The DSS system is fully “data-driven”; “configuring” the DSS ultimately means changing the data on which the Front-end “safety” code is operating PVSS DATAPOINTS USER INPUT CONFIGURE • The configuration process is incremental. New data items can be added at any time without perturbing the operation on the already defined ones

10. Configuration General Principles (2/3) • What has to be configured • Hardware (Crates and Modules), from PLC Configuration File • Logistic Entities (Geographical Locations, Subsystems) • Basic Entities : THE CORE OF THE DSS SYSTEM • Input Channels • Alarm Conditions • Output Channels (== Actions) • Alarm-Action relationships • Auxiliary Entities (Sensor Types, Channel Classes) • Access Control (Users and their privileges)

11. Configuration General Principles (3/3) • Making it easier • Whenever possible, options are selected from a list • Coherent design of the different panels • Coherent usage of colors through the interface (ex. yellow = action on datapoint, cyan = no action, orange = compulsory …) • CONSISTENCY CHECKS on User Input • …. (filtering, auxiliary entities, “copy” button) • Still to be defined : logging of modifications

12. The Configuration Panel (directly reachable from the Back-end Front Panel) This panel gives access to the specialized panels dedicated to the different configuration operations. The actual configuration actions are restricted to privileged users (GLIMOS). The normal Operator can only view the current configuration.

13. Hardware configuration : “Show modules” panel The Back-end extracts the information about crates and modules from the “PLC configuration file”, and creates the corresponding PVSS datapoints. For consultation only : The User does not have to edit this panel • This panel shows to the User • A list of the I/O modules in his DSS system • The features (type, address, number of channels, hardware address …) of each module • The current allocation state of the module (which sensors or actuators are connected to the module)

14. Logistic entities : user-defined classification of DSS items • Every entity (input channel, alarm condition, action) • - belongs to a subsystem • - is attached to a location • -Locations • - user defined • - tree structure • - used by the system to build the synoptic tree • -Subsystems • - user defined • - used to filter selection list INPUT CHANNELS ACTIONS (OUTPUT CHANNELS) ALARM CONDITIONS

15. LIST OF DEFINED ITEMS PARAMETERS RELATIONS AND DYNAMIC INFORMATION ACTION ON DATAPOINT NO ACTION ON DATAPOINT Subsystem Configuration LIST OF MODIFIED ITEMS

16. ROOT LO_lab LO_lab_rack1 X and Y will determine the position on the synoptic panel Click here to see all items currently attached to this location Geographical Location Configuration

17. INPUT CHANNELS (DIGITAL, PT100, 4to20mA) LOGICAL CONDITIONS LEVEL2 SUBCONDITIONS - N_OF_M - COMPARE ALARM CONDITIONS ALARM-TO-ACTION RELATIONS OUTPUT CHANNELS (ACTIONS) DSS Main Entities (defining the detector Safety) EXIST ALSO IN THE FRONT-END • Input and Output channels • correspond to real hardware • User configured • Logical Conditions • Autom. derived from the Inputs • Input value versus thresholds • Used by the Alarm Conditions • Alarm Conditions • are “software” (data) entities • User defined • Mapped into the PLC memory • Alarm-to-Action • Link Alarms to Actions

18. Configuring the DSS Main Entities THE FOLLOWING THINGS HAVE TO BE IMPLEMENTED IN THE BACK-END DATAPOINTS AND IN THE CONFIGURATION PANEL SCRIPTS • Mapping the Front-end representation (OPC items) • Determine the position of an entity in the corresponding Front-end datablock (next slide) • Define the OPC addresses • Checking the consistency of the User’s input • Ex. Low threshold < High threshold • Ex. High threshold < Max. Physical Value • Ex. An Alarm Condition can effectively become true or false. • Track the interdependences among the different entities • which Inputs are used by which Alarm • which Actions are triggered by which Alarm

19. Determination of the position of an item in the corresponding Front-end datablock • Items corresponding to real hardware (I/O channels) • The position is determined from the address of the I/O module to which the channel is attached (and from the channel number) • “Software” items (Alarm Conditions, Alarm-to-Action relationships, N_OF_M, COMPARE) • The Back-end uses some PVSS datapoints as “allocation lists” for these entities. • Every time a new item has to be created, an entry is removed from the corresponding “free” list. • If later on the item is deleted, the corresponding entry is added again to the “free” list.

20. THE FIELD “MODULE NAME” WILL LET THE USER SELECTING A I/O MODULE ONLY AMONG THE ONES SUPPORTING 4to20mA SENSORS PLEASE NOTE THAT THIS FIELD IS NOW CALLED “CHANNEL”. IT DEFINES THE INDEX OF THE POSITION (IN THE I/O MODULE) TO WHICH THE SENSOR IS ATTACHED From MODULE_NAME and CHANNEL the system gets the position in the F-E datablock, and the “Channel Index” (for an Analogue Channel the index goes from 8193 to 9216) PHYSICAL MIN and MAX define the physical range for the Sensor, and are used to convert from real numbers to the 16-bit acquisition value Here is where 4to20mA and PT100 are different (for PT100 these values are predefined) THE FIELDS “SENSOR TYPE” AND “CHANNEL CLASS” ENABLE THE USER TO FILL THE SECTIONS BELOW WITH PREDEFINED VALUES REASONABLE MIN and MAX define a range out of which the Sensor value should be considered wrong (ex. The temperature in an office will never go below 0). The goal is to avoid false alarms TOO_LOW and TOO_HIGH define the thresholds out of which the situation has to be considered as potentially dangerous and an Alarm could be generated The WARNING values are entirely treated at the Back-end level. They are not part of the Safety Chain NEW: the Copy button will copy all parameters (apart from Name, Module, Channel) of an existing datapoint to a new one Analogue Channel Configuration (4to20mA)

21. FOR A PT100 “CLIMATE” TEMPERATURE SENSOR, SOME PARAMETERS ARE PREDEFINED AND CANNOT BE MODIFIED BY THE USER. THEY ARE MARKED IN GREY THE “ON FAILURE” BEHAVIOR CAN BE SET TO IGNORE (==inhibit on error) OPTIMIST(==use value like if sensor was good) PESSIMIST(==trigger on error) (this applies also to 4to20mA and digital sensors) PT100 Configuration

22. THE SYSTEM WILL NOT LET THE USER SELECTING A CHANNEL ALREADY OCCUPIED Digital Input Channel Configuration SIMPLER THAN THE ANALOGUE CHANNEL CASE, BUT THE BASIC STRUCTURE OF THE PANEL (AND ALSO OF THE SOFTWARE BEHIND) IS THE SAME

23. Alarm Condition Configuration (1/5) • An Alarm Condition is a logical expression of values and logical states of one or more Input Channels • In the DSS Front-End implementation, an Alarm Condition is a “N_OF_M” function of up to 8 sub-conditions. • Each sub-condition is either • An elementary comparison (Analogue Sensor TOO HIGH (or TOO_LOW), Digital sensor TRUE). • A “N_OF_M” function of up to 8 elementary comparisons. • A “COMPARE” function, where the difference between two analogue values is compared with a threshold value. • Every element (elementary comparison, N_OF_M or COMPARE function) can also be negated.

24. THIS ALARM USES ONLY ONE SUB-CONDITION, OF THE “COMPARE” KIND IF THE ALARM WAS “DISABLED”, IT WOULD NOT BE PROCESSED BY THE FRONT-END IF THE ACTIONS ARE DISABLED, THE FRONT_END WILL PROCESS THE ALARM, BUT IT WILL NOT TRIGGER THE ACTIONS EVEN IF THE ALARM WAS TRUE THIS IS THE ID THAT THE SYSTEM HAS ALLOCATED FOR THIS ALARM WHILE 12239 IS THE ID ALLOCATED FOR THE “COMPARE” FUNCTION Alarm Condition Configuration (2/5) A SIMPLE CONDITION : ALARM IS TRUE IF |PT_8193-PT_8194|>2.0

25. Alarm Condition Configuration (3/5) A “TOO_HIGH” condition means comparing the measured value for an analogue sensor with the “TOO_HIGH” threshold defined in the sensor configuration. Once more, the User is assisted by the system, that presents a list of all the defined analogue sensors. The list could even be filtered if the User had selected a specific Subsystem

26. THE “HIDE”, “SHARE” and “CLONE” buttons are used to reserve, share or copy a sub-condition THIS BLOCK READS LIKE IF DI_261 OR NOT DI_262 THE DIFFERENT POSSIBILITIES FOR THE USER WHEN DEFINING A SUB-CONDITION TYPE. THE “ALE” OPTION IS USED TO SELECT AN ALREADY DEFINED SUB-CONDITION Alarm Condition Configuration (4/5) A MORE COMPLEX ALARM CONDITION

27. Alarm Condition Configuration (5/5) • Consistency checks before validating the Alarm Condition and writing it into the PVSS Datapoint • Detect repetitive usage of sensors • Detect repetitive usage of sub-conditions • Fully test the Alarm Condition, to detect “contradiction” that would make the Condition always True or always False. To do this : • Make a list of all sensors used more than once • One sensor at a time, assign to the sensor the different logical values, while keeping the other sensors used by the Condition as undefined : for each case compute the Condition value • Verify that the values are neither all True, nor all False

28. SELECT AN ALARM : THE ACTIONS CURRENTLY CONNECTED TO IT WILL BE LISTED. A DELAY BETWEEN THE ALARM AND THE ACTION CAN BE SPECIFIED TO CONNECT AN ACTION, SELECT IT FROM THE LIST. TO DISCONNECT AN ACTION, CLICK IN THE “DELETE” FIELD Connecting Alarms with Actions

29. Configuring Alarm Help for the Operators TO BE REFINED … • VIA THIS PANEL THE USER CAN FILL • ALL THE INFORMATION THAT THE OPERATOR WILL BE SHOWN WHEN LOOKING AT THE DETAILS OF AN ALARM • THE SMS AND EMAIL ADDRESSES THAT SHOULD BE NOTIFIED • (NOT YET IMPLEMENTED)

30. LIST OF THE SHARED “N_OF_M” LIST OF THE SHARED “COMPARE” IN THIS CASE, THE MODIFICATION IS REJECTED, AS IT WOULD MAKE THE ALARM “AL_BERTO” WRONG THE USER CAN TEST THE MODIFICATION BEFORE SAVING IT Editing a Sub-condition THE USER CAN MODIFY THE SUB-CONDITION WHILE VIEWING THE OLD SETTING • A Sub-condition used in one or more Alarm Condition can be modified if • Its shared flag is set • The modification will not break the correctness of one of the Alarms

31. AS THESE ARE THE THINGS THAT COULD SWITCH PARTS OF YOUR DETECTOR OFF, IT IS GOOD PRACTICE TO USE MEANINGFUL NAMES AND DESCRIPTIONS Configuring an Action (==Output Channel) VERY SIMILAR TO CONFIGURING A DIGITAL INPUT

32. Sensor Types and Channel Classes THESE TWO PANELS ENABLE THE USER TO DEFINE CONFIGURATIONS THAT CAN BE LATER INHERITED BY SEVERAL INPUT CHANNELS IN THIS CASE THE PARAMETERS ARE PREDEFINED “PHYSICAL” PROPERTIES, USED IN CONVERTING BETWEEN RAW ACQUISITION VALUES AND REAL NUMBERS “LOGICAL” PROPERTIES, USED IN ALARMS, WARNINGS AND DETECTION OF FAULTY SENSORS

33. THIS PANEL ENABLES THE USER TO SET/RESET A INPUT INHIBIT • IT SHOWS • A LIST OF ALL THE INHIBIT SENSORS • THE CURRENT STATE OF THE SENSOR • THE CONSEQUENCES OF THE SET/RESET OPERATION IF PT_8194 IS INHIBITED, AL_8194 WILL BECOME FALSE, BUT THE SYSTEM WILL NOT BE ANYMORE ABLE TO EVALUATE AL_CAPONE “Frequent” modifications : Inhibiting a Sensor IT COULD HAPPEN THAT AN ALARM IS TRIGGERED BECAUSE A SENSOR IS GIVING A WRONG VALUE IF THIS IS THE CASE, AFTER HAVING CHECKED EVERYTHING, THE SENSOR HAS TO BE INHIBITED IN ORDER TO RESTORE THE DETECTOR’S OPERATIONAL CONDITIONS

34. “Frequent” modifications: Change a Threshold SENSOR PT_8194 IS MEASURING 22.77 DEGREES. IT IS MARKED AS “TOO_HIGH”, AS ITS “HIGH” THRESHOLD IS SET AT 20 DEGREES CHANGING THE TOO_HIGH THRESHOLD FROM 20 to 25 DEGREES WOULD CHANGE THE SENSOR STATE FROM “TOO_HIGH” TO NORMAL THIS COULD HAVE AN IMPACT ON THE CURRENT STATE OF THE ALARMS USING PT_8184. THE USER CAN TEST THIS IMPACT BEFORE ACTUALLY CHANGING THE THRESHOLD IN PARTICULAR, THE ALARM AL_8194 WOULD CHANGE FROM “TRUE” TO “FALSE”

35. Configuring Users and Access Rights • It goes without saying that all the configuration operations described until now can only be carried out by authorized Users • The normal Operator will only have “Read” and “Ack-Reset” rights. • The privileges currently available depend on who is logged in on the Front Panel. In case of necessity, a GLIMOS can login, and later logout, without having to restart the Front Panel PANEL TO CREATE DSS USERS AND ESTABLISH THEIR ACCESS RIGHTS

36. MONITORING What's happening, and why

37. Monitoring Goals • INFORM • Put under the Operator’s eyes a complete overview of the current DSS status (Alarms, Actions, Sensors) • RESTORE • Enable the Operator to easily take the necessary “normality restoring actions” (acknowledge Alarms, reset Actions) • UNDERSTAND • Give access in a friendly way to more detailed information, useful to better understand the DSS behavior

38. Monitoring Panels • INFORM & RESTORE • Front Panel • UNDERSTAND • Detail Panels • Summary Panels • Trend Panels • Synoptic Panels

39. CLICK HERE TO CHANGE WHO IS LOGGED IN MORE DETAILED INFORMATION ARE AVAILABLE BY CLICKING HERE HERE ALL THE CURRENTLY ACTIVE ALARMS AND ACTIONS ARE DISPLAYED. THIS BUTTON GIVES ACCESS TO THE EXACT SEQUENCE OF EVENTS AN ALARM IS “MASKED” IF THE FRONT-END IS UNABLE TO EVALUATE IT (DUE TO INHIBIT OR BROKEN SENSORS) CHANNELS OUT OF RANGE, IN WARNING, INHIBIT OR FAULTY ARE DISPLAYED HERE THE OPERATOR ACKNOWLEDGES THE ALARMS AND RESETS THE ACTIONS BY CLICKING HERE. SHOW SUMMARY PANELS SHOW CONFIGURATION PANEL SHOW SYNOPTIC PANELS HISTORY TABLE, WHERE ALL THE EVENTS ARE SHOWN The DSS Front Panel

40. THE ALARM IS TRUE (RED) BECAUSE (AT LEAST) 2 OF ITS SUBCOMPONENT (1 and 4) ARE TRUE BY CLICKING ON AN ALARM NAME, A DETAILED VIEW OF THAT ALARM WILL APPEAR Summary of Alarm Condition status

41. TOO HIGH TOO HIGH WARNING HIGH SELECT CHANNELS TO BE DISPLAYED WARNING LOW TOO LOW CLICK HERE TO SEE DETAILS TOO LOW THE UNITS ARE AUTOMATICALLY RESCALED, SO THAT THE TOO_HIGH AND TOO_LOW LINES ARE OK FOR ALL CHANNELS CLICK HERE TO POPUP TREND SELECTION CLICK HERE TO SHOW TREND Summary of Analogue Input Channel status

42. Archive strategy • A new value is archived for an Analogue Input if • The new value differs by more than “delta” from the last archived value (delta = (TOO_HIGH-TOO_LOW)/50). • The new value crosses a threshold (ex. Last archived value was “TOO LOW” and new value is not “TOO LOW”, or viceversa) • If the value needs to be archived, the Control Script writes it into the .Archive.Value datapoint element of the corresponding datapoint. This datapoint element defines the PVSS archive config. • Also the state transitions of Alarms, Actions, Digital and Analogue channels are archived.

43. CURRENT LOCATION THE SHOW BUTTON GIVES ACCESS TO THE LIST OF ITEMS (SENSORS, ALARMS, ACTIONS) ATTACHED TO A LOCATION SUMMARY STATUS SUB-LOCATIONS Synoptic (a first implementation) • The synoptic page displays a summary of the abnormalities associated with the current location and with its children. • A synoptic page is automatically generated for every user-defined geographical location. It displays the “children” (sub-locations) of the current location. • The navigation tree and the “Back” and “Home” buttons can also be used to navigate. • By clicking on a sublocation the user will navigate to the corrispondent page. • From the Front Panel the Operator can initiate the synoptic navigation. Here is what a synoptic page looks like.

44. OPC Optimization Strategy (1/4) • The total amount of “state” information contained in the PLC datablocks (for a fully configured system) is of the order of 100 kbytes. • A permanent OPC monitoring of all this information would create serious delays in the refresh rate of the OPC items that are actually modified. • Therefore, we needed to improve our strategy OPC OPTIMIZATION

45. OPC Optimization Strategy (2/4) • 1) Regroup information which needs constant monitoring • Creation of bit arrays containing, for instance, the status of the alarms and of the actions, the sensors out of range etc. • Creation of an integer array containing the raw values of the analogue sensors. • 2) Regroup information only needed “on demand”, and automatise the activation/deactivation of their monitoring. • OPC items of this category are grouped into different OPC groups, so that each OPC group would roughly cover 1 Kbyte. • OPC groups are activated only when needed (for instance to show the details on an alarm, or of an input channel), and deactivated afterwards. This is done automatically. OPC OPTIMIZATION

46. OPC Optimization Strategy (3/4) • Automatic activation/deactivation of OPC Groups • To each OPC group we associate a “visibility counter” datapoint • The OPC group is activated (by the Control Script) when the counter goes from 0 to positive, and deactivated when the counter goes back to 0 • The counter is incremented every time the Back-end needs information associated with an OPC Item attached to the group • If an Alarm becomes TRUE, we would like to update the detailed information of all the Input Channels used by the Alarm • The same if the details of an Alarm are displayed • The same if an Input Channel is out of range, or if its details are displayed… • The counter is decremented when the information is not needed anymore (ex. when a detail panel is closed) OPC OPTIMIZATION

47. OPC Optimization Strategy (4/4) • Results: • 2176 bytes (10 OPC items) are monitored constantly, with a refresh rate of 500 ms. (Alarm triggers/errors/masked, sensor triggers/errors, action trigger/errors). • 2048 bytes (7 OPC items) are monitored constantly, with a refresh rate of 2 secs. (Level2 triggers/errors, alarm-to-action triggers/errors, digital input raw data). • 2048 bytes, corresponding to the Analogue values, have been divided in 5 OPC items, refreshed every 3 secs. • The items modified are received by the Control Script, that finds which bits were changed and updates the corresponding datapoint elements • Every other OPC item is only monitored while its information need to be presented to the Operator. OPC OPTIMIZATION

48. Tools for the Experts • In addition to the Configuration and Monitoring panels, several facilities have been added, to ease the maintenance of the DSS system in case of problems. • These “Service facilities” enable the Expert to get a more immediate access to the information contained in the PVSS datapoints, in order to reduce the time needed to fix a problem. • In the next slides we will show a few examples

49. Expert Tools : OPC Group Monitoring • Via this panel the Expert can monitor and control the activation state of the different OPC Groups TOOLS FOR THE EXPERTS

50. Expert Tools : Import/Export of datapoint elements • The Expert can easily create text files containing the parameters assigned to one or more DSS objects. • These files can be also read back by the system TOOLS FOR THE EXPERTS