Attachment_F_-_LMOC_Operations_Concept_-_Redacted_1.pdf

i | P a g e

MOC Operations Concept

1 | P a g e

Table of Contents

1. DATA ITEM DESCRIPTION

1.1. Use

1.2. DID Preparation Information

2. INTRODUCTION

3. FLIGHT OPERATIONS TEAM ROLES AND RESPONSIBILITIES

3.1. Flight Operations Manager (FOM)

3.2. S/C Engineers

3.2.1. Flight System Lead

3.2.2. Subsystem Engineers

3.2.3. Operations Engineers

3.2.4. Ground System Engineers

3.2.5. Mission Planners (MPs)

3.2.6. Flight Dynamics

3.2.7. Ground System Infrastructure

3.2.8. LMOC System Engineer (LSE)

3.3. Staffing ....................................................................... Error! Bookmark not defined.

4. USE CASES AND FUNCTIONAL THREADS

4.1. Introduction to Use Cases and Functional Threads

4.2. Major use cases:

4.2.1. Pre-launch Operations Readiness

4.2.1.1. Ground Readiness Testing, Network Readiness Testing

4.2.1.2. Ops Product Development

4.2.1.3. Mission Readiness Testing

4.2.1.4. Flight Operations Team Training & Certification

4.2.1.5. Operational Readiness Testing

4.2.1.6. Mission Simulations

4.2.1.7. Mission Rehearsals

4.2.2. Landsat 9 LEO&C operations

4.2.3. Mission Transition to LMOC

4.2.4. Day in the life science operations (DITL)

4.2.5. Simultaneous real-time T&C with multiple spacecraft

4.2.6. Instrument Calibration and Off-Nadir Slew Planning

4.2.7. Mission Data Management

4.2.7.1. Overview

4.2.7.2. Data Recording on an Observatory

4.2.7.3. In Pass MDM

4.2.7.4. Data Accounting

4.2.7.5. Pass Automation

2 | P a g e

4.2.8. Autonomous operations and notifications

4.2.9. Orbit maintenance maneuvers

4.2.9.1. Drag Make-Up Maneuvers

4.2.9.2. Inclination Control Maneuvers and Constellation

Coordination

4.2.10. Conjunction Assessment and Risk Mitigation Maneuvers

4.2.11. Simulator operations

4.2.12. Mission Analytical Modelling

4.2.13. Training and certification

4.2.14. Anomaly response

4.2.15. IT security patching & scanning

4.2.16. Infrastructure sustainment

4.2.17. Configuration Management including deployment of CM-approved ops products

4.2.18. Regression testing and deploying LMOC builds to operations

4.2.19. Data and configuration backups and archive

4.2.20. bLMOC contingency operations

4.2.21. Deorbit and passivation

4.3. Misuse cases:

4.3.1. IT security incident response

4.3.2. Hardware failures

4.3.3. Disaster recovery scenarios

4.4. Functional Threads

4.4.1. Daily Activities

4.4.1.1. Command Scheduling

4.4.1.2. Data Downlink and Processing

4.4.1.3. Mission Data Management

4.4.2. On Orbit Maneuver Planning

4.4.3. Data Archive

5. Maintenance Operations

5.1. System update concept

6. Acronym List

List of Figures

Figure 2-1 Landsat 9 Mission Architecture

Figure 2-2 LMOC Block diagram

Figure 3-1 LMO FOT Functional Breakdown

Figure 3-2 Staffing during Mission Phases .................................... Error! Bookmark not defined.

3 | P a g e

Figure 4-1 Sample Prelaunch LMOC Parallel Testing

Figure 4-2 Routine Daily Operations

Figure 4-3 LMOC MPS DITL

Figure 4-4 Station Scheduling

Figure 4-5 Daily Ops Activity Planning

Figure 4-6 Activity Planning

Figure 4-7 Load Generation

Figure 4-8 Load Building, Uplink and Operation

Figure 4-9 MDM Overview

Figure 4-10 Activity Planning

Figure 4-11 Data Accounting

Figure 4-12 Pass Automation Timeline

Figure 4-13 LMOC System Automation

Figure 4-14 Softbench Interface Diagram

Figure 4-15 S/OS Interface Diagram

Figure 4-16 Anomaly Response Flow

Figure 4-17 Configuration Management Flow Diagram

Figure 4-18 Command Scheduling

Figure 4-19 Data Downlink & Processing

Figure 4-20 Mission Data Management

Figure 4-21 Maneuver Planning

Figure 4-22 Data Archive

Figure 5-1 Monthly IT Patching & Scanning

List of Tables

Table 4-1 Command Scheduling

Table 4-2 Data Downlink & Processing

Table 4-3 Mission Data Management

Table 4-4 Maneuver Planning

Table 4-5 Data Archive

Attachments

Attachment Filename Description https://alliance.gd-ms.com/sites/Programs2/LMO/Program%20Execution/4.11%20TechnicalCDRLs/4.11.01%20Draft%20CDRLs/MD%20-%20MOC%20Development/CDRL_02_MD_01_MOC_Operations_Concept.docx#_Toc520203349 https://alliance.gd-ms.com/sites/Programs2/LMO/Program%20Execution/4.11%20TechnicalCDRLs/4.11.01%20Draft%20CDRLs/MD%20-%20MOC%20Development/CDRL_02_MD_01_MOC_Operations_Concept.docx#_Toc520203353

4 | P a g e

1. DATA ITEM DESCRIPTION

1.1. Use

Describes the proposed LMOC in terms of the operator and user needs it will fulfill, its relationship to existing systems or procedures, the satellite operational needs, and the external operational interfaces.

1.2. DID Preparation Information

The MOC Operations Concept shall address the total LMOC scope, including interactions with its external interfaces and incorporate, as directed by the USGS Landsat Mission Operations Project, operations concept and interface content received from GFP vendors. The LMOC Operations Concept shall include the following at a minimum:

a. Flight Operations Team Organization and Roles and Responsibilities

b. Describe how LMOC systems are operated in nominal and non-nominal modes of operations which includes at a minimum:

