470-00436 SMBA IMAR_RFI Release_V0.pdf

470-MWS-00436 Effective Date: October 14, 2022

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

470-MWS-00436

Revision RFI DRAFT

Sounder for Microwave Brightness and

Analysis (SMBA) Instrument

Instrument Mission Assurance Requirements

(IMAR)

Goddard Space Flight Center

Greenbelt, Maryland

JPSS Reviewed – Not Subject to Export Control

SMBA IMAR 470-MWS-00435, RFI Release Draft Effective Date: October 14, 2022 ii

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Sounder for Microwave Brightness and Analysis Instrument

Instrument Mission Assurance Requirements

(IMAR)

Review/Signature/Approval Page

Prepared By:

Brooke Greybeck

Instrument Chief Safety Office (CSO)

NASA GSFC LEO Programs Division Code 470

Reviewed By:

Dave Bogart

Instrument Chief Safety Office (CSO)

Approved By:

Jessica Knizhnik

SMBA Instrument Manager

*** Signatures are available on-line at: https://......... *** iii

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Goddard Space Flight Center

Greenbelt, Maryland iv

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Preface

This document is under LEOS Sounder Project configuration control. Once this document is approved, LEOS Sounder Project approved changes are handled in accordance with Class I and

Class II change control requirements as described in the LEOS Program Configuration

Management Procedures, and changes to this document shall be made by complete revision.

Any questions should be addressed to:

LEOS Program Configuration Management Office

NASA/GSFC

Code 470

Greenbelt, MD 20771 v

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Change History Log vi

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Deviations/Waivers Record

Section # /

Requireme nt

Deviation /

Waiver #

CCR # Date

Approved

Title Mission vii

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Table of TBDs/TBRs

Item No. Location Summary Individual/

Organization Due

Date viii

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

TABLE OF CONTENTS

DOCUMENT ORGANIZATION AND CONVENTIONS

1.1 Systems Safety and Mission Assurance Program

1.2 Management

1.3 Requirements Flowdown

1.4 Identification of Project-Level Critical Items (PCIs)

1.5 Suspension of Work Activities

1.6 Surveillance

1.7 Government Mandatory Inspection Points (GMIPs)

1.8 List of Sub-Tier Contractors and Suppliers

1.9 Use of Inherited Products/Items

1.10 Protection of Flight Hardware

1.11 Risk Management

2 QUALITY MANAGEMENT SYSTEM

2.1 General

2.2 Supplemental Quality Management System Requirements

2.2.1 Control of Nonconforming Product

2.2.2 Material Review Board (MRB)

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

3 SYSTEM SAFETY

3.1 General

3.2 Mission Related Safety Requirements Documentation

3.3 System Safety Deliverables

3.3.1 System Safety Program Plan

3.3.2 Safety Requirements Compliance Checklist

3.3.3 Hazard Analyses

3.3.3.1 Preliminary Hazard Analysis

3.3.3.2 Operations Hazard Analysis (OHA) and Hazard Verification Tracking Log

(HVTL) 11

3.3.3.3 Lifting Device Safety Requirements

3.3.3.4 Operating and Support Hazard Analysis

3.3.4 Instrument Safety Assessment Report (ISAR)/ Safety Data Package (SDP)

3.3.5 Verification Tracking Log (VTL)

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

3.3.7 Mishap Reporting and Investigation

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

3.3.9 Safety Waivers

4 RELIABILITY

4.1 Reliability Program Plan (RPP)

4.2 Analysis of Design

4.2.1 Failure Modes and Effects Criticality Analyses (FMECA) and Critical Items List

(CIL) 15

4.2.2 Fault Tree Analysis (FTA)

ix

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

4.2.3 Reliability Calculations

4.3 Limited Life Analysis

4.4 Worst-Case Analysis

5 SOFTWARE ASSURANCE

5.1 Software Assurance Program

5.2 Surveillance of Software Development, Maintenance, and Assurance Activities

6 WORKMANSHIP

6.1 General

6.2 Electrostatic Discharge Control (ESD)

6.3 Printed Circuit Boards (PCB)

6.4 Lead-Free Control Measures

7 ELECTRICAL, ELECTRONIC, AND ELECTROMECHANICAL (EEE) PARTS

7.1 General

7.2 Parts Control Board

7.3 Re-use of EEE Parts

7.4 Master EEE Parts List

7.5 Radiation

8 MATERIALS AND PROCESSES

