Transcript LHCC

Beam Monitoring in CMS
Application of the BLM System to CMS
Alick Macpherson
On behalf of the
CMS Beam Conditions and Radiation Monitoring Group
Institutes Involved:
Auckland, Canterbury, CERN, DESY, Karlsruhe, Princeton, Rutgers, Tennessee, UCLA
CMS BRM: Beam Conditions + Radiation Monitoring
Group Remit
Provide monitoring of the beam-induced radiation field within the UXC55
cavern and the adjacent straight sections.
Provide real-time fast diagnosis of beam conditions and initiate protection
procedures in the advent of dangerous conditions for the CMS detector

System features must include:
 Active whenever there is beam in LHC
 Ability to initiate beam aborts
 Provision of warning & abort signals to CMS subdetectors
 Postmortem reporting
 Provision of online and offline beam diagnostic information to CMS
and LHC
 Bench-marking of integrated dose and activation level calculations
 Integration of all online beam diagnostic information (including
subdetectors).

Updating at ≥1 Hz
2

RADMON
PHASE 1: Installed for Startup


BCM2: Diamond leakage current monitor at rear of HF




No FE electronics

Commissioned in conjunction with BCM2.Output to CCC and CMSCR
Input into beam abort after commissioning (against BCM2)
BSC: Beam Scintillator Counters




Readout as extension of the LHC Beam Loss Monitor (BLM) system

Commissioned against BLM monitors in Long Straight Section

Output to CCC and CMSCR
Input into beam abort (after commissioning against LHC BLM)
BCM1L: Diamond leakage current monitor in tracker vol. (close to beampipe)


Extension of LHC wide radiation monitoring system. 18 monitors in CMS
Large area scintillator tiles on the front of HF
Output to CMSCR
Initially only a monitoring system
BPTX
PHASE 2
Output to CMSCR. Initially only for monitoring

PHASE 3

Upgrade systems under consideration for 2008/9

Upgraded BSC (position, robustness, technical trigger)

PLT: Pixel Luminosity Telescope (not yet endorsed).
BCM1F: Diamond + fast amplifier for bunch by bunch monitoring




Installed prior to First physics run (or earlier)
Output to CMSCR
Initially only a monitoring system
Would also be a beam diagnostic device
CCC=CERN Central Control RM
CMSCR=CMS Control Rm
Increased complexity/deviation from standard LHC interfaces
BRM Subsystems: The Prioritized List
3
Subsystem
Location
Sampling
time
Function
Readout +
Interface
Passives
In CMS and
UXC
Long term
Monitoring
---
RADMON
Around
CMS
1s
Monitoring
CMS +
Standard LHC
BCM2
At rear of
HF
40 us
Protection
CMS +
Standard LHC
BCM1L
Pixel
Volume
Sub orbit
~ 8us
Protection
CMS +
almost std LHC
BSC
Front of HF
Bunch by
bunch
Monitoring
CMS
Standalone
BCM1F
Pixel
volume
Bunch by
bunch
Monitoring +
protection
CMS
Standalone
Increased time resolution
BRM Subsystem Summary
All online systems read on when machine operational and possibility of beam in LHC
Systems are independent of CMS DAQ
4
BCM: Beam Conditions Monitors
CMS BCM Units
1
BCM1L: Leakage current monitor
Location: z=±1.9m, r=4.5cm
4 stations in 
Sensor: 1cm2 PCVD Diamond
Readout: 100kHz
No front end electronics
2
BCM1F: Fast BCM unit
3
Location: z=±1.9m, r=4.3cm
4 stations in 
Sensor: Single Crystal Diamond
Electronics: Analog+ optical
Readout: bunch by bunch (Asynch)
2
2 Sensor Locations, 3 Monitoring
3 BCM2: Leakage current monitor
Location: z=± 14.4m, r=29cm, 5cm
8 stations in 
Sensor: 1cm2 PCVD Diamond
1
Readout: ~20kHz
Sensors shielded from IP
Timescales Off detectors electronics
5
Full BCM Readout Chains

