semp
Post on 27-Apr-2015
33 Views
Preview:
TRANSCRIPT
Document # Date Effective
LAT-MD-00066-01 3nd Draft 1/23/01 Prepared by(s) Supersedes
Tim Thurston None Warren Davis
Subsystem/Office GLAST LAT PROJECT MANAGEMENT PLAN Systems Engineering
Document Title
LAT Systems Engineering Management Plan
Gamma-ray Large Area Space Telescope
(GLAST)
Large Area Telescope (LAT)
Systems Engineering Management Plan
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 2 of 29
CHANGE HISTORY LOG Revision Effective Date Description of Changes DCN #
1 Initial Release LAT-CN-000xx
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 3 of 29
CONTENTS
1 Purpose and Scope ..........................................................................................................5
2 Acronyms ........................................................................................................................5
3 Applicable Documents ....................................................................................................6
4 Systems Engineering Process..........................................................................................7
4.1 Organizational Responsibilities and Relationships.................................................7
4.2 Systems Engineering Process Planning ..................................................................8
4.2.1 Major Systems Engineering Products .................................................................8
4.2.2 Technical Objectives .........................................................................................10
4.2.3 Work Breakdown Structure...............................................................................10
4.2.4 Work Authorization ..........................................................................................10
4.2.5 Verification: Integration and Test Plans ...........................................................11
4.2.6 Participants........................................................................................................11
4.3 Requirements Analysis..........................................................................................12
4.3.1 Flowdown..........................................................................................................12
4.3.2 Engineering Considerations ..............................................................................12
4.3.3 Allocated Requirements ....................................................................................12
4.3.4 Review Process .................................................................................................13
4.4 System Analysis ....................................................................................................13
4.4.1 Trade Studies.....................................................................................................14
4.4.2 Cost Effectiveness Analyses .............................................................................14
4.5 System Control......................................................................................................14
4.5.1 Risk Management..............................................................................................14
4.5.2 Configuration Management ..............................................................................15
4.5.3 Interface Management.......................................................................................15
4.5.4 Technical Performance Metrics (TPMs)...........................................................15
4.5.5 Technical Reviews ............................................................................................16
4.5.6 Supplier Control ................................................................................................17
4.5.7 Requirements Traceability ................................................................................17
5 Implementation .............................................................................................................18
5.1 Integration of Systems Engineering Effort ...........................................................18
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 4 of 29
5.2 Problem Resolution...............................................................................................18
5.3 Systems Engineering Plans and Specifications.....................................................18
6 Other Systems Engineering Activities ..........................................................................19
6.1 Long Lead Items ...................................................................................................19
6.2 Engineering Tools .................................................................................................19
6.2.1 Requirements Management Software ...............................................................19
6.2.2 Database Software.............................................................................................20
6.2.3 Forms.................................................................................................................20
APPENDIX A .......................................................................................................................21
LAT Level III Specification Review/Release Description and Charge ............................21
APPENDIX B .......................................................................................................................25
Technical Review Definitions and Checklists ......................................................................25
System Requirements Review (SRR) ...............................................................................25
Preliminary Design Review (PDR)...................................................................................26
Critical Design Review (CDR) .........................................................................................27
Test Readiness Review (TRR) ..........................................................................................28
Pre-Shipment Readiness Review (PSRR).........................................................................29
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 5 of 29
1 Purpose and Scope This Systems Engineering Management Plan (SEMP) describes the activities, processes,
and tools that will by used by the GLAST Large Area Telescope (LAT) Systems Engineering team to support the design and construction of the LAT instrument and Instrument Operations Center. The objective of the Systems Engineering effort is to assure successful development of the LAT system primarily by defining clear and accurate system requirements and verifying compliance of the system to those requirements.
The LAT system consists of the Science Instrument (SI) and the Instrument Operations Center (IOC). The SI is a space-borne detector capable of measuring the direction and energy of incident cosmic gamma rays. The IOC is the ground-based facility that controls the operation of the SI and records and processes its raw data.
This SEMP is applicable to all Systems Engineering tasks to be performed in support of the LAT project. This document will be placed under change control upon its initial release.
2 Acronyms ACD – Anticoincidence Detector
CAL – Calormeter
CCB – Change Control Board
CDR – Critical Design Review
CEA – Commissariat à l'Energie Atomique
CMP – Configuration Management Plan
DAPNIA – Département d'Astrophysique, de physique des Particules, de physique Nucleaire et de L’Instrumentation Associée
E/PO – Education and Public Outreach
GLAST – Gamma-ray Large Area Space Telescope
GSFC – Goddard Space Flight Center
IN2P3 – Institut National de Physique Nucleaire et de Physique des Particules
INFN – Istituto Nazionale di Fisica Nucleare, Italy
IOC – Instrument Operations Center
IPI – Instrument Principal Investigator
IPM – Instrument Project Manager
IPO – Instrument Project Office
ISE – Instrument Systems engineer
KTH – Royal Institute of Technology, Sweden
LAT – Large Area Telescope
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 6 of 29
LOF – LAT Operations Facility
NRL – Naval Research Laboratory
PAIP – Product Assurance Implementation Plan
PAPL – Program Approved Product List
PDR – Preliminary Design Review
PER – Pre-Environmental Review
PFR – Problem/Failure Report
PSR – Pre-Shipment Review
RMP – Risk Management Plan
SAS – Science Analysis Software
SEMP – Systems Engineering Management Plan
SI – Science Instrument
SLAC – Stanford Linear Accelerator Center
SRR – System Requirements Review
SSAC – Senior Scientist Advisory Committee
SSRR – Subsystem Requirements Review
SSU – Sonoma State University
SU – Stanford University
SU-HEPL – Stanford University High Energy Physics Lab
T&DF – Trigger and Dataflow
TKR – Tracker
TPM – Technical Performance Metric
UCSC – University of California at Santa Cruz
WBS – Work Breakdown Structure
3 Applicable Documents The following documents are applicable to the development of this SEMP.
GLAST00110, “Mission Assurance Requirements (MAR) for Gamma-Ray Large Area Telescope (GLAST) Large Area Telescope (LAT)”, June 9, 2000
GEVS-SE Rev A, “General Environmental Verification Specification for STS & ELV Payloads, Subsystems, and Components”, http://arioch.gsfc.nasa.gov/302/gevs-se/toc.htm
“GLAST Large Area Telescope Flight Investigation: An Astro-Particle Physics Partnership Exploring the High-Energy Universe”, proposal to NASA, P. Michelson, PI, November, 1999.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 7 of 29
4 Systems Engineering Process
4.1 Organizational Responsibilities and Relationships The LAT team consists of members from several geographically diverse organizations and
is managed by the LAT Instrument Project Office (IPO) at Stanford Linear Accelerator Center (SLAC). The Instrument Systems engineer (ISE), who is part of the IPO and reports to the Instrument Project Manager (IPM), manages and is responsible for the systems engineering activities. The organizational structure of the LAT collaboration is shown in Figure 1.
The ISE provides technical leadership and directs the work of the subsystem development teams through the development and tracking of requirements, reserves, interface control documents, and performance and verification specifications. The ISE is responsible for assuring that the subsystems are compatible and meet the overall objectives. The ISE also oversees, from the instrument side, all aspects of the spacecraft/instrument interfaces.
Figure 1: LAT Organization Chart
System Engineer (ISE) SLAC
Integration & Test SLAC
Mech. Systems SLAC
Project Controls SLAC
Performance & Safety Assurance
SLAC
Principal Investigator (IPI) SU
Project Manager (IPM)SLAC
Instrument Design Team SLAC
Sci. Software SLAC
IOC SU
CAL NRL, France,
Sweden
TKR UCSC, SLAC,
Italy, Japan
ACD GSFC
Instrument Scientist GSFC
E/PO SSU
SSAC GSFC
Collaboration Science Team
Electronics & DAQ SLAC
IPO
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 8 of 29
The subsystem organizations provide support to the project systems engineering effort through development of subsystem level specifications and test plans and overseeing the subsystem-level verification process.
4.2 Systems Engineering Process Planning This section describes the key components of the LAT systems engineering process,
including the major systems engineering products, technical objectives, work breakdown structure, requirements verification, and engineering participants.
4.2.1 Major Systems Engineering Products
4.2.1.1 Integrated Database Throughout the design phase of the LAT project, many studies and analyses will be
conducted to support decisions regarding requirements selection and system design. The collection of these reports effectively documents the process of defining the LAT system and will be archived for future reference. As requirements and specifications are recorded in the requirements database, they will be linked to the applicable analyses to provide traceability to the rationale for the requirements. By providing the original context in which a requirement was selected, any future reconsideration of the requirement can determine if the original constraints are still valid.
4.2.1.2 Baselines Throughout the lifecycle of the project, the LAT system configuration is defined in a series
of technical baselines, consisting of the approved documentation used to define the technical requirements and interfaces. These baselines define the characteristics of the LAT system, subsystems, software and equipment at different development stages of the project. The technical baseline progresses from high-level requirements (the Functional Baseline) to more detailed requirements, design drawings and specifications (the Allocated Baseline) to complete “as-built” manufacturing drawings and specifications (the Product Baseline).
Specifications, interface control documents, and drawing packages are used to design and fabricate or procure items. These baseline documents will be organized in a hierarchy that provides design traceability to the lowest level. Once approved, these baseline documents are placed under configuration control, as described in the Configuration Management Plan (CMP).
4.2.1.3 Specifications The planned specification tree, Figure 2, shows the allocation of specifications to the
functional units of the LAT organization. The specification tree also represents the flow of requirements from the top-level mission requirements to increasingly detailed requirements for the subsystems.
The specifications are grouped into levels within the context of the GLAST project. The LAT instrument and IOC are two elements of the GLAST system. The high-level mission specifications are developed by the GLAST Project Office. The levels of specifications developed and controlled by the LAT Project are:
• Elements, Level II(b): The Level II(b) specifications contain the high-level performance requirements for the SI and IOC. These specifications are the
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 9 of 29
responsibility of the ISE. Changes to these specifications require approval of the Configuration Control Board (CCB) and GSFC.
• Subsystems, Level III: The Level III specifications define the requirements of the SI and IOC subsystems and components. These specifications are developed by the Subsystem Managers, but are controlled and approved by the ISE. Changes to the Level III specifications require approval of the CCB.
• Lower Levels: Lower-level specifications, not shown in Figure 2, describe individual items that are part of the subsystems. They are the responsibility of the Subsystem Managers and, once released, are controlled by the IPO. Changes to lower-level specifications require approval of the responsible Subsystem Manager.
Figure 2: Specification Tree
Document under control of the LAT Project
Operations ConceptDocument
GLAST00089
LAT Instrument Performance Spec.
LAT-SS-00010
LAT - ACD Spec. LAT-SS-00016
LAT - TKR Spec. LAT-SS-00017
LAT - CAL Spec. LAT-SS-00018
T&DF Spec. LAT-SS-00019
Aux. Subsystem Spec.LAT-SS-000xx
Leve
l I
Proj
ect S
peci
ficat
ions
Le
vel I
I(a) S
yste
m
Leve
l III
Su
bsys
tem
Spe
cific
atio
ns
LAT IOC Spec. LAT-SS-00021
Program Plan Requirements
Science Req’ts Document
GLAST00010
Mission Assurance Requirements GLAST00110
Mission System Specification GLAST00074
SGL Comm Interface Spec.
GBM Instrument Performance Spec.
LV Interface Specification
SC-SI Interface Specification GLAST00038
Spacecraft Performance Spec.
GBM IOC Specification
Inter-Center Interface Spec.
Mission Operations Center Spec.
Leve
l II(b
) Ele
men
t
LAT Interface Spec. LAT-SS-000xx
LAT IOC Performance Spec.
LAT-SS-00015
LAT SAS Spec. LAT-SS-00020
Science Support Center Spec.
Document not under control of the LAT Project
Leve
l II S
yste
m S
peci
ficat
ions
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 10 of 29
4.2.2 Technical Objectives The technical objectives of the GLAST mission are described in the Science Requirements
Document. The objective of the systems engineering process is to assure that the LAT system meets all the requirements that flow down from the mission objectives.
4.2.3 Work Breakdown Structure The work breakdown structure (WBS) is a hierarchical tree-like depiction of the system
development activities as they relate to the LAT system architecture. The WBS provides a coordinated and complete view of the LAT Project and is useful for technical systems engineering and non-technical program management activities. The initial WBS has already been developed for the Formulation Phase and the Implementation and Operations Phases of the project. The structure of the WBS is shown in Figure 3. For a detailed description of the WBS elements down to the fourth level, see the LAT proposal, Volume 2, Appendix F. This WBS will be maintained and updated by the IPO with support from the ISE.
The WBS is used by Systems Engineering to aid in:
• Identifying products, processes, data and documents.
• Organizing risk management analysis and tracking.
• Implementing configuration management and control of subsystem interfaces.
• Organizing technical reviews and audits.
4.2.4 Work Authorization The WBS defines the limits of individual responsibility for work efforts. The method for
authorizing work within the LAT Project is defined in the Project Management Plan.
Figure 3: Work Breakdown Structure
Level 2
Integration and Test Performance and Safety AssuranceInstrument Operations Center Education and Public Outreach
TrackerCalorimeterAnticoincidence DetectorTrigger and DataflowGrid
Instrument Management System Engineering Science
LAT System
IPO and System-Level Science
Level 1
Level 3
Hardware Subsystems Instrument-Level Functional Groups
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 11 of 29
4.2.5 Verification: Integration and Test Plans Subsystems will undergo a subsystem-level test program to verify that the units meet all
subsystem requirements prior to delivery to SLAC for integration into the system. The Subsystem Managers are responsible for developing the test plans.
The integrated instrument will undergo a system-level test program. The development of the system-level Integration and Test Plan is primarily the responsibility of the Integration and Test Manager.
Systems Engineering will review the test plans to assure that the requirements are sufficiently verified and that the test plans conform to the GLAST Project requirements contained in the Mission Assurance Requirements and General Environmental Verification Specification documents.
4.2.6 Participants The systems engineering process will involve coordinating the engineering efforts of
various institutions as they design and implement subsystems that will be integrated into a complete system at SLAC. The primary technical contact for a subsystem will be the Subsystem Manager. The engineering participants in the LAT Project are shown in Table 1.
Table 1: Participating Institutions
Institution Areas of Responsibility
SLAC Instrument systems engineering; electrical system engineering; TKR: mechanical design, construction, testing, integration; Grid development; Software management; Instrument integration and test; T&DF: engineering support
SU-HEPL T&DF subsystem development; IOC
GSFC ACD; thermal blankets; micrometeorite shield
NRL CAL: digital electronics and integration and test; T&DF: DAQ/CPU, DAQ/DSF, S/C Interface Unit
CEA/DAPNIA, France CAL: front-end photo-diodes and electronics readout
IN2P3/France CAL: mechanical design and assembly; CAL and instrument simulation
KTH, Stockholm Univ. CAL: CsI crystals
UCSC TKR: electronics, mechanical design, assembly, testing
JGC, Japan TKR: silicon-strip detectors
INFN, Italy TKR: silicon-strip ladders and tray assembly
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 12 of 29
4.3 Requirements Analysis Requirements analysis is the iterative process of transforming the mission objectives into a
set of requirements that define the characteristics and functions of the system and specify the environment in which it must perform. The process is iterative because as the design of the system progresses, further system analyses result in better understanding of the system and should prompt a reconsideration of the system requirements.
4.3.1 Flowdown The requirements analysis process involves transforming the mission objectives into high-
level performance requirements and then further refining those requirements into lower-level performance requirements and design specifications.
The LAT system requirements flow down from the GLAST mission requirements. The primary sources of the LAT requirements are:
• The GLAST Science Requirements Document
• The GLAST Science Instrument-Spacecraft Interface Requirements Document
• The Mission Assurance Requirements Document
• The General Environmental Verification Specification
• Derived Requirements The high-level mission requirements and the GLAST performance verification
requirements are transformed into performance specifications for the LAT instrument and IOC. These specifications are captured in the Level II(b) specifications, namely, the LAT Performance Specification and the LAT IOC Performance Specification. These documents undergo extensive review by the LAT team and are put under configuration management early in the Formulation Phase.
The subsystem-level performance and design requirements will flow down from the Level II(b) performance specifications. The flowdown of requirements will be documented and tracked using a requirements management software tool. The LAT requirements database will interface with the GLAST database, providing requirements traceability from the highest to lowest levels.
4.3.2 Engineering Considerations The reliability, maintainability and supportability of the system as well as other human
factors should be considered when developing and analyzing the LAT requirements. This is to ensure that the system will meet its performance requirements over its lifetime and in its operating environment and that it can be logistically supported, operated, and maintained at the intended level of skill and training.
4.3.3 Allocated Requirements Some system parameters, such as mass, power usage, and physical dimensions, must be
distributed among the subsystems in order to meet the overall system requirements. The allocation of these parameters is assigned by the IPO and is imposed on the subsystems through the
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 13 of 29
subsystem (Level III) specifications. The requirements analysis process will verify that requirements are correctly allocated to the subsystems.
4.3.4 Review Process All requirements documents will be subject to review by the appropriate LAT team
members prior to initial release. The reviewers are responsible for verifying that the higher-level requirements are satisfied. The reviewers should also verify that the requirements have the following attributes:
• Achievable – the requirement must be technically achievable within the allotted schedule and budget constraints.
• Verifiable – the requirement must be expressed in a way that is verifiable by an objective test or analysis.
• Unambiguous – the requirement must have only one possible meaning.
• Complete – the set of requirements must contain all the information necessary to successfully meet the mission objectives, including mission profiles, environments (including ground, handling and on-orbit environments), operational and maintenance concepts and interface constraints.
• Consistent – each requirement must not conflict with another requirement.
4.3.4.1 Specification Reviews – Level III Each Level III specification will be subject to a formal instrument-level review that is
coordinated by the ISE. Since the Level III specifications establish agreement between the IPO and the responsible subsystem organizations on the high-level performance and interface requirements that the subsystems must meet, it is important that these specifications undergo thorough review by all Subsystem Managers and representatives of the IPO prior to initial release.
The Level III Specification review process and the charge for the Review Board are described in detail in Appendix A.
4.3.4.2 Specification Reviews – Level IV and Lower All Level IV and lower specifications should be reviewed by personnel within the
subsystem organizations before they are submitted for initial release. The Subsystem Managers are responsible for reviewing and approving the specifications and submitting them to the IPO to be placed under configuration management.
4.4 System Analysis System analysis is the process of evaluating the system and documenting data and
decisions. System analysis activities support all steps of the systems engineering process and provide a quantitative basis for selecting performance, functional, and design requirements. All LAT system analyses will be documented and archived.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 14 of 29
4.4.1 Trade Studies System analysis uses trade studies to support decisions about requirements selections and
design alternatives. These trade studies target performance drivers and constraints from the limited resources, such as mass, power and dimension. Certain trade studies may also address increased margins in power and reliability as well as ease of fabrication and testing.
4.4.2 Cost Effectiveness Analyses Cost effectiveness analyses are used to provide economic balance to the systems
engineering decision-making process. Cost effectiveness analyses weigh the total cost of design alternatives against their effectiveness in order to determine the relative value of solutions. These analyses attempt to capture all short-term and long-term costs associated with an item. The potential costs and effectiveness parameters to be considered in the analyses are listed in Table 2.
Table 2: Cost Effectiveness Parameters
Life-Cycle Costs System Effectiveness Parameters
• Research, design, and development cost
• Construction cost
• Production cost
• System operation cost
• Maintenance and support cost
• Retirement and disposal cost
• System performance
• Availability, reliability, supportability
• Producability
• System quality
• Disposability
• Other technical factors
4.5 System Control System control is the collection of methods used to manage the project configuration, risk,
and subsystem and external interfaces, as well as to track both the LAT system performance and the progress of the system development.
4.5.1 Risk Management Risk management will be included as part of the system control process to accomplish the
following objectives:
• Identify the potential sources of risk and identify risk drivers.
• Quantify risks and assess their impacts on cost, schedule and performance.
• Determine the sensitivity of these risks to program, product and process assumptions, and the degree of correlation among the risks.
• Determine and evaluate alternative approaches to mitigate moderate and high risks.
• Take actions to avoid, control, assume or transfer each risk, and
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 15 of 29
• Ensure that risk is factored into decisions on selection of specification requirements and solution alternatives.
The risk management process for the LAT Project is described in detail in the LAT Risk Management Plan.
4.5.2 Configuration Management Systems engineering will exercise control of the LAT system design and fabrication
through configuration management. The objective of configuration management is to ensure that:
• Baselines are defined and documented
• Documentation is identified, released and controlled
• The Configuration Control Board (CCB) is established and functions according to CMP guidelines
• Changes to the baseline are evaluated and controlled
• Approved configuration changes are implemented and tracked
• Configuration status accounting is accomplished Configuration management is the responsibility of the Instrument Program Manager, but is
coordinated by the Instrument Systems Engineer. The configuration management process is described in detail in the LAT Configuration Management Plan.
4.5.3 Interface Management The interfaces between LAT subsystems will be defined in the LAT Subsystem Interface
Requirements Document. This document imposes the interface requirements on the subsystems. Changes to this document must be approved by the Configuration Control Board.
The LAT external interfaces are controlled by the GLAST Science Instrument-Spacecraft Interface Requirements Document. The LAT external interface requirements cannot be changed unless approval is granted by the GSFC Project Office.
4.5.4 Technical Performance Metrics (TPMs) The IDT will establish a set of TPMs to track critical performance parameters throughout
the development of the instrument. These TPMs are parameters that will impact the science, cost or schedule if they exceed critical values. These parameters, which are either directly measurable or derivable from modeling of the instrument, will be tracked as part of the systems engineering process to ensure that the mission objectives are met.
The technical performance metrics will be monitored and reported at project status and technical reviews. The report will include the current value and the threshold or “trigger point” for the current phase of development. The “trigger point” is the value which, if exceeded, triggers an automatic review of the entire system by the IPO to assess impacts and corrective actions.
The system-level metrics are flowed down and budgeted to the subsystems by the IDT. The top-level TPMs for the LAT instrument are:
• Instrument Mass
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 16 of 29
• Instrument Electrical Power
• Center of Gravity Offset from Instrument Interface Plane
• Horizontal Dimension
• Instrument Dead Time
• Background Rejection
• Field of View
• Single Photon Angular Resolution (68%) @ 1 GeV
• Single Photon Angular Resolution (95%) @ 1 GeV
• Peak Effective Area
• Energy Resolution @ 1 GeV
4.5.5 Technical Reviews The systems engineering process will utilize technical reviews to promote communication
and guidance within the LAT team and to provide status to and obtain feedback from the GSFC Project Office. These technical reviews will include the NASA mission-level reviews, NASA instrument-level reviews and LAT internal peer reviews. The time order of these reviews is depicted in Figure 4. The suggested content of these reviews is given in Appendix B.
Figure 4: Technical Review Timeline
NASA Instrument Reviews
Formulation Phase
NASA Mission Reviews
LAT Internal Instrument Reviews
Implementation Phase
SRR
Acronyms: CDR Critical Design Review IRR Interface Requirements Review PDR Preliminary Design Review
TRR Test Readiness Review PRR Production Readiness Review
PSRR Pre-Shipment Readiness Review SRR System Requirements Review
Time
M-CDR
I-CDR
L-SRR
L-PDR
L-CDR
L-PSRR L-TRR
M-PDR
I-PDR
L-IRR
L-PRR
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 17 of 29
The IPO will support the NASA mission-level reviews, including the M-PDR and the M-CDR, with status reporting on the instrument technical and programmatic progress.
For the NASA instrument-level reviews, the IPO will present designs, test plans, and verification plans. The review team will develop and present specific recommendations, actions, and concerns to the Project. These actions will be tracked to resolution by the IPM, to ensure closure, and then presented to the same team at the next review. The NASA instrument-level reviews include the SRR, I-PDR, and I-CDR.
The LAT internal peer reviews will be convened and managed by the ISE. For these reviews, technical experts from within the instrument subsystems will be called upon to engage in reviews of plans, designs, and implementations. Formal notes and action items will be taken at these peer reviews and will be presented at the NASA reviews. These peer reviews will occur at key development stages, such as preliminary design, design completion, pre-production, pre-test and pre-shipment.
Subsystem-level internal peer reviews, not shown in Figure 4, will be conducted at key development stages for major subsystem components. These reviews will be identified and called for by the ISE in concert with the responsible Subsystem Manager.
The ISE may convene other internal reviews not shown in Figure 4 on an ad hoc basis. GSFC will be invited to all peer reviews in accordance with the Mission Assurance Requirements.
4.5.6 Supplier Control Control of suppliers for subsystem components will be the responsibility of the Subsystem
Managers. In order to minimize the number of different part types used in the system and preclude use of parts with reliability deficiencies, the IPO will develop a Program Approved Parts List (PAPL). This is described in the Product Assurance Implementation Plan.
4.5.7 Requirements Traceability A requirements management software package will be used to facilitate requirements
traceability. This software will allow the LAT Project to convert requirements documents into requirements databases, with each requirement receiving a unique identifier. Each requirement in the database can then be assigned a link to a higher-level requirement. As lower-level requirements are developed, imported into the database, and linked to the higher-level requirements, a structure evolves which allows the flowdown of requirements to be traced from the highest-level mission objectives to the lowest-level component specifications.
The requirements database will include the following information about each requirement:
• Higher-level requirement satisfied
• Related documents (trade studies, system analyses, etc.)
• Requirement owner
• Requirement change history
• Verification method
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 18 of 29
5 Implementation
5.1 Integration of Systems Engineering Effort Through all phases of the LAT project, the systems engineering effort is managed by the
ISE. The systems engineering team will consist of engineering representatives from each of the subsystems. When special engineering disciplines are required, the ISE will obtain engineering support from SLAC resources or from other organizations if required.
During the integration and test phase at SLAC, the systems engineering team will work closely with the on-site LAT integration team to review and approve all test data and to identify and resolve problems.
5.2 Problem Resolution Problems or failures occurring during ground test of any flight hardware or software will be
identified, documented, assessed, tracked and corrected according to the procedures to be defined in the LAT Quality Manual. The process to assure closure of all such incidents is the Problem/Failure Report (PFR) system.
Systems Engineering is generally responsible for identifying the troubleshooting steps and other analyses required to assess the problem and to determine the resolution and corrective action. The ISE gives final approval of the corrective actions. The PSAM is responsible for tracking and closing PFR’s.
5.3 Systems Engineering Plans and Specifications
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 19 of 29
The systems engineering processes will be implemented upon release of the defining documents. The planned release of systems engineering documents is shown in Figure 5.
6 Other Systems Engineering Activities
6.1 Long Lead Items As stated in the LAT proposal, the instrument has only one long-lead item, the silicon-strip
detectors for the Tracker subsystem. An aggressive development program has been undertaken to fully characterize the requirements and performance of these detectors early in the Formulation Phase. Procurement of these items will begin early to ensure that delivery will pose a low schedule risk.
6.2 Engineering Tools
6.2.1 Requirements Management Software In order to facilitate requirements tracking, a requirements management software tool, such
as DOORS®, will be implemented and maintained at the IPO.
Project Milestones SRR PDR
LAT SE Documents Configuration Mngt Plan (CMP) Systems Engineering Mngt Plan (SEMP) Risk Mngt Plan (RMP) Software Mngt Plan (SMP) Integration and Test Plan (ITP) Level II(b) SAT System Specifications LAT Performance Specification (L-PS) LAT IOC Performance Spec. (L-IPS) Level III LAT Subsystem Specifications LAT – ACD Subsys. Spec. (L-ASS) LAT – Tracker Subsys. Spec. (L-TSS) LAT – Calorimeter Subsys. Spec. (L-CSS) LAT – Trigger & Data Subsys. Spec. (L-TDSS) LAT – Grid/Thermal Subsys. Spec. (L-GSS) LAT – Subsystem IRD (L-SIRD) LAT – Mechanical Design Spec. (L-MDS) LAT – Electronics Design Spec. (L-EDS) LAT – IOC Subsystem Spec. (L-ISS) LAT – Science Analysis Software Spec. (L-SSS) Level IV LAT Design Specifications LEVEL V LAT Detail Design Specifications
SSRR
Doc. Development Doc. Review Doc. Initial Release
Figure 5: LAT Systems Engineering Documentation Plan
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 20 of 29
6.2.2 Database Software Several databases will be maintained for systems engineering, such as an action item
database and configuration management and risk management databases. These databases will be implemented using simple database software, such as Microsoft Access.
6.2.3 Forms The IPO will provide forms to aid in risk management, configuration management, and
problem resolution activities. These forms, listed in Table 3, are provided to help capture all the pertinent information for systems engineering tasks.
Table 3: Systems engineering Forms
Form Purpose Where found
Problem/Failure Report (PFR) Document and resolve a hardware/software failure
PAIP
Document Change Notice (DCN) Authorize a change to a controlled document
CMP
Change Request (CR) Request CCB approval for a DCN if required
CMP
LAT Risk Appraisal Form Document and quantify risks to be evaluated by Risk Review Board
RMP
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 21 of 29
APPENDIX A
LAT Level III Specification Review/Release Description and Charge Refer to the Figure A-1 for a graphical depiction of the review and release
process.
Prepare Specification The Subsystem Manager prepares or is responsible for preparing the review draft
of the specification and requests the Project Manager for a review.
Charge Review Board and Announce Review The Project Manager identifies and assigns members of the Review Board. A
Review Charge and Notice is prepared and distributed to the Review Board. The Review Notice includes the following:
• Review Board assignments • Date and time of the review meeting • Expectations of Review Board members
Distribute Review Material and Solicit Comments The Review Notice and a copy of the specification are sent out to the Review
Board for comment two weeks prior to the review. The review materials are posted for general review by all LAT collaborators. Review Board comments are collected one week prior to the review meeting and are distributed to the Subsystem Manager and the other Review Board members.
Review Meeting At the review meeting, the specification is presented by the Subsystem Manager
or his representative. The specification is reviewed for completeness. This meeting is open to all LAT collaborators.
Review Record The Review Board Secretary records the comments, actions, resolutions, etc.
agreed upon by the Review Board and obtains Review Board concurrence for recommendations and changes to the specification. A Review Report is generated that captures review comments, recommends changes to the specification, and refers the specification for approval contingent upon the recommendations.
Resolve Actions and Update Specification The Subsystem Manager is responsible for updating the specification according to
the review report.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 22 of 29
Specification Signoff and Release The final draft of the specification is submitted to Systems Engineering for
approval. All required approvals are obtained and a Document Change Notice is generated. The document and DCN are then released, placed under Configuration Management and are posted to the CyberDocs system.
Figure A-1. LAT Level III Specification Review Process
SSM prepares specification and requests a review.
PM charges Review Board and announces
review.
SE distributes review material 2 weeks prior
to review meeting.
Review Meeting
Specification is presented by the specification owner for Board review
and comment.
Open to all
SE assembles Review Record, which contains: • Comments • Actions • Recommendations • Board concurrence
SSM resolves actions and
updates specification.
SSM and SE submit
specification for signoff and
release.
SSM = Subsystem Manager SE = System Engineering PM = Project Manager
Review Board comments are collected and distributed by SE
one week prior to review meeting.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 23 of 29
Review Board Charge Specification Reviews – Level III
(Subsystem performance specification) The purpose of the Level III specification review is to validate the flow-down of
requirements from higher-level specifications. The LAT Performance Specification, LAT IOC Performance Specification, and Mission System Specification as well as other GLAST specification are where most level III requirements are decomposed.
The review board is charged with sitting in review of the specification to assess the completeness of the requirements, recommend acceptance of the specification, and summarize the review and assessments in a review report.
The Specification: The specification, prepared by the subsystem manager, will be distributed to the
review board at least two weeks prior to the review. At the completion of the review, the subsystem manager will be responsible for updating the specification according to the recommendation of the review Board.
The Review Board: The review board consisting primarily of the LAT subsystem managers and
functional leads are expected to review the submitted specification and submit comments to the committee chairperson one week prior to the review meeting. Each member of the board is expected to query the specification and presenter at the review meeting as necessary to understand and assess the requirements. The chairperson or project manager may add additional members of the board.
Level III Specification Review Board: ACD Subsystem Mng’r Jonathan Ormes jfo@lheapop.gsfc.nasa.gov CAL Subsystem Mng’r Neil Johnson johnson@gamma.nrl.navy.mil TKR Subsystem Mng’r Robert Johnson johnson@scipp.ucsc.edu IOC Subsystem Mng’r Scott Williams scott@razzle.stanford.edu Electronics Systems Eng’r Gunther Haller haller@slac.stanford.edu Mechanical Systems Eng’r Martin Nordby nordby@slac.stanford.edu Instrument Scientist Steve Ritz ritz@milkyway.gsfc.nasa.gov Instrument System Eng’r(chair) Tim Thurston thurston@slac.stanford.edu Instrument Technical Mng’r Tune Kamae kamae@slac.stanford.edu PSA Mng’r Darren Marsh dmarsh@slac.stanford.edu Review Board Secretary Warren Davis wdavis@slac.stanford.edu
The Assessment: The level III specification review board is selected and charged with probing the
specification to assess a) the completeness, b) the source of requirements, and c) the verifiability of submitted requirements.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 24 of 29
The completeness of the requirement set should be assessed for the following:
Performance – Do the derived requirements satisfy the performance requirements of higher-level requirements? How?
Functionality – Are requirements defined and consistent with higher-level and interfacing requirements?
Feasibility – Are presented requirements achievable? Does any evidence exist in support of this?
Quality – Have standards been established in specification?
Reliability – Do requirements clearly support the mission life? Are redundancy and component reliability identified in supports mission reliability?
Operability – Do requirements support performance throughout the mission life? Is performance degradation taken in to account?
The source of stated requirements should be assessed to identify the flow-down. Additionally, studies and analyses should be identified that demonstrate how the higher-level or shared requirements are satisfied.
Verifiability of requirements should be assessed for feasibility and practicality of the verifying method. Since all requirements must be verified, the specification should identify the methods to be employed.
The Review: The committee chair will conduct the review. The subsystem manager submitting
the specification will make a presentation of requirements, walking the board through each requirement, its source, and verification. Board members will submit recommendations for action (RFA) forms for any item of concern. The secretary will record minutes of the meeting.
The Review Recommendation: The review board is expected to make a recommendation for approval contingent
on resolution of open issues. Questions, concerns, deficiencies and comments regarding a requirement will be documented and carried in the review.
The Review Report: The secretary will collect RFA’s, comments, and decisions and prepare a
summary report of the review for concurrence for the review board. The Review report will be distributed within the week following the review. The report will be presented and discussed at a subsequent IDT meeting.
The Specification Approval and Release: The updated document, and review recommendations will be forwarded to the
project manager for approval. A document change notice (DCN) will accompany the documentation as it is released and distributed through the LAT Document Control System.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 25 of 29
APPENDIX B
Technical Review Definitions and Checklists
System Requirements Review (SRR) The SRR occurs early in the Formulation Phase and is used to reach mutual agreement between
all parties to the development of system requirements. In this review, the draft system requirements should be reviewed for completeness and necessity. The draft system specification should be complete with all TBR items clearly identified with planned closure responsibility and dates. The draft system architecture and external interfaces should also be reviewed.
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 26 of 29
Preliminary Design Review (PDR) The Preliminary Design Review occurs at the end of the Formulation Phase and is used to
determine if the project is ready to authorize the detailed design work involving a considerable increase in manpower and cost. All system and subsystem requirements must be complete as well as credible design concepts that are responsive to those requirements. The PDR should address the following items:
�� Subsystem block and functional diagrams
�� Equipment layouts and preliminary drawings
�� Environmental controls and thermal design aspects
�� Power distribution and grounding
�� Electromagnetic compatibility considerations
�� Instrumentation, control, and diagnostic design approach
�� Producibility and manufacturing considerations
�� Preliminary parts lists
�� Support system requirements and design approach
�� Preliminary Development Specifications
�� Physics parameter modeling, test, and simulation data
�� Software Development Plan
�� Software requirements specifications (Preliminary Design)
�� Risk and abatement strategy
�� Interface control documents
�� Design standardization and logistic considerations
�� Trade and design studies
�� Preliminary reliability, maintainability, and availability studies
�� Transportation, packaging, and handling considerations
�� Environmental, Health, and Safety analyses
�� Quality Control Planning
�� Test methodology
�� Schedules
�� Problems and Concerns
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 27 of 29
Critical Design Review (CDR) The CDR occurs after the design is approximately 90% completed and is used to determine if
the project is ready to proceed to the manufacture of flight and ground support hardware and the coding of software. The following items should be addressed to the extent possible:
�� Subsystem block and functional diagrams
�� Drawing packages (assembly drawings and majority of remaining drawings)
�� Final parts lists
�� Final Development Specifications
�� Design analysis and engineering test data
�� Detailed software design, database design, interface design, firmware support, and computer resources integrated support documents
�� Logistic support considerations
o Transportation, packaging, and handling
o Standardization
o Support equipment requirements
o Spares requirements
o Calibration requirements
�� Risk: cost, schedule, and technical
�� Plans for acquisition of parts, components, and materials needed for fabrication
�� Integration and Test Plans
�� Software Test Plans
�� Design reliability and maintainability
�� System safety
�� Quality control plans
�� Schedules
�� Problems and concerns
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 28 of 29
Test Readiness Review (TRR) The PER occurs prior to the start of environmental testing of the integrated instrument. The
primary purpose of the PER is to establish the readiness of the system for test and to evaluate the environmental test plans. The following items should be addressed:
�� Changes since the CDR
�� Tests planned
�� Test facilities
�� Test configuration
�� Test procedure status
�� Staffing plans
�� System performance during initial performance testing
�� Significant Problem/Failure Reports (status and plans for closure)
�� Risk: cost, schedule, and technical
�� System safety
�� Schedules
�� Problems and concerns
LAT-MD-00066-01 LAT Systems Engineering Management Plan Page 29 of 29
Pre-Shipment Readiness Review (PSRR) The PSR takes place prior to shipment of the instrument for integration with the spacecraft.
The PSR establishes the completion of the integration and test of the instrument. This review focuses on the system performance during qualification testing and the verification of all system requirements. The following items should be addressed:
�� Changes since the PER
�� System performance during environmental and final performance testing
�� Significant Problem/Failure Reports (status and plans for closure)
�� Documentation to be sent to spacecraft contractor
�� System safety
�� Constraints to spacecraft integration
�� Schedules
�� Problems and concerns
top related