LNext_MOC_Functions_Summary_1.pdf

LNext Landsat Next

LNext MOC Functions Summary

Version 1.0 February 14, 2025

Purpose This material is intended to provide a high-level summary of the core functions of the

Landsat Next USGS MOC and to clarify terminology.

The functions included here are not intended to be an architecture or even reflect subsystems. USGS recognizes that implementers may refer to these functions using different names and may consolidate or divide functions within subsystems of an architecture in ways not represented here.

The summary is not intended to be comprehensive but rather to highlight the scope boundaries of the LNext MOC and of each defined function.

Multi-satellite Operations Center Functions Telemetry and Command: real time activities, and routine operations Orbit/Flight Dynamics: orbit determination, ephemeris and event generation, and maneuver planning (orbit maintenance) Planning and Scheduling: contact, imaging, calibration, and all special activities to be executed by the Observatory Analytical Modeling: modeling and tools to verify current flight operations concepts and assess potential modifications Simulation: activity validation, anomaly support, training, product updates, etc Trending and Analysis: multi-mission, short-term, and long-term trending Configuration & State Management: manage observatory and ground Contact & Activity Orchestration: Plan, schedule, and manage all activities in support of lights out operations Ground Network (GN) Functions Provide the RF interfaces between the ground and Observatory S-Band interface for command and telemetry, and SSOH Ka-Band interface for the capture of mission data from the Observatory Mission data transfer to Landsat cloud

Data Processing & Archive System Functions Generation of special collection requests, transmission to LMOC Interval assembly and accounting of mission data files received from the GN Ingest of mission data files to produce Level-0 intervals Storing and archiving the data and products (short-term and long-term storage) Level 1 and Level 2 product generation User discovery and access International Cooperator data and products exchange Ground system and science metric gathering and reporting

Ground Segment Architecture Summary

Notional Depiction Only

Mission Operations Center (MOC)

Planning & Scheduling

(P&S)

Monitoring, Trending &

Analysis

Telemetry & Command

(T&C)

Flight Dynamics/

Orbit Operations

(FD/OO)

Situational Awareness

Load Builder/ Generator

Alerts & Notification

Analytical Modeling & Simulators

Configuration Management

& State Management

Contact & Activity

Orchestration

(CAO)

Landsat Next MOC Functions & Interfaces

Other Tools/ Capabilities

External Interfaces

• Ground Network (GN)

• Data Processing & Archive (DPAS)

• Cal/Val

• S/C Vendor

• Instrument Vendor

• Launch Services Segment

• NASA GSFC Services:

• Flight Dynamics Facility (FDF)

• Conjunction Analysis (CARA)

• Near Space Network (NSN)

• US Space Command

• Status Dashboard

• Conjunction Analysis Services

• US Naval Observatory

MOC Interfaces

MOC/GN

T&C – TLM and CMD data exchange via encrypted WAN connection, i.e. – SSL tunnel Scheduling – Interface to each LGN station to pass contact schedules and ephemeris in a single common format for all stations, includes any handshake protocols to confirm receipt and acceptance of scheduled passes (i.e. – API, CFR/CFC/CCS, etc.)

VTOC – S/C mass storage (SSR) directory listing (volume table of contents) of files stored and corresponding file attributes (i.e. – priority, creation date/time, playback status, protected, etc.), nominally via Ka, but dumpable via S-Band on demand (i.e. – for anomalies) Post-Pass Report (GPR) – Listing of files that passed and failed checksum verification (e.g., ACK/NAKs), note this may not include leading partial files that are mission file ID information (and thus cannot be identified by the GNE) Status – Station equipment/systems status for use during pre-pass and pass operations to support MOC automated functions, not expected to allow MOC control of any station equipment/systems Tracking information (i.e. – angle files), for LEOC and contingencies

MOC/DPAS

