1. The Software for the CERN Detector Safety System G. Morpurgo, R. B. Flockhart and S. Lüders, CERN IT/CO

2. Contents The Detector Safety System (DSS) Two main components: the Front-End and the Back-End The data-driven DSS software The Front-End Alarm-Action Matrix processing software Front-End   Back-End communication The Back-End software  Operator Display  Configuration Tool Conclusions

3. The Detector Safety System in a nutshell DSS “Detector” Alarm-Action Matrix DSS Sensor DSS Actuator (typically a power switch) Read the Sensors Evaluate the Alarm Conditions Set the Actuators ~1 Hz

4. Two questions Who configures the Alarm Action Matrix (Sensors, Alarm Conditions, Actuators) ? How to know what the DSS is doing ?

5. The Back-End and the Front-End Detector Evaluate the Alarm Conditions Read the Sensors Set the Actuators Configure Monitor OPC Operator Display Configuration Interface The Back-End runs on a PC and is based on the PVSS SCADA system The Front-End is based on a redundant Siemens PLC The Back-End deals with User Interaction The Front-End deals with Safety

6. Some requirements  At least 4 similar systems have to be built, modified and maintained over twenty years.  Sensors, Actuators or Alarm Conditions can be added or re- parameterized at any time by the User, without stopping the system. How does the “data-driven” approach work  The details of the Sensors, Alarms and Actuators will not be “hardcoded” in the software.  These details, which describe the peculiarities of each system protected by the DSS, will instead be confined into “data structures”.  The DSS software will interpret the data contained in the above mentioned structures. Benefits  The software will then be identical for every DSS. This reduces the overall development effort, and allows more exhaustive testing, hence more reliability.  This approach automatically eliminates the risk of introducing software bugs when the User adds new items. Software: the data-driven approach

7. The F-E Alarm-Action Matrix processing software(1) PLC software structured as a sequence of simple steps (like “read a sensor’s value”, or “set a status bit if a sensor’s value is higher than its threshold”). Every step processes the items contained into a PLC “memory datablock”. A datablock contains parameters and status for all items of a specific type.  These types are: the digital and analogue Sensors, the Alarm Conditions and sub-conditions, the links between Alarms and Actions, and the Actions (i.e. the Actuators) themselves. This sequence of steps is cyclically repeated by the PLC.

8. The F-E Alarm-Action Matrix processing software(2) A few additional remarks: Each datablock has space for a predefined number of entries (typically one or two thousands). Each entry (Sensor, Alarm, Actuator, etc.) occupies a well defined position in its datablock. Each entry can be addressed by the different processing steps via its Unique Channel Identifier (UCI), a number in the [1,32767] range. In fact, every processing step uses as input results produced by the previous steps.

9. Example: the data structure for an Alarm Condition UCI 12291 … UCI 12289 UCI 12290 “Compare” blocks UCI 14339 … UCI 14337 UCI 14338 Sub-conditions If “A”=TRUE or “B”=TRUE or “C”=TOO_HIGH or “D”=TOO_LOW then ALARM “E” UCI 3 … UCI 1 UCI 2 Digital sensors A = true B = true… … UCI 8193 UCI 8194 Analogue sensors UCI 10247 UCI 10248 C = high D = high C = low D = low delay = 2 … UCI 16421 UCI 24577 Alarm-Action links … UCI 24579 … UCI 24577 UCI 24578 Actuators (i.e. Actions) If ALARM “E” then ACTION “F” (after 2 secs.) UCI = 1 UCI = 3 UCI = 8193 UCI = 10248 UCI = 0 (empty) N = 1 (OR) … Alarm “E” value UCI = 0 (empty) Alarm conditions UCI 16421UCI 16421 … Step 1: read digital sensors Step 2: read analogue sensors and compare with thresholds Step 5: evaluate Alarm Conditions Step 6: look at Alarm-Action links Step 7: set Actuator values (execute Actions)

10. Communication between Front-End and Back-End memory datablocks PVSS “database” datapoint elements datapoint elements … Back-End Front-End OPC Parameters are mirrored from B-E to F-E Status are mirrored from F-E to B-E A datapoint element can have an “OPC address” pointing to a location in the Front-End memory datablocks

11. OPC and optimization Once configured, OPC makes the transmission of data changes transparent to the programmer. If a parameter changes on the B-E, it will be mirrored into a F-E datablock, and used next time the F-E software reads the datablock. If a status changes on the F-E, it will be mirrored into a B-E datapoint element. A PVSS script can be programmed to react to such a change. Optimization is needed: The amount of PLC datablock memory over which data to be monitored are spread has to be minimized. Try to put all the critical status information in contiguous memory.

12. PVSS DATABASE (DATAPOINTS) The Back-end Software Event driven “managers” GUI panels DSS EVENTS MANAGER ARCHIVE MANAGER EMAIL MANAGER LOG MANAGERS ORACLE DATABASE SMS/EMAIL PVSS ARCHIVE PLC DATABLOCKS Front-End PLC MIRRORING OPC User Interaction part MONITOR PANELS CONFIGURE PANELS Parameter changes (from User)Status changes (Front-End “events”)

15. Many consistency checks are needed when defining an Alarm Condition Check that, depending on the sensor values, the condition can actually be TRUE or FALSE ex. (A too_high and A too_low) is bad ex. (B true or B false) is bad Check against the same sensors being reused in a redundant way ex. (B true or B true) : maybe the User has made a mistake DSS Configuration panels: an example

16. Conclusions(1) Five DSS systems, each running the same identical software, have been delivered to the Users and commissioned. A tight schedule was matched by the very small DSS development team (2 persons). Many other features were implemented in the software  ORACLE logging of all events and configuration modifications  Monitoring the status of the PLC system itself  Preventing configuration modifications if OPC is not working  … and many more Sophisticated PVSS-based User Interface

17. Conclusions(2) The data-driven approach has led to  Simplicity and stability in the Safety-Critical part (F-E)  Very well established interface between F-E and B-E (PLC memory datablocks   PVSS datapoint elements) …but, even more important…  Reduced software development and maintenance time (write it once, use it everywhere).  Independence from the data details. There is nothing “CERN- specific” in the DSS. The system can be effortlessly reused “as it is” in other environments, including in industry.