Attachment D MAR Rev C.pdf

Effective Date: August 8, 2020 Expiration Date: July 27, 2025

CHECK https://ipdtdms.gsfc.nasa.gov

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

National Aeronautics and Space Administration

Goddard Space Flight Center Greenbelt, Maryland

RST-SMA-REQ-0032, Revision C

Roman Space Telescope (RST) Code 448

Attachment D, Mission Assurance Requirements (MAR)

Mission Risk Classification: NPR 8705.4 Class A

GSFC RST CMO

August 8, 2020

Released https://ipdtdms.gsfc.nasa.gov/

RST MAR RST- SMA-REQ-0032, Revision C

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://ipdtdms.gsfc.nasa.gov iii

Preface This document is a Roman Space Telescope (RST) Configuration Management (CM)-controlled document.

Note: Prior to May 20, 2020, the project name was Wide Field Infrared Survey Telescope

(WFIRST).

For the purposes of configuration management, the prefixes “WFIRST” and “RST” are completely interchangeable. For example, RST-MGMT-PROC-0024 is the same as WFIRST-

MGMT-PROC-0024.

Changes to this document require prior approval of the applicable Configuration Control Board (CCB) Chairperson or designee. Proposed changes shall be submitted to the RST 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:

RST Configuration Management Office Mail Stop 448 Goddard Space Flight Center Greenbelt, Maryland 20771 iv

Change History Log

Revision Effective Date Description of Changes

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

Revision - April 12, 2017 Initial Release of document per RST-CIR-01958 Revision A February 23, Class A Upgrades per RST-CCR-05371

Revision B June 28, 2019 Updated document per RST-CCR-0015 Requirement identification numbers assigned to each of the “shall” statements in the main body of the document; added “Waivers and Deviations” subsection; added DID 3-2 for the “Inherited Items Package” requirement included in subsection 3.7 in the previous versions of the MAR; combined “Material Review Board (MRB)” subsection with “Anomaly Reporting and Disposition” subsection;

modified Table 4, Likelihood Rankings; deleted Table 5, RPN Scores; deleted duplicate “suspension of work activities” requirement from subsection 5.3.9; changed Windchill document numbers to TDMS document numbers; editorial changes and corrections

Revision B w/deviation_waiver

June 28, 2019 Per Deviation/Waiver (DW) 0019 added a Deviation/Waiver Table

Revision C July 27, 2020 Per CCR-0257 Change all references FROM:

WFIRST TO: RST and Change all references FROM: Wide Field Infrared Survey Telescope TO:

Roman Space Telescope v

Deviation/Waiver Table

DW

No.

Date Approved Description of Waiver Approved by

Requirement Deviated/ Waived

DW-

May 4, 2020 and June 17, 2020

Allow the use of this material which may have been subject to a GIDEP Alert after the heritage hardware was built.

See attached Technote for justification, it was determined by the WFIRST SMSS Design team that the loads used in the Sister Program analysis envelop the WFIRST loads.

D. Content and M. Samuel

NA

vi vii

Table of TBDs/TBRs/TBSs

Item No. Location Summary Individual/ Organization

Actionee

Due Date viii

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.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)

3.9 Waivers and Deviations

4 QUALITY MANAGEMENT SYSTEM

4.1 General

4.2 Nonconforming Material

4.2.1 Control of Nonconforming Product

4.2.2 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

6.2 Reliability Program Plan (RPP)

6.3 Probabilistic Risk Assessment

6.4 Software Reliability Analysis

6.5 FMECA and Critical Items List (CIL)

ix

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

11.3 Materials Identification and Usage List (MIUL)

11.4 Life Test for Lubricated Mechanisms

12 CONTAMINATION CONTROL

12.1 Contamination Control Plan

x

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. ACRONYMS

List of Tables Table 1: Inherited Product Data Requirements Table 2: Inherited Product Supplementary Information Table 3: Severity Categories Table 4: Technical Likelihood Criteria

1 INTRODUCTION

1.1 Purpose