8.1 M&P Selection, Control, and Implementation Plan (MPCIP)

8.2 Materials Usage Agreement (MUA)

8.3 Materials Identification and Usage List (MIUL)

8.4 Life Test Plan and Final Report for Lubricated Mechanisms

8.5 Additive Manufacturing Control Plan (AMCP)

8.6 AM Part Production Plan (PPP)

9 CONTAMINATION CONTROL

9.1 Contamination Control Plan

9.2 Material Outgassing

9.3 Foreign Object Damage/Debris Program

10 METROLOGY AND CALIBRATION

10.1 Metrology and Calibration Program

10.2 Use of Calibrated and Non-Calibrated Instruments

11 GIDEP ALERTS AND PROBLEM ADVISORIES

11.1 Government-Industry Data Exchange Program (GIDEP)

11.2 Alert Disposition

11.3 GIDEP Reporting

11.4 Review Reporting

12 END ITEM ACCEPTANCE DATA PACKAGE (EIADP)

Appendix A Acronym List Appendix B Data Item Descriptions Appendix C Referenced Documents x

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

List of Tables

Table 4.1 Severity Categories Table 4.2 Likelihood Rankings Table 4.3 Consequence Rankings Table 4.4 Example Limited Life Item Tracking Log

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

DOCUMENT ORGANIZATION AND CONVENTIONS

This document establishes a risk-based application of mission assurance requirements for a Class C free flyer payload. It is organized around the following SMA disciplines/focus areas, each with its own section:

• Section 1 – General SMA Requirements • Section 7 - EEE Parts

• Section 2 – Quality Management System • Section 8 – Materials and Processes

• Section 3 – System Safety • Section 9 – Contamination Control

• Section 4 – Reliability • Section 10 – Metrology and Calibration

• Section 5 – Software Assurance • Section 11 – GIDEP Alerts and Problem

Advisories

• Section 6 - Workmanship • Section 12 – End Item Acceptance Data

Package

Each discipline/focus area is further decomposed into subsections associated with its individual SMA activities or deliverables (ex. within Section 2.2 “Quality Management System”, subsection 2.2.2 flows down the specific requirements for operating a “Material Review Board”). In instances where the risk classification does not warrant the flow down of specific SMA process/product standards, that section or subsection has been identified as “not applicable”, and the developer is expected to apply their internal standards, without government oversight.

In this document:

1. A specific requirement is denoted by “shall”

2. A good practice by “should”,

3. Permission by “may”,

4. An expectation by “will”.

The requirements in this document use the following identification convention:

SMA Discipline_AlphaNumeric Identifier

Ex. QMS_01x

Where the key is as follows:SMA

Discipline

• GEN – General SMA Requirements • EEE - EEE Parts

• QMS – Quality Management System • MAP – Materials and Processes

• SAF – System Safety • CON – Contamination Control

• REL - Reliability • MAC – Metrology and Calibration

• SWA – Software Assurance • GID - GIDEP Alerts and Problem

Advisories

• WOR - Workmanship • EIA – End Item Acceptance Data

Package

Numeric

Identifier

A unique and sequential 2-digit number, with or without a character, assigned to each requirement in the discipline/focus area

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

GENERAL

1.1 Systems Safety and Mission Assurance Program

GEN_01a: The developer shall implement a safety and mission assurance (SMA) program that is consistent with contractual requirements.

GEN_01b: 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 interfaces with flight items to the extent necessary to assure the integrity and safety of flight items

• Ground systems required for spacecraft communication, command and control, health and safety monitoring, and science data processing/distribution.

GEN_02: The developer shall submit a compliance matrix that identifies variance(s) and acceptance rationale for processes, procedures, and standards that are proposed as alternatives to those specified by the contract (Data Item Description (DID) 1-1).

This includes identification of items and mission assurance requirements for which relief is requested via the Inherited Item Risk Assessment process (see Section 1.9

"Use of Inherited Products/Items").

1.2 Management

GEN_03a: The Developer shall designate a manager for assurance activities.

GEN_03b: The assurance manager shall not be responsible for project costs and schedules other than those pertaining to assurance activities.

GEN_04: The Developer shall ensure that the assurance manager has direct access to upper management that is independent of project management and with functional freedom and authority to interact with all elements of the project.

1.3 Requirements Flowdown

GEN_05: The Developer shall ensure flow down of SMA requirements to all sub-tier