Baseline systems on track
 BCM2 readout chain
 Full chain validated [sensor to backend readout]: Karlsruhe Aug 06
 BCM1L readout chain
 Custom Mezzanine card tested: Based on Tevatron design
 Prototype of chain from sensor to VME backplane expected January 07

Interface:
 Interface teststand (Bat 376-R-009) with interface to CCC: operational by 1/12/06

Implication: Will complete full slice test by February 07
=> BCM1, BCM2 readout chain + interface to CMSCR and CCC
Front end
VME Crates
Interface
Network and
hardwired
connection to
CMS and CCC
6
Example: CMS BCM Sensors in CDF- Online Monitoring Plots
Polycrystalline diamond
At diff radii (3, 10.7cm)
to control room
Poly vs single
ECDF, ESCMS: same location
CMS BCM Sensors in CDF:
- Sensors + electronics in
realistic hadron collider environ
- Cross calibrate with existing
CDF beam monitoring (BLM
and diamond based)
- Uses 20us Sampling
7
CMS
BRM Interface: Schematic view
BSC
Info logging from BRM
- 1s sum
- capture
- post mortem on abort
CCC - DB
Radmon
BRM - PC
BCM
Radmon
DCS
DB
PowerPC
x1/x2
PowerPC
PowerPC
VME
?
BCM1/BCM2
Display
Conditions
DB
or
LHC
BIC
LHC-expt data exchange
(defined by LEADE)
DIP
8
BCM in detail: What’s envisaged

Three locations


BCM1: Inside the CMS detector, z=1.8m from the IP, r=4.8cm
BCM2: Outside the central detector ( z= 14.365 m)


Outside CMS: Place diamond sensor next to a BLM unit in LSS



monitor diamond leakage current synthetic polycrystalline diamond sensor

Warning/alarm abort thresholds to be CMS configurable
Readout:

BCM2 + outside CMS:



Standard BLM readout ( Tunnel card to DAB board to data base)
Exactly the same readout and reporting structure
BCM1:





Calibration cross check
Readout as per tunnel card and full BLM system
All locations:


Two locations
 Shielded from IP (r= 29cm)
 As close as possible to Beampipe (r=5cm)
BLM readout from DAB card onwards.
Sub orbit monitoring (~10us) synchronized to orbit Clock
No tunnel card
Custom mezzanine card on DAB board. Uses BLM interface and reporting structure
Post-mortem and monitoring data


