Attachment G - LNext IMAR-Rev A.pdf

IMAR LNEXT-SMA-REQ-0013 Revision A ii

Landsat Next Instrument Mission Assurance Requirements Signature/Approval Page

Prepared by:

Electronic Signature in TDMS Approval Date in TDMS Samilet Lee Date Landsat Next Chief Safety and Mission Assurance Officer Org./Code 383

Approved by:

Electronic Signature in TDMS Approval Date in TDMS Wen-Ting Hsieh Date Landsat Next Payload Manager Org./Code 426

Approved by:

Electronic Signature in TDMS Approval Date in TDMS James Pontius Date Landsat Next Project Manager Org./Code 426

Approved by:

Electronic Signature in TDMS Approval Date in TDMS Evan Webb Date Landsat Next Mission System Manager Org./Code 599 iii

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 iv

Change History Log v

List of TBDs/TBRs Hyperlink to TBx Location Summary Ind.

Name/Org.

Due Date vi

Table of Contents SIGNATURE/APPROVAL PAGE ................................................................................................ II

CM FOREWORD ..........................................................................................................................III

CHANGE HISTORY LOG .......................................................................................................... IV

LIST OF TBDS/TBRS .................................................................................................................... V

TABLE OF CONTENTS .............................................................................................................. VI

LIST OF FIGURES .................................................................................................................... VIII

LIST OF TABLES ...................................................................................................................... VIII

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 Protection of Flight Hardware

1.11 Risk Management

1.12 RELATED DOCUMENTS

1.12.1 Applicable Documents

1.12.2 Reference Documents

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

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 Instrument Safety Assessment Report (ISAR)/ Safety Data Package (SDP)

3.3.4 Hazard Analyses

3.3.4.1 Preliminary Hazard Analysis

vii

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

3.3.4.3 Lifting Device Safety Requirements

3.3.4.4 Operating and Support Hazard Analysis

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

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

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

viii

9.3 Foreign Object Debris Program

10.0 METROLOGY AND CALIBRATION

10.1 Metrology and Calibration Program

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 List

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

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). See LNEXT-LANDIS-PLAN-0052, Landsat Next Landsat Instrument Suite (LandIS) Contract Data Requirements List (CDRL) and Data Item Descriptions (DID).

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 process documented in GPR 8730.5, Safety and Mission Assurance Acceptance of Inherited and Build-to-Print Products.

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 PROTECTION OF FLIGHT HARDWARE

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

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

IMAR-453 Prior to performing work on flight hardware, the performing organization 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.

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

1.12 RELATED DOCUMENTS

1.12.1 Applicable Documents

Document Number Title Revision EEE-INST-002 Instruction for EEE Parts Selection, Screening, Qualification, and Derating

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 L

NASA-STD-6016

Standard Materials and Processes Requirements for Spacecraft

C

NASA-STD-8719.9 Lifting Standard B NASA-STD-8719.24 NASA Expendable Launch Vehicle

Payload Safety Requirements

- w/ CHANGE 3

Document Number Title Revision NASA-STD-8739.4 Workmanship Standard for Crimping, Interconnecting Cables, Harnesses, and Wiring

A w/Change 2

NASA-STD-8739.8 NASA Standard for Software Assurance A NASA-STD-8739.6 Implementation Requirements for NASA

Workmanship Standards B

NASA-STD-8739.12 Metrology & Calibration - w/Change 1 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 48 CFR § 46.4 Code of Federal Regulations, Contract

Management, Quality Management, Government Contract Quality Assurance

N/A

48 CFR § 46.5 Code of Federal Regulations, Acceptance N/A 48 CFR § 46.103 Code of Federal Regulations, Contracting office responsibilities N/A

48 CFR § 46.104 Code of Federal Regulations, Contract administration office responsibilities

N/A

48 CFR § 46.202-2 Code of Federal Regulations, Government reliance on inspection by contractor

N/A

ANSI/ESD S20.20 Protection of Electrical and Electronic Parts, Assemblies and Equipment (Excluding Electrically Initiated Explosive Devices)

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 GIDEP Operations Manual Government-Industry Data Exchange

Program Operations Manual N/A

ANSI/IPC-2225 Sectional Design Standard for Organic Multichip Modules (MCM-L) and MCM-L Assemblies

N/A

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

N/A

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

D

IPC-J-STD-001 Requirements for Soldered Electrical and Electronic Assemblies

H

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

Third Edition

Document Number Title Revision MIL-PRF-55110 Performance Specification: Printed Wiring

Board, Rigid, General Specification For J

AS9100 Quality Systems - Aerospace - Model for Quality Assurance in Design, Development, Production, Installation and Servicing

D

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 B

1.12.2 Reference Documents

Document Number Title Revision GPR 8730.5 Safety and Mission Assurance Acceptance of

