Attachment E - Mission Assurance Requirements (MAR) Rev - A.pdf

TSIS-2 Spacecraft MAR TSIS2-SC-REQ-0006 Revision A

Effective Date: November 1, 2019

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

TSIS-2 Spacecraft Mission Assurance Requirements Signature/Approval Page

Prepared by:

Electronic signature on TDMS 11/1/2019 Sue Pollard Date TSIS-2 Chief Safety & Mission Assurance Officer NASA/GSFC, Code 383

Approved by:

Susan Breon Date TSIS-2 Project Manager NASA/GSFC, Code 424

Concurred by:

Jesse Leitner Date Safety & Mission Assurance Chief Engineer NASA/GSFC, Code 300

*** Electronic signatures are available on-line at: https://ipdtdms.gsfc.nasa.gov*** ii

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

CM FOREWORD

This document is under the TSIS-2 project configuration control. Once this document is approved, TSIS-2-approved changes are handled in accordance with Class I and Class II change control requirements as described in the TSIS-2 Configuration Management Procedures, and changes to this document shall be made by complete revision.

Any questions should be addressed to:

TSIS-2 Configuration Management Office

NASA/ GSFC

Code 424 Greenbelt, MD 20771 iii

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

Change History Log

Revision Approved Date Description of Changes

(Reference the CCR) Rev - 07/31/2019 TSIS2-CCR-0010

Rev A 11/1/2019 TSIS2-CCR-0027 ii

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

Table of Contents

1.0 GENERAL

1.1 System Safety and Mission Assurance Program

1.2 Management

1.3 Requirements Flow Down

1.4 Suspension of Work Activities

1.5 Surveillance

1.6 Government Mandatory Inspection Points (GMIPS)

1.7 Use of Inherited Products

2.0 QUALITY MANAGEMENT SYSTEM

2.1 General

2.2 Supplemental Quality Management System Requirements

2.2.1 Control of Nonconforming Product

2.2.2 Material Review Board (MRB)

2.2.3 Anomaly Reporting and Disposition

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

3.0 SYSTEM SAFETY

3.1 General

3.2 Mission Related Safety Requirements Documentation

3.3 System Safety Deliverables

3.3.1 System Safety Plan

3.3.2 Safety Requirements Compliance Checklist

3.3.3 Hazard Analyses

3.3.3.1 Preliminary Hazard Analysis

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

(HVTL)

3.3.3.3 Operating and Support Hazard Analysis

3.3.4 Safety Data Package (SDP)

3.3.5 Verification Tracking Log (VTL)

3.3.6 Hazardous Procedures for Payload I&T and Prelaunch Processing

3.3.7 Safety Waivers

3.3.8 Mishap Reporting and Investigation

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

4.0 RELIABILITY

4.1 Reliability Program Plan (RPP)

4.2 Failure Modes, Effects, and Criticality Analysis (FMECA) and Critical Items List (CIL) .9

4.3 Fault Tree Analysis

4.4 Parts Stress Analysis

4.5 Limited Life Items

iii

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

5.0 SOFTWARE ASSURANCE

5.1 Applicable Software Definitions

5.2 Software Assurance Program

5.3 Surveillance of Software Development, Maintenance, and Assurance Activities

6.0 WORKMANSHIP

6.1 General

6.2 Design and Process Qualification

6.3 Electrostatic Discharge Control (ESD)

6.4 Splices, Circuit Board Trace Cuts, and Jumper Wires

6.5 Printed Wiring Board (PWB) Test Coupons and Verification Tests

6.6 Lead-Free and Tin Whisker Control Measures

7.0 EEE PARTS

7.1 General

7.2 Parts Control Board

7.3 Re-use of EEE Parts

7.4 As-Built Parts List

7.5 Radiation

8.0 MATERIALS AND PROCESSES

8.1 General

8.2 Materials Identification and Usage List (MIUL)

8.3 Non-Destructive Evaluation (NDE) Plan

9.0 CONTAMINATION CONTROL

9.1 Contamination Control Plan

9.2 Material Outgassing

9.3 Foreign Object Debris Prevention and Control Program

10.0 METROLOGY AND CALIBRATION

10.1 Metrology and Calibration Program

10.2 Use of Calibrated and Non-Calibrated Instruments

11.0 GIDEP ALERTS AND PROBLEM ADVISORIES

11.1 Government-Industry Data Exchange Program (GIDEP)

11.2 Alert Disposition

11.3 GIDEP Reporting

11.4 Review Reporting

12.0 END ITEM ACCEPTANCE DATA PACKAGE

iv

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

List of Tables

Table 4-1. Severity Categories Table 4-2. Likelihood Rankings

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

1.0 GENERAL

1.1 System Safety and Mission Assurance Program

