LSDS-2424

Version .9

Department of the Interior U.S. Geological Survey

Landsat 10 (L10) Mission Operations Center (MOC) Synopsis

November 2026

- ii - LSDS-2424

Landsat 10 Mission Operations Center (MOC) Synopsis

November 2026

Document Owner

G. R. Mah Date Landsat 10 Mission System Engineer

Approved By:

Brian Sauer Date Landsat 10 Project Manager

EROS

Sioux Falls, South Dakota

- iii - LSDS-2424

Executive Summary

This document provides a synopsis of Landsat 10 (L10) mission operations center MOC operations based on MOC functions, along with other project descriptive narrative covering the expected work for mission readiness and integration and test (I&T) support.

Landsat represents the world’s longest continuously acquired collection of space-based moderate-resolution land remote-sensing data. The program’s imagery provides a unique resource for those who work in agriculture, geology, forestry, regional planning, education, mapping, and global change research. Landsat images are also invaluable for emergency response and disaster relief.

This document is under the U.S. Geological Survey (USGS) Landsat 10 (L10) Project Configuration Control Board (CCB) control.

- iv - LSDS-2424

Document History

Document Number

Document Version

Publication Date

Change Number

LSDS-2424 .9 November 2026 –

- v - LSDS-2424

Contents

Executive Summary ..................................................................................................... iii

Document History ........................................................................................................ iv

Contents ......................................................................................................................... v

List of Figures ............................................................................................................. vii

List of Tables ............................................................................................................... vii

Section 1 Introduction

1.1 Background

1.2 Purpose

1.3 Scope

1.4 References

1.4.1 Applicable Documents

1.4.2 Reference Documents

Section 2 Landsat 10 Overview

2.1 Mission Statement

2.2 Summary

2.3 Objectives

Section 3 Overview

3.1 Introduction

3.2 MOC Architecture and Characteristics

3.3 Development Phase

Section 4 Mission Readiness

4.1 Overview

4.2 Flight Ops Product Development

4.3 MOC to S/C Facility Connection

4.4 Network Readiness Tests (NRTs)

4.5 Spacecraft Operations Readiness Test (SORTs)

4.6 MOC Facilities for Mission Readiness Test Support and Launch

4.7 Simulators

4.8 Mission Readiness Test (MRTs)

4.9 Mission Simulations (MSIMs)

4.10 Launch Rehearsals

4.11 Launch and Early Orbit (LEO)

4.12 In-orbit commissioning

4.13 Acceptance and Handover Support

Section 5 MOC Operations

5.1 Routine Operations

5.2 MOC Automation

5.3 Notional Operations Scenarios

5.3.1 GN Contact Planning Scenario

5.3.2 Routine Contact Scenario

5.3.3 Trending and Analysis Scenario

5.3.5 Mission Data File Retransmit Scenario

- vi - LSDS-2424

5.3.6 LCR/SCR Scenario

5.3.7 Special Command Request (SpCR) Scenario

5.3.8 Orbit Determination and Maintenance Scenario

5.3.9 Conjunction Assessment / Risk Mitigation Maneuver (RMM) Scenario ... 35

5.3.10 Alternate Tracking Scenario

5.3.11 Ad-Hoc GN Contact Scheduling (Blind Acquisition) Scenario

5.3.12 FSW State Management and Maintenance Scenario

5.4 Flight Operations Policies and Protocols

Appendix A MOC Functions Summary

A.1 Introduction A.2 Ground Segment Architecture Summary A.3 MOC Interfaces A.4 MOC Functions and Capabilities

A.4.1 Telemetry and Command (T&C) A.4.2 Flight Dynamics / Orbit Operations (FD/OO) A.4.3 Planning and Scheduling A.4.4 Contact and Activity Orchestration (CAO) A.4.5 Configuration Management and State Management A.4.6 Trending and Analysis A.4.7 Alerts and Notifications A.4.8 Load Builder/Generator and Validation A.4.9 Analytical Modeling and Simulators A.4.10 Network and Infrastructure A.4.11 Mission Operations Situational Awareness A.4.12 Other Capabilities

Appendix B Acronyms

References

- vii - LSDS-2424

List of Figures

Figure 3-1. MOC Functions Figure 4-1. Notional MOC Mission Readiness Support Timeline Figure 4-2. MOC and “mini-MOC” Support for I&T Figure 4-3. Notional MOC Facilities Figure 4-4. Landsat 10 Simulators and Users Figure 4-5. Notional Profile for Transition to Automated Operations Figure 5-1. Notional FOT Coverage

List of Tables

Table 1-1. Applicable Documents Table 1-2. Reference Documents Table 4-1. Notional MOC Coverage for Tests, Launch and Operations Table 4-2. Notional L10 MRTs Table 4-3. Notional L10 Mission Simulations Table 5-1. Landsat Flight Operations Policies and Protocols

- 1 - LSDS-2424

Section 1 Introduction

1.1 Background

The Landsat 10 (L10) mission is a component of the Sustainable Land Imaging (SLI) Program conducted jointly by the National Aeronautics and Space Administration (NASA) and U.S. Geological Survey (USGS) of the Department of the Interior (DOI).

