Attachment H - LandIS GOLD Rules Compliance Matrix.pdf

LandIS Gold Rules Matrix LNEXT-LANDIS-REQ-0016 Revision -ii

Landsat Next Instrument Suite (LandIS) Gold Rules Compliance Matrix

Signature/Approval Page

Prepared by:

Electronic Signature in TDMS

12/05/2022 Joy Henegar-leon Date Landsat Next Payload Technical Manager NASA/GSFC, Code 426

Approved by:

Wen-Ting Hsieh Date Landsat Next Payload Manager

Evan Webb Date Landsat Next Systems Manager NASA/GSFC, Code 599

James Pontius Date Landsat Next Project Manager iii

CM Foreword This document is a Landsat Next Project Configuration Management (CM)-controlled document.

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

Questions or comments concerning this document should be addressed to:

NASA/Goddard Space Flight Center Landsat Next Project Office, Code 426 Attention: Configuration Management Office Greenbelt, Maryland 20771 iv

Change History Log

Revision Effective Date Description of Changes

- 12/05/2022 LNEXT-CCR-0010– Initial Release v vi

Table of Contents SIGNATURE/APPROVAL PAGE ................................................................................................ II

CM FOREWORD ..........................................................................................................................III

CHANGE HISTORY LOG .......................................................................................................... IV

TABLE OF CONTENTS .............................................................................................................. VI

LIST OF FIGURES ...................................................................................................................... VI

LIST OF TABLES ........................................................................................................................ VI

1.0 INTRODUCTION

2.0 LANDIS GOLD RULES MATRIX

List of Figures

No table of contents entries found.

List of Tables

No table of contents entries found.

1.0 INTRODUCTION

This document describes the Goddard Space Flight Center Gold Rules that are applicable to the Landsat Next Instrument Suite (LandIS).

2.0 LANDIS GOLD RULES MATRIX

Rule No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

1.05 Single Point

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

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.

Yes

1.06 Resource

Margins

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.

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.

Yes

Rule No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

Tabl e 1.06 -1

Technical Resource Margins All values are assumed to be at the end of the phase

Changed in Rev G

1.07 End-to-End

GN&C Phasing

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.

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.

No

1.08 System End-to-

End Testing

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.

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

Yes

1.09 Test as You Fly 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

Testing of all critical mission-operation elements as they will be flown greatly

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS 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.

reduces the risk of encountering negative impacts upon Mission success, from partial to full loss of mission capability.

1.11 Qualification of

Heritage Flight Hardware

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.

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

Yes

1.14 Mission Critical

Telemetry and Command Capability

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.

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.

No

1.17 Safe Hold Mode 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.

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

No

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS unpredictable controller behavior.

1.19 Initial Thruster

Firing Limitations

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.

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.

No

1.20 Wetted Joints of

Hazardous Propellants

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

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

No

1.21 Overpressurizati

on Protection in Liquid Propulsion Systems

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

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.

No

1.22 Purging of

Residual Test Fluids

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

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

No

1.23 Spacecraft

“OFF”

Command

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.

Requiring multiple actions to power off the spacecraft will mitigate the possibility

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS of an unintentional spacecraft power off.

1.24 Propulsion

System Safety Electrical Disconnect

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

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.

No

1.25 Redundant

Systems

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.

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

Yes

1.26 Safety Inhibits

& Fault Tolerance

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.

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

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS inhibits (seals) shall be limited to the minimal practical volume and designed to limit the external leakage in the event of failures.

1.27 Propulsion

System Overtemp Fuse

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

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.

No

1.28 Unintended

Propellant Vapor Ignition

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

Ignition of propellant vapor can occur due to a variety of conditions including (1) mixing of fuel and oxidizer in

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS 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.

1.30 Controller

Stability Margins

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.

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

No

1.31 Actuator Sizing

Margins

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

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.

No

1.32 Thruster and

Venting Impingement

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

Impingement is likely to contaminate critical surfaces and degrade material properties and

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS can also create adverse and unpredictable S/C torques and unacceptable localized heating.

1.33 Polarity Checks

of Critical Components

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

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.

Yes

1.35 Maturity of New

Technologies

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

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

Yes

1.37 Stowage

Configuration

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.

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.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

