Attachment G - L10 Spacecraft Simulator Req Document (SC Sim RD).pdf

Attachment No. G

Landsat 10 Spacecraft Simulator Requirements Document (SC Sim RD)

RFP 80GSFC26R0015

National Aeronautics and Space Administration Goddard Space Flight Center

Landsat 10 SC Sim RD L10-SC-REQ-0012 Revision A ii

Landsat 10 Spacecraft Simulator Requirements Document (SC Sim

RD)

Signature/Approval Page

Prepared by:

Electronic Signature in TDMS Approval Date in TDMS Shawn Butani Date Landsat 10 Simulator Lead NASA/GSFC, Code 426

Approved by:

Cagatay Aymergen Date Landsat 10 Deputy Project Manager / Acting Observatory Manager

Ross Henry Date Landsat 10 Project Manager

Evan Webb Date Landsat 10 Mission Systems Manager NASA/GSFC, Code 533 iii

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

Note: Prior to February 2026, the project name was Landsat Next (LNext).

For the purposes of configuration management, the prefixes “LNEXT” and “L10” are completely interchangeable. For example, LNEXT-MGMT-PLAN-0004 is the same as L10-MGMT-PLAN- 0004.

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 10 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 10 Project Office, Code 426 Attention: Configuration Management Office Greenbelt, Maryland 20771 iv

Change History Log v

List of TBDs/TBRs Hyperlink to TBx Location Summary Ind.

Name/Org.

Due Date

TBx-1 Section 3.14

SCSim-483 The RF suitcase shall operate and transmit continuously for a minimum of 30 (TBR) minutes without affecting performance.

Simulators Systems

Engineering

SC

Award vi

Table of Contents SIGNATURE/APPROVAL PAGE ................................................................................................ II CM FOREWORD ..........................................................................................................................III CHANGE HISTORY LOG .......................................................................................................... IV

LIST OF TBDS/TBRS .................................................................................................................... V

TABLE OF CONTENTS .............................................................................................................. VI LIST OF FIGURES ..................................................................................................................... VII LIST OF TABLES ....................................................................................................................... VII

1.0 INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 Related Documentation

1.3.1 Applicable Documents

1.3.2 Reference Documents

1.3.3 Project Reference Documents

1.3.4 Project Applicable Documents

2.0 MISSION OVERVIEW

2.1 Mission Statement

2.2 Mission Background

2.3 Mission Objectives

2.4 Mission Implementation

2.4.1 Space Segment

2.4.2 Ground Segment

2.4.3 Launch Segment

3.0 GENERAL

3.1 Modes

3.2 Flight software (FSW)

3.2.1 FSW

3.2.2 FSW Commands

3.2.3 FSW Stored Commands

3.2.4 FSW State-of-Health TLM (Telemetry)

3.2.5 FSW Ancillary Data

3.3 Command and Data Handling (C&DH) System

3.3.1 C&DH Commands

3.3.2 C&DH Mass Storage

3.3.3 C&DH Instrument Simulator Interface

3.3.4 C&DH Instrument Simulator Commands

3.3.5 C&DH Instrument Simulator Telemetry

3.3.6 C&DH Instrument Simulator Time of Day

3.3.7 C&DH Imaging Sensor Data

vii

3.4 SC Operational Autonomy

3.5 Failure Response and Redundancy

3.6 Thermal

3.7 Attitude Control System (ACS)

3.8 Electrical Power System (EPS)

3.9 Communication Subsystem

3.10 Electrical Systems

3.11 Simulator Operations

3.12 Operations Interface

3.13 Launch Vehicle Interface Simulator (LVIS)

3.14 RF Suitcase

3.15 Security

APPENDIX A APPLICABILITY MATRIX

APPENDIX B ABBREVIATIONS AND ACRONYMS

APPENDIX C DEFINITIONS

List of Figures Figure 2.4-1 Landsat 10 Mission Architecture

List of Tables Table 1.2-1 Simulator Descriptions Table 2.4.1-1 Landsat 10 Mission Parameters

1.0 INTRODUCTION

1.1 PURPOSE

This specification serves to establish the requirements for the Landsat 10 Observatory Operations Simulator (OOpS), Spacecraft Operations Simulator (SOpS), Spacecraft Software Simulator (SoftSim), Command and Telemetry Simulation System (CTSS), Launch Vehicle Interface Simulator (LVIS), and Radio Frequency (RF) Suitcase Simulator simulation capability. The high-fidelity SOpS will be integrated with the Landsat Instrument Suite (LandIS) Operational Simulator (LOpS), and relevant ground equipment, to form the Observatory Operations Simulator (OOpS). The OOpS is a high-fidelity simulator and serves as the workhorse tool for operations in Ground System and operations readiness checkouts.

1.2 SCOPE

This specification establishes the requirements for the development, delivery, and operations of the OOpS, SOpS, SoftSim, CTSS, LVIS, and RF Suitcase. This document does not cover the requirements for the LOpS. The LOpS is the high-fidelity instrument simulator that will have flight like connectors to allow for it to be integrated with the SOpS to form the OOpS. Further detail on the LOpS may be found in the Simulator appendix of the Landsat 10 Mission Operations Concept Document (L10-SYS-PLAN-0007).

Table 1.2-1 Simulator Descriptions

Simulator Key Highlights Description and functional details Command and Telemetry Simulation System

(CTSS)

• Simple C&T functions (unencrypted)

• Deployable internationally

• Delivered to Landsat 10

Mission Operations Center (MOC) and United States Geological Survey (USGS) Earth Resource Observation and Science Center (EROS)

• Simple, low fidelity system for simulating realistic spacecraft command and telemetry (C&T) responses with basic scripting capability

• Primarily used for ground station and ground system checkout activities

