310 likes | 314 Views
This document discusses the data exchange mechanisms between the LHC machine and the ALICE experiment, including the use of the Beam Synchronous Timing Message (BST) and the Beam Interlock System. It also covers the responsibilities of the AB department and the experiments in maintaining the infrastructure for data transport.
E N D
Signals between LHC Machine & ALICE David Evans ALICE TB 13th December 2005
Three Categories • Data Exchange LHC-Experiment • Machine Beam Synchronous Timing Message (BST) • Beam Interlock System
Data Exchange • LDIWG defined single data exchange mechanism between all systems involved in LHC data operations • Requires DIP databus supporting: • Publish/subscribe data exchange • 250 kBytes & 100 messages/s • Dominated by LHC Cryo Machine bandwidth • Latency about 1 s
Data Exchange – DIP • DIP is a simple and robust publish/subscribe system which supports an on-change data exchange • DIP API provided for C++/Java and Windows/Linux • The DIP data format includes a timestamp and quality flag • There is a negotiated contract between the consumer and the provider. Hence, the consumer is expected to know the name of the data item, its meaning and its data type • There can only be one publisher per item • The DIP product DIM was selected
LHC Logging System • Data logging facility for LHC Controls System (Timber) • Input/Output Interface • Web-deployed GUI • Output • Graphical visualisation • File output NB: Offline only
Beam Synchronous Timing Message (BST) • BST is separate from TTC system which supplies the LHC clock. • BST uses the TTC technology, however, to send messages over channel B of TTC. • Machine supplies optical cable but NOT interface.
Purpose of BST system • BST developed to provide LHC beam instrumentation with 40MHz bunch synchronous triggers and 11kHz LHC revolution frequency. • Can also send encoded message which can be updated every LHC turn (orbit). • Message mainly used by LHC instrumentation etc. • Some messages of interest to experiments.
BST – AB Responsibilities • AB department – installing, testing and maintaining BST Master crate. • BST message and clock NOT guaranteed during machine access or shutdown. • AB will ensure BST fibres are patched through to central fibre hub in the Central Control Centre (CCC). • Actually, they should deliver optical cable to ALICE pit.
BST Experiments’ Responsibilities • Organising and maintaining the infrastructure required to transport the BST message from the CCC to required destination. • Includes fibres, splitters and experiment specific receiver modules. • Note, currently nothing in place or planned for ALICE. (See later for possibilities).
Beam Interlocks • Beam Interlock System (BIS) is to protect the LHC machine (& experiments) against damage due to failures. • As well as interlock signals under the machine control, experiments must provide both hardware and software interlock signals.
Beam Interlocks BIC = Beam Interlock Controller
LHC Machine Modes • Injection • Filling • Ramp • Adjust • Stable Beams • Unstable Beams • Beam Dump • Recover Mode info available to experiments thro’ software (DIP data exchange protocol) and hardware link (via Safe LHC Parameter (SLP) System). Note: Names still under discussion so may change but functionality will not.
Mode Transitions • Adjust Mode – (after Ramp or Stable Beams modes) – when entered from Stable Beams experiments will be warned (voice or automated signal). • Unstable Beams – (from Stable Beams) – can be entered without pre-warning. ALICE may need to power-down, ZDC moved away from beam etc.
Beam Dumps • Can happen without warning • Time-scale of minutes (beam degrades slowly) – Experiments will be warned and mode will only change when all experiments ready. • Time-scale of seconds – mode may be set to Unstable Beams without warning. ALICE will need to power down etc.
Hardware Interlocks for Experiments • Three Categories • Injection inhibits • Beam dump requests • Position interlocks (ZDC) • ALICE may provide up to 3 user inputs (1 for each) to one of the LHC BICs installed in our IR. • Hardware Interlocks must be non-maskableour interlock signals must be operational (and fully reliable) by LHC machine checkout period (few weeks before 1st beam injection).
Injection Inhibit • ALICE must have the possibility to provide a signal over a hardware link in order to inhibit injection without dumping beam. • Two options • One individual optical link IR2IR8 • Independent injection interlock similar to beam permit. • Technical implementation still not decided.
Beam Dump Request • As mentioned, ALICE may provide 1hardware user input for dump requests. • Should only be used if background levels likely to damage detectors. • Beam dump request will initiate a “post-mortem” procedure – we must provide system to monitor and record our radiation detectors.
Beam Dump Request • Output of monitors used to create beam dump signal need to be continuously provided to the CCC on a normalised scale (e.g. 1 is “safe” and 5 is “abort”). • These include monitor level & gradient. Dump thresholds must also be provided. • NB we are only provided with a BST user interface (CIBU). (2U 19 rack mounted board) • ALICE is responsible for the hardware, software and monitoring of this radiation detector. • For ALICE, this doesn’t exit yet!
Position Interlocks • ZDC will have its own interlock. • E.g. should be in its OUT position during Beam Injection Phase. • ALICE has asked machine to be responsible for and control the ZDC position – this is still not agreed. • ALICE Magnets – the solenoid and dipole magnet interlocks will be under the control of the PH/DT1 group.
Software Interlocks • Available to further define control of operating conditions. • S/W interlocks will NOT be used to dump the beams – used to permit/inhibit actions instead. • Most useful S/W interlock maybe injection VETO. • S/W interlocks will use DIP data exchange.
Special S/W Interlocks • Ready for Adjust Procedure • ALICE will provide a READY_FOR_ADJUST signal (acknowledgement for ADJUST_REQUESTsignal from machine) • Ready for Beam Dump • ALICE will provide a READY_FOR_BEAM_DUMP signal(acknowledgement for IMMINENT_BEAM_DUMP signal from machine) • These interlocks are not a substitute for voice communication but a safety backup.
Summary / What Next ALICE needs to be prepared – much work to be done.
Data Exchange Data Exchange – DIP/DIM • Software needs to be written to display and store data. (ECS group) • Data from ALICE needs to be sent through the Data Exchange. (ECS + DCS groups ?) • Would be useful to have summary of data on end-of-run record. (DAQ Group) • Graphical interface also useful (ECS group)
BST Messages • Useful but not essential • No system in place to record data. • Possible hardware: • TTCit board being developed by Kosice to monitor trigger system. • Machine BST interface board (BOBR) – already developed by machine. • Both 6U VME boards with TTCrx chips.
BST Messages • Currently (even with hardware) there’s no system in place to record these data. • Impossible to send data via CTP without major upgrade to CTP and new firmware for FE electronics (may be possible in future upgrade). • Possible to send data to DAQ to be appended to events. Not ideal and could involve a lot of work to implement.
Beam Interlocks – H/W • Only Interlock Interface supplied • No ALICE radiation detectors exist. • Use CMS (or ATLAS) design • Need to organise this now (if not already started) – Marc Tavlet ? • No ALICE INJECTION INHIBIT in place (no tech specs from machine yet). • Need someone (hardware person) assigned to this.
Beam Interlocks – S/W • Need software to read and send data (over DIP/DIM). • Display machine data • Send ALICE data • Automatic detector response (power down etc) • Assume DCS (and ECS) will take care of this.
Summary • A lot of S/W and H/W signals need to be exchanged between LHC machine and ALICE. • A lot of work needs to be done by ALICE before June 2007. • It may be a good idea to set-up an ALICE working party involving DCS, ECS, DAQ, Trigger, and Safety.