1.39 Propellant

Sampling in Liquid Propulsion Systems

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

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.

No

1.40 Maintaining

Command Authority of a Passive Spacecraft

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

Mission control needs to be maintained.

No

1.41 GSE Use At

Launch Site

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.

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

Yes

1.42 Powering Off

RF Command Receiver

The spacecraft RF Command Receiver shall not be powered off during nominal flight operations.

Preserves spacecraft command receipt capability.

No

1.43 Flight Software

Update Demonstration

There shall be a pre-flight, end-to-end demonstration of code change, using the MOC and flight observatory, for any software which can be changed in flight.

Demonstration of this capability for software not hosted in the

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS spacecraft primary computer is often overlooked prior to launch

1.44 Early Interface

Testing

Spacecraft-to-payload electrical interfaces, including protocol and software compatibility, shall be tested with breadboard or engineering unit hardware, as soon as the hardware is available, preferably before the instrument (or component) CDRs.

On multiple missions, it has been demonstrated that the time and effort to execute early interface tests reduces the overall mission cost and schedule by finding and correcting incompatibilities before they impact system-level I&T.

While having well-written ICDs and/or the use of industry-standard interfaces, can minimize interface incompatibilities, there are often nuances that can only be uncovered via test.

Yes

1.45 System

Alignments

System alignment verifications shall be performed before and after exposure to system environmental testing to demonstrate alignment stability.

Demonstrates stability of alignments through the environments which gives confidence that alignments will not shift due to launch vibro-acoustic environment or post-launch thermal environment

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

1.46 Use of Micro-

Switches

Micro-switches shall be used for information only and shall not be used to initiate on-board autonomous activity or as an on-board interlock.

Micro-switches have known reliability issues.

Yes

1.47 Design

Deployables For Test

Whenever practical, appendages and other deployables shall be capable of deployment under 1G conditions without the use of g-negation ground support equipment. When it is not practical to design for unassisted 1G deployment, the design shall have provisions for interfacing to gravity off-load GSE.

Numerous occasions where instrument doors, etc. are not designed for 1G deployment and don't have provisions built in for g-negation.

Yes

1.48 Space Data

Systems Standards

Space data systems standards (e.g. CCSDS, OMG, commercial) shall be utilized by missions and implemented in all space communication systems.

Notes: 1) The Center CCSDS Standards Point of Contact (POC) is a recommended resource for learning the current breadth of standards to be considered and the status of CCSDS and OMG standards currently under development. 2) The Consultative Committee for Space Data Standards (CCSDS) publications span a wide range of technical areas which may be of benefit to missions, including both optical and RF communications, uplink and downlink messaging, file transfer protocols, delay-tolerant networking, navigation messages, service-oriented approaches to increase interoperability, data compression and security, and more. The Object Management Group (OMG) is an international, not- for-profit technology standards consortium. The OMG Space Domain Task Force (Space DTF) maintains standards specific to space applications, including common telemetry and command definition formats, scripting standards, and ground equipment interface definitions. Commercial or general use standards, including internet protocol or mobile device standards may also provide significant benefit to some missions and shall not be precluded.

Standardization of space data system interfaces, formats, and protocols within the Agency reduces the cost of specification and implementation of data systems. It increases reliability through the use of proven interfaces and heritage software and tested vendor products. Space data systems standards enable easier and lower-cost data interoperability between systems within a local system, across a Center or Agency, and with external partners.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

2.01 Flight Electronic

Hardware Operating Time

One thousand (1000) hours of operating/power-on time shall be accumulated on all flight electronic hardware (including all redundant hardware) prior to launch The last 350 hours of operating/power-on time shall be failure-free, of which at least 200 hours shall be in vacuum. For Class D and below, only the failure-free and vacuum requirements shall apply.

Accumulated power-on time that demonstrates trouble-free parts performance helps reduce the risk of failures after launch.

Yes

2.05 System

Grounding Architecture

For all missions, a system grounding design shall be developed and documented for flight and GSE test configurations. Except for coaxial interfaces, structure or shields shall not be used for the primary circuit current return path. A dedicated conductor shall be included to provide the current return path with the smallest loop area possible.

