SPACE ASSURANCE REQUIREMENTS AND GUIDELINES (SARG)

##### GRC-M0510.002

Revision A

Glenn Research Center

Risk Management Office

Director's Message

This Space Assurance Requirements and Guidelines manual is for Programs
and Projects. The manual applies NASA Policy for Safety and Mission
Assurance NPD 7120.5 for use at Glenn. A Product Assurance Plan prepared
by each Program or Project shall invoke these instructions.

The Office of Safety and Assurance Technologies uses this manual to
point to Safety and Mission Assurance instructions that are controlled.
These instructions apply to the design, development, fabrication,
assembly, test, and operation of space flight systems and related
support equipment. All personnel are to meet these instructions.

This manual consists of ten sections. These sections cover overall
requirements, assurance review, verification, system safety, EEE and
mechanical parts control, materials and processes, reliability and
maintainability, quality assurance, continuous risk management, and
software assurance. They give specific instructions that are to be used
to accomplish these tasks. The Office of Safety and Assurance
Technologies is available to consult with the Programs and Projects when
they perform their independent assessment and verification tasks.

Compliance with these instructions is essential to ensure successful
accomplishment of our commitment to continuous improvement and
innovation to ensure quality products, excellent service, and satisfied
customers in an efficient, timely, and cost effective manner. Each
member of the staff shares the responsibility to work as a team member
to achieve this goal.

Donald J. Campbell

