From lankford@lankford.ps.uci.edu Thu Dec 14 13:19 PST 1995 Date: Thu, 14 Dec 95 12:57:19 -0800 From: lankford@lankford.ps.uci.edu (Andrew J. Lankford) To: babar_elex_lead@lankford.ps.uci.edu, babar_elex_colead@lankford.ps.uci.edu, babar_elex_engr@lankford.ps.uci.edu, babar_elex_coengr@lankford.ps.uci.edu Subject: Materials for BaBar Elex Reviews Cc: LUTH@slac.stanford.edu Content-Type: text Content-Length: 8657 14 December 1995 (Near-final draft) REVIEW MATERIALS Required for BABAR Electronics PDRR+CDR and PDR Reviews This note lists and briefly explains the materials which are required for Preliminary Design Requirements and Conceptual Design Reviews (PDRR+CDR) and Preliminary Design Reviews (PDR) of BABAR electronics subsystems. List of materials for PDRR+CDR: ------------------------------- Requirements Document Block Diagrams System Description Preliminary Interface Specifications Document Preliminary Grounding and Shielding Plan Deliverables List also: Cost Estimate Schedule List of materials for PDR: -------------------------- Block Diagrams System Description Interface Specifications Document Grounding and Shielding Plan Deliverables List Preliminary Test Plan also: Requirements Document Cost Estimate Schedule SHORT DESCRIPTION OF MATERIALS FOR PDRR+CDR: -------------------------------------------- REQUIREMENTS DOCUMENT: The Requirements Document is a text document which clearly states the requirements of the subsystem. The list of requirements should include requirements which derive from BABAR physics and from the performance requirements of detector systems, including requirements for calibration, monitoring, high voltage or bias voltage, power dissipation, and mechanical constraints. The list of requirements should also include interface requirements with detector systems and other electronics subsystems. It may also include functional requirements upon the system which have been adopted in order to facilitate subsystem design or definition. Requirements should guarantee physics goals but should not be so stringent as to demand undue cost, schedule, or technical risk. Each requirement listed should be supported by (1) a brief justification and (2) a statement of status, which explains the stability or flexibility allowed for the requirement. A brief explanation of the requirement should be provided where needed for clarity. The list of requirements should be complete. Where a requirement is not yet fully defined, the requirement should still be included in the document and its status should be noted as requiring further definition. Following successful completion of the PDRR, changes to the Requirements Document will be controlled. BLOCK DIAGRAMS (for CDR): For the CDR, a hierarchal set of block diagrams is required. This set should start with a system overview, including interfaces to detector systems and to other electronics subsystems. The hierarchy should descend to the level of principal components (at the level of boards and ASICs). Where appropriate, for instance for ASICs and critical boards, the hierarchy should descend one more level to the principal blocks of each critical component. The hierarchy should not descend to a more detailed level, and schematics should not be included. The set of block diagrams should be self-consistent. Signals and interfaces between blocks should be identified. Following successful completion of the CDR, changes to block diagrams included in this set will be controlled. SYSTEM DESCRIPTION: For the CDR, a written System Description is highly desirable. At minimum, a system description in the form of an explanation of each block diagram is required. A description at least at the level of the 1995 BABAR TDR is suggested. PRELIMINARY INTERFACE SPECIFICATIONS DOCUMENT: For the CDR, a Preliminary Interface Specifications Document is highly desirable. At minimum, the set of block diagrams should provide a complete list of the interfaces with detector systems, with other electronics systems, and between components. A separate document which will be the basis of the Interface Specifications Document required for the PDR is strongly suggested. Definition of signal levels, impedances, etc. are not required for the CDR. PRELIMINARY GROUNDING AND SHIELDING PLAN: For the CDR, a presentation of a Preliminary Grounding and Shielding Plan is required. The grounding plan should be documented by a block diagram. The Preliminary Grounding and Shielding Plan can be covered by the Preliminary Interface Specifications Document and/or the System Description or in a separate document. DELIVERABLES LIST: A Deliverables List should define the complete set of deliverable components, including the number required of each (including spares). The System Description and Block Diagrams provides a description of the deliverables. COST ESTIMATE: The Cost Estimate will normally be the standard BABAR WBS; however, if changes are required to the WBS then these should be documented. SCHEDULE: The Schedule will normally be the standard BABAR PMCS schedule; however, if changes are required then these should be documented. SHORT DESCRIPTION OF MATERIALS FOR PDR: --------------------------------------- BLOCK DIAGRAMS: For the PDR, the hierarchy of Block Diagrams provided for the CDR should be continued to the level of schematics. The set of block diagrams should be complete and self-consistent. Following successful completion of the PDR, changes to Block Diagrams will be controlled. SYSTEM DESCRIPTION: For the PDR, a written System Description in required. This description should be adequate to provide an understanding of the system at the most detailed block diagram level. Following successful completion of the PDR, changes to the System Description will be controlled. INTERFACE SPECIFICATIONS DOCUMENT: For the PDR, an Interface Specifications Document (or a complete set of component specifications documents) specifying the interfaces to detector systems, to other electronics subsystems, and between components is required. The Interface Specifications Document should fully specify all interfaces. Following successful completion of the PDR, changes to the Interface Specifications Document will be controlled. GROUNDING AND SHIELDING PLAN: For the PDR, the Grounding and Shielding Plan is required. The grounding plan should be documented by a block diagram. The Grounding and Shielding Plan may be covered by the Interface Specifications Document and/or the System Description or in a separate document. DELIVERABLE LIST: For the PDR, a Deliverables List which defines the complete set of deliverable components, including the number required of each (including spares), is required. The System Description and Block Diagrams provides a description of the deliverables. PRELIMINARY TEST PLAN: A description of the test procedures to be used to evaluate performance of prototype and preproduction models of components and of the subsystem is required. The defined procedures should be adequate to assure subsystem performance which meets the defined subsystem requirements. REQUIREMENTS DOCUMENT COST ESTIMATE SCHEDULE These items are the same as for the PDRR+CDR; however, changes required since the PDRR+CDR should be documented. Notes on Change Control: ------------------------ Change control procedures are intended to allow changes to designs to be made in a coherent and successful manner. It is not their purpose to eliminate design changes. The basic principle of change control is that changes to documents and designs which are controlled must be agreed to (i.e. approved) by the parties affected, and coordinated (i.e. approved) by the responsible leader. For instance, changes to the interface between two major components of an electronics subsystem must be approved by the designers of both components and by the subsystem leader and system engineer. Changes to the system block diagram must be approved by the affected designers, by the subsystem leader and system engineer, and by the System Manager and Chief Electronics Engineer. Changes to overall scope of a major subsystem must be approved by the subsystem leader and system engineer, by the System Manager and Chief Electronics Engineer, and by the Technical Coordinator. Changes to the subsystem requirements must be approved by the affected detector system System Manager in addition to the people as above. BABAR change control procedures also apply in certain cases, mostly cases involving changes to cost or to schedule.