Attachment H- 418-XO-SCMAR-0083_V_1_0.pdf

Effective Date: February 15, 2022 418-XO-SCMAR-0083 Responsible Organization: GeoXO Flight Project/Code 418 Baseline 1.0

Geostationary Extended Observations (GeoXO)

Mission Assurance Requirements (MAR) Signature/Approval Page

Prepared by:

Electronically approved by:

02/15/2022

Joseph Spector Date GeoXO Flight Project Chief Safety & Mission Assurance Officer

Code 383

Reviewed by:

02/09/2022

Syed Aziz Date GeoXO Program Chief Safety & Mission Assurance Officer

Code 383

Concurred by:

Michelle Rizzo Date GeoXO Observatory Manager Code 418

Approved by:

Monica Todirita electronically approved for:

Jason Hair Date GeoXO Flight Project Manager Code 418

/GeoXO Flight Project Spacecraft

SCMAR

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance Requirements (MAR)

Version: 1.0 Printed by: rkhoover Printed on: Wednesday, February 16, 2022

No filter applied.

No sort applied.

Generated from DOORS 9.7.2.4

Contents

1 1 GENERAL

1.1 1 Terminology

1.2 1 Systems Safety and Mission Assurance Program

1.3 2 Management

1.4 2 Requirements Flowdown

1.5 2 Suspension of Work Activities

1.6 2 Surveillance

1.7 3 Government Mandatory Inspection Points (GMIPS)

1.8 4 Suppliers List

1.9 4 Use of Inherited Products/Items

1.10 4 Risk Management

1.11 4 Data item Description (DID)

2 5 QUALITY MANAGEMENT SYSTEM

2.1 5 General

2.1.1 5 Suppliers of Procured Critical Hardware

2.1.2 5 Suppliers of Critical Piece Parts

2.2 5 Supplemental Quality Management System Requirements

2.2.1 5 Control of Non-conforming Product

2.2.1.1 5 Preliminary Material Review (PMR)

2.2.1.2 6 Material Review Board (MRB)

2.2.1.3 7 Failure Review Board (FRB)

2.2.2 8 Reporting of Non-Conformances

2.2.3 8 Safety and Mission Assurance Policy

2.2.4 8 Lessons Learned

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

3 10 SYSTEM SAFETY

3.1 10 General

3.2 10 Mission Related Safety Requirements Documentation

3.2.1 10ELV Eastern Test Range (ETR)

3.3 11 System Safety Deliverables

3.3.1 11 System Safety Program Plan

3.3.2 11 Safety Requirements Compliance Checklist

3.3.3 11 Hazard Analyses

Project: GeoXO Flight Project Spacecraft Module: SCMAR Baseline Version: 1.0

Contents ii

3.3.3.1 11 Preliminary Hazard Analysis

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

3.3.3.3 12 Mechanical Ground Support Equipment Safety Requirements

3.3.3.4 13 Operating and Support Hazard Analysis (O&SHA)

3.3.4 13 Safety Data Package (SDP)

3.3.5 14 Verification Tracking Log (VTL)

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

3.3.7 14 Safety Waivers

3.3.8 14 Support for Safety Working Group Meetings

3.3.9 15 Mishap Reporting and Investigation

3.3.10 15 NASA Expendable Launch Vehicle (ELV) Payload Safety Program Forms

4 16 RELIABILITY

4.1 16 Reliability Program Plan (RPP)

4.2 16 FMECA and Critical Items List (CIL)

4.3 18 Reliability Assessments and Predictions

4.4 19 Limited-Life Items

4.5 19 Parts Stress Analysis

4.6 20 Worst-Case Analysis

4.7 20 Trend Analysis

5 21 SOFTWARE ASSURANCE

5.1 21 General

5.2 21 Software Assurance Program

5.3 21 Surveillance of Software Development, Maintenance, and Assurance Activities

6 23 WORKMANSHIP

6.1 23 General

6.2 24 Design and Process Qualification

6.3 24 Electrostatic Discharge Control (ESD)

6.4 25 Printed Circuit Board (PCB) Procurement, Test Coupons, and Verification Tests

6.5 25 Use of Water-Soluble Flux

6.6 25 Lead-Free and Tin Whisker Control Measures

6.7 26 Ground System Equipment That Interface with Space Flight Hardware

6.8 26 Training and Certification

6.9 26 Handling

6.10 27 Preservation and Packaging

7 28 EEE PARTS

7.1 28 General

Contents iii

7.1.1 28 Single Point of Contact

7.2 29 Parts Control Board

7.2.1 29 PCB Responsibilities

7.2.2 29 PCB Meetings and Notification

7.2.3 30 PCB Membership

7.3 30 Part Selection and Processing

