![](media/image1.png){width="1.4484251968503936in"
height="1.2807086614173229in"}

**Landsat Data Continuity Mission**

**Instrument**

**Mission Assurance Requirements**

**October 30, 2006**

CM FOREWORD

This document is a Landsat Data Continuity Mission (LDCM) 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 LDCM 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:

LDCM Configuration Management Office

Mail Stop 427

Goddard Space Flight Center

Greenbelt, Maryland 20771

Signature Page

+-----------------------------+-----+---------------------------+----+
| Prepared by:                | D   |                           |    |
|                             | ate |                           |    |
| Jack Ellis                  |     |                           |    |
|                             |     |                           |    |
| LDCM Systems Assurance      |     |                           |    |
| Manager                     |     |                           |    |
|                             |     |                           |    |
| NASA GSFC Code 303          |     |                           |    |
+-----------------------------+-----+---------------------------+----+
| Reviewed by:                | D   | Reviewed by:              | Da |
|                             | ate |                           | te |
| Del Jenstrom                |     | Evan Webb                 |    |
|                             |     |                           |    |
| LDCM Deputy Project Manager |     | LDCM Mission Systems      |    |
|                             |     | Manager                   |    |
| NASA GSFC Code 427          |     |                           |    |
|                             |     | NASA GSFC Code 427        |    |
+-----------------------------+-----+---------------------------+----+
| Reviewed by:                | D   | Reviewed by:              | Da |
|                             | ate |                           | te |
| William Anselm              |     | Jeanine Murphy-Morris     |    |
|                             |     |                           |    |
| LDCM Observatory Manager    |     | LDCM Instrument Manager   |    |
|                             |     |                           |    |
| NASA GSFC Code 427          |     | NASA GSFC Code 427        |    |
+-----------------------------+-----+---------------------------+----+
| Reviewed by:                |     |                           |    |
|                             |     |                           |    |
| USGS                        |     |                           |    |
+-----------------------------+-----+---------------------------+----+

+-----------------------------+-------+------------------------+-----+
| Approved by:                | Date  |                        |     |
|                             |       |                        |     |
| William Ochs                |       |                        |     |
|                             |       |                        |     |
| LDCM Project Manager        |       |                        |     |
|                             |       |                        |     |
| NASA GSFC Code 427          |       |                        |     |
+-----------------------------+-------+------------------------+-----+

![](media/image2.pct){width="1.0416666666666666e-2in"
height="1.0416666666666666e-2in"}Landsat Data Continuity Mission

**DOCUMENT CHANGE RECORD** Sheet: 1 of 1

+-----+--------------------------------------------+---------+--------+
| REV | DESCRIPTION OF CHANGE                      | A       | DATE   |
|     |                                            | PPROVED |        |
| LE  |                                            |         | AP     |
| VEL |                                            | BY      | PROVED |
+-----+--------------------------------------------+---------+--------+
|     |                                            |         |        |
+-----+--------------------------------------------+---------+--------+

TABLE OF CONTENTS

Page

