LSDS-2388_(Draft)_L10_MOC_L4_Requirements_Nov_2026_1.pdf

LSDS-2388

Version .9

Department of the Interior U.S. Geological Survey

Landsat 10 (L10) Mission Operations Center Requirements Document (MOCRD)

November 2026

DRAFT

- ii - LSDS-2388

Landsat 10 (L10) Mission Operations Center Requirements Document (MOCRD)

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-2388

Executive Summary

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 contains the level-4 (L4) requirements for the Landsat 10 (L10) Mission Operations Center (MOC). Requirements are based on the scenarios described in the MOC Synopsis, LSDS-2424.

- iv - LSDS-2388

Document History

Document Number

Document Version

Publication Date

Change Number

LSDS-2388 .9 November 2026 –

ID Requirement Rationale Driving

The MOC shall provide a backup capability

Changing from specifically calling out a "bMOC" to both match SMRD language and to acknowledge that a specific bMOC facility may not be required in a cloud-based architecture

Yes

The MOC shall have an availability of 99.9% for telemetry and command functions

Trace to GSRD 4787 Allocation:

The GS must have a highly available observatory communication link to ensure observatory health & safety detection and response. Allocation: GNE - 99.9%; MOC - 99.9%; Network - 99.9%.

Yes

The MOC shall restore component functionality within 48 hours of a detected failure

Continuity of Operations (COO) and backup capability failover. A component is defined as any item in the signal path or supporting the transmission of a signal that prevents proper operation of the MOC, e.g. - a H/W encrypter box, network router, non-redundant power supply, etc.

Trace to GSRD 23689

Yes

The MOC shall have an availability of 98.5% for non-telemetry and commanding mission operations functions

Trace to GSRD 22439 Rationale:

Mission-supporting functions in the MOC must be highly available, but are not subject to the strictness necessary for telemetry and command functions.

Examples of these functions include mission planning, flight dynamics, offline trending and

Yes

The MOC shall have a backup capability to support continuity of operations in the event the (primary) MOC systems cannot support operations

Trace to GSRD 4808: The GS shall have a bMOC that can be activated and maintain full mission operations within 24 hours of the decision to activate the bLMOC.

Yes

The backup MOC capability shall execute observatory health and safety and science data collection activities for a minimum of 30 consecutive days.

This defines storage and other resource sizing needed to support backup operations Trace to GSRD 4809

Yes

The MOC shall backup operational systems, system configurations, software installations and databases

Trace to GSRD 4810

The MOC shall have the ability to restore system functionality from the backup data and documentation

Trace to GSRD 22441

The MOC shall support remote operations

Allow of FOT to log into MOC for monitoring and execution of permitted operations

Yes

General Requirements

The MOC shall operate under automation control

"Lights Out" or "Lights Dim" automated execution of MOC functions with management and monitoring by

FOT

Trace to GSRD 4796: The GS shall operate autonomously for up to 72 consecutive hours under nominal operations

Yes

The MOC shall allow manual operation of functions and subsystems

Allows FOT to manually operate some or all MOC systems as needed for testing, training, contingencies or commissioning operations

Yes

The MOC shall support a minimum of 15 years of on-orbit operations

Trace to GSRD 4778 Yes

The MOC shall use the Coordinated Universal Time (UTC) for all ground operations and data products

Trace to GSRD 4775

The MOC shall employ security controls of NIST PUB 800-53 Rev 5 moderate level system in accordance with corresponding USGS guidance

Trace to GSRD 4791 Rationale:

DOI USGS Institutional requirement for the protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction. This includes both physical and information security. The USGS creates security controls from NIST PUB 800-53 Rev 5, the USGS then provides instruction/guidance to satisfy the control.

Yes

The MOC shall control specified information per International Traffic in Arms Regulations (ITAR) Title 22 CFR 120-130

Some S/C and instrument information and artifacts will be subject to ITAR. Note that this may limit access to information and artifacts for staff.

The MOC shall control specified information per Export Administration Regulations (EAR) Title 15 CFR Parts 730-799

Some S/C and instrument information and artifacts will be subject to EAR

The MOC shall control Controlled Unclassified Information (CUI) in accordance with NIST SP 800-171 &

NPR 2810.7

Some MOC documentation, artifacts, and system configuration information (e.g. - network details, etc.)

are CUI and need to be handled accordingly

All interfaces between the MOC and external systems shall 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 FISMA Moderate system

These are institutional security requirements for a FISMA moderate system. The implementation will need to account for the additional overhead of running security protocols and scanning, without impacts to normal MOC functionality or performance. Yes

Compute resources margins shall take into account overhead associated with IT and network security protocols and scanning, for a FISMA Moderate system

IT/Network security overhead needs to be included when calculating system margins to ensure proper analysis of performance in a realistic operational environment

Yes