SoftSim • 100% software

• Runs spacecraft (SC) Flight

Software (FSW) only

• Has full environmental truth model which includes Gravitational model, magnetic field model, drag force model, Sun and Moon position model, gravity gradient disturbance torque model, magnetic moment disturbance torque model, Solar Array Sun incidence angle model, solar pressure model, and Global Positioning System (GPS) constellation

• Delivered to Landsat 10

MOC

• Software based (emulated hardware) simulator of the spacecraft

• High fidelity Spacecraft (Executes SC FSW with ability to use and update as in flight, modeled subsystems, and environmental truth model, etc.)

• Low fidelity LandIS (basic C&T only) capability

• Primarily used for spacecraft and ground procedure development, ground software development, and ground readiness tests

Spacecraft Operational Simulator (SOpS)

• Runs SC FSW

• Built to interface with LOpS to form OOpS

• Has full environmental truth model which includes Gravitational model, magnetic field model, drag force model, Sun and Moon position model, gravity gradient disturbance torque model, magnetic moment disturbance torque model, Solar Array Sun incidence angle model, solar pressure model, and GPS constellation

• High fidelity spacecraft simulators integrated with LOpS to form OOpS

• Flight-like command and telemetry response, redundancy, subsystem models, timing, compression, and science data flow

• Executes SC FSW, with ability to use and update as in flight

Simulator Key Highlights Description and functional details Observatory Operations Simulator (OOpS)

• Executes S/C and LandIS FSW, with ability to use and update as in flight

• Flight Timing for all mission data chain elements

• Has full environmental truth model.

• Workhorse simulator for mission readiness and operations teams

• Delivered OOpS to Landsat

10 MOC

• High fidelity observatory simulators (integrated LandIS Operational Sim (LOpS) with S/C Operational Sim (SOpS)) with flight like timing for all mission data elements

• Flight-like command and telemetry response, redundancy, subsystem models, timing, compression, and science data generation/flow

• Long term operational use: special activity testing, product updates, anomaly investigation, team training and proficiency, etc

• Primary resource for operational process and procedure development, Mission Conops validation, operations testing, and Mission Readiness tests and simulations

RF Suitcase • Simulates Ka-band RF output of the spacecraft

• Delivered to USGS EROS

• Takes raw CADU data captured from the flight SC and generates a representative Ka-band signal for ground stations

• Generates PN and VC63 fill data

• Provides alternative coax output

• Portable for deployment to international sites Launch Vehicle Interface Simulator (LVIS)

• Simulates the observatory interface to the launch vehicle

• Delivered in place at SC vendor and sent to the launch site

• Will be integrated with the launch vehicle prior to observatory to validate interfaces and configurations

1.3 RELATED DOCUMENTATION

1.3.1 Applicable Documents

Document Number Title Revision Section Reference

CCSDS 133.1-B-3 Encapsulation Packet Protocol Recommended Standard, Issue 3, Editorial Change 1

All

CCSDS 232.1-B-2 Communications Operation Procedure-1

Recommended Standard, Issue 2, Technical corrigendum 1

All

CCSDS 732.0-B-5 AOS Space Data Link Protocol Recommended Standard, Issue 5

All

In this document, citations are assumed to be the latest version unless otherwise noted.

This document table was generated from the Landsat 10 Common Reference and Applicable Documents List (L10-MGMT-DESC-0008), DRAFT Rev F.

1.3.2 Reference Documents

Document Number Title Revision Public Law #105-303 Commercial Space Act of 1998, Public Law

#105-303, 112 Stat., 2843., H.R. 1702, 105th Congress, Adopted October 28, 1998

N/A

Public Law #102-555 Land Remote Sensing Policy Act of 1992, Public Law #102-555, 106 Stat. 4163., H.R.

6133, 102nd Congress, Adopted October 28, N/A

In this document, citations are assumed to be the latest version unless otherwise noted.

1.3.3 Project Reference Documents

Document Number Title L10-OPS-06 Handbook Landsat 10 Observatory Command and Telemetry Handbook L10-OPS-07 Database Landsat 10 Observatory Command and Telemetry Database In this document, citations are assumed to be the latest version unless otherwise noted.

1.3.4 Project Applicable Documents

Document Number Title L10-LV-ICD-0008 Landsat 10 Launch Vehicle Interface Control Document

(LVICD)

L10-SC-ICD-0002 Landsat 10 Spacecraft Interface Requirements Document

(SCIRD)

L10-SC-ICD-0004 Landsat 10 Spacecraft to Ground Interface Control Document

(SC-GND ICD)

L10-SC-ICD-0005 Landsat 10 Spacecraft (SC) to Landsat Instrument Suite

(LandIS) Interface Control Document (SC-LandIS ICD) L10-SC-ICD-0007 Landsat 10 Spacecraft to Ground Interface Requirements

Document (SC-GND IRD) L10-SC-REQ-0011 Landsat 10 Spacecraft Requirements Document (SRD) L10-SYS-ICD-0016 Landsat 10 Mission Data Format Interface Control Document

(ICD)

L10-SYS-ICD-0017 Landsat 10 Simulator and Ground Test Equipment Interface

Control Document (ICD) In this document, citations are assumed to be the latest version unless otherwise noted.

2.0 MISSION OVERVIEW

2.1 MISSION STATEMENT

Landsat 10, consistent with United States (U.S.) law and government policy, will continue the Landsat program's acquisition, archival, and distribution of multi-spectral imagery, thereby affording global, synoptic, and repetitive coverage of the Earth's land surfaces and coastal regions at a scale where natural and human-induced changes can be detected, differentiated, characterized, and monitored over time.

2.2 MISSION BACKGROUND