[]{#Director_Draft .anchor}Office Notice

0500 March 22, 2001

To: Distribution

From: 0500/ Office of Safety and Assurance Technologies

Subject: NASA Glenn Space Assurance Requirements

The Glenn Space Assurance Requirements and Guidelines manual (SARG) is
under the change control of this Office. It is available at BMS Library
under Center Manuals.

The SARG represents considerable effort on the part of all the Glenn
Space Organizations. It has been revised to meet the ISO Business
Management System (BMS). The SARG is a living document that can be
changed to meet the needs of the Programs and Projects. All changes are
made using the Document Control and Change Procedure LeR-P3.7.2.1.

Thanks to everyone that assisted in the preparation of the BMS for
Glenn.

Vernon W. Wessel

Office Director

TABLE OF CONTENTS

***[Director's Message](#Director_Draft)***

***[Office Notice](#Director_Draft)***

***[INTRODUCTION](#INTRODUCTION)***

#  Background 

Purpose

Scope

# 

# [GUIDE TO THE USE OF THE SARG DOCUMENT](#GUIDE_TO_THE_USE_OF_THE_SARG_DOCUMENT) 

#### 

#### TABLE OF CONTENTS

**[SECTION M:]{.underline}** *MATRICES OF ASSURANCE REQUIREMENTS AND
GUIDELINES FOR THE VARIOUS CARRIERS*

# [**SECTION I:** *OVERALL REQUIREMENTS*](#SECTION_1) 

1.  **Description Of Overall Requirements**

2.  **Product Assurance Plan**

3.  **Use Of Previously Designed, Fabricated, Or Flown
    Hardware...............................................**

4.  **Assurance Status Reports**

5.  **Contractor Surveillance**

# 

# [**SECTION 2:** *ASSURANCE REVIEW REQUIREMENTS*](#SECTION_2) 

**2.1 General Requirements**

**2.2 GRC Assurance Review Requirements**

3.  **GRC Assurance Review Program**

> 2.3.1 Preliminary Design Review

2.3.2 Critical Design Review

2.3.3 Verification Review

2.3.4 Pre-ship Review

2.3.5 Additional Review
Requirements.................................................................................

**2.4 System Safety**

[**SECTION 3:** *VERIFICATION REQUIREMENTS*](#SECTION_3)

**3.1** **General Requirements**

**3.2 Overall Verification Program**

**3.3 Electrical Function Test Requirements**

3.4 **Structural And Mechanical Requirements**

3.4.1 Safety Critical Structures and Flight Safety

3.4.2 Structural Loads

3.4.2.1 Pressure Systems

3.4.2.1.1 Design Verification

3.4.3 Vibration -Acoustics

3.4.3.1 Flight Acceptance

3.4.4 Mechanical Shock

3.4.4.1 Design Qualification

3.4.4.2 Flight Acceptance

3.4.5 Mechanical Function

3.4.5.1 Flight Acceptance

3.4.5.2 Life Testing

3.4.6 Pressure Profile

3.4.6.1 Flight Acceptance

3.4.7 Mass Properties

**3.5 Electromagnetic Compatibility (EMC) Requirements**

3.5.1 EMC Guidance

**3.6 Vacuum, Thermal, And Humidity Requirements**

3.6.1 Compliance with Requirements

3.6.2 Testing Levels

3.6.3 Description of Applicable Testing

3.6.3.1 Thermal Cycling

3.6.3.1.1 Ambient Pressure Thermal Cycle

3.6.3.1.2 Thermal Vacuum

3.6.3.2 Burn-in-Test

3.6.3.3 High Temperature Dwell Tests.

3.6.4 Description of Applicable Analysis

3.6.5 References

3.7 Mission Simulation And Compatibility Tests Requirements

3.7.1 Mission Simulation

2.  Compatibility Test

[**SECTION 4*: ****SYSTEM SAFETY*](#section_4)

4.1 **System Safety Requirements**

4.1.1 General System Safety Requirements

4.1.2 Space Transportation System Safety Requirements

4.1.3 Space Station System Safety Requirements

4.1.4 Sounding Rockets Safety Requirements

5.  Project Safety Plan

6.  Safety Compliance Documentation

7.  Aeronautics System Safety Requirements

4.2 **System Safety Guidelines**

4.2.1 System Safety Guidelines for Projects in Phase A

4.2.2 System Safety Guidelines for Projects in Phase B

4.2.3 System Safety Guidelines for Projects in Phase C

4.2.4 System Safety Guidelines for Projects in Phase D

[**SECTION 5**: *EEE and MECHANICAL PARTS CONTROL*](#SECTION_5)

5.1 **General Requirements**

5.2 **Parts Selection And Screening**

5.2.1 Parts Grades

5.2.2 Flight Parts Screening

5.2.3 De-rating

5.2.4 Radiation Hardness

5.2.4.1 Total Dose

5.2.4.2 Single Event Effects

5.2.5 Electric Motors

5.3 **Parts Storage Control**

5.4 **Parts Age Control**

5.5 **Parts Identification List**

[**SECTION 6:** *MATERIALS AND PROCESSES REQUIREMENTS*](#SECTION_6)

6.1 GENERAL REQUIREMENTS

6.1.1 Specific Requirements

6.2 Reference Documents

6.3 Materials Assessment Program

6.3.1 Corrosion

6.3.2 Stress Corrosion

6.3.3 Outgassing

6.3.4 Flammability

6.3.5 Fluid Compatibility

6.3.6 Materials Offgassing in Habitable Areas

7.  Other Materials Assessments

[**SECTION 7:** *RELIABILITY AND
MAINTAINABILITY*](#section-7-reliability-and-maintainability-requirements-and-guidelines)

7.1 GENERAL REQUIREMENTS

2.  AppLICABLE DOCUMENTS

3.  RELIABILITY, MAINTAINABILITY AND AVAILABILITY

7.3.1 Analysis Documentation

7.3.2 Failure Modes and Effects Analysis and Critical Items List

7.3.3 Fault Tree Analysis

7.3.4 Parts Stress Analyses

7.3.5 Worst Case Analyses

6.  Reliability Prediction Analysis

7.  Maintainability Assessment

8.  Availability Analysis

7.3 ANALYSIS OF TEST DATA

7.3.1 Trend Analyses

7.3.1.1 Performance Trending

7.3.1.2 PRACA Trending

7.3.2 Trending Activities

7.4 LIMITED-LIFE ITEMS

7.5 OFF-THE-SHELF COMPONENTS

7.6 THERMOGRAPHIC MAPPING

7.7 MAINTENANCE

7.8 PREVENTIVE MAINTENANCE ANALYSIS

7.9 SPARES REQUIREMENT ANALYSIS.

[**SECTION 8:** *QUALITY ASSURANCE REQUIREMENTS*](#SECTION_8)

1.  GENERAL REQUIREMENTS

> 8.1.1 Applicable Documents

8.2 ORGANIZATION

3.  CONFIGURATION MANAGEMENT AND VERIFICATION

4.  IDENTIFICATION AND TRACEABILITY

8.5 PROCUREMENT REQUIREMENTS

8.5.1 Government Source Inspection

8.6 RECEIVING INSPECTION

8.7 CONTROL OF FABRICATION ACTIVITIES

8.7.1 Fabrication and Inspection Requirements

8.7.2 Training and Certification for Personnel

8.7.3 Evaluation and Control of Process Specifications and Procedures

8.7.4 Bonded Storage

8.8 CONTAMINATION CONTROL

8.8.1 General Requirements

8.8.2 Contamination Control Plan

8.9 ELECTROSTATIC DISCHARGE CONTROL

10. PROBLEM REPORTING AND CONTROL

8.10.1 Review Boards

8.11 ALERT INFORMATION

8.12 CONTROL OF ASSEMBLY AND INSPECTION/TEST ACTIVITIES

8.12.1 Assembly, Inspection and Test (AIT) Procedures

8.12.2 Inspection and Tests of Stored Limited Life Hardware

8.12.3 Records of Inspection and Tests

13. CONFIGURATION VERIFICATION

14. HANDLING, PRESERVATION, MARKING, PACKAGING, PACKING, AND
    TRANSPORTATION

15. CONTROL OF GOVERNMENT PROPERTY

16. GOVERNMENT OR PRESHIP ACCEPTANCE

8.17 AUDITS AND
REPORTS...................................................................................................

[**Session 9**: *CONTINOUS RISK MANAGEMENT*](#SECTION_9)

1.  Overview

2.  Reference

3.  Purpose

4.  Implementation

9.4.1 Identify Risks

> 9.4.1.1 Risk Statements

9.4.1.2 Contexts

9.4.2 Analyze Risks

> 9.4.2.1 Evaluate
>
> 9.4.2.2 Classify
>
> 9.4.2.3 Prioritize

9.4.3 Planning

> 9.4.3.1 Research
>
> 9.4.3.2 Accept

9.4.3.3 Watch

9.4.3.4 Action Plan

9.4.4 Tracking

9.4.5 Control

9.4.6 Communication and Documentation

[**Session 10:** *SOFTWARE ASSURANCE*](#SECTION_10)

10.1 GENERAL REQUIREMENTS

10.1.1 Roles and Responsibilities

10.1.2 Scope of Software Assurance Program

10.1.3 Software Assurance Plan

10.1.4 Software Development Requirements

10.1.4.1 Software Development Life Cycle

10.1.4.2 Software Development Life Cycle Summary

10.1.5 Applicable Development Standards

10.1.6 Project Documentation

10.1.7 Government, Subcontractor and Purchased Software

10.1.8 Firmware Assurance

10.2 SOFTWARE SAFETY

10.3 SOFTWARE RELIABILITY

10.4 SOFTWARE QUALITY ASSURANCE

10.5 SOFTWARE CONFIGURATION MANAGEMENT

10.6 SOFTWARE PRACA

10.7 PERFORMANCE VERIFICATION AND VALIDATION

10.7.1 Software Review

10.7.2 Inspections

10.7.3 Software Testing

10.7.3.1 Software Test Plan

10.7.3.2 Software Test Procedures

10.7.3.3 Software Test Reports

10.7.4 Software Audits

10.7.5 Software Records

10.7.5.1 References

10.7.6 Software Acceptance

## **APPENDICES**

[A -- APPLICABLE/REFERENCE DOCUMENTS](#Appendix_A)

[B --ABBREVIATIONS, ACRONYMS, AND GLOSSARY](#Appendix_B)

[C -- PROJECT SCHEDULE](#Appendix_c)

[]{#INTRODUCTION .anchor}**INTRODUCTION**

BACKGROUND

The Standard Assurance Guidelines for Experiments (SAGE) was base-lined
at Glenn Research Center (GRC) on January 6, 1993. SAGE was created to
provide safety, reliability and quality assurance (SR&QA) guidelines for
Glenn space-flight experiments and was tailored for Glenn applications
primarily from two Goddard Space Flight Center documents: Standard
Payload Assurance Requirements and General Environmental Verification
Specification.

While the SAGE served as a useful guide, Glenn decided that a minimum
set of SR&QA guidelines were required for space experiments. Hence, the
Standard Assurance Requirements and Guidelines for Experiments (SARGE)
document was created in 1996 to explicitly define which SR&QA guidelines
should be treated as requirements for different types of micro-gravity
missions.

In March 2001, Glenn renamed this document Space Assurance Requirements
and Guidelines (SARG). The document was revised to reflect the increased
Safety and Mission Assurance (SMA) role in space Programs and Projects
to meet the ISO 9001 Certification Requirements. In addition, the
document was updated to reflect the new NASA Headquarters Policy for
Program and Project Management Process and Requirements, NPG 7120.5,
including the new assurance requirements for continuous risk management.
Finally, the document was updated to include assurance requirements
applicable to payloads on the International Space Station.

PURPOSE

The SARG document was developed to promote the safety and success of
space flight Programs and Projects managed by Glenn Research Center.
SARG defines overall requirements, assurance review, verification,
system safety, EEE and mechanical parts, materials and processes,
reliability and maintainability, quality assurance, continuous risk
management and software assurance requirements that shall be followed.

SCOPE

This document identifies the safety and assurance requirements and
recommended guidelines for space flight Programs and Projects. The SARG
applies to in-house and contractor managed Programs and Projects. The
NASA Project Manager shall determine which sections will be followed and
documented in the Project Plan and the Product Assurance Plan. GRC
management approval is required for each Project Plan or Product
Assurance Plan.

During RDR and subsequent reviews, Programs and Projects shall show how
they are complying with SARG requirements. For any requirement not
satisfied, they should obtain management approval and document
non-compliances.

[]{#GUIDE_TO_THE_USE_OF_THE_SARG_DOCUMENT .anchor}GUIDE TO THE USE OF
THE SARG DOCUMENT

The SARG includes all necessary SMA requirements and guidelines. The
SARG is organized with sections that can be used as requirements
depending on the needs of the Programs and Projects. The Section M
Matrices in the front of the document describe the recommended
requirements and guidelines for the various carriers. Sections 1 to 10
in the document describe the assurance tasks that shall be done. The
Office of Safety and Assurance Technologies serves as a consultant to
perform the verification and assessment tasks.

[]{#SECTION_1 .anchor}SECTION 1 - OVERALL REQUIREMENTS

1.1 DESCRIPTION OF OVERALL REQUIREMENTS

The GRC Project Manager (PM) has primary responsibility for ensuring
assurance requirements are satisfactorily accomplished. However, the
Program Assurance Manager (PAM) shall assist the PM in this effort and
have direct access to developer management. The Safety and Mission
Assurance (SMA) program shall operate concurrently with all other
elements.

The developer is required to plan, implement and organize a SMA Program
that encompasses all flight hardware, software, government furnished
equipment, and support equipment from initiation through development and
subsequent missions or tests (see Section 1.3). The SMA Program shall be
in place until the Program or Project is completed and the associated
hardware and software is retired.

The SMA Program applies to all work accomplished by the developer,
subcontractors and suppliers. The development may be in-house or by an
outside contractor.

1.2 PRODUCT ASSURANCE PLAN

The SMA Program shall be implemented with an approved Product Assurance
Plan (PAP), which addresses all sections of the SARG. The PAP shall
document how the program/project is going to meet the requirements of
the SARG. The PAP shall also include: SARG reference paragraphs,
deliverables, and performing organizations. Any non-compliance to the
requirements or guidelines in the SARG shall be identified and justified
in the PAP. The PAP shall be reviewed and approved by the PM and PAM.
Any proposed changes to the approved PAP shall be submitted to the PM
and PAM for approval prior to implementation Developers are encouraged
to make maximum use of their own existing procedures and any existing
GRC work instructions and procedures (to include the Product Assurance
Instructions (PAIs) in the BMS) in complying with the SARG. All
developer procedures referenced in an approved PAP shall also be
available for information at the developer's facility.

For an outside contract, the PAP shall be delivered by the effective
date of the contract in accordance with the contract schedule. The
contractor's practices and procedures referenced in the PAP shall also
be delivered at the effective date of contract in accordance with the
contract schedule. If any inconsistencies between the approved PAP and
this document become evident during the contract period of performance,
this document shall take precedence, except when specific
non-compliances have been approved by the PM and PAM. Any new procedure
or any proposed changes to the approved procedures shall be submitted to
the PM and PAM for review and/or approval in accordance with the
contract.

1.3 USE OF PREVIOUSLY DESIGNED, FABRICATED OR FLOWN SYSTEMS

When a system that was designed, fabricated or flown previously is to be
used, the developer is required to demonstrate how the system complies
with the SMA requirements and guidelines in this document. Furthermore,
to avoid repeating certain tasks which previously demonstrated the
system complied with requirements, the developer shall have evidence
from the previous Program or Project that shows how flight worthiness
and the integrity of the system were maintained.

1.4 ASSURANCE STATUS REPORTS

The developer shall submit SMA Status Reports on a quarterly basis to
the PM and PAM. The reports shall cover items such as those listed below
as well as those discussed in the individual sections of this document:

1\. Key SMA organization and personnel changes

2\. Significant SMA risks

3\. Safety Issues

4\. Status of SMA activities in manufacturing, testing, and operations

5\. Supplier and subcontract SMA activities

6\. Audit, non-conformance, and problem reports

7\. Review status

8\. Parts list, parts problems, and ALERT findings

9\. SMA trend analyses

1.5 CONTRACTOR SURVEILLANCE

NASA GRC shall use a surveillance approach to evaluate the contractor
and determine if contract performance is acceptable. The government's
objective is to balance the level of surveillance with the perceived
impacts and risks of meeting program/project goals. The GRC
Program/Project shall identify program requirements, strategy,
resources, review and control processes, surveillance activities, and
metrics for continuous measurement of the contractor's performance.

The work activities, operations, and documentation performed on the
program/project by a contractor, subcontractor or supplier are subject
to evaluation, review, audit and/or inspection by the government or its
designated representatives as specified in the contract. When necessary,
GRC will delegate responsibilities and authority to other government
agencies in a letter of delegation or with an independent assurance
contractor with a GRC contract, as appropriate.

The contractor, upon request, shall provide government representatives
with SMA documents, records, and equipment required to perform these
activities. The contractor shall also provide the government
representatives with an acceptable work area within its facilities when
requested.

[]{#SECTION_2 .anchor}

SECTION 2 - ASSURANCE REVIEW REQUIREMENTS

2.1 GENERAL REQUIREMENTS

The developer shall support a series of formal or informal comprehensive
system and subsystem level design reviews. The reviews cover all aspects
of project hardware, software and operations for which the developer has
responsibility.

2.2 GRC ASSURANCE REVIEW REQUIREMENTS

For each specified system level review conducted by an Assurance Review
Team, the developer shall:

2.2.1 Develop and organize material for oral presentation to the
Assurance Review Team. Copies of visual aids and other supporting
material that is pertinent to the review shall be submitted to the
Project Manager for information in accordance with the Project Schedule
(Appendix C).

2.2.2 Participate in splinter review meetings as needed.

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

2.3 GRC ASSURANCE REVIEW PROGRAM

The Assurance Review Program consists of individual, periodic reviews of
the project as defined below. The reviews shall include information on
project objectives and design in sufficient detail to facilitate
understanding of the internal and external interfaces of the project's
hardware and software.

The peer reviews shall be conducted by a team of experts not working on
the project being reviewed. GRC reserves the right to attend assurance
reviews conducted by GRC developers and all review documentation shall
be available to the review team 10 working days prior to the review.

The results of the reviews shall be documented, and the documents shall
be retained as quality records and made available to the government upon
request.

2.3.1 Preliminary Design Review (PDR) - The Preliminary Design Review is
a project implementation review conducted after the completion of the
preliminary design synthesis and before the detailed design process.
This review is conducted approximately when the project plan is signed
with a mature budget and schedule or project implementation phase per
NPG 7120.5A. The overall purpose of the review is to confirm the
requirements, evaluate the technical progress and adequacy, evaluate the
system design compliance to requirements, and to review the results of
breadboard testing and design analyses. The PDR shall evaluate the
ability of the system, subsystem and components to successfully perform
their function under operating and environmental conditions, during
qualification and acceptance testing, and the project's planned
activities. The results of parts de-rating analyses and component
packaging review, including the results of associated tests, shall be
discussed at the PDR.

2.3.2 Critical Design Review (CDR) - The Critical Design Review is
conducted after the design has reached the degree of completion needed
to permit a comprehensive and detailed examination, verification and
data analysis. This review shall be conducted after the review of
engineering model system testing and prior to release of drawings for
fabrication of the end item hardware. The goal is to have 90 percent of
the flight or end item hardware drawings finished at the time of t he
CDR. Typically, a CDR is performed along with a Verification Readiness
Review (VRR). Successful completion of the CDR and close-out of all
Review Actions provides the technical definition for the end item
baseline. The overall purpose of the CDR is to verify compliance of the
detailed design to the design requirements and the acceptability of the
engineering test results and design analyses. The CDR shall evaluate the
ability of the system, subsystem and components to successfully perform
their function under operating and environmental conditions, during
qualification and acceptance testing, and the project's planned
activities. The results of parts de-rating analyses and component
packaging review, including the results of associated tests, shall be
discussed at the CDR.

2.3.3 Verification Readiness Review (VRR) -- The purpose of a
Verification Readiness Review (VRR) is to have the Project Team present
the verification methods it will use to show compliance with the
science/technical and engineering requirements. It is often performed at
the same time as the CDR. The verification methods defined at this
review will then be the accepted method used at the Pre-Ship Review to
verify that requirements are met. The functional and environmental t est
plans, ground operations and verification matrix for science/technical
and engineering requirements, as well as a review of system interfaces
are reviewed in this process. 2.3.4 Pre-ship Review (PSR) - Held prior
to the shipment of flight or other project equipment to the launch site
or other project activities destination, this review concentrates on
system performance during flight or other project acceptance testing,
significant non-conformances, open risks, and functional failures for
corrective action, and closeout of open items.

2.3.5 Additional Review Requirements

For flight projects, packaging reviews shall be conducted on all
electrical and electromechanical components in the flight system.

The packaging review shall specifically address the following:

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

b.  Structural support and thermal accommodation of the boards,
    substrates, and hybrids and their interconnection in the system
    design.

c.  Provision for parts protection and inspection.

2.4 SYSTEM SAFETY

The approach used to comply with the system safety requirements will be
an agenda item at each of the reviews listed in paragraph 2.3 and, as
such, the GRC assurance reviews will complement the system safety
reviews of Section 4

[]{#SECTION_3 .anchor}SECTION 3 - VERIFICATION

3.1 GENERAL REQUIREMENTS

The developer must conduct a verification program to ensure that the
science and project verification requirements for the activity are
satisfied. Science requirements are defined in the Science Requirements
Document (SRD), and are not described further in the SARG. Project
requirements that should be verified are defined in this Section, and
throughout the rest of the SARG Sections. The overall verification
program aP/Proach for project requirements are described generally in
this section.

The project requirements that is described in this section address
integration and functional testing in the following areas: electrical,
structural, EMI, thermal and end-to-end. The project will determine
which integration requirements documents need to be followed. These
documents provide the basis for the integration testing that is required
in these areas. The functional testing requirements are based on GRC
experience and practices developed over the years on a variety of
programs.

Payload integration with the experiment carrier (i.e. GAS-can,
hitchhiker) as described in this section is worked directly with the
integration centers as shown in the figure. Integration of the
payload/carrier with the shuttle or other launch vehicle is the
responsibility of the integration center with suP/Port from the payload
developer.

3.2 OVERALL VERIFICATION PROGRAM

A verification program begins with the development of a Verification
Plan that: identifies the project verification requirements; defines the
method(s) of verification; defines the associated verification matrix;
describes the SARG compliance matrix. It concludes when the required
verifications are completed as outlined in the Plan.

The methods of verification include analytical investigations, physical
property measurements, inspections, and tests that include simulating
the environments to be encountered. These environments may include:
handling and transportation, pre-launch, launch, on-orbit, and where
aP/Propriate, retrieval, reentry and landing. These methods are
described throughout the various SARG sections, and need to be reviewed
and identified accordingly.

The Verification Plan should be initiated at Requirements Design Review
(RDR) and updated as necessary through final aP/Proval by the board at
Preliminary Design Review (PDR). The implementation can be at the
component, subsystem or system levels of assembly as required by the
Plan. The Plan shall include a flight or other project simulation
end-to-end test of the entire system that includes a mission simulation
for the mission timeline.

In the RDR timeframe, a coordination meeting shall be held that includes
GRC payload integration testing experts in the following test areas:
electrical, structural, EMI, thermal, and end-to-end. The purpose of the
meeting shall be to identify the experiment unique characteristics that
will drive the design in these areas, and make the Project Team and the
Project Manager aware of the risks so that mitigation can be tracked in
a timely and effective manner.

All flight operations or other project activities shall undergo
acceptance testing in accordance with the flight, re-flight or other
project verification plan. All prototype or proto-flight systems shall
undergo qualification to demonstrate compliance with the requirements of
the Plan. Additional requirements and guidance for test specifications
and reporting is in the Quality Assurance Section.

The Verification Matrix shall contain the following information:

-   Requirements Document - identify the source document from which the
    verification element was obtained.

-   Paragraph Reference - identify the paragraph from the source
    document.

-   Requirement Title - specify the specific requirement in a brief
    descriptive form.

-   Methods of Verification - identify methods of verification.

-   Verification/Validation AP/Proach Summary - to verify the integrity,
    space worthiness and capability of the flight or other project
    system to fulfill the performance requirement.

-   Closure Requirement - specify how closure will be accomplished and
    documented.

-   Safety Closure Reference - identify any safety closure
    documentation.

In addition, the Matrix shall include the science requirements traceable
to the SRD (or SRED) and the methods of verification.

The Verification Matrix must be updated throughout the project to
reflect the latest documentation, and status changes.

3.3 ELECTRICAL FUNCTION TEST REQUIREMENTS

Before the integration of an assembly, component or subsystem into the
next higher-level system assembly, electrical interface tests shall be
performed to verify that all software and signals are within acceptable
limits of aP/Plicable performance specifications.

Prior to being mated with other components, all-electrical harnessing
used to mate assemblies shall be inspected and have continuity and IR
tests accomplished in accordance with NASA-STD-8739.4, paragraph 18.2.
All cables shall be made from spools of wire which have been sample
tested to NASA-STD-8739.4, paragraph 18.2.

3.4 STRUCTURAL AND MECHANICAL REQUIREMENTS

The Project shall demonstrate compliance with the structural and
mechanical requirements as defined in the verification matrix by
inspection, demonstration, similarity, analyses, or tests. Keep in mind
that the Flight Experiment may have structural and mechanical
requirements in addition to the carrier requirements.

The payload developer is charged with establishing a verification plan
to satisfy both safety and mission success criteria. The verification
plan or program should include structural analysis, testing and
structural assessment to verify the structural integrity of all payload
flight or other aP/Plicable project equipment for all ground and flight
environments. These environments may include structural loads,
vibration-acoustics, mechanical shock and pressure profiles. Mass
properties and mechanical functions shall also be verified.

3.3.1 Safety Critical Structures and Flight Safety

The structural integrity of the Space Transportation System (STS) or
International Space Station (ISS) payloads is a critical flight safety
concern. All structural elements in the primary load path, pressure
systems, uncontained glass, rotating or articulating machinery and
containment devices are safety critical. Safety critical structures will
usually include components whose failure present catastrophic hazards to
the STS or ISS crew. These Fracture Critical components must be shown by
test or analysis to be safe from failure throughout the mission.

For other than STS launched payloads, the project should obtain users
handbook to obtain the current environment that the payload will be used
in and experience during launch. The GSFC GEVS-SE document provides some
of this information for some launch vehicles in its aP/Pendix.

3.4.2 Structural Loads

Qualification of the payload for the structural loads environment
requires a combination of test and analysis. A finite element model of
the payload may be developed and verified by modal testing. A coupled
loads analysis of the launch vehicle also must be performed utilizing
the test verified model. For small payloads the coupled load analyses is
done by the Mission Integrator. The maximum loads resulting from the
analysis define the limit loads for each critical loading condition and
configuration including handling and transportation, vibration-acoustic
effects during lift-off, engine start-up and shutdown, landing, thermal
effects, and pyrotechnic shocks. To determine the combined loads for any
loading phase, the root-sum-square (RSS) of the low and high frequency
dynamic components are Superimposed upon the steady-state component.

Qualification for the structural loads environment shall be accomplished
by a combination of test and analysis. A modal survey should be
performed on each subsystem to verify that the analytic model adequately
represents the system's dynamic characteristics. The test-verified model
shall then be used to predict the maximum expected load for each
potential critical loading condition, including handling and
transportation, vibration-acoustic effects during lift-off, pyrotechnic
shocks, and emergency landing including thermal effects as aP/Plicable
to the mission. The maximum loads resulting from the analysis define the
load limits.

The usual methods of qualifying flight systems are by a strength test of
the structure to load limit times a safety factor. Some times primary
structure cannot be strength tested, and the structure must be designed
in that case to a higher safety margin. To satisfy STS safety
constraints, the untested structure must be manufactured using processes
subject to stringent quality control procedures to ensure conformance of
the structure to the design. A stress analysis must be performed to
demonstrate that the hardware has the proper margins on yield, ultimate
and dispersion. Below is an example of design safety margin required for
Space lab from the SPAH.

Minimum Design Safety Margin aP/Plicable to Space lab for a critical
experiment

+--------------------------------------------+-------+--------+-------+
|                                            | [Yie  | [Ult   | [Pro  |
|                                            | ld]{. | imate] | of]{. |
|                                            | under | {.unde | under |
|                                            | line} | rline} | line} |
+--------------------------------------------+-------+--------+-------+
| Tested\* structures                        | 1.1   | 1.4    | \-    |
+--------------------------------------------+-------+--------+-------+
| Non-tested structures                      | 1.25  | 2.0    | \-    |
+--------------------------------------------+-------+--------+-------+
| Emergency landing condition                | \-    | 1.0    | \-    |
|                                            |       |        |       |
| (No test required)                         |       |        |       |
+--------------------------------------------+-------+--------+-------+
| Lines and fittings less than 38 mm         | \-    | 4.0    | 2.0   |
+--------------------------------------------+-------+--------+-------+
| Lines and fittings 38 mm or greater        | \-    | 1.5    | 1.2   |
+--------------------------------------------+-------+--------+-------+
| Pressure tanks, actuating cylinders,       | \-    | 2.0    | 1.5   |
| valves, filters, and switches              |       |        |       |
+--------------------------------------------+-------+--------+-------+

Note: \* Qualification unit satisfactorily tested to 1.4 x Limit Load

There are several structural materials that require special
considerations due to their inherent failure Characteristics and
difficult manufacturing processes. Beryllium, composites, ceramics, and
glass structures all have specific requirements that are required to
verify the structures integrity for an STS flight. For an unmanned
launch, the structural verification requirements are lowered to flight
hardware standards and conservative engineering practice.

It is emphasized that all structural elements shall be in compliance
with aP/Plicable fracture control provisions for materials and
processes.

For a detail requirement aP/Plicable to your project needs be sure to
review the specific documentation that aP/Plies.

3.4.2.1 Pressure Systems

The maximum design pressure (MDP) for a pressurized system shall be the
highest pressure defined by the maximum relief pressure, maximum
regulator pressure or maximum temperature. Transient pressures shall be
considered. Design safety margins shall aP/Ply to MDP. Pressure
integrity shall be verified at the system level.

For shuttle aP/Plications, where pressure regulators, relief devices, or
a thermal control system is used to control pressure, collectively they
must be two faults tolerant from causing the pressure to exceed the MDP
of the system.

3.4.2.1.1 Design Verification

The design verification process for pressure vessels is shown in Figure
3.4.2.1-1. This figure contains the details for this verification
process, which aP/Plies to pressure vessels including qualification and
acceptance testing.

A pressure vessel is defined as a container designed for pressurized
storage of gases or liquids. The vessel meets these requirements:
Contains stored energy of 14,240 ft-lbs or greater based on adiabatic
expansion of a perfect gas; has a design limit pressure greater than 100
Pisa; contains a fluid in excess of 15 Pisa which will create a hazard
if released.

The carrier documentation should also be reviewed for any specific
requirements relative to that carrier.

3.4.3 Vibration Acoustics

The purposes of acoustic and random vibration testing, with test
factors, are: (1) to prove design performance at the maximum expected
flight level (MEFL), plus margin for uncertainty, (2) to demonstrate
that hardware is acceptable for flight, and (3) to verify that adequate
workmanship exists in the construction of the hardware.

To satisfy the vibration acoustic requirements, a space flight hardware
test program shall be developed which is based on an assessment of the
expected mission environments and the type of flight hardware program
(prototype or proto-flight). NASA-STD-7001 states very clearly the
requirements for space flight hardware, and these requirements should be
enveloped with the carrier mission requirements. An executive summary of
NASA-STD-7001 is given in Table 1.

**Table 1. Executive Summary of NASA-STD-7001 Verification Test
Requirements**

+--------------------------+-----------------+------------------------+
| **Type of Test           | **Test          | **Test Duration**      |
| Hardware**               | Level^1,2^**    |                        |
+--------------------------+-----------------+------------------------+
| Prototype:               | MEFL + 3 dB     | 2 minutes per axis     |
|                          |                 |                        |
| Qualification:           | MEFL + 3 dB     | 2 + 0.5N minutes per   |
|                          |                 | axis                   |
| Single Mission           | MEFL - 3 dB     |                        |
|                          |                 | 1 minute per axis      |
| Multiple (N) Re-flights  |                 |                        |
|                          |                 |                        |
| Flight Acceptance:       |                 |                        |
+--------------------------+-----------------+------------------------+
| Proto-flight:            | MEFL + 3 dB     | 1 minute per axis      |
+--------------------------+-----------------+------------------------+

Notes:

1.  Maximum Expected Flight Level (MEFL) defined as 95%/50% Probability
    Level.

2.  A [minimum]{.underline} workmanship random vibration test
    specification of 6.8 G's shall be imposed on electrical, electronic,
    and electromechanical components weighing 50 kg (110 lbs.) or less.
    This spectrum is given in Table 2.

3.4.3.1 Component Random Vibration Testing

Random vibration testing is required for essentially all electrical,
electronic, and electromechanical components and mechanisms. Exceptions
include large area-to-weight structures (which may be subjected to
acoustic testing) and hardware not practical to vibrate at the component
level (which may be more easily tested at the subsystem level, such as
cabling, plumbing, and blankets).

Random vibration tests, in three axes, shall be performed at the
component level of assembly to the test levels and durations specified
in NASA-STD-7001. If aP/Propriate, as specified in Section 3.4.3.1.1,
these test levels shall also envelope the component minimum workmanship
levels.

3.4.3.1.1 Workmanship

Workmanship random vibration testing is performed to identify latent
defects and manufacturing flaws in electrical, electronic and
electromechanical hardware at the component level. The minimum
workmanship level provided in NASA-STD-7001 is shown in Table 2 and has
been proven to be an aP/Propriate level for workmanship screening.
Thermal stress screening is also highly recommended, but it does not
replace the workmanship random vibration screening.

**Table 2. Component Minimum Workmanship Random Vibration Test Levels**

  ------------------------------------ ----------------------------------
  **Frequency**                        **Test Level**

  20 Hz                                0.01 g^2^/Hz

  20 to 80 Hz                          \+ 3 dB/octave

  80 to 500 Hz                         0.04 g^2^/Hz

  500 to 2000 Hz                       \- 3 dB/octave

  2000 Hz                              0.01 g^2^/Hz

  Overall Level                        6.8 G's
  ------------------------------------ ----------------------------------

The minimum workmanship random vibration test specification shall be
imposed on electrical, electronic, and electromechanical components
weighing 50 kg (110 lbs.) or less. It need not be aP/Plied to components
weighing greater than 50 kg (110lbs.).

When the minimum workmanship test level exceeds the qualification/flight
acceptance/proto-flight levels, the random vibration test level shall
envelope the two spectra. Thus, the workmanship level may often drive
the test level for hardware flying in relatively benign flight
environments, such as a space experiment being launched in the Shuttle.

Care should be exercised not to aP/Ply workmanship to highly
vibration-sensitive optical components and sensors that could be damaged
by these levels. Examples of possible exceptions might include mirror
assemblies, alignment critical devices and optical hard drives. For
these exceptions, some confidence of sufficient workmanship should be
obtained by other means such as by inspection or vendor data.

3.4.3.1.2 Stowed Components

Hardware designed and launched in a stowed condition shall satisfy the
following two conditions:

\(1\) A qualification/proto-flight test in the stowed configuration
shall be performed. This test is to verify that the flight package
design can survive the launch environments with margin.

\(2\) Electrical, electronic and electromechanical components weighing
50 kg (110 lbs.) or less shall be exposed to workmanship levels via
either testing in the stowed or hard-mounted configuration. This test is
to verify adequate workmanship of the flight /proto-flight hardware and
identify latent defects that could cause on-orbit failure (despite
package protection during launch), particularly in light of loads and
stresses imposed by handling and transportation. Highly
vibration-sensitive flight/proto-flight hardware will only be screened
to the vibration levels seen in the stowed configuration test (which is
likely to be below the 6.8 G's workmanship level).

The recommended logic to determine what testing should be performed is
provided in Figures 1 and 2, for proto-flight and prototype projects
respectively. For the evaluation of new flight packaging concepts it may
be beneficial to test first with a mass simulator unit, before testing
with the actual hardware.

A hard-mounted workmanship test of the flight/proto-flight hardware may
actually drive the hardware design. In these cases, it may be
aP/Propriate to first perform a qualification test of the hardware in
its hard-mounted configuration to relieve concern.

3.4.3.2 Additional Vibration Acoustic Testing

Vibration Acoustic testing shall be performed at the subsystem level, if
aP/Propriate, per NASA-STD-7001. Workmanship is not to be aP/Plied at
the subsystem level of assembly. Subsystems undergoing random vibration
testing may have their test levels reduced in order to prevent an over
test at the resonance's of the vibration test fixture.

An acoustic test may be required for large area-to-weight ratio
structures (such as skin panels, reflectors, dish antennae and solar
panels) that respond significantly to the direct impingement of the
acoustic environment.

Additional vibration acoustic tests shall be included in the test
program if aP/Propriate. For example, sine vibration may be added to
simulate sustained oscillations occurring during the launch, or as an
alternative method of satisfying another requirement such as loads
testing.

3.4.3.1 Flight Acceptance

Testing shall be conducted at the flight levels for 60 seconds.

3.4.4 Mechanical Shock

Self-induced pyrotechnic and externally induced shocks shall be
considered in defining the mechanical shock environment.

In addition, when the most severe shock is externally induced, a
suitable simulation of that shock shall be aP/Plied. When it is feasible
to aP/Ply the shock with a controllable shock-generating device, the
qualification level shall be 1.4 times the maximum expected value,
aP/Plied once in each of the three axes. If it is not feasible to aP/Ply
the shock with a controllable shock-generating device, the test may be
conducted at the payload level by actuating the shock-producing devices
in the payload that produce the shocks external to the subsystem to be
tested.

3.4.4.1 Flight Acceptance

The need for mechanical shock tests for the acceptance of previously
qualified systems shall be considered on a case-by-case basis. Testing
should be given careful consideration in accordance with mission
reliability goals, shock severity, hardware susceptibility, design
changes that could affect proximity to the shock-producing device, and
previous history. An End-to-End Test of any pyrotechnic device shall be
conducted for demonstration of acceptance for flight.

3.4.5 Mechanical Function

A kinematics analysis of all experiment mechanical operations is
required (a) to ensure that each mechanism can perform satisfactorily
and has adequate design margins under worst-case conditions, (b) to
ensure that satisfactory mechanical component clearances exist, for
stowed, operational configuration, and any mechanical operation, and (c)
to ensure that all mechanical elements are capable of withstanding the
worst-case loads that may be encountered.

Experiment verification tests are required to demonstrate that the
installation of each mechanical device is correct and that no problems
exist that will prevent proper operation of the mechanism during mission
life.

Qualification tests are required for each mechanical operation at
nominal-, low-, and high-energy levels. To establish that functioning is
proper for normal operations, the nominal test shall be conducted at the
most probable conditions expected during flight. A high-energy test and
a low-energy test shall also be conducted to prove positive margins of
strength and function. The levels of the tests shall demonstrate test
margins beyond the nominal conditions to cover adverse interaction of
potential extremes of parameters such as temperature, friction, spring
forces, stiffness of electrical cabling or thermal insulation, and, when
aP/Plicable, spin rate. Parameters to be varied during these high- and
low-energy tests shall include, to the maximum extent practicable, all
those that could substantively affect the operation of the mechanism as
determined by the results of analytic predictions or development tests.
As a minimum, however, successful operation at temperature extremes 10
degrees C beyond the range of expected flight temperatures shall be
demonstrated.

3.4.5.1 Flight Acceptance

Testing of experiment mechanical operation is required only at the
nominal condition for the acceptance of previously qualified systems.

3.4.5.2 Life Testing

Mechanical elements that are used for a fixed number of cycles (i.e.;
100 cycles) shall be qualified for 10% of the wear out-no failure (i.e.;
10 cycles) testing and for 5% of mission test operations (i.e., 5
cycles), this should leave an adequate life margin of 85% for final
mission operations (i.e.; 85 cycles). Life testing methods and systems
to be used will be described in the Verification Plan. Verification of
useful lifetime by analysis shall require a rationale for not testing
and suP/Porting analyses for each element that is not tested.

3.4.6 Pressure Profile

The need for a pressure profile test shall be assessed for all
subsystems. A qualification test shall be performed if analysis does not
indicate a positive margin for ultimate strength at loads equal to twice
those induced by the maximum expected pressure differential during
launch and, if aP/Plicable, reentry.

If a test is required, the limit pressure profile is determined by the
predicted pressure-time profile for the nominal trajectory of the
particular mission. Because pressure-induced loads vary with the square
of the rate of change, the qualification pressure profile is determined
by multiplying the predicted pressure rate of change by a factor of 1.12
(the square root of 1.25, the required qualification factor on load).

3.4.6.1 Flight Acceptance

Pressure profile test requirements do not aP/Ply for the acceptance
testing of previously qualified systems.

3.4.7 Mass Properties

Hardware mass property requirements are mission-dependent and,
therefore, must be determined on a case-by-case basis. The mass
properties program must include an analytic assessment of the system
ability to comply with the mission requirements, including constraints
imposed by the launch vehicle, suP/Plemented as necessary by
measurement.

3.5 ELECTROMAGNETIC COMPATIBILITY (EMC) REQUIREMENTS

EMC component, subsystem and system design are required to meet two
basic criteria. First, the equipment shall not generate electromagnetic
interference that interferes with its own mission objectives or the
operation and safety of concurrently operating systems, i.e., the launch
vehicle, aircraft, or other payloads. Secondly, the system shall be
designed to operate in the missions\' defined electromagnetic
environment, containing both conducted and radiated interference
sources.

A demonstration of 6 dB margins for safety critical interfaces, and a 20
dB margin for pyrotechnic circuits is required.

3.5.1 EMC Guidance

From these two basic requirements, program level electromagnetic
interference (EMI) specifications have been derived for generic payloads
integrated into specific carriers, i.e., Space Laboratory, Hitchhiker
etc. These specifications are controlled by the integrating element and
represent a set of design and verification specifications that if
complied with, will assure adequate margin exists between emissions and
susceptibility of the payload and the conducted and radiated
environment. This document does not present any GRC-unique EMI
verification test levels or test methods since these requirements are
dictated by the integrating Center.

The method of achieving EMC is through a process called EMI control, and
is managed through the use of an EMI Control Plan. For simple function
payloads, this plan may be as simple as adherence to the aP/Propriate
carrier\'s EMC specification referenced earlier. For a larger,
multifunctional system however, the power distribution system, control
functions, signal, data processing, and distribution function must be
managed through careful attention to electrical isolation, grounding,
filtering and shielding. It is important to recognize that EMI must be
controlled in the time domain (in-rush current at turn-on, turn off) and
in the frequency domain (signal pass bands and switching power
suP/Plies).

Many experiments rely on the use of commercial off-the-shelf (COTS)
equipment that may not meet these requirements. The EMI control process
must address how these non-compliant components will be managed in the
integrated system such that they will meet the system objectives before
procurement of these items is allowed.

Below are some design requirements to look for in COTS equipment:

Isolation - All referenced EMC specifications have a requirement for
both power and signal isolation usually verified by a DC measurement.
These requirements are verified at the system level. Adherence to these
principles within the system, while not mandatory in all cases, should
not be abandoned without sound engineering judgment. The most
fundamental decision to be made for the power distribution system is
whether to use a primary or secondary power distribution system and how
this affects signal referencing. A system level grounding and isolation
diagram is useful for this purpose and should be presented at or prior
to PDR.

Bonding - the methods and processes of joining electrical fraying
surfaces, is specified as a method to assure an equal potential ground
plane (at all frequencies) and to achieve electrical safety
requirements. This requirement aP/Plies to all conductive materials
unless a deviation is requested. The deviation is aP/Proved by the
Project Manager and the Project Assurance Manager. Shielding - Shielding
may be employed to control radiated fields to and from the external
environment (addressed by the verification requirements), and control of
fields within equipment. Shields take the form of braids and foils for
cables, and metal compartments within equipment. Shielding is normally
aP/Plied to wiring connecting individual equipment or to reduce
cable-to-cable coupling in signal circuits. Filtering - Filtering may be
employed to control conducted emissions into and out of individual
equipment or components within equipment. EMI control utilizing
filtering is usually necessary to meet electrical transient requirements
or limit the pass band of power, control, and signal circuits to meet
emissions and susceptibility requirements. Filtering is best aP/Plied at
the source of the unwanted interference. Twisted leads are used to
reduce electric fields.

3.6 VACUUM, THERMAL, AND HUMIDITY REQUIREMENTS

Vacuum, thermal, and humidity tests shall demonstrate the system
performance:

a.  Properly operate in the flight environment, specifically vacuum,
    temperature, and humidity.

b.  Properly control the thermal environment of temperature sensitive
    items with a passive or active thermal control system.

c.  Survive the temperature and humidity conditions of transportation;
    storage, and pre and post launch conditions on the carrier.

These tests shall also be used as an environmental screening for the
system to identify manufacturing defects and serve as burn-in to reduce
the failure rate caused by infant mortality.

3.6.1 Compliance with Requirements

The developer shall demonstrate compliance by conducting a set of tests
and analyses that collectively meet the above requirements. Tests may
require suP/Porting analyses and vice versa. The following are
guidelines of tests and analyses that will meet the requirements.
Depending upon the project and location of the project some tests will
not be relevant to all systems.

3.6.2 Testing Levels

The project shall determine the testing levels for the system. Testing
at the component and subsystem levels should be considered optional for
small projects.

The testing criteria should have the system operating during testing
except for shiP/Ping and storage. If the system cannot be operated in
the specified ranges, it should be flagged that the testing was reduced
for this component in the verification plan. No non-operating tests are
required or suggested

unless there are unusual shiP/Ping and storage requirements. If, for
example, a material specimen must be maintained within a narrow
temperature range, then the transportation technique and packaging
should be tested. When components cannot be operated unless in a
subsystem, then the testing should occur at the subsystem level.

Testing is only required at the full assembly level. It is recommended
that testing be performed on suspect components and subassemblies as
soon as possible in project development to uncover problems early in the
program.

Slow and fast thermal cycles may be needed. A slow ramp rate is
considered 1 degree C/minute and a fast rate are 3-5 degrees C/minute.

If the temperature range needs to be modified, the project should use
the following guidelines: The number of cumulative cycles shall be no
less than eight with the test levels at max/min predicted temperature
levels +/-10 degrees C, respectively, with a minimum delta of 55 degrees
C for component level testing.

3.6.3 Description of AP/Plicable Testing

This section describes the testing and analysis that may be performed to
satisfy the requirements. This is by no means the only testing and
analysis that may be performed but is offered as a guideline to the
system developer.

3.6.3.1 Thermal Cycling

Thermal cycling is a common testing method. It is used to verify thermal
analyses, to verify acceptable performance over the operating
temperature ranges, and to burn-in the system and reduce the failure
rate caused by manufacturing defects. As a minimum, three thermal cycles
failure free should be the goal.

3.6.3.1.1 Ambient Pressure Thermal Cycle

Thermal conditions based on the worst case high and low temperature
extremes with +/- 10 C added margins should be used. The system should
be operating during this test. The negative extreme should be
aP/Proached prior to the positive extreme, since the shorter duration
will reduce the test time should a critical failure occur at low
temperature extreme.

3.6.3.1.2 Thermal-Vacuum

Thermal vacuum tests are only required for systems that will see a
vacuum. The test should be performed the same as ambient pressure
thermal cycling except for the vacuum. If your payload is in a sealed
container, you may only want to run the test on the container to prove
that the components inside will never see the vacuum.

Another use of the thermal vacuum test is to simulate the absence of
free convection in a low gravity environment. This is usually only
performed on system with passive thermal control and components that is
not sensitive to the vacuum.

The number of thermal cycles and levels are the same as would be used
for ambient pressure thermal cycles.

3.6.3.2 Burn-in Tests

One hundred hours of failure, free operation is desired before flight.
Mission simulations are recommended to fulfill this time.

3.6.3.3 High Temperature Dwell Tests

High temperature dwell precipitates failures due to time dependent
dielectric breakdown (TDDB). The system shall be operating during this
test. This test can accelerate failure rate and thus may be used to
reduce burn-in times.

3.6.4 Description of AP/Plicable Analysis

Thermal Analysis can be performed by using many different commercial
software aP/Plications. The thermal analysis should include the
following:

Requirements of analyses

Configuration of system

List of operating temperature range of components

Material properties

Environmental conditions and design criteria

3.6.5 References

The reference documents for this manual are available at:

<http://www.hq.nasa.gov/office/codeq/doctree/doctree.htm>.

3.7 MISSION SIMULATION AND COMPATIBILITY TEST REQUIREMENTS

The mission simulation test is intended to demonstrate that the system
will perform the total set of operations it was designed and programmed
for in a simulated flight environment.

The end-to-end test is intended to demonstrate the compatibility of the
system with other mission operational elements. The end-to-end
requirements aP/Ply equally to the testing of prototype flight payloads
or the testing of previously qualified system.

3.7.1 Mission Simulation

The complete mission operating timeline shall be simulated using the
flight hardware and flight software (i.e., the complete flight system).
This simulation would cover both nominal and if aP/Propriate,
contingency cases. The system operation shall simulate the real flight
mission as closely as possible. This would include using external
stimulus or instruments, simulation of external signals, data flows and
external system control.

3.7.2 Compatibility Test

An end-to-end compatibility test shall be conducted on the complete
operational system in the final mission configuration, as closely as
possible. This test would include the system, the operational software,
the ground system, including the Project Operation Control Center
(POCC), and the aP/Propriate network elements in order to fully
demonstrate operational compatibility and the ability of the entire
system to perform as required during the mission.

![](media/image1.wmf)

[]{#section_4 .anchor}SECTION 4 - SYSTEM SAFETY

4.1 SYSTEM SAFETY REQUIREMENTS

4.1.1 General System Safety Requirements (required by NPG 8715)

A system safety program shall be established in accordance with the
aP/Propriate guidelines stated in: NPG 8715 "NASA Safety Manual
Procedures And Guidelines" and shall follow the process flow outlined
in:

LeR-P0510.007

http://livelink.lerc.nasa.gov/livelink/livelink?
func=llnologin&objId=459717&objAction=browsenologin&sort=name

4.1.2 Space Transportation System Safety Requirements (required by NSTS
1700.7)

All space flight hardware and software that is designed to fly on the
Space Transportation System (Shuttle) must comply with the requirements
as stated in:

-   NSTS 1700.7 Safety Policy and Requirements for Payloads Using the
    Space Transportation System, and

-   NSTS 13830 Implementation Procedure for NSTS Payloads System Safety
    Requirements.

-   NSTS 18798 Interpretations of NSTS/ISS Payload Safety Requirements

-   <http://wwwsrqa.jsc.nasa.gov/pce/Default.htm#Requirements_Documents>

All ground processing of Shuttle payloads and associated GSE at Kennedy
Space Center must meet the requirements in:

KHB 1700.7 Space Transportation System Payload Ground Safety Handbook

http://wwwsrqa.jsc.nasa.gov/pce/Default.htm#Requirements_Documents

For GAS Projects:

870-PG-7120.x.x (to be written) GAS Experimenter\'s Handbook.

<http://gdms.gsfc.nasa.gov/gdms/plsql/masterlist.pgwi>

4.1.3 Space Station System Safety Requirements (required by NSTS 1700.7
ISS Addendum)

All space flight hardware and software that is designed to fly on the
Space Station must comply with the requirements as stated in section
4.1.2 at a minimum.

The Specific Space Station System Safety Requirements are covered in:

NSTS 1700.7B ISS Addendum

<http://wwwsrqa.jsc.nasa.gov/pce/Default.htm#Requirements_Documents>

4.1.4 Sounding Rockets Safety Requirements (required by 803-WI-8072.1.1)

All hardware and software that is designed to fly on a Sounding Rocket
must comply with the requirements stated in:

Range Safety Manuals for GSFC/WFF, 803-WI-8072.1.1:

http://gdms.gsfc.nasa.gov/gdms/plsql/masterlist.pgwi:

Sounding Rocket Program Handbook, 810-HDBK 87730.4.4

<http://www.wff.nasa.gov/pdf/sr_handbook.pdf>

4.1.5 Project Safety Plan

The experiment developer shall prepare and submit a project safety plan
(typically included as a section in the PAP, section 1.2) to the Chief
of the Glenn Risk Management Office for review and concurrence prior to
RDR. The safety plan should contain a brief explanation of what will be
done and a schedule describing how the experiment developer intends to
meet the aP/Plicable safety requirements stated in sections 4.1.1
through 4.1.4.

4.1.6 Safety Compliance Documentation

All Safety Compliance Data Packages must be concurred by the Chief of
the Glenn Risk Management Office (0510) and the Project Manager.

4.1.7 Aeronautics System Safety Requirements

TBD

4.2 SYSTEM SAFETY GUIDELINES

This section consists of a typical set of tasks and guidance to assist
the Project Manager to setup an effective system safety program. This
section divides the guidelines into four sections that address the
different program phases (Phase A - CODR, Phase B - RDR, Phase C -
PDR/CDR, and Phase D - Post CDR/PSR). The guidelines are divided into
four categories:

a.  Trade Studies/Engineering Activities

b.  Requirements

c.  Hazard Analysis

d.  Safety Compliance Data Packages.

    4.2.1 System Safety Guidelines for Projects in Phase A

> a\. The System Safety Engineer should participate in initial trade
> studies.
>
> b\. Develop overall safety plan for the project.
>
> c\. Provide mandatory safety requirements based on section 4.1 above.
>
> d\. Develop initial hazard analysis, if required by PAP, as data is
> available.

4.2.2 System Safety Guidelines for Projects in Phase B

> a\. Continue participation in trade studies and engineering
> activities.
>
> b\. Finalize safety requirements based on carrier, destination, etc.
> Ensure requirements are incorporated in aP/Propriate project
> documentation.
>
> c\. Update hazard analysis as aP/Propriate.
>
> d\. Gather data for input into a Safety Compliance Data Package, if
> required by the PAP.

4.2.3 System Safety Guidelines for Projects in Phase C

> a\. Continue participation in engineering activities.

b\. Determine requirements verification methodologies. Ensure specific
safety verifications are included in overall project verification
plans/activities.

> c\. Update and complete hazard analysis, if aP/Plicable.

d\. Develop and present Safety Compliance Data Package to aP/Propriate
review organizations, if aP/Plicable.

4.2.4 System Safety Guidelines for Projects in Phase D

> a\. Continue participation in engineering activities.
>
> b\. Ensure completion of requirements verification.
>
> c\. Ensure hazard analysis results are considered in final risk
> management decisions.
>
> d\. Ensure implementation of all identified hazard controls and
> perform closeout of all verifications required by the Safety
> Compliance Data Package.

[]{#SECTION_5 .anchor}SECTION 5 - EEE AND MECHANICAL PARTS CONTROL
REQUIREMENTS AND GUIDELINES

5.1 GENERAL REQUIREMENTS

The developer shall plan and implement an electrical, electronic, and
electromechanical (EEE) and mechanical parts control program according
to the general guidelines of NPD 8730.2, NASA Parts Policy, that
complies with the requirements and addresses the guidelines as outlined
in this section. The parts control program implemented shall suP/Port
the required mission life. In the following paragraphs, short duration
missions are defined to be one year or less, and long duration missions
are greater than one year.

The requirements of Section 5 shall aP/Ply to all flight system
fidelities including qualification and proto-flight systems.

5.2 PARTS SELECTION AND SCREENING

Parts shall be selected in order to meet program/project reliability
requirements over mission life. For ISS payloads, EEE parts selection
shall be per the requirements of SSP 50431.

5.2.1 Parts Grades

For long duration missions, parts from the highest grade possible that
meets mission life reliability requirements shall be selected. For short
duration projects, many of them use commercial off the shelf parts. The
Space Experiments Division selects parts from the requirements of
Operating Instruction 6700.4, Electrical, Electronic, and
Electromechanical (EEE) Parts Policy.

A higher grade part will have a higher reliability due to the
manufacturer\'s quality assurance procedures and practices, including
screening. Parts manufactured on a qualified manufacturing line will
tend to be the most reliable. In general, the available grades of EEE
parts, in order of decreasing reliability, are as follows:

1.  Level 1 parts contained in the NASA Parts Selection List (NPSL) or
    Grade 1 parts contained in the GSFC Preferred Parts List (GSFC P/PL)

2.  Qualified Manufacturing Line (QML) or Qualified Parts List (QPL)
    parts meeting the same quality level as Level 1 parts, e.g. Class
    S/Class V microcircuits, Class K hybrids, JANS semiconductors,
    failure rate level S passive parts

3.  Level 2 parts contained in the NPSL or Grade 2 parts contained in
    the GSFC P/PL

4.  Qualified Manufacturing Line (QML) or Qualified Parts List (QPL)
    parts meeting the same quality level as Level 2 parts, e.g. Class
    B/Class Q microcircuits, Class H hybrids, JANTXV/JANJ
    semiconductors, failure rate level P passive parts

5.  Level 3 parts contained in the NPSL

6.  Other qualified military parts, including Class M/Class N/Class
    T/883B microcircuits, JANTX/JAN semiconductors, failure rates M and
    L passive parts

7.  Other military parts, e.g. ceramic, hermetically sealed
    microcircuits with an operating temperature range of -55 degrees C
    to 125 degrees C

8.  Industrial parts, e.g. ceramic, hermetically sealed microcircuits
    with an operating temperature range of -25 degrees C to 85 degrees C

9.  Commercial parts, e.g. plastic or ceramic, non-hermetic
    microcircuits with an operating temperature range of 0 degrees C to
    70 degrees C

Fasteners that are recommended for flight systems are listed in the GSFC
Preferred Flight Fastener Inventory.

5.2.2 Flight Parts Screening

In addition to the parts level screening tests associated with the
different grades, component or system level tests are required to
demonstrate the reliability of the parts and their assemblies. These
tests are required no matter what grade of parts is used in the
development of the experiment. However, the results of these tests do
not improve the reliability of the individual parts, and cannot, for
example, be used to assume the same reliability for a commercial part as
for a grade 1 part. The required component or system level screening
tests are the following:

-   Burn-In (see Section 3.6)

-   Thermal Cycle (see Section 3.6)

-   Vibration (see Section 3.4)

5.2.3 De-rating

The de-rating of parts improves the reliability of systems (see
Preferred Reliability Practice PD-ED-1201
<http://www.hq.nasa.gov/office/codeq/overvu.htm>). All EEE parts shall
be used in accordance with the de-rating guidelines of the GSFC
Preferred Parts List. For ISS payloads, EEE parts shall be de-rated per
the requirements of SSP 57000 or SSP 57003 as aP/Plicable. (Reference
SSP 30312, AP/Pendix B that contains the ISS core system de-rating
requirements.) A developer\'s de-rating policy may be used in its place
if it has received GRC Project Manager aP/Proval.

5.2.4 Radiation Hardness

Parts shall be selected to meet their mission aP/Plication in the
predicted radiation environment. The radiation environment consists of
two separate concerns, total dose and single event effects.

5.2.4.1 Total Dose

Total dose radiation may damage semiconductor devices and microcircuits
either by displacement (lattice damage by recoil) or ionization
(electron-hole pair generation). In bipolar devices displacement and
ionization cause gain degradation and an increase in leakage currents.
In MOS devices ionizing radiation causes an accumulation of traP/Ped
charge in the gate oxide and resultant shifts in threshold voltages. The
total dose effects of gain degradation, increased leakage currents,
threshold voltage shifts, and increased propagation delays can all cause
devices to fail.

Total dose damage is cumulative and is a function of time, exposure, and
shielding. As time of exposure increases and shielding decreases the
absorbed total dose will increase.

Effects of total dose may be neglected for short and long duration
missions where the experiment is enclosed within the walls of the
spacecraft (i.e. within the Space Shuttle/Space Station). In this case
use of commercial parts with no total dose testing is acceptable.

For any mission where the experiment is not sheltered by the spacecraft
walls, and the expected total dose is greater than 1 kilo-rads, assembly
level testing may be performed. Testing shall be performed under nominal
bias conditions and at the expected flight environment dosage. The
expected flight dosage can be determined from a dose vs. shielding
curve, such as Figure 3.1.3-1 in SSP30512, Revision C, for the Space
Station orbit.

Alternatively, in lieu of testing, an analysis of the parts list may be
performed. The expected dose may be compared to the susceptibility of
semiconductors and microcircuits in the parts list. General
susceptibility levels are available from publications such as the GSFC
P/PL. Jet Propulsion Laboratory (JPL) maintains a database of radiation
test results, called the JPL Radiation Effects Database (RADNET). In
general, more data exists for higher-grade parts. Other databases of
radiation test results are the GSFC Radiation Effects and Analysis and
the Electronics Radiation Response Information Center (ERRIC).

5.2.4.2 Single Event Effects

Single Event Effects (SEE) is phenomena, affects integrated circuits or
power transistors caused by a single high-energy particle strike. These
events may cause either \"soft\" errors or \"hard\" errors.

A \"soft\" error or Single Event Upset (SEU) occurs when the logic state
of a circuit is changed. It can be corrected by reloading the correct
information into memory or by restarting an algorithm.

A \"hard\" error results in permanent damage to a device and can cause
circuit failure. Examples of \"hard\" errors include Single Event Gate
Rupture (SEGR) in N-channel power transistors, Single Event Burnout
(SEB) in power transistors and Single Event Latch up (SEL) in CMOS
integrated circuits.

The likelihood of a SEE occurring is a function of the sensitivity of
the device in question and of the natural space environment that will be
encountered. Highly susceptible devices (such as those sensitive to
protons) may experience multiple SEU hits on every orbital pass through
the South Atlantic anomaly, where the radiation belts dip down into the
uP/Per atmosphere. Unlike total dose, SEE is not a cumulative effect; it
does not depend on the length of time in orbit. For this reason,
susceptibility to SEE should be considered for both short and long
duration missions.

Testing for SEE can be cost prohibitive. However, proper part selection,
as well as aP/Propriate circuit design and parts de-rating, can help to
mitigate the impact of SEE, and designers should compare their parts
lists to existing test data. Jet Propulsion Laboratory's RADNET, Goddard
Space Flight Center\'s Radiation Effects and Analysis, and ERRIC
databases contain SEE test data as well as total dose.

5.2.5 Electric Motors

Non-contacting electric motors are preferred for space flight use. They
are recommended for long duration missions where motor durability is
required and for aP/Plications where the motor is exposed to vacuum.

5.2.6 Parts Risk

The risk associated with a given part is related to the grade level of
the part, with the highest-grade parts (e.g. Grade 1 or Class S) having
the lowest risk. The risk associated with each part shall be evaluated
(typically as low, medium, high or unknown) according to a set of
guidelines based upon mission requirements. A plan shall be developed to
mitigate the risk in cases of high or unknown risk. An example of a set
of parts risk guidelines that are suitable for long duration space
flight missions is the EEE Parts Risk Assessment Matrix for Flight
AP/Plications
(http://eee.larc.nasa.gov/forum/mission_parts_risk_assesment_matrix_joint.htm).

5.3 PARTS STORAGE CONTROL

Parts shall be stored in a controlled environment that protects the
parts from excessive temperatures and humidity and from contamination.
An electrostatic discharge (ESD) control plan shall be implemented for
ESD sensitive parts (see Section 8.9). Trace ability by part number,
manufacturer, and lot date code shall be maintained for parts in
controlled storage.

5.4 PARTS AGE CONTROL

As some types of parts may fail or drift while in storage, parts
assemblies in controlled storage shall be subjected to an acceptance
test within four months prior to flight. If there is any system
modification as a result of a failure during the acceptance test, the
functional acceptance test shall be repeated. In addition, if there is a
significant system modification that may affect the mechanical/software
integrity of the assembly, the thermal cycle and vibration procedures of
the acceptance test shall be repeated.

Information on types of parts subject to age degradation can be obtained
from the Reliability Analysis Center.

5.5 PARTS IDENTIFICATION LIST

A Parts Identification List (PIL) shall be prepared, maintained, and
updated by the developer in accordance with the developer\'s
configuration control system. All submissions to GRC Project Manager and
Program Assurance Manager (0510-RMO) shall be in a computer-readable
form.

The PIL shall be compiled by experiment component, instrument, or
instrument component and shall include as a minimum the following
information: part number, part name or description, manufacturer name or
CAGE number, quantity, and drawing number and name of the next higher
assembly where part is located. The part number shall be the military
specification part number if it is a military part or the
manufacturer\'s part number if it is a commercial part.

The developer shall maintain trace ability by part number, manufacturer,
and lot date code for all EEE parts assembled into flight hardware
through the use of configuration identification lists (build paper) (see
Section 8.4).

[]{#SECTION_6 .anchor}SECTION 6 - MATERIALS AND PROCESSES REQUIREMENTS

6.1 GENERAL REQUIREMENTS

The objective of the materials and processes activity is to ensure the
safety of the project through the proper selection, aP/Plication,
processing, inspection, and testing of the chosen materials for the
project subsystems and equipment. The Glenn Research Center (GRC) Risk
Management Office (RMO), under the management of the Office of Safety
and Mission Assurance (OSAT), uses the "Materials and Processes (M&P)"
Inter Center Agreements (ICA) established with Marshall Space Flight
Center (MSFC), Johnson Space Flight Center (JSC), and Goddard Space
Flight Center (GSFC) to baseline the process for selection and
certification of materials used in space flight payload hardware. The
ICA is used to ensure compliance with the safety requirements of NSTS
1700.7B.

6.1.1 Specific Requirements

Assurance of safety related materials and processes requirements is
accomplished by review of all drawings and Engineering Change Orders
(ECO) by the M&P project representative as part of the drawing release
process. M&P aP/Prove the as-designed materials on the basis of this
review process. The experiment developer provides materials reliability
through aP/Plication of specifications such as material allowables,
welding, brazing, heat-treating, and testing.

6.2 REFERENCE DOCUMENTS

See AP/Pendix A.

6.3 MATERIALS ASSESSMENT PROGRAM

The following outlines the general provisions for the materials and
processes program at GRC. MSFC-HDBK-527 is used as a database for the
selection of payload materials. Topics that are addressed include:

1.  Corrosion Resistance per LeR-W0510.042

```{=html}
<!-- -->
```
2.  Stress Corrosion Cracking Susceptibility per LeR-W0510.044

3.  Outgassing (Thermal Vacuum Stability of Polymeric Materials) per

> LeR-W0510.045

4.  Flammability per LeR-W0510.043

```{=html}
<!-- -->
```
5.  Fluid Compatibility LeR-W0510.047

6.  Materials Offgassing in Habitable Areas (Toxicology Assessment) per

> LeR-W0510.046
>
> 7\. Other Material Assessments according to NSTS 1700.7B paragraph
> 209.1
>
> Methods of control of the above entail:
>
> a\. Material Identification and Usage Lists (MIUL) per LeR-W0510.040
>
> b\. Material Usage Agreements (MUA) per LeR-W0510.041
>
> c\. Flammability Assessment per NSTS 22648
>
> d\. Testing to NASA-STD-6001 (previously NASA-STD-6001)

6.3.1 Corrosion (Internal and External Environments)

All parts, assemblies, and equipment, including spares shall be finished
to provide protection from corrosion in accordance with the requirements
of MSFC-SPEC-250. MSFC-HDBK-527 rates the corrosion resistance of a
component based on MSFC-SPEC-250. Materials are rated \"A\" if they meet
the requirements of MSFC-SPEC-250 Class II and do not require a coating
for their intended service. Material rated other than \"A\" requires
specific corrosion protection for each aP/Plication and documented per
LeR-W0510.042. The required protection shall be specified by the design
organization and verified by GRC OSAT per Product Assurance Instruction
(PAI) 312.

For materials exposed to other than salt water, seacoast, or mild
industrial environments, specific evaluations shall be conducted and
verified to determine the compatibility of materials utilized. The RMO
M&P representative should be contacted regarding the specific evaluation
required.

6.3.2 Stress Corrosion (Internal and External Environments)

Stress corrosion is defined as the combined action of sustained tensile
stress and corrosion to cause premature failure of materials. Certain
materials are more susceptible than others are. If a susceptible
material is placed in service in a corrosive environment under tension
of sufficient magnitude, and the duration of service is sufficient to
permit the initiation and growth of cracks, failure will occur at a
stress lower than the material would normally be expected to withstand.
The corrosive environment need not be severe in terms of general
corrosive attack. Service failures due to stress corrosion are
encountered for which the surfaces of the failed parts are not visibly
corroded. There is no absolute threshold stress for stress corrosion;
such as with other material properties, but comparative stress corrosion
thresholds can be determined under controlled condition of test.
Estimates of the stress corrosion threshold for a specific service
aP/Plication must be determined for each alloy and heat treatment using
a test piece, stressing procedure, and corrosive environment that are
aP/Propriate for the intended service.

MSFC-SPEC-522 lists alloys susceptibility to stress corrosion cracking
at ambient temperature exposed to salt water, seacoast, or a mild
industrial environment. Alloys and tempers, which by testing and
experience have been shown to possess high resistance to stress
corrosion cracking, are listed in Table I. Figure 6-1 lists a small
sample of these alloys. These should be used preferentially and GRC OSAT
RMO aP/Proval is not required prior to their use. Any alloys or
weldments not listed in Table I of MSFC-SPEC-522, require an MUA per
LeR-W0510.041 containing information specified on the Stress Corrosion
Evaluation Form (AP/Pendix C of MSFC-SPEC-522) as referenced in
LeR-W0510.044 paragraph 6.6.

Alloys and tempers listed in Table II of MSFC-SPEC-522 are moderately
resistant to stress corrosion cracking. They should be considered for
use only for cases where a suitable alloy cannot be found in Table I. An
MUA, per LeR-W0510.041, must be submitted containing information
specified on the Stress Corrosion Evaluation Form (AP/Pendix C of
MSFC-SPEC-522), as referenced in LeR-W0510.044 paragraph 6.6, and
aP/Proved by RMO prior to use. Proposed utilization of materials from
Table II in aP/Plications involving high installation stress, such as
springs or fasteners, will not be aP/Proved.

The alloys listed in Table I have been found to be highly susceptible to
stress corrosion cracking. They should be considered for use only in
aP/Plications where it can be demonstrated conclusively that the
probability of stress corrosion is remote because of low sustained
tensile stress in critical grain directions, suitable protective
measures, or an innocuous environment. An MUA, per LeR-W0510.041, must
be submitted containing information specified on the Stress Corrosion
Evaluation Form (AP/Pendix C of MSFC-SPEC-522), as referenced in
LeR-W0510.044 paragraph 6.6, and aP/Proved by RMO shall be obtained
prior to use of any alloy or weldments in Table I.

Alloys used for electrical wiring, thermocouple wires, and magnet wires,
and similar non-structural electrical or electronic aP/Plications are
exempt from the requirements of MSFC-SPEC-522.

Protective coatings such as electroplate, anodize, or chemical
conversion coatings do not change the stress corrosion rating of alloys
to which they are aP/Plied. Table I alloys thus treated must be
identified with MUA and stress corrosion evaluation forms submitted for
aP/Proval by RMO (0510) prior to their use.

Surface treatments such as carburizing or nitriding may adversely affect
the stress corrosion rating of materials to which they are aP/Plied. All
materials thus treated must be identified and MUA and stress corrosion
evaluation forms submitted to RMO (0510) prior to their use.

MSFC-HDBK-527 lists materials as \"A\" rated if they are listed in Table
I of MSFC-SPEC-522. Materials listed in Table II of MSFC-SPEC-522 are
rated \"B\", and materials in Table I are rated \"C\". Materials rated
\"U\" have not been tested and require testing to determine stress
corrosion cracking susceptibility prior to use. Materials rated \"N\"
are not aP/Plicable to stress corrosion cracking susceptibility or not
usually used in design. Materials rated other than \"A\" in
MSFC-HDBK-527 shall be substantiated by an MUA, containing information
specified on the Stress Corrosion Evaluation Form (AP/Pendix C of
MSFC-SPEC-522) and submitted per LeR-W0510.051. Non-"A" rated material
used in safety critical of fracture critical aP/Plications must also be
referenced in the stress corrosion cracking hazard report.

6.3.3 Outgassing (AP/Plicable to Exterior Areas of Vehicle Only)

All organic materials shall meet the requirements of JSC SP-R-0022A. JSC
SP-R-0022 establishes outgassing requirements and test guidelines for
polymeric materials used in the space thermal vacuum environment. The
basic requirement is that organic materials used in vacuum aP/Plications
exhibit a total mass loss of less than 1% and a collected volatile
condensible material of less than 0.1% when tested in accordance with
SP-R-0022A or ASTM-E-595. Materials rated \"A\" in MSFC-HDBK-527 meet
these requirements without a special cure or bakeout. Material usage
agreement\'s (MUA) must be submitted to the RMO (0510) for all materials
that are not \"A\" rated for outgassing (thermal vacuum stability) as
assessed per LeR-W0510.045.

Commercial off-the-shelf items (black boxes) that incorporate materials
not specifically identified on a materials list or drawing and items
whose identification becomes impractical shall be vacuum baked. The
baking shall be done at a pressure of less than 10^-5^ torr at the
highest allowable temperature for a sufficient period of time to reduce
the rate of outgassing to a level where the outgassed products cannot
contaminate sensors, electronics, optical surfaces, etc. Sealed
pressurized containers are exempt.

6.3.4 Flammability (AP/Plicable to All Vehicle Areas)

All materials shall meet the flammability requirements of NSTS 1700.7B,
section 209.2. Materials flammability shall be tested in accordance with
NASA-STD-6001 (previously NASA-STD-6001C), Test 1 - \"Upward Flame
Propagation,\" Test 8 - \"Flammability Test for Materials In Vented and
Sealed Containers,\" or by configuration tests that establish whether a
material can ignite and propagate fire in its use configuration.

MSFC-HDBK-527 assigns an \"A\" rating to a material, which meets Test 1,
in the thickness and test condition specified. All materials not \"A\"
rated for flammability will require an MUA as well as being documented
in a flammability assessment in accordance with LeR-W0510.043 and NSTS
22268.

Electrical wire insulation shall be made of Teflon or polyimide and meet
one of the following specifications:

-   MIL-C-17/60

-   MIL-C-17/93

-   MIL-C-27500 (Teflon jacket only)

-   MIL-W-16878 slash numbers 4A, 5A, 6, 11, and 13

-   MIL-W-22759 slash numbers 1, 5-8, 12, 28, 29, 30, and 31

-   MIL-W-8138

The RMO M&P representative shall be contacted regarding utilization of
any wires or cables that do not meet any of the above specifications.
Testing for flammability in accordance with NASA-STD-6001 Test 4
\"Electrical Wire Insulation Flammability,\" and for arc tracking in
accordance with NASA-STD-6001 Test 18, \"Arc Tracking\" may be required.
An alternative is protection from external ignition sources by one of
the following methods:

a.  WraP/Ping with a nonflammable fiberglass-backed/silicone adhesive
    tape.

b.  Covering with a sleeve of double-layer 7.5 oz/square yard Nomex
    fabric or a single layer of beta cloth, polybenzimidazole (PBI), or
    other nonflammable fabric.

c.  Covering with a braided Teflon sleeve.

d.  Covering by heat shrinking a polyvinylidene fluoride or Teflon
    sleeve.

Wire and cable accessories such as cable markers, spacers, and cable
ties should not contribute to fire propagation paths. Polyvinylidene
fluoroelastomeric cable markers are generally used. Other types of cable
marker material may be accepted if used in small amounts or covered with
a clear Teflon TFE or FEP sleeve. Most types of spacers are usually
accepted based on their heat sink effects. Acceptable lacing cords can
be made from Teflon TFE, Teflon TFE/glass, or Nomex, and acceptable
cable ties can be made from ETFE or ECTFE fluoropolymers. When flammable
cable tie wraps are used, spacing of 2 inches or more between ties
generally results in a non-fire-propagation condition.

In addressing EEE parts, past studies have shown that EEE parts covered
by a conformal coating that meets the test requirements of NASA-STD-6001
for flammability in the worst-case use atmosphere are acceptable for
flammability. All EEE parts not conformal coated with a material meeting
the flammability requirements of NASA-STD-6001 shall be evaluated for
flammability according to the guidelines of NSTS 22648.

6.3.5 Fluid Compatibility (AP/Plicable to All Vehicle Areas)

All materials shall meet the fluid systems compatibility requirements of
NSTS 1700.7B, paragraph 209.la. Materials compatibility with liquid and
gaseous oxygen shall be evaluated in accordance with LeR-W0510.047. The
tests that must be complied with are NASA-STD-6001C Test 13,
\"Mechanical Impact for Materials in ambient Pressure LOX (Test 13A)\"
and \"Mechanical Impact for Materials in Variable Pressure LOX and GOX
(Test 13B),\" and \"Upward Flammability of Materials in GOX (Test 17).\"
When a material in an oxygen system fails the criteria of either test at
its maximum use pressure, the Project and RMO (0510) will document the
system safety rationale in an MUA per LeR-W0510.041.

Materials compatibility with hazardous fluids other than oxygen shall be
performed in accordance with NASA-STD-6001 Test 15, \"Reactivity of
Materials in Aerospace Fluids.\" Typically, testing is done for 48 hours
at the maximum system temperature or 160^o^F whichever is higher.
However, there should be consideration regarding actual exposure
duration and thermal environment. The payload suP/Plier\'s compatibility
data may be used if aP/Proved by RMO. Materials will be considered
compatible with the test fluid if exposure results in no significant
changes in the material and no visible change in color of the test
fluid.

When materials can be exposed to hazardous fluids by a credible single
barrier failure, an engineering evaluation and analysis of test data
will be conducted to demonstrate the acceptability of the configuration.

6.3.6 Materials Offgassing in Habitable Areas

All materials used in habitable flight compartments shall be assessed
per LeR-W0510.046 and meet the offgassing requirements of NASA-STD-6001
by test or analysis. The acceptance criteria is as follows:

For all hardware components, a summation of Toxic Hazard Index (T)
values of all offgassed constituent products (total concentration in
milligrams per cubic meter/Spacecraft Maximum Allowable Concentration)
must not exceed 0.5. Spacecraft Maximum Allowable Concentrations for
Airborne Contaminants are given in JSC 20584.

If a single hardware component is tested or evaluated for toxicity, but
more than one will be flown, the T value obtained for one unit times the
number of flight units must be less than 0.5.

Materials that are evaluated individually shall use the ratings in
MSFC-HDBK-527/JSC 09604 or MAPTIS. The maximum quantity and associated
rating is specified for each material code. The project organization
responsible for the hardware must track the amount of each material
being used to ensure the maximum quantity will not be exceeded.

In addressing EEE parts, past studies have shown that EEE parts covered
by a conformal coating that meets the test requirements of NASA-STD-6001
for offgassing, in the worst case use atmosphere, are acceptable for
offgassing. All EEE parts not conformal coated with a material meeting
the offgassing requirements of NASA-STD-6001 shall be evaluated for
offgassing by conducting NASA-STD-6001 Test 7.

6.3.7 Other Materials Assessments

Other materials and processes items will be evaluated according to the
requirements of NSTS 1700.7B paragraph 209.1b.

# 

# Figure 1. Steel and Aluminum Alloys

> (From MSFC-SPEC-522 Table I)

+---------------------------------+---+---+-------------------------------+
| Table I. High Stress Corrosion  |   |   |                               |
| Cracking Resistance Alloys      |   |   |                               |
+---------------------------------+---+---+-------------------------------+
| ### Steel Alloys                |   |   |                               |
|                                 |   |   |                               |
| [Alloy]{.underline}             |   |   |                               |
| [Condition]{.underline}         |   |   |                               |
+---------------------------------+---+---+-------------------------------+
| Carbon Steel (1000 Series)      |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | B |                               |
|                                 |   | e |                               |
|                                 |   | l |                               |
|                                 |   | o |                               |
|                                 |   | w |                               |
|                                 |   |   |                               |
|                                 |   | 1 |                               |
|                                 |   | 8 |                               |
|                                 |   | 0 |                               |
|                                 |   |   |                               |
|                                 |   | k |                               |
|                                 |   | s |                               |
|                                 |   | i |                               |
|                                 |   |   |                               |
|                                 |   | U |                               |
|                                 |   | T |                               |
|                                 |   | S |                               |
+---------------------------------+---+---+-------------------------------+
| Low Alloy Steel (4130, 4340,    |   | # |                               |
| D6AC, etc.)                     |   | # |                               |
|                                 |   |   |                               |
|                                 |   | B |                               |
|                                 |   | e |                               |
|                                 |   | l |                               |
|                                 |   | o |                               |
|                                 |   | w |                               |
|                                 |   |   |                               |
|                                 |   | 1 |                               |
|                                 |   | 8 |                               |
|                                 |   | 0 |                               |
|                                 |   |   |                               |
|                                 |   | k |                               |
|                                 |   | s |                               |
|                                 |   | i |                               |
|                                 |   |   |                               |
|                                 |   | U |                               |
|                                 |   | T |                               |
|                                 |   | S |                               |
+---------------------------------+---+---+-------------------------------+
| Music Wire (ASTM 228)           |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | C |                               |
|                                 |   | o |                               |
|                                 |   | l |                               |
|                                 |   | d |                               |
|                                 |   |   |                               |
|                                 |   | D |                               |
|                                 |   | r |                               |
|                                 |   | a |                               |
|                                 |   | w |                               |
|                                 |   | n |                               |
+---------------------------------+---+---+-------------------------------+
| 1095 Spring Steel               |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | T |                               |
|                                 |   | e |                               |
|                                 |   | m |                               |
|                                 |   | p |                               |
|                                 |   | e |                               |
|                                 |   | r |                               |
|                                 |   | e |                               |
|                                 |   | d |                               |
+---------------------------------+---+---+-------------------------------+
| HY80 Steel                      |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | T |                               |
|                                 |   | e |                               |
|                                 |   | m |                               |
|                                 |   | p |                               |
|                                 |   | e |                               |
|                                 |   | r |                               |
|                                 |   | e |                               |
|                                 |   | d |                               |
+---------------------------------+---+---+-------------------------------+
| HY 130 Steel                    |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | T |                               |
|                                 |   | e |                               |
|                                 |   | m |                               |
|                                 |   | p |                               |
|                                 |   | e |                               |
|                                 |   | r |                               |
|                                 |   | e |                               |
|                                 |   | d |                               |
+---------------------------------+---+---+-------------------------------+
| HY 140 Steel                    |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | T |                               |
|                                 |   | e |                               |
|                                 |   | m |                               |
|                                 |   | p |                               |
|                                 |   | e |                               |
|                                 |   | r |                               |
|                                 |   | e |                               |
|                                 |   | d |                               |
+---------------------------------+---+---+-------------------------------+
| 200 Series Stainless Steel      |   | # |                               |
| (Unsensitized)                  |   | # |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | l |                               |
|                                 |   | l |                               |
+---------------------------------+---+---+-------------------------------+
| 300 Series Stainless Steel      |   | # |                               |
| (Unsensitized)                  |   | # |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | l |                               |
|                                 |   | l |                               |
|                                 |   |   |                               |
|                                 |   | ( |                               |
|                                 |   | i |                               |
|                                 |   | n |                               |
|                                 |   | c |                               |
|                                 |   | l |                               |
|                                 |   | u |                               |
|                                 |   | d |                               |
|                                 |   | i |                               |
|                                 |   | n |                               |
|                                 |   | g |                               |
|                                 |   |   |                               |
|                                 |   | w |                               |
|                                 |   | e |                               |
|                                 |   | l |                               |
|                                 |   | d |                               |
|                                 |   | m |                               |
|                                 |   | e |                               |
|                                 |   | n |                               |
|                                 |   | t |                               |
|                                 |   | s |                               |
|                                 |   |   |                               |
|                                 |   | o |                               |
|                                 |   | f |                               |
|                                 |   |   |                               |
|                                 |   | 3 |                               |
|                                 |   | 0 |                               |
|                                 |   | 4 |                               |
|                                 |   | L |                               |
|                                 |   | , |                               |
|                                 |   |   |                               |
|                                 |   | 3 |                               |
|                                 |   | 1 |                               |
|                                 |   | 6 |                               |
|                                 |   | L |                               |
|                                 |   | , |                               |
|                                 |   |   |                               |
|                                 |   | 3 |                               |
|                                 |   | 2 |                               |
|                                 |   | 1 |                               |
|                                 |   | , |                               |
|                                 |   |   |                               |
|                                 |   | a |                               |
|                                 |   | n |                               |
|                                 |   | d |                               |
|                                 |   |   |                               |
|                                 |   | 3 |                               |
|                                 |   | 4 |                               |
|                                 |   | 7 |                               |
|                                 |   | ) |                               |
+---------------------------------+---+---+-------------------------------+
| 400 Series Ferritic Stainless   |   | # |                               |
| Steel (404, 430, 440, etc)      |   | # |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | l |                               |
|                                 |   | l |                               |
+---------------------------------+---+---+-------------------------------+
| Nitronic 32                     |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | n |                               |
|                                 |   | n |                               |
|                                 |   | e |                               |
|                                 |   | a |                               |
|                                 |   | l |                               |
|                                 |   | e |                               |
|                                 |   | d |                               |
+---------------------------------+---+---+-------------------------------+
| Nitronic 33 (including          |   | # |                               |
| weldments)                      |   | # |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | n |                               |
|                                 |   | n |                               |
|                                 |   | e |                               |
|                                 |   | a |                               |
|                                 |   | l |                               |
|                                 |   | e |                               |
|                                 |   | d |                               |
+---------------------------------+---+---+-------------------------------+
| A286 Stainless Steel            |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | l |                               |
|                                 |   | l |                               |
+---------------------------------+---+---+-------------------------------+
| AM-350 Stainless Steel          |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | S |                               |
|                                 |   | C |                               |
|                                 |   | T |                               |
|                                 |   |   |                               |
|                                 |   | 1 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   |   |                               |
|                                 |   | a |                               |
|                                 |   | n |                               |
|                                 |   | d |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | b |                               |
|                                 |   | o |                               |
|                                 |   | v |                               |
|                                 |   | e |                               |
+---------------------------------+---+---+-------------------------------+
| AM-355 Stainless Steel          |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | S |                               |
|                                 |   | C |                               |
|                                 |   | T |                               |
|                                 |   |   |                               |
|                                 |   | 1 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   |   |                               |
|                                 |   | a |                               |
|                                 |   | n |                               |
|                                 |   | d |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | b |                               |
|                                 |   | o |                               |
|                                 |   | v |                               |
|                                 |   | e |                               |
+---------------------------------+---+---+-------------------------------+
| Carpenter 20Cb Stainless Steel  |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | l |                               |
|                                 |   | l |                               |
+---------------------------------+---+---+-------------------------------+
| Custom 450 Stainless Steel      |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | H |                               |
|                                 |   | 1 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   |   |                               |
|                                 |   | a |                               |
|                                 |   | n |                               |
|                                 |   | d |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | b |                               |
|                                 |   | o |                               |
|                                 |   | v |                               |
|                                 |   | e |                               |
+---------------------------------+---+---+-------------------------------+
| Custom 455 Stainless Steel      |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | H |                               |
|                                 |   | 1 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   |   |                               |
|                                 |   | a |                               |
|                                 |   | n |                               |
|                                 |   | d |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | b |                               |
|                                 |   | o |                               |
|                                 |   | v |                               |
|                                 |   | e |                               |
+---------------------------------+---+---+-------------------------------+
| 15-5PH Stainless Steel          |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | H |                               |
|                                 |   | 1 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
|                                 |   |   |                               |
|                                 |   | a |                               |
|                                 |   | n |                               |
|                                 |   | d |                               |
|                                 |   |   |                               |
|                                 |   | A |                               |
|                                 |   | b |                               |
|                                 |   | o |                               |
|                                 |   | v |                               |
|                                 |   | e |                               |
+---------------------------------+---+---+-------------------------------+
| PH 15-7 Mo Stainless Steel      |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | C |                               |
|                                 |   | H |                               |
|                                 |   | 9 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
+---------------------------------+---+---+-------------------------------+
| 17-7PH Stainless Steel          |   | # |                               |
|                                 |   | # |                               |
|                                 |   |   |                               |
|                                 |   | C |                               |
|                                 |   | H |                               |
|                                 |   | 9 |                               |
|                                 |   | 0 |                               |
|                                 |   | 0 |                               |
+---------------------------------+---+---+-------------------------------+
| ### Aluminum Alloys             |   |   |                               |
|                                 |   |   |                               |
| [Alloy]{.underline} (Wrought)   |   |   |                               |
|                                 |   |   |                               |
| [Condition]{.underline}         |   |   |                               |
+---------------------------------+---+---+-------------------------------+
| 1000 Series                     | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | A |   |                               |
|                                 | l |   |                               |
|                                 | l |   |                               |
+---------------------------------+---+---+-------------------------------+
| 2011                            | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | T |   |                               |
|                                 | 8 |   |                               |
+---------------------------------+---+---+-------------------------------+
| 2024 Rod, Bar                   | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | T |   |                               |
|                                 | 8 |   |                               |
+---------------------------------+---+---+-------------------------------+
| 2219                            | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | T |   |                               |
|                                 | 6 |   |                               |
|                                 | , |   |                               |
|                                 |   |   |                               |
|                                 | T |   |                               |
|                                 | 8 |   |                               |
+---------------------------------+---+---+-------------------------------+
| 3000 Series                     | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | A |   |                               |
|                                 | l |   |                               |
|                                 | l |   |                               |
+---------------------------------+---+---+-------------------------------+
| 5000 Series                     | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | A |   |                               |
|                                 | l |   |                               |
|                                 | l |   |                               |
+---------------------------------+---+---+-------------------------------+
| 6000 Series                     | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | A |   |                               |
|                                 | l |   |                               |
|                                 | l |   |                               |
+---------------------------------+---+---+-------------------------------+
| 7050                            | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | T |   |                               |
|                                 | 7 |   |                               |
|                                 | 3 |   |                               |
+---------------------------------+---+---+-------------------------------+
| 7075                            | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | T |   |                               |
|                                 | 7 |   |                               |
|                                 | 3 |   |                               |
+---------------------------------+---+---+-------------------------------+
| 7475                            | # |   |                               |
|                                 | # |   |                               |
|                                 |   |   |                               |
|                                 | T |   |                               |
|                                 | 7 |   |                               |
|                                 | 3 |   |                               |
+---------------------------------+---+---+-------------------------------+
| ### Aluminum Alloys             |   |   |                               |
|                                 |   |   |                               |
| [Alloy]{.underline} (Cast)      |   |   |                               |
| [Condition]{.underline}         |   |   |                               |
+---------------------------------+---+---+-------------------------------+
| 319.0, A319.0                   |   |   | ## As Cast                    |
+---------------------------------+---+---+-------------------------------+
| 333.0, A333.0                   |   |   | ## As Cast                    |
+---------------------------------+---+---+-------------------------------+
| 355.0, C355.0                   |   |   | ## T6                         |
+---------------------------------+---+---+-------------------------------+
| 356.0, A356.0                   |   |   | ## All                        |
+---------------------------------+---+---+-------------------------------+
| 357.0                           |   |   | ## All                        |
+---------------------------------+---+---+-------------------------------+
| 380.0, A380.0                   |   |   | ## As Cast                    |
+---------------------------------+---+---+-------------------------------+
| 514.0 (214)                     |   |   | ## As Cast                    |
+---------------------------------+---+---+-------------------------------+
| 535.0 (Almag 35)                |   |   | ## As Cast                    |
+---------------------------------+---+---+-------------------------------+
| A712.0, C712.0                  |   |   | ## As Cast                    |
+---------------------------------+---+---+-------------------------------+

# SECTION 7: Reliability and Maintainability Requirements and Guidelines

# 

7.1 GENERAL REQUIREMENTS

The developer shall plan and implement a reliability/ maintainability
program. Program/Project disciplines, including systems engineering,
hardware design, and product assurance shall include Reliability and
Maintainability (R&M) engineering as an integral part of the design
process. PAI 400 and LeR-P0510.006 should be consulted when planning the
R&M program. This section explains many of the requirements for a major
program. Smaller projects may choose to tailor these requirements to
their needs.

7.2 AP/Plicable Documents

NPD 8720.1 Reliability/Maintainability Policy

NASA-STD-8729.1 Planning, Developing, and Managing an Effective
Reliability and Maintainability (R&M) Program

NASA TM 4322 Reliability Preferred Practices for Design and Test

NASA TM 4628 Recommended Techniques for Effective Maintainability

The above documents are available at [http://www.hq.nasa.gov/office/code
q/q doc.pdf](http://www.hq.nasa.gov/office/code q/q doc.pdf). The NASA
Lessons Learned Information System is available at
<http://envnet.gsfc.nasa.gov/ll/llis/llis.html>

# 

7.3 RELIABILITY, MAINTAINABILITY, AND AVAILABILITY (RAM) ANALYSES

Reliability analyses should be performed concurrently with design, to
indicate areas of Reliability risk, and to promote design improvements
to increase system reliability. Safety critical or Mission-success
critical failures or faults can be designed out of the system or the
hardware can be designed for minimum risk. Other assessments of design
should be performed (concurrently with design process) to determine the
maintainability of the design. Availability analysis should be performed
for long duration missions to optimize levels of reliability,
maintainability, and sparing suP/Port.

1.  Analysis Documentation

Reliability, Availability, and Maintainability Analysis Reports ( e.g.
Reliability prediction and/or trade studies, Maintainability
Assessments, Availability models and analyses, Fault Tree Analysis,
Failure Modes and Effects Analysis, Critical Items Lists, Limited Life
Items Lists and Worst Case Analysis) must include the following:

1.  Purpose, Scope, and limitations

2.  Reference Documentation

3.  Description of system hardware and operation

4.  Relevant Schematic and list of major components analyzed

5.  Ground Rules and Assumptions

6.  Criticality Categories (if FMEA/CIL)

7.  Description of operating environment and/or aP/Plication (if a
    reliability prediction or trade study)

8.  Operating times and Duty Cycle Estimates (if a reliability
    prediction or trade study)

9.  Table of Data inputs. (Failure rates for components if a reliability
    study)

10. Table of Analysis Outputs (Reliabilities, Availability, or
    Mean-time-to-repair or replace for Maintainability assessments)

11. Worksheets for the Analysis

12. Reliability Block Diagram

13. Written description of the Analysis Findings

14. Written description of Changes and Corrective Actions taken to
    mitigate risk.

7.3.2 Failure Modes, Effects, and Criticality Analysis

NASA Payload Classifications and any specific FMEA Requirements for
Payload Carriers should be consulted to determine [if]{.underline} an
FMEA (Failure Modes and Effects Analysis) is required. When an FMEA is
required, a Critical Items List (CIL) should document the Safety
critical and Mission-critical failure modes and their associated
Retention Rationale. Retention Rationale should include information such
as design features or operational workarounds, inspection, testing,
maintenance actions, or Failure history, which indicate that risk has
been minimized. There may be cases when the required data elements for
an FMEA and CIL should be derived from the FMEA Requirements of the
Payload carrier. \[Noted examples are: the FMEA and CIL prepared for a
science payload or experimental facility that will be deployed on the
ISS (International Space Station) or on the NSTS (Space Shuttle). In the
case of the ISS, SSP 30234 is the requirement for the FMEA/CIL
methodology. Tailoring of the SSP 30234 requirement is permitted but
must be coordinated with NASA)\] In general, Methodology should be
consistent with GRC- W0510.060 and acceptable to the NASA organization
responsible for the payload carrier. However, in the case of a facility
or payload to be deployed on the ISS, if there is a conflict between SSP
30234 and GRC- W0510.060, SSP 30234 shall take precedence.

When an FMEA is required, the developer should be sure to:

1.  Assign criticality categories to failure modes as indicated in
    LeR-W050.060 of this document. (Or, as in the case of a payload or
    facility deployed on the ISS: as indicated in SSP 30234)

2.  Address all failure modes that are safety critical and mission
    critical.

3.  Evaluate the mission, determine the required level of analysis, and
    then analyze to the required level of detail: subsystem, assembly,
    or component level.

4.  Address items (a) and (b) below:

    a.  Failure modes and effects totally contained within the boundary
        of the experiment package.

    b.  Failure modes and effects that have an impact on hardware or
        other experiments outside of the experiment package boundary.

The FMEA and CIL shall be documented in suP/Port of required reviews
that are scheduled during the project. Details on the FMEA process may
be found in LeR- W0510.060.

7.3.3 Fault Tree Analysis

In those cases where an FMEA is not required it may be advantageous to
perform a Fault Tree Analysis of the payload design. Fault Tree Analysis
of payloads should be conducted according to LRC- W0510.060.

When a Fault Tree Analysis is performed, the developer should be sure
to:

1.  Define a relevant definition of the undesired top-level event.

2.  Determine the lowest level of the Fault Tree that is required.

3.  Consider intermediate and primary faults associated with hardware,
    command and control, and human interfaces.

7.3.4 Parts Stress Analyses

The analyses shall be performed for all parts at the most stressful
values that result from specified performance and environmental
requirements (e.g. temperature, voltage, vibration, and shock) on the
assembly or component.

7.3.5 Worst Case Analyses

Worst Case Analyses (WCA) shall be performed on all Safety critical and
Mission Critical circuits for primary payloads. For secondary payloads,
worse case circuit analysis must be performed on safety critical
circuits, and can be selectively performed on mission-critical circuits.

The most sensitive design parameters, including those that are subject
to variations that could degrade performance, shall be included in the
analysis.

The analyses shall consider all parameters set at worst case limits and
worst case environmental stresses for the parameter or operation being
evaluated. Depending on mission parameters and parts selection methods,
part parameter values for the analysis typically include the following:
manufacturing variability, variability due to temperature, aging effects
of environment, and variability due to cumulative radiation. The
analyses shall be updated in keeping with design changes and made
available for information upon request.

7.3.6 Reliability Prediction Analysis

Selected reliability predictions shall be performed for secondary and
primary payloads, such that areas of reliability risk are identified,
and recommendations may be made for design improvement, higher quality
level of parts, sparing, or reduction in planned operating time. The
predictions may be trade studies that evaluate alternatives. Reliability
goals may be established for a selected assembly or sub-system of an
experiment, but the objective of the analyses is to improve the design
and not to force the design to meet an absolute reliability goal. (Refer
to LeR-W0510.061)

Reliability predictions can be performed at different levels of detail:
Overall system, subsystem, component, board, and electronic part. The
reliability predictions shall be documented in suP/Port of required
reviews that are scheduled during the project.

7.3.7 Maintainability Assessment

Selected maintainability assessments shall be performed for secondary
and primary payloads that are long duration missions. Areas of
maintainability risk are identified, and recommendations may be made for
design improvement, accessibility, sparing, or reduction in failure
detection or isolation time. The assessments may include estimates of
mean time to repair or replace failed units. Maintainability goals may
be established for a selected assembly or sub-system of an experiment,
but the objective of the analyses is to improve the design and not to
force the design to meet an absolute Maintainability goal. (Refer to
GRC-W0510.061)

Maintainability predictions can be performed at different levels of
detail: Overall system, subsystem, component, or board level. Each
experiment that is a long duration mission shall be evaluated to
determine the aP/Propriate scope of analysis required.

The Maintainability assessments shall be documented in suP/Port of
required reviews that are scheduled during the project.

7.3.8 Availability Analysis

Selected availability analyses shall be performed for secondary and
primary payloads that are long duration missions. Long duration usually
refers to a mission of at least one year, and to a planned operating
time for system components that

exceeds 4000 hours. Availability risk is identified, and recommendations
may be made for design improvement, accessibility, sparing, or reduction
in failure detection or isolation time. The assessment will include an
estimate of inherent or operational availability. A system availability
goal may be established, but the objective of the analyses is to improve
the design and its suP/Portability and not to force design and
suP/Portability to meet an absolute availability goal. (Refer to
LeR-W0510.061)

Availability predictions are usually performed for a system but can be
performed at different levels of detail: subsystem, or major component
level. Each system that suP/Ports a long duration mission shall be
evaluated to determine the aP/Propriate scope of analysis required.

The Availability assessments shall be documented in suP/Port of required
reviews that are scheduled during the project.

7.4 ANALYSIS OF TEST DATA The developer shall fully utilize test
information during the normal test program to assess flight equipment
reliability performance and identify potential or existing problem
areas.

7.4.1 Trend Analyses

The developer shall assess the project\'s component, subsystem and
system reliability and safety risk functions by quantitatively
identifying variables through two types of Trend Analyses (TA):
performance data trending, and PRACA (Problem Reporting and Corrective
Action) data trending.

7.4.1.1 Performance Trending. This trend analysis should be used when
measurement can be made of a condition, or conditions, which are
changing over time in a manner that eventually will cause a piece of
hardware or system to fail. An example of a performance trend would be
the continued decline in performance of an item, that is used by many
space experiment Projects or re-flight projects, to suP/Port mission
requirements over time. The item\'s performance can degrade over time,
especially when it encounters test, storage, launch, and micro gravity
environments.

7.4.1.2 PRACA Trending

This trend analysis includes the tracking and categorization of problems
over time in order to identify trends in the data. These problems may be
for an entire system, subsystem, or any other aP/Propriate level of
aggregation. This technique allows project managers to focus their
attention on the problems that are occurring with the most frequency. An
indication of a concern is when items have multiple problem reports
and/or workmanship defects.

7.4.2 Trending Activities

It is known that the values of certain variables will directly impact a
component or system\'s reliability, even though the exact quantitative
relationship or risk has not been determined. Knowing those measurable
variables (parameters such as hardware stress levels which are functions
of other variables such as pressure and temperature), which directly
affect system or component reliability, these variables can be sampled
over time. The variable values would be examined to see if there is a
pattern of deviation over time (i.e., a trend) from acceptable
performance limits. Selected parameters shall be monitored for trends
starting at component/subsystem acceptance testing and continuing during
the system integration, storage, and prior to launch checkout phases.
The monitoring shall be accomplished within the normal test framework;
i.e., during functional tests, environmental tests, flight acceptance
tests and prior to launch checkout phases.

In this manner, the project manager may be able to predict future
parameter values, or at least estimate the long-term range of values of
these influential variables. In turn, if these parameters are trending
toward hazardous or unacceptable levels, the potential problem can and
should be identified prior to the occurrence of high-risk situations.

The developer shall look for those cases where a distinct trend exists.
For example, there should be an increasing trend in reliability with
successive design changes, and a decreasing trend in open significant
problems reports as time-to-launch decreases.

Trend analysis data shall be reviewed with the operational personnel at
the pre-ship review and prior to launch. Operational personnel shall
continue recording trends throughout the mission life. Trend analysis
data/results and information that list the components and subsystems
assessed for trending shall be kept with the project\'s documentation
and files. A copy of the data and analysis shall be submitted to the
Risk Management Office (0510), where the trend data will be compared
with other GRC projects and systems.

7.5 LIMITED-LIFE ITEMS

Limited-Life items shall be identified and managed by means of a
Limited-Life Plan, which shall be submitted to the Project Assurance
Manager (in the Risk Management Office) for aP/Proval. The plan shall
present definitions, the impact on mission parameters, responsibilities,
and a list of limited-life items, including data elements as follows:
Expected life, required life, duty cycle, and rationale for selection.
The useful life period starts with fabrication and ends with the
completion of the final mission.

The list of limited-life items should include selected structures,
thermal control surfaces, solar arrays and electromechanical mechanisms.
Atomic oxygen, solar radiation, shelf-life, extreme temperatures,
thermal cycling, wear and fatigue should be used to identify
limited-life thermal control surfaces and structure items. Mechanisms
such as batteries, compressors, seals, bearings, valves, tape recorders,
momentum wheels, gyros, actuators, and scan devices should be included
when aging, wear, fatigue and lubricant degradation limit their life.
Records shall be maintained that allow evaluation of the cumulative
stress (time and/or cycles) for limited-life items, starting when useful
life is initiated and indicating the program activity that stressed the
items. The use of an item whose expected life is less than its mission
design life must be aP/Proved by the Project Manager.

7.6 OFF-THE-SHELF COMPONENTS

When using an off-the-shelf component, the developer shall:

Procure the optimal reliability component based on the following:

1.  Acceptable vendor screening program to the project requirements
    (burn-in, thermal cycle and vibration levels)

2.  Acceptable vendor quality control program

For each Component:

Request mean time to failure (MTBF) reliability data. If MTBF is not
available, request a bill of materials for the component and perform a
reliability analysis to estimate the component \'s MTBF by analysis.
Replace high failure rate commercial parts with higher quality
industrial or space grade parts, to meet project and mission
requirements.

AP/Ply conformal coating to components to minimize off gassing and seal
plastic parts.

Cinch all active parts onto boards and stake parts (weight of 0.5 grams
or more) with a staking compound aP/Proved by M&P in Risk Management
Office (0520). This will protect components from launch vibration
movement and avoid broken parts.

All components should be de-rated for electrical, mechanical, thermal
stresses. The de-rating should verify that the actual stresses are
substantially less than the design maximum ratings (design maximum
ratings of components are usually related to the maximum rating given by
the manufacturer, the closer a component is operated to its design
maximum ratings, the greater the probability of failure. Reference to
NASA Reliability Preferred Practice No. PD-ED-1201. (available at
<http://www.hq.nasa.gov/office/code>q/qdoc.pdf) for de-rating
information**.**

7.7 THERMO GRAPHIC MAP/PING

Thermo graphic maP/Ping should be performed on components to
qualitatively assess whether or not all parts are aP/Plied in accordance
with the de-rating requirements of the project.

7.8 MAINTENANCE

The developer shall document the following, as aP/Plicable:

> a\. Estimated system operational availability based on planned
> spares.( If a long duration mission is planned. Long duration means a
> mission time that is equal to or greater than 1 year.)
>
> b\. Repair and replacement policy
>
> c\. Level of replacement
>
> d\. Skill level requirements
>
> e\. Sparing concept
>
> f\. Standardization policy and practice
>
> g\. Diagnostic principles and concepts
>
> h\. Responsibility for payload maintenance
>
> i\. Crew time allocated for both preventive and corrective maintenance
> action
>
> j\. Tool requirements
>
> k\. Accessibility
>
> l\. Planned maintenance activities after shipment

7.9 PREVENTIVE MAINTENANCE ANALYSIS

The developer shall conduct an analysis to determine which items require
a preventive maintenance schedule that will minimize the amount of
experiment down time.

7.10 SPARES REQUIREMENT ANALYSIS

Consistent with the maintenance concept, the developer shall determine
the quantities of spares required, in accordance with the spares
philosophy as follows:

1.  Development Spares. These spares are needed to suP/Port test,
    integration, storage and checkouts up to and prior to launch. The
    quantity for development spares should be determined based on: a)
    Custom-made items (new and in-house design), and b) Items that have
    long lead time.

2.  Operational (flight) Spares. These spares are needed to sustain
    mission operations on-orbit. The quantity for operational spares
    should be determined based on:

    a.  Items that are critical to system operation and mission success,

    b.  Items that have high failure rate/low reliability (as determined
        by vendor MTBF data, reliability analysis, and test data),

    c.  Items that have limited life.

AP/PENDIX 7-A

## Failure Mode Criticality Categories 

1 A single point failure that could result in serious injury, loss of
life, or cause loss of (failure/damage of) flight hardware that is a
part of other carrier payloads or the carrier itself.

1R Redundant items, all of which if failed, could result in serious
injury, loss of life, or cause loss of (failure/damage of ) flight
hardware which is a part of other payloads or the carrier itself.

1S A single failure point of a system component designed to provide
safety or protection capability against a potentially hazardous
condition or event or a single failure point in a safety or hazard
monitoring system that causes the system to fail to detect, or operate
when needed during the existence of a hazardous condition that could
lead to loss of flight or ground personnel or carrier. (fire
suP/Pression, medical hardware, etc.)

1SR Redundant components designed to provide safety or protection
capability against a potentially hazardous condition or event, all of
which if failed could cause the system to fail to detect, or operate
when needed during the existence of a hazardous condition that could
lead to loss of flight or ground personnel or carrier; OR redundant
components within a safety or hazard monitoring system, all of which if
failed could cause the system fail to detect, or operate when needed
during the existence of a hazardous condition that could lead to loss of
flight or ground personnel or carrier.

2 A single point failure that could result in a total loss of capability
to perform science experiments suP/Ported by the system under analysis.

2R Redundant items, all of which if failed, could result in a total loss
of capability to perform science experiments suP/Ported by the system
under analysis.

3.  A single point failure that could result in a partial loss of
    capability to perform science experiments suP/Ported by the
    Combustion Integrated Rack.

3R Redundant items, all of which if failed, could result in a partial
loss of capability to perform science experiments suP/Ported by the
Combustion Integrated Rack.

4 All others.

[]{#SECTION_8 .anchor}SECTION 8 - QUALITY ASSURANCE REQUIREMENTS

8.1 GENERAL REQUIREMENTS

The developer shall maintain an effective Quality Assurance Program,
which assures that all system and science quality requirements are met
through control of operations, processes, procedures, testing, and
inspection. See [Section 10](../srg10.htm) of the document for
requirements of the Software Product Assurance Program. The QA Program
shall:

1.  Demonstrate recognition of the quality aspects of the project and
    the importance of an organized aP/Proach to satisfy our customers.

```{=html}
<!-- -->
```
1.  Ensure quality requirements are determined and satisfied throughout
    all phases of the project. This shall begin at the design and
    development procedures phase, and continue through fabrication,
    processing, assembly, inspection, test, packaging, shiP/Ping,
    storage, maintenance, field use, flight and post-flight, as
    aP/Plicable.

2.  Ensure that quality considerations are fully included in all systems
    and all operations.

3.  Provide for the detection of potential problems, which could result
    in less than satisfactory performance.

4.  Provide timely and effective corrective action.

    1.  AP/Plicable Documents

        NPD 8730.3 Quality Management System Policy

        NPD 8070.6 Technical Standards

        NPD 8730.1 Metrology, Calibration & Measurements

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

        NASA-STD-8739.3 Requirements for Soldered Electrical Connections

        NASA-STD-8739.4 Requirements for Interconnecting Cables and
        Crimping

        NASA-STD-8739.7 Requirements for Electrostatic Discharge Control

        IPC-D-275 Design Standard for Rigid Printed Boards and Rigid P/B
        Assemblies

        ASME Y14.5 Y 14.5 Dimensioning and Tolerances

        Most of these documents are available at:

        \<<http://www.hq.nasa.gov/office/codeq/doctree/qdoc.pdf>\>

    ```{=html}
    <!-- -->
    ```
    1.  ORGANIZATION

The developer shall make functional assignments to implement each
element of the quality program. Personnel performing quality program
functions shall have sufficient, well-defined responsibilities and the
organizational freedom to identify and assess problems, and to
recommend, track and review solutions. The effectiveness of quality
program functions and the ability of assigned personnel to objectively
assess, document and report findings shall be maintained during all
phases of the project and shall not be reduced by other considerations,
such as the influence of engineering changes, rework or rescheduling.
The developer shall designate an individual who is responsible for
directing and managing the Quality Assurance Program.

2.  CONFIGURATION MANAGEMENT AND VERIFICATION

Please refer to Section 10.5 of this document for a discussion of
software configuration management. All documents, drawings and
revisions, which affect the system, shall be kept under configuration
control. A Configuration Management Plan shall be developed which will
specify responsibilities, and as a minimum, address the following:

a.  Identification of configuration items, which will be base, lined and
    controlled, including specifications and procedures.

b.  Formation of a Configuration Control Board (CCB) to review base
    lined items, and to review changes to controlled items. The
    complexity of the operations of this board, along with
    responsibilities, shall be specified in the Configuration Management
    Plan.

c.  The completion of an as-built list, which will document the final
    versions of the components contained in the flight system, along
    with a verification that all testing and changes have been properly
    completed in both documentation and the system.

d.  Files of all changes made to the system once the configuration item
    have been base lined. The System configuration items shall be placed
    under configuration control and base lined at the earliest possible
    time. This will occur at the time an assembly is considered to be in
    a flight-like configuration. This may be at the engineering,
    functional, prototype or proto-flight model stage, but in all cases,
    the system shall be base lined by CDR. The responsible project
    configuration control personnel will assure that documents are kept
    current, and when changes are made, they are made promptly and
    include changes to all associated documentation and the system. The
    Configuration Control Plan will also outline requirements of the
    system, which will assure that only the latest drawings, including
    all changes, are used for the fabrication, assembly, testing and
    inspection of all components. Inspection records shall indicate the
    revision level with which the item has been fabricated, inspected
    and/or tested. Evidence shall be provided specifying compliance with
    the as-built documentation as a basis for acceptance.

    1.  IDENTIFICATION AND TRACEABILITY

A system identification and tracking procedure shall be established
which identifies each part by a unique part or type number, consistent
with the configuration management system. The configuration management
system shall be capable of retrieving the identification and
serialization record at the subassembly level. Beginning at the
subassembly level and continuing through the end system, the procedure
shall be capable of tracing backwards to the originating subassembly and
forward to the location of the subassembly at any given level of
process, assembly or test. Identification and serialization data lower
than that for subassemblies shall be maintained in the manufacturing and
processing records, and shall contain part and material date code, lot
number and manufacturer information. Part information for commercially
bought subassemblies should be obtained if available.

2.  PROCUREMENT REQUIREMENTS

All procurement shall include the aP/Propriate quality assurance
requirements for the task. A risk management survey to gain confidence
in the manufacturers ability to produce acceptable systems shall be
performed. This survey may use information such as past history,
inspection and test results, suP/Plier rating and audit results.

If inspections, tests or processes need to be verified at the
manufacturer/suP/Plier\'s plant, the procurement document shall so
indicate. Examples of when such inspections, tests or verifications are
needed include:

a.  When in-process or end-item controls have an important impact on the
    performance or quality of the product, and the quality cannot be
    determined solely by inspection or tests at the developer\'s
    facility.

b.  The environment or test equipment needed to perform any verification
    is not feasibly or economically available at the developer\'s
    facility.

c.  Past history of the developer shows risk.

d.  Qualification testing is to be performed by the developer.

    1.  Government Source Inspection

All purchase orders shall include a statement, which assures that the
Government has the right to inspect any or all of the work included in
the purchase order at the developer\'s plant.

1.  RECEIVING INSPECTION

A receiving inspection system shall be developed and implemented which
ensures purchased components are in compliance with procurement
documents.

The receiving inspection system shall verify that:

a.  Documentation is reviewed to verify that components are in
    compliance with purchase requirements.

b.  Inspections and/or tests are performed in accordance with written
    procedures for selected components to verify performance.

c.  Verification and acceptance of limited-life and age control data and
    documentation are maintained.

d.  Identification of acceptance or nonconformance status of components
    and records when released from receiving inspection.

e.  Maintenance of receiving inspection and test records, including
    copies of documents for three years after completion of the mission.

f.  Implementation of protective measures for cleanliness, electrostatic
    discharge, handling, shiP/Ping, and storage.

    1.  CONTROL OF FABRICATION ACTIVITIES

A Fabrication and Assembly Flow Plan shall be developed and implemented
that covers operations from start of fabrication to end item completion.
Inspection and test points, and all special processes to be used shall
be included. The plan shall be submitted for review to the Project
Manager and Project Assurance Manager (RMO 0510) no later than PDR. This
Plan assists both the Project Managers in planning activities, along
with reviewing the process to help correct systemic problems not readily
evident without the Flow Plan. Controls shall ensure that only
conforming components are released and used during fabrication.

8.7.1 Fabrication and Inspection Requirements

Suitable fabrication and inspection requirements shall be used based on
the complexity and expected environment of the project. GRC has
determined that the following requirements are aP/Plicable for flight
systems, and that personnel performing these functions must have the
qualifications to meet the intent of these documents: NASA-STD-8739.1,
NASA-STD-8739.3, NASA-STD-8739.4, and IPC-D-275. All drawings shall meet
the requirements of ASME Y14.5. Only released prints, aP/Proved in
accordance with the configuration control plan, shall be used for the
manufacture of the system.

8.7.2 Training and Certification for Personnel

A system shall be in place that assures only qualified personnel will be
permitted to perform the work. The Project Manager has the
responsibility and authority to assure only qualified personnel are
used.

8.7.3 Evaluation and Control of Process Specifications and Procedures

All specifications and procedures for processes shall be evaluated to
ensure compliance to project requirements. Special processes, with which
the quality cannot be ensured by inspection alone, shall be given
special attention as to the controls and methods of verifying the
adequacy of the process. The Quality Department shall assure all
processes are adequate for the stated purpose.

8.7.4 Bonded Storage

The developer shall maintain a controlled bonded storage area, which is
capable of storing flight material, parts and assemblies. The area shall
have controlled access aP/Plicable to the type of system being held, and
shall have a documentation system adequate to identify and track the
flow of parts in and out of bonded storage. Bonded storage shall be
capable of segregating materials, assemblies, qualified components,
accepted systems, limited-life items and nonconforming components.

8.8 CONTAMINATION CONTROL

The quality assurance personnel shall assure compliance to the
requirements of the Contamination Control Plan during all phases of the
program.

1.  General Requirements

A contamination control plan is required for all experiment systems. The
contamination control requirements for defining and implementing a
contamination control procedure aP/Plicable to the system are described
in this section. The system procedure generally consists of first
defining the specific cleanliness requirements and setting forth the
aP/Proaches to meeting them in a Contamination Control Plan (CCP), and
then implementing the control and verifying activities specified by the
plan.

Contaminants include all materials of molecular or of particulate nature
whose presence degrades system performance. The source of the
contaminant materials may be the system itself, the test facilities, and
the environments to which the system is exposed.

8.8.2 Contamination Control Plan

The developer shall prepare a Contamination Control Plan (CCP) that
describes methods for controlling contaminants and verifying that they
have been prevented or abated such that the hardware will meet
performance requirements. A preliminary plan shall be evaluated as part
of the PAP and Project Management and the Project Assurance Manager of
the Risk Management Office (RMO). The final CCP shall also be submitted
for aP/Proval. Analyses, procedures, standards, processes, and
specifications referenced in the CCP shall be available for review at
the developer's facility.

The CCP shall define a contamination allowance for performance
degradation of contamination-sensitive systems such that, even in the
degraded state, the system will meet its mission objectives. Allowable
contamination levels are either those necessary to ensure that the
system will meet its performance requirements or those necessary to meet
mission contamination control considerations, whichever is more
stringent. The allowance and the rationale for allowable levels shall be
described in the CCP and shall serve as a basis for the measures to be
taken ton control contamination. The contamination allowable shall be
assessed in a timely fashion such that results can be used to assess the
adequacy of and, if necessary, to modify the design of the system.

The CCP shall describe methods for controlling contamination and for
ensuring that the contamination allowance is not exceeded. It shall
identify the controls, process, inspections, productions, test,
assembly, methodology, analyses, and documentation necessary to
measuring and maintaining the levels of cleanliness required during the
various phases of the system's lifetime.

The CCP shall identify controls to be exercised in preparing test
facilities such as the thermal-vacuum chamber and fixtures. It shall
also identify the operational procedures that will be followed to
minimize the contamination hazard during various test phases, such as
from pump down through return to ambient conditions. AP/Propriate
pretest measurements, monitoring methods to be used during the tests,
and post-test measurement shall be identified.

Bake outs of hardware exposed to payload bay must be considered. When
required, the parameters of such bake outs (e.g., temperature, duration,
pressure) must be individualized depending on materials used, the
fabrication environment, and the established contamination allowance.

The contamination potential of material and equipment used in cleaning,
handling, packaging, tent enclosures, shiP/Ping containers, and bagging
(e.g., antistatic film materials), shall be considered. Clean room
standards shall also be included in the processes.

8.9 ELECTROSTATIC DISCHARGE CONTROL

The developer shall develop, implement and maintain a program to control
Electrostatic Discharge (ESD) for any components susceptible to damage
by ESD in accordance with NASA-STD-8739.7All personnel who will have
access to ESD sensitive components shall be trained to be ESD methods,
and in the proper handling of sensitive components.

8.10 PROBLEM REPORTING AND CONTROL

The developer shall operate a documented problem reporting analysis,
corrective action, and management concurrence system for failures and
nonconformance's. The system shall include documentation of problem,
trace ability of material or part, disposition of problem, root cause
corrective action, segregation of discrepant material, verification of
corrective action, and trending to help prevent similar discrepancies.

8.10.1 Review Boards

A review board shall be operated with the responsibility of reviewing
all problem reports. The board shall include the following:

a.  Quality or reliability representative (chairman).

b.  Engineering representative.

c.  Project manager or his representative (necessary for failure board
    only).

d.  Government representative, if other members are contractor
    personnel.

The board shall have the authority and responsibility to:

a.  Determine the disposition of the submitted problem.

b.  AP/Prove all standard repair procedures.

c.  Ensure that remedial and preventative actions are properly
    addressed.

d.  Ensure that excessive repairs do not compromise the components
    reliability and quality.

8.11 ALERT INFORMATION

The project is required to review NASA Parts Advisories and GIDEP Alerts
to respond to RMO and review teams as to the aP/Plicability of the
problem to project systems, location of affected system, and disposition
for design reviews.

The project/developer shall prepare parts advisories or alerts and
submit, through the GIDEP system, alerts on problems within the scope of
the advisory alert, and safety system and shall submit a copy of the
alert to the Glenn Research Center (GRC) Project Manager and Project
Assurance Manager (RMO 0510) for information. The

-   [GIDEP Home Page](http://www.gidep.corona.navy.mil/):
    [http://www.gidep.org](http://www.gidep.org/)

-   [Alert Search](http://nppp.jpl.nasa.gov/dmg/jpl/loc/alr/alerts.htm)
    Program are available:
    [http://gidep-data.corona.navy.mil](http://gidep-data.corona.navy.mil/)
    (requires username and password. GIDEO representative in
    0520/Quality Assurance Office can assist with this)

8.12 CONTROL OF ASSEMBLY AND INSPECTION/TEST ACTIVITIES

The project/developer shall plan and conduct an assembly, inspection and
test program, which controls fabrication, assembly and testing of flight
systems, and demonstrates that drawing and specification requirements
are met. Inspections and tests should be performed on components before
they are installed in the next level of assembly, based upon complexity
and risk associated with the system. Each inspection and test shall be
traceable to the person performing the task. Quality assurance shall
verify that all manufacturing documentation processes, procedures, and
specifications are available prior to the build.

All work and inspections performed on flight systems shall be conducted
with the use of Project Manager aP/Proved procedures and instructions.
Proper planning shall be done to ensure orderly and timely inspections
are performed at all levels of assembly and tests deemed necessary, and
to allow coordination and Project Manager aP/Proval of assembly, test
and inspection procedures.

An early planning effort is necessary to accurately schedule adequate
assembly, inspection and test operations. Once the plan is agreed to by
the Project Manager and the RMO PAM, factors such as cost and schedule
should not be considered viable reasons for deviating from the plan, and
as such requires the cognizance of division level, SED and RMO
management. The assembly, inspection and test plan should be aP/Proved
by the Project Manager by Conceptual Design Review, but no later than
Requirements Design Review.

Please refer to Sections [10.7.3](#Software_Testing) through
[10.7.3.3](#Software_Test_Reports) for software testing requirements.

8.12.1 Assembly, Inspection and Test (AIT) Procedures

AIT procedures shall be written for all flight system operations. The
degree of detail in the procedures shall be commensurate with the
complexity of the operation. Drawings may stand alone as assembly
procedures as aP/Propriate.

Procedures shall include, as aP/Plicable, revision level of the
document, the nomenclature of the article, instructions for qualified
personnel to perform the work, characteristics to be inspected or
tested, accept/reject criteria, and special considerations regarding
handling, measuring, testing, equipment, standards, safety and
environment. Quality assurance shall verify proper inspection and
testing criteria are included in the procedures during the QA review of
processes procedures and specifications.

8.12.2 Inspection and Test of Stored Limited-Life Hardware

A test plan shall be developed which adequately assures that
limited-life items stored or stocked have not been degraded or damaged
during their storage. The plan shall address proper handling, including
environmental conditions, to mitigate damage or prolong life, and
testing to assure the stored items meet required specifications.
Limited-life items not meeting the requirements set forth in the plan
shall be considered nonconforming, and handled in accordance with
paragraph 8.10.

8.12.3 Records of Inspections and Tests

Records shall be maintained of all inspections and tests as evidence
that all operations have been performed, objectives have been met, and
the end-item is fully verified. Logbooks shall be kept for each, based
on the complexity of the component. As the product is integrated, the
next higher-level assembly documentation shall reference all integrated
by positive configuration identification. The logbooks shall document
all actions taken on the component, and shall provide for easily
accessible total operating time of the component under control. Records
shall be kept for 3 years after the mission is complete.

8.13 CONFIGURATION VERIFICATION

The developer\'s Configuration Management (CM) System shall be capable
of assuring that as-built hardware conforms to the design documentation.
Quality Assurance will provide assessment of the CM system at
aP/Propriate intervals during construction of the engineering and flight
systems. Formal verification and sign-off that flight as-built systems
conform to as-designed documentation shall be the responsibility of the
developer, unless otherwise stated in the Project Assurance Plan.

8.14 HANDLING, PRESERVATION, MARKING, PACKAGING, PACKING AND
TRANSPORTATION

The developer shall develop and implement procedures for handling,
preservation, marking, packaging, packing and transportation to properly
protect and identify all flight systems and ground suP/Port equipment
during build-up, handling, storage, testing, shiP/Ping and turn-over at
integration.

8.15 CONTROL OF GOVERNMENT PROPERTY (AP/PLIES TO OUTSIDE CONTRACTORS)

When suP/Plied in accordance with the provisions of the contract,
government property shall be controlled and accounted for by the
contractor. The contractor shall be responsible for, as a minimum:

a.  Upon receipt, examine components to detect damage that may have
    occurred in transit.

b.  Inspect for quantity, completeness of shipment and proper shiP/Ping
    documents.

c.  Provisions for protection, maintenance, calibration, periodic
    inspection and controls necessary to prevent damage or deterioration
    during handling, storage, installation or shipment.

d.  Maintenance of records concerning all actions performed by the
    contractor for 3 years after the mission is complete.

Any property that is found damaged, malfunctioning or otherwise
unsuitable for use shall be processed in accordance with government
procedures and paragraph 8.10. The property shall not be disposed of,
repaired, reworked, replaced, or in any way modified unless such actions
are authorized by or prior aP/Proval of Glenn Research Center\'s Project
Manager.

8.16 GOVERNMENT OR PRESHIP ACCEPTANCE

Prior to GRC shipment of, or acceptance by GRC of systems, GRC RMO shall
ensure that all deliverable end-items are in accordance with the
requirements, and that the following GRC required Acceptance Data
Package is complete, which includes the following:

a.  As-built Configuration List in accordance with [Section
    8](#SECTION_8).

b.  List of parts used in accordance with [Section 5](#SECTION_5).

c.  List of Materials and Processes used in accordance with [Section
    6](#SECTION_6).

d.  Log Books, including total operating and repair, times, and cycle
    records.

e.  Status of all verification items with a list of open items and
    rationale for the items being open.

f.  Listing and status of Limited-Life items.

g.  Results of Final Mission Simulation Test.

h.  Listing and status of all nonconformance, failure or problem
    reports.

i.  Listing of waivers/deviations affecting integration, safety and
    mission success.

j.  Cleanliness certification

k.  Certification of software acceptance in accordance with [Section
    10](#SECTION_10), Software Acceptance.

l.  The Acceptance Data Package shall be delivered to GRC in accordance
    with the project schedule.

**8.17 AUDITS AND REPORTS**

To ensure compliance with the assurance provisions of the PAP,
developer\'s assurance organization shall audit and/or monitor the
assurance efforts of the in-house or contracted effort including those
of subcontractors and suP/Pliers. To verify the effectiveness of the
performance assurance systems, each audit shall include examination of
documentation (process, procedures, analyses, reports), operations, and
products. The audit schedule shall be based on the following:

a.  Criticality of items being procured as identified by Failure Modes
    and Effects Analyses (FMEA), a Critical Items List (CIL), or by
    other information,

b.  SuP/Plier history,

c.  Known problems, such as Alerts,

d.  Remaining period of contract performance.

An audit report shall be submitted to management with recommendations
for correction of deficiencies. Management action shall be taken to
ensure that corrections have been implemented. The audit report shall be
available for information at the developer\'s facility. A summary of the
audit report shall be submitted as part of the Assurance Status Report
(1.4).

[]{#SECTION_9 .anchor}Section 9 -Continuous Risk Management

9.1 Overview/Introduction

Continuous Risk Management is defined as an engineering management
practice with processes, methods, and tools for managing risks in a
project. It provides a disciplined environment for proactive decision
making to:

-Assess continually what could go wrong (risks);

-Determine which risks are important to deal with;

-Implement strategies to deal with those risks; and

-Assure and measure the effectiveness of the implemented strategies.

9.2 References

# NPG 7120.5A, Program and Project Management Process and Requirements

NPG 8705, Risk Management Procedures and Guidelines

GRC BMS Procedure CLP 2.9 Risk Management

GRC Continuous Risk Management Implementation Plan

9.3 Purpose

In accordance with the above-referenced documents, each
program/project/facility (P/PF) at Glenn Research Center must address
and implement Continuous Risk Management (CRM). The methodology of
implementation will be unique for each P/PF. The purpose of this
document is to provide an overview of the steps that must be
addressed/performed to ensure adequate CRM activities are incorporated
into the P/PF.

9.4 Implementation

Implementation of CRM involves six steps as discussed below. Each P/PF
is responsible for defining and implementing a means of accomplishing
each of the six steps. The GRC Risk Management Office is chartered to
provide a wide range of technical assistance in the CRM process, from
consultation/facilitation to extensive training and implementation
activities.

9.4.1 Identify Risks

Identification of risks is the process of transforming uncertainties and
issues about a P/PF into distinct (tangible) risks that can be described
and measured. Each P/PF shall identify aP/Plicable risks at a time as
early as possible in their respective life cycle. The goal of risk
identification activities is to search for and locate risks before they
become problems.

9.4.1.1 Risk Statements

Each identified risk shall be written as a Risk Statement, which
consists of two parts: a Condition that exists and a Consequence, which
occurs due to the Condition. Every Risk Statement must contain
[both]{.underline} a Condition and a Consequence.

9.4.1.2 Context

Each Risk Statement shall contain Context which consists of additional
information that is necessary to understand the full meaning of a Risk
Statement (i.e. additional project information, circumstances under
which the risk occurs, timeframe of occurrence, and other terms needed
to explain the risk).

9.4.2 Analyze Risks

Analysis of risks is the process of examining the risks in detail to
determine the extent of the risks, how they relate to each other, and
which ones are the most important. The goal of risk analysis is to
convert risk data into decision-making information.

9.4.2.1 Evaluate

Each identified risk shall be evaluated for its respective impact,
probability, and timeframe for mitigation. There are many tools
available to perform this task that range from simple to complex
depending on the number and complexity of the respective P/PF risks.

9.4.2.2 Classify

Once the P/PF risks that have been evaluated for impact, probability,
and time frame for mitigation, they should be classified into
aP/Propriate groups (i.e. management, technical, operations, and others
as needed) to assist in the mitigation process.

9.4.2.3 Prioritize

# Once classified, the P/PF risks can now be prioritized to assist in the determination of resource aP/Plication, mitigation methods, and other tracking methods.

9.4.3 Planning

Planning is the process of deciding what, if anything, should be done
about a risk or set of related risks. The goal of planning is to
translate risk information into decisions and mitigating actions (both
present and future), and implement those actions. There are four types
of mitigating actions that can be taken: research, accept, watch, and
action plan.

9.4.3.1 Research

Research is selected as a mitigating action if additional information is
needed to determine the full effect of a risk on a P/PF.

9.4.3.2 Accept

# Accept is selected as a mitigating action if the severity or probability associated with an individual risk (or a set of risks) is acceptable to a P/PF with no further actions required.

9.4.3.3 Watch

Watch is selected as a mitigating action, if there is data/information
that needs to be monitored to determine if a risk (or set of risks) will
occur.

9.4.3.4 Action Plan

Action plan is selected as a mitigating action if specific actions must
be taken to mitigate the risk (or set of risks).

9.4.4 Tracking

Tracking is the process in which risk status data is acquired, compiled,
and reported. The goal of tracking is to monitor risk indicators and
mitigation actions. AP/Propriate risk metrics should be selected to
provide meaningful information to enable more informed control decisions
by the P/PF.

9.4.5 Control

# 

# Control is the process that takes status reports of the tracking metrics for the P/PF risks and decides what to do with the risks based on the reported data.

# 

# 9.4.6 Communication and Documentation 

Communication and documentation is the process in which risk information
is conveyed between all levels of a P/PF team, Communication and
documentation throughout all levels of the P/PF is critical to the
success of CRM.

[]{#SECTION_10 .anchor}SECTION 10 - SOFTWARE ASSURANCE

10.1 GENERAL REQUIREMENTS

A Software Assurance program shall be established in accordance with

NASA-STD-2201-93 (Software Assurance Standard) or another standard of
equal

or greater measure that has been agreed upon by both program management
and Software Product Assurance. The Standard will assure conformance of
a given software system to established requirements, development
methodologies, and standards.

Software Assurance (SA) is a technical discipline that assures the
safety, reliability, and quality of a given software system. According
to the NASA Software Assurance Guidebook (SMAP-GB-A201), \"software
assurance is the planned and systematic set of activities that ensures
that software processes and products conform to requirements, standards,
and procedures. \'Processes\' include all of the activities involved in
concept formulation, specifying, designing, developing, enhancing, and
maintaining software; \'products\' include the software, associated
data, its documentation, and all suP/Porting and reporting paperwork.\"

SA is not an organization. It is one of three components involved in the
entire Software Development process; the other two being software
management and software engineering. Software management involves the
planning, controlling, and directing of the software project. Software
engineering consists of analyzing requirements, development of designs,
writing code, and structuring of databases. Software assurance helps the
management and engineering efforts result in a product that meets all
its requirements. All three must work together to help ensure that a
safe, reliable, and high quality product are created.

10.1.1 Roles and Responsibilities

The SA program shall be the combined responsibility of the GRC Project
Manager, project software engineer(s), and the independent SA engineer
from the NASA GRC Office of Safety and Mission Assurance (OSAT) assigned
to the project.

Table 10-1 lists the major SA activities to be performed as well as the
personnel charged with the responsibility for each activity.

10.1.2 Scope of Software Assurance Program

The SA program shall encompass flight software, ground suP/Port system
software, post mission operations software and any other software that
is related to flight mission operations such as test, simulator and
ground software. Firmware shall be treated as software for development
and sustaining engineering.

As a minimum, the SA program shall consist of software engineering,
software safety, software reliability, software quality assurance,
software configuration management, nonconformance reporting and
corrective action, performance verification, and software certification.

The SA program will assure that software is developed with a systems
perspective and that the software effort is closely coordinated with all
project disciplines.

10.1.3 Software Assurance Plan

The SA program shall be implemented through the development of a
Software

Assurance Plan created for each project. These plans shall completely
define the SA program and establish procedures for performance of SA
activities on each individual project. The SA plan shall describe in
detail the specific activities to be performed by project management,
software engineering, and software assurance engineering in order to
assure that a given software system meets its requirements. The plan
serves as a contract or agreement between project management and the
Office of Safety Assurance Technologies (OSAT) concerning the software
management and assurance activities.

Unless another standard is aP/Proved, this plan shall be developed in
accordance with NASA-DID-M400, located in NASA-STD-2100-91, but may be
tailored with aP/Proval of the NASA GRC Project Manager and concurrence
of the SA engineer.

As a minimum, the SA plan shall contain the methodologies for reviews of
documentation and source code, performance verification, configuration
management assurance, and maintenance of records. This plan may be a
\"stand alone\" document or may be a section of the Product Assurance
Plan. In either case, the Software Assurance Plan shall be considered a
part of the overall Product Assurance Plan described in Section 1.2 of
this document.

10.1.4 Software Development Requirements

This program shall be in effect throughout the life of the project,
beginning with requirements definition and continuing into the
sustaining engineering phase. The SA program shall be coordinated with
the hardware and system assurance programs established to meet the rest
of the requirements of this document. The following items shall be
addressed during the establishment of the software development program.
The results shall be captured in the Software Management Plan, whether
the plan is stand alone or part of the Project Management Plan Document.

a.  The software to be developed, and all associated documentation.

b.  The management structure and responsibilities of the organizations
    that are to develop and assure the software, and their relationship
    to the hardware and flight systems development activities of the
    project.

c.  The Software Development Life Cycle (SDLC) that will be followed by
    the project in the software engineering process. See section
    10.1.4.1 for further discussion of the SDLC.

d.  The software requirements development and control process.

e.  The software design and implementation plan/procedures.

f.  The software performance verification process, including the various
    levels of testing to be performed, pass/fail criteria, regression
    testing, test reporting, test site/equipment configuration
    management, etc.

g.  The software configuration management/control process, including the
    procedures for identifying and maintaining proper revisions/versions
    of software and suP/Porting documentation.

h.  The software maintenance or sustaining engineering process.

i.  The SA process and its aP/Plication to the software to be developed.

j.  Portions of software deemed more \"critical\" than other portions
    require different management and assurance practices, such as
    software hazard analyses. Any such software and SA practices shall
    be documented.

10.1.4.1 Software Development Life Cycle

Each project shall develop and maintain software in accordance with a
defined process. A software development process consists of the
activities that must be performed, the specific products that result
from these activities, and the reviews, inspections, and audits that are
held during, and at the conclusion of, these activities.

The process that is to be followed is commonly called the Software
Development Life Cycle (SDLC). This SDLC and its associated activities
should be captured in a Software Development Plan or as part of the
Software Management Plan.

An SDLC breaks down the process into major phases: conceptual analysis;
requirements definition; preliminary design; detailed design;
implementation (coding and unit testing); integration testing;
acceptance and delivery; and maintenance and sustaining operations.
Specific documents are prepared, and reviews or audits are held during
or at the end of each phase.

Various software development processes or life cycles can be selected by
the project. The traditional \"waterfall\" aP/Proach, as shown in figure
10.1, begins with the definition of the system and software
requirements, proceeds through design and coding phases, and concludes
with increasingly comprehensive test activities. However, the waterfall
model does have some problems. In many situations, it may not be
possible to completely define the software requirements at the beginning
of the software development effort. Another problem is that the user
only receives the software at the end of the complete and lengthy
development process; the user may need partial capability to test
electrical boards, etc.

Other software development processes or life cycles have been created to
address the above problems. One alternative is the Prototyping Software
Life Cycle, shown in Figure 10.2. With this process, the most important
and critical software requirements defined to the extent possible. A
\"quick\" design addressing these requirements is prepared and a rapid
prototype is coded and tested. The purpose of the prototype is to gain
information about the total requirements and confidence in the
correctness of the design. After confidence in the requirements and
design aP/Proach is achieved by the prototyping, the final software
would be developed using a process similar to the waterfall aP/Proach.

Some disadvantages exist with the prototyping aP/Proach. There is a
tendency to ignore documentation preparation in early phases. This means
that the later phases often do not receive a full transfer of
information from the early phases; therefore the life cycle suP/Port is
made more difficult. Another disadvantage is an incompatibility with a
formal review and audit procedure. Measuring whether a milestone has
been fully achieved would be difficult. Yet another disadvantage is that
there is a tendency for difficult problems to be pushed into the future
so that the initial promise of the first prototypes is not met by
subsequent releases.

The Spiral Model of software development, shown in Figure 10.3,
encompasses

the best features of both the traditional and prototyping life cycles.
The spiral model defines four major activities within its life cycle:
planning; risk analysis; engineering; and customer evaluation. The model
is followed from the center of the spiral in a clockwise direction. Risk
analysis is performed in each spiral immediately prior to prototyping of
the software. Once the operational prototype is obtained in the
outermost spiral, the process becomes more of a traditional waterfall
aP/Proach.

The spiral model is regarded as the most realistic aP/Proach to software
development for large scale or complex software systems. However, it can
have disadvantages as well. The risk analysis phase of the model is
critical; an error made, or risk omitted, at this stage can lead to
numerous defects and failures at later stages. The software engineer
must be accomplished at risk analysis to avoid these problems.

10.1.4.2 Software Development Life Cycle Summary

No SDLC model will be suitable for every project. Projects that will
have smaller, less complex software systems will most likely use some
form of the Prototyping Model. Projects with safety critical or complex
software systems should use either the traditional waterfall model, or
the spiral model.

The decision as to which model is aP/Propriate for a given project shall
be made by the project with concurrence from the SA engineer.

10.1.5 AP/Plicable Development Standards

Once chosen and agreed to, all aP/Plicable standards (i.e. language,
documentation, OOD, etc.) shall be adhered to throughout the entire
software development life cycle. If necessary, a deviation to these
standards can be obtained by written agreement between the project and
the Office of Safety and Mission Assurance via the PAP or S/W Assurance
Plan. The configuration management requirements of section 10.5 and the
nonconformance reporting and corrective action requirements of section
10.6 shall aP/Ply to all the software within the scope of the SA
program. Any significant modification to any portion of pre-existing
software shall be subject to the assurance provisions of this document.

10.1.6 Project Documentation

Each project shall produce documentation in suP/Port of the software
development effort. As required by NMI 2410.10 (NASA Software
Management, Assurance, and Engineering Policy), the documentation
requirements contained in NASA-STD-2100-91, or similar agreed upon
standard that meets or exceeds the intent of NASA-STD-21000-91, shall be
used in producing the software documents. The following documents, as a
minimum, shall be produced and delivered in suP/Port of the software
development effort for any given project.

> \* Software Management Plan (SMP) \[Reference Section 10.1.4 of this
> document\]

\* Software Assurance Plan (SWAP) \[Sec. 10.1.3\]

\* Software Configuration Management Plan\* (SCMP)\[Sec. 10.5\]

\* Software Requirements Specification (SRS) \[Sec. 10.11\]

\* Software Test Plan (STP)\[Sec. 10.7.3.1\]

\* Software Test Procedures \[Sec. 10.7.3.2\]

\* Software Test Reports \[Sec. 10.7.3.3\]

\* Software Version Description Document (VDD)\[Sec. 10.7.6\]

In addition to the above documents, the following documents are required
for any project for which software could contribute to hazardous events,
leading to possible loss or injury to life or equipment.

\* Software Development Plan\* \[Sec. 10.1.4.1\]

\* Software Design Documentation (both Architectural and Detailed)

\* Firmware SuP/Port Manual (only if firmware is to be developed)

\* Operational Procedures Manual

\* Software User\'s Guide

Note: \* The documents marked with an asterisk (\*) may be included as
part

of the Software Management Plan.

The Software Assurance Plan can be included in the Project Assurance
Plan.

Responsibilities for the development of software documentation are
depicted in Table 10-2. An individual project may elect to tailor this
list, as necessary, with the aP/Proval of the project manager and
concurrence of the independent SA engineer, and documented in the PAP or
SWAP. Individual documents may also be tailored using the guidelines
found in NASA-STD-2100-91, or similar document.

Tailoring is an important aspect of the software development process.
While the intent of the required documents must be met and captured in
writing, the project and SA engineer shall work together to determine
the actual needed number and type of documents, their size, layout, and
how their contents can best be presented and maintained. Any chosen
documentation standard should be followed.

10.1.7 Government, Subcontractor, and Purchased Software

Any software provided as government furnished equipment (GFE) shall meet
project requirements to the extent that it was intended. In part or in
whole, any software obtained from contractors or subcontractors shall be
developed under a contract which specifies that they follow the
standards, requirements, and procedures agreed to for the project and as
specified in this document, or standards, procedures and requirements
that meet or exceed the project's. This includes delivery of required
software documentation as described in 10.1.6. Any previously existing
(reusable) software should have been developed under the same, or
similar, requirements and shall be thoroughly tested both as a stand
alone and as part of the integrated product.

Commercially purchased software (COTS - Commercial, Off The Shelf) shall
be

Configuration Managed and tested to the extent possible. All
documentation (including the licenses), the executable and any
libraries, suP/Port software, etc. for COTS Software should be kept by
configuration management. If possible, and necessary, the providing
company can hold the version of code purchased in escrow to protect
against future changes that might effect how it works with the rest of
the project. This is often done for Operating Systems that might be used
long term.

Acceptance testing of these types of software shall be performed in
accordance with the provisions of sections 10.7.3.1, 10.7.3.2, and
10.7.3.3. All software shall be configuration managed to the extent
possible. GFE, Contracted Software code and delivered documentation, and
COTS shall be put under configuration management and the Version
Description Document shall call out their version and status.

10.1.8 Firmware Assurance

The SA program shall aP/Ply to the development and suP/Port of the
software element of firmware. For the purposes of this document, the
term \"firmware\" is defined according to NASA-STD-2201-93 (NASA
Software Assurance Standard) as follows:

\"Hardware that contains a computer program and data that cannot be
changed in its user environment. The computer programs and data
contained in the firmware are classified as software; the circuitry
containing the computer program and data is classified as hardware.\"

A methodology shall be developed to include processes for assurance of
firmware source code and documentation, assurance of proper loading of
source code, and preparation of associated drawings.

10.2 SOFTWARE SAFETY

A software safety activity shall be implemented which maximizes the
extent to which the developed software and electronic hardware perform
their intended functions in a safe manner. Any software commands that
could cause hazardous operations to occur shall be identified and
documented.

A Preliminary Hazard Analysis shall be performed by the system safety
engineer(s) assigned to the project as required by Section 4.1.6 of this
document and any potential software hazards shall be identified.
Measures shall be taken to provide for their elimination or control. The
activities performed in this area shall adhere to the requirements of
section 4.0 of this document, and the NASA Software Safety Standard (NSS
1740.13).

Safety Analysis is an iterative process that begins at system concept
and continues through testing and maintenance. Once the Software portion
of the project has been identified, Safety analysis follows the software
through it's life cycle with iterative analyses to assure that hazards
identified from the system level and any hazards possibly introduced
during design and coding are either eliminated, mitigated or that proper
warning exists.

10.3 SOFTWARE RELIABILITY

A software reliability function shall be implemented which assures that
the developed software performs its required functions and meets its
fault tolerance requirements - ability to continue to operate, perhaps
with reduced functionality -within the framework of its designed
conditions. The software reliability activity shall assure that the
software will not contribute, beyond this accepted level, to a system
failure. The OSAT system reliability engineer(s) shall perform a failure
tolerance analysis on the software.

The activities performed in this area shall adhere to the requirements
of section 7.0 of this document.

10.4 SOFTWARE QUALITY ASSURANCE

A Software Quality Assurance (SQA) function shall be implemented in
accordance with NASA-STD-2201-93, or a standard that meets or exceeds
the requirements and intent of NASA-STD-2201-93, which verifies that the
established requirements and standards have been met. The SQA function
shall also verify that the required test, configuration management, and
nonconformance reporting procedures have been followed, and that
walkthroughs or inspections are performed and documented as specified in
the Project Assurance Plan and or Management Plan. SQA audits shall be
performed per section 10.7.4 of this document.

10.5 SOFTWARE CONFIGURATION MANAGEMENT

A software configuration management process shall be implemented to
manage requirements, design, code, data and documentation, and to track
and report on the status of changes to them. The process shall be
documented in a Software Configuration Management Plan (SCMP), in
accordance with NASA-DID-M600 to be found in NASA-STD-2100-91, unless
another standard is aP/Proved. This process shall include, as a minimum,
the following elements:

a\. Identification of configuration items that will be base lined and
maintained under configuration control. At least three baselines shall
be established:

-   the first after successful completion of the Critical Design Review
    (CDR) (e.g., baseline of requirements, test plans);

-   the second immediately prior to formal Software Acceptance testing
    (e.g., baseline of code, test procedures, design documents, and any
    updates to requirement documents, and test plan);

-   and the last after successful completion of acceptance testing and
    acceptance of the software by GRC (e.g., baseline all changes to any
    previous documents and code).

After the establishment of each baseline, any changes will require the
issuance of change proposals for review and aP/Proval by the CCB.

a.  A Configuration Control Board (CCB), or similar function, for
    reviewing and disposition proposed changes to baseline software and
    related documentation. Proposed changes shall require the aP/Proval
    of the CCB prior to implementation of the changes. The SA engineer
    shall be a permanent member of the CCB for software-related changes.

b.  Version control and media labeling methods and procedures. This
    shall include a method to provide certification that the correct
    version of flight software is present in the flight hardware prior
    to acceptance by the GRC Project Manager and the SA engineer.

c.  The establishment of Software Development Folders which are to
    include engineering data, notes, design, test results, etc.

d.  The performance of a Physical Configuration Audit (PCA) to verify
    the \"as-built\" configuration of the flight software prior to
    acceptance and/or shipment.

e.  The performance of a Functional Configuration Audit (FCA) to verify
    the flight software performs its required functions, without error,
    prior to acceptance and/or shipment.

f.  A change classification and impact assessment process that results
    in Class I changes being forwarded to GRC project management for
    disposition, throughout the entire life of the project. Class I
    changes are defined as those which affect system requirements,
    software requirements, system safety or reliability, cost, schedule,
    and external interfaces.

g.  Written procedures, including any required forms, to implement the
    components of the SCM process.

10.6 SOFTWARE PRACA (NONCONFORMANCE REPORTING AND CORRECTIVE ACTION)

A process shall be established for the reporting, analysis, and
correction of non-conformances and problems discovered in the baseline
software and related documentation. This process shall be in effect
after the initial software baseline is established, and continue until
the software is retired from use. This process shall meet the
requirements specified in Section 8.10 of this document.

This process shall be a component of the software configuration
management process to the extent that change control is effected and
that reported non-conformances and change requests are identified and
processed. In the event of a nonconformance, the discoverer of the
nonconformance (either software engineer or SA engineer) shall, within
24 hours, document the problem on a nonconformance report or discrepancy
report that identifies the problem and the criticality of the problem.
Then, within two calendar weeks, the assigned software engineer shall
provide an analysis of the cause and propose a corrective action to be
implemented. If a change is needed, the report shall reference the
change proposal number. The developer shall present the change proposal
to the CCB identified in section 10.5(b) for review and aP/Proval prior
to implementing the change.

A reporting process shall be established and maintained that shows the
status and criticality of all non-conformances.

10.7 PERFORMANCE VERIFICATION AND VALIDATION

A performance verification and validation process shall be planned and
implemented to demonstrate that the developed software is correct and
meets system requirements. The process shall include software reviews,
walkthroughs or inspections, software testing, and software acceptance.

10.7.1 Software Review

Various software reviews shall be conducted throughout the software
development life cycle. The project may elect to hold these reviews with
formal presentations or may conduct them in a less-formal manner. In
either method, the requirements of section 2.2 shall be met. The
requirements for the reviews include the following:

a.  At the Software Requirements Review, present the established
    software requirements and demonstrate the verifiability (test,
    inspection, demonstration) of the requirements. Present a
    requirements-driven verification aP/Proach.

b.  At the Preliminary Design Review, present the top-level
    (architectural) design, specified using a disciplined aP/Proach
    currently accepted within the software engineering community.
    Software review material shall address questions of Software to
    Hardware interfaces, Software to Software interfaces, how the
    requirements flow into the design, and initial fault detection,
    isolation and recovery schemes. In addition, the test plan should be
    reviewed for proposed verification process.

c.  At the Critical Design Review, describe the software detailed
    design, including data flow, command flow, and the interfaces, as
    well as an implementation aP/Proach/plan. Present the completed
    software test plans and review preliminary software test procedures
    for coverage and method.

d.  At the Pre-ship Review, present the results of software testing,
    validate that no open non-conformances or corrective actions exist,
    and provide proof of passage of software acceptance testing. Also
    present results of PCA/FCA to certify correct version of flight
    software resides in flight hardware, and performs its required
    functions. Provide the Version Description Document.

e.  At each review, present evidence of meeting schedule and
    requirements.

f.  At each review, any questions or issues relating to software safety
    or mission success shall be addressed.

10.7.2 Inspections

Software Formal Inspections of requirements, design and code shall be
conducted with the intent of finding defects as early as possible in the
software development life cycle. Results of the inspections shall be
documented. These inspections shall occur during the requirements,
design, and implementation phases. Software Formal Inspections shall be
performed in accordance with NASA-STD-2202-93 (Software Formal
Inspections Standard). The number of inspections and products to be
inspected may be tailored by each project.

10.7.3 []{#Software_Testing .anchor}Software Testing

A software testing process shall be implemented. Software testing shall
be performed in increments, beginning with unit (module level) testing,
continuing with integration and systems testing, and ending with
acceptance testing.

After GRC Project Manager acceptance of baseline software, any changes
shall require issuance of a new or revised test plan and the associated
test procedures. If the software is updated, regression testing is
required and shall be so identified in the test plan and procedures.

The test procedures shall be available in the developer\'s facility for
GRC review. The individual(s) performing the acceptance testing shall
notify the SA engineer at least four (4) hours prior to test
commencement.

The actual test results shall be available for review. Test reports
shall be provided to the GRC Project Manager for review in accordance
with the project schedule. The SA engineer as well as the engineer
performing the tests shall review SA selected test reports. Software and
associated software testing will be aP/Proved by the SA engineer based
on this review process.

10.7.3.1 Software Test Plan

As required in Section 10.1.6 a Software Test Plan (STP) will be
developed and submitted for GRC project manager aP/Proval in accordance
with the project schedule, for any software covered by this assurance
requirement (listed in 10.1.2).

The plan covers all levels of testing discussed in section 10.7.3. The
plan describes what tests are to be performed, including
hardware/software integration tests, to demonstrate that the software
meets its requirements. The plan includes pass/fail criteria, problem
report procedures, test reporting procedures, and retest procedures and
regression testing philosophy.

The plan is to be updated as requirements are changed and shall be
included as part of each review required in 10.7.1. The plan also
describes any special test suP/Port tools needed (i.e., simulators and
emulators) for the testing and any required suP/Port from other
organizations.

10.7.3.2 Software Test Procedures

In accordance with Section 10.1.6, Software test procedures will be
prepared to implement the software test plans as described in 10.7.3.1.
The procedures include the environment (e.g., hardware) under which the
test is to be conducted, the data required for the test, the expected
test results, and any special operating conditions required. The
procedures also include the steps followed in the creation of the flight
software executable element.

10.7.3.3 []{#Software_Test_Reports .anchor}Software Test Reports

Software test reports that summarize each of the software testing and/or
retesting activities (including acceptance testing) will be prepared by
the person who performed the test and delivered in accordance with the
project schedule. The report shows which of the planned tests were
completed, conformance of the test results to the expected results, the
number, type, and criticality of the discrepancies found and
identification of associated nonconformance report(s), identification of
the software tested, and an analysis of any performance requirements
that the items tested could affect.

10.7.4 Software Audits

A process shall be implemented for performing audits on the entire
software development process, from establishment of requirements through
acceptance testing. The development program shall be audited for
conformance to requirements, the Management Plan, Testing Plans, and
other standards. The audit program shall be performed on both in-house
and subcontractor software development programs.

For large projects of long duration, these audits shall occur at the
conclusion of each SDLC phase, or, at a minimum, annually if some
development stages are scheduled out for more than a year. For smaller
projects, at least one audit shall be conducted during the development
lifecycle prior to the required Functional Configuration Audit and
Physical Configuration Audit (Section 10.5 e. & f.). For smaller, less
critical projects, an audit at the end of requirements definition phase
and during the critical design or coding phases is recommended. However,
a survey, which is a less formal audit, may be conducted at the end of
each SDLC phase.

The SA engineer assigned to the project shall either perform these
audits or shall review and aP/Prove the audit checklists and findings if
performed by another individual. Audit reports shall be reported to
engineering management within one week of concluding the audit. Audit
reports may additionally be presented during milestone (or other)
reviews. Audits shall list \"findings\", which indicate the project is
at fault in meeting its requirements, standards or plans. The project
office shall respond, in writing, within two calendar weeks to any audit
findings and address how they plan to correct the problems. Audits may
also list \"observations\" which indicate potential problem areas but do
not signify that the project has not met its requirements. The
Engineering Management need not address observations in its reply to the
audit.

10.7.5 Software Records

A system for storage and tracking of records pertaining to the software
development process shall be specified and maintained. These records
shall include audit and survey results, requirement and design
documents, source code listings, results of project reviews, and
configuration management data.

10.7.5.1 References

\* NMI-2410.10 NASA Software Management, Assurance and Engineering
Policy

\* SMAP-GM-A201 Software Assurance Guidebook

\* NASA-STD-2201-93 Software Quality Assurance Standard

\* NASA-STD-2202-93 Software Formal Inspections Standard

\* NASA-GB-A302 Software Formal Inspections Guidebook

\* NSS 1740.13 Software Safety Standard

10.7.6 Software Acceptance

Prior to final shipment of a given system (or acceptance by GRC of a
contracted system), the GRC SA engineer shall assure that all
deliverable end-items are in accordance with project and contractual
requirements. These deliverables will make up a portion of the overall
project Acceptance Data Package (ADP). If acceptable to the project and
OSAT, the ADP shall be signed off by the lead software engineer, the SA
engineer, and the project manager.

In accordance with section 8.17 of this document, the following
information concerning the deliverable software shall be included in the
project Acceptance Data Package:

A Version Description Document (VDD) which completely defines the

\"As-built\" flight software. The VDD shall include:

a.  The name and version number of the flight software executable
    element.

b.  The files (and version numbers), which make up the executable
    element.

c.  Location of the source and object code for the flight executable.

d.  The procedure used to compile (i.e., create) the flight software.

> executable element. This information shall include the environment
>
> (hardware) and any software libraries and their version numbers used
>
> in compilation.

e.  The procedure used to load the flight software onto the experiment

> hardware. This information shall include a description of the hardware
>
> and any software libraries used in loading the flight software,
>
> including version numbers. Also, the storage medium (ROM, hard disk,
>
> etc.) in which the flight code will reside shall be identified, along
>
> with an identification number.

f.  A list of all action items, problem reports, audit findings and
    final

> reports, engineering change orders\'s, waivers, and deviations written
> against the software during development. This shall include any open
> items with rationale
>
> for the item remaining open. The location of the original
> \"discrepancy
>
> reports\" shall be specified.

g.  The Physical Configuration Audit (PCA) report required in section

> 10.5(e).

h.  The Functional Configuration Audit (FCA) report required in section

> 10.5(f).

i.  Software test results, including the procedures followed during the

> test, plus the test reports. Any problems shall be noted.

j.  A copy of the flight software on some aP/Propriate storage medium
    with

> proper labeling.

k.  Any other deliverables, including agreed upon software
    documentation,

> log books, etc.

Table 10-1 SOFTWARE ASSURANCE RESPONSIBILITY MATRIX ACTIVITY

Software Development Requirements Management Plan/Structure- P

Requirements Development- P S

Design and Implementation- P S

Performance Verification and Validation Software Reviews- P S

Software Formal Inspections- P S

Software Testing/Reporting- J

Software Safety/Reliability- S P

Software Quality Assurance J

Software Configuration Management Identify Configuration Items- P S

CCB or Similar Function- P S

Version Control Procedure- P S

Perform PCA/FCA- S P

Software Nonconformance Reporting/Corrective Action J

Legend: P = Primary Responsibility, S = Secondary Responsibility J =
Joint Responsibility

Table 10-2 SOFTWARE DOCUMENTATION MATRIX

  ------------------ --------- --------- ----------- ------------- -------------
  Document           Author    Inputs    AP/Proval   Final         Draft

  Management Plan    Project   P/OSAT    Project     R Phase       N/A

  Assurance Plan\*   OSAT      P/OSAT    P/OSAT      R Phase       R Phase

  Config. Mgt.       Project   OSAT/P    OSAT        PDR           Software
  Plan\*                                                           Concept

  Requirements Spec  Project   POSAT     Project     R Phase       R Phase

  Test Plan          Project   P/OSAT    Project     PDR           R Phase

  Test Procedures    Project   P/OSAT    Project     Prior unit    Design Phase
                                                     testing       

  Test Reports       Project   P/OSAT    OSAT        Pre-ship      N/A
                                                     Review        

  Version            Project   Project   P/OSAT      Prior to      N/A
  Description Doc                                    Pre-ship      

  Development Plan\* Project   Project   Project     PDR           R Phase

  Design Documents   Project   Project   Project     Prior Formal  Testing PDR

  Firmware SuP/Port  Project   P/OSAT    Project     Prior to test N/A
  Manual                                                           

  User\'s Guide      Project   Project   Project     Pre-ship      Prior to test
                                                     Review        

  Acceptance Data    Project   P/OSAT    P/OSAT      Pre-ship      Acceptance
  Package                                            Review        Testing
  ------------------ --------- --------- ----------- ------------- -------------

Legend: P- Project, R- Requirements.

Note: Items marked with an asterisk may be part of Management Plan. OSAT
shall review all developed software documentation, but has aP/Proval
authority only on Assurance Plan, Version Description Document, and Test
Reports.

[]{#Appendix_A .anchor}AP/Pendix A

AP/Plicable Documents

The aP/Plicable documents for this manual are located on the NASA
Headquarters Web Site at:
<http://www.hq.nasa.gov/office/codeq/doctree/qdoc.htm>.

##### Reference Documents

The reference documents for this manual are located on the NASA
Headquarters Web Site at: <http://neptune.hq.nasa.gov/pbma.>

AP/PENDIX B - ABBREVIATIONS, ACRONYMS, AND GLOSSARY

### ABBREVIATIONS, ACRONYMS

ADP Acceptance Data Package

ASR Assurance Status Report

ASTM American Society for Testing and Materials

CCB Configuration Control Board

CCP Contamination Control Plan

CDR Critical Design Review

CODR Conceptual Design Review

CIL Critical Items List

CM Configuration Management

CPT Comprehensive Performance Test

CSI Contractor Source Inspection

CVCM Collected Volatile Condensable Mass

DPA Destructive Physical Analysis

EEE Electrical, Electronic, & Electromechanical

EMC Electromagnetic Compatibility

EMI Electromagnetic Interference

ESD Electrostatic Discharge

ETR Eastern Test Range

FMEA Failure Modes and Effects Analysis

FRB Failure Review Board

FRR Flight Readiness Review

GFE Government Furnished Equipment

GIA Government Inspection Agency

GIDEP Government Industry Data Exchange Program

GSE Ground SuP/Port Equipment

GSI Government Source Inspection

IAC Independent Assurance Contractor

IBM International Business Machines

ICD Interface Control Document

JSC Johnson Space Center

KHB Kennedy Handbook

LeRC Glenn Research Center

LPT Limited Performance Test

MIL-STD Military Standard

MIUL Material Identification and Usage List

MRB Material Review Board

MSFC Marshall Space Flight Center

MUA Materials Usage Agreement

NCR Noncompliance Report

NHB NASA Handbook

NSPAR Non-standard Parts AP/Proval Request

NSPL NASA Standard Parts List

NSTS NASA Space Transportation System (Shuttle)

OHA Operations Hazard Analysis

PAI Product Assurance Instruction

PAP Product Assurance Plan

PAR Performance Assurance Requirements

PDA Percentage of Defectives Allowable

PDR Preliminary Design Review

PIL Parts Identification List

POCC Payload Operations Control Center

P/PL Preferred Parts List

PRACA Problem Reporting and Corrective Action

PSR Pre-ship Review

QA Quality Assurance

QCM Quartz Crystal Microbalance

R,M & Q Reliability, Maintainability & Quality Assurance

RFP Request for Proposal

RH Relative Humidity

SAF Safety

SAGE Standard Assurance Guidelines for Experiments

SCC Stress Corrosion Cracking

STS Space Transportation System

T-V Thermal Vacuum

V & V Verification and Validation

WCA Worst Case Analysis

### GLOSSARY

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

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

**Audit:** A review of a process to verify that it complies with the
requirements.

**Catastrophic Hazard:** For NSTS flight operations, a catastrophic
hazard is a hazard, which has potential for personal injury, loss of
life, loss of the orbiter, or NSTS equipment. For ground operations, a
catastrophic hazard is a hazard, which has potential for personnel
fatality or loss of the launch site facilities, GSE, payload(s), or
orbiter.

**Collected Volatile Condensable Material (CVCM):** The quantity of out
gassed material from a test specimen that condenses on a collector.

**Component:** An assembly in a system necessary for the system\'s
operation. Examples are transmitter, gyro package, actuator, motor, and
battery.

**Configuration:** The functional and physical characteristics of parts,
assemblies, equipment or systems, or any combination of these which are
capable of fulfilling the fit, form, and functional requirements defined
by performance specifications and engineering drawings.

**Configuration Control:** The systematic evaluation, coordination, and
formal aP/Proval/disaP/Proval of proposed changes and implementation of
all aP/Proved changes to the design and production of an item the
configuration of which has been formally aP/Proved by the developer or
by the purchaser, or both.

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

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

**Critical Hazard:** For flight operations, a hazard that has potential
for damage to equipment. For ground operations, a hazard that has
potential for damage to site facilities.

**De-rating:** The reduction of the aP/Plied load (or rating) of a
device to improve reliability or to permit operation at high ambient
temperatures.

**Design Specification:** Generic designation for a specification which
describes functional and physical requirements for an article, usually
at the component level or higher levels of assembly. In its initial
form, the design specification is a statement of functional requirements
with only general coverage of physical and test requirements. The design
specification evolves through the project life cycle to reflect
progressive refinements in performance, design, configuration, and test
requirements. In many projects the end - item specifications serve all
the purposes of design specifications for the contract end - items.
Design specifications provide the basis for technical and engineering
management control.

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

**Discrepancy:** See Nonconformance.

**Electromagnetic Compatibility:** When various electronic components
are performing in a system according to test requirements.

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

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

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

**Expected Failure Free Life:** That period of time following acceptance
testing during which an item is not expected to (1) fail
catastrophically or (2) degrade in functional output or performance
beyond acceptable limits. {Expected failure free life shall be
determined by suP/Plier/vendor test or field performance data,
aP/Plicable reliability data sources, or will be estimated by design
engineering in the absence of any tabulated data based upon design
knowledge, experience, and judgment.}

**Experiment:** See Payload.

**Failure:** See Nonconformance.

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

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

**Generic Hazard:** Those hazard groups that may be present in the
design or use of equipment and generally include hazard causes from the
environment, collision, fire/explosion (explosion/implosion)
vibration/shock/acoustic effect, thermal effects, contamination,
radiation, electrical discharge, biological/physiological/psychological
impact, toxicity, and other general items.

**GFE:** Government Furnished Equipment

**GSE:** Ground SuP/Port Equipment

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

> 1\. Prototype Hardware: Hardware of a new design; it is subject to a
> design qualification test program; it is not intended for flight.
>
> 2\. Flight Hardware: Hardware to be used operationally in space. It
> includes the following subsets:
>
> a\. Proto-flight Hardware: Flight hardware of a new design; it is
> subject to a test program that combines elements of prototype and
> flight acceptance verification; that is, the aP/Plication of design
> qualification test levels and flight acceptance test durations.
>
> b\. Follow-On Hardware: Flight hardware built in accordance with a
> design that has been qualified either as prototype or as proto-flight
> hardware; follow-on hardware is subject to a flight acceptance test
> program.
>
> c\. Spare Hardware: Hardware the design of which has been proven in a
> design qualification test program; it is subject to a flight
> acceptance test program and is used to replace flight hardware that is
> no longer acceptable for flight.
>
> d\. Re-flight Hardware: Flight hardware that has been used
> operationally in space and is to be reused in the same way; the
> verification program to which it is subject depends on its past
> performance, status, and the upcoming mission.

**Hazard:** A risk situation that could cause an unsafe condition that
could result in an accident.

**Hazard Analysis (HA):** The technique used to systematically identify,
evaluate, and resolve hazards. The determination of potential sources of
danger, causes, effects, hazard levels, and recommended resolution for
those conditions found in either the hardware/software system; the
person-machine relationship, or both, that could cause loss of life or
injury to persons or damage to or loss of systems or equipment.

**Hazard Category:** Category used in risk assessment associated with
accidents (e.g. low, medium, and high).

**Inspection:** The process of comparing an article with requirements.

**Item:** Space Flight hardware such as a part, component, assembly, or
material used to fabricate flight hardware.

**Limited Life Items:** Space flight hardware (1) whose failure
consequences are safety or mission critical and (2) has an expected
failure free life that is less than the projected mission time when
considering cumulative ground operation, storage, and on-orbit
operation. \[ Material used to fabricate flight hardware with a shelf
life that is less than its planned storage time qualifies as a limited
life item \]

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

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

**Noncompliance (Safety):** If a requirement of NHB 1700.7 or KHB
(1700.7) cannot be met, the payload organization must submit a Payload
Safety Noncompliance Report. The report contains the rationale and
suP/Porting data that demonstrates the safety of the questionable design
feature, procedures, configuration, etc.

If the NSTS operator aP/Proves the noncompliance, the aP/Proval will
come in the form either of a waiver or a deviation. Waivers restrict the
use of the non-complying feature to a single mission and a single
payload element.

A deviation may allow the feature to be employed for more than one
mission. A deviation aP/Plies to a feature that does not comply with a
requirement in the specified manner but does satisfy the intent of the
requirement and achieves a comparable or higher degree of safety.

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

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

**Outgassing:** The spontaneous evolution of gas or vapor from a
material, and evolution of the decomposition products, in a vacuum.

**Part:** A hardware element that is not normally subject to further
subdivision or disassembly without destruction of designed use.

**Payload:** An integrated assemblage of subsystems designed to perform
a specified mission in space.

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

**Preliminary Hazard Analysis:** An analysis technique for performing an
initial risk assessment of a system concept to identify safety-critical
areas, evaluate hazards, and identify the safety design requirements
needed in the project.

**Prototype Hardware:** See Hardware.

**Qualification Tests:** The process of demonstrating that a given
design and manufacturing aP/Proach will produce hardware that will meet
all performance specifications when subjected to defined conditions more
severe than those expected to occur during its intended use.

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

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

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

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

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

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

**Subsystem:** A functional subdivision of a payload consisting of two
or more components. Examples are attitude control, electrical power
subsystems, and instruments.

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

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

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

**Thermal-Vacuum Test:** A test to demonstrate the validity of the
design in meeting functional goals; it also demonstrates the capability
of the test item to operate satisfactorily in vacuum at temperatures
based on those expected for the mission. The test can also uncover
latent defects in design, parts, and workmanship.

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

**Verification:** See Performance Verification.

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

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

[]{#Appendix_c .anchor}AP/Pendix C - PROJECT SCHEDULE -- Deliverable

-   \*\* A\--GRC aP/Proves within the period that has been negotiated
    and specified in the contract before contractor may proceed.

-   R \-- GRC reviews and may comment within 30 days; contractor may
    continue work unless directed to stop.

-   I \-- Information; the developer\'s work schedule is not normally
    affected.

-   P \-- Submitted as part of the PAP and evaluated with the proposal.

-   The \"Project Schedule\" shall be entitled \"Contract Schedule\"
    when the developer is a contractor.

SARG-1 PROJECT SCHEDULE\* Deliverable Data

+---+------------------------------+----+----------------------+------+
| I | REFERENCED                   | P  | DELIVERY             | GRC  |
| T |                              | AR |                      |      |
| E | DESCRIPTION                  | A. | SCHEDULE             | AC   |
| M |                              |    |                      | TION |
|   |                              |    |                      |      |
| N |                              |    |                      |      |
| O |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | AP/Proved Product Assurance  | 1  | a\. At effective     | P    |
| \ | Plan (PAP). In addition to   | .2 | date of contract     |      |
| . | the data called for in the   |    |                      | A    |
|   | text, the items designated   |    | b\. Proposed         | \*\* |
|   | with a \"P\" under GRC       |    | changes, updates as  |      |
|   | changes, updates Action      |    | generated.           |      |
|   | shall also be submitted with |    |                      |      |
|   | the PAP.                     |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | AP/Proved Developer's        | 1  | a.  At GRC RDR       | P    |
| \ | practices and procedures     | .2 |                      |      |
| . | referenced in the PAP.       |    | b.  New or proposed  | A    |
|   |                              |    |     changes as       |      |
|   |                              |    |     generated.       |      |
+---+------------------------------+----+----------------------+------+
| 3 | Previously designed,         | 1  | GRC RDR              | P    |
| \ | fabricated or flown hardware | .3 |                      |      |
| . | data.                        |    | GRC                  | I    |
|   |                              |    |                      |      |
|   | a.  AP/Proved preliminary    |    | GRC                  | A    |
|   |                              |    |                      |      |
|   | b.  Revision                 |    |                      |      |
|   |                              |    |                      |      |
|   | c.  Final                    |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 4 | Assurance Status Reports     | 1  | Monthly: can be part | I    |
| \ | (ASRs)                       | .4 | of the Project       |      |
| . |                              |    | Status Reports       |      |
+---+------------------------------+----+----------------------+------+
| 5 | Copies of material presented | 2  | Two weeks before RDR | I    |
| \ | for review                   | .2 |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 6 | Verification Plan            | 3  | At GRC CDR           | P    |
| \ |                              | .2 |                      |      |
| . | a.  AP/Proved preliminary    |    | As generated         | A    |
|   |     plan                     |    |                      |      |
|   |                              |    | 30 days after        | A    |
|   |     1.  Procedures           |    | completion of        |      |
|   |                              |    | activity             |      |
|   | b.  Final                    |    |                      |      |
|   |                              |    |                      |      |
|   | c.  Updates                  |    |                      |      |
|   |                              |    |                      |      |
|   | d.  Reports                  |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 7 | Fracture Control             | NA | RDR                  | P    |
| \ | Implementation Plan          |    |                      |      |
| . |                              |    | GRC PDR              | A    |
|   | a.  AP/Proved preliminary    |    |                      |      |
|   |     plan                     |    |                      |      |
|   |                              |    |                      |      |
|   | b.  Final                    |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 8 | Hazard Control Verification  | 4  | Prior to Safety      | R    |
| \ |                              | .1 | Review               |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 9 | Payload Safety Noncompliance | 4  | As generated         | A    |
| \ | Report/Wavier                | .1 |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | Safety Data Package/Safety   | 4  | As generated         |      |
| 0 | Assessment Report            | .1 |                      |      |
| \ |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | Safety Plan                  | 4  | 30 days prior to     | A    |
| 1 |                              | .1 | operation            |      |
| \ |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | De-rating                    | 5  | 30 days before       | A    |
| 2 |                              | .2 | building the         |      |
| \ |                              | .3 | hardware             |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | Parts Identification List    | 5  | As generated         | I    |
| 3 | (Computer readable formats)  | .5 |                      |      |
| \ |                              |    | As generated         | I    |
| . | a.  Preliminary              |    |                      |      |
|   |                              |    | 30 days prior to CDR | R    |
|   | b.  Updates                  |    |                      |      |
|   |                              |    | With end-item        | A    |
|   | c.  As Designed              |    | acceptance data      |      |
|   |                              |    | package              |      |
|   | d.  As Built                 |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | Material Usage               | 6  | As generated         | A    |
| 4 | Agreement/Stress Corrosion   | .3 |                      |      |
| \ | Evaluation Form              | .2 |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | Materials List (Polymeric &  | 6  | 30 days before       | R    |
| 5 | Inorganic)                   | .3 | contractor PRD       |      |
| \ |                              |    |                      | A\   |
| . | a.  Preliminary              |    | 30 days before       | A    |
|   |                              |    | contractor CDR       |      |
|   | b.  Final                    |    |                      | I    |
|   |                              |    | As generated         |      |
|   | c.  Updates                  |    |                      | A    |
|   |                              |    | With end-item        |      |
|   | d.  As-Built                 |    | acceptance data      |      |
|   |                              |    | package              |      |
|   | e.  SuP/Porting data for     |    |                      |      |
|   |     materials aP/Plications  |    | As generated         |      |
+---+------------------------------+----+----------------------+------+
| 1 | Waiver Request for use of    | 6  | As generated         | A    |
| 6 | materials whose shelf life   | .3 |                      |      |
| \ | has expired                  |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | Material Test Reports for    | 6  | As generated         | I    |
| 7 | Fasteners (i.e., rivets,     | .3 |                      |      |
| \ | nuts, bolts) Lots            |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | A copy of the Proposed       | 6  | As generated         | R    |
| 8 | Material Processes           | .3 |                      |      |
| \ |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 1 | A copy of the Proposed       | 6  | As generated         | R    |
| 9 | Welding and Brazing (or      | .3 |                      |      |
| \ | repairs) Procedures, and a   |    |                      |      |
| . | copy of the Operator's       |    |                      |      |
|   | Qualification Record         |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Data for the results of      | 6  | As generated         | I    |
| 0 | Nondestructive Chemical and  | .3 |                      |      |
| \ | Physical Tests, or a         |    |                      |      |
| . | Certificate of Compliance    |    |                      |      |
|   | for Purchased Raw Materials  |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Failure Modes and Effects    | 7  | 30 days before       | R    |
| 1 | Analysis and CIL             | .2 | contractor PDR       |      |
| \ |                              | .1 |                      | R    |
| . | a.  Preliminary              |    | 30 days before       |      |
|   |                              |    | contractor CDR       |      |
|   | b.  Refined                  |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Parts Stress Analysis        | 7  | As generated         | R    |
| 2 |                              | .2 |                      |      |
| \ | a.  Final                    | .2 | As generated         | R    |
| . |                              |    |                      |      |
|   | b.  Updates                  |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Trend Analysis               | 7  | As generated         | I    |
| 3 |                              | .3 |                      |      |
| \ | a.  List of parameters to be | .1 | As generated         | I    |
| . |     monitored                |    |                      |      |
|   |                              |    |                      |      |
|   | b.  Trend Analysis           |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Limited-Life Plan            | 7  | As generated         | R    |
| 4 |                              | .4 |                      |      |
| \ | a.  Preliminary              |    | As generated         | A    |
| . |                              |    |                      |      |
|   | b.  Final                    |    | As generated         | A    |
|   |                              |    |                      |      |
|   | c.  Updates                  |    | As generated         | A    |
|   |                              |    |                      |      |
|   | d.  Waivers                  |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Test Coupons and Reports     | 8  | Before assembly of   |      |
| 5 |                              | .6 | hardware             |      |
| \ |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Fabrication & Assembly Flow  | 8  | 30 days before       | R    |
| 6 | Plan                         | .7 | contractor PDR       |      |
| \ |                              |    |                      | R    |
| . | a.  Preliminary              |    | 30 days before       |      |
|   |                              |    | contractor PDR       |      |
|   | b.  Final                    |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Fabrication and Inspection   | 8  | As generated         | R    |
| 7 |                              | .7 |                      |      |
| \ | a.  Matrix for comparing     |    | As generated         | A    |
| . |     contractor's procedures  |    |                      |      |
|   |     as they differ from NASA |    |                      |      |
|   |     Std.                     |    |                      |      |
|   |                              |    |                      |      |
|   | b.  All other processes,     |    |                      |      |
|   |     specifications, or       |    |                      |      |
|   |     procedures               |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | New or Change to Training    | 8  | 30 days before use   | A    |
| 8 | Plans                        | .7 |                      |      |
| \ |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 2 | Electrostatic Discharge      | 8  | Before assembly of   | A    |
| 9 | Control Plan                 | .9 | hardware             |      |
| \ |                              |    |                      | A    |
| . | a.  AP/Proved Preliminary    |    | 30 days before       |      |
|   |                              |    | contractor CDR       |      |
|   | b.  Final                    |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Requests for Delegation of   | 8. | As generated         | A    |
| 0 | MRB Responsibility           | 10 |                      |      |
| \ |                              |    | As generated         | A    |
| . | a.  Nonstandard Repair       |    |                      |      |
|   |     Procedures               |    |                      |      |
|   |                              |    |                      |      |
|   | b.  Waiver Requests          |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Nonconformance               | 8. | As generated         | I    |
| 1 |                              | 10 |                      |      |
| \ | a.  Initial oral             |    | As generated         | I    |
| . |     Notification             |    |                      |      |
|   |                              |    | On completion of     | A    |
|   | b.  Written notification     |    | required action      |      |
|   |                              |    |                      |      |
|   | c.  Malfunction/Failure      |    |                      |      |
|   |     Report Closeout          |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Alerts                       | 3. | As generated         | I    |
| 2 |                              | 11 |                      |      |
| \ |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Acceptance Data Package for  |    |                      |      |
| 3 | each Experiment, comprising: |    |                      |      |
| \ |                              |    |                      |      |
| . | a.  As-built Configuration   |    |                      |      |
|   |     List in accordance with  |    |                      |      |
|   |     paragraph 8.13           |    |                      |      |
|   |                              |    |                      |      |
|   | b.  List of Parts/Devices    |    |                      |      |
|   |     used in the hardware.    |    |                      |      |
|   |     Prepared in accordance   |    |                      |      |
|   |     with 5.3                 |    |                      |      |
|   |                              |    |                      |      |
|   | c.  List of Materials and    |    |                      |      |
|   |     Processes used in the    |    |                      |      |
|   |     hardware                 |    |                      |      |
|   |                              |    |                      |      |
|   | d.  Test Log Book including  |    |                      |      |
|   |     total operating time and |    |                      |      |
|   |     cycle records            |    |                      |      |
|   |                              |    |                      |      |
|   | e.  List of Open Items with  |    |                      |      |
|   |     reasons for items being  |    |                      |      |
|   |     open                     |    |                      |      |
|   |                              |    |                      |      |
|   | f.  Safety Compliance Data   |    |                      |      |
|   |     Package                  |    |                      |      |
|   |                              |    |                      |      |
|   | g.  Listing and status of    |    |                      |      |
|   |     the Final Performance    |    |                      |      |
|   |     Acceptance Test          |    |                      |      |
|   |                              |    |                      |      |
|   | h.  Critical Parameters      |    |                      |      |
|   |     Trend Data               |    |                      |      |
|   |                              |    |                      |      |
|   | i.  Results of the Final     |    |                      |      |
|   |     Performance Acceptance   |    |                      |      |
|   |     Test                     |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Contamination Control        | 8  | Before assembly of   | P    |
| 4 |                              | .8 | hardware             |      |
| \ | a.  AP/Proved Preliminary    |    |                      | A    |
| . |                              |    | At time of GRC CDR   |      |
|   | b.  Final                    |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Software Assurance Plan      | 10 | As generated         | P    |
| 5 |                              | .1 |                      |      |
| \ |                              | .3 |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Software Configuration       | 10 | As generated         | A    |
| 6 | Management, Class I Changes  | .5 |                      |      |
| \ |                              |    |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Software Review Charts,      | 10 | At requirements PDR, | R    |
| 7 | Actions, Items, Resolutions  | .7 | CDR, and Pre-ship    |      |
| \ |                              | .1 |                      |      |
| . |                              |    |                      |      |
+---+------------------------------+----+----------------------+------+
| 3 | Software Test Reports        | 10 | Upon completion of   | R    |
| 8 |                              | .7 | test, before         |      |
| \ |                              | .3 | acceptance for final |      |
| . |                              | .3 | use                  |      |
+---+------------------------------+----+----------------------+------+