Att_D_422-L1-IMAR-0004_Ver0.1_-_Signed.pdf

Effective Date: Oct. 3, 2019 422-L1-IMAR-0004

Expiration Date: Oct. 2, 2024 Version 0.1

Responsible Organization: SWFO-L1/Code 422

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

National Aeronautics and Space Administration

Goddard Space Flight Center

Greenbelt, Maryland

422-L1-IMAR-0004

Version 0.1

Space Weather Follow On - Lagrange 1 (SWFO-L1)

Code 422

SWFO-L1

Instrument Mission Assurance

Requirements

(IMAR)

Mission Risk Classification – Class C https://goessp.ndc.nasa.gov/

SWFO IMAR 422-L1-IMAR-0004

ii

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

SWFO-L1 Instrument Mission Assurance Requirements Document

(IMAR)

Signature/Approval Page

Prepared by:

Sue Pollard Date

SWFO-L1 Chief Safety & Mission

Assurance Officer NASA/GSFC, Code 383

Reviewed by:

Ronald J. Hooker Date

SWFO-L1 Instrument Systems Manager

NASA/GSFC, Code 422

Approved by:

Gene Martin Date

SWFO-L1 Project Manager

NASA/GSFC, Code 422

Concurred by:

Jesse Leitner Date

Safety & Mission Assurance Chief Engineer

NASA/GSFC, Code 300 iii

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

CM FOREWORD

This document is a Space Weather Follow On - Lagrange 1 (SWFO-L1) Project Configuration

Management (CM)-controlled document. Changes to this document require prior approval of the applicable Configuration Control Board (CCB) Chairperson or designee. Proposed changes will be submitted to the SWFO CM Office (CMO), along with supportive material justifying the proposed change. Changes to this document will be made by complete revision.

Questions or comments concerning this document should be addressed to:

NASA/Goddard Space Flight Center

SWFO-L1 Project Office, Code 422

Attention: Configuration Management Office

Greenbelt, Maryland 20771 iv

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

Change History Log

REV

LEVEL

DESCRIPTION OF CHANGE APPROVED

BY

DATE

APPROVED

0.0 Sept 5, 2019

0.1 Added CDRL 74 reference to Section 1.8 Oct 3, 2019

v

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

Table of TBDs/TBRs/TBSs

Action

Item No.

Location Summary

Individual/

Organization

Actionee vi

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

Table of Contents

1 GENERAL

1.1 Systems 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 List of Suppliers

1.8 SMA Acceptance of Inherited, Build-To-Print, or Modified Heritage 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)

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

4.1 Reliability Program

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

4.3 Parts Stress Analysis

4.4 Limited Life Items

4.5 Worst-Case Analysis

5 SOFTWARE ASSURANCE

5.1 Applicable Software Definitions

vii

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

5.2 Software Assurance Program

5.3 Surveillance of Software Development, Maintenance, and Assurance Activities

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

6.6 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 Non-destructive Evaluation (NDE) Plan

9 CONTAMINATION CONTROL

9.1 Contamination Control Plan

9.2 Material Outgassing

9.3 Foreign Object Debris Program

10 METROLOGY AND CALIBRATION

10.1 Metrology and Calibration Program

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: ABBREVIATIONS AND ACRONYMS

APPENDIX B: MISSION ASSURANCE COMPLIANCE MATRIX

APPENDIX C: DATA ITEM DESCRIPTION LIST

APPENDIX D: APPLICABLE DOCUMENTS

APPENDIX E: REFERENCE DOCUMENTS

viii

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

List of Tables

Table Title Page

1-1 Inherited Product Data Requirements

1-2 Inherited Product Supplementary Information

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

1 GENERAL

This Instrument Mission Assurance Requirements (IMAR) document will be applied to the three

SWFO instruments being procured by NASA GSFC for the project:

- Solar Wind Instrument Suite (SWiPS)

- Magnetometer (MAG)

- Supra Thermal Ion Sensor (STIS).

The following instruments are also manifested on the SWFO L1 mission, but are contributed by

NOAA or other parties and as such will be covered by a “Do No Harm” mission assurance approach and are therefore not covered by this IMAR:

- Compact Coronagraph (CCOR),

- One or more potential Instrument of Opportunity (IOOs).