Following the successful launch of Landsat 8 (formally named Landsat Data Continuity Mission, LDCM) in February 2013, and during the development of Landsat 9, the United States Geological Survey (USGS) and the National Aeronautics and Space Administration (NASA) recognized the need to assemble a team of experts from within both agencies to evaluate and inform an acquisition strategy for the Landsat mission to follow Landsat 9. The NASA-USGS Joint Agency Sustainable Land Imaging (SLI) Architecture Study Team (AST) was formed in September 2018, and tasked with investigating how to best satisfy the diverse set of user needs collected in the USGS User Needs for the Sustainable Land Imaging Program July 2018, Release

2.0. This investigation resulted in a set of recommendations to the headquarters of both agencies, delivered in December 2019. The highest-recommended “Roadmap 1” architecture described a small constellation of “superspectral” space-based sensors that would substantially improve the spectral, spatial, and temporal capabilities of previous Landsat missions, while continuing to satisfy the primary goal of ensuring a highly calibrated data set that maintains compatibility with the legacy data of the Earth’s land surfaces and coastal regions held in the National Satellite Land Remote Sensing Data Archive at the USGS’s Earth Resources and Observation Science (EROS) Center. In April 2020 NASA/Goddard Space Flight Center (GSFC) received authorization to initiate the Landsat Next project consistent with the AST’s “Roadmap 1” recommendation. Landsat Next subsequently passed its Mission Concept Review (MCR) and Key Decision Point-A (KDP-A) reviews in 2022. In March 2026, the Landsat Next mission was re-architected and re-designated Landsat 10 as a single observatory mission.

The goal of Landsat 10 is to continue the acquisition, archival, and distribution of multi-spectral imagery, thereby affording global, synoptic, and repetitive coverage of the Earth's land surfaces and coastal regions at a scale where natural and human-induced changes can be detected, differentiated, characterized, and monitored over time. This goal is in keeping with the Landsat programmatic goals stated in both the Commercial Space Act of 1998, Public Law #105-303 and the Land Remote Sensing Policy Act of 1992, Public Law #102-555. This policy requires that the Landsat Program provide data into the future that is sufficiently consistent with previous Landsat data to allow the detection and quantitative characterization of changes in or on the land surface of the globe.

Landsat 10 continues the long-running partnership of NASA and the USGS, with NASA providing the space and launch segments and the USGS providing the ground system (GS), providing the longest continuous global record of the Earth’s land surface and coastal regions.

The Landsat series of satellites have continuously acquired multispectral images of the global land surface since the launch of the Earth Resources Technology Satellite (ERTS, later renamed Landsat 1) in 1972.

2.3 MISSION OBJECTIVES

Landsat 10 has these major mission objectives:

· Collect and archive moderate resolution Visible to Shortwave-Infrared (VSWIR) reflective and Thermal Infrared (TIR) emissive image data affording seasonal coverage of the global landmass for a continuous period of not less than five (5) years.

· Ensure that Landsat 10 data are sufficiently consistent with data from the earlier Landsat missions in terms of relative acquisition geometry, calibration, coverage characteristics, spectral characteristics, output product quality, and data availability; all of which permit scientific studies, management of land cover and land use change, along with associated inland and coastal water resources, over multi-decadal periods.

· Ensure Landsat 10 is responsive to documented emerging user needs and applications as characterized by periodic assessment, currently the User Needs for the SLI Program July 2018, Release 2.0, and identified by the operational requirements for acquisition, processing, archiving, and distribution of Earth’s image data to the United States Government and other users.

· Distribute Landsat 10 data products to the public freely on a nondiscriminatory basis.

2.4 MISSION IMPLEMENTATION

The Landsat 10 mission includes a single observatory in a 653 km sun-synchronous low-earth orbit (LEO). The observatory includes a single integrated suite of sensors called LandIS (the Landsat Instrument Suite) that images the full swath required to achieve global coverage via a repeating ground track every 18 days.

The LandIS improves all spectral and spatial capabilities by approximately twofold when compared with the Operational Land Imager (OLI) and Thermal InfraRed Sensor (TIRS) instruments flown on Landsats 8 and 9, while maintaining the historical Landsat data continuity and similar temporal coverage.

Each Landsat 10 partner agency has specific responsibilities and will deliver major elements to the overall mission. NASA will provide the Space Segment (SS) and the Launch Services Segment (LSS), and the USGS will provide the Ground System (GS) and Mission Operations.

NASA/Goddard Space Flight Center (GSFC) will provide overall Landsat 10 project management, mission system engineering and mission assurance during development and will transition the mission to USGS for science operations following on-orbit commissioning.

Figure 2.4-1 Landsat 10 Mission Architecture

(Generated from Landsat 10 Common Mission Architecture Diagram L10-SYS-DESC-0022 Rev B)

2.4.1 Space Segment

NASA/GSFC provides the Space Segment via competitive procurements for the science instrument suite (LandIS) and the spacecraft bus. The Space Segment will consist of a single observatory flying in a sun-synchronous, near-polar orbit at 653 km altitude. The spacecraft, instrument, and overall Landsat 10 mission are specified as risk class C per NPR 8705.4. The overall mission parameters needed to achieve global coverage are shown below in the Mission Parameters Table.

Table 2.4.1-1 Landsat 10 Mission Parameters

LandIS is a whiskbroom scanner which provides 26 spectral bands covering a swath on the ground of approximately 164 km on a fixed ground track defined by a world-wide reference system known as WRS-3. LandIS acquires raw detector data for all spectral bands within 15 seconds to minimize band-to-band and georegistration errors, reduce classification change detection errors due to clouds, and provide simultaneous acquisitions for science applications.