Developers and suppliers based on the work to be performed and establish a process to verify compliance, with the exception of those requirements approved for relief via the Inherited Item Risk Assessment process (see Section 1.9 "Use of

Inherited Products/Items").

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

GEN_06: The Developer’s contract review and purchasing processes shall indicate the method for documenting, communicating, and reviewing requirements with sub-tier suppliers to ensure requirements are met.

GEN_07: The developer shall ensure that quality plans, processes, procedures, hardware and software submitted by the developer’s sub-tier developers and suppliers are compliant with the requirements in this mission assurance requirement’s document, as applicable.

1.4 Identification of Project-Level Critical Items (PCIs)

GEN_08: The developer shall identify its critical items for incorporation into the Government developed project-level critical items (PCIs) with development in accordance with

NPR 8735.2C, Section 4.1.4.”.

Identification of critical items and processes should include the results of system safety and reliability analyses.

1.5 Suspension of Work Activities

GEN_11: The developer shall direct the suspension of any work activity that presents an unsafe work condition to personnel or imminent danger to property.

1.6 Surveillance

GEN_12: The developer shall provide access to quality management system documentation, information systems and work products/artifacts to NASA representatives.

GEN_13: The work activities, operations, and documentation performed by the Developer and sub-tier contractors or suppliers shall be subject to evaluation, review, audit, inspection, and survey by NASA representatives at various points over the program/project development lifecycle.

GEN_14a: In accordance with Federal Acquisition Regulations (FAR) 46.103, 46.104, 46.202-2, 46.4, and 46.5, the developer shall grant physical or remote access to

NASA representatives to conduct an on-site and/or remote audit, assessment, or inspection upon notice. A 30-day notice will be provided to the supplier/developer prior to the start of an assessment.

GEN_14b: The supplier/developer shall supply personnel, documents, records, equipment, and an acceptable work area within the developer’s facilities to assist with any audit, assessment, or inspection.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

GEN_15: The developer shall report the status of facility operations and quality metrics to

NASA on a quarterly basis. The report should include the following data for 1st tier and 2nd tier contractors or suppliers of PCIs:

• Quality escapes - Any product released by an internal or external supplier that is subsequently determined to be nonconforming to contract and/or product specification requirements:

• First Pass Yield - A measure of quality in a process that reflects the percentage of product made correctly without any rework or corrective activity.

• Supplier Defect Rate - The supplier defect rate measures the percentage of materials or product received from suppliers that do not meet required or compliance specifications.

• Internal Audit results

1.7 Government Mandatory Inspection Points (GMIPs)

GEN_16a: For cost plus projects, the Developer shall provide a plan for proposed GMIPs of

PCIs, subject to government approval. NPR 8735.2 “” may be used as a guide.

GEN_16b: Prior to the start of manufacturing, the developer shall provide work instructions, procedures, drawings, etc. that are required for performing the planned inspections.

1.8 List of Sub-Tier Contractors and Suppliers

GEN_19: The developer shall provide a list of sub-tier contractors and suppliers used for items produced under this contract (DID 1-2).

1.9 Use of Inherited Products/Items

For Inherited Products/Items, defined as those that will be build-to-print (BTP), or rebuilt with modification, or are available as commercial-off-the-shelf (COTS), or were previously developed and exist (e.g., spares), the developer may propose to follow the processes documented in GPR

8730.5.

Use of this process does not relieve the developer from meeting contractual performance and functional requirements for the Inherited Product/Item.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

1.10 Protection of Flight Hardware

GEN_21: The Developer shall evaluate the potential for Ground Support Equipment (GSE) to damage flight hardware and use appropriate means to prevent such damage from occurring.

GEN_22: The approach to obviate GSE damage to flight hardware shall be presented prior to the start of testing and at subsequent review milestones.

GEN_23: Prior to performing work on flight hardware, the Developer shall identify a list of items, if any, that are sensitive to normal handling environments, such as presence of light, presence of metal objects (magnets), or presence of humidity outside of normal cleanroom and workmanship limits.

GEN_24: The Developer shall hold a meeting on the day work is to be performed, prior to the start of each shift, that includes a discussion of the list of items.

1.11 Risk Management

SMA activities should be tightly linked with the project’s Risk Management processes. For example, risks that evolve from reliability analyses that affect overall mission objectives should be managed in the project’s risk database when not eliminated or mitigated to noncredible likelihood levels.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

2 QUALITY MANAGEMENT SYSTEM

2.1 General

QMS_01: The developer shall have a quality management system (QMS) that is compliant with the requirements of SAE AS9100 Quality Systems - Aerospace - Model for

Quality Assurance in Design, Development, Production, Installation and Servicing.

2.2 Supplemental Quality Management System Requirements

2.2.1 Control of Nonconforming Product

QMS_05a: The developer shall have a documented closed loop system for identifying, reporting, and correcting product nonconformances.

QMS_05b: The system shall ensure that the adequacy of corrective action is determined by audit, inspection or test, that objective evidence is collected, and that preventive action is implemented to preclude recurrence.

2.2.2 Material Review Board (MRB)

QMS_07: The Developer shall have a documented process(es) for the establishment and operation of an MRB to process major non-conformances, which are those that affect form, fit, function, require a software change, involve the presence of foreign object debris (FOD), or those that the developer determines involves elevated risk.

QMS_08: The Developer shall appoint a MRB chairperson who is responsible for implementing the MRB process and for appointing Developer representatives as

MRB members.

QMS_10: The MRB process shall include a Government representative as a participating member on MRB actions involving major nonconformances.

QMS_12: The Government shall be provided notice and applicable documentation 24 hours in advance of scheduled MRB meetings.

QMS_14: The MRB shall use the following disposition actions:

• Scrap — the product is not usable

• Re-work/Re-test — the product will be re-worked/re-tested to conform to requirements (sometimes referred to as “return to print”)

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

• Repair — the product will be repaired

• Use as is — the product will be used as is

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Anomaly Reporting and Disposition

QMS_15: The developer shall have a documented process for the establishment and operation of an anomaly review board (ARB) to process, report, and disposition major anomalies, which are those that have resulted in hardware or software test failures and damage or potential damage to hardware (DID 2-1).

QMS_17: Reporting of major anomalies shall begin with the first application of power at the component level, flight software acceptance testing, when interfacing with flight hardware, and the first mechanical operation.

QMS_19: The ARB (or equivalent function) shall include a government representative as a participating member on ARB actions involving major anomalies.

QMS_20: The government shall be provided notice of major anomalies and applicable documentation in advance of scheduled ARB meetings.

QMS_21: Anomalies that cannot be duplicated, have unknown root cause, or cannot be verified shall be assessed for residual risk, declared as red flag anomalies and brought to the Government’s project risk board for disposition.

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

QMS_22: The developer shall provide the information necessary for the development of the

ODAR and the EOMP deliveries per the content defined in NASA-STD 8719.14

(DID 2-2).

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

3 SYSTEM SAFETY

3.1 General

SAF_01: The developer shall document and implement a system safety program, support the expendable launch vehicle (ELV) Safety Review Process as defined in Chapter 3 of

NPR 8715.7, comply with launch service provider requirements, and comply with launch range safety requirements.

SAF_02a: The developer shall include the following specific safety requirements in the system safety program:

• SAF_02b: The developer shall incorporate three independent inhibits in the design

(dual failure tolerant) if a system failure may lead to a catastrophic hazard. A prelaunch catastrophic hazard is a payload-related hazard, condition, or event occurring prior to launch that could result in a fatal injury to personnel or loss of a ground facility. A post-launch catastrophic hazard is a payload-related hazard, condition, or event occurring after launch and up to payload separation that could result in a fatal injury or loss of flight termination system.

• SAF_02c: 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 severe injury or occupational illness or major property damage to facilities.

• SAF_02d: 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".

3.2 Mission Related Safety Requirements Documentation

SAF_03a: The developer shall implement the launch range safety requirements that are applicable to the launch site.

SAF_03b: The developer shall implement the most stringent safety requirement in the event there are conflicting requirements. The sections below include the applicable requirements documents for the pertinent launch ranges:

ELV Eastern Test Range (ETR) or Western Test Range (WTR) Missions

• NASA-STD 8719.24 (with Annex)

• KNPR 8715.3

• NPR 8715.7

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

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Wallops Flight Facility (WFF) Missions

• NASA-STD 8719.24 (with Annex)

• GSFC-STD-8009

3.3 System Safety Deliverables

3.3.1 System Safety Program Plan

SAF_10: The developer shall prepare 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 3-1).

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

