1 / 24

Operational scenario of the BLM system

Operational scenario of the BLM system. Addressed questions. Strategy for operation of the BLM system Operation with less than 4000 channels available? Mobile BLM? Tests with beam?. Outlines. Presentation of the system Initial settings of the thresholds Changing threshold

hblack
Download Presentation

Operational scenario of the BLM system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Operational scenario of the BLM system

  2. Addressed questions • Strategy for operation of the BLM system • Operation with less than 4000 channels available? • Mobile BLM? • Tests with beam?

  3. Outlines Presentation of the system Initial settings of the thresholds Changing threshold Reliability of the system Tests needed

  4. 1. Strategy for BLMS operation • BLMs are part of the machine protection system: • to protect LHC from losses, the only one for fast losses between 0.4 and 10 ms. • The system should prevent quenches and limit the number of false dump : operational efficiency • Therefore, based on HERA experience, all BLMs are interlocked and only one giving an interlock is enough to trigger a beam dump • There are 2 groups of monitors : • For cold elements ( thresholds related to quench level) • For warm elements (thresholds related to the element damage level)

  5. 6 monitors around each quadrupoles (arcs +LSS) Beam dump threshold set relative to the quench level (marginto be discussed with the uncertainty on quench level knowledge) Monitors are maskable for the arc Strategy : BLM for quench prevention beam 1 beam 2

  6. Strategy: BLM for warm elements beam 2 top view collimator TDI beam 1 BLM in LSS : at collimators, warm magnets, MSI, MSD, MKD,MKB, all the masks… Beam dump threshold set to the same beam flags (need equipments experts to set the correct values), dependan with beam energy and intergration time Non-maskable channels

  7. Strategy: BLM families • For settings generation, BLM are grouped in families: a family is a set monitors which see the same level of signal for the same level of energy deposited in the coil • A family is defined by the type of element to which the monitor is attached (MQ, MQM, MSD,TCTH…) and the position on this element (entrance, middle, exit, beam 1/2, outside/inside…) • We came up with up to some 250 different families. • BLMs in the arcs (~ 2200 IC) are only 6 families • the rest (~1500 IC + 300 SEM) is for the quad in the DS, LSS and warm elements • One thresholds table is generated by family from 2 curves: damage level dependence with beam energy and with integration time (32*12 values for cold elements) • The 32*12 values of this table are assigned as properties of a family in the operational (LSA?) database.

  8. Summary of the implementation Via an expert application, a thresholds table is generated by family and stored in ORACLE database (family_info table). This table and the monitor_info table are used to fill the MASTER table, within the Database (SQL request) The MASTER tables (25, one per crate) are protected and set to a so-called ”max safe value” of the different equipment (energy and integration dependant ). Inside the database, an APLLIED table is derived from the same family_info and monitor_info tables AND multiplying by a factor F, 0<F≤1. Internal check within ORACLE: APPLIED table ≤ MASTER table APPLIED table is sent to front-end and read back for comparing with the one in the database on a regular basis (once per day and after every change) Important to note that this change can only be done without beam (action remove the Beam_Permit)

  9. Implementation

  10. 1. Safety critical components • Comparison between the APPLIED table in the front end and the MASTER table in the DB • Comparison between the APPLIED table in the front end and the APPLIED table in the DB • History of the changes on the MASTER tables : max thresholds, maskable status, connected/not connected • What about the electronics? Families? • Responsalibity for follow-up? proposal :BLM team

  11. Proposed values for the different tables

  12. Pending questions • General strategy is to minimize the manipulation of the MASTER tables: what parameters are critical and should be in this MASTER? • Is the granularity of the predefined families fit the operational requirement for changing thresholds? • If not, is there a splitting of the family which fullfill the requirement or do we need one scaling factor per monitor? • Which value for the “max safe value”?: • Proposed value :“Safe beam flag” for cold element? • Damage level x margin for warm element?

  13. remarks/questions • With this strategy, MASTER table is below the damage level for cold elements (factor 320 to 1000 between damage level and quench level according to the beam energy, but the same constant is used) • too much conservative? • Do we want to fit better the damage level? • Is the comparison between the APPLIED table loaded in the front-end and the one in the database enough if ORACLE guarantee that an internal check of APLLIED < MASTER is done every time you generate a new APPLIED? OR do we also want an external APPLIED in front-end < MASTER in database? • The masking is done at the CIBU level: you mask all the channels connected to the maskable CIBU at the same time! (i.e one per sector) • Is it acceptable from machine protection point of view?

  14. Status of the software • Expert application for thresholds generation exists (ROOT scripts) and is used to fill the DB. (expert to LSA?) • Database : Work in progress, structure defined, prototype exists with some 10 families, still some discussions about history of changes • TRIM for operation : to be done • External tables comparison: to be done, but no major problem

  15. BLM system : signals available • 12 running sums (40 μs to 84 s) to cover the loss duration and 32 energy levels used for filling different buffers: • logging: at 1 Hz, max loss rate in each running sums over the last second + corresponding quench levels + error and status from tests • Post-Mortem : the last 1.7 s with a 40 μs sample rate (43690 values) + the last 2 min of the logging data + thresholds and masking tables + system status info • XPOC : possible to get up to 32000 values per channel for the chosen running sum (need to be specified by LBDS) • Collimation: on request, 32 consecutive sums of 2,54 ms • Study Data: can be triggered by a timing event (to de detailed)

  16. 2. Operation with < 4000 channels? (1/2) • Reliability of the BLM system: • G. Guaglio Ph-D thesis • Designed to be SIL 3 level : redundancy when necessary, experience with the SPS… • acquire statistic with the existing system on SPS and LHC one as soon as available (150 days of running for the moment) • the new software part need to be included in this study?

  17. 2. Operation with < 4000 channels? (2/2) • staged approach: • how much protection is needed or how much can we relax on it during commissioning with hope to gain operational efficiency? • The system need to be fully operational for phase A.5 • Minimum system for each phase can/should be defined (MPSCWG) • Possibility to change status of channel via the same soft as for the Thresholds • masking helps for wrong evaluation of the threshold • possibility to change at the BLM level the maskable/unmaskable status

  18. How many channels we can lose? • The loss can be seen by another monitor but need to change the threshold to keep the protection? • Do we have to go through the different loss patterns? (accidental case?)

  19. Simulation : typical result Maximum of the shower ~ 1m after impacting point in material increase of the signal in magnet free locations Amplitude/length of the pressure bump? z (cm)

  20. Mobile BLMs? • Mobile BLM • Same Ionisation Chambers • use the spare channels per card : 2 in the arcs at each quad, a bit more complicated in the LSS because of more elements. • electronics is commissioned as for connected channel • All the free channels/cards… will be predifined to allow their display without touching the threshold tables • Need access to connect the extra chambers • Can cover a half-cell every 3-m if 2 chambers per channel • No dump thresholds • For which use: • He leak detection: is it enough? Need some evaluation of the expected pressure dump to evaluate the signal • In the LSS?

  21. 4. BLM tests • Functional test of full acquisition chain with Radioactive Source • The procedure for this test will be described in a dedicated document made in collaboration with TIS. The purpose is to create a signal on the chamber with the RA source and check its presence in the corresponding DAB card channels. • Time estimation : 0.5 to 1 hour per front-end station (8 BLMs) • Provoked magnet quench • possibility to check steady state losses quench limit with circulating beam (part of the MPS commissioning) • possibility to check fast losses quench behavior if sector test • What do we lose if we cannot do the tests?

  22. Restricted tests? • Testing only a given set of BLMs with the radioactive source? • Motivation of the quench test: • Verification of the correlation between energy deposition in the coil (= quench level) and BLM signal (= thresholds) • Verify or establish „real-life“ quench levels • Verify simulated BLM signal and loss patterns • => Accurately known quench levels will increase operational efficiency!

  23. Conclusion • GO for implementation? • Acquire statistics on the reliability of the connections and the applications during the coming dry runs • Evaluate the safety of the solution in March and if not satisfactory, close the HW switch! • Strategy to run with non-working channels? Action for the MPWG?

More Related