GSFC-STD-1000G.pdf

Requests for information, corrections, or additions to this standard should be submitted via “Feedback” in the GSFC Technical Standards System at http://standards.gsfc.nasa.gov.

Goddard Space Flight Center

Rules for the Design, Development, and Operation of Flight Systems

GSFC-STD-1000

Revision G

Approved by: Original Signed by:

Chief Engineer Goddard Space Flight Center

Original Signed by:

Director of Applied Engineering and Technology Goddard Space Flight Center

Original Signed by:

Director of Flight Projects Goddard Space Flight Center

Original Signed by:

Director of Safety and Mission Assurance Goddard Space Flight Center

Table of Contents Introduction 6

Figure 1: NASA/GSFC Processes and Rules Hierarchy 8

Figure 2: Goddard Open Learning Design (G.O.L.D) Standard Architecture 9

Figure 3: GSFC Project Lifecycle 10

Figure 4: User's Guide 11

GSFC Rules

1.0 Systems Engineering

1.01 Reserved

1.02 Reserved

1.03 Reserved

1.04 Reserved

1.05 Single Point Failures 12

1.06 Resource Margins 13

Table 1.06-1 Technical Resource Margins 14

1.07 End-to-End GN&C Phasing 15

1.08 System End-To-End Testing 16

1.09 Test As You Fly 17

1.10 Reserved

1.11 Qualification of Heritage Flight Hardware 18

1.12 Reserved

1.13 Reserved

1.14 Mission Critical Telemetry and Command Capability 19

1.15 Reserved

1.16 Reserved

1.17 Safe Hold Mode 20

1.18 Reserved

1.19 Initial Thruster Firing Limitations 21

1.20 Wetted Joints of Hazardous Propellants 22

1.21 Overpressurization Protection in Liquid Propulsion Systems 23

1.22 Purging of Residual Test Fluids 24

1.23 Spacecraft “OFF” Command 25

1.24 Propulsion System Safety Electrical Disconnect 26

1.25 Redundant Systems 27

1.26 Safety Inhibits & Fault Tolerance 28

1.27 Propulsion System Overtemp Fuse 29

1.28 Unintended Propellant Vapor Ignition 30

1.29 Reserved

1.30 Controller Stability Margins 31

1.31 Actuator Sizing Margins 32

1.32 Thruster and Venting Impingement 33

1.33 Polarity Checks of Critical Components 34

1.34 Reserved

1.35 Maturity of New Technologies 35

1.36 Reserved

1.37 Stowage Configuration 36

1.38 Reserved

1.39 Propellant Sampling in Liquid Propulsion Systems 37

1.40 Maintaining Command Authority Of A Passive Spacecraft 38

1.41 GSE Use At Launch Site 39

1.42 Powering Off RF Command Receiver 40

1.43 Flight Software Update Demonstration 41

1.44 Early Interface Testing 42

1.45 System Alignments 43

1.46 Use Of Micro-Switches 44

1.47 Design Deployables For Test 45

1.48 Space Data Systems Standards 46

2.0 Electrical

2.01 Flight Electronic Hardware Operating Time 48

2.02 Reserved

2.03 Reserved

2.04 Reserved

2.05 System Grounding Architecture 49

2.06 System Fusing Architecture 50

2.07 Reserved; merged with 4.18 and removed

2.08 Reserved

2.09 Reserved

2.10 Reserved

2.11 Reserved

2.12 Reserved

2.13 Electrical Connector Mating 51

2.14 Protection of Avionics Enclosures External Connectors Against ESD 52

2.15 Reserved

2.16 Reserved

2.17 Reserved

2.18 Reserved; merged with 1.25 and removed

2.19 Reserved

2.20 Reserved

2.21 Reserved

2.22 Corona Region Testing of High Voltage Equipment 53

2.23 RF Component Testing For Multipaction and Corona 54

2.24 Solar Array Testing 55

2.25 Electrical Interface Verification 56

2.26 Power-On Reset Visibility 57

2.27 Spacecraft Strip-Charting Capability 58

3.0 Software

3.01 Verification and Validation Program for Mission Software Systems 59

3.02 Elimination of Unnecessary and Unreachable Software 60

Table 3.02-1: Unnecessary and Unreachable Software Definitions 61

Table 3.02-2: Sample Types of Unnecessary and Unreachable Software 61

3.03 High Fidelity Interface Simulation Capabilities 62

3.04 Independent Software Testing 63

3.05 Flight / Ground System Test Capabilities 64

3.06 Dedicated Engineering Test Unit for Flight Software Testing 65

3.07 Flight Software Margins 66

Table 3.07-1 Flight Software Margins 67

Resource Margins for Flight Software Development 67

3.08 Reserved

3.09 Reserved

3.10 Flight Operations Preparations and Team Development 70

Table 3.10: Simulation Types and Minimum Number of Successful Simulations / Test Hours versus Mission Class 71

3.11 Long Duration and Failure Free System Level Test of Flight and Ground System Software 72

3.12 Reserved

3.13 Maintaining Adequate Resources For Mission Critical Components 73

3.14 Command Procedure Changes 74

3.15 Reserved

4.0 Mechanical

4.01 Contamination Control, Planning, and Execution 75

4.02 Reserved

4.03 Factors of Safety for Structural Analysis and Design, and Mechanical Test Factors & Durations 76

4.04 Reserved

4.05 Reserved

4.06 Validation of Thermal Coatings Properties 77

4.07 Reserved

4.08 Reserved

4.09 Reserved

4.10 Minimum Workmanship 78

4.11 Testing in Flight Configuration 79

4.12 Structural Proof Testing 80

4.13 Reserved

4.14 Structural and Mechanical Test Verification 81

4.15 Torque Margin 82

4.16 Reserved

4.17 Reserved

