Beam dump XPOC analysis

Beam dump XPOC analysis Brennan Goddard AB/BT • Dump system and its beam instrumentation • Diagnostics – some terminology • External Post Operation Checks (XPOC) requirements & scope • What data • Triggering and acquisition • Interaction with sequencer, SIS, MCS etc. • Archiving and retrieval • Implementation With input from Mike, Julian, Jerome, Verena, Adriaan, Jorg, Etienne, … Draft Specification

LHC beam dump system (LBDS) Dump block Dilution kickers Passive diluter Extraction septum Passive diluter Extraction kicker

Instrumentation (per ring) • BPMs • For circulating beam • Regular “lattice” BPMs at Q4 and Q5 L&R (4); • Additional warm IR6 BPM MSD exit (1); • Dedicated Interlock BPMs at TCDQ and Q4 (4); • For extracted beam • At entrance to TCDS/MSD and exit of MKB (2); • Screens (for extracted beam only) • At entrance of TCDS, exit of MKB and entrance of TDE (3); • BLMs • For circulating beam • At MKD, TCDS, MSD, TCDQ and TCS (56 regular and 2 interlock); • For extracted beam • At MKB, TD vacuum line section changes (18); • For TDE secondary shower profile • Along and behind TDE (8 per beam) • BCTs (for extracted beam only) • At entrance to MKB (2) • Abort gap monitor • Uses signal from IR4 BSRT SR telescope and gated photon counting

Correct LBDS operation • Interlock interrupts BIS 10 MHz and detected by LBDS interface • Beam orbit in tolerance in IR6 • Energy tracking working for kicker charging voltage levels • RF rev. frequency signal correct for abort gap synch • Trigger and Synch unit in LBDS gives power trigger fan-out • All 15 MKD and 10 MKB correctly triggered • All magnetic fields on to correct value at end of abort gap • Kickers MKD MKB, MSD septa and Q4 quadrupoles • Beam extracted and swept onto TDE • No quench in Q4 or other IR6 magnets • low transverse losses (tail scraping) at TCDS, MSD, TD line • Low losses from swept beam in abort gap at TCDQ, Q4

LBDS Diagnostics INTERNAL DIAGNOSTICS • The internal surveillance of the LBDS system monitors the internal status, and when a fault is detected generates either alarms or beam dump actions depending on type of exception. • After each beam dump action the LBDS conducts a series of Internal Post-Operation Checks IPOC, designed to verify that the beam dump hardware operated correctly. Both the internal surveillance and IPOC will be implemented by BT in supervisory systems of the LBDS itself, at PLC level. Act on BIS. No beam needed for these checks. EXTERNAL DIAGNOSTICS • Each dump action must be followed by an External Post-Operation Check XPOC which is launched automatically and is designed to verify that the dump with beam was correctly executed. • For long-term analysis purposes, comprehensive logging must be made of the data associated with the LBDS operation. • The salient transient data associated with each dump action must be recorded by the LHC Post-Mortem system, which will have its own generic retrieval facility for beam fault analysis. • Finally, a number of LBDS systems will generate alarms and warnings which must be incorporated into the CERN alarm system. The LHC control system must provide these external diagnostic systems. Only the XPOC is a ‘non-standard’ requirement, and will be implemented by LSA with BT/OP.

Importance of XPOC for reliability • Critical subsystems (triggering, energy tracking) analysed numerically for reliability (Failure Mode Effect Analysis) • Calculations confirmed that LBDS should reach SIL4 as required • LBDS ‘unsafety’ 4.810-7 per year of operation • Need to maintain redundancy (elements should not fail blind) • Unsafety increases to 2 10-4 per year without POC diagnostics • should ideally return the system to a “good as new” state • play important role in ensuring the safety of beam dump system • LBDS operational state depends on the XPOC result • no high intensity beam operation is allowed unless a TRUE XPOC was obtained for the last dump with pilot/safe beam • XPOC needs to be RELIABLE and AVAILABLE

XPOC functional requirements • Automatically triggered after each dump (server with interface to timing?); • Inhibit beam permit via SW channel to BIS when triggered and while busy; • Acquire LHC configuration data (energy, intensity, mode, fill pattern, etc.); • Acquire equipment data (BTV images, kicker waveforms, BLM signals, etc.); • Acquire reference and tolerance data from MCS databases; • Check consistency of equipment, configuration and reference data; • Build ‘model’ for trajectory and sweep, from configuration/ measured data; • Test measured data against model or (configuration dependant) references; • Give beam permit via BIS if dump was as expected (XPOC TRUE); • Withhold permit to BIS and generate alarm if XPOC returns FALSE; • Display a summary of comparison results and allow diagnostic of problem; • Provide summary data to LHC logging (and Post-Mortem?) systems; • Provide facility to retrieve ‘reference’ and archived dump actions; • Maximum time for acquisition + analysis + reaction is about 10 s