The purpose of this document is to establish the Safety and Mission Assurance (SMA) guidelines and requirements for the Roman Space Telescope (RST) 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 RST as a Class A mission through the direction of the Program-Level Requirements Appendix (PLRA, RST-MGMT-REQ-0044), with the exception that a protoflight development approach will be followed, flight sparing will be at a combination of assembly and sub-assembly levels, and a combination of Level 1 and 2 parts will be allowed.

Refer to the RST Project Tailored Class A Approach presentation (RST-REF-15949) for further details.

Therefore, the RST 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 RST project. This includes, but is not limited to, flight hardware (spacecraft, telescope and instruments), ground support equipment that interface 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, unless otherwise specified within this document. 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. RST documents can be obtained from https://ipdtdms.gsfc.nasa.gov.

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 RST Project Configuration Change Board has the final authority for conflict resolution.

Document Number Title Section/DID 500-PG-8700-2.7 Design of Space Flight Field Programmable Gate Arrays 8.2 541-PG-8072.1.2C 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

NPR 2810.1 Security of Information 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- 6018 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 (FOD) Prevention Guidance Document

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-5017A Design and Development Requirements for Mechanisms

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-6016A

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-

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

RST-SMA-PLAN-0038 RST System Safety Program Plan 5.1, 5.3.1, DID 5-1

RST-SMA-PLAN-0044 RST Project Surveillance Plan 3.6

RST-SYS-ANYS-0031 Radiation Environment for the Roman Space Telescope (RST) 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.

RST-MGMT-REQ-0044 Program-Level Requirements Appendix (PLRA) 1.1 RST-REF-15949 RST Project Tailored Class A Approach 1.1 RST-SMA-LIST-0027 RST Mission Assurance Requirements (MAR) Applicability

Matrix 3.1

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 ISO 146441-1 Cleanrooms and Associated Controlled Environments –

Classification of Air Cleanliness

DID 12-1

NASA/CR-2005-213424 Lubrication for Space Applications DID 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)

DID 11-4

RST-SYS-PLAN-0051 RST Contamination and Control Plan DID 12-1

RST-SMA-PLAN-0040 RST Reliability Program Plan 6.2

3 GENERAL

3.1 System Safety and Mission Assurance Program

MAR-001 The developer shall implement a safety and mission assurance program that is consistent with the requirements in this MAR as implemented through the RST Specific Quality Assurance Plan and Requirements Compliance Matrix (DID 3-1).

MAR-002 The mission assurance program shall cover:

• 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.

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

NOTE: The Ground MAR, RST-SMA-REQ-0021, defines the 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.

MAR-003 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.

MAR-004 The MAIP or Quality 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 (DID 3-1).

The RST MAR Applicability Matrix (RST-SMA-LIST-0027) provides guidance on which of the MAR requirements apply to the Observatory subsystems that are developed or managed in-house by the Goddard Space Flight Center (GSFC).

Traceability: GPR 1280.1 GSFC Management System Manual, P.2; NPD 1280.1 5.c

3.2 Management

MAR-005 The developer shall designate an Assurance Manager who is independent and responsible as a single point of contact for all Safety and Mission Assurance activities.

MAR-006 The Assurance Manager shall not be responsible for project costs and schedules, other than those pertaining to assurance activities.

MAR-007 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

MAR-008 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

MAR-009 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.

MAR-010 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.

MAR-011 The developer shall provide key sub-tier component suppliers’ MAIP/Compliance Matrix response to the government.

Traceability: GPR 1280.1 GSFC Management System Manual, paragraph 1.1

3.5 Data Item Descriptions (DID)

MAR-012 The developer shall deliver data items per the requirements of the applicable DIDs. 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).

MAR-013 The developer shall submit the CDRLs in accordance with the following definitions:

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

- 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.

- 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

MAR-014 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 contract-specific Quality Assurance Surveillance Plans and the RST Project Surveillance Plan.

MAR-015 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.

MAR-016 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. Use of this process does not relieve the developer from meeting contractual performance and functional requirements. The government will determine if the risks are acceptable or if mitigations are required.

MAR-017 The developer shall assume ownership and responsibility for risk mitigations associated with the use of inherited products.