L10 was conceived as a follow-on mission to the highly successful Landsat series of missions that have provided satellite coverage of Earth’s continental surfaces since the launch of the Earth Resources Technology Satellite (ERTS, later renamed Landsat 1) in 1972. The Landsat data archive constitutes the longest continuous moderate-resolution record of the global land surface as viewed from space. L10 is intended to ensure that Landsat-like data be provided to the USGS National Satellite Land Remote Sensing Data Archive (NSLRSDA) for a period of not less than five years.

1.2 Purpose

The purpose of this L10 Mission Operations Center (MOC) synopsis is to provide context to potential vendors on the expected functions, operations, and activities of the L10 MOC through development and operations. Additionally, this synopsis provides some operational flows and scenarios that were used to generate the MOC driving requirements. These scenarios attempt to be as agnostic as possible to allow for internal functionality to be defined without artificially imposing specific subsystem definitions on an existing application suite. It is additionally expected that these notional scenarios will need to be revised, or additional scenarios added, to map to a vendor specific application suite and internal operations philosophy. All of these scenarios will be used in the generation of the complete set of Level 4 MOC requirements after award.

1.3 Scope

This document provides a synopsis of L10 MOC operations based on MOC functions, along with other project descriptive narrative covering the expected work for mission readiness and integration and test (I&T) support.

1.4 References

1.4.1 Applicable Documents

The documents in Table 1-1 are considered to form a part of this document.

Document Number Document Title

TBS

Table 1-1. Applicable Documents

- 2 - LSDS-2424

1.4.2 Reference Documents

The documents in Table 1-2 provide additional background and context for this document.

Document Number Document Title L10-MGMT-DESC-0028 Landsat 10 Mission Synopsis, March 2026 Update

Table 1-2. Reference Documents

- 3 - LSDS-2424

Section 2 Landsat 10 Overview

2.1 Mission Statement

L10 will continue the acquisition, archive, and distribution of multi-spectral imagery affording global, synoptic, and repetitive coverage of 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 Summary

The L10 mission is in keeping with the Landsat programmatic goals stated in the Commercial Space Act of 1998 (Public Law 105-303) and the Land Remote Sensing Policy Act of 1992 (Public Law 102-555), which require the Landsat program to provide future data that are consistent with previous Landsat data, allowing the detection and quantitative characterization of changes in or on Earth’s land surfaces.

L10 continues the long-running partnership of NASA and USGS, with NASA providing the Space and Launch segments and USGS providing the Ground System and Mission Operations. NASA/Goddard Space Flight Center (GSFC) will provide overall L10 project management, mission system engineering, and mission assurance during development and will transition the mission to USGS for science operations following on-orbit commissioning.

The L10 mission features a single observatory operating in a 653-kilometer (km) sun-synchronous, low-Earth orbit. The observatory includes the Landsat Instrument Suite (LandIS), an integrated set of sensors designed to capture the full imaging swath needed to achieve global coverage on a repeating 18-day ground track. The instrument will provide 26 spectral bands with a maximum Ground Sampling Distance (GSD) of 10- 60 meters (m) dependent on the spectral band, covering a swath of approximately 164 km on a ground track defined by a Worldwide Reference System known as WRS-3.

2.3 Objectives

L10 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 L10 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 L10 is responsive to documented emerging user needs and applications as characterized by periodic assessment, currently the User Needs for the Sustainable Land Imaging Program July 2018, Release 2.0,

- 4 - LSDS-2424

and identified by the operational requirements for acquisition, processing, archiving, and distribution of Earth’s image data to the U.S. Government and other users.

Distribute L10 data products to the public freely and on a nondiscriminatory basis.

For detailed information on the L10 mission overview and architecture, and operations concepts, reference the L10-SYS-PLAN-0007 Landsat 10 Mission Operations Concept (Ops Con) Document.

- 5 - LSDS-2424

Section 3 Overview

3.1 Introduction

The Mission Operations Center (MOC) supports three major phases of activities:

Development, including execution of scope post-launch/handover that was deferred, as well as any essential bug fixes or enhancements needed to achieve steady-state long-term operations

Mission Readiness, including launch readiness, launch, and commissioning Routine Operations

This ops con will primarily focus on describing scenarios for the Routine Operations phase. A section is included that describes Mission Readiness support and a notional roll-out of phased MOC capabilities.

The MOC should be developed using the test-like-you-fly (TLYF) philosophy. Therefore testing at the MOC-level (level-4, L4) should be done in the context of how the MOC will be used in routine operations. Thus, specific test scenarios will be covered in test procedures generated during development.

The operations scenarios will be described in the Routine Operations section, and be described in the terms of the following MOC functions:

Figure 3-1. MOC Functions

The MOC is intended to operate using automation that is ready at launch. This will be implemented in a phased “crawl/walk/run” approach during commissioning with an objective of being able to operate using “lights-out” automation following handover / Mission Transition Handover Review (MTHR). All routine operational scenarios here are intended to be executed by the MOC automation system, with minimal Flight Operations

- 6 - LSDS-2424

Team (FOT) staff inputs under normal conditions. It is envisioned that the FOT will serve more of an oversight role in the routine MOC operations, overseeing automated operations, and only stepping in when required to address off-nominal situations that the automation cannot deal with. It is expected that some level of automated fault determination and contingency operations will be built into the MOC automation system to address off-nominal cases that are seen periodically (frequently) and/or easy to resolve without major system impacts.