4.18 Deployment and Articulation Verification 83

4.19 Reserved

4.20 Fastener Locking 84

4.21 Brush-type Motor Use Avoidance 85

4.22 Precision Component Assembly 86

4.23 Life Test 87

4.24 Mechanical Clearance Verification 88

4.25 Thermal Design Margins 89

4.26 Reserved

4.27 Test Temperature Margins 90

4.28 Thermal Design Verification 91

4.29 Thermal-Vacuum Cycling 92

5.0 Instruments

5.01 Reserved

5.02 Reserved

5.03 Reserved

5.04 Instrument Testing for Multipaction 93

5.05 Fluid Systems GSE 94

5.06 Flight Instrument Detector Characterization Standard 95

5.07 Reserved

5.08 Laser Development Contamination Control 96

5.09 Cryogenic Pressure Relief 97

5.10 Early Demonstration of Instrument Opto-Mechanical Alignment and Test 98

5.11 Instrument System Performance Margins 99

5.12 Instrument Alignment, Integration and Test 100

5.13 Laser Life Testing 101

Glossary and Acronym Guide 102

Change History 111

INTRODUCTION

Purpose:

The Goddard Open Learning Design (GOLD) Rules specify sound engineering principles and practices, which have evolved in the Goddard community over its long and successful flight history. They are intended to describe foundational principles that “work,” without being overly prescriptive of an implementation “philosophy.” The GOLD Rules are a select list of requirements, which warrant special attention due either to their historical significance, or their new and rapidly evolving nature.

The formalization of key requirements helps establish the methodology necessary to consistently and efficiently achieve safety and mission success for all space flight products. The GOLD Rules share valuable experiences, and communicate expectations to developers. Where appropriate, the rules identify typical activities across lifecycle phases with corresponding evaluation criteria. The GOLD Rules also provide a framework for the many responsible Goddard institutions to assess and communicate progress in the project’s execution. The GOLD Rules ensure that GSFC Senior Management will not be surprised by late notification of noncompliance to sound and proven engineering principles that have made GSFC missions consistently successful. Each GOLD Rule specifies requirements in the form of a Rule Statement, along with supporting rationale, and guidance in the form of typical lifecycle phase activities and verifications.

Scope:

The GOLD Rules focus on fundamental principles and practices, and therefore are intended to apply to all space flight projects (and where applicable, associated ground projects) regardless of implementation approach or mission classification (except where explicitly noted). Whenever necessary, rules clarify requirements and expectations consistent with different mission classifications. Although not required, an a priori Mission Exceptions List (MEL) may be proposed at the start of a Program and/or Project, to highlight rules which may not apply to that mission. If a MEL is submitted and approved, waivers will not be required for exceptions covered by the MEL unless changes occur to the underlying basis for exception. For rules that include multiple elements (e.g., “test as you fly”), waivers and exceptions are valid for the specific elements indicated in a MEL or waiver and do not constitute a global approval to waive all elements of that rule. Other exceptions that arise during execution of the mission still require waivers, as appropriate. A MEL approved at the program level for multi project programs will be reviewed at key points in the program lifecycle (e.g. at the release of a new Announcement of Opportunity) to validate its applicability for new Projects within that program.

The GOLD Rules is a living document, periodically assessed and updated to improve its clarity of purpose and effectiveness. While the engineering principles and practices are stable, the select set of requirements may evolve based on whether they continue to warrant increased visibility by their inclusion. The intent is to improve the GOLD Rules over time, not to grow it in size, complexity, and coverage so that it becomes more cumbersome and less helpful over time. Requirements temporarily included because of their new and rapidly evolving nature, must be accompanied by transition plan out of GOLD rules and into an appropriate lower level document.

GSFC Rules are governed by GPR 8070.4, configuration-controlled and accessible to all GSFC employees. A technical authority designated for each rule will be responsible for requirements validation, rationale verifications, related guidance and lessons learned, and participation in the evaluation of proposed changes and waivers. The process for submitting waivers is described in GPR

8070.4. Note, for any rule listing multiple owners, the project should work any waiver requests with the owner designated as “primary” and it will be the responsibility of the “primary owner” to get concurrence from the other owners.

Figure 2

Figure 3 (Reference: NPR 7120.5, The NASA Project Lifecycle)

User's Guide

Rule # Title Discipline

Rule Rule Statement – The requirement.

Rationale: Statement(s) providing justification, clarification and/or context.

Phase: <A A B C D E F Activities:

Verification:

Revision Status:

When implemented/modified Owner:

Subject Matter Expert / Technical Authority Reference:

Supporting Materials

Figure 4

Rule-associated best practices, within each phase, to ensure compliance (guidance only)

Rule-associated best practices, within each phase, to ensure compliance (guidance only)

1.05 Single Point Failures Systems Engineering

Rule:

Single point failures that prevent the ability to fully meet Mission success requirements shall be identified, and the risk associated with each shall be characterized, managed, and tracked and the system trades necessary to determine the need and effectiveness of mitigation efforts (e.g., redundancy, selection of robust parts, etc.) commensurate with mission class shall be conducted and documented. NOTE: Does not apply to missions explicitly architected as single-string.

Rationale: Robust design approaches make the elimination of single point failures desirable. From a risk management perspective, it is recognized that the acceptance of some single point failures may be prudent. In these cases, it is essential to understand the attendant risks and ensure that they are communicated to senior management.

Phase: <A A B C D E F Activities: 1. Identify all requirements necessary for minimum Mission success.

2. Determine if a breach of any of these requirements will cause the minimum mission to fail.

1. Identify failures that would cause the minimum mission to fail and develop a design strategy to avoid single point failures.

1. Identify failures for all hardware and software that performs mission-critical functions.

2. Develop a design to avoid single point failures.

1. Design mission-critical elements to avoid single point failures.