1.1 Systems Safety and Mission Assurance Program

NOTE: The term Developer is the equivalent of Contractor in the associated SOW, CDRL, and other procurement documents.

The Developer shall implement a safety and mission assurance program that is consistent with contractual requirements. The mission assurance program shall cover:

- Flight hardware, critical Ground Support Equipment (GSE) 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 (CDRL 108).

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 manager shall have direct access to management that is independent of project management and the functional freedom and authority to interact with all elements of the product be provided to the government.

1.3 Requirements Flow Down

The Developer shall apply system safety and mission assurance requirements to subcontractors and suppliers to the extent necessary as agreed to between the government and Developer to ensure that the delivered product meets performance requirements.

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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 grant access for National Aeronautics and Space Administration (NASA) and NASA assurance representatives to conduct an audit, assessment, or survey upon notice.

The Developer shall supply documents, records, equipment, and a work area within the

Developer’s facilities.

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 grant access for NASA and NASA assurance representatives to conduct an audit, assessment, or survey. The Developer shall supply documents, records, equipment, support personnel, and a work area within the Developer’s facilities.

NASA has the right to specify Government Mandatory Inspection Points (GMIPs) as applicable.

The Developer should provide documentation indicating both Project and subcontractor workflow to NASA with any planned inspection points to facilitate efficient assignment.

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;

and furthermore, in response to events, such as failures, anomalies, and process shortfalls that prompt a need for further inspection.

NASA will coordinate the scheduling of any NASA-directed audits and inspections with the

Developer (at Developer and Subcontractor facilities) to the greatest extent possible in order to maximize efficiency and minimize impact to schedule.

1.7 List of Suppliers

The Developer shall provide a list of suppliers used for product produced under this contract

(CDRL 109).

1.8 SMA Acceptance of Inherited, Build-To-Print, or Modified Heritage Items

For products that have either been previously developed and exist (e.g., spares), or will be built-to-print (BTP) or are commercial-off-the-shelf (COTS), the Developer may follow an inherited items review process, in which NASA will perform an inheritance risk assessment on the

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

selected Developer’s heritage products, as an alternative to pursuing waivers to requirements in other sections of this IMAR document. This process establishes a potential risk and consequence for using the item and may avoid routine waiver processing, based on the established prior history, the change in the design, environment, or operations, and the information provided about the processes used to develop the product. The risk determined shall be primarily based on prior usage, changes, and the approach to changes in standard products. Just as with waivers, NASA determines whether risks are acceptable or if mitigations are required. The Developer shall assume ownership and responsibility for mitigation of any such risks. The risks that are determined from the inheritance risk assessment shall be brought in to the project risk board for disposition.

If the Developer elects to pursue this process in lieu of other requirements in this IMAR to cover internal attributes of an inherited item, the Developer should provide sufficient data from Table

1-1 and 1-2 to substantiate the item as a product that is at a level of risk commensurate with the

Class C risk posture. After the first deliverable package (CDRL 074), NASA has 30 days to review the package and provide a recommendation to the Developer as to whether the risk is likely to be acceptable for each item based on the prior history combined with the availability of other options to provide the pertinent function. Table 1-1 is typically considered the minimum information set needed to characterize the risk of the current application of the item based on its history, while additional information from Table 1-2 should be provided as available to further reduce the risk to NASA. The Developer shall provide the initial Inherited Items package at 60 days after contract award and the final package at SDR + 60 days. Inherited components should demonstrate at least 50 hours of failure-free testing for each year of required operation on orbit to mitigate infant mortality concerns.

Use of this process does not alleviate the Developer from meeting spacecraft/observatory technical functional or performance requirements.

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

Table 1-1. Inherited Product Data Requirements

No. Data Needed for Inherited Products

List of inherited products and statement of approach to use – rebuild, modification of previous build, or use of existing product

Summary results of qualification, acceptance, and/or prototype/proto-flight testing completed, or comparison of current qualification/proto-qualification requirements and what was performed/realized on the inherited design, including environments, required design margins, and life

Flight history of the products and specific attributes for each flight, including environments (compare previous environment to current, including duty cycle and general concept of operations)