Reporting mechanism unchanged from BLM system ie CMW/FESA
Data stored in BLM database (just like other BLM data)
9
Components: What’s needed
Baseline
System
Spares
Total
Test setup
ASAP
Ordered/
Delivered
Crates (BI-B inc. Fan tray and PSU)
2
0
2
2
Ordered
Spare PSU and fan tray
1
0
1
0
Ordered
Power PC, Lynx OS (BI - BLM Standard)
2
1
3
2
Request
BOBR TTC Timing Cards
2
1
3
1
Request
CTRV card for GMT info
2
1
3
1
Request
BLM-COM Cards (BLM Combiner cards for input to BIC)
1
1
2
0
Request
DAB64 Cards (DAI #2223379)
4
6
10
1
Ordered
BCM1 CMS BCM Mezzanine Card
8
8
16
1
Prototype
DAB64 Cards (DAI #2223379)
4
6
10
1
Ordered
BLM Mezzanine Cards
4
4
8
1
Request
Optical Patch Connectors (MU to E2000APC)
4
4
8
1
Request
BLM CFC Tunnel Cards
4
4
8
1
Request
3U Tunnel Crates (BLM Std - incl backplane, modified PSUs)
2
2
4
1
Request
CRATES, etc
BCM1
BCM2
CMS_BCM Interface Lab (Bat 376-R-009 ):
BCM1 Programme (Princeton):
BCM2 test programme (Karlsruhe):
Teststand for Interface to CMSCR/CCC
Development site for BCM1
Based on BLM_USB prototype
10
Timing Cards: What’s needed – part II

Modules needed for complete BCM1L and BCM2 system:



2 CTRV
2 BOBR
Gives BCM crates full functionality and compatibility of the BLM system.

CTRV modules were not foreseen for CMS. This is a new purchase request.
 Cards to be located in existing BCM1L and BCM2 crates
 Exactly the same configuration as for the BLM system.
 No new software is foreseen for these timing modules,
 will be used in exactly the same way as for the BLM system.

Signals into CTRV cards


Should come directly from machine racks in CMS
 GMT comes into S1E08 of the CMS USC
Optical signals into BOBR: Ideally should come directly in from machine.


=> split off from main input into CMS.
Question over routing: Need to ensure this main input into CMS is on “safe power”
 Needs some discussions within CMS.
11
Maintenance + Software: What makes sense

All hardware/software taken from machine group


Any additional hardware that is added by the BRM group



Ideally, treated as any other BLM system as regards maintenance and upgrades
MUST be fully compatible with the BLM system
Maintenance is the responsibility of CMS_BCM group.
Timing signals

responsibility of machine group up to the unit in the crate


Software/Firmware: Where possible use BLM system without changes



Changes only when absolutely necessary.
All software which has been changed becomes responsibility of CMS_BCM.
Wherever changes are needed, they will be implemented by the BRM group


ie CTRV and BOBR modules.
However would appreciate consultation with the expertise in BLM/BI/CO groups
It is not foreseen to request any special software from the BLM/Controls groups
12
Modifications/Additions: What we would like

Tunnel Card Low Voltage power supplies.


HV supplies


Requesting that “capture data” functionality be available in baseline firmware.
 Capture data = diagnostic postmortem data without triggering beam abort
 Purpose: Full diagnostics calibration and commissioning
BCM2


Presently investigating options: Integrate supplies with our CAEN controller
General Firmware


Will not use power supplies due transformers in to fringe field of CMS magnet
=> supply low voltage directly to tunnel card regulators via long cable
 Tested tunnel card and regulators to 3 kGauss
No modifications or additions requested
BCM1

CMS Custom mezzanine card that mounts onto DAB. CMS responsibility.
 No optical link => No tunnel card
 Firmware
 Custom mezzanine card firmware being developed. CMS responsibility.
 Where possible/feasible, use standard BLM firmware for DAB and interface to CCC
 At this stage no requests for modification foreseen
13
ABORT signal: What we foresee
CMS_BRM is responsible for CMS detector input to the BIC

This means that we generate the input to CMS detector CIBU

We need to confirm the CIBU interface with AB_CO.
Location of patch panel for CIBU interface
 USC55; area S1. Rack S1E08. By design, BCM2 rack is S1F08

Observations: Both racks on generator + UPS power
=> "safe" operation guaranteed in event of power cut to CMS services/cavern.
Operations and the ABORT signal

CMS-Detector input is an integral part of the detector safety system
=> Must be active whenever there is a possibility of beam in the machine
 Operation on Day 1:

input into BIC (via CIBU) to be via BLM COM card in BCM2 crate
Exactly the same ABORT functionality as for the BLM system.
 => BCM2 is baseline for initial system
 Commissioning is in line with BLM commissioning
Operation ASAP after Day 1 (Once initial running conditions assessed)
 Add CMS specific combiner card.
 Combines BCM2 and BCM1 signals, issue ABORTs
 This CMS combiner is in addition to the BLM combiner
 CMS_BCM is responsible for design, commissioning, maintenance of this card
 The CMS combiner initially runs in parallel.
 output monitored =>performance and reliability cross checked.


14
Summary: What we are asking for

Endorse proposal of CMS_BCM to use BLM system within CMS


CMS_BCM to be considered as an extension of BLM system into Pt 5
CMS BCM system is to be based on BLM hardware and firmware
 CMS BCM data reporting and storage to be done in the same way as
BLM data.
 Ensures BLM-consistent reporting and tracking of CMS beam
conditions to CCC

Recognize that:






the BCM2 is fully based on the BLM system
the BCM1 system, while based on the BLM, requires a custom
mezzanine card.
The CMS_BCM inputs into the CMS experiment input of the Pt5 BIC
The warning/alarm/abort thresholds are to be CMS configurable.
Modifications/additions to the BLM framework to limited to a minimum
Allow CMS_BCM to purchase the necessary BLM hardware


Equipment list discussed to be approved by Bernd Dehning
Where possible we would hope to purchase through standard AB_BI
channels
15
Summary: What we are asking for – part II

Endorse request for timing cards

Request is made so that CMS_BCM can:
 maintain full BLM functionality
 Provide a full set of diagnostic tools to CMS
=> comprehensive reporting of Pt 5 beam and bkgd conditions as function of
machine operation.

Endorse proposal for cross calibration sensor outside CMS

Permit continued discussion and development between BLM and CMS_BCM



Development and testing of hardware and firmware
Operations and data logging
Take note: a clear monitoring program is being put in place for CMS



This program is focused on the commissioning and early running
Will rely on open feedback and discussion between CMS and the LHC
Will benefit from close working relations and consultation with BLM, AB_BI, AB_CO, and
LHC_OP
 In all aspects the CMS_BCM is flexible wrt BLM/BI constraints, as we very much
want to integrate and take full advantage of the BLM system.
16
Spare stuff
17
CMS_BCM Specific Combiner Cards
18
BCM: Monitoring Timescales
BCM2: monitors leakage current on half-orbit scale
 LHC-standard readout hardware from LHC Beam Loss Monitor (BLM) group
 Replaced ionization chamber with polycrystalline diamond (10x10x0.4mm)

Sampling time: 40 us
 Monitoring time scales: 12 staggered buffers to cover 40us to 100s history
BCM1L: monitors leakage current on sub-orbit scale

Synchronizes with orbit marker
 User configurable sub-orbit sampling scheme: (4us minimum)
 Statistical measurement of conditions at user specified positions in orbit
 Sub-orbit monitoring averaged and passed to std BCM2 staggered buffer readout
 Dedicated sampling of beam abort gap
BCM1L
Sampling
Scheme
19
BCM1 Unit
Modular design
Sensors hermetically sealed
•
Accommodates gross misalignment of beampipe (2mm)
Rad hard of TiW metallisation
validated at PSI and Karlsruhe







BCM1_ L
Leakage current measurement
Sensor: polycrystalline diamond
 Fine for leakage current
 10x10x0.4mm
 7000e-/MIP
In : 4 BCM units
No front end electronics
Bias voltage: 400V (nominal)
Sensor orientation set by need for ExB
 avoid anomalous leakage currents
No direct cooling allowed/needed







BCM1_ F
Bunch by bunch measurement
Sensor: Single crystal diamond
 Needed for single MIP detection
 5x5x0.4mm
 18000e-/MIP
In : 4 BCM units
Dedicated front end electronics
 rad hard amplifier -> optohybrid
Bias voltage: ~100V (nominal)
Limited space for front end electronics
No direct cooling allowed/needed
20
21
RADMON
Locations
18 Monitors deployed
around CMS
(UXC +USC)
22
BSC: Beam Scintillator Counters
Functionality
 Provide an independent bunch occupation monitor.
 Abort gap monitoring
 Provide a technical trigger source


CMS: display similar
to ZEUS example
independently supply “better than zero-bias” trigger
Halo muon trigger for Tracker alignment
Readout:

Mounted on front of HF, readout over long cables to USC.
 Simple standalone system: No front end electronics
 ADC & discriminator + TDC readout (t1,t2,Dt). Common stop
 Same back end as BCM1F
 Output to CMS: statistical measurements
 Rate monitoring on sub orbit scales
 Relative time measurements: incoming bkgd to
outgoing collision products + bkgd
Cross-sectional Areas
HF = 5.6m2
BSC paddles =0.6m2
TK = 3.8m2
BSC =1.1m2
Ratios
BSC_Paddles/TK =17%; BSC/HF =20%
BSC Paddles
BSC Disks
23