L1 Series COR MAR Rev 11-8-2023.docx

L1 Series Project Coronagraph MAR L1SERIES-COR-REQ-0019, Rev - Effective Date:

GSFC SW Next L1 Series CMO

L1SERIES-COR-REQ-0019, Revision- L1 Series Project, Code 493

Space Weather Next (SW Next) Lagrange 1 (L1) Series Project Coronagraph Mission Assurance Requirements (MAR)

Mission Risk Classification – C

U.S. Department of Commerce (DOC) National Oceanic and Atmospheric Administration (NOAA) National Environmental Satellite, Data, and Information Service (NESDIS) National Aeronautics and Space Administration (NASA) Effective Date:

Expiration Date:

L1 Series Project Coronagraph MAR L1SERIES-COR-REQ-0019 Effective Date:

Check the L1 Series CM tool Server at https://ipdtdms.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

ii

Check the L1 Series CM tool Server at https://ipdtdms.gsfc.nasa.gov/frontmenu_dsp.cfm to verify that this is the correct version prior to use.

L1 Series Coronagraph Mission Assurance Requirements (MAR) Signature/Approval Page Prepared by:

David Bogart L1 Series Project Chief Safety and Mission Assurance Officer (CSO) SW Next L1 Series NASA Goddard Space Flight Center

Reviewed By:

Charles Hudson DeLee L1 Series Instrument Systems Manager SW Next L1 Series

Approved By:

J. Timothy Van Sant Project Manager, SW Next L1 Series

Preface This document is a L1 Series Project signature-controlled document. Changes to this document require prior approval by the SW Next L1 Project Configuration Control Board (CCB) Chairperson or designee. Proposed changes shall be submitted in the L1 Series Project Technical Data Management System (TDMS) via a Signature Control Request (SCoRe) 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:

L1 Series Project Configuration Management Office Mail Stop: 493.0 Goddard Space Flight Center Greenbelt, Maryland 20771

Change History Log

(Reference the CCR & CCB/ERB Approval Date)

Table of Contents

List of Tables

Document Organization and Conventions This document establishes a risk-based application of mission assurance requirements for a Class C free flyer payload. It is organized around the following Safety and Mission Assurance (SMA) disciplines or focus areas, each with its own section:

Each discipline or focus area is further decomposed into subsections associated with its individual SMA activities or deliverables, e.g., within Section 2.2, “Quality Management System”, subsection 2.2.2 flows down the specific requirements for operating a “Material Review Board.” In instances where the risk classification does not warrant the flow down of specific SMA process/product standards, that section or subsection has been identified as “not applicable,” and the developer is expected to apply their internal standards, without government oversight.

In this document, a specific requirement is denoted by “shall,” a good practice by “should,” permission by “may,” and an expectation by “will.”

The requirements in this document use the following identification convention:

SMA Discipline_Numeric Identifier

Ex. QMS_01

The key to the requirement identification is as follows:

Note: The contents of this Mission Assurance Requirements (MAR) document are the result of tailoring from a master set of requirements. Consequently, there may be instances where jumps or gaps occur in the numbering sequence of requirement IDs and DIDs. Due to the tailoring, there may also be sections that are not applicable, and have thus been marked “RESERVED.” This is done intentionally to preserve the organization of the document and to facilitate tracking of data from implementation of requirements.

Requirements that have an associated Contract Data Requirements List (CDRL) item are denoted with the CDRL item number of MA x-y, where MA indicates a Mission Assurance CDRL item, x is the section referenced in this MAR document, and y is a sequential item number.

1. GENERAL

Systems Safety and Mission Assurance Program GEN_01: 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

GEN_02: The developer shall submit a compliance matrix that identifies variance and acceptance rationale for processes, procedures, and standards that are proposed as alternatives to those specified by the contract (CDRL MA 1-1). This includes identification of requirements for which relief is requested via the Inherited Item Risk Assessment process (see Section 1.9 “Use of Inherited Products/Items”).

Management GEN_03: The developer shall designate a manager for all assurance activities. The assurance manager shall not be responsible for project costs and schedules other than those pertaining to assurance activities.

GEN_04: The developer shall ensure that the assurance manager has direct access to upper management that is independent of project management, with functional freedom and authority to interact with all elements of the project.