LOSTT, OSTT SIFMT – Scene to interval mapping table from MOC to DPAS, i.e. – what files are part of a given imaging interval, scheduled acquisitions (from S/C) LCR/SCR – Imaging requests from DPAS to MOC, assume these are initially vetted (by science team) for gross errors and format (also handshake back to DPAS) Retransmit Request – Handshake protocol to receive retransmit requests and verify status of request from S/C Reporting – Provide reporting, metrics and statistics to DPAS for use outside of the MOC secure environment, from MOC to DPAS; Also DPAS statistics back to MOC Scheduling Artifacts – Send contact schedules to DPAS for mission planning (i.e. – data volume management, etc.)

Deconfliction Reports – May be included as part of other interfaces (OSTT, LOSTT, handshakes, etc. from S/C) Definitive Ephemeris and other FD/OD information from MOC to DPAS as needed (i.e. – fuel usage/monitoring, etc.)

Cal/Val Cal Requests – Two-way coordination to support planning of cal/val maneuvers/acquisitions TLM – MOC TLM access to support analysis of instrument performance and scheduling cal/val activities; Does this cover ACS/FD/OD data ?

Science Ops Coordination ? Needed to support observed anomalies in data ? Maybe pass data to DPAS for external distribution ?

MOC Interfaces, cont.

MOC/Externals S/C Vendor EGSE/Facility (“Listen-Line”) – T&C WAN connection to S/C vendor facility to receive copies of all S/C

T&C traffic during I&T, also used for MOC to command S/C (and receive TLM) during MRTs and CTs (also supports connections at launch site) Instrument Vendor – Interface to receive simulator updates and pass operational TLM (and CMD) data for troubleshooting and instrument maintenance (products) S/C Vendor – Interface to receive simulator updates and pass operational TLM (and CMD) data for troubleshooting and S/C maintenance (products) Launch Site Interfaces – Connections to S/C via launch vehicle (facility) for TLM (possibly commanding too) during

I&T NASA/NSN – NASA NSN/NEN station interface for T&C data transfers, scheduling and status, could be multiple interfaces or single NexTEra-type unified interface NASA/SN – NASA SN/TDRSS interface for T&C data transfers, scheduling and status, could be multiple interfaces or single NexTEra-type unified interface, availability of NASA SN resources TBD for long-term ops NASA Commercial SN – T&C data transfers, scheduling and status interface with commercial SN (in-space relay) provider for long-term ops, could be multiple vendors, interface could be unified NASA interface or vendor-specific NASA FDF – Tracking and OD information during commissioning, also for contingencies as needed Conjunction Assessment – Two-way interface with conjunction assessment provider, expected to be NASA CARA during commissioning and transition to a commercial provider for ops Status – High-level MOC (and limited S/C) status, e.g. – web GUI displaying MOC status for approved users (but could also be public-facing) US Space Command (Space Force) – 18th/19th space defense squadron to pass CA information; send TLM to UDL US Naval Observatory – Timing information (e.g. – leap seconds, etc.)

MOC Functions

Telemetry and Command (T&C) Core/Basic/Common Capabilities All standard functions needed to autonomously manage real-time station contacts (pre-pass, pass, post-pass activities), including managing connections with stations and automated failovers as needed Telemetry processing/decommutation/engineering conversion/distributing to MOC subsystems/etc. and

Command processing/assembly/transmission/confirmation/etc.

Automated and user directed contact activities, including procedure execution, load uplink, telemetry limit monitoring, user page/plot display, archive of all activities performed, etc.

Landsat Next specific required capabilities and highlights:

Command and Telemetry Database will be CCSDS XTCE Standard Ability to safely manage contacts with all observatories simultaneously, if needed Ability to split/manage large loads that span multiple contacts Execute mission data retransmit requests provided by DPAS Perform observatory state and configuration checking/monitoring (using received TLM) Command encryption, to potentially include Software command encryption (in the cloud)