Faults the XPOC must detect

Scope of XPOC comparison checks • Impact position and shape of the swept beam on the BTVDD; • Extracted beam trajectory envelope and sweep form; • Losses in extraction channel; • Synchronization with the particle free gap; • Dumped intensity vs circulating intensity; • All LBDS sub-system summary status; • IPOC correct execution; • Origin of the dump request (BIS or LBDS internal); • Environmental data (vacuum, cooling, TDE temperature & pressure) • Kicker waveform shape (full analysis or summary information); • Long-term drift of kicker waveform key parameters.

Parameters for dump action model • LHC configuration (from LHC machine LSA database) • Beam Energy (450-7000 GeV) • Bunch intensity (0-100% nominal) • Bunch filling pattern (many) • Emittance (1 mm – 15 mm) • IR6 orbit X,X’,Y,Y’ (X,Y: 0-10 mm, X’Y’: 0-100 rad) • Q4 gradient (0-0.03 m-1) • Beta functions at BTVDD (X,Y) (2500 – 7500 m) • Layout data • Element lengths and drift distances • Kicker magnets • MKD energy (x1) (450-7000 GeV) • Active MKD kickers (x15) • MKB energy (x1) (450-7000 GeV) • Active MKB kickers (x10) • Septum magnets • MSD energy (x1) (450-7000 GeV) • Synchronisation and abort gap population

Reference data for comparison from MCS • MKD individual magnet reference functions of energy • Rise time • Current at 3.0 s • Current at overshoot 1 • Current at overshoot 2 • Current at 90 s • MKB individual magnet reference functions of energy • Current at first maximum • Current at first minimum • Time for first zero crossing • Time for second zero crossing • BDI references/tolerances as function of energy • Maximum losses • Tolerance limits on BTVDD derived values • H/V projection width (at half-maximum value) • H/V projection centre • Sweep length • Tolerance limits on BPMD values • H/V projection width (at half-maximum value) • H/V projection centre • Sweep length • Interlock BPM trigger thresholds • Tolerance limits on extracted current

Equipment and beam instrumentation data Beam losses Extraction channel losses during extraction TD line losses during extraction TDE losses during extraction Select LHC ring loss history before/during extraction Direct BLM losses before/during extraction BPMs Machine BPM orbit over ~100 turns Interlock BPM bunch positions over ~100 turns BPMSE bunch positions during extraction BPMD bunch positions during extraction BCT extraction vs circulating intensity measured filling pattern BTV screens BTVDD image & projections BTVD position/status BTVSE position/status Abort Gap Monitor measured gap population MKD/MKB Kickers Kicker waveform summary information Set/read generator charging voltages Set/read generator trigger voltages IPOC results MSD septa MSD measured currents MSD FMCM status Beam Energy Tracking BETS Measured currents from DCCTs BETS Reference energy BETS Reference main voltage for MKB/Ds BETS Reference trigger voltage for MKB/Ds BETS Reference current for MSD/Q4 TCDQ/TCS Jaw up/down set/measured positions Interlock reference function value Cooling status & jaw temperatures TCDS cooling status temperature TDE cooling status, temperature & pressure Vacuum system status & pressures Mains/UPS status Relevant active alarms Issue: what level of redundancy is needed/desired between XPOC and SIS/BIS?? - e.g. do we check if TCDQ function/position/interlock status are all coherent? - if BIS/SIS fully checked and unchanging, should not be needed!

Triggering the XPOC • Conditioning of “request PM” event is needed and depends on whether a beam dump has been requested or not – Julian’s talk • XPOC needed after EVERY beam dump • Needed in cases where there will be NO PM trigger • Inject and dump, intermediate beam during injection sequence, EOF,… • Use (“request dump” OR “request PM”) events to trigger XPOC • XPOC server with HW interface to timing system?

Data acquisition • In the case of a programmed dump…PM is suppressed • Cannot rely on PM data for the programmed dumps • Should use triggered acquisition for equipment data • XPOC subscribes to the equipment concerned • Trigger Data Acquisition using “request XPOC data” event in timing table • In the case of an emergency dump…. • No “request dump” event…! • Two possibilities: • Make dedicated triggered acquisition in all cases….? • PM data for E_dump PLUS triggered acquisition of data for programmed dump…? • Need to set up and maintain 2 data acquisition pathways • More complicated XPOC process (different data structures, response times, …) • Unnnnngggggggggghhhh….. • Propose (after several iterations) NOT to use PM data for XPOC. Use dedicated acquisition triggered for both E_dump and P_dump cases • One data source and pathway with minimum complexity • Overcome issue of diagnostics for badly-executed programmed dump with no PM, by extending scope, e.g. key BLMs (collimators, triplets) and BPMs (see JW) • Might be easier to issue a “request XPOC data” event EVERY time the BIS loop breaks (while still conditioning the “request PM” event on mode etc.)

