**Outer Planets/Solar Probe Project**

**Mission Assurance Plan**

Note: Printed copies of this document may not be relied on for official
purposes. The current version is in the Product Data Management System
(PDMS) at [http://pdms](http://pdms/)

Prepared by: Section 515

Richard Kemski

OP/SP Mission Assurance Manager

JPL D-18353, Rev. B

August 21, 2000

![](media/image1.wmf){width="1.0715277777777779in"
height="0.36319444444444443in"}

Jet Propulsion Laboratory

California Institute of Technology

**OP/SP Mission Assurance Plan**

![](media/image2.png){width="4.208333333333333in"
height="6.236111111111111in"}

TABLE OF CONTENTS

Document Log [iv](#document-log)

1.0 MISSION ASSURANCE PLAN [1](#mission-assurance-plan)

1.1 General [1](#general)

1.2 Implementation [1](#implementation)

1.3 Reviews [2](#reviews)

1.4 Environmental Requirements [2](#environmental-requirements)

1.4.1 Radiation Control Plan [2](#radiation-control-plan)

1.5 Systems Safety [3](#systems-safety)

1.6 Risk Management [3](#risk-management)

1.7 Configuration Management [3](#configuration-management)

1.8 Lessons Learned [3](#lessons-learned)

1.9 Materials and Processes Control
[3](#materials-and-processes-control)

1.10 Contractor Requirements [4](#contractor-requirements)

1.11 Waivers [4](#waivers)

2.0 QUALITY ASSURANCE REQUIREMENTS FOR OP/SP
[5](#quality-assurance-requirements-for-opsp)

2.1 Purpose [5](#purpose)

2.2 Scope [5](#scope)

2.3 Applicable Documents [5](#applicable-documents)

2.4 Resource Management [5](#resource-management)

2.4.1 Training and Certification [5](#training-and-certification)

2.4.2 Information [6](#information)

2.5 Product Realization [6](#product-realization)

2.5.1 General Requirements [6](#general-requirements)

2.5.2 Design and Development Review [6](#design-and-development-review)

2.5.3 Quality Assurance Requirements for Engineering Model Hardware
[7](#quality-assurance-requirements-for-engineering-model-hardware)

2.5.4 Acceptance and Environmentsl Test Verification
[7](#acceptance-and-environmentsl-test-verification)

2.5.5 Ground Support Equipment [8](#ground-support-equipment)

2.5.6 Control of Changes [8](#control-of-changes)

2.5.7 Procurement Activities [9](#procurement-activities)

2.5.8 JPL Quality Assurance Activities at Contractors and Suppliers
[10](#jpl-quality-assurance-activities-at-contractors-and-suppliers)

2.6 Measurement, Analysis and Improvement
[11](#measurement-analysis-and-improvement)

2.6.1 Measurement and Monitoring of System Performance
[11](#measurement-and-monitoring-of-system-performance)

2.6.2 Measurement and Monitoring of Processes
[11](#measurement-and-monitoring-of-processes)

2.6.3 Measurement and Monitoring of Product
[11](#measurement-and-monitoring-of-product)

2.6.4 Control of Nonconforming Product
[13](#control-of-nonconforming-product)

2.6.5 Records [13](#records)

2.6.6 End Item Data Package [14](#end-item-data-package)

2.6.7 Assembly, Test, and Launch Operations Support
[15](#assembly-test-and-launch-operations-support)

2.7 Software Development Process Tailoring
[15](#software-development-process-tailoring)

2.7.1 General Software Development Process Requirements
[15](#general-software-development-process-requirements)

2.8 Software Process and Product Metrics
[16](#software-process-and-product-metrics)

2.8.1 Metrics Requirements [16](#metrics-requirements)

2.8.2 Software Assurance Activities [17](#software-assurance-activities)

2.9 Software Safety [17](#software-safety)

2.9.1 Software Safety Requirements [17](#software-safety-requirements)

2.9.2 Software Assurance Activities
[17](#software-assurance-activities-1)

3.0 HARDWARE RELIABILITY ASSURANCE PLAN
[19](#hardware-reliability-assurance-plan)

3.1 Introduction [19](#introduction)

3.1.1 Scope [19](#scope-1)

3.1.2 Purpose [19](#purpose-1)

3.1.3 Objectives [19](#objectives)

3.1.4 Responsibilities [19](#responsibilities)

3.2. Applicable Documents [19](#applicable-documents-1)

3.2.1 Documents [19](#documents)

3.3 Reliability Assurance Requirements
[20](#reliability-assurance-requirements)

3.3.1 Reliability Analyses Requirements
[20](#reliability-analyses-requirements)

3.3.2 Success-Critical Single Failure Point (SFP)
[21](#success-critical-single-failure-point-sfp)

3.3.3 Reliability Analyses [21](#reliability-analyses)

3.3.3.1 FMECA [21](#fmeca)

3.3.3.2. Electrical/Electronic Worst Case Analysis
[21](#electricalelectronic-worst-case-analysis)

3.3.3.3. Mechanical Worst Case Analysis
[22](#mechanical-worst-case-analysis)

3.3.3.4. Electronic and Electromechanical Parts Stress Analysis
[23](#electronic-and-electromechanical-parts-stress-analysis)

3.3.3.5. Structural [23](#structural)

3.3.3.6. Thermal [23](#thermal)

3.3.3.7 Single Event Effects Analysis
[23](#single-event-effects-analysis)

3.3.3.8 Sneak circuit analysis [24](#sneak-circuit-analysis)

3.3.4 Operating Time Requirements [24](#operating-time-requirements)

4.0 PFR PLAN [25](#pfr-plan)

4.1 Introduction [25](#introduction-1)

4.1.1 Purpose [25](#purpose-2)

4.1.2 Scope [25](#scope-2)

4.2 Applicable Documents [25](#applicable-documents-2)

4.3 Problem/Failure Reporting System Requirements
[25](#problemfailure-reporting-system-requirements)

4.3.1 General [25](#general-1)

4.3.2 PFR and AR Starting Points [26](#pfr-and-ar-starting-points)

4.3.2.1 PFRs for: [26](#pfrs-for)

4.3.2.2 ARs for: [26](#ars-for)

4.3.3 Requirements for PFRs and ARs [26](#requirements-for-pfrs-and-ars)

4.3.3.1 Incidents Requiring Reports [26](#incidents-requiring-reports)

4.3.3.2 Timeliness of Reporting and Release
[27](#timeliness-of-reporting-and-release)

4.3.3.3 Responsibility of Reporting [27](#responsibility-of-reporting)

4.3.3.4 Form for Reporting [27](#form-for-reporting)

4.3.3.5 Analysis Requirements [27](#analysis-requirements)

4.3.3.6 Corrective Action Requirements
[27](#corrective-action-requirements)

4.3.3.7 Criticality and Cause/Corrective Action Rating
[28](#criticality-and-causecorrective-action-rating)

4.3.3.7.1 Failure Effect Rating [28](#failure-effect-rating)

4.3.3.7.2 Cause and Corrective Action Rating
[29](#cause-and-corrective-action-rating)

4.3.3.8 Risk Assessment [30](#risk-assessment)

4.3.3.8.1 Red Flag PFRs [30](#red-flag-pfrs)

4.3.3.8.2 Preliminary Rating of PFRs [30](#preliminary-rating-of-pfrs)

4.3.3.9 Safety Rating and Assessment [31](#safety-rating-and-assessment)

4.3.3.10 Spacecraft Significant Event File (SSEF) and Alert/Concern
Assessment
[31](#spacecraft-significant-event-file-ssef-and-alertconcern-assessment)

4.3.3.11 Review, Approval, and Closure
[31](#review-approval-and-closure)

4.3.3.11.1 PFR Review, Approval and Closure
[31](#pfr-review-approval-and-closure)

4.4 Contractor Problem/Failure Reporting Requirements
[34](#contractor-problemfailure-reporting-requirements)

4.4.1 General [34](#general-2)

4.4.2 Liaison and Submittals to JPL [34](#liaison-and-submittals-to-jpl)

5.0 ELECTRONIC PARTS PROGRAM REQUIREMENTS
[35](#electronic-parts-program-requirements)

5.1 Introduction [35](#introduction-2)

5.1.1 Purpose [35](#purpose-3)

5.1.2 Applicability [35](#applicability)

5.1.3 Applicable Documents [35](#applicable-documents-3)

5.2 Requirements [36](#requirements)

5.2.1 Management Requirements [36](#management-requirements)

5.2.2 Reviews [36](#reviews-1)

5.3 Parts Selection [36](#parts-selection)

5.3.1 Parts Classification [36](#parts-classification)

5.3.1.1 Standard Parts [37](#standard-parts)

5.3.1.2 Nonstandard Parts [37](#nonstandard-parts)

5.3.1.3 Die [38](#die)

5.3.1.4 Noncompliant Parts [38](#noncompliant-parts)

5.3.2 Application Specific Integrated Circuit (ASIC) Requirements
[38](#application-specific-integrated-circuit-asic-requirements)

5.3.2.1 Digital ASIC Test Requirements
[38](#digital-asic-test-requirements)

5.3.2.2 Mixed-Signal ASIC Test Requirements
[38](#mixed-signal-asic-test-requirements)

5.3.3 MCM/Hybrid Requirements [39](#mcmhybrid-requirements)

5.4 Radiation Requirements [40](#radiation-requirements)

5.4.1 Total Ionizing Dose (TID) [40](#total-ionizing-dose-tid)

5.4.2 Dose Rate [40](#dose-rate)

5.4.3 Displacement Damage [40](#displacement-damage)

5.4.4 Single Event Latchup (SEL) [41](#single-event-latchup-sel)

5.4.5 Single Event Upset (SEU) [41](#single-event-upset-seu)

5.4.6 Single Event Burnout (SEB) [41](#single-event-burnout-seb)

5.4.7 Single Event Gate Rupture (SEGR)
[41](#single-event-gate-rupture-segr)

5.5 Parts Acquisition [42](#parts-acquisition)

5.5.1 Use of Residual (Heritage) Parts Inventory
[42](#use-of-residual-heritage-parts-inventory)

5.5.2 Parts Procurement [42](#parts-procurement)

5.5.3 Backward Traceability [42](#backward-traceability)

5.5.4 Parts Data Requirements [42](#parts-data-requirements)

5.5.5 Customer Source inspection [42](#customer-source-inspection)

5.5.6 Post-Programming Burn-In for Programmable Devices
[42](#post-programming-burn-in-for-programmable-devices)

5.5.7 Destructive Physical Analysis (DPA)
[43](#destructive-physical-analysis-dpa)

5.6 Electronic Parts Application [43](#electronic-parts-application)

5.6.1 Parts Derating [43](#parts-derating)

5.6.2 Electrostatic Discharge (ESD) Control Requirements for
Static-Sensitive Parts
[43](#electrostatic-discharge-esd-control-requirements-for-static-sensitive-parts)

5.6.3 NASA and Government Industry Data Exchange Program (GIDEP) Alerts
[44](#nasa-and-government-industry-data-exchange-program-gidep-alerts)

5.6.4 Parts Failure Analysis [44](#__RefHeading___Toc491480099)

5.6.5 As-Built Parts List [44](#as-built-parts-list)

5.7 System Contractors [45](#system-contractors)

Acronym List [47](#acronym-list)

# Document Log

  ----------- -------------- -------------- ------------------------------
  **Issue**   **Date**       **Pages        **Description**
                             Affected**     

  **Rev. B**  **8/21/00**    **Pg. 31-32,   **Added Flight Instruments
                             par.           Development Manager to PRB
                             4.3.3.11.1**   membership and PFR closure
                                            process.**

  **Rev.B**   **8/21/00**    **Pg. 33,      **Added Flight Instruments
                             Figure 1**     Development Manager to PFR
                                            flow.**

  **Rev. B**  **8/21/00**    **Pg. 40, Par. **Added GaAs transistors and
                             5.4.1**        MMIC device exception to RLAT
                                            requirement.**

  **Rev. B**  **8/21/00**    **Pg. 47,      **Added Flight Instruments
                             Acronym List** Development Manager (FIDM) to
                                            list.**

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            

                                            
  ----------- -------------- -------------- ------------------------------

# **1.0 MISSION ASSURANCE PLAN**

## 1.1 General

This section defines the Outer Planets/Solar Probe (OP/SP) Project's
approach to Mission Assurance. The approach described here is in
compliance with the JPL Process for Tailoring Mission Assurance to
Specific Projects (JPL D-12872, Rev. 1). The Mission Assurance Plan is
tailored to the OP/SP Project requirements of developing and integrating
hardware and software for the Europa Orbiter, Pluto/Kuiper Express and
Solar Probe Missions.

The following characteristics of this Project will be given appropriate
consideration in the development of all aspects of the Mission Assurance
Program:

Assumed Mission Lifetimes: Europa Orbiter -- 6 1/2 years, Pluto/Kuiper
Express - 14 years, Solar Probe - 6 years,

The implementation approach defined herein was determined by identifying
the driving customer mission characteristics and requirements followed
by the identification of the various Mission Assurance activities that
address the mission's characteristics and requirements. These results
were then reviewed by the Mission Assurance team, Project Management and
PEMs and are incorporated in this document. The driving requirements on
Mission Assurance are:

Radiation (Europa Orbiter)

Long life (Pluto/Kuiper Express (14 years), Europa Orbiter (6 ½ years),
Solar Probe (6 years)

## 1.2 Implementation

A Mission Assurance Manager (MAM) shall be assigned as a member of the
OP/SP Project staff, reporting to the Project Manager. The MAM shall be
responsible for coordinating the support and participation of the
various areas of mission assurance expertise and will advise the Project
Manager on all aspects of risk management and control.. The Mission
Assurance Program and its functional supporting elements will have high
visibility to both the Project Management and the independent Safety and
Mission Assurance Directorate (SMAD). The MAM, with the concurrence of
the Project Manager, will be responsible for reporting the status of the
OP/SP Mission Assurance Program. At the Project MMRs and monthly SMAD
status reviews.

The Mission Assurance Program will be implemented using a concurrent
engineering approach in all related disciplines. The MAM and other key
personnel being an integral part of the Project Design Team will
facilitate this.

Due to the complexity of the individual Mission Assurance disciplines,
the MAM will have control of the funding resources to obtain the support
of engineering specialists, including quality assurance, reliability
engineering, electronic parts, software assurance, environmental
requirements and testing, to assure Mission Assurance technical
excellence.

## 1.3 Reviews

The Project shall implement a formal review program commensurate with
the guidelines described in the JPL Guidelines for Reviews (JPL D-10401,
Rev. A) This document is compliant with the requirements of NPG 7120.5A.
The Project Manager shall appoint a Standing Review Board and conduct,
as a minimum, the following formal reviews for each mission:

-   PDR

-   CDR

-   Assembly and/or Subsystem PDRs and CDRs

-   Inheritance Reviews (where applicable)

-   Test Readiness Reviews (TRRs)

-   Hardware Readiness and Certification Reviews (HRCR)

-   Software Readiness and Certification Reviews (SRCR)

-   Spacecraft Pre-ship Review

-   Launch Readiness Review (LRR)

Pre-environmental test reviews, functional requirements review, and ASIC
reviews may be informal peer reviews. Additional informal reviews may be
convened at the Project Manager's discretion.

## 1.4 Environmental Requirements

The environmental requirements for OP/SP are contained in JPL D-18354.
The environmental requirements for X2000 IFDP, which is applicable to
the avionics subsystem, are contained in the X2000 First Delivery
Project Environmental Design and Test Requirements (JPL D-15517, Rev.
B). The environmental requirements specific to the Stirling Radioisotope
Power Source (SRPS) are contained in JPL D-18868. The intent of these
documents is to qualify the OP/SP deliverables over the enveloped set of
mission requirements. The environmental requirements for the F5 RTG will
be determined by JPL and DOE.

### 1.4.1 Radiation Control Plan

The extreme Jovian and near-Sun radiation environments necessitate the
implementation of a Radiation Control Plan (RCP). The RCP (JPL D-18357)
shall be implemented to verify that the OP/SP hardware has been
evaluated for survivability in the Jovian and Solar radiation
environments. The Radiation Control Engineer (RCE) shall work
concurrently with the CogEs, Reliability Engineer and Parts Program
Engineer in order to facilitate: the completion of the Radiation
Analysis Completion Statements (RACS) and the verification that all
OP/SP hardware meets the mission radiation requirements.

## 1.5 Systems Safety

The OP/SP Project Systems Safety Plan (JPL D-18355) establishes the
overall systems safety for the OP/SP Project. The plan provides a
management approach for assuring safe design and operations throughout
all activities associated with development and delivery to the user
projects. It is the policy of JPL and the OP/SP Project to ensure
personnel and hardware safety in consonance with Project achievement.
Personnel involved with the OP/SP Project will have a thorough knowledge
of systems safety practices and shall apply it to assure safe and
successful missions.

## 1.6 Risk Management

The OP/SP Project shall implement a risk management program consistent
with NASA NPG 7120.5A. The OP/SP Project Manager shall assign a Project
level Risk Manager. The Risk Manager shall be responsible for the
coordination of the Significant Risk Lists (SRL's), risk status
reporting, risk analyses and shall participate in risk management
decisions. The Outer Planets/Solar Probe Project Risk Management Plan
(JPL D-18863) describes the implementation of risk management for OP/SP
.

## 1.7 Configuration Management

OP/SP shall implement a configuration management program at all levels
of hardware and software development. The OP/SP Project Manager shall
assign a Project level Configuration Engineer (CE). The Configuration
Engineer shall be responsible for managing the configuration of
prototype, ProtoFlight, EM and FM hardware. The CE shall coordinate
software configuration management with TMOD/MDS to provide overall CE
cognizance. The Configuration Management Plan (JPL D-18356) describes
the implementation of configuration management for OP/SP. .

## 1.8 Lessons Learned

The OP/SP Project shall implement the infusion of NASA (including JPL)
lessons learned into the design, development, and test and integration
of the Project's hardware and software deliverables. The Mission
Assurance Manager will support the development and implementation of the
lessons learned process. The OP/SP PEMs and CogEs shall be responsible
for documenting their responses to each lesson learned prior to the
Mission CDR.

## Materials and Processes Control

All implementing organizations, both internal and external to JPL, shall
meet the requirements of the OP/SP Materials and Process Control Plan,
JPL D-18570.

## 

## 1.10 Contractor Requirements

All Project contractors and their subcontractors shall observe all
requirements contained herein. Project contractors shall submit for JPL
review and approval, ISO 9000 compliant Implementation Plans describing
how the requirements of this document are to be met. Contractors shall
designate an individual within their project organization to be
responsible for planning and management of Mission Assurance activities
including:

-   Overall Product Assurance

```{=html}
<!-- -->
```
-   Hardware Quality Assurance

-   Software Quality Assurance

-   Reliability Assurance

-   Problem Reporting System

-   Parts Program

-   System Safety

-   Materials and Processes Control

-   Contamination Control

That person shall be responsible for monitoring to assure proper and
timely accomplishment of the required Mission Assurance tasks. The
contractors Mission Assurance organization, in general, will have an
independent path to upper management to raise Mission Assurance issues.
The contractor shall implement and maintain a system of monthly
reporting to the OP/SP Project Office, in a manner and format such as to
provide JPL the visibility and status of the contractor's and all
subcontractor's Mission Assurance Programs (i.e., Product Assurance).
Deviations from JPL approved contractor plans shall be documented by the
Contract Technical Manager (CTM) per the JPL Waiver Procedure
(DMIE-15032).

## 1.11 Waivers

All deviations from the requirements stated herein shall be documented
per the JPL Waiver Procedure (DMIE-15032). The Project waiver request
initiators may obtain waiver numbers electronically in the Project Data
Management System (PDMS).

# **2.0 QUALITY ASSURANCE REQUIREMENTS FOR OP/SP**  {#quality-assurance-requirements-for-opsp .unnumbered}

## 2.1 Purpose

This section covers three specific areas for the OP/SP Project: the
policies and procedures required in the JPL Product Delivery System
(PDS), the processes and resources needed to achieve the desired
results, and the verification activities and criteria required for
acceptability.

## 2.2 Scope

This plan defines the detailed quality assurance requirements and
activities to be implemented during the formulation, design, build,
assemble and test (DBAT) phases of the OP/SP Project. It includes only
those quality system requirements required by the Project, and/or by the
nature of the product, necessary to produce conforming product. It
encompasses all program flight, non-flight, test and ground support
hardware and software.

The following Quality Assurance Requirements apply to all JPL
organizations supporting the OP/SP Project.

## 2.3 Applicable Documents

ISO 9001 Quality Assurance for Design, Development, Production,
Installation and Servicing

> JPL D-15378 The JPL Software Development Process Description
>
> ISO 9000-3 Quality management and quality assurance standards-Part 3:
> Guidelines for the application of ISO 9001: 1994 to the development,
> supply, installation and maintenance of computer software, second
> edition 1997-12-17.
>
> JPL D-18864 OP/SP Software Management Plan
>
> JPL D-18356 OP/SP Configuration Management Plan
>
> JPL D-16635 Mission Data System Software Quality Assurance Plan

## 2.4 Resource Management

### 2.4.1 Training and Certification

Individuals working on flight shall be trained and certified to the
requirements of D-8208 or the approved equivalent supplier document.

### 2.4.2 Information

### 

The QAR (lead hardware Quality Assurance Representative) and SAR (lead
Software quality Assurance Representative) shall define, monitor,
collect, analyze and report to the OP/SP Project, through the MAM, the
information necessary for the control of processes and to ensure
conformity of products. Metrics that characterize the program with
respect to trends observed over time allow for both predictive behavior
and continuous improvement efforts. The selection and definition of
appropriate value-added metrics will be a joint OP/SP Project
Office-Quality Assurance activity.

## 2.5 Product Realization

### 2.5.1 General Requirements

The Assembly and Inspection Data Sheet (AIDS), Forms 2916 and 2916-1,
shall be utilized for hardware fabrication, assembly, integration and
testing performed on-site at JPL. The AIDS, or equivalent planning, will
provide clear and concise instructions defining specific assembly
instructions, inspection points, inspection criteria and special
techniques. The AIDS, or equivalent, will be reviewed, approved and
signed prior to the beginning of operations defined in the text. Flight
hardware at JPL must be accompanied by the appropriate documentation at
all times.

Workmanship standards on OP/SP Project Flight Hardware shall meet or
exceed the requirements of D-8208.

### 2.5.2 Design and Development Review

The QAR and SAR shall participate in the following reviews, as
appropriate:

-   Preliminary Design Reviews

```{=html}
<!-- -->
```
-   Critical Design Reviews

```{=html}
<!-- -->
```
-   Inheritance Reviews

```{=html}
<!-- -->
```
-   Readiness Reviews (Manufacturing, Pre-environmental, Test, Launch
    Vehicle Integration, etc.)

```{=html}
<!-- -->
```
-   Pre-Shipment Acceptance Reviews

```{=html}
<!-- -->
```
-   Contractor End-Item-Data-Package Reviews

```{=html}
<!-- -->
```
-   Hardware Certification Reviews

-   Software Review and Certification Requirement (SRCR)

    The QAR and SAR perform Quality Assurance risk assessments early in
    the formulation phase, during the design process, and throughout the
    project/program life cycle to ensure that hardware and software
    process/development issues are evaluated relative to end-user goals.
    The QAR and SAR shall analyze designs for completeness and
    correctness in addressing mission critical and interface
    requirements. Special attention is paid to verifying requirement
    traceability and monitoring performance constraints.

    The SAR shall pay particular attention to the area of fault
    protection and safety critical requirements during all reviews. The
    details of software safety/hazards analysis are provided in Section
    2.9.

### 2.5.3 Quality Assurance Requirements for Engineering Model Hardware 

Quality assurance support of hardware engineering models shall be on an
as-requested basis. In general, quality involvement with engineering
model hardware is limited to inspection for workmanship and safety, and
verification of hardware/software and test set-up configuration.
Engineering models which are later used for protoflight or flight
purposes shall require additional quality review, as determined by the
QAR and Project personnel.

### 2.5.4 Acceptance and Environmentsl Test Verification 

> JPL Quality Assurance shall support the implementation of the OP/SP
> Project functional
>
> and environmental test program. QA shall monitor and/or witness
> acceptance and environmental testing on EM Qualification and FM
> hardware. Guidelines for QA activities in support of testing are
> listed below:
>
> • Verification of released test procedures and specifications
>
> • Completion of Facility and Operation Safety Survey's
>
> • Completion of ESD Surveys
>
> • Verification that test area is controlled to the extent necessary to
> protect hardware
>
> • Verification that requirements for hardware handling, storage,
> contamination, and environmental controls are in effect
>
> • Verification that test equipment is within calibration and/or proof
> test cycles
>
> • Verification that changes to procedures are documented and approved
> by the appropriate engineering authority

• Verification that test data is properly recorded

The SAR shall assure that test processes are properly defined and
followed. For mission critical requirements, the SAR shall analyze the
test objectives and assure that entry and exit criteria for each level
of testing is properly defined and any/all performance shortfalls are
documented and properly addressed. As a goal, exit criteria should be
met before the OP/SP Project completes the last level of validation
testing.

The SAR should also assure proper existence of evidence for performing
major software system functional capabilities testing and interface
testing.

### 2.5.5 Ground Support Equipment

Quality assurance involvement in Ground Support Equipment (GSE) shall be
limited to the level necessary to assure:

• Flight hardware/software interfaces, mechanical and/or electrical are
compliant to requirements

-   Current calibration of Electrical GSE

-   Current proof-load of Mechanical GSE

-   Cleanliness and contamination control requirements are compliant

-   Proper and legible identification of the product

-   Safety requirements are satisfied and potential hazards are
    identified

### 2.5.6 Control of Changes

Quality assurance shall participate in the control of changes by:

-   Reviewing and approving software system requirement changes after
    initial baseline is completed

-   Ensure that master red-line drawing sets are maintained when
    necessary

-   Verifying all approved changes are properly incorporated/implemented

-   Verifying product as-built configuration

-   Ensure all software system configurations under system test are
    properly identified and controlled

-   Verifying the appropriateness of the Release Description Document
    (RDD)

    Hardware inspected to pre-released or redlined documents shall be
    written-up on an Inspection Report (IR). Pre-released and redlined
    documentation shall be handled in accordance with the OP/SP
    Configuration Management Plan, JPL D-18356 sections 3.4.2 and 3.4.3.

For class A/B software, the SAR shall also participate in assessing the
criticality of the ARs (Anomaly Reports), software-related PFRs (Problem
Failure Reports) or engineering change requests, and
evaluating/reviewing the risks associated with its disposition.

The SAR may also author the software portion of the Configuration
Management (CM) plan and provide a project CM library function, if
requested by the OP/SP Project.

### 2.5.7 Procurement Activities

Contracts, purchase orders and off-lab fabrication work orders will be
coordinated with technical and quality assurance personnel to ensure
incorporation of applicable quality and technical requirements. The
OP/SP Project QAR and SAR shall support the Contract Technical Managers
during the implementation of the procurement phase in the following
areas:

-   Review procurement documentation, including Requests For Proposals
    (RFP's), Statement-Of-Work (SOW's), Procurement Requisitions and
    Equipment Specifications to ensure appropriate quality provisions
    and clauses are defined, including Contractor End-Item-Data-Package
    requirements

```{=html}
<!-- -->
```
-   Provide the Cognizant Engineer or Contract Technical Manager with
    pertinent information about the supplier by researching the Quality
    Assurance Documentation Center (QADC) Vendor Survey Database

-   Perform Vendor Survey's at potential supplier's, as required

-   Interpret and clarify quality activities that are anticipated in
    support of the Contract Negotiator, to include review of supplier
    Quality Assurance plans, and Software Configuration Management as
    applicable

-   Participate in vendor Fabrication/Manufacturing Readiness Reviews

-   Assist the project management in determining proper contract
    monitoring points based on risk assessment of contractor's
    capability, functional complexity, and mission criticality

### 2.5.8 JPL Quality Assurance Activities at Contractors and Suppliers 

JPL Quality Assurance shall monitor procurements at contractor's
facilities. Their activities shall include, but not be limited to:

-   Providing insight/oversight (as applicable), monitoring and auditing
    of contractor quality assurance activities, to include source
    inspection when necessary, to assure compliance with documented
    program quality requirements

-   Participating in contractor's design reviews

-   Review of manufacturing processes

-   Participating in the disposition of nonconforming hardware and
    acting as "NASA/Government Quality Representative" on Contractor
    Material Review Boards (MRB's)

```{=html}
<!-- -->
```
-   Monitoring specified test operations

```{=html}
<!-- -->
```
-   Performing final, pre-ship inspections and participating in Pre-ship
    reviews at the Contractor's facility

```{=html}
<!-- -->
```
-   Verifying accuracy and completeness of end-item-data-packages per
    purchase order

-   Generating a Final Inspection Report (JPL Form 1898) signifying
    acceptance and Certification of Flight Hardware and its data package

-   Verifying packaging, shipping/handling is appropriate for flight
    hardware prior to shipment to or from JPL

    Receiving inspection shall be performed to the extent necessary to
    assure that JPL procured hardware is compliant to specifications.
    Quality Assurance responsibilities for receiving inspection include
    maintaining a system of calibrated equipment capable of measuring
    mechanical hardware and generating the necessary documentation
    required by the OP/SP Project to certify hardware for flight upon
    its' acceptance. Additional receiving inspection activities include
    documenting, segregating and obtaining disposition of non-conforming
    hardware or material and maintaining a system that provides for
    continuous assessment of supplier performance.

## 2.6 Measurement, Analysis and Improvement

### 2.6.1 Measurement and Monitoring of System Performance

All hardware and software intended for flight shall have documented
evidence of acceptance by Quality Assurance. Certification of hardware
for flight will be by virtue of a final Inspection Report (IR), which
will establish the flight pedigree. As a goal, all Inspection Report's
should be closed-out prior to the Hardware Review and Certification
Record (HRCR).

Quality Assurance shall verify that all hardware is certified by virtue
of completion of Hardware Review and Certification Review (HRCR). The
JPL HRCR Form TBD will be used to verify and document the minimum OP/SP
Project requirements have been satisfied. A signed and completed HRCR
form will be necessary to accompany any critical hardware prior to
delivery to Assembly, Test, and Launch Operations (ATLO). Hardware with
open liens from the HRCR shall be authorized for flight system
integration with approval of the ATLO Manager.

The SAR shall participate in and support the delivery manager in
ensuring that all required items (including source code and
documentation) are available, prior to any Software Review and
Certification Requirement (SRCR), or delivery review. Software with open
liens from the SRCR shall be authorized for flight system integration
with approval of the ATLO Manager.

Software system metrics for monitoring the software development is
included in Section 2.8.

### 2.6.2 Measurement and Monitoring of Processes

All processes used in the fabrication of OP/SP Project Flight Hardware
will be qualified in accordance with NASA or JPL's internal procedures.
Qualification of processes shall be performed by the cognizant Technical
Division or Organization, and approved by Quality Assurance.

Software development process tailoring and requirements are specified in
Section 2.7.

### 2.6.3 Measurement and Monitoring of Product

Quality Assurance evaluates the delivered hardware/software against the
agreed to requirements and ensures any outstanding liens resulting from
deferred requirements and open problem failure reports are properly
addressed. The SAR shall also assure the delivered hardware/software has
been properly tested and that proper traceability is present.

All hardware or material destined for Qualification, Protoflight, Flight
or Flight Spare status shall be subjected to inspections performed at
the level necessary to assure:

-   Information, Electrical, Mechanical and physical dimensions and
    conditions are compliant to applicable Interface Control Documents
    (ICD's)

-   Work-stations and areas in which Flight Hardware will meet the
    required Electrostatic Discharge (ESD) protective measures as
    defined in D-1348

-   Hardware traceability requirements are satisfied

-   Compliance with the Training and Certification requirements
    specified in D-8208

-   Evidence of Supplier/Contractor or JPL inspection acceptance has
    been provided by virtue of a Certificate of Conformance, or
    equivalent

-   Applicable handling, packaging, packing and storage requirements
    have been attained

-   Any electrical interfaces and requirements are compliant

-   Compliance to the requirements for workmanship, fit, form and
    function

-   Identification of unacceptable workmanship and processing conditions
    by documenting any findings on an Inspection Report

> All software destined for Qualification, Protoflight, Flight or Flight
> Spares shall be subjected to the following assurance activities by the
> SAR:

-   Accuracy of as-built product identification

-   Existence of instructions for installing the software or appropriate
    reference to the software manual/user's manual

-   Proper test plans/procedures/reports have been released

-   Software system requirements are properly traced in a test
    traceability matrix or equivalent

-   A listing of all problem/failure reports (including open and closed)
    generated against the latest release of software has been published

    Inspection status of hardware will be indicated by means of
    inspection stamps on applicable documentation that accompanies the
    hardware. Records of JPL stamp assignments will be maintained in the
    JPL Office of Quality Assurance organization files.

    Post-test hardware inspections will be performed to determine if the
    condition of the hardware has been adversely affected by being
    subjected to the specified testing. All changes that may have
    resulted from the testing will be documented on an Inspection
    Report.

### 2.6.4 Control of Nonconforming Product

A closed-loop system for identifying, documenting, controlling and
correcting nonconformances will be implemented on the OP/SP Project.
When hardware, material or documentation is found to be non-compliant,
it shall be identified as a nonconforming article, documented as such on
an Inspection Report or Problem Failure Report and segregated, to the
extent practicable, from acceptable articles. Each nonconformance will
be reviewed and dispositioned by the Cognizant Engineer and that
disposition will require concurrence by Quality Assurance Engineering.
Nonconformances documented on IR's and PFR's requiring rework or repair
to flight or engineering model hardware shall be verified by the QAR.
Corrective action will be taken to prevent recurrence of similar
discrepancies. When a software item is found to be nonconforming to
specified requirements, it shall be controlled by the software CM
process to ensure that it is prevented from unintended use or
installation.

Contractor Material Review Boards shall be convened by Contractor QA.
The JPL Quality Assurance Representative will be a member of the OP/SP
Project Contractors' MRB(s). The QAR will obtain concurrence from the
appropriate JPL Engineering Cognizant Engineer before signing and
approving any Contractor dispositions. Contractor nonconformance reports
will become a part of the hardware's End-Item-Data-Package.

### 2.6.5 Records

Quality Assurance shall maintain records that provide evidence of
inspections, tests, as-built, configuration and hardware/software status
during all phases of the hardware fabrication, assembly, integration and
test process. Records will be clearly identified as OP/SP Project
hardware/software and maintained in a manner that provides accessibility
for audit review. These records will become a part of the End Item Data
Package that will be retained to support the OP/SP Project. The
Engineering Data Management Group will be the focal point for
compilation of End-Item-Data-Package(s). These records will be archived
at a location and for a period of time determined by the OP/SP Project
Office.

### 2.6.6 End Item Data Package

Hardware fabricated and/or assembled at JPL or procured from a
contractor shall have a data package sufficient enough to validate a
pedigree as flight worthy and to support a failure investigation, if
necessary. Contractor End-Item-Data-Package and As-Built-Data
requirements will be clearly defined in the Purchase Order or Contract
Statement of Work (SOW).

Software End-Item Data Package (EIDP) shall be prepared for each
delivered software item. The contents of the package shall include, but
are not limited to the following:

(a) As-built product identification for the software, including:

```{=html}
<!-- -->
```
i.  Operating System name and version.

ii. Programming language name and compiler manufacturer and version.

iii. Supporting development environment name and version (if any).

iv. Software version and release date.

```{=html}
<!-- -->
```
(b) All needed programs and files necessary to re-build the software
    executable.

(c) A set of detailed building instructions.

(d) Instructions for installing the software or appropriate reference to
    the software manual/user's manual.

(e) A list of new or changed capabilities and liens (comparing to the
    agreed-to baseline). Also list the approved change requests. (The
    liens refer to those baselined capabilities which are not delivered
    and hence shall not be included in the subsequent testing.)

(f) List of dates and versions of all required documents.

(g) A list of all open or closed problem/failure reports discovered
    against this release of software. (This is needed only when the
    problems are required to be tracked via problem/failure reports.)

(h) Verification test procedures/results.

    For class A/B software delivery, the following three are also
    required:

(i) Acceptance test plan/procedure/report. This shall address acceptance
    test configuration, including versions of the interfacing software
    in the RAM/PROM. Requirements traceability shall also be included to
    demonstrate that the deliverables meet the specified requirements.

(j) Completed Software Review/Certification Requirements (SRCR) form for
    the delivered item.

(k) Evidence of acceptance by the implementation organization's software
    QA.

### 2.6.7 Assembly, Test, and Launch Operations Support

> JPL Quality Assurance support activities for Assembly, Test, and
> Launch Operations will include, but not be limited to the following:
>
> • Work proactively in the safety and contamination control activity to
> ensure hardware integrity
>
> • Provide configuration support for test and flight software
>
> • Assure that project documentation requirements are met
>
> • Conduct a physical verification of all hardware to ensure that it
> meets workmanship, configuration management and other project
> requirements
>
> • Witness critical operations
>
> • Maintain a spacecraft configuration log

## Software Development Process Tailoring

### 2.7.1 General Software Development Process Requirements

The project shall tailor its software development process following the
JPL document D-15378. It also responds to the ISO 9000-3 guidelines. The
tailored software development process shall be addressed in the OP/SP
Software Management Plan (SMP).

Based on the criteria defined in JPL D-15378, the software will be
classified by the OP/SP project software engineer. Detailed
classification shall be included in its SMP.

The SMP shall also address the following:

(a) Deliverables, including documents required to be generated.

> As a minimum, the following documents for different class of software
> as listed in the table below shall be produced.

+-----------------+----------------------------------------------------+
| > Software      | > Minimum Deliverables                             |
| > Class         |                                                    |
+=================+====================================================+
| > A/B           | > Software requirements document,                  |
|                 | >                                                  |
|                 | > interface specifications (APIs & ICDs), software |
|                 | > design documentation,                            |
|                 | >                                                  |
|                 | > test plans/procedures/reports, and               |
|                 | >                                                  |
|                 | > user guides/software operator's manuals          |
|                 | >                                                  |
|                 | > adaptation guides                                |
+-----------------+----------------------------------------------------+
| > C             | > Software functional requirements document (or    |
|                 | > software capabilities list), test                |
|                 | > plans/procedures/reports and user guides         |
+-----------------+----------------------------------------------------+

(b) The criticality of the products and the type of review that the
    products are subjected to.

> \(c\) Appropriate metrics
>
> \(d\) Software development methodology.

d.  

> \(e\) Software development life cycle phases.

e.  \(f\) Software adaptation approach.

> \(g\) Governing standards and guidelines (for example, design
> guidelines, interface specification standards, and coding standards).

The SAR shall assure proper deliverables are generated and reviewed in
accordance with their processes. The SAR shall also review the quality
records periodically to assure proper process is followed.

The SAR shall assist the Project Management in tailoring the software
development process, within the constraints of cost and schedule, and
with acceptable risks.

## 2.8 Software Process and Product Metrics

### 2.8.1 Metrics Requirements

The project shall define software system metrics to meet the following
two goals:

(a) To characterize the software development process/product with
    respect to defects, modifications, requirements, and delivered
    products from the point of view of progress monitoring and product
    assurance.

(b) To build software development historical data to allow predictive
    behavior with respect to requirements, defect density, anomaly
    reports, schedules, and effort characteristics from the point of
    view of progress monitoring, product assurance and process
    improvement.

> For class A/B software, the following five metrics will be collected
> and analyzed:

(a) Product Delivery Metric

(b) Earned Value Progress Tracking Metric

(c) Use Case/Scenario (or Capabilities) Verification Metric

(d) Anomaly Closure Metrics

    The details of the first four metrics definitions and samples are
    provided in the MDS Software Quality Assurance Plan (JPL D-16635).

### 2.8.2 Software Assurance Activities

The selection/definition of appropriate metrics for progress monitoring
or product quality assessment will be elaborated upon and agreed-to by
the SAR and the implementation organization Management. The criteria of
selection should be based on the added values the metric provides. The
deployment of metrics collection should be supported by an
infrastructure which is minimally intrusive to the development
activities.

By agreement of all parties involved, the SAR will perform the metric
data collection and analysis.

## 2.9 Software Safety

### 2.9.1 Software Safety Requirements

During the system safety Preliminary Hazard Analysis (PHA), the OP/SP
project shall determine the allocation of safety controls to either
hardware or software. As software controls become more clearly defined,
the SAR shall perform software safety/hazard analyses to identify
individual components, modules, etc. that are safety-critical. The
results from the OP/SP Failure Mode Effects and Criticality Analysis
(FMECA) will also be used as part of the inputs for the software safety
requirements. The design shall not allow any software components to
become safety critical and impact personnel safety.

### 2.9.2 Software Assurance Activities

The SAR shall assure the identification, implementation, and
verification of safety-critical components are properly performed. The
SAR should assure that the software will execute within a system context
without contributing to hazards. The SAR should assure the software will
not affect system safety in the following two ways:

(a) It cannot produce output values or timing that puts the system in a
    hazardous state.

(b) It cannot fail to recognize or handle hardware failures which it is
    required to control or respond to.

# 3.0 HARDWARE RELIABILITY ASSURANCE PLAN

## 3.1 Introduction

### 3.1.1 Scope

This section establishes the detailed reliability assurance requirements
to be satisfied and activities to be implemented during the design,
fabrication, integration, test, and delivery of all hardware elements
for the OP/SP project.

### 3.1.2 Purpose

The purpose of this section is to define the reliability assurance
requirements, which when satisfied, will serve as verification that all
assemblies and subsystems meet their performance requirements in the
intended operating environment.

### 3.1.3 Objectives

The objective of this section is to identify the reliability tasks and
activities necessary to accomplish the mission goals. To this end, this
section has the following specific objectives:

-   Assure that adequate consideration is given to reliability during
    the design and development of the flight hardware (assemblies and
    system).

-   Assure that possible sources of reliability risk are identified and
    eliminated through the design verification process.

-   

### 3.1.4 Responsibilities

Primary responsibility for the implementation and accomplishment of
activities that satisfy the requirements of this section belong to the
JPL responsible design agencies and their respective contractors and
subcontractors. Technical adequacy of the analyses shall be verified and
approved by JPL independent review or concurrent engineering generation
of the analyses.

## 3.2. Applicable Documents

### 3.2.1 Documents

JPL D-18357 OP/SP Project Radiation Control Plan

JPL D-5703 JPL Reliability Analyses Handbook

JPL D-8545, Rev. B JPL Derating Guidelines

## 3.3 Reliability Assurance Requirements

### 3.3.1 Reliability Analyses Requirements

Analyses of the hardware design shall be performed to ensure proper
designed-in reliability and consistency with mission requirements and
objectives. The analyses will be performed concurrently with the design
effort. The following reliability analyses shall utilize the methodology
described in JPL D-5703 or PEM and MAM approved methodologies:

a\. Failure Modes, Effects, and Criticality Analysis (FMECA)

1.  At assembly level interfaces

2.  At fault containment region boundaries

3.  At GSE interfaces

4.  At the flight system level

    b\. Worst Case Analysis (WCA)

    1\. On all circuits and interfaces

    c\. Stress Analysis

    1\. Parts Stress Analysis (PSA) on all Electrical and
    Electromechanical Parts

    2\. Structural

    3\. Thermal

    d\. Single Event Effect Analysis

    1.  On all flight assemblies

    2.  At the system level by considering the combined effect the
        assembly level SEE analysis results

        Responsible design agencies within JPL, contractors, and
        subcontractor organizations, shall be responsible for
        performing, documenting, and updating all of their analyses. All
        analyses shall be maintained in a current state and reflect the
        currently approved design. These agencies shall take appropriate
        actions driven by the results of each analysis.

        The results of the WCAs, PCAs, and SEE Analyses, and all
        supporting data shall be documented and provided to the
        Radiation Control Engineer to facilitate the completion of the
        Radiation Analysis Completion Statement (RACS) as required by
        the OP/SP Project Radiation Control Plan (JPL D-18357).

        For inherited hardware, existing analyses may be satisfactory if
        applicability is demonstrated by verification that all
        originally applied requirements, environments, and other
        bounding conditions envelope the corresponding elements required
        by the current application. Analyses shall be performed and
        documented, if applicability cannot be demonstrated or analysis
        has not been performed.

### 3.3.2 Success-Critical Single Failure Point (SFP)

OP/SP hardware may contain SFPs provided that a single failure will not
adversely affect hardware in another fault containment region or across
a spacecraft interface. All system SFPs shall be identified and
documented in a SFP list. No safety critical single point failures are
allowed.

### 3.3.3 Reliability Analyses

#### 3.3.3.1 FMECA

The main objective of a FMECA is to identify SFPs and to verify that
failures will not propagate and damage other hardware. The FMECA shall
be performed and documented to analyze postulated failures and identify
the potential resultant effects. The FMECA shall be performed on the
Flight configurations. The FMECA shall, as a minimum:

For interface FMECA:

-   Be performed at the slice and/or assembly level interfaces to the
    piece part level to verify that a failure in any slice and/or
    assembly interface circuit cannot propagate to and/or damage the
    interfacing circuit and or damage hardware in another fault
    containment region.

-   Verify that failures in ground support or test equipment cannot
    propagate to and damage the OP/SP hardware.

For system level FMECA:

-   Consider all operational modes

-   Verify that a failure in a system element will be detected and
    determine the system reaction to the failure.

-   Verify that a failure in a non-critical circuit (e.g., telemetry,
    current monitoring, test interfaces not used in flight) will not
    affect the performance of a critical function.

#### 3.3.3.2. Electrical/Electronic Worst Case Analysis

A WCA shall be documented for all circuit designs to demonstrate that
sufficient operating margins exist for all operating conditions and
performance requirements considering the combination of the following:

-   Part temperature range, based on those stated in the environmental
    requirements document. If the thermal analysis indicates a part
    temperature outside of the specified range, the WCA must be amended
    to take into account the thermal analysis predicted temperatures.

-   Piece part initial tolerance

-   Part aging for the operating life of the mission including ground
    test time

-   Radiation effects

-   Special factors such as shock, vibration, or vacuum where such
    conditions would contribute to variations in the circuit parameters,
    voltage, frequency, and load variations shall also be included.

The analysis shall be at least a 3-sigma worst case analysis (i.e.,
extreme value or extreme value with temperature tracking) in that the
value for each of the variable parameters shall be set to limits that
will drive the output to a maximum (or minimum) and shall consider AC,
DC, and transient condition effects on the circuit. Piece part
parametric data should be obtained from test and/or the appropriate
procurement documentation.

Analysis of protective circuitry shall be performed to ensure proper
operation if a fault were to occur. (i.e., Assume a fault condition
occurred such that the protective circuit is operating and will continue
to operate under worst case conditions.)

Electrical noise on power lines, including ground differences, and
interface signal lines shall be considered. Power supply turn on and
turn off transients shall be included.

The documentation of the WCAs shall describe all identifiable
deficiencies and performance restrictions.

#### 3.3.3.3. Mechanical Worst Case Analysis

#### 

Worst case mechanical analyses shall be performedto ensure that worst
case mechanical tolerances and thermal environments cannot adversely
affect the performance of mechanical and/or optical assemblies.

#### 3.3.3.4. Electronic and Electromechanical Parts Stress Analysis

Parts Stress Analysis shall be performed under worst case operating
conditions and documented to verify that the applied stress on each
piece part does not exceed the derating values established in JPL
D-8545, Rev. B. All analyses shall be documented on JPL-provided or
approved forms. The stress analysis shall utilize the predicted part
case temperature over the qualification temperature range .

#### 3.3.3.5. Structural

A structural stress analysis shall be performed on mechanical and
electromechanical (e.g., actuators) subsystems/assemblies at the slice
and subsystem level. The analysis shall address the effects to be
experienced by the structure due to the dynamic environment (i.e.,
acceleration, shock, vibration, and acoustic noise), including worst
case estimates for design environmental conditions.

#### 3.3.3.6. Thermal

The thermal analysis shall address the effect of the thermal
environment, including worst case estimates, for all anticipated
environmental conditions. The analysis shall address material properties
and the effect of thermal cycling on solder joints, conformal coating,
and other critical materials. As a guideline, the conservative
assumption of a maximum temperature rise from the thermal control
surface to the part case of no greater than 35°C, may be applied.

#### 3.3.3.7 Single Event Effects Analysis

Circuit designs containing parts susceptible to SEE (Single Event Upsets
and Single Event Transients) shall be analyzed to provide either an
assembly upset rate or upset probablility during a mission critical
time. The requirements regarding performance with respect to SEE during
operation for any microprocessor or its peripheral family, or any other
parts, are as follows:

-   Temporary loss of function or loss of data shall be permitted
    provided that the loss does not compromise subsystem/system health,
    full performance can be recovered, and there is no time in the
    mission that the loss is mission critical.

-   Normal operation and function shall be restored via internal
    correction methods without ground intervention in the event of an
    SEU.

-   Fault traceability shall be provided in the telemetry stream to the
    greatest extent practical for all anomalies involving SEEs.

-   Irreversible actions shall not occur as the result of an SEE.

#### 3.3.3.8 Sneak circuit analysis

Subsystem interface circuits should be analyzed to determine if sneak
paths exist with powered and unpowered circuits. If sneak paths do
exist, there must be assurance that they will not affect the function of
the circuits involved nor cause overstress to any parts.

### 3.3.4 Operating Time Requirements

Cumulative test operating time shall be tracked on OP/SP hardware. All
OP/SP flight hardware deliveries to Europa Orbiter, Pluto/Kuiper
Express, and Solar Probe shall have accumulated 500 hours (goal of 1000
hours) of operating time prior to delivery to ATLO; 1000 hours (goal of
2000) prior to launch.

# **4.0 PFR PLAN**

## 4.1 Introduction

### 4.1.1 Purpose

The purpose of this section is to define the requirements for reporting,
analysis, corrective action, review, and closure of problem/failures
documented for the OP/SP Project.

### 4.1.2 Scope

This section covers all OP/SP hardware, software, and support equipment
and associated software. The provisions of this document apply to all
activities affecting these items up to and including ATLO and launch.

## 4.2 Applicable Documents

The following documents, of the latest issue, form a part of this
document to the extent specified herein. In case of conflict between a
referenced document and this document, the conflict shall be presented
to the Mission Assurance Manager for resolution.

D-1926 Reporting System and Procedure for Spaceflight Significant Events
File

D-8091 JPL Standards Document, Problem/Failure Reporting System,
Guidelines and Procedures

D-11119 Alert/Concerns Handbook

## 4.3 Problem/Failure Reporting System Requirements

### 4.3.1 General

The requirements and processes described herein have been tailored from
D-8091. OP/SP hardware and software shall be supported by a
problem/failure reporting, analysis and corrective action program. Two
types of problem/failure reports shall be utilized:

a.  Problem Failure Reports shall be used for:

```{=html}
<!-- -->
```
(1) Prototypes, Engineering Models (both qualified and nonqualified),
    ProtoFlight and Flight hardware

(2) Hardware and software during I & T (hardware testbed) and ATLO

(3) Support equipment (hardware and software)

```{=html}
<!-- -->
```
b.  Anomaly Reports (ARs) shall be used for:

```{=html}
<!-- -->
```
(1) Developmental and Flight software

### 4.3.2 PFR and AR Starting Points

The required starting points for PFRs are defined below. Reporting
requirements continue during all subsequent phases of testing and
integration.

#### 4.3.2.1 PFRs for:

(1) Hardware to begin at first application of power of each PT, EM, PF,
    and FM assembly.

(2) Support equipment hardware and software (including test and facility
    equipment) after GSE acceptance testing.

    GSE anomalies that occur during GSE acceptance testing shall be
    logged and included in the End Item Data Package.

#### 4.3.2.2 ARs for:

\(1\) Software to begin at S/W development, integration and/or test on
workstations.

ARs will be converted to PFRs, within 24 hours, at the start of System I
& T.

### 4.3.3 Requirements for PFRs and ARs

This section outlines the requirements for PFRs and ARs.

#### 4.3.3.1 Incidents Requiring Reports

All incidents require the initiation of a PFR or AR, including:

-   All hardware failures, damage, problems, malfunctions, anomalies,
    nonstandard or unexpected results, and incidents of performance
    outside specification limits; also incidents of anomalous dynamic
    performance such as glitches, drifts, transients, stepping,
    oscillation, etc., within specification limits.

-   All software and procedure problems, errors, ambiguities encountered
    with the software while utilized with OP/SP hardware or while being
    checked in preparation for operation with OP/SP hardware or while in
    the workstation environment.

-   All support equipment, test equipment, or test facilities problems,
    failures, and anomalous performance, including procedures and
    operator actions, while being utilized in conjunction with OP/SP
    hardware or while being checked in preparation for operation with
    OP/SP hardware.

-   All incidents involving actual or potential damage to hardware,
    software, or injury to personnel, from testing, handling, shipping,
    or storage.

#### 4.3.3.2 Timeliness of Reporting and Release

All reportable incidents shall be documented within one working day of
incident/observation. The reports shall be released without delay,
regardless of the incident's apparent magnitude.

#### 4.3.3.3 Responsibility of Reporting

The individual in charge of the activity, or of the OP/SP hardware,
software, test equipment, or support equipment at the time a reportable
incident occurs has the primary responsibility to originate the P/FR or
AR; however, any individual observing a reportable incident has a
responsibility to originate a PFR or AR.

#### 4.3.3.4 Form for Reporting

All problem/failure incidents shall be documented by entering the
appropriate information electronically into the JPL UPRS (Unified
Problem Reporting System), AAMS (Automated Anomaly Management System) or
contractors equivalent system (with Mission Assurance Manager approval).

#### 4.3.3.5 Analysis Requirements

Analyses of the PFRs and ARs shall be conducted to the extent necessary
to define the problem, determine the failure mechanism, identify whether
parts may have been overstressed as a result of the failure, address the
effect of the incident on associated elements of the subsystem and the
system (including near and long-term effects on desired functional
performance), and determine the necessary corrective action. The
proposed corrective action shall be analyzed to ensure that the
implementation will address both the problem and any interactions with
other elements of the subsystem and the system.

#### 4.3.3.6 Corrective Action Requirements

When corrective action is implemented, all documents defining changes in
design configuration, or document revisions shall be processed in
accordance with configuration control requirements and referenced on the
PFR or ARs prior to closeout review and approval.

Verification of corrective action shall involve appropriate analyses,
breadboard or prototype tests, rerun of qualification, protoflight or
acceptance tests, regression testing, or the completion of special tests
to ensure that correction has been accomplished. After completion of the
corrective action, the item must again be subjected to the conditions
under which the problem/failure occurred and must perform successfully
under those conditions.

#### 4.3.3.7 Criticality and Cause/Corrective Action Rating

Each PFR shall be assigned a two-factored rating.

##### 4.3.3.7.1 Failure Effect Rating

The Failure Effect Rating is an assessment of the consequence or the
impact of the problem or failure if it had occurred in flight. It shall
not be an assessment of the adequacy of the corrective action.
Redundancy shall not be considered in making this assessment. The
assessment shall be 1, 2, or 3 based on the criteria listed below. Table
1 indicates the P/FR rating requirements.

Rating 1: Negligible effect on mission performance and system safety.

(1) No appreciable change in functional capability.

(2) Minor degradation of engineering or science capability.

(3) Support equipment or test equipment problem/failure.

(4) SE, TE, or operator induced failure.

(5) Workmanship failures found at initial test opportunity.

(6) Causes negligible operational difficulties or constraints.

(7) Negligible or no reduction in lifetime.

(8) Cannot occur in flight.

Rating 2: Significant effect on mission performance or system safety.

(1) Appreciable change/degradation in functional capability.

(2) Appreciable degradation of engineering or science capability.

(3) Causes significant operational difficulties or constraints.

(4) Significant reduction in lifetime.

Rating 3: Major or catastrophic effect on mission performance or system
safety.

(1) Major change/degradation in functional capability.

(2) Major degradation of engineering or science capability.

(3) Causes major operational difficulties or constraints.

(4) Major reduction in lifetime.

##### 4.3.3.7.2 Cause and Corrective Action Rating

The Cause/Corrective Action Rating is an assessment of the certainty
that the exact failure cause has been determined and that the corrective
action will eliminate any known possibility of recurrence of the
problem/failure in flight.

The assessment shall be 1, 2, 3, or 4 based on the criteria listed
below.

Rating 1: Known Cause/Certainty in corrective action.\
Analysis, corrective action and verification of correction are
considered to have determined the cause and have defined an effective
corrective action that has been implemented and verified by test or
other demonstration. No known possibility of recurrence in flight.

Rating 2: Unknown Cause/Certainty in corrective action.\
The cause could not be completely determined, but an effective
corrective action has been implemented and verified by test or other
demonstration; or the problem/failure (observed incident) could not be
repeated in tests or checkouts. No known possibility of recurrence in
flight.

Rating 3: Known Cause/Uncertainty in corrective action.\
Analysis, corrective action and verification of correction are
considered to have determined the cause, but effective corrective action
has not been implemented and verified by test or other demonstration.
Some possibility of recurrence in flight.

Rating 4: Unknown Cause/Uncertainty in corrective action.\
The cause could not be completely determined and no effective corrective
action has been implemented and verified by test or other demonstration.
Some possibility of recurrence in flight.

#### 4.3.3.8 Risk Assessment

##### 4.3.3.8.1 Red Flag PFRs 

All PFRs having a Failure Effect Rating of 2 or 3 coupled with a Failure
Cause/Corrective Action rating of 3 or 4 are defined as "Red Flag"
Problem Logs and PFRs.

Each Red Flag PFR must include a statement regarding the rationale for
accepting the residual risk.

All Red Flag PFRs shall be discussed at subsequent formal reviews.

  ------------------- -------------- ------------------ ---------------------
                      **Failure      **Failure          
                      Effect**       Cause/Corrective   
                                     Action**           

  Negligible          1              1                  Known cause/Certainty
                                                        in corrective action.

  Significant         2              2                  Unknown
                                                        cause/Certainty in
                                                        corrective action.

  Major               3              3                  Known
                                                        cause/Uncertainty in
                                                        corrective action.

                                     4                  Unknown
                                                        cause/Uncertainty in
                                                        corrective action.
  ------------------- -------------- ------------------ ---------------------

Table 1 P/FR ratings

##### 4.3.3.8.2 Preliminary Rating of PFRs

A preliminary rating in accordance with 4.3.3.7 above shall be assigned
within 10 working days from date of incident to determine if there are
potential Red Flag issues.

#### 4.3.3.9 Safety Rating and Assessment

Each PFR and AR shall be reviewed by the Reliability Engineer to
determine if there is any potential adverse effect on personnel safety
or hardware safety associated with the problem/failure. It is the
responsibility of each PFR/AR reviewer to determine that the assigned
safety ratings are appropriate.

All PFRs and ARs with a hardware or personnel safety issue shall have a
safety risk assessment made by the JPL Systems Safety office and shall
be signed by the JPL Systems Safety Engineer and the Contractor Safety
Engineer (if applicable).

#### 4.3.3.10 Spacecraft Significant Event File (SSEF) and Alert/Concern Assessment

Each PFR and ARs shall be reviewed to determine if it meets the criteria
for an SSEF issue as defined in D-1926 and or if it meets the criteria
for a JPL alert/concern issue (reference D-11119).

#### 4.3.3.11 Review, Approval, and Closure

##### 4.3.3.11.1 PFR Review, Approval and Closure

Each PFR and AR shall be subjected to a review, approval, and closure
process as follows:

The subsystem cognizant engineer and reliability engineer shall perform
a preliminary review of each PFR and AR. Each PFR and AR shall be
assessed and rated for safety concerns. Each PFR and AR shall be
assigned a cause code, and a cause/corrective action rating by the
Flight Systems Engineer.

PFRs and ARs ready for closure shall be sent to the appropriate
signatories prior to a Problem Review Board (PRB) meeting. The PRB
membership, as a minimum, shall consist of the following:

-   Subsystem CogEs

-   Subsystem PEMs

-   Reliability Engineer

-   Flight Systems Engineer

-   System Safety Engineer

-   Mission Assurance Manager

-   ATLO Test Conductor (at start of I & T)

-   Flight Systems Manager

-   Flight Instruments Development Manager (for science instruments)

Additionally for ARs:

-   Project Software Engineer

The PRB shall meet to review, approve and sign PFRs and ARs on a regular
basis. Closure of a PFR or AR requires that all appropriate signatures
are on the PFR or AR as follows (see figure1):

(1) Project Element Manager for all PFRs and ARs.

(2) Hardware and/or Software Reliability Engineer for all PFRs and ARs.

(3) System Engineer for PFRs and ARs which:

```{=html}
<!-- -->
```
(a) Result in an E/BCR to OP/SP hardware or software

(b) Result in a waiver to level 4 or higher functional requirements

(c) Have an unknown cause

(d) Have a cause/corrective action rating of 3 or 4

In addition, the cognizant engineer or reliability engineer can decide
that any other PFR or AR should be reviewed by the System Engineer.

(4) Safety Engineer will review all PFRs and ARs to assess for hardware
    or personnel safety issues.

(5) Mission Assurance Manager for all PFRs and ARs (Project S/W Engineer
    for ARs) with a rating \>1/1 or 1/2.

(6) OP/SP Project Manager, Flight System Manager and Flight Instruments
    Development Manager (science instruments) for Red Flag PFRs and ARs
    (Project S/W Engineer for ARs).

## 4.4 Contractor Problem/Failure Reporting Requirements

### 4.4.1 General

Each Contractor organization external to JPL that is providing OP/SP
hardware and/or software shall establish a system for controlling and
monitoring the status of problem/failure reports prepared under its
cognizance. The requirements for such a system shall be in accordance
with Section **4** herein. The use of a contractor's problem/failure
reporting form requires the approval of the JPL Reliability Engineer or
the OP/SP Mission Assurance Manager. Contractors shall pass these
requirements down to subcontractors/suppliers.

### 4.4.2 Liaison and Submittals to JPL

The initial submittal to JPL shall consist of JPL PFR Form 1846 or
equivalent as approved by JPL with at least Section I (Description)
completed, or a copy of the Contractor's report as released with initial
reporting data sections completed. The submittal shall be sent
electronically to the JPL UPRS or entered directly into the web-based
UPRS system within 2 working days of the incident. The UPRS will then
electronically inform the Contract Technical Manager and JPL Cognizant
Engineer that the report is in the JPL UPRS automated system. The
Monthly Technical Progress Reports shall include a summary of problem
logs and/or PFRs generated during the reporting period.

Interim submittals to JPL shall consist of updated releases of the
Contractor's report and copies of referenced supplemental data and
documents. Submittals shall be sent to the JPL UPRS.

The final submittal to JPL shall consist of the Contractor's signed PFR
with copies of referenced supplemental data/documents not previously
submitted. Submittals shall be sent to the JPL UPRS.

Prior to submittal of a Contractor signed PFR to JPL, the verification
analysis and corrective action must be reviewed and approved by both
contractor's Project Engineer and the Contractor's Product Assurance
Manager. Also, in the case of Red Flag PFRs, the Contractor's Project
Manager must review and approve the PFR. After the receipt of a
Contractor signed PFR at JPL, it shall be reviewed by the JPL cognizant
engineer and/or PEM. The PFR shall not be considered closed by the
contractor until it has been approved by the appropriate signatories at
JPL.

## 

#  **ELECTRONIC PARTS PROGRAM REQUIREMENTS**

## 5.1 Introduction

### 5.1.1 Purpose

This section defines OP/SP Electronic Parts Program requirements and
their applicability to organizations both within and external to JPL.

### 5.1.2 Applicability

The requirements specified herein are applicable to all OP/SP EM and FM
hardware. This includes all JPL, contractor, subcontractor and other
supporting organizations providing flight equipment. In cases of
conflict between this document and any applicable document, this
document shall take precedence.

### 5.1.3 Applicable Documents

The latest revision of the following documents applies to the extent
specified herein.

[JPL Documents]{.underline}

JPL D-1348, Rev. D Electrostatic Control for Assembly and test Area for
Flight Projects

> JPL D-8545 Rev. B JPL Derating Guidelines
>
> JPL D-16389 Guidelines for Insuring Known-Good-Die (KGD) in JPL Space
> Flight Hardware
>
> JPL D-18354 OP/SP Project Environmental Design Requirements
>
> JPL D-18357 OP/SP Project Radiation Control Plan

[NASA and Military Documents]{.underline}

> MIL-STD-883 Test Methods and Procedures for Microelectronics
>
> MIL-PRF-19500 General Specification for Semiconductor Devices
>
> MIL-PRF-38534 General Specification for Hybrid Microcircuits
>
> MIL-PRF-38535 General Specification for Manufacturing Integrated
> Circuits
>
> QML-38534 Qualified Manufacturers List of Custom Hybrid Microcircuits
>
> QML-38535 Qualified Manufacturers List of Microcircuits Manufactured
> to the Requirements of MIL-I-38535 (including Appendix A where
> applicable)
>
> QPL-19500 Qualified Products List of Products Qualified under
> PRF-19500, General Specification for Semiconductor Devices
>
> SSQ25000 Destructive Physical Analysis Testing Specification for the
> Space
>
> Station Program, Revision B
>
> SSQ25001 Upgrade Screening, Space Station Program

## 5.2 Requirements

### 5.2.1 Management Requirements

The OP/SP Parts Program Engineer (PPE) shall be responsible for the
overall implementation and enforcement of this portion of the Mission
Assurance Plan.

### 5.2.2 Reviews

The OP/SP Parts Program Manager shall report on contractors Electronic
Parts Program Plan (EPPP) compliance to this section of the Mission
Assurance Plan at the Preliminary Design Review (PDR) and at the
Critical Design Review (CDR) Management reviews of the Parts Program
shall be conducted by the procuring agency on a monthly basis until all
flight parts have been delivered. These reviews shall include selection
and procurement status, Alert resolution, waiver status, problem
description/solutions, qualification status and DPA results. Actions
items resulting from the reviews shall be documented and reported.
Designers shall submit the preliminary parts lists by their PDR to the
Parts Program Engineer for reliability and radiation assessments.

A review by the JPL Office 514 Component Specialists shall be performed
on a complete part list of all OP/SP electronic assemblies. The OP/SP
PPE shall evaluate the results of the review.

The PPE will provide monthly reports to the Mission Assurance Manager
and the Project. This information shall include selection and
procurement status, Alert resolution, waiver status, problem
description/solutions, evaluation/qualification status, DPA results and,
when JPL is the procuring agency, the Electronic Parts Quality Assurance
status. Action items shall be documented and reported, as appropriate.

## 5.3 Parts Selection

Only parts of acceptable quality, reliability, and radiation
characterization compliance, as demonstrated through evaluation and/or
verified performance, shall be selected for application in flight
equipment. Use of lower quality level parts shall not be allowed without
an approved waiver.

### 5.3.1 Parts Classification

#### 5.3.1.1 Standard Parts

The OP/SP electronic hardware for Engineering Model qualification units
shall use parts from the same manufacturer and process as the flight
parts as a minimum. Parts from the same wafer lot or inspection lot are
preferred.

The OP/SP electronic hardware for flight shall use packaged electronic
parts that conform to the following minimum reliability standards:

-   MIL-STD-975, Grade 1

-   Parts successfully meeting the Class K (or equivalent) requirements
    of MIL-PRF-38534, the appropriate detail specification and listed in
    QML-38534

-   Parts successfully meeting the Level V requirements of
    MIL-PRF-38535, the appropriate detail specification and listed in
    QML-38535 (including appendix A where applicable)

-   MIL-STD-883, Class S compliant (when QML listed parts are
    unavailable)

-   QPL-19500, JANS

-   Military Established Reliability (ER) passive devices, Failure Rate
    Level R or S

Science instruments shall use "Class S" parts where possible, however,
as a minimum shall conform to the "Class B" requirements of the
specifications listed below. The Class B requirements of the
specifications listed below shall be considered as standard parts for
Science Instruments.

-   MIL-STD-975, Grade 2

-   Parts successfully meeting the Class H (or equivalent) requirements
    of MIL-PRF-38534, the appropriate detail specification and listed in
    QML-38534

-   Parts successfully meeting the Level Q requirements of
    MIL-PRF-38535, the appropriate detail specification and listed in
    QML-38535 (including appendix A where applicable)

-   MIL-STD-883, Class B compliant (when QML listed parts are
    unavailable)

-   QPL-19500, JANTXV

```{=html}
<!-- -->
```
-   Military Established Reliability (ER) passive devices, Failure Rate
    Level R or S

#### 5.3.1.2 Nonstandard Parts

All parts not meeting the minimum reliability criteria of the standard
parts in 5.4.1.1 are defined as nonstandard parts. All nonstandard parts
shall be upgraded to Class S, Level V, Class B for Science Instruments
or equivalent level. A list of the nonstandard parts accompanied by
supporting documents (including reliability test data/analysis,
radiation test data/analysis, procurement and screening specifications)
shall be submitted to and approved by the JPL Parts Program Engineer
prior to use.

#### 5.3.1.3 Die

When, based on technology maturity, development cost and risk, the
Project decides to implement a Known Good Die program for hybrid
microcircuits and MCMs, a Known Good Die (KGD) program (JPL D-16389)
level-V shall be implemented for all die, with JPL approval.

#### 5.3.1.4 Noncompliant Parts

Whenever either a standard or nonstandard part fails to fully comply
with the standard or nonstandard parts requirements identified herein,
and it is decided that the parts will be used in flight equipment, a
waiver shall be initiated and submitted to the Mission Assurance Manager
for approval. The waiver shall be approved before the part may be kitted
for assembly.

### 5.3.2 Application Specific Integrated Circuit (ASIC) Requirements

Screening and qualification testing shall be in accordance with
MIL-PRF-38535, QML level-V (QML Level-Q for Science Instruments) or
equivalent.

#### 5.3.2.1 Digital ASIC Test Requirements

Digital logic circuitry in ASICs (including the microprocessor,
microcontroller and all custom designs) shall be tested to at least 98%
stuck-at fault coverage as is defined by MIL-STD-883, Method 5012.

Quiescent current (all vector IDDQ method) tests shall be based on a set
of vectors that will toggle 99.5% of the nodes.

Additional tests shall be conducted that include: 1) operating speed (or
maximum testable speed) functional test to verify all functions of the
design and 2) DC and AC parametric test vectors.

#### 5.3.2.2 Mixed-Signal ASIC Test Requirements

For mixed-signal ASIC's the digital portions shall be tested separately
from the analog portions; the digital parts will be tested as above. The
analog portions shall be SPICE modeled and tests performed to measure
the correspondence of the actual die to the SPICE models. The ASIC
designer and the die manufacturer will jointly specify these tests. Each
die must meet its analog performance specifications. As a minimum, these
tests shall be performed prior to incorporation into Slices or MCM's.
Parametric tests shall be performed over the full military temperature
range of --55°C to +125°C.

Digital logic circuitry in ASICs (including the microprocessor,
microcontroller and all custom designs) shall be tested to at least 98%
stuck-at fault coverage as is defined by MIL-STD-883, Method 5012.
Quiescent current (all vector IDDQ method) tests shall be based on a set
of vectors that will toggle 99.5% of the nodes. Additional tests shall
be conducted that include: 1) operating speed (or maximum testable
speed) functional test to verify all functions of the design and 2) DC
and AC parametric test vectors. As a minimum, these tests shall be
performed prior to incorporation into Slices or MCM's. Parametric tests
shall be performed over the full military temperature range of --55°C to
+125°C.

A minimum sample of 22 die from each ASIC wafer run shall be packaged,
tested and subjected to life test. Qualification testing shall be in
accordance with MIL-PRF-38535.

Read and record variables test data shall be taken at each test stage of
the Life tests; it is anticipated that this data will be used to verify
the Worst Case Analysis (WCA) and to characterize the parameter
variations. This characterization will be used to evaluate the SPICE
model vs. test data correspondence described above.

A product monitoring plan shall be implemented which includes a
provision for the procuring activity to monitor the ASIC vendor's
progress, problems, corrective actions, schedule impacts and
requirements for the following:

1.  Performance of design reviews, including PDR and CDR.

2.  Performance of 100% customer precap visual inspection.

3.  Demonstration that the selected vendor's ASIC parts can meet the
    Programs Radiation requirements set forth in this section.

### 5.3.3 MCM/Hybrid Requirements

Each custom hybrid microcircuit contractor shall include a plan for
meeting the following requirements.

A pre-award survey for the candidate manufacturer's facilities and
controls shall be conducted. The hybrid microcircuit processing and
controls shall be in accordance with the following.

1.  Element evaluation per paragraph 3.2 Method 5008 in MIL-STD-883.

2.  Process control per paragraph 3.3 of method 5008 in MIL-STD-883

3.  One-hundred percent (100%) customer pre-seal visual inspection per
    Method 2017 of MIL-STD-883.

4.  Delidding of packaged parts for rework or reseal shall not be
    permitted.

Following the award of a contract to a manufacturer for a hybrid
microcircuit procurement, a post-award hybrid design review shall be
convened by the CogE to demonstrate design adequacy. Also, a hybrid
manufacturing readiness review shall be conducted prior to initiating
assembly of the flight devices to verify all necessary procedures,
facilities and quality assurance controls are in place and ready to
support flight build.

### 

## 

### 

## 5.4 Radiation Requirements

All parts shall be selected to meet the highest radiation levels
available as indicated in the following paragraphs. All selected parts
shall meet the RDM requirements as specified in JPL D-18354 OP/SP
Environmental Design and Test Requirements. Compliance with the
following requirements will be verified by implementing the process
described in the OP/SP Project Radiation Control Plan (JPL D-18357).

### 5.4.1 Total Ionizing Dose (TID)

All Parts shall be selected to meet the highest TID levels available.
All parts shall be selected to meet a minimum TID level of 100k (Si) at
the die level. Parts not meeting this requirement shall not be used
without an approved waiver. RLAT shall be performed on all flight lots,
except GaAs transistors and MMIC devices, per (MIL-STD 883, M-5005,
Group E.)

The RLAT specifications shall be submitted with the procurement and
screening specifications to the JPL OP/SP Parts Program Engineer for
review and approval.

The external radiation environment is specified in the OP/SP Project
Environmental Requirements Document (JPL D-18354).

### 5.4.2 Dose Rate

> All linear bipolar, BiCMOS IC's, and embedded structures in ASICs
> (e.g., voltage references) shall be evaluated and reported to JPL for
> susceptibility to enhanced low dose rate (ELDR) effects to assure that
> parametric degradation due to ELDR have been accounted for in the ASIC
> or subsystem worst case analysis.

### 5.4.3 Displacement Damage

> All parts shall be evaluated and reported to JPL for displacement
> damage sensitivity to assure that parametric degradation due to
> displacement damage has been accounted for in the subsystem worst case
> analysis. Selected parts shall have a minimum susceptibility to
> displacement damage of 10^13^ n/cm^2^ equivalent 1 MeV neutron
> fluence. Potentially susceptible parts include but are not limited to
> optical devices, photodetectors, charge, coupled devices,
> optocouplers, LEDs, laser diodes bipolar power transistors and
> precision bipolar linear devices. Displacement damage (beyond that
> associated with total dose) may also be an issue with neutrons and
> heavy ions in optoelectronics and certain linear devices.

### 5.4.4 Single Event Latchup (SEL)

> All CMOS devices (including those with epitaxial layers) shall be
> subject to latchup evaluation. All parts shall exhibit no latchup with
> an LET of 75 MeV-cm^2^/mg.

### 5.4.5 Single Event Upset (SEU)

All microcircuits containing bistable elements (e.g. flip-flops,
counters, RAMs, microprocessors, etc.) shall be characterized so that an
upset rate or upset probability calculation can be performed. A
sufficient number of data points (a minimum of three) shall be taken to
determine the curve of device cross section versus LET (to saturation or
to an LET of 75 meV-cm^2^ /mg, whichever comes first).

The requirements for parts SEU acceptability are:

-   No upsets during SEU testing to LET of 75 MeV-cm^2^/mg,
    **[OR]{.underline}**

-   Verification of device bit error rate of 10^-10^ upsets per bit per
    day or less in the galactic cosmic ray environment (GCR),
    **[OR]{.underline}**

-   Calculation of a device's upset rate in the GCR, Solar Flare
    Protons, Jovian environment shall be equal to or less than the
    required circuit upset rate as determined by the Flight Systems
    Engineer.

### 5.4.6 Single Event Burnout (SEB)

> All power transistors operated in the off-mode may be susceptible to
> and shall be evaluated for single event burnout (SEB) at the lowest
> application V~BE~ or V~GS~ . The survival voltage (V~CE~ for bipolar
> and V~DS~ for MOSFETs) shall be established. The application voltage
> shall be derated to 75% of the established survival voltage.

### 5.4.7 Single Event Gate Rupture (SEGR)

> All power MOSFETs operated in the off-mode may be susceptible to, and
> shall be evaluated for single event gate rupture (SEGR) at the lowest
> application V~GS~. The established survival voltage (V~DS~) shall be
> established. The application voltage shall be derated to 75% of the
> established survival voltage.

## 5.5 Parts Acquisition

### 5.5.1 Use of Residual (Heritage) Parts Inventory

Residual inventory (i.e., heritage parts) refers to parts previously
approved and procured for prior flight Project applications. Residual
electronic parts may be used for OP/SP only if they meet all
requirements of this document.

### 

### 5.5.2 Parts Procurement

Semiconductors and IC's shall come from identifiable, non-mixed lots.

Purchase orders shall not take exception to reference specifications or
requirements therein unless approved by the OP/SP Parts Program Engineer
via waiver.

### 5.5.3 Backward Traceability

All parts shall be traceable by manufacturer\'s part number, serial
number, and lot date code. All ASICs shall have wafer traceability.

### 5.5.4 Parts Data Requirements

All test and evaluation data shall be submitted electronically. The
manufacturer's or vendor's certificate of conformance for each
electronic part lot shall be obtained and retained at JPLuntil the end
of mission. All parts, electrical test parametric data (variables data)
shall be read and recorded. The parametric data shall be traceable to
each serialized part. All variables and attributes data generated in
compliance with the specification shall be delivered to the
procuringagency. The data package shall be reviewed by the procuring
agency for completeness. The read and record data may be required for
standard parts when the project needs to establish worst case circuit
analysis acceptability. This should be included in the parts procurement
as requested by the project.

### 5.5.5 Customer Source inspection

Pre-seal visual inspection shall be performed on all packaged, flight
ASICs, hybrid microcircuits, MCMs, crystal oscillators and relays.

### 5.5.6 Post-Programming Burn-In for Programmable Devices

For \"one time\" programmable devices (i.e. PROMs and FPGAs) a post
programming 160-hour burn‑in at 125°C followed by DC parametric and
functional testing is required for all flight units.

### 5.5.7 Destructive Physical Analysis (DPA)

DPAs shall be performed on a sample of each manufacturing lot date code
for microcircuits, oscillators, resistor networks, crystals, filters,
ceramic capacitors (except MIL-C-123), relays, MIL-C-39010 inductors,
and all nonstandard packaged parts (including MCM's and hybrids).
MIL-C-39010 inductors/transformers shall be sectioned to examine the
adequacy of the termination.

DPAs shall be performed using only JPL-approved DPA specifications,
which may be modeled after SSQ25000. The results of the DPA shall be
evaluated by the procuring activity and the lot shall be accepted or
rejected based on the criteria of the specification.

## 5.6 Electronic Parts Application

## 

### 5.6.1 Parts Derating

Each part used in flight equipment shall be applied in a manner such
that the temperatures experienced and electrical stresses produced when
it is operating do not exceed the derating criteria defined in JPL
D-8545, Rev.B.

### 5.6.2 Electrostatic Discharge (ESD) Control Requirements for Static-Sensitive Parts

ESD damage or degradation may occur in static-sensitive electronic parts
during handling of the parts from procurement through incoming
inspection, testing, screening, storing and final assembly/test. To
protect static-sensitive parts from ESD, handling of parts shall be
controlled by the requirements of JPL D-1348.

### 5.6.3 NASA and Government Industry Data Exchange Program (GIDEP) Alerts

All hardware-delivering design agencies, both internal and external to
JPL, shall establish and implement a system to review GIDEP Alerts, take
appropriate action, and notify their respective GIDEP Alert coordinators
of significant parts problems that may warrant issuance of new Alerts.

Design agencies which do not presently receive Alerts directly should
request distribution from the Defense Supply Center Corporation (DSCC),
GIDEP Operations Center or the JPL Electronic Parts Engineering Office.
The design agency is responsible for reviewing all Alerts, and for
immediately reporting corrective action for applicable Alerts (i.e. for
parts used in the hardware) to the project.

The design agency shall present a report at the CDR, and another at the
Pre-Ship Review, that lists all of the Alerts which are pertinent to the
parts used in the flight design, the possible impact should the part
fail, and the actions proposed and those taken. It is the responsibility
of the design agency to avoid the use of defective parts in flight
equipment.

### 5.6.4 Parts Failure Analysis

Failure analysis is required for all part failures that occur subsequent
to screening. The only exceptions are parts damaged by human error
(e.g., improper installation). Analysis shall be carried to the point
that lot dependency of the failure mode can be determined. Failure
analysis reports shall be written to document the analysis approach, the
determined failure mode and mechanism (i.e., cause) responsible for the
failure, and the corrective actions required to prevent recurrence of
the failure. If a lot dependency is found, the MAM will disposition the
assemblies using the suspect lot.

### 5.6.5 As-Built Parts List

An As-Built Parts List shall be released prior to hardware integration
and test and shall be included in the end item data package (EIDP). In
addition to the information required in the Preliminary Parts Lists, the
As-Built Parts List shall include for each different part the**:**

-   Generic part number,

```{=html}
<!-- -->
```
-   Actual part marking,

```{=html}
<!-- -->
```
-   Manufacturer,

```{=html}
<!-- -->
```
-   Lot date code,

```{=html}
<!-- -->
```
-   Serial number (for serialized parts),

```{=html}
<!-- -->
```
-   Wafer and wafer lot numbers (when required),

```{=html}
<!-- -->
```
-   Parts test lot numbers (where applicable),

```{=html}
<!-- -->
```
-   Procurement specification number,

```{=html}
<!-- -->
```
-   Traceability number (when assigned by the cognizant parts
    organization), the serial number and part number of the next
    assembly level into which the part is installed (e.g., board or
    module),

```{=html}
<!-- -->
```
-   Reference designator of the location where each part is used on the
    next assembly level.

    The as-built parts list shall be supplied to the JPL Electronic
    Parts Engineering Section in a computer readable format.

## 5.7 System Contractors

All Cognizant Engineers who manage contractors and subcontractors shall
be responsible for ensuring that hardware delivered to JPL meet all the
requirements of this section unless a waiver in accordance with Section
1.11 of this document is first approved by the OP/SP Project Office.

Each organization responsible for implementing a parts program
(contractors and subcontractors) shall prepare an Electronic Parts
Program Plan (EPPP) responsive to the requirements of this Parts Program
Requirements section. The OP/SP Project Parts Program Engineer shall
review and approve each EPPP, which will include:

-   The flight equipment affected including identification of hardware
    designated as critical.

-   The organizational responsibilities, relationships, and key
    managerial, programmatic and technical roles planned for the
    implementation of the parts program.

-   The implementation plan for meeting the parts requirements of this
    document, including monitoring its contractors\' compliance with
    their respective EPPP.

-   The plan by which the contractors shall demonstrate and report
    monthly to JPL their compliance with this document.

The contractor shall describe in an EPPP how the technical requirements
in this section flow down to subcontractors, how subcontractors\'
implementation of the requirements shall be reviewed and monitored, and
how part selection and procurement status, Alert resolution, nonstandard
parts review status, waiver status, problems, problem solutions, and
schedules of the contractor and subcontractors shall be reported to JPL.
The contractor shall submit to JPL, for review and approval, a list of
all the contractor\'s and subcontractors\' nonstandard parts including
part specifications (viz., procurement, screening, lot demonstration,
additional testing, upgrade, and DPA), and radiation lot acceptance test
plans. The EPPP shall also specify the procedures for maintaining lot
traceability and integrity of surplus parts that will be returned to JPL
at the conclusion of the contract as well as the procedures for
returning surplus parts to JPL Flight Stores.

The contractor shall implement and maintain a system of monthly
reporting to the Project Office, in a manner and format such as to
provide JPL the visibility and status of the contractors and all
subcontractors\' parts programs.

All contractors (system/instrument contractors and subcontractors) shall
be responsible for the performance of failure analysis on parts that the
contractor procures or builds, in accordance with failure analysis
requirements delineated in Section 5.7.4 of thissection. Failure
analysis results shall be made available to JPL as the contractor
determines them (typically through the Monthly Management Review).
Failure analysis reports shall be delivered to JPL within two months
after the discovery of the cause of failure and in no case more than six
months after the part failure is discovered. All failure analysis
reports shall be completed and submitted prior to hardware delivery.

##  Acronym List

The following is a list of the acronyms and their meanings used in this
document:

[Acronym]{.underline} [Meaning]{.underline}

AAMS Automated Anomaly Management System

AIDS Assembly and Inspection Data Sheets

API Application Program Interface

ATLO Assembly, Test, and Launch Operations

AR Anomaly Report

ASIC Application Specific Integrated Circuit

CDR Critical Design Review

CE Configuration Engineer

CM Configuration Management

CMOS Complementary Metal Oxide Semiconductor

CogE Cognizant Engineer

DBAT Design, Build, Assembly, and Test

DI Dielectrically Isolated

DMIE Define and Maintain the Institutional Environment

DPA Destructive Physical Analysis

DSCC Defense Supply Center Corporation

E/BCR Engineering/Budget Change Request

EIDP End Item Data Package

EM Engineering Model

EPPP Electronic Parts Program Plan

EPPR Electronic Parts Program Requirements

ESD Electrostatic Discharge

FIDM Flight Instruments Development Manager

FM Flight Model

FMECA Failure Modes, Effect, and Criticality Analysis

FSM Flight System Manager

GIDEP Government Industry Data Exchange Program

GSE Ground Support Equipment

HRCR Hardware Review and Certification Record

ICD Interface Control Drawing

IR Inspection Report

ISO International Standards Organization

I & T Integration and Test

JPL Jet Propulsion Laboratory

KGD Known Good Die

LET Linear Energy Transfer

MAM Mission Assurance Manager

MCM Multi-Chip Module

MDS Mission Data System

MeV Million Electron Volts

MOSFET Metal Oxide Semiconductor Field Effect Transistor

MRB Materials Review Board

NASA National Aeronautics and Space Administration

NPG NASA Program Guideline

OP/SP Outer Planets/Solar Probe

PDR Preliminary Design Review

PDS Project Data System

PEM Project Element Manager

PF Proto-Flight

PFR Problem Failure Report

PHA Preliminary Hazard Analysis

PPE Parts Program Engineer

PRB Problem Review Board

PROM Programmable Read Only Memory

PSA Parts Stress Analysis

QA Quality Assurance

QADC Quality Assurance Documentation Center

QAR Quality Assurance Representative

QCI Quality Conformance Inspection

QML Qualified Manufacturers List

QPL Qualified Parts List

RAM Random Access Memory

RCP Radiation Control Plan

RGA Residual Gas Analysis

RLAT Radiation Lot Acceptance Test

SAR Software Assurance Representative

SCM Software Configuration Management

SEB Single Event Burnout

SEE Single Event Effect

SEGR Single Event Gate Rupture

SEL Single Event Latchup

SEU Single Event Upset

SFP Single Failure Point

SMAD Safety and Mission Assurance Directorate

SMP Software Management Plan

SOI Silicon On Insulator Semiconductor

SOS Silicon On Sapphire Semiconductor

SOW Statement of Work

SRCR Software Review and Certification Requirement

SRL Significant Risk List

TBD To Be Determined

TID Total Ionizing Dose

TMOD Telecommunications and Mission Operations Directorate

UPRS Unified Problem Reporting System

WCA Worst Case Analysis

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

#