2. Identify and communicate single point failures to stakeholders and review panels

3. Characterize the risk likelihood and consequences of any single point failures

4. Identify mitigation strategies for the single point failures identified

1. Communicate single point failures to stakeholders and review panels.

2. Provide mitigation status of any identified single point failures

N/A N/A

Verification: 1. Verify or present management exceptions at MCR.

1. Verify or present management exceptions at MDR.

1. Verify or present management exceptions at PDR.

1. Verify or present management exceptions at CDR.

1. Verify or present management exceptions at PER and PSR.

N/A N/A

Revision Status:

Rev. E, Updated Rev G

Owner:

Mission Engineering and Systems Analysis Division (590)

1.06 Resource Margins Systems Engineering

Rule: Total (contingency plus reserve) resource margins shall be met in accordance with Table 1.06-1. The allocation of system margin between contingency and reserve shall be at the discretion of the project.

Rationale: Compliance with these margins improves performance on cost and schedule as well as overall mission performance.

NOTE: Flight software margin guidelines are covered in Rule 3.07.

Phase: <A A B C D E F Activities: 1. Identify resource margins.

2. Identify the percent of resource that was determined by estimation, calculation or measurement.

1. Update resource margins.

2. Identify the percent of resource that was determined by estimation, calculation or measurement.

1. Update resource margins.

2. Identify the percent of resource that was determined by estimation, calculation or measurement.

1. Update resource margins.

2. Identify the percent of resource that was determined by estimation, calculation or measurement.

1. Update resource margins.

N/A N/A

Verification: 1. Verify at MCR. 1. Verify at ICR and

MDR.

1. Verify at PDR and confirmation review.

1. Verify at CDR. 1. Verify at PER and

PSR.

N/A N/A

Revision Status:

Baseline; Updated: Rev G

Owner:

Mission Engineering and Systems Analysis Division (590)

AIAA Guidelines

1.07 End-to-End GN&C Phasing Systems Engineering

All GN&C sensors and actuators shall undergo end-to-end (i.e., from sensor stimulus to actuator response) phasing/polarity testing after spacecraft integration in the final flight configuration (hardware and software), and shall have flight software mitigations to efficiently correct phasing/polarity errors.

The test methodology and results shall be independently reviewed.

Rationale: Inadequate verification of signal phasing or polarity can result in unexpected on-orbit performance and possible loss of mission. Component-level and end-to-end phasing tests and flight software mitigations can ensure correct operation.

Phase: <A A B C D E F Activities: N/A N/A 1. Define interface requirements of sensors and actuators.

2. Design flight software to include capability to fix polarity problems via table upload.

1. Update ICDs to include polarity definition.

2. Review vendor unit-level phasing test plans.

3. Write flight S/W to include capability to fix polarity problems via table upload.

4. Create unit-level & end-to-end phasing test plan.

1. Perform unit-level phasing tests.

2. Test flight S/W for table upload functionality.

3. Perform end to-end phasing test for all sensor-to-actuator combinations.

4. Develop & test contingency flight ops procedures for fixing phasing problems.

5. Conduct an independent review of the methodology and results

N/A N/A

Verification: N/A N/A 1. Verify through peer review and at

PDR.

1. Verify through peer review and at

CDR.

1. Verify phasing methodology/results at PSR and FSW/Ops mitigations at ORR.

N/A N/A

Revision Status:

Rev. E, Updated Rev G

Owner:

Guidance, Navigation, and Control Systems Engineering Branch (591)

ACS Handbook sec. 7.3.3.1

1.08 System End-to-End Testing Systems Engineering

System end-to-end testing shall be performed in the final flight configuration, hardware and software. End-to-end testing shall be from instrument(s) sensor input, through the spacecraft, to a command and telemetry ground system.

Rationale: End-to-end testing is the best verification of the system's functionality..

Phase: <A A B C D E F Activities: 1. Identify end-to-end tests that represent system-level functions.

1. Review and update the list of end-to-end tests and analyses identified in Pre-phase A.

2. Define success criteria for verification and incorporate into verification plan.

3. Review and update verification plan and schedule.

4. Identify facilities required for end-to-end testing.

1. Review and update list of end-to end tests and analyses identified in Phase A.

2. Review and update verification plan and schedule.

3. Identify test plans and facilities that need to be in place for end-to-end testing.

1. Draft final verification plan.

2. Sign off on plan, put under CM test schedule.

3. Identify and schedule sequence of analyses and testing for verifying end-to-end flight performance.

4. Quantify the fidelity of each verification step.

1. Perform end-to-end testing per the plan developed in Phase C.

N/A N/A

Verification: 1. Verify all elements of the operating observatory and ground system at

MCR.

1. Verify at MDR. 1. Verify at SDR or

SRR, PDR.

1. Verify at CDR. 1. Verify at PSR and

LRR.

N/A N/A

Revision Status:

Rev. F, Updated Rev G

Owner:

Mission Systems Engineering Branch (599)

GEVS 2.8

1.09 Test as You Fly Systems Engineering

All GSFC missions shall follow a, "Test as You Fly (TAYF) - Fly as You Test" approach, throughout all applicable life cycle phases. Each deviation to this approach, along with the rationale for the deviation, shall be documented and a waiver submitted. Note: A waiver or exception to this rule will be based only on the specific elements that appear and are approved in the request and is not a global approval to waive TAYF for all elements.

Rationale: Testing of all critical mission-operation elements as they will be flown greatly reduces the risk of encountering negative impacts upon Mission success, from partial to full loss of mission capability.

Phase: <A A B C D E F Activities: 1. Develop the preliminary test plan employing a TAYF philosophy.

1. Develop final test plan, employing a TAYF philosophy.

2. Develop a preliminary list of TAYF exceptions and discuss with rule owners.