7.3.1 30 Radiation Requirements for Part Selection

7.3.1.1 30 Total Ionizing Dose (TID)

7.3.1.2 30 Displacement Damage

7.3.1.3 31 Single-Event Effects (SEE)

7.3.2 31 Custom or Advanced Technology Devices

7.3.3 32 Parts Approved on Prior Programs

7.3.4 32 Parts Used in Off-the-Shelf Assemblies

7.4 32 Value Added Testing

7.4.1 32 Surge Current Screening for Tantalum Capacitors

7.4.2 33 Screening for Magnetic Components

7.5 33 Failure Analysis

7.6 34 Re-use of EEE Parts and Materials

7.7 34 Master EEE Parts List

7.8 34 Data Requirements

7.8.1 34 General

7.8.2 35 Retention of Data and Test Samples

8 36 MATERIALS AND PROCESSES

8.1 36 M&P Selection, Control, and Implementation Plan (MPSCIP)

8.2 36 Material Usage Agreement (MUA)

8.3 36 Materials Identification and Usage List (MIUL)

8.4 36 Life Test Plan and Final Report for Lubricated Mechanisms

8.5 36 Additive Manufacturing Control Plan (AMCP)

8.6 36 AM Part Production Plan (PPP)

9 37 CONTAMINATION CONTROL

10 38 METROLOGY AND CALIBRATION

10.1 38 Metrology and Calibration Program

10.2 38 Use of Calibrated and Non-Calibrated Instruments

11 39 GIDEP ALERTS AND PROBLEM ADVISORIES

11.1 39 Government-Industry Data Exchange Program (GIDEP)

11.2 39 Alert Disposition

Contents iv

11.3 39 GIDEP Reporting

11.4 39 Review Reporting

12 41 END ITEM ACCEPTANCE DATA PACKAGE

13 42 Appendix A. Acronym List

14 44 Appendix B. Data Item Descriptions

14.1 45 DID 1-1: Mission Assurance Implementation Plan

14.2 46 DID 1-2: Mission Assurance Compliance Matrix

14.3 47 DID 1-3: Suppliers List

14.4 47 DID 1-4: Use of Inherited Products/Items

14.5 50 DID 2-1: Non-Conformance Report - MRB

14.6 50 DID 2-2: Non-Conformance Report - FRB

14.7 52 DID 2-3: Lessons Learned

14.8 53 DID 2-4: Orbital Debris Assessment Report (ODAR) and End of Mission Plan

(EOMP)

14.9 53 DID 3-1: System Safety Program Plan

14.10 54 DID 3-2: Safety Requirements Compliance Checklist

14.11 55 DID 3-3: Operations Hazard Analysis and Hazard Verification Tracking Log

14.12 56 DID 3-4: Safety Data Package

14.13 58 DID 3-5: Hazardous Procedures for Payload I&T and Pre-Launch Processing

14.14 59 DID 3-6: Pre-Mishap Plan

14.15 61 DID 4-1: Reliability Program Plan

14.16 62 DID 4-2: FMECA and Critical Items List

14.17 63 DID 4-3: Fault Tree Analysis

14.18 64 DID 4-4: Reliability Assessments and Predictions

14.19 65 DID 4-5: Limited-Life Items List

14.20 65 DID 4-6: Parts Stress Analysis

14.21 66 DID 4-7: Worst-Case Analysis

14.22 67 DID 5-1: Software Assurance Plan

14.23 68 DID 6-1: Workmanship Program Plan

14.24 69 DID 6-2: Alternate Printed Circuit Board Standard Report

14.25 69 DID 6-3: ESD Control Plan

14.26 70 DID 6-4: Printed Circuit Board Procurement Plan

14.27 71 DID 6-5: Printed Circuit Board (PCB) Coupon Evaluation Report

14.28 73 DID 6-6: Lot Acceptance and Quality Conformance Testing Results for Printed

Circuit Boards

14.29 73 DID 6-7: Use of Water-Soluble Flux

14.30 74 DID 6-8: Lead-Free Control Plan

Contents v

14.31 74 DID 7-1: EEE Parts Control Plan

14.32 75 DID 7-2: Master EEE Parts List

14.33 77 DID 8-1: Materials and Processes Selection, Control, & Implementation Plan

(MPSCIP)

14.34 78 DID 8-2: Material Usage Agreement

14.35 79 DID 8-3: Materials Identification and Usage List

14.36 80 DID 8-4: Life Test Plan and Final Report for Lubricated Mechanisms

14.37 81 DID 8-5: Additive Manufacturing Control Plan (AMCP)

14.38 82 DID 8-6: Additive Manufacturing Part Production Plan (PPP)

14.39 83 DID 11-1: Responses to Alerts

