![](media/image1.wmf){width="8.625in" height="0.9777777777777777in"}

> **LANDSAT DATA CONTINUITY**
>
> **MISSION (LDCM)**
>
> **Operations Concept DOCUMENT**
>
> **VERSION 0**
>
> **oCTOBER 2006**
>
> DRAFT

NOT A REQUIREMENTS DOCUMENT

![](media/image3.png){width="1.25in" height="1.03125in"}

**LDCM Operations Concept**

**[Signature Page]{.underline}**

+----------------------------------+-----------------------------------+
| ***Prepared by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_\_\_               | \_\_\_\_\_\_\_\_\_                |
|                                  |                                   |
| Vicki Zanoni Date                | Jason Williams Date               |
|                                  |                                   |
| LDCM Data Systems and Operations | LDCM Flight Operations Segment    |
| Manager                          | Lead Systems Engineer             |
|                                  |                                   |
| NASA GSFC Code 581               | SAIC, contractor to USGS EROS     |
+----------------------------------+-----------------------------------+
| ***Reviewed by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_\_\_               | \_\_\_\_\_\_\_\_\_ Tom Kalvelage  |
|                                  | Date                              |
| Evan Webb Date                   |                                   |
|                                  | LDCM Chief Engineer               |
| LDCM Mission Systems Engineer    |                                   |
|                                  | USGS EROS                         |
| NASA GSFC Code 599               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_\_\_               | \_\_\_\_\_\_\_\_\_                |
|                                  |                                   |
| William Anselm Date              |                                   |
|                                  |                                   |
| LDCM Observatory Manager         |                                   |
|                                  |                                   |
| NASA GSFC Code 427               |                                   |
+----------------------------------+-----------------------------------+
| ***Approved by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_\_\_               | \_\_\_\_\_\_\_\_\_ Mike Hedley    |
|                                  | Date                              |
| William Ochs Date                |                                   |
|                                  | LDCM Project Manager              |
| LDCM Project Manager             |                                   |
|                                  | USGS                              |
| NASA GSFC Code 427               |                                   |
+----------------------------------+-----------------------------------+

LDCM Operations Concept

Table of Contents