The MOC shall use SI (Système international d'unités) units

Required to maintain consistency with the S/C, instrument, and ground system

The MOC shall allow servicing, maintenance, or training while still meeting system requirements and specifications

This allows for system sustainment without the need to take the system offline, as well as the ability to conduct training without impacting routine operations

The MOC shall allow user-configuration of tools and functions

Avoid the need for a new patch/release. Allow users to make updates as needs arise and change, e.g.

telemetry limits; load checking and validation, constraint checking; alert persistence, threshold, priority; dashboard configuration.

The MOC shall generate the Long-term Observatory Time-translation Table (LOSTT) beyond the onboard image schedule The MOC shall provide the long-term observatory schedule time-translation table (LOSTT) to the DPAS in accordance with the DPAS-MOC ICD.

The DPAS/MOC ICD documents the format and protocols for product and information exchanges

The MOC shall provide the observatory schedule time-translation table (OSTT) to the DPAS in accordance with the

DPAS-MOC ICD

The DPAS/MOC ICD documents the format and protocols for product and information exchanges

The MOC shall provide the WRS-3 Time- Translation Table (WRS3TT) to the DPAS in accordance with the DPAS-

MOC ICD

Trace to GSRD 5003 The DPAS/MOC ICD documents the format and protocols for product and information exchanges

The MOC shall receive the LTAP Collection Request (LCR) from the DPAS in accordance with the DPAS-

MOC ICD

Trace to GSRD 4997 The DPAS/MOC ICD documents the format and protocols for product and information exchanges

Yes

The MOC shall receive Special Collection Requests (SCR) from the DPAS in accordance with the DPAS-

MOC ICD

Trace to GSRD 4999 The DPAS/MOC ICD documents the format and protocols for product and information exchanges

Yes

The MOC shall receive retransmit requests from the DPAS in accordance with the DPAS-MOC ICD

The DPAS/MOC ICD documents the format and protocols for product and information exchanges Yes

Interface Requirements (from GSRD L3 Requirements and N²)

The MOC shall provide the Imaging Deconfliction Report to the DPAS in accordance with the DPAS-MOC ICD

The DPAS/MOC ICD documents the format and protocols for product and information exchanges

The MOC shall provide Definitive Ephemeris (DE) to the DPAS in accordance with the DPAS-MOC ICD

The DPAS/MOC ICD documents the format and protocols for product and information exchanges

The MOC shall provide the Station Contacts Execution Summary (SCES) to the DPAS in accordance with the DPAS-

MOC ICD

Trace to GSRD 7604 The DPAS/MOC ICD documents the format and protocols for product and information exchanges

The MOC shall provide LGN contact schedules to the DPAS in accordance with the DPAS-MOC ICD The MOC shall received TLM information requests from the Cal/Val team The MOC shall provide TLM to the Cal/Val team

The MOC shall coordinate scheduling of passes with GN stations

Trace to GSRD 4977 Use of an API or equivalent interface to request and confirm contact windows with GN stations (USGS, IC partner-operated or commercial). The GN/MOC ICD documents the format and protocols for station coordination.

Yes

The MOC shall receive station availability information from GN stations in accordance with the GN-MOC ICD

Used for MOC planning to determine candidate stations to consider for pass scheduling. The GN/MOC ICD documents the format and protocols for station coordination.

The MOC shall coordinate scheduling of passes with NASA NSN stations

Trace to GSRD 5036 Use of a TBD interface to request and confirm contact windows with NSN stations (commercial or NASA-operated)

Yes

The MOC shall coordinate scheduling of passes with the NASA SN stations

Trace to GSRD 5034 Use of SNAS TBD to schedule SN/TDRSS contacts (expected only to be used during LEOC)

Yes

The MOC shall generate ephemeris for passes with GN stations

Trace to GSRD 4978 Expected to be TLEs TBD

The MOC shall generate ephemeris for passes with NASA NSN stations

Expected to be TLEs TBD

The MOC shall generate ephemeris for passes with the NASA SN (NSN Space Relay)

Trace to GSRD 5033 Expected to be IIRV

The MOC shall provide commands to the Observatory (via S-band using GN and NSN stations) in accordance with the SC-GND ICD

Trace to GSRD 5015, 4979 The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption.

This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together)

Yes

The MOC shall receive telemetry from the Observatory (via S-band using GN stations) in accordance with the SC-

GND ICD

Trace to GSRD 5016, 4980 The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption.

This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together)

Yes

The MOC shall receive telemetry from the Observatory (via S-band using NASA NSN stations) in accordance with the SC-

GND ICD

Trace to GSRD 5037 The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption.

This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together)

Yes

The MOC shall provide commands to the Observatory via hardline interface in accordance with the SC-GND ICD

Trace to GSRD 5048 Support for CTs, SORTs and MRTs, as well as potentially RF compat testing. The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption. This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via the listen-line WAN connection.

Yes

The MOC shall interface with the S/C vendor facility for listen-line T&C communications with the S/C during S/C and Obs I&T activities

Trace to GSRD 4943 This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via the listen-line WAN connection.

Yes

The MOC shall interface with the payload processing facility for listen-line T&C communications with the S/C during payload processing

Trace to GSRD 4944 This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via the listen-line WAN connection.

Yes

The MOC shall receive telemetry from the Observatory via hardline interface in accordance with the SC-GND ICD

Trace to GSRD 5049 Support for CTs, SORTs and MRTs, as well as potentially RF compat testing. The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption. This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via the listen-line WAN connection.

Yes

The MOC shall provide commands to the Simulator via hardline interface in accordance with the SC-GND ICD

Trace to GSRD 5015 Support for GRTs, SIMs and other testing and training. The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption. This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via a LAN connection.

Yes

The MOC shall receive telemetry from the Simulator via hardline interface in accordance with the SC-GND ICD