Poor system grounding design will lead to grounding incompatibility between different systems during the integration phase, with potential degradation of end-to-end functional performance.. Failure to consider GSE grounding could result in damage to flight hardware.

Yes

2.06 System Fusing

Architecture

A system fusing architecture shall be developed and documented for all missions, including the payloads. All circuit breakers that can’t be reset by command (i.e., fuses) should be easily accessible for replacement and/or for integrity verification at any time prior to launch vehicle integration.

Lack of a system fusing design may lead to fuse incompatibilities between the power source and the payloads, which could lead to the power source fuse being blown prior to the payloads. The system fusing design should maximize the reliability of the system.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

2.13 Electrical

Connector Mating

All flight connectors where mating cannot be verified via ground tests, shall be clearly labeled and keyed uniquely, and mating of these connectors shall be verified visually to prevent incorrect mating. The design shall not use connectors that require a blind mating in system-level integration, test and launch operations.

Error in mating of interchangeable connectors can result in mission degradation or failure.

Yes

2.14 Protection of

Avionics Enclosures External Connectors Against ESD

All avionics enclosures shall be protected from ESD. All external connectors must be fitted with shorting plugs or appropriate caps during transportation between locations.

Additionally, all test points and plugs must be capped or protected from discharge for flight.

Capping open connectors provides protection from electrostatic discharge resulting from space charging.

Yes

2.18 Rule Deleted Rule Deleted Rule Deleted

2.22 Corona Region

Testing of High Voltage Equipment

Assemblies containing a High Voltage supply that is not tested through the Corona region shall undergo venting / outgassing analysis to determine when it is safe to turn on and operate after launch.

Each High Voltage supply is different in its design and the voltage where coronal discharge may occur will vary by the construction and materials used. It will also be dependent on how clean the supply is and how well the outgassing products are vented to space.

Yes

2.23 RF Component

Testing for Multipaction and Corona

Components of RF communications subsystems shall not exhibit Corona or Multipaction.

If compliance is satisfied by test, the test shall be done at least 6 dB above the nominal power level. If satisfied by analysis, the analysis shall show at least 10 dB of margin above the nominal power level.

Unless significant design margin is demonstrated, small unit-to-unit variations make it impossible to predict whether an RF component is susceptible to Multipaction or Corona.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

2.24 Solar Arrays a. Solar arrays shall incorporate solar cells that have been qualified per AIAA-S-111A- 2014, “Qualification and Quality Requirements for Space Solar Cells.” If a later revision of AIAA-S-111 has been released by the time of contract award for the mission, the later revision shall govern.

b. Solar panels shall be qualified to the mission environment via qualification panels per AIAA-S-112A-2013, “Qualification and Quality Requirements for Electrical Components on Space Solar Panels.” If a later revision of AIAA-S-112 has been released by the time of contract award for the mission, the later revision shall govern.

c. Qualification and flight solar panels shall be tested at ambient temperature and at their highest predicted operating temperature including calibrated I-V curves before and after panel-level environmental testing.

d. Flight solar arrays shall be tested at wing level or array level at ambient temperature including calibrated I-V curves after all environmental testing (integrated to the spacecraft or not) is complete. Should the flight solar array be stored for a period of more than two years after the post-environmental array testing is complete, the calibrated I-V curve measurements at ambient temperature shall be repeated prior to launch.

Space solar arrays must survive severe environments including particulate radiation, UV, and up to tens of thousands of very rapid temperature excursions between cold and hot.

Incremental changes to parts and processes can have unexpectedly large consequences.

Therefore, it is essential that the solar array for each mission be rigorously qualified and tested for that mission.

No

2.25 Electrical

Interface Verification

Electrical Interface (i.e., copper-path) Verification Test (IVT) shall be performed on all flight connectors following final flight mating. This may be performed via powered testing and/or physical (e.g., resistance) measurements.

Final verification of flight interfaces is required to ensure proper electrical integrity and function, thereby minimizing the probability of system failure and maximizing probability of mission success.

Yes

2.26 Power-On Reset

Visibility

A power-on reset occurrence shall be unambiguously identifiable via telemetry. Note: This does not imply real-time telemetry as the reset is occurring.

An unexpected power-on reset could be an indication of a serious issue and should be able to be distinguished from resets that are

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS indicative of less serious conditions.