14.40 84 DID 12-1: End Item Acceptance Data Package

15 85 Appendix C. Mission Assurance Compliance Matrix

16 95 Appendix D. Data Item Description Delivery Requirements

17 103 Appendix E: Applicable Documents

18 105 Appendix F: Reference Documents

Contents vi

Page 1 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR1

SCMAR2

SCMAR3

SCMAR4

SCMAR5

SCMAR6

SCMAR7

SCMAR8

SCMAR9

SCMAR10

SCMAR11

Object Number

1.1

1.1.0-1

1.1.0-2

1.1.0-3

1.1.0-4

1.1.0-5

1.2

1.2.0-1

1.2.0-2

1.2.0-3

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

1 GENERAL

1.1 Terminology

The following requirements terminology is used throughout this document:

The use of “shall” designates a requirement that must be met.

The use of “will” designates a statement of fact or intention of the government.

The use of “may” designates that permission has been granted by the government.

The term “(TBD)” means, “to be determined” and is used when no value is available with subsequent study needed to obtain it.

The term “(TBR)” means “to be refined/reviewed” for a value that is subject to review for appropriateness and is subject to revision. The vendor is liable for compliance with the information marked “TBR” as if the “TBR” notation did not exist.

The term “days” refers to calendar days, unless specified as business days.

1.2 Systems Safety and Mission Assurance Program

The developer shall plan and implement a safety and mission assurance program that is consistent with contractual requirements.

The program shall at a minimum cover:

⦁ Flight hardware that is designed, built, or provided by the developer, its subcontractors or furnished by the government, from project initiation through launch and mission operations

⦁ The ground support equipment and test scripts that interfaces with flight items to the extent necessary to assure the integrity and safety of flight items

⦁ This includes but is not limited to any electrical, optical, laser, mechanical Ground Support Equipment (GSE) that interfaces with flight articles.

⦁ Procedures shall specifically reference this in developer project documentation and drawings.

⦁ The developer shall include a Mission Assurance Implementation Plan which details how Electrical Ground Support Equipment (EGSE) and Mechanical Ground Support Equipment (MGSE) are certified to cause no harm to flight articles (including design for safety and current limiting).

⦁ All software critical for mission success ⦁ Ground data systems required for spacecraft communication, command and control, health and safety monitoring, and science data processing/distribution as required by the Statement of Work.

This program shall be documented in a Mission Assurance Implementation Plan (DID 1-1).

Note: The safety aspects of this program will be documented in the Systems Safety Program Plan (SSPP) in Section 3.

Page 2 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR12

SCMAR13

SCMAR14

SCMAR15

SCMAR16

SCMAR17

SCMAR18

SCMAR19

SCMAR20

SCMAR21

SCMAR22

SCMAR23

SCMAR24

SCMAR25

Object Number

1.2.0-4

1.3

1.3.0-1

1.3.0-2

1.3.0-3

1.3.0-4

1.4

1.4.0-1

1.4.0-2

1.4.0-3

1.5

1.5.0-1

1.6

1.6.0-1

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

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

1.3 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 developer shall ensure that the assurance manager has direct access to upper management that is independent of project management.

The assurance manager shall have the functional freedom and authority to interact with all elements of the project.

1.4 Requirements Flowdown

The Developer shall ensure flow down of the processes, products, and services to be provided including the identification of relevant technical data (e.g., specifications, drawings, process requirements, work instructions) and SMA requirements to all suppliers based on the work to be performed and establish a process to verify compliance, with the exception of items identified through the Inherited Item Risk Assessment process (see Section 1.9 "Use of Inherited Products/Items").

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.

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, as applicable.

1.5 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.6 Surveillance

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 government-designated representatives as directed in the 418-TBD-XXXX Project Quality Assurance Surveillance Plan (PQASP). These audits, assessments, inspections, or surveys may be performed by NASA Project representatives and/or by NASA Supply Chain Quality representatives at various points over the program/project development lifecycle. Surveillance plans will focus on suppliers of project-defined critical items. (per NPR 8735.2).

Page 3 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR26

SCMAR27

SCMAR28

SCMAR29

SCMAR30

SCMAR31

SCMAR32

SCMAR33

SCMAR34

SCMAR35

SCMAR36

Object Number

1.6.0-2

1.6.0-3

1.6.0-4

1.6.0-5

1.6.0-6

1.6.0-7

1.7

1.7.0-1

1.7.0-2

1.7.0-3

1.7.0-4

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

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, inspection, or survey upon notice. A 30-day notice will be provided to the supplier prior to the start of an assessment.

The developer shall supply personnel, documents, records, equipment, and an acceptable work area within the developer’s facilities to assist with the audit/assessments/inspection/surveys.