LandIS then performs data compression prior to packaging the data for transfer to the spacecraft storage and subsequent downlink. LandIS also provides internal calibration sources such as blackbody, a space port, stim lamps and solar diffuser.

The Space Segment will also provide simulators for mission, ground system and interface testing during the development phase of the mission and in support of long-term maintenance of systems. These simulators will have varying fidelity and capabilities to meet various mission needs.

2.4.2 Ground Segment

The Landsat Ground Segment (GS) consists of the ground system and its external interfaces, including NASA institutional services. The GS includes the Mission Operations Center (MOC), the Ground Network (GN), and the Data Processing and Archive System (DPAS). External interfaces include NASA's Near Space Network (NSN), GSFC Conjunction Assessment and Risk Analysis (CARA) and its Flight Dynamics Facility, along with other external interfaces.

The Landsat 10 MOC will be used for command and control, health and status monitoring, orbit and attitude maintenance, performance analysis, onboard memory management, and flight software maintenance. The MOC will support onboard autonomy for mission planning and scheduling. The MOC ingests, processes and archives telemetry data delivered via the GN. The Landsat 10 Flight Operations Team (FOT) located at the MOC performs these functions and is responsible for monitoring the observatory, detecting, investigating and resolving spacecraft anomalies and monitoring the instrument image collections and special image collections.

The GN provides geographically dispersed ground station resources for mission execution; it includes the Landsat Ground Network (LGN) and a wideband data routing capability to the Landsat cloud. The LGN provides communication capability to and from the observatory and MOC for commanding and housekeeping data via the S-band, and will receive science mission data from the observatory over a Ka-band downlink.

The DPAS ingests, processes, and archives science data returned from the observatory via the GN. LandIS data will be processed into data products with a ground sample distance (GSD) ranging from 10m-60m depending on the particular spectral band. The DPAS also provides a long-term archive capability for raw data and allows the user community to query, download, and directly interact in the cloud with Landsat 10 data products, via a public-facing web portal for receiving data products.

The USGS will lead overall Landsat 10 GS development. The USGS will also lead integration of the GS and ensure timely completion of ground readiness testing in preparation for NASA-led mission readiness activities. The MOC will support Landsat 10 mission readiness activities.

2.4.3 Launch Segment

The Launch Segment will provide the assets and services associated with the Launch Vehicle (LV) and the observatory-to-LV integration. The Launch Segment will include the LV; all Launch Vehicle-Ground Support Equipment (LV-GSE), property, and facilities to integrate the observatory to the LV and verify its integration; and perform prelaunch testing with ground-based functions. The launch vehicle and launch site will be specified during late Mission Phase B or early Phase C.

Sections 2.0-2.4.3 were generated using Landsat 10 Common Boilerplate (L10-MGMT-DESC- 0005) Rev E

3.0 GENERAL

Within this section requirements are tagged with the applicable simulators for each requirement.

This approach has been adopted with the plan that the CTSS, SoftSim, SOpS and OOpS will provide incremental capabilities and functions. The approach of the subsequent requirements is to identify the interface, performance, and functional requirements that the simulators are required to meet. The interface simulator requirements will identify the governing document that specifies the required formats. The performance requirements will identify where the simulator needs to match performance of the flight spacecraft to support the goal of flight-like timing and the ability to generate Level 1 science products. The functional requirements that reference the flight spacecraft are intended to require that the simulators perform the same functions and exhibit the same behaviors as the flight spacecraft.

3.1 MODES

SCSim-3 The Simulator shall simulate Landsat 10 SC operational modes and mode transitions. [SOpS, SoftSim]

Rationale: The Simulator mirrors the functionality of the flight SC. This includes responses from deployments, subsystem configurations, and power loading.

SCSim-471 The Simulator shall simulate Landsat 10 Observatory operational modes and mode transitions [OOpS]

Rationale: The Simulator mirrors the functionality of the flight observatory. This includes responses from deployments, subsystem configurations, power loading, and flight software / fault management / safehold.

SCSim-5 The Simulator shall simulate transitioning from unpowered to the same initial state as the flight spacecraft does upon application of operational power. [SOpS, SoftSim]

Rationale: The simulator is expected to mirror the functionality of the Flight SC. The simulator needs the same engineering state to power into and proceed to configure the SC into its nominal science configuration.

SCSim-8 The Simulator shall simulate the flight spacecraft's transition to a safe configuration upon detection of safing events. [SOpS, SoftSim, OOpS]

Rationale: This capability mirrors the functionality of the Flight SC and is expected to respond to internal fault monitoring and configure the spacecraft into the same safe configuration as the flight spacecraft. Replicating the transition to a safe configuration following internal faults is a critical training tool. Faults may also be induced via a user interface.

SCSim-9 The Simulator shall simulate both Attitude Control System (ACS) closed and open loop operations. [SOpS, SoftSim]

Rationale: The Simulator will be used in the preparation for various Mission and Ground Readiness Tests that will be operated in open and closed loop configurations. In order to accurately simulate the spacecraft response, the simulator needs the capability to replicate both these operations.

3.2 FLIGHT SOFTWARE (FSW)

3.2.1 FSW

SCSim-30 The Simulator shall operate using unmodified SC flight software, databases, limits, and settings. [SOpS, SoftSim, OOpS]

Rationale: The operations Database (DB) and Flight Software (FSW) should be used on the Simulator to allow for validation of activities performed on the Simulator. Simulator software functionality must mirror the flight unit. The FSW usage will be identical to the flight SC and is expected to replicate the flight SC FSW startup read only memory, deterministic processing, memory operations, patching, version identifiers, event logging, initialization, commanding, stored commanding, State of Health (SOH) Telemetry generation, and ancillary data generation.

Flight SC Flight Software Requirements are captured in Landsat 10 Spacecraft Requirements Document (SRD), L10-SC-REQ-0011 Section 3.14.

