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) BME HV1 HV2 LV effective MDT (CSM) ChamberA HV1 LV ChamberB HV1 LV effective MDT (CSM) HV1 HV2 LV1 LV2 (*) effective MDT1 effective MDT2 Chamber (HV2) NEW Exisiting... FSM state logic conditions stored to COOL (JTAG and LV state) Effective MDT1 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 RPC CSM MRODMROD BA or BC MDT ROD Crate MRODMROD MRODMROD MDT TTC MDT ROS Event data: MDT detector ID RPC CSM MRODMROD TIMTIM SBCSBC Extra TTC ?? BUSYBUSY TIMTIM SBCSBC DCS OK DCS OK No dropped chamber recovery Need to ensure conf DB distinguishes proper MDT MRODs/chambers from RPC DCS Init Drop recovery Init Standalone partition DCS RPC CSM MRODMROD TIMTIM SBCSBC Extra TTC Init DCS Extra TTC Event data: New detector ID ATLAS partition BUSYBUSY ??? DCS: Some issues 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 „MDT readout“ „standalone a la sMDT“ „new subdet in ATLAS“

5. BME – „RPC MDT“ -- DCS considerations RPC CSM MRODMROD MRODMROD MRODMROD MDT TTC MDT ROS BUSYBUSY TIMTIM SBCSBC DCS Drop recovery, Crate Ctrl. Crate monitoring Init RPC TTC Event data: MDT detector ID Event data: RPC or separate detector ID Very proble matic 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... extra ROS RPC ROS „Readout in ATLAS using MDT crate“

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,...