1. Develop test procedures employing a TAYF philosophy.

1. Perform testing per plan / procedures.

N/A N/A

Verification: 1. Verify at MDR. 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PER. N/A N/A

Revision Status:

Rev. F, Updated Rev G

Owner:

Mission Engineering and System Analysis Division (590, Primary) and Instrument Systems and Technology Division (550)

1.11 Qualification of Heritage Flight Hardware Systems Engineering

All heritage flight hardware shall be fully qualified and verified for use in its new application. This qualification shall take into consideration necessary design modifications, changes to expected environments, and differences in operational use.

Rationale: All hardware, whether heritage or not, must be qualified for its expected environment and operational uses.

Phase: <A A B C D E F Activities: 1. Identify/list heritage hardware to be used and make a cursory assessment of "use as is" or delta-qual.

2.Determine life expectancy of the residual spare flight hardware to be used from previous flight projects including implications of obsolete parts.

1. Update hardware list and identify the qualification requirements.

2. Assess through the peer review process the ultimate applicability of previously flown/heritage hardware designs.

1. Refine/finalize heritage hardware list and the required qualification requirements.

1. Qualify heritage hardware as part of overall qualification of mission hardware.

1. Develop, test, and integrate the flight articles.

N/A N/A

Verification: 1. Review summary documentation at

MCR.

1. Review summary documentation at

MDR.

1. Review summary documentation at

PDR.

1. Review summary documentation at

CDR.

1. Review summary documentation at PER and PSR.

N/A N/A

Revision Status:

Rev. F, Updated Rev G

Owner:

Mission Systems Engineering Branch (599)

1.14 Mission Critical Telemetry and Command Capability Systems Engineering

Continuous telemetry coverage shall be maintained during all mission-critical events. Mission-critical events shall be defined to include separation from the launch vehicle; power-up of major components or subsystems; deployment of mechanisms and/or mission-critical appendages; initial thruster firings and all planned propulsive maneuvers required to establish mission orbit and/or achieve safe attitude. Following launch vehicle separation, critical deployments, and initial orbit attitude acquisition, continuous command coverage shall be maintained during all subsequent mission-critical events.

Rationale: With continuous telemetry and command capability, operators can prevent anomalous events from propagating to mission loss. Also, flight data will be available for anomaly investigations.

Phase: <A A B C D E F Activities: 1. Identify and document potential mission-critical events in concept of operations.

2. Identify and document in concept of operations all potential needs for communications coverage, such as TDRSS or backup ground stations.

1. Update concept of operations.

2. Identify requirements for critical event coverage in ground system design.

1. Address and document coverage of mission critical events in draft of Mission Operations Concept.

2. Address critical event coverage in requirements for ground system design.

1. In Operation Plan, identify telemetry and command coverage for all mission-critical events.

1. Update Operations Plan.

2. Address telemetry and command coverage of critical events in Operations Procedures.

1. Perform critical events with telemetry and command capability.

N/A

Verification: 1. Verify or present exceptions at MCR.

1. Verify or present exceptions at MDR.

1. Verify or present exceptions at PDR.

1. Verify or present exceptions at CDR.

1. Verify or present exceptions at ORR.

1. Verify telemetry capability for events not excepted in Phase D during mission operations.

N/A

Revision Status:

Rev. F, Updated Rev G

Owner:

1.17 Safe Hold Mode Systems Engineering

All spacecraft shall have a power-positive, thermally safe, control mode (Safe Hold) to be entered in spacecraft emergencies. Safe Hold Mode shall have the following characteristics: (1) its safety shall not be compromised by the same credible fault that led to Safe Hold activation; (2) it shall be as simple as practical, employing the minimum hardware set required to maintain a safe attitude; and (3) it shall require minimal ground intervention for safe operation.

Rationale: Safe Hold Mode should behave very predictably while minimizing its demands on the rest of the spacecraft. This facilitates the survival, diagnosis, and recovery of the larger system. Complexity typically reduces the robustness of Safe Hold, since it increases the risk of failure due to existing spacecraft faults or unpredictable controller behavior.

Phase: <A A B C D E F Activities: 1. Ensure that requirements document and operations concept include Safe Hold Mode.

1. Ensure that requirements document and operations concept include Safe Hold Mode.

1. Identify hardware & software configuration for Safe Hold Mode.

2. In preliminary assessment, demonstrate that no single credible fault can both trigger Safe Hold entry and cause Safe Hold failure.

3. Analyze performance of preliminary Safe Hold algorithms.

1. Establish detailed Safe Hold design including entry/exit criteria and FDAC requirements for flight software.

2. In final assessment, demonstrate that no single credible fault can both trigger Safe Hold entry and cause Safe Hold failure.

3. Analyze performance of Safe Hold algorithms.

4. Via a rigorous risk assessment, decide whether or not to test Safe Hold on-orbit.

1. Implement Safe Hold Mode.

2. Verify proper mode transitions, redundancy, and phasing in ground testing.

3. Execute recovery procedures during mission simulations.

4. Perform on-orbit testing if applicable.

N/A N/A

Verification: 1. Verify through peer review and at

MCR.

1. Verify through peer review and at

MDR.

1. Verify through peer review and at

PDR.

1. Verify through peer review and at

CDR.

1. Verify at PER and

FOR.

N/A N/A

Revision Status:

Rev. G

Owner:

Attitude Control Systems Engineering Branch (591)

1.19 Initial Thruster Firing Limitations Systems Engineering

If alternate actuators (e.g. reaction wheels) are present, the momentum induced by initial thruster firings shall be within the alternate actuators' capability to execute safe recovery of the spacecraft.

Rationale: Polarity issues and thruster underperformance typically occur early in the mission. Both conditions can result in a spacecraft emergency due to excessive spacecraft spin rates.