The prime contractor shall report the status of facility operations and quality metrics to NASA on a monthly basis.

The reports shall include:

⦁ 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

This monthly report shall include 1st tier and 2nd tier suppliers of project-defined critical items within scope of the contract.

The developer shall consider supplier quality and develop an industrial base and Supply Chain Risk Management (SCRM) Strategy per NPR 8735.2 during design and product selection.

1.7 Government Mandatory Inspection Points (GMIPS)

The developer shall provide a plan for proposed GMIPs, consistent with the requirements of NPR 8735.2 “Hardware Quality Assurance Program Requirements for Programs and Projects”, and subject to government approval.

The developer shall develop criticality identification method, determine critical items and develop a plan to address them using hardware quality data management analytics per NPR 8735.2.

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

The following activities shall be subject to GMIPs:

⦁ Pre-ship inspection ⦁ Circuit card assemblies ⦁ Final solder inspection before conformal coating and staking ⦁ Post conformal coating ⦁ Pre-closure of boxes ⦁ Harness – pre-integration (pre-staking or potting)

Page 4 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR36

SCMAR37

SCMAR38

SCMAR39

SCMAR40

SCMAR41

SCMAR42

SCMAR43

SCMAR44

SCMAR45

SCMAR46

SCMAR47

SCMAR48

SCMAR49

SCMAR50

SCMAR51

Object Number

1.7.0-4

1.7.0-5

1.7.0-6

1.8

1.8.0-1

1.9

1.9.0-1

1.9.0-2

1.9.0-3

1.10

1.10.0-1

1.11

1.11.0-1

1.11.0-2

1.11.0-3

1.11.0-4

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

⦁ Unit and component-level assembly – witness final assembly ⦁ Mechanical – final assembly and acceptance test (unit/component, subsystem, and top-level assembly) ⦁ Software acceptance test ⦁ Rework and repairs to flight hardware

The developer can exclude non-critical items (as defined in NPR 8735.2 and determined by the project) or where GMIP requirements have been relieved as a result of the Inherited Item Risk Assessment (see Section 1.9 "Use of Inherited Products/Items"), or by the GSFC project office through terms of the procurement for COTS items.

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

1.8 Suppliers List

The developer shall provide a list of suppliers used for product(s) and services produced under this contract (DID 1-3).

1.9 Use of Inherited Products/Items

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

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

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

1.10 Risk Management

SMA activities should be tightly linked with the project’s Risk Management processes.

For example, see the Section 4 Reliability discussion regarding risks managed in the project’s risk database that evolve from reliability analyses.

1.11 Data item Description (DID)

This document references DIDs for deliverables, however the DIDs reside in the GeoXO Flight Project Contract Data Requirements List (CDRL) (DOC_TBD). The developer shall deliver data items per the requirements of the applicable DID and CDRL.

The developer shall perform work in accordance with the definitions in the CDRL document.

(Note: The DIDs contained in this version are for implementation phase only and will be moved in future revisions of this document to the CDRL)

The developer may combine deliverables if the requirements for the individual deliverables are addressed.

Page 5 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR52

SCMAR53

SCMAR54

SCMAR55

SCMAR56

SCMAR57

SCMAR58

SCMAR59

SCMAR60

SCMAR61

SCMAR62

SCMAR63

SCMAR64

SCMAR65

SCMAR66

SCMAR67

SCMAR68

Object Number

2.1

2.1.0-1

2.1.1

2.1.1.0-1

2.1.2

2.1.2.0-1

2.2

2.2.0-1

2.2.1

2.2.1.0-1

2.2.1.0-2

2.2.1.0-3

2.2.1.0-4

2.2.1.1

2.2.1.1.0-1

2.2.1.1.0-2

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

2 QUALITY MANAGEMENT SYSTEM

2.1 General

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

2.1.1 Suppliers of Procured Critical Hardware

Suppliers of procured critical hardware systems (e.g., subassemblies, functional systems, mission payloads, spacecraft, aircraft, or launch systems) and launch services shall be compliant to AS9100D. Third-party certification to AS9100D is preferred over compliance to AS9100D.

2.1.2 Suppliers of Critical Piece Parts

Supplier of piece parts determined to be critical items, or special process execution (e.g., plating, polishing, soldering, brazing) determined to be critical or services excluding launch services (e.g., machining, laboratory testing, transportation, and storage) determined to be critical, shall maintain a current QMS that complies with one of the following: AS9100 (preferred), ISO9001, AS9003A, ISO17025 or other applicable technical accreditation (Nadcap, IPC, DoD).

2.2 Supplemental Quality Management System Requirements

The following requirements supplement identified portions of the AS9100 requirements.

2.2.1 Control of Non-conforming Product

The developer shall have a documented closed loop system for identifying, reporting, and correcting product non-conformances.