Ground and on-orbit anomaly and failure history including the determination of root causes or information that root cause was not determined. Ground anomalies may be restricted to major anomalies, where component performance requirements were violated

5 Reliability analyses performed for the most recent version of the product

Identification of significant changes in manufacturing from qualified product to current product (facility, process, sub-tier supplier, testing changes, company change of ownership, etc.), and any changes in design or materials, including electronic parts, printed circuit boards, and standards used (changing from an older revision of a standard to the latest revision need not be discussed).

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

Table 1-2. Inherited Product Supplementary Information

No. Supplement Information for Inherited Product

Deviations of each product from original design (white wires, cut traces, splices, etc., if not objectively clear to be part of the design) and reasons for each deviation. If the design has been qualified on a previous GSFC project in the same environment and same risk posture, then the deviations may be declared relative to the previously qualified design.

Specifications and/or standards used to develop the products (e.g., IPC, J-STD, NASA, or GSFC requirements, including fastener integrity approach, or company standards). For products with minimal prior flight history, company standards or detailed synopses of such should be provided, if such are used to develop the product

Previous as-built parts list, including lot date codes, and the differences for new inherited item. This should include evidence that Government Industry Data

Exchange Program (GIDEP) alerts and advisories have been properly dispositioned, if the parts have already been procured. Note that GIDEP should always be used as an aid in procuring new parts or pulling parts from inventory. Reference to prior project deliveries to GSFC is acceptable, in which case, an amendment may be delivered to indicate any changes

Known obsolete parts that will be supplied from existing inventory, including the quantity required and the quantity available. If available, include the sparing plan (quantity required, quantity available, and sparing philosophy)

Materials list and approved Material Usage Agreements (MUAs). Materials list includes lot date codes and evidence that GIDEP alerts and advisories have been properly dispositioned, if the materials have already been procured. Such evidence should be encompassed in GIDEP closure records for each of the items that have impacts. Reference to prior project deliveries to GSFC is acceptable, in which case, an amendment may be delivered to indicate any changes

List of major electrical and mechanical analyses completed and summary of results

2 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

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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.

2.2.2 Material Review Board (MRB)

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

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 on all major MRBs involving procured hardware. The government representative shall be supplied with the applicable documentation 24 hours in advance of the scheduled MRB. The Developer shall inform the government of MRB actions (CDRL 110).

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 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 nonconformances.

The Developer shall submit major anomalies to the ARB and to the government (CDRL 101).

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

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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 sub-assembly 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 (CDRL 111).

3. SYSTEM SAFETY

3.1 General

The Developer shall document and implement a system safety program, support the ELV Safety

Review Process as defined in paragraphs 2.4 of NPR 8715.7 Expendable Launch Vehicle

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

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

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

The Developer shall implement launch range safety requirements applicable to the launch site.

The Developer shall implement the most stringent safety requirement in the event there are conflicting requirements.

ELV Eastern Test Range (ETR) or Western Test Range (WTR) Missions

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

- 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 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 (CDRL 077).

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 (CDRL

112).

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

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

eliminate hazards or reduce their associated risk to an acceptable level.

The Developer shall deliver the PHA with SDP I (CDRL 113).

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 facility safety requirements and that hazards associated with those activities are mitigated to an acceptable level of risk (CDRL 081).

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 four years after the initial test.

- Perform 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 Non-destructive Testing (ASNT) or equivalently trained inspector.

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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 SDP II and SDP III (CDRL 113).

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 (CDRL 113).

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 SDP III (CDRL 113).

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 (CDRL 114).

The Developer shall document hazardous procedures that will be implemented when performing

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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.

3.3.8 Mishap Reporting and Investigation

The Developer shall prepare a Pre-Mishap Plan (CDRL 082) that describes appropriate mishap and close call notification, reporting, recording, and investigation procedures in accordance with

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

The Developer shall report accidents, test failures, or other mishaps and close calls promptly

(within 24 hours) to NASA.

The Developer shall promptly investigate so as to determine the root cause.

A follow-up report shall be documented in accordance with NPR 8621.1, NASA Procedures and

Requirements for Mishap Reporting.

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

The Developer shall prepare NASA Expendable Launch Vehicle Payload Safety Forms. The forms are available at URL http://kscsma.ksc.nasa.gov/ELVPayloadSafety/Forms