Trace to GSRD 5016 Support for GRTs, SIMs and other testing and training. The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption. This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via a LAN connection.

Yes

The MOC shall provide commands to the NASA NSN Space Relay for TDRS (SN) in accordance with the SC-GND

ICD

Trace to GSRD 5032 The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption.

This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via a LAN connection.

Yes

The MOC shall receive telemetry from the NASA SN in accordance with the SC-

GND ICD

Trace to GSRD 5035 The Space-to-Ground ICD documents the format of T&C data, as well as protocols and CMD encryption.

This is expected to be TCP/IP encapsulated T&C data in streaming raw CADU format with VC63 fill removed but without VC separation (i.e. - still muxed together) via a LAN connection.

The MOC shall provide Radio Frequency Interference (RFI) orbit products to the FDF in accordance with the MOC-FDF

MOA

Trace to GSRD 5024 NASA FDF will used during LEO.

To account for underfly of L8 and L9, and RFI of any other S/C, e.g. Sentinel

The MOC shall provide orbit maneuver plans to the FDF in accordance with the

MOC-FDF MOA

Trace to GSRD 5025 NASA FDF will used during LEO

The MOC shall receive orbit products from the FDF in accordance with MOC-

FDF MOA

Trace to GSRD 5026 NASA FDF will used during LEO Yes

The MOC shall receive NASA Near Earth Relay Services (SN/TDRSS) ephemeris data from the FDF in accordance with the MOC-FDF MOA

Trace to GSRD 33256 NASA FDF will used during LEO. The ephemeris will allow the MOC to calculate the location of SN/TDRSS assets for contact planning and scheduling.

The MOC shall receive space environmental files from the FDF in accordance with the MOC-FDF MOA

Trace to GSRD 33257

The MOC shall provide orbit maneuver plans to the NASA Services (TBD) in accordance with the TBD ICD

Trace to GSRD 5028 NASA services (e.g. - CARA, etc.) will be used during LEOC and may also be used during contingencies in long-term operations

The MOC shall provide orbit products to the NASA Services (TBD) in accordance with the TBD ICD

Trace to GSRD 5030 NASA services (e.g. - CARA, etc.) will be used during LEOC and may also be used during contingencies in long-term operations

The MOC shall provide orbit maneuver plans to an external SSA Services (TBD) in accordance with the TBD (agreement or SLA)

It is expected that a SSA services provider will be used in long-term operations

Yes

The MOC shall provide orbit products to an external SSA Services (TBD) in accordance with the TBD (agreement or

SLA)

It is expected that a SSA services provider will be used in long-term operations

Yes

The MOC shall receive observatory flight software updates from the Spacecraft Vendor

Trace to GSRD 5051 Used both to update simulator FSW and to receive updates to uploaded to the S/C

The MOC shall receive observatory ground reference image data from the Spacecraft Vendor

Trace to GSRD 5053

The MOC shall receive telemetry and command definitions from the Spacecraft Vendor

Trace to GSRD 22458 Used both to update simulator and to support T&C operations with the S/C

Yes

The MOC shall receive time-based command requests from the Spacecraft Vendor

Used to support S/C vendor generated SpCRs in support of testing or troubleshooting (anomaly activities)

The MOC shall provide supplementary data to the Spacecraft Vendor

Used in support of anomaly investigations and other routine activities needed for S/C vendor support in operations

Yes

The MOC shall receive supplementary data from the Spacecraft Vendor

In support of anomaly investigations and other routine activities needed for S/C vendor support in operations

The MOC shall receive Earth Orientation Parameters from the United States Naval Observatory (USNO).

Trace to GSRD 5072

The MOC shall provide stored housekeeping telemetry data to the LandIS Vendor

Used in support of anomaly investigations and other routine activities needed for instrument vendor support in operations

Yes

The MOC shall provide supplementary data to the LandIS Vendor

Used in support of anomaly investigations and other routine activities needed for S/C vendor support in operations

Yes

The MOC shall receive time-based command requests from the LandIS Vendor

Used to support instrument vendor generated SpCRs in support of testing or troubleshooting (anomaly activities)

Yes

The MOC shall provide orbit products to Space Force

Support for space situational awareness and conjunction assessment and mitigation

The MOC shall provide TLM to Space Force

Support for space situational awareness and conjunction assessment and mitigation

The MOC shall receive volume table of contents (VTOC) from GN stations in accordance with the GN-MOC ICD

The VTOC provides a "snapshot" listing of files currently on Obs mass storage. A VTOC can also be dumped via S-Band upon CMD by the MOC. The GN/MOC ICD documents the format and protocols for station coordination.

Yes

The MOC shall provide anomaly information to the Anomaly Catalog (TBD) in accordance with the ICD (TBD).

The MOC shall receive anomaly information from the DPAS for use in populating the Anomaly Catalog (TBD) in accordance with the ICD (TBD)

Presume formats and protocols are documented in

DPAS/MOC ICD.

The MOC shall provide expedited response of operations during anomaly investigation

The MOC shall generate Obs attitude and line-of-sight geometry products for use in calibration and validation

Products such as definitive ephemeris and definitive attitude and other ACS, Obs attitude and line-of-sight geometry products and data are required for calibration/validation of the LANDIS instrument

Yes

Cloud Hosting

