DAQ Consortium Strategy - January 2018 Dave Newbold, Georgia Karagiorgi, 23rd January 2018 DRAFT 1 Consortium Scope The consortium scope has been clarified in discussions over the last few months, and documented via a series of draft system requirements and in- terface agreements. • On the detector side, DAQ responsibility begins with the optical fibres emerging from the detectors. DAQ is not responsible for any on-cryostat components. Note that, since some components of the signal processing chain for the SP TPC will be housed within the CUC, those components fall within DAQ scope. • DAQ is responsible for all hardware operating at SURF, up to the WAN link to FNAL. Operation of the WAN link and all elements thereafter are the responsibility of the offline computing group. Elements of offline soft- ware running on the DAQ system are the responsibility of the computing group. • Interfaces to other subsystems of DUNE FD exist (e.g. slow controls and calibrations) where DAQ will provide network and computing services, as well as synchronisation and databases as needed. 2 Consortium Status Several key technical and architectural decisions have been made in the last months, that will form an agreed basis for future discussions on design and implementation. • The DAQ will operate as a single system for all detectors , allowing use of common components, full synchronisation of front-end electronics, and triggering based on information from all DUNE FD elements. • The DAQ will operate as a deadtimeless system, capable of storing continu- ous sequences of data for periods of up to tens of seconds, or of independent overlapping samples from multiple space/time regions of the detectors. 1
• The DAQ will be capable of storing the full information from the detectors (i.e. without any form of lossy data manipulation), for short periods of time. This however may not always be the mode of operation all the time. • The DAQ will consist of a set of front-end buffers and a processing pipeline for each sub-detector, an event builder system for each subdetector, a single WAN transfer buffer, and a data selection system. The data selection sys- tem will comprise components that are specific to individual sub-detectors, and central components (spanning all sub-detectors). • The DAQ will provide human interfaces for operation (configuration, run control, data taking), monitoring, data quality management, and data book-keeping. • The DAQ architecture and implementation will be designed with the fol- lowing characteristics, in priority order: robustness, scalability, ease of deployment and commissioning, ease of design and construc- tion, cost-effectiveness, and running costs and space and power requirements. • The DAQ will be sized to allow for significant conservatism in the operation of data selection for the first sub-detector(s), i.e. able to operate with a far greater data rate than would be expected, than asymptotically when the detector performance is fully understood. This implies sizing key elements of infrastructure for four detectors, from the start. • The final DAQ design will be demonstrated in a series of pre-production and integration tests of increasing scale, including tests with detector pro- totypes, before a decision to proceed with construction is made. The consortium has agreed on a draft schedule and WBS, and is defining a list of areas of institutional interest. At the time of writing, there are few firm institutional commitments, or firm sources of funding. Based on the scope defined above, it will be necessary to increase both the person power and financial resources available to the consortium, on a time scale allowing a full resourced plan to be presented in the TDR. 2
3 Time line and decision-making process 3.1 Milestones The DAQ has defined a set of internal milestones, spanning the time between late 2017 and the TDR delivery in July 2019. • M1 (Dec 2017) Interface documents complete (DONE) • M2 (Jan 2018) Functional specifications complete • M3 (Mar 2018) Cost and infrastructure requirements complete • M4 (Apr 2018) Technical Proposal • M5 (Aug 2018) Internal (preliminary) review of baseline TDR design • M6 (Dec 2018) First prototype components available • M7 (Dec 2018) TDR structure and institute responsibilities defined • M8 (Mar 2019) Slice test with CE completed • M9 (Mar 2019) Review of baseline TDR design • M10 (Jul 2019) Technical Design Report At the time of this writing, the DAQ design is not yet finalised, with several key technical decisions yet to be made, and demonstration of the feasibility of the chosen solutions is yet to be achieved. It is understood that the reviews (M5 and M8) will also consider alternatives to the baseline design as outlined in the TP. More specifically, the consortium will continue to explore and allow the baseline design to evolve, as the DAQ design evolves and new findings are available through R&D. 3.2 Technical Proposal (M4) The Technical Proposal will present: • A well-motivated set of design parameters for the DAQ, based on physics requirements, and anticipated detector performance • A design philosophy for the DAQ, encompassing the agreed points specified above 3
• An overall architectural view of the DAQ for the first two detectors • A baseline design consisting of a technically-plausible and conservative solution for each DAQ component, based on protoDUNE experience wher- ever possible • A documented set of alternative solutions for components, where appli- cable, along with a statement of the R&D strategy, and the criteria for deciding between solutions • An outline cost and schedule for the baseline solution. 3.3 Pre-TDR Review (M9) At a formal external review in March 2019, we will receive: • An iteration on the system requirements in light of further physics and data selection studies • Concrete costed proposals for implementation of each system component • Concrete expressions of interest from groups of institutes capable of deliv- ering the proposed solutions This strategy allows for up to a year after the TP for groups of institutes to carry out necessary R&D into particular solutions; to demonstrate those solutions based on practical tests or simulation; and to seek support from funding agencies in the implementation of components. It will also permit time for institutes from whom expressions of interest are just now being received to join the consortium and make a substantive contribution before decisions are made for the TDR. The review will result in a set of decisions for component implementations, to form the basis of the TDR design. In some cases, it may be optimal to let multiple solutions continue to a post-TDR phase of R&D; however, this should only be the case where emerging technologies are of interest, rather than a means of postponing decisions. Decisions will be made by an appointed review panel, that will comprise consortium and experiment leadership, experts from within the consortium, collaboration members with applicable expertise, and invited external review- ers. The criteria for decision making will be: the maturity and demonstrated effectiveness of the proposals; the matching to the criteria for the overall DAQ design expressed above; and the presence of a team able to implement the concept on the required time scale. 4
3.4 Technical Design Report (M10) For the Technical Design Report, we will present: • A final set of design parameters for the DAQ, along with a statement of their uncertainties and the margins allowed • A proposed detailed design for the DAQ for the first two detectors • A resourced work plan for delivery of the DAQ by the required data (cur- rently understood to be around 2023), and including prototyping, con- struction, installation and commissioning phases • A full budget and risk mitigation strategy 4 Key decision points For the currently envisioned baseline design, although several components of the DAQ are well-established, and in some cases are being demonstrated in the ProtoDUNEs, in other areas there are multiple options for components implementation. There are also remaining uncertainties on the requirements from physics in some areas. Listed below are key areas where binary decisions must eventually be made, or where there is significant interaction with sys- tems outside the DAQ and where time-critical information is needed. This is in contrast to ‘tactical’ and potentially reversible decisions (e.g. data selec- tion strategy, decisions on component implementation) which can be made over a more extended time scale, and in a more discursive way. 4.1 Noise assumptions for SP TPC The complexity of data processing of SP TPC data, and hence the scale and cost of the DAQ system, depend strongly on the level and nature of noise in the SP TPC. Until firm results are obtained from tests of the final electronics in a realistic environment, it will be necessary to make an agreed- upon assumption here, including a worst-case livable scenario. The DAQ should be capable of scaling, at additional cost, to a worst-case scenario for noise. Time scale: we require an initial agreed assumption for the TP, which will be reviewed before the TDR. 5
Recommend
More recommend
