C.4 Attachment D_MSR-CCRS-SMA-REQ-0003-_04-09-2021 (1).pdf

Effective Date: April 09, 2021 Expiration Date: April, 09, 2026

Check https://ipdtdms.gsfc.nasa.gov to verify that this is the correct version prior to use

400-FORM-0002 (4/16/2014)

MSR-CCRS-SMA-REQ-0003

Revision -

Mars Sample Return (MSR) Capture, Containment and Return System (CCRS)

NASA/GSFC Code 435

Mission Assurance Requirements (MAR)

Mission Risk Classification – Class A

National Aeronautics and Space Administration

Goddard Space Flight Center Greenbelt, Maryland

MSR-CCRS CMO

April 09, 2021

RELEASED

https://ipdtdms.gsfc.nasa.gov/

MAR MSR-CCRS-SMA-REQ-0003

Effective Date: 04/09/2021 ii

CCRS Mission Assurance Requirements Signature/Approval Page

Prepared by:

Signature on TDMS

Chanel Duncan Date MSR-CCRS Chief Safety & Mission Assurance Officer NASA/GSFC Code 383

Reviewed by:

Electronic Signature

Jonathan Burroughs Date Branch Head NASA/GSFC Code 383

Approved by:

Signature on TDMS

Sridhar Manthripragada Date CCRS Project Manager NASA/GSFC Code 699

Concurred by:

Electronic Signature

Dr. Jesse Leitner Date S&MA Chief Engineer Code 300

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

Preface This document is a Mars Sample Return (MSR) Capture, Contain and Return System (CCRS) Project configuration control board (CCB) controlled document. Changes to this document require prior approval of the CCB Chairperson or designee. Proposed changes shall be submitted in the Technical Data Management System (TDMS) via a configuration change request (CCR) along with supportive material justifying the proposed change.

Changes to this document will be made by complete revision.

All of the requirements in this document assume the use of the word "shall" unless otherwise stated.

Questions or comments concerning this document should be addressed to:

CCRS Configuration Management Office Mail Stop: 435 Goddard Space Flight Center Greenbelt, Maryland 20771 iv

Change History Log

Revision Effective Date Description of Changes (Reference the CCR & CCB/ERB Approval Date)

Revision - 04/09/2021 Released per MSR-CCRS-CCR-0005, 04/07/2021 v

Table of TBDs/TBRs/TBSs [optional]

Action Item No. Location Summary Individual/

Organization Actionee vi

Table of Contents List of Tables ............................................................................................................................ x

1 GENERAL

1.1 Systems Safety and Mission Assurance Program

1.2 Management

1.3 Requirements Flowdown

1.4 Suspension of Work Activities

1.5 Quality Assurance Surveillance

1.6 Government Mandatory Inspection Points (GMIPS)

1.7 Active Suppliers List (ASL)

1.8 Use of Inherited Products/Items

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

3 SYSTEM SAFETY

3.1 General

3.2 Mission Related Safety Requirements Documentation

3.3 System Safety Deliverables

3.3.1 System Safety Program Plan

3.3.2 Safety Requirements Compliance Checklist

3.3.3 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 Lifting Device Safety Requirements

3.3.3.4 Operating and Support Hazard Analysis

3.3.4 Instrument Safety Assessment Report (ISAR)

3.3.5 Verification Tracking Log (VTL)

3.3.6 Hazardous Procedures for Payload I&T and Pre-launch 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 18

4 PROBABILISTIC RISK ASSESSMENT (PRA) AND RELIABILITY

4.1 Reliability Requirements

4.2 Reliability Program Plan (RPP)

vii

4.3 Probabilistic Risk Assessment (PRA)

4.4 FMEA/FMECA and Critical Items List (CIL)

4.5 Fault Tree Analysis

4.6 Parts Stress Analysis

4.7 Worst-Case Analysis

4.8 Reliability Assessments and Predictions

4.9 Trend Analysis