i. Mission planning processes.

1. Off-Nadir Calibration

ii. Science data collection activity planning processes

1. Instrument calibrations

2. Primary science mission collection planning

iii. Maneuver planning processes

1. Orbit modification maneuvers

2. Inclination maneuvers

3. Conjunction maneuvers

iv. Telemetry and commanding control

1. Station contact execution

2. Post-pass processing

v. Mission data management process

vi. Offline operations

1. Trending and analysis

2. Engineering data processing

vii. Anomaly response process

1. Observatory onboard data recovery

2. 2. S/C events

3. 3. Ground events

c. Address the operations concepts of any new multi-mission systems introduced as part of the design, with emphasis placed on changes to heritage operational practices.

d. Convey how the LMOC operations concept fulfills the overall mission operations concept, and the larger Ground System operations concept.

e. Address all the major phases of operations of the LMOC which includes at a minimum:

i. Pre-launch operations readiness

ii. Launch and commissioning

iii. Sustaining operations

f. Include the approach for maintenance operations such as system patching, security scanning, and testing of software updates which might impact operations, conveying how ongoing operations are still supported concurrent with maintenance activities throughout the mission lifecycle

i. Include the overall approach for handling major LMOC software deliveries throughout the mission lifecycle

5 | P a g e

2. INTRODUCTION

This Operations Concept (OpsCon) will describe the intended uses of the Landsat Multi-Satellite

Operations Center (LMOC) system, including the significant functional threads and use cases which drive design and testing. This operations concept covers the LMOC system, its interactions with the Landsat 8 and Landsat 9 observatories, interfaces to the Ground Network

Element (GNE) and Data Processing and Archive Segment (DPAS) elements, and other externals such as NASA, NOAA, spacecraft vendor, and instrument vendor.

The Landsat System includes all components and capabilities (both space and ground based) that are under the developmental and operational responsibility of the Landsat NASA-USGS interagency team. For mission definition and formulation purposes, the Landsat System is defined at the highest level in terms of three parts - the Space Segment (including Landsat 8 and

Landsat 9), the Ground System, and the Launch Segment (Figure 2-1).

Figure 2-1 Landsat 9 Mission Architecture

The Space Segment consists of the operational Landsat 8 (L8) observatory, the Landsat 9 (L9) observatory, and pre-launch ground support equipment. Each observatory is comprised of the imaging sensor(s) and the spacecraft platform. The L8 and L9 observatories will operate in a

704 Km orbit with a 16-day repeat cycle and a 10:00 a.m. (+/- 15 minutes) mean local time for the descending node. The L8 and L9 observatories will be stationed 8 days apart within the 16

L9 Ground System

Calibration Maneuvers & Request

Pole Wander

Search & Discovery, Request, & Browse

Data Products, Science Products

Orbit Information

S/C, Instrument(s)

Vendor Facilities

P&S Products, Status, Notifications

Coordination, Command, Telemetry

Flight Software

CPF

Pole Wander

Image

Assessment

User Community

Space Segment

(L9 Observatory)

Launch Services

Segment (VAFB)

Collection Request, Land Mask

Mission Data, Metadata

Mission Data, Metadata

Test Data

CMD/TLM Database

CMD/TLM

International

Cooperators (ICs)

Archive

GSFC Flight

Dynamics, & CARA

Science

Office

NASA

Near Earth

Network

NASA

Space

Network

(WSC)

S/C, Instrument(s)

Flight Software

Vendors

Cal/Val

Team

Ground Network Element

LGN RF Communications

USNO

Landsat Multi-Satellite Operations Center

Simulators

Trending &

Analysis

Telemetry, Command

& Control

Mission

Planning &

Scheduling

Data Processing & Archive System

Storage and

Archive

Access

Distribution

Image

ProcessingIngest

L9 GS Operational Concept Architecture

DCN: LSDS-1647 v2.0

Date: March 22, 2017

X-Band Downlink

S-Band CMD/TLM

System and Human Interfaces

External Entities

NASA Services

CMD/TLM, P&S

Products

CMD/TLM,

CFDP Status, P&S Products, Interval

Metadata

P&S Products

Image Data Flow

Flight

Dynamics

Health &

Status

Monitoring

Metrics &

Reporting

Mission Data

Routing

Command and

Telemetry

Routing

6 | P a g e day repeat cycle. Imaging sensor and ancillary data (combined as mission data) will be collected, stored onboard and subsequently downlinked to ground stations within the ground network via an X-band communications link. This link will also include stored housekeeping telemetry. Additionally, a real-time X-band downlink capability will transmit mission (imaging sensor and ancillary) data to the Ground Network Element (GNE) / Landsat Ground Network

(LGN) and International Cooperators (ICs) equipped to receive Landsat data. Each observatory will also receive and execute commands and transmit real-time housekeeping telemetry via S-band link to the ground network. L9 will utilize ground support equipment to perform ground-based integration and testing of the observatory prior to launch.

The Landsat Ground System is composed of the Ground Network Element (GNE), the Data

Processing and Archive Segment (DPAS), and the LMOC. The GNE acts as the primary interface to the spacecraft and provides S-band uplink for commanding and X- and S-band downlink. The Space Network and Near Earth Network are also used in supporting satellite communication roles. DPAS processes mission data for the user community and provides input to data collection planning. The LMOC performs fleet management of the L8 and L9 observatories, ensures mission data collection and downlink, and maintains observatory health & safety.

The LMOC is based on LDCM/L8 MOC heritage and provides critical operations functions:

• Telemetry and Command

• Trending and Analysis

• Flight Dynamics

• Collection & Mission Planning

• Alert & Notification

• Infrastructure & IT Security

Key updates to the LMOC design from the heritage system include the capability to support multi-satellite operations, and replacement of the mission planning and trending subsystems.

Multi-satellite configuration at the system level is largely driven by data product naming and other meta-data controls. LMOC subsystems also utilize subsystem or application level configuration controls to support multi-satellite ops and ensure intra-subsystem product and information control. Satellite-unique repository and product delivery structures both support fleet operations and LMOC system backups.

