Attachment_D,_WFIRST-RQMT-05819_Released_Rev_A.pdf

Effective Date February 23, 2018

Expiration Date:February 23, 2023

CHECK https://gddms.gsfc.nasa.gov/Windchill/app/

TO VERIFY THAT THIS IS THE CORRECT VERSION PRIOR TO USE.

National Aeronautics and Space Administration

Goddard Space Flight Center Greenbelt, Maryland

WFIRST-RQMT-05819, Revision A

Wide Field Infrared Survey Telescope (WFIRST)

Code 448

Mission Assurance Requirements (MAR)

Mission Risk Classification – NPR 8705.4

Class A

GSFC WFIRST CMO

February 28, 2018

Released https://gddms.gsfc.nasa.gov/Windchill/app/

WFIRST MAR WFIRST-RQMT-05819, Revision Number A

Effective Date: February 23, 2018

400-FORM-0002 (4/16/2014)

Mission Assurance Requirements (MAR)

Review/Signature/Approval Page

Prepared by:

Timothy Bowser

Approved by:

Kenneth Anderson

Concurred by:

Jesse Leiter

Electronic Approval available on-line at: https://gddms.gsfc.nasa.gov/Windchill/app https://gddms.gsfc.nasa.gov/Windchill/app

WFIRST MAR WFIRST-RQMT-05819, Revision A ii

Preface

This document is a Wide Field Infrared Survey Telescope (WFIRST)

Configuration Management (CM)-controlled document. Changes to this document require prior approval of the applicable Configuration Control Board (CCB) Chairperson or designee.

Proposed changes shall be submitted to the WFIRST CM Office (CMO), along with supportive material justifying the proposed change.

In this document, a requirement is identified by “shall,” a good practice by “should,” permission by “may” or “can,” expectation by “will,” and descriptive material by “is.”

Questions or comments concerning this document should be addressed to:

WFIRST Configuration Management Office

Mail Stop 448

Goddard Space Flight Center

Greenbelt, Maryland 20771 iii

Change History Log

Revision Effective Date Description of Changes

(Reference the CIR/CCR & CCB/ERB Approval Date)

Rev- April 12, 2017 Initial Release of document per WFIRST-CIR-01958

Rev A February 23, 2018 Class A Upgrades per WFIRST-CCR-05371 iv

Table of TBDs/TBRs/TBSs

Item No. Location Summary Individual/

Organization

Actionee

Due Date

001 Section 3.8 Inspection and Test GMIPS CSO v

Table of Contents

1 INTRODUCTION

1.1 Purpose

1.2 Scope

2 RELATED DOCUMENTATION

2.1 Applicable Documents and Forms

2.2 Reference Documents

3 GENERAL

3.1 System Safety and Mission Assurance Program

3.1.1 Flight hardware and software that is designed, built, or provided by the developer and its subcontractors or furnished by the government, from project initiation through launch and mission operations

3.1.2 The ground support equipment that interfaces with flight items to the extent necessary to assure the integrity and safety of flight items

3.2 Management

3.3 Suspension of Work Activities

3.4 Requirements Flowdown

3.5 Data Item Descriptions (DID)

3.6 Surveillance

3.7 Use of Inherited Products

3.8 Government Mandatory Inspection Points (GMIPS)

4 QUALITY MANAGEMENT SYSTEM

4.1 General

4.2 Nonconforming Material

4.2.1 Control of Nonconforming Product

4.2.2 Material Review Board (MRB)

4.2.3 Anomaly Reporting and Disposition

5 SYSTEM SAFETY

5.1 General

5.2 Mission Related Safety Requirements Documentation

5.3 System Safety Deliverables

5.3.1 System Safety Program Plan

5.3.2 Safety Requirements Compliance Checklist

5.3.3 Hazard Analyses

5.3.4 Safety Data Package (SDP)

5.3.5 Verification Tracking Log (VTL)

5.3.6 Hazardous Procedures for Payload I&T and Pre-launch Processing

5.3.7 Safety Waivers

5.3.8 Orbital Debris Assessment Report (ODAR) and End of Mission Plan (EOMP)

5.3.9 Mishap Reporting and Investigation

5.3.10 NASA Expendable Launch Vehicle (ELV) Payload Safety Program Forms

6 RELIABILITY

6.1 Reliability Requirements

vi

6.2 Reliability Program Plan (RPP)

6.3 Probabilistic Risk Assessment

6.4 Software Reliability Analysis

6.5 FMEA/FMECA and Critical Items List (CIL)

6.6 Fault Tree Analysis (FTA)

6.7 Parts Stress Analysis

6.8 Worst Case Analysis

6.9 Reliability Assessments and Predictions

6.10 Trend Analysis

6.11 Analysis of Test Results

6.12 Limited Life Items

6.13 Single Point Failures

6.14 Redundant Systems

7 SOFTWARE ASSURANCE

7.1 Applicable Software Definitions

7.2 Software Assurance Program

7.2.1 Software Quality

7.2.2 Software Safety Analysis

7.2.3 Software Reliability Analysis

7.2.4 Verification and Validation

7.2.5 Independent Verification and Validation (IV&V)

7.3 Software Reviews

7.4 Surveillance of Software Development, Maintenance, and Assurance Activities

8 DIGITAL ELECTRONIC COMPONENTS

8.1 General

8.2 Peer Reviews

9 WORKMANSHIP

9.1 General

9.2 Design and Process Qualification

9.3 Electrostatic Discharge Control (ESD)

9.4 Splices, Circuit Board Trace Cuts, and Jumper Wires

9.5 Printed Circuit Board (PCB) Test Coupons

9.6 Use of Water Soluble Flux

9.7 Lead-Free and Tin Whisker Control Measures

9.8 Touch-up and rework of Printed Wiring Board Assemblies

10 EEE PARTS

10.1 General

10.2 Parts Control Board

10.3 Re-use of EEE Parts