The system shall ensure that the adequacy of corrective action is determined by audit or test, that objective evidence is collected, and that preventive action is implemented to preclude recurrence.

The developer shall provide electronic access to the non-conformance system to designated local and remote government representatives.

Non-conformances shall be reported in accordance with (DID 2-1) and (DID 2-2).

2.2.1.1 Preliminary Material Review (PMR)

The material review process shall be initiated with the identification and documentation of a non-conformance.

A preliminary review shall be the initial step performed by developer-appointed personnel to determine if the non-conformance is minor and therefore can readily be processed using 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

Page 6 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR69

SCMAR70

SCMAR71

SCMAR72

SCMAR73

SCMAR74

SCMAR75

SCMAR76

SCMAR77

SCMAR78

SCMAR79

SCMAR80

SCMAR81

SCMAR82

Object Number

2.2.1.1.0-3

2.2.1.1.0-4

2.2.1.2

2.2.1.2.0-1

2.2.1.2.0-2

2.2.1.2.0-3

2.2.1.2.0-4

2.2.1.2.0-5

2.2.1.2.0-6

2.2.1.2.0-7

2.2.1.2.0-8

2.2.1.2.0-9

2.2.1.2.0-10

2.2.1.2.0-11

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

The developer shall refer the non-conformance to the Material Review Board when the above actions do not apply to the nonconformance.

Note: Preliminary Review does not negate the requirement to identify, segregate, document, report, and disposition non-conformances.

2.2.1.2 Material Review Board (MRB)

Non-conformances not dispositioned by Preliminary Review shall be referred to the MRB for disposition.

The developer shall have a documented process for the establishment and operation of an MRB to process major non-conformances, which are those that affect form, fit, function of the product, requires a software change, involves domestic or foreign object debris, or involves elevated risk per assessment by the developer.

The developer process shall include definitions of major and minor nonconformances.

The MRB process shall investigate, in a timely manner, each nonconforming item in sufficient depth to determine proper disposition.

For each reported non-conformance, there shall be an investigation and engineering analysis sufficient to determine cause and corrective actions for the non-conformance.

The developer shall appoint an MRB chairperson who is responsible for implementing the MRB process and ensuring that the MRB actions are performed in compliance with this standard as implemented by developer procedures.

The MRB shall consist of a core team of functional and project representatives with other disciplines brought in as necessary.

The MRB process shall include the Project Chief Safety and Mission Assurance Officer (CSO) or designee as a voting member. The CSO or designee reserves the right to include and poll the government project representatives (e.g. Systems Engineers, Discipline Leads, etc.) in the MRB before giving approval.

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 ⦁ Request for Waiver

The developer shall submit all standard repair procedures to NASA Workmanship Alternate Process Evaluation System (NWAPES). Once NWAPES approves the standard repair, the CSO will communicate with the developer via an approval letter.

All MRB meetings shall be documented in the developer’s system and include a list of the attendees (virtual and in person), key discussions, action items, and decision of the voting members.

Page 7 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR83

SCMAR84

SCMAR85

SCMAR86

SCMAR87

SCMAR88

SCMAR89

SCMAR90

SCMAR91

SCMAR92

SCMAR93

SCMAR94

SCMAR95

SCMAR96

SCMAR97

SCMAR98

SCMAR99

Object Number

2.2.1.2.0-12

2.2.1.2.0-13

2.2.1.2.0-14

2.2.1.2.0-15

2.2.1.2.0-16

2.2.1.2.0-17

2.2.1.3

2.2.1.3.0-1

2.2.1.3.0-2

2.2.1.3.0-3

2.2.1.3.0-4

2.2.1.3.0-5

2.2.1.3.0-6

2.2.1.3.0-7

2.2.1.3.0-8

2.2.1.3.0-9

2.2.1.3.0-10

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

Written authorization shall be documented to disposition the nonconforming product.

Completed MRB’s shall be approved by NASA/Government representative.

The developer shall submit MRB reports no later than 24 hours after occurrence.

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

The developer shall inform the government of major MRB actions no later than five (5) working days after MRB action for approval.

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

2.2.1.3 Failure Review Board (FRB)

Non-conformances not dispositioned by Preliminary Review or Material Review Board shall be referred to the Failure Review Board for disposition.

Non-conformances to be dispositioned by FRBs shall include those that have resulted in hardware or software test failures and damage or potential damage to hardware.

The developer shall have a documented process for the establishment and operation of an FRB to process non-conformances.

The FRB process shall investigate, in a timely manner, each nonconforming item in sufficient depth to determine proper disposition.

For each reported non-conformance, there shall be an investigation and engineering analysis sufficient to determine cause and corrective actions for the non-conformance.