Routine operations within the LMOC will be heavily augmented by automation. Automation supports product/file transfer, pass operations, data accounting, observatory alerts, batch plot generation, and LMOC/bLMOC subsystem alerts. The operations team will monitor automation, provide sustaining engineering, plan/execute unautomated or non-routine ops functions, and provide contingency response and resolution support.

7 | P a g e

Freeflyer

Meridian

MTASS

Scheduler / CPAWTLM

Master Activity Lists

Ephemeris, Attitude slews

TLM

clients

TLM

Galaxy

Events

WhatsUp Gold

Events

Events

Events

Events EventsNotifications

AWT

Mercury

Mercury

CR

CMD / TLM

Resource Model

L8 / L9

Simulators

Stars

DMS (Mercury)

Other socket

Gilbert

MOC-CTP

TLM

LCR, SCR

DPAS

GNE

Pass schedules

FDS

products

GNE

CMD/TLM SIFMT CFDP

SN / NEN

CMD/TLM

SSOH

L8 Heritage

LMOC New

External

JASON

Spacecraft-Unique Instances

(all others are spacecraft agnostic) Figure 2-2 LMOC Block diagram

8 | P a g e

3. FLIGHT OPERATIONS TEAM ROLES AND RESPONSIBILITIES

The LMO FOT is comprised of engineers from the GD-MS LMO Team. The team structure allows all teammates to provide unique functional support within the LMO FOT.

LMO TEAM

FOT Manager

Mission Planning

FDS Engineer

S/C Engineering

IT Security

CM

Property

GSI Network

GSI SA

Ops Engineers

GSE

General Dynamic

Mission Systems

AI Solutions

The Hammers Company

RT Ops Certified

L9 Flight System Lead

LMOC System Engineer

(LSE)

LMOC Transition Lead

(LTL)

FOT Engineers Matrixed to provide the Ops prospective and insight to the LMOC engineering development

Figure 3-1 LMO FOT Functional Breakdown

3.1. Flight Operations Manager (FOM)

The FOM manages the entire Operational scope of the LMO contract and is the direct interface for the USGS Flight System Managers (FSMs). They are the day to day leadership of the FOT and work with the Flight System Lead (FSL) to ensure the resources, both internal and external, are available for seamless operation of L8 and L9. The FOM ensures that all CM best practices and processes are followed and heads the Configuration Control Board (CCB). They provide technical oversight and mentoring to the FSL. The FOM manages all staffing schedules and ensures the required training is maintained.

• The Flight Operations Manager (FOM) uses short, daily standup meetings to engage the team in clear communication of priorities, challenges, and solutions for achieving the science goals. The FOM has technical authority over the operations team.

• The FOM’s major duties include leading all LMO mission operations activities and managing the FOT.

9 | P a g e

• The FOM performs technical planning, cost and risk analyses, provides an operations perspective to systems engineering and spacecraft I&T activities, synthesizes solutions to meet USGS expectations and technical performance while staying within schedule and cost constraints, leads operations modeling and simulation activities, and chooses the appropriate standards, processes, procedures, and tools for mission operations.

3.2. S/C Engineers

S/C Engineers are responsible for the health and safety of the L8 and L9 Observatories. The L8 and L9 Flight System Leads (FSL) are the Engineers in charge of their respective observatory engineering duties. The FSLs are supported by Subsystem Engineers (SSEs) who are responsible for the various spacecraft subsystems and instruments and their components in the performance of their daily operations.

3.2.1. Flight System Lead

The FSLs are the SMEs for the L8 and L9 Observatories. They champion Observatory health and safety against scheduling and operational pressures.

• They lead the subsystem engineers in ensuring the safety of the Observatories and sustaining their performance to maximize science data collection.

• They are the FOT final technical approval for command requests before being taken to the USGS Flight System Manager (FSM) for final approval.

• They analyze trends across subsystems for interactions and Observatory-level concerns.

• They participate in all technical meetings and project status briefings as needed and lead

Command Authorization Meetings (CAMs) when needed.

• They lead the FOT in anomaly/issue investigations and recoveries.

3.2.2. Subsystem Engineers

The SSEs maintain the health and safety of Observatory systems. They verify any related routine commanding, analyze trends to assess near and long term performance, and verify nominal ops for the systems. They work side by side with the Ops Engineers for special real-time command operations. (e.g. MDM, charge/discharge cycles and maneuvers).

• SSEs prepare and submit products for commanding requests and perform verification/validation activities (simulations).

• SSEs maintain the validity of procedures, displays, and configuration files for their subsystems.

• SSEs work with the instrument vendors, CalVal Team, and the Data Acquisition Manager

(DAM) to prepare command requests and verify onboard execution.

3.2.3. Operations Engineers

The Operations Engineers (OEs) are tasked with day-to-day spacecraft and ground system console operations. The Ops Engineers are responsible for:

10 | P a g e

• All normal and special S/C real-time commanding, including uplink of daily command loads.

• Real-time ops environment readiness and execution, assessment of the Observatories during contacts, and first line response to Out of Limits (OOL) violations

• Mission Data Management (MDM) activities, including:

o verifying the Scene-Image Mapping Table (SIMT) o intervening to resolve on-board file corruption o working with the Ground Network Element (GNE) to quickly recover from significant MDM interruptions

• Analysis of X-band utilization time, Solid State Recorder (SSR) file count, and SSR block usage to ensure performance margins

• Proper operation of the Galaxy real-time ground system operations and external interfaces to the GNE stations

• Automation performance

• Identifying and commanding manual recorder file maintenance

• Ground system automation performance

• Daily console log reports

The OEs are re-certified according to the Training Plan to keep skills up to date and participate in periodic proficiency contacts and failover simulations.

3.2.4. Ground System Engineers

The Ground System Engineers are the SMEs for the various ground system applications. The

GSEs are responsible for:

• Functional health and safety of the LMOC systems.

• Operational processes of the LMOC.

• Troubleshooting LMOC internal and external interfaces

• LMOC sub system performance and operations