The MOC shall use GovCloud or equivalent secure, approved public cloud services that are authorized at FedRAMP Class C (or higher), for any cloud-hosted systems

Required to support handling CUI/ITAR-restricted material, specifically T&C database and CMD encryption, but possibly other information such as some LANDIS parameters and documentation, etc. A pre-approved USGS/DOI GFE environment could be used or a specific FedRAMP approval is required for a vendor-approved environment (the vendor will need to certify their environment, they cannot pass-through an environment provisioned by a third party)

Yes

The MOC shall only use services provided by CHS III if the MOC is hosted in a CHS III-provisioned cloud environment

If using a CHS III-provisioned (provided) cloud hosting environment, all services used must be provided by the CHS III team, vendors will not be allowed to install their own services or tools. Note that a GovCloud or equivalent secure environment may not provide all services or tools available in the general public cloud.

The MOC shall plan S-Band and Ka- Band contacts to occur simultaneously or standalone

Could be single-service contacts (S or Ka only) or dual/full service with both S and Ka

The MOC shall model contacts and sequencing, as necessary, to generate a schedule to meet operational needs

If needed, the MOC will use modeling to select optimal set of contacts to meet operational requirements, considering factors such as contact cost, availability of station (how likely is it that you can schedule a contact there), GN station constraints, contact duration, etc.

Yes

The MOC shall schedule GN and NSN (and SN) contacts, as defined in the GN/MOC ICD or TBS ICD

Use protocol defined in the ICD to schedule and confirm contacts with stations or the SN; Includes handshake process to request and confirm contacts, or SNAS terminal scheduling and confirmation handshake

Yes

The MOC shall partition CMD loads as needed to fit into multiple contacts

If a CMD load is too large for a single contact (could vary based on the max elevation angle of the contact planned for the upload), the MOC will need assess time needed for the upload and compare it with the expected CMD contact time, and split the CMD load into two or more uploads to fit into the available CMD contact time windows

Planning and Scheduling

The MOC shall assess CMD upload times to determine if CMD loads will need to span more than one contact

Based on scheduled activities and CMD upload size, and expected CMD upload time window(s) for scheduled contacts; Includes incorporation of timing for planned activities in the contact being modeled

The MOC shall coordinate confirmation of contacts with GN and NSN stations (and the SN)

Confirm start (AOS) and stop (LOS) times for the contact, and that the station will be scheduling the contact to be taken; Confirmation via an API or other handshake process

Yes

The MOC shall schedule the upload of a Ground Contact Request (GCR) into a specific contact

Ensures that S/C has sufficient time to ingest and process a GN contact request before the contact is scheduled to take place

The MOC shall validate S/C execution of ground inputs

Check the update automated planning product to ensure the ground input was properly processed by the S/C and correctly incorporated as expected into automated onboard mission plans, e.g. - check to see that a new contact requested by a GCR upload was added to the CAS and GDAL

Yes

The MOC shall support validation of ground inputs across multiple contacts

MOC may need to wait until a subsequent contact to receive and validate an updated S/C product, if it takes longer than the initial scheduled contact for the S/C to process the ground input and generate an updated automated planning product

Yes

The MOC shall ingest retransmit requests received from the DPAS

Yes

The MOC shall manage SCRs

Trace to GSRD 4839: The GS shall generate and maintain the status of all image data collection requests The MOC needs to use effectivity dates to determine which SCRs need to be deleted off the S/C after their period expires, as well as when to upload SCRs before an upcoming effectivity window. The DPAS could send SCRs to the MOC for active periods far in advance of the current date. There can also be SCRs that are for periodic activities (i.e. - fall cal/val collect, etc.) that need to be loaded and deleted as necessary. The S/C has a fixed number of SCRs that can be loaded onboard, so the MOC will need to manage SCRs to ensure this constraint is followed.

Keep track of effectivity windows of SCRs to determine when to U/L and when to delete off S/C when the expire, as well as determining if any SCRs overlap to flag back to DPAS/science; Also re-entering desired SCRs when a new LCR is uploaded

YesDRAFT

The MOC shall maintain a record of SCRs

Trace to GSRD 4839: The GS shall generate and maintain the status of all image data collection requests.

The MOC needs to keep a record of past, current, and future/planned SCRs, both to manage effectivities onboard the S/C, as well as for the historical record since the DPAS will not be maintaining a database of SCRs that have been submitted.

Also used for re-entering desired SCRs when a new LCR is uploaded.

The MOC shall regenerate and deconflict all Special Collection Requests when generating a new LTAP Collection Request (LCR)

The MOC will need to (re)load all SCRs that are still within their effectivity window when a new LCR is uploaded since it will overwrite all current LCR/SCR directives in the onboard mission planning system

Yes

The MOC shall perform format check and validation of incoming LCRs, SCRs or Retransmit Requests, informing DPAS if there is a format error per the

DPAS/MOC ICD.

Simple format check to ensure it is a valid request.

Reject any requests that fail the format check back to the DPAS. Presumes DAM checks science rationale before SCRs are submitted.

Yes

The MOC shall provide the DPAS with status regarding SCRs, LCRs, or retransmit request reception by the S/C

Confirmation, or an error message if CMD fails and request or upload is not accepted (processed) by the S/C.

