1 / 4

ALICE DAQ architecture

ALICE DAQ architecture. Main requirements agreed upon and architectural model defined System decomposed into independent components with clear interfaces Components are functional building blocks (hardware or software) No final technology choices done now

marina
Download Presentation

ALICE DAQ architecture

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. ALICE DAQ architecture • Main requirements agreed upon and architectural model defined • System decomposed into independent components with clear interfaces • Components are functional building blocks (hardware or software) • No final technology choices done now • BUT: the architecture cannot be static and cannot be paperware only • Requirements and needs are evolving • More refined ideas on the physics • New detectors added • Technology is evolving even faster • Architecture must be verified very early and refined continuously

  2. ALICE DAQ community • Get the people involved and informed • Critical hardware and software interfaces defined with the detectors groups • Show the progress on paper and by prototyping • Get the feed-back from the collaboration • The collaboration has also important needs today • Interface and test other subsystems (front-end electronics to Trigger or DAQ e.g.) • Test beams or current fixed target experiments • Start the integration as soon as possible

  3. ALICE DAQ prototyping • Components prototypes done or being done of each component • Detector Data Link (DDL) and Readout Receiver Card (RORC) • DATE (Data Acquisition and Test Environment) • Frameworks for DATE readout and monitoring programs • Online monitoring using ROOT • EBDS (Event Building and Distribution System) • Mass storage systems: HPSS, Castor, Eurostore, • Components prototypes and technologies exposed to real applications • DDL and RORC used for TPC test beam • DATE used for most ALICE test beams, NA57 (ALICE ITS), NA58 (Compass) • HPSS used to store the raw data • System prototyped by integration of components prototypes • In the lab and then dedicated simulated runs (ALICE Data Challenges)

  4. Conclusions • Good architecture is essential but it is not enough • Current and future deliverables and milestones are very important as well • Candidate technologies and components must be stress-tested on the field (links, memories, CPUs, OS, switching networks etc.) • Most of the components have a working prototype now • Used for DAQ developments and for detectors groups tests • Feedback from the collaboration • Establish reference points for future comparison • Refine the architecture design and the components implementation by an iterative process

More Related