• Performance of the file management system, real-time system operation, and trending system plot generation

• Post-pass report and stored state of health receipt

• Responding and resolving (or coordinating response) to LMOC subsystem issues.

The OEs and GSEs use time outside of contacts to maintain the LMOC systems, implement approved updates, and test possible improvements. They use time outside of that to meet training and company requirements, address operations concerns, enhance skills (e.g., further training), and read technical publications (such as from USGS.gov).

11 | P a g e

3.2.5. Mission Planners (MPs)

The MPs utilize the Mission Planning Subsystem (MPS) to generate the Master Activity List

(MAL) for each Observatory; resulting in the daily Absolute Time Sequence (ATS), Imaging

Window Table (IWT), and associated Scene-Interval Mapping Table (SIMT), MOC Directive

File (MDF), and Confirmed Contact Schedule (CCS). They use MPS for inclusion of predictions, ingest of flight dynamics products, and handling of Observatory command requests/activities.

The MPs work with instrument and science teams and SSEs to properly plan special or contingency activities, including any contact scheduling needs. They shepherd the load approval process to ensure products are available when needed for uplink.

3.2.6. Flight Dynamics

FD personnel perform a specialized role within the team. Like Mission Planning this is an offline position, with mature processes and procedures.

• FDs ensure the automated daily orbit and attitude processes (definitive and predictive) meet mission requirements and all planning products are successfully generated.

• Generate plans and command data when maneuvers are required.

• Support mission planning as needed for lunar calibration slew planning, generation of necessary command/planning products, and slew validation.

• Coordinate with the calibration and validation (CalVal) team weekly via an exchange of planning products and requests.

• Analyze planned slews and verify expected attitude Euler angles and star tracker, instrument, and radiator interference, before committal and inclusion in the operational products to ensure the safety of the Observatories.

3.2.7. Ground System Infrastructure

GSI engineers are the system and network administrators who maintain the availability, reliability, and security of the LMOC/bLMOC. They maintain the centralized, CM-controlled OS templates and the support systems needed to initialize and apply security controls to individual

VMs.

• GSI engineers install security patches and system software updates, maintain network and host firewalls, and administer user accounts.

• GSI engineers troubleshoot and resolve issues with network connectivity, access permissions, and system and network performance. They set up, monitor, and maintain the system backups.

• IT security GSI engineers work with NASA/USGS IT security managers and LMO system administrators to develop solutions for compliance with federal standard security practices set forth in NIST special publications, OMB memorandums, and executive orders including, but not limited to, NIST SP 800-53 revision 4.

12 | P a g e

• The LMO IT security engineers perform routine vulnerability scans and manage mission patch cycles on the LMOC systems. They are tasked with tracking any security variances and Plans of Actions and Milestones (POA&Ms) that make up security liens against the

LMOC systems. The IT security engineers are also tasked with maintaining the LMOC

IT Security Compliance Matrix (03-MD-03).

3.2.8. LMOC System Engineer (LSE)

The LMOC System Engineer works closely with the LMO Chief Engineer and LMOC

Development lead in the design and implementation of the LMOC. The LSE will act as the voice of operations for the LMOC development engineers as the requirements and capabilities are decomposed and the OpsCon is nested into the design. The LSE will coordinate FOT support for development activities including I&T and T&E. The LSE will provide the deployment post-test report.

13 | P a g e

4. USE CASES AND FUNCTIONAL THREADS

4.1. Introduction to Use Cases and Functional Threads

LMOC operations are captured in a series of functional threads. These scenarios provide an overview of the major use case scenarios in the Operations Concept to describe how major activities are accomplished. This set of scenarios helps in understanding how the LMOC system behaves and serves as a tool to aid in verifying the completeness of the Operations Concept. The scenarios do not portray every possible situation that may be encountered during operations, but serve as a basis for further operations planning and building test cases for system verification and regression testing.

4.2. Major use cases:

Several use case scenarios are core to the LMOC and are required to support expected operations. These major use cases must be thoroughly understood, developed, and tested to ensure successful operations.

4.2.1. Pre-launch

Operations Readiness

In the lead-up to launch, the

LMOC must support a wide range of preparation and testing activities. Throughout the pre-launch phase, the LMOC supports a variety of concurrent activities, with the expected cadence and specific configurations changing over time. See Figure 4-1 for an overview of LMOC configurations in use to support parallel activities. The chief pre-launch operations activities are listed in the following subsections.

4.2.1.1. Ground Readiness

Testing, Network

Readiness Testing

The purpose of Ground Readiness Tests (GRTs) is to prove the capabilities of the core integrated ground system, including the LMOC, GNE, and DPAS. These tests are organized and led by the

USGS Ground System Integration & Test Team, with support from the LMO team as LMOC system users and SMEs. Network Readiness Tests (NRTs) are similar to GRTs but are geared towards testing of the LMOC with the Space Network (SN), Near Earth Network (NEN), Flight

Dynamics Facility (FDF), NASA Integrated Service Network (NISN), and Conjunction

Assessment Risk Analysis (CARA).

L8 LSIMSS

L8 SoftBench 1 L8 SoftBench 2

L8 SOS

L8 Observatory

L9 LSIMSS

L9 SoftSim 1 L9 SoftSim 2 L9 SoftSim 3

L9 SOS

L9 Observatory

SimulatorsSubsystems

Single Mission

Multi Mission

I&T Operations Environment A

Operations Environment B

Si m u la to r

A cc e ss

Su b sy st e m s

C o m m o n

Galaxy

CMD

Galaxy

TLM

STARS

MPS

FDS

DMS

Spare

Spare

Spare

SAT GRT MRT

MRT

Dry-Run

Figure 4-1 Sample Prelaunch LMOC Parallel Testing

14 | P a g e

For both GRTs and NRTs, the LMOC operational environment is utilized to perform testing in a flight-like fashion. The procedures are developed to reference existing FOT Standard Operating

Procedures (SOPs) to maximize reuse and to most closely mimic real operations. The specific configuration of the LMOC depends on the simulator and GRT configuration being used, with the majority of testing with the Spacecraft/Observatory Simulator (SOS) or the Linux Scalable