4.10 Analysis of Test Results

4.11 Limited Life Items

4.12 Single Point Failures / Redundant Systems

5 SOFTWARE ASSURANCE

5.1 Applicable Software Definitions

5.2 Software Assurance Program

5.3 Surveillance of Software Development, Maintenance, and Assurance Activities ... 26

6 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 Circuit Board (PCB) Procurement, Test Coupons, and Verification Tests 28

6.6 Use of Water Soluble Flux

6.7 Lead-Free and Tin Whisker Control Measures

7 EEE PARTS

7.1 General

7.2 Parts Control Board

7.3 Re-use of EEE Parts

7.4 Master EEE Parts List

8 MATERIALS AND PROCESSES

8.1 General

8.2 Materials Usage Agreement (MUA)

8.3 Materials Identification and Usage List (MIUL)

8.4 Life Test Plan and Final Report for Lubricated Mechanisms

9 CONTAMINATION CONTROL

9.1 Contamination Control Plan

9.1.A PLANETARY PROTECTION

9.2 Material Outgassing

9.3 Foreign Object Debris Program

10 METROLOGY AND CALIBRATION

10.1 Metrology and Calibration Program

viii

10.2 Use of Calibrated and Non-Calibrated Instruments

11 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 END ITEM ACCEPTANCE DATA PACKAGE

Appendix A. Acronym List Appendix B. Data Item Descriptions

DID 1-1: Mission Assurance Compliance Matrix DID 1-2: active SUPPLIERs LIST (asl) DID 1-3: Use of Inherited products DID 2-1: reporting of MRB actions DID 2-2: Major anomaly Report DID 2-3: Orbital Debris Assessment Report (ODAR) and End of Mission Plan

(EOMP)

DID 3-1: System Safety Program Plan DID 3-2: Safety Requirements Compliance Checklist DID 3-3: Operations Hazard Analysis and Hazard Verification Tracking Log . 48 DID 3-4: Instrument Safety Assessment Report DID 3-5: Hazardous Procedures for Payload I&T and Pre-Launch Processing 52 DID 4-1: Reliability Program Plan DID 4-2 Probabilistic Risk Assessment Support DID 4-3: FMEA/FMECA and Critical Items List DID 4-4: Fault Tree Analysis DID 4-5: Parts Stress Analysis DID 4-6: Worst-Case Analysis DID 4-7: Reliability Assessments and Predictions DID 4-8: Limited Life Items List DID 5-1: Software Assurance Plan DID 5-2: Software Assurance Status Report DID 6-1: Alternate Printed Circuit Board Standard Report DID 6-2: ESD Control Plan DID 6-3: Printed Circuit Board Procurement Plan DID 6-4: Printed Circuit Board (PCB) Coupon Evaluation Report DID 6-5: Lot Acceptance and Quality Conformance Testing Results for Printed Circuit Boards DID 6-6: Use of Water Soluble Flux DID 6-7: Lead-Free Control Plan DID 7-1: EEE Parts Control Plan ix

DID 7-2: Master EEE Parts List DID 8-1: Materials and Processes Selection, Control, & Implementation Plan . 75 DID 8-2: Materials Usage Agreement DID 8-3: Materials Identification and Usage List DID 8-4 Life Test Plan and Final Report for Lubricated Mechanisms DID 9-1: Contamination Control Plan and Data DID 9-2: Foreign Object Debris Prevention and Control plan DID 12-1: End Item Acceptance Data Package

Appendix C. Mission Assurance Compliance Matrix Appendix D. Data Item Description Delivery Requirements Appendix E: Applicable Documents Appendix F: Reference Documents x

List of Tables Table Title Page

4-1 Severity Categories 21 4-2 Likelihood Rankings 22

1 GENERAL

1.1 Systems Safety and Mission Assurance Program

This requirements document is applicable to developers providing hardware and labor efforts to CCRS. The 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 ground support equipment that interfaces with flight items to the extent necessary to assure the integrity and safety of flight items

