Barrel RPC Detector Control System

Presentazione sul tema: "Barrel RPC Detector Control System"— Transcript della presentazione:

1 Barrel RPC Detector Control System
Pierluigi Paolucci & Giovanni Polese I.N.F.N. of Naples cms.na.infn.it

2 Main Features and Requirements
The main aims of the RPC DCS are to : Assure the equipment protection for the RPC Muon Barrel System Detect abnormal and potentially harmful situation and minimize the consequent damage to the equipment by taking protective actions Control and monitor all the power supply devices and the enviroments sensors. Provide beetwen an user-friendly GUI an interface to the final users and high-level operations of the experiment. A typical control system for an experiment is organized in two main layers: the front-end layer and the supervision layer. The front-end layer is responsible for giving access to the equipment, whilst the supervision offers an interface to the different human users and high-level operations of the experiment.

3 Architecture Modular and hierarchical Partitionable Scalable
Its structure, developed as a hierarchy, follows the geografical partition of the barrel Each single element of the structure, in the FSM approach, is a different parts of the detectors, structured as logical software units, arranged in a tree-like structure. RPC DCS is developed as a hierarchy where every object is represented as a node of the tree, following the CMS structure. Control Unit performs as logical decision unit, they can take decisions and act on their children, sending comands, based on their states. The logical behavior of a Control Units is expressed in terms of Finite State Machines States transitions can be triggered by: Command reception, either from its parent or from the operator State changes of its child Each single element of the structure, in the FSM approach, is a different parts of the detectors, structured as logical software units, arranged in a tree-like structure. Each logical unit is characterized by a set of well defined states.

4 Final State Machine An FSM may be thought of as a generic, data-driven, mechanism for modelling the functionality of a piece of equipment or a subsystem. The description of the behavior of each node has been defined by state and commands. It can move between these states by making transitions, and transitions are triggered either by commands or state changes of a dependent FSM.

5 FSM Schema TOP DCS States: ON, OFF, STANDBY,ERROR
RPC States: ON, OFF, STANDBY, RUMP1STEP, RAMP2STEP, ERROR STANDBY: HV intermediate voltage, LV OFF; ON: HV nominal voltage, LV ON; RAMP1STEP: from OFF to STANDBY; RAMP2STEP: from STANDBY to ON; Wh Sec Ch La scelta degli stadi nasce da uno studio approfondito del rivelatore e dei suoi componenti HW, delle varie fasi di rpeparazione dei fasci e di presa dati Operazioni piu delicate sono sviluppate su potenza gas cooling, quest’ultimi due devono essere sempre on sia durante la presa dati (data tacking) sia nel caso di preparazione dei fasci (injection,tuning…) An FSM may be thought of as a generic, data-driven, mechanism for modelling the functionality of a piece of equipment or a subsystem. The item to be modelled is thought of as having a set of stable, or quasi-stable, states. It can move between these states by making transitions, and transitions are triggered either by commands or state changes of a dependent FSM. In general, transitions are only possible between one state and a subset of the other states Il funzionamento degli RPC risente delle condizioni di Background; è necessario quindi realizzare degli stadi SAFE durante la fase di fasci instabili e sporchi Le FSM di Ruota, settore e camera hanno una logica comune che ne assicura la compatibilità nella comunicazione (ON,OFF,RAMP1STEP,RAMP2STEP, STANDBY,ERROR) STANDBY RPC sono ad una tensione intermedia (6 kV) (nessuna amplificazione), e i LV sono OFF per non rischiare il danneggiamento dell’elettronica dovuto a bust di particelle prodotto dai fasci sporchi RAMP: stadi transienti che monitorano il comportamento del sistema in evoluzione Logical Description of the channels behavior: (ON,OFF, RAMPING,AND DIFFERENT SEVERITY ERROR CONDITIONS) Hv ON OFF RUP RDW Lv

6 Grafic User Interface RPC Barrel Main Node
It has been implemented the hardware and logical view Initialize and configure the entire system All objects are clickable. The Set/Monitor button provides the possibility to set and control all the wheel channels. Wheel Ramping display (a sort of average status) Majority is not well defined (waiting from JCOP news) The wheel panel contains info about the parent and the children nodes with the relative state condition. Semplifica l’accesso, il controllo e la configurazione da parte dell’operatore umano attraverso un’interfaccia uomo macchina semplice ed intuitiva Facilita la navigazione lungo l’intera struttura grazie ad una combinazione di diagrammi sinottici, testo ed oggetti grafici Consente di visualizzare e settare le principali caratteristiche del sistema attraverso oggetti interattivi ed elementi di interfaccia collegati a variabili di processo Attraverso grafici e diagrammi, consente di monitorare l’evoluzione temporale delle principali variabili sia sui dati online che su quelli immagazzinati all’interno dei database

7 Sector & Chamber Panels
Fully description of a chamber. Main parameters, simple settings and possibility to follow ramping level Simple Info about temperature value and sensor status. VMON/IMON history plots

8 Alerts Handling & Archiving
Different severity levels: Warning, Error and Fatal Acknowledge Summary Alarms Mask/Unmask Infos about element, status and timestamp It’s possible to archive into Configuration Database hardware and logical structure. We are investigating how design Condition Database

9 Conclusions The right working has been tested in Naples using a CAEN mainframe with two EASY module for HV and LV boards It respects all guidelines present into “CMS DCS INTEGRATION GUIDELINES” This system has been showed to Coordinator CMS DCS group and it had been accepted; it will be integrated in the main CMS DCS system in Feb. 06 We are close to be ready for the Cosmic Test but we have to develop: the condition DB (Oracle), test the logfile and the alarm handling and provide a way to retrieve and plot the DB data.