Experiment Control System Architecture and Tools Clara Gaspar

Experiment Control System Architecture and Tools Clara Gaspar, May 2000

Generic Architecture Commands Control Units T. S. ECS LHC GAS Device Units . . . Det. Dcs 1 Sub. Sys 1 DAQ DCS Det. Dcs. N Sub. Sys 2 Dev 1 Dev 2 Det. Daq 1 . . . Sub. Sys. N Dev 3 Dev N Status & Alarms To Devices (HW or SW) Clara Gaspar, May 2000 2

HW Architecture Clara Gaspar, May 2000 3

The Control Framework z. Will provide guidelines and tools for the implementation of all components in the tree. z. Based on: y. A Commercial Tool - SCADA (tender out next week) y+Additions (home made or commercial) x. Finite State Machine Toolkit x. Specific drivers xetc. Clara Gaspar, May 2000 4

Control Framework Dev y. Tools for Device Unit implementation: x. Device Description x. Several Access Protocols x. Alarm Generation Configuration x. User Interface Editor x. Behaviour Model x. Predefined (Configurable) Device Components, like: • Power supply (CAEN, Lecroy, …) • CC-PC interface • etc. Clara Gaspar, May 2000 5

Device Configuration Clara Gaspar, May 2000 6

Device User Interfaces Clara Gaspar, May 2000 7

Device Behaviour Model y. User tasks: (with the help of tools) x. Define Device States x. Define Actions possible in each state x. Derive State from Device status “bits” x. Implement Action by setting the relevant “bits”. Clara Gaspar, May 2000 8

Predefined Components Clara Gaspar, May 2000 9

Control Framework (cont. ) DCS y. Tools for Developing the Control Units: x. Control Unit Configuration • Which Components: Devices and/or Control Units x. Logic Behaviour Modeling (FSM) • Model the dependencies between components • Automate Operations & Error Recovery x. Alarm Handling • Filtering, Summarising, Displaying, Masking, etc x. Partitioning x. User Interface Generation Clara Gaspar, May 2000 10

Partitioning ECS DCS . . . Det. Dcs 1 Sub. Sys 1 Det. Dcs. N Sub. Sys 2 Dev 1 Dev 2 DAQ Det. Daq 1 . . . Sub. Sys. N Dev 3 Dev N To Devices (HW or SW) Clara Gaspar, May 2000 11

Control Unit Operation Modes z Control Units: y. Publish State and Information y. Can receive commands Normal Operation Partitioned y. Hierarchical control only y. No Hierarchical control y. Control from a “local” U. I. Info Parent State Cmd U. I. Info C. U. Parent State Cmd C. U. Clara Gaspar, May 2000 12

Control Unit tasks y. Each C. U. is “inherently” capable of: x. Publishing information/receiving commands x. Handling Partitioning x. Communicating with its children • Send Commands / Receive states x. Take decisions based on received states (Logic behaviour described using graphic tools) x. Filtering and Summarizing Alarms x. Interfacing to the user (U. I. Automatically generated by the tools) • Generic Control • Alarm Display ( Acknowledgment and Masking of alarms) x. Archiving, Retrieving and Displaying (trending) all data Clara Gaspar, May 2000 13

Modeling Clara Gaspar, May 2000 14

Generated User Interfaces Clara Gaspar, May 2000 15

Alarm Display Clara Gaspar, May 2000 16

Control Framework z. Other Items that will be supported: y. CERN recommended Fieldbuses x. CAN, Profibus, World. Fip y. Ethernet (and Credit Card PC) x. OPC, DIM y. Experiment Infrastructure x. Rack and Crate Control, GAS Systems (GAS WG), Cooling (? ) y. CERN Infrastructure (Data Interchange WG) x. Technical Services, LHC machine, LHCb Magnet(? ) Clara Gaspar, May 2000 17

Conclusions y. The best way to achieve an homogeneous and maintainable control system (and to save manpower) is: x. To do the maximum in common • The Controls Framework is to be developed and used by the 4 LHC experiments • New “Devices” should be developed in a re-usable way and included in the Framework x. To Standardize on HW choices as much as possible • So that common SW can be used y. Please contact us for HW choices (of potentially common items) xlike: power supplies, Temperature Sensors, etc Clara Gaspar, May 2000 18