3.2 MOC Architecture and Characteristics

The MOC will use a containerized/cloud-native architecture for cost and operations efficiency, ideally allowing processes and applications to run only when needed. Use of a hosting or infrastructure-as-code architecture will enable reduced support and system administration needs, further optimizing operations and cost efficiency.

Given the anticipated architecture, the approach and requirements for a backup MOC capability are being revised. It is expected that a traditional “hot backup” rack of MOC equipment will not be implemented, but details of the specific MOC implementation will guide the final approach and requirements as a containerized or cloud-based system will allow different options for addressing backup MOC requirements. We are also revising backup requirements considering continuity of operations and identifying critical data flows and services that would be the highest levels of performance and availability.

Use of a modular design with well-defined interfaces between applications and services will provide flexibility to accommodate future changes and updates, as well as scalability.

Data generated by the MOC systems (telemetry from L10, system metrics, derived mnemonics, etc.) will be stored in a format that is optimized for use by automated analysis tools, i.e. artificial intelligence/machine learning (AI/ML) to permit both ongoing operational analysis for anomaly detection and initiating a response, as well as for emerging applications such as predictive analysis that allows proactive mission decision-making.

All interfaces between the MOC and external systems will be required to support additional processing specific to security including functions that monitor baseline compliance, protect data-at-rest and data-in-transit, endpoint detection and response, packet capture, and other functions required to operate a Federal Information Security Modernization Act (FISMA) Moderate system. The MOC architecture and implementation will include compute resources with enough additional processing capability to accommodate these functions and provide validation artifacts that show that all required cyber security functions are capable of operating in a high availability satellite communications ground system for an officially designated High Value Asset.

Additionally, all protocols that are in use will be documented with a description of where it is transmitted/stored as plaintext or cipher text in the system architecture documentation.

- 7 - LSDS-2424

Staff working on MOC development or on the flight operations team will need to adhere to USGS and DOI policies and procedures for access to USGS computer systems and facility access. As needed for their scope of work, staff will need to apply for and receive USGS credentials (personal identity verification, PIV), per the following policies:

H.14 GS 1415 Access to Government Facilities, July 2001 H.17 GS 1420 Use of Government Computers, September 2018 H.23 Security Requirements: Facility Access and Information Technology, August 2016 (for DOI Access and PIV Issuance)

3.3 Development Phase

It is anticipated that the MOC will be developed using a largely established existing framework of applications that have already been integrated with each other, and the main task of the development effort is customization for L10 and implementation of new mission-specific functionality that is not part of the base application suite.

The MOC may be delivered in a series of phased releases to deliver capabilities needed to support spacecraft (S/C) and mission integration and test (I&T), as a function of the S/C maturity and the S/C vendor’s test approach. A MOC release will first be internally verified for lower-level (Level 5, L5, and below) subsystems and components, then a formal Level 4 (L4) requirements verification will be conducted that covers the capabilities being delivered in the release. Following successful L4 testing the release will be delivered to the ground system for integration and testing at Level 3 (L3) via Ground Readiness Tests (GRTs). After successful GRT execution, the release (and MOC environment) will be available for use in S/C or other mission-level tests.

- 8 - LSDS-2424

Section 4 Mission Readiness

4.1 Overview

Mission Readiness scope includes the following:

Support (early T&C capability) for generating instrument and S/C bus products in the language used by the MOC

Implement the capability for the MOC to observe S/C and observatory I&T Support Network Readiness Tests (NRTs) to validate interfaces between the

MOC and NASA institutional services Support for S/C end-to-end testing Support for observatory end-to-end testing Participate in Mission Simulations (MSIMs) Participate in Launch Rehearsals Conduct flight operations for Launch and Early Orbit (LEO) Conduct In-orbit commissioning of the S/C bus, instrument and observatory, including demonstration of a period of routine operations covering at least one complete 18-day imaging cycle, under direction of the S/C and instrument vendors, and Mission Readiness team

Support on-orbit acceptance and handover of the mission from NASA to the

USGS

A notional timeline for MOC support of mission readiness activities is shown below (USGS-led activities are shown in green, and NASA-led activities are shown in blue):

Figure 4-1. Notional MOC Mission Readiness Support Timeline

4.2 Flight Ops Product Development

The mission is using a commercial FAR part-12 acquisition approach for the S/C bus and is expecting to get a S/C that is largely “off-the-shelf” with no major development required for use in L10, but will include some mission unique capabilities within the defined critical interfaces. As an “off-the-shelf” product, it is expected that a large number of the operations products needed to “fly” the S/C bus are already developed and have already been validated in orbit, though there will be ops products that need to be developed for additional capabilities for L10. Thus, the responsibility of the flight ops

- 9 - LSDS-2424

product development has been split between NASA Mission Readiness and the S/C vendor, which takes advantage of S/C commercial practices.

To streamline overall L10 development, the S/C vendor (or NASA mission readiness team) will provide validated S/C and observatory operations products to the MOC vendor in the language used by the MOC system. As it is expected that an existing “off-the-shelf” S/C bus will be procured for L10, it is anticipated that this approach could accelerate the L10 development effort. To support development of S/C and observatory products, an early delivery of T&C (and possibly load-builder) functionality is required so it can be used to generate new operations products, convert/translate pre-existing S/C products, and validate (e.g. via simulators, flatSAT or other tools) all S/C and observatory products for use with flight hardware.