The developer shall appoint an FRB chairperson who is responsible for implementing the FRB process and ensuring that the FRB actions are performed in compliance with this standard as implemented by developer procedures.

The FRB shall consist of a core team of functional and project representatives with other disciplines brought in as necessary.

The FRB process shall include the Project Chief Safety and Mission Assurance Officer (CSO) or designee as a voting member. The CSO or designee reserves the right to include and poll the government project representatives (e.g. Systems Engineers, Discipline Leads, etc.) in the FRB before giving approval.

The FRB 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

FRB

⦁ Use as is — the product will be used as is ⦁ Request for Waiver

All FRB meetings shall be documented in the developer’s system and include a list of the attendees (virtual and in person), key discussions, action items, and decision of the voting members.

Page 8 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR100

SCMAR101

SCMAR102

SCMAR103

SCMAR104

SCMAR105

SCMAR106

SCMAR107

SCMAR108

SCMAR109

SCMAR110

SCMAR111

SCMAR112

SCMAR113

SCMAR114

SCMAR115

Object Number

2.2.1.3.0-11

2.2.1.3.0-12

2.2.1.3.0-13

2.2.1.3.0-14

2.2.1.3.0-15

2.2.1.3.0-16

2.2.2

2.2.2.0-1

2.2.2.0-2

2.2.2.0-3

2.2.3

2.2.3.0-1

2.2.3.0-2

2.2.4

2.2.4.0-1

2.3

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

Written authorization shall be documented to disposition the nonconforming product.

Completed FRB’s shall be approved by NASA/Government representative.

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

The developer shall submit FRB reports no later than 24 hours after occurrence.

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

Failures that cannot be duplicated, have unknown root cause, or cannot be verified shall be assessed for residual risk, and brought to the project risk board for disposition.

2.2.2 Reporting of Non-Conformances

The developer shall report:

⦁ Major hardware nonconformances beginning with the first application of power at the component level

⦁ Major software non-conformances beginning with flight software acceptance testing and when interfacing with flight hardware

⦁ Major mechanical system nonconformances beginning with the first operation.

⦁ All nonconformances for review on a periodic basis as deemed appropriate by the government and developer SMA team

Non-conformance reporting shall continue through formal Government acceptance of the end item on orbit.

Note: a component is defined as a functional subdivision of a subsystem and generally as a self-contained combination of items performing a function necessary for the subsystem's operation and synonymous with Unit. Examples are electronics unit and sensor unit.

2.2.3 Safety and Mission Assurance Policy

Developers shall ensure that appropriate review processes are in place at their level to certify the safety and operational readiness of flight hardware/software, mission-critical support equipment, hazardous facilities/operations, and high-energy ground-based systems.

Notwithstanding any other requirements developers shall direct the suspension of any operation that presents an immediate and unacceptable danger to personnel, property, or mission operations.

2.2.4 Lessons Learned

The developer shall collect lessons learned and provide them to the GeoXO Project.

(DID 2-3)

2.3 Orbital Debris Assessment Report (ODAR) and End of

Mission Plan (EOMP)

Page 9 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR116

SCMAR117

Object Number

2.3.0-1

2.3.0-2

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

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

The developer shall provide inputs/data to ensure the implementation of orbital debris mitigation measures for all mission hardware in Earth orbit.

Page 10 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR118

SCMAR119

SCMAR120

SCMAR121

SCMAR122

SCMAR123

SCMAR124

SCMAR125

SCMAR126

Object Number

3.1

3.1.0-1

3.1.0-2

3.1.0-3

3.2

3.2.0-1

3.2.0-2

3.2.1

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

3 SYSTEM SAFETY

3.1 General

The developer shall document and implement a system safety program to include their facility, and the launch facilities; support the 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.

The System Safety program shall provide for early identification and control of hazards during design, fabrication, test, transportation, and ground activities.

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

⦁ 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 system is defined as all flight hardware, all supporting equipment, interfacing EGSE and MGSE, and facilities.

⦁ 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 system is defined as all flight hardware, supporting equipment, interfacing EGSE and MGSE, and facilities as applicable.

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

3.2 Mission Related Safety Requirements Documentation

The developer shall implement the launch range safety requirements that are applicable to the launch site.

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

3.2.1 ELV Eastern Test Range (ETR)

Page 11 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR196

SCMAR127

SCMAR128

SCMAR129

SCMAR130

SCMAR131

SCMAR132

SCMAR133

SCMAR134

SCMAR135

SCMAR136

SCMAR137

SCMAR138

SCMAR139

SCMAR140

Object Number

3.2.1.0-1

3.3

3.3.1

3.3.1.0-1

3.3.2

3.3.2.0-1

3.3.2.0-2

3.3.3

3.3.3.1