MAR-018 The developer shall provide the data specified in Table 1: Inherited Product Data Requirements to substantiate the product’s baseline and risk of use in the Inherited Items Package (DID 3- 2). The developer may provide additional available information from Table 2 to further evaluate the risk.

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

Table 1: Inherited Product Data Requirements

No. Data Needed for Inherited Products

1 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

No. Supplement Information for Inherited Product 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)

MAR-020 The developer/sub-tier supplier shall plan for GMIPs that will require government oversight and inspection of specified activities.

MAR-021 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 – addressed at time of contract (e.g., alignment, performance acceptance and environmental test);

- Document Configuration Control;

- Nonconformance processing, etc.

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.

MAR-022 The developer shall give the Government 24 hours notice (minimum) prior to a 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

3.9 Waivers and Deviations

A Deviation is a specific written authorization, granted prior to the manufacture or testing of an item, to depart from a particular performance or design requirement specified in a project controlled drawing.

A Waiver is a specific written authorization, granted after the manufacture or testing of an item, to depart from a particular performance or design requirement of a specification or other project controlled document, but is considered suitable for use “as is”.

Traceability: RST-MGMT-PROC-0024 RST Project Configuration Management Procedure

4 QUALITY MANAGEMENT SYSTEM

4.1 General

MAR-023 All developers for the RST shall have a quality management system that meets the intent of SAE AS9100 Quality Management Systems - Requirements for Aviation, Space, and Defense Organizations 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 GSFC Management System 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

MAR-024 The developer shall have a documented closed loop system per DID 4-1, for identifying, reporting, and correcting product nonconformances.

MAR-025 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.

MAR-026 The Anomaly Review Boards (ARBs) shall include the Chief Safety and Mission Assurance Officer (CSO) or delegate and other government representatives who will be voting members on all major nonconformances involving procured hardware. ARBs include Material Review Boards (MRBs) and Failure Review Boards (FRBs).

MAR-027 The government representatives shall be supplied with the applicable documentation within 24 hours of the scheduled ARB.

MAR-028 The developer shall inform the government of Review Board actions (DID 4-2).

MAR-029 The developer shall grant electronic access to the government representatives in order to review nonconforming reports and documentation related to the ARBs.

MAR-030 The developer shall have a documented process for the establishment and operation of an ARB to process nonconformances, including the definitions of major and minor nonconformances (DID 3-1).

Major nonconformances (Class I) are those that affect form, fit or function, critical path schedule, cost, performance or interfaces, safety, reliability or contract requirements.

Minor nonconformances (Class II) are those that can be corrected without affecting critical factors.

A preliminary review of a nonconformance may be conducted as an initial step by the developer-appointed personnel to determine if the nonconformance is minor and can readily be processed using the following disposition actions, such that the product will fulfill the specified requirements: scrap, rework, or return to supplier. A preliminary review does not negate the requirement to identify, segregate, document, report, and disposition nonconformances.

MAR-031 The developer shall appoint an ARB chairperson who is responsible for implementing the ARB process, and functional and project representatives as ARB members.

MAR-032 The ARB shall use the following disposition actions:

- Scrap – the product is not usable for the intended purposes and cannot be economically reworked or repaired;

- Rework – the product will be reworked to conform to requirements;

- Return to supplier – the product will be returned to the supplier for rework or replacement;

- Repair – the product will be repaired using a repair process approved by the ARB and/or government Quality Assurance organization; or

- Use-As-Is – the product will be used as-is; a waiver request may be required.

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

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

NPR 8705.4 Risk Classification for NASA Payloads, Appendix A

4.2.2 Anomaly Reporting and Disposition

MAR-033 All major safety incidents and nonconformances shall be reported to the CSO immediately and followed up with a written report within 24 hours of the occurrence.

MAR-034 The process shall require major nonconformances to be submitted to the ARB and the government (DID 4-1).

MAR-035 The developer shall report major hardware nonconformances beginning with the first application of power at the component level, major software nonconformances beginning with flight software acceptance testing and when interfacing with flight hardware, and major mechanical system nonconformances beginning with the first operation.