The NASA mission readiness team will be responsible for generating LandIS instrument products and will need a similar early delivery of T&C (and possibly load-builder) functionality. As L10 is intended to implement on-board automated mission planning, it is possible that a subset of instrument flight products related to instrument imaging configuration will be used only during early phases of commissioning until the on-board automation has been proven; the instrument imaging configuration products will reflect similar steps used internally by the S/C onboard mission planning system.

The T&C database for both the S/C and instrument are required to be in XTCE format, and a preliminary version of these databases will be available for initial testing prior to the delivery of the early T&C capability.

4.3 MOC to S/C Facility Connection

Early in S/C I&T, after the S/C has been integrated, the S/C vendor is required to work with NASA to establish a bidirectional WAN connection (AKA “listen-line”) between the MOC and the S/C vendor facility to support mission readiness (MR) activities and Ground System (GS) development (the listen-line will be moved to follow the observatory when it goes to the launch site). This connection serves two purposes:

Provides a path for MOC systems to command the S/C and view TLM in support of mission end-to-end testing

Provides means for the MOC to capture all S/C TLM during the development/I&T phase (whenever the vehicle is powered on) for both a long-term archive (providing a resource for anomaly investigations in ops) and training/testing of MOC systems and FOT staff

Historically, on prior missions, following provisioning of the “listen-line” WAN connection, a series of tests would be held to establish the capability for the MOC to communicate with the S/C. This was initially done by sending a “mini-MOC” to the S/C vendor facility to interface with a flatSAT or similar Engineering Development Unit (EDU) or flight Software Development and Validation Facility (SDVF) system using a local hardline connection to perform unencrypted commanding (send and validate a no-op CMD) and reception of TLM. The mini-MOC was a server running the current build of the MOC T&C application and operated by both a FOT member and one of the MOC

- 10 - LSDS-2424

development staff (with the assumption that this would provide the ability to make minor modifications to the T&C S/W as needed to execute the test or resolve any issues seen). Once unencrypted commanding capability was demonstrated, the test would progress to encrypted commanding with the S/C in preparation for further testing. Given that it is expected the MOC will be a containerized virtual system running in the cloud or on the Earth Resources Observation and Science (EROS) enterprise cluster, it has yet to be defined what an equivalent mini-MOC system implementation will be for L10, though the intent will be the same: provide an initial T&C capability to support early interface testing with a flight-like system at the S/C vendor facility.

Figure 4-2. MOC and “mini-MOC” Support for I&T

4.4 Network Readiness Tests (NRTs)

Network Readiness Tests (NRTs) verify Near Space Network (NSN), Space Network (SN) and Landsat Ground Network (LGN) interfaces between space segment, Flight Dynamics Facility (FDF), Conjunction Assessment Risk Analysis (CARA), spacecraft contractor facilities and L10 MOC. The NASA Mission Readiness Manager (MRM) will coordinate testing between ground system and NASA SN, NSN, FDF, Spacecraft Vendor and CARA. NSN will lead the development of associated test plans and procedures, and collaboration with L10 NASA and USGS project teams. The primary objectives of NRTs are to verify network connectivity and data flow to ensure all network connection and firewalls are properly configured between NSN/FDF/CARA/NASCOM/Spacecraft contractor and MOC, specifically:

Verify connectivity and interfaces Verify reliable network communication Verify scheduling interfaces Exercise the network from L10 MOC through network elements in an operational cadence using operational procedures and processes to build expertise and proficiency for Ops personnel

NRTs may also be performed as part of regression testing after each major GS build release and will take advantage of other tests for efficiency.

- 11 - LSDS-2424

4.5 Spacecraft Operations Readiness Test (SORTs)

As part of the commercial acquisition approach for the S/C bus, the mission end-to-end testing responsibility has been split between the S/C vendor and NASA MR. The Spacecraft Operations Readiness Test (SORT) will be led by the S/C vendor and cover functionality provided solely by the S/C bus (e.g. – ACS, structures, power, some RF comm, etc.). The S/C vendor can choose to structure SORT testing in the way that best fits with their established I&T flow, either as specific milestone test events, as a series of smaller tests that are in-line with their I&T flow, or some combination thereof but must be performed on integrated components.

While the S/C vendor is responsible for organizing and leading the SORTs, formal testing must be conducted out of the operational MOC and executed by the FOT. The FOT will send CMDs and execute procedures under direction of the S/C vendor. The notional schedule for SORT execution will be defined in the procurement package for the MOC RFP, along with the phasing for expected capabilities needed for SORTs. The scope and schedule for the SORTs will be further refined with the S/C vendor as part of a working group led by the NASA Mission Readiness team with the participation of the USGS Ground and MOC teams. The S/C vendor is required to have all SORTs completed by the Observatory Integration Readiness Review. The SORTs will need to be executed from an initial release of the operational MOC environment/framework, thus there will be an initial MOC release for ground readiness testing (GRT) prior to SORTs (this includes the time needed for any pre-test dry-runs). As this is an operational release, formal acceptance and delivery will be required, along with implementation of operational configuration management from this point forward.