3.3.3.1.0-1

3.3.3.1.0-2

3.3.3.1.0-3

3.3.3.1.0-4

3.3.3.1.0-5

3.3.3.2

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

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

3.3.2 Safety Requirements Compliance Checklist

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

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

3.3.3 Hazard Analyses

3.3.3.1 Preliminary Hazard Analysis

The developer shall perform a Preliminary Hazard Analysis (PHA) in accordance with NASA-STD 8719.24 to obtain an initial risk assessment and to identify safety critical areas of a concept or system.

The developer shall 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), hazard probability and operational constraints.

The developer shall identify safety provisions and alternatives that are needed to eliminate hazards or reduce their associated risk to an acceptable level.

The developer shall deliver the PHA with the SDP I (DID 3-4).

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

Page 12 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR141

SCMAR142

SCMAR143

SCMAR144

SCMAR145

SCMAR146

Object Number

3.3.3.2.0-1

3.3.3.2.0-2

3.3.3.3

3.3.3.3.0-1

3.3.3.3.0-2

3.3.3.3.0-3

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

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

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

3.3.3.3 Mechanical Ground Support Equipment Safety Requirements

The MGSE, including but not limited to, lifting slings/spreader bars, handling and support fixtures, and shipping containers, shall provide the required mechanical support from lower level assembly operations through final Satellite I&T at all Spacecraft vendor facilities and the Launch Site Payload Processing Facility.

MGSE is divided into the following three categories: Lifting devices and equipment (LDE); Support and Handling MGSE; and Work Platforms, Stands, and other Personnel Access MGSE.