Examples of major nonconformances are those that have resulted in hardware or software test failures and damage or potential damage to hardware, such as overvoltage or overcurrent conditions, exceedance of test limits resulting in overstress, blown fuses, and unexpected system responses.

MAR-036 The developer shall assess the failure risk ratings and failure effect risk ratings for major anomalies (see DID 4-1 for criteria) and will 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.

MAR-037 The process shall allow the developer to disposition minor nonconformances with an appropriate subset of the ARB.

Examples of minor nonconformances 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, such as 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.

“Could Not Duplicate” or “Un-Verified” Failures (UVFs) must be discussed with the ARB for approval and disposition, and documented in the risk list.

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

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

MAR-038 The developer shall document and implement a system safety program, support the Expendable Launch Vehicle (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.

MAR-039 The developer and supplier teams shall provide applicable inputs to the Project Safety Manager for inclusion into the project level Safety deliverables.

MAR-040 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.

MAR-041 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 pre-launch 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.

MAR-042 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.

MAR-043 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

MAR-044 The developer shall implement launch range safety requirements as applicable for the specific launch site.

MAR-045 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

MAR-046 The developer shall prepare or provide 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).

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraphs 2.4.2a(2), 2.4.2b(2)I, and 2.5.4

5.3.2 Safety Requirements Compliance Checklist

MAR-047 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).

MAR-048 The developer shall document non-compliances to safety requirements in waivers per section 5.3.7 of this document.

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraphs 2.4.2a(2), 2.4.2b(2)I and 2.5.4

5.3.3 Hazard Analyses

5.3.3.1 Preliminary Hazard Analysis

MAR-049 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.

MAR-050 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.

MAR-051 The developer shall identify safety provisions and alternatives that are needed to eliminate hazards or reduce their associated risk to an acceptable level.

MAR-052 The developer shall deliver the PHA with Safety Data Package (SDP) I (DID 5-4) to the Project Office for review.

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, 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)

MAR-053 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).

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

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraphs 1.3.6b, 2.3.1c & 2.3.1t

5.3.3.3 Lifting Device Safety Requirements

MAR-055 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.9 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.9 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 will 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 will 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.9 paragraphs 4.9 or other acceptable means.

Traceability: NASA-STD 8719.9 Lifting Standard

5.3.3.4 Operating and Support Hazard Analysis

MAR-056 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 of the O&SHA 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.

MAR-057 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).

Traceability: NASA-STD-8719.24 NASA Expendable Launch Vehicle Payload Safety Requirements, Volume 3: 2.2.3, 4.2, and Attachment 1

5.3.4 Safety Data Package (SDP)

MAR-058 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.

MAR-059 The Instrument developer shall generate an Instrument Safety Assessment Report (ISAR) (DID 5-4a) 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).

Traceability: NASA-STD-8719.24 NASA Expendable Launch Vehicle Payload Safety Requirements, Volume 1, Attachment 1

5.3.5 Verification Tracking Log (VTL)

MAR-060 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.

MAR-061 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.

MAR-062 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.

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

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

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

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraph 2.2.3d

5.3.6 Hazardous Procedures for Payload I&T and Pre-launch Processing MAR-066 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).

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

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraph 2.2.3f

5.3.7 Safety Waivers

MAR-068 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

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

5.3.8 Orbital Debris Assessment Report (ODAR) and End of Mission Plan (EOMP) MAR-069 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

5.3.9 Mishap Reporting and Investigation

MAR-070 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.

MAR-071 The developer shall report accidents, test failures, or other mishaps and close calls promptly to NASA.

MAR-072 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 MAR-073 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 https://ipdtdms.gsfc.nasa.gov/ http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html.

http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html.

6 RELIABILITY

6.1 Reliability Requirements

MAR-074 The developer shall implement a Reliability and Risk Assessment Program as specified herein and as referenced in NPR 8705.4, 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 via analysis that redundant functions, including alternative paths and work-a-rounds, are independent to the extent practicable;

d. Demonstrate via analysis 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 via analysis 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/critical performance parameters during fabrication and pre-launch I&T activities to…