The S/C vendor will provide staff at the MOC facility (where the FOT sits) to support SORT execution and provide coordination. The MOC facility will have connectivity to the test voice loop used by the S/C vendor as well as the NASA voice loop (SCAMA/MOVE). The listen-line WAN connection will be used to send CMDs and receive TLM for testing.

4.6 MOC Facilities for Mission Readiness Test Support and Launch Given the MOC architecture is expected to be cloud-based, the FOT can be located where it is most efficient. For L10, FOT staff will not be located on the GSFC campus.

Likely locations are:

USGS EROS in Sioux Falls, SD (preferred location) MOC vendor facility GSFC area in vendor or other government facility

Therefore, the anticipated MOC coverage would look like:

Table 4-1. Notional MOC Coverage for Tests, Launch and Operations

Testing and Simulations Launch/Commissioning Long-Term Operations FOT FOT FOT (ramped down)

- 12 - LSDS-2424

• Realtime Ops

• Flight Systems Lead

• Flight Dynamics

• S/C System Engineering

• Ground System Engineering

• Mission Planning

• Realtime Ops

• Flight Systems Lead

• Flight Dynamics

• S/C System Engineering

• Ground System Engineering

• Mission Planning

• Realtime Ops

• Flight Systems Lead

• Flight Dynamics

• S/C System Engineering

• Ground System Engineering

• Mission Planning

USGS Flight Readiness Manager/Flight Systems Lead

USGS Flight Readiness Manager/Flight Systems Lead

NASA Mission Readiness Manager/Mission Ops Manager and support staff

NASA Mission Readiness Manager/Mission Ops Manager and support staff

S/C Engineering and/or Representatives

S/C Engineering and/or Representatives

SC Ops & Sustainment reach-back

Instrument Engineering and/or Representatives

Instrument Engineering and/or Representatives

Instrument Ops & Sustainment reach-back

Mission Readiness Test Lead and support staff

Mission system engineering staff are also expected to support testing and launch/commissioning, though most of these staff will not need to be located physically close to the MOC (where the FOT sit). To support these staff, a Launch Support Room (LSR) will be set up as a temporary facility, expected to be located at NASA/GSFC. In addition to the LSR, there may be a small number of mission systems engineering staff that may be physically close to the MOC to facilitate real-time coordination during testing and commissioning. A notional diagram is shown below.

Figure 4-3. Notional MOC Facilities

The FOT will be located in the MOC and nearby permanent office space, per the long-term ops profile staffing needs. Instrument and S/C engineering and representatives would be housed in temporary overflow space that is in or physically near the MOC The NASA Mission Readiness staff will also be housed in the temporary overflow space and

- 13 - LSDS-2424

be limited to staff that need close-proximity and interaction with FOT staff. Note that this staffing will change between testing, simulations, launch, and commissioning. Other Mission Readiness staff, including those in the LSR, will connect in remotely to MOC systems and via virtual meetings (e.g. – Microsoft Teams) for coordination.

Limited (very small) number of NASA MSE staff may be located in the temporary overflow space near MOC, with management and other staff not needing direct FOT proximity located in LSR. The LSR may also host S/C and/or instrument staff for coordination with mission system engineering and management.

The MOC vendor will provide application software to run on LSR consoles, which will be provided by NASA (government-furnished equipment, GFE). NASA will also be responsible for setting up network connectivity between the LSR and MOC systems (e.g. – in the cloud).

4.7 Simulators

The S/C vendor will be providing three types of simulators for use in the MOC:

CTSS (CMD and TLM Simulation System) – A moderate-fidelity (S/W) simulator that runs the S/C T&C database to generate simulated TLM and model unencrypted CMD acceptance processing

SoftSIM (S/W S/C Simulator) – A high-fidelity S/W-based simulator of the S/C and Observatory that runs the S/C T&C database and flight S/W (FSW), as well as simulating operations in the space environment. While the instrument (H/W) simulator can be interfaced to the SoftSIM, wideband data flow is modeled and the SoftSIM does not generate simulated wideband data (only T&C operations are simulated).

OOpS (Observatory Operational Simulator) – A high-fidelity simulator for the Observatory that runs the S/C T&C database and FSW and provides flight-like behavior and timing. The OOPS simulates imaging operations using an integrated instrument simulator to generate simulated wideband data that can be processed. The mass storage capacity is lower than flight H/W, and radio frequency (RF) communications H/W is modeled. It is expected that the OOPS will not include encryption H/W, thus commanding to the simulator will be unencrypted.

A diagram of all the simulators being provided by the S/C and instrument vendors for L10 is shown below in figure 4-4.

- 14 - LSDS-2424

Figure 4-4. Landsat 10 Simulators and Users

Simulators will be delivered in a phased sequence to support ground system and MOC development, initially the CTSS, followed by the SoftSIM, then finally the OOpS. The S/C vendor will conduct factory and site acceptance tests of the simulator before delivery to the MOC and after integration. The baseline plan is for the OOpS to be installed at USGS/EROS, but this could be changed to a MOC vendor facility depending upon the specific MOC design implementation and associated efficiencies.