Note: Landsat separates Tracking from Telemetry and Commanding (or Command & Control). Landsat used GPS for Orbit Determination, and NASA FDS for Tracking as a backup only.

Desired capabilities (may not be required):

Apply user generated T&C database updates and/or limits (allows for limit/alarm behavior as a function of ops mode, e.g. maneuvers)

Configuration Management & State Management Configuration Management Definition Landsat uses this in the traditional sense – managing all configured items for the ground system, operations, and observatories, and has formal processes and tools for updating and changing them. This includes utilizing common tools like JIRA, Confluence, Sharepoint, Clearquest, or others.

Includes hardware lists/configurations, ground software (MOC, tools, etc.), Mission Operations Configured Items (Command Procedures, SOPs/COPs, Reference Docs, Loads, FSW images, Onboard parameters, etc.)

Key for LNext – with 3 observatories, the ability to manage configurations and configured items through time (e.g. version, date, etc.) and across/between the observatories is critical (i.e. There will be common products, and observatory specific products).

State Management Definition This has sometimes been lumped into CM, but for clarity, this is intended to differentiate the ability to track, manage, and compare the specific states/configurations of the observatories and related ground system components.

Observatory & Ground System State Management

• Monitor, manage, and archive states and configurations for flight H/W, flight S/W, and MOC systems

• Ability for tracking configuration of the observatories and ground system and be able to look back to any point in time to prior configurations.

Memory management, tracking, and comparison of ground “gold copy” (e.g. disk image, EEPROM, RAM, etc.) of onboard FSW, tables, and parameters per satellite and between satellites

Note: Other missions have used "Config Check", "Config Monitor", "State Check" to describe this capability.

Examples include:

• Tracking and checking any onboard parameters (e.g. FSW tables/parameters, load versions, etc.) or states (e.g. Side A "on", onboard process "enabled", etc.) and then logging and taking action based on changes discovered.

• Checking/auditing the same parameters are onboard and in the ground system models (e.g. Earth parameter definitions for onboard ACS and ground Flight Dynamics models, etc.).

• Confirming pre-anomaly and post-anomaly observatory configurations match (i.e. to confirm full anomaly recovery).

Desired Capabilities (may not be required):

Digital twin

Monitoring, Trending & Analysis Core/Basic/Common Capabilities:

Process and Store ground and observatory housekeeping (health and status) telemetry and provide a full suite of trending and analysis tools on all required timescales (near-real time, periodic, long term, and life of mission) Automated statistics and plot/table/report generation for traditional daily, weekly, monthly, quarterly, yearly, and LOM, and user initiated on-demand and custom generation Landsat Next specific required capabilities and highlights:

Managing, tracking, and reporting key performance parameters of the spacecraft, instruments, and ground system for the life of the mission, including trends and margins Managing key life limiting budgets (e.g. power, fuel, rotational components, etc.), including predictions of failure Life of mission performance tracking, performance comparison, and reporting per satellite and between satellites Remote access for engineering & Cal/Val teams to support T&A and anomaly resolution Store data in a format and data structure to facilitate ML and other automated analysis tools (i.e. “analysis-ready data”) Execute automated analysis tools (i.e. AI/ML) to monitor large amounts of telemetry points of LNext constellation for anomaly identification at a minimum

• AI/ML capability is growing and changing rapidly, so requirements shouldn't be tied to specific current implementations, but be as future proof as possible (i.e. “analysis-ready data” vs. specific ML algorithms) Desired capabilities (may not be required):

Provide read-only access to TLM Database for Data Processing Facility (i.e. cal/val, science, DPAS) for data analysis

Clearly identify what data is export controlled

Flight Dynamics / Orbit Operations (FD/OO) Core/Basic/Common Capabilities:

Orbit Determination: Use S/C GNSS telemetry to create definitive orbit; Ingest external tracking data as needed (i.e. NASA FDF, commercial tracking services, angle tracking data from GN stations, etc.) for backup orbit determination capability Orbit Propagation: Generate and provide ephemeris for all ground and operational needs Orbit and Maneuver Planning

