Transcript quench level - AB-BDI-BL

Operational scenario of the
BLM system
LTC 01/2008
1
Addressed questions
1. Strategy for operation of the BLM system
2. Operation with less than 4000 channels
available?
3. Mobile BLM?
4. Tests with beam?
LTC 01/2008
2
Outlines
Presentation of the system
Initial settings of the thresholds
Changing threshold
Reliability of the system
Tests needed
LTC 01/2008
3
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)
LTC 01/2008
Strategy : BLM for quench prevention
beam 1
beam 2
6 monitors around each quadrupoles (arcs +LSS)
Beam dump threshold set relative to the quench level
(margin to be discussed with the uncertainty on quench level knowledge)
Monitors are maskable for the arc
LTC 01/2008
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
LTC 01/2008
6
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.
LTC 01/2008
7
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 socalled ”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)
LTC 01/2008
8
Implementation
LTC 01/2008
9
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
LTC 01/2008
10
Proposed values for the different tables
Element
Proposed
“Max safe
level”
Safe beam
flag
Master
Table
Applied
table
Maskable/
unmaskab
le
Maskable
Number of
monitors
Max safe
value
Quench
level
LSS quad
Safe beam
flag
Max safe
value
Quench
level
Unmaskable
360
DS quad
Safe beam
flag
Max safe
value
Quench
level
Unmaskable
480
TCP,TCS%,
??
TDI, TCH,
TCLP,TCLI,T
CDQ,…
MQW, MBW Safe beam
flag
Max safe
value
Damage
level
Maskable
~330
Max safe
value
Damage
level
Maskable
60
MSI, MSD
Safe beam
flag
Max safe
value
Damage
level
Unmaskable
24+60
MBR%
Safe beam
flag
Max safe
value
Quench
level
Unmaskable
MQ, MB
LTC 01/2008
2160
11
Element
Damage
level
Master
Table
Applied
table
Maskable/
unmaskab
le
Unmaskable
Number of
monitors
MKD, MKB
Safe beam
flag
Damage
level
Damage
level
MBX
Safe beam
flag
Damage
level
Quench
level
Unmaskable
4
TAN,TAS
?
Damage
level
Damage
level
Maskable
8
XRP
?
Damage
level
Unmaskable
9
BCM
?
Damage
level
Unmaskable
BPMSW
?
Damage
level
Maskable
LTC 01/2008
24
8
12
Pending questions
1. General strategy is to minimize the manipulation of the
MASTER tables: what parameters are critical and should be in
this MASTER?
2. Is the granularity of the predefined families fit the operational
requirement for changing thresholds?
3. If not, is there a splitting of the family which fullfill the
requirement or do we need one scaling factor per monitor?
4. Which value for the “max safe value”?:
•
•
Proposed value :“Safe beam flag” for cold element?
Damage level x margin for warm element?
LTC 01/2008
13
remarks/questions
4. 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?
5. 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?
6. 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?
LTC 01/2008
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
LTC 01/2008
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)
LTC 01/2008
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?
LTC 01/2008
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
LTC 01/2008
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?)
LTC 01/2008
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)
LTC 01/2008
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?
LTC 01/2008
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?
LTC 01/2008
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!
LTC 01/2008
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?
LTC 01/2008
24