The S/C vendor will be responsible for delivery and installation of the simulators, with support from the MOC vendor and mission readiness and ground systems teams. The simulators are designed to mimic routine S/C operations and interfaces, and a (ground network, GN) CMD and TLM Processor (CTP) will be used to interface the simulators with MOC systems. This mirrors the operational configuration with the MOC talking to the Observatory via GN stations, so no significant configuration or operational changes are expected when using the simulators.

The simulators are designed for efficient remote operations, so physical access is only expected to be necessary for hard reboots of the system and power-cycling. Configuring and executing simulations can be run remotely by the FOT.

The S/C vendor will develop scenarios and configurations for the simulators for use in preparations for S/C and Observatory test activities (including mission readiness activities). The FOT will need to manage operations of the simulators for testing, for both mission-led activities and internal testing (e.g. – use in development or training).

The FOT will also assume primary responsibility for simulators operations following launch and commissioning, including maintenance and systems administration. The S/C and instrument vendors will provide T&C database and FSW updates as needed, and work with the MOC/FOT to install them on the simulators.

- 15 - LSDS-2424

The anticipated simulator usage is as follows:

CTSS – Early MOC development and testing SoftSIM – Testing of MOC releases, validation of ops products and procedures, some validation and dry-run testing for early mission readiness activities, some FOT training

OOpS – Later testing of MOC releases, validation of ops products and procedures, validation and dry-run testing for mission readiness activities, execution of mission simulations and rehearsals, generation of simulated wideband data for ground system testing, FOT training, development or modification of ops products and procedures in long-term operations, simulation of planned operational activities, anomaly investigations and responses

4.8 Mission Readiness Test (MRTs)

The Mission Readiness Tests (MRTs) are Observatory-level end-to-end tests that will be led and executed by NASA MR. These tests cover operations of the full integrated mission capabilities, S/C bus, LandIS instrument, and ground system, and are used to verify end-to-end mission data flows and operations (e.g. – scheduling and acquisition of simulated imagery by the LandIS instrument, transfer of imagery through the S/C RF links to representative ground system H/W and systems, and processing of received imagery to create simulated products). Observatory-level environmental testing is also interleaved with MRT execution

The MOC will be used by the FOT to execute all mission readiness tests under direction of the NASA mission readiness team. The mission readiness team will coordinate with the FOT to develop and dry-run test procedures to achieve test objectives for each specific MRT. The purpose of MRTs is to exercise end-to-end observatory level operations using the operational ground system, as well as to verify level 2 mission requirements. A list of notional MRTs is shown below. The scope, schedule, and duration of the MRTs will be refined through the Mission Readiness Working Group led by the NASA team with support from the SC, Instrument, and all elements of the Ground System team. As per the SC RFP, the SC vendor is required to support 144 hours of test time with the Observatory with additional hours allocated to verify connectivity between the Observatory and MOC prior to each MRT, and the working group will define the total number of MRTs to be executed and how the 144 hours of test time will be distributed across these tests.

- 16 - LSDS-2424

Table 4-2. Notional L10 MRTs

4.9 Mission Simulations (MSIMs)

Mission Simulations (MSIMs)are rehearsals that will exercise operations staff, including FOT and MOC personnel, through various scenarios using the MOC system. The high-fidelity Observatory Operational Simulator (OOpS) is notionally used for mission simulations. The FOT will walk through the various mission phases (S/C and observatory activation, instrument activation, routine imaging, maneuvers, decommissioning, etc.) using the operational procedures and flight products. Critical activities in each phase are executed multiple times in the MSIMs, with anomalies added for subsequent times when they are run. There will be NASA mission readiness staff as well as S/C and instrument representatives present to support the MSIMs. In addition to the formal MSIMs, the MOC and FOT execute internal operational readiness tests and training to develop and maintain proficiency.

Table 4-3. Notional L10 Mission Simulations

- 17 - LSDS-2424

Similar to the SORTs and MRTs, this table describes notional content for the MSIMs, to cover the objectives of FOT training and demonstration of various mission phases.

4.10 Launch Rehearsals

Launch rehearsals are similar to the MSIMs but focused on the one-time activities specifically related to launch. Launch rehearsals primarily involve personnel at the launch site but will include a small subset of MOC personnel. Rehearsals take place after the observatory is moved to the launch site and close to the planned launch date.

There are currently 3 launch rehearsals scoped for L10, one of which will be the final full mission dress rehearsal. The final MSIM will be tied to the mission dress rehearsal such that the rehearsal will lead into MSIM4.

4.11 Launch and Early Orbit (LEO)

During LEO, the FOT will operate MOC systems to send CMDs, but activities will be dictated by the S/C vendor to activate the observatory once it reaches orbit. A direct ascent profile is planned, so L10 will be injected into its nominal orbit, though it is expected that maneuvers will be required to align it to the WRS grid for operations. It is expected that the FOT will be manually operating or closely supervising automated MOC procedures during LEO, as well as executing one-time events that have not been automated (the “crawl” phase for MOC automation). FOT staffing will be 24×7 during LEO and for the first few days afterwards (perhaps up to 1-2 weeks).

