SuperCMDS at SNOLAB

1. SuperCMDS at SNOLAB Ge Towers System Requirements Eduardo do Couto e Silva eduardo@slac.stanford.edu June 17, 2010 Project Management Kick-off Meeting

2. SuperCDMS Plans Project Execution Plan (PEP) SuperCDMS Safety Plan Project Management Plan (PMP) Performance and Safety Assurance Plan (PSAP) Project Control Plan (PCP) System Engin Mng Plan (SEMP) Value Mng Plan (CMP) Management Plans System Safety Program Plan (SSPP) Quality Assurance Plan (QA Plan) ES&H Assurance Plan Configuration Mng Plan (CMP) Risk Mng Plan (RMP) Preliminary Hazard Analysis (PHA) Integration and Test Plan (I&T Plan) Institutional Safety Implementation Plans Institutional Quality Assurance Plans Final Hazard Analysis (FHA) Performance Verification Plan (PVP) Can we actually have all that for CD1? Do we really need it? Hazard List Environmental Test Plan (CCP) Implementation Plans Hazard Reports Contamination Control Plan (CCP) Safety Assessment Document (SAD) Grounding and Shielding Plan (CCP) Operations and Support Hazard Analysis (O&SHA) Software Development Plan Design Review Plan

3. Requirements Management • Why do want/need to do it? • Validation of science requirements • Basis for hardware specifications and mechanism to tune design • Provide elements to manage interfaces • Build and test what you need, no less, no more and if need funding is required there is a clear justification. (manage scope) • What do we need to do (we do not have time to cover it all today)? • Requirements Identification • Analysis • Traceability • Documentation and Management • Requirements Verification • Interface management • Challenges for SuperCDMS at SNOLAB • Cater to the needs of small experiment, remember we are small! (20-30M) • Resistance to change from physicists within the collaboration • Yes, I have been there, done that, and resisted a lot before I realized the real value behind! • This is not paperwork only!

4. It is not only paperwork, it is an art! • Requirements must be clear • Specify the minimum acceptable functionality and performance • Specify what is expected performance. • This is not to satisfy reviews only is to HELP us develop a better instrument with a well defined scope • Science Requirements • It seems easy to do from the physics point of view, but making it meaningful and flowing it down to hardware specifications is an art • Make sure a requirement is testable • Do we need testable requirements at every level ? • Success will be measured by validating requirements • Requirements must be traceable to clearly stated science objectives • Again, be careful here, we are a 30 M level experiment

5. Drivers of System Requirements • Each of the systems below will be driven by Science and SuperCDMS level requirements • Ge Modules • Cryostat and shielding • Trigger and DAQ • SNOLAB Facilities • System Integration • Background Controls • Software/Computing • Science and superCDMS level requirements • It is time to start writing them • Who will shepherd this effort? • Where do we store them?

6. A WBS proposal: 7 systems and Project Management SNOLAB Facilities Project Management Cryostat & Veto/Shield Ge Towers Systems Integration Trigger & DAQ Background Controls Software/Computing • Software and Computing includes • Offline software framework • Reconstruction Software • Data processing • Databases • Background Controls includes • Material Radiopurity specifications • Screening of Materials (a,b,g, chemical) • Simulations (electromagnetic, hadronic)

7. WBS Proposal: Ge Tower Subsystems

8. SuperCDMS Requirements Requirements, Verification and Integration Flow SuperCDMS Integration and Test SuperCDMS Verification Plan system Ge Towers Requirements Ge Towers Integration and Test Ge Towers Verification Plan subsystem Ge Modules Requirements Ge Modules Integration and Test Ge Modules Verification Plan component Ge Crystals Requirements Ge Crystals Integration and Test Ge crystals Verification Plan Ge Crystal Development Do not promise to write documentation that you will not have resources to maintain

9. Ge Towers - System Requirements • Ge Towers Requirements Document • Defines functionality of the towers, but not the implementation • Provides detailed physics/science requirements • Defines the functions a tower must perform to support the superCDMS experiment • Basis for engineering design • Required for the CD1 Review • Ge Towers Systems Engineering will derive the Ge Tower Specification • Levies derived requirements • Levies requirements from plans • contamination, grounding and shielding are examples • Defines the functionality we will see and test when Ge Towers are integrated into the cryostat • Provides a home for special subsystems, such as thermal, that only exist when the Ge Towers are fully integrated • Required for the CD1 Review • Subsystem Specification (Ge Module, Cold Electronics, Tower Mechanical Structures & Cabling) • Will contain requirements directly flowed down from the Ge Towers Specification • Will contain derived requirements, some by the Ge Tower Systems Engineering team and some by the subsystems team • Will define the functionality seen when the subsystem is integrated and tested • Subsystem specification does not flow requirements, and should contain sufficient details that the document could be used by an outside firm to design, build and test the component

10. 7 months later than Dan’s proposal 3 months later than Dan’s proposal 6 months later than Dan’s proposal 3 months later than Dan’s proposal Same CD4 dates as Dan’s proposal

11. What did I leave out? • There is a lot more to talk about, but we have no more time today • Next time we should go over at least the following • External interfaces • Interface Control Documents • Risk Management • Requirements Tree • List of requirements for CD1 review • Where to store documents • We are testing Sharepoint to provide inputs to the process • https://slacspace.slac.stanford.edu/sites/cdms/Pages/Default.aspx • Acknowledgments • I “stole” material produced by Pat Hascall and Martin Nordby from LSST which were kindly provided to me by Nadine Kurita.