• Assess adherence to orbit and mission parameters (ground track, inclination, constellation spacing, drag monitoring, fuel management, etc.)

• Generate and assess (validate) ephemeris and maneuver plans as needed for orbit maintenance, mission safety (i.e.

RMMs), and one-time and special events in cooperation with S/C vendor and mission engineering (i.e. LEO, constellation respacing, EOL deorbit, etc.)

Landsat Next specific required capabilities and highlights:

Generate, Maintain, and Deliver definitive ephemeris (historical), and other relevant mission parameter to DPAS as needed (TBD) Event Generation: Generate orbital events for GS use (contact in views for scheduling, sun/eclipse, moon angles and times for calibration, descending node crossing, solar calibration angles, etc.)

Flight Dynamics

• Perform attitude and ACS performance monitoring and management (if not done by T&A) - (e.g. MTASS on L8/L9)

• Attitude Slew planning (e.g. ACS or Science Calibration, maneuver slews, etc.) and keep out zone monitoring (Sun in sensor

FOV, Sun/Earth in Radiator FOV, etc.)

Interface with external conjunction assessment (CA) services (i.e. NASA CARA, SpaceNav, etc.) for space situational awareness and coordination of risk mitigation maneuver (RMM) planning (and execution) Desired capabilities (may not be required):

More dynamic drag model – above standard drag model – things like solar weather induced changes, dynamic models, etc.

Planning and Scheduling Core/Basic/Common Capabilities:

Ground network (GN) and In-Space Relay (e.g. TDRSS or similar) contact planning, scheduling, deconfliction, etc.

Routine observatory activity planning, deconfliction, constraint checking, and validation

• Includes contact activities, Cal/Val activities, attitude and propulsive maneuvers, engineering requests, routine maintenance, etc.

Creates activity schedule for load builder/generator Landsat Next specific required capabilities and highlights:

Maintain the ground imaging plan and schedule (defined in the LCR, and modified by any active SCRs) Predict observatory mass storage device usage and schedule necessary ground contacts to downlink expected science data, including adding new contacts if needed (due to missed downlink, or other issue)

• Note: this could be a function of the analytical model that is used as input for contact and schedule updates.

Ingest, validate, and deconflict SCRs and LCRs received from DPAS Validate each observatory provided imaging plan (the 18-day onboard WRS-3 scene (Path/Row) plan) against the LCR/SCRs Autonomously review and validate the observatory provided 24 hour (TBD) integrated onboard timeline (IOT) and notify engineering of any issues, errors, or unexpected results Optimization of GN contact schedules while still meeting contact time requirements Desired capabilities (may not be required):

Contact and Activity Orchestration (CAO) Description / LNext specific capabilities and functions:

Plan, schedule, and manage all routine contact activities (i.e. What activities and commanding will occur on which contact) Facilitate review, approval, and execution of engineering approved activities (e.g. command authorization meeting approves commanding for upcoming activity, activity sequence generated, reviewed by engineering team, approved, and scheduled for execution on upcoming contact) Accept and validate automated retransmit requests from DPAS, convert to CMD sequence for U/L to S/C, schedule execution of commanding Monitor status (contents) of onboard mass-storage system, and estimate mass-storage usage (predict usage based on scheduled imaging, update to “known truth” as VTOCs are received) could be part of analytical modeling

Note: This can be done in other MOC systems or mission enabling tools or similar. Mission Planning/Scheduling, Load Builder/Generator, T&C, Mission Management system, JIRA, Pass Plan Tools, Timeline/Activity Tools, etc.

Note: On L9, this was/is done in custom tools, Mercury (load review, approval, distribution), JIRA/Mission Operations

Timeline Execution (MOTE) (pass plan activity management, procedure review, etc.), and the LEOC timeline tool (no longer used)