The launch vehicle provider generates a series of predicted ephemeris for different launch scenarios to cover potential dispersion of the S/C at separation. The launch vehicle will track the launch and separation to tell the FOT the correct predicted ephemeris set to use (and pass along to the ground stations, as required). Initial activation will be via automated sequencing onboard the S/C and include the nominal first set of contacts. For a VSFB polar launch (south over the Pacific Ocean) the first contact will likely be Svalbard, followed by a North American high-latitude station (Alaska or Canada). Space Network (SN)/Tracking and Data Relay Satellite System (TDRSS) support has been requested for LEO, though this will be dependent upon the status of the assets remaining when L10 is launched in 2031. It is anticipated that there will be longer gaps in coverage between SN and ground station contacts than in previous missions, and the S/C activation sequence will also need to take this into account.

Additionally, it is anticipated that SN/TDRSS will be unable to provide two-way difference Doppler ranging, so ground station angle tracking and possibly radar tracking will likely be required until the GPS system activates and starts providing position, velocity and time (PVT) data. The MOC will need to ingest and process this alternate tracking data until then. External tracking data may also need to be processed by the MOC in the event the GPS data is unavailable or corrupted (i.e. – GPS jamming or spoofing). A more rapid activation sequence for the S/C GPS is planned to mitigate the amount of time external tracking data needs to be ingested and processed by the MOC.

- 18 - LSDS-2424

4.12 In-orbit commissioning

Similar to LEO, activities during on-orbit commissioning will largely be dictated by the S/C and instrument vendor timelines. Notionally the first 30 days of commissioning will be used to activate and check out the S/C bus, and the instrument activation and checkout will start around day 30 (after launch) once instrument outgassing is complete and thermal equilibrium has been achieved. Instrument activation will begin approximately on day 8 to start outgassing, but full instrument activation and checkout will notionally take place over the second 30-day period after launch and culminate in the instrument operating at or near the operational cadence for image acquisition. The remainder of the 100-day commissioning period will include an 18-day normal ops cycle demonstration, as well as a buffer to resolve any issues seen in earlier commissioning activities.

Following LEO and throughout the commissioning phase, it is expected that more of MOC automaton will be enabled to allow FOT staffing to transition to more of a 2-shift posture (the “walk” phase for automation), then (ideally) down to a single shift with the objective of having full lights-out automation in place at the end of commissioning (the “run” phase for automation). The pace of transition to automated operations will be dictated by the maturity of the Observatory and MOC systems.

Figure 4-5. Notional Profile for Transition to Automated Operations

- 19 - LSDS-2424

4.13 Acceptance and Handover Support

To support final in-orbit acceptance and handover of the mission from NASA to the USGS, the FOT and MOC may be asked to generate reports and trending to support verification of mission-level requirements. NASA and the S/C and instrument vendors will be primarily responsible for generating artifacts for acceptance, but the FOT and MOC may be asked to provide data and statistics from MOC systems for use in these artifacts. Additionally, handover will include transition of the ground system (Data Processing and Archive System (DPAS), Ground Network (GN) and MOC) from USGS development to the USGS operations group, and the MOC/FOT will need to support generation of artifacts for this transition activity as well.

- 20 - LSDS-2424

Section 5 MOC Operations

5.1 Routine Operations

The scenarios defined in this section are intended to convey how the various MOC functions interact to execute various tasks within the MOC. MOC functions are being used for these scenarios with the expectation that application suites will be partitioned in subsystems along different boundaries for different vendors, and this ops con attempts to be as agnostic as possible to allow for internal functionality to be defined without artificially imposing specific subsystem definitions on an existing application suite. It is additionally expected that these notional scenarios will need to be revised to map to a specific application suite and internal operations philosophy.

Routine operations consist of a nested series of activities that repeat on different periodicity as follows (all operations to be executed by MOC automation unless specified otherwise):

Pass Activities o Receive retransmit requests from the DPAS (that were received prior to the deadline for the contact), merge them with the CMD stream for the contact, and uplink them o Build CMD loads for the contact o Execute pre-scheduled activities and manual/user commanding o Execute a scheduled GN contact (S-Band or combined S/Ka), including automated handshake with the GN station during pre-pass, transfer of T&C data and statistics/metrics during the contract, and automated post-pass shutdown/clean-up – There will not be any MOC interaction with the station during a Ka-only contact (VTOCs and a post-pass report will be provided for the contact and used by the MOC for internal status updates) o Ingest and assess RT TLM (check for limit violations, state/config check, alert generation, etc.)

o Ingest and process back-orbit stored state-of-health (SSOH/PB) TLM (check for completeness, limit violations, trend TLM, etc.)

o Ingest post-pass report and GN statistics/metrics o Generate standard post-pass reporting and metrics o Update FD/OD state and model, including generation of standard products and reports for Cal/Val, and generation of new ephemeris for GN stations as necessary o Update (“snapshot”) SSR model and configuration/state database, including assessment of S/C onboard planning products (to verify expected behavior or assess variances), as necessary o Synchronize databases as needed for backup/contingency operations, so the most recent record is available in the event of a failover

Daily Activities o Ingest and process any SCRs received before the deadline for the planning period (perform format check, model/deconflict, and load into SCR database, etc.) – it is expected that SCRs will nominally be uploaded only once per week (unless there is an emergency)

- 21 - LSDS-2424