SCSim-403 The simulator shall be capable of receiving flight software patch updates by patches at the function, unit, module, and task levels. [SOpS, SoftSim, OOpS]

Rationale: The simulator will have the same FSW patching capability as the flight SC to allow for flight like training and product development.

SCSim-308 The Simulator shall be capable of receiving flight software loads with a duration that extends across one or more simulated ground station contacts.

[SOpS, SoftSim, OOpS]

Rationale: Supports the simulation of on-orbit software updates for large loads that may not complete in one ground contact which is typically 10 – 12 minutes. This capability is needed for software updates to S/C FSW and other S/C components (Star Tracker, GPS, etc) as well as to the LOpS/LandIS.

SCSim-309 The simulator flight software shall time tag events logged in telemetry with an accuracy of 100 msec or less. [SOpS]

Rationale: Simulator is required to provide the same timing and performance as the flight unit.

This will allow for trouble shooting of science data generated on the simulator during test activities.

3.2.2 FSW Commands

SCSim-29 The Simulator shall reject invalid or unvalidated commands. [SOpS, SoftSim, CTSS]

Rationale: The simulator is intended for procurement development, testing and FOT Training, thus will need to replicate the behavior of the S/C when an incorrect, mis-formatted, or invalid CMD is sent.

SCSim-35 The simulator shall receive commands in any flight valid format and valid data rate as specified in the Landsat 10 Spacecraft to Ground Interface Control Document (SC-GND ICD), L10-SC-ICD-0004. [SOpS, SoftSim, CTSS]

Rationale: The simulator is intended for procurement development, testing and FOT Training, thus will need to replicate the behavior of the S/C when a correct CMD is sent.

SCSim-313 The simulator flight software shall be capable of executing stored commands with an accuracy of 50 milliseconds or less. [SOpS]

Rationale: The Simulator is expected to replicate the flight SC capabilities of executing stored commands in 50 milliseconds or less for flight-like performance during mission readiness activities.

SCSim-38 The simulator shall execute real-time commands within 50 milliseconds of receipt. [SOpS, SoftSim]

Rationale: To support realistic Simulator operations Simulator commands are to be executed with the same timing as the flight S/C.

3.2.3 FSW Stored Commands

SCSim-315 The simulator flight software time resolution for stored commands shall be

100 milliseconds or less. [SOpS, SoftSim]

Rationale: The Simulator is expected to replicate the flight SC capabilities to ensure testing and operations product development being performed on the simulators will also execute properly on the S/C.

3.2.4 FSW State-of-Health TLM (Telemetry)

SCSim-15 The Simulator shall process spacecraft simulator and LOpS SOH telemetry as necessary to enable monitoring. [SOpS, SoftSim, OOpS]

Rationale: The simulator must provide the same telemetry monitoring capability as the flight unit to allow the Flight Operations Team (FOT) to perform monitoring of the simulated observatory as it would during flight operations.

SCSim-317 The simulator shall time-tag SOH telemetry at the time of collection with an accuracy of +/-100 microseconds, 3-sigma. [SOpS, OOpS]

SCSim-318 The Simulator shall provide the same SOH TLM configurability as the flight system. [SOpS]

Rationale: The Simulator will be required to perform the same functions to changes SOH TLM as the flight unit to support mission readiness activities and support operations product development.

SCSim-13 The Simulator shall buffer at least 72 hours of Simulator Stored State of

Health (SSOH) in local command and data handling (C&DH) memory at the maximum onboard telemetry rate. [SOpS, SoftSim]

Rationale: The simulator must have the capability to maintain all SSOH onboard at the unfiltered volume for 72 hours to allow for attempts to retransmit data or downlink in the event of anomaly.

SCSim-319 The Simulator shall allow for the playback of a user provided SSOH file in the same manner as flight that is no less than 100 minutes of SSOH that is at the maximum onboard telemetry rate. [CTSS]

Rationale: The CTSS does not need the capability to record SSOH, but does need the capability to playback a set of SSOH to simulate the House-Keeping (HK) TLM playback in the same manner as flight for ground testing.

SCSim-320 The most recent 10 minutes of SSOH shall be preserved indefinitely and made available for downlink upon a switchover to a redundant C&DH element and persist through reboot. [SOpS, SoftSim]

Rationale: Capability to preserve more than 10 minutes of data is acceptable. SSOH data that precedes a C&DH swap should not be deleted unless directed via ground command. It's necessary for the simulators to replicate this function for mission readiness activities and training.

SCSim-36 The Simulator shall provide the same SSOH playback capabilities as the flight unit [SOpS, SoftSim]

Rationale: The Simulator will be required to perform the same functions to play back SSOH as the flight unit to support mission readiness activities and operations product development

3.2.5 FSW Ancillary Data

SCSim-322 The Simulator shall time tag ancillary ephemeris data to the Simulator time reference with an accuracy of 50 microseconds, 3-sigma. [SOpS]

Rationale: The Simulator will need to replicate the flight unit's ability to generate ancillary data to support realistic product generation

SCSim-323 The Simulator shall time tag ancillary attitude data to the Simulator time reference with an accuracy of 150 microseconds, 3-sigma. [SOpS]

Rationale: The Simulator will need to replicate the flight unit's ability to generate ancillary data

SCSim-324 The Simulator shall time tag all other ancillary data to the Simulator time reference with an accuracy of 250 microseconds, 3-sigma. [SOpS]

Rationale: The Simulator will need to replicate the flight unit's ability to generate ancillary data

SCSim-325 The Simulator ancillary data shall include source data at the generated rate.

[SOpS]

Rationale: The Simulator will need to replicate the flight unit's ability to generate ancillary data