[The spacecraft developer shall implement a safety and mission assurance program that is consistent with contractual requirements. The mission assurance program shall cover: Flight hardware and software that is designed, built, or provided by the developer and its subcontractors or furnished by the government, from project initiation through launch and mission operations

The developer shall submit a mission assurance requirements compliance matrix that identifies variances and acceptance rationale for processes, procedures, and standards that are proposed as alternatives to those specified by the contract (MA-1).

1.2 Management

The developer shall designate a point of contact to manage assurance activities. The assurance manager may not be responsible for project costs and schedules other than those pertaining to assurance activities. The assurance manager may have direct access to upper management that is independent of project management and may have the functional freedom and authority to interact with all elements of the project.

1.3 Requirements Flow Down

The developer shall apply system safety and mission assurance requirements to subcontractors and suppliers to the extent necessary to ensure that the delivered product meets performance requirements.

1.4 Suspension of Work Activities

The developer shall direct the suspension of any work activity that presents a hazard, imminent danger, or future hazard to personnel, property, or mission operations resulting from unsafe acts or conditions that are identified by inspection, test, or analysis.

1.5 Surveillance

The developer shall provide upon request a list of suppliers used for products produced under this contract.

1.6 Government Mandatory Inspection Points (GMIPS)

The developer shall have a process for inspections to be completed by the developer during the flight hardware build.

In addition, NASA has the right to specify Government Mandatory Inspection Points (GMIPs), as applicable. The developer shall provide documentation indicating both Project and subcontractor workflow to NASA with any planned inspection points. GMIPs will be assigned as a result of an upfront negotiation based on (1) assessment of developer’s own inspection points, (2) developer identified risks, (3) project identified risks, (4) experiences from TSIS development; and furthermore, in response to events, such as failures, anomalies, and process shortfalls that prompt a need for further inspection.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

1.7 Use of Inherited Products

For inherited products, defined as those that were previously developed and exist (e.g., spares), will be build-to-print, or are available as commercial-off-the-shelf (COTS), the developer may follow an inherited product review process in accordance with the Safety and Mission Assurance Acceptance of Inherited and Build to Print Products (GPR 8730.5) and provide an Inheritance Data package for Risk Assessment.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

2.0 QUALITY MANAGEMENT SYSTEM

2.1 General

The developer shall have a quality management system that is compliant with SAE AS9100 Quality Systems - Aerospace - Model for Quality Assurance in Design, Development, Production, Installation and Servicing.

2.2 Supplemental Quality Management System Requirements

2.2.1 Control of Nonconforming Product

Control of Nonconforming Product – The developer shall have a documented closed loop system for identifying, reporting, and correcting product nonconformance’s. The system shall ensure that the adequacy of corrective action is determined by audit or test, that objective evidence is collected, and that preventive action is implemented to preclude recurrence.

2.2.2 Material Review Board (MRB)

The developer shall have a documented process for the establishment and operation of a MRB to process nonconformance’s. The process will include the definitions of major and minor nonconformance’s, where a major nonconformance is generally defined as one affecting form, fit, function, reliability, or safety of the end item. The developer shall appoint a MRB chairperson who is responsible for implementing the MRB process and functional and project representatives as MRB members. The MRB shall include a government representative. The developer shall notify the government representative 24 hours in advance of the scheduled MRB. The developer shall provide applicable documents to the government representative in advance. The developer shall inform the government of MRB actions (MA-2).

The MRB shall use the following disposition actions:

- Scrap: the product is not usable

- Re-work: the product will be re-worked to conform to requirements

- Return to supplier: the product will be returned to the supplier

- Repair: the product will be repaired using a repair process approved by the MRB

- Use as is: the product will be used as is

2.2.3 Anomaly Reporting and Disposition

The developer shall have a documented process for anomaly reporting and disposition. The developer shall establish an anomaly review board (ARB) whose membership shall include a government representative with approval authority for proposed actions on all major anomalies. The ARB process shall include classification supported by analysis to determine if an anomaly is a major or minor anomaly.

The process shall require major anomalies to be submitted to the ARB and the government (MA-3).

The developer shall report major hardware anomalies beginning with the first application of power at the component level, major software anomalies beginning with flight software acceptance testing and when interfacing with flight hardware, and major mechanical system anomalies beginning with the first operation. Major anomalies are those that have resulted in hardware or software test failures, Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

environmental test exceedances and damage or potential damage to hardware. Examples of major anomalies are overvoltage or over current conditions, exceedance of test limits resulting in overstress, blown fuses, and unexpected system responses. Failures that either cannot be duplicated, that have unknown root cause, or cannot be verified shall be analyzed for residual risk, declared as red flag problem failure records (PFRs), and brought to the project risk board for disposition.

The process shall allow the developer to disposition minor anomalies with an appropriate subset of the ARB. Minor anomalies are those that analyses have shown have not resulted in hardware failure or have caused no damage or stress to hardware or required no change in flight software. Examples of minor anomalies are those that can be resolved immediately, procedural errors, database problems, operator errors, and exceedance of test limits that do not affect the end item.

Note: a component is defined as a functional subdivision of a subsystem and generally as a self-contained combination of items performing a function necessary for the subsystem's operation.

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

The developer shall provide the information necessary for the development of the ODAR and the EOMP deliveries per the content defined in NASA-STD 8719.14 Process for Limiting Orbital Debris (MA-4).

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

3.0 SYSTEM SAFETY

3.1 General

The developer shall document and implement a system safety program, support the ELV Safety Review Process as defined in NPR 8715.7 Expendable Launch Vehicle Payload Safety Program, meet launch service provider requirements, and launch range safety requirements.

Specific safety requirements include the following:

- The developer shall incorporate three independent inhibits in the design (dual failure tolerant) if a system failure may lead to a catastrophic hazard. A prelaunch catastrophic hazard is a payload-related hazard, condition, or event occurring prior to launch that could result in a fatal injury to personnel or loss of a ground facility. A post-launch catastrophic hazard is a payload-related hazard, condition, or event occurring after launch and up to payload separation that could result in a fatal injury or loss of flight termination system.

- The developer shall incorporate two independent inhibits in the design (single failure tolerant) if a system failure may lead to a critical hazard. A critical hazard is defined as a hazard, condition or event that may cause severe injury or occupational illness or major property damage to facilities.

- The developer shall adhere to specific detailed safety requirements, including compliance verification that must be met for design elements with hazards that cannot be controlled by failure tolerance. The process by which safety is incorporated into these design elements (e.g., structures and pressure vessels) is called "Design for Minimum Risk".

3.2 Mission Related Safety Requirements Documentation

The developer shall implement launch range safety requirements as applicable for the specific launch site. The most stringent applicable safety requirement shall take precedence in the event of conflicting requirements.

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

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

- NPR 8715.7, “Expendable Launch Vehicle Payload Safety Program”

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

3.3 System Safety Deliverables

3.3.1 System Safety Plan

The developer shall prepare a System Safety Program Plan (SSPP) that describes the tasks and activities of system safety management and engineering required to identify, evaluate, and eliminate or control hazards to the hardware, software, and system design by reducing the associated risk to an acceptable level throughout the system life cycle, including launch range safety requirements

(MA-5).

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

3.3.2 Safety Requirements Compliance Checklist

The developer shall document and implement a Safety Requirements Compliance Checklist to demonstrate that the payload is in compliance with NASA and range safety requirements

(MA-6).

The developer shall document non-compliances to safety requirements in waivers per section 3.3.7 of this document.

3.3.3 Hazard Analyses

3.3.3.1 Preliminary Hazard Analysis

The developer shall perform a Preliminary Hazard Analysis (PHA) to obtain an initial risk assessment and to identify safety critical areas of a concept or system. The developer will base the PHA on the best available data, including mishap data from similar systems and other lessons learned.

The developer shall evaluate hazards associated with the proposed design or function for severity, control approach (fault tolerance or design for minimum risk), and operational constraints. The developer shall identify safety provisions and alternatives that are needed to eliminate hazards or reduce their associated risk to an acceptable level.

The developer shall deliver the PHA with SDP I (MA-8) to the Project Office for review.

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

The developer shall perform and document an Operations Hazard Analysis (OHA) and a Hazard Verification Tracking Log (HVTL) to demonstrate that hardware operations, test equipment operations, and integration and test (I&T) activities comply with facility safety requirements and that hazards associated with those activities are mitigated to an acceptable level of risk (MA-7).

The developer shall update and maintain the Hazard Verification Tracking Log during I&T activities to track open issues.

3.3.3.3 Operating and Support Hazard Analysis

The developer shall perform an Operating and Support Hazard Analysis (O&SHA) to evaluate activities for hazards introduced during testing, transportation, storage, integration, and prelaunch operations at the launch site. The primary purpose is to evaluate the adequacy of procedures used to eliminate, control, or mitigate identified hazards so as to ensure implementation of safety requirements for personnel, procedures, and equipment during activities at the launch site.

The developer shall submit the results of the O&SHA as a part of the SDP II and SDP III

(MA-8).

3.3.4 Safety Data Package (SDP)

The developer shall prepare an integrated SDP to document the results of hazard analyses identifying the prelaunch, launch and ascent hazards associated with the flight system, ground support equipment, and their interfaces in hazard reports (MA-8).

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

3.3.5 Verification Tracking Log (VTL)

The developer shall document and implement a VTL that documents a Hazard Control and Verification Tracking process as a closed-loop system that ensures safety compliance has been satisfied per applicable launch range safety requirements.

The developer shall document in the VTL the process of verifying the control of hazards by test, analysis, inspection, similarity to previously qualified hardware, or any combination of these activities.

The developer shall ensure that verifications listed on the hazard reports refer to specific test, analysis, or inspection reports with a summary of the pertinent results.

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

The VTL shall identify hazard controls that are not verified as closed and shall be delivered to the Project Office with SDP III (MA-8).

The developer shall provide regular electronic updates of the VTL until all hazard controls are verified as closed.

3.3.6 Hazardous Procedures for Payload I&T and Prelaunch Processing

The developer shall document and implement hazardous procedures that comply with applicable facility safety requirements when performing integration and test activities and prelaunch activities at the launch site (MA-9).

The developer shall document hazardous procedures that will be implemented when performing integration and test activities and prelaunch activities at the processing facilities and launch site. The developer shall ensure that the procedures comply with applicable facility safety requirements.

The developer shall provide safety support for hazardous operations at the launch site.

3.3.7 Safety Waivers

The developer shall request waivers for variations from the applicable safety requirements per paragraph 1.4 of NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program. The waiver form is available at URL http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms.html.

(MA-15).

3.3.8 Mishap Reporting and Investigation

The developer shall submit documentation of their process to report accidents, test failures, or other mishaps and close calls promptly to NASA’s TSIS-2 project management and TSIS-2 Chief Safety & Mission Assurance Officer. This shall include the TSIS-2 emergency contact list and instructions to ensure notification is made to NASA in less than 24 hours, or less than 1 hour for major mishaps.

Major mishaps would include Type A or B mishaps as defined in NPR 8621.1 (MA-13).

The developer shall promptly investigate mishaps and close-calls to determine the root cause.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

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

The developer shall prepare the following forms as applicable:

KTI-5212 Material Selection List for Plastic Films, Foams, and Adhesive Tapes AF Form 813 Request for Environmental Impact Analysis KSC Form 26-551V2 Process Waste Questionnaire KSC Form 16-294 Radiation Training and Experience Summary (Ionizing Radiation) KSC Form 16-295 Radiation Use Request/Authorization (Radioactive Materials KSC Form 16-353 Modification of Radiation Use Authorization Form KSC Form 16-450 Radiation Training & Experience Summary (Nonionizing Radiation) KSC Form 16-447 Laser Device Use Request/Authorization KSC Form 16-451 Radiofrequency/Microwave System Use Request/Authorization KSC Form 28-34 Radiation Use Request Authorization (Ionizing Machine/Device) KSC Form 28-45 Radioactive Material Transfer Receipt KSC Form 28-626 Optical Device Use Request/Authorization

Some forms are available via https://kscsma.ksc.nasa.gov/PayloadSafety/forms.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

4.0 RELIABILITY

4.1 Reliability Program Plan (RPP)

The developer shall plan, document, and implement a Reliability Program that interacts effectively with other project disciplines, including engineering, hardware design, software reliability, systems safety, and mission assurance (MA-10).

The developer shall document the performance of analyses specified in the remainder of this section in order to evaluate mission risks and if additional reliability analysis techniques (e.g., RBD/ prediction, FMECA Functional, Design, or Process), and/or WCA) will be used to supplement these when needed.

The developer shall perform reliability analyses concurrent with design so that identified problem areas are addressed and corrective action taken in a timely manner.

4.2 Failure Modes, Effects, and Criticality Analysis (FMECA) and Critical Items List (CIL)

The developer shall perform and maintain FMECAs at the interface level to assess the risk of failure propagation and interactions (MA-11). Specific functional FMECAs may be requested to address critical failure indications from other analyses.

The developer shall prepare and maintain a Critical Items List for severity categories 1, 1R, 1S, and 2 per Table 4-1.

The developer shall prepare and maintain a single point failure list for modes resulting in categories 1, 1R, 1S, and 2 per Table 4-1 and document applicable failure causes, corresponding mitigations, and retention rationale.

In performing the likelihood part of this analysis the developer shall predict the likelihood score from 1-5 for each failure mode, using the Technical Likelihood criteria shown in Table 4-2, to facilitate risk assessment using the FMECA results. Each likelihood prediction can be based on qualitative assessment and/or failure rate data from other analyses (i.e., system predictions) in order to score each failure mode for the mission duration.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

4.3 Fault Tree Analysis

The developer shall perform and maintain qualitative fault tree analyses (FTA) to assess mission failure or safing modes. (MA-12)

The developer shall address both hardware and software contributions and identify risk areas.

4.4 Parts Stress Analysis

The developer shall perform parts stress and derating analyses for electrical, electronic, and electromechanical (EEE) parts in accordance with GSFC EEE-INST-002 Instruction for EEE Parts Selection, Screening, Qualification, and Derating or similar process (with process documentation required). (MA-14)

4.5 Limited Life Items

The developer shall document and implement a plan to manage limited life items. (MA-16)

The developer shall prepare a list of potential limited life items that includes expected life, required life, duty cycles, an assessment of life margin that includes servicing and maintenance, and the retention rationale for items with an expected life of less than 2x the requirement.

Note: Limited Life items are generally defined as items that have a limited shelf life, operational life, or a cycle life and whose life expectancy is less than 2x the requirement. The risk assessment and mitigations plans may factor in wear caused by atomic oxygen, solar and trapped radiation, shelf-life, extreme temperatures, thermal cycling, and mechanical wear or fatigue, and include refurbishment and maintenance plans.

Note: Examples of potential limited-life items shall include, but not necessarily be limited to:

selected consumables; structures; mechanisms; batteries; seals; thermal control surfaces; solar arrays; and, electromechanical mechanisms.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

5.0 SOFTWARE ASSURANCE

5.1 Applicable Software Definitions

When identifying, developing, verifying, and maintaining software, the developer shall apply the following definitions:

- Software is defined as computer programs, procedures, scripts, rules, and associated documentation and data pertaining to the development and operation of a computer system.

Software includes commercial–off-the-shelf (COTS) software, government-off-the-shelf (GOTS) software, modified-off-the-shelf (MOTS) software, custom software, reused software, heritage software, auto-generated code, and code executed on microprocessors.

- Mission Critical Software is software that can cause, contribute to, or mitigate the loss of capabilities that are essential to the primary mission objectives or can damage flight hardware under developments. The software reliability assessment and analysis is focused on failure modes specific to mission ending effects and programmatic threats during Integration and Test, launch and nominal operations.

- Safety-Critical Software is software that can cause, contribute to, or mitigate human safety hazards or damage to facilities. The software safety assessment and analysis is focused on hazards specific to personnel and facility safety during Integration and Test, launch, and re-entry/recovery (where applicable).

* Note: The above definitions for Mission and Safety Critical Software are derived from Safety

Critical as defined by the NASA Software Standard. The delineation is meant only to provide clarification for organizations with separate processes for assessing personnel/facility hazards and mission ending failures/programmatic threats. Both categories of software must comply with the NASA-STD-8719.13 Software Safety Standard, which requires assessment of the entire lifecycle for potential injury, major damage, or mission failure.

5.2 Software Assurance Program

The developer shall plan and implement a Software Assurance Program for mission and safety critical SW. That program shall comply with the definitions in 5.1 and the following documents:

- NASA-STD-8739.8 NASA Standard for Software Assurance

- NASA-STD-8719.13 Software Safety Standard

The developer shall identify the person responsible for directing and managing the software assurance program and interfacing with government assurance personnel.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

The developer shall work with NASA/GSFC to describe the software assurance program in a Software Assurance Plan (MA-24). The plan will address the disciplines of Software Quality, Software Safety, Software Reliability, and Software Verification and Validation (V&V) commensurate with the Software Classification per NPR 7150.2 NASA Software Engineering Requirements, and the project’s risk posture.

5.3 Surveillance of Software Development, Maintenance, and Assurance Activities

The developer shall provide the following:

- Schedule of software development activities and critical milestones

- Schedule of assurance reviews, audits, and assessments of the developer’s processes and products

- Access to the corrective actions from process and product audits

- Access to review action item status and resolution

- Access to the NPR 7150.2 Compliance Matrix

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

6.0 WORKMANSHIP

6.1 General

The developer shall implement a workmanship program to assure that electronic packaging technologies, processes, and workmanship meet mission objectives for quality and reliability per the requirements of the following standards: Note that the vendor may substitute internal processes and procedures that will meet these requirements

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

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

- NASA-STD-8739.6 Implementation Requirements for NASA Workmanship Standards

- GSFC-STD-6001 Ceramic Column Grid Array Design and Manufacturing Rules for Flight

Hardware

- IPC-J-STD-001FS Joint Industry Standard, Space Applications Electronic Hardware

Addendum (except Chapter 10 of IPC-J-STD-001F)

- IPC-2221 Generic Standard on Printed Board Design

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

- IPC-2223 Sectional Design Standard for Flexible Printed Boards

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

Assemblies

- IPC-6011 Generic Performance Specification for Printed Boards (Class 3 requirements)

- IPC-6013 Qualification and Performance Specification for Flexible Printed Boards (Class 3 requirements)

- MIL-PRF-50884F Performance Specification: General Specification For Printed Wiring

Board, Flexible or Rigid-Flex

- IPC-6015 Qualification and Performance Specification for Organic Multichip Module

(MCM-L) Mounting and Interconnecting Structures

- IPC-6018 Qualification and Performance Specification for High Frequency (Microwave)

Printed Boards (Class 3 requirements)

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

Note that the vendor may substitute internal processes and procedures that will meet these requirements

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

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

Assemblies, Space Addendum

The developer shall comply with one of the following standards for rigid printed circuit boards: Note that the vendor may substitute internal processes and procedures that will meet these requirements

- IPC-6012 Qualification and Performance Specification for Rigid Printed Boards, Revisions B through D are acceptable (Class 3 requirements)

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

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

- ECSS-Q-ST-70-10 Qualification of Printed Circuit Boards

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

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

6.2 Design and Process Qualification

The developer shall perform and document qualification of designs and processes that are not covered by or do not conform to the above standards, including the establishment of quality controls and inspections for non-standard configurations and submit a waiver request for government approval.

6.3 Electrostatic Discharge Control (ESD)

The developer shall prepare and implement an ESD control program that conforms to the requirements of ANSI/ESD S20.20 Protection of Electrical and Electronic Parts, Assemblies and Equipment [Excluding Electrically Initiated Explosive Devices].

6.4 Splices, Circuit Board Trace Cuts, and Jumper Wires

The developer shall require approval by the Material Review Board for splices, board trace cuts, or jumper wires that result from repairs or design changes.

6.5 Printed Wiring Board (PWB) Test Coupons and Verification Tests

The developer shall have either GSFC or a GSFC-approved lab evaluate PWB test coupons. The developer may proceed “at risk” to populate PWBs concurrently.

6.6 Lead-Free and Tin Whisker Control Measures

The developers shall submit uses of lead-free solder or surface finishes to the MRB for approval before use.

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

The developer shall conformal coat printed circuit board assemblies to a thickness of at least 0.004 inches.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

7.0 EEE PARTS

7.1 General

The developer shall document and implement a Parts Control Plan (PCP) using Level 3 parts per the requirements of GSFC EEE-INST-002 Instruction for EEE Parts Selection, Screening, Qualification, and De-rating (MA-17). Note that Level 3 parts include (1) Military Specification parts that are equivalent to Level 3 (categories are provided in EEE-INST-002) or (2) Commercial-off-the-shelf parts that are upscreened per the requirements in EEE-INST-002.

The developer may use Military Specification (MIL-SPEC) parts under Defense Logistics Agency (DLA) monitoring without any additional screening, qualification, or part-level testing, subject to GIDEP review and approval.

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

The developer may use plastic-encapsulated microcircuits (PEMs) per the process prescribed in EEE-INST-002, section M4.

7.2 Parts Control Board

The developer shall establish a parts control board (PCB) that is responsible for the planning, management, and coordination of the selection, application, and procurement requirements of EEE parts. The PCB shall assess and identify any additional parts screening, board qualification, analysis and risks appropriate for the TSIS-2 mission.

The GSFC Project Parts Engineer shall be a voting member of the PCB.

7.3 Re-use of EEE Parts

The developer shall require approval of the Material Review Board to re-use EEE parts that have been installed and removed for any reason other than as documented in a plan or procedure.

7.4 As-Built Parts List

The developer shall develop, maintain and deliver a final list of EEE parts that are used in the flight hardware (MA-18).

7.5 Radiation

Effects of radiation shall be mitigated either by the use of radiation-tolerant designs that are substantiated by analyses and testing as needed or by part-by-part radiation hardness or radiation tolerance demonstrated by analyses and testing. Information shall be included in MA-17.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

8.0 MATERIALS AND PROCESSES

8.1 General

The developer shall prepare and implement a materials and processes selection, control, and implementation plan that addresses the Project’s specific launch site and platform requirements and mission risk classification (MA-19).

8.2 Materials Identification and Usage List (MIUL)

The developer shall prepare a materials identification and usage list (MA-20).

Note: Soldering flux shall be included in the MIUL. Solvents used for cleaning flight electronic assemblies other than isopropyl alcohol or deionized water shall be included in the MIUL.

8.3 Non-Destructive Evaluation (NDE) Plan

The developer shall implement a non-destructive evaluation plan for the procedures and specifications used in the inspection of materials per the requirements outlined in NASA-STD-6016 Standard Materials and Processes Requirements for Spacecraft, or comparable vendor practices

(MA-22).

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

9.0 CONTAMINATION CONTROL

9.1 Contamination Control Plan

The developer shall prepare and implement a contamination control program (MA-21).

9.2 Material Outgassing

The developer shall include in MA-21 information regarding material outgassing. Materials will meet requirements of < 1% total mass loss (TML) and < 0.1% collected volatile condensable material (CVCM) at 125C under vacuum for twenty-four hours when tested to ASTM E595 Standard Test Methods for Total Mass Loss and Collected Volatile Condensable Materials from Outgassing in a Vacuum Environment.

9.3 Foreign Object Debris Prevention and Control Program

The developer shall prepare and implement a foreign object debris program (MA-23).

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

10.0 METROLOGY AND CALIBRATION

10.1 Metrology and Calibration Program

The developer shall comply with one of the following standards for the calibration of measuring and test equipment:

- ANSI/NCSL Z540.1-1994 (R2002) Calibration Laboratories & Measuring & Test Equipment

- General Requirements

- ANSI/NCSL Z540.3-2006 Requirements for the Calibration of Measuring and Test Equipment

- ISO 17025-2002 General requirements for the competence of testing and calibration laboratories

10.2 Use of Calibrated and Non-Calibrated Instruments

The developer shall maintain the calibration of test and measuring equipment and safety instruments used for: acceptance testing; inspection; maintenance; flight hardware qualification; measurement where accuracy is essential for the safety of personnel or the public; telecommunication, transmission, and test equipment where exact signal interfaces and circuit confirmations are essential to mission success; development, testing, and special applications where the specifications, end products, or data are accuracy sensitive, including instruments used in hazardous and critical applications.

The developer shall calibrate any article of equipment used to take measurements to meet accuracy requirements within the project to one of the standards in Section 10.1. The developer may calibrate torque wrenches per one of the standards in Section 10.1 or may verify against a calibrated torque tester prior to use. The developer shall record the measurements that require accuracy in applicable project build documents (e.g., WOAs, job orders, task sheets or test plans), including the article of calibrated equipment used to take the measurement and its calibration end date.

The developer is not required to calibrate an article of test and measuring equipment if the accuracy of the equipment’s signals or measurements has been verified to meet minimum requirements against calibrated instruments or intrinsic standards, using a documented measurement procedure.

The developer shall perform verification within a timeframe that has been demonstrated to provide appropriate levels of reliability, in the same facility, and under the same conditions that will be encountered during the process. If this method is employed, the developer shall record the following items in the work order, test plan, or procedure:

- Measurement process or procedure used to perform the verification

- Unambiguous identification of the item(s) being verified (Model/Part Number and

Serial/Asset Number, or in the case of a multi-unit configuration, a Model/Part/Drawing number and configuration listing that provides identification of all verified sub components)

- Measurement parameters that must be verified

- Acceptance limits for each parameter being verified

- Actual measurements at each parameter being verified

- Verification status (pass/fail)

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

- Traceability

- Unambiguous identification of calibrated instruments utilized, including the end date of its calibration, or

- Type and method of verification against an intrinsic standard (examples are ice baths, monochromatic light source, etc.)

The developer shall limit the use of non-calibrated and non-verified instruments to applications where substantiated accuracy is not required or for indication-only purposes in non-hazardous, non-critical applications.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

11.0 GIDEP ALERTS AND PROBLEM ADVISORIES

11.1 Government-Industry Data Exchange Program (GIDEP)

The developer shall participate in GIDEP per the GIDEP Operations Manual (Note: this document is available through http://www.gidep.org).

11.2 Alert Disposition

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

When the developer identifies an item in their design, inventory, or assembly that is documented in an Alert, the developer shall disposition the item and Alert through the Material Review Board as a major nonconformance.

11.3 GIDEP Reporting

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

11.4 Review Reporting

The developer shall report the status of NASA products that are affected by Alerts or by significant EEE parts, materials, and safety problems at monthly status reviews, parts control board meetings, program milestone reviews and readiness reviews. The developer shall include a summary of the review status for EEE parts and materials lists and of actions taken to eliminate or mitigate negative effects.

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

12.0 END ITEM ACCEPTANCE DATA PACKAGE

The developer shall submit an end item acceptance data package (PM-11).

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

Abbreviations and Acronyms

Abbreviations/

Acronyms Definition

ANSI American National Standards Institute ARB Anomaly Review Board ASTM American Society for Testing and Materials CAGE Commercial and Government Entity CCB Change Control Board CCR Change Control Request CDR Critical Design Review CDRL Contract Data Requirements List COTS Commercial Off the Shelf Software CVCM Collected Volatile Condensable Material DID Data Item Deliverable DLA Defense Logistics Agency EEE Electrical, Electronic, and Electro-mechanical ELV Expendable Launch Vehicle ENIG Electroless Nickel Immersion Gold ENEPIG Electroless Nickel Electroless Palladium Immersion Gold EOMP End of Mission Plan ERB Engineering Review Board ESD Electro-Static Discharge ETR Eastern Test Range FAR Federal Acquisition Requirements FMECA Failure Modes, Effects, and Criticality Analysis FOD Foreign Object Debris FTA Fault Tree Analysis GEVS General Environmental Verification Standard GIDEP Government-Industry Data Exchange Program GMIP Government Mandatory Inspection Point GOTS Government Off the Shelf Software GSFC Goddard Space Flight Center HVTL Hazard Verification Tracking Log I&T Integration & Test IPC International trade association for electronic assemblies ISAR Instrument Safety Assessment Report ISO International Organization for Standardization KSC Kennedy Space Center LFCP Lead Free Control Plan M&P Materials and Processes MA Mission Assurance MAR Mission Assurance Requirements

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

Abbreviations/ Acronyms

Definition

MIL Military MIUL Material Identification and Usage List MOTS Modified Off the Shelf Software MRB Material Review Board MUA Material Usage Agreement NASA National Aeronautics and Space Administration NPD NASA Policy Document NPR NASA Procedural Requirement ODAR Orbital Debris Assessment Report OHA Operations Hazard Analysis O&SHA Operating and Support Hazard Analysis OSHA Occupational Safety and Health Administration PCB Printed Circuit Board PCB Parts Control Board PCP Parts Control Plan PDF Portable Document Format PDR Preliminary Design Review PEM Plastic Encapsulated Microcircuit PHA Preliminary Hazard Analysis PSR Pre-Ship Review PWB Print Wiring Board QCM Quartz Crystal Microbalance RPP Reliability Program Plan SAE Society of Automotive Engineers SAP Software Assurance Plan SCoRe Signature Control Request SDP Safety Data Package SEL Single Event Latchup SEU Single Event Upset SPEC Specification SRR System Requirements Review SSPP System Safety Program Plan STD Standard TDMS Technical Data Management System TID Total Ionizing Dose TIM Technical Interchange Meeting TML Total Mass Loss V&V Verification & Validation VTL Verification Tracking Log

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

Applicable Documents

Note: Documents may be applicable with regard to requirements in some instances and cited as references in others.

Note: This list does not reflect the documents that apply to the launch site selection in Section 3.2 Mission Related Safety Requirements Documentation

Document Number Title 500-PG-8700-2.7 Design of Space Flight Field Programmable Gate Arrays 541-PG-8072.1.2 GSFC Fastener Specification

ANSI/ESD S20.20

Protection of Electrical and Electronic Parts, Assemblies and Equipment (Excluding Electrically Initiated Explosive Devices)

ANSI/NCSL Z540.1-1994

(R2002)

Calibration Laboratories & Measuring & Test Equipment - General Requirements

ANSI/NCSL Z540.3-2006

Requirements for the Calibration of Measuring and Test Equipment

Federal Acquisition Regulations

Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5 for government quality assurance requirements at contractor facilities; Part 52.246 for inspection clauses by contract type

GEIA-STD-0005-1

Performance Standard for Aerospace and High Performance Electronic Systems Containing Lead-free Solder

GEIA-STD-0005-2

Standard for Mitigating the Effects of Tin Whiskers in Aerospace and High Performance Electronic Systems

GPR 8730.5

Safety and Mission Assurance Acceptance of Inherited and Build to Print Products

GSFC EEE-INST-002

Instruction for EEE Parts Selection, Screening, Qualification, and Derating

GSFC-STD-6001

Ceramic Column Grid Array Design and Manufacturing Rules for Flight Hardware

GSFC-STD-8002

GSFC Standard Quality Assurance Requirements for the Use of Water Soluble Flux

IPC-2221 Generic Standard on Printed Board Design IPC-2222 Sectional Design Standard for Rigid Organic Printed Boards IPC-2223 Sectional Design Standard for Flexible Printed Boards

IPC-2225

Sectional Design Standard for Organic Multichip Modules (MCM- L) and MCM-L Assemblies

IPC-6011

Generic Performance Specification for Printed Boards (Class 3 requirements)

IPC-6012

Qualification and Performance Specification for Rigid Printed Boards (Class 3 requirements), Revisions B through D are acceptable

IPC-6013

Qualification and Performance Specification for Flexible Printed Boards (Class 3 requirements)

Check the TSIS-2 TDMS Server at https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use.

IPC-6015

Qualification and Performance Specification for Organic Multichip Module (MCM-L) Mounting and Interconnecting Structures

IPC-6018

Qualification and Performance Specification for High Frequency (Microwave) Printed Boards (Class 3 requirements)

IPC-J-STD-001FS

Joint Industry Standard, Space Applications Electronic Hardware Addendum (except Chapter 10 of IPC-J-STD-001F)

IPC/WHMA-A-620-S

Requirements and Acceptance for Cable and Wire Harness Assemblies, Space Addendum

ISO 17025-2002

General requirements for the competence of testing and calibration laboratories

KNPR 8715.3 KSC Safety Practices Procedural Requirements

MIL-PRF-50884F

Performance Specification: Printed Wiring Board, Flexible or Rigid-Flex, General Specification For

MIL-PRF-55110H

Performance Specification: Printed Wiring Board, Rigid, General Specification For

MSFC-STD-3029

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

NAS 412 Foreign Object Damage/Foreign Object Debris (FOD) Prevention NASA-STD-6016 Standard Materials and Processes Requirements for Spacecraft NASA-STD 8719.14 Process for Limiting Orbital Debris, Appendices A and B NASA-STD 8719.24 NASA Expendable Launch Vehicle Payload Safety Requirements with Annex NASA-STD-6016 Standard Materials and Processes Requirements for Spacecraft NASA-STD-8715.7 Expendable Launch Vehicle Payloads Safety Program NASA-STD-8719.9 Standard for Lifting Devices and Equipment NASA-STD-8719.13 Software Safety Standard

NASA-STD-8739.1

Workmanship Standard for Staking and Conformal Coating of Printed Wiring Boards and Electronic Assemblies

NASA-STD-8739.4 Crimping, Interconnecting Cables, Harnesses, and Wiring NASA-STD-8739.5 Fiber Optic Terminations, Cable Assemblies, and Installation NASA-STD-8739.6 Implementation Requirements for NASA Workmanship Standards NASA-STD-8739.8 Standard for Software Assurance NPR 7150.2 NASA Software Engineering Requirements

NPR 8621.1

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

NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program S0300-BT-PRO-010 GIDEP…