3.3.2 Safety Requirements Compliance Checklist

SAF_11: The developer shall document and implement a Safety Requirements Compliance

Checklist to demonstrate that the payload complies with NASA and range safety requirements (DID 3-2).

3.3.3 Hazard Analyses

3.3.3.1 Preliminary Hazard Analysis

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

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

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

SAF_15: The developer shall deliver the PHA with the Preliminary ISAR (DID 3-4) or SDP I

(DID 3-5).

3.3.3.2 Operations Hazard Analysis (OHA) and Hazard Verification Tracking Log (HVTL)

SAF_16: The developer shall document, implement, and maintain an Operations Hazard

Analysis (OHA) and a Hazard Verification Tracking Log (HVTL) to demonstrate that hardware operations, test equipment operations, and integration and test (I&T) activities comply with the safety requirements of the facilities where the activities will be performed and that hazards associated with those activities are mitigated to an acceptable level of risk (DID 3‑3).

SAF_17: The developer shall update and maintain the Hazard Verification Tracking Log during Integration and Test (I&T) activities to track open issues.

3.3.3.3 Lifting Device Safety Requirements

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

A Critical Lift is defined as a lift during which failure/loss of control presents an elevated risk of serious injury, loss of life, or loss of one-of-a-kind articles, or high dollar items, whose loss would have serious programmatic or institutional impact.

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