Phase: <A A B C D E F Activities: 1. The Attitude

Control System (ACS) Concept shall ensure that thrusters will not be required during launch vehicle separation for a 3-sigma distribution of cases. The concept for operations shall ensure that, except in case of emergency, all thrusters can be test-fired on-orbit prior to the first delta-v maneuver.

1. The Attitude Control System shall design the thruster electronics, size and place the thrusters, and size other actuators (e.g.

reaction wheels) such that a failed thruster can be shut down and the momentum absorbed before power or thermal constraints are violated. The activities specified in Pre-Phase A shall be maintained.

1. Hardware (processors, power interfaces, data interfaces, etc.) and software shall ensure that anomalous thruster firings will be shut down quickly enough to allow recovery of the spacecraft to a power-safe and thermal-safe condition.

2. Develop design and operations concept consistent with the activities established in Pre- Phase-A.

1. Establish detailed recovery procedures.

Finalize design and operations concept consistent with the activities established in Pre-Phase-A.

1. Test failed thruster conditions with the greatest possible fidelity. Verify transitions and polarity.

2. Ensure that recovery procedures have been simulated with the flight operations team.

3. During on-orbit testing, thrusters shall be test fired to verify polarity and performance prior to being used in a closed loop control.

1. Ground contact shall be maintained during thruster firings.

1. Maintain activity per Phase E.

2. Document any lessons learned.

Verification: 1. GN&C and system engineering organizations shall verify at MCR.

1. GN&C and system engineering organizations shall verify at MDR.

1. GN&C and system engineering organizations shall verify at PDR.

1. GN&C and system engineering organizations shall verify at CDR.

1. GN&C and system engineering organizations shall verify at SAR.

2. Follow-up at Operational Readiness Review

(ORR).

1. Document lessons learned.

1. GN&C and system engineering organizations shall verify at DR.

2. GN&C and system engineering organizations document lessons learned.

Revision Status:

Rev. F, Updated Rev G

Owner:

Attitude Control Systems Engineering Branch (591)

1.20 Wetted Joints of Hazardous Propellants Systems Engineering

All joints in the propellant lines between the propellant supply tank and the first isolation valve shall be NDE-verified welds.

Rationale: Failure of wetted joint poses a catastrophic threat to personnel and/or facility.

Phase: <A A B C D E F Activities: N/A N/A 1. Confirm system requirements for welded tubing joints between the propellant supply tank and the first isolation valve.

1. Present weld & technician certification plans and NDE plans.

1. Certify integrity of welds by NDE.

N/A N/A

Verification: N/A N/A 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PER. N/A N/A

Revision Status:

Rev. E, Updated Rev. G

Owner:

Propulsion Branch (597)

1.21 Overpressurization Protection in Liquid Propulsion Systems Systems Engineering

The propulsion system design and operations shall preclude damage due to pressure surges ("water hammer"). (Note: See also rule 1.28 "Unintended Propellant Vapor Ignition.")

Rationale: Pressure surges could result in damage to components or manifolds, leading to failure of the propulsion system, damage to facilities, and/or safety risk to personnel.

Phase: <A A B C D E F Activities: N/A N/A 1. Perform pressure surge analysis, based on worst-case operating conditions, to determine maximum surge pressure.

2. If maximum surge pressure is greater than system proof pressure, incorporate design features to reduce surge pressure below proof pressure.

1. Demonstrate by test that maximum surge pressure is less than proof pressure of the affected components and tubing manifolds.

2. Demonstrate by test that surge-suppression features (if applicable) do not lead to violation of flow-rate/pressure drop requirements.

3. Demonstrate by analysis that flight SW and/or on-orbit procedures will prevent operation of propulsion system beyond conditions assumed in pressure surge analyses and tests.

N/A N/A N/A

Verification:

N/A N/A 1. Verify at PDR. 1. Verify at CDR. N/A N/A N/A

Revision Status:

Rev. E

Owner:

1.22 Purging of Residual Test Fluids Systems Engineering

Propulsion system design and the assembly & test plans shall preclude entrapment of test fluids that are reactive with wetted material or propellant.

Rationale: Residual test fluids can be reactive with the propellant or corrosive to materials in the system leading to critical or catastrophic failure.

Phase: <A A B C D E F Activities: N/A N/A 1. If test fluids are used in the assembled system, present plans for purging & drying of system.

1. Demonstrate that the method for drying the wetted system has been validated by test on an equivalent or similar system.

1. Verify dryness of wetted system by test.

N/A N/A

Verification: N/A N/A 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PSR. N/A N/A

Revision Status:

Rev. E

Owner:

1.23 Spacecraft “OFF” Command Systems Engineering

No single command shall result in Spacecraft "OFF." This includes both the single string spacecraft case and the redundant spacecraft with one side failed case.

Rationale: Requiring multiple actions to power off the spacecraft will mitigate the possibility of an unintentional spacecraft power off.

Phase: <A A B C D E F Activities: 1. Complete applicability assessment.

1. Reassess and update applicability.

2. Complete initial compliance assessment, based upon applicability.

1. Reassess compliance.

2. Ensure flow-down traceability to appropriate sub-system in draft technical requirements and Design-To specifications.

3. Define verification approach.

2. Ensure flow-down traceability to appropriate sub-system in technical requirements and Design-To specification baselines.

3. Update verification

2. Perform verification activity.

N/A N/A

Verification: Verify at MCR.

Verify at SRR, MDR..

Verify at PDR.

Verify at CDR and

SIR.

Verify at ORR, SMSR, and FRR.

Revision Status:

Rev. F, Updated Rev. G

Owner:

1.24 Propulsion System Safety Electrical Disconnect Systems Engineering

An electrical disconnect "plug" and/or set of restrictive commands shall be provided to preclude inadvertent operation of propulsion system components.