Requirements Flow down GEN_05: The Developer shall ensure flow down of SMA requirements to all suppliers based on the work to be performed and establish a process to verify compliance, with the exception of those approved for relief via the Inherited Item Risk Assessment process (see Section 1.9 “Use of Inherited Products/Items”).

GEN_06: The Developer’s contract review and purchasing processes shall indicate the method for documenting, communicating, and reviewing requirements with sub-tier suppliers to ensure requirements are met and information on discrepancy reports is communicated.

GEN_07: The Developer shall ensure that quality plans, processes, procedures, hardware, and software submitted by the Developer’s sub-tier suppliers are compliant with the requirements in this MAR and adequately communicated, as applicable.

Identification of Project-Level Critical Items (PCIs) GEN_08: The Developer shall identify its critical items for incorporation into the Project-Level Critical Items (PCIs) developed in accordance with NPR 8735.2, Section 4.1.4 “Critical Items and Processes Determination”.

GEN_10: Identification of critical items and processes should include the results of system safety and reliability analyses.

Suspension of Work Activities GEN_11: The developer shall direct the suspension of any work activity that presents an unsafe work condition to personnel or imminent danger to property.

Surveillance GEN_12: The developer shall provide access to quality management system documentation, information systems and work products or artifacts to National Aeronautics and Space Administration (NASA) representatives.

GEN_13: The work activities, operations, and documentation performed by the Contractor and sub-tier contractors or suppliers shall be subject to evaluation, review, audit, inspection, and survey by NASA representatives at various points over the program or project development lifecycle.

GEN_14: In accordance with Federal Acquisition Regulations (FAR) 46.103, 46.104, 46.202-2, 46.4, and 46.5, the developer shall grant physical or remote access to NASA representatives to conduct an on-site and/or remote audit, assessment, or inspection upon notice. A 30-day notice will be provided to the supplier or developer prior to the start of an audit or assessment. The supplier or developer shall supply personnel, documents, records, equipment, and an acceptable work area within the developer’s facilities to assist with the audit, assessments, or inspections.

GEN_15: The developer shall report the status of facility operations and quality metrics to NASA on a quarterly basis. This should include the following data for 1st tier and 2nd tier suppliers of project-defined critical items:

· Quality escapes - Any product released by an internal or external supplier that is subsequently determined to be nonconforming to contract and/or product specification requirements.

· First Pass Yield - A measure of quality in a process that reflects the percentage of product made correctly without any rework or corrective activity.

· Supplier Defect Rate - The supplier defeat rate measures the percentage of materials or product received from suppliers that do not meet required or compliance specifications.

· Internal Audit results Government Mandatory Inspection Points (GMIPs) GEN_16: For cost plus projects, the developer shall provide a proposed GMIP plan, which will be used by the government in determining the final GMIPs that will be conducted. NASA Procedural Requirements (NPR) 8735.2 “Hardware Quality Assurance Program Requirements for Programs and Projects” may be used as a guide.

Typical GMIPs include:

a. Inspect Circuit Card Assemblies (CCAs), harnesses, connectors, etc. prior to staking/conformal coating process (solder, crimps, handling, and overall workmanship).

b. Inspect CCAs for proper staking and conformal coating.

c. Pre-Cap inspection of Hybrid Components

d. Perform a pre-closure inspection of flight components (e.g., box, subsystem, structure) prior to the start of acceptance testing for configuration verifications and general mechanical and electrical workmanship.

e. Inspect flight harnesses for compliance to NASA-STD-8739.4

f. Review of purchase orders and statements of work on components/subsystem elements for proper requirements flow-down

g. Packaging, packing, shipping, and storage of flight products pre-shipment, and receiving of Government Furnished Equipment (GFE).

h. Witness and verify fastener torquing involving flight hardware.

i. Witness and inspect mates and demates of all flight connectors.

j. Verify test setups.

k. Witness and inspect any additional items or processes identified by the Government as areas of concern due to perceived risk.

GEN_19: Prior to the start of manufacturing, the developer shall provide work instructions, procedures, drawings, etc. that are required for performing the planned inspections.

List of Suppliers GEN_20: The developer shall provide a list of suppliers used for product produced under this contract (CDRL MA 1-2).

Use of Inherited Products/Items GEN_21: 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 processes documented in GPR 8730.5 “Safety and Mission Assurance Acceptance of Inherited and Build-to-Print Products”.

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