• Overhead cranes, winches, and wire rope hoists shall have a dual hoist braking system installed per the NASA STD 8719.9B Sections 5.4 and 7.4. Chain hoists typically do not have dual brakes as standard equipment unless included in the manufacturer’s design when specifically requested by the user. A single hoist motor holding brake in combination with a Variable Frequency Drive (VFD) dynamic braking system is an acceptable dual braking system.

• Label and tag LDE the NASA STD 8719.9B, Section 4.9 requirements with no more than it's Working Load Limit (WLL) as determined by the original equipment manufacturer (OEM) or its current certified WLL if that value is lower than the original equipment manufacturer (OEM) rated WLL.

• Perform an initial one-time proof load test per the following NASA STD

8719.9B, Section 4.5 requirements:

• 1.25X WLL for overhead cranes.

• 1.25X WLL for mobile aerial platforms that will be used near critical hardware.

• 1X WLL for mobile cranes and derricks (.95X to 1X is acceptable).

• 1.25X WLL for below-the-hook (BTH) lifting devices.

• Slings (i.e., wire rope, synthetics, chain, etc.,) should only be proof load tested beyond its WLL with OEM approval.

• 2X WLL for rigging hardware items used for critical lifts (i.e., shackles. hoist rings. turnbuckles, etc.,).

• Perform a 1X WLL load test every four years after the initial proof test on all LDE.

• In addition to visual inspection, perform a post load test non-destructive test (NDT) inspection (e.g., radiographic, ultra-sonic, magnetic particle, dye penetrant, etc.) on crane hooks and critical welds. A critical weld is one in which a failure would result in a failure of the hardware. The inspections will be performed by an American

Society of Non-destructive Testing (ASNT) or equivalently trained inspector."

3.3.3.4 Operating and Support Hazard Analysis

SAF_20: 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 to ensure implementation of safety requirements for personnel, procedures, and equipment during activities at the launch site.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

SAF_21: The developer shall submit the results of the O&SHA as a part of the Intermediate &

Final instrument safety reports (ISARs) (DID 3-4) or safety data package (SDP) II and SDP III (DID 3-5).

3.3.4 Instrument Safety Assessment Report (ISAR)/ Safety Data Package (SDP)

SAF_22: The developer shall generate an 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 3-4) as an input to the Safety Data

Package (SDP) (DID 3-5).

SAF_23: The developer shall prepare an integrated SDP to document the results of hazard analyses identifying the prelaunch, launch and ascent hazards associated with the flight system, ground support equipment, and their interfaces in hazard reports (DID

3-5).

3.3.5 Verification Tracking Log (VTL)

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

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

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

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

SAF_28: The VTL shall identify hazard controls that are not verified as closed and shall be delivered with the final ISAR (DID 3-4) or SDP III (DID 3-5).

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

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

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

SAF_30: The developer shall document the hazardous procedures that will be implemented when integration and test activities and pre-launch activities are performed at processing facilities and the launch site (DID 3-6).

SAF_31: The developer shall ensure that the procedures comply with applicable facility safety requirements.

SAF_32: The developer shall provide safety support for the implementation of hazardous procedures.

3.3.7 Mishap Reporting and Investigation

