Attachment G - LNext IMAR Rev -.pdf

DOORS EXPORT

National Aeronautics and

Space Administration

Goddard Space Flight Center Greenbelt, Maryland

LNEXT-SMA-REQ-0013, Revision -

Landsat Next, Code 426

Landsat Next Instrument Mission Assurance

Requirements dsierfel LNext CM Stamp

LNext IMAR LNEXT-SMA-REQ-0013 Revision -ii

Landsat Next Instrument Mission Assurance Requirements

Signature Page

Prepared by:

Electronic Signature in TDMS

01/06/2023

Samilet Lee Date Landsat Next Chief Safety and Mission Assurance Officer, CSO

NASA/GSFC, Code 383

Approved by:

Joy Henegar-leon Date Landsat Next Payload Technical Manager NASA/GSFC, Code 426

Wen-Ting Hsieh Date Landsat Next Payload Manager NASA/Goddard, Code 426

Evan Webb Date Landsat Next Systems Manager NASA/GSFC, Code 599 iii

James Pontius Date Landsat Next Project Manager NASA/GSFC, Code 426 iv

CM Foreword This document is a Landsat Next Project Configuration Management (CM)-controlled document.

Changes to this document require prior approval of the applicable Configuration Control Board (CCB) Chairperson or designee. Proposed changes shall be submitted to the Landsat Next CM

Office (CMO), along with supportive material justifying the proposed change. Changes to this document will be made by complete revision.

Questions or comments concerning this document should be addressed to:

NASA/Goddard Space Flight Center Landsat Next Project Office, Code 426 Attention: Configuration Management Office

Greenbelt, Maryland 20771 v

Change History Log

Revision Effective Date Description of Changes

- 01/06/2023 LNEXT-CCR-0027 – Initial Release vi

List of TBDs/TBRs Hyperlink to TBx Location Summary

Ind.

Name/Org.

Due

Date vii

Table of Contents

CM FOREWORD ................................................................................................................. IV

CHANGE HISTORY LOG......................................................................................................V

LIST OF TBDS/TBRS........................................................................................................... VI

TABLE OF CONTENTS ...................................................................................................... VII

LIST OF FIGURES ............................................................................................................... IX

LIST OF TABLES ................................................................................................................ IX

1.0 GENERAL

1.1 Systems Safety and Mission Assurance (SMA) 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 Suppliers

1.9 Use of Inherited Products/Items

1.10 Risk Management

1.11 RELATED DOCUMENTS

1.11.1 Applicable Documents

2.0 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.2.3 Anomaly Reporting and Disposition

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

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

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)

viii

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

4.0 RELIABILITY

4.1 Reliability Program Plan (RPP)

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

(CIL)

4.3 Fault Tree Analysis

4.4 Reliability Assessments and Predictions

4.5 Limited Life Items

4.6 Parts Stress Analysis

4.7 Worst-Case Analysis

5.0 SOFTWARE ASSURANCE

5.1 General

5.2 Software Assurance Program

5.3 Surveillance of Software Development, Maintenance, and Assurance Activities

6.0 WORKMANSHIP

6.1 General

6.2 Electrostatic Discharge Control (ESD)

6.3 Printed Circuit Board (PCB)

6.4 Lead-Free Control Measures

7.0 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.0 MATERIALS AND PROCESSES

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

(MPCIP)

8.2 Materials Usage Agreement (MUA)

8.3 Materials Identification and Usage List (MIUL)

8.4 Additive Manufacturing Control Plan (AMCP)

8.5 AM Part Production Plan (PPP)

9.0 CONTAMINATION CONTROL

9.1 Contamination Control Plan

9.2 Material Outgassing

9.3 Foreign Object Debris Program

10.0 METROLOGY AND CALIBRATION

10.1 Metrology and Calibration Program

ix

10.2 Use of Calibrated and Non-Calibrated Instruments

11.0 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.0 END ITEM ACCEPTANCE DATA PACKAGE

APPENDIX A ABBREVIATIONS AND ACRONYMS

APPENDIX B DEFINITIONS

List of Figures No table of contents entries found.

List of Tables Table 4.2-1 Severity Categories

Table 4.2-2 Likelihood Rankings Table 4.2-3 Consequence Rankings Table 4.5-1 Example Limited Life Item Tracking Log