1.0 Overall Mission Assurance Requirements
[1-1](#overall-mission-assurance-requirements)

1.1 Description of Overall Requirements
[1-1](#description-of-overall-requirements)

1.2 Surveillance of the Developer [1-1](#surveillance-of-the-developer)

1.3 Contract Delivery Requirements List
[1-1](#contract-delivery-requirements-list)

2.0 Quality Management System [2-2](#quality-management-system)

2.1 General [2-2](#general)

2.2 Supplemental Quality Management System Requirements
[2-2](#supplemental-quality-management-system-requirements)

2.2.1 Control of Nonconforming Product
[2-2](#control-of-nonconforming-product)

2.2.2 Preliminary Review [2-2](#preliminary-review)

2.2.3 Material Review Board [2-3](#material-review-board)

2.2.4 Reporting of Failures [2-3](#reporting-of-failures)

2.2.5 Control of Monitoring and Measuring Devices
[2-3](#control-of-monitoring-and-measuring-devices)

2.2.6 New On-Orbit Design [2-3](#new-on-orbit-design)

2.2.7 Flow-Down [2-4](#flow-down)

3.0 System Safety Requirements [3-1](#system-safety-requirements)

3.1 General Requirements [3-1](#general-requirements)

3.2 System Safety Deliverables [3-2](#system-safety-deliverables)

3.2.1 System Safety Program Plan [3-2](#system-safety-program-plan)

3.2.2 Safety Requirements Compliance Checklist
[3-2](#safety-requirements-compliance-checklist)

3.2.3 Safety Analysis [3-2](#safety-analysis)

3.3 Safety Assessment Report [3-3](#safety-assessment-report)

3.4 Verification Tracking Log [3-3](#verification-tracking-log)

3.5 Ground Operations Procedures [3-4](#ground-operations-procedures)

3.6 Safety Variance [3-4](#safety-variance)

3.7 Support for Safety Meetings [3-4](#support-for-safety-meetings)

3.8 Orbital Debris Assessment [3-4](#orbital-debris-assessment)

3.10 Launch Site Safety Support [3-5](#launch-site-safety-support)

3.11 Mishap Reporting and Investigation
[3-5](#mishap-reporting-and-investigation)

3.12 Miscellaneous Submittals for Range Use
[3-5](#miscellaneous-submittals-for-range-use)

4.0 Reliability and Probabilistic Risk Assessment
[4-1](#reliability-and-probabilistic-risk-assessment)

4.1 General Requirements [4-1](#general-requirements-1)

4.1.1 Reliability Program Plan [4-1](#reliability-program-plan)

4.1.2 Probabilistic Risk Assessment
[4-1](#probabilistic-risk-assessment)

4.1.3 Design Reviews and Readiness Reviews
[4-2](#design-reviews-and-readiness-reviews)

4.1.4 Reliability Working Group Participation
[4-2](#reliability-working-group-participation)

4.1.5 Reliability Progress Reporting
[4-2](#reliability-progress-reporting)

4.2 Reliability Analyses [4-2](#reliability-analyses)

4.2.1 Failure Modes and Effects Analysis, Critical Items List, and
Critical Items Control Plan
[4-2](#failure-modes-and-effects-analysis-critical-items-list-and-critical-items-control-plan)

4.2.2 Fault Tree Analysis [4-4](#fault-tree-analysis)

4.2.3 Parts Stress Analyses [4-4](#parts-stress-analyses)

4.2.4 Worst-Case Analyses [4-4](#worst-case-analyses)

4.2.5 Numerical Assessments and Predictions
[4-5](#numerical-assessments-and-predictions)

4.2.6 Limited-Life Items Plan [4-5](#limited-life-items-plan)

4.3 Reliability Analysis of Test Data
[4-6](#reliability-analysis-of-test-data)

4.3.1 Trend Analyses [4-6](#trend-analyses)

4.3.2 Analysis of Test Results [4-6](#analysis-of-test-results)

4.4 Control of Sub-Developers and Suppliers
[4-6](#control-of-sub-developers-and-suppliers)

4.5 Reliability of Government Furnished Equipment
[4-7](#reliability-of-government-furnished-equipment)

4.6 Software Reliability [4-7](#software-reliability)

5.0 Software Assurance Requirements
[5-1](#software-assurance-requirements)

5.1 General [5-1](#general-1)

5.2 Software Assurance [5-1](#software-assurance)

5.3 Software Quality [5-1](#software-quality)

5.4 Software Safety [5-2](#software-safety-1)

5.5 Software Reliability [5-3](#software-reliability-1)

5.6 Verification and Validation [5-3](#verification-and-validation)

5.7 Independent Verification and Validation
[5-3](#independent-verification-and-validation)

5.8 GFE, Existing and Purchased Software
[5-3](#gfe-existing-and-purchased-software)

6.0 Risk Management Requirements [6-1](#risk-management-requirements)

6.1 General [6-1](#general-2)

6.2 Applicable Documents [6-1](#applicable-documents)

6.3 Risk Management Plan [6-2](#risk-management-plan)

6.4 Risk List [6-2](#risk-list)

6.5 Risk-Based Acquisition Management
[6-3](#risk-based-acquisition-management)

7.0 Integrated Independent Review Requirements
[7-1](#integrated-independent-review-requirements)

7.1 General Requirements [7-1](#general-requirements-2)

7.2 Instrument Reviews [7-1](#instrument-reviews)

7.3 Peer Reviews [7-1](#peer-reviews)

8.0 Design Verification Requirements
[8-1](#design-verification-requirements)

8.1 General [8-1](#general-3)

8.2 Documentation Requirements [8-1](#documentation-requirements)

8.3 Performance Operating Time and Failure-Free Performance Testing
[8-1](#performance-operating-time-and-failure-free-performance-testing)

9.0 Workmanship Standards [9-1](#workmanship-standards)

9.1 General [9-1](#general-4)

9.2 Applicable Documents [9-1](#applicable-documents-1)

9.3 Design [9-2](#design)

9.3.1 Printed Wiring Boards [9-2](#printed-wiring-boards)

9.3.2 Assemblies [9-2](#assemblies)

9.3.3 Ground Support Equipment that Interface with Space Flight Hardware
[9-3](#ground-support-equipment-that-interface-with-space-flight-hardware)

9.4 Workmanship Requirements [9-3](#workmanship-requirements)

9.4.1 Training and Certification [9-3](#training-and-certification)

9.4.2 Flight and Harsh Environment Ground Systems Workmanship
[9-3](#flight-and-harsh-environment-ground-systems-workmanship)

9.4.3 Ground Systems (Non-Flight) Workmanship
[9-3](#ground-systems-non-flight-workmanship)

9.4.4 Documentation [9-4](#documentation)

9.5 New and Advanced Materials and Packaging Technologies
[9-4](#new-and-advanced-materials-and-packaging-technologies)

9.6 Hardware Handling [9-4](#hardware-handling)

9.7 Special Provisions [9-4](#special-provisions)

9.7.1 Precision Component Assembly [9-4](#precision-component-assembly)

9.7.2 Capping of Test Points and Plugs
[9-4](#capping-of-test-points-and-plugs)

9.7.3 Electrical Connector Mating [9-4](#electrical-connector-mating)

9.7.4 Solder Joint Intermetallics Mitigation
[9-4](#solder-joint-intermetallics-mitigation)

10.0 Materials and Process Requirements
[10-1](#materials-and-process-requirements)

10.1 General Requirements [10-1](#general-requirements-3)

10.2 Materials Selection Requirements
[10-1](#materials-selection-requirements)

10.2.1 Inorganic Materials [10-4](#inorganic-materials)

10.2.2 Vacuum Outgassing of Polymeric Materials
[10-5](#vacuum-outgassing-of-polymeric-materials)

10.2.3 Lubrication Systems [10-5](#lubrication-systems)

10.2.4 Process Selection Requirements
[10-6](#process-selection-requirements)

10.2.5 Fasteners [10-6](#fasteners)

10.3 Materials Used in \"Off-the-Shelf-Hardware"
[10-7](#materials-used-in-off-the-shelf-hardware)

10.4 Materials Procurement Requirements
[10-7](#materials-procurement-requirements)

10.4.1 Incoming Inspection Requirements
[10-7](#incoming-inspection-requirements)

10.5 Shelf-Life-Control Requirements for Polymeric Materials
[10-7](#shelf-life-control-requirements-for-polymeric-materials)

10.6 Failure Analysis [10-7](#failure-analysis)

10.7 Preservation and Packing [10-8](#preservation-and-packing)

10.8 Handling [10-8](#handling)

10.9 Data Retention [10-9](#data-retention)

11.0 EEE Parts Control Program Support
[11-1](#eee-parts-control-program-support)

11.1 General [11-1](#general-5)

11.2 Developer's Project Parts Engineer
[11-1](#developers-project-parts-engineer)

11.3 Parts Control Board [11-2](#parts-control-board)

11.3.1 PCB Responsibilities [11-2](#pcb-responsibilities)

11.3.2 PCB Meetings, Notification, and Reports
[11-2](#pcb-meetings-notification-and-reports)

11.3.3 PCB Membership [11-2](#pcb-membership)

11.4 Part Selection and Processing
[11-3](#part-selection-and-processing)

11.4.1 Parts Selection [11-3](#parts-selection)

11.4.2 Radiation Requirements for Parts Selection
[11-3](#radiation-requirements-for-parts-selection)

11.4.3 Custom or Advanced Technology Devices
[11-4](#custom-or-advanced-technology-devices)

11.4.4 Plastic Encapsulated Microcircuits
[11-4](#plastic-encapsulated-microcircuits)

11.4.5 Verification Testing [11-4](#verification-testing)

11.4.6 Parts Approved on Prior Programs
[11-5](#parts-approved-on-prior-programs)

11.5 Part Analysis [11-5](#part-analysis)

11.5.1 Destructive Physical Analysis
[11-5](#destructive-physical-analysis)

11.5.2 Failed EEE Parts [11-5](#failed-eee-parts)

11.5.3 Failure Analysis [11-5](#failure-analysis-1)

11.6 Additional Requirements [11-6](#additional-requirements)

11.6.1 Parts Age Control [11-6](#parts-age-control)

11.6.2 Derating [11-6](#derating)

11.6.3 Alerts [11-6](#alerts)

11.6.4 Prohibited Metals [11-7](#prohibited-metals)

11.7 Parts List [11-7](#parts-list)

11.7.1 Parts Identification List [11-7](#parts-identification-list)

11.7.2 Program Approved Parts List [11-7](#program-approved-parts-list)

11.7.3 As-Built Parts List [11-7](#as-built-parts-list)

11.8 Data Requirements [11-8](#data-requirements)

11.8.1 Radiation Hardness [11-8](#radiation-hardness)

12.0 Contamination Control Requirements
[12-1](#contamination-control-requirements)

12.1 General [12-1](#general-6)

12.2 Contamination Control Verification Process
[12-1](#contamination-control-verification-process)

12.3 Contamination Control Plan [12-1](#contamination-control-plan)

12.4 Material Outgassing [12-1](#material-outgassing)

12.5 Thermal Vacuum Bakeout [12-1](#thermal-vacuum-bakeout)

12.6 Hardware Handling [12-2](#hardware-handling-1)

13.0 Electrostatic Discharge Control
[13-1](#electrostatic-discharge-control)

13.1 General [13-1](#general-7)

13.2 Applicable Documents [13-1](#applicable-documents-2)

13.3 Electrostatic Discharge Control Requirements
[13-1](#electrostatic-discharge-control-requirements)

14.0 GIDEP Alerts and Problem Advisories
[14-1](#gidep-alerts-and-problem-advisories)

14.1 General [14-1](#general-8)

15.0 Applicable Documents List [15-1](#applicable-documents-list)

Appendix A. Abbreviations and Acronyms [1](#__RefHeading___Toc23847542)

Appendix B. Glossary/Definitions [1](#__RefHeading___Toc23847543)

**LIST OF FIGURES**

[Figure]{.underline} [Page]{.underline}

Figure 10‑1. Material Usage Agreement
[10-2](#__RefHeading___Toc23846281)

Figure 10‑2. Stress Corrosion Evaluation Form
[10-3](#__RefHeading___Toc23846282)

Figure 10‑3. Inorganic Materials List
[10-4](#__RefHeading___Toc23846283)

Figure 10‑4. Polymeric Materials List
[10-5](#__RefHeading___Toc23846284)

**LIST OF TABLES**

[Table]{.underline} [Page]{.underline}

Table 4‑1. Severity Categories [4-3](#__RefHeading___Toc23396477)

# Overall Mission Assurance Requirements

## Description of Overall Requirements

The Systems Safety and Mission Assurance Program is applicable to LDCM
instrument(s), (i.e., the Operational Land Imager (OLI) and the Thermal
Infrared Sensor (TIRS)) and their associated developers. References made
herein to the instrument Statement of Work (SOW) and Contract Data
Requirements List (CDRL) refer respectively to the OLI and TIRS SOW and
CDRL.

The developer is required to plan and implement an organized Systems
Safety and Mission Assurance Program that encompasses:

-   All flight hardware, either designed/built/provided by the developer
    or furnished by the GSFC, from project initiation through launch and
    mission operations.

-   The ground system ( e.g. test equipment, simulators, etc.) that
    interfaces with flight equipment to the extent necessary to assure
    the integrity and safety of flight items..

-   All software critical for mission success.

Managers of the assurance activities shall have direct access to
developer management independent of project management, with the
functional freedom and authority to interact with all other elements of
the project. Issues requiring project management attention shall be
addressed with the developer(s) through the Project Manager(s) and/or
Contracting Officer Technical Representative(s) (COTR).

## Surveillance of the Developer

The work activities, operations, and documentation performed by the
developer and/or his suppliers are subject to evaluation, review, audit,
and inspection by government-designated representatives from GSFC, the
Government Inspection Agency (GIA), or an independent assurance
contractor (IAC). GSFC will delegate in-plant responsibilities and
authority via a letter of delegation, or the GSFC contract with the IAC.

The developer and/or suppliers shall grant access for NASA and/or NASA
representatives to conduct an assessment/survey upon notice. Resources
shall be provided to assist with the assessment/survey with minimal
disruption to work activities. The developer, upon request, shall
provide government assurance representatives with documents, records,
and equipment required to perform their assurance and safety activities.
The developer shall also provide the government assurance
representative(s) with an acceptable work area within developer
facilities.

## Contract Delivery Requirements List

The instrument Contract Delivery Requirements List (CDRL) identifies
DRDs describing data deliverable to the GSFC Project Office. A complete
list of CDRLs and associated DRDs may be found in the instrument CDRL.

# Quality Management System

## General

The developer shall have a quality management system (QMS) that is
compliant with the minimum requirements of American National Standards
Institute (ANSI)/International Organization for Standardization
(ISO)/American Society for Quality (ASQ) Q9001-2000. The developer's
Quality Manual shall be provided in accordance with CDRL SA-1. The
developer shall supplement their Q9001 Quality Manual with an LDCM
instrument specific Systems Assurance Plan (CDRL SA-1) that defines on a
chapter-by-chapter/section-by-section basis (referenced to the chapters
of this document) how the developer will meet each requirement of this
document. Every "shall" statement in this document is a requirement.

## Supplemental Quality Management System Requirements

As mentioned previously, some assurance related activities are not
covered by ISO requirements. These activities are identified in the
following sections and should supplement the ANSI/ISO/ASQ Q9001
requirements.

### Control of Nonconforming Product

The developer shall have a closed loop system for identifying and
reporting nonconformances, ensuring that corrective action is
implemented to prevent recurrence. The developer will audit and test as
applicable to verify adequacy of the corrective action implemented. The
system shall include a nonconformance review process, which shall
consist of a preliminary review and a Material Review Board (MRB). The
Government project Safety and Mission Assurance (SMA) representative
shall sign off on all MRB activity relating to flight hardware or ground
support equipment (GSE) that interfaces with flight hardware.

### Preliminary Review

The preliminary review process shall be initiated with the
identification and documentation of a nonconformance. A preliminary
review shall be the initial step performed by developer-appointed
personnel to determine if the nonconformance is minor and can readily be
processed using the following disposition actions:

a.  Scrapped, because the product is not usable for the intended
    purposes and cannot be economically reworked or repaired.

b.  Re-worked, to result in a characteristic that completely conforms to
    the standards or drawing requirements.

c.  Returned to supplier, for rework, repair or replacement.

d.  Repaired using a standard repair process previously approved by the
    MRB and /or government Quality Assurance (QA) organization.

e.  Referred to MRB when the above actions do not apply to the
    nonconformance.

**Note**: Preliminary review does not negate the requirement to
identify, segregate, document, and report and disposition
nonconformances.

### Material Review Board

Nonconformances not dispositioned by preliminary review, normally
critical and major nonconformances, shall be referred to the MRB for
disposition. MRB dispositions shall include scrap, rework, return to
supplier, repair by standard or non-standard repair procedures,
use-as-is, or request for major waiver. The MRB shall consist of a core
team including QA, supplemented with other disciplines brought in as
necessary. It shall be chaired by a developer representative responsible
for ensuring that MRB actions are performed in compliance with this
standard and implemented per developer procedures. This is usually a
systems engineering function.

The MRB shall consist of the appropriate functional and project
representatives who are needed to ensure timely determination,
implementation and close-out of recommended MRB disposition. Safety and
quality assurance personnel shall review all MRBs.

At developer/supplier facilities, NASA/Government representatives shall
participate in MRB activities as deemed appropriate by Government
management or contract, otherwise, the MRB chairperson shall advise the
Government of the MRB actions and recommendations. NASA will exercise
the prerogative to review and approve all "use-as-is," standard and
non-standard repair dispositions before they are initiated.

The MRB process shall investigate, in a timely manner, nonconforming
item(s) in sufficient depth to determine proper disposition. For each
reported nonconformance, there shall be an investigation and engineering
analysis sufficient to determine cause and corrective actions for the
nonconformance. Written authorization shall be provided to disposition
the nonconformances.

### Reporting of Failures

Reporting of failures shall begin as early in the life cycle as
possible. Reporting shall begin by the first power application at the
start of end item acceptance testing or the first operation of a
mechanical item. It shall continue through formal acceptance by the GSFC
Project Office. Failures shall be reported in accordance with (CDRL
SA-2).

Developer review/disposition/approval of failure reports shall be
addressed by a Failure Review Board as described in applicable
procedure(s) included or referenced in the Quality Manual.

### Control of Monitoring and Measuring Devices

Testing and calibration laboratories shall be compliant with the
requirements of ISO 17025, "General Requirements for the Competence of
Testing and Calibration Laboratories."

### New On-Orbit Design

The developer shall ensure modification of on-orbit flight software
shall be in accordance with original system design specifications and
validation processes.

### Flow-Down

The developer's QA and safety programs shall ensure flow-down of
requirements to all suppliers, including a process to verify compliance.
Specifically, contract review and purchasing processes shall indicate
the processes for documenting, communicating, and reviewing requirements
with sub-tier suppliers to ensure requirements are met.

Examples include, but are not limited to the following: Technical,
Safety, Parts and Materials, Reliability, Quality Assurance, NASA
Advisories, Government Industry Data Exchange Program (GIDEP) (Alerts,
Safe-Alerts, Problem Advisories, and Agency Action Notices).

# System Safety Requirements

## 3.1 General Requirements {#general-requirements .unnumbered}

The system safety program shall be implemented by instrument developers
for flight hardware, GSE, associated software, and support facilities.
The system safety program shall be initiated in the concept phase of
design and continue throughout all phases of the mission. GSFC shall
certify safety compliance in support of the Pre-Shipment Review (PSR),
and again at the Mission Readiness Review (MRR). The system safety
program shall accomplish the following:

a.  Provide for the early identification and control of hazards to
    personnel, facilities, support equipment, and the flight system
    during all stages of project development including design,
    development, fabrication, test, handling, storage, transportation,
    and pre-launch activities. The program shall address hazards in the
    flight hardware, associated software, GSE, operations, and support
    facilities, and shall conform to the safety review process
    requirements of NASA-STD-8719.8, "Expendable Launch Vehicle Payloads
    Safety Review Process Standard."

b.  Meets the system safety requirements of AFSCM 91-710, "Range User
    Requirements Manual."

c.  Meets the baseline industrial safety requirements of the
    institution, AFSPC 91-710 applicable Industry Standards to the
    extent practical to meet NASA and Office of Safety and Health
    Administration (OSHA) design and operational needs, and any special
    contractually imposed mission unique obligations. This should be
    documented in the contractor's Facility Health and Safety Plan.

Specific safety requirements include the following:

-   If a system failure may lead to a catastrophic hazard, the system
    shall have three inhibits (dual fault tolerant). A [catastrophic
    hazard]{.underline} is defined as: 1) A hazard that could result in
    a mishap causing fatal injury to personnel, and/or loss of one or
    more major elements of the flight vehicle or ground facility. 2) A
    condition that may cause death or permanently disabling injury,
    major system or facility destruction on the ground, or vehicle
    during the mission.

-   If a system failure may lead to a critical hazard, the system shall
    have two inhibits (single fault tolerant). A [critical
    hazard]{.underline} is defined as: a condition that may cause severe
    injury or occupational illness, or major property damage to
    facilities, system, or flight hardware.

-   Hazards which cannot be controlled by failure tolerance (e.g.,
    structures, pressure vessels, etc.) are called "Design for Minimum
    Risk" areas of design, and have separate detailed safety
    requirements that they must meet. Hazard controls related to these
    areas are extremely critical and warrant careful attention to the
    details of verification of compliance on the part of the developer.

##  {#section .unnumbered}

## System Safety Deliverables

### 3.2.1 System Safety Program Plan {#system-safety-program-plan .unnumbered}

The developer shall prepare a System Safety Program Plan (SSPP) (see
CDRL SA-3) which describes in detail, tasks and activities of system
safety management and system safety engineering required to identify,
evaluate, eliminate and control hazards or reduce the associated risk to
a level acceptable throughout the system life cycle.

The approved plan provides a formal basis of understanding between the
instrument provider and GSFC Code 302 on how the System Safety Program
will be conducted to meet the range safety requirements and spacecraft
Integrator safety requirements, including general and specific
provisions. The approved plan shall account for all contractually
required tasks and responsibilities on an item-by-item basis, and will
address the roles and responsibilities of each organization. The SSPP
shall specify the hazard analyses required to be performed on flight
hardware, GSE, integration and test (I&T) and pre-launch operations.

### 3.2.2 Safety Requirements Compliance Checklist {#safety-requirements-compliance-checklist .unnumbered}

The developer shall demonstrate that the payload is in compliance with
all safety requirements (or that Problem Failure Reports
\[PFRs\]/waivers have been submitted and approved by GSFC Code 302 and
the launch site safety representative). The developer shall document
this in the Safety Requirements Compliance Checklist (see CDRL SA-6).
Safety compliance shall be granted via GSFC Code 302 Safety
Certification Letter to the Project Manager only after verification that
all applicable safety requirements have been met.

### 3.2.3 Safety Analysis {#safety-analysis .unnumbered}

The analyses described in the following sections are typical hazard
analysis techniques. The following analyses shall be performed.

#### 3.2.3.1 Preliminary Hazard Analysis {#preliminary-hazard-analysis .unnumbered}

The purpose of this task is to perform and document a Preliminary Hazard
Analysis (PHA) to identify safety critical areas, to provide an initial
assessment of hazards, and to identify requisite hazard controls and
follow-on actions.

The developer shall perform and document a PHA in accordance with (CDRL
SA-4) to obtain an initial risk assessment of a concept or system. Based
on the best available data, including mishap data from similar systems
and other lessons learned, hazards associated with the proposed design
or function shall be evaluated for hazard severity, hazard probability,
and operational constraint. Safety provisions and alternatives needed to
eliminate hazards or reduce their associated risk to a level acceptable
to Range Safety shall be included.

**3.2.3.2 Operations Hazards Analyses**

The developer shall prepare an Operations Hazard Analysis (OHA) which
describes the hardware and test equipment operations. The OHA shall be
prepared in accordance

with (CDRL SA-5), demonstrate that the planned I&T activities are
compatible with the facility safety requirements, and that any inherent
hazards associated with those activities is mitigated to an acceptable
level. GSFC Code 302 is responsible for reviewing and approving the OHA.
GSFC Code 302 shall also review all Work Order Authorizations (WOAs).
Hazardous WOAs generated during I&T activities require GSFC Code 302
approval. All hazardous operations must be witnessed by GSFC Code 302.

#### 3.2.3.3 Software Safety {#software-safety .unnumbered}

Hazards caused by software shall be identified as a part of the nominal
hazard analysis process, and their controls shall be verified prior to
acceptance. Hazard analysis recommendations typically require the
software developer to demonstrate that adequate inhibits and/or controls
are incorporated to eliminate or mitigate hazards to an acceptable
level. Additional independent assessment may be required by the
Government as dictated by the hazard probability and severity. Section
5.2.2 describes desired software safety activities to meet NASA HQ
guidelines.

## 3.3 Safety Assessment Report {#safety-assessment-report .unnumbered}

The instrument or subsystem developer shall perform and document a
comprehensive evaluation of the mishap risk of their instrument or
system. This report is used to assist the spacecraft
developer/integrator in preparing the MSPSP for submittal to the launch
range. This Safety Assessment Report (SAR) (refer to CDRL SA-8) shall
identify all safety features of the hardware, software, and system
design, as well as procedural related hazards present in the system.

It shall include:

a.  Safety criteria and methodology used to classify and rank hazards.

b.  Results of hazard analyses and tests used to identify hazards in the
    system.

c.  Hazard reports documenting the results of the safety program
    efforts.

d.  List of hazardous materials generated or used in the system.

e.  Conclusion with a signed statement that all identified hazards have
    been eliminated or controlled to an acceptable level.

f.  Recommendations applicable to hazards at the interface of their
    system.

## 3.4 Verification Tracking Log {#verification-tracking-log .unnumbered}

The instrument developer shall establish a "closed loop" process for
tracking all hazards to acceptable closure through the use of a
Verification Tracking Log (VTL) (see CDRL SA-9). The VTL shall be
delivered with the final SAR and updated regularly as requested until
all items are closed. Individual VTL items shall be closed with
appropriate documentation verifying

## 3.5 Ground Operations Procedures {#ground-operations-procedures .unnumbered}

The developer shall submit, in accordance with the contract schedule,
all ground operations procedures (see CDRL SA-10) to be used at GSFC
facilities, other integration facilities, or the launch site. All
hazardous operations, as well as the procedures to control them, shall
be identified and highlighted. All launch site procedures shall comply
with the launch site and NASA safety regulations. GSFC Code 302 will
review and approval all hazardous procedures before submittal to the
launch range.

## 3.6 Safety Variance {#safety-variance .unnumbered}

When a specific safety requirement cannot be met, the developer shall
submit an associated safety variance, per NASA Procedural Requirement
(NPR) 8715.3 and CDRL SA-11, which identifies the hazard and shows the
rationale for approval of a variance. The following definitions apply to
the safety variance approval policy:

a.  Variance: Documented and approved permission to perform some act or
    operation contrary to established requirements.

b.  Deviation: A documented variance that authorizes departure from a
    particular safety requirement that does not strictly apply or where
    the intent of the requirement is being met through alternate means
    that provide an equivalent level of safety with no additional risk.
    The OSHA requirements (1910 29 Code of Federal Regulations \[CFR\])
    term for deviation is alternate or supplemental standard only when
    it applies to OSHA requirements.

c.  Waiver: A variance that authorizes departure from a specific safety
    requirement where a special level of risk has been documented and
    accepted.

All requests for variance will be accompanied by documentation as to why
the requirement cannot be met, what risks are involved, alternative
means to reduce the hazard or risk, the duration of the variance, and
comments from any affected employees or their representatives (if the
variance affects personal safety).

## 3.7 Support for Safety Meetings {#support-for-safety-meetings .unnumbered}

Technical support shall be provided to the Project for Safety Working
Group (SWG) meetings, Technical Interface Meetings (TIMs), and technical
reviews, as required. The SWG will meet as necessary to review
procedures and analyses that contain or examine safety critical
functions, or as convened by GSFC Code 302 to discuss any situations
that may arise with respect to overall project safety. Meetings are
normally held as a sidebar to other reviews and meetings, to minimize
extra travel. There is no required number of meetings.

## 3.8 Orbital Debris Assessment {#orbital-debris-assessment .unnumbered}

The Instrument developer shall supply to GSFC, the information required
to support the Orbital Debris Assessment consistent with NASA Policy
Directive (NPD) 8710.3, "Policy for Limiting Orbital Debris Generation,"
and NASA Safety Standard (NSS) 1740.14, "Guidelines and Assessment
Procedures for Limiting Orbital Debris," in accordance with the CDRL.
Design and safety activities shall take into account the observatory's
ability to conform to debris generation requirements. The Orbital Debris
support data shall be prepared in accordance with CDRL SA-12.

**3.9 PRE-MISHAP PLAN DOCUMENT**

The Instrument developer shall provide a Pre-Mishap Plan (CDRL SA-25)
prior to initiating any project operations with potential for personnel
injury or flight hardware damage. This includes any GSE loss or damage
that could cause a flight delay or be of high value.

## 3.10 Launch Site Safety Support {#launch-site-safety-support .unnumbered}

The instrument developer shall provide and coordinate manpower
requirements for safety support of all operations at the launch site.
Range safety is not responsible for project safety support at the launch
ranges. Safety support of hazardous I&T operations performed at the
launch site needs to be planned and budgeted for by the project.

## 3.11 Mishap Reporting and Investigation {#mishap-reporting-and-investigation .unnumbered}

All mishaps, incidents, hazards, and close calls shall be reported to on
NASA Form NF1627 or equivalent form, per NPR 8621.1, "NASA Procedures
and Guidelines for Mishap Reporting, Investigating, and Recordkeeping."

## 3.12 Miscellaneous Submittals for Range Use {#miscellaneous-submittals-for-range-use .unnumbered}

The Instrument developer shall provide information to the spacecraft
integrator and GSFC as necessary to support generation of the following
forms required by Range Safety.

-   Material Selection List for Plastic Films, Foams, and Adhesive Tapes
    --
    (<http://rtreport.ksc.nasa.gov/techreports/95report/msf/ms10.html>).
    The list is published in GP-1098, KSC Ground Operations Safety Plan,
    Volume I, Safety Requirements, and is updated quarterly. Materials
    are evaluated for electrostatic discharge (ESD), flammability, and
    compatibility with hypergols. (Ship-60 day to GSFC)

-   Radiation forms/analysis -- KHB 1860.1 (KSC Ionizing Radiation
    Protection Program) and KHB 1860.2 (KSC Non-Ionizing Radiation
    Protection Program) includes forms for ionizing and non-ionizing
    radiation from Radio Frequency (RF), light, laser, and radioactive
    sources.  Forms must be completed to provide information on the
    radiation source(s) and the source user(s).  Procedures must also be
    submitted. (Ship-120 days to GSFC)

-   Process Waste Questionnaire (PWQ) (Kennedy Space Center
    \[KSC\]/Eastern Range Only) -- PWQ records all the hazardous
    materials that are brought to the range with the payload. Specific
    information on storage, containment, and spill control are required.
    (Ship- 60 days to KSC/Eastern Test Range \[ETR\])

# Reliability and Probabilistic Risk Assessment 

## General Requirements

The developer shall implement a reliability program applicable to the
development of all software and hardware products and processes.

### Reliability Program Plan

The developer shall provide with the proposal a Reliability Program Plan
(CDRL SA-7) describing the planned approach and schedule for the project
reliability activities, including the support and analyses they will
provide to the developer of the mission level Probabilistic Risk
Assessment (PRA). The developer shall identify in the plan the
reliability tasks to be performed and how those tasks will be
implemented and controlled. The developer shall discuss the scheduling
of the reliability tasks relative to project milestones. The developer
shall ensure reliability functions are an integral part of the design
and development process and the reliability functions interact
effectively with other project disciplines, including systems
engineering, hardware design, and product assurance. The developer shall
describe how reliability assessments are integrated with the design
process and other assurance practices. The developer shall describe how
failure definitions and alternate and degraded modes of operations that
include credible failure conditions could be mitigated by implementing
workarounds. The developer shall describe the integration of reliability
activities with the probabilistic risk assessment process. The developer
shall ensure that system elements obtained from sub-developers and
suppliers meet project reliability requirements, and shall ensure all
subcontracts include provisions for review and evaluation of the
sub-developers' and suppliers' reliability efforts by the prime
developer at the prime developer's discretion, and by GSFC at its
discretion. The plan shall be updated as required.

### 4.1.2 Probabilistic Risk Assessment {#probabilistic-risk-assessment .unnumbered}

The developer shall support the development of a Limited Scope
Probabilistic Risk Assessment (PRA) commensurate with a Class B mission
as defined in NPR 8705.4, Risk Classification for NASA Payloads, and in
accordance with the requirements of NPR 8705.5, Probabilistic Risk
Assessment (PRA) Procedures for NASA Programs and Projects. The
developer shall support the PRA development by providing instrument
related analyses (PRA inputs) that are integral to the mission level
PRA. A limited scope PRA is of the same general rigor as a full-scope
PRA, but focuses on the mission-related end-states of specific
decision-making interest, instead of all applicable end states.

Potential candidates for PRA analyses may come from mission operational
working group meetings, reliability working group (RWG) meetings, safety
hazard analyses, instrument and observatory FMEA, Instrument and
Spacecraft Reliability Prediction Analyses, I&T Problem reports, etc.
The instrument developer shall identify and use the appropriate types of
analyses

for each scenario modeled, and the modeling tools and techniques to be
used (e.g., Master Logic Diagrams (MLD), Failure Mode and Effects
Analysis (FMEA), Fault Tree Analyses (FTA), Event Tree Analyses (ETA),
and/or Event Sequence Diagrams).

The developer shall use the PRA process to quantify risk and
uncertainties associated with identifying pivotal events or scenarios
that may cause a mission-ending failure or human safety hazardous
condition. The developer shall support the implementation of the PRA
procedures across every phase of the instrument life cycle.

The developer shall submit the PRA inputs (CDRL SA-13) to the project
office for approval, and shall present a summary of the PRA inputs at
all instrument design reviews, beginning with the Instrument Preliminary
Design Review (IPDR). Presentations shall include design trade-study
results and PRA results impacting design or risk decisions.

### Design Reviews and Readiness Reviews

The developer's activities shall include support of internal and
supplier design reviews at the system, subsystem, and component levels
and NASA design and readiness reviews. This activity shall include an
assurance function for compliance of the design to the design criteria
defined for the instrument, subsystems and component levels.

### Reliability Working Group Participation

The developer shall provide technical support to the Project for
Reliability Working Group (RWG) meetings and technical reviews, as
required.

The RWG will meet as necessary, and as convened by Government project
personnel, to review reliability requirements and analyses, to assist in
resolving reliability issues and concerns, and to discuss any situations
that may arise with respect to overall mission reliability.

### Reliability Progress Reporting

The developer shall report on the progress of the reliability effort
through monthly status reports and periodic management meetings.

## Reliability Analyses

The developer shall ensure that reliability analyses are performed
during the design phase so that identified problem areas can be
addressed and any required corrective action can be taken in a timely
manner. The developer shall perform the following analyses for the
instrument and shall support associated mission-level activities.

### Failure Modes and Effects Analysis, Critical Items List, and Critical Items Control Plan

The developer shall perform a Failure Modes and Effects Analysis (FMEA)
early in the design phase to identify potential instrument failure modes
during each phase of the mission, and the effect of those failures on
related systems and the mission. As changes to the design are made, the
developer shall revise the FMEA to reflect the current design. Failure
modes shall, at a minimum, be assessed at the circuit card level,
assessing each potential failure mode for the effect at the level of
analysis (circuit level), the next higher level, and the mission level.
The FMEA shall be performed in accordance with CDRL SA-14.

Severity categories shall be determined in accordance with Table 4-1:

[]{#__RefHeading___Toc23396477 .anchor}Table 4‑1. Severity Categories

  ----------------------------------------------------------------------------
  **Category**   **Severity Description**
  -------------- -------------------------------------------------------------
  1              Catastrophic Failure modes that could result in serious
                 injury, loss of life (flight or ground personnel), or loss of
                 launch vehicle.

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

  1S             Failure in a safety or hazard monitoring system that could
                 cause the system to fail to detect a hazardous condition or
                 fail to operate during such condition and lead to Category 1
                 consequences.

  2              Critical Failure modes that could result in loss of one or
                 more mission objectives as defined by the GSFC project
                 office.

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

  3              Significant Failure modes that could cause degradation to
                 mission objectives

  4              Minor failure modes that could result in insignificant or no
                 loss to mission objectives.
  ----------------------------------------------------------------------------

Failure modes resulting in severity categories 1, 1R, 1S or 2 shall be
analyzed at a greater depth, to single parts if necessary, to identify
the cause of failure.

A Critical Items List shall be developed from those failure modes that
could result in serious injury, loss of life or loss of launch vehicle
whether the result of single point failures or redundant failures, and
shall include single point failures that could result in loss of one or
more mission objectives. For each critical item, retention rationale
shall be provided that describes justification for retaining the
potential failure in the design. Retention rationale shall consist of
design features, test, inspection, heritage and flight history,
operational considerations, workarounds, etc., that reduce the
likelihood of the failure occurring and reduce the potential
consequences if the failure occurs.

The developer shall develop a Critical Items Control Plan (CDRL SA-15)
which identifies the Critical Items List and the specific controls used
to mitigate risks associated with each critical item. The Critical Items
Control Plan shall require specific, traceable, and verifiable
procedures be introduced into the design, manufacturing and test phases
of the program to control and reduce the likelihood that critical items
will fail on orbit. The Critical Items Control Plan shall also provide
retention rationale for each critical item that describes justification
for retaining the potential failure in the design.

Retention rationale shall consist of design features, test, inspection,
heritage and flight history, operational considerations, workarounds,
etc., that reduce the likelihood of the failure occurring and reduce the
potential consequences if the failure occurs.

The developer shall present results of the FMEA and CIL at all design
reviews, beginning with the Instrument Preliminary Design Review (IPDR).
Presentations shall include design trade-study results and FMEA results
impacting design or risk decisions.

### Fault Tree Analysis

The developer shall prepare Fault Tree Analyses (FTAs), in accordance
with CDRL SA-16, that address both mission failures and degraded modes
of operation as pertains to the instrument. FTA's shall be performed and
integrated as part of the PRA inputs. Component hardware/software
failures, external hardware/software failures, and human factors shall
be considered in the analysis.

The developer shall present results of the FTA at all design reviews,
beginning with the Instrument Preliminary Design Review (IPDR).
Presentations shall include design trade-study results and FTA results
impacting design or risk decisions.

### Parts Stress Analyses

The developer shall perform stress analyses on Electrical, Electronic,
and Electromechanical (EEE) parts and devices, as applied in circuits
within each component for conformance with EEE-INST-002. The analyses
shall be performed in accordance with CDRL SA-22. The analyses shall be
performed at the most stressful part-level parameter values that can
result from the specified performance and environmental requirements on
the assembly or component. The analyses shall be performed in close
coordination with the packaging reviews and shall be required input data
for component-level design reviews. The analyses shall be documented and
maintained current to the latest design. The developer shall provide the
analyses, summary sheets, and revisions to the Project Office for
approval. Analyses results shall be presented at all design reviews
beginning with PDR. Presentations shall include design trade-study
results and Parts Stress Analyses results impacting design or risk
decisions.

### Worst-Case Analyses

The developer shall perform worst-case analyses in accordance with CDRL
SA-23 for mission or science-critical parameters that are subject to
variations that could degrade instrument performance, where failure
results in a severity category of 2 or higher, and provides data that
question the flightworthiness of the design. Analyses or test or both
shall demonstrate adequacy of margins in the design of electronic
circuits, optics, electromechanical and mechanical items (mechanisms).
The analyses shall consider all parameters set at worst‑case limits due
to manufacturing variability and worst‑case environmental (including
radiation) and aging stresses for the parameter or operation being
evaluated. The analyses shall be updated in keeping with design changes.
The developer shall provide the analyses, summary sheets, and revisions
to the Project Office for approval. The analyses and updates shall be
presented at all design reviews beginning with PDR. Presentations shall
include design trade-study results and Worst Case Analysis results
impacting design or risk decisions..

### Numerical Assessments and Predictions

The developer shall perform comparative numerical assessments and/or
reliability predictions to:

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

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

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

4.  Evaluate the design in terms of mission success requirements

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

The developer shall describe in their assessments the level of detail of
a model suitable for performing the intended functions enumerated above.
The results of the reliability assessments shall be reported at design
reviews starting with IPDR. 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.

### Limited-Life Items Plan 

The developer shall provide a plan to identify and manage limited life
items. The developer shall submit the Limited-Life Items Plan in
accordance with CDRL SA-24. In the plan, the developer shall define
limited-life items, the impact on mission parameters, responsibilities
for mitigating limited-life items, and provide a list of limited-life
items, including data elements as follows:

-   Expected life

-   Required life

-   Duty cycle

-   Rationale for selection

The useful life period starts with fabrication and ends with completion
of final orbital mission, including the disposal phase.

The developer shall list limited-life items including selected
structures, thermal control surfaces, solar arrays and electromechanical
mechanisms. The developer shall consider atomic oxygen, solar radiation,
shelf-life, extreme temperatures, thermal cycling, wear and fatigue to
identify limited-life thermal control surfaces and structure items; the
developer shall include mechanisms such as batteries, compressors,
seals, bearings, valves, tape recorders, momentum wheels, gyros,
actuators and scan devices when aging, wear, fatigue and lubricant
degradation limit their life.

The developer shall maintain records allowing for evaluation of
cumulative stress (time and cycles) for limited-life items, starting
when useful life is initiated, and indicating the project activity that
stresses the items.

The developer shall obtain a program waiver approval by GSFC when the
use of an item whose expected life is less than its mission design life.

## Reliability Analysis of Test Data

The developer shall fully utilize test information during the normal
test program to assess reliability performance and identify potential or
existing problem areas.

### Trend Analyses

Parameter trend analyses is a companion approach to analytical
reliability models. In general, known values of certain parameters can
directly impact component or systems reliability, even though the exact
quantitative relationship may not have been determined. Those measurable
parameters that directly affect system or component reliability, when
sampled over time can be examined to determine if there is a pattern of
deviation over time (i.e., a trend) from acceptable performance limits.
In this manner, it may be possible to predict future parameter values,
or at least estimate the long-term range of values of these influential
variables. Thus, if these parameters are trending towards hazardous or
unacceptable levels, the potential problem could be identified prior to
the occurrence of high-risk situations.

The developer shall assess subsystems and components to determine
measurable parameters that relate to performance stability and
reliability. The developer shall monitor selected parameters for trends
starting at component acceptance testing and continuing during the
system integration and test phases. The developer shall ensure
monitoring is accomplished within the normal test framework; i.e.,
during functional tests and environmental tests. The developer shall
establish a system for recording and analyzing the parameters as well as
any changes from the nominal (even if the levels are within specified
limits). The developer shall maintain and submit a list of subsystem and
components to be assessed, parameters to be monitored, and trend
analysis reports in accordance with CDRL SE-3. The developer shall
provide a list of parameters to be monitored at the CDR. The developer
shall provide trend analysis reports at the Pre-Environmental Review
(PER) and Flight Readiness Review (FRR).

### Analysis of Test Results

The developer shall analyze test information, trend data and failure
investigations to evaluate reliability implications. The developer shall
document identified problem areas, and ensure developer management takes
corrective action. The developer shall include this information in
progress reports to the Project, or in a separate monthly report. The
developer shall report results of analyses at design reviews. The
developer shall address in the report design trade studies and
reliability prediction results impacting design or risk decisions.

## Control of Sub-Developers and Suppliers

The developer shall ensure that system elements obtained from
sub-developers and suppliers meet project reliability requirements. All
subcontracts shall include provisions for review and evaluation of the
sub-developers' and suppliers' reliability efforts by the prime
developer at the prime developer's discretion, and by GSFC at its
discretion. The developer shall tailor the reliability requirements of
this document in hardware and software subcontracts for the project. The
developer shall exercise necessary surveillance to ensure that
sub-developer and supplier reliability efforts meet overall system
requirements.

The developer shall ensure the tailored requirements:

-   Incorporate quantitative reliability requirements in subcontracted
    equipment specifications.

-   Assure that sub-developers have reliability programs that are
    compatible with the overall program

-   Review sub-developer assessments and analyses for accuracy and
    correctness of approach.

-   Review sub-developer test plans, procedures and reports for
    correctness of approach and test details.

-   Attend and participate in sub-developer design reviews.

-   Ensure that sub-developers, during the project operational phase,
    comply with the applicable system reliability requirements.

## Reliability of Government Furnished Equipment

When the overall system includes components or other elements furnished
by the Government, the developer shall be responsible for identifying
and requesting from the Project Office adequate reliability data on the
items. The developer shall use the reliability data provided by the
Project Office to perform the reliability analyses. The developer shall
formally notify the Project Office promptly when examination of the data
or testing by the developer indicates that the reliability or
maintainability of Government Furnished Equipment is inconsistent with
the reliability requirements of the overall system

## Software Reliability

Refer to Section 5.5 for software reliability requirements.

# Software Assurance Requirements

## General

For the purposes of this section, all references to the developer shall
include the prime software developer, as well as any subcontractors
tasked in the development process.

## Software Assurance

The developer's Software Assurance program shall address software
assurance disciplines (i.e., Software Quality, Software Safety, Software
Reliability, Verification and Validation, and Independent Verification
and Validation) and functions for all flight and ground system software.
The software assurance program shall apply to software and firmware
developed under this contract, including Government off-the-shelf (GOTS)
software, modified off-the-shelf (MOTS) software, and commercial
off-the-shelf (COTS) software when included in a NASA system.

The developer shall identify a person responsible for directing and
managing the Software Assurance Program (e.g., a software assurance
manager). The developer shall document in The instrument Systems
Assurance Plan (CDRL SA-1) how the Software Assurance Requirements will
be met.

## Software Quality 

The developer shall implement a Software Quality program to assure the
quality of the software products and software processes. The function of
software quality assurance assures that the standards, processes, and
procedures correctly implemented and appropriate to the project.
Software quality control assures adherence to those software
requirements, plans, procedures and standards.

Product assurance activities shall be performed to assure:

-   Standards and procedures for management, software engineering and
    software assurance activities are defined.

-   All plans (e.g., Configuration Management \[CM\], Risk Management,
    Software Management Plan) required by the contract are documented
    and comply with contractual requirements.

-   Standards, design, and code are evaluated for quality and issues.

-   All software requirements are documented and traceable from system
    requirements to design, code and test (i.e., a software requirements
    traceability matrix).

-   Software requirement verification status is updated and maintained
    via a software requirements verification matrix.

-   Formal and acceptance-level software tests are witnessed to assure
    satisfactory completion and maintenance of test artifacts.

-   Software products and related documentation (e.g., Version
    Description Documents \[VDD\] and User Guides) have the required
    content and satisfy their contractual requirements.

-   Project documentation, including plans, procedures, reports,
    schedules and records are reviewed for impact to the quality of the
    product.

-   Software quality metrics are captured, analyzed, and trended to
    ensure the quality and safety of the software products.

Process assurance activities shall be performed to assure:

-   Management, software engineering, and assurance personnel adhere to
    specified standards and procedures and comply with contractual
    requirements.

-   All plans (e.g., CM, Risk Management, and Software Management Plan)
    and procedures are implemented according to specified standards and
    procedures.

-   Contract requirements are passed down to any subcontractors, and
    that the subcontractor's software products satisfy the prime
    developer's contractual requirements.

-   Engineering peer reviews (e.g., design walkthroughs and code
    inspections) and software milestone reviews are conducted and action
    items are tracked to closure.

-   A software problem reporting system and corrective action process is
    in place and provides the capability to document, search, and track
    software problems and anomalies.

-   The software is tested to verify compliance with functional and
    performance requirements.

-   Software safety processes and procedures are followed.

-   Management, software engineering, and assurance personnel have
    received proper software assurance training.

## Software Safety

The developer shall ensure that safety considerations are integrated
with the overall software assurance and systems safety program and is
compliant with the software safety requirements of NASA-STD-8719.13. The
developer shall ensure that their approach to the software safety
program is documented in the System Safety Program Plan as appropriate.

The developer shall ensure that software safety requirements are clearly
identified, documented, tracked, and controlled throughout the
lifecycle. The developer shall identify potential hazards and ensure
implementation of safety critical requirements. The developer shall test
all software safety critical components on actual hardware to ensure
that the safety requirements were sufficiently implemented and that
applicable controls are in place to verify all safety conditions. The
developer shall document in operational documentation all safety-related
commands, data, input sequences and workarounds necessary for the safe
operation of the system. The developer shall report on all software
safety requirements, software safety issues and risks at all formal
system-level reviews.

For software deemed software safety critical, the developer shall
identify and document the software safety critical classification of
each item in terms of criticality, severity, associated risks, and
likelihood of occurrence. Software safety requirements shall also be
clearly identified and distinguishable in the software requirements
traceability matrix. The developer shall test all software safety
critical components on actual hardware to ensure that the safety
requirements were sufficiently implemented and that applicable controls
are in place to verify all safety conditions.

The developer shall continually monitor, assess, and review the software
development efforts for changes that may affect the safety critical
classification of the software and as necessary update engineering
analyses to reflect these changes.

## Software Reliability

The developer shall ensure that software reliability is incorporated
into their software products. The software reliability program shall be
tailored t the appropriate level based upon criticality of the software
to the mission, software safety criticality, software complexity, size,
cost, consequence of failure, and other attributes. The developer shall
ensure that appropriate activities are planned to support the
achievement and verification of the developer's software reliability
requirements. Refer to IEEE Standard 982.1-1988, IEEE Standard
Dictionary of Measures to Produce Reliable Software, for methods to
evaluate software reliability.

## Verification and Validation

a.  The developer shall plan and implement a Verification and Validation
    (V&V) program in accordance with the SOW Paragraph 4.2.1.2.1.

## Independent Verification and Validation

The developer shall support NASA IV&V activities in accordance with the
SOW paragraph 4.2.1.4.

## GFE, Existing and Purchased Software 

If the developer is provided software as government-furnished equipment
(GFE), or will use existing or purchased software and firmware, the
developer shall verify that the software and firmware meets the
functional, performance, and interface requirements placed upon it. The
developer shall ensure that the software and firmware meets applicable
standards, including those for design, code, and documentation, or shall
secure a LDCM Project waiver to those standards. Any significant
modification to any piece of the existing software shall be subject to
the provisions of the developer's quality management system and the
provisions of this document. A significant modification is defined as
the change of twenty percent of the lines of code in the software.

# Risk Management Requirements

## General

The Developer shall develop and implement a project-specific Risk
Management Plan (RMP) (Section 7.3) as a means to anticipate, mitigate
and control risks and to focus project resources to ensure success of
the project. The NPR 7120.5, "NASA Program and Project Management
Processes and Requirements," is the controlling requirements used in the
preparation of this plan.

The primary activities of the Developer Continuous Risk Management (CRM)
process are:

a.  Search for, locate, identify, and document reliability and quality
    risks before they become problems.

b.  Evaluate, classify, and prioritize all identified reliability and
    quality risks.

c.  Develop and implement risk mitigation strategies, actions, and tasks
    and assign appropriate resources.

d.  Track risk being mitigated; capture risk attributes and mitigation
    information by collecting data; establish performance metrics; and
    examine trends, deviations, and anomalies.

e.  Control risks by performing: risk close-out, re-planning,
    contingency planning, or continued tracking and execution of the
    current plan.

f.  Communicate and document (via the risk recording, reporting, and
    monitoring system) risk information to ensure it is conveyed between
    all levels of the project.

g.  Report on outstanding risk items at all management and design
    reviews.

The GSFC Project Office, the GSFC SRO (for design reviews only), and the
Instrument Developer will agree on what level of detail is appropriate
for each review.

All identified reliability and quality risks will be documented and
reported on in accordance with the Instrument Developer's Risk
Management Plan. Although not all risks will be fully mitigated, all
risks shall be addressed with mitigation and acceptance strategies
agreed upon at appropriate mission reviews.

## Applicable Documents

GPR 1060.2 Management Review and Reporting for Programs and Projects

GPR 8700.4 Integrated Independent Reviews

NPR 5100.4 Federal Acquisition Regulation Supplement

NPR 7120.5 Program and Project Management Processes and Requirements

NPR 8000.4 Risk Management Procedural Requirements

NPR 8715.3 NASA Safety Manual

## Risk Management Plan

The Developer shall document the project-specific implementation of the
CRM process in a RMP in accordance with CDRL PM-12. Preparation of the
RMP is a requirement established by NPR 7120.5 and includes the content
shown in NPR 8000.4, "Risk Management Procedural Requirements." The plan
shall include risks associated with hardware and software (e.g.,
technical challenges, new technology qualification, etc.), COTS, system
safety, performance, cost and schedule (i.e., programmatic risks). The
plan shall identify which tools and techniques will be used to manage
the risks.

All identified risks shall be documented and reported in accordance with
the project's RMP. Identified risk areas shall be addressed at project
status reviews and at Integrated Independent Reviews (GPR 8700.4). Risk
status shall be available to all members of the project team for review.
Although not all risks will be fully mitigated, all risks shall be
addressed with mitigation and acceptance strategies agreed upon at
appropriate mission reviews.

## Risk List

The developer shall maintain a Risk List throughout the project life
cycle, along with programmatic impacts. The list should indicate which
risks have the highest probability, which have the highest consequences,
and which risks represent the greatest risk to mission success. The list
should also identify actions being taken to address each specific risk.
The Risk List shall be configuration controlled.

Risk status shall be communicated on a regular basis to the entire
project team and customers. Risk status shall be communicated to the
Governing Program Management Council (GPMC) through the MSRs.

For each primary risk (those having both high probability and high
impact/severity), the Developer shall prepare and maintain the following
in the risk sections of the Program/Project Plans:

-   Description of the risk, including primary causes and contributors,
    current mitigation strategy, and information collected for tracking
    purposes.

-   Primary consequences should the undesired event occur.

-   Estimate of the probability of occurrence (qualitative or
    quantitative) together with the uncertainty of the estimate and the
    effectiveness of any implemented risk mitigation measures.

-   Potential additional risk mitigation measures, which shall include a
    comparison of the cost of risk mitigation versus the cost of
    occurrence multiplied by the probability of occurrence.

-   Characterization of a primary risk as "acceptable" shall be
    supported by a rationale (with the concurrence of the GPMC) that all
    reasonable mitigation options (within cost, schedule, and technical
    constraints) have been instituted.

## Risk-Based Acquisition Management

GSFC projects shall incorporate the requirements of the Risk-Based
Acquisition Management (RBAM) initiative as part of the CRM process. The
purpose of RBAM is to convey NASA's focus on safety and mission success
to NASA contractors.

Acquisition planning shall incorporate input from GSFC personnel
responsible for safety and mission assurance, health, environmental
protection, information technology, export control, and security.

When technical proposals are required as part of requests for proposals
for supplies or services, offerors shall be instructed to identify and
discuss risk factors and their approach for managing those risk factors
(see NFS 1815.201 and NSF 1815.203-72). Where the solicitation requires
submission of a Safety and Health Plan (see NFS 1823.7001(c)), safety
and health shall be considered in the evaluation process (also see NFS
1815.305).

QA surveillance plans are required and prepared with the SOW for all
performance based contracts and, as necessary, for other contracts.
Those plans shall reflect a specific surveillance approach that is
commensurate with the perceived risk. The plans are general at the
outset, but after contract award, contracting officers shall ensure that
the plans are revised to reflect the risks associated with the
successful proposal (see NFS 1846.401).

# Integrated Independent Review Requirements

## General Requirements

The developer shall support a series of comprehensive system-level
technical reviews that will be conducted by the GSFC Office of Systems
Safety and Mission Assurance (OSSMA) Systems Review Office (SRO). These
reviews cover all aspects of flight and ground hardware, software, and
operations for which the developer has responsibility. In addition, each
developer shall conduct a program of peer reviews at the component and
subsystem level.

For each specified review conducted by the GSFC SRO, the developer
shall:

a.  Develop and organize material for oral presentation to the GSFC
    review team. Copies of the presentation material will be made
    available as specified in the instrument CDRL.

b.  Support splinter meetings resulting from the review.

c.  Produce timely written responses to recommendations and action items
    resulting from the review.

d.  Summarize, as appropriate, the results of the engineering peer
    reviews conducted by the developer.

## Instrument Reviews

Reviews required for LDCM instruments are specified in paragraph 1.2 in
the instrument Statement of Work.

## Peer Reviews

The Developer shall implement a program of peer reviews at the component
and subsystem levels. In addition, packaging reviews shall be conducted
on all electrical and electromechanical components in the flight system.

The packaging reviews shall specifically address the following:

a.  Placement, mounting, and interconnection of EEE parts on circuit
    boards or substrates.

b.  Structural support and thermal accommodation of the boards,
    substrates, and their interconnections in the component design.

c.  Provisions for protection of the parts and ease of inspection.

The Developer peer reviews shall be conducted by personnel who are not
directly responsible for design of the hardware under review. The GSFC
Project Office and SRO shall be invited to attend the peer reviews, and
shall be provided ten working days notification.

The peer reviews shall have RFA item recordation which are reviewed and
assigned to appropriate personnel at the end of the reviews. The
Developer team is required to submit written responses to
recommendations and action items resulting from the reviews to GSFC in a
timely manner.

The results of the reviews will be documented and the documents will be
made available for review.

# Design Verification Requirements

## General

The developer shall conduct a Verification Program to ensure that the
flight system meets the specified mission requirements. The program
shall consist of functional demonstrations, analytical investigations,
physical measurements and tests that simulate all expected environments.

The Design Verification Requirements are contained in the LDCM
Environmental Verification Requirements (LEVR) Document and the
instrument Statement of Work (SOW).

## Documentation Requirements

The documentation requirements applicable to design verification are
included in the instrument Statement of Work.

## Performance Operating Time and Failure-Free Performance Testing

Performance operating time and failure-free performance testing shall
meet the requirements specified in the LDCM Environmental Verification
Requirements (LEVR) (427-xx-xxx-xxx) in section 2.3.4.

# Workmanship Standards

## General

The developer shall plan and implement a Workmanship Program to assure
that all electronic packaging technologies, processes, and workmanship
activities selected and applied meet mission objectives for quality and
reliability. See Section 13 for additional information on ESD control.

## Applicable Documents

The current status and/or any application notes for these standards can
be can be found at http://workmanship.nasa.gov/. The most current
version of these standards shall be used for new procurements. However,
if a specific revision is listed for a referenced standard, only that
revision is approved for use, unless otherwise approved by project
management.

[Conformal Coating and Staking]{.underline}:

NASA-STD-8739.1 "Workmanship Standard for Staking and Conformal Coating
of Printed Wiring Boards and Electronic Assemblies"

[Soldering - Flight, Surface Mount Technology]{.underline}:

NASA-STD-8739.2 "Workmanship Standard for Surface Mount Technology"

[Soldering - Flight, Manual (hand)]{.underline}:

NASA-STD-8739.3 "Soldered Electrical Connections"

[Soldering - Ground Systems]{.underline}:

IPC/ EIA J-STD-001C "Requirements for Soldered Electrical and Electronic
Assemblies"

[Electronic Assemblies -- Ground Systems]{.underline}:

IPC-A-610 "Acceptability of Electronic Assemblies"

[Crimping, Wiring, and Harnessing]{.underline}:

NASA-STD-8739.4 "Crimping, Interconnecting Cables, Harnesses, and
Wiring"

[Fiber Optics]{.underline}:

NASA-STD-8739.5 "Fiber Optic Terminations, Cable Assemblies, and
Installation"

[ESD Control]{.underline}:

ANSI/ESD S20.20 "Protection of Electrical and Electronic Parts,
Assemblies and Equipment" (excluding electrically initiated explosive
devices)

[Printed Wiring Board (PWB) Design]{.underline}:

IPC-2221 "Generic Standard on Printed Board Design"

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

IPC-2223 "Sectional Design Standard for Flexible Printed Boards"

[PWB Manufacture]{.underline}:

IPC A-600 "Acceptability of Printed Boards"

IPC-6011 "Generic Performance Specification for Printed Boards"

IPC-6012 "Qualification and Performance Specification for Rigid Printed
Boards"\
(Flight Applications supplemented with: GSFC/S312-P-003, "Procurement
Specification for Rigid Printed Boards for Space Applications and Other
High Reliability Uses")

IPC-6013 "Qualification and Performance Specification for Flexible
Printed Boards"

IPC-6018 "Microwave End Product Board Inspection and Test"

## Design

### Printed Wiring Boards

The PWB manufacturing and acceptance requirements identified in this
chapter are based on using PWBs designed in accordance with the PWB
design standards referenced above. Space flight PWB designs shall not
include features that prevent the finished boards from complying with
the Class 3 requirements of the appropriate manufacturing standard
(e.g., specified plating thickness, internal annular ring dimensions,
etc.).

Design of rigid PWBs shall not violate the requirements of the
Association Connecting Electronics Industries (IPC) 6012B Performance
Specification Sheet for Space and Military Avionics (PSSSMA). In the
event of a conflict between the IPC design specifications, the 6012B
Class 3 requirements, and the PSSSMA, the PSSSMA shall take precedence.

### Assemblies

The design considerations listed in the NASA Workmanship and IPC
standards listed above should be incorporated to the extent practical.

### Ground Support Equipment that Interface with Space Flight Hardware

Any portion of Ground Support Equipment (GSE) that mate with flight
hardware, that reside with space flight hardware in environments that
simulate a space flight environment (e.g. connectors, test cables,
etc.), or that interface directly with space flight hardware in any way,
shall be designed and fabricated using space flight parts, materials and
processes.

## Workmanship Requirements

### Training and Certification

All personnel working on flight hardware shall be certified as having
completed the required training appropriate to their involvement, as
defined in the above standards or, when approved by project management,
in the Developer's quality manual. This includes, but is not limited to,
the aforementioned workmanship and ESD standards. At a minimum,
certification shall include successful completion of formal training in
the appropriate discipline. Recertification shall be in accordance with
the requirements defined in the above workmanship standards.

### Flight and Harsh Environment Ground Systems Workmanship

#### Printed Wiring Boards

PWBs shall be manufactured in accordance with Class 3 requirements in
the above referenced IPC PWB manufacturing standards and the IPC 6012B
PSSSMA. In the event of a conflict, the requirements specified in the
IPC 6012B PSSSMA shall take precedence over all other specifications.
The Developer shall provide PWB test coupons to the GSFC Materials
Engineering Branch (MEB) or a GSFC/MEB approved laboratory for
evaluation. Coupon acceptance shall be obtained prior to population of
flight PWBs. Test coupons and test reports are not required for delivery
to GSFC/MEB if the Developer has the test coupons evaluated by a
laboratory that has been approved by the GSFC/MEB, however, they shall
be retained and included as part of the Project's documentation/data
deliverables package.

#### Assemblies

Assemblies shall be fabricated using the appropriate workmanship
standards listed above (i.e., NASA-STD-8739.3 for hand soldering;
NASA-STD-8739.4 for crimping/cabling; NASA-STD-8739.5 for fiber optic
termination and installation; NASA-STD-8739.2 for Surface Mount
Soldering, etc.) and ANSI/ESD S20.20.

### Ground Systems (Non-Flight) Workmanship

#### Printed Wiring Boards

Ground system PWBs not covered by Section 9.3.3 shall be manufactured in
accordance with the Class 3 requirements in the above referenced IPC PWB
manufacturing standards.

#### Assemblies

Assemblies shall be fabricated using the Class 3 requirements of
J-STD-001, IPC-A-610, and ANSI/ESD S20.20. If any conflicts between
J-STD-001 and IPC-A-610 are encountered, the requirements in J-STD-001
shall take precedence.

### Documentation

The developer shall document the procedures and processes that will be
used to implement the above referenced workmanship, design, and ESD
control standards; including any procedures or process requirements
referenced by those standards.

Alternate standards may be proposed by the developer. Proposals shall be
accompanied by objective data documenting that mission safety or
reliability will not be compromised. Their use is limited to the
specific project and allowed only after they have been reviewed and
approved by program management.

## New and Advanced Materials and Packaging Technologies

New and/or existing advanced materials and packaging technologies (e.g.,
multi-chip modules \[MCMs\], stacked memories, chip on board \[COB\],
ball grid array \[BGA\], etc.) shall be reviewed and approved by the
Government Parts Engineer for EEE parts or the Government Materials
Assurance Engineer (MAE) for materials and processes.

## Hardware Handling

The developer shall use proper safety, ESD control and cleanroom
practices (where appropriate) when handling flight hardware. The
electrostatic charge generation and contamination potential of
materials, processes, and equipment (e.g., cleaning equipment, packaging
materials, purging, tent enclosures, etc.) shall be addressed.

## Special Provisions

### Precision Component Assembly

When precise location of a component is required, the design shall use a
stable, positive location system (not relying on friction) as the
primary means of attachment.

### Capping of Test Points and Plugs

All test points and plugs shall be capped or protected from discharge
for flight.

### Electrical Connector Mating

Mating of all flight connectors which can not be verified via ground
tests, shall be clearly labeled and keyed uniquely, and mating of them
shall be verified visually to prevent incorrect mating.

### Solder Joint Intermetallics Mitigation

All materials at a solder joint shall be selected to avoid the formation
of potentially destructive intermetallic compounds.

# Materials and Process Requirements

## General Requirements

The developer shall develop and implement a Materials and Processes
Control Plan (MPCP) (CDRL SA-20) to be implemented by the beginning of
the hardware design stage. The MPCP shall be compliant with the specific
requirements of this section and the relevant LDCM surveillance,
documentation, safety and contamination control requirements specified
in other sections of this MAR. The plan shall document developer's
policies, procedures and guidelines for the selection, processing,
inspection, testing, procurement and control of materials, and
lubricants employed to meet the design and operational requirements of
the LDCM instrument. The Government shall approve developer materials,
lubrication usage, and associated manufacturing processes prior to their
use in spaceflight hardware.

Existing developer in-house documentation may be used and referenced in
the plan to address how these requirements are to be met, and shall be
submitted to the Government for approval. All appropriate sub-developers
shall participate in the MPCP to the extent required by the prime
developer and the Government in order to meet these requirements. The
plan shall address how the developer will ensure the flow down of
applicable MPCP requirements to sub-developers.

At the request of the Government, the developer shall deliver hardware
to the Government for direct or indirect examination. The Government
intends to make these requests on a non-interference basis. Direct
examinations may take the form of non-destructive evaluations such x-ray
fluorescence for plating thickness verification, or sample destructive
examinations such as total ionizing dose tests for microcircuits or
printed wiring board cross section examinations. Indirect examination
will be used when direct examination is not possible. Methods of
indirect examinations may include inspection of similar hardware
produced on the same production line by the same personnel as the flight
hardware.

## Materials Selection Requirements 

To qualify as a material compliant with intended spaceflight use, a
material shall have a satisfactory flight heritage, be approved by the
Government and meet the following applicable selection criteria as
defined herein for:

1\. Vacuum outgassing

2\. Stress corrosion cracking (SCC)

3\. Lubrication requirements

4\. Manufacturing process selection

5\. Fastener integrity

Thorough evaluation of the environmental effects of the trajectory
paths/orbits shall be assessed for the impact on materials selection and
design. The selection and use of material with hazardous properties
(such as flammability and toxicity) shall meet the requirements
specified in AFSCM 91-710 Range Safety User Requirements Manual,
Chapters 10 and 12.

A material that has limited spaceflight heritage or does not meet the
applicable selection requirements listed above shall be considered
non-compliant. In that case, if there are no alternatives available to
select a compliant material, the material's usage shall be justified for
the desired application on the basis of test, similarity, analyses,
inspection, existing data, or a combination of those data; Government
approval shall be obtained by the developer prior to use. Materials used
in structural applications shall be highly resistant to SCC as specified
in MSFC-STD-3029. A Materials Usage Agreement (MUA) (Figure 10-1) and/or
a Stress Corrosion Evaluation Form (Figure 10-2) shall be submitted to
the LDCM for approval for use of the proposed non-compliant material.
Both forms are required for a material that does not meet the SCC
requirements. The Developer may use their own forms if they contain
equivalent information and justification.

  --------------- ----------- -------------- -------- ------------- ---------- ---------- -------------- ------------- ------------- -------------- --------------- --------
  **MATERIAL                                          USAGE                                                                                         PAGE OF         
  USAGE                                               AGREEMENT                                                                                                     
  AGREEMENT**                                         NO.:                                                                                                          

  PROJECT:                    SUBSYSTEM:              ORIGINATOR:                                                                                   ORGANIZATION:   

  DETAIL DRAWING              NOMENCLATURE                                     USING                                                 NOMENCLATURE                   
                                                                               ASSEMBLY                                                                             

                                                                                                                                                                    

  MATERIAL &                                                                              MANUFACTURER &                                                            
  SPECIFICATION                                                                           TRADE NAME                                                                

                                                                                                                                                                    

  USAGE           THICKNESS                  WEIGHT                 EXPOSED                              ENVIRONMENT                                                
                                                                    AREA                                                                                            

                                                                                                         PRESSURE      TEMPERATURE                                  MEDIA

                                                                                                                                                                    

  APPLICATION:                                                                                                                                                      

  RATIONALE:                                                                                                                                                        

  ORIGINATOR:                                                       PROJECT                                                                         DATE:           
                                                                    MANAGER:                                                                                        
  --------------- ----------- -------------- -------- ------------- ---------- ---------- -------------- ------------- ------------- -------------- --------------- --------

[]{#__RefHeading___Toc23846281 .anchor}**Figure 10‑1. Material Usage
Agreement**

> 1\. Part Number
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 2\. Part Name
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 3\. Next Assembly Number
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 4\. Manufacturer
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 5\. Material
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 6\. Heat Treatment
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 7\. Size and Form
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 8\. Sustained Tensile Stresses-Magnitude and Direction
>
> a\. Process Residual
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> b\. Assembly
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> c\. Design, Static
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 9\. Special Processing
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 10\. Weldments
>
> a\. Alloy Form, Temper of Parent Metal
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> b\. Filler Alloy, if none, indicate
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> c\. Welding Process
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> d\. Weld Bead Removed - Yes ( ), No ( )
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> e\. Post-Weld Thermal Treatment
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> f\. Post-Weld Stress Relief
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 11\. Environment
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 12\. Protective Finish
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 13\. Function of Part
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 14\. Effect of Failure
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 15\. Evaluation of Stress Corrosion Susceptibility
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> 16\. Remarks:
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

[]{#__RefHeading___Toc23846282 .anchor}**Figure 10‑2. Stress Corrosion
Evaluation Form**

The developer shall create and maintain an As-Designed/As-Built
Materials and Processes (M&P) List of all materials planned for use in
the configured flight hardware (CDRL SA-21). This list shall include a
Polymeric Materials and Composites Usage List, an Inorganic Materials
and Composites Usage List, a Lubrication Usage List, and a Materials
Process Utilization List.

The initial M&P and subsequent updates shall be submitted for review and
approval. An As-Built M&P list shall also be prepared and submitted for
review and approval. The final M&P list is the As-Built materials list
that includes all materials, processes, and lubrication being used in
the as-built configured flight article designated to fly and as
delivered on-orbit.

Each materials list shall be an itemization of the materials, processes
and lubricants used in the configured flight article and shall contain
as a minimum the information in Figures 10-3 through 10-6, respectively.

In order to minimize materials and lubricant problems during use in
space hardware, the developers shall anticipate and consider potential
application problem areas during the material selection process.
Potential problem areas and application factors to be considered include
radiation effects, electrostatic discharging, thermal cycling, SCC,
galvanic corrosion, hydrogen embrittlement, lubrication, contamination
of cooled surfaces, composite materials, atomic oxygen , limited life,
vacuum outgassing, toxicity, flammability and fracture toughness, as
well as the properties required by each material usage or application.

### Inorganic Materials

The developer shall prepare and document an Inorganic Materials List
(Figure 10-3) or the Developer's equivalent. The list shall be submitted
as part of the M&P list. (CDRL SA-21)

![](media/image3.pct){width="5.998611111111111in"
height="1.3395833333333333in"}

[]{#__RefHeading___Toc23846283 .anchor}Figure 10‑3. Inorganic Materials
List

The use of tin, zinc, and cadmium platings in any flight application
requires an MUA prior to use of that material. Bright tin, cadmium, and
zinc platings have the potential for developing whisker growths. For
tin, these have been measured up to 12.5 microns in diameter and up to
10 millimeters (mm) in length. These whiskers can result in short
circuits, plasma arcing, and debris generation within the spacecraft.
Zinc and cadmium platings also evaporate in vacuum environments and may
redeposit on optics or electronics, posing potential risks to flight
hardware.

### Vacuum Outgassing of Polymeric Materials

Only materials that have a total mass loss (TML) less than 1.00% and a
collected volatile condensable mass (CVCM) less than 0.10% shall be
approved for use in a vacuum environment. Material vacuum outgassing
shall be determined in accordance with American Society for Testing of
Materials (ASTM) E-595. If a material exceeds these maximum limits, the
developers shall be required to either replace with a compliant material
or bring it into compliance via a vacuum bakeout, or to submit a MUA for
its usage. In general, a material is qualified on a product-by-product
basis. However, lot testing may be required by the Government of any
material for which lot variation is evident or suspected. In such cases
unless supporting justification is provided negating additional lot
testing via an MUA, material approval is contingent upon lot testing.

The developer shall prepare and submit a Polymeric Materials List as
indicated in Figure 10-4 as part of the M&P list (CDRL SA-21)

![](media/image4.pct){width="6.504166666666666in"
height="1.8465277777777778in"}

[]{#__RefHeading___Toc23846284 .anchor}Figure 10‑4. Polymeric Materials
List

### Lubrication Systems 

Lubricants shall be selected for use with materials on the basis of
flight heritage and valid test results that confirm the suitability of
the composition and the performance characteristics for each specific
application, including compatibility with the anticipated environment
and contamination concerns.

All lubricated mechanisms shall be life tested unless it can be
established and documented that a valid flight heritage exists to an
identical mechanism used in an identical flight application or to an
identical mechanism that has been separately qualified by suitable life
testing.

The developer shall prepare and submit a Lubrication Materials List as
indicated in Figure 10-5 as part of the M&P list (CDRL SA-21). In
addition, the developer may be required by the Government to submit
supporting applications data.

![](media/image5.pct){width="6.497222222222222in"
height="2.473611111111111in"}

Figure 10‑5. Lubrication Materials List

### Process Selection Requirements 

Manufacturing processes (e.g., conformal coating, adhesive bonding,
lubrication, heat treatment, welding, chemical or metallic coatings,
etc.) shall be carefully selected to preclude unacceptable material
property changes during exposure to flight environments that could cause
adverse effects to the material and/or to the intended applications.

The developer shall create and maintain a Materials Processes List with
the format and content indicated in Figure 10-6 as part of the M&P list
(CDRL SA-21).

![](media/image6.pct){width="6.490277777777778in"
height="1.4430555555555555in"}

Figure 10‑6. Materials Processes List

### Fasteners 

The developer shall comply with the procurement and test requirements
for flight hardware and critical GSE fasteners contained in
541-PG-8072.1.2, Goddard Space Flight Center Fastener Integrity
Requirements.

Fasteners made of plain carbon or low alloy steel shall be protected
from corrosion. When plating is specified, it shall be compatible with
the space environment. On steels harder than RC 33, a plating process
that does not embrittle the steel shall be utilized.

No split ring or internal tooth lock washers are permitted on any flight
hardware or GSE that will be vibration tested with flight hardware. Some
locking feature is required for all flight fasteners.

## Materials Used in \"Off-the-Shelf-Hardware"

\"Off-the-shelf hardware\" for which a detailed materials list is not
available and where the included materials cannot be easily identified
and/or replaced shall be treated as non-compliant. The developer shall
submit an MUA that defines the appropriate measures that will be used to
ensure that all materials in the "off-the-shelf" hardware are acceptable
for use. It may be possible to replace unknown or non-compliant
materials within the hardware with compliant materials, or hermetically
seal, or vacuum bake out the questionable hardware to bring the hardware
into a suitable condition for use. Such approaches shall be documented
in the MUA. When a vacuum bake-out is the selected method, it shall
incorporate a quartz crystal microbalance (QCM) and cold finger to
enable a determination of the duration and effectiveness of the bake-out
as well as compliance with the project contamination plan and error
budget.

## Materials Procurement Requirements

Raw materials purchased by the developer shall be accompanied by a
Certificate of Raw Materials Compliance and, where applicable, the
results of nondestructive, chemical and physical tests. When requested,
this information shall be made available to the Government for review.

### Incoming Inspection Requirements

The developer shall perform, or be responsible for the performance of
applicable incoming tests and inspections of materials to ensure that
they meet the requirements of the procurement specification. Unless
previously accomplished and accepted by Government or developer field
personnel, incoming testing and inspections shall be performed upon
receipt of the parts or materials. The inspection and testing of
materials shall be conducted in accordance with a plan approved by the
Government MAE.

## Shelf-Life-Control Requirements for Polymeric Materials 

Polymeric materials that have a limited shelf life shall be controlled
by a process that identifies the start date (manufacturing date,
shipment date, or date of receipt, etc.), the storage conditions
associated with a specified shelf life, and expiration date. Materials
such as o-rings, rubber seals, tape, uncured polymers, lubricated
bearings and paints shall be included. When a limited-life piece part is
installed in a subassembly, the subassembly item shall be included in
the Limited-Life Items List.

Materials usage beyond the expiration date requires that the developer
demonstrate by means of appropriate testing that the material's
properties are not compromised for the intended use. In these
situations, a waiver shall be written and submitted to the Government
for approval prior to use of the material beyond the expiration date.

## Failure Analysis

Failure analysis shall be performed on part and material failures
experienced during assembly and testing. Failures shall be analyzed to
the extent necessary to understand the failure mode and cause, to detect
and correct out-of-control processes, to determine the necessary
corrective actions, and to determine lot disposition. When required, a
failure analysis report shall be prepared and documented. The developer
MAE shall determine and implement appropriate corrective action for each
material and processes (M&P) failure. All failures, and the results of
final failure analysis, shall be documented.

Failure analysis reports shall be retrievable for the duration of the
contract, and shall be available to GSFC.

## Preservation and Packing

Preservation, packaging, and packing shall be in accordance with the
item and the system requirements. All parts that are subject to
degradation by ESD shall be packaged in accordance with the approved ESD
procedures.

## Handling

Handling (including storage) procedures shall be instituted to prevent
part and material degradation. The handling procedures shall be retained
through inspection, kitting, and assembly and shall be identified on
"build to" documentation. The following criteria shall be used as a
minimum for establishing handling and storage procedures for parts and
materials:

a.  Control of environment, such as temperature, humidity,
    contamination, and pressure.

b.  Measures and facilities to segregate and protect parts and materials
    routed to different locations, such as to the materials review crib,
    to a laboratory for inspection, or returned to the manufacturer from
    unaccepted shipments.

c.  Space quality parts shall be stored in easily identified containers.

d.  Control measures to limit personnel access to parts and materials
    during receiving inspection and storage.

e.  Facilities for interim storage of parts and materials.

f.  Provisions for protective cushioning, as required, on storage area
    shelves, and in storage and transportation containers.

g.  Protective features of transportation equipment design to prevent
    packages from being dropped or dislodged in transit.

h.  Protective bench surfaces on which parts and materials are handled
    during operations such as test, assembly, inspection, and organizing
    kits.

i.  Required use of gloves, finger cots, tweezers, or other means when
    handling parts to protect the parts from contact by bare hands.

j.  Provisions for protection of parts susceptible to damage by ESD.

k.  Unique parts and materials criteria.

## Data Retention

The developer shall maintain records of incoming inspection tests, lot
qualification and acceptance test data, radiation hardness assurance
test data, traceability data and other data as determined by the
Government MAE for a period of time specified by GSFC.

# EEE Parts Control Program Support

## General

The developer shall plan and implement an EEE Parts Control Program to
assure that all parts selected for use in flight hardware meet mission
objectives for quality and reliability. The program shall be in place to
effectively support the design and selection processes for the duration
of the contract. The Developer shall control the selection, application,
evaluation, and acceptance of all parts through a Parts Control Board
(PCB).

All parts shall be selected and processed in accordance with GSFC
EEE-INST-002, "EEE Parts Selection, Screening Qualification and
Derating," for part quality level 2. Exceptions for use of a lesser
grade part with additional testing shall be made on a case-by-case basis
only when a level 2 part is not available. Such exceptions require
approval by the PCB.

The Developer shall prepare a Parts Control Plan (PCP) (CDRL SA-18)
describing the approach and methodology for implementing their Parts
Control Program. The PCP shall also define the Developer's criteria for
parts selection and approval based on the guidelines of this section.
The Developer Project Parts Engineer (PPE) shall work with the GSFC PPE
to assure that all necessary information is contained in the PCP.

## Developer's Project Parts Engineer

The developer shall designate one key individual as the PPE, who shall
have the prime responsibility for management of the EEE Parts Control
Program. This individual shall have direct, independent and unimpeded
access to the GSFC PPE and PCB. The PPE shall work with design
engineers, radiation engineers, reliability engineers and the GSFC PPE
to perform part selection and control.

Tasks performed by the developer PPE shall include but are not limited
to the following:

> 1\. Work with GSFC PPE team to perform parts control.
>
> 2\. Provide PCB agenda, prepare Parts Lists and provide supporting
> part information for parts evaluation and approval by the PCB.
>
> 3\. Coordinate Parts Control Board meetings, maintain minutes, develop
> and maintain the spacecraft's Parts Identification List (PIL), develop
> the spacecraft portion of the Project Approved Parts List (PAPL),
> As-Designed Parts List (ADPL) and As-Built Parts List (ABPL).
>
> 4\. Perform Customer Source Inspections (CSI) and audits at supplier
> facilities as required.
>
> 5\. Prepare part procurement, screening, qualification, and
> modification specifications, as required.
>
> 6\. Disposition/track part nonconformances and part failure
> investigations.
>
> 7\. Track and report impact of Alerts and Advisories on flight
> hardware.

## Parts Control Board

The developer shall establish a PCB or similar documented system to
facilitate the management, selection, standardization, and control of
parts and associated documentation for the duration of the contract. The
PCB shall be responsible for the review and approval of all EEE parts,
for conformance to established criteria as defined herein (including
radiation effects), and for developing and maintaining a
Project-Approved Parts List (PAPL). In addition, the PCB is responsible
for providing assistance in all parts activities, such as part failure
investigations, disposition of part non-conformances, and part problem
resolutions. PCB operating procedures shall be included as part of the
PCP.

### PCB Responsibilities

The responsibilities of the PCB shall include, but not be limited to,
the following:

-   Evaluate EEE parts for conformance to established criteria and
    inclusion in the parts list.

-   Develop and maintain a PAPL.

-   Review and approve EEE part derating as necessary for unique
    applications.

-   Define testing requirements.

-   Review unique applications (including radiation effects).

-   Track part failure investigations and non-conformances.

### PCB Meetings, Notification, and Reports

PCB meetings shall be convened on a regular basis, and otherwise as
needed. If agreeable by the Government, PCB meetings may be conducted
via phone conversation. The GSFC PPE shall be a permanent member of PCB
meetings. The developer PPE shall prepare meeting minutes to document
all decisions made

The Developer PPE shall notify attendees at least five working days in
advance of all upcoming meetings except in an emergency situation.
Notification shall, at a minimum, include a proposed agenda and Parts
Identification List (PIL) of candidate parts.

### PCB Membership

At a minimum, the PCB membership shall consist of the developer's
Product Assurance Manager, developer PPE, GSFC PPE, and GSFC Project
Radiation Engineer (PRE) (GSFC Code 561) when required. The developer
PPE and GSFC PPE shall participate in all PCB meetings. The GSFC System
Assurance Manager (SAM), or designee, may attend as necessary. The
developer PPE, GSFC PPE and GSFC PRE shall be permanent members of the
PCB. The developer PPE shall assure that the appropriate individuals
with engineering knowledge and skills are represented as necessary at
meetings, such as part commodity specialists, radiation engineers, or
the appropriate subsystem design engineer.

If there are any parts issues that cannot be resolved at the PCB level,
the issues shall be elevated to the GSFC (LDCM) Project Manager for
disposition.

## Part Selection and Processing

All part commodities identified in EEE-INST-002 are considered EEE parts
and shall be subjected to the requirements set forth in this section.
EEE parts types that do not fall into any of the categories covered in
EEE-INST-002 shall be reviewed by the Government on a case-by-case basis
using the closest NASA, Defense Supply Center Columbus (DSCC), or
government controlled specification. In the event a suitable government
baseline specification does not exist, the developer PPE shall consult
the GSFC PPE to identify the best available industry standard for that
particular commodity, and develop appropriate procurement, screening and
qualification specifications.

### Parts Selection

Parts shall be selected from the GSFC EEE-INST-002, "Parts Selection,
Screening, Qualification and Derating" document, or the NASA Parts
Selection List (NPSL) for quality level 2 or better. Exceptions for use
of a lower grade shall only be made by the Government on a case-by-case
basis when a level 2 part is unavailable. Such exceptions require
approval by PCB. The use of a lower grade part requires additional
testing be performed in accordance with EEE-INST-002 to upgrade the part
to level 2.

EEE-INST-002 contains value added testing for a number of parts listed
in the NPSL. These tests include Particle Impact Noise Detection (PIND)
testing for all EEE devices, surge current testing for tantalum
capacitors and dielectric screening for several types of ceramic
capacitors. These, and any other value added tests listed in
EEE-INST-002, shall be performed to enhance the reliability of parts.
PCB approval is required if there is any deviation from any screening or
qualification tests as specified in EEE-INST-002.

### Radiation Requirements for Parts Selection

All parts shall be selected to perform nominally in the predicted
radiation environment, including the applicable Radiation Design Margin
(RDM). The radiation environment causes the following three main
degradation effects, which shall be accounted for in all active parts
selection:

-   Total Ionizing Dose (TID) (including Enhanced Low Dose Rate \[ELDR\]
    effects) -- Parts shall be selected to ensure adequate performance
    in the application, up to a dose of twice the expected mission dose.
    Linear bipolar parts shall be assumed to be ELDR susceptible, unless
    the parts have been successfully tested and shown insensitive.

-   Single-Event Effects (SEE) -- Parts shall be assessed for the
    potential of Single-Event Upset (SEU) or Single-Event Transient
    (SET), which requires analysis of the circuit application on a
    case-by-case basis. Parts susceptible to Single-Event Latch-up (SEL)
    should be avoided. If performance demands the use of an SEL
    susceptible part, measures shall be implemented to ensure that SEL
    induced damages (both prompt and latent) are mitigated and that
    instrument performance is not compromised. These measures shall
    receive approval by the GSFC PRE and PPE before the part can be
    added to the PAPL. Applied voltages for power
    Metal-Oxide-Semiconductor Field Effect Transistors (MOSFETs), Field
    Effect Transistors (FETS), and bipolar junction transistors shall be
    in the safe operating ranges for these devices, based on
    Single-Event Gate Rupture (SEGR)/Single- Event Burn-out (SEB) test
    data.

-   Displacement Damage -- Parts shall be able to withstand the
    displacement damage to high energy protons, to twice the fluence
    expected in the predicted LDCM environment. This effect can cause
    significant damage in optical devices.

These effects and others may require individual part application
analysis to be performed as determined by the GSFC PRE. The developer
shall document the radiation analysis of each part as applicable.

### Custom or Advanced Technology Devices

Devices such as custom hybrid microcircuits, detectors, Application
Specific Integrated Circuits (ASICs), and MCMs shall also be subject to
parts control and include a design review appropriate for the individual
technology. The design review shall include element evaluation to assure
each element's reliability (review should include such items as burn-in,
voltage conditioning, sample size, element derating, etc.), device
construction and assembly process (including materials evaluation for
such items as contamination concerns, metal whisker concerns, and
adequate material thermal matching; materials specialists shall be
consulted as necessary). A customer source inspection may be required if
so determined by the Government.

A procurement specification may be required for parts in this category
based on the determination of the Government PPE. These specifications
shall fully describe the item being procured, and shall include
physical, mechanical, environmental, electrical test requirements, and
QA provisions necessary to control manufacture and acceptance. Screening
requirements designated for the part shall be included in the
procurement specification. Test conditions, burn-in circuits, failure
criteria, and lot rejection criteria shall be included. For lot
acceptance or rejection, the Percentage of Defectives Allowable (PDA) in
a screened lot shall be in accordance with that prescribed in the
closest military part specification.

### Plastic Encapsulated Microcircuits

The use of Plastic Encapsulated Microcircuits (PEMs) and plastic
semiconductors is discouraged, however, when use of PEMs is necessary to
achieve unique performance requirements unachievable using hermetic high
reliability microcircuits, plastic encapsulated parts shall meet the
requirements of EEE-INST-002. The PCB shall review the procurement
specification, application of part, and storage processes for PEMs, to
assure that all aspects of EEE-INST-002 have been met.

### Verification Testing

Re-performance of screening tests, which were performed by the
manufacturer or authorized test house, as required by the military or
procurement specification, are not required unless deemed necessary by
failure history, GIDEP Alerts, age, or other reliability concerns. If
required, testing shall be performed in accordance with GSFC
EEE-INST-002, or as determined by the PCB.

### Parts Approved on Prior Programs

Parts previously approved by GSFC for other projects via prior PCB
activity or a Nonstandard Parts Approval Request (NSPAR) shall not be
granted "grandfather approval" on LDCM. However, existing approval
packages may be brought by the developer to the PCB as an aid to present
candidate parts for approval. (Preparation of NSPARs is not a
requirement for LDCM.)

## Part Analysis

### Destructive Physical Analysis

A sample of each lot date code of microcircuits, hybrid microcircuits,
and semiconductor devices may be subjected to a Destructive Physical
Analysis (DPA) based on PCB recommendation. All other parts may require
a sample DPA if it is deemed necessary by the PCB as indicated by
failure history, GIDEP Alerts, or other reliability concerns. DPA tests,
procedures, sample size and criteria shall be as specified in GSFC
specification S-311-M-70, "Destructive Physical Analysis." If approved
by the PCB, the developer's procedures for DPA may be used in place of
S-311-M-70 and shall be submitted with the PCB for concurrence prior to
use. The PCB shall consider variation to the DPA sample size
requirements, due to part complexity, availability or cost on a
case-by-case basis.

### Failed EEE Parts

An EEE part failure is defined as a failure for which the part itself is
the intrinsic cause, which occurs while the part is operating within its
specification limits. Emphasis shall be placed on detection, analysis,
and feedback of failure data during unit level testing. The developer
shall have a method in place to report all EEE component failures.
Failures occurring during EEE part screening and qualification shall be
reported. In addition, failures that occur after the first application
of power at the subassembly level (and continuing through unit,
subsystem and system levels) during qualification and acceptance testing
of flight hardware shall be reported. The failure reporting shall
include identification of failed parts, notification within an approved
time of failure, retrieval of failed/overstressed parts, part failure
analysis, and documentation of all pertinent information related to each
failure. The failure reporting plan shall be documented and presented to
the PCB.

### Failure Analysis

When a component part Failure Analysis (FA) is necessary to support a
Failure Review Board (FRB), the developer shall prepare a part Failure
Analysis Report. The contractor PPE shall submit the completed report to
the PCB for review and approval in order to assure proper documentation
is presented for the FRB. The failure report form shall provide the
following information at a minimum:

-   The failed part's identity (part name, part number, reference
    designator, manufacturer, manufacturing lot/date code, and part
    serial number if applicable), and symptoms by which the failure was
    identified (the conditions observed as opposed to those expected).

-   The name of the unit or subsystem on which the failure occurred,
    date of failure, the test phase, and the environment in which the
    test was being conducted.

-   An indication of whether the failure of the part or item in question
    constitutes a primary or secondary (collateral) failure (caused by
    another failure in the circuit and not a failure on its own merit).

The completed failure report shall include copies of any supporting
photographs, X-rays, metallurgical data, microprobe or spectrographic
data, Scanning Electronic Microscope (SEM) photographs, pertinent
variables (electrical and radiation) data, etc. Radiation data shall be
submitted where it is deemed relative to the failure mechanism.

## Additional Requirements

### Parts Age Control

All active EEE parts procured with date codes indicating that more than
five years have elapsed from the date of manufacture to date of
procurement shall be subjected to a re-screen (and sample DPA per PCB
recommendation). Parts taken from user inventory older than five years
do not require re-screen, provided they have been properly stored (refer
to Section 13). Proper storage means maintaining the parts within their
rated temperature range in an area protected from conditions that create
electrostatic damage or contaminants that may affect their functionality
(e.g. corrosive atmospheres that damage the plating on the leads or
terminations). Storage areas shall be inspected and electrostatic
discharge (ESD) certified for proper equipment and handling procedures
in accordance with ANSI/EDS-S20.20, "Protection of Electrical and
Electronic Parts, Assemblies, and Equipment (Excluding Electrically
Initiated Explosive Devices)."

An alternate contractor method of controlling parts age may be used upon
review and approval by the PCB.

Parts over seven years from the date of manufacture to date of
procurement are discouraged. Exceptions shall be reviewed on a
case-by-case basis and require approval of the PCB. Parts stored in
uncontrolled conditions where they may be exposed to ESD, the elements,
or sources of contamination shall not be used.

### Derating

All EEE parts shall be used in accordance with the derating guidelines
of GSFC EEE-INST-002. As determined by the Government, the developer's
derating policy may be used in place of the GSFC guidelines and shall be
submitted with the developer PCP for approval. The developer shall
maintain documentation on parts derating analysis and make it available
for GSFC review.

### Alerts

The developer shall be responsible for the review and disposition of all
GIDEP Alerts on parts proposed for flight use. In addition, any NASA
Alerts and Advisories provided to the developer by GSFC shall be
reviewed and dispositioned. Alert applicability, impact, and corrective
actions shall be continuously documented and reported to GSFC. The
review process shall continue from delivery to launch.

### Prohibited Metals

Pure tin plating shall not be used in the construction and surface
finish of EEE parts proposed for space hardware. Only alloys containing
less than 97% tin are acceptable.

The use of pure cadmium or zinc is prohibited in the construction and
surface finish of space hardware. All cadmium alloys or zinc alloys
(e.g. brass) must be completely over plated with an approved metal. The
GSFC Materials Branch shall be consulted as necessary.

## Parts List

The developer shall document and maintain a Program Approved Parts List
(PAPL) and a Parts Identification List (PIL) for the duration of the
project. The contractor shall submit the PAPL to GSFC. Parts must be
approved for listing on the PAPL before initiation of procurement
activity. All submissions to the LDCM Project shall include a computer
compatible form (Microsoft Excel, Microsoft Access, etc.; consult GSFC
PPE for acceptable format).

### Parts Identification List

The PIL shall be a real time working list of all parts proposed for use
in flight hardware. The PIL is prepared from design team inputs or
subcontractor inputs, and is used for presenting and tracking candidate
parts to the PCB. The PIL shall include the following information at a
minimum: part number, part name or description, manufacturer,
manufacturer's generic part number, drawing number, specifications,
comments as necessary (to indicate problems, long lead times, additional
testing imposed, application unique notes, etc). The PIL shall also have
radiation effects information on active devices such as semiconductors,
microcircuits and optoelectronic parts. (CDRL SA-19)

### Program Approved Parts List

The PAPL shall be the only listing of approved parts for flight
hardware, and shall be the combined listing of all parts submitted
through PILs that are approved by the PCB, plus approval status and
disposition notes. Only parts that have been evaluated and approved by
the PCB shall be listed in the PAPL. The PCB shall assure
standardization of parts listed in the PIL across various systems and
subsystems. (CDRL SA-19)

### As-Built Parts List

An As-Built Parts List (ABPL) shall also be prepared and submitted to
the LDCM by the Contractor PPE. The ABPL is generally a final
compilation of all parts as installed in flight equipment, with
additional "as-installed" part information such as manufacturer name,
Commercial and Government Entity (CAGE) code, Lot-Date code, part serial
number (if applicable), box identification and/or part location.
Provisions shall be in place to find quantity used and provide
traceability to box or board location through build paperwork. The
manufacturer's plant specific CAGE code is preferred, but if unknown,
the supplier's general CAGE code is sufficient. (CDRL SA-19)

## Data Requirements

Attributes summary data shall be kept available to GSFC for all testing
performed. Variable data (read and record) shall be recorded for
initial, interim and final electrical test points and shall be kept
available to GSFC.

For flight lots with samples subjected to Radiation Lot Acceptance Test
(RLAT), the radiation report that identifies parameter degradation
behavior shall be provided to the PCB, and variables data acquired
during radiation testing shall be kept available to GSFC.

### Radiation Hardness

The developer shall have a method in place for retention of data
generated for parts tested and used in flight hardware. The data shall
be kept on file in order to facilitate future risk assessment and
technical evaluation. In addition, the developer shall retain all part
functional failures, all destructive and non-flight non-destructive test
samples, which could be used for future validation of parts for
performance under certain conditions not previously accounted for. These
devices shall be kept until launch. Data shall be retained for the
useful life of the mission, unless otherwise permitted by PCB.

All historical records and data required to support these records shall
be retained for a period of five years and shall be provided to GSFC on
request.

# Contamination Control Requirements

## General

The developer shall plan and implement a contamination control program
appropriate for the hardware. The program shall establish the specific
cleanliness requirements and delineate the approaches to be followed in
a Contamination Control Plan (CCP).

Contamination includes all materials of molecular and particulate nature
whose presence degrades hardware performance. The source of the
contaminant materials may be the hardware itself, the test facilities,
and the environments to which the hardware is exposed.

## Contamination Control Verification Process

The developer shall develop a contamination control verification
process. The verification process shall be performed in order:

a.  Determination of contamination sensitivity.

b.  Determination of a contamination allowance.

c.  Determination of a contamination budget.

d.  Development and implementation of a contamination control plan.

Each of the above activities shall be documented and submitted to GSFC
for concurrence/approval.

## Contamination Control Plan

The developer shall prepare a CCP that describes the procedures that
will be followed to control contamination (CDRL SA-17). It shall
establish the implementation and describe the methods that will be used
to measure and maintain the levels of cleanliness required during each
of the various phases of the item's lifetime. In general, all mission
hardware shall be compatible with the most contamination-sensitive
components.

## Material Outgassing

In accordance with ASTM E595, NASA RP 1124 shall be used as a guide.
Individual material outgassing data shall be established based on each
component's operating conditions. Established material outgassing data
shall be verified and shall be reviewed by GSFC.

## Thermal Vacuum Bakeout

The developer shall perform thermal vacuum bakeouts of all hardware. The
parameters of such bakeouts (e.g., temperature, duration, outgassing
requirements, and pressure) shall be individualized depending on
materials used, the fabrication environment, and the established
contamination allowance. Thermal vacuum bakeout results shall be
verified and shall be reviewed by GSFC.

## Hardware Handling

The developer shall practice cleanroom standards in handling hardware.
The contamination potential of material and equipment used in cleaning,
handling, packaging, tent enclosures, shipping containers, bagging
(e.g., anti-static film materials), and purging shall be described in
detail for each subsystem or component at each phase of assembly,
integration, test, and launch.

# Electrostatic Discharge Control

## General

The developer shall document and implement an ESD Control Program to
assure that all manufacturing, inspection, testing, and other processes
will not compromise mission objectives for quality and reliability due
to ESD events.

## Applicable Documents

The current status and/or any application notes for these standards can
be obtained at http://workmanship.nasa.gov. The most current version of
these standards shall be used for new procurements. Included shall be
ANSI/ESD S20.20, "ESD Association Standard for the Development of an
Electrostatic Discharge Control Program for protection of electrical and
electronic parts, assemblies, and equipment (excluding electrically
initiated explosive devices)."

However, if a specific revision is listed for a referenced standard,
only that revision is approved for use unless otherwise approved by
project management.

## Electrostatic Discharge Control Requirements

The developer shall document and implement an ESD Control Program in
accordance with ANSI/ESD S20.20, "Protection of Electrical and
Electronic Parts, Assemblies and Equipment (excluding electrically
initiated explosive devices)," suitable to protect the most sensitive
component involved in the project. At a minimum, the ESD Control Program
shall address training, protected work area procedures and verification
schedules, packaging, facility maintenance, storage, and shipping.

All personnel who manufacture, inspect, test, otherwise process
electronic hardware, or require unescorted access into ESD protected
areas shall be certified as having completed the required training,
appropriate to their involvement, as defined in ANSI/ESD S20.20 or in
the developer's quality manual prior to handling any electronic
hardware.

Electronic hardware shall be manufactured, inspected, tested, or
otherwise processed only at designated ESD protective work areas. These
work areas shall be verified on a regular schedule as identified in the
developer's ESD Control Program; an ESD Control Program that has been
approved by the procuring organization.

Electronic hardware shall be properly packaged in ESD protective
packaging at all times when not actively being manufactured, inspected,
tested, or otherwise processed.

Alternate standards may be proposed by the developer. Their use is
limited to the specific project and is allowed only after they have been
reviewed and approved by the GSFC Project Office.

Materials selected for packaging or protecting ESD sensitive devices
shall not leach chemicals, leave residues, or otherwise contaminate
parts or assemblies (e.g., \"pink poly\" is well known for its
outgassing of contaminants and should only be used for storing
documentation or other non-hardware uses).

# GIDEP Alerts and Problem Advisories

## General

The developer shall participate in the GIDEP in accordance with the
requirements of the GIDEP SO300-BT-PRO-010 ("GIDEP Operations Manual")
and SO300-BU-GYD-010 ("Government-Industry Data Exchange Program
Requirements Guide"), available from the GIDEP Operations Center, Post
Office (PO) Box 8000, Corona, California 92878-8000.

The developer shall review all GIDEP Alerts, GIDEP Safe-Alerts, GIDEP
Problem Advisories, GIDEP Agency Action Notices, NASA Advisories and any
informally documented component issues presented by Code 303, to
determine if they affect the developer products produced for NASA. For
the above mentioned alerts and advisories that are determined to affect
the program, the developer shall take action to eliminate or mitigate
any negative effect to an acceptable level.

The developer shall provide a matrix that shows whether or not GIDEPs
and related alerts impact their hardware and this matrix shall be
maintained and updated as new alerts are issued or new hardware is
received. It is the developers' responsibility to review and update this
matrix during the life of the project.

The developer shall generate the appropriate failure experience data
report(s) (GIDEP Alert, GIDEP Safe-Alert, GIDEP Problem Advisory) on a
monthly basis, in accordance with the requirements of GIDEP
SO300-BT-PRO-010 and SO300-BU-GYD-010 whenever failed or nonconforming
items, available to other buyers, are discovered during the course of
the contract.

# Applicable Documents List

**DOCUMENT** **DOCUMENT TITLE**

AFSCM 91-710 Range Safety Users Requirements Manual

ANSI/ASQC Q9000-3 Quality Management and Quality Assurance Standards --
Part 3: Guidelines for the Application of ISO 9001 to the Development,
Supply and Maintenance of Software

ANSI/ISO/ASQ Q9001:2000 American National Standard Quality Systems -
Model for Quality Assurance in Design, Development, Production,
Installation and Servicing

ANSI/IPC-A-600 Acceptability of Printed Boards

ASTM E-595 Standard Test Method for Total Mass Loss and Collected
Volatile Condensable Materials from Outgassing in a Vacuum Environment

FAR Federal Acquisition Regulations

GIDEP S0300-BT-PRO-010 GIDEP Operations Manual

GIDEP S0300-BU-GYD-010 Government-Industry Data Exchange Program
Requirements Guide

GMI 1700.2 Goddard Space Flight Center Health, and Safety Program

GPR 1060.2 Management Review and Reporting for Programs and Projects

GPR 8621.1 Reporting of Mishaps, Incidents, Hazards, and Close Calls

GPR 8621.2 Processing Mishap, Incident, Hazard, and Close Call Reports

GPR 8621.3 Mishap, Incident, Hazard, and Close Call Investigation

GPR 8700.4 Technical Review Program

GPR 8700.6 Engineering Peer Reviews

GSFC-STD-7000 General Environmental Verification Standards (GEVS) for
Flight Programs and Projects

GSFC S-312-P003 Procurement Specification for Rigid Printed Boards for
Space Applications and Other High Reliability Uses

GSFC EEE-INST-002 Instructions for EEE Parts Selection, Screening, and
Qualification and Derating

IEEE STD 610.12 IEEE Standard Glossary for Software Engineering
Terminology

IEEE STD 730 IEEE Standard for Software Quality Assurance Plans

IEEE STD 982.1 IEEE Standard Dictionary of Measures to Produce Reliable
Software

IEEE STD 982.2 IEEE Guide for the Use of IEEE Standard Dictionary of
Measures to Produce Reliable Software

IPC A-600 Acceptability of Printed Boards

IPC-A-610 Acceptability of Electronic Assemblies

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

IPC-2221 Generic Standard on Printed Board Design

IPC-2222 Sectional Design Standard for Rigid Organic Printed Boards

IPC-2223 Sectional Design Standard for Flexible Printed Boards

IPC-6011 Generic Performance Specifications for Printed Boards

IPC-6012 Qualification and Performance Specification for Rigid Printed
Boards

IPC-6013 Qualification and Performance Specification for Flexible
Printed Boards

IPC-6018 Microwave End Product Board Inspection and Test

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

KHB 1860.1 KSC Ionizing Radiation Protection Program

KHB 1860.2 KSC Non-Ionizing Radiation Protection Program

KNPR 8715.3 KSC Safety Practices Procedural Requirements

MIL-HDBK-217 Reliability Prediction of Electronic Equipment

MIL-HDBK-470 Designing and Developing Maintainable Products and Systems

MIL-HDBK-472 Maintainability Prediction

MIL-PRF-19500 General Specification for Semiconductor Devices

MIL-PRF-38534 General Specification for Hybrid Microcircuits

MIL-PRF-38535 General Specification for Integrated Circuits
(Microcircuits) Manufacturing

MIL-PRF-55365/4 General Specification for Established Reliability and
Nonestablished Reliability of (Tantalum) Chip Fixed Electrolytic
Capacitors

MIL-STD-461 Electromagnetic Emission and Susceptibility Requirement for
Control of Electromagnetic Interference

MIL-STD-756 Reliability Modeling and Prediction

MIL-STD-882 System Safety Program Requirements

MIL-STD-883 DoD Test Method Standards for Microcircuits

MIL-STD-981 Design, Manufacturing and Quality Standards for Custom
Electromagnetic Devices for Space Applications

MIL-STD-1629 Procedures for Performing a Failure Mode Effects and
Criticality Analysis

MSFC 3029 Guidelines for the Selection of Metallic Materials for Stress
Corrosion Cracking Resistance in Sodium Chloride Environments

MSFC CR 5320.9 Payload and Experiment Failure Mode Effects Analysis and
Critical Items List Ground Rules

MSFC-HDBK-527 Material Selection List for Space Hardware Systems

NASA RP-1124 Outgassing Data for Selecting Spacecraft Materials

NASA RP-1161 Evaluation of Multi-Layer Printed Wiring Boards by
Metallographic Techniques

NFS 1815.201 NASA Federal Acquisition Regulation Supplement Exchanges
with Industry before Receipt of Proposals

NFS 1823.7001 NASA Federal Acquisition Regulation Supplement Safety and
Health NASA Solicitation Provisions and Contract Clauses

NFS 1815.305 NASA Federal Acquisition Regulation Supplement Source
Selection Proposal Evaluation

NFS 1846.401 NASA Federal Acquisition Regulation Supplement Government
Contract Quality Assurance General

NHB 1700.1 NASA Safety Policy and Requirements Document

NPD 7120.4 Program and Project Management

NPD 8700.1 NASA Policy for Safety & Mission Success

NPD 8710.2 NASA Safety and Health Program Policy

NPD 8710.3 NASA Policy for Limiting Orbital Debris Generation

NPR 5100.4 NASA FAR Supplement

NPR 7120.5 NASA Program and Project Management Processes and
Requirements

NPR 7150.2 NASA Software Engineering Requirements

NPR 8621.1 NASA Procedures and Guidelines for Mishap Reporting,
Investigating, and Record Keeping

NPR 8715.3 NASA Safety Manual

NPR 8000.4 Risk Management Procedural Requirements

NASA-STD 8719.8 Expendable Launch Vehicle Payloads Safety Review Process
Standard

NASA-STD 8719.9 NASA Standard for Lifting Devices and Equipment

NASA-STD 8719.13 NASA Software Safety Standard

NASA-STD 8719.14 Guidelines and Assessment Procedures for Limiting
Orbital Debris

NASA-STD 8739.1 Workmanship Standard for Staking and Conformal Coating
of Printed Wiring Boards and Electronic Assemblies

NASA-STD 8739.2 Workmanship Standard for Surface Mount Technology

NASA-STD 8739.3 Workmanship Standard for Soldered Electrical Connections

NASA-STD 8739.4 Workmanship Standard for Crimping, Interconnecting
Cables, Harnesses and Wiring

NASA-STD-8739.5 Workmanship Standard for Fiber Optic Terminations, Cable
Assemblies and Installation

NSS 1740.14 Guidelines and Assessment Procedures for Limiting Orbital
Debris

S-302-89-01 Procedures for Performing a Failure Mode and Effects
Analysis

S-311-M-70 Specification for Destructive Physical Analysis

SAE AS9100 Aerospace Standard, Quality Systems Model for Quality
Assurance, Design, Development, Production, Installation and Servicing

SAE JA1002 Software Reliability Program Standard

300-PG-7120.2.1 Mission Assurance Guidelines (MAG) Implementation

302-PG-7120.2.1 Mission Assurance Guidelines Implementation

541-PG-8072.1.2 GSFC Fastener Integrity Requirements

540-PG-8715.1.1 Mechanical Systems Division Safety Manual, Volume I

540-PG-8715.1.2 Mechanical Systems Division Safety Manual, Volume II

[]{#__RefHeading___Toc23847542 .anchor}Appendix A. Abbreviations and
Acronyms

  -------------------------------------------------------------------------
  **Abbreviation/   **DEFINITION**
  Acronym**         
  ----------------- -------------------------------------------------------
                    

  ABPL              As-Built Parts List

  ABML              As-Built Materials List

  ADMPL             As-Designed Materials and Processes List

  AFSPC             Air Force Space Command

  ANSI              American National Standards Institute

  AR                Acceptance Review

  ASIC              Application Specific Integrated Circuits

  ASQ               American Society for Quality

  ASQC              American Society for Quality Control

  ASTM              American Society for Testing of Materials

  BB                Ball Bearing

  BGA               Ball Grid Array

  C                 Centigrade

  CAGE              Commercial and Government Entity

  CCB               Configuration Control Board

  CCP               Contamination Control Plan

  CCR               Configuration Change Request

  CDR               Critical Design Review

  CDRL              Contract Delivery Requirements List

  CFR               Code of Federal Regulations

  CIL               Critical Items List

  CM                Configuration Management

  CMO               Configuration Management Office

  CO                Continuous Oscillation

  COB               Chip on Board

  COTR              Contracting Officer Technical Representative

  COTS              Commercial Off-the-Shelf

  CPM               Centimeters per minute

  CRM               Continuous Risk Management

  CRMS              Continuous Risk Management System

  CS                Continuous Sliding

  CSCI              Computer Software Configuration Item

  CUR               Continuous Unidirectional Rotation

  CVCM              Collected Volatile Condensable Mass

  DID               Data Item Description

  DoD               Department of Defense

  DOORS             Dynamic Object Oriented Requirements System

  DPA               Destructive Physical Analysis

  DSCC              Defense Supply Center Columbus

  EEE               Electrical, Electronic, and Electromechanical

  EIA               Electronics Industry Alliance

  EIDP              End Item Data Package

  EIS               Environmental Impact Statement

  ELDR              Enhanced Low Dose Rate

  ELV               Expendable Launch Vehicle

  EMC               Electromagnetic Compatibility

  EMI               Electromagnetic Interference

  ESD               Electrostatic Discharge

  ESMD              Exploration Systems Mission Directorate

  ETA               Event Tree Analysis

  ETM               Environmental Test Matrix

  ETR               Eastern Test Range

  EVA               Extravehicular Activity

  EWR               Eastern and Western Test Ranges

  FA                Failure Analysis

  FAP               Flight Assurance Procedure

  FAR               Federal Acquisition Regulations

  FCA               Functional Configuration Audit

  FETs              Field Effect Transistors

  FMEA              Failure Modes and Effects Analysis

  FOR               Flight Operations Review

  FRB               Failure Review Board

  FRR               Flight Readiness Review

  FTA               Fault Tree Analysis

  FY                Fiscal Year

  G                 Gears

  GDS               Ground Data System

  GEVS              General Environmental Verification Standards

  GFE               Government-Furnished Equipment

  GHB               Goddard Space Flight Center Handbook

  GIA               Government Inspection Agency

  GIDEP             Government Industry Data Exchange Program

  GMI               Goddard Management Instruction

  GOTS              Government Off-the-Shelf

  GPMC              Governing Program Management Council

  GPR               Goddard Procedure and Guidelines

  GSE               Ground Support Equipment

  GSFC              Goddard Space Flight Center

  hrs               hours

  HTL               Hazard Tracking Log

  HQ                Headquarters

  I&T               Integration and Test

  IAC               Independent Assurance Contractor

  IEEE              Institute of Electrical and Electronics Engineers

  IIR               Integrated Independent Review

  IIRT              Integrated Independent Review Team

  INST              Instruction

  IO                Intermittent Oscillation

  IPC               Association Connecting Electronics Industries

  IR                Intermittent Rotation

  IS                Intermittent Sliding

  ISO               International Organization for Standardization

  IV&V              Independent Verification and Validation

  JSC               Johnson Space Center

  KHB               Kennedy Space Center Handbook

  KSC               Kennedy Space Center

  LAO               Large Angle Oscillation

  LDCM              Landsat Data Continuity Mission

  LRU               Line Replaceable Unit

  M                 Million

  M&P               Materials and Processes

  M&PCP             Materials and Processes Control Program

  MAE               Materials Assurance Engineer

  MAG               Mission Assurance Guidelines

  MCM               Multi-Chip Module

  MEB               Materials Engineering Branch

  MIL               Materials Identification List

  MLD               Master Logic Diagram

  mm                millimeter

  MOR               Mission Operations Review

  MOSFETs           Metal-Oxide-Semiconductor Field Effect Transistors

  MOTS              Modified Off-the-Shelf

  MPCP              Materials and Processes Control Plan

  MRB               Materials Review Board

  MRR               Mission Readiness Review

  MSFC              Marshall Space Flight Center

  MSPSP             Missile System Pre-Launch Safety Data Package

  MSR               Monthly Status Review

  MUA               Materials Usage Agreement

  NASA              National Aeronautics and Space Administration

  NCR               Nonconformance Report

  NHB               NASA Handbook

  NPD               NASA Policy Directive

  NPR               NASA Procedural Requirements

  NPSL              NASA Parts Selection List

  NSF               NASA Federal Supplement

  NSPAR             Nonstandard Parts Approval Request

  NSS               NASA Safety Standard

  O~2~              Oxygen

  O&SHA             Operating and Support Hazard Analysis

  ODA               Orbital Debris Assessment

  OHA               Operational Hazard Analysis

  OPM               Oscillation per minute

  OSSMA             Office of Systems Safety and Mission Assurance

  PAPL              Project Approved Parts List

  PCA               Physical Configuration Audit

  PCB               Parts Control Board

  PCP               Parts Control Plan

  PDA               Percentage of Defective Allowable

  PDR               Preliminary Design Review

  PEM               Plastic Encapsulated Microcircuit

  PER               Pre-Environmental Review

  PFR               Problem/Failure Report

  PG                Procedures and Guidelines

  PHA               Preliminary Hazards Analysis

  PIL               Parts Identification List

  PIND              Particle Impact Noise Detection

  POCC              Payload Operations Control Center

  PPE               Project Parts Engineer

  PPL               Preferred Parts List

  PQR               Procedure Qualification Record

  PRA               Probabilistic Risk Assessment

  PRE               Project Radiation Engineer

  PSM               Project Safety Manager

  PSR               Pre-Shipment Review

  PSSSMA            Performance Specification Sheet for Space and Military
                    Avionics

  PTFE              Polytetrafluoroethylene

  PWB               Printed Wiring Board

  PWQ               Process Waste Questionnaire

  QA                Quality Assurance

  QCM               Quartz Crystal Microbalance

  QMS               Quality Management System

  R&M               Reliability and Maintainability

  RBAM              Risk-Based Acquisition Management

  RDM               Radiation Design Margin

  RF                Radio Frequency

  RFA               Request for Action

  RLAT              Radiation Lot Acceptance Test

  RMP               Risk Management Plan

  RPP               Reliability Program Plan

  RPM               Revolutions Per Minute

  RVM               Requirements Verification matrix

  SAE               Society of Automotive Engineers

  SAM               System Assurance Manager

  SAO               Small Angle Oscillation

  SAR               Safety Assessment Report

  SB                Sleeve Bearings

  SC                Spacecraft

  SCC               Stress Corrosion Cracking

  SCM               Software Configuration Management

  SCR               System Concept Review

  SEB               Single-Event Burn-Out

  SEC               Sliding Electrical Contacts

  SEGR              Single-Event Gate Rupture

  SEE               Single-Even Effects

  SEL               Single-Event Latch up

  SEM               Scanning Electronic Microscope

  SET               Single-Event Transient

  SEU               Single-Event Upset

  SHA               System Hazard Analysis

  SMA               Safety and Mission Assurance

  SOW               Statement of Work

  SRO               Systems Review Office

  SRP               System Review Program

  SRR               System Requirements Review

  SS                Sliding Surface

  SSHA              Subsystem Safety Hazard Analysis

  SSPP              System Safety Program Plan

  STD               Standard

  STS               Space Transportation System

  STT               Strategy-to-Task-to-Technology

  SWG               Safety Working Group

  SWRR              Software Requirements Review

  TID               Total Ionizing Dose

  TIG               tungsten inert gas

  TIM               Technical Interface Meeting

  TML               Total Mass Loss

  TRR               Test Readiness Review

  U.S.              United States

  UV                Ultraviolet

  V&V               Verification and Validation

  VDD               Version Description Document

  VTL               Verification Tracking Log

  WOA               Work Order Authorization
  -------------------------------------------------------------------------

[]{#__RefHeading___Toc23847543 .anchor}Appendix B. Glossary/Definitions

The following definitions apply within the context of this document:

**Acceptance Tests**: The validation process that demonstrates that
hardware is acceptable for flight. It also serves as a quality control
screen to detect deficiencies and, normally, to provide the basis for
delivery of an item under terms of a contract.

**Assembly:** See Level of Assembly.

**Audit:** A review of the developer's or sub-developer's documentation
or hardware to verify that it complies with project requirements.

**Collected Volatile Condensable Material (CVCM):** The quantity of
outgassed matter from a test specimen that condenses on a collector
maintained at a specific constant temperature for a specified time.

**Component:** See Level of Assembly.

**Configuration:** The functional and physical characteristics of the
payload and all its integral parts, assemblies, and systems capable of
fulfilling the fit, form and functional requirements defined by
performance specifications and engineering drawings.

**Configuration Control**: The systematic evaluation, coordination, and
formal approval/disapproval of proposed changes, including the
implementation of all approved changes to the design and production of
an item with a configuration formally approved by the
developer/purchaser/both.

**Configuration Management (CM):** The systematic control and evaluation
of all changes to baseline documentation and subsequent changes to that
documentation which define the original scope of effort to be
accomplished (contract and reference documentation) and the systematic
control, identification, status accounting and verification of all
configuration items.

**Contamination**: The presence of materials of molecular or particulate
nature, which degrade the performance of hardware.

**Derating:** The reduction of the applied load (or rating) of a device
to improve reliability or to permit operation at high ambient
temperatures.

**Design Specification:** Generic designation for a specification that
describes functional and physical requirements for an article, usually
at the component level or higher levels of assembly. In its initial
form, the design specification is a statement of functional requirements
with only general coverage of physical and test requirements.

The design specification evolves through the project life cycle to
reflect progressive refinements in performance, design, configuration,
and test requirements. In many projects, the end-item specifications
serve all the purposes of design specifications for the contract
end-items. Design specifications provide the basis for technical and
engineering management control.

**Designated Representative:** An individual (such as a NASA plant
representative), firm (such as assessment developer), Department of
Defense (DoD) plant representative, or other government representative
designated and authorized by NASA to perform a specific function for
NASA. As related to the developer's effort, this may include evaluation,
assessment, design review, participation, and review/approval of certain
documents or actions.

**Destructive Physical Analysis (DPA**): An internal destructive
examination of a finished part or device to assess design, workmanship,
assembly, and any other processing associated with fabrication of the
part.

**Design Qualification Tests:** Tests intended to demonstrate that an
item will function within performance specifications under simulated
conditions more severe than those expected from ground handling, launch,
and orbital operations. Their purpose is to uncover deficiencies in
design and method of manufacture. They are not intended to exceed design
safety margins or to introduce unrealistic modes of failure. The design
qualification tests may be to either "prototype" or "protoflight" test
levels.

**Discrepancy:** See Nonconformance.

**Electromagnetic Compatibility (EMC):** The condition that prevails
when various electronic devices are performing their functions according
to design in a common electromagnetic environment.

**Electromagnetic Interference (EMI):** Electromagnetic energy, which
interrupts, obstructs, or otherwise degrades or limits the effective
performance of electrical equipment.

**Electromagnetic Susceptibility:** Undesired response by a component,
subsystem, or system to conducted or radiated electromagnetic emissions.

**End-to-End Tests**: Tests performed on the integrated ground and
flight system, including all elements of the payload, its control,
stimulation, communications, and data processing to demonstrate that the
entire system is operating in a manner to fulfill all mission
requirements and objectives.

**Failure:** A departure from specification that is discovered in the
functioning or operation of the hardware or software. See
nonconformance.

**Failure Modes, Effects, and Criticality Analysis (FMECA):** A
procedure by which each credible failure mode of each item from a low
indenture level to the highest is analyzed to determine the effects on
the system and to classify each potential failure mode in accordance
with the severity of its effect.

**Flight Acceptance:** See Acceptance Tests.

**Fracture Control Program:** A systematic project activity to ensure
that a payload intended for flight has sufficient structural integrity
as to present no critical or catastrophic hazard. Also, to ensure
quality of performance in the structural area for any payload
(spacecraft) project. Central to the program is fracture control
analysis, which includes the concepts of fail-safe and safe-life,
defined as follows:

a.  *Fail-safe:* Ensures that a structural element, because of
    structural redundancy, will not cause collapse of the remaining
    structure or have any detrimental effects on mission performance.

b.  *Safe-life:* Ensures that the largest flaw that could remain
    undetected after non-destructive examination would not grow to
    failure during the mission.

**Functional Tests**: The operation of a unit in accordance with a
defined operational procedure to determine whether performance is within
the specified requirements.

**Hardware:** As used in this document, there are two major categories
of hardware as follows:

a.  *Prototype Hardware:* Hardware of a new design; it is subject to a
    design qualification test program and is not intended for flight.

b.  *Flight Hardware:* Hardware to be used operationally in space. It
    includes the following subsets:

```{=html}
<!-- -->
```
(i) Protoflight Hardware: Flight hardware of a new design, subject to a
    qualification test program that combines elements of prototype and
    flight acceptance verification; that is, the application of design
    qualification test levels and duration of flight acceptance tests.

(ii) Follow-On Hardware: Flight hardware built in accordance with a
     design that has been qualified either as prototype or as
     protoflight hardware; follow-on hardware is subject to a flight
     acceptance test program.

(iii) Spare Hardware: Hardware whose design has been proven in a design
      qualification test program, subject to a flight acceptance test
      program and used to replace flight hardware that is no longer
      acceptable for flight.

(iv) Re-flight Hardware: Flight hardware that has been used
     operationally in space and is to be reused in the same way; the
     validation program to which it is subject depends on its past
     performance, current status, and the upcoming mission.

**Inspection:** The process of measuring, examining, gauging, or
otherwise comparing an article or service with specified requirements.

**Instrument:** See Level of Assembly.

**Level of Assembly:** The environmental test requirements of LEVR
generally start at the component or unit-level assembly and continue
hardware/software build through the system level (referred to in LEVR as
the payload or spacecraft level). The assurance program includes the
part level. Verification testing may also include testing at the
assembly and subassembly levels of assembly; for test recordkeeping
these levels are combined into a "subassembly" level. The verification
program continues through launch, and on-orbit performance. The
following levels of assembly are used for describing test and analysis
configurations:

a.  *Part:* A hardware element that is not normally subject to further
    subdivision or disassembly without destruction of design use.
    Examples include resistor, integrated circuit, relay, connector,
    bolt, and gaskets.

b.  *Subassembly:* A subdivision of an assembly. Examples are wire
    harness and loaded printed circuit boards.

c.  *Assembly:* A functional subdivision of a component consisting of
    parts or subassemblies that perform functions necessary for the
    operation of the component as a whole. Examples are a power
    amplifier and gyroscope.

d.  *Component or unit:* A functional subdivision of a subsystem and
    generally a self-contained combination of items performing a
    function necessary for the subsystem's operation. Examples are
    electronic box, transmitter, gyro package, actuator, motor, battery.
    For the purposes of this document, "component" and "unit" are used
    interchangeably.

e.  *Section:* A structurally integrated set of components and
    integrating hardware that form a subdivision of a subsystem, module,
    etc. A section forms a testable level of assembly, such as
    components/units mounted into a structural mounting tray or
    panel-like assembly, or components that are stacked.

f.  *Subsystem:* A functional subdivision of a payload consisting of two
    or more components. Examples are structural, attitude control,
    electrical power, and communication subsystems. Also included as
    subsystems of the payload are the science instruments or
    experiments.

g.  *Instrument*: A spacecraft subsystem consisting of sensors and
    associated hardware for making measurements or observations in
    space. For the purposes of this document, an instrument is
    considered a subsystem (of the spacecraft).

h.  *Module:* A major subdivision of the payload that is viewed as a
    physical and functional entity for the purposes of analysis,
    manufacturing, testing, and record keeping. Examples include
    spacecraft bus, science payload and upper stage vehicle.

i.  *Payload:* An integrated assemblage of modules, subsystems, etc.,
    designed to perform a specified mission in space. For the purposes
    of this document, "payload" and "spacecraft" are used
    interchangeably. Other terms used to designate this level of
    assembly are Laboratory, Observatory, and satellite.

j.  *Spacecraft:* See Payload. Other terms used to designate this level
    of assembly are Laboratory, Observatory, and satellite.

**Limit Level**: The maximum expected flight.

**Limited Life Items**: Spaceflight hardware that (1) has an expected
failure-free life that is less than the projected mission life, when
considering cumulative ground operation, storage and on-orbit operation,
and (2) has limited shelf life material used to fabricate flight
hardware.

**Maintainability:** A measure of the ease and rapidity with which a
system or equipment can be restored to operational status following a
failure. It is characteristic of equipment design and installation,
personnel availability in the required skill levels, adequacy of
maintenance procedures and test equipment, and the physical environment
under which maintenance is performed.

**Margin:** The amount by which hardware capability exceeds mission
requirements.

**Mission Assurance:** The integrated use of the tasks of system safety,
reliability assurance engineering, maintainability engineering, mission
environmental engineering, materials and processes engineering,
electronic parts engineering, quality assurance, software assurance,
configuration management, and risk management to support NASA projects.

**Module:** See Level of Assembly.

**Monitor:** To keep track of the progress of a performance assurance
activity; the monitor need not be present at the scene during the entire
course of the activity, but will review resulting data or other
associated documentation (see Witness).

**Nonconformance:** A condition of any hardware, software, material, or
service in which one or more characteristics do not conform to
requirements. As applied in quality assurance, nonconformances fall into
two categories -- discrepancies and failures. A discrepancy is a
departure from specification that is detected during inspection or
process control testing, etc., while the hardware or software is not
functioning or operating. A failure is a departure from specification
that is discovered in the functioning or operation of the hardware or
software.

**Offgassing:** The emanation of volatile matter of any kind from
materials into a manned pressurized volume.

**Outgassing:** The emanation of volatile materials under vacuum
conditions resulting in a mass loss and/or material condensation on
nearby surfaces.

**Part:** See Level of Assembly.

**Payload:** See Level of Assembly.

**Performance Verification:** Determination by test, analysis, or a
combination of the two that the payload element can operate as intended
in a particular mission; this includes being satisfied that the design
of the payload or element has been qualified and that the particular
item has been accepted as true to the design and ready for flight
operations.

**Protoflight Testing:** See Hardware.

**Prototype Testing:** See Hardware.

**Qualification:** See Design Qualification Tests.

**Red Tag/Green Tag:** Physical tags affixed to flight hardware that
mean: red (remove before flight) and green (enable before flight).

**Redundancy (of design):** The use of more than one independent means
of accomplishing a given function.

**Reliability:** The probability that an item will perform its intended
function for a specified interval under stated conditions.

**Repair:** A corrective maintenance action performed as a result of a
failure so as to restore an item to operate within specified limits.

**Rework:** Return for completion of operations (complete to drawing).
The article is to be reprocessed to conform to the original
specifications or drawings.

**Section:** See Level of Assembly.

**Similarity:** Verification by: a procedure of comparing an item to a
similar one that has been verified. Configuration, test data,
application and environment should be evaluated. It should be determined
that design differences are insignificant, environmental stress will not
be greater in the new application, and that manufacturer and
manufacturing methods are the same.

**Single Point Failure:** The failure of a single hardware element which
would result in loss of mission objectives, hardware, or crew, as
defined for the specific application or project for which a single point
failure analysis is performed.

**Spacecraft:** See Level of Assembly.

**Subassembly:** See Level of Assembly.

**Subsystem:** See Level of Assembly.

**Temperature Cycle:** A transition from some initial temperature
condition to temperature stabilization at one extreme and then to
temperature stabilization at the opposite extreme, then returning to the
initial temperature condition.

**Temperature Stabilization:** The condition that exists when the rate
of change of temperatures has decreased to the point where the test item
may be expected to remain within the specified test tolerance for the
necessary duration or where further change is considered acceptable.

**Thermal Balance Test:** A test conducted to verify the adequacy of the
thermal model, the adequacy of the thermal design, and the capability of
the thermal control system to maintain thermal conditions within
established mission limits.

**Thermal-Vacuum Test:** A test conducted to demonstrate the capability
of the test item to operate satisfactorily in vacuum at temperatures
based on those expected for the mission. The test, including the
gradient shifts induced by cycling between temperature extremes, can
also uncover latent defects in design, parts, and workmanship.

**Torque Margin:** Torque margin is equal to the torque ratio minus one.

**Torque Ratio:** Torque ratio is a measure of the degree to which the
torque available to accomplish a mechanical function exceeds the torque
required.

**Total Mass Loss (TML):** Total mass of material outgassed from a
specimen that is maintained at a specified constant temperature and
operating pressure for a specified time.

**Unit:** See Level of Assembly.

**Validation:** The process of evaluating software during, or at the end
of, the software development process to determine whether it satisfies
specified requirements.

**Verification:** The process of evaluating software to determine
whether the products of a given development phase (or activity) satisfy
the conditions imposed at the start of that phase (or activity).

**Vibroacoustics:** An environment induced by high-intensity acoustic
noise associated with various segments of the flight profile; it
manifests itself throughout the payload in the form of directly
transmitted acoustic excitation and as structure-borne random vibration.

**Workmanship Tests:** Tests performed during the environmental
verification program to verify adequate workmanship in the construction
of a test item. It is often necessary to impose stresses beyond those
predicted for the mission in order to uncover defects. Thus random
vibration tests are conducted specifically to detect bad solder joints,
loose or missing fasteners, improperly mounted parts, etc. Cycling
between temperature extremes during thermal-vacuum testing and the
presence of electromagnetic interference during EMC testing can also
reveal the lack of proper construction and adequate workmanship.

**Witness:** A personal, on-the-scene observation of a performance
assurance activity with the purpose of verifying compliance with project
requirements (see Monitor).