Signals between LHC Machine & ALICE

1. Signals between LHC Machine & ALICE David Evans ALICE TB 13th December 2005

2. Three Categories • Data Exchange LHC-Experiment • Machine Beam Synchronous Timing Message (BST) • Beam Interlock System

3. 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

4. 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

5. 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

6. Data from Experiments to Machine

7. Data from Machine to Experiments

8. 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.

9. 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.

10. Portion of BST Message for Experiments

11. 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.

12. 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).

13. 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.

14. Beam Interlocks BIC = Beam Interlock Controller

15. 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.

16. 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.

17. 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.

18. 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-maskableour interlock signals must be operational (and fully reliable) by LHC machine checkout period (few weeks before 1st beam injection).

19. 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 IR2IR8 • Independent injection interlock similar to beam permit. • Technical implementation still not decided.

20. 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.

21. 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!

22. 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.

23. 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.

24. 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.

25. Summary / What Next ALICE needs to be prepared – much work to be done.

26. 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)

27. 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.

28. 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.

29. 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.

30. 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.

31. 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.