semp

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 of 29

CHANGE HISTORY LOG Revision Effective Date Description of Changes DCN #

1 Initial Release LAT-CN-000xx


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


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


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


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.

http://arioch.gsfc.nasa.gov/302/gevs-se/toc.htm


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


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


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


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


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


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


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.


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


• 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


• 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


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


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


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


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


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.


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.


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 [email protected] CAL Subsystem Mng’r Neil Johnson [email protected] TKR Subsystem Mng’r Robert Johnson [email protected] IOC Subsystem Mng’r Scott Williams [email protected] Electronics Systems Eng’r Gunther Haller [email protected] Mechanical Systems Eng’r Martin Nordby [email protected] Instrument Scientist Steve Ritz [email protected] Instrument System Eng’r(chair) Tim Thurston [email protected] Instrument Technical Mng’r Tune Kamae [email protected] PSA Mng’r Darren Marsh [email protected] Review Board Secretary Warren Davis [email protected]

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.

mailto:[email protected]












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.


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.


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


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


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


�� Schedules



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


�� Constraints to spacecraft integration

�� Schedules
