1 / 6

BOE/BME – MDT: DCS

BOE/BME – MDT: DCS. For the 2 BOE , DCS needs to handle 2 x 2 HV (1 ch/multilayer) 2x LV 2x JTAG, associated 2 MDMs/ELMBs Monitoring of T, B and CSM sensors. Standard MDT chamber, at least in pirnciple „straight forward“. For the 2 BME , DCS needs to handle 2 x 2 HV (1 ch/multilayer )

joseph-moran
Télécharger la présentation

BOE/BME – MDT: DCS

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. BOE/BME – MDT: DCS • For the 2 BOE, DCS needs to handle • 2 x 2 HV (1 ch/multilayer) • 2x LV • 2x JTAG, associated 2 MDMs/ELMBs • Monitoring of T, B and CSM sensors Standard MDT chamber, at least in pirnciple „straight forward“ • For the 2 BME, DCS needs to handle • 2 x 2 HV (1 ch/multilayer) • 2 x 2 LV --- each chamber has 2 CSMs due to the large number of tubes • 2 x 2 JTAG, associated 2 x 2 ELMBs • Monitoring of T, B and CSM sensors • Needed additional hardware and connectivity – very preliminary • BOE: LV needs additional board, need to check available slots in crates ,no adding of things without involving us, HV may be ok using spare channels on exisiting boards • BME: LV may be ok using spare channels (BML*13 boards), HV may be ok using spare channels on exisiting boards • MDMs/CanBus: no issue if MDMs are in hand, add to BO_A13-14, BO_C13-14, BM_A13-14, BM_C13-14 chains

  2. BOE/BME – MDT: DCS • Integration into DCS software – Main work • Adding additional devices: HV chans, LV chans, LV/HV boards, MDMs, ... • Adding additional chamber objects • If LV/HV boards are added to the system, probably will need to rebuild the „address space“ for the CAEN communication --- will destroy also all alerts, archiving, etc. settings, to be re-configured – tested during PS DCS project upgrade by Kostas, Nikos etc. • Adding BOE/BME to valid chamber objects --- need to find all such checks in all code • Adding BOE/BME to panels showing a graphical representation of the detector – many different displays which will have to be modified one by one Complication – BME representation in the FSM (and elsewhere) • FSM state logic • conditions stored to COOL (JTAG and LV state) NEW Chamber ChamberA ChamberB BME HV1 HV1 HV1 HV1 HV2 LV (HV2) HV2 LV1 LV LV Effective MDT1 Effective MDT2 LV2 (*) effective MDT (CSM) effective MDT (CSM) effective MDT1 Exisiting ... effective MDT2

  3. BME – „RPC MDT“ (RPC strips readout via a MDT mezz + CSM) • If RPC secondary readout is via MDT mezz and CSM, assume configuration (JTAG init) has to be provided by MDT DCS  • Hard requirements: • If JTAG is part of MDT DCS, also CSM LV must be part of MDT and not RPC(not a problem) • If JTAG is part of MDT DCS, there will be no connection to the JTAG information, commands, state etc. from the RPC DCS projects. --- this is mandated by Local Control Stations layer of MDT DCS projects for stability/performance reasons being isolated • (*) JTAG command access will be provided to the muon shifter via the Muon global UI – but not to RPC experts (consequence of the FSM access control scheme) – is this acceptable ? • If any conditions data on the RPC „MDT“ needs to be stored from DCS to COOL, it will go to the MDT folder and not RPC – is this acceptable ?

  4. BME – „RPC MDT“ -- DCS considerations BA or BC MDT ROD Crate „MDT readout“ MROD MROD MROD BUSY TIM SBC MDT TTC DCS OK RPC CSM Event data: MDT detector ID MDT ROS Init DCS Drop recovery „standalone a la sMDT“ DCS OK MROD TIM SBC ExtraTTC • No dropped chamber recovery • Need to ensure conf DB distinguishes proper MDT MRODs/chambers from RPC RPC CSM ?? Init Standalone partition DCS „new subdet in ATLAS“ MROD BUSY TIM SBC ExtraTTC Event data: New detector ID RPC CSM ExtraTTC DCS: Some issues Init ATLAS partition ??? DCS • ATLAS run can hang/block for something requiring MDT DCS actions (SBC reboot) • No dropped chamber recovery, removal handling ? From RC point big concerns of this scheme

  5. BME – „RPC MDT“ -- DCS considerations „Readout in ATLAS using MDT crate“ RPC TTC MDT TTC MROD MROD MROD BUSY TIM SBC RPC CSM Event data: MDT detector ID MDT ROS Init RPC ROS Event data: RPC or separate detector ID DCS extra ROS Drop recovery, Crate Ctrl. Crate monitoring Very problematic • Very complex interleaved scheme: • JTAG init fails if RPC TTC (clock) not there ... • SBC reboot via Sys Reset is a DCS action --- mixing RPC and MDT on the same device brings down the other partition as well • ...

  6. BME – „RPC MDT“ • A final comment: • Any solution (other than the fully standalone „a la sMDT in 2012“ solution and possibly the solution of treating the RPC CSM as a MDT in the normal MDT data flow) will require committment also of from RPC DAQ for it • Message treatment • Shifter assistant • Stopless removal monitoring, Busy source monitoring • If involving a RPC or extra ROS in the ATLAS partition: on call, follow up, ...

More Related