SAF_33: The developer shall prepare a Pre-Mishap Plan that describes appropriate mishap and close call notification, reporting, recording, and investigation procedures (DID

3-7).

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

SAF_35: The developer shall promptly investigate to determine the root cause.

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

SAF_36: The developer shall prepare NASA ELV Payload Safety Forms. The forms are available at URL https://kscsma.ksc.nasa.gov/PayloadSafety/forms.

3.3.9 Safety Waivers

SAF_37: The Contractor shall request waivers for variations from the applicable safety requirements per paragraph 1.4 of NPR 8715.7B, Payload Safety Program. The waiver form is available at URL https://kscsma.ksc.nasa.gov/PayloadSafety/forms https://kscsma.ksc.nasa.gov/PayloadSafety/forms https://kscsma.ksc.nasa.gov/PayloadSafety/forms

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

4 RELIABILITY

4.1 Reliability Program Plan (RPP)

REL_01: The developer shall document and implement an RPP that includes both qualitative and quantitative techniques to support decisions regarding mission success and safety throughout system development (DID 4‑1).

REL_03: The developer shall include a detailed approach to the analysis of hardware and software for their contributions to system reliability and mission success

The developer should perform reliability analyses concurrent with design and maintain consistency between reliability analyses so that identified problem areas are addressed, and corrective action taken in a timely manner.

4.2 Analysis of Design

4.2.1 Failure Modes and Effects Criticality Analyses (FMECA) and Critical Items List

(CIL)

REL_11a: The developer shall perform, document, and maintain a FMECA that addresses flight hardware and software and GSE that interfaces with flight systems that are being designed, built, or provided from project initiation through launch and mission operations (DID 4-2).

REL_11b: The developer’s FMECA shall include likelihood, cause, detection and mitigation, and the effects of each failure mode at the local, subsystem, and system or mission levels, to the interface level for existing systems and to the box or functional level for modified or new systems (DID 4‑2).

REL_12: The developer shall prepare and maintain a Critical Items List for items with failure-mode severity categories 1SC (Safety Critical), 1, 1R (Redundant), 1S (Safety), and

2 per table 4.1. (DID 4-2)

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Table 4.1 Severity Categories

C ri ti ca li t y Category Description

S P

F s

C ri ti ca l

1SC

Failure modes that could cause a catastrophic event such as the loss of life, permanently disabling injury to personnel, or facility loss/destruction.

Failure modes that could result in mission loss or minimum mission success criteria not being achievable.

1S

Failure modes that could prevent detection of or operations during a hazardous condition resulting in 1SC conditions, eliminate a hazard inhibit, or cause severe injury, occupational illness, or major property damage.

1R Failure modes of identical or equivalent redundant hardware items that, if all failed, could result in category 1/1SC effects.

Failure modes that could result in loss of one or more mission objectives, including the significant loss of data, functionality, or a significant reduction in life of the mission. Minimum mission success criteria is still achievable.

S ig n if ic a n t

2R Failure modes of identical or equivalent redundant hardware items that could result in Category 2 effects if all failed.

Significant failure modes that could cause degradation to full mission objectives and still meet minimum mission.

M in o r 4

Minor Failure modes that could result in insignificant or no loss to mission objectives.

REL_13: The developer shall prepare and maintain a Single Point Failure (SPF) list for modes resulting in category 1 and 1SC severities per table 4.1 and document applicable failure causes, mitigations, and retention rationale.

REL_14: The developer shall identify and assess any known common cause failure modes and their causes for category 1R and 2R items.

REL_15: The developer shall estimate the likelihood score for each failure mode from 1-5 using the appropriate criteria from GPR 7120.4 (shown in Table 4.2), or another scale approved by the Government reliability expert. Each likelihood prediction can be based on qualitative assessment and/or failure rate data from other analyses (i.e., system calculations) in order to score each failure mode for the mission duration.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Table 4.2 Likelihood Rankings

REL_16: The developer shall identify the consequence for each failure mode using the appropriate criteria from GPR 7120.4 (shown in Table 4.3).

Table 4.3 Consequence Rankings

4.2.2 Fault Tree Analysis (FTA)

REL_18: The developer shall perform and maintain qualitative fault tree analyses (FTA) (DID

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

4-3), as deemed necessary by the chief safety and mission assurance officer (CSO) and the Mission Systems Engineer (MSE).