Rationale: Unplanned operation of propulsion system components (e.g. 'dry' cycling of valve; heating of catalyst bed in air; firing of thrusters after loading propellant) can result in injury to personnel or damage to components.

Phase: <A A B C D E F Activities: N/A N/A 1. Present design and/or operational plan that preclude unplanned operation of propulsion system components.

1. Present detailed design of electrical disconnect and/or set of restrictive commands to preclude unplanned operation of propulsion system components.

2. Present detailed plan for verification of operation after installation for flight (for electrical disconnect plugs).

See rule 2.25, Electrical Interface Verification.

1. Demonstrate the effectiveness of the disconnect and/or set of restrictive commands by test.

N/A N/A

Verification: N/A N/A 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PER. N/A N/A

Revision Status:

Rev. E, Updated Rev. G

Owner:

1.25 Redundant Systems Systems Engineering

When redundant systems or functions are implemented, the redundant components, or functional command paths, shall be independent, such that the failure of one component or command path does not affect the other component or command path. Critical single point failures due to electrical, thermal, mechanical and functional dependencies should be documented. The design shall avoid routing of redundant power/signals through a single connector, relay, integrated circuit or other common interface.

Rationale: For redundancy to have its desired effects to enhance system reliability, care must be taken to maintain independence between the redundant and primary systems.

Phase: <A A B C D E F Activities: 1. Complete

2. Complete initial compliance

2. Ensure flow-down traceability to appropriate sub-system in draft technical requirements and Design-To specifications.

2. Ensure flow-down traceability to appropriate sub-system in technical requirements and Design-To specification baselines.

Verification: 1. Verify at MCR.

1. Verify at SRR, MDR, and PNAR.

1. Verify at PDR and

NAR.

1. Verify at CDR and

1. Verify at ORR, Rev. F, Updated Rev. G

Owner:

1.26 Safety Inhibits & Fault Tolerance Systems Engineering

The external leakage of hazardous propellant is a Catastrophic Hazard, and requires three independent inhibits to prevent it. Dynamic seals (e.g.

solenoid valves) shall be independently verified as close to propellant loading as possible. Static seals (i.e. crush gaskets, o-rings, etc.) are recognized as non-verifiable at the system level. The integrity of these seals shall be controlled by process or procedures consistent with industry standards.

Secondary/tertiary seals and materials internal to the device that would be exposed in the event the primary seal fails shall be compatible with the working fluid. Components where fault tolerance is not credible or practical (e.g., tanks, lines, etc.) shall use design for minimum risk instead.

Rationale: Adequate control of safety hazards is necessary in order to develop safe hardware and operations. Verification of independence of inhibits is necessary to preclude propagation of failure in safety inhibits that can result in critical or catastrophic threats to personnel or facility.

The internal volume between redundant inhibits (seals) shall be limited to the minimal practical volume and designed to limit the external leakage in the event of failures.

Phase: <A A B C D E F Activities: N/A N/A 1. Identify proposed design inhibits that preclude hazardous condition and document in preliminary hazard analysis.

2. Present compliance with range safety requirements, including fault tolerance to hazardous events.

Document in subsystem design and initial MSPSP.

1. Demonstrate by analysis or component test that A) failure in selected inhibit will not cause failure of the other inhibits, or B) that no single event or software command can open multiple inhibits.

2. Provide implementation details of the fault tolerance requirements of propulsion system.

Document in subsystem design and Intermediate

MSPSP.

1. Demonstrate by analysis or component test that A) failure in selected inhibit will not cause failure of the other inhibits, or B) that no single event or software command can open multiple inhibits.

2. Provide hazard control verification details addressing fault tolerance of propulsion system.

Document in subsystem design and Final MSPSP.

N/A N/A

Verification: N/A N/A 1. Verify at PDR and in Preliminary MSPSP/Safety Data Package.

1. Verify at CDR and in Intermediate MSPSP/Safety Data Package.

1. Verify in Final MSPSP Safety Data Package.

N/A N/A

Revision Status:

Rev. F, updated Rev G

Owner:

System Safety Branch (321) & Propulsion Branch (597)

1.27 Propulsion System Overtemp Fuse Systems Engineering

Flight fuses (or other over-current protection devices) for wetted propulsion system components shall be selected such that overheating of propellant will not occur at the maximum current limit rating of the flight fuse. (Note: See also rule 2.06 "System Fusing Architecture.")

Rationale: Propulsion components such as pressure transducers normally draw very low current, and therefore their fuses are usually oversized. In such cases it may be possible for a malfunctioning component to overheat significantly without exceeding the rating of the fuse. Any wetted component (i.e., in addition to fuses) that could be continuously powered should also be considered. Exceeding the auto-ignition temperature of propellant can result in mission failure or critical/catastrophic hazard to personnel and facility.

Phase: <A A B C D E F Activities: N/A N/A 1. Present fusing plan for wetted propulsion system components.

1. Present mitigation plan and/or over-current thermal analysis to show that wetted components will not exceed maximum allowable temperature of propellant at the maximum current limit rating for the flight fuse.

2. Verify that a single failure within the drive electronics of pulsed components will not result in the pulse components being continuously powered.

1. Verify by inspection of QA records that the correct flight fuse has been installed.

N/A N/A

Verification: N/A N/A 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PER or

PSR.

N/A N/A

Revision Status:

Rev. E, Updated Rev. G

Owner:

Propulsion Branch (597, Primary), Component Hardware Systems Branch (596)

EEE-INST-002

1.28 Unintended Propellant Vapor Ignition Systems Engineering

Propulsion system design and operations shall preclude ignition of propellants in the feed system.