1.0 GENERAL

1.1 SYSTEMS SAFETY AND MISSION ASSURANCE (SMA) PROGRAM

IMAR-431 The developer shall implement a safety and mission assurance program that is consistent with contractual requirements.

IMAR-434 The mission assurance program shall cover the following:

• 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 and test scripts that interface 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.

1.2 MANAGEMENT

IMAR-8 The developer shall designate a manager for assurance activities.

IMAR-436 The assurance manager shall not be responsible for project costs and schedules other than those pertaining to assurance activities.

IMAR-9 The developer shall ensure that the assurance manager has direct access to upper management that is independent of project management and shall have the functional freedom and authority to interact with all elements of the project.

1.3 REQUIREMENTS FLOWDOWN

IMAR-11 The developer shall ensure flow down of Safety and Mission Assurance (SMA) requirements to all suppliers based on the work to be performed and establish a process to verify compliance, except for those identified through the Inherited Item Risk Assessment process (see Section 1.9 "Use of

Inherited Products/Items").

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

IMAR-13 The developer shall ensure that quality plans, processes, procedures, hardware, and software submitted by the developer’s sub-tier suppliers are compliant with the requirements in this Mission Assurance Requirements (MAR) document, as applicable.

1.4 IDENTIFICATION OF PROJECT-LEVEL CRITICAL ITEMS (PCIS)

IMAR-15 The developer shall identify its critical items for incorporation into the project-level critical items (PCIs) developed in accordance with NPR 8735.2, Section 4.1.4, Critical Items and Processes Determination.

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

1.5 SUSPENSION OF WORK ACTIVITIES

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

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

IMAR-21 The work activities, operations, and documentation performed by the contractor and sub-tier contractors or the suppliers shall be subject to Government Contract Quality Assurance (GCQA) and will be required to include evaluation, review, audit, inspection, and survey by government-designated representatives at various points over the program/project development lifecycle. Surveillance plans will focus on suppliers of PCIs (per NPR 8735.2).

IMAR-22 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 prior to the start of an assessment.

IMAR-355 The developer shall supply personnel, documents, records, equipment, and an acceptable work area within the developer’s facilities to assist with the audit/assessments/inspections.

IMAR-357 The prime contractor shall report the status of facility operations and quality metrics to NASA on a quarterly basis. The reports should include the following:

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

b. First pass yield — The first pass yield is a measure of quality in a process that reflects the percentage of product made correctly without any rework or corrective activity.

c. Supplier defect rate — The supplier defeat rate measures the percentage of materials or product received from suppliers that do not meet required or compliance specifications.

d. Internal audit results

This quarterly report should include tier-1 and tier-2 suppliers of PCIs within scope of the contract.

1.7 GOVERNMENT MANDATORY INSPECTION POINTS (GMIPS)

IMAR-30 For cost plus contracts, the developer shall provide a plan for proposed Government Mandatory Inspection Points (GMIPS) of project-level critical items, subject to government approval. NPR 8735.2, Hardware Quality Assurance Program Requirements for Programs and Projects may be used as a guide.

IMAR-358 Prior to the start of manufacturing, the developer shall provide work instructions, procedures, drawings, etc., that are required for performance of the planned inspections.

The developer can exclude non-critical items (as defined in NPR 8735.2 and determined by the project) or items where GMIP requirements have been relieved as a result of the Inherited Item Risk Assessment (see Section 1.9 "Use of Inherited Products/Items"), or by the GSFC project office through terms of the procurement for commercial-off-the-shelf (COTS) items. Note that items that have redundancy (i.e., where loss of one unit does not jeopardize mission success criteria) within a spacecraft or instrument or across multiple spacecraft are not critical. However, GMIPs should be planned for all applicable items in a multi-item repeat build.

1.8 LIST OF SUPPLIERS

IMAR-33 The developer shall provide a list of suppliers used for product produced under this contract (SA-2).

1.9 USE OF INHERITED PRODUCTS/ITEMS

For Inherited Products/Items, defined as those that will be build-to-print (BTP), rebuilt with modification, are available as COTS, or were previously developed and exist (e.g., spares), the developer may propose to follow the GSFC Inherited Item Risk Assessment process (SA-3).

IMAR-36 The developer shall comply with all requirements of the MAR and Statement of Work (SOW) for the Inherited Product unless specifically relieved by the GSFC project office as a result of the Inherited Item Risk Assessment.

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

1.10 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; likewise for safety risks (threats to personnel, the public, the environment, hosts, and facilities).

1.11 RELATED DOCUMENTS

1.11.1 Applicable Documents

Document Number Title Revision GPR 7120.4 Risk Management D GSFC-STD-6001 Ceramic Column Grid Array Design and

Manufacturing Rules for Flight Hardware A

KNPR 8715.3 KSC Safety Procedure Requirements Rev K V1-3 NASA-STD-8719.9 Lifting Standard B NASA-STD-8719.24 NASA Expendable Launch Vehicle

Payload Safety Requirements

- w/ CHANGE 3

NASA-STD-8739.8 NASA Standard for Software Assurance A NASA-STD-8739.4 Workmanship Standard for Crimping, Interconnecting Cables, Harnesses, and Wiring

A w/Change 2

NASA-STD-8739.6 Implementation Requirements for NASA Workmanship Standards

B

NPR 8735.2 Hardware Quality Assurance Program Requirements for Programs and Projects

C w/ CHANGE 1

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

D

NPR 8715.7 Expendable Launch Vehicle Payload Safety Program

B

2023-01 Federal Acquisition Regulations N/A ANSI/ESD S20.20 Protection of Electrical and Electronic

Parts, Assemblies and Equipment (Excluding Electrically Initiated Explosive

Devices)

ANSI/NCSL z540.1 Requirements for the Calibration of

Measuring and Test Equipment

TBD

ANSI/NCSL z540.3 Requirements for the Calibration of

Measuring and Test Equipment

TBD

AS9100 Quality Systems - Aerospace - Model for

Quality Assurance in Design, Development, Production, Installation and

Servicing

D

Document Number Title Revision ASTM E595-15 Standard Test Methods for Total Mass

Loss and Collected Volatile Condensable

Materials from Outgassing in a Vacuum Environment

ECSS-Q-ST-70-10 Qualification of Printed Circuit Boards C EEE-INST-002 Instruction for EEE Parts Selection, Screening, Qualification, and Derating

GIDEP Operations Manual Government-Industry Data Exchange

Program Operations Manual N/A

IPC-2225 Sectional Design Standard for Organic

Multichip Modules (MCM-L) and MCM-L Assemblies

05/01/1998

IPC-6012 Qualification and Performance Specification for Rigid Printed Boards

E

IPC-6015 Qualification and Performance Specification for Organic Multichip Module (MCM-L) Mounting and

Interconnecting Structures

02/01/1998

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

ISO/IEC 17025 General Requirements for the Competence of Testing and Calibration Laboratories Third Edition

J-STD-001 Requirements for Soldered Electrical and

Electronic Assemblies H

MIL-PRF-55110 Performance Specification: Printed Wiring

Board, Rigid, General Specification For H

RSM-2002 Ranger Safety Manual for GSFC/WFF In this document, citations are assumed to be the latest version unless otherwise noted.

This document table was generated from the Landsat Next Referenced Documents List Draft Rev -

2.0 QUALITY MANAGEMENT SYSTEM

2.1 GENERAL

IMAR-42 The developer shall have a quality management system 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

IMAR-45 The developer shall have a documented closed loop system for identifying, reporting, and correcting product nonconformances.

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

2.2.2 Material Review Board (MRB)

IMAR-47 The developer shall have a documented process for the establishment and operation of a Material Review Board (MRB) to process major nonconformances, which are those that affect form, fit, function, require a software change, involve foreign or domestic object debris, (FOD or DOD) or those for which the developer determines elevated risk is involved.

IMAR-48 The developer shall appoint an MRB chairperson, who is responsible for implementing the MRB process and functional and project representatives as

MRB members.

IMAR-49 For non-commercial buys, the MRB process shall include a government representative as a voting member on MRB actions involving major nonconformances.

For commercial buys, a procurement that does not include government design requirements but involves only end-item requirements, the government will be a participating member but may or may not be a voting member depending on the government role as specified by the contract.

IMAR-50 The government shall be provided notice and applicable documentation 24 hours in advance of scheduled MRB meetings.

IMAR-51 The developer shall inform the government of major MRB actions no later than five (5) working days after MRB action for approval (SA-4).

IMAR-362 The MRB shall use the following disposition actions:

a. Scrap — the product is not usable.

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

c. Return to supplier — the product will be returned to the supplier.

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

e. Use as is — the product will be used as is.

2.2.3 Anomaly Reporting and Disposition

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

IMAR-60 For non-commercial buys, the ARB shall include a government representative, who will be a voting member.

For commercial buys, the government will be a participating member but may be a non-voting member.

IMAR-61 The developer shall submit major anomalies to the ARB and the government

(SA-5).

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

IMAR-62 The developer shall submit anomaly reports no later than 24 hours after occurrence.

IMAR-366 The government shall be provided notice and applicable documentation 24 hours in advance of scheduled ARB meetings.

IMAR-63 Failures that cannot be duplicated, have unknown root cause, or cannot be verified shall be assessed for residual risk, declared as red flag problem failure records (PFRs), and brought to the project risk board for disposition.

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.

2.3 ORBITAL DEBRIS ASSESSMENT REPORT (ODAR) AND END OF MISSION

PLAN (EOMP)

IMAR-66 The developer shall provide the information necessary for the development of the Orbital Debris Assessment Report (ODAR) and the End of Mission Plan (EOMP) deliveries per the content defined in NASA-STD 8719.14

Process for Limiting Orbital Debris (SA-6).

3.0 SYSTEM SAFETY

3.1 GENERAL

IMAR-69 The developer shall document and implement a system safety program, support the Expendable Launch Vehicle (ELV) Safety Review Process as defined in paragraph 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.

IMAR-368 The developer shall include the following specific safety requirements in the system safety program:

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

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

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

IMAR-75 The developer shall implement the launch-range safety requirements that are applicable to the launch site.

IMAR-369 The developer shall implement the most stringent safety requirement in the event there are conflicting requirements.

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

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

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

c. NPR 8715.7, Expendable Launch Vehicle Payload Safety Program

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

Wallops Flight Facility (WFF) Missions

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

Safety Requirements

• RSM-2002, Range Safety Manual for GSFC/WFF

3.3 SYSTEM SAFETY DELIVERABLES

3.3.1 System Safety Program Plan

IMAR-86 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 (SA-7).

3.3.2 Safety Requirements Compliance Checklist

IMAR-88 The developer shall document and implement a Safety Requirements Compliance Checklist to demonstrate that the payload complies with NASA and range safety requirements (SA-8).

3.3.3 Hazard Analyses

3.3.3.1 Preliminary Hazard Analysis

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

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

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

IMAR-94 The developer shall deliver the PHA with Preliminary Instrument Safety Assessment Report (ISAR) (SA-10-1).

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

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

(SA-9).

IMAR-97 The developer shall update and maintain the HVTL during I&T activities to track open issues.

3.3.3.3 Lifting Device Safety Requirements

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

• For overhead cranes, winches, and wire rope hoists, install a dual hoist braking system per NASA STD 8719.9 (Lifting Standard), 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, per NASA STD 8719.9B, Section 4.9 requirements, with the Working Load Limit (WLL), as determined by the original equipment manufacturer (OEM) or the current certified WLL, if that value is lower than the 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 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

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

IMAR-111 The developer shall submit the results of the O&SHA as a part of the Intermediate & Final ISARs (SA-10-2 and SA-10-3).

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

IMAR-113 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 (SA-10).

The spacecraft developer will use the ISAR as an input to the Safety Data Package (SDP).

3.3.5 Verification Tracking Log (VTL)

IMAR-115 The developer shall document and implement a Verification Tracking Log (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.

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

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

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

IMAR-119 The VTL shall identify hazard controls that are not verified as closed and those hazard controls shall be delivered with the final ISAR (SA-10-3).

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

IMAR-122 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 (SA-11).

IMAR-123 The developer shall ensure that the procedures comply with applicable facility safety requirements.

IMAR-124 The developer shall provide safety support for the implementation of hazardous procedures.

3.3.7 Mishap Reporting and Investigation

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

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

IMAR-130 The developer shall promptly investigate to determine the root cause.

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

IMAR-132 The developer shall prepare NASA Expendable Launch Vehicle Payload Safety Forms. The forms are available at URL https://kscsma.ksc.nasa.gov/PayloadSafety/forms.

https://kscsma.ksc.nasa.gov/PayloadSafety/forms

4.0 RELIABILITY

4.1 RELIABILITY PROGRAM PLAN (RPP)

IMAR-135 The developer shall document and implement a Reliability Program Plan

(RPP) that includes both qualitative and quantitative techniques to support decisions regarding mission success and safety throughout system development (SA-12).

IMAR-136 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 so that identif ied problem areas are addressed, and corrective action taken in a timely manner.

4.2 FAILURE MODES AND EFFECTS CRITICALITY ANALYSES (FMECA) AND

CRITICAL ITEMS LIST (CIL)

IMAR-139 The developer shall perform and maintain Failure Modes and Effects

Criticality Analyses (FMECA) that address flight hardware, software, ground support equipment, and simulators that interface with flight systems that are being designed, built, or provided from project initiation through launch and mission operations.

IMAR-378 The developer shall include likelihood, cause, detection and mitigation, and the effects of each failure mode at the local, subsystem, and system or mission levels.

IMAR-379 The developer shall analyze the interface level for existing systems and the box level or functional level for modified or new systems (SA-13).

IMAR-140 The developer shall prepare and maintain a Critical Items List (CIL) for items with failure-mode severity categories 1SC (Safety Critical), 1, 1R (Redundant), 1S (Safety), and 2 per table 4.2-1.

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

IMAR-142 The developer shall identify and assess any known common cause failure modes and causes for category 1R and 2R items.

Table 4.2-1 Severity Categories

IMAR-179 The developer shall estimate the likelihood score for each failure mode from 1-5 using the appropriate criteria from GPR 7120.4D (shown in Table 4.2-2), or another scale approved by the government. 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.

Table 4.2-2 Likelihood Rankings

IMAR-182 The developer shall identify the consequence for each failure mode using the appropriate criteria from GPR 7120.4D (shown in Table 4.2-3).

Table 4.2-3 Consequence Rankings

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

4.3 FAULT TREE ANALYSIS

IMAR-187 The developer shall perform and maintain Fault Tree Analyses (FTA) (SA-

14) to identify design weaknesses, support design trades, and demonstrate the impact of critical items, as deemed necessary by the CSO and the Mission Systems Engineer (MSE).

4.4 RELIABILITY ASSESSMENTS AND PREDICTIONS

IMAR-380 The developer shall perform comparative numerical assessments and/or reliability predictions (SA-15) to perform the following:

• Assist in trade studies by evaluating alternative design concepts, redundancy and cross strapping approaches, and part substitutions.

• Identify the elements of the design which are potentially the greatest detractors of system reliability.

• Identify those potential mission limiting elements and components that will require special attention in part selection, testing, environmental isolation, and/or special operations.

• Evaluate the design in terms of mission success requirements

• Evaluate the impact of proposed engineering changes and waiver requests on reliability.

IMAR-195 MIL-HDBK-217 data is outdated and inaccurate source for reliability predictions. The developer shall not use any data from MIL-HDBK-217 as a source for this CDRL. Refer to CDRL SA-15 for approved list of predictions data.

IMAR-381 Reliability prediction methods shall be verified with GSFC prior to analysis delivery.

IMAR-382 The results of the reliability assessments shall be reported at design reviews starting with the first major design review.

IMAR-383 The presentations shall include comments on how the analyses were used to perform design trade-offs or how the results were taken into consideration when making design or risk management decisions.

4.5 LIMITED LIFE ITEMS

IMAR-198 The developer shall prepare a list of limited life items (SA-16) that includes expected life, required life, duty cycles, and an assessment of life margin that includes servicing and maintenance.

IMAR-384 Retention rationale shall be provided for items with an expected life of less than 2x the required life.

Limited life items are generally defined as items that have a limited shelf life, operational life, or a cycle life. The risk assessment and mitigation plans should (as appropriate) factor in wear caused by atomic oxygen, solar and trapped radiation, shelf -life, extreme temperatures, thermal cycling, and mechanical wear or fatigue, and the assessment should include refurbishment and maintenance plans.

Potential limited life items include, but are not necessarily limited to, selected consumables, structures, mechanisms, batteries, seals, thermal control surfaces, solar arrays, and electromechanical mechanisms.

IMAR-201 For each limited life item, engineering/SMA-personnel shall track the life-limiting characteristics and maintain records of the used/remaining life for each limited life item in a logbook (e.g., Table Table 4.5-1).

Table 4.5-1 Example Limited Life Item Tracking Log

Item Life-Limiting

Mechanism Expected

Life Required

Life Compliance &

Life Ratio Data Sources & Notes

Mirror Coating

Degradation of optical properties

10 years 5 years Complies 2.0

Expected Life: Vendor datasheet Required Life:

Requirement Doc 98765

Switch Wear-out of contacts

190 cycles 100 cycles Does Not Comply (DNC) 1.9

Expected Life: Test Report 12345 Required Life:

Requirement Doc 98765

4.6 PARTS STRESS ANALYSIS

IMAR-239 The developer shall perform parts stress and derating analyses for electrical, electronic, and electromechanical (EEE) parts in accordance with GSFC EEE-INST-002, Instruction for EEE Parts Selection, Screening, Qualification, and Derating (SA-17).

4.7 WORST-CASE ANALYSIS

IMAR-241 The developer shall perform worst-case analyses (WCA) for circuits (SA-

18).

5.0 SOFTWARE ASSURANCE

5.1 GENERAL

IMAR-386 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 the following:

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

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

c. Program or set of programs used to run a computer

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

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

IMAR-250 The developer shall ensure the independence of software assurance from software engineering.

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

5.2 SOFTWARE ASSURANCE PROGRAM

IMAR-253 The developer shall document and implement a Software Assurance Plan and schedule compliant to NASA-STD-8739.8A, NASA Software Assurance and Software Safety Standard (SA-19).

IMAR-387 The plan shall include the software assurance processes, procedures, tools and techniques to be used commensurate with the software classification and safety criticality assessment, along 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.).

IMAR-254 The plan shall address both the Software Assurance and the 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.3 SURVEILLANCE OF SOFTWARE DEVELOPMENT, MAINTENANCE, AND

ASSURANCE ACTIVITIES

IMAR-389 Consistent with general requirement for support of government surveillance (see Section 1.6, Surveillance), the developer shall provide on-demand access to the following:

a. Software problem reports

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

c. Source code

d. Findings and corrective actions from software process and product audits and assessments

6.0 WORKMANSHIP

6.1 GENERAL

IMAR-390 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:

a. NASA-STD-8739.6 Implementation Requirements for NASA

Workmanship Standards, excluding sections 8.1, 9.1, and 10.1

b. J-STD-001, Requirements for Soldered Electrical and Electronic Assemblies

c. GSFC-STD-6001, Ceramic Column Grid Array Design and

Manufacturing Rules for Flight Hardware

d. IPC-2225, Sectional Design Standard for Organic Multichip Modules (MCM-L) and MCM-L Assemblies

e. IPC-6015, Qualification and Performance Specification for

Organic Multichip Module (MCM-L) Mounting and Interconnecting Structures

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

a. NASA-STD-8739.4, Crimping, Interconnecting Cables, Harnesses, and Wiring

b. IPC/WHMA-A-620, Requirements and Acceptance for Cable and

Wire Harness Assemblies

6.2 ELECTROSTATIC DISCHARGE CONTROL (ESD)

IMAR-273 The developer shall prepare and implement an Electrostatic Discharge (ESD) control program that conforms to the requirements of ANSI/ESD S20.20, Protection of Electrical and Electronic Parts, Assemblies and Equipment (Excluding Electrically Initiated Explosive Devices) (SA-21).

6.3 PRINTED CIRCUIT BOARD (PCB)

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

a. IPC-6012, Qualification and Performance Specification for Rigid

Printed Boards

b. MIL-PRF-55110H, Performance Specification: Printed Wiring Board, Rigid, General Specif ication For

c. ECSS-Q-ST-70-10, Qualification of Printed Circuit Boards

Note: Agreements between the developer and supplier that reduce a standard’s requirements are considered alternate standards and require the submission of an Alternate Printed Circuit Board Standard Report (DID 6-1). Revisions or other versions of the above standards that contain more stringent acceptability and quality assurance requirements are not considered alternate standards and do not have to be identified.

Note: The most current version of IPC-6012 should be used to clarify requirement ambiguities in prior versions.

IMAR-281 The developer shall document and implement a PCB procurement plan.

IMAR-282 The developer shall deliver PCB procurement information for PCB manufacturing (SA-22).

IMAR-283 The developer shall deliver PCB coupon evaluation reports (SA-32).

IMAR-284 The developer shall deliver PCB lot acceptance and quality conformance verification test results (SA-33).

6.4 LEAD-FREE CONTROL MEASURES

IMAR-286 The developer shall document and implement a Lead-Free Control Plan

(LFCP) (SA-23).

IMAR-287 The developers shall submit uses of lead-free solder or surface finishes to the

MRB for approval before use.

IMAR-288 The developer shall tin EEE parts leads with a tin lead solder prior to use.

7.0 EEE PARTS

7.1 GENERAL

IMAR-291 The developer shall document and implement a Parts Control Plan (PCP) per

Level 3 requirements of GSFC EEE-INST-002, Instruction for EEE Parts Selection, Screening, Qualification, and De-rating (SA-24).

IMAR-292 The PCP shall address counterfeit parts in accordance with SAE AS5553.

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

7.2 PARTS CONTROL BOARD

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

IMAR-296 The developer shall identify the person responsible for interfacing with government assurance personnel and directing and managing the EEE parts program.

IMAR-297 The developer shall include the GSFC Project Parts Engineer or the GSFC Parts and Radiation Assurance Engineer (PRAE) as a participating member of the PCB.

7.3 RE-USE OF EEE PARTS

IMAR-299 The developer shall require approval of the MRB to reuse EEE parts that have been installed and removed other than as planned and designed.

IMAR-448 Parts that have been installed in an assembly and are then removed from the assembly for any reason, cannot be used again in any item of flight or spare hardware without prior approval of the MRB. The approval shall be based on the submission of evidence that re-used devices did not degrade during the removal and re-installation process, shortening the device useful life.

7.4 MASTER EEE PARTS LIST

IMAR-301 The developer shall develop and deliver a Master EEE Parts List in accordance with SA-25 and maintain it for the duration of the project.

7.5 RADIATION

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

8.0 MATERIALS AND PROCESSES

8.1 MATERIALS AND PROCESSES (M&P) SELECTION, CONTROL, AND

IMPLEMENTATION PLAN (MPCIP)

IMAR-306 The developer shall prepare and implement a Materials and Processes (M&P) Selection, Control, and Implementation Plan (MPCIP) (SA-26).

8.2 MATERIALS USAGE AGREEMENT (MUA)

IMAR-308 The developer shall prepare Materials Usage Agreements (MUAs) (SA-27).

8.3 MATERIALS IDENTIFICATION AND USAGE LIST (MIUL)

IMAR-310 The developer shall prepare a Materials Identification and Usage List

(MIUL) (SA-28).

8.4 ADDITIVE MANUFACTURING CONTROL PLAN (AMCP)

IMAR-312 The developer shall prepare and implement an Additive Manufacturing

Control Plan (AMCP) for the design and manufacture of Additively Manufactured (AM) Parts (SA-34).

8.5 AM PART PRODUCTION PLAN (PPP)

IMAR-314 The developer shall prepare a Part Production Plan (PPP) for each AM part

(SA-35).

9.0 CONTAMINATION CONTROL

9.1 CONTAMINATION CONTROL PLAN

IMAR-317 The developer shall prepare and implement a contamination control program

(SA-29).

9.2 MATERIAL OUTGASSING

IMAR-319 The developer shall include information regarding material outgassing in

MIUL, SA-28.

IMAR-320 Materials shall meet requirements of < 1% total mass loss (TML) and < 0.1% collected volatile condensable material (CVCM) at 125C under vacuum for

24 hours when tested to ASTM E595, Standard Test Methods for Total Mass Loss and Collected Volatile Condensable Materials from Outgassing in a Vacuum Environment.

9.3 FOREIGN OBJECT DEBRIS PROGRAM

IMAR-322 The developer shall prepare and implement a foreign object debris program

(SA-30).

10.0 METROLOGY AND CALIBRATION

10.1 METROLOGY AND CALIBRATION PROGRAM

IMAR-393 For measurement and test equipment that has documented requirements for metrological accuracy and traceability, the developer shall comply with NASA-STD-8739.12 "Metrology and Calibration", or verify equipment against calibrated instruments or intrinsic standards, using a documented procedure.

Note: The developer may verify torque wrenches against a calibrated torque tester prior to use.

10.2 USE OF CALIBRATED AND NON-CALIBRATED INSTRUMENTS

IMAR-330 The developer shall record the measurements that require accuracy in applicable project build documents (e.g., WOAs, job orders, task sheets or test plans), including the article of calibrated equipment used to take the measurement and its calibration end date.

IMAR-331 When verification is chosen instead of calibration, the developer shall perform verification within a timeframe that has been demonstrated to provide appropriate levels of reliability, in the same facility, and under the same conditions that will be encountered during the process.

11.0 GIDEP ALERTS AND PROBLEM ADVISORIES

11.1 GOVERNMENT-INDUSTRY DATA EXCHANGE PROGRAM (GIDEP)

IMAR-344 The developer shall participate in the Government-Industry Data Exchange

Program (GIDEP) per the GIDEP Operations Manual (Note: this document is available through http://www.gidep.org).

11.2 ALERT DISPOSITION

IMAR-346 The developer shall review the following, hereafter referred to collectively as Alerts, for effects on EEE parts, materials, equipment, and software used in NASA products: GIDEP Alerts; GIDEP SAFE-ALERTS; GIDEP Problem Advisories; GIDEP Agency Action Notices; NASA Advisories.

IMAR-347 When the developer identifies an item in their design, inventory, or assembly that is documented in an Alert, the developer shall disposition the item and Alert through the MRB as a major nonconformance.

11.3 GIDEP REPORTING

IMAR-349 The developer shall prepare and submit failure experience data and safety issue reports per the requirements of the GIDEP Operations Manual whenever failed or nonconforming items that are available to other buyers are discovered.

11.4 REVIEW REPORTING

IMAR-351 The developer shall report the status of NASA products that are affected by Alerts or by significant EEE parts, materials, and safety problems at monthly status reviews, parts control board meetings, program milestone reviews, and readiness reviews.

IMAR-399 The developer shall include a summary of the review status for EEE parts and materials lists and of actions taken to eliminate or mitigate negative effects.

http://www.gidep.org/

12.0 END ITEM ACCEPTANCE DATA PACKAGE

IMAR-353 The developer shall submit an End Item Acceptance Data Package (SA-31).

Appendix A Abbreviations and Acronyms

Acronym/Abbreviation Definition AMCP Additive Manufacturing Control Plan ANSI American National Standards Institute ARB Anomaly Review Board ASNT American Society of Nondestructive Testing ASTM American Society for Testing and Materials BTP Build-to-Print C Centigrade CDRL Contract Data Requirements List CIL Critical Items List COTS Commercial-Off-the-Shelf CSO Chief Safety Mission Assurance Officer CVCM Collected Volatile Condensable Material ECSS European Cooperation for Space Standardization EEE Electrical, Electronic, and Electromechanical ELV Expendable Launch Vehicle EOMP End of Mission Plan ESD Earth Science Division ETR Eastern Test Range f Frequency FAR Federal Acquisition Regulation FMECA Failure Modes and Effects Criticality Analyses FTA Fault Tree Analyses GCQA Government Contract Quality Assurance GIDEP Government-Industry Data Exchange Program GMIPS Government Mandatory Inspection Points GOTS Government-Off-the-Shelf GPR GSFC Procedural Requirements GSFC Goddard Space Flight Center HDBK Handbook HVTL Hazard Verification Tracking Log IMAR Instrument Mission Assurance Requirements ISAR Instrument Safety Assessment Report ISO International Standards Organization I&T Integration and Test KNPR Kennedy Space Center (KSC) NASA Procedural Requirement KSC Kennedy Space Center LDE Lifting Devices and Equipment LFCP Lead-Free Control Plan MAR Mission Assurance Requirement MIL Military MIUL Materials Identification and Usage List MOTS Modified-Off-the-Shelf M&P Materials and Processes MPCIP Materials, Processes, Control, and Implementation Plan MRB Material Review Board MSE Mission Systems Engineer MUA Materials Usage Agreement MUAs Materials Usage Agreements

Acronym/Abbreviation Definition NASA National Aeronautics and Space Administration NPR NASA Procedural Requirement ODAR Orbital Debris Assessment Report OHA Operations Hazard Analysis O&SHA Operating and Support Hazard Analysis…