REL_19: The fault tree shall address both hardware and software contributions at a level necessary to identify risks, verify mitigations, and assist in the development of fault management.

REL_20: In the event the developer or the project identifies a major mission risk contributor in the FMECA or FTA, the developer shall quantify (and if necessary, expand) the appropriate FTA or the portions of the FTA necessary for detailed risk assessment, as deemed necessary by the CSO and the MSE.

REL_21: FTA should also be considered for use to check the FMECAs for completeness.

4.2.3 Reliability Calculations

REL_23: The developer shall perform and maintain reliability and ground-system availability calculations using Fault Tree Analyses (FTA), reliability block diagrams, and/or

Probabilistic Risk Assessment (PRA) (DID 4‑3) to identify design weaknesses, support design trades, and demonstrate the impact of critical items, as deemed necessary by the CSO and the MSE.

4.3 Limited Life Analysis

REL_25: The developer shall perform a Limited Life Item Analysis (LLA) that identifies components that have a limited useful life inherent to the performance of their respective function and documents and fosters a plan to manage limited life items

(DID 4-4).

REL_27: The developer shall prepare a list of limited life items that includes expected life, required life, an assessment of life margin (including servicing and maintenance), and retention rationale for items with an expected life of less than 2x the required life.

REL_29: The risk assessment and mitigations plans shall factor in wear caused by atomic oxygen, solar and trapped radiation, shelf-life, extreme temperatures, thermal cycling, and mechanical wear or fatigue, and include refurbishment and maintenance plans.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

Table 4.4 Example Limited Life Item Tracking Log

Limited-Life Item:

Limiting Characteristic:

Date Start

(e.g., time)

End

(e.g., time)

Total Remarks

Parts Stress Analysis

REL_30: The developer shall perform parts stress and derating analyses for electrical, electronic, and electromechanical (EEE) parts in accordance with GSFC EEE-INST-

002 (DID 4-5), unless specifically relieved of this requirement by the GSFC

Inherited Items Risk Assessment process (See Section 1.9).

If alternate derating guidelines are requested to be used, they will be submitted to the Parts

Control Board for approval.

4.4 Worst-Case Analysis

REL_35: The developer shall perform worst-case analyses (WCA) for circuit designs that are new or significantly modified and identified as critical through analysis of the design

(See Section 4.2) (DID 4-6).

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

5 SOFTWARE ASSURANCE

5.1 Software Assurance Program

SWA_01: The developer shall establish a software assurance program consisting of a planned and systematic set of activities and disciplines that ensures that software conforms to organizational and project-specific requirements and standards throughout the project lifecycle, where software is defined as:

• Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system

• All or a part of the programs, procedures, rules, and associated documentation of an information processing system

• Program or set of programs used to run a computer

• All or part of the programs which process or support the processing of digital information

• Part of a product that is the computer program or the set of computer programs.

Note: The software definition applies to software developed by NASA, software developed for

NASA, software maintained by or for NASA, COTS, GOTS, MOTS, OSS, reused software components, auto-generated code, embedded software, software used on ground support equipment, the software executed on processors embedded in programmable logic devices, legacy, heritage, applications, freeware, shareware, trial or demonstration software, and open-source software components.

SWA_03: The developer shall ensure the independence of software assurance from software engineering.

SWA_04: The developer shall document and implement a Software Assurance Plan and schedule compliant to NASA-STD-8739.8A (DID 5-1B/C). The plan will include the software assurance processes, procedures, tools and techniques to be used commensurate with the software classification and safety criticality assessment, with additional tailoring in accordance with guidance provided by NASA-STD-

8739.8A for each category of software (new, reused, Off-the-shelf, auto-generated code, etc..).

The plan will address both Software Assurance and Software Safety disciplines. This includes the necessary collaboration with relevant SMA and Engineering stakeholders (i.e., system safety, system reliability, hardware quality, system security, and software engineering), and the process by which traceability is established to their respective analyses and/or requirements.

5.2 Surveillance of Software Development, Maintenance, and Assurance Activities

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

SWA_09: Consistent with the general requirement for support of government surveillance (see

Section 1.8 "Surveillance"), the developer shall provide on-request access to following:

• Software problem reports

• Software documentation (i.e., management plans, assurance plans, configuration management plans, requirements specifications, design documents, test plans, test cases, test procedures, test results, software review results, software engineering and assurance schedule, maintenance plans)

• Source code