Protection of Flight Hardware GEN_22: The Developer shall evaluate the potential for Ground Support Equipment (GSE) to damage flight hardware and use appropriate means to prevent such damage from occurring.

GEN_23: The approach to obviate GSE damage to flight hardware shall be presented prior to the start of testing and at subsequent review milestones.

GEN_24: Prior to performing work on flight hardware, the performing organization shall identify a list of items, if any, that are sensitive to normal handling environments, such as presence of light, presence of metal objects (magnets), or presence of humidity outside of normal cleanroom and workmanship limits.

GEN_25: The Developer shall hold a meeting on the day work is to be performed, prior to the start of each shift, that includes a discussion of the list of items from GEN_24.

Risk Management GEN_26: SMA activities should be tightly linked with the project’s Risk Management processes. For example, risks that evolve from reliability analyses that affect overall mission objectives should be managed in the project’s risk database when not eliminated or mitigated to noncredible likelihood levels.

QUALITY MANAGEMENT SYSTEM

General QMS_01: The developer shall have a quality management system that is compliant with the requirements of Society of Automotive Engineers (SAE) AS9100 Quality Systems – Aerospace – Model for Quality Assurance in Design, Development, Production, Installation and Servicing.

Supplemental Quality Management System Requirements Control of Nonconforming Product QMS_04: The developer shall have a documented closed loop system for identifying, reporting, and correcting product nonconformances that shall include sub-tier supplier discrepancy reports. The system shall ensure that the adequacy of corrective action is determined by audit, inspection, or test, that objective evidence is collected, and that preventive action is implemented to preclude recurrence.

Material Review Board (MRB) QMS_06: The Developer shall have a documented process(es) for the establishment and operation of an MRB to process major non-conformances, which are those that affect form, fit, function, require a software change, involve the presence of Foreign Object Debris (FOD), affect the reliability, or safety of the end item, where a contractual requirement is violated, or those that the Government or developer determines involve elevated risk.

QMS_07: The Developer shall appoint a MRB chairperson who is responsible for implementing the MRB process and for appointing Developer representatives as MRB members.

QMS_09: The MRB process shall include a government representative as a voting member on MRB actions involving major nonconformances.

QMS_11: The government shall be provided notice and applicable documentation 24 hours in advance of scheduled MRB meetings.

QMS_13: The MRB shall use the following disposition actions:

· Scrap — the product is not usable

· Re-work/Re-test — the product will be re-worked/re-tested to conform to requirements (sometimes referred to as “return to print”)

· Return to supplier — the product will be returned to the supplier

· Repair — the product will be repaired

· Use as is — the product will be used as is Anomaly Reporting and Disposition QMS_14: The developer shall have a documented process for the establishment and operation of an anomaly review board (ARB) to process (report and disposition) major anomalies, which are those that have resulted in hardware or software test failures and damage or potential damage to hardware, require a software change, affect safety or where there is a violation of a Government requirement.

QMS_16: Reporting of major anomalies shall begin with the first application of power at the component or board level, flight software acceptance testing and when interfacing with flight hardware, and the first mechanical operation.

QMS_19: The ARB (or equivalent function) shall permit a government representative to be a voting member.

QMS_20: The government shall be provided notice of major anomalies and applicable documentation in advance of scheduled ARB meetings.

QMS_21: Failures that cannot be duplicated, have unknown root cause, or cannot be verified shall be assessed for residual risk, declared as red flag problem failure records (PFRs), and brought to the project risk board for disposition.

Orbital Debris Assessment Report (ODAR) and End of Mission Plan (EOMP) QMS_22: 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 MA 2-1).

Note: This is input to the Observatory ODAR and EOMP, and not the report and plan themselves which the Project will provide.

SYSTEM SAFETY

SAF_01: The developer shall document and implement a system safety program, support the Expendable Launch Vehicle (ELV) Safety Review Process as defined in Chapter 3 of NPR 8715.7 Payload Safety Program, comply with launch service provider requirements, and comply with launch range safety requirements.

SAF_02: The developer shall include the following specific safety requirements in the system safety program:

· The developer shall ensure 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 ensure 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."

Mission Related Safety Requirements Documentation SAF_03: The developer shall implement the launch range safety requirements that are applicable to the selected launch site. The developer shall implement the most stringent safety requirement in the event there are conflicting requirements. The sections below include the applicable requirements documents for the likely launch range (Requirements to be provided if another range is selected):

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

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

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