Integrated Multimission Simulation System (LSIMSS) simulator deployed by the GNE.

The execution of GRTs and NRTs are primarily supported by the system glueware developed within the LMOC I&T environment, with additional updates as required by the FOT to address any differences between simulated interfaces and actual interfaces. The dry-run and run-for-record for these tests primarily requires a minimal number of subsystem instances for user interaction, but a performance, capstone, or LEO&C GRT may call for a larger MOC footprint.

4.2.1.2. Ops Product Development

A significant portion of the pre-launch development work undertaken by the FOT is the development of operational products which define the operation of the spacecraft and instruments. The primary types of products are

• STOL procedures (procs): Real-time scripts which perform telemetry and command operations with the observatory

• Telemetry pages, plots: Define views of telemetry used for real-time situational awareness

• SOPs & COPs: Provide FOT direction on executing pre-determined activities

• Trending plots: Define textual reports or graphical plots which render Stored State Of Health

(SSOH) data captured in back-orbit and ingested by trending system

• Activity Definitions: Defines the relationship between activities planned by the MPS and actual command sequences for uplink to the spacecraft

• Mission Planning configurations: Used to generate a list of activities based on discrete input files

• Mercury model: Defines file-based product flows within the MOC

• Glueware: Other configuration files and scripting using languages such as python and bash

The LMOC supports LMOC product development by providing user access to both

Configuration Managed (CM’d) and non-CM’d product spaces within user space. The end-user can utilize non-CM’d spaces for ongoing development, testing, and merging their products into the CM baseline. The LMOC also houses multiple simulators for FOT use in testing ops products, and a corresponding number of command workstations.

The LMOC also provides work management tools to organize and coordinate the work required to prepare for an MRT. The work management tools integrate to the CM system for greater situational awareness and tracking of test readiness.

4.2.1.3. Mission Readiness Testing

Mission Readiness Tests (MRTs) are formal tests conducted between the LMOC and the

Observatory during the pre-launch campaign. MRTs are intended to validate ops products generated by the FOT as well as validating the ground system. The LMOC supports MRT dry-runs through rigorous CM in the operational accounts, access to high-fidelity simulators, and a multitude of smaller organizational tools. The MRT execution is supported by connecting from the LMOC T&C systems to the MOC Command & Telemetry Processor (MOC-CTP), which is provided and maintained by the GNE. The LMOC also provides other functionality as required

15 | P a g e for MRT preparations such as FDS and MPS for load building, and Trending to assess the success of the MRT.

The NASA Mission Operations Readiness Team (MORT) leads the development and execution of the MRTs. The FOT provides input in the form of syntactically correct invocation of command procedures as requested by the MORT.

4.2.1.4. Flight Operations Team Training & Certification

The Operations Staff Training and Certification Plan (CDRL 02-OR-03) details the training activities and certifications tests required for FOT to participate in operating the spacecraft. The

LMOC supports FOT training & certification through the use of simulator environments for every subsystem, and a strict segregation of data between sources. This ensures the FOT can operate the LMOC and a simulator in a high-fidelity simulation of operations. The LMOC also provides organizational tools to manage the training and certification programs.

4.2.1.5. Operational Readiness Testing

Operational Readiness Tests (ORTs) are geared towards ensuring operator proficiency and fluid operations with ground stations which have been previously tested in GRTs and/or NRTs. The

ORTs are executed using only SOPs and COPs, with no other formal test procedure given.

4.2.1.6. Mission Simulations

Mission Simulations (MS’s) are primarily used to train and test the wider Flight Support Team

(FST) in the proper usage of the LMOC, the management of the spacecraft during LEO&C, and the coordination steps required to complete the spacecraft commissioning. The activity in an MS is centered in the Launch Support Room (LSR) which conducts all commissioning activities.

The MS campaign is organized by the MORT with participation by the L9 Project, the FOT, spacecraft vendor, instrument vendor, and other support staff. The LMOC supports the MS’s by providing the LSR and associated launch operations functions, and access to the high fidelity simulators. The LMO team also provides training to LSR users. The NASA project coordinates usage of the LSR and provides the MOVE voice keysets for intra-facility and inter-facility communications.

4.2.1.7. Mission Rehearsals

Mission Rehearsals are a subset of Mission Simulations which focus on the pre-launch countdown and the first few hours of commissioning. The support requirements are comparable to Mission Simulations.

4.2.2. Landsat 9 LEO&C operations

The Launch, Early Orbit, and Commissioning phase of Landsat 9 begins with the final countdown to launch and runs through the early orbit checkout of the L9 observatory.

The L9 launch countdown will begin when the NASA/KSC, launch service contractor, L9

Project, and USAF Western Range (WR) launch teams all agree that there are no impediments to launch. At T=0, the LV begins its ascent from the launch facility. During the final countdown and LV ascent telemetry monitoring and observatory support will be performed by the launch team at the launch site. During all powered flight portions of the launch and ascent through observatory separation, the LV transmits telemetry to the LV ground tracking stations and/or

16 | P a g e instrumented aircraft. After achieving the injection orbit, the LV releases the observatory. The operations team, with support of the observatory vendors and NASA Goddard Space Flight

Center (GSFC) Engineering and Technology Directorate, assumes full operations of L9 from the

LMOC after the observatory separates from the LV upper stage. Following observatory release, the LV will perform a collision avoidance maneuver.

Commissioning begins at spacecraft separation from the LV. At this point the launch service contractor will provide the LMOC FDS and the NASA GSFC Flight Dynamics Facility (FDF) with a valid observatory separation state vector to support the first orbit determination. This will be used to update orbit-dependent planning products such as ground station contact data.

The spacecraft will perform an autonomous pre-programmed activation sequence after separation from the LV to initiate deployments, generate power to the observatory, and turn on critical subsystems. During early-orbit, the proper functionality of observatory command and data handling functions and attitude and orbit determination and control functions will be demonstrated. The L9 observatory will be capable of transmitting real-time S-band telemetry to the SN for routing to the LMOC T&C system. Additionally, the observatory may begin transmitting real-time S-band telemetry to the GNE ground stations and the NASA Near Earth