• Findings and corrective actions from software process and product audits and assessments"

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

6 WORKMANSHIP

6.1 General

WOR_02: The developer shall implement a workmanship program to assure that electronic packaging technologies, processes, and workmanship meet mission objectives for quality and reliability per the requirements of the following standards:

• NASA-STD-8739.6 Implementation Requirements for NASA Workmanship Standards, excluding sections 8.1, 9.1, and 10.1

• J-STD-001

• GSFC-STD-6001

• IPC-2225

• IPC-6015

WOR_03: The developer shall comply with one of the following standards for electrical cables and harnesses:

• NASA-STD-8739.4

• IPC/WHMA-A-620-S

6.2 Electrostatic Discharge Control (ESD)

WOR_05: The developer shall prepare and implement an ESD control plan that conforms to the requirements of ANSI/ESD S20.20 " (DID 6-1).

6.3 Printed Circuit Boards (PCB)

WOR_07: The developer shall comply with one of the following standards for rigid printed circuit boards:

• IPC-6012 (Note: the latest revision preferred, but older revisions acceptable based on inherited designs or developer standard practices)

• MIL-PRF-55110H

• ECSS-Q-ST-70-10

Note: In cases in which high-density interconnect (HDI) components (e.g., reconfigurable field programmable gate arrays (FPGAs), high-density static random access memory (SRAM), etc.) or board population are present, the developer should consult with the Project and Government

Materials Process Control Board Commodities Risk Assessment Engineer (MPCB CRAE) for a specification strategy to avoid extensive rebuilds or the incorporation of risky features solely in

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

order to meet the spec. This consultation may result in deviations from the specifications above with no waiver required.

WOR_08: The developer shall document and implement a PCB procurement plan (DID 6-2).

WOR_11: The developer should deliver PCB coupon evaluation reports for information only.

Note: 3rd party coupon evaluations are not required.

6.4 Lead-Free Control Measures

WOR_14: The developer shall document and implement a Lead-Free Control Plan (LFCP)

(DID 6-5).

WOR_15: The developers shall submit uses of lead-free solder or surface finishes to the

NASA project office for approval before use.

Note: The MPCB CRAE should disposition based on a risk assessment.

WOR_16: The developer shall replace pure-tin-finishes on EEE parts with tin lead solder prior to use.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

7 ELECTRICAL, ELECTRONIC, AND ELECTROMECHANICAL (EEE)

PARTS

7.1 General

EEE_02: The developer shall document and implement a Parts Control Plan (PCP) per Level

3 requirements of GSFC EEE-INST-002 (DID 7-1B/C).

Note: The developer may use Military specification parts without additional screening or qualification tests.

7.2 Parts Control Board

EEE_06: The developer shall establish a Parts Control Board (PCB) that is responsible for the planning, management, and coordination of the selection, application, and procurement requirements of EEE parts.

EEE_09: The developer shall identify the person responsible for directing and managing the

EEE parts program and interfacing with government assurance personnel.

EEE_12: The developer shall include the Government Parts Engineer or the Government

Parts and Radiation Assurance Engineer (PRAE) as a participating member of the

PCB.

7.3 Re-use of EEE Parts

EEE_14: The developer shall require approval of the MRB to re-use EEE parts that have been installed.

7.4 Master EEE Parts List

EEE_15: The developer shall develop and deliver a Master EEE Parts List in accordance with

DID 7-2, and maintain it for the duration of the project.

7.5 Radiation

EEE_18: Effects of radiation shall be mitigated either by the use of radiation-tolerant designs that are substantiated by analyses and testing as needed or by part-by-part, board-level, or box-level radiation hardness or radiation tolerance demonstrated by analysis or testing.

Check the JPSS/LEO MIS Server at https://jpssmis.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

Use or disclosure of data contained on this page is subject to the restriction(s) on the title page of this document.

8 MATERIALS AND PROCESSES

8.1 M&P Selection, Control, and Implementation Plan (MPCIP)

MAP_01: The developer shall prepare and implement a Materials and Processes (M&P)

Selection, Control, and Implementation Plan (MPCIP) (DID 8-1B/C). NASA-

STD-6016 shall be used as a baseline, with developer standard practices acceptable if associated command media are shared with NASA.

8.2 Materials Usage Agreement (MUA)

MAP_04: The developer shall prepare materials usage agreements (DID 8-2).

8.3 Materials Identification and Usage List (MIUL)

MAP_06:…