· NPR 8715.7 Expendable Launch Vehicle Payload Safety Program

· Launch Site Facility-specific Safety Requirements, as applicable (e.g., Astrotech) System Safety Deliverables System Safety Plan SAF_10: The developer shall prepare a System Safety Plan (SSP) 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 MA 3-1).

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

Instrument Safety Assessment Report (ISAR) SAF_22: 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 (CDRL MA 3-4). The spacecraft developer will use the ISAR as an input to the Safety Data Package (SDP).

Hazard Analyses Preliminary Hazard Analysis SAF_15: 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 PHA is based on the best available data, including mishap data from similar systems and other lessons learned.

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

SAF_17: The developer shall deliver the PHA with a Preliminary ISAR (CDRL MA 3-4).

Operations Hazard Analysis (OHA) and Hazard Verification Tracking Log (HVTL) SAF_18: 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 (CDRL MA 3‑3).

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

Operating and Support Hazard Analysis SAF_20: 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.

SAF_21: The developer shall submit the results of the O&SHA as a part of the Intermediate & Final ISARs (DID 3-4).

Verification Tracking Log (VTL) SAF_22: 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.

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

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

SAF_25: The developer shall make the results of the tests, analyses, and inspections from SAF_24 available for government review.

SAF_26: The VTL shall identify hazard controls that are not verified as closed and shall be delivered with the final ISAR (CDRL MA 3-4).

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

Hazardous Procedures for Payload I&T and Pre-launch Processing SAF_28: 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 (CDRL MA 3-5).

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

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

Lifting Device Safety Requirements A Critical Lift is defined as a lift during which failure/loss of control presents an elevated risk of serious injury, loss of life, or loss of one-of-a-kind articles, or high dollar items, whose loss would have serious programmatic or institutional impact.

SAF_31: The developer shall implement the following safety requirements for Lifting Devices and Equipment (LDE) when performing NASA work at non-NASA facilities:

· Overhead cranes, winches, and wire rope hoists shall have a dual hoist braking system installed per the NASA STD 8719.9 (Lifting Standard), Sections 5.4 and 7.4. Chain hoists typically do not have dual brakes as standard equipment unless included in the manufacturer’s design when specifically requested by the user. A single hoist motor holding brake in combination with a Variable Frequency Drive (VFD) dynamic braking system is an acceptable dual braking system.

· Label and tag LDE per the NASA STD 8719.9B, Section 4.9 requirements with no more than its Working Load Limit (WLL) as determined by the original equipment manufacturer (OEM) or its current certified WLL if that value is lower than the OEM rated WLL.

· Perform an initial one-time proof load test per the following NASA STD 8719.9B, Section 4.5 requirements:

· 1.25X WLL for overhead cranes.

· 1.25X WLL for mobile aerial platforms that will be used near critical hardware.

· 1X WLL for mobile cranes and derricks (.95X to 1X is acceptable).

· 1.25X WLL for Below-The-Hook (BTH) lifting devices.

· Slings (i.e., wire rope, synthetics, chain, etc.,) should only be proof load tested beyond its WLL with OEM approval.

· 2X WLL for rigging hardware items used for critical lifts (i.e., shackles. hoist rings. turnbuckles, etc.).

· Perform a 1X WLL load test every four years after the initial proof test on all LDE.

· In addition to visual inspection, perform a post load test NDT inspection (e.g., radiographic, ultra-sonic, magnetic particle, dye penetrant, etc.) on crane hooks and critical welds. 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."

Mishap Reporting and Investigation SAF_32: The developer shall prepare a Pre-Mishap Plan that describes appropriate mishap and close call notification, reporting, recording, and investigation procedures (CDRL MA 3-6).

SAF_33: The developer shall report accidents, test failures, or other mishaps and close calls promptly (within 24 hours) to NASA.

SAF_34: The developer shall promptly investigate test failures, or other mishaps and close calls to determine the root cause of the mishap/close call.

NASA ELV Payload Safety Program Forms SAF_35: The developer shall prepare NASA Expendable Launch Vehicle Payload Safety Forms. The forms are available at URL https://kscsma.ksc.nasa.gov/PayloadSafety/forms.

RELIABILITY

Reliability Program REL_05: The developer should perform reliability analyses concurrent with design so that identified problem areas are addressed, and corrective action taken in a timely manner.

