The Detector Safety System for LHC Experiments The DSS Team – IT/CO JCOP Review, 11 March 2002

The Detector Safety System

for LHC Experiments

The DSS Team – IT/COJCOP Review, 11 March 2002

11 March 2003The Detector Safety System for LHC Experiments 2/17

Introduction

Experimental Safety LHC Experimental Needs The DSS

Functional Requirements Design and Architecture of the

Prototype Conclusions and Planning


Sensors for• temperature (equipment, ambient air, water),

• humidity,• water-flow,

• sniffers,• watchdog signals of the sub-detectors

monitor the state of the equipment.

There are dedicated sensors for the different safety and control systems.

The LHC experiments and their sites, e.g.• (sub-)detectors,

• gas systems,• magnets,

• power distribution,• racks and crates

will be the equipment to be acted uponby the control and safety systems.

Technical Services provide power, water, gas (general services) and distribute them to the different locations (experiment services).

The DSS complements CSS and DCS:

“The DSS is a system to safeguard the experiment.As such, it acts to prevent damage to the experimental

equipment when a serious fault situation is detected (e.g. temperature too high, water leak, bad detector status…), inside

or outside of the detector…”

The Detector Control System (DCS) is responsible for the overall monitoring and control of the detector.

It might take corrective action to maintain normal operation.All DCS sub-systems are interconnected.

monitor

control

General services: power, water, gas

Experiment services:power, water, gas

Experiment: sub-detectors, racks, crates

In 2001, the experiments have realized, that some safety aspects are

not covered by the CSS and DCS.

The DSS was born.Level 3Level 3 Level 1Level 1Level 2Level 2

Experiment’s DCS

The DSS is embedded in the Experiment’s DCS.Alarm conditions are exchanged with the CSS (hardwired).

Sensors Sensors Sensors

3 Levels of Experiment Safety

DCSsub-system C

DCSsub-system B

DCSsub-system ACSS

CSAM,CSE,etc.DSS

The safety for personnel is ensured by the CERN Safety System (CSS).

It has its own sensors.

Water LeakSmoke,

Gas Leak

Hardware LayerHardware Layer

Supervisory LayerSupervisory Layer

Trip


The DSS functional requirements have been evaluated by the four LHC experiments in a joint WG, and are described in the document CERN-JCOP-2002-012:

http://cern.ch/proj-lhcdss/images/DSSFRD_20020425.pdf

“A Detector Safety System for the LHC Experiments – Functional Requirements Document”

The WG was chaired by Philippe Gavillet.

The DSS Functional Requirements


Scope and Goal:An Optimization Challenge

The DSS should… Protect experimental equipment Improve the experiment’s efficiency by…

preventing situations leading to level-3-alarms(these might lead to 2-3 weeks downtime)

decreasing downtime due to failures Not cost too much

DSS can be considered as an “insurance policy”


Constraints for the DSS

Easy integration… into the controls system of the experiment of sub-detector safety systems of external information (GCS, CSS, …)

Adaptability… since the DSS is a common solution

proposed for all four experiments. to different needs of the four experiments to evolving experimental environments


LHC Experimental Needs

200 to 800 inputs to be monitored

sensors located in several buildings

(caverns & surface) several 100 outputs

Geographicallydistributed system


The DSS must be a standalone system and be…

highly reliable highly available as simple and robust as possible re-configurable by the GLIMOS’s and

experiment experts self-checking for consistency

The DSS Functional Requirements


The Prototyping Phase

A DSS prototype is currently being developed by the DSS Team

(1.5 FTE from IT and 1.0 FTE from EP) to meet the defined requirements

will be a “proof-of-concept”The DSS Advisory Board, consisting of

representatives from all four experiments, site safety experts and the DSS Team is overseeing the prototyping phase.

A review in May 2003 will verify that the design meets the requirements. This will allow for a series production.


After discussions in the DSS Advisory Board, the Front-End will…

be based on PLC technology have its own sensors and actuators check and filter the input sensors be on safe power (CERN safe power plus own

UPS’s) will always react immediately and automatically

on fault conditions indicated by the sensors

DSS Front-End Architecture


The DSS User Interface (Back-End) will… be based on PVSS and the JCOP Framework monitor and configure the Front-End allow a configuration of the relations between

sensor values, fault situations and the actions performed in these cases (the “Alarm/Action Matrix”)

define user access rights through a controlled scheme

provide the user with comprehensible displays log alarm states, warnings, and related information

DSS Back-End Architecture


Redundancy:

• up to the level of I/O interfaces

• backup if failure of a PS, a CPU, a Profibus

• Modules have high MTBF (low failure rates).

• optical link between CPUs

• step-by-step comparison between CPU processes

OPC server:

• gateway to the Back-End

• data distribution via an OPC server

• redundant in the Front-End communication

Front-End (cont’d):

• Siemens S7-300

• capable of handling the number of channels (inputs and outputs) as

required

• located near sensors (<200m)

• I/O interfaces hot-swappable

• inputs and outputs use “positive safety”External crate:

ET 200Mredundant PS

Profibus adapterI/O interfaces

Front-End:

• uses a Siemens S7-400 station

• implementation and processing of the Alarm/Action Matrix

• monitors the DSS system itself

CPU crate:redundant PS

CPU 414-4HEthernet adapter

(CP 443-1)

DSS Architecture

Back End:

• PVSS user interface for displays and logging

• modification of the Alarm/Action MatrixProfibus

DSS COM

OPCServer

Oracle DB & PVSS

CERN LAN


PLC:

Input: Sensors

cycle time

The Alarm/Action Matrix

The PLC loop: PLCs continuously monitor the

sensors e.g. temperatures, water flow,

sub-detector status

Output: Action(e.g. switching off power)

T>TthresT>TthresT>Tthres

Input values are compared to defined thresholds.

Several conditions can be logically combined. Their fulfillment will produce an alarm.

Alarms will trigger defined actions. Actions are on a coarse level (e.g.

cutting power to a complete sub-detector).

ANDAlarm

End-of-Loop


Conclusion

The design of the Detector Safety System, arrived at in consultation with the DSS Advisory Board, will consist of… Front-End:

Siemens S7-400 redundant PLC hardware STEP7 development environment PC based OPC server acting as a gateway

Back-End: A PC based system with a PVSS user interface,

using the JCOP Framework Oracle Database connection for data and configuration

logging


Planning OverviewTask Status Target Date

Front End software Operational June 2003

Back End software In progress June 2003

Installation, commissioning and test of the complete prototype

In progress April 2003

System Review May 2003

Final tests of the revised prototype May/June 2003

*Preliminary version of the DSS

Installation / commissioning for CMS Summer 2003

Operational DSS for CMS* 01/09/2003

Installation / commissioning for LHCb Autumn/Fall 2003

Operational DSS for LHCb* 20/11/2003

Operational DSS for ALICE / ATLAS 2004


Status

Hardware development The PLC hardware has been installed in the lab. The complete system is now being commissioned. Survey of useful temperature sensors (ambient

air & water), humidity sensors, etc. has started.

Software development The DSS database has been defined. A first implementation of the Front-End software

has been done. PVSS Back-End interface implementation is

underway.

A prototype DSS system will be ready forthe review in May 2003.


Where to find more Information?

All documents and DSS presentations can be found on the DSS site

http://cern.ch/proj-lhcdss/

Or visit us in our laboratory: 14/3-030Contact: [email protected] (74841)

Documents

The Detector Safety System for LHC Experiments The DSS Team – IT/CO JCOP Review, 11 March 2002