Network. The observatory X-band system will be enabled and checked out against the GNE prior to instrument activation.

During commissioning, activation of the L9 imaging sensors begins. The imaging sensors will be activated based on a series of steps following out-gassing, including powering-on of imaging sensor electronics, functional checkout of any on-board calibration sources, generation of imaging sensor health and status, and collection of the first image. Imaging sensor data will be transmitted via X-band communications to the GNE ground stations.

The LMOC will receive telemetry through the ground network and will begin monitoring spacecraft status and health. Imaging sensor data will also be received by the GNE and routed to the DPAS.

After initial observatory checkout steps, it is anticipated that orbit adjustments will be made to move the observatory from its initial parking orbit to its nominal orbit. This will include any coordination needed to bring the observatory into the “morning constellation” of Earth-observing satellites. These orbit maneuvers may take several weeks and will require periodic orbit determination using observatory telemetry and flight dynamics analysis. The NASA GSFC FDF will be available to support these activities if needed.

It is anticipated that activities such as spacecraft checkout, orbit raising, imaging sensor(s) out-gassing, activation and decontamination will nominally take place in the first 30 days following launch. Likewise, days 30-60 will nominally include imaging sensor(s) transition to operational mode, first light image collection, and start of on-orbit imaging sensor(s) calibration activities with mission data flow tests.

17 | P a g e

During L9 LEO&C the operations team will be supporting ongoing operations of L8. Since L8 is in the routine operations mission phase it is anticipated that automation will reduce operations staffing need. The operations team will be compartmentalized between L8 and L9 operations to ensure any L8 issues do not disrupt L9 observatory commissioning. Additional details regarding simultaneous satellite operation can be referenced in the Transition Plan (MT-01).

4.2.3. Mission Transition to LMOC

The LMOC and bLMOC will be thoroughly tested prior to starting operations with the L8 and

L9 observatories. LMOC and bLMOC testing will support the L9 I&T plan, which includes

Mission Operations Simulations (MOSs), Mission Readiness Tests (MRTs), and Ground

Readiness Tests (GRTs). The L9 MOS, MRT, and GRT plans will test LMOC/bLMOC internal functions and interfaces with the L9 mission spacecraft, GNE/ /SN/NEN, EROS, FDF, and other external segments.

Since L9 testing must be accomplished on an extremely strict timeline to meet the L9 launch date, L8 testing of the LMOC/bLMOC may not impact L9 testing. L8 testing is completely independent of the L9 MOS, MRT, and GRT plans within the LMOC/bLMOC. Successful completion of the L9 I&T plan will certify the LMOC/bLMOC for L9 operations.

The L8 transition will be handled separately from L9 and will focus on verifying L8 ground/operations functions. Note, fleet operations (L8 and L9) will be tested and validated as part of LMOC I&T work. Network Proficiency Tests (NPTs), Operation Readiness Exercises

(OREs) and Transition Readiness Tests (TRTs) have been outlined to verify LMOC/bLMOC functionality, external interfaces, and ground system/ground network interactions.

NPTs are informal tests which will exercise the L8 operations interfaces. NPTs will demonstrate network connectivity and appropriate accounts/privileges required for data flows and external interfaces. NPTs will be conducted between the LMOC/bLMOC and the following external interfaces (all other external interfaces will be tested via LMOC I&T):

• SNAS

• S/OS

• SB

• Vendor Delivery

• Alert Path

• SN CMD/TLM

• NEN CMD/TLM

• LGN CMD/TLM

OREs are designed to demonstrate basic L8 operations functions on LMOC subsystems. All

18 | P a g e

OREs will utilize simulator data instead of real-time data. Several OREs will require passing test products between external interfaces and LMOC subsystems.

TRTs are formal system level tests and will use the observatory simulators to replicate day in the life operations and LMOC functionality.

• TRT Functional Threads (L8 Only)

• TRT Shadow Operations Testing (L8 only, DITL and TWITL)

• TRT Multi Satellite Testing

LMO will coordinate the tests with the other GS elements and take their schedule into account for testing.

For more details on L8 Transition, refer to CDRL_04_MT_01 L8 MOC Transition Plan.

4.2.4. Day in the life science operations (DITL)

Nominal Landsat operations revolve around the day in the life (DITL) cadence. Central to the

DITL is the daily activity scheduling and execution of observatory commands. The L8 and L9 satellites execute stored command loads that contain instructions regarding spacecraft subsystem management, image collection, instrument calibration, transmitter management, and data downlink. These command loads must be built, reviewed, and uplinked on a reoccurring schedule to keep a fresh command load on each satellite for execution.

The timeline shown in Figure 4-2 outlines the cadence of routine operations contacts as well as load-building activities for the scenario where both spacecraft loads are built on the same day.

This scenario assumes a single workstation is being utilized for both spacecraft, the operations team may elect to utilize two workstations in parallel for two spacecraft if the daily staffing permits.

19 | P a g e

10:00 00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00

12 00 14:00 13:00

12:00 - 12:01

Stars gens GPS data

12:03 - 12:13

FDS Automated Daily Production

12:15 - 12:45

MP Checks Inputs

13:25 - 13:28

T&C Build Loads

13:20 - 13:25

MP Reviews Plan 13:28 - 13:48

MP Review Loads

16 00 18:00 17:00

16:00 - 16:01

Stars gens GPS data

16:03 - 16:13

FDS Automated Daily Production

16:15 - 16:45

MP Checks Inputs

17:25 - 17:28

T&C Build Loads

17:20 - 17:25

MP Reviews Plan 17:28 - 17:48

MP Review Loads

13:48 - 15:00

FOT Reviews Loads (detail timeline ends @14:00)

17:48 - 19:00

FOT Reviews Loads (detail timeline ends @18:00)

10:40 - 10:57

L8 NSN

11:26 - 11:43

L9 NSN 12:18 - 12:35

L8 NSN