Rationale: Ignition of propellant vapor can occur due to a variety of conditions including (1) mixing of fuel and oxidizer in pressurant manifolds via diffusion and condensation; (2) pyrotechnic valve initiator products entering propellant manifolds; (3) adiabatic compression of gas due to pressure surges, i.e.

"water hammer" effects. These conditions can cause hardware damage and/or mission failure.

Phase: <A A B C D E F Activities: N/A N/A 1. Present design analysis, including pyro valve firing sequence and/or propellant line initial pressurization, supporting mitigation of conditions for ignition of propellant vapors.

2. For bipropellant systems, demonstrate by analysis that the design provides adequate margin against diffusion and condensation of propellant vapors in common manifolds.

1. Demonstrate by analysis or test that pyro valve firing sequence and/or propellant line initial pressurization plan will not promote conditions for ignition of propellant vapor.

2. For bipropellant systems, demonstrate by test that selected pressurant system components exhibit vapor diffusion resistance per the Phase B analysis.

N/A N/A N/A

Verification: N/A N/A 1. Verify at PDR. 1. Verify at CDR. N/A N/A

Revision Status:

Rev. E

Owner:

1.30 Controller Stability Margins Systems Engineering

The Attitude Control System (ACS) shall have stability margins of at least 6db for rigid body stability with 30 degrees phase margin. The magnitude of the flexible modes in the open-loop transfer function shall be less than minus 12dB.

Rationale: Proper gain and phase margins are required to maintain stability for reasonable unforeseen changes and uncertainty in spacecraft configuration.

Phase: <A A B C D E F Activities: 1. Identify in the

Attitude Control System (ACS) Concept if the gain and phase margin requirements will be difficult to meet due to the spacecraft configuration.

1. Update the ACS concept and identify if the gain and phase margin requirements will be difficult to meet due to the spacecraft configuration.

1. Design all control modes so that the rigid body stability margins are at least 6 dB of gain margin and 30 degrees of phase margin.

2. Ensure that the magnitude of the flex ble modes in the open-loop transfer function is less than minus 12dB.

1. Stability analyses should include all flexible mode effects, sample data and delay effects (and other nonlinear effects such as fuel slosh) incorporated with adequate evaluation of mode shape, damping and frequency uncertainties.

1. Verify that the stability analyses presented at CDR encompass the “as built” mass properties and flexible body models.

2. Update CDR analyses if necessary to verify that stability margin requirements are met.

Verification: 1. GN&C and system engineering organizations verify at MCR.

1. GN&C and system engineering organizations verify at MDR.

1. GN&C and system engineering organizations verify at PDR.

1. GN&C and system engineering organizations verify at CDR.

1. GN&C and system engineering organizations verify at PSR.

N/A N/A

Revision Status:

Rev. F, Updated Rev. G

Owner:

Attitude Control Systems Engineering Branch (591)

ACS Handbook

1.31 Actuator Sizing Margins Systems Engineering

The Attitude Control System (ACS) actuator sizing shall reflect specified allowances for mass properties growth.

Rationale: Knowledge of spacecraft mass and inertia can be very uncertain at early design stages, so actuator sizing should be done with the appropriate amount of margin to ensure a viable design.

Phase: <A A B C D E F Activities: N/A 1. ACS actuators

(including propulsion) shall be sized for the current best estimate of spacecraft mass properties with 100% design margin.

1. ACS actuators (including propulsion) shall be sized for the current best estimate of spacecraft mass properties with 50% design margin.

1. ACS actuators (including propulsion) shall be sized for the current best estimate of spacecraft mass properties with 25% design margin.

N/A N/A N/A

Verification: N/A 1. GN&C and system engineering organizations shall verify at MDR.

1. GN&C and system engineering organizations shall verify at PDR.

1. GN&C and system engineering organizations shall verify at CDR.

N/A N/A N/A

Revision Status:

Rev. F

Owner:

Attitude Control Systems Engineering Branch (591)

ACS handbook

1.32 Thruster and Venting Impingement Systems Engineering

Thruster or external venting plume impingement shall be analyzed and demonstrated to meet mission requirements.

Rationale: Impingement is likely to contaminate critical surfaces and degrade material properties and can also create adverse and unpredictable S/C torques and unacceptable localized heating.

Phase: <A A B C D E F Activities: N/A N/A 1. Develop analytical mass transport model.

2. Update as design evolves.

1. Refine analysis based on updated designs.

1. Refine analysis based on updated designs.

2. Measure venting rates during T/V tests and verify analysis.

N/A N/A

Verification: N/A N/A 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PSR. N/A N/A

Revision Status:

Rev. F

Owner:

Mission Engineering and Systems Analysis Division (590)

1.33 Polarity Checks of Critical Components Systems Engineering

All hardware shall be verified by test and inspection for the proper polarity, orientation, and position of all components (sensors, switches, and mechanisms) whose performance is affected by these parameters

Rationale: Each spacecraft and instrument contains many components that can be reversed easily during installation. Unless close inspections are performed, and proper installations are verified by test, on-orbit failures can occur when these components are activated.

Phase: <A A B C D E F Activities: N/A 1. Identify all polarity-dependent components in the spacecraft design concept.

2. Ensure that design concept provides capability for testing functionality of polarity-dependent components at end-to-end mission system level, in addition to subsystem level.

1. Identify all polarity-dependent components in the spacecraft preliminary design.

2. Ensure that preliminary design provides capability for testing functionality of polarity-dependent components at end-to-end mission system level, in addition to subsystem level.

3. Develop test plan for polarity-dependent components.

1. Identify all polarity-dependent components in the spacecraft detailed design.

2. Ensure that detailed design provides capability for testing functionality of polarity-dependent components at end-to-end mission system level, in addition to subsystem level.

3. Develop test procedures for polarity-dependent components.

1. Execute polarity tests at subsystem and end-to-end mission system levels.

N/A N/A