The developer shall implement the following safety requirements for 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 NASA Standard 8719.9 Standard for LDE (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.9.

⦁ 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.9, a proof test at 100% of the SWL for overhead cranes, mobile cranes, derricks, hooks, hydra-sets, load measuring devices, below the hook lifting devices/assemblies (e.g. lift fixtures), 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 load test every four years after the initial proof test or annually if at a GSFC facility.

⦁ Perform NDT inspections of single point failure critical welds on LDE and all Support and Handling MGSE after all load testing (a critical weld is one in which a failure would result in a failure of the hardware). The inspections shall be performed by an American Society of Nondestructive Testing (ASNT) or equivalently certified inspector.

Page 13 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR147

SCMAR150

SCMAR151

SCMAR152

SCMAR153

SCMAR154

SCMAR155

SCMAR156

SCMAR157

SCMAR158

SCMAR160

SCMAR161

SCMAR162

SCMAR163

SCMAR164

SCMAR165

Object Number

3.3.3.3.0-4

3.3.3.3.0-5

3.3.3.3.0-6

3.3.3.3.0-7

3.3.3.3.0-8

3.3.3.3.0-9

3.3.3.3.0-10

3.3.3.3.0-11

3.3.3.3.0-12

3.3.3.3.0-13

3.3.3.4

3.3.3.4.0-1

3.3.3.4.0-2

3.3.4

3.3.4.0-1

3.3.4.0-2

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

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.

Any lift hardware which attaches to the Spacecraft or Spacecraft component below the respective center of gravity shall be verified by an analysis to show that the lift is stable.

Support and Handling MGSE that is not being delivered to the Launch Site shall meet factors of safety requirements as defined in NASA-STD-5005D, Section 5.1.2 Factor of Safety [28].

Support and Handling MGSE that is not being delivered to the Launch Site shall be proof load tested to 150% of rated load.

LDE MGSE that interfaces to flight hardware and is not being delivered to the Launch Site shall meet requirements as defined in Chapter 14 of NASA-STD-8719.9.

Support and Handling MGSE shall be recertified at minimum to the working load once every four years.

A surface non-destructive test of all Support and Handling MGSE single point failure critical welds shall be performed after all proof load tests.

Work Platforms, Stands, and other Personnel Access MGSE shall meet requirements as defined in CFR 29 OSHA 1910.28.

Work Platforms, Stands, and other Personnel Access MGSE and dollies shall be subjected to stability analysis.

MGSE that is being delivered to the Launch Site shall meet requirements as defined in

NASA-STD-8719.24.

3.3.3.4 Operating and Support Hazard Analysis (O&SHA)

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 to ensure implementation of safety requirements for personnel, procedures, and equipment during activities at the launch site.

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

III (DID 3-4).

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 personnel, the flight system, ground support equipment, and their interfaces in hazard reports (DID 3-4).

The spacecraft developer shall integrate ISAR inputs from the instrument developers into the SDP.

Page 14 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR166

SCMAR167

SCMAR168

SCMAR169

SCMAR170

SCMAR171

SCMAR541

SCMAR172

SCMAR173

SCMAR174

SCMAR175

SCMAR176

SCMAR178

SCMAR179

SCMAR180

SCMAR181

Object Number

3.3.5

3.3.5.0-1

3.3.5.0-2

3.3.5.0-3

3.3.5.0-4

3.3.5.0-5

3.3.5.0-6

3.3.5.0-7

3.3.6

3.3.6.0-1

3.3.6.0-2

3.3.6.0-3

3.3.7

3.3.7.0-1

3.3.8

3.3.8.0-1

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

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 NASA-STD 8719.24 (with Annex) 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 (DID 3-4).

The VTL shall be delivered with the SDP III (DID 3-4).

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

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

Processing

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

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

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

3.3.7 Safety Waivers

The developer shall request waivers for variations from the applicable safety requirements per paragraph 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/PayloadSafety/Forms.

3.3.8 Support for Safety Working Group Meetings

Developer safety personnel shall support Safety Working Group (SWG) meetings, Payload Safety Working Group (PSWG) meetings, Technical Interface Meetings (TIMs), and technical reviews, as required. The PSWG will meet as necessary to review procedures and analyses that contain or examine safety critical functions, or as convened by the GeoXO project to discuss any situations that may arise with respect to overall project safety. The timeline for all safety reviews, beginning with the Payload Safety Introduction Briefing, is contained in NPR 8715.7, Section 3.4.

Page 15 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR182

SCMAR183

SCMAR184

SCMAR185

SCMAR186

SCMAR187

Object Number

3.3.9

3.3.9.0-1

3.3.9.0-2

3.3.9.0-3

3.3.10

3.3.10.0-1

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

3.3.9 Mishap Reporting and Investigation

The developer shall prepare a Pre-Mishap Plan, prior to initiating any project operations with potential for personnel injury or hardware damage, 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 (DID 3-6).

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

The developer shall promptly investigate to determine the root cause.

3.3.10 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/PayloadSafety/Forms.

Page 16 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR188

SCMAR189

SCMAR190

SCMAR191

SCMAR192

SCMAR193

SCMAR194

SCMAR195

SCMAR197

SCMAR198

Object Number

4.0-1

4.0-2

4.0-3

4.0-4

4.0-5

4.1

4.1.0-1

4.1.0-2

4.2

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

4 RELIABILITY

Reliability activities should be coordinated 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; likewise for safety risks (threats to personnel, the public, the environment, hosts, and facilities). All credible Single Point Failures (SPFs) shall be analyzed and considered for management within the project’s Risk Management process.

In addition, as designs evolve and change, the analyses described in this section shall be updated. Credible denotes that the likelihood is at least as high as the lowest likelihood on the pertinent risk scale.

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

The developer shall provide technical support to the GeoXO Project for the NASA-chaired Reliability Working Group (RWG) meetings and technical reviews, as required.

The RWG will meet as necessary, and as convened by NASA, to review reliability requirements and analyses, to assist in resolving reliability issues and concerns, and to discuss any situations that may arise with respect to the overall mission reliability.

The developer shall formally report on the progress of their reliability efforts through the PMSR and provide progress reports to the GSFC GeoXO Reliability Engineer through periodic reliability working group meetings as well as informal communications such as teleconferences and e-mails.

4.1 Reliability Program Plan (RPP)

The developer shall document and implement an RPP that includes both qualitative and quantitative techniques to support decisions regarding mission success and safety throughout system development (DID 4-1) that interacts effectively with other disciplines, including systems engineering, risk management, hardware design, software design, and product assurance to:

a. Demonstrate that the stress applied to parts meets applicable derating criteria assuming worst-case conditions;

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

c. Identify limited-life items and ensure that special precautions are taken to conserve their useful life for on-orbit operations; and

d. Perform trend analysis during fabrication and pre-launch I&T activities.

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

4.2 FMECA and Critical Items List (CIL)

Page 17 of 105 Printed Wednesday, February 16, 2022

ID

SCMAR199

SCMAR200

SCMAR201

SCMAR202

SCMAR203

SCMAR204

Object Number

4.2.0-1

4.2.0-2

4.2.0-3

4.2.0-4

4.2.0-5

4.2.0-6

418-XO-SCMAR-0083, RM Version, Geostationary eXtended Observations (GeoXO) Spacecraft (SC) Mission Assurance

Requirements (MAR)

The developer shall perform and maintain Failure Modes and Effects Criticality Analyses (FMECA) that address flight hardware, flight software, test facility equipment used for all Satellite level environmental testing, 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 developer shall include likelihood, cause, detection and mitigation, and the effects of each failure mode at the local, subsystem, and system or mission levels, to the interface level for existing systems and to the box or functional level for modified or new systems (DID 4 2).

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.

The developer shall prepare and maintain a Single Point…