10.4 EEE Parts Lists

11 MATERIALS AND PROCESSES

11.1 Materials and Processes Selection, Control, and Implementation Plan (MPSCIP)

11.2 Materials Usage Agreement (MUA)

11.3 Materials Identification and Usage List (MIUL)

vii

11.4 Life Test for Lubricated Mechanisms

12 CONTAMINATION CONTROL

12.1 Contamination Control Plan

12.2 Material Outgassing

12.3 Foreign Object Debris Program

13 METROLOGY AND CALIBRATION

13.1 Metrology and Calibration Program

13.2 Use of Calibrated and Non-calibrated Instruments

14 GIDEP ALERTS AND PROBLEM ADVISORIES

14.1 Government-Industry Data Exchange Program (GIDEP)

14.2 Alert Disposition

14.3 GIDEP Reporting

14.4 Review Reporting

15 END ITEM ACCEPTANCE DATA PACKAGE

APPENDIX A DATA ITEM DESCRIPTIONS

APPENDIX B. DATA ITEM DESCRIPTION LIST

APPENDIX C. MISSION ASSURANCE COMPLIANCE MATRIX

APPENDIX D. ABBREVIATIONS AND ACRONYMS

List of Figures

No table of figures entries found.

List of Tables

Table 1. Inherited Product Data Requirements

Table 2. Inherited Product Supplementary Information Table 3 Severity Categories Table 4 Liklihood Rankings

Table 5 RPN Scores

1 INTRODUCTION

1.1 Purpose

The purpose of this document is to establish the Safety and Mission Assurance (SMA) guidelines and requirements for the Wide Field Infrared Survey Telescope (WFIRST) Project as a means to assure the mission success and safety of personnel, payloads, equipment, and facilities. This

Mission Assurance Requirements (MAR) document is in accordance with the requirements of

NPR 8705.4, Risk Classification for Payloads, for Class A missions.

NASA Headquarters has designated WFIRST as a Class A mission through the direction of the

Program-Level Requirements Appendix, (PLRA); with the exception that a protoflight development approach will be followed, flight sparing will be a combination of assembly and sub-assembly level, and a combination of Level 1 and 2 parts will be allowed.

Therefore, the WFIRST assurance plan will focus on developing a robust, fault-tolerant system that is assessed and verified to meet mission-unique challenges. Compliance to the above requirements should not drive cost without commensurate risk reduction.

1.2 Scope

These guidelines and requirements apply to the design, development, manufacturing, procurement, test, integration, flight operations, and pre- and post-mission ground operations phases of the

WFIRST project. This includes, but is not limited to, flight hardware (spacecraft, telescope and instruments), ground support equipment that interfaces with flight hardware, and critical ground support equipment. Subsystem procurement documentation will include applicable portions of these requirements without imposing the entire MAR document.

2 RELATED DOCUMENTATION

The version of the documents below will be the most current revision at the time the contract is awarded. For IPC documents where the space addendum is included, the revision is signified by

“ x”, ex. IPC J-STD-001xS refers to the J-STD most current revision with the space addendum revision. WFIRST documents can be obtained from https://gddms.gsfc.nasa.gov/Windchill/app/.

2.1 Applicable Documents and Forms

The following documents are referenced within this MAR’s sections as shown below, and are applicable to the extent indicated by the requirement statements in those sections. In the event of conflict between an Applicable Document and the content of this document, the WFIRST Project

Configuration Change Board has the final authority for conflict resolution.

Document Number Title Section(s)

500-PG-8700-2.7 Design of Space Flight Field Programmable Gate Arrays 8.2

541-PG-8072.1.2 GSFC Fastener Specification Integrity Requirements DID 11-1

ANSI/ESD S20.20

Protection of Electrical and Electronic Parts, Assemblies and

Equipment (Excluding Electrically Initiated Explosive

Devices)

9.3

ANSI/NCSL Z540.1

Calibration Laboratories & Measuring & Test Equipment -

General Requirements

13.1

ANSI/NCSL Z540.3

Requirements for the Calibration of Measuring and Test

Equipment

13.1

ASTM E595 Standard Test Methods for Total Mass Loss and Collected

Volatile Condensable Materials from Outgassing in a Vacuum

Environment

12.2

ECSS-Q-ST-70-10 Qualification of Printed Circuit Boards 9.1

Federal Acquisition

Regulations

Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5 for government quality assurance requirements at contractor facilities; Part 52.246 for inspection clauses by contract type

3.6, 3.8

GEIA-STD-0005-1

Performance Standard for Aerospace and High Performance

Electronic Systems Containing Lead-free Solder

DID 9-6

GEIA-STD-0005-2

Standard for Mitigating the Effects of Tin Whiskers in

Aerospace and High Performance Electronic Systems

DID 9-6

GPR 2810.1 Security of Informaiton Technology 7.2

GPR 8730.5

Safety and Mission Assurance Acceptance of Inherited and

Build-to-Print Products

3.7

GSFC-STD-1000 Rules for the Design, Development, Verification, and

Operation of Flight Systems

6.13, 6.14, DID

12-1

GSFC-STD-6001

Ceramic Column Grid Array Design and Manufacturing

Rules for Flight Hardware

9.1

GSFC-STD-8002

GSFC Standard Quality Assurance Requirements for the Use of Water Soluble Flux

9.1, 9.6, DID 9-5

IEEE Standard 730 Software Quality Assurance Plans 7.2, DID 7-1

IPC-2221 Generic Standard on Printed Board Design 9.1, 9.5, DID 9-3

IPC-2222 Sectional Design Standard for Rigid Organic Printed Boards 9.1

IPC-2223 Sectional Design Standard for Flexible Printed Boards 9.1

IPC-2225

Sectional Design Standard for Organic Multichip Modules

(MCM-L) and MCM-L Assemblies

9.1

IPC-6011

Generic Performance Specification for Printed Boards (Class

3 requirements)