2.27 Spacecraft Strip-

Charting Capability

A minimal set of hard-line spacecraft parameters, sufficient to establish spacecraft health and safety, shall be monitored and captured (stored), independent of the spacecraft telemetry system, by the EGSE whenever the spacecraft is powered. This data should be sampled at a rate sufficiently high to aid in diagnosis of abnormal power events.

This capability is necessary to capture data for anomalous behavior on the spacecraft during I&T when spacecraft telemetry is not available.

3.01 Verification and

Validation Program for Mission Software Systems

A thorough verification and validation process shall be applied to all mission software systems. This process shall trace customer/mission operations concepts and science requirements to implementation requirements and system design, and shall include requirements based testing of all mission elements, and end-to-end system operations scenario testing.

Mission software, especially flight software, must be tested thoroughly to ensure a successful mission/project. The activities described below provide guidance on recommended software verification and validation activities at each lifecycle phase to supplement the requirements found in

NPR 7150.2.

Yes

3.02 Elimination of

Unnecessary and Unreachable Software

An analysis of unnecessary and/or unreachable code, as defined per Table 3.02-1, shall be performed on the intended flight load for launch. The analysis shall identify all instances (areas) of unnecessary/unreachable flight code, the general functionality associated with the code, the reason each is intended to be left within the flight load, and the justification (e.g. mitigating action) that explains why the included code does not provide a risk to the mission. The focus is on technical risk to the long-term mission, not cost.

There are significant benefits to re-using software from past missions but each mission has different requirements and re-using heritage software often carries

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS forward software not required by the current mission. Unnecessary and unreachable software can also occur within a mission’s lifecycle as system and software requirements change during the software development process.

Unnecessary and unreachable software is typically not verified or validated as part of the current mission test programs, as a mission is only required to verify its mission requirements.

This creates the potential for negative side-effects, costs, and risks during the current mission’s on-orbit life. Table 3.02-2 provides sample types of unnecessary or unreachable code.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

Tabl e 3.02 -1

Unnecessary and Unreachable Software Definitions updated table

Tabl e 3.02 -2

Examples Areas To Consider For Analysis updated table

3.03 High Fidelity

Interface Simulation Capabilities

A high fidelity software simulation capability for each external interface to FSW shall be provided in the FSW development/maintenance environments. Both nominal and anomalous data inputs to FSW shall be configurable in real-time using the procedure language of the FSW test workstation.

When adequate simulation capabilities aren't planned, there may be significant impact to FSW development/maintena nce productivity and funds.

Yes

3.04 Independent

Software Testing

Software functional/requirements and comprehensive performance verification/validation testing shall be performed by qualified testers that are independent of the software designers and developers. NOTE: For small projects, members of the same development team can perform independent testing as long as the assigned testers have not been involved in any part of the design and development of the software components being tested.

Ideally, an independent team should develop the software test plan and verification/validation test procedures, and execute the tests.

Frequently the software development team will be used to perform these

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS functions as a means to reduce cost and schedule. Having authored the code, they already know how it should function and can quickly perform the testing activities. The independent test team approach is non-biased, with an end-user perspective, and specialized test teams frequently have greater expertise on various test tools and technologies; thus, providing a more thorough and comprehensive test program. An independent test team ensures adequate time for testing because there is a clear demarcation between development and testing. However, if utilizing an independent test team is not feasible, at a minimum, the use of independent testers who were not involved with the software design and

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS development process allows alternate interpretations of requirements and multiple approaches to testing.

3.05 Flight / Ground

System Test Capabilities

Access to flight system interface and functional capabilities, provided either by the spacecraft or by spacecraft simulators, shall be negotiated with all stakeholders, including the ground system and operations teams. Schedules and agreements should address the spacecraft and spacecraft simulators at all levels of fidelity.

The ground system must be compatible with the S/C it is being designed to support, and this must be proven prior to launch via tests. Similarly, the operations team must be able to develop and validate a variety of operations products, such as procedures, databases, display pages, and launch scripts. The operations team must also have opportunities to learn about operating the S/C and prove this knowledge has been acquired prior to launch.

Yes

3.06 Dedicated

Engineering Test Unit for Flight Software Testing