- The ground data system to the extent necessary to assure performance as required by the Statement of

Work

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

1.2 Management

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

1.3 Requirements Flowdown

The developer shall apply the system safety and mission assurance requirements in this document 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 Quality Assurance Surveillance

The work activities, operations, and documentation performed by the Contractor and sub-tier contractors or suppliers shall be subject to evaluation, review, audit, and inspection by government-designated representatives from GSFC, the Government Inspection Agency (GIA), or an Independent Assurance Contractor (IAC). GSFC will delegate in-plant responsibilities and authority to those agencies via a letter of delegation and task assignment.

The contractor shall grant access for National Aeronautics and Space Administration (NASA) and NASA quality assurance representatives to conduct an audit, assessment, or survey upon notice. The contractor shall supply documents, records, equipment, and a work area within the contractor’s facilities in support of NASA audits, assessments, inspections, or surveys. Resources shall be provided to assist with the assessments/surveys with minimal disruption to work activities.

These assessments, audits, assessments, inspections, or surveys may be performed by NASA Project representatives and/or by NASA Supply Chain Quality representatives at various points over the program/project development lifecycle and will focus on prime and critical/complex sub-tier suppliers across the NASA Goddard Space Flight Center supply chain. Any assessment may require a follow-up visit.

Note: see Federal Acquisition Regulations (FAR) Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5 for government quality assurance requirements at contractor facilities. See FAR Part 52.246 for inspection clauses by contract type.

1.6 Government Mandatory Inspection Points (GMIPS)

The developer shall plan for GMIPS. The developer shall provide work instructions, procedures, drawings, etc.

that are appropriate for the activities. The following are examples of activities that may be subject to GMIPS:

- Circuit card assemblies

- Final solder inspection before conformal coating and staking

- Post conformal coating

- Pre-closure of boxes

- Harness – pre-integration (pre-staking or potting)

- Unit and component level assembly – witness final assembly

- Mechanical – final assembly and acceptance test

- Software acceptance test

- Rework and repairs to flight hardware

This list is for planning purposes. Items may be added or deleted based on the specifics of the development effort.

1.7 Active Suppliers List (ASL)

The developer shall provide a list of active suppliers used for product produced under this contract (DID 1-2).

1.8 Use of Inherited Products/Items

For Inherited Products/Items, defined as those that will be build-to-print (BTP), or rebuilt with modification, or are available as commercial-off-the-shelf (COTS), or were previously developed and exist (e.g., spares), the developer may propose to follow the GSFC Inherited Item Risk Assessment process (DID 1-3).

The developer shall comply with all requirements of the MAR and SOW for the Inherited Product unless specifically relieved by the GSFC project office as a result of the Inherited Item Risk Assessment.

Use of this process does not relieve the developer from meeting contractual performance and functional requirements for the Inherited Product.

2. QUALITY MANAGEMENT SYSTEM

2.1 General

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

2.2 Supplemental Quality Management System Requirements

2.2.1 Control of Nonconforming Product

The developer shall have a documented closed loop system for identifying, reporting, and correcting product nonconformances. 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.

The developer shall provide electronic access to designated local and remote government representatives.

2.2.2 Material Review Board (MRB)

The developer shall have a documented process for the establishment and operation of an MRB to process nonconformances, including the definitions of major and minor nonconformances.

The developer shall appoint an MRB chairperson who is responsible for implementing the MRB process and functional and project representatives as MRB members.

The MRB process shall include a government representative who will be a voting member on MRB actions involving major nonconformances.

The MRB shall provide the government representative with the applicable documentation at least 24 hours in advance of the scheduled MRB meeting.

The developer shall inform the government of MRB actions (DID 2-1).

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

The developer shall provide electronic access to designated local and remote government representatives.

2.2.3 Anomaly Reporting and Disposition