o Plan, model, and build SpCRs as needed (SpCRs are primarily used for cal collects that are time-based or not covered by the LCR or an SCR, but could cover other S/C activities like table updates, etc.) – Also expected that SpCRs will only be uplinked once per day like SCRs and other daily activities o Build plan for real-time commanding, which includes any ad-hoc SCR and SpCR updates; in some cases this may be the “big” stored CMD load and could contain weekly updates, planned maneuvers, S/C maintenance tasks o Take 12-14 passes per day, the specific number is determined by GN station in-view geometry, the need to download all imagery acquired every day, latency considerations for imagery acquired over specific regions (i.e.

– CONUS), and other operational adjustments (e.g. – GN station outages, pattern of past weather-related data losses requiring additional contacts for retransmits, etc.)

Continually assess impacts of GN changes like missed contacts to on-board data storage management, as well as during Contact Rescheduling mentioned later o Review Integrated Onboard Timeline (IOT) and Deconfliction report, and notify FOT of any emergency action needed o Intrusion detection and reporting (PNT/GPS, Commanding, etc.), including Civil Space Interference Reports (CSIR) o Provide GPS/Comm/etc. telemetry to Civil Space and Space Force / Joint Commercial Operations (JCO) / Unified Data Library (UDL) for broader situational awareness o Monitor Cloud system use and costs Weekly Activities o Schedule GN contacts for the next weekly planning period (utilize GN station API or other scheduling interface to schedule and confirm contacts for the next “rolling wave” 28-day planning period, reschedule contacts as needed, generated updated ephemeris as needed, etc.) – There will be a priority list defined for precedence in scheduling GN contacts to provide guidance to the scheduling system to optimize GN schedule for best operational efficiency and cost control, while still scheduling the number of contacts required to download the daily imagery acquisitions and meeting latency requirements over specific regions o Plan, model, and build SpCRs as needed (e.g. – cal collects that happen on a weekly or longer cadence, etc.)

o Orbit analysis (comparison with ground track “science box”, assessment of ACS performance, etc.)

o MOC systems maintenance activities, e.g. – patching and scanning, updates, etc., though these could happen on a less frequent basis (monthly or quarterly) instead

Monthly/Quarterly Activities o These activities happen less frequently than weekly, on a monthly or longer cycle, possibly once per quarter

- 22 - LSDS-2424

o Plan and execute a drag makeup maneuver (DMU), expected monthly ± a few weeks based on space weather influencing the drag environment

DMUs, Risk Mitigation Maneuvers (RMMs), or other propulsive maneuvers may require the MOC to generate an IOT and override the on-board IOT to re-align image collection to WRS-3 if the S/C vendor cannot handle it automatically, since propulsive maneuvers slightly change the orbit o Table loads or updates, possibly over the course of multiple successive contacts due to size (e.g. ACS / Earth Orientation parameters, clock/time parameters, calibration parameters, battery balancing, error and counter clearing) o State Management for Memory - tracking and comparison of ground “gold copy” (e.g. disk image, EEPROM, RAM, etc.) of onboard S/C and LandIS FSW, tables, and parameters; for example, verify CRCs/checksums match; if S/C design allows bulk and quick checksum/version dumps, automate to a more frequent basis

Annual Activities o These activities typically happen once per year or less frequently o Plan and execute a delta-inclination (∆i) maneuver; could occur more frequently to save fuel o Ingest and process an LCR update (this could involve simulating the new

LCR), build the LCR into a scheduled CMD upload and validate the new LCR has been accepted by the S/C and is being used to schedule imaging (verify via S/C scheduling products); Reload any SCRs that are still active (could require some interaction with science office if the new LCR modifies an existing SCR, to assess how to address the impact)

In addition to the periodic activities, there are others that happen asynchronously, as needed (including anomalies and other operational issue mitigations):

Conjunction Assessment and RMMs o This could also be done as a scheduled weekly or daily activity, depending upon the operational space environment that requires proactive assessment instead of a reactive response o Based on a notification from a space situational awareness service, the MOC identifies a High-Interest Event (HIE) to monitor and possibly start planning an RMM (posigrade or retrograde), nominally with a DeltaV from a list of onboard pre-approved magnitudes o If needed, the MOC plans and executes an RMM Contact Rescheduling o On occasion a GN station may need to cancel a scheduled contact o This covers when sufficient notice is given and enough time is available to send an updated ground (network) contact request (GCR) to get a replacement contact schedule scheduled onboard the S/C o The MOC will (re)execute the weekly steps described above to generate and uplink a new GCR and get it scheduled on the S/C in time to cover the contact that was de-scheduled

- 23 - LSDS-2424

Blind-Acquisitions (Ad-hoc Contacts) o Determined by the need to schedule an ad-hoc contact that is not currently scheduled on S/C, thus a blind-acquisition will be required to establish contact with the S/C o Handshake with the GN station could be done using automation (e.g. – using a time-based sequence to execute a “blind-acq” profile at the station) or manually via FOT interaction with the GN station o Once contact is established, the remainder of the activities proceed similarly to a regular contact as described previously

Anomaly Response o It is expected that some (minor) recurring anomalies can be addressed via an automated detection and correction process, though this will be S/C dependent o Other anomalies will, by necessity, be handled via manual processes that will be documented via standard ops/contingency procedures (SOPs/COPs) to capture data…