Analysis of Design FMECA and Critical Items List (CIL) REL_11: The developer shall perform and maintain Failure Modes and Effects Criticality Analyses (FMECA) that address flight hardware and software and ground support equipment that interfaces with flight systems that are being designed, built, or provided from project initiation through launch and mission operations. The FMECA may be limited to safety items in the single string design. 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. Components and systems designated as inherited items shall be analyzed at the interface level. All others shall be analyzed at the box or functional level. (CDRL MA 4‑2).

REL_12: The developer shall prepare and maintain a Critical Items List for items with failure-mode severity categories 1SC (Safety Critical), 1, 1R (Redundant), 1S (Safety), and 2 per Table 4.1.

Table 4.1 Severity Categories

REL_13: The developer shall prepare and maintain a Single Point Failure (SPF) list for modes resulting in category 1 and 1SC severities per table 4.1 and document applicable failure causes, mitigations, and retention rationale.

REL_14: The developer shall identify and assess any known common cause failure modes and their causes for category 1R and 2R items. This shall be included and maintained in CDRL MA 4-2.

REL_15: The developer should estimate the likelihood score for each failure mode from 1-5 using the appropriate criteria from GPR 7120.4 (shown in Table 4.2) or another scale approved by GSFC Reliability. Each likelihood estimation can be based on qualitative assessment and/or failure rate data from other analyses (e.g., system calculations) in order to score each failure mode for the mission duration. This should be included and maintained in CDRL MA 4-2.

Table 4.2 Likelihood Rankings

REL_16: The developer should identify the consequence for each failure mode using the appropriate criteria from GPR 7120.4 (shown in Table 4.3). This should be included and maintained in CDRL MA 4-2).

Table 4.3 Consequence Rankings

Fault Tree Analysis (FTA) REL_17: The developer shall perform and maintain qualitative fault tree analyses (FTA) (CDRL MA 4-3), as deemed necessary by the Chief Safety and Mission Assurance Officer (CSO) and the Mission Systems Engineer (MSE).

REL_18: Fault trees shall address both hardware and software contributions at a level necessary to identify risks, verify mitigations, and assist in the development of fault management.

REL_19: In the event the developer or the project identifies a major mission risk contributor in the FMECA or FTA, the developer shall quantify (and if necessary, expand) the appropriate FTA or the portions of the FTA necessary for detailed risk assessment, as deemed necessary by the CSO and the MSE.

REL_20: FTA should also be considered for use to check the FMECAs for completeness.

Reliability Calculations REL_21: The developer shall perform and maintain reliability and availability calculations (CDRL MA 4‑4) using Fault Tree Analyses (FTA), reliability block diagrams, and/or Probabilistic Risk Assessment (PRA) to identify design weaknesses, support design trades, and demonstrate the impact of critical items, as deemed necessary by the CSO and the MSE.

Limited Life Analysis REL_22: The developer shall perform and maintain Limited Life Item Analysis (LLA) that includes expected life, required life, and an assessment of life margin (including servicing and maintenance); provides retention rationale for items with an expected life of less than 2x the required life and fosters a plan to manage limited life items (CDRL MA 4-5).

REL_25: The risk assessment and mitigations plans shall be included in the LLA for items not meeting the 2X life requirement and shall factor in wear caused by atomic oxygen, solar and trapped radiation, shelf-life, extreme temperatures, thermal cycling, write/erase cycles and mechanical wear or fatigue, and include refurbishment and maintenance plans.

Parts Stress Analysis REL_26: 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 MA 4-6) or the developer’s own established standard, unless specifically relieved of this requirement by the GSFC Inherited Items Risk Assessment process (See Section 1.9).

REL_28: If alternate derating guidelines are requested to be used, they shall be submitted to the Parts Control Board and GSFC Reliability Engineering for approval.

Worst-Case Analysis REL_30: The developer shall perform Worst-Case Analyses (WCA) for circuit designs that are new or significantly modified or are being used in an environment not covered by the existing analysis and identified as critical through analysis of the design (See Section 4.2) (CDRL MA 4-7).

SOFTWARE ASSURANCE

Software Assurance Program SWA_01: The developer shall establish a software assurance program consisting of a planned and systematic set of activities and disciplines that ensures that software conforms to organizational and project-specific requirements and standards throughout the project lifecycle, where software is defined as:

· Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system

· All or a part of the programs, procedures, rules, and associated documentation of an information processing system