Verification: N/A 1. Verify through peer review and at

MDR.

1. Verify through peer review and at

PDR.

1. Verify through peer review and at

CDR.

1. Verify through peer review, at PER, and at PSR.

N/A N/A

Revision Status:

Rev. E

Owner:

1.35 Maturity of New Technologies Systems Engineering

All technologies shall achieve a TRL 6 by PDR. Not applicable to technology demonstration opportunities.

Rationale: The use of new and unproven technologies requires a thorough qualification program in order to reduce development risk to an acceptable level.

Phase: <A A B C D E F Activities: 1. Identify relevant technologies, readiness levels, develop overall risk mitigation plan (including fall back to existing technologies), and conduct peer review(s).

1. Develop qualification plan for specific technologies, including risk mitigation. Peer review plan.

1. Implement qualification plan and demonstrate that TRL 6 has been achieved. Peer review qualification results.

N/A N/A N/A N/A

Verification: 1. Review summary documentation at

MCR.

1. Review summary documentation at

MDR.

1. Review summary documentation at

PDR.

N/A N/A N/A N/A

Revision Status:

Rev. E

Owner:

Applied Engineering and Technology Directorate (500)

1.37 Stowage Configuration Systems Engineering

When a spacecraft is in its stowed (launch) configuration, it shall not obscure visibility of any attitude sensors required for acquisition, and shall not block any antenna required for command and telemetry.

Rationale: Establishment of spacecraft communications and acquisition of safe attitude are the two highest-priority post-separation activities, and should not be dependent on completion of deployments.

Phase: <A A B C D E F Activities: N/A 1. Demonstrate by inspection that mechanical subsystem concept allows for full visibility of sensors and telemetry & command antennas.

1. Demonstrate by field-of-view analysis that mechanical subsystem preliminary design allows for full visibility of sensors and telemetry & command antennas.

1. Demonstrate by field-of-view analysis that mechanical subsystem detailed design allows for full visibility of sensors and telemetry & command antennas.

1. Ensure during I&T that mechanical subsystem detailed design allows for full visibility of sensors and telemetry & command antennas.

N/A N/A

Verification: N/A 1. Verify at MDR. 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PER. N/A N/A

Revision Status:

Rev. E

Owner:

1.39 Propellant Sampling in Liquid Propulsion Systems Systems Engineering

Liquid propellant quality shall be verified by sampling at point of use prior to loading spacecraft propulsion system.

Rationale: Contaminated propellant could result in damage to components or manifolds, leading to failure of the propulsion system with a potential impact on mission success. If detected after loading propellant into the flight system, purging and cleansing the propulsion system of contaminants would incur significant cost and result in launch delay.

Phase: <A A B C D E F Activities: N/A 1. Ensure propellant sampling is included in project planning.

1. Include propellant sampling requirements in the propulsion system design process including the design of the GSE.

2. Include discussions of propellant sampling requirements in Ground Operations Working Group

(GOWG).

1. Incorporate propellant sampling in development of fuel loading procedures.

2. Incorporate propellant sampling considerations into fuel loading equipment selection/design.

3. Include propellant sampling and analysis requirements in GOWG discussions.

1. Analyze samples to demonstrate the propellant meets quality standards

2. Ensure adequate propellant flow through the entire propellant loading system to detect contamination sources within the loading system.

3. Draw samples at "point of use" after the propellant flows through loading equipment and as close as possible to spacecraft.

4. Include propellant sampling and analysis rqts for purity and particulate count in launch processing timelines prior to introduction to on-board flight hardware

5. Wait for acceptable analysis results before loading propellants into the flight system.

N/A N/A

Verification: N/A 1. Review summary documentation at

MDR.

1. Review summary documentation at peer reviews and

PDR.

1. Review summary documentation at peer reviews and CDR.

1. Review summary documentation at

PSR.

N/A N/A

Revision Status:

Rev. F

Owner:

1.40 Maintaining Command Authority of a Passive Spacecraft Systems Engineering

All spacecraft shall be designed to prevent loss of command authority and command integrity.

Rationale: Mission control needs to be maintained.

Phase: <A A B C D E F Activities: N/A 1. Ensure that vehicle commanding scheme design is robust against failures that will result in loss of control.

2. Ensure that in the case of an encrypted primary command link, there is a backup with adequate command integrity.

1. Incorporate features, commensurate with mission class that facilitates restoration of command link in the case of loss.

1. Test scheme against likely command link loss scenarios.

1. Validate primary and backup command link, as applicable.

N/A N/A

Verification: N/A 1. Review summary documentation at

MDR.

1. Review summary documentation at peer reviews and

PDR.

1. Review summary documentation at peer reviews and CDR.

1. Review summary documentation at

PSR.

N/A N/A

Revision Status:

Rev. F, Updated Rev. G

Owner:

1.41 GSE Use At Launch Site Systems Engineering

All testing of flight systems at the launch site shall only use GSE and test configurations that have been previously demonstrated with the flight hardware. Proper operation of the spacecraft with umbilical length equal to or with similar impedance and circuit characteristics to that expected at the launch site shall be demonstrated. Note: Does not apply to launch site resident GSE.

Rationale: New test configurations introduce unknown variables that could possibly result in unexpected test results or damage flight hardware

Phase: <A A B C D E F Activities: N/A N/A 1. Develop preliminary list of planned launch site testing and GSE configuration.

1. Refine list of planned launch site testing and GSE configurations.

1. Develop final list of planned launch site test activities and GSE configurations to support those activities.

2. Develop and execute test procedures for the planned launch site test activities using the planned launch site GSE configurations.

N/A N/A

Verification: N/A N/A 1. Verify at PDR. 1. Verify at CDR. 1. Verify at PER. N/A N/A

Revision Status:

Rev. G

Owner:

Fl…