Note - Assumes that action by the S/C to D/L the file may happen quicker than commanding a VTOC dump to show a file PB flag status change, as a confirmation to be sent to the DPAS. This provides inputs to DPAS for generation of routine reporting for imaging activities (e.g. - was SCR activated and executed, etc.)

The MOC shall schedule alternate tracking sources, when needed

Covers scheduling GN and NSN stations to also capture antenna angle data during a contact, as well as scheduling a direct tracking service (such as radar or optical tracking)

Yes

The MOC shall provide orbit determination, ephemeris, and other flight dynamics products to external users

For GN and NSN stations (also SN), and other users needing flight dynamics products, i.e. - DPAS, Cal/Val team, alternate tracking service, etc.

The MOC shall perform an impact assessment on the incoming SCR to identify any conflicts with active SCRs or SpCRs

SpCRs will override SCR action, S/C will reject an uploaded SCR when a SpCR is scheduled.

Expect that DAM will not submit any SCRs for acquisitions already covered by LCR.

The MOC shall reject an SCR if conflicts with active SCRs or SpCRs are unresolvable

The MOC shall update the WRS-3-based Ground Imaging Plan for an approved SCR or LCR update

Yes

The MOC shall receive confirmation from observatory on the successful upload of LCR/SCR.

Yes

The MOC shall notify DPAS on the successful upload of LCR/SCR per

DPAS/MOC ICD.

Yes

The MOC shall validate IOT and Imaging plan from observatory after the successful ingest of LCR/SCR.

Yes

The MOC shall validate IOT and Imaging plan from observatory within 4 hours following the successful ingest of

LCR/SCR

Yes

The MOC shall support insertion of unplanned (ad-hoc) contacts into the current schedule of contact activities

Inserting an ad-hoc (extra) contact in between other planned contact activities, typically due to an emergency or contingency. The contact is expected to be a blind acquisition since there won't be an opportunity to uplink a new GCR containing the contact.

Yes

The MOC shall define objectives and activities for each pass (contact)

Define what CMDs are to be uploaded, what other commanding activities need to take place, and any other S/C activities. This includes calculation of timing for CMDs and activity execution to ensure they can be done in the planned contact window.

Yes

The MOC shall confirm GN station contacts within 15 min TBR

Supports the ability to schedule a contact in sufficient time to meet the emergency/contingency turnaround requirement. Timeline for GN station contact scheduling is defined in the GN/MOC ICD.

Yes

The MOC shall schedule ground station contacts within 60 minutes, in support of a S/C emergency

Applies to both GN and NSN contacts Yes

The MOC shall schedule NASA S-Band services contacts within 60 minutes, in support of a S/C emergency

Applies to both direct-to-earth (DTE) and space-relay services Yes

The MOC shall use station-provided horizon mask values to calculate contact times, per the GN/MOC ICD.

For both planning and confirmed contacts

The MOC shall translate pass objectives and activities into a CMD sequence

Yes

The MOC shall maintain a margin of 20% TBD for CMD upload timing in order to allow uplink of RT CMDs during a pass

This margin allows time to send RT CMDs while providing a time allocation when calculating the timing to assess if a CMD load needs to be split

Yes

The MOC shall utilize prioritization when sequencing activities and CMDs in a CMD upload

Ensure CMDs like mission data file retransmits get sent, etc.

Expect that prioritization scheme will be further defined in lower-level requirements.

Yes

The MOC shall receive maneuver parameters from Flight Dynamics and plan the maneuver accordingly.

Flight Dynamics parameters will need to be incorporated into command parameters for execution on the Observatory. E.g. via Planning & Scheduling function.

The MOC shall deconflict imaging and non-imaging observatory activities

Trace to GSRD 4843 The MOC will need to deconflict activities that impact each other and generate a report that contains all of the impacted image acquisitions.

Yes

The MOC shall generate a report for all imaging acquisition that are disrupted by other Observatory activities

Trace to GSRD 22443 Yes

The MOC shall plan a Risk Mitigation Maneuver (RMM) to occur for the HIE at a time that allows the HIE to be avoided and also allows for further monitoring.

The planned maneuver time ideally needs to be far enough in the future that further updates and more up to date orbit tracking can occur so that unnecessary maneuvers can be avoided

Yes

The MOC shall plan an RMM within 6 TBR hours

This allows the RMM to be planned in sufficient time to mitigate the risk. Per current flight operations policies, the value shown is for a fastest-possible RMM response, while a normal RMM response time is 12+ hours. Waiting for screening results with a Space Situational Awareness (SSA) provider may be the limiting factor, which increases planning time.

The MOC shall produce calibration event files specifying the times various calibration opportunities exist.

To support the various calibrations needed to maintain the observatory, the times that these calibration activities may occur need to be known in order to properly schedule them. These include, but are not limited to Solar, Lunar, and partial off-nadir collects (off nadir collections that are not exactly one path away from the current path)

Yes

The MOC shall provide the calibration opportunity event times to the CALVAL Team.

The CALVAL team will utilize the MOC interface to submit calibration requests.

The MOC shall allow authorized users (internal and external to the MOC) to submit requests for activities to be planned and executed on the observatory.

The CALVAL, Spacecraft, Instrument or Operations Teams need a mechanism to request specific activities be planned and scheduled for execution on the observatory. These activities include various calibration requests (Instrument or Spacecraft), parameter updates, various real-time activities (including procedure execution), etc. The MOC provides an interface to accept SpCRs from external and internal users. SpCR submissions (requests) will contain the timing and specific parameters for the requested activity.