Load Builder/Generator Description / LNext specific capabilities and functions:

Takes activity schedule created by Planning & Scheduling converts activity sequences into CMD loads

(ASCII to binary) for U/L to the S/C (formatting for U/L and use by the S/C) Load checking and validation (independent review, with configurable modules for new signatures discovered during mission life to check against).

Segments loads into smaller chunks appropriate for command upload windows and creates ability to load large loads over multiple contacts

Note: These functions could be separate tools or part of another function (i.e. T&C, CAO, or planning & scheduling).

Analytical Modeling and Simulators Description / LNext specific capabilities and functions:

Provides modeling and tools to verify current and assess potential modifications to flight operations concepts, including assessing impacts of GN and imaging changes

• e.g. Evaluate a request for a new night collection, or a change to the LCR, or a loss/addition of a new ground station Operation, configuration and maintenance of simulators provided by S/C vendor (in cooperation with S/C vendor) Operation, configuration and maintenance for simulators provided by MOC vendor (i.e. digital twin, etc.)

Interface simulators provided by S/C vendor with MOC systems (i.e. T&C and status/control interfaces, etc.)

Execute simulations for testing, training, CMD planning, anomaly investigations, or other engineering activities

(i.e. what-ifs, etc.)

Model “what-if” scenarios for different parameters in image scheduling, GN station distribution, etc.

Develop and maintain a model of S/C mass storage operation and file system usage could be part of CAO

Note: These functions could be separate tools or part of another function (i.e. T&C, CAO, or mission planning).

Alerts and Notifications Description / LNext specific capabilities and functions:

Delivers messages from MOC applications/subsystems/functions to external systems and operations staff, utilizing configurable settings Messages could be machine to machine communication (e.g. post outage status to website, send partner system at LGN a message via API, etc.) or external alerts to staff via E-mail, SMS text, voice calls, etc.

Populate, display and update (manage) mission “dashboard” status display Could be part of Situational

Awareness

Desired Capabilities (may not be required):

Track notification times and response times for metric gathering and escalation (e.g. notification not responded to within 30 minutes, so send to next level recipient)

Situational Awareness Description / LNext specific capabilities and functions:

Observability of overall status of constellation, MOC & Ground System health monitoring, metrics Centralized access system Dashboard that includes status of MOC system, Ground System health monitoring and observatory health monitoring, also trending and monitoring Can easily dig into details from dashboard; drive down into the subsystems underneath status to troubleshoot Configurable dashboard by FOT based on needs

Desired Capabilities (may not be required):

Customizable dashboard with ability to integrate external tools. Examples include tools for near-term forecasts for space weather (from NOAA or Space Force), Space Weather anomaly assessment tools, CA reports/dashboard, drag models, RF interference (from Space Force)

Other Capabilities o Infrastructure - MOC IT Environment o Manage infrastructure and environment (e.g. cloud, infrastructure as code (IaC), containerization, etc.)

o Still Determining the Responsibilities of USGS Cloud Hosting Solutions Provided Govcloud vs MOC Vendor o Support IT security and patching o Support and maintain tools o Supports MOC Data Management for optimized data storage in a way that enables future data analysis tools (see Trending & Analysis) o Incident Management Tool & Process o Internal MOC system development tool – MOC dev vendor o Note: Project will select the tool for GRTs, MRTs, etc, ops product development o Operational incident management. Work with the Government to define tool and process.

o Software Patching & Deployment o Rapid Deployment o Automated testing in I&T – standard automated regression testing o Security Scanning & Patching Management and SCRM/Threat Management o Ground security council – establish security agreement for patching ground hardware/software o Ability to easily revert back o Periodic checks against known bad actor lists throughout life to confirm existing HW and SW hasn't been compromised (sold to a banned vendor/country or become a known unsecure vendor, etc.)

o Collaboration Tools o Can handle multi-agency CUI, ITAR data, meets security guidelines