110 likes | 232 Vues
The DØ Online Technical Design Report (TDR) is a detailed document outlining the plans, costs, schedules, and manpower requirements for the online system as part of the DOE Lehman review of the upgrade project. It serves as the foundation for the documentation of the as-built system. The report should be formatted for printing and include essential sections on design, implementation, costs related to hardware, schedules of tasks, and interdependencies among system components. Key contributors are identified for each section, which covers hardware, software utilities, control systems, and data paths.
E N D
DØ OnlineTechnical Design Report • What is it? • It needs to be a fairly comprehensive document detailing the plans, costs, schedules, and resource (manpower) needs for the Online system. It is a component requirement of the DOE Lehman review of the entire upgrade project. • It should also be the basis for our documentation of the as built system. • In what form? • The document presented to the Lehman reviewers needs to be printed - hence it must fit into a serial format • Our working document might be better maintained as a number of (hyperlinked) distinct components • Suggest we produce chapters or sections according to the project components
DØ Online TDR • What should it contain? • Requirements • As much design and implentation detail as… • is known • is possible • is correct but at a maintainable level • Costs • Only needed for the hardware section • Personnel costs not considered • Schedule • Typically only a handful of tasks (aka WBS lines) per section • Only a few milestones per section • Should feed into the (revised) master project schedule • May need to be periodically updated • Be careful to consider interdependencies with other sections!
DØ Online TDR • When is it needed? • Next Lehman review is early January • Need to have: • significant portions of TDR written • schedule for completion of TDR • Important considerations: • Upgrade project is already baselined • Cost and schedule are set • Any modifications to such must go through a change control procedure • Basically, we must try to live up to the cost and schedule that I created years ago… • Final warning: • Can’t overemphasize the need to understand the relationships in design and schedule among various system components!
DØ Online TDR • List each component of the document and note who should write it • Major divisions: • Hardware • Software utilities • Run and configuration control software • Event data path software (including monitoring) • Calibration • Controls path • Accelerator interface
DØ Online TDR • Hardware: • Online system • Stu • Dean • future system manager
DØ Online TDR • Software utilities: • Interprocess Communication • Laura • User interfaces • Nobu • Databases • Stan • Laura
DØ Online TDR • Run and configuration control: • COOR • Scott • Al • Run Control • Scott • (Computing Division)
DØ Online TDR • Event data path sections: • Level 3 Interface • Gordon / Brown • Data Logger • (Computing Division, Gene O.) • Fritz • RIP (logging to FCC) • Stu • (RIP documentation) • DAQ monitoring • (Stu) • Gordon • Event distribution • (Computing Division) • Stan
DØ Online TDR • Event data path sections (cont’d): • Event monitoring / Framework • Silvia • Stan • (Computing Division) • Event monitoring / Detector • Iain • Fritz • Event monitoring / Physics & Expressline • (Stu) • Nobu (for display)
DØ Online TDR • Calibration: • Framework • Iain • Detector components • Iain • ???
DØ Online TDR • Controls path: • to be topic of Monday meeting… • Accelerator interface: • Accelerator console • (Stu) • Information interchange • (Laura)