Yes

The MOC shall receive approved activity requests for incorporation into planning activities.

Request for activities to be performed need to be approved prior to their incorporation into the planning cycle.

Yes

The MOC shall generate SpCRs as needed to support observatory activities, including absolute-time based calibration activities

SpCRs are the mechanism to place absolute time commands for various activities onto the observatory, e.g. Lunar, Solar and ad-hoc non-routine calibrations

Yes

The MOC shall deconflict the SpCRs with other operational activities that may be occurring at the same time.

For interrupting SpCRs, the Observatory will prioritize the SpCR activity over any scheduled SCR or LCR.

Other non-interrupting activities may also be occurring at the same time (via other SpCRs or contact activities) so the MOC needs to ensure that the SpCR activities do not interfere with one another or other planned events.

Yes

The MOC shall process and schedule all earth imaging collection requests referenced to the WRS-3 path/row coordinate system while not in a WRS-3 compliant orbit.

Trace to GSRD 22442 Supports mission planning during LEOC before the S/C is in its final operational orbit

Contact Orchestration

The MOC shall plan activities to take place during each contact scheduled

Determine what will be uploaded during a contact, if there will be any RT commanding, sequence in retransmit requests, etc.

Yes

The MOC shall schedule a retransmit request to be uplinked to the S/C on the next available contact

Note there is a requirement for a 20% TBR margin to provide an allowance for retransmit CMDs when doing analyses of CMD sequence timing

Yes

The MOC shall schedule the command upload for an approved LCR/SCR

Command(s) can be delivered in next contact or new contact will be scheduled

The MOC shall manage all contact activities for the execution of contacts with the Observatory

Yes

The MOC shall assign Observatory activities to contacts for real-time execution during the assigned contact

Activities identified to be executed or generated by the ground need to be assigned to a contact for execution, and CMDs/loads can be uplinked to the Observatory

Yes

The MOC shall determine if an activity request is to be performed during a real-time contact (request for execution of a procedure) or if the activity is to be executed via stored commands on the observatory.

Approved activities that can be executed during a real-time contact can be assigned to future contact(s).

Activities that require additional stored commands to execute need to have SpCRs generated.

Yes

The MOC shall generate a ground contact request (GCR) from GN and NSN station (and SN) contact plans

Yes

The MOC shall utilize FD determination for scheduling GN and NSN station (and SN) contact times

OO/FD provides exact start (AOS) and stop (LOS) times based on current orbital parameters Yes

The MOC shall generate the definitive ephemeris of the observatory daily based on ACS and GPS orbit data available in housekeeping telemetry at an accuracy of better than 24m in each axis, 3 sigma.

Accuracy requirements may only be met with the use of GPS data from the observatory and is needed to support accuracy requirements of the predicted ephemeris as well as potentially being used for image processing.

Yes

The MOC shall generate a valid OD and ephemeris in TBD min once sufficient valid tracking data are received

Performance requirement for how long it takes to generate an OD and ephemeris. Applies for GPS and ACS data in TLM or alternate tracking data. Note "sufficient" qualification, where it may take multiple contacts to acquire enough data for an OD, etc.

Yes

Orbit determination, ephemeris, and other flight dynamics products shall remain valid for at least 8 hours TBR after the last good data/measurement was received

The MOC will be able to propagate FD/OD products that are valid for at least 8 hours TBR once S/C GPS data is denied or becomes corrupt

Flight Dynamics/Orbit Operations

The MOC shall assess accuracy of orbit determination, ephemeris, and other flight dynamics products Yes

The MOC shall receive data to be used in orbit determination from multiple sources.

It may be necessary to utilize various inputs to perform orbit determination activities within the MOC based on mission phase or anomalous conditions, per MOC ICDs. Sources of information that may be used are:

1) GPS Telemetry from the Spacecraft (RT Telemetry and SSOH)

2) GSFC Flight Dynamics Facility

3) Space based Ranging and Tracking Data (i.e.

TDRSS)

4) Ground Station Tracking or Ranging data

5) Launch Vehicle provider (Separation Vectors)

Yes

The MOC shall generate definitive ephemeris utilizing any of the data received from various sources (individually or in combination).

Multiple sources of orbit data may be available depending on the phase of the mission and available capabilities. The MOC needs to be able to produce current orbit parameters based off of these various inputs per MOC ICDs and T&C handbook. Sources of orbit data include:

1) GPS Telemetry from the Observatory

2) Ground based tracking or ranging data

3) Space based tracking or ranging data

4) External sources (GSFC FDF, Launch Vehicle, etc.)

Yes

The MOC shall calculate predicted orbit state vectors at 96 hours with errors no larger than:

1) 420 meters (3s) radial

2) 4200 meters (3s) along-track

3) 480 meters (3s) cross-track

The MOC needs to ensure that the accuracy of the predicted ephemeris is sufficient to use for activity and orbit determination planning. This accuracy assumes a solar flux (F10.7) value of less than 215 (10-22 W/m2/Hz) and no maneuver activity during the propagation interval.

The MOC shall distribute definitive and predicted orbital products to identified stakeholders in accordance with their respective ICDs.

The orbital products may need to be delivered in various formats (ephemeris, TLEs, IIRVs, etc.)