An ETU flight data system testbed(s) shall be dedicated to FSW teams specifically for FSW development and test. The number of flight data system testbed units shall be sufficient to support the FSW development schedule and the overall mission schedule.

Early investment in dedicated FSW testbed hardware fidelity saves costs and avoids significant schedule risks to FSW and I&T teams. Anything less than a dedicated ETU will add to mission

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS risk and threaten cost/schedule.

3.07 Flight Software

Margins

Flight software resource margins shall be maintained in accordance with Table 3.07-1 and presented at Key Decision Point (KDP) milestone reviews.

Early and repeated attention by flight software teams to resource utilization will improve resource margins for future phases of the mission.

Yes

Resource Margins for Flight Software Development The numbers provided in the table below are margins for different mission phases and maturity levels. These do not represent hard limits, but levels where the software development team should start to get concerned. Project waivers are not required unless the resource starvation means the system can’t meet one of its performance requirements.

Margin is calculated using the formula: (total allocated resource – used resource)/total allocated resource Total allocated resource = the total magnitude of the resource that allocated for use by flight software.

Used resource is estimated, analyzed and/or measured.

Note: Selecting which column to use at a particular time is not always obvious. Generally, one should pay more attention to the “Method” row rather than the “Mission Phase” row.

For example, if there is a lot of re-use and you have actual measured code sizes for most modules, your PROM could be 80% full at PDR without causing concern. Different resource elements can be at different maturity levels at any given point in a project. The right-most column should only be used when the code is fully integrated and tested. Those are the margins we want to save for in-flight maintenance.

Average CPU Usage: This is the percentage of time the CPU is doing non-background processing work. Background processing may include tasks such as memory scrubbing, memory validation (such as memory checksum), or any process that is interruptible or has very loose timing requirements. This average should be estimated/measured over an interval that exceeds the longest real-time event rate under normal worst-case operating conditions.

Deadlines: This row usually represents the interrupt timing requirements of the system.

For example: How quickly does the processor need to re-fill that FIFO after the HW interrupt is asserted? If you have a 50 ms deadline for an ISR and you estimate the

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS processor can meet it in 20ms, your usage (margin) is 40% (60%). All deadlines in the system should be considered, and compared individually to the recommended margin.

Also, consider which deadlines can occur simultaneously to calculate the worst-case timing.

PROM is non-volatile memory that cannot be modified in flight.

EEPROM is non-volatile memory that can be modified in flight.

RAM is volatile memory where the executing code and data are stored. This memory is always on the processor’s local bus. Note: Bulk memory used for storage of housekeeping and science data has been removed from this table. The amount of bulk memory is driven more by mission parameters (data rates, number of ground contacts, etc.) than software design. So, systems engineers should track the bulk memory margin. However, some systems have the “bulk” memory on the processor card, indistinguishable from regular RAM. In this case, the software team should track margins on this combined RAM/bulk memory space.

1553 Bus: Usage calculations should include 1 retry for each transaction, unless mission requirements specify otherwise. If the scheduling of bus traffic is segmented into slots or channels, the usage should be calculated based on the number of slots used (rather than actual bus time).

For software resources that do not appear in the table, use an analogous resource that does appear or work with the project systems engineer to define acceptable margins for that unique resource.

3.10 Flight

Operations Preparations and Team Development

Experienced operations personnel shall participate as early as possible during mission development, preferably during the mission operations concept phase and the development of specifications for the spacecraft and/or instruments which impact operations. Ideally, the Flight Operations Team (FOT) will supply Test Conductors to support Observatory I&T, which will serve to prepare and train the FOT. As a minimum, the FOT shall participate in flight operations readiness tests that are specified in Table 3.10. Note that these serve as guidelines and are not intended to be prescriptive.

Involving experienced operations personnel early in the mission helps ensure that the mission design will be considerate of operational requirements and practicalities. It will allow the operations team to become intimately familiar with the mission design, including design rationale, spacecraft limitations, No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS and operating constraints. Involving FOT members during mission operations readiness tests gives them a great deal of hands-on experience with the observatory prior to launch thereby enhancing their training; and, the FOT will be able to assume their responsibility with a reasonable degree of skill and knowledge for conducting on-orbit spacecraft operations.

Tabl e 3.10 -1