12:31 - 12:48

L9 ASN

13:17 - 13:34

L8 ASN

14:06 - 14:23

L9 ASN

15:40 - 15:57

L8 LGS

16:28 - 16:45

L9 LGS

17:13 - 17:30

L8 LGS

17:52 - 18:09

L9 NSN

18:38 - 18:55

L8 NSN

19:25 - 19:42

L9 NSN

19:43 - 20:00

L9 GLC

20:13 - 20:30

L8 NSN

21:03 - 21:20

L9 NSN

21:53 - 22:10

L8 NSN

22:45 - 23:02

L9 LGS

23:07 - 23:24

L8 NSN

23:29 - 23:46

L9 GLC

16:45 - 17:20

MPS Collection Planning12:45 - 13:20

MPS Collection Planning

16:15 - 17:28

Landsat-9 Daily Production (LMOCRD-3442) 12:15 - 13:28

Landsat-8 Daily Production (LMOCRD-3442)

L8 Uplink Opportunities

L9 Uplink Opportunities

Figure 4-2 Routine Daily Operations

Stars:

Auto

Generate GPS data

Freeflyer Meridian:

Auto perform OD, generate Ephemeris, orbit maneuver plans

MP triggers* CPAW:

1. Define Planning Window

2. Select Scenes

3. Run algorithms

4. Create Scans & D/L Plan

5. Generate Reports

CPAW:

Order Manager auto converts

*CR’s into CPAW Orders

Mission Planner:

Review Plan

Mission Planner:

Disposition Planning

Window as Save

Mission Planner:

CPAW Disposition

Planning window as Transmit

Bad

Good

Mercury:

Detect Master Activity List.

Deliver and initiate offline

Galaxy compiler

Mission Planner:

Check input products, update future housekeeping activities

Offline Galaxy:

Compile Activity List into reports and binary loads.

Execute FOT load checker

Mercury:

Receive products and place in wait-for-signature state

MP Review products

Copy to Real-time Operations

Console W/S

Cease product promotion

Initiate Review

FOT Load Review

Approved

Rejected

Real-time Operations

Console:

Uplink

DPAS:

Generate

LCR

Generate SCRs

CPAW:

Place products in delivery directory

STK Scheduler:

Push scheduling blackouts and bus activities to

CPAW

Mission Planner:

Identify and perform rework. Disable / update collection requests as needed.

FD Analyst:

Review/Update

Maneuver planning tableB

C

E

D

F

G

H

I

J

K

L

O

M

P

N

Q

R

S

T

U

COST:

Generate CalCRs

A

Figure 4-3 LMOC MPS DITL

Prior to beginning command load generation, several input files must be created and collected.

A. Science community user requests are reviewed by the USGS Data Acquisition Manager and approved requests are posted to DPAS as special requests. Calibration Collection

Requests are generated by the LMOC-internal COST system.

20 | P a g e

B. The Collection Planning and Analysis Workstation (CPAW) converts the collection requests into CPAW orders.

C. STARS collects real-time and back-orbit spacecraft data and generates the GPS data that will be used by Flight Dynamics.

D. Freeflyer Meridian uses this GPS data to create various ephemerides and orbit maneuver plans.

E. The Mission Planner checks all of the input products and updates future housekeeping activities.

F. Flight Dynamics reviews and update maneuver products if necessary.

Generate CFC Updates Needed?

YES

NO

LMOC Station Scheduling

Collect Input Data Files

Generate Deconflicted Contact Schedule

Predicted Ephem Scheduler Contact File (SCF) sent to

CPAW

Define / Update

Planning Period

Update Contacts

CFR

CFC

Galaxy

CPAW

GNE

STK Scheduler Product Transfer

Process Flow

DPAS

FDS

FOT

COST

Figure 4-4 Station Scheduling

Each week the mission planning team submits acquisition products to GNE/NEN stations with a requested contact schedule. The requested contact schedule is created in STK

Scheduler using predictive ephemerides provided by FDS and scheduling rules programmed into STK Scheduler. STK Scheduler will create a Contact Forecast Request that contains the desired ground contacts for the next 28 days. Stations will review the requests and provide a Contact Forecast Confirmation with the contacts they can support.

A Scheduler Contact File (SCF) is then sent from Scheduler to CPAW.

Review Schedule Options

Are updates needed

Make Schedule

Corrections

YES

NO

Ingest

CPAW

Orders & Sched

Daily Ops Activity Planning

Receive Input Data

Files

RESOLVED

Generate Master Activity ListDMS

Automated FDS Products

Schedule

FOT Ops Requests

Galaxy Receives

Activity List

Run Sched Algorithms

Special Requests

Cal Requests

LCR

Check Inputs

GOOD

BAD

Update Models as Necessary

Galaxy

CPAW

GNE

STK Scheduler Product Transfer

Process Flow

DPAS

FDS

Figure 4-5 Daily Ops Activity Planning

21 | P a g e

Review Plan Options

Are updates needed

Make Activity Plan Corrections

YES

NOInitiate Planning

LMOC Daily Ops Activity Planning

Receive Input Data

Files

RESOLVED

Generate Master Activity List and SIMT (and STS, IDSR, CCS)

FDS Products

Schedule

FOT Special Ops/ Requests

Galaxy Receives MAL and

SIMT

Run Algorithms &

Generate Plan

Special Requests

Cal Requests

LCR

Check Inputs

GOOD

BAD

Open workspace (L08/L09/ simulator)

Commit plans and transmit all committed

Galaxy

CPAW

GNE

STK Scheduler Product Transfer

Process Flow

DPAS

FDS

Figure 4-6 Activity Planning