9.1

IPC-6012xS Qualification and Performance Specification for Rigid

Printed Boards with Space Addendum

9.1

IPC-6013

Qualification and Performance Specification for Flexible

Printed Boards (Class 3 requirements)

9.1

IPC-6015

Qualification and Performance Specification for Organic

Multichip Module (MCM-L) Mounting and Interconnecting

Structures

9.1

IPC-6018xS

Space and Military Avionics Applications Addendum to

IPC-6018C Qualification and Performance Specification for

High Frequency (Microwave) Printed Boards

9.1

IPC-J-STD-001xS

Joint Industry Standard, Space Applications Electronic

Hardware Addendum (except Chapter 10 of IPC-J-STD-001) with Space Addendum

9.1, DID 9-6

IPC/WHMA-A-620xS Requirements and Acceptance for Cable and Wire Harness

Assemblies, Space Addendum

9.1

ISO 17025

General requirements for the competence of testing and calibration laboratories

13.1

ISO 9001 Quality Management System 4.1

KNPR 8715.3 KSC Safety Procedural Requirements 5.2, DID 5-5

MIL-PRF-50884

Performance Specification: Printed Wiring Board, Flexible or Rigid-Flex, General Specification For

9.1

MIL-PRF-55110

Performance Specification: Printed Wiring Board, Rigid, General Specification For

9.1

NAS 412

Foreign Object Damage/Foreign Object Debris (FOD)

Prevention

DID 12-1, DID

12-2

GSFC-EEE-INST-002

Instructions for EEE Parts Selection, Screening, Qualification, and Derating

6.7, 10.1 DID 6-

4, DID 10-1

NASA-STD-5017

Standard Materials and Processes Requirements for

Spacecraft. Paragraphs 4.16 and 4.13.3

11.4, 11-4

NASA-STD-6008 NASA Fastener Procurement Receiving Inspection &

Storage Practices for Spaceflight Hardware

DID 11-1

NASA-STD-6016

Standard Materials and Processes Requirements for

Spacecraft

11.1, 11.2, 11.3, 12.1, 12.2, 12.3, DIDs 11-1, 11-2, 11-3, 12-1

NASA-STD-8719.9 Lifting Standard 5.3.3, DID 5-1, DID 5-3

NASA-STD-8719.13

NASA Software Safety Standard 6.5, 7.1, 7.2, 7.2.2, DID 7-1

NASA-STD-8719.14 Process for Limiting Orbital Debris, Appendices A and B 5.3.8, DID 5-6

NASA-STD-8719.24

(with Annex)

NASA Expendable Launch Vehicle Payload Safety

Requirements

5.1, 5.3.3, 5.3.3.4, 5.3.4

NASA-STD-8739.1

Workmanship Standard for Polymeric Application on

Electronic Assemblies

9.1

NASA-STD-8739.4

Workmanship Standard for Crimping, Interconnecting

Cables, Harnesses, and Wiring

9.1

NASA-STD-8739.5

Workmanship Standard for Fiber Optic Terminations, Cable

Assemblies, and Installation

9.1

NASA-STD-8739.6

Implementation Requirements for NASA Workmanship

Standards

9.1

NASA-STD-8739.8

Standard for Software Assurance 7.1, 7.2, 7.2.1, 7.2.3, 7.2.4, 7.2.5, 7.3, 7.4

NPR 7120.5

NASA Space Flight Program and Project Management

Processes and Requirements

6.2

NPR 7150.2

NASA Software Engineering Requirements 7.2, 7.2.1, 7.2.4, 7.3, 7.4, DID 7-1, DID 7-2

NPR 8621.1

NASA Procedural Requirements for Mishap and Close Call

Reporting, Investigating, and Recordkeeping

5.3.9

NPR 8705.4

Risk Classification for NASA Payloads 1.1, 6.1-6.7, 6.9, DIDs 6-1, 6-2, 6-

3, 6-4, 6-5

NPR 8705.5

Technical Probabilistic Risk Assessment (PRA) Procedures for Safety and Mission Success for NASA Programs and

Projects

6.1

NPR 8715.3 NASA General Safety Program Requirements DID 6-3

NPR 8715.7

Expendable Launch Vehicle (ELV) Payload Safety Program 5.1, 5.2, 5.3.1, 5.3.2, 5.3.3.1, 5.3.3.2, 5.3.5, 5.3.6, 5.3.7, DID

5-1

NPD 8720.1 NASA Reliability and Maintainability (R&M) Program

Policy

6.10, 6.11, 6.12, DID 6-1, DID 6-5

S0300-BT-PRO-010

Government-Industry Data Exchange Program (GIDEP)

Operations Manual

14.1, 14.3

S0300-BU-GYD-010

Government-Industry Data Exchange Program (GIDEP)

Requirements Guide

14.1, 14.3

SAE AS9100 Quality Management Systems - Requirements for Aviation, Space, and Defense Organizations

4.1, DID 4-1,

DID 4-2

WFIRST-PLAN-08010 WFIRST System Safety Program Plan 5.1, 5.3.1, DID 5-

WFIRST-PLAN-08008 WFIRST Project Surveillance Plan 3.6

WFIRST-REF-06764 Radiation Environment for the Wide-Field Infrared Survey

Telescope (WFIRST)

DID 10-1

2.2 Reference Documents

The following documents are referenced herein and amplify or clarify the information presented in this document. These documents are not binding on the content of this document.

Document Number Title

GSFC-FAP-322-208 NASA Fault Tree Handbook with Aerospace Applications