· Program or set of programs used to run a computer

· All or part of the programs which process or support the processing of digital information

· Part of a product that is the computer program or the set of computer programs.

Note: The software definition applies to software developed by NASA, software developed for NASA, software maintained by or for NASA, COTS, GOTS, MOTS, OSS, reused software components, auto-generated code, embedded software, software used on ground support equipment, the software executed on processors embedded in programmable logic devices, legacy, heritage, applications, freeware, shareware, trial or demonstration software, and open-source software components.

SWA_03: The developer shall ensure the independence of software assurance from software engineering.

SWA_04: The developer shall document and implement a Software Assurance Plan and schedule compliant to NASA-STD-8739.8B, NASA Software Assurance and Software Safety Standard (CDRL MA 5-1).

The plan includes the software assurance processes, procedures, tools, and techniques to be used commensurate with the software classification and safety criticality assessment, with additional tailoring in accordance with guidance provided by NASA-STD-8739.8B for each category of software (new, reused, Off-the-shelf, auto-generated code, etc..).

The plan addresses both Software Assurance and Software Safety disciplines. This includes the necessary collaboration with relevant SMA and Engineering stakeholders (i.e., system safety, system reliability, hardware quality, system security, and software engineering), and the process by which traceability is established to their respective analyses and/or requirements.

Surveillance of Software Development, Maintenance, and Assurance Activities SWA_08: Consistent with the general requirement for support of government surveillance (see Section 1.6 "Surveillance"), the developer shall provide on-request access to following:

· Software problem reports

· Software documentation (i.e., management plans, assurance plans, configuration management plans, requirements specifications, design documents, test plans, test cases, test procedures, test results, software review results, software engineering and assurance schedule, and maintenance plans)

· Source code

· Findings and corrective actions from software process and product audits and assessments

WORKMANSHIP

WOR_02: 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.6 Implementation Requirements for NASA Workmanship Standards, excluding sections 8.1, 9.1, and 10.1

· J-STD-001, Requirements for Soldered Electrical and Electronic Assemblies

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

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

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

WOR_04: 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 Requirements and Acceptance for Cable and Wire Harness Assemblies Electrostatic Discharge Control (ESD) WOR_06: The developer shall prepare and implement an ESD control plan that conforms to the requirements of ANSI/ESD S20.20 "Protection of Electrical and Electronic Parts, Assemblies and Equipment (Excluding Electrically Initiated Explosive Devices)" (CDRL MA 6-1).

Printed Circuit Boards (PCB) WOR_08: 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, Class 3 (the latest revision preferred, but older revisions acceptable based on inherited designs or developer standard practices)

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

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

WOR_09: In cases in which high-density interconnect (HDI) components (e.g., reconfigurable FPGAs, high-density SRAMs, etc.) or board population are present, the developer should consult with the GSFC Project and GSFC MPCB CRAE for a specification strategy to avoid extensive rebuilds or the incorporation of risky features solely in order to meet the spec. This consultation may result in deviations from the specifications above with no waiver required.

WOR_10: The developer shall document and implement a PCB procurement plan (CDRL MA 6-2).

WOR_12: For non-conforming coupons, the evaluation report shall be delivered to the GSFC MPCB CRAE for a risk assessment. If the CRAE's risk assessment determines that there is no elevated risk, no waiver is required and the CSO will determine the disposition of the board.

Lead-Free Control Measures WOR_16: The developer shall document and implement a Lead-Free Control Plan (LFCP) (CDRL MA 6-5).

WOR_17: The developers shall submit uses of lead-free solder or surface finishes to the NASA project office for approval before use.

EEE PARTS

General EEE_02: The developer shall document and implement a Parts Control Plan (PCP) per Level 3 instructions of GSFC EEE-INST-002 Instruction for EEE Parts Selection, Screening, Qualification, and De-rating (CDRL MA 7-1).

Note: The developer may use as is Class V, S, Q, B, M compliant microcircuits; JANS, JANTXV, and JANTX semiconductors without any further approval.

Note: The developer may use as is automotive or hi-rel commercial off the shelf (COTS) parts, compliant to level 3 per NASA-STD-8739.10 without any additional screening or qualification tests without any further approval.

Parts Control Board EEE_07: 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.

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

EEE_13: The developer shall include the GSFC Parts Engineer and the Parts and Radiation Assurance Engineer (PRAE) as participating members of the PCB.