Simulation Types and Minimum Number of Successful Simulations/ Test Hours versus Mission Class

Note: Simulations and tests may be performed in parallel or in combination, if appropriate, to satisfy above goals. End-to-end test implies spacecraft-to- Control Center interface and includes all supporting elements, i.e., Science Data Center, communication s network, etc.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

Ground Readiness Tests (GRTs) are not included in this table.

3.11 Long Duration

And Failure Free System Level Test of Flight and Ground System Software

Ground test of the fully integrated FSW and ground system shall include demonstration of error free operations-like scenarios over an extended time period. The minimum duration of uninterrupted FSW system-level test (on the highest fidelity FSW testbed) and ground system operations is 72 hours for Class A and B missions; 48 hours for Class C missions;

and, 36 hours for Class D missions, respectively.

Frequent restart of FSW and the ground system during ground tests may mask problems which will only occur following extended execution of these systems. Also, ground system stress testing is needed to ensure reliable operation. The number of hours specified is based on discussion with senior-level engineers, and reflect best practices accumulated over a period of 15 years.

Yes

3.13 Maintaining

Adequate Resources for Mission Critical Components

The updating of mission critical components during the mission operations phase (including any combination of hardware platforms, hardware devices, and software code) shall not compromise the capability of the system to meet mission requirements. Missions shall provide sufficient quantities of flight and ground resources to allow development, test, and operations activities to be conducted without compromising mission availability requirements.

Missions should provide sufficient resources to allow updates to mission critical/high availability components, such as flight software and ground system components directly supporting space-ground

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS communications, to be developed and tested without compromising operations. Missions should also ensure against inadvertent updates or deliberate concurrent updates of mission critical/high availability components. For example, under no circumstances should prime and redundant components, such as prime and backup flight software code images, be modified/updated concurrently, before the operational performance of the change is properly verified in a single unit.

3.14 Command

Procedure Changes

Command procedures and/or scripts, and mission databases (onboard and ground) shall be controlled (treated with the same rigor as changes to flight critical software). This includes formal configuration management, peer review by knowledgeable technical personnel, and full verification with up-to- date simulations wherever possible. (Routine command loads to perform nominal operations may require less test rigor based on experience of senior engineers.)

Changes in command procedures and critical database areas that are not tracked, controlled, and fully tested can cause loss of science and/or the mission.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

4.01 Contamination

Control, Planning, and Execution

Specific contamination control requirements and processes (such as analytical modeling, laboratory investigations, and contamination protection and avoidance plans) that support mission objectives shall be identified.

Contamination sensitive components are often critical elements that directly affect system performance. It is essential that critical component performance be preserved and not allowed to degrade due to contamination exposure & accumulations.

Yes

4.03 Factors of Safety

for Structural Analysis and Design, and Mechanical Test Factors & Durations

Structural analysis and design factors of safety shall apply to all systems in accordance with GEVS Section 2.2.5. The project shall employ the mechanical test factors and durations in accordance with GEVS Section 2.2.4.

This will provide confidence that the hardware will not experience failure or detrimental permanent deformation under test, ground handling, launch, or operational conditions.

Yes

4.06 Validation of

Thermal Coatings Properties

All thermal coatings properties shall be determined, measured and validated to be accurate for materials and mission flight parameters over the lifecycle of the mission. All thermal analysis shall employ these properties. The GSFC Coatings Committee (chaired by Code

546) shall review and approve the coatings properties.

Thermal coatings properties directly affect Mission success through S/C or instrument thermal design. Early assessment of thermal coating ensures the mission objectives will be met.

Yes

4.10 Minimum

Workmanship

All electrical, electronic, and electro-mechanical components shall be subjected to minimum workmanship test levels as specified in GEVS Section 2.4.2.5.

The workmanship levels defined in GEVS Section 2.4.2.5 have been found to be

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS the minimum input level necessary to adequately screen the hardware types above for workmanship flaws.

4.11 Testing in Flight

Configuration

Mechanical environmental testing (sine, random, & acoustic, shock, etc.) of flight hardware shall be performed with the test article in the flight like configuration.

Mechanisms shall be configured for flight, and the flight (or flight like) blankets and harness shall be present for test. The flight optical system shall also be present for the test and configured for flight.