depending on the stakeholder. The orbital products are used for contact execution, maneuver planning assessments, or image product generation (in the event of an anomaly). Orbit Products are distributed to:

1) Ground Network (and stations)

2) DPAS

3) NASA/GSFC Flight Dynamics Facility (FDF)

4) NASA/CARA

5) SpaceNav or other external space situational awareness service

6) NASA Near Space Network (NSN)

7) NASA Space Network (SN)

Yes

The MOC shall maintain the observatory ground track to the WRS-3 grid within ± 5 Km cross-track at the descending node.

The ± 5 Km is the WRS-3 cross track overlap between adjacent scenes, so to ensure all land is imaged, the ground track must be maintained such that no gaps in image acquisitions occur.

Yes

The MOC shall propagate the current orbit and generate predictive maneuver execution times.

Maneuver predictions are needed to be able to better forecast when they are needed and other activities can be planned around them.

Yes

The MOC shall notify external users of when a potential maneuver may be needed to maintain the observatory within the science box.

Notifications of predictive maneuvers are needed to evaluate potential interruptions to imaging operations.

The MOC shall generate maneuver plans to support all phases of the mission.

The MOC needs to support various types of maneuver executions throughout the mission lifetime.

Identified maneuver types are (which may include both posigrade and retrograde directions):

1) Initial Constellation phasing

2) Drag makeup Maneuvers

3) Inclination Adjustments

4) Conjunction avoidance

5) Constellation re-phasing

6) Decommissioning

Yes

The MOC shall perform observatory attitude maneuver planning.

Attitude maneuvers are required for off-nadir imaging, calibrations (spacecraft and instrument), and orbit maneuvers which will need to be performed over the course of the life of the mission.

The MOC shall automatically identify and report constraint violations during attitude maneuver planning.

The MOC needs to ensure that planned activities do not violate observatory constraints that may be an instantaneous violation or a "not to exceed" duration.

Constraints may include:

1) Instrument boresight violations with the Moon or Sun

2) Star Tracker boresight violations with the Earth, Moon, or Sun

3) Radiator or Thermal "keep-out" zones (exposure of a portion of the observatory to Earth, Sun, Moon, or space)

4) Ka Band antenna pointing angle constraints

The MOC shall distribute maneuver planning products to identified stakeholders in accordance with their respective ICDs.

The maneuver planning products may need to be delivered in various formats depending on the stakeholder. The maneuver planning products are used for maneuver assessments and for scene acquisition metrics being gathered within DPAS (i.e.

tracking which scene collections are interrupted by propulsion maneuvers). Maneuver Planning Products are distributed to:

1) DPAS

2) NASA/GSFC Flight Dynamics Facility (FDF)

3) NASA/CARA

4) SpaceNav or other external space situational awareness service

Yes

The MOC shall assess performance of the spacecraft propulsion system maneuver execution and update maneuver model to reflect current state.

The MOC needs to update and forecast propellant usage as well as thruster efficiencies in order to more accurately plan maneuvers throughout the life of the mission.

Yes

The MOC shall generate definitive ephemeris following maneuver execution.

The MOC needs to verify the maneuver executed as planned and achieved the desired the orbit.

The MOC shall generate predictive ephemeris following maneuver execution

The MOC needs to propagate the new orbit following the maneuver.

The MOC shall distribute updated orbit products and event files following maneuver execution.

The MOC needs to create updated products for the new orbit and distribute them to the appropriate parties.

The MOC shall receive Conjunction Assessment messages from CARA or other Space Situational Awareness (SSA) providers.

These sources provide conjunction assessment analyses and alert users on potential conjunction.

These messages are used to determine if L10 needs to execute a Risk Mitigation Maneuver (RMM)

Yes

The MOC shall evaluate the Conjunction Assessment messages for High Interest Events (HIE) based on a configurable threshold.

The MOC needs to establish evaluation criteria to determine which of the messages are events that may need to be responded to with actions within the

MOC.

The MOC shall assess the objects identified in the HIE for their potential to maneuver out of the way of the L10 Observatory

The MOC should flag objects that have the potential to move away vs. objects that have no maneuvering capabilities or are outside of nominal Space Situational Awareness (SSA) provider communication lines.

Yes

The MOC shall determine mitigation strategies for HIE that maintain the L10 Observatory within the nominal orbit requirements.

The MOC needs to determine if a risk mitigation maneuver for L10 can be performed or if operations needs to be notified.

Yes

The MOC shall ensure potential RMM plans do not cause additional HIE(s) with greater risk compared to the original

HIE.

The potential maneuvers need to be evaluated against other close objects to ensure the maneuver does not cause a more significant problem with a different object.

Yes

The MOC shall continue to monitor the status of the HIE for updates until it is time to execute (or waive) the RMM

The MOC should allow sufficient time to upload the planned RMM to the observatory (if not using pre-onboard RMM option) for execution while also allowing more time for updated SSA reports and ephemeris to be evaluated to determine if the HIE still exists or if the object has moved outside of concerns.

Prevent infinite automation loops between systems (especially with externals)

The MOC shall be capable of automatically triggering RMMs, including the pre-loaded maneuver sequence options onboard the observatory.

Allows the MOC to execute a pre-determined range of intrack and retro maneuver options without the need for custom command sequences

Yes