The developer shall have a documented process for anomaly reporting and disposition. The process will establish an anomaly review board (ARB) whose membership will include a government representative as a voting member with approval authority for proposed actions on all major anomalies.

The developer shall submit major anomalies to the ARB and to the government (DID 2-2). The developer shall report major hardware anomalies beginning with the first application of power at the sub-assembly 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 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 developer may disposition minor anomalies with an appropriate subset of the ARB. Minor anomalies are those that 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.

The developer shall provide electronic access to designated local and remote government representatives.

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 (DID 2-3).

3 SYSTEM SAFETY

3.1 General

The developer shall document and implement a system safety program, support the Safety Review Process as defined in Section 3 of NPR 8715.7 Payload Safety Program (https://nodis3.gsfc.nasa.gov/main_lib.cfm), comply with launch service provider requirements, and comply with 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.

https://nodis3.gsfc.nasa.gov/main_lib.cfm

- 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 the launch range safety requirements that are applicable to the launch site. The developer shall implement the most stringent safety requirement in the event there are conflicting requirements.

- NASA-STD 8719.24 (with Annex) NASA Expendable Launch Vehicle (ELV) Payload Safety Requirements, as negotiated by each project with European Sapace Agency (ESA) and GSFC SMA Directorate

- 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 Payload Safety Program

- Launch Site Facility-specific Safety Requirements, as applicable

For European missions:

- NASA-STD 8719.24 (with Annex) NASA Expendable Launch Vehicle Payload Safety Requirements, as negotiated by each project with ESA and GSFC SMA Directorate

- ECSS-E-10A Space Engineering – System Engineering

- ECSS-Q-40-02A Space Product Assurance – Hazard Analysis

- ECSS-Q-40 Space Product Assurance: Safety

- CSG-NT-SBU-16687-CNES Payload Safety Handbook

- CNES/P N°2010-1 of December 2010 Operation of the Guiana Space Centre Facilities

3.3 System Safety Deliverables

3.3.1 System Safety Program 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 (DID 3-1).

3.3.2 Safety Requirements Compliance Checklist

The developer shall document and implement a Safety Requirements Compliance Checklist to demonstrate that the payload complies with NASA and range safety requirements (DID 3-2).

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 Preliminary Instrument Safety Assessment Report (ISAR) (DID 3-4).

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

The developer shall document, implement, and maintain an Operations Hazard Analysis (OHA) and a Hazard Verification Tracking Log (HVTL) to demonstrate that hardware operations, test equipment operations, and integration and test (I&T) activities comply with the safety requirements of the facilities where the activities will be performed and that hazards associated with those activities are mitigated to an acceptable level of risk

(DID 3-3).

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

3.3.3.3 Lifting Device Safety Requirements

The developer shall implement the following safety requirements for lifting devices and equipment (LDE) when performing NASA work at non-NASA facilities:

- Ensure that, for critical lifts, overhead cranes, winches, and hoists have dual holding brakes and dual upper limit switches installed per paragraph 5.4 of NASA Standard 8719.9A Standard for Lifting Devices and Equipment (note: dual upper limit switches do not apply to chain hoists). A single holding brake in combination with a motor drive that automatically tests the holding ability of the brake prior to every release of the brake is equivalent to a second brake if the crane has an audible or visual alarm to alert the operator of a failure in the braking system.

- Label and tag lifting devices and equipment per paragraph 4.9 of NASA-STD-8719.9A.

- Label LDE as having a Safe Working Load (SWL) as determined by the manufacturer or of no more than the applied load if the SWL test is performed at a value lower than that allowed by the manufacturer.

- Perform, per paragraph 4.5 of NASA-STD-8719.9A, a proof test at 100% of the SWL for overhead cranes, mobile cranes, derricks, hooks, hydra-sets, load measuring devices, slings, and rigging, with the following exceptions;

- A proof test at 125% of the SWL for overhead and mobile cranes and for aerial platforms such as scissor or boom lifts that will be used near critical hardware.

- A proof test at 200% of the SWL for shackles, turnbuckles, and similar items.

- Perform SWL proof test every year after the initial test.

- Perform Nondestructive Test (NDT) inspections of critical welds on LDE after initial proof test and load testing (a critical weld is one in which a failure would result in a failure of the hardware). The inspections will be performed by an American Society of Nondestructive Testing (ASNT) or equivalently trained inspector.

3.3.3.4 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 Intermediate & Final ISARs (DID 3-4).

3.3.4 Instrument Safety Assessment Report (ISAR)

The developer shall generate an ISAR to document the comprehensive evaluation of the risk being assumed prior to the testing or operation of an instrument. The spacecraft developer will use the ISAR as an input to the Safety Data Package (SDP) (DID 3-4).

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 with the final ISAR

(DID 3-4).

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

3.3.6 Hazardous Procedures for Payload I&T and Pre-launch Processing

The developer shall document the hazardous procedures that will be implemented when integration and test activities and pre-launch activities are performed at processing facilities and the launch site (DID 3-5).

The developer shall ensure that the procedures comply with applicable facility safety requirements.

The developer shall provide safety support for the implementation of hazardous procedures.

3.3.7 Safety Waivers

The developer shall request waivers for variations from the applicable safety requirements per paragraph 3.5 of NPR 8715.7 Payload Safety Program. The waiver form number is NF1827 (NASA Expendable Launch Vehicle (ELV) Payload Safety Waiver Request. On KSC site, the form is named as “NASA Payload Safety Waiver Request”), which can be downloaded from https://kscsma.ksc.nasa.gov/PayloadSafety/forms.

3.3.8 Mishap Reporting and Investigation

For activities at GSFC, Project Safety and Mission Assurance personnel will provide information as specified in the requirements in GPR 8621.4.

For activities not occurring at GSFC up to and including pre-launch activities, Project Safety and Mission Assurance will prepare and submit a Mishap Preparedness and Contingency Plan (MPCP) in accordance with NASA requirements (NPR 8621.1B).

The developer shall report accidents, test failures, or other mishaps and close calls promptly to NASA.

The developer shall promptly investigate to determine the root cause.

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

The developer shall prepare NASA Expendable Launch Vehicle Payload Safety Forms. These forms will be submitted to ESA if requested.

https://nef.nasa.gov/search?query=NF1827&center=7&center=1 https://nef.nasa.gov/search?query=NF1827&center=7&center=1 https://kscsma.ksc.nasa.gov/PayloadSafety/forms

4 PROBABILISTIC RISK ASSESSMENT (PRA) AND RELIABILITY

4.1 Reliability Requirements

The developer shall implement a Reliability and Risk Assessment Program as specified herein and as referenced in NPR 8705.4, Risk Classification for NASA Payloads, “Class A” requirements and NPR 8705.5 for Technical Probabilistic Risk Assessment (PRA) Procedures for Safety and Mission Success for NASA Programs and Project requirements to ensure that:

a. Probability Risk Assessment (PRA) is used to assess, manage, and quantitatively assess the need to reduce program technical risks;

b. Demonstrate via analysis that redundant functions, including alternative paths and work-a-rounds, are independent to the extent practicable;

c. Demonstrate via analysis that the stress applied to parts are not excessive and meet applicable derating criteria;

d. Identify single failure points , their effect on the attainment of mission objectives, and possible safety degradation;

e. Identify limited-life items and ensure that special precautions are taken to conserve their useful life for on-orbit operations as needed to meet mission requirements;

f. Demonstrate via analysis that the performance margins for electrical/electronic circuits are shown to be commensurate with mission lifetime requirements under worst case conditions;

g. Ensure that the reliability design aligns with mission design life and is consistent among the systems, subsystems, and components;

h. Perform trend analysis on the significant engineering/critical performance parameters during fabrication and pre-launch I&T activities to identify/monitor performance trends;

i. Ensure that the design permits easy replacement of parts and components during ground testing, and that redundant paths are easily monitored.

The developer will provide technical support to the MSR-CCRS Project for the NASA-chaired Reliability Working Group (RWG) meeting and technical reviews, as required. The RWG will meet as necessary, and as convened by NASA, to review Reliability and Risk Assessment requirements and analyses, to assist in resolving reliability issues and concerns, and to discuss any situations that may arise with respect to the overall mission reliability.

The developer shall formally report on the progress of their reliability efforts through the project status reports and management meetings, and provide real-time progress reports to GSFC CCRS Reliability Engineering through informal communications such as teleconferences and e-mails.

Traceability: NPR 8705.4 Risk Classification for NASA Payloads

4.2 Reliability Program Plan (RPP)

The developer shall document and implement a RPP, including the developer’s approach to PRA requirements in section 4.3 using both qualitative and quantitative techniques in accordance with the requirements of NPR

8705.4 for a Class A mission (DID 4-1).

Support rationale and decisions regarding mission success and safety throughout system development shall be documented in DID 4-1.

The RPP shall include a detailed approach to the analysis of hardware and software for their contributions to system reliability and mission success.

Traceability: NPR 8705.4 Risk Classification for NASA Payloads

4.3 Probabilistic Risk Assessment (PRA)

The developer shall provide inputs to the campaign PRA developed in accordance with NPR 8705.4 for a Class A mission and per NPR 8705.5, Probabilistic Risk Assessment (PRA) Technical Procedures for Safety and Mission Success for NASA Programs and Projects (DID 4-2).

At a minimum, campaign PRA inputs shall support the following events of interest (TBR):

a. Loss of Sample Containment

b. Loss of Sample Integrity

The MSR-CCRS Project RPP, MSR-CCRS-SMA-PLAN-0008, will further adjudicate specific campaign PRA inputs required and end states of interest.

Traceability: NPR 8705.4 Risk Classification for NASA Payloads

4.4 FMEA/FMECA and Critical Items List (CIL)

The developer shall perform and maintain FMECAs that address flight hardware and software and ground support equipment that interfaces with flight systems that is being designed, built, or provided from project initiation through launch and mission operations. The developer shall include likelihood, cause, detection and mitigation, and the effects of each failure mode at the local, subsystem, and system or mission levels to the interface level for existing systems and to the box or functional level for modified or new systems (DID 4-3).

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 and 1S per table 4-1 and document applicable failure causes, corresponding mitigations, and retention rationale.

Table 4-1 Severity Categories

Category Severity Description 1 Catastrophic Failure modes that could result in loss of life, or permanently disabling or injuring of personnel, (flight or ground), and/or complete loss of primary mission capability.

[Failure to meet minimum mission success criteria]

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

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

2 Critical Failure modes that could result in major loss or degradation of mission and/or loss of some mission objectives as defined by the GSFC project or causes severe injury or occupational illness but not mission loss.

[Major/Moderate impact to full mission success criteria. Minimum mission success criteria is achievable]

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

3 Significant Failure modes that could cause degradation to mission objectives.

[Moderate/Minor impact to full mission success criteria. Minimum mission success criteria is achievable with margin]

4 Minor Failure modes that could result in insignificant or no loss to mission objectives [No impact to full mission success criteria]

The developer shall identify and assess any known common cause failure modes and causes for category 1R and 2R items.

The developer shall identify and address safety-critical software, as defined in NASA-STD-8719.13.

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

Table 4-2 Likelihood Rankings

Results of the FMECA shall be used to evaluate the design relative to requirements (e.g., no single payload failure will prevent removal of power from the payload).

Identified discrepancies shall be evaluated by management and design groups for assessment of the need for corrective action.

FMECA results shall be presented at the Preliminary Design Review (PDR) and Critical Design Review

(CDR).

Traceability: NPR 8705.4 Risk Classification for NASA Payloads

4.5 Fault Tree Analysis

The developer shall perform and maintain qualitative fault tree analyses (FTA) to address PRA end states, mission failure, and/or degraded modes of operation (DID 4-4).

Fault tree analyses shall address both hardware and software contributions to analyzed scenarios and identify cut sets of interest and risks.

The developer shall quantify FTAs to support limited scope campaign PRA or in lieu of a PRA to support specific end-states of interest risk assessments (DID 4-4).

The results of the FTA shall be presented at system-level reviews and made available electronically to GSFC upon request.

The developer shall update the FTA throughout the development life cycle to address the design changes and changes to corresponding faults, fault consequences, fault logic, and/or fault propagation scenarios.

GSFC SMA will adjudicate FTA and FMECA needs based on equipment type (mechanical, electronic, electrical, electro-mechanical, etc.) in support of campaign Fault Protection efforts.

Traceability: NPR 8705.4 Risk Classification for NASA Payloads, Appendix C

4.6 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 (DID 4-5).

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

If alternate derating guidelines are requested to be used, they must be submitted to the CCRS Parts Control Board for approval.

Traceability: NPR 8705.4 Risk Classification for NASA Payloads, Appendix C

4.7 Worst-Case Analysis

The developer shall perform worst-case analyses (WCA) for performance critical or functionally critical components for which excessive operating variations could compromise mission performance to assure the design meets critical performance and life requirements (DID 4-6).

Elements that may warrant worst case analysis may include: resets, clocks, interfaces, power phase and gain margins, control loops that require adequate phase and gain margin to operate properly, sensitive analog circuitry, power supply or switching circuitry, motor and actuator systems, electro-mechanical elements that require torque margin to operate over life and environmental variations.

Adequate margins in electronic circuits and electro-mechanical devices can be verified by analysis, testing or both.

When verification by analysis is used, the analyses shall consider all parameters at worst case limits and worst case environmental conditions for the parameter or operation being evaluated.

Similarly, when verification by testing is used, the testing shall be conducted to provide as direct a measure as possible of the critical performance or function while the element is subjected to worst-case parameter variations.

This analysis shall be made available for MSR-CCRS Project review.

The results of any analyses shall be presented at all design reviews starting with the CDR.

Traceability: NPR 8705.4 Risk Classification for NASA Payloads, Appendix C

4.8 Reliability Assessments and Predictions

The developer shall perform comparative numerical reliability assessments and reliability predictions (DID 4-7) to:

a. Evaluate alternative design concepts, redundancy, cross-strapping approaches, and part substitutions

b. Identify the elements of the design that are the greatest detractors of system reliability

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

d. Assist in evaluating the ability of the design to achieve the mission life requirement and other reliability goals and requirements as applicable

e. Evaluate the impact of proposed engineering change and waiver requests on reliability

f. Assure that the specified reliability (probability of success) is achieved in accordance with the Mission

Requirements Document

Traceability: NPR 8705.4 Risk Classification for NASA Payloads, Appendix C

4.9 Trend Analysis

The developer shall prepare and maintain a list of subsystems and components for which trend analysis will be performed, including the parameters to be monitored.

The developer shall begin the monitoring, collection and analysis at subsystem and component acceptance testing and continue through system integration and test phase.

The developer shall prepare a report that includes the trending data.

Trend data shall be recorded and maintained (DID 12-1).

Traceability: NPD 8720.1, NASA Reliability and Maintainability Program Policy, paragraph 5 NPR 8705.4 Risk Classification for NASA Payloads, Appendix C

4.10 Analysis of Test Results

The developer shall document the analysis of test information, trend data, and failure investigations to assess reliability and identify potential or existing problem areas.

The developer shall prepare a report that includes the analysis results.

Traceability: NPD 8720.1 NASA Reliability and Maintainability Program Policy, paragraph 5

4.11 Limited Life Items

The developer shall prepare and implement a plan to identify and manage limited life items, including moving mechanical components and bonded joints as applicable (DID 4-8).

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

The use of an item whose expected life is less than its mission design life must be approved by MSR-CCRS Project by means of a program waiver.

Note: The useful life period starts with fabrication and ends with the completion of the mission.

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.

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 project activity that will stress the items.

Limited-Life Items List shall be presented at PDR, CDR, and the PSR.

Traceability: NPD 8720.1, NASA Reliability and Maintainability Program Policy, paragraph 5

4.12 Single Point Failures / Redundant Systems

Single Point Failures (SPFs) for all hardware and software that performs mission-critical functions shall be identified, and the risk associated with each characterized, managed, and tracked.

When redundant systems or functions are implemented for risk mitigation, the redundant components, or functional command paths shall be independent, such that the failure of one component or command path does not affect the other component or command path.

Traceability: GSFC-STD-1000 Goddard Open Learning Design (GOLD) Rules, rule 1.25

5 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 processors embedded in programmable logic devices.

- Mission-Critical Software - Software that can cause, contribute to, or mitigate the loss of capabilities that are essential to the primary mission objectives. The software reliability assessment and analysis is focused on failure modes specific to post-separation mission phases.

- Safety-Critical Software - 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 Integration and Test, launch, and up through spacecraft separation from the launch vehicle

(except for International Space Station (ISS) payloads that have constant human presence) and re-entry/recovery (where applicable).

Note: The definitions for Mission and Safety Critical Software are provided as clarification for organizations with separate processes for assessing pre-separation and post-separation hazards and failures. Both categories of software must comply with the NASA-STD-8739.8A Software Assurance 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 that complies with the definitions in 5.1 and:

- NASA-STD-8739.8A NASA Standard for Software Assurance and Software Standard

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

The developer shall document the software assurance program in a Software Assurance Plan (DID 5-1). The plan will address the disciplines of Software Quality, Software Safety, Software Reliability, Software Verification and Validation (V&V), and Independent Verification and Validation (IV&V) and detail the role of assurance and their activities in ensuring quality products and processes for each discipline. The plan will include the software assurance processes, procedures, tools, and techniques to be used commensurate with the Software Classification Assessment. The plan will address the necessary collaboration between software assurance, system safety, system reliability, and software engineering.

5.3 Surveillance of Software Development, Maintenance, and Assurance Activities

The developer shall provide the following:

- Direct access to the software problem reporting system

- Electronic access to the software documentation (i.e., management plans, assurance plans, configuration management plans, requirements specifications, design documents, test plans, test cases, test procedures, test results, schedule, maintenance plans)

- Electronic access to the software review results

- Electronic access to source code

- 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 monthly software measurement and metrics data prepared per the requirements of NPR

7150.2 NASA Software Engineering Requirements

- Access to requirements traceability matrices and data prepared per the requirements of NPR

7150.2 NASA Software Engineering Requirements

- Software Assurance Status Report (DID 5-2)

6 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:

- 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-001xS Joint Industry Standard, Space Applications Electronic Hardware Addendum

(except Chapter the chapter on “COATING, ENCAPSULATION AND STAKING (ADHESIVE)”). x is the lastest revision number.

- 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: Printed Wiring Board, Flexible or Rigid-Flex, General Specification For

- 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:

- 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:

- IPC-6012 Qualification and Performance Specification for Rigid Printed Boards, Revisions B and later are acceptable (Class 3/A requirements are required for Revisions B and C; IPC-6012DS and IPC-6012ES addendum is required for Revisions D and E), with a preference for D or later. IPC- 6012 Revs B and C should only be used to avoid changes to pre-existing drawings. Boards that show evidence of copper wrap are acceptable without meeting the copper wrap requirments in the applicable specifications.

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

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

The specification and subsequent class followed will be As Agreed Between User and Supplier. (AABUS) as determined from a discussion between the developer, the board manufacturer, and the GSFC PCB CRAE.

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 (DID 6-1).

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.

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) (DID 6-2).

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 Circuit Board (PCB)…