1. VC Sept 2005Jean-Sébastien Graulich Report on DAQ Workshop Jean-Sebastien Graulich, Univ. Genève o Introduction o Monitoring and Control o Detector DAQ o Conclusions and Afterthoughts MICE DAQ and Controls Workshop

2. VC Sept 2005Jean-Sébastien GraulichSlide 2 Introduction  Took place at Daresbury, Aug 31 – Sept 1  14 people registered  Workshop goals Overview MICE needs and main issues Decide general orientations for Control and Monitoring Detector DAQ

3. VC Sept 2005Jean-Sébastien GraulichSlide 3 On the Agenda  Talks on Control and Monitoring (CM)  Talks on Detector DAQ (DDAQ)  Talks on integration between CM and DDAQ

4. VC Sept 2005Jean-Sébastien GraulichSlide 4 Workshop Goals (A. Bross)  Refine “Physics” parameter List  Further develop an understanding of the D/C/M needs for Beam Line Cooling Channel Detectors  Produce Baseline Proposal for DAQ Online System Controls system Monitoring system  Produce Outline for Comprehensive MICE D/C/M specification document Start from MICE-NOTE-GEN-097 (Draft01/JSG) Goal to have draft (0/1?) ready for collaboration meeting  GIVE SERIOUS CONSIDERATION TO EXISTING SYSTEMS/SOLUTIONS

5. VC Sept 2005Jean-Sébastien GraulichSlide 5 Key issues  For CM Safety Guarantee the stability of Beam line, including target system RF system Absorbers  For DDAQ Guarantee stability of the DDAQ system (no data loss nor data taking time loss Guarantee the data quality (integrity and relevance)

6. VC Sept 2005Jean-Sébastien GraulichSlide 6 About CM  EPICS has been presented (Brian Martlew) Experimental Physics and Industrial Control System Software framework for control monitoring Free, Open Source Based on Channel Access protocol Large user community in physics : Advanced Photon Source (Argonne), PSI, DESY, LBL, LANL, Jefferson Lab, KEK B-Factory Expertise available Daresbury, D0 at FNAL  EPICS was found complying with MICE requirements

7. VC Sept 2005Jean-Sébastien GraulichSlide 7 About DDAQ  Detector data Readout must be performed at the end of the spill Data has to be buffered in the FEE  There is an ADC problem Conversion time for conventional ADC does not allow 600 muons/1ms spill Critical for EmCal  The Particle-trigger scheme is not well defined Particle trigger = Digitisation trigger ≠ Readout trigger Should be flexible (allow calibration, cosmic events, etc…)  Data Volume: 25 kB/μ (2 kB/μ if zero suppression in the tracker) ~10 MB/spill or 25 GB/run ~ 60 TB/year (2500 runs)

8. VC Sept 2005Jean-Sébastien GraulichSlide 8 DAQ Architecture Proposal Trigger distribution Optical link Online Monitoring TrackerEmCalTOF Trigger + Ckovs Ethernet Linux PCs GigaBit Switch Run Control Event Builder Online Storage VME Crates Remote Storage

9. VC Sept 2005Jean-Sébastien GraulichSlide 9 DAQ Software  UNIDAQ has been presented (Makoto) Would require to write an Event Builder  LHC DAQ software have been presented (Emilio) CMS design is not importable DATE from Alice has the following functionalities

10. VC Sept 2005Jean-Sébastien GraulichSlide 10 List of DAQ functions  Run control (state machine) with GUI Configure DAQ topology Select trigger Start/stop (by user or by DCS) Communicate status to DCS  Partitioning. Its importance is never stressed enough.  Minimal set of hardware access libraries (VME, USB, S- LINK), and ready-to-use methods to initialize interfaces.  Data flow Push (or pull …) data from FE to Storage via (one or more) layer of Event-Building  DAQ performance check with GUI  Data quality monitoring (or framework to do it) GUI most likely external  Logging (DAQ-generated messages) with GUI to select/analyze logs

11. VC Sept 2005Jean-Sébastien GraulichSlide 11 Emilio pointed out  Users are not experts: provide them the tools to work and to report problems effectively.  Flexible partitioning.  Event-building with accurate fragment alignment and validity checks, state reporting and reliability.  Redundancy / fault tolerance  A proper run-control with state-machine And simplifying to the users the tasks of Partition, Configure, Trigger selection, Start, Stop  A good monitoring framework, with clear-cut separation between DAQ services and monitoring clients  Extensive and informative logging  GUIs

12. VC Sept 2005Jean-Sébastien GraulichSlide 12 About CM DDAQ  Long discussion Not finalised

13. VC Sept 2005Jean-Sébastien GraulichSlide 13 Monitoring System

14. VC Sept 2005Jean-Sébastien GraulichSlide 14 About CM DDAQ MICE Beam Line MICE Cooling Channel MICE Detectors Detector DAQ Slow Control Data Storage Monitoring Data Log Run Control UI MICE User Interface Environment RF Phase

15. VC Sept 2005Jean-Sébastien GraulichSlide 15 Conclusions  Decisions CM will be based on Epics DAQ will be based on VME bus We’ll PC under Linux Easier if all VME have the same interface  To be done Specifications for DDAQ, including trigger system -> Choose the DAQ software Finalise discussion on DDAQ/CM interconnection Design an Ethernet Network Infrastructure Start Testing