The MOC shall perform checks to ensure CMD loads do not violate any S/C or instrument constraints or limitations

This could be accomplished by manual and/or automated examination of the CMD load or by running the proposed CMD load through a simulator to assess S/C behavior

Yes

The MOC shall CM all hardware lists/configurations, ground software, Mission Operations Configured Items

This could include but is not limited to: MOC, tools, Command Procedures, SOPs/COPs, Reference Docs, Loads, approved SCRs and LCRs, FSW images, Onboard parameters

Yes

The MOC shall perform configuration and state checks of space segment systems, H/W and S/W, as appropriate, to verify the proper execution of CMDs and maintenance of a known state of L10

To ensure CMDs do not change settings or table values on the S/C or instrument in unexpected ways, or that a setting to value is returned to a nominal setting after an activity has taken place

Yes

The MOC shall perform configuration and state checks of MOC systems and ground models

To ensure MOC health and provide a means for historical performance and analysis with logs Yes

Configuration Management/State Management

The MOC shall maintain a repository of all Observatory loads that are executed on-board.

Activities and command loads need to be archived and tracked throughout the life of the mission.

Yes

The MOC shall monitor memory usage and maintain version control for all onboard Flight Software and Files/Tables

Memory management, tracking, and comparison of ground “gold copy” (FSW image, EEPROM, RAM, etc.) of onboard FSW, tables, and parameters

Yes

The MOC shall build a (binary) CMD load from CMD sequences and mnemonics

Commands and associated parameters need to be translated into the proper format needed for observatory execution.

Yes

The MOC shall translate pass objectives and activities into the (binary) format suitable for uplink to the L10 S/C

Functional requirement to translate CMD mnemonics into format for U/L Yes

The MOC shall ingest, validate and build a CMD load for a retransmit request within 30 min TBR of receipt from the

DPAS

This ensures that a request is ready to be uploaded on the next contact opportunity, assuming ~90 min between contacts (and we don't waste file lifetime on the SSR)

Yes

The MOC shall check loads based on user-configurable constraints and logic

Provides ability to customize and add load checking info as necessary during operations

The MOC shall utilize an Extensible Markup Language (XML) Telemetric (TLM) and Command (CMD) Exchange (XTCE) formatted TLM and CMD database

The S/C vendor will be providing the S/C (Observatory) database in XTCE format, as specified in the S/C SOW and Requirements Yes

Telemetry and Command

Load Builder/Generation

The MOC shall transmit CMDs, files, table loads to the S/C via GN or NSN stations (or the SN)

These could consist of:

1. GCR - Ground Contact Requests to add/update GN contacts

2. LCRs

3. SCRs - Special Collection Requests, defined in terms of a path/row

4. SpCRs - Special CMD Requests, time-based command activities (absolute time) that will get incorporated with other stored command that already exist on the observatory and executed at a future time

5. Retransmit Requests - For mission data files to be re-played back

6. RT CMDs

Yes

The MOC shall utilize COP-1 CMD verification/validation, as defined in the space-to-ground ICD

To ensure CMD was successfully received by the S/C Yes

The MOC shall command the S/C to dump updates to products modified by ground inputs

The MOC should have an up to date list of all commands scheduled for execution on the spacecraft; Onboard planning products include: IOT, Imaging plan, GDAL, etc. The MOC will need to assess if requests have been executed as well as maintain an image of all activities currently planned by S/C automation

The MOC shall process TLM to extract updates of onboard planning products

Extract the updated onboard planning product(s) and route them (to planning and scheduling function) for comparison; Products include: IOT, Imaging plan, GDAL, etc.

Yes

The MOC shall uplink retransmit requests with a higher priority than TBD

Want retransmit requests to have high priority in CMD upload sequences so they can be acted upon as soon as possible (we don't want them to be delayed to near the end of the contact)

Yes

The MOC shall confirm the S/C has received the retransmit request

COP-1 verification or other more detailed handshake with the C&DH. It is assumed the S/C will quickly act on the request and the next verification step would be the D/L of the requested file (which the DPAS will verify by the post-pass report and/or the GN transferring the file)

Yes

The MOC shall uplink SCRs received ≥ 96 hrs prior to overflight of the affected scenes (path/rows)

Ensure that SCRs are uploaded with sufficient time to be incorporated by the onboard mission planning system and subsequently be validated by S/C planning products

Yes

The MOC shall check limit violations of all TLM received from Observatory

T&C initial limit violation check for all telemetry data

The MOC shall take contacts using automation

MOC automation will execute pass activities based on status received from GN stations

Yes

The MOC shall be able to manually execute any automated operations

This allows the FOT to manually perform any functions normally being done by automation

Yes

The MOC shall interface with GN stations to receive status used to coordinate automated MOC activities, per GN/MOC ICD

Also NASA NSN stations, and the SN

Yes

The MOC shall be capable of RT commanding to send single CMDs or CMD sequences outside of a CMD upload

Permits the MOC to send test CMDs, such as no-ops, or to exercise manual control for contingency operations, e.g. - send a CMD to turn on the S/C S- Band TLM TX during a blind acquisition

Yes

The MOC shall coordinate with GN stations for manual operations

Coordination for activities in support of contingency operations, testing, or training, e.g. - coordination of actions between the MOC and GN station to perform a blind acquisition

Yes

Yes

The MOC shall configure…