Inherited and Build to Print Products A

NASA-STD-8739.10 Electrical, Electronic, and Electromechanical (EEE) Parts Assurance Standard

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 B

1.12.3 Project Applicable Documents

Document Number Title LNEXT-LANDIS-PLAN-0052 Landsat Next Landsat Instrument Suite (LandIS)

Contract Data Requirements List (CDRL) and Data Item Descriptions (DID)

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 B

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.

Note: “Repair” and “Use-As-Is” dispositions always fall under major the MRB classification.

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 The MRB process shall include a government representative as a voting member on MRB actions involving major nonconformances.

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

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 The ARB (or equivalent function) shall permit a government representative to be a participating member.

IMAR-364 Reporting of major anomalies shall begin with the first application of power at the component or board level, flight software acceptance testing and when interfacing with flight hardware, and the first mechanical operation.

IMAR-366 The government shall be provided notice of major anomalies and applicable documentation 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.

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

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

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 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.4 Hazard Analyses

3.3.4.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.4.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.4.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.9, 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.9, 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.4.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.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 (SA-36).

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.

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 identified 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 (SA-13).

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 Components and systems designated as inherited items shall be analyzed at the interface level with all others being analyzed at the box or functional level.

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.4 (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.4 (shown in Table 4.2-3).

Table 4.2-3 Consequence Rankings

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

IMAR-455 Fault trees shall address both hardware and software contributions at a level necessary to identify risks, verify mitigations, and assist in the development of fault management.

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

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

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 all design reviews and associated Engineering Peer Reviews starting with PDR.

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

IMAR-384 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. See example in Table 4.5-1.

IMAR-458 The risk assessment and mitigations plans shall factor in wear caused by atomic oxygen, radiation, shelf-life, extreme temperatures, thermal cycling, Memory Read/Write Cycling and mechanical wear or fatigue, and include refurbishment and maintenance plans.

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.

Table 4.5-1 Example Limited Life Item List

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) or the developer’s own established standard, unless specifically relieved of this requirement by the GSFC Inherited Items Risk Assessment process (See Section 1.9).

IMAR-459 If alternate derating guidelines are requested to be used, they shall be submitted to the Parts Control Board and GSFC Reliability Engineering for approval.

4.7 WORST-CASE ANALYSIS

IMAR-241 The developer shall perform Worst-Case Analyses (WCA) for circuit designs that are new or significantly modified, or are being used in an environment not covered by the existing analysis, and identified as critical through analysis of the design (See Section 4.2) (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 software, Government Off -the-Shelf (GOTS) software, Modified-Off-the-Shelf (MOTS software), Open Source Software (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.8, 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.8 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. IPC-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

f. Contractor processes may be accepted by Landsat project after review of the processes. Prior approval by other programs does not guarantee approval for Landsat Next.

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, Class 3 (the latest revision preferred, but older revisions acceptable based on inherited designs or developer standard practices)

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

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

IMAR-460 In cases in which High-Density Interconnect (HDI) components (e.g., reconfigurable Field Programmable Gate Array (FPGA), high-density Static Random Access Memory (SRAMs), etc.) or board population are present, the developer shall consult with the GSFC Project and GSFC Materials and Processes Control Board (MPCB) Commodity Risk Assessment Engineer (CRAE) for a specification strategy to avoid extensive rebuilds or the incorporation of risky features solely in order to meet the spec. This consultation may result in deviations from the specifications above with no waiver required.

IMAR-281 The developer shall document and implement a PCB procurement plan (SA- 22).

IMAR-283 The developer shall deliver PCB coupon evaluation reports for information only.

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.

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

Note: The developer may use as is Class V, S, Q, B, M compliant microcircuits; JANS, JANTXV, and JANTX semiconductors. The developer may use as is automotive or hi-rel commercial off the shelf (COTS) parts, compliant to level 3 per NASA-STD-8739.10 without any 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 and 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 acquire 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.

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 If an alternate standard to NASA-STD-6016, STANDARD MATERIALS AND PROCESSES REQUIREMENTS FOR SPACECRAFT is implemented, materials shall meet requirements of < 1% total mass loss (TML) and < 0.1% Collected Volatile Condensable Material (CVCM) at 125C under vacuum for twenty-four 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., Work Order Authorizations (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, software, and safety problems) and the actions taken to eliminate or mitigate negative effects at monthly status reviews, parts control board meetings, program milestone reviews, and readiness reviews.

12.0 END ITEM ACCEPTANCE DATA PACKAGE

IMAR-353 The developer shall maintain the End Item Acceptance Data Package

(EIADP) throughout the project lifecycle and submit in accordance with 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 BTH Below-The-Hook BTP Build-to-Print C Centigrade CDRL Contract Data Requirements List CIL Critical Items List COTS…