4 RELIABILITY

4.1 Reliability Program

The shall Developer execute a reliability analysis program that identifies failure risks and mitigations strategies for a 5 year and 10 year mission concurrently with design and effectively integrated with knowledge and models from other project disciplines, including engineering, hardware design, software reliability, systems safety, and mission assurance.

The Developer shall perform the analyses specified in the remainder of this section in order to https://kscsma.ksc.nasa.gov/PayloadSafety/forms https://kscsma.ksc.nasa.gov/PayloadSafety/forms

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

evaluate mission risks and if additional reliability analysis techniques (e.g., RBD/prediction, FMEA Functional, Design, or Process), and/or WCA) will be used to supplement these when needed.

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 in terms of propagation, failure protection, mitigation/detections, and interactions (CDRL

083). Specifically 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.

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 flight or ground systems.

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 loss of one or more mission objectives as defined by the GSFC project or causes severe injury or occupational illness.

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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.

4 Minor Failure modes that could result in insignificant or no loss to mission objectives

Table 4-2: Technical Likelihood

4.3 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 (CDRL 115) new or modified critical circuits.

4.4 Limited Life Items

The Developer shall prepare a list of potential limited life items (including but not limited to:

selected consumables; structures; mechanisms; batteries; seals; thermal control surfaces; solar arrays; and, electromechanical mechanisms) 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. (CDRL 087)

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

4.5 Worst-Case Analysis

The Developer shall perform worst-case analyses (WCA) for circuits that are identified by other analyses as critical or mission success risks (CDRL 084).

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 microprocessors.

- 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 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 that complies with the definitions in 5.1 and:

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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

The Developer shall document the software assurance program in a Software Assurance Plan

(CDRL 075). The plan will address the disciplines of Software Quality, Software Safety, Software

Reliability, Software Verification and Validation (V&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 software assurance 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 requirements traceability matrices and data prepared per the requirements of NPR 7150.2 NASA Software Engineering Requirements

- Software Assurance Status Report

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

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

- 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: 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 through D are acceptable (Class 3 requirements)

- 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 (CDRL 116). 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.

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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

The Developer shall deliver PCB procurement information for printed circuit boards that meet specific design and complexity criteria. (CDRL 117).

The requirement for PCB test coupon evaluation at Goddard is optional. When PCB coupons are submitted to GSFC or any other third party Lab, the Developer may “at risk” populate PCB concurrently or after the printed circuit board structural integrity coupons are inspected by the

Lab.

The Developer shall deliver PCB lot acceptance and quality conformance verification test results

(CDRL 118).

6.6 Lead-Free and Tin Whisker Control Measures

The Developer shall address the requirements of GEIA-STD-0005-1 and GEIA-STD-0005-2 for solders and surface finishes that are less than 3% lead by weight. The Parts Control Plan shall comply with the Level “2C" requirements set.

The Developer shall conformal coat printed circuit board assemblies to a thickness of at least

0.004 inches.

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

7 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 (CDRL 088).

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 Military specification parts with prior flight history without additional screening or qualification tests.

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 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 MRB to re-use EEE parts that have been installed and removed other than as planned and designed.

7.4 Master EEE Parts List

The Developer shall develop and maintain a Master EEE Parts List (CDRL 089).

8 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 (CDRL 119).

8.2 Materials Usage Agreement (MUA)

The Developer shall prepare materials usage agreements (CDRL 091).

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

8.3 Materials Identification and Usage List (MIUL)

The Developer shall prepare a materials identification and usage list (CDRL 120).

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.4 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 outlines in NASA-STD-

6016 Standard Materials and Processes Requirements for Spacecraft.

9 CONTAMINATION CONTROL

9.1 Contamination Control Plan

The Developer shall prepare and implement a contamination control program (CDRL 038).

9.2 Material Outgassing

The Developer shall include in CDRL 038 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. The Developer shall perform contamination analyses to demonstrate that contamination requirements will be met.

9.3 Foreign Object Debris Program

The Developer shall prepare and implement a foreign object debris program (CDRL 121).

10 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

Check the SWFO-L1 Portal at (UPDATE) https://goessp.ndc.nasa.gov to verify correct version prior to use.

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…