Archiving and retrieval • Need to archive (& afterwards retrieve) ALL acquired data… a) Immediately write acquired data to SDDS structures before analysis ? • Simplifies retrieval process (same methods for Automatic Analysis and Browse) • Time response issues? b) Separate archiving process in parallel with Analysis Analysis XPOC ? • May improve time response • Two process subscribing to XPOC equipment for relevant data • Need a ‘dump browser’ GUI for manual search for faults • Look up and load data from any archived dump • Regenerate “Model dump” from archived configuration data • Reload references from archived data • Re-run XPOC analysis on old data? • Fiddle with model parameters • Need to archive data, configuration and references for each dump • Issues of archiving structure, persistency, … • Use solutions developed for Post-Mortem?

Interfaces • CMW: XPOC subscribes to equipment device property for XPOC triggered data • LSA LHC machine database: configuration data • Sequencer • LBDS operational state must be changed to “failed” following a FALSE XPOC result – and must ensure that dump is made without beam and then with pilot to re-validate the system. • Must load timing table containing events for dump requests and XPOC data acquisition • Alarms • Generate FALSE result or warning when values close to tolerance limits) • Acquire relevant alarms states (and recent history) • MCS: adjustment of references and tolerances • SIS: check consistency of references in XPOC and MCS • Timing • “request dump” and “request PM” events or (“request XPOC data”) trigger XPOC process and acquisition of relevant data • Logging/SDDS database • need to store all the data associated with each beam dump (SDDS?) • Need to write out the XPOC results and ‘reduced/summary’ data (logging DB?)

Data volumes • Kicker systems • Measured kick waveforms (analysed in FE): ~4 Mb 40 Mb • Summary information from IPOC: ~1 kb • Other data (voltages, status, …): ~1 kb • Other systems • TDE, VAC, FMCM, PCs, TCDQ, TCS, … ~1 kb • Beam instrumentation • BLMs – interested in losses at extraction only ~1 kb • BTVs – 1 screen per beam ~1 Mb • BPMs – acquire ~100 turns, ~10 monitors per beam ~10 kb • BCTs – all bunches, 3-4 monitors per beam ~10 kb • Abort gap monitor, ~100 turns, 100 ns bins ~10 kb • End up with some Mb dominated by kicker waveforms • Kicker waveform analysis may be restricted ONLY to the IPOC in the kicker FEs • Can anyway PM and log kicker waveforms – but would be nice to associate with dump event

Implementation • LSA project framework – Java applications • Shame that cannot directly reuse the LabView PM browsers etc • Should at least learn from the concepts and features developed • Can some of other components be re-used: SDDS convertors, …? • Separation of analysis and dump event browser functionalities • Requirements fairly well defined – some stuff still needed • Details of equipment device properties and data structures • Data reduction algorithms • Comparison tests • Definition of reference and tolerance tables • Impact ‘known’ on sequencer, MCS, logging, triggering, timing,

Priorities & timescales • Needed for beam commissioning • Priorities for 2007 machine startup (Nov) • Minimum XPOC analysis process with main features aimed at 450 GeV • Acquire key equipment and configuration data • Correct interfacing with CMW, sequencer, SIS, timing, MCS, logging • Checks for key parameters • BLMs, BPMD, BTVDD • IPOC results • For 2008 startup (spring) • Ready with full system • All data, references and configuration acquired • Checks for all parameters • Full interfacing with all other systems

Some issues which spring to mind • Performance adequate with subscription to triggered acquisition? • BLM buffers, BPMs for last turns before beam dump • Requirements not too stringent: looking only for one or few turns, limited scope • XPOC process in server with timing system interface? • PM suppression for programmed dump, e.g. open BIC loop triggers RF PM buffer freeze, … • Acquisition architecture and data flow? • equipconvertorSDDSXPOC or equipXPOCconvertorSDDS • Use SDA? • Archiving of the data associated with each dump? • Reuse of PM system components? LabView vs Java issues… • Overlap of functionality with SIS/BIS? • Redundancy can be beneficial, but needs to be selective and well documented • Check acquiring triggered data in midst of PM data “storm”

Fin • XPOC  Post-Mortem • Needed for programmed dumps when PM may be suppressed • Triggered on “request dump” OR “request PM” event • Defined and limited functionality: validate operation of dump with beam • Seems preferable to have data flow for XPOC based on triggered acquisition of all necessary data, separate to PM • Anyway needed for programmed dumps • Would otherwise have two sources of data depending on dump type • Avoids duplication and extra complexity • Should be in a position to finish prototype application and check out the issues in the course of this year • Specifications drafted (iteration needed once concept finalised)

Beam dump XPOC analysis