SCSim-326 The Simulator shall acquire ancillary data from the SOpS and LOpS as defined in the Landsat 10 Mission Data Format ICD. [SOpS, OOpS]

Rationale: LOpS ancillary data is provided by the LOpS as part of the instrument data cubes.

Simulator information regarding attitude, attitude rate, timing, and telemetry SOH parameters such as temperature, voltage, operational configuration, and mechanism must be provided in the Simulator ancillary stream to support image reconstruction by the ground system. Ancillary data is necessary to provide level 1G products without the need to query external sources or MOC database.

SCSim-327 The Simulator shall acquire ancillary data while in any operational mode the same as the flight system. [SOpS]

Rationale: The Simulator will need to replicate the flight unit's ability to generate ancillary data

SCSim-328 The Simulator shall have the capability to ingest and store Simulator generated ancillary data independently of image operations. [SOpS]

Rationale: The Simulator will need to replicate the flight unit's ability to generate ancillary data to support diagnostic activities

3.3 COMMAND AND DATA HANDLING (C&DH) SYSTEM

3.3.1 C&DH Commands

SCSim-27 The Simulator shall validate commands the same as the flight unit. [SOpS, Rationale: The simulator should provide command validation in accordance with the command and telemetry (C&T) DB.

SCSim-330 The Simulator shall process and execute validated commands the same as the flight unit. [SOpS, SoftSim]

SCSim-331 The Simulator shall reject invalid commands the same as the flight unit.

[SOpS, SoftSim, CTSS]

SCSim-332 The Simulator shall support Command Operations Procedure-1 protocol as defined in CCSDS 232.1-B-2. [SOpS, SoftSim, CTSS]

SCSim-333 The Simulator shall execute all hardware decoded commands upon receipt

[SOpS, SoftSim]

SCSim-334 The Simulator shall be capable of receiving table loads across multiple contacts. [SOpS, SoftSim, OOpS]

SCSim-41 The Simulator shall accept and process all key management commands the same as the flight unit. [SOpS, SoftSim]

Rationale: While encryption and decryption are not necessary on the Simulator, it will be necessary to simulate the complete management of encryption and RF operations to support realistic simulation and training capabilities.

SCSim-336 The Simulator shall simulate the functions of the decryption hardware.

Rationale: While the simulator will not operate with encrypted commanding, it will be necessary to fully simulate the functions associated with encryption and management on the simulators to facilitate ground and operations testing.

3.3.2 C&DH Mass Storage

SCSim-16 The Simulator shall provide a mass storage system that replicates the flight unit's physical memory locations. [SOpS]

Rationale: The Simulator will be required to replicate the flight mass storage system's capability to manage physical memory for mission readiness and operations product development in a flight like manner.

SCSim-339 The Simulator shall perform mass storage system diagnostic and test functions the same as the flight system. [SOpS]

Rationale: The Simulator mass storage system will need to replicate the flight systems functionality.

SCSim-17 The Simulator shall have the capacity to store at least 8 Terabits of Mission

Data within the mass storage system. [SOpS]

Rationale: In order to match the flight unit capabilities in support of Test-As-You fly operations the size of the memory needs to accommodate storage of mission data files, which is the combined instrument data cube (which consists of imaging sensor data and Instrument simulator ancillary data) and spacecraft simulator ancillary data.

SCSim-437 The simulator shall retain all data stored in the simulated mass storage system when simulating any mode transitions, including power cycling.

Rationale: The simulator needs to model the behavior of the flight mass storage system for use during mission readiness activities and training.

SCSim-49 The simulator shall assemble data cubes and instrument ancillary data with spacecraft ancillary data into mission data files as defined in the Landsat 10 Mission Data Format ICD. [SOpS]

Rationale: Mission data is stored in a mission data file (MDF), which includes the instrument simulator data cubes, spacecraft simulator ancillary data, and MDF checksum. The detailed format of the MDF will be defined in the Landsat 10 Mission Data Format ICD.

SCSim-340 The Simulator shall store mission data files in the mass storage system that are comprised of instrument data and associated spacecraft ancillary data.

[SOpS]

Rationale: This association of the ancillary and imaging sensor data into a single file minimizes the impact of data loss and supports ground processing. Instrument ancillary and instrument imaging sensor data is provided by the LOpS. The spacecraft ancillary data is generated by the Simulator.

SCSim-341 The Simulator shall include the following attributes within each mission data file:

• Time of File Generation (in DDD_YYYY_HHMMSS format)

• Priority Designation

• File Name

• File Length [SOpS, OOpS]

Rationale: In addition to the instrument imaging sensor and ancillary data, each mission data file must include a set of attributes that enable the Ground System to identify and process the data.

SCSim-342 The Simulator shall store 30 seconds of continuous spacecraft Simulator ancillary data that spans the time of capture of each LOpS data cube contained within the Mission Data Files (MDF). [SOpS, OOpS]

Rationale: The Spacecraft simulator ancillary data that is stored in each mission data file should correlate closely with the LOpS data cube in that file to support ground processing. MDFs include imaging data, instrument ancillary, and simulator ancillary data. The MDF is sent to the ground via wideband system – therefore a narrowband link is not necessary to support acquisition and generation of 1G products on the ground.

SCSim-343 The Simulator shall append no less than 12 seconds of the 30 seconds of the continuous ancillary data block from the ancillary data preceding the mission data imaging. [SOpS, OOpS]

Rationale: The simulator will need to replicate the flight systems generation of Mission Data Files to enable proper ground processing.

SCSim-344 The Simulator shall append no less than 10 seconds of the 30 seconds of the continuous ancillary data block post-mission data imaging. [SOpS, OOpS]

Rationale: The simulator will need to replicate the flight systems generation of Mission Data Files to enable proper ground processing.

SCSim-345 The Simulator shall receive from LOpS for each scan instrument data cubes that total no more than 3 Gigabytes in size. [SOpS, OOpS]

Rationale: The limitation on the total volume on LOpS data cubes associates with a single scan ensures that once packaged in an MDF, the MDF will not exceed the maximum data size allowable per the CCSDS 133.1-B-3 Encapsulation Packet Protocol standard.

SCSim-346 The Simulator shall have the capability to mark individual mission data files as priority files based on the onboard land mask. [SOpS, OOpS]

Rationale: The Simulator will need the capability to replicate the flight SC capabilities.

SCSim-347 The Simulator shall maintain a Volume Table of Contents (VTOC) that includes a list of all files currently stored in the mass storage, which is accessible external to the mission data files themselves and contains the same content as the flight SC VTOC. [SOpS, OOpS]

Rationale: The Simulator must be able to track and report the listing of files managed by the mass storage system and their logical location in memory.

SCSim-348 The Simulator shall interleave and downlink the VTOC over the wideband link each time a Mission Data File is downlinked. [SOpS, OOpS]

Rationale: VTOC downlink accompanying each MDF ensures that the ground has current knowledge of files that the Simulator attempted to downlink.

SCSim-349 The Simulator shall provide the VTOC in the SSOH stream upon command.

[SOpS, OOpS]

Rationale: The VTOC must be able to be accessed via the narrowband link upon ground command.

SCSim-350 The Simulator shall provide the same playback capabilities as the flight mass storage system. [SOpS]

Rationale: The mass storage system on the Simulator must operate in an identical fashion to the flight unit for use during mission readiness activities and operations product development.

SCSim-351 The Simulator shall provide the same playback operations as the flight spacecraft. [SOpS]

Rationale: The mass storage system on the Simulator must operate in an identical fashion to the flight unit for use during mission readiness activities and operations product development.

SCSim-439 The simulator shall simulate the mass storage data integrity functions of the flight spacecraft. [SOpS, SoftSim]

Rationale: The simulator needs to model the same behavior and capabilities as the flight spacecraft to support mission readiness activities and training.

SCSim-352 The Simulator shall protect data at the MDF level upon command such that it cannot be autonomously overwritten [SOpS]

Rationale: To support diagnostic investigation, there may be times in which data needs to be protected to ensure it remains available on board for an extended duration and will not be overwritten by autonomous operational functions.

SCSim-353 The Simulator shall unprotect MDFs by command only. [SOpS]

Rationale: To ensure indefinite lifetime of data that has been protected, it is critical to ensure that it remains available until it is manually unprotected by the ground.

3.3.3 C&DH Instrument Simulator Interface

SCSim-20 The Simulator shall provide a flight-like interface to the LOpS output data bus for imaging data cubes, and telemetry consistent with the Landsat 10 Spacecraft Interface Requirements Document (SCIRD), L10-SC-ICD-0002.

Rationale: To validate data exchanged between the Simulator and LOpS, the Simulator will need to provide an output data bus interface consistent with what is defined in the Landsat 10 Spacecraft Interface Requirements Document (SCIRD), L10-SC-ICD-0002.

SCSim-23 The Simulator shall provide a flight-like interface to the LOpS input data bus for commands and time-of-day time code consistent with the Landsat 10

Rationale: To validate data exchanged between the Simulator and LOpS, the Simulator will need to provide an input data bus interface consistent with what is defined in the Landsat 10 Spacecraft Interface Requirements Document (SCIRD), L10-SC-ICD-0002.

3.3.4 C&DH Instrument Simulator Commands

SCSim-21 The Simulator shall send commands to the LOpS over a flight-like input data bus. [SOpS, OOpS]

Rationale: In support of FOT training and testing the Simulator should replicate the ability to send all commands to the LOpS. The commands are inclusive of ground commands, spacecraft stored commands, files, memory and table loads.

SCSim-22 The Simulator shall simulate instrument command verification when not integrated with a LOpS. [SOpS, OOpS]

Rationale: For training, mission readiness, and database checkout the Simulator will be able to accept and forward all LOpS commands and simulate basic command verification of LOpS for testing without a LOpS available.

SCSim-358 The Simulator shall simulate the capability to send discrete commands to the

LOpS, as needed. [SOpS, OOpS]

Rationale: The Simulator should fully simulate the flight interface with the LOpS

SCSim-359 The Simulator shall issue instrument simulator commands at the same rate as the flight spacecraft. [SOpS]

Rationale: The Simulator should replicate the flight SC timing with the LOpS.

3.3.5 C&DH Instrument Simulator Telemetry

SCSim-361 The simulator shall receive and process instrument housekeeping data from the LOpS in all valid formats and data rates as specified in the Landsat 10

Rationale: The data going across the output data bus from the LOpS will need to match the flight unit as defined in Landsat 10 Spacecraft Interface Requirements Document (SCIRD), L10-

SC-ICD-0002.

SCSim-362 The Simulator shall receive simulated bilevel or analog telemetry from the

LOpS to indicate the execution of discrete commands, as needed. [SOpS, Rationale: The Simulator should fully simulate the flight interface with the LOpS.

3.3.6 C&DH Instrument Simulator Time of Day

SCSim-365 The Simulator shall provide the time-of-day time message to LOpS over an input data bus. [SOpS, OOpS]

SCSim-366 The Simulator shall provide a Time-Of-Day signal that matches the performance and capability of the flight spacecraft. [SOpS]

Rationale: It is critical for the Simulator to perform with the same timing as the flight units to properly validate operational performance during mission readiness testing.

3.3.7 C&DH Imaging Sensor Data

SCSim-25 The Simulator shall receive LOpS instrument data cubes via an output data bus in accordance with Landsat 10 Spacecraft Interface Requirements Document (SCIRD), L10-SC-ICD-0002. [SOpS, OOpS]

Rationale: LOpS instrument data cubes include the imaging sensor data and corresponding instrument ancillary data. Diagnostic data provided by LOpS may be either uncompressed or compressed depending on the diagnostic mode in which LOpS is configured. Diagnostic data will be packaged within instrument data cubes by the LOpS before being sent to the spacecraft.

SCSim-368 The Simulator shall receive metadata with instrument data cubes from the

LOpS. [SOpS, OOpS]

SCSim-370 The Simulator shall receive from LOpS on each Ethernet lane a explicit start-of-scan and end-of-scan markers that bracket Instrument Data Cube transmission in accordance with Landsat 10 Spacecraft Interface Requirements Document (SCIRD), L10-SC-ICD-0002. [SOpS, OOpS]

SCSim-48 The simulator shall provide a bus monitoring capability for the analysis of and capture of data exchanged between the LOpS and the simulator. [SOpS, Rationale: It is necessary to capture data exchanged between LOpS and Simulator for analysis during integration and operations troubleshooting.

SCSim-91 The Simulator shall generate Mission Data Files using LOpS data cubes and spacecraft Simulator generated ancillary data. [SOpS, OOpS]

Rationale: It is essential to get simulated mission data from the simulators emulating the interface, data format, and rate to test the image processing system. The ground system will use these data as part of ground system testing, including processing to Level 1 products.

3.4 SC OPERATIONAL AUTONOMY

SCSim-355 The Simulator shall replicate the flight SC Operational Autonomy. [SOpS, SoftSim, OOpS]

Rationale: The Simulator should replicate the flight SC's operational autonomy capabilities.

3.5 FAILURE RESPONSE AND REDUNDANCY

SCSim-7 The Simulator shall provide and simulate the same onboard diagnostic capability as the Flight SC. [SOpS, SoftSim, OOpS]

Rationale: The SC diagnostic capability is intended to provide the operational status of the SC software and hardware. Diagnostics may be performed in the background such as memory scrubbing and operational-interleaved diagnostics such as in-process testing of components or commanded for a specific component. The results of diagnostic testing are provided in SC telemetry.

SCSim-52 The Simulator shall simulate the response characteristics of failed Landsat 10

SC subsystems and components, including but not limited to degraded mode operations, loss of function, and fault-induced state transitions. [SOpS, Rationale: Simulator should be able to simulate failed spacecraft components for the purpose of operator training and mission simulations.

SCSim-53 The Simulator shall replicate flight subsystem SC failover response. [SOpS, Rationale: Simulator response should reflect what the flight system configuration would be in the event of the failover in telemetry.

SCSim-54 The Simulator shall emulate the internal flight hardware response for all internal redundancy. [SOpS, SoftSim, OOpS]

Rationale: The Simulator must accept commands and provide realistic response to transition to redundant systems.

SCSim-55 The Simulator shall be capable of overriding autonomous functions in the same manner as the flight spacecraft. [SOpS, SoftSim, OOpS]

Rationale: Simulator needs to be able to mirror flight system behavior for the diagnosis of failures and anomalies as well as in support of mission readiness testing.

SCSim-372 The Simulator shall be capable of overriding automatic safing in the same manner as the flight spacecraft. [SOpS, SoftSim, OOpS]

SCSim-373 The Simulator shall be capable of performing all component switchovers in the same manner as the flight spacecraft [SOpS, SoftSim, OOpS]

SCSim-56 The Simulator shall report autonomous state changes and reconfigurations in housekeeping telemetry. [SOpS, SoftSim, OOpS]

Rationale: Simulator telemetry needs to report state changes for detection of failures and anomalies within the simulator in the same manner as the flight SC.

3.6 THERMAL

SCSim-110 The Simulator shall accept flight-like operational and survival heater temperature and sensor data as defined in the Landsat 10 Spacecraft to Landsat Instrument Suite (LandIS) Interface Control Document (SC-LandIS ICD), L10-SC-ICD-0005. [SOpS, OOpS]

Rationale: To accept response characteristics from the instrument during power on testing.

SCSim-111 The Simulator shall simulate all thermal subsystem component functions and responses. [SOpS, SoftSim]

Rationale: Allows Simulator to test with realistic thermal functions and responses.

SCSim-112 The Simulator shall simulate Landsat 10 SC survival heaters temperatures.

Rationale: Allows the Simulator to test with realistic thermal conditions.

SCSim-374 The Simulator shall simulate Landsat 10 operational heaters temperatures.

Rationale: Allows the Simulator to test with realistic thermal conditions.

SCSim-375 The Simulator shall dynamically simulate the thermal environment based on simulated attitude and orbit. [SOpS, SoftSim]

Rationale: The Simulator should accurately represent the SC thermal environment.

SCSim-57 The Simulator shall simulate flight-like survival heater current draw per each power services. [SOpS, SoftSim]

Rationale: The simulator will need to replicate the flight spacecraft performance for use in mission readiness activities.

3.7 ATTITUDE CONTROL SYSTEM (ACS)

SCSim-93 The Simulator shall simulate the operations and functions of the complete attitude and orbital control system. [SOpS, SoftSim]

Rationale: The simulator is expected to model attitude and environment sensors and controls(e.g., actuators, thrusters, valves).

SCSim-377 The Simulator shall model mass properties of the observatory in both a stowed and deployed configuration. [SOpS, SoftSim]

Rationale: The Simulator should accurately represent the vehicle performance with changes to the mass properties.

SCSim-97 The Simulator shall simulate updates to attitude and body rates based on actuator…