(http://www.hq.nasa.gov/office/codeq/doctree/fthb.pdf)

DID 6-3

GSFC 500-PG-

8715.1.2

Applied Engineering and Technology Directorate (AETD)

Safety Manual (for operations at GSFC)

DID 5-3, DID 5-5

GSFC-STD-7000 General Environmental Verification Standard (GEVS) DID 12-1

IEST-STD-CC1246 Product Cleanliness Levels and Contamination Control

Program

DID 12-1

http://www.hq.nasa.gov/office/codeq/doctree/fthb.pdf

ISO 146441-1 Cleanrooms and Associated Controlled Environments –

Classification of Air Cleanliness

DID 12-1

NASA/CR-2005-

213424

Lubrication for Space Applications 11-4

NASA-STD-8729.1 Planning, Developing and Managing an Effective Reliability and Maintainability (R&M) Program

DID 6-1, DID 6-5

NASA-TM-86556 Lubrication Handbook for the Space Industry (Part A: Solid

Lubricants, Part B: Liquid Lubricants)

11-4

WFIRST-PLAN-

06635

WFIRST Contamination and Control Plan DID 12-1

WFIRST-PLAN-08011 WFIRST Reliability Program Plan, 3 GENERAL

3.1 System Safety and Mission Assurance Program

The developer shall implement a safety and mission assurance program that is consistent with the requirements in this MAR as implemented through DID 3-1. The mission assurance program shall cover:

3.1.1 Flight hardware and software that is designed, built, or provided by the developer and its subcontractors or furnished by the government, from project initiation through launch and mission operations.

3.1.2 The ground support equipment that interfaces with flight items to the extent necessary to assure the integrity and safety of flight items.

NOTE: The Ground MAR, WFIRST-RQMT-06634, will define Safety and Mission Assurance requirements for the Ground System including the Science Operations Center (SOC), and the

Mission Operations Center (MOC) and/or Ground System supporting the mission.

The developer shall submit a Mission Assurance Implementation Plan (MAIP) or Quality Plan that includes hardware and software per (DID 3-1). While the MAIP or Quality Plan represents how the developer will meet the MAR requirements using their internal documentation; it does not supersede the MAR requirements. The Plan shall include a mission assurance requirements compliance matrix that identifies variances and acceptance rationale for processes, procedures, and standards that are proposed as alternatives to those specified by the MAR in Appendix C.

Mission Assurance Compliance Matrix and delivered for acceptance in (DID 3-1).

Traceability: GPR 1280.1 P.2; NPD 1280.1 5.c

3.2 Management

The developer shall designate an Assurance Manager that is independent and responsible as a single point of contact for all Safety and Mission Assurance activities. The Assurance Manager shall not be responsible for project costs and schedules other than those pertaining to assurance activities. The Assurance Manager shall have direct access to management that is independent of project management and the functional freedom and authority to interact with all elements of the project.

3.3 Suspension of Work Activities

The developer shall direct the suspension of any work activity that presents a hazard, imminent danger, or future hazard to personnel, property, or mission operations resulting from unsafe acts or conditions that are identified by inspection, test, or analysis.

Traceability: NPD 8700.1 NASA Policy for Safety and Mission Success, paragraph 1.b

3.4 Requirements Flowdown

The developer shall apply system safety and mission assurance requirements to subcontractors and suppliers to the extent necessary to ensure that the delivered product meets performance requirements and this MAR. The developer shall supply a Mission Assurance Implementation

Plan (MAIP) or Quality Plan to include specifics of the subcontractor requirements flowdown and oversight process in support of this project. Developer shall provide key sub-tier component suppliers’ MAIP/Compliance Matrix response to the government.

Traceability: GPR 1280.1 The GSFC Quality Manual, paragraph 1.1

3.5 Data Item Descriptions (DID)

The developer shall deliver data items per the requirements of the applicable DID. A complete list of DIDs associated with the MAR may be found in Appendix A Data Item Descriptions of this document. The developer may combine deliverables if the requirements for the individual deliverables are addressed and submit them as Contract Deliverable Items Lists (CDRLs).

The developer shall perform work in accordance with the following definitions:

a. Deliver for approval: The GSFC Project approves the deliverable within the specified period of time before the developer proceeds with the associated work.

b. Deliver for review: The GSFC Project reviews the deliverable and provides comments within the specified period of time before the developer proceeds with the associated work.

The developer can continue with the associated work while preparing a response to the GSFC comments unless directed to stop work.

c. Deliver for information: For GSFC Project information only. The developer continues with the associated work.

Traceability: GPR 5100.1 Procurement, paragraph 3.1a

3.6 Surveillance

The developer shall grant access for National Aeronautics and Space Administration (NASA) and NASA appointed quality assurance representatives to conduct inspections, audits and assessments as covered in the WFIRST Project Surveillance Plan.

The developer shall supply documents and records (including remote electronic access), equipment, and a suitable work area within the developer’s facilities to support these surveillance activities.

The developer shall provide a list of key sub-tier suppliers. This list will be included in the

Mission Assurance Compliance Matrix with the MAIP or Quality Plan (DID 3-1).

Note: See Federal Acquisition Regulations (FAR) Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5 for government quality assurance requirements at contractor facilities. See FAR Part 52.246 for inspection clauses by contract type.

Traceability: GPR 5100.1 Procurement, paragraph 1.1g; Part 46 Federal Acquisition

Regulations, paragraphs Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5

3.7 Use of Inherited Products

For inherited products, defined as those that were previously developed and exist (e.g., spares), will be build-to-print (BTP), or are available as commercial-off-the-shelf (COTS), the developer may follow an inherited items review process. With this process the Government establishes a risk for using the product that is based on established prior history, changes in design, environment or operations, and information regarding the processes used to develop the product. The government will determine if the risks are acceptable or if mitigations are required.

The developer shall assume ownership and responsibility for risks mitigation.

To follow this process, the developer shall provide the data specified in Table 1. Inherited

Product Data Requirements to substantiate the product’s baseline and risk of use. The developer may provide additional available information from Table 2 to reduce the risk.

The developer shall provide the initial Inherited Items package at thirty (30) days after contract award and the final package thirty (30) days after Systems Requirements Review.

The developer shall participate in Technical Interchange Meetings (TIMs) to substantiate the baseline risk and potential risk mitigation strategies for inherited products.

Use of this process does not relieve the developer from meeting contractual performance and functional requirements.

Table 1. Inherited Product Data Requirements

No. Data Needed for Inherited Products

List of inherited products and statement of approach to use – rebuild, modification of previous build, or use of existing product

Summary results of qualification, acceptance, and/or prototype/proto-flight testing completed, or comparison of current qualification/proto-qualification requirements and what was performed/realized on the inherited design, including environments, required design margins, and life

Flight history of the products and specific attributes for each flight, including environments

(compare previous environment to current, including duty cycle and general concept of operations)

Ground and on-orbit anomaly and failure history including the determination of root causes or information that root cause was not determined. Ground anomalies may be restricted to major anomalies, where component performance requirements were violated

5 Reliability analyses performed for the most recent version of the product

Identification of significant changes in manufacturing from qualified product to current product

(facility, process, sub-tier supplier, testing changes, company change of ownership, etc.), and any changes in design or materials, including electronic parts, printed circuit boards, and standards used

(changing from an older revision of a standard to the latest revision need not be discussed).

Table 2. Inherited Product Supplementary Information

No. Supplement Information for Inherited Product

Deviations of each product from original design (white wires, cut traces, splices, etc., if not objectively clear to be part of the design) and reasons for each deviation. If the design has been qualified on a previous GSFC project in the same environment and same risk posture, then the deviations may be declared relative to the previously qualified design.

Specifications and/or standards used to develop the products (e.g., IPC, J-STD, NASA, or GSFC requirements, including fastener integrity approach, or company standards). For products with minimal prior flight history, company standards or detailed synopses of such should be provided, if such are used to develop the product

Previous as-built parts list, including lot date codes, and the differences for new inherited item.

This should include evidence that Government Industry Data Exchange Program (GIDEP) alerts and advisories have been properly dispositioned, if the parts have already been procured. Note that GIDEP should always be used as an aid in procuring new parts or pulling parts from inventory. Reference to prior project deliveries to GSFC is acceptable, in which case, an amendment may be delivered to indicate any changes

Known obsolete parts that will be supplied from existing inventory, including the quantity required and the quantity available. If available, include the sparing plan (quantity required, quantity available, and sparing philosophy)

Materials list and approved Material Usage Agreements (MUAs). Materials list includes lot date codes and evidence that GIDEP alerts and advisories have been properly dispositioned, if the materials have already been procured. Such evidence should be encompassed in GIDEP closure records for each of the items that have impacts. Reference to prior project deliveries to GSFC is acceptable, in which case, an amendment may be delivered to indicate any changes

6 List of major electrical and mechanical analyses completed and summary of results

Traceability: GPR 8730.5: Safety and Mission Assurance of Inherited and Build-to-Print

Products.

3.8 Government Mandatory Inspection Points (GMIPS)

The developer/sub-tier supplier shall plan for GMIPS that will require government oversight and inspection of specified activities. The developer shall provide work instructions, procedures, and drawings, etc. that are appropriate for the activities. The following are examples of activities that may be subject to GMIPS:

- Circuit card assemblies

- Final solder inspection before conformal coating and staking

- Post conformal coating, potting and staking

- Pre-closure of boxes

- Optical inspections and test evaluation witnessing

- Harness – pre integration (pre staking or potting)

- Unit/component, subsystem level assembly – witness final assembly

- Mechanical – final assembly and acceptance test

- Software acceptance test

- Rework and repairs to flight hardware

- Test – TBD (addressed at time of contract), for example alignment, performance acceptance and environmental test

- Document Configuration Control

- Nonconformance Processing

This list is for planning purposes. Items may be added or deleted based on the specifics of the development effort. Proper identification and coordination of these activities will help ensure there is no work delay or schedule impact from the completion of the GMIP. The developer shall give the Government 24 hours notice prior to an GMIP for any planned inspections.

Traceability: GPR 5100.1 Procurement, paragraph 1.1g; Part 46 Federal Acquisition

Regulations, paragraphs Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5

4 QUALITY MANAGEMENT SYSTEM

4.1 General

All developers for the WFIRST shall have a quality management system that meets the intent of

SAE AS9100 Quality Systems - Aerospace - Model for Quality Assurance in Design, Development, Production, Installation and Servicing or an ISO 9001 Quality Management

System, or equivalent that encompasses all flight hardware, software, and GSE. The developer’s management structure will ensure that managers of the assurance activities have direct access and independent reporting paths to upper management, separate from the project management structure. The developer’s management structure will provide the assurance managers with the functional freedom and authority to interact with all elements of the project regarding flight assurance issues and concerns.

Traceability: GPR 1280.1 The GSFC Quality Manual P.2; NPD 8730.5 NASA Quality

Assurance Program Policy, Attachment A, paragraph 2.a

4.2 Nonconforming Material

4.2.1 Control of Nonconforming Product

The developer shall have a documented closed loop system per DID 4-1, for identifying, reporting, and correcting product nonconformance. The system shall ensure that the adequacy of corrective action is determined by audit or test, that objective evidence is collected, and that preventive action is implemented to preclude recurrence. The Material and Anomaly Review

Boards shall include a government representative who will be a voting member on all major

Nonconformances involving procured hardware and government risk assessment consultants.

The government representative shall be supplied with the applicable documentation within 24 hours of the scheduled Review Board. The developer shall inform the government of Review

Board actions (DID 4-2).

The developer shall grant electronic access to the government representatives in order to review nonconforming reports and documentation related to material/failure review boards.

Traceability: GPR 5340.4 Problem Reporting and Problem Failure Reporting, paragraph 1.b;

NPD 8705.4 Risk Classification for NASA Payloads, Appendix A

4.2.2 Material Review Board (MRB)

The developer shall have a documented process for the establishment and operation of a MRB to process nonconformances, including the definitions of major and minor nonconformances (DID

3-1).

Major nonconformances are those that affect form, fit or function, critical path schedule, cost, performance or interfaces, safety, reliability or contract requirements. Minor nonconformances are those that can be corrected without affecting critical factors.

The developer shall appoint a MRB chairperson who is responsible for implementing the MRB process, and functional and project representatives as MRB members.

The MRB shall use the following disposition actions:

- Scrap — the product is not usable

- Re-work — the product will be re-worked to conform to requirements

- Return to supplier — the product will be returned to the supplier

- Repair — the product will be repaired using a repair process approved by the MRB

- Use-As-Is — the product will be used as-is. A waiver request may be required.

NPD 8730.5 NASA Quality Assurance Program Policy, paragraphs 1.b(8)(a) and 1.b(8)(b)

4.2.3 Anomaly Reporting and Disposition

The developer shall have a documented process for anomaly reporting and disposition. The process will establish an Anomaly Review Board (ARB) whose membership will include the

CSO as a voting member with approval authority for proposed actions on all major nonconformances and government risk assessment consultants to help with risk and root cause identification. All major safety incidents, nonconformances or anomalies shall be reported to the

CSO immediately and followed up with a written report within 24 hours of the occurance.

The process shall require major anomalies to be submitted to the ARB and the government (DID

4-1). The developer shall report major hardware anomalies beginning with the first application of power at the component level, major software anomalies beginning with flight software acceptance testing and when interfacing with flight hardware, and major mechanical system anomalies beginning with the first operation. Major anomalies are those that have resulted in hardware or software test failures and damage or potential damage to hardware. Examples of major anomalies are overvoltage or over current conditions, exceedance of test limits resulting in overstress, blown fuses, and unexpected system responses. The developer shall assess the failure risk ratings and failure effect risk ratings for major anomalies (see DID 4-1 for criteria) and shall identify those that have a failure effect risk rating of 2 or 3 and a failure corrective action risk rating of 3 or 4 as a significant residual risk in the risk list.

The process shall allow the developer to disposition minor anomalies with an appropriate subset of the ARB. Minor anomalies are those that have not resulted in hardware failure or have caused no damage or stress to hardware or required no change in flight software. Examples of minor anomalies are those that can be resolved immediately, procedural errors, database problems, operator errors, and exceedance of test limits that do not affect the end item.

Note: A component is defined as a functional subdivision of a subsystem and generally as a self-contained combination of items performing a function necessary for the subsystem’s operation.

NASA is adverse to “Could Not Duplicate” failures, and as such, must be discussed with the formal anomaly or nonconformance review board for approval and disposition.

NASA-HDBK-8739.18 Procedural Handbook for NASA Program and Project Management of

Problems, Nonconformances, and Anomalies, paragraph 4.

5 SYSTEM SAFETY

5.1 General

The developer shall document and implement a system safety program, support the ELV Safety

Review Process as defined in paragraphs 2.4 of NPR 8715.7 Expendable Launch Vehicle

Payload Safety Program, comply with launch service provider requirements and comply with launch range safety requirements.

The developer and supplier teams will provide applicable inputs to the Project Safety Manager for inclusion into the following project level Safety deliverables.

The safety program shall satisfy the applicable guidelines, constraints, and requirements stated in

NASA-STD-8719.24 (with Annex), NASA Expendable Launch Vehicle Payload Safety

Requirements. Specific safety requirements include the following:

- The developer shall incorporate three independent inhibits in the design (dual failure tolerant) if a system failure may lead to a catastrophic hazard. A catastrophic hazard prelaunch is defined as a payload-related hazard, condition, or event occurring prior to launch (on ground) that could result in a mishap causing fatal injury to personnel or loss of spacecraft, launch vehicle, or ground facility. A catastrophic hazard post-launch is defined as a payload-related hazard, condition or event occurring post-launch (airborne) through payload separation that could result in a mishap causing fatal injury (including fatal injuries to the public) or loss of flight termination system.

- The developer shall incorporate two independent inhibits in the design (single failure tolerant) if a system failure may lead to a critical hazard. A critical hazard is defined as a hazard, condition or event that may cause a severe injury or occupational illness, or major property damage to facilities, systems, or flight hardware.

- The developer shall adhere to specific detailed safety requirements, including compliance verification that must be met for design elements with hazards that cannot be controlled by failure tolerance. The process by which safety is incorporated into these design elements (e.g., structures and pressure vessels) is called "Design for

Minimum Risk".

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, Volume

3, paragraphs 2.4 and 3.2 and Volume 7 (definitions)

5.2 Mission Related Safety Requirements Documentation

The developer shall implement launch range safety requirements as applicable for the specific launch site. The most stringent applicable safety requirement shall take precedence in the event of conflicting requirements.

- NASA-STD 8719.24 (with Annex) NASA Expendable Launch Vehicle Payload

Safety Requirements

- KNPR 8715.3 KSC Safety Practices Procedural Requirements (applicable at KSC property, KSC-controlled property, and offsite facility areas where KSC has operational responsibility)

- NPR 8715.7 Expendable Launch Vehicle Payload Safety Program

- Launch Site Facility-specific Safety Requirements, as applicable (e.g., Astrotech)

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraph 1.2a-c

5.3 System Safety Deliverables

5.3.1 System Safety Program Plan

The developer shall prepare inputs to the Project for a System Safety Program Plan (SSPP) that describes the tasks and activities of system safety management and engineering required to identify, evaluate, and eliminate or control hazards to the hardware, software, and system design by reducing the associated risk to an acceptable level throughout the system life cycle, including launch range safety requirements. (DID 5-1).

paragraphs 2.4.2a(2), 2.4.2b(2)I, and 2.5.4

5.3.2 Safety Requirements Compliance Checklist

The developer shall document and implement a Safety Requirements Compliance Checklist to demonstrate that the payload is in compliance with NASA and range safety requirements (DID

5-2).

The developer shall document non-compliances to safety requirements in waivers per section

5.3.7 of this document.

paragraphs 2.4.2a(2), 2.4.2b(2)I and 2.5.4

5.3.3 Hazard Analyses

Traceability: NASA-STD-8719.24 NASA Expendable Launch Vehicle Payload Safety

Requirements, Volume 1, paragraph A2.2.3

5.3.3.1 Preliminary Hazard Analysis

The developer shall perform a Preliminary Hazard Analysis (PHA) to obtain an initial risk assessment and to identify safety critical areas of a concept or system. The developer will base the PHA on the best available data, including mishap data from similar systems and other lessons learned.

The developer shall evaluate hazards associated with the proposed design or function for severity, control approach (fault tolerance or design for minimum risk), and operational constraints. The developer shall identify safety provisions and alternatives that are needed to eliminate hazards or reduce their associated risk to an acceptable level.

The developer shall deliver the PHA with Safety Data Package (SDP) I (DID 5-4) to the Project

Office for review.

paragraphs 1.3.6b, 2.3.1c, & 2.4.2b(2)

5.3.3.2 Operations Hazard Analysis (OHA) and Hazard Verification Tracking Log (VTL)

The developer shall perform and document an Operations Hazard Analysis (OHA) and a Hazard

Verification Tracking Log (VTL) to demonstrate that hardware operations, test equipment operations, and integration and test (I&T) activities comply with facility safety requirements and that hazards associated with those activities are mitigated to an acceptable level of risk (DID 5-

3).

The developer shall update and maintain the Hazard Verification Tracking Log during I&T activities to track open issues.

paragraphs 1.3.6b, 2.3.1c & 2.3.1t

5.3.3.3 Lifting Device Safety Requirements

The developer shall implement the following safety requirements for lifting devices and equipment when performing NASA work at non-NASA facilities:

- Ensure that for critical lifts overhead cranes, winches, and hoists have dual holding brakes and dual upper limit switches installed as defined in NASA Standard 8719.9A

Lifting Standard, paragraphs 5.4.1 and 5.4.2 respectively. A single holding brake in combination with a motor drive that automatically tests the holding ability of the brake prior to every release of the brake is acceptable as a second brake as long as the crane has a notification device to alert operator of failure of the braking system.

- Perform periodic load testing in accordance with paragraph 4.5 of NASA-STD-

8719.9A for the following lifting devices and equipment: overhead cranes; mobile cranes and derricks; hooks hydra-sets and load measuring devices; and slings and riggings.

- After the initial proof test of the lifting device or equipment (LDE), a load test of the rated safe working load (SWL) LDE shall be performed every four years. Proof tests will be 125% of the SWL for Lifting Devices, such as overhead and mobile cranes and include aerial platforms used near critical hardware. Proof tests will be at 200% of the SWL for Lifting Equipment, such as shackles, turnbuckles and so forth. A load test will be at 100% of the labelled SWL for all LDE. If the LDE is de-rated to a lower SWL because of a lower proof or load test, the LDE shall be labelled as this new SWL and only be used to the maximum capacity as such.

- Perform NDT inspections using an American Society of Non-destructive Testing

(ASNT) or equivalently trained inspector on critical lifting hardware equipment on critical welds (weld failure would result in failure of hardware) after initial proof test and load testing.

- Label and tag lifting devices and equipment per NASA-STD-8719.9A paragraphs 4.9 or other acceptable means.

Traceability: NASA-STD 8719.9 Lifting Standard

5.3.3.4 Operating and Support Hazard Analysis

The developer shall perform an Operating and Support Hazard Analysis (O&SHA) to evaluate activities for hazards introduced during testing, transportation, storage, integration, and prelaunch operations at the launch site. The primary purpose is to evaluate the adequacy of procedures used to eliminate, control, or mitigate identified hazards so as to ensure implementation of safety requirements for personnel, procedures, and equipment during activities at the launch site.

The developer shall submit the results of the O&SHA as a part of the Safety Data Packages SDP

II and SDP III (DID 5-4).

Requirements, Volume 3: 2.2.3, 4.2, and Attachment 1

5.3.4 Safety Data Package (SDP)

The developer shall prepare an integrated SDP that documents the results of hazard analyses that identify prelaunch, launch, and ascent hazards which are associated with the flight system, ground support equipment, and their interfaces that were identified in hazard reports (DID 5-4).

This applies only to the spacecraft developer.

The Instrument developer shall generate an Instrument Safety Assessment Report (ISAR) to document the comprehensive evaluation of the risk being assumed prior to the testing or operation of an instrument. The spacecraft developer will use the ISAR (DID 5-4a) as an input to the Safety Data Package (SDP).

Requirements, Volume 1, Attachment 1

5.3.5 Verification Tracking Log (VTL)

The developer shall document and implement a VTL that documents a Hazard Control and

Verification Tracking process as a closed-loop system that ensures safety compliance has been satisfied per applicable launch range safety requirements.

The developer shall document in the VTL the process of verifying the control of hazards by test, analysis, inspection, similarity to previously qualified hardware, or any combination of these activities.

The developer shall ensure that verifications listed on the hazard reports refer to specific test, analysis, or inspection reports with a summary of the pertinent results.

The developer shall make the results of these tests, analyses, and inspections available for government review.

The developer shall identify in the VTL hazard controls that are not verified as closed and shall submit the VTL as part of ISAR III (DID 5-4a) or SDP III (DID 5-4).

The developer shall provide regular electronic updates of the VTL until all hazard controls are verified as closed.

paragraph 2.2.3d

5.3.6 Hazardous Procedures for Payload I&T and Pre-launch Processing

The developer shall provide inputs for the Project to document and implement hazardous procedures that comply with applicable facility safety requirements when performing integration and test activities and pre-launch activities at the launch site (DID 5-5).

The developer shall provide safety support for hazardous operations at the launch site.

paragraph 2.2.3f

5.3.7 Safety Waivers

The developer shall request waivers for variations from the applicable safety requirements per paragraph 1.4 of NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program. The waiver form is available at URL http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html paragraph 1.4

5.3.8 Orbital Debris Assessment Report (ODAR) and End of Mission Plan (EOMP)

The developer shall provide the inputs necessary for the development of the ODAR and the

EOMP per the content defined in NASA-STD 8719.14, (DID 5-6).

Traceability: NASA-STD-8719.14 Process for Limiting Orbital Debris, Appendices A and B http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html

5.3.9 Mishap Reporting and Investigation

The developer shall prepare a Pre-Mishap Plan that describes appropriate mishap and close call notification, reporting, recording, and investigation procedures in accordance with NPR 8621.1

NASA Procedural Requirements for Mishap and Close Call Reporting, Investigating, and

Recordkeeping.

The developer shall direct the suspension of any work activity that presents a hazard, imminent danger, or future hazard to personnel, property, or mission operations resulting from unsafe acts or conditions that are identified by inspection, test, or analysis.

The developer shall report accidents, test failures, or other mishaps and close calls promptly to

NASA.

The developer shall promptly investigate so as to determine the root cause.

Traceability: GPR 8621.4 GSFC Mishap Preparedness and Contingency Plan, paragraph 1.9;

NPR 8621.1 NASA Procedural Requirements for Mishap and Close Call Reporting, Investigating, and Recordkeeping

5.3.10 NASA Expendable Launch Vehicle (ELV) Payload Safety Program Forms

The developer shall prepare NASA Expendable Launch Vehicle Payload Safety Forms. The forms are available at URL http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html.

Traceability: Required by Range http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html.

6 RELIABILITY

6.1 Reliability Requirements

All NASA Centers and their support contractors support a reliability and Risk Assessment (RA) program, applicable to all system elements, which shall be implemented as specified herein and as referenced in NPR 8705.4 for Risk Classification for NASA Payloads, “Class A”, requirements and NPR 8705.5 for Technical Probabilistic Risk Assessment (PRA) Procedures for Safety and Mission Success for NASA Programs and Project requirements to ensure that:

a. Probability Risk Assessment (PRA) is used to assess, manage, and quantitatively assess the need to reduce program technical risks;

b. Assure that the specified reliability (probability of success) is achieved;

c. Demonstrate that redundant functions, including alternative paths and work-a-rounds, are independent to the extent practicable;

d. Demonstrate that the stress applied to parts are not excessive and meet applicable derating criteria;

e. Identify single failure points , their effect on the attainment of mission objectives, and possible safety degradation;

f. Identify limited-life items and ensure that special precautions are taken to conserve their useful life for on-orbit operations as needed to meet mission requirements;

g. Demonstrate that the performance margins for electrical/electronic circuits are shown to be commensurate with mission lifetime requirements under worst case conditions;

h. Ensure that the reliability design aligns with mission design life and is consistent among the systems, subsystems, and components;

i. Perform trend analysis on the significant engineering parameters during fabrication and pre-launch I&T activities to identify/monitor performance trends;

j. Ensure that the design permits easy replacement of parts and components during ground testing, and that redundant paths are easily monitored.

The developer will provide technical support to the WFIRST Project for the NASA-chaired

Reliability Working Group (RWG) meeting and technical reviews, as required. The RWG will meet as necessary, and as convened by NASA, to review reliability and Risk Assessment requirements and analyses, to assist in resolving reliability issues and concerns, and to discuss any situations that may arise with respect to the overall mission reliability.

Developer shall formally report on the progress of their reliability efforts through the project status reports and management meetings, and provide real-time progress reports to the GSFC

WFIRST Reliability Engineering through informal communications such as teleconferences and e-mails.

Traceability: NPR 8705.4 Safety and Mission Success for NASA Programs and Projects

6.2 Reliability Program Plan (RPP)

The developer shall document and implement an RPP using both qualitative and quantitative techniques in accordance with the requirements of NPR 8705.4 for a Class A mission.

Support rationale and decisions regarding mission success and safety throughout system development shall be documented in (DID 6-1). The RPP shall include a detailed approach to the analysis of hardware and software for their contributions to system reliability and mission success. The approach includes in the design process and implementing throughout the system development life cycle that interacts effectively with other disciplines, extending system engineering, risk management, hardware design, software design, and product assurance.

present the implementation of these plans and related activities at milestone reviews beginning with the System Requirements Review (DID 6-1).

6.3 Probabilistic Risk Assessment

GSFC Reliabilty Program Plan, WFIRST-PLAN-08011, will adjudicate PRA needs.

6.4 Software Reliability Analysis

The developer shall perform qualitative software reliability analysis for software identified as mission-critical in the FMECA (Section 6.5) and FTA (Section 6.6) . The developer shall provide software metrics and update FMECA and FTA deliverables described in Section 6.5 and

6.6. Metrics will include defect reports and test coverage report (number of tests planned vs.

completed).

The developer will make software problem reports, including analysis and disposition, available to the Government for review electronically.

6.5 FMEA/FMECA and Critical Items List (CIL)

The developer shall perform a FMEA (GSFC-FAP-322-208), that addresses flight hardware and software that is designed, built, or provided by their organization or subcontractors, from project initiation through launch and mission operations, and includes likelihood, cause, detection/ mitigation, and, effects of each interface and box/functional element failure mode at the local, subsystem, and system/mission levels as well as FMECA scores per Table 4 and

Table 5. As a result a CIL shall be prepared and maintained for severity categories 1, 1R, 1S, and

2, per Table 3 (DID 6-2). The developer shall identify and analyze single point failure modes resulting in severity categories 1, 1R, 1S, or 2 to determine the root cause, corresponding mitigation actions, and retention rationale.