Testing in-flight configuration ensures that hardware which is difficult to analyze (i.e. blankets, harnesses, mechanisms) will be adequately screened by environmental testing for design or workmanship flaws.

The presence of the optical system in this testing enables verification that the performance stability of the as-built opto-mechanical configuration is compliant to requirements (e.g., wave-front error, alignment, etc.) before and after testing.

Yes

4.12 Structural Proof

Testing

Primary and secondary structures fabricated from nonmetallic composites, beryllium, or containing bonded joints or bonded inserts shall be proof tested in accordance with GSFC- Std-7000 Section 2.4.1.4.1.

The mechanical strength of the above items is dependent on workmanship and processing and can only be verified by proof testing.

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS

4.14 Structural and

Mechanical Test Verification

Structural and Mechanical Test Verification program shall comply with GEVS-Table 2.4- 1, Structural and Mechanical Verification Test Requirements.

Demonstration of structural requirements is a key risk reduction activity during mission development.

Yes

4.15 Torque Margin The Torque Margin (TM) requirement defined in GEVS section 2.4.5.3 shall apply to all mechanical functions, those driven by motors as well as springs, etc. at beginning of life (BOL). End of Life (EOL) mechanism performance shall be determined by life testing, and/or by analysis; however, all torque increases due to life test results and/or analysis shall be included in the final TM calculation and verification. Margins shall include all flight drive electronics effects and limitations.

The torque or force margin needs to be sufficiently large to guarantee system-performance under worst-case conditions throughout its life by fully accommodating the uncertainty in the resisting forces or torques and in the source of energy.

Yes

4.18 Deployment and

Articulation Verification

All flight deployables, movable appendages, and mechanisms shall demonstrate full range of motion and articulation under worst-case conditions, when being driven by the flight avionics (i.e., not EGSE) prior to flight.

Environmental factors such as temperature, gravity, acceleration fields, wire bundle stiffness, and others can adversely affect successful deployment.

Additionally, initiation of mechanism release with EGSE could result in masking system-level design issues. Verification of these systems under worst- case conditions will improve on-orbit success.

Yes

4.20 Fastener

Locking

All threaded fasteners shall employ a locking feature. If not locked in the torqued, preloaded

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS position, threaded fasteners subjected to vibration and thermal cycling loads may back out causing a reduction in preload and potentially jeopardize the mission.

4.21 Brush-type

Motor Use Avoidance

Designs shall avoid brush-type motors for critical applications with very low relative humidity or vacuum operations. Intentionally excluded from this rule are contacting sensory and signal power transfer devices such as potentiometers and electrical contact ring assemblies (slip rings, roll rings), etc.

The operating life of the brush-type motors can be significantly decreased in extremely dry or vacuum conditions. Critical components relying on brush- type motors could be rendered inoperable due to excessively worn brushes or brush particulate contamination.

Yes

4.22 Precision

Component Assembly

When precise location of a component is required, the design shall use a stable, positive location system (not relying on friction) as the primary means of attachment.

When in the domain of arc-sec to sub-arc-sec location requirements, the use of pinning or similar non-friction reliant method will help ensure alignment is maintained through all expected stresses.

Yes

4.23 Life Test A life test shall be conducted, within representative operational environments, to at least 2x expected life for all repetitive motion devices with a goal of completing 1x expected life by CDR. The differences between the life-test drive electronics and the flight drive electronics (e.g., voltage, current, duty cycle, etc.) could affect mechanism operating life and should be considered in the life-test.

Degradation in repetitive motion devices from wear, fatigue, lubrication degradation, etc., can have serious negative

No.

Rev G Title Rev G Object Text Rev G Rationale Applicab le to LandIS impacts on mission success.

4.24 Mechanical

Clearance Verification

Verification of mechanical clearances and margins (e.g. potential reduced clearances after blanket expansion) shall be performed on the final as-built hardware.

Proper mechanical clearances are often critical to successful on-orbit performance (e.g. free-movement area, thruster impingement, FOV, etc.). Verification through analysis and drawing checking alone is not sufficient to properly demonstrate adequate clearance.

Yes

4.25 Thermal Design

Margins

Thermal design shall provide adequate margin between stacked worst-case flight predictions and component allowable flight…