Re-use of EEE Parts EEE_15: The developer shall require approval of the PCB to re-use EEE parts that have been installed.

Master EEE Parts List EEE_16: The developer shall develop and deliver a Master EEE Parts List in accordance with CDRL MA 7-2 and maintain it for the duration of the project.

Radiation Effects Mitigation EEE_19: The developer shall provide a plan, for approval, for how radiation will be addressed (CDRL MA 7-3).

EEE_20: The developer shall provide a radiation and shielding analysis to ensure that all instrument parts will be compatible with the expected space radiation environment for the required mission life and to determine whether the instrument radiation shielding is adequate to protect the instrument electrical and optical parts from excessive degradation due to radiation (CDRL MA 7-4).

MATERIALS AND PROCESSES

M&P Selection, Control, and Implementation Plan (MPCIP) MAP_01: The developer shall prepare and implement a Materials and Processes (M&P) Selection, Control, and Implementation Plan (MPCIP) (CDRL MA 8-1). NASA-STD-6016 shall be used as a baseline, with developer standard practices acceptable if associated command media are shared with NASA.

Materials Usage Agreement (MUA) MAP_03: The developer shall prepare materials usage agreements (CDRL MA 8-2).

Materials Identification and Usage List (MIUL) MAP_04: The developer shall prepare a materials identification and usage list (CDRL MA 8-3).

Life Test Plan and Final Report for Lubricated Mechanisms MAP_05: The developer shall prepare and implement a life test plan and final report for lubricated mechanisms (CDRL MA 8‑4).

Additive Manufacturing Control Plan (AMCP) MAP_06: The developer shall prepare and implement an Additive Manufacturing Control Plan (AMCP) for the design and manufacture of Additively Manufactured (AM) Parts (CDRL MA 8‑5).

AM Part Production Plan (PPP) MAP_07: The developer shall prepare a Part Production Plan (PPP) for each AM part (CDRL MA 8‑6).

CONTAMINATION CONTROL

Contamination Control Plan CON_01: The developer shall prepare and implement a contamination control program (CDRL MA 9-1) consistent with the Project Contamination Control Plan.

Material Outgassing CON_03: The developer shall include in CDRL MA 8-3 (MIUL) information regarding material outgassing.

CON_04: If an alternate standard to NASA-STD-6016 "STANDARD MATERIALS AND PROCESSES REQUIREMENTS FOR SPACECRAFT " is implemented, materials shall 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.

Foreign Object Debris Program CON_05: The developer shall prepare and implement a foreign object debris program (CDRL MA 9-2).

METROLOGY AND CALIBRATION

Metrology and Calibration Program MAC_01: For measurement and test equipment that has documented requirements for metrological accuracy and traceability, the developer shall comply with NASA-STD-8739.12 "Metrology and Calibration", or verify equipment against calibrated instruments or intrinsic standards, using a documented procedure.

Note: The developer may verify torque wrenches against a calibrated torque tester prior to use.

Use of Calibrated and Non-Calibrated Instruments MAC_02: The developer shall record the measurements that require accuracy in applicable project build documents (e.g., Work Order Authorizations (WOAs), job orders, task sheets or test plans), including the article of calibrated equipment used to take the measurement and its calibration end date.

MAC_03: When verification is chosen instead of calibration, 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.

GIDEP ALERTS AND PROBLEM ADVISORIES

Government-Industry Data Exchange Program (GIDEP) GID_01: The developer shall participate in GIDEP per the GIDEP Operations Manual (Note: this document is available through http://www.gidep.org).

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

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

GIDEP Reporting GID_06: The developer shall prepare and submit failure experience data and safety issue reports per the requirements of GIDEP Operations Manual whenever failed or nonconforming items are discovered that are available to other buyers. (CDRL MA 11-2).

Review Reporting GID_07: The developer shall report the status of NASA products that are affected by Alerts (or by significant EEE parts, materials, software, and safety problems) and the actions taken to eliminate or mitigate negative effects at monthly status reviews, parts control board meetings, program milestone reviews and readiness reviews. (CDRL MA 11-1)

END ITEM ACCEPTANCE DATA PACKAGE

EIA_01: The developer shall maintain the End Item Acceptance Data Package (EIADP) throughout the project lifecycle and submit in accordance with (CDRL MA 12-1).

Acronym List