1. 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
17 Jan 2007

2. LHC beam dump system (LBDS)
Dump block
Dilution kickers
Passive diluter
Extraction septum
Passive diluter
Extraction kicker
17 Jan 2007

3. 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
At MKD, TCDS, MSD, TCDQ and TCS (56 regular and 2 interlock);
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
17 Jan 2007

4. 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
17 Jan 2007

5. LBDS Diagnostics INTERNAL DIAGNOSTICS EXTERNAL 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.
17 Jan 2007

6. 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
17 Jan 2007

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

8. Faults the XPOC must detect
LBDS BI
Other diagnostic
Asynchronous dump
BLM,BPM
IPOC
MKD pre-trigger
Missing MKD
BPM,BTV
MKD energy tracking error
BPM,BLM,BTV
MKB energy tracking error
Missing MKB (dilution failures)
Missing MKD redundant branch
MKD re-triggering not working correctly
MSD energy tracking error
Beam emittance too large
BLM
Orbit in IR6 out of tolerance
BIS (ITLK BPM)
Direct BLM triggered
IR6 access loop broken
MSD power convertor trip
BIS (FMCM)
Over-populated abort gap
AGM,BLM
TDE over-temperature
TDE monitoring
TDE over/under pressure
TCDQ-beam position out of tolerance
SIS (Feedback)
Abnormal vacuum pressure in MKD/MSD/TD lines
VAC monitoring
TCDQ/TCS out of position
BIS (TCDQ posn)
MKB/D internal diagnostics not working
Beam instrumentation not working correctly
Alarm?
BETS not working correctly
BLM, BPM
17 Jan 2007

9. 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.
17 Jan 2007

10. Parameters for dump action model
LHC configuration (from LHC machine LSA database)
Beam Energy ( 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’: rad)
Q4 gradient ( m-1)
Beta functions at BTVDD (X,Y) (2500 – 7500 m)
Layout data
Element lengths and drift distances
Kicker magnets
MKD energy (x1) ( GeV)
Active MKD kickers (x15)
MKB energy (x1) ( GeV)
Active MKB kickers (x10)
Septum magnets
MSD energy (x1) ( GeV)
Synchronisation and abort gap population
17 Jan 2007

11. 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
Interlock BPM trigger thresholds
Tolerance limits on extracted current
17 Jan 2007

12. Equipment and beam instrumentation data
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
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
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!
17 Jan 2007

13. 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?
17 Jan 2007

14. 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.)
17 Jan 2007

15. 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?
17 Jan 2007

16. 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?)
17 Jan 2007

17. Data volumes Kicker systems Other systems Beam instrumentation
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
17 Jan 2007

18. 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,
17 Jan 2007

19. 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
17 Jan 2007

20. 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”
17 Jan 2007

21. 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)
17 Jan 2007