G. The Mission Planner collects current planning inputs - (Scheduler Contact File, LCR, SCRs, CalCRs, recorder state, and subsystem command requests and creates a Master

Activity List (MAL) in CPAW for each satellite. The MAL is essentially a deconflicted activity plan that serves as the basis for the satellite command load. A typical MAL will contain instrument commands for image collections or calibrations, data playback commands, and C&DH maintenance commands. The standard MAL duration for both spacecraft is 96 hours. In parallel to the MAL, the CPAW software generates the SIMT, STSs, IDSR and CCSs.

H. The Mission Planners internally review the plan.

I. If an issue with the plan has been identified, the planning team will “save” the plan, and

J. Start the rework and recycle to step G.

K. If no issues are identified, the planning team marks the plan as “transmit” and

L. Delivers the products to the “Delivery” directory.

M. Mercury will detect that the MAL has been delivered and start the offline Galaxy compile.

N. Galaxy uses the Stored Command Sequence (SCS) compiler to reformat the MAL for each satellite into binary load by using the Galaxy command database to convert instructions. The SCS also generates text versions of the command loads for operations review and checks. Text versions of the command load are then used as inputs to the operations load checking script. The load checker examines the load for configurations, values, and event conflicts which should be avoided.

O. The outputs from SCS (binaries and text versions) and the load checker for each individual satellite are grouped together and collected by Mercury for operations review and signature.

22 | P a g e

Galaxy

CPAW

GNE

STK Scheduler Product Transfer

Process Flow

DPAS

FDS

MP

Review

Resolve Schedule

Errors

FAIL

PASS

To MPS Daily Ops Activity Planning (FOT initiate planning)

MAL

SIMT

Build Loads

FOT

Review

PASS

Staged on ROC

Uplink/Ingestion

FOT

AWT

Figure 4-7 Load Generation

P. The Mission Planning team does a final review and if approved, forwards to the FOT for review. If the load is rejected, the process cycles back to step G.

Q. The FOT reviews and if approved…

R. The FOT copies the load to the Real-time Operations Console (ROC). If they reject the load, the process cycles back to step G. Typical required review and signatories include a

Spacecraft Engineer and an Operations Engineer.

S. Ideally, a command load is delivered to a Real-time Operations Console 3 uplink passes before UTC day change. Depending on the time of year this would be approximately 2 p.m. or 3 p.m. local time. The Operations Engineer either manually, or the ROC autonomously uplinks the load to the S/C.

Command loads that have been uplinked to the satellite will sit in an inactive buffer in FSW until

UTC day change. At this point the active and inactive command buffers will swap and the new command products will become active. As mentioned earlier, command products contain a minimum of 72 hours of commands, so a new command load is not required to be uplinked daily.

23 | P a g e

FriThuWedTueMon Sat Sun Mon

3 day load

3 day load 3 day load

3 day load

B uf fe r

A B uf fe r B

3 day load

3 day load

3 day load

3 day load

B u ff e r

S w it ch

B u ff e r

S w it ch

B u ff e r

S w it ch

B u ff e r

S w it ch

B u ff e r

S w it ch

B u ff e r

S w it ch

B u ff e r

S w it ch

Build

Uplink

Build

Uplink

Build

Uplink

Build

Uplink

Build

Uplink

Build

Uplink

Build

Uplink

Build

FriThuWedTueMon Sat Sun Mon

4 day load

4 day load

B uf fe r

A B uf fe r B

4 day load

B u ff e r

S w it ch

Build

Uplink

Build

Uplink

B u ff e r

S w it ch

Mission Operations Concept baseline – Daily load building and uplink

Mission Operations Concept goal: Monday-Thursday loads

Figure 4-8 Load Building, Uplink and Operation

Figure 4-8 shows the baseline plan for LMOC load building, uplink and operation on spacecraft buffers (top), and the eventual goal of building, uplinking and operating loads twice a week

(bottom). The baseline plan is driven from L8 Mission Planning heritage, whereby a load is built on day 1, uplinked on day 2, and run on day 3. In this baseline, loads are built and uplinked every day and a buffer switch also occurs every day at approximately 00:00 UTC, to a stored command load on the other buffer. The Mission Operations Concept goal reduces the amount of loads built to two four-day loads per week, per spacecraft. A stored command margin of one day will always be preserved onboard.

24 | P a g e

Typically, each satellite will take one GNE contact per 90 minute orbit. Since the L8 and L9 satellite orbits are 180 degrees out of phase they will never be in contact with the same ground station at the same time after L9 exits the LEO&C phase. It is possible, however, for each satellite to be in contact with the ground at the same time on different ground stations. Each satellite will have a separate Real-time Operations Console (ROC) with a schedule executer and file accounting instance to ensure a designated command path and pass automation is available for each satellite at all times.

Each satellite ROC will run automation that will configure for and execute nominal GNE NEN pass operations. A unique MDF is delivered to each satellite ROC which contains the pass times scheduled as part of the daily load processes associated with that satellite. At day change the

ROC schedule executer activates the newest MDF for cueing pass operations. The MDF contains the AOS and LOS times for pass times associated with the corresponding command load. Schedule Executer on the ROC uses the AOS and LOS times within the MDF to kick off ground automation procs used for ROC pre-pass configuration, automated real-time commanding, and ROC post-pass configuration teardown.

Prior to a scheduled ground contact on the GNE/NEN, the MDF and Schedule Executer will kick off ground automation procs which configure and establish links to the ground station, configure the command encryption hardware, and open a new log. After AOS ground automation will issue a NOOP command to the satellite to verify command link, then proceed with issuing retransmits and performing commanding/product uplink required for MDM. During the pass, the active command load on the satellite will play back science data and back-orbit housekeeping data. After LOS the links to the station are terminated, the GALAXY log is closed, and a post-pass report is created.

Pass automation is nominally active on both the L8 and L9 ROCs at all times, but is monitored closely by the Operations Engineer (OE). The OEs are responsible for monitoring automation and resolving any noted issues with ROC configuration, links to GNE/NEN/SN stations, and automation. Occasionally commands that are not part of nominal automation must be issued.

Command procs which require execution are submitted via a Command Request (CR) and must obtain approval signatures. Once CR approval is obtained the OE will coordinate with the requestor and execute the desired command procedure at a coordinated time.

A bank of Galaxy workstations will be located in the LMOC for spacecraft engineering use.

When in contact with an observatory, telemetry can be forwarded from the ROC to Galaxy workstations and other subsystems.