[1 Introduction 5](#introduction)

[1.1 Purpose 5](#purpose)

[1.2 Scope 5](#scope)

[1.3 Background 5](#background)

[1.4 LDCM Mission Objectives 6](#ldcm-mission-objectives)

[1.5 Roles and Responsibilities 6](#roles-and-responsibilities)

[1.6 Document Organization 7](#document-organization)

[1.7 Reference Documents 7](#reference-documents)

[2 System Concept 8](#system-concept)

[2.1 Space Segment 8](#space-segment)

[2.2 Flight Operations Segment 9](#flight-operations-segment)

[2.3 Data Processing and Archive Segment
9](#data-processing-and-archive-segment)

[2.4 Launch Segment 9](#launch-segment)

[2.5 LDCM System Interfaces 9](#ldcm-system-interfaces)

[2.6 Primary Internal & External User Interfaces
11](#primary-internal-external-user-interfaces)

[3 Functional View of Operational Concept
12](#functional-view-of-operational-concept)

[3.1 Space Segment 12](#space-segment-1)

[3.1.1 Observatory 12](#observatory)

[3.1.2 Observatory Simulator 16](#observatory-simulator)

[3.1.3 Ground Support Equipment 16](#ground-support-equipment)

[3.2 Flight Operations Segment 16](#flight-operations-segment-1)

[3.2.1 Collection Activity Planning Element
16](#collection-activity-planning-element)

[3.2.2 Mission Operations Element 18](#mission-operations-element)

[3.2.3 LDCM Ground Network Element 21](#ldcm-ground-network-element)

[3.2.4 International Cooperators (ICs) Interface
21](#international-cooperators-ics-interface)

[3.2.5 NASA Space Network (SN) Interface
22](#nasa-space-network-sn-interface)

[3.2.6 NASA Ground Network (NGN) Interface
22](#nasa-ground-network-ngn-interface)

[3.3 Data Processing and Archive Segment
22](#data-processing-and-archive-segment-1)

[3.3.1 Storage and Archive Element 22](#storage-and-archive-element)

[3.3.2 Image Processing Element 23](#image-processing-element)

[3.3.3 User Portal Element 24](#user-portal-element)

[3.4 Launch Segment 24](#launch-segment-1)

[3.4.1 Launch Vehicle 24](#launch-vehicle)

[3.4.2 Launch Vehicle Ground Support Equipment (LV-GSE)
25](#launch-vehicle-ground-support-equipment-lv-gse)

[4 Logistics Support and Sustaining Engineering
25](#logistics-support-and-sustaining-engineering)

[4.1 Logistics Support 25](#logistics-support)

[4.1.1 Facilities 25](#facilities)

[4.1.2 Security 26](#security)

[4.1.3 Training 26](#training)

[4.1.4 Management Support 26](#management-support)

[4.2 Sustaining Engineering 26](#sustaining-engineering)

[5 Operational Phases and Scenarios
28](#operational-phases-and-scenarios)

[5.1 Pre-Launch 28](#pre-launch)

[5.2 Launch and Early Orbit 30](#launch-and-early-orbit)

[5.3 Commissioning 31](#commissioning)

[5.4 Operations 32](#operations)

[5.4.1 Daily Activity Scheduling Mission Scenario (LDCM-01)
33](#daily-activity-scheduling-mission-scenario-ldcm-01)

[5.4.2 Collect Imaging Sensor Data (LDCM-02)
35](#collect-imaging-sensor-data-ldcm-02)

[5.4.3 Flight Software Upload Scenario (LDCM-03)
37](#flight-software-upload-scenario-ldcm-03)

[5.4.4 User Query Order and Product Distribution Scenario (LDCM-04)
38](#user-query-order-and-product-distribution-scenario-ldcm-04)

[5.4.5 Monitor Health & Safety (LDCM-05)
40](#monitor-health-safety-ldcm-05)

[5.4.6 Priority Scene Acquisition & Delivery (LDCM-06)
41](#priority-scene-acquisition-delivery-ldcm-06)

[5.4.7 Maintain Orbit (LDCM-07) 45](#maintain-orbit-ldcm-07)

[5.4.8 IC Scheduling and Delivery (LDCM-08)
48](#ic-scheduling-and-delivery-ldcm-08)

[5.4.9 Communications with the SN (LDCM-09)
50](#communications-with-the-sn-ldcm-09)

[5.4.10 Safehold/Autonomous Failsafe Occurrence and Recovery Mission
Scenario (LDCM-20)
51](#safeholdautonomous-failsafe-occurrence-and-recovery-mission-scenario-ldcm-20)

[5.4.11 Non-Autonomous Anomaly Correction (LDCM-21)
52](#non-autonomous-anomaly-correction-ldcm-21)

[5.4.12 Retransmission (LDCM-22) 54](#retransmission-ldcm-22)

[5.4.13 Backup Flight Operations 55](#backup-flight-operations)

[5.5 Decommissioning 56](#decommissioning)

[6.0 Design Reference Case 56](#design-reference-case)

[Appendix A: Potential List of International Cooperator Ground Stations
58](#appendix-a-potential-list-of-international-cooperator-ground-stations)

[Appendix B: Design Reference Case
59](#appendix-b-design-reference-case)

# Introduction

The Landsat Data Continuity Mission (LDCM) is a joint mission being
formulated, implemented, and operated by the National Aeronautics and
Space Administration (NASA) and the Department of Interior (DOI) United
States Geological Survey (USGS). The LDCM is a remote sensing satellite
mission providing coverage of the Earth's land surfaces. This mission
continues the 33+ years of global data collection and distribution
provided by the Landsat series of satellites.

## Purpose

The primary purpose of the LDCM Operations Concept (OpsCon) document is
to provide a description of the planned functions and operations of the
LDCM System comprised of space and ground assets. The OpsCon is not a
requirements document and does not contain LDCM requirements. Rather,
the OpsCon presents a functional view of the LDCM system and operations
based on high level program guidance. It represents the operational
approaches used to develop and set context for mission and segment
requirements. Functions and scenarios described in this OpsCon are not
intended to imply design or implementation approaches for the specific
elements comprising the LDCM System.

## Scope

The scope of the OpsCon includes all functions associated with the LDCM
System as well as those external entities that interact with the LDCM
System. Thus, the OpsCon encompasses the collection of image data by the
observatory, transmission of data to the ground, and processing,
archival, and distribution of the data for the Landsat data user
community.

## Background

The Landsat Data Continuity Mission (LDCM) is a component of the Landsat
Program conducted jointly by the National Aeronautics and Space
Administration (NASA) and the United States Geological Survey (USGS) of
the Department of Interior (DOI). The goal of the LDCM is to continue
the collection, archival, and distribution of multi-spectral imagery
affording global, synoptic, and repetitive coverage of the Earth\'s land
surfaces at a scale where natural and human-induced changes can be
detected, differentiated, characterized, and monitored over time. The
LDCM goal is in keeping with the Landsat programmatic goals stated in
the United States Code (USC) Title 15, Chapter 82 "Land Remote Sensing
Policy" (derived from the Land Remote Sensing Policy Act of 1992). This
policy requires that the Landsat Program provide data into the future
that is sufficiently consistent with previous Landsat data to allow the
detection and quantitative characterization of changes in or on the land
surface of the globe. The LDCM was conceived as a follow-on mission to
the highly successful Landsat series of missions that have provided
satellite coverage of the Earth's continental surfaces since 1972. The
data from these missions constitute the longest continuous record of the
Earth's surface as seen from space.

The LDCM is intended to ensure that Landsat-like data will be provided
to the USGS National Satellite Land Remote Sensing Data Archive
(NSLRSDA) for at least 5 years.

## LDCM Mission Objectives

The major mission objectives are as follows:

-   Collect and archive medium resolution (*circa* 30 m spatial
    resolution) multi-spectral image data affording seasonal coverage of
    the global land mass for a period of no less than five years.

```{=html}
<!-- -->
```
-   Ensure that LDCM data are sufficiently consistent with data from the
    earlier Landsat missions, in terms of acquisition geometry,
    calibration, coverage characteristics, spectral characteristics,
    output product quality, and data availability to permit studies of
    land cover and land use change over multi-decadal periods.

-   Distribute LDCM data products to the general public on a
    nondiscriminatory basis and at a price no greater than the
    incremental cost of fulfilling a user request.

## Roles and Responsibilities

NASA and USGS, as Landsat Program Management, will share the overall
responsibility of fulfilling the LDCM mission objectives and all
subsequent requirements. The roles and responsibilities related to this
OpsCon are as follows:

NASA will

-   Acquire and manage the development of the LDCM Space Segment and
    Mission Operations Element

-   Acquire and manage the LDCM Launch Segment and services;

-   Serve as LDCM mission integrator

-   Manage the LDCM observatory (integrated spacecraft and imaging
    sensor(s)) on-orbit operations from launch through on-orbit
    acceptance; and

-   Transition LDCM mission operations capabilities and observatory
    operational and maintenance responsibility to USGS, following
    on-orbit acceptance.

USGS will:

-   Manage the development and operation of the LDCM Data Processing,
    and Archive Segment;

-   Manage the development and operations of the LDCM Ground Network;

-   Manage the development and operations of the LDCM imaging sensor(s)
    Collection Activity Planning Element

-   Operate the LDCM observatory following on-orbit acceptance; and
    throughout the life of the mission.

## Document Organization

Section 1 of the document provides the introduction to the LDCM and this
Operational Concept Document. Section 2 provides a high level overview
of the LDCM System. Section 3 describes the LDCM operational concept as
a series of segments and functions, sufficient to understand the system
capabilities and interfaces. Section 4 presents an overview of the
logistics support and sustaining engineering that will be provided to
the LDCM. Section 5 describes the operational phases of the mission and
illustrates LDCM operational scenarios for selected sequences of events
during the mission life. Section 6 presents a design reference case,
capturing several relevant operational activities conducted during a
series of LDCM orbits.

## Reference Documents

  ---------------- ------------- -----------------------------------------
  **Document       **Revision/   **Document Title**
  Number**         Release       
                   Date**        

  427-xx-xx                      LDCM Acronym List and Lexicon

  427-xx-xx                      LDCM Operational Land Imager (OLI)
                                 Statement of Work

  427-XX-XX                      LDMC OLI Requirements Document

  427-XX-XX        Draft         LDCM Mission Operations Element
                                 Requirements Document

  427-xx-xx                      Special Calibration Test Requirements
                                 (SCTR)

  White paper                    LDCM World Reference System -2

  NPR 2810.1A      May 16, 2006  NASA Procedural Requirement, Security of
                                 Information Technology

  NPD 8710.3B      April 28,     NASA Policy for Limiting Orbital Debris
                   2004          Generation

  NSS 1740.14      August 1995   NASA Safety Standard, Guidelines and
                                 Assessment Procedures for Limiting
                                 Orbital Debris

  NPR 1600.1       November 3,   NASA Security Program Procedural
                   2006          Requirements
  ---------------- ------------- -----------------------------------------

# System Concept

The LDCM System includes all components and capabilities, both space and
ground based, that are under the developmental and operational
responsibility of the LDCM NASA-USGS interagency team. For mission
definition and formulation purposes, the LDCM System is defined at the
highest level in terms of four segments - the Space Segment, Flight
Operations Segment, Data Processing and Archive Segment, and the Launch
Segment. See Figure 2-1. It should be noted that the specific functions
within these segments may change during the implementation phase of the
LDCM.

![](media/image4.png){width="6.425in" height="4.2756944444444445in"}

**Figure 2-1: LDCM System and Operations Concept**

## Space Segment

The Space Segment (SS) consists of the observatory and pre-launch ground
support equipment (GSE). The observatory is comprised of the imaging
sensor(s) and the spacecraft platform. The observatory will operate in a
705 Km orbit with a 16-day repeat cycle and a 10:00 a.m. (+/- 15
minutes) mean local equatorial crossing time. Imaging sensor and
ancillary data (combined as mission data) will be collected, stored
onboard and subsequently downlinked to ground stations within the LDCM
Ground Network via an X-band communications link. Additionally, a
real-time X-band downlink capability will transmit imaging sensor and
ancillary data to the LDCM Ground Network and International Cooperators
(ICs) equipped to receive these data. The observatory will also receive
and execute commands and transmit telemetry. The GSE provides the
functionality to perform ground-based integration and testing of the
observatory prior to launch.

## Flight Operations Segment

The Flight Operations Segment (FOS) includes Collection Activity
Planning functions, the Mission Operations Element, and the LDCM Ground
Network. The Collection Activity Planning Element (CAPE) function
defines the set of images to be collected by the observatory on a daily
basis. The Mission Operations Element (MOE) plans and schedules
observatory activities, commands and controls the observatory, and
monitors the health and status of the observatory and ground operating
systems. The MOE hardware and software systems reside in the LDCM
Mission Operations Center (MOC). There is also a backup MOE (bMOE) which
resides in a geographically separated backup MOC (bMOC). The LDCM Ground
Network (LGN) includes the ground stations that will communicate with
the observatory for commanding and monitoring, and will receive image
data from the observatory. The LGN will also route data between elements
of the FOS and the Data Processing and Archive Segment.

## Data Processing and Archive Segment

The Data Processing and Archive Segment (DPAS) ingests, processes, and
archives all LDCM image data. Storage and Archive Element perform ingest
and long-term archiving. The Image Processing Element processes all data
to create LDCM data products, and performs image assessment. The LDCM
Independent Cal/Val team interacts with the image assessment capability
to assess data quality and update calibration parameters. A capability
to receive and fulfill user requests for LDCM image collections and data
products is provided by the DPAS User Portal Element. The DPAS will be
located at the USGS Center for Earth Resources Observation and Science
(EROS) in Sioux Falls, SD.

## Launch Segment

The Launch Segment (LS) provides those assets and services associated
with the launch vehicle (LV) and the payload integration. Included,
along with the launch vehicle, are all launch vehicle ground support
equipment (including hardware and software), property, and facilities to
integrate the spacecraft to the LV, verify their integration, and
conduct pre-launch testing with ground-based functions.

## LDCM System Interfaces

There are certain external entities that provide information to, or
receive information from the LDCM System.

[NASA Space Network]{.underline}

NASA's Space Network (SN) will provide S-band communications
capabilities for LDCM. The SN Tracking and Data Relay Satellite System
(TDRSS) will provide bi-directional data transmission services between
LDCM and ground receiving stations, using satellite to satellite
communications links to allow communications even when LDCM is not in
view of a ground station. LDCM will utilize the SN during launch and
early orbit for S-band uplink and downlink operations. Following
commissioning, the SN will only be used to support observatory emergency
operations.

[NASA Ground Network]{.underline}

The NASA Ground Network (NGN) includes several satellite ground
receiving stations throughout the world that are available to support
NASA missions. LDCM will interface with a subset of NGN stations for
support during launch and early orbit operations. Following
commissioning, the NGN will only be used in support of observatory
emergencies. The NGN stations will provide S-band services for uplink
and downlink only, no X-band reception.

[External Data Sources]{.underline}

LDCM will utilize certain external data as input to the Flight
Operations Segment and the Data Processing and Archive Segment. These
data will include auxiliary data such as government-provided ground
control data and digital elevation models for terrain correction or
lunar radiance data to support imaging sensor calibration. External data
will also include cloud prediction information used in data collection
scheduling, or other data that are used to operate the mission or
produce LDCM data products.

[]{.mark}

[U.S. Strategic Command (USSTRATCOM)]{.underline}

The U.S. Strategic Command (USSTRATCOM) presently supports NASA'S Space
Network and Earth science missions by performing routine conjunction
assessment. This facility sends a message to the LDCM FOS whenever there
is a possible conjunction with a safety buffer around LDCM. The
conjunction analysis is based upon LDCM state vector information,
provided to the Constellation Coordination System (refer to description
below). There are three levels of warning, with three associated volumes
used for the conjunction analysis.

[Constellation Coordination System]{.underline}

The Constellation Coordination System is an existing utility that
provides easy exchange of orbit data between missions. The LDCM FOT will
upload observatory state vectors to the CCS to support conjunction
analyses performed at USSTRATCOM.

[Earth Science Mission Operations (ESMO)]{.underline}

The ESMO office at NASA GSFC is responsible for the operation of several
NASA Earth science missions. The LDCM orbit will allow LDCM to fly as
part of a morning constellation that includes several ESMO missions, if
they are still operational. (This constellation presently consists of
Landsat 7, Terra, SAC-C.) Any required orbit or maneuver coordination to
maintain this constellation is performed through human interaction with
the ESMO staff and the potential exchange of state vectors corresponding
to satellite orbits.

[NASA Flight Dynamics Facility]{.underline}

The NASA Goddard Space Flight Center maintains a Flight Dynamics
Facility that provides attitude and orbit determination, prediction, and
control services. The LDCM will utilize FDF services during early orbit
and for anomaly resolution activities.

## Primary Internal & External User Interfaces

This section describes the groups and teams that use or interact with
the capabilities of the LDCM.

[User Community]{.underline}

The User Community encompasses all those members of the general public
that use Landsat data for purposes as diverse as scientific research and
operational resource management. The User Community interfaces to the
Data Processing and Archive Segment to search for, browse, order, and
receive LDCM data products, and to request image collections

[International Cooperators]{.underline}

The USGS maintains agreements with several foreign entities (typically,
governmental) referred to as the LDCM International Cooperators (ICs).
The ICs are a special subset of the User Community that has the ability
to receive LDCM data from the observatory real-time downlink stream.
Real-time imaging sensor and ancillary data (including spacecraft,
calibration data, etc.) necessary for processing are contained in the
real-time stream and are received by IC ground stations. The number of
active IC ground stations is not constant. IC ground stations may move
to/from an active condition based upon the state/terms of their
respective Landsat agreement, funding conditions, or the technical
capabilities of the IC ground station. A list of current Landsat 5 and
Landsat 7 ICs is included in Appendix A for reference purposes.

[Flight Operations Team (FOT)]{.underline}

The LDCM Flight Operations Team (FOT) is the team of mission operations
personnel managed by the USGS. The LDCM FOT will use the Flight
Operations Segment to operate the observatory from launch vehicle
separation through the life of the mission.

[Data Collection Planner]{.underline}

The USGS Data Collection Planner (DCP) manages the data collection
schedules for LDCM. The DCP operates the Collection Activity Planning
function within the Flight Operations Segment. The DCP may be an
individual or a team of staff who share the DCP responsibilities.

[Landsat Science Team]{.underline}

The USGS convenes a Landsat Science Team composed of competitively
selected investigators. The Team will conduct research on issues
critical to the success of the LDCM, including data acquisition, product
access and format, practical applications, and science opportunities for
new- and past-generation Landsat data. The Team will offer research and
science support to the USGS on topics that will affect the overall
success of the LDCM mission. The USGS and NASA LDCM Project Scientists
will co-chair the Science Team.

[Independent Cal/Val Team]{.underline}

The Independent Calibration/Validation (Cal/Val) team consists of
discipline scientists and engineers who perform calibration of the LDCM
imaging sensor(s) and data. The Independent Cal/Val Team is
geographically dispersed and includes members from both NASA and USGS.
While the team will advise on and review imaging sensor calibration
activities, they will remain independent from the development
contractor/organization in their calibration assessments through the
life of the mission. NASA leads this team during observatory development
through on-orbit acceptance. Following on-orbit acceptance, this team is
led by USGS. The Independent Cal/Val Team works with members of the LDCM
Science Team on various calibration and validation issues and special
collections of LDCM data.

# Functional View of Operational Concept

The LDCM operational concept is presented in this section as a set of
functions required to operate the LDCM. The allocation of functions to
specific segments and any grouping of functions within segments are
based on experience gained from developing similar systems. However,
this allocation is not meant to constrain the LDCM system architecture
that will be defined later in the development cycle. Therefore, while
the objective of the OpsCon is to capture all necessary functionality of
the LDCM operations, some functions may ultimately be allocated to
different segments at a later time.

## Space Segment

The LDCM observatory and associated GSE make up the Space Segment. The
LDCM observatory consists of the spacecraft and imaging sensor(s).

### Observatory

Planned for a 5 year minimum mission life, the LDCM observatory will
operate in 705 Km sun-synchronous orbit. The observatory will have a
16-day ground track repeat cycle and a 10:00 a.m. (+/- 15 minutes) mean
local equatorial crossing time. This will allow image collections to be
referenced to the second Worldwide Reference System (WRS-2).

The LDCM observatory will perform the standard functions of image data
collection, communications, command and data handling, and attitude and
orbit control. The observatory will receive S-band communications from
LDCM ground stations nominally, and from the SN and NGN during launch
and early orbit or contingency/emergency operations. Commands and
spacecraft software updates received via the S-band communications
stream will be managed on-board, and forwarded to the respective
observatory sub-systems for execution. The observatory will nominally
receive command loads every 24 hours, and each will encompass 72 hours
of observatory activity. If another command load has not been received
at the end of the 72 hour period, the observatory will automatically
enter a safe operational state. The observatory will monitor the health
and status of each sub-system including the imaging sensor(s).
Corresponding housekeeping telemetry will be generated and stored
on-board for future transmission. During contacts with a ground network
station, the stored and real time housekeeping telemetry data will be
downlinked. Stored telemetry data may also be downlinked over the X-band
link.

The observatory will have the ability to generate on-board ephemeris and
manage spacecraft timing. Navigation and attitude sensor data (raw and
processed) will be stored and transmitted as part of the observatory
telemetry. The observatory will be capable of attitude and orbit
adjustments, as commanded by the Flight Operations Segment, to maintain
the WRS-2 and image quality requirements, and to perform required
calibration maneuvers. Power and thermal management functions will also
be performed on-board.

If any of a pre-defined list of anomalies occurs, the observatory will
have the ability to detect the anomaly. If the severity of the anomaly
warrants it, the observatory will automatically place itself in a safe
and protected state until the anomaly is resolved.

The LDCM observatory imaging sensor(s) will nominally collect
multispectral images of the Earth referenced to WRS-2. Additionally, the
observatory will be able to collect off-nadir image data up to one WRS-2
path east and west of observatory ground track, in lieu of imaging the
nadir WRS-2 path. The observatory will collect images of the moon for
imaging sensor calibration. Due to changes in the moon phase, the
observatory will perform lunar calibrations during only two 8-hour long
windows that occur every 28 days. The observatory may also perform
additional instrument or attitude sensor calibrations using on-board
calibration systems or other maneuvers (e.g. gyro calibration maneuver),
if necessary.

The observatory will nominally collect image data equivalent to produce
400 scenes per 24-hour period; this includes any required routine
calibration and housekeeping telemetry data needed for processing the
400 scenes. (It is noted that non-routine events, such as lunar
calibrations, may impact the number of scenes acquired in a given day.)
All WRS-2 scenes are selected and scheduled by the Flight Operations
Segment as described in the next section, and will include data to
support global change research, International Cooperators, special
requests, and all daytime scenes over the United States. Collected WRS-2
scenes are expected to meet image quality requirements. Any off-nadir
image collections are not subject to meeting image quality requirements.

All imaging sensor data will be temporarily stored on board the
observatory. When commanded by the Flight Operations Segment, image data
will be transmitted to the ground via an X-band communications stream.
X-band transmissions will be performed using either an omni or direct
beam antenna architecture. The X-band data stream will contain the image
data and ancillary data, including imaging sensor and select spacecraft
housekeeping telemetry, calibration data, and other data necessary for
image processing. Collectively, the components of the X-band
communications stream are referred to as mission data.

The observatory will transmit X-band data in both playback and real-time
modes to the LDCM ground stations. The observatory will also transmit
real-time X-band data to ICs. All real-time data will also be stored on
board for subsequent downlink to an LDCM ground station. The observatory
will be capable of transmitting to the LDCM ground stations (in
real-time and/or playback modes) the equivalent of at least 400 scenes
and associated calibration data per 24-hour period. The observatory will
also be capable of re-transmitting telemetry and image data if the
original transmission was not properly received.

When communicating with the LDCM ground stations, the observatory will
be capable of performing the following functions concurrently during a
nominal day time contact:

-   Receipt of S-band communications

-   Transmission of real-time housekeeping telemetry

-   Storage of real-time housekeeping telemetry

-   Transmission (playback) of stored housekeeping telemetry

> AND

-   Transmission of real-time mission data

-   Storage of real-time mission data

-   Transmission of one unique (playback) stored mission data stream

> OR

-   Storage of real-time mission data

-   Transmission of up to two unique (playback) stored mission data
    streams

When communicating with the LDCM ground stations, the observatory will
be capable of performing the following functions concurrently during a
nominal night time contact:

-   Receipt of S-band communications

-   Transmission of real-time housekeeping telemetry

-   Storage of real-time housekeeping telemetry

-   Transmission (playback) of stored housekeeping telemetry

-   Transmission of up to two unique (playback) stored mission data
    streams

It should be noted that if any night time imaging sensor data is being
collected during an LGN contact, mission data could be transmitted to
the LGN ground station via one real-time stream and one unique playback
stream during a night time contact.

When communicating with the IC ground stations, the observatory will be
capable of performing the following functions concurrently:

-   Storage of real time housekeeping telemetry

-   Transmission of real-time mission data

-   Storage of real-time mission data

When in view of both an IC ground station and an LGN station
concurrently, the observatory will be capable of performing the
following mission data downlink functions concurrently:

-   Transmission of real-time mission data to an IC station

-   Storage of real-time mission data

> AND

-   Transmission of real-time mission data to the LGN station

-   Transmission of one unique (playback) stored mission data stream to
    the LGN station

> OR

-   Transmission of up to two unique (playback) stored mission data
    streams to the LGN station

Storage and downlink of imaging sensor data on the observatory will be
managed from the ground Flight Operations Segment. The Flight Operations
Segment will schedule imaging sensor data for downlink. Nominally,
oldest data will be downlinked first. However the observatory, as
commanded by the Flight Operations Segment, will downlink priority image
data collections (see section 3.2.1) in advance of non-priority
collections to the first available LDCM ground station. If a priority
image collection is acquired in an IC region, the priority collection
will be real-time downlinked to that IC and stored on-board for priority
downlink to the first available LDCM ground station.

The observatory will be capable of protecting selected imaging sensor
data in observatory mass storage from being overwritten by future image
collections. The protect capability will be applied by the Flight
Operations Segment to selected image collections or to all image data
collected. Nominally, all data will be protected until it has been
successfully downlinked to the ground. Immediately after downlink is
confirmed, likely during the same ground station contact, the
successfully downlinked data will be made available for overwriting via
ground commands. (See Section 3.2.2.5.) If downlink cannot be fully
confirmed, data may remain protected on-board until the next available
LDCM ground station contact. If mass storage capacity is reached when
all data is protected, the observatory will automatically stop storing
any additional data in mass storage. If mass storage capacity is reached
with unprotected data, the observatory will automatically overwrite
oldest data first.

### Observatory Simulator

A key component of the space segment, although resident on the ground,
is the observatory simulator. The observatory simulator simulates the
interaction between the LDCM Mission Operations Element and the actual
LDCM flight observatory with high fidelity. The observatory simulator
will reside in the LDCM mission Operations Center. See section 3.2.2.6
for additional explanation.

### Ground Support Equipment

Both electrical and mechanical Ground Support Equipment (GSE) interfaces
to the LDCM observatory, and are essential to successful observatory
integration and verification. The electrical GSE originates test
commands internally and receives responses from the observatory during
observatory level integration and test. The mechanical GSE is used
during final assembly of the observatory for the installation and
testing of any mechanical components.

A subset of the integration and test GSE will travel to the launch site
to support observatory final preparations for launch. The electrical GSE
at the launch site will be used in the payload process for launch as
well as during the launch count down to place LDCM observatory in its
final launch configuration.

## Flight Operations Segment

The LDCM Flight Operations Segment (FOS) includes all of the
ground-based assets needed to operate the LDCM observatory. The primary
components of the FOS are the Collection Activity Planning Element;
Mission Operations Element; and the LDCM Ground Network.

The overall activity planning for the mission is split between the
Collection Activity Planning Element (CAPE) and the Mission Operations
Element (MOE). The CAPE schedules activities on a path-row scene basis.
The MOE schedules all the detailed observatory activities and generates
commands necessary to acquire the identified scenes and operate the
observatory. The MOE schedules activities such as orbit maneuvers and
identifies these to the CAPE as periods where science data collection
cannot occur.

### Collection Activity Planning Element

The FOS Collection Activity Planning Element functions build and manage
collection activity requests for the LDCM imaging sensor(s). The
collection activity requests include:

-   Imaging requests to support the LDCM Global Mission Acquisition Plan
    (GMAP), which provides requirements for Earth land imagery
    collections based on seasonality, cloud climatology, and other
    factors.

-   International Cooperator imaging requests

-   All daytime imaging sensor data over the United States, regardless
    of cloud cover

-   Imaging sensor calibration activities, such as lunar calibrations.

-   Special imaging requests

Daily cloud cover predictions from the National Center for Environmental
Prediction (NCEP) are input to the CAPE functions to identify the best
opportunities to collect cloud-free images. Factoring in cloud cover and
any observatory resource constraints provided by the MOE, the CAPE
de-conflicts the requests and develops the collection activity request.
The CAPE will assign each scene or imaging sensor(s) activity in the
request a unique identifier. The unique identifies will be shared with
the Mission Operations Element and the Data Processing and Archive
segment so that every scene can be tracked throughout the entire
planning, collection, and production process.

The collection activity request is optimized to meet a maximum number of
requests while fulfilling the GMAP requirements. The criteria for
prioritizing collection requests will be defined and documented within
CAPE operating procedures. The CAPE will nominally generate a collection
activity request every 24 hours, and each request will encompass up to
72 hours of activities. Collection activity requests may be generated
more frequently in response to time-critical special requests (priority
requests) or other special circumstances.

Special imaging requests, such as for natural disasters or to support
unique science research campaigns, are forwarded to the LDCM Data
Collection Planner (DCP) -- a USGS team member(s) responsible for
coordinating and approving special requests. The DCP interacts with the
CAPE functions of the FOS. The Data Collection Planner evaluates the
special requests using the prioritization criteria and determines
whether or not they will be scheduled for collection. Certain special
requests, called priority requests, are those time-critical image
collections of national or international interest (e.g. natural
disasters). Priority requests are flagged by the DCP to be expedited
through the entire image collection and production process.

The DCP may flag selected image collection requests for protection. The
DCP may request protected data to be re-downlinked if it has not been
successfully received. The DCP may also remove the protect flag in
certain cases where the DPAS confirms successful data receipt following
cursory image quality checks. The flagging (or unflagging) of priority
and protected data is included within the collection activity request
provided by the CAPE to the MOE.

### Mission Operations Element

The FOS Mission Operations Element includes four primary functions;
Planning and Scheduling; Command and Control; Flight Dynamics; and
Trending and Analysis. Additional mission operations functions of flight
software and mass storage management are also performed by the MOE. The
capabilities to perform these functions will physically reside in the
Mission Operations Center (MOC), a government-provided facility located
at TBD.

A limited number of MOE functions will be available through remote
access. Remote access to selected MOE functions will allow FOT members
or observatory engineering support staff to support operations without
being present in the MOC. Observatory commanding will *not* be performed
via remote access.

#### Planning and Scheduling

Planning and Scheduling (P&S) functions will plan/coordinate and
schedule observatory and ground station activities. Key inputs to this
function are the collection activity requests developed by the CAPE.
Upon receipt of the collection activity request, the MOE will assign
imaging sensor activities to imaging intervals -- periods of time when
imaging sensor data is acquired. Imaging intervals will be assigned a
unique identifier and the MOE will maintain an imaging sensor data
collection (e.g. scene) to interval mapping table. Any collections
marked as priority will be managed and tracked within the MOE for
expedited downlink. Any collections marked as protected will be
identified within the observatory commands so as to be protected from
overwriting in observatory mass storage. The MOE will be able to remove
priority and protected flags based on input from the CAPE.

In addition to the CAPE collection activity requests, P&S will plan and
schedule

-   Observatory activities such as orbit adjustments, routine
    calibrations, maneuvers, and housekeeping data downlinks

-   Downlink of imaging sensor(s) data, including the downlink of
    priority data in advance of non-priority to the first available LDCM
    ground station and re-downlink of data

-   Ground station contacts including those to the LDCM Ground Network,
    ICs, and those performed through the SN and NGN.

-   Ground network activities required to transfer data between ground
    stations and the MOE or DPAS.

-   Implementation / upload of flight software updates

In order to develop activity plans and schedules, the MOE will also
perform activity management functions such as activity prioritization,
activity resource allocation, and allocation of operational constraints.
Additional resource management will also be performed by the MOE
including keeping track of ground systems hardware and software
downtimes and preventive maintenance.

[]{.mark}

Incorporating the collection activity requests, the P&S functions will
plan and schedule observatory activities, perform constraint checking
and schedule de-confliction, and generate the observatory activity
schedule. Planning and Scheduling will nominally generate an activity
schedule every 24 (TBR5) hours, and each schedule will encompass 72
(TBR6) hours of observatory operations[.]{.mark} Activity schedules may
be generated more frequently in response to priority requests or other
special circumstances. Activity schedules will be provided to the CAPE,
DPAS, and LDCM ground stations for feedback/planning purposes.

#### Command and Control

The MOE Command and Control functions build command loads for
transmission to the observatory. Command loads are built to implement
observatory activity schedules and flight software updates. Observatory
activity schedules will be received from the P&S function. Nominal daily
command loads will be automatically rule- and constraint- checked prior
to uplinking. Commands will be encrypted and routed to the LDCM Ground
Network or through the SN or NGN for transmission to the observatory.
Commands will only be generated from a single MOC terminal at any given
time. I.e. only one FOT member resident in the MOC will have the ability
to command the observatory at any given time.

The Command and Control functions will monitor the LDCM observatory
beginning with the receipt of real-time (RT) and stored housekeeping
telemetry from the LDCM Ground Network or through the SN or NGN.
Housekeeping telemetry will be monitored and limit checked. Out of limit
values will trigger visual indicators, alarms, or other notification
(e.g. paging) of the Flight Operations Team (FOT).

#### Flight Dynamics

The MOE Flight Dynamics functions include

-   Orbit analysis and propagation

-   Maneuver planning in order to support orbit maintenance, off-nadir
    imaging, calibration, and decommissioning maneuvers

-   Calibration of any observatory on-board attitude sensors or
    propulsion components

```{=html}
<!-- -->
```
-   Generation of predicted ground station and SN contact/view periods

-   Processing of on-board ephemeris and predicted ephemeris generation

#### Trending and Analysis

All housekeeping telemetry for the mission will be stored on or near
line by the MOE to support Trending and Analysis functions. A suite of
analysis tools within the MOE will be used by the FOT and engineers to
perform long-term trending, analysis, anomaly investigation, etc. With
these functions, FOT personnel can generate automated and user-definable
statistics, plots, and reports. The MOE will also send processed
housekeeping telemetry data to the DPAS for use in image processing and
image assessment.

#### Flight Software and On-board Mass Storage Management

Modifications or updates to observatory flight software will be
performed by the development contractors/organizations for the
spacecraft and imaging sensor(s). Flight software modifications/updates
will be provided to the MOE for upload to the observatory. All flight
software updates will be tested first on the observatory simulator prior
to upload to the flight observatory. The MOE will maintain version
control of the observatory flight software.

The MOE will manage the observatory mass storage by monitoring mass
storage utilization, scheduling data in mass storage for downlink and by
monitoring the downlink of imaging sensor data through data receipt
status messages received from the LGN ground stations. Imaging sensor
data that has been received by the LGN station will be commanded by the
MOE to be unprotected and available for overwriting in observatory mass
storage.

#### MOE Interface to Simulator

The LDCM Observatory Simulator will be integrated within the LDCM MOC
and will interface directly to the MOE. The LDCM Observatory Simulator
will be used by the FOT to simulate interactions between the MOE and the
flight LDCM Observatory. It will be a high fidelity observatory
simulator that receives and executes commands, and generates simulated
resulting telemetry for analysis by FOT personnel. It accurately
simulates the capabilities of the observatory and its subsystems.

During operations, the observatory simulator will be used, at a minimum,
for the following:

-   FOT training

-   Maneuver rehearsals and validation

-   Flight software updates testing and validation

-   Anomaly investigation and resolution

#### Autonomy

During nominal operations, the MOE will be staffed with a single, 5
days/week, 8-hour shift of no more than 5 (TBR) operators. The MOE will
also have the capability to support unattended operations for up to 72
hours. Unattended operations include contacts with ground stations,
downlink of housekeeping and imaging sensor data, real-time monitoring
of the housekeeping telemetry data, monitoring of imaging sensor data
receipt acknowledgements, and commanding to unprotect received imaging
sensor data. The MOE system will be capable of autonomously monitoring
MOE operations and MOE system health.

Any mission-critical anomalies detected in housekeeping telemetry or
within the MOE system will cause the MOE to autonomously activate a
notification and call-in system for the FOT. Autonomous mission
operations capabilities will not be used early in the mission, during
maneuvers, or other times of increased risk.

#### Backup MOE and Backup MOC

The FOS will include a backup MOE (bMOE). The bMOE will have all the
capabilities of the MOE, with the exception of its interface to the
observatory simulator. The bMOE will be located in a backup MOC facility
at a location geographically separated from the primary MOC, so that it
can serve as a backup in the event of a critical failure, malicious
attack, or natural disaster at the primary MOC facility. The location of
the bMOC is TBD. The primary MOE will routinely share/update command and
control data and information with the bMOE so that the bMOE can assume
operations of the LDCM with no risk to mission health and safety, and
minimal impact to image data collection.

### LDCM Ground Network Element

The FOS includes a ground-based capability for communicating with the
observatory, called the LDCM Ground Network. The LDCM Ground Network is
comprised of two nodes located at Sioux Falls, SD and Fairbanks, Alaska
(TBC). These stations will be fully dedicated to LDCM. A third station
at TBD location will be used as a backup.

Each node in the LDCM Ground Network includes a ground station that will
be capable of receiving LDCM X-band data. Additionally, each station
provides complete S-band uplink and downlink capabilities. These enable
the Mission Operations Element to interface to the observatory. During
an X-band mission data downlink event, the LGN ground station will
monitor the downlink and provide the MOE, in near real time, a status of
mission data that was successfully received by the ground.

The LDCM Ground Network includes a data routing capability. This allows
the transfer of X-band imaging sensor data to the DPAS and the transfer
of commands/telemetry between the nodes and the MOE in a secure manner.
Each LGN node will cache data received for a fixed period of time in
case the data must be re-sent to the MOE or DPAS.

### International Cooperators (ICs) Interface

The LDCM International Cooperators (ICs) will be capable of receiving
real-time downlinks of X-band imaging sensor data. ICs will submit
requests for imaging sensor data collections and downlinks to the CAPE.

### NASA Space Network (SN) Interface

The LDCM will interface to the NASA Space Network (SN) Tracking Data
Relay Satellite System (TDRSS). This interface will be used for S-band
communications during the launch and early orbit of the LDCM
observatory, and potentially for emergencies / critical maneuvers /
anomaly resolution following commissioning. The LDCM Flight Operations
Segment MOC and MOE will interface to the SN through the SN White Sands
Complex (WSC) in Las Cruces, NM. The WSC will perform S-band
communications directly with the SN satellites. Link service requests
and real-time messaging will be transferred between the WSC and the MOE.
The scheduling of SN capabilities will be performed through the SN
scheduling tools resident in the MOC.

### NASA Ground Network (NGN) Interface

The LDCM will interface to the NASA Ground Network (NGN). This interface
will be used for S-band communications during the launch and early orbit
of the LDCM observatory, and potentially for emergencies / critical
maneuvers / anomaly resolution following commissioning. The LDCM will be
compatible with the following NGN stations:

-   Norway -- SGS

-   Wallops, Virginia 11.3m -- WGS 11.3m

-   McMurdo, Antarctica -- MGS

-   Poker Flat, Alaska -- AGS

The LDCM Flight Operations Team will schedule NGN resources through the
White Sands Complex (WSC) scheduling system called Wallops Orbital
Tracking Information System (WOTIS). NGN stations will receive S-band
communications form the observatory and route them to the MOE.

## Data Processing and Archive Segment

The Data Processing and Archive Segment (DPAS) includes those functions
related to ingesting, archiving, calibration, processing, and
distribution of LDCM data and data products.

### Storage and Archive Element

The Storage and Archive Element receives all LDCM mission data from the
Flight Operations Segment LGN for archival. LDCM mission data are made
available to the image processing function and pre-processed into a
format for archival (refer to section 3.3.2).

The Storage and Archive Element archives all LDCM data. The LDCM data
includes LDCM mission data (imaging sensor(s) and ancillary data),
auxiliary data, and mission related data (e.g. engineering and
pre-launch test data, development and engineering documentation from all
phases of the program). Auxiliary datasets include Digital Elevation
Models (DEMs), water mask datasets, and ground control datasets. The
total volume of the data archived is nominally 600 GB per day or 1 PB
for a five year mission. A copy of all housekeeping data is also
archived in the Storage and Archive Element for easy access by cal/val
team members.

In addition, the Storage and Archive Element:

-   Maintains the safety and integrity of all archive media, including
    the management of an offsite copy of all archived LDCM data.

-   Maintains an archive database \-- metadata information that
    describes all LDCM data in the archive. The mission database is used
    as a data inventory.

### Image Processing Element

The Image Processing Element includes all processing functions within
the DPAS. This includes processing data for archival and generating data
products.

The Image Processing Element generates browse imagery and metadata for
all image collections stored in the LDCM archive. Additionally, all
imaging sensor data is processed to ascertain quality assessment
information. This processing includes verifying any checksum fields,
estimating bit error rate, performing limits checking on metadata
parameters, etc. A quality assessment process also includes a visual
inspection step performed by operations staff. Cloud cover scores, and
other information are also generated.

The Image Processing function extracts archived data granules, prior to
delivery, for other requesting DPAS functions. The extraction activity
may include extracting/combining data for a requested time interval,
extracting only a certain set of bands, creating a seamless granule,
etc. The image processing function generates all the LDCM data products
distributed by the DPAS. This includes generation of Level 0 and Level 1
products.

The Image Processing Function ensures that the LDCM data products meet
all the radiometric, geometric and spatial performance requirements.
This function uses stored data from the DPAS Storage and Archive
Function to generate calibration parameters. The calibration parameters
are used by the Image Processing Function to generate data products
which meet performance requirements.

The Image Processing Function provides the capability to characterize
LDCM products for radiometric, spatial and geometric performance. This
refers to both Level 0 LDCM data and to all the Level 1 products
generated by the Image Processing Function. This function also performs
analysis of LDCM archive data (both sensor data and telemetry) to
extract detector-level statistics and various calibration-related
parameters and data.

The Image Processing Function has a critical human-in-the-loop element.
The LDCM Independent Calibration and Validation (Cal/Val) Team oversees
all calibration performed by this function. The Independent Cal/Val Team
members, both NASA and USGS, perform analysis of calibration data and
collectively decide on updates to LDCM calibration parameters and on the
need for observatory calibration maneuvers and calibration data
collections. The Independent Cal/Val Team serves in this role for the
life of the mission.

### User Portal Element

The User Portal Function provides the LDCM interface to data users, and
manages the generation and completion of orders for LDCM data products.
(Note that ICs may access the User Portal to order products as well.)
The User Portal includes a discovery capability that allows users to
search for LDCM data products, place orders, request LDCM image
collections, and supports a bulk order capability. The bulk order
capability supports a machine to machine interface to the User Portal.

The User Portal includes financial functions related to billing and
accounting and the exchange of funds for data product sales and returns.

The User Portal provides public access to related LDCM information. This
includes: Calibration reports; calibration data; documentation; data
format descriptions and similar types of information.

## Launch Segment

The Launch Segment consists of the Launch Vehicle (LV) and the
associated facilities, equipment and services needed to place the LDCM
observatory into orbit.

The LDCM will be launched from the Western Range at the Vandenberg Air
Force Base (VAFB) located near Lompoc, California. The LDCM space
segment will be transported to VAFB to prepare for launch. A payload
processing facility (PPF) will be assigned at VAFB to support the final
observatory integration and test activities required before launch.

### Launch Vehicle

The LDCM launch vehicle and associated launch services will be procured
by NASA's Kennedy Space Center (KSC). The LV will be a Delta II
7320-10C. The LV will be delivered to the launch site at VAFB. The LDCM
observatory will be mated to the LV at the launch site.

### Launch Vehicle Ground Support Equipment (LV-GSE)

The launch vehicle ground support equipment (LV-GSE) are those
mechanical, electrical, communications, propulsion, and monitoring
equipment needed to provide launch base services for the LDCM launch.
The majority of the LV-GSE is internally unique to the LV and has few
interfaces to the LDCM. There are several items in the LV-GSE that
affect LDCM operations. These include:

-   Blockhouse console for pre-launch power and commands to the
    observatory, and hard line monitors and telemetry from the
    observatory via the LV umbilical

-   Communications interface equipment to allow command and telemetry
    from the observatory electrical GSE to interface with the
    observatory while it is mated to the LV

-   Observatory handling equipment for mating the observatory to the LV,
    for installation of the fairing, and ensuring a temperature and
    humidity controlled environment

# Logistics Support and Sustaining Engineering

The following logistical and sustaining engineering support will be
provided as part of the LDCM operations.

## Logistics Support

### Facilities

The Facilities Logistics functions provide LDCM physical infrastructure.
The physical infrastructure includes everything needed to operate the
Flight Operations and Data Processing and Archive Segments except for
the information technology infrastructure and the ground station
antennas. A non-inclusive list of items provided as part of the physical
infrastructure is:

-   Power, including backup power

-   Heat and air conditioning

-   Environmental services

-   Buildings, including operating buildings, warehouses, and storage
    areas

-   Facility maintenance

-   Roads

-   Vehicles

-   Construction

-   Foundations for antenna

It is expected that most ground equipment will be located at a USGS
facility, at a facility owned by another organization, or both. In
either case, the LDCM will act as a tenant. Thus LDCM facilities
logistics is primarily a management role -- coordinating with the site
facility manager for facilities needs and funding.

### Security

LDCM security measures will address:

-   Physical security of critical operations facilities such as the
    Mission Operations Center (MOC), backup MOC (bMOC), and ground
    station facilities as specified in the USGS LDCM System Security
    Plan and NPR 1600.1.

-   Information technology (IT) security to ensure secure operations of
    LDCM software or network capabilities as specified in NPR 2810.1A
    and the USGS LDCM System Security Plan, GSFC IP Open Network (IONet)
    Security Plan and the IONet Assets Protection Policy. IT security
    will also include the use of command uplink encryption and
    authentication in LDCM mission operations.

### Training

The LDCM Flight Operations Team (FOT) will be trained and certified to
operate the mission. FOT training will include:

-   Functionality of the observatory (spacecraft and imaging sensor(s))

-   Functionality of MOE software and hardware

-   Operations procedures including launch, early orbit, commissioning,
    nominal, contingency/recovery procedures

Training will take various forms, including exercises to simulate
typical day-in-the-life on-orbit Observatory operations and launch
rehearsals. To the extent possible/practicable, the FOT will be trained
using the system(s) and interfaces that will be used in actual
operations. Where this is not possible equipment that emulates the
interfaces and simulates performance with high fidelity will be used.

### Management Support

Management support will provide all management data needed by the LDCM
team. Management support logistics functions will include:

-   Property management, to be performed in accordance with NASA and
    USGS policies.

-   Configuration management, to be performed in accordance with the
    LDCM Configuration Management Plan.

-   Risk management, to be performed in accordance with the LDCM Risk
    Management Plan. It is intended that risk management will be done
    proactively.

-   Safety, to be consistent with NASA and USGS safety policies, plans,
    and procedures.

## Sustaining Engineering

Sustaining engineering support will be provided throughout the life of
the LDCM and will support the Space Segment, Flight Operations Segment,
and Data Processing and Archive Segment. All sustaining engineering
functions affecting mission operations will be coordinated with the LDCM
FOT to assure that routine support does not interfere with operations.

Sustaining engineering efforts for the Space Segment will address:

1.  Engineering analysis and expertise to support spacecraft and imaging
    sensor(s) post-commissioning operations.

2.  Investigation of on-orbit anomalies that affect spacecraft or
    imaging sensor(s) performance and/or anomalies that threaten
    sensor(s) or spacecraft health and safety.

3.  Maintenance and updating of spacecraft and imaging sensor(s) flight
    software

4.  Maintenance of flight software development environment(s).

5.  Updating of flight software development environment software
    licenses and hardware maintenance contracts

6.  Maintenance of the Observatory simulator and documentation.

7.  Maintenance of imaging sensor(s) EDU components for use in resolving
    on-orbit anomalies.

Sustaining engineering efforts for the Flight Operations Segment (FOS)
will address:

1.  Maintenance and updating of MOE software and licenses, hardware, and
    documentation.

2.  Investigation of anomalies of the Mission Operations Element, CAPE,
    or LGN.

3.  Maintenance and updating of CAPE hardware, software and licenses

4.  Maintenance and updating of LGN equipment

5.  Maintenance of network and IT resources

Sustaining engineering efforts for the Data Processing and Archive
Segment (DPAS) will address:

1.  Maintenance and updating of the Storage and Archive hardware,
    software, and licenses

2.  Maintenance and updating of the Image Processing hardware, software,
    and licenses

3.  Maintenance and updating of the User Portal hardware, software, and
    licenses

4.  Maintenance of network and IT resources

In general, sustaining engineering activities can be grouped as either
software or hardware based. Software sustaining engineering is generally
concentrated on monitoring and maintaining operations; however, software
modifications may also be required to improve operations. It is expected
that the LDCM software will be modular and interoperable so that
upgrades are easily and cost-effectively performed. All operational
software must follow standard procedures and rigorous testing. Defined
software processes will be used and data on how well these processes
perform will be collected and used in improvement efforts.

Potential software upgrades and new programs will be evaluated. When the
decision is made to use either new or an upgraded version of software,
the software will be tested prior to installation. No operational
software will be introduced to the LDCM operational system until after
it has been thoroughly tested using operational data in a high fidelity
simulation environment. Testing and installation of new or modified
software will be performed to ensure transparency and non-interference
to operations.

The precise way that ground hardware sustaining engineering will be done
will be further defined in the FOS and DPAS operations concept
documents. It is expected that the FOS and DPAS architectures will be
modular in nature so that future upgrades are easily performed. The
maintenance of equipment and implementation of new equipment will be
conducted with emphasis on transparency to the FOS and DPAS operations.
The maintenance and installation process will be compatible with the
property management policies referenced in Section 4.1.4.

# Operational Phases and Scenarios

LDCM operations are described within the context of five phases:

-   Pre-Launch

-   Launch and Early Orbit

-   Commissioning

-   Operations

-   Decommissioning

## Pre-Launch

The Pre-Launch phase runs throughout the course of imaging sensor(s),
spacecraft, and ground-based system development, testing, and
integration through the final phase of launch readiness.

In the Pre-launch phase, the LDCM Space Segment spacecraft and imaging
sensor(s) will be designed, developed, and qualified. The LDCM
Independent Cal/Val Team will participate in imaging sensor(s) testing
by performing independent characterization of the radiometric sources
used to characterize the imaging sensors. The Independent Cal/Val Team
will also review imaging sensor calibration/characterization data.

In parallel with the design and development of the space segment, the
design and development of the FOS and DPAS will take place. Imaging
sensor test data and test algorithms will serve as inputs to develop the
algorithms and software in the Image Processing functions within the
DPAS.

Integration and testing (I&T) of each element and segment will be
performed during the Pre-launch phase. MOE to observatory I&T will begin
with interface/compatibility tests between the MOE and spacecraft
communications interfaces and will continue through I&T of spacecraft
and imaging sensor(s). MOE interface testing will also be performed with
the observatory simulator. Approximately one year before launch, I&T of
imaging sensor(s) and spacecraft (observatory I&T) will begin. This will
include environmental qualifications of the observatory. RF
compatibility testing between the observatory and the LDCM Ground
Network, NASA Ground Network, and the SN will also be performed.
Approximately 8-10 months before launch the MOE will be integrated and
tested within the MOC.

Within the FOS and DPAS, element to element I&T will be conducted in the
months leading up to segment-level I&T. Approximately 6 - 7 months
before launch, segment-level FOS I&T and DPAS I&T will begin. FOS I&T
will include interface testing between the CAPE and MOE/MOC, and between
the MOE/MOC and LGN. DPAS I&T will encompass the integration of the DPAS
elements and the interface to Users.

A key component of the Pre-launch phase is the training of the LDCM
Flight Operations Team (FOT). The FOT will be fully trained and
certified to operate the LDCM. Training will include observatory and MOE
operations, and day-in-the life exercises using nominal and contingency
operations procedures. It is expected that FOT training will be
preformed using the actual MOE system(s).

[]{.mark}

LDCM system integration across all segments will take place and will
test the end to end interfaces between the observatory, FOS, and DPAS.
This includes end-to-end testing, occurring approximately 3 months prior
to launch, to demonstrate that the total LDCM system can plan and
execute commands, produce and transmit telemetry, and acquire, deliver,
and process image data in accordance with requirements. End-to-end
testing will utilize the CAPE to generate imaging requests and the MOE
to command the LDCM Observatory to produce a data output that will be
captured to the on-board mass storage recorder for playback to ground
support equipment. The mass storage data will be flowed through the
appropriate ground system elements such as the LGN, MOE, and DPAS, to
demonstrate the transfer and ingest of housekeeping and mission data.
The DPAS will demonstrate the ability to process data through Level 1
data, and make data available to the user community. At least one
end-to-end test will be performed prior to Observatory shipment to the
launch site.

Following successful integration and testing of the LDCM, the
observatory and associated GSE will be prepared for shipping, and then
shipped to the launch site.

The Pre-Launch phase continues with the arrival of the LDCM observatory
at its assigned payload processing facility (PPF) at Vandenberg Air
Force Base (VAFB). Observatory pre-launch activities required before
mating to the launch vehicle are performed at the PPF (e.g. limited
performance tests, cleaning, fueling, etc)..\
\
Following final preparations in the PPF, the observatory will be
transported to the launch complex where it will be mated to the LV.
While mated to the LV, an observatory "aliveness" test will take place
to ensure the observatory is functioning as expected. Observatory
telemetry will be flowed to the MOE, but there will be no live
commanding by the MOE at the PPF or launch complex.

Prior to the LDCM launch, launch dress rehearsals will take place to
fully train and prepare launch teams and LDCM FOT. Launch and operations
procedures will be followed and refined.

## Launch and Early Orbit

The Launch and Early Orbit phase begins with the final countdown to
launch and runs through the early orbit checkout of the LDCM
observatory.

The LDCM launch countdown will begin when the NASA/KSC, launch service
contractor, LDCM 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 preformed 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
instrumented aircraft. After achieving the injection orbit, the LV
releases the observatory. The LDCM FOT assumes full operations of the
LDCM from the MOC after the observatory separates from the LV upper
stage. Following observatory release, the LV will perform a collision
avoidance maneuver.

Early orbit begins at spacecraft separation from the LV. At this point
the launch service contractor will provide the FOS MOE and the NASA
Goddard Space Flight Center 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. []{.mark}

The spacecraft will perform a pre-programmed activation sequence after
separation from the LV to provide power to the observatory and turn on
critical sub-systems. It is anticipated that orbit adjustments will be
made during this phase 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 Goddard Space Flight Center
Flight Dynamics Facility will be available to support these early orbit
activities, if needed.

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 observatory will be capable of
transmitting real-time S-band telemetry to the SN for routing to the FOS
MOE. Additionally, the observatory may begin transmitting real-time
S-band telemetry to the LDCM ground stations and the NASA Ground
Network.

During early orbit, activation of the LDCM imaging sensor(s) begins. The
imaging sensor(s) 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
LDCM ground stations.

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

It is anticipated that early orbit activities such spacecraft checkout,
orbit raising, imaging sensor(s) out-gassing, activation and
decontamination will nominally take place in the first 30 days (TBR)
following launch. Likewise, days 30-60 (TBR) 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

## Commissioning

During on-orbit commissioning and acceptance, the LDCM observatory will
demonstrate that it meets pre-defined performance requirements.
Commissioning will nominally be performed within 90 days after launch
(days 60-90 (TBR)). The Commissioning phase testing will address a
series of performance requirements for the spacecraft and imaging
sensor(s) such as the first complete 16 day operational test, completion
of imaging sensor(s) calibration activities, and development of final
test and performance assessments

In this phase, the LDCM FOT will continue to operate the LDCM from the
MOC. Additional operational activities include:

-   CAPE functions of preparing acquisition plans to collect imaging
    sensor(s) data

-   receiving these data via the Landsat Ground Network

-   DPAS processing of image data

-   Storage of data within DPAS

The commissioning activities will include those imaging sensor data
acquisitions and spacecraft activities required to complete observatory
on-orbit testing. This will include, but not be limited to, the required
calibration activities/maneuvers specified by the Special Calibration
Test Requirements (SCTR) document. Commissioning activities for the
imaging sensor(s) will be included in the CAPE collection activity
requests, and folded into the MOE mission planning and scheduling
process. Observatory commissioning activities will be given scheduling
priority during the commissioning phase.

In addition, the government's Independent Calibration/Validation Team
(ICVT) will submit image acquisition requests for test data to support
their independent test and cal/val operations. This could include, for
example, imagery over vicarious calibration sites or coincident
acquisitions with operational high- and moderate-resolution imaging
sensors. (These acquisitions will be coordinated with the operators of
those systems as needed.) These requests will be provided to the CAPE
for acquisition scheduling so long as they do not conflict with the
observatory commissioning schedule. These data will be acquired,
processed and archived along with the all other imaging sensor data
requests. The ICVT requested data sets will subsequently be extracted
from the archive for further processing and analysis by the ICVT.

Once the observatory is fully checked out and calibrated, the on-orbit
performance for the acquired image data will be assessed. This includes
determining the initial on-orbit calibration parameters (CPF) and
presenting the results of on-orbit data processing and analysis. The
data sets analyzed will include one or more test scenes processed using
government-provided supporting data - ground control points (GCPs) and
elevation data (DEM) - after the on-orbit calibration parameters are
determined.

At the completion of on-orbit commissioning, an On-orbit Acceptance
Review (OAR) will take place. Upon the successful completion of the OAR,
NASA, with concurrence from the USGS, will declare the LDCM operational.
NASA will then transfer ownership and operation of the LDCM to the USGS.

## Operations

The Operations phase represents the period between observatory
commissioning and decommissioning.

The LDCM operations are illustrated by a series of scenarios. These
scenarios provide an overview of the major threads through the
Operational Concept to describe how major activities are accomplished.
The set of scenarios help in understanding how the LDCM 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.

Each scenario includes a brief description, a list of assumptions, a
data flow figure, and a table that describes the key functions and data
flows. The figure below illustrates the graphical convention used for
these scenarios. In this example, a function happens at step 1 and data
flows to step 2. A function occurs at step 2, and then there are two
flows shown. In this example, the primary flow is through steps 3, 4 and
then 5. This flow always occurs as these steps are numbered sequentially
and shown in the same style. There is an optional, alternate flow
represented as steps A1, A2 and A3 in the example.

![](media/image5.wmf){width="4.571527777777778in"
height="0.9694444444444444in"}

Figure 5‑1. Scenario Style Example

### Daily Activity Scheduling Mission Scenario (LDCM-01)

#### Description

This scenario illustrates the daily activity scheduling of LDCM image
data and providing command loads to the LDCM space segment. This
scenario begins with data acquisition requests and ends with upload of a
command sequence to the spacecraft.

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

![](media/image6.png){width="6.175in" height="4.147222222222222in"}

Figure 5‑2. Daily Activity Scheduling Mission Scenario (LDCM-01)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | The User Community generates and submits special image         |
|     | requests that are not in the daily activity or acquisition     |
|     | schedule. The LDCM Independent Cal/Val Team also generates and |
|     | submits image requests to support imaging sensor calibration.  |
|     | The User Community interfaces with the DPAS User Portal        |
|     | function to submit requests, and the Independent Cal/Val Team  |
|     | interfaces with the Data Collection Planner and/or the User    |
|     | Portal to submit calibration requests. Note that all these     |
|     | inputs are optional, as the acquisition schedules will largely |
|     | be automatically generated.                                    |
+-----+----------------------------------------------------------------+
| 2   | The DPAS forwards the image requests to the FOS Collection     |
|     | Activity Planning Element (CAPE) for consideration. This step  |
|     | is also optional, since user image requests will not always be |
|     | made.                                                          |
+-----+----------------------------------------------------------------+
| 3   | The DPAS User Portal function makes the entire inventory of    |
|     | LDCM metadata in the archive available to the CAPE. This       |
|     | information includes the cloud cover percentages for all       |
|     | scenes in the archive.                                         |
+-----+----------------------------------------------------------------+
| 4   | As part of the CAPE function, all special image requests are   |
|     | evaluated by the Data Collection Planner for acceptance or     |
|     | rejection, guided by established policy. The accepted requests |
|     | and GMAP are combined based on predicted cloud cover           |
|     | probabilities, existing archive quality and extent, and        |
|     | observatory or ground system constraints (provided from the    |
|     | MOE).                                                          |
+-----+----------------------------------------------------------------+
| 5   | The accepted requests and GMAP collections are converted into  |
|     | an image collection activity request and forwarded to the      |
|     | Planning and Scheduling function of the MOE.                   |
+-----+----------------------------------------------------------------+
| 6   | The collection activity request is combined with other         |
|     | observatory activities being managed by the MOE Planning and   |
|     | Scheduling functions. MOE Planning and Scheduling functions    |
|     | allocate resources, perform any needed activity                |
|     | de-confliction, and generate the observatory activity          |
|     | schedule, which is forwarded to the MOE Command and Control    |
|     | function. The MOE provides the to-be-executed observatory      |
|     | schedule information to the CAPE, the LDCM ground stations, IC |
|     | ground stations, and the DPAS.                                 |
+-----+----------------------------------------------------------------+
| 7   | The MOE Command & Control function prepares and transmits the  |
|     | command load to implement the observatory activity schedule.   |
|     | At the time of the uplink opportunity, the Command & Control   |
|     | function sends the command load through the LDCM Ground        |
|     | Network to the observatory, in real time.                      |
|     |                                                                |
|     | The Ground Network sends the command sequence to the LDCM      |
|     | observatory during the scheduled command opportunity.          |
+-----+----------------------------------------------------------------+
| A1  | The status of special requests (if any) is passed back to the  |
|     | DPAS.                                                          |
+-----+----------------------------------------------------------------+
| A2  | The DPAS User Portal function makes the status information     |
|     | available to the User Community and Independent Cal Val Team   |
|     | member(s) who originally placed the request.                   |
+-----+----------------------------------------------------------------+

Table 5‑1. Daily Activity Scheduling Mission Scenario (LDCM-01)

### Collect Imaging Sensor Data (LDCM-02)

#### Description

This scenario illustrates the collection of LDCM image data. This
scenario begins with the initial image collection by the observatory and
ends with the ingestion into the DPAS archive. This scenario refers only
to mission data -- imaging sensor and ancillary data. (Note that stored
housekeeping telemetry playback is described in scenario LDCM-05.)

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

![](media/image7.png){width="5.925in" height="2.954861111111111in"}

Figure 5‑3. Collect Imaging Sensor Data (LDCM-02)

  ---------------------------------------------------------------------------
  **Step**   **Description**
  ---------- ----------------------------------------------------------------
  1          The Space Segment observatory imaging sensor(s) collects the
             scheduled image data (refer to scenario LDCM-01)

  2          The observatory may optionally store the data on board until the
             next downlink opportunity. The X-band imaging sensor data are
             then downlinked to the LDCM Ground Network.

  3          A ground station within the LDCM Ground Network receives the
             X-band mission data from the Space Segment observatory. The
             mission data is then routed to the DPAS.

  4          The Storage and Archive function makes the data available to the
             Image Processing function.

  5          The Image Processing function generates scene quality
             information, metadata and other metrics. The Image Processing
             function also extracts trend data to support detailed image
             assessments.

  6          The Image Processing function makes the archive-formatted data
             available to the Storage and Archive function for archival.

  7          The Storage & Archive function makes the metadata for the
             ingested data available to the User Portal function.

  8          The User Portal function makes available metadata regarding all
             data received to the Collection Activity Planning function.
  ---------------------------------------------------------------------------

Table 5‑2. Collect Imaging Sensor Data Scenario (LDCM-02)

### Flight Software Upload Scenario (LDCM-03)

#### Description

This scenario illustrates the routine update of LDCM flight software.
The scenario begins with the generation of new flight software and ends
with verification that the in-flight software was successfully updated.

#### Assumptions

-   All segments are functioning nominally.

-   There is some reason to perform a flight software update, and the
    nature of the update required is well characterized.

#### Walkthrough

![](media/image8.png){width="6.3in" height="3.0972222222222223in"}

Figure 5‑4. Flight Software Update Scenario (LDCM-03)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | A new flight software update is provided by the imaging        |
|     | sensor(s) or spacecraft flight software developer/maintainer.  |
|     | This is the actual flight software code, which will be         |
|     | installed in the observatory. The update is sent to the MOE    |
|     | Command and Control function.                                  |
+-----+----------------------------------------------------------------+
| 2   | The Command & Control function generates a command sequence,   |
|     | to apply the flight software update to the observatory.        |
|     |                                                                |
|     | The Command & Control function tests the flight software       |
|     | update command sequence using the observatory simulator.       |
+-----+----------------------------------------------------------------+
| 3   | A flight software update request is forwarded to the Planning  |
|     | and Scheduling function.                                       |
+-----+----------------------------------------------------------------+
| 4   | Planning & Scheduling incorporates the flight software update  |
|     | into the observatory activity schedule. The observatory        |
|     | schedule is sent back to the Command & Control function.       |
+-----+----------------------------------------------------------------+
| 5,6 | The Command & Control function establishes communication with  |
|     | the observatory through the LDCM Ground Network. This          |
|     | communications link is bidirectional and occurs in real time.  |
|     | Through this link, the Command & Control function sends the    |
|     | command load to install the flight software update.            |
|     |                                                                |
|     | Note that it may require multiple contacts with a ground       |
|     | station to uplink an entire flight software update.            |
+-----+----------------------------------------------------------------+
| 7   | The observatory receives, verifies, and executes the command   |
|     | load.                                                          |
+-----+----------------------------------------------------------------+
| 8,  | The command load would typically include instructions to       |
| 9   | verify the application of the flight software update, such as  |
|     | checksums, reporting the operating version number and so on.   |
|     | The observatory executes these verification commands and the   |
|     | results are sent back to the Command & Control function        |
|     | through the LDCM Ground Network, in real time.                 |
+-----+----------------------------------------------------------------+
| 10  | The Command & Control function evaluates the verification data |
|     | to confirm that the command load and flight software execution |
|     | were successful. The command load is sent to the Trending and  |
|     | Analysis function for archival.                                |
+-----+----------------------------------------------------------------+
| 11  | The Trending and Analysis function archives the command load   |
|     | and updated flight software.                                   |
+-----+----------------------------------------------------------------+

Table 5‑3. Flight Software Update Scenario (LDCM-03)

### User Query Order and Product Distribution Scenario (LDCM-04)

#### Description

This scenario illustrates the routine user query, order and product
distribution of a particular LDCM scene(s). The scenario begins with a
user initiating a search for data and concludes with delivery of data
products to the user.

#### Assumptions

-   All segments are functioning nominally.

-   The user is requesting a product from archived data.

#### Walkthrough

![](media/image9.png){width="5.675in" height="2.5131944444444443in"}

Figure 5‑5. User Query Order and Product Distribution Scenario (LDCM-04)

  -------------------------------------------------------------------------------------
  **Step**             **Description**
  -------------------- ----------------------------------------------------------------
  1                    A User from the User Community initiates a search for LDCM data.

  2                    The DPAS User Portal executes the search and presents results to
                       the User. The User may search several more times, and view
                       browse data and metadata about resulting scenes. The User
                       ultimately chooses scenes for ordering. The User Portal obtains
                       additional information from the User if required (through the
                       same interface) and builds the order(s) required to fulfill the
                       User request.

  Note; In the case of 
  some large (bulk)    
  data orders, the     
  User functions in    
  steps 1 and 2 may be 
  performed via a      
  machine-to-machine   
  interface.           

  3                    The User Portal generates the processing requests necessary to
                       satisfy the order and passes them to the Image Processing
                       function.

  4                    The Image Processing function obtains the required data from the
                       Storage and Archive function.

  5                    The Image Processing function generates the required products.
                       These are made available to the Storage and Archive function.

  6                    The Storage and Archive function makes the products available to
                       the User Portal function.

  7                    The User Portal function provides the products back to the User
                       in the format specified. This may be on physical media or via
                       electronic transfer, as specified in the order.
  -------------------------------------------------------------------------------------

Table 5‑4. User Query Order and Product Distribution Scenario (LDCM-04)

### Monitor Health & Safety (LDCM-05)

#### Description

This scenario describes the operations performed for both short term and
long term monitoring of the spacecraft heath and safety. The scenario
begins with the collection of related data on the spacecraft and ends
with monitoring / analysis by the FOT operators. (Acting upon any issues
found is covered under scenarios LDCM-20 and LDCM-21.)

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

![](media/image10.png){width="5.675in" height="2.8819444444444446in"}

Figure 5‑6. Monitor Health & Safety (LDCM-05)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | The observatory collects telemetry points regarding health &   |
|     | status information of subsystems. These data are stored        |
|     | onboard and later downlinked to the LDCM Ground Network. The   |
|     | real-time telemetry is also downlinked to the Ground Network.  |
+-----+----------------------------------------------------------------+
| 2   | A ground station within the LDCM Ground Network receives the   |
|     | telemetry data. The Ground Network routes this data in real    |
|     | time to the FOS MOE.                                           |
+-----+----------------------------------------------------------------+
| 3   | The MOE Command & Control function automatically monitors all  |
|     | key telemetry points for pre-established limit values. Any     |
|     | out-of-limits value is automatically detected. If a FOT        |
|     | operator is not on staff, the MOE will notify FOT staff so     |
|     | appropriate action can be taken.                               |
|     |                                                                |
|     | The MOE Command & Control function presents a real-time        |
|     | summary of all key telemetry points and indicators of any      |
|     | out-of-limits telemetry points. A FOT operator interface       |
|     | allows the operator to investigate certain points during the   |
|     | pass.                                                          |
+-----+----------------------------------------------------------------+
| 4   | Following each telemetry pass contact, the data are saved      |
|     | within the Trending and Analysis function. The Trending and    |
|     | Analysis function stores all telemetry data acquired since     |
|     | launch within the MOE for real to near real-time access by FOT |
|     | members.                                                       |
|     |                                                                |
|     | The MOE Trending and Analysis function makes a copy of the     |
|     | telemetry data available to the Storage & Archive function     |
|     | within the DPAS for use by the Independent Cal/Val Team.       |
+-----+----------------------------------------------------------------+
| The |                                                                |
| fol |                                                                |
| low |                                                                |
| ing |                                                                |
| thr |                                                                |
| ead |                                                                |
| r   |                                                                |
| epr |                                                                |
| ese |                                                                |
| nts |                                                                |
| the |                                                                |
| lon |                                                                |
| g-t |                                                                |
| erm |                                                                |
| m   |                                                                |
| oni |                                                                |
| tor |                                                                |
| ing |                                                                |
| ca  |                                                                |
| pab |                                                                |
| ili |                                                                |
| ty. |                                                                |
+-----+----------------------------------------------------------------+
| 5   | A FOT operator (engineer or other FOS team member) interfaces  |
|     | to the MOE Trending and Analysis function, and initiates an    |
|     | analysis session. The operator chooses what data to evaluate,  |
|     | such as battery temperature data or any other data contained   |
|     | in the telemetry archive                                       |
+-----+----------------------------------------------------------------+
| 6   | The MOE Trending and Analysis function retrieves all relevant  |
|     | data from the telemetry archive. Processing is performed as    |
|     | required / specified by the operator conducting the analysis.  |
+-----+----------------------------------------------------------------+
| 7   | The MOE Trending and Analysis function presents the results to |
|     | the operator. The operator may perform a number of steps,      |
|     | including starting new analysis, exporting data for further    |
|     | analysis, updating telemetry point limits and so on.           |
+-----+----------------------------------------------------------------+
| A1  | Independent Cal/Val Team members interface to the Image        |
|     | Processing function to access observatory state of health data |
|     | for the long term calibration and performance monitoring of    |
|     | the imaging sensor(s) and any calibration components/devices.  |
+-----+----------------------------------------------------------------+

Table 5‑5. Monitor Health & Safety (LDCM-05)

### Priority Scene Acquisition & Delivery (LDCM-06)

#### Description

This scenario describes the operations performed when priority data
acquisition requests are received. This scenario begins with the
initiation of a request by a User and ends with delivery of data
products to the User.

#### Assumptions

-   All segments are functioning nominally.

-   The priority scene request is approved by the Data Collection
    Planner as falling within the policy guidelines for such requests.

-   The User already has an account on the User Portal, and this account
    has been pre-cleared to submit Priority data collection requests.

#### Walkthrough

![](media/image11.png){width="6.55in" height="3.9722222222222223in"}

Figure 5‑7. Priority Scene Acquisition & Delivery (LDCM-06)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | A User from the User Community identifies a need for priority  |
|     | data acquisition & delivery. The User submits this request to  |
|     | the DPAS through the User Portal function. (The user may also  |
|     | contact a Customer Service agent on the telephone, who in turn |
|     | enters the request into the User Portal on their behalf.)      |
|     | There is an account-level control over who may submit Priority |
|     | data collection requests.                                      |
+-----+----------------------------------------------------------------+
| 2   | The User Portal sends the acquisition request to the           |
|     | Collection Activity Planning function within the FOS. Now, or  |
|     | at any time before step 11, the User Portal function sends a   |
|     | request to the Image Processing function for generation of the |
|     | requested products.                                            |
+-----+----------------------------------------------------------------+
| 3   | The Data Collection Planner interacts with the Collection      |
|     | Activity Planning function. The DCP translates the acquisition |
|     | request into a set of specific acquisitions necessary to       |
|     | complete the request. The DCP identifies the request as a      |
|     | Priority request.                                              |
+-----+----------------------------------------------------------------+
| 4   | The Collection Activity Planning function develops a           |
|     | collection activity request, which incorporates the priority   |
|     | request, along with other regularly scheduled acquisitions,    |
|     | adjusted to accommodate the Priority request if necessary.     |
|     | This request is sent to the MOE Planning & Scheduling          |
|     | function.                                                      |
+-----+----------------------------------------------------------------+
| 5   | The Planning & Scheduling function develops or revises the     |
|     | observatory activity schedule. The MOE provides the            |
|     | to-be-executed observatory schedule information to the CAPE,   |
|     | the LDCM ground stations, and the DPAS. The observatory        |
|     | activity schedule and resources are passed to the Command &    |
|     | Control function.                                              |
|     |                                                                |
|     | The Planning & Scheduling function also schedules a Ground     |
|     | Network contact as soon as possible following the observatory  |
|     | collection of the Priority image data. The commands to         |
|     | downlink the priority data may be uplinked in the same contact |
|     | or a subsequent contact.                                       |
+-----+----------------------------------------------------------------+
| 6,7 | The Command & Control function translates the activity         |
|     | schedule into a command load. At the scheduled time, the       |
|     | Ground Network establishes contact with the observatory. In    |
|     | real time, the Command & Control function sends the command    |
|     | load to the observatory through the Ground Network.            |
+-----+----------------------------------------------------------------+
| 8   | The observatory acquires the Priority image data.              |
+-----+----------------------------------------------------------------+
| 9   | At the next scheduled Ground Network contact, based on         |
|     | observatory commands received from the MOE (step 5), the       |
|     | observatory downlinks all Priority image data in advance of    |
|     | non-Priority data.                                             |
+-----+----------------------------------------------------------------+
| 10  | The Priority scenes are sent to the DPAS Storage and Archive   |
|     | function from the Ground Network station.                      |
+-----+----------------------------------------------------------------+
| 11  | The Storage and Archive function makes the priority data       |
|     | available to the Image Processing function immediately upon    |
|     | receipt.                                                       |
+-----+----------------------------------------------------------------+
| 12  | The Image Processing function generates the requested data     |
|     | products and makes them available to the Storage and Archive   |
|     | function for temporary storage.                                |
+-----+----------------------------------------------------------------+
| 13, | The User Portal receives the Priority products from Storage    |
| 14  | and Archive, and sends the products to the User. In the        |
|     | Priority scenario, it is anticipated that users will normally  |
|     | order electronic delivery.                                     |
+-----+----------------------------------------------------------------+
|     | *This alternate thread illustrates a status capability*        |
+-----+----------------------------------------------------------------+
| A1  | The CAPE notifies the User Portal of the particular            |
|     | acquisitions identified to satisfy this request. The Planning  |
|     | & Scheduling function updates this information if there are    |
|     | any changes.                                                   |
+-----+----------------------------------------------------------------+
| A2  | At any time the User may query the User Portal to inquire      |
|     | about the status of the collection request.                    |
+-----+----------------------------------------------------------------+

Table 5‑6. Priority Scene Acquisition & Delivery (LDCM-06)

#### Scenario Timeline

![](media/image12.png){width="6.3in" height="4.284722222222222in"}

Figure 8. Priority Scene Acquisition & Delivery Timeline

Figure 8 presents the timeline established to meet the worst case
scenarios for scheduling a priority acquisition, and processing products
from a priority acquisition. The numbers in each block represent the
minutes allocated to that step to meet the timeline. The table below
ties the steps on the timeline to the scenario steps from section
5.4.6.3 and provides additional notes.

The LGN ground station locations of Sioux Falls, SD, and Fairbanks, AK,
create a period of several orbits where the observatory is not in
contact with the LGN. The worst case from a scheduling point of view is
to schedule a priority scene which would be acquired at the very end of
this contact gap. For the time from acquisition to production, the worst
case is a scene acquired at the very beginning of this contact gap.
Although in practice back-to-back contact gaps of 411 minutes will not
occur, these timelines are presented this way in order to show the worst
cases for both planning & scheduling and image production purposes.

+---------------+-------------+---------------------------------------+
| **Timeline**  | *           | **Notes**                             |
|               | *Scenario** |                                       |
| **Step**      |             |                                       |
|               | **Steps**   |                                       |
+===============+=============+=======================================+
| Request       | 1           |                                       |
| Received      |             |                                       |
+---------------+-------------+---------------------------------------+
| CAPE          | 2,3,4       |                                       |
| Processing    |             |                                       |
+---------------+-------------+---------------------------------------+
| MOE           | 5,6         |                                       |
| Processing    |             |                                       |
+---------------+-------------+---------------------------------------+
| Minimum Time  | 6           | The MOE cannot schedule a ground      |
| to Next LGN   |             | station contact in less time than     |
| Pass          |             | this                                  |
+---------------+-------------+---------------------------------------+
| Upload        | 7           |                                       |
| Revised       |             |                                       |
| Commands      |             |                                       |
+---------------+-------------+---------------------------------------+
| Time to Image | 8           | This represents the time from the     |
|               |             | last Alaska LGN contact to the last   |
|               |             | possible daytime land image prior to  |
|               |             | an LGN contact in the daily contact   |
|               |             | gap.                                  |
+---------------+-------------+---------------------------------------+
| Image         | 8           |                                       |
| Acquired      |             |                                       |
+---------------+-------------+---------------------------------------+
| Time to Next  | 9           | This represents the time assuming a   |
| Downlink      |             | scene was acquired just after the     |
|               |             | last Alaska LGN contact, until the    |
|               |             | first LGN contact after the daily     |
|               |             | contact gap.                          |
+---------------+-------------+---------------------------------------+
| Downlink Data | 9           |                                       |
+---------------+-------------+---------------------------------------+
| Transfer Data | 10          | The worst case is to assume data was  |
| to DPAS       |             | downlinked to a station other than    |
|               |             | Sioux Falls, SD, so network transfer  |
|               |             | must take place.                      |
+---------------+-------------+---------------------------------------+
| Process Data  | 11,12,13    |                                       |
+---------------+-------------+---------------------------------------+
| Product Ready | 14          |                                       |
+---------------+-------------+---------------------------------------+

Table 5‑7. Priority Scene Acquisition & Delivery Timeline Details

### Maintain Orbit (LDCM-07)

#### Description

This scenario describes the processes related to station keeping for the
LDCM spacecraft. The scenario begins with measurements of the spacecraft
position and ends with confirmation that maneuvers were completed
successfully.

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

![](media/image13.png){width="6.425in" height="4.238888888888889in"}

Figure 5‑9. Maintain Orbit (LDCM-07)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
|     | *This scenario begins with measurements relevant to the        |
|     | determination of the spacecraft precision ephemeris. These     |
|     | measurements occur asynchronously and are represented as       |
|     | parallel flows for the purpose of this scenario.*              |
+-----+----------------------------------------------------------------+
| 1   | The observatory performs measurements relevant to orbit        |
|     | determination. These measurements are included as part of the  |
|     | standard telemetry streams during contacts with stations in    |
|     | the Ground Network.                                            |
+-----+----------------------------------------------------------------+
| 2   | The Ground Network stations forward the telemetry data to the  |
|     | Command & Control function.                                    |
+-----+----------------------------------------------------------------+
| 3   | The Command & Control function passes all the telemetry data   |
|     | to the Trending and Analysis function for archival after the   |
|     | ground network contact is completed. These data include the    |
|     | observatory measurements.                                      |
+-----+----------------------------------------------------------------+
| A1  | The GSFC Constellation Coordination Office coordinates with    |
|     | the FOT Operators (TBD8). This coordination is to ensure       |
|     | adequate operational safety in the group of satellites flying  |
|     | in the same orbital plane as LDCM.                             |
+-----+----------------------------------------------------------------+
| A2  | The USSTRATCOM sends orbital debris monitoring alerts to the   |
|     | Flight Dynamics function. These messages consist of ellipsoid  |
|     | volume data representing buffer regions between LDCM and other |
|     | orbiting debris that could collide with LDCM. Two volumes are  |
|     | used - the "monitor volume" (larger) and the "tasking alert    |
|     | volume" (smaller). Predicted monitor volume violations are     |
|     | reported in routine messages from USSTRATCOM. Violation of the |
|     | tasking alert volume initiates additional tracking of the      |
|     | offending objects by USSTRATCOM to refine the orbit for more   |
|     | accurate conjunction assessment, which is forwarded to the     |
|     | FOT.                                                           |
+-----+----------------------------------------------------------------+
| 4   | An FOT operator(s) evaluates telemetry and makes a             |
|     | determination as to whether a maneuver is required to maintain |
|     | orbit and mission safety. Additional operations management     |
|     | approval for certain types of maneuvers may be required.       |
+-----+----------------------------------------------------------------+
| 5   | The FOT Operator uses the Flight Dynamics function to derive   |
|     | the details of the orbital maneuver(s) required. Predicted     |
|     | ephemerides corresponding to planned maneuvers are also sent   |
|     | to USSTRATCOM for predicted conjunction assessment(s). The     |
|     | potential for conjunctions are assessed prior to final         |
|     | maneuver planning and selection.                               |
+-----+----------------------------------------------------------------+
| 6   | A maneuver request is sent to the Planning and Scheduling      |
|     | function.                                                      |
+-----+----------------------------------------------------------------+
|     | *Note that the planning of maneuvers is done well in advance   |
|     | of the maneuver. Steps 4, 5, 6 and 7 are all expected to occur |
|     | after a significant amount of coordination on the part of FOT  |
|     | staff. Steps 4, 5, 6 and 7 may be completed days or even weeks |
|     | in advance of the actual maneuver.*                            |
+-----+----------------------------------------------------------------+
| 7   | The Planning and Scheduling function allocates resources for   |
|     | executing the maneuver. This includes scheduling the Ground    |
|     | Network contact for the commanding, and potentially            |
|     | identifying a period of time during which no mission data      |
|     | acquisitions will be performed, for input to the scheduling    |
|     | process. The maneuver is then incorporated into the            |
|     | observatory activity schedule.                                 |
+-----+----------------------------------------------------------------+
| 8,  | The Command and Control function transmits the command load to |
| 9   | implement the observatory activity schedule, including the     |
|     | maneuver.                                                      |
|     |                                                                |
|     | At the time of the contact, the Command & Control function     |
|     | establishes contact with the observatory through the Ground    |
|     | Network. This communication is accomplished in real time. The  |
|     | command load is sent to the observatory through the Ground     |
|     | Network.                                                       |
+-----+----------------------------------------------------------------+
| 10  | The observatory executes the commanded maneuver sequence.      |
+-----+----------------------------------------------------------------+
|     | *Note that this is an iterative process. Following the         |
|     | maneuver, measurements are taken to ensure that the            |
|     | observatory is in the intended orbit. Therefore the system     |
|     | proceeds to steps 1 and 2 of this scenario, and repeats.*      |
+-----+----------------------------------------------------------------+

Table 5‑8. Maintain Orbit (LDCM-07)

###  IC Scheduling and Delivery (LDCM-08)

#### Description

This scenario illustrates the primary interactions between LDCM and the
International Cooperators (ICs). This scenario begins with the IC
request for image collection and ends with the delivery of data to the
IC.

There are two ways for an IC to request data. A mask providing relative
scene priorities can be submitted as seasonal or operational
considerations change. Specific individual scenes can be requested using
the functionality provided by the DPAS User Portal.

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

![](media/image14.png){width="6.208333333333333in"
height="3.7055555555555557in"}

Figure 5‑10. IC Scheduling and Delivery (LDCM-08)

  ---------------------------------------------------------------------------
  **Step**   **Description**
  ---------- ----------------------------------------------------------------
  1          An IC generates and submits an image collection request that is
             not in the daily activity or collection schedule. The IC
             interfaces with the DPAS User Portal function to submit
             individual scene requests. The IC interfaces with the Collection
             Activity Planning function to submit an IC-mask of relative
             scene priorities.

  2          The DPAS forwards the collection request to the FOS for
             consideration.

  3          As part of the Collection Activity Planning function, all IC
             requests are evaluated by the Data Collection Planner (DCP) for
             acceptance or rejection, guided by established policy. The
             accepted requests and GMAP are combined based on predicted cloud
             cover probabilities, existing archive quality and extent, and
             engineering constraints (provided by the MOE) to form the
             collection activity request.

  4          The Collection Activity Planning function coordinates with the
             IC for the availability and scheduling of IC ground stations
             resources to receive LDCM data. Each IC is coordinated with and
             scheduled on an individual basis.

  5          The collection activity request is forwarded to the MOE.

  6          The collection activity request is combined with other
             observatory activities being managed by the MOE Planning and
             Scheduling functions. MOE Planning and Scheduling functions
             allocate resources, perform any needed activity de-confliction,
             and generate the observatory activity schedule, which is
             forwarded to the MOE Command and Control function. The MOE
             provides the to-be-executed observatory schedule information to
             the CAPE, the LDCM ground stations, IC ground stations, and the
             DPAS.

  7          The Command and Control function uses the activity schedule to
             generate a command sequence, and forwards this to the LDCM
             Ground Network.

  8          The Ground Network sends the command sequence to the LDCM
             observatory during the scheduled command opportunity.

  9          The observatory collects the scheduled image data. In real-time,
             the observatory transmits the image data to the IC ground
             station. The image data are also stored on board the observatory
             for future downlink to an LDCM ground station.

  10         The IC ground station notifies the DPAS User Portal function of
             the receipt of the X-band data and provides related information
             associated with the collection.

  11         If additional calibration data is needed, the ICs access it
             through the DPAS User Portal function.

  A1         The status of IC requests (if any) is passed back to the DPAS.

  A2         The DPAS User Portal function makes the status information
             available to the International Cooperators who originally placed
             the request.
  ---------------------------------------------------------------------------

Table 5‑9. IC Scheduling and Delivery (LDCM-08)

###  Communications with the SN (LDCM-09)

#### Description

This scenario describes the interactions between LDCM and the SN. This
scenario begins with the scheduling of the SN resources and ends with
the receipt of S-band telemetry stream.

#### Assumptions

-   The mission is in early orbit, contingency operations, or
    proficiency testing phase

-   All segments are functioning nominally.

#### Walkthrough

![](media/image15.png){width="6.3in" height="3.3847222222222224in"}

Figure 5‑11. Communications with the SN (LDCM-09)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | FOS MOE Flight Dynamics and Planning and Scheduling functions  |
|     | define/plan the desired SN contact times. An FOT operator uses |
|     | this information to schedule SN resources.                     |
+-----+----------------------------------------------------------------+
| 2   | The SN custom scheduling tool in the MOC is used by an FOT     |
|     | operator to schedule SN resources through the SN White Sands   |
|     | Complex (WSC). This process may start 21 days in advance and   |
|     | is iterated with updated flight dynamics information as the    |
|     | planned SN contact draws nearer.                               |
+-----+----------------------------------------------------------------+
| 3   | The SN contact activity is incorporated into the observatory   |
|     | activity schedule within the MOE Planning and Scheduling       |
|     | function. The activity schedule is forwarded to the MOE        |
|     | Command and Control function.                                  |
+-----+----------------------------------------------------------------+
| 4   | Prior to the scheduled contact time, the MOE Command and       |
|     | Control function generates a link service request and forwards |
|     | this to the WSC.                                               |
+-----+----------------------------------------------------------------+
| 5   | The MOE Command and Control function generates a command       |
|     | sequence using the observatory activity schedule, and forwards |
|     | this to the WSC.                                               |
+-----+----------------------------------------------------------------+
| 6,  | The WSC ground station transmits the S-band communications     |
| 7   | stream to an SN satellite (TDRSS).                             |
|     |                                                                |
|     | The SN satellite contacts the LDCM observatory and relays to   |
|     | it the S-band communication.                                   |
+-----+----------------------------------------------------------------+
| 8,  | The observatory generates telemetry data and transmits an      |
| 9   | S-band communications stream to the SN satellite.              |
|     |                                                                |
|     | The SN satellite relays the S-band communications stream to    |
|     | the SN WSC ground station.                                     |
+-----+----------------------------------------------------------------+
| 10  | The WSC ground station forwards the received S-band telemetry  |
|     | data to the MOE Command and Control function.                  |
+-----+----------------------------------------------------------------+
| *At |                                                                |
| t   |                                                                |
| his |                                                                |
| po  |                                                                |
| int |                                                                |
| t   |                                                                |
| his |                                                                |
| sc  |                                                                |
| ena |                                                                |
| rio |                                                                |
| is  |                                                                |
| ov  |                                                                |
| er. |                                                                |
| In  |                                                                |
| pra |                                                                |
| cti |                                                                |
| ce, |                                                                |
| s   |                                                                |
| eve |                                                                |
| ral |                                                                |
| sce |                                                                |
| nar |                                                                |
| ios |                                                                |
| co  |                                                                |
| uld |                                                                |
| be  |                                                                |
| ini |                                                                |
| tia |                                                                |
| ted |                                                                |
| at  |                                                                |
| t   |                                                                |
| his |                                                                |
| poi |                                                                |
| nt, |                                                                |
| inc |                                                                |
| lud |                                                                |
| ing |                                                                |
| LD  |                                                                |
| CM- |                                                                |
| 03, |                                                                |
| LD  |                                                                |
| CM- |                                                                |
| 05, |                                                                |
| LD  |                                                                |
| CM- |                                                                |
| 07, |                                                                |
| and |                                                                |
| LDC |                                                                |
| M-2 |                                                                |
| 0.* |                                                                |
+-----+----------------------------------------------------------------+

Table 5‑10. Communications with the SN (LDCM-09)

### Safehold/Autonomous Failsafe Occurrence and Recovery Mission Scenario (LDCM-20)

#### Description

This scenario illustrates the non-nominal activity associated with an
anomaly identified onboard the observatory and the fail-safe process the
observatory will complete without ground interaction. The scenario
begins with a fault condition and ends with notification of the FOS that
the observatory is in safe-hold mode.

#### Assumptions

-   The FOS and DPAS are functioning nominally.

-   The observatory flight software has been developed such that
    continuous health and status data is recorded, analyzed and logged
    on board, allowing for detection of fault situations.

-   A fault situation (not intermittent) occurs on board the
    observatory, which triggers a safehold mode.

-   The observatory successfully enters safehold mode and cannot change
    modes without ground commanding.

#### Walkthrough

![](media/image16.png){width="6.125in" height="1.7368055555555555in"}

Figure 5‑12. Safehold/Autonomous Failsafe Occurrence and Recovery
Mission (LDCM-20)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | A fault condition occurs on board the observatory. The         |
|     | observatory detects the condition during routine internal      |
|     | health and status monitoring.                                  |
|     |                                                                |
|     | The observatory verifies the condition and continues data      |
|     | logging.                                                       |
+-----+----------------------------------------------------------------+
| 2   | The observatory initiates the safe-hold protocol by shutting   |
|     | down all non-essential hardware and processes (but continuing  |
|     | to log data) and continues until successfully completed. After |
|     | completion of safing, data logging continues.                  |
+-----+----------------------------------------------------------------+
| 3   | The observatory downlinks S-band data to a ground station      |
|     | within the FOS Ground Network at the next opportunity.         |
+-----+----------------------------------------------------------------+
| 4   | The Ground Network routes the data to appropriate FOS teams    |
|     | for analysis and archiving. The routing of telemetry data is   |
|     | identical to that shown in scenario LDCM-05.                   |
+-----+----------------------------------------------------------------+
| *At |                                                                |
| t   |                                                                |
| his |                                                                |
| po  |                                                                |
| int |                                                                |
| t   |                                                                |
| his |                                                                |
| sc  |                                                                |
| ena |                                                                |
| rio |                                                                |
| is  |                                                                |
| ov  |                                                                |
| er. |                                                                |
| In  |                                                                |
| pra |                                                                |
| cti |                                                                |
| ce, |                                                                |
| the |                                                                |
| sys |                                                                |
| tem |                                                                |
| im  |                                                                |
| med |                                                                |
| iat |                                                                |
| ely |                                                                |
| ini |                                                                |
| tia |                                                                |
| tes |                                                                |
| sc  |                                                                |
| ena |                                                                |
| rio |                                                                |
| L   |                                                                |
| DCM |                                                                |
| -21 |                                                                |
| u   |                                                                |
| pon |                                                                |
| det |                                                                |
| ect |                                                                |
| ion |                                                                |
| of  |                                                                |
| the |                                                                |
| saf |                                                                |
| e-h |                                                                |
| old |                                                                |
| con |                                                                |
| dit |                                                                |
| ion |                                                                |
| wit |                                                                |
| hin |                                                                |
| the |                                                                |
| FO  |                                                                |
| S.* |                                                                |
+-----+----------------------------------------------------------------+

Table 5‑11. Safehold/Autonomous Failsafe Occurrence and Recovery Mission
Scenario (LDCM-20)

### Non-Autonomous Anomaly Correction (LDCM-21)

#### Description

This scenario describes the process of anomaly resolution. The scenario
begins with the establishment of an Anomaly Resolution Team and ends
with the determination of the appropriate procedures to correct the
anomaly.

#### Assumptions

-   An anomaly has occurred and has been detected by the FOT

#### Walkthrough

![](media/image17.png){width="6.040972222222222in"
height="2.933333333333333in"}

Figure 5‑13. Non-Autonomous Anomaly Correction (LDCM-21)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | An Anomaly Resolution Team (ART) is formed. The ART may be     |
|     | comprised of the following representatives, depending on the   |
|     | type of anomaly: FOT operators, spacecraft and imaging         |
|     | sensor(s) sustaining engineering support, NASA discipline      |
|     | engineering support, DPAS support, and the Independent Cal/Val |
|     | team.                                                          |
+-----+----------------------------------------------------------------+
| 2   | The ART interfaces to the Trending and Analysis functions to   |
|     | study and analyzes observatory engineering and state of health |
|     | data.                                                          |
+-----+----------------------------------------------------------------+
| 3   | The ART develops and evaluates possible anomaly resolution     |
|     | options using MOE tools/capabilities, engineering and design   |
|     | data, and other operations support tools and information.      |
|     |                                                                |
|     | A spacecraft anomaly report is generated and becomes the       |
|     | official document to track and close the incident              |
|     |                                                                |
|     | Steps 2 and 3 may be performed iteratively until the anomaly   |
|     | resolution plan and procedures are determined.                 |
+-----+----------------------------------------------------------------+
| *At |                                                                |
| t   |                                                                |
| his |                                                                |
| poi |                                                                |
| nt, |                                                                |
| t   |                                                                |
| his |                                                                |
| sc  |                                                                |
| ena |                                                                |
| rio |                                                                |
| en  |                                                                |
| ds. |                                                                |
| Dep |                                                                |
| end |                                                                |
| ing |                                                                |
| on  |                                                                |
| the |                                                                |
| t   |                                                                |
| ype |                                                                |
| of  |                                                                |
| a   |                                                                |
| nom |                                                                |
| aly |                                                                |
| and |                                                                |
| re  |                                                                |
| sol |                                                                |
| uti |                                                                |
| on, |                                                                |
| a   |                                                                |
| num |                                                                |
| ber |                                                                |
| of  |                                                                |
| dif |                                                                |
| fer |                                                                |
| ent |                                                                |
| eve |                                                                |
| nts |                                                                |
| or  |                                                                |
| sce |                                                                |
| nar |                                                                |
| ios |                                                                |
| co  |                                                                |
| uld |                                                                |
| be  |                                                                |
| ini |                                                                |
| tia |                                                                |
| ted |                                                                |
| at  |                                                                |
| t   |                                                                |
| his |                                                                |
| po  |                                                                |
| int |                                                                |
| inc |                                                                |
| lud |                                                                |
| ing |                                                                |
| a   |                                                                |
| fli |                                                                |
| ght |                                                                |
| so  |                                                                |
| ftw |                                                                |
| are |                                                                |
| upd |                                                                |
| ate |                                                                |
| (   |                                                                |
| LDC |                                                                |
| M-0 |                                                                |
| 3), |                                                                |
| a   |                                                                |
| cti |                                                                |
| vat |                                                                |
| ion |                                                                |
| of  |                                                                |
| red |                                                                |
| und |                                                                |
| ant |                                                                |
| fli |                                                                |
| ght |                                                                |
| sy  |                                                                |
| ste |                                                                |
| ms, |                                                                |
| a   |                                                                |
| mod |                                                                |
| ifi |                                                                |
| cat |                                                                |
| ion |                                                                |
| in  |                                                                |
| im  |                                                                |
| age |                                                                |
| d   |                                                                |
| ata |                                                                |
| c   |                                                                |
| oll |                                                                |
| ect |                                                                |
| ion |                                                                |
| or  |                                                                |
| pr  |                                                                |
| oce |                                                                |
| ssi |                                                                |
| ng, |                                                                |
| or  |                                                                |
| ot  |                                                                |
| her |                                                                |
| s.* |                                                                |
+-----+----------------------------------------------------------------+

Table 5‑12. Non-Autonomous Anomaly Correction (LDCM-21)

### Retransmission (LDCM-22)

#### Description

This scenario describes two possible levels of LDCM data retransmission
which the LDCM system will provide.

#### Assumptions

-   Scenario Flow A: LDCM imaging sensor data was acquired and
    downlinked successfully. Following successful ground receipt as
    confirmed by LGN, the MOE commanded data to be overwriteable in the
    observatory mass storage. The LGN transferred the imaging sensor
    data to the DPAS, and the resulting data was judged invalid.

-   Scenario Flow B: LDCM imaging sensor data was acquired by the
    observatory and downlinked to the LGN. A portion of the data
    downlinked could not be confirmed as successfully received during
    the LGN contact. The portion that could not be confirmed remains on
    board the observatory in mass storage.

#### Walkthrough 

![](media/image18.png){width="6.05in" height="3.0368055555555555in"}

Figure 5‑14. Retransmission (LDCM-22)

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| A1  | The Storage & Archive function requests that the Ground        |
|     | Network re-transfer LDCM data to the Storage & Archive         |
|     | function. This request can only be placed within the fixed     |
|     | period of time for which the Ground Network nodes cache data   |
|     | for this purpose.                                              |
+-----+----------------------------------------------------------------+
| A2  | The Ground Network makes the LDCM data available to the        |
|     | Storage & Archive function.                                    |
+-----+----------------------------------------------------------------+
| B1  | Based on observatory telemetry and LGN ground station contact  |
|     | data, the MOE Mass Storage Management function identifies the  |
|     | data in observatory mass storage that must be re-downlinked.   |
|     | Mass Storage utilization is also re-analyzed to account for    |
|     | the data still in mass storage and upcoming imaging sensor     |
|     | data collections.                                              |
|     |                                                                |
|     | Note: The DPAS, through CAPE, could also originate a request   |
|     | for re-downlink for data that has been found to be of poor     |
|     | quality by the DPAS, provided that the data was flagged for    |
|     | protection and has not yet been overwritten within observatory |
|     | mass storage. The MOE recorder management functions will be    |
|     | capable of managing this by maintain the protection even after |
|     | downlink receipt acknowledgement.                              |
+-----+----------------------------------------------------------------+
| B2  | The MOE Planning and Scheduling function schedules the data    |
|     | for re-downlink in an upcoming pass. Re-planning and           |
|     | re-scheduling of imaging sensor data collections may be needed |
|     | to account for the unavailable space in observatory mass       |
|     | storage.                                                       |
+-----+----------------------------------------------------------------+
| B3  | The Command and Control function transmits a command for       |
|     | re-downlink from the observatory. This could be done either    |
|     | during the normal commanding schedule, or as an additional     |
|     | commanding event, as the situation warrants.                   |
+-----+----------------------------------------------------------------+
| B4  | The Observatory sends the requested data back down to the      |
|     | Ground Network as requested in the command load.               |
+-----+----------------------------------------------------------------+
| B5  | The Ground Network makes the LDCM data available to the        |
|     | Storage & Archive function.                                    |
+-----+----------------------------------------------------------------+

Table 5‑13. Retransmission (LDCM-22)

### Backup Flight Operations

As discussed in section 3.2, the LDCM has a backup flight operations
center capability. The Mission Operations Manager can transfer
operations responsibility to the backup location at any time. The
switchover may be initiated from the backup mission operations center,
in the event the primary location is unexpectedly non-operational. No
scenario is shown for this because the details of activating the backup
mission operations center are design-specific. All nominal and
non-nominal operations can be executed from the backup location.

To ensure that the backup capability is ready, operations will be tested
from the backup location on a routine periodic basis.

## Decommissioning

At the end of the mission, the LDCM will undergo decommissioning. The
decommissioning of the LDCM observatory will comply with the NASA Safety
Standard Guidelines and Assessment Procedures for Limiting Orbital
Debris (NSS 1740.14) and the NASA Policy for Limiting Orbital Debris
Generation (NPD 8710.3).

# 6.0 Design Reference Case {#design-reference-case .unnumbered}

A Design Reference Case has been developed to present a 15 orbit
scenario for the LDCM mission. This reference case is intended to
incorporate all the driving operational cases into a single day's
operation to show a worst case operational scenario.  The DRC is
presented in tabular form in Appendix B. The table includes one row for
every WRS-2 path/row orbit increment where either imaging sensor data is
acquired or X-band data is downlinked.

This design reference case (DRC) assumes that all imaging sensor data is
protected on-board from overwriting until it is downlinked to an LGN
ground station.  Within the same ground station contact, the data
downlinked will be unprotected and available for overwriting in
observatory mass storage.\
\
The DRC color coding is as follows:\
green = imaging sensor data collected\
yellow = downlink to LGN station\
red = off-nadir collection

The DRC column headings are explained in the following table.

+-----------------------------------+-----------------------------------+
| **Column Heading**                | **Explanation/Description**       |
+-----------------------------------+-----------------------------------+
| Acquired?                         | Indicates a 1 for any time the    |
|                                   | imaging sensor(s) is collecting   |
|                                   | data for downlink                 |
+-----------------------------------+-----------------------------------+
| Off-nadir?                        | Indicates a 1 for any time the    |
|                                   | collected imaging sensor data is  |
|                                   | an off-nadir image of the Earth   |
+-----------------------------------+-----------------------------------+
| Downlinked                        | Indicates the number of           |
|                                   | simultaneous X-band downlink      |
|                                   | streams to an LDCM Ground Network |
|                                   | ground station.  LGN ground       |
|                                   | stations can receive up to 2      |
|                                   | simultaneous streams of either 1  |
|                                   | real-time + 1 playback or 2       |
|                                   | playbacks, as indicated in the    |
|                                   | Comment column.                   |
+-----------------------------------+-----------------------------------+
| broadcast                         | Indicates the number of           |
|                                   | simultaneous real-time X-band     |
|                                   | downlink streams to International |
|                                   | Cooperator (IC) ground stations   |
+-----------------------------------+-----------------------------------+
| station_id                        | Includes the LGN ground station   |
|                                   | identifier for the station        |
|                                   | receiving the downlink.           |
|                                   |                                   |
|                                   | LGS = Landsat Ground Station,     |
|                                   | Sioux Falls, South Dakota         |
|                                   |                                   |
|                                   | AK = Alaska Ground station, TBD,  |
|                                   | Alaska                            |
+-----------------------------------+-----------------------------------+
| Ic1, ic2, and ic3                 | Includes the IC ground station    |
|                                   | identifiers for the IC stations   |
|                                   | receiving real-time X-band        |
|                                   | downlinks                         |
+-----------------------------------+-----------------------------------+
| Comment                           | Includes additional information   |
|                                   | about the activity, including     |
|                                   | calibration events, types of      |
|                                   | downlinks, etc.                   |
+-----------------------------------+-----------------------------------+

#  Appendix A: Potential List of International Cooperator Ground Stations {#appendix-a-potential-list-of-international-cooperator-ground-stations .unnumbered}

  --------- ------------------------- --------------- ---------------- ----------
  Station   Location                  Latitude (deg)  Longitude (deg)  Altitude
                                                                       (km)

  ASN       Alice Springs, Australia  23:45:32.0000 S 133:52:56.0000 E 0.579

  BJC       Beijing, Peoples Republic 40:27:02.0000 N 116:51:26.0000 E 0.109
            of China                                                   

  BKT       Bangkok, Thailand         13:43:48.0000 N 100:47:24.0000 E 0.002

  COA       Cordoba, Argentina        31:31:27.0000 S 64:27:49.0000 W  0.73

  CUB       Cuiaba, Brazil            15:33:10.0000 S 56:04:24.0000 W  0.268

  DKI       Parepare, Indonesia       03:58:41.0000 S 119:38:59.0000 E 0.09

  GNC       Gatineau, Canada          45:34:52.6800 N 75:48:22.3200 W  0.286

  HAJ       Hatoyama, Japan           36:00:13.0000 N 139:20:53.0000 E 0.088545

  HIJ       Hiroshima, Japan          34:21:52.7800 N 132:22:43.0170 E 0.01915

  HOA       Hobart, Australia         42:55:32.0000 S 147:25:14.0000 E 0.15

  JSA       Johannesburg, South       25:53:24.0000 S 27:42:00.0000 E  1.543
            Africa                                                     

  KIS       Kiruna, Sweden            67:52:36.0000 N 21:03:44.0000 E  0.51

  MPS       Maspolomas, Spain         27:45:36.0000 N 15:37:48.000 W   0.154

  MTI       Matera, Italy             40:39:00.0000 N 16:42:00.0000 E  0.53

  PAC       Prince Albert, Canada     53:12:45.0000 N 105:56:01.0000 W 0.489

  PF1       Poker Flat (DataLynx),    65:07:04.5303 N 147:26:00.5960 W 0.519074
            Alaska                                                     

  SEK       Seoul, Korea              37:27:33.3714 N 127:04:07.2243 E 0.14947

  SGS       Svalbard, Norway          78:13:50.6006 N 15:23:22.9048 E  0.480434

  TFT       Taipei Fixed Taiwan       25:05:34.9000 N 121:23:24.0000 E 0.27

  UPR       University of Puerto Rico 18:12:39.9600 N 67:08:12.4800 W  0.1
  --------- ------------------------- --------------- ---------------- ----------

# Appendix B: Design Reference Case {#appendix-b-design-reference-case .unnumbered}

See Excel file attachment.