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

> **LANDSAT DATA CONTINUITY**
>
> **MISSION (LDCM)**
>
> **Operations Concept**
>
> **VERSION 0**
>
> **June 1, 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 Systems Engineer             |
| Manager                          |                                   |
|                                  | SAIC, contractor to USGS EROS     |
| NASA GSFC Code 581               |                                   |
+----------------------------------+-----------------------------------+
| ***Reviewed by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_\_\_               | \_\_\_\_\_\_\_\_\_ Jim Nelson     |
|                                  | Date                              |
| Ted Grems Date                   |                                   |
|                                  | LDCM Lead Systems Engineer        |
| LDCM Systems Engineer            |                                   |
|                                  | SAIC, contractor to USGS EROS     |
| AI Solutions GSFC Code 427       |                                   |
+----------------------------------+-----------------------------------+
| ***Approved by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_\_\_               | \_\_\_\_\_\_\_\_\_ Date           |
|                                  |                                   |
| Del Jenstrom Date                | USGS                              |
|                                  |                                   |
| LDCM Deputy Project Manager      |                                   |
|                                  |                                   |
| NASA GSFC Code 427               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_\_\_               | \_\_\_\_\_\_\_\_\_ Tom Kalvelage  |
|                                  | 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 Applicable Documents 7](#applicable-documents)

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

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

[2.2 Flight Operations Segment 8](#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 Users
10](#primary-internal-external-users)

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

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

[3.1.1 Observatory 12](#observatory)

[3.1.2 Ground Support Equipment 13](#ground-support-equipment)

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

[3.2.1 Collection Activity Planning 14](#collection-activity-planning)

[3.2.2 Mission Operations 14](#mission-operations)

[3.2.3 LDCM Ground Network 17](#ldcm-ground-network)

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

[3.3.1 Storage and Archive 17](#storage-and-archive)

[3.3.2 Image Processing 18](#image-processing)

[3.3.3 User Portal 18](#user-portal)

[3.3.4 Image Assessment 19](#image-assessment)

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

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

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

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

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

[4.1.1 Facilities 20](#facilities)

[4.1.2 Security 21](#security)

[4.1.3 Training 21](#training)

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

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

[4.2.1 Role of Prime Mission Contractor
22](#role-of-prime-mission-contractor)

[4.2.2 Ground Hardware 22](#ground-hardware)

[4.2.3 Ground Software 23](#ground-software)

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

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

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

[5.3 Commissioning 27](#commissioning)

[5.4 Operations 28](#operations)

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

[5.4.2 Collect Wideband Data (LDCM-02)
30](#collect-wideband-data-ldcm-02)

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

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

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

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

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

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

[5.4.9 Communications with TDRSS (LDCM-09)
44](#communications-with-tdrss-ldcm-09)

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

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

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

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

[5.5 Decommissioning 50](#decommissioning)

# 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.

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

-   Acquire and manage the LDCM launch services;

-   Manage the LDCM observatory early 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,
    archive, and distribution system(s);

-   Manage the development and operations of the LDCM ground network;

-   Manage the development and operations of the LDCM data collection
    scheduling capability

-   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 this 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.

## Applicable Documents

LDCM Lexicon

# 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.a. It should be noted that the specific
functions within these segments may change during the implementation
phase of the LDCM.

![](media/image4.pct){width="5.996527777777778in" height="3.64375in"}

**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
instrument(s) and the spacecraft platform(s). 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. Instrument and
ancillary data will be collected, stored onboard and subsequently
downlinked to ground stations within the LDCM ground network.
Additionally, a real-time downlink capability will transmit instrument
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 (CAP) 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). 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 functions perform
ingest and long-term archival. The Image Processing function processes
all data received to assess quality and performance, while Image
Assessment functions perform characterization and calibration updates. A
capability to receive and fulfill user requests for LDCM image
collections and data products is provided by the DPAS User Portal
function. The DPAS will be located at the USGS Center fro 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.

[TDRSS]{.underline}

NASA's Tracking and Data Relay Satellite System (TDRSS) network will
provide S-band communications capabilities for LDCM. TDRSS is a
communication signal relay system that provides continuous tracking and
bi-directional data transmission services between low earth orbiting
spacecraft and ground receiving stations, using satellite to satellite
communications links to allow communications even when the target
satellite is not in view of a ground station. LDCM will utilize TDRSS
during launch and early orbit operations, at a minimum, for telemetry,
tracking, and control.

[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 instrument 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}

[NORAD]{.underline}

The Air Force Cheyenne Mountain staff presently support NASA TDRSS 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, sent to the ESMO
ESC (refer to description below). There are three levels of warning,
with three associated volumes used for the conjunction analysis.

[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, EO-1 and 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.

## Primary Internal & External Users

[Users]{.underline}

Users encompass all those members of the general public that use Landsat
data for purposes as diverse as scientific research and operational
resource management. Users interface 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 set of Users that have the ability to receive LDCM
data from the observatory real-time downlink stream. Real-time
instrument 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.

[Prime Mission Contractor (PMC)]{.underline}

The LDCM Prime Mission Contractor (PMC) is the contractor who will
provide the LDCM Space Segment and Mission Operations Element under
contract to NASA. The PMC will perform LDCM mission operations from
launch through on-orbit acceptance of the observatory and mission
operations systems by NASA. Following on-orbit acceptance and the
transition to USGS, the PMC will provide sustaining engineering support
to USGS. The PMC may include sub-contractors, but for the purposes of
this document, the entire team is referred to as the PMC.

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

The LDCM Flight Operations Team (FOT) is the team of mission operations
personnel managed by the USGS. The FOT will assume full operations of
the observatory following on-orbit acceptance.

[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 Science Team will also include NASA
science representation.

[Independent Cal/Val Team]{.underline}

The Independent Calibration/Validation (Cal/Val) team consists of
discipline scientists and engineers who perform calibration of the LDCM
instrument(s) and data. The Independent Cal/Val Team is geographically
dispersed and includes members from both NASA and USGS. While the team
will advise the PMC in instrument calibration, they will remain
independent from the PMC 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 instrument(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 and TDRSS. 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 daily command loads encompassing
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
record health and safety telemetry at all times. During contacts with a
ground network station, the real time telemetry data will be downlinked.
Stored telemetry data will also be downlinked over the wideband link.

The observatory will have the ability to determine 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 perform attitude and orbit adjustments
as commanded 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.

The observatory will monitor the health and status of each sub-system
including the instrument(s). Corresponding telemetry will be generated
and stored on-board for future transmission to the LDCM ground stations.
Additionally, observatory telemetry will be transmitted in real-time via
S-band communications to TDRSS and LDCM ground stations.

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

The LDCM observatory will nominally collect multispectral images of the
Earth referenced to WRS-2. Additionally, the observatory will be able to
collect image data along a WRS-2 path adjacent to the observatory ground
track in lieu of imaging the nadir WRS-2 path. The observatory will
collect images of the moon for instrument calibration. 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 LDCM observatory will collect image data in the form of image
intervals -- periods of time (typically, seconds to minutes) in which
the observatory is collecting image data of the Earth or calibration
targets. The observatory will be capable of collecting 1 or more image
intervals per orbit, and the separation between image intervals may be
as small as the time required to collect 1 WRS-2 scene. The observatory
will collect image data at an expected rate of at least 400 WRS-2 scenes
meeting image quality requirements plus required calibration data per
24-hour period.

Earth image data and calibration data may be collected at any point in
the orbit, and will be temporarily stored on board the observatory.
Image data will be transmitted via a wideband communications stream to
LDCM ground stations, and will be real-time downlinked to both the
International Cooperators (ICs) and LDCM ground stations. Priority image
data collections will be downlinked in advance of non-priority
collections to the first available LDCM ground station or to an IC. The
wideband data stream will also contain ancillary data, including
instrument and select spacecraft telemetry, calibration data, and other
data necessary for image processing. The observatory will be capable of
transmitting the equivalent of at least 400 WRS-2 scenes meeting image
quality requirements and associated calibration data per 24-hour period.

The observatory will be capable of simultaneously collecting, storing,
and transmitting (both in real-time and playback) telemetry and image
data. The observatory will also be capable of re-transmitting telemetry
and image data if the original transmission was not properly received.

### 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. This segment
is also responsible for maintaining observatory health and safety and
on-orbit sustaining engineering. The primary capabilities of the FOS are
Collection Activity Planning; Mission Operations; and the LDCM Ground
Network.

### Collection Activity Planning

The FOS Collection Activity Planning (CAP) functions build and manage a
collection activity request for the LDCM instrument(s). The collection
activity plan includes:

-   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

-   Non-routine instrument 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 CAP functions to identify the best
opportunities to collect cloud-free images. Factoring in cloud cover,
the CAP de-conflicts the requests and develops the collection activity
request. 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 CAP operating procedures. CAP will generate a collection activity
request every 24 ([TBR1]{.mark}) hours, and each request will encompass
72 ([TBR2]{.mark}) hours of activities.

Special imaging requests, such as for natural disasters or to support
unique science research campaigns, are forwarded to the LDCM DCP -- a
USGS team member(s) responsible for coordinating and approving special
requests. The DCP interacts with the CAP 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.

### Mission Operations

The FOS Mission Operations Element includes four primary functions;
Mission Planning and Scheduling; Command and Control; Flight Dynamics;
and Long-Term Trending. The capabilities to perform these functions will
physically reside in the Mission Operations Center (MOC).

A limited number of MOE functions will be available through remote
access. Remote access to selected MOE functions will allow FOT to
perform certain operations functions without being present in the MOC.
Observatory commanding will *not* be performed via remote access.

#### Mission Planning and Scheduling

Mission Planning and Scheduling (MPS) functions will plan/coordinate and
schedule observatory and ground station ([TBR3]{.mark}) activities. A
key input to this function is the collection activity plan developed by
the CAP function. In addition to the received image collection activity
plan, MPS will plan and schedule

-   Observatory activities such as orbit adjustments, routine
    calibrations, maneuvers, and ground station contacts.

-   Ground station contacts including those to the LDCM Ground Network,
    ICs, and those performed through TDRSS [(TBR4)]{.mark}.

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

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 tracking of ground systems hardware and software downtimes and
preventive maintenance.

[]{.mark}

Incorporating the collection activity request, the MPS functions will
plan and schedule these activities, perform any schedule de-confliction,
and generate the observatory activity schedule. The MPS will generate an
activity schedule every 24 ([TBR5]{.mark}) hours, and each schedule will
encompass 72 ([TBR6]{.mark}) hours of observatory operations.

#### Command and Control

The Command and Control Function builds 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 MPS function, while flight software
updates will be received from the LDCM Prime Mission Contractor.
Commands are formulated into encrypted RT CCSDS commands and routed to
the LDCM Ground Network or through TDRSS 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 function monitors the LDCM observatory beginning
with the receipt of real-time (RT) and stored downlinks from the LDCM
Ground Network or through TDRSS. Spacecraft housekeeping telemetry is
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).

New commands are developed and tested off-line using an observatory
simulator. This simulator receives and executes test commands, simulates
resulting telemetry, and sends it back to the MOE for analysis by FOT
personnel. All new commands will be fully tested prior to transmission
to the observatory. The observatory simulator will also be used for FOT
training and anomaly resolution.

#### Flight Dynamics

Flight Dynamics functions include

-   Orbit analysis and propagation

-   Maneuver planning in order to maintain the proper LDCM orbit

-   Calibration of any observatory on-board sensors

```{=html}
<!-- -->
```
-   Determination of ground station masks and available LGN ground
    station contact times

-   Determination of potential TDRSS contact times

-   Definitive ephemeris generation

#### Trending and Analysis

All housekeeping telemetry for the mission is stored on line in order to
perform Trending and Analysis functions. A suite of analysis tools is
provided for 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.

#### Autonomy

The MOE will have the capability to support non-commanding operations
autonomously. When the observatory is operating based on a command load,
the MOE will be able to support mission operations without staffing for
periods of time. Unstaffed operations include contacts with ground
stations and real-time monitoring of the S-band telemetry data within
the command and control function. Any problems detected will cause the
MOE to autonomously activate a notification and call-in system for the
FOT. This autonomous operations capability would not be implemented
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, but with less redundancy. The bMOE will be
located in a backup MOC facility, at a geographically separated location
that allows it to serve as a backup in the event of a critical failure,
malicious attack, or natural disaster at the primary MOC facility.

### LDCM Ground Network

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

Each node in the LDCM Ground Network includes a ground station that will
be capable of receiving LDCM wideband data. Additionally, each station
provides complete S-band uplink and downlink capabilities. These enable
the Command and Control function to interface to the observatory.

The LDCM Ground Network includes a data routing capability. This allows
the transfer of data and commands/telemetry between the nodes, the
Command and Control function, and TDRSS in a secure manner. If data is
not successfully received by a node, the LDCM Ground Network will be
capable of re-transmitting data between nodes.

#### Tracking Data Relay Satellite System Interface

The LDCM Ground Network will interface to the NASA 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 critical maneuvers or anomaly
resolution. The LDCM Ground Network will interface to TDRSS through the
TDRSS White Sands Complex (WSC) in Las Cruces, NM. The WSC will perform
S-band communications directly with the TDRSS satellites. The TDRSS
satellite(s) will continually track the LDCM observatory to provide a
continuous real-time S-band link. The availability of TDRSS capabilities
will be coordinated between the WSC and the Planning and Scheduling
function within the Flight Operations Segment.

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

The Storage and Archive Function receives all LDCM data from the Flight
Operations Segment for archival. LDCM wideband 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 Function archives all LDCM data. The LDCM data
includes LDCM image data, telemetry data, ancillary data, and mission
related data (e.g. engineering and pre-launch test data, development and
engineering documentation from all phases of the program). Ancillary
datasets include Digital Elevation Models (DEMs), water mask datasets,
and ground control datasets. The total volume of the data archived is
nominally 275 GB per day or 510 TB for a five year mission.

In addition, the Storage and Archive Function:

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

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

### Image Processing

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

The Image Processing Function generates browse imagery and metadata for
all image collections stored in the LDCM archive. Additionally, all
instrument 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 detector-level statistics and
related information for use by the calibration and validation function.

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.

### User Portal

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

### Image Assessment

The Image Assessment 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 Assessment 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 various calibration-related parameters and data. (Note that the
latter function executes within Image Processing for performance
reasons.)

The Image Assessment 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 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.

## 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 NASA Medium-class
(e.g. Delta II) Expendable Launch Vehicle. The LV will be delivered to
the launch site and 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

The LDCM will be responsible for assuring that LDCM infrastructure needs
are met. 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

Security plans and procedures will be developed for LDCM later in the
development life cycle. Security logistics are expected to include

-   Secure access to 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.

-   Information technology measures to ensure undisrupted operations of
    LDCM software or network capabilities as specified in NPR 2810.1 and
    the USGS LDCM System Security Plan.

### Training

Details of LDCM operations training will be established later in the
LDCM development cycle. FOT training is expected to include:

-   Involvement in observatory integration and testing, including
    training on observatory engineering and operations

-   All LDCM routine and contingency operations procedures

-   Use of MOE hardware and software systems

-   Maintenance of MOE hardware and software systems

The LDCM Flight Operations Team is expected to be knowledgeable on the
testing and operations of the LDCM instrument(s) and spacecraft,
beginning well in advance of LDCM launch, through integration of the
Flight Operations Team with the space segment engineering and test
teams. Training of the LDCM Flight Operations Team will ensure that they
are well-prepared and ready to safely operate the observatory.

Training will take various forms, depending on the type of training. For
example, operators will be trained using equipment that emulate the
interfaces and simulates observatory performance with high fidelity.
Software and hardware maintenance personnel may receive training from
vendors on specific programs or equipment.

### 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, and that this topic will be included in operator
    training.

-   Safety, to be consistent with NASA and USGS safety plans,
    guidelines, 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 operations will be coordinated with the LDCM FOT to
assure that routine support does not interfere with operations.

### Role of Prime Mission Contractor

The LDCM Prime Mission Contractor will provide observatory sustaining
engineering support during the 5-year mission life. Observatory
sustaining engineering will primarily support non-nominal operations
such as anomaly resolution and flight software updates. The Flight
Operations Team will coordinate with the Prime Mission Contractor for
access to and exchange of data and information necessary to perform
observatory sustaining engineering, and will coordinate observatory
sustaining engineering activities to avoid disruptions to routine flight
operations.

Observatory sustaining engineering will include review of data,
technical/engineering analyses, and review of changes to documentation.
Sustaining engineering will also include investigation of on-orbit
observatory anomalies and recommendations for resolution.

Observatory sustaining engineering will also include flight software
updates and maintenance. The Prime Mission Contactor will maintain the
flight software development environment and will provide flight software
updates to the MOE for uplinking to the observatory. Standard procedures
for flight software updates will be developed and tested prior to
launch. All updates will be tested on a non-interference basis.

The Prime Mission Contractor will also provide support for MOE
maintenance, including investigation of MOE system anomalies and
recommendations for resolution.

### Ground Hardware

Ground hardware sustaining engineering will encompass the installing,
monitoring, testing and maintaining all hardware within the Flight
Operations and Data Processing and Archive Segments. FOS and DPAS
hardware includes, but is not limited to computer systems, ground
station antennas, IT equipment; and communications equipment. It is
expected that the FOS and DPAS architectures will be modular in nature
so that future upgrades are easy to perform. The precise way that ground
hardware sustaining engineering will be done will be further defined in
the FOS and DPAS operations concept documents. 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.

### Ground Software

Ground software sustaining engineering includes installing, monitoring
and maintaining all LDCM software, databases and processors within the
FOS and DPAS, including IT administration software, operational and
ground software. Ground software sustaining engineering does not
including observatory flight software.

The ground software sustaining engineering activity is generally
concentrated on monitoring and maintaining operations; however, software
may also be developed to make the operations more efficient. It is
expected that the software provided 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.

# 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 instrument(s),
observatory, and ground-based system development, testing, and
integration through the final phase of launch readiness.

In the Pre-launch phase, the Prime Mission Contractor (PMC) will design,
develop, integrate and test the LDCM observatory. These activities will
occur at the PMC facilities. The Independent Cal/Val Team will
participate in the instrument level testing with the PMC. This will
include independent characterization of the radiometric sources used by
the PMC to calibrate the space segment instruments. The Independent
Cal/Val Team will also independently analyze selected PMC-collected
data. Observatory development progress will be assessed through a
comprehensive set of peer and independent reviews.

During these activities, the anticipated roles of the LDCM Flight
Operations Team will include observing and/or participating in testing
and integration of the instrument(s) and observatory.

In parallel with the design and development of the space segment, the
design and development of the FOS and DPAS will take place. Early
activities will include requirements decomposition, design of segment
components and interfaces, and design of interfaces to the space
segment. The FOS and DPAS requirements and designs will be reviewed at
the ground System Requirements Review (SRR), Preliminary Design Review
(PDR) and Critical Design Review (CDR), and also at mission-level
reviews.

Prior to significant integration and test of the observatory and ground
systems, a Mission Operations Review (MOR) will take place. The purpose
of the MOR is to demonstrate that all aspects of flight and ground
operations are incorporated into the plans and schedules necessary to
support integration at the PMC facility and the launch site, as well as
launch and early orbit, routine mission, and end-of-life operations.
Flight and ground system operational interfaces and operations plans
will be reviewed during the MOR.

FOS testing and training will take place during the Pre-launch phase to
assess the performance of the functions and components within the FOS.
The PMC will perform integration and testing of the Mission Operations
Element (MOE), and will deliver and integrate it within the MOC. The PMC
will provide training to the FOT on the use of the MOE. The FOT and PMC
will work together [(TBR)]{.mark} to perform integrated FOS testing and
integrated ground system testing. Key operational aspects of the testing
will include testing functions such as command generation and
transmission to the LDCM Ground Network and operations of the LDCM
ground stations. Interfaces between the observatory, LDCM ground
network, the ICs, and TDRSS will also be tested.

The functions and components within the DPAS will also be tested during
the Pre-launch phase. PMC-collected data will be used to develop the
algorithms and software in the Image Assessment function within the
DPAS. Interface tests between the DPAS and FOS will take place. From a
mission operations standpoint, the emphasis is on the interface between
the DPAS and the LDCM Ground Network, which ensures that the DPAS will
be able to receive LDCM wideband data.

A Flight Operations Review (FOR) will occur just prior to the last major
interactive test between the flight and ground system elements before
shipment of the observatory to the launch site. At the FOR, the results
of its mission operations activities will be reviewed to demonstrate
compliance with requirements, and that the ability to execute all phases
and modes of mission operations has been demonstrated.

LDCM system integration across all segments will take place and will
test the end to end interfaces between the observatory, TDRSS, FOS, and
DPAS. This end-to-end data flow tests to demonstrate that both wideband
and S-band data can be transferred between the observatory and the FOS,
and that the DPAS can receive wideband data and make LDCM data products
available for users. Operations testing on the integrated system will be
performed using the LDCM operations plans and procedures. Results of any
mission simulations will be presented along with remaining discrepancies
and work to be performed.

An Operations Readiness Review (ORR[)]{.underline} will take place to
establish that the LDCM system is ready to transition into an
operational state. The ORR will examine the results of observatory, FOS,
and DPAS tests, analyses, and operational demonstrations.

A NASA Goddard Space Flight Center (GSFC), government-only, Mission
Readiness Review (MRR) will also be conducted. The MRR will assess the
readiness of GSFC-managed LDCM missions for launch and on-orbit
operations, and will provide the documented basis for certifying to NASA
Headquarters that the mission is ready for launch.

Following successful integration and testing of the LDCM, the
observatory and associated GSE will be prepared for shipping, and then
shipped to 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). Any remaining observatory integration and test
activities required before mating to the launch vehicle are performed at
the PPF. Observatory GSE is typically linked to the MOE in the MOC via
data lines, RF links, and any voice and video lines, if required. The
FOS MOE can then exchange telemetry and commands with the observatory
through the GSE or through an RF link in the PPF while the observatory
is in the PPF or at the launch complex.\
\
At the launch site a Flight Readiness Review (FRR[)]{.underline} will
take place. This review will assess the overall readiness of the total
LDCM system to support the objectives of the mission.

Following final preparations in the PPF, the observatory is transported
to the launch complex where it is mated to the LV. All ground-based
services to the observatory will be provided through the LV-GSE. The LV
umbilical will provide the interface between the observatory and the
observatory's electrical GSE in the launch site blockhouse. The
observatory electrical GSE provides the MOE command and control
functions while the observatory is mated to the LV.

While mated to the LV, an observatory "aliveness" test will take place
to ensure the observatory is functioning as expected. This will include
the exchange of commands and telemetry between the observatory and the
MOE located at the MOC. This test would not involve the observatory
electrical GSE. The observatory S-band communications will be open air
radiated to antenna "hats" temporarily mounted in the observatory. The
S-band communications stream will be routed through the launch site RF
network for monitoring by the MOE.

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.

Two to three days before the scheduled launch date, a Launch Readiness
Review (LRR[)]{.underline} will occur. The LRR will ensure that all
flight and ground hardware, software, personnel, procedures, and the
launch range are ready to support a safe and successful launch.

## 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.

In this phase, the LDCM FOT will conduct operations of the LDCM from the
LDCM MOC. Since the PMC is ultimately responsible for observatory
operations during this phase, it is expected that the PMC will
appropriately train the FOT, and will oversee all operations within the
MOC during this phase of the mission.

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 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. If the observatory is powered on, observatory S-band telemetry
will be real-time transmitted to TDRSS for relay to the LDCM ground
network during launch, and/or will be stored and transmitted following
spacecraft activation. After achieving the injection orbit, the LV
releases the observatory. Following release, the LV will perform a
collision avoidance maneuver. []{.mark}

Early orbit begins at spacecraft separation from the LV. At this point
the launch service contractor will provide the FOS MOE with a state
vector at observatory separation to provide assistance for early
tracking coverage.

The spacecraft will perform a pre-programmed activation sequence after
separation from the LV to provide power to the observatory and turn on
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 days and will require
periodic orbit determination using observatory telemetry and flight
dynamics analysis. The NASA Goddard Space Flight Center Flight Dynamics
Facility personnel will provide support to the LDCM FOT and the PMC
during early orbit.

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
continually transmitting S-band telemetry to TDRSS for routing to the
FOS MOE. Additionally, the observatory will begin transmitting real-time
S-band telemetry directly to the LDCM ground stations. Stored telemetry
will also be transmitted using the wideband communications stream to the
LDCM ground stations.

During early orbit, activation of the LDCM instrument(s) begins. The
instrument(s) will be activated based on a series of steps following
outgassing, including powering on of instrument electronics, functional
checkout of any on-board calibration sources, generation of instrument
health and status, and collection of the first image. Image data and
ancillary data will be transmitted via wideband 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. Image and ancillary
data will also be received by the LDCM ground network and routed to the
DPAS.

## Commissioning

During on-orbit commissioning and acceptance, the LDCM observatory will
demonstrate that it meets pre-defined performance requirements through
successful completion of observatory acceptance testing. The acceptance
testing will address a series of performance requirements for the
spacecraft such as command and data handling; attitude & orbit
determination and control; power/thermal management; S-band
transmit/receive; and wideband transmit capabilities.

Similarly, the LDCM instrument(s) will demonstrate that it meets
pre-defined performance requirements through successful completion of
instrument acceptance tests. The instrument(s) must produce imagery that
meets image quality specifications for geometric accuracy, radiometric
accuracy, and spatial response. Instrument calibration will be a
significant part of commissioning and acceptance, and will include
calibration maneuvers and measurements of on-board sources. Based on
these initial calibration data, instrument tuning will be performed.
Calibration measurements and maneuvers may be performed multiple times
in order to achieve image quality requirements. Operational performance
requirements will also be verified, including the collection and
delivery of 400 scenes/day over a 16-day period ([TBR8]{.mark}).

During commissioning the LDCM observatory may seek coincident
acquisitions with operational high- and moderate-resolution imaging
sensors. These acquisitions will be coordinated with the operators of
those systems as needed.

During commissioning, the DPAS will receive LDCM wideband data routed
from the ground network. As part of the acceptance testing, instrument
data will be processed using the LDCM algorithms provided by the PMC and
implemented by USGS within the DPAS. The geometric, radiometric, and
spatial response accuracy of the resulting data products will be
assessed against the imagery requirements.

At the completion of on-orbit commissioning, an On-orbit Acceptance
Review (OAR) will take place. Upon the successful completion of the OAR,
the LDCM Project will officially accept delivery of the observatory and
MOE.

## 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 acquisition requests and ends with upload of a
command sequence to the spacecraft.

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

![](media/image6.wmf){width="5.9944444444444445in"
height="3.754861111111111in"}

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

  ---------------------------------------------------------------------------
  **Step**   **Description**
  ---------- ----------------------------------------------------------------
  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 instrument calibration. The User Community
             and Independent Cal/Val Team interface with the DPAS User Portal
             function to submit 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 for
             consideration. This step is also optional, since user image
             requests will not always be made.

  3          The DPAS storage and archive function makes the entire inventory
             of LDCM data in the archive available to the planning &
             scheduling function. This information includes the cloud cover
             percentages for all data in the archive.

  4          As part of the Planning and Scheduling 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.

  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 MOE Planning and Scheduling function uses the collection
             activity request to generate an overall observatory activity
             schedule.

  7          The MOE Command & Control function converts the observatory
             activity schedule into a command load. 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.

  7          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 CalVal Team
             member(s) who originally placed the request.
  ---------------------------------------------------------------------------

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

### Collect Wideband Data (LDCM-02)

#### Description

This scenario illustrates the collection of LDCM image data. This
scenario begins with the initial collection by the observatory and ends
with the ingestion into the DPAS archive. (Note that stored telemetry
playback through the wideband link is described in scenario LDCM-05.)

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

![](media/image7.wmf){width="5.996527777777778in"
height="2.8208333333333333in"}

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

  ---------------------------------------------------------------------------
  **Step**   **Description**
  ---------- ----------------------------------------------------------------
  1          The Space Segment observatory 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 data are then downlinked to the
             LDCM Ground Network.

  3          A ground station within the LDCM Ground Network receives the
             data from the Space Segment observatory. The 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 specified by the Image
             Assessment function and makes those data available to the Image
             Assessment function.

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

  7          The Storage & Archive function makes available metadata
             regarding all data received to the Collection Activity Planning
             function.
  ---------------------------------------------------------------------------

Table 5‑2. Collect Image 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.wmf){width="5.997222222222222in"
height="2.9006944444444445in"}

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

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | The Prime Mission Contractor generates a new flight software   |
|     | update. 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.        |
+-----+----------------------------------------------------------------+
| 3   | If necessary, the Command & Control function tests the flight  |
|     | software update command sequence using the observatory         |
|     | simulator. This test does not verify the flight software       |
|     | itself, only the command load for applying the software. A     |
|     | flight software update request is forwarded to the Planning    |
|     | and Scheduling function.                                       |
+-----+----------------------------------------------------------------+
| 4   | The Planning & Scheduling incorporates the flight software     |
|     | update into the observatory activity schedule. The observatory |
|     | schedule is sent back to the Command & Command 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 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 was 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.wmf){width="5.99375in" height="2.79375in"}

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

  ---------------------------------------------------------------------------
  **Step**   **Description**
  ---------- ----------------------------------------------------------------
  1          The User 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.

  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.wmf){width="5.995833333333334in"
height="2.951388888888889in"}

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 through the wideband              |
|     | communications stream to the LDCM Ground Network. The          |
|     | real-time telemetry is also downlinked via the S-band stream   |
|     | 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 FOS 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 FOS 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. This interaction with a FOT operator may be optional     |
|     | ([TBD6]{.mark}) if the FOS is not staffed 24/7.                |
+-----+----------------------------------------------------------------+
| 4   | Following each telemetry pass contact, the data are saved into |
|     | an archive. This archive contains all telemetry data acquired  |
|     | since launch.                                                  |
|     |                                                                |
|     | The 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 FOS 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 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 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        |
|     | Assessment function to access observatory state of health data |
|     | for the long term calibration and performance monitoring of    |
|     | the instrument(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.

#### Walkthrough

![](media/image11.wmf){width="5.995833333333334in"
height="3.6256944444444446in"}

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

  ---------------------------------------------------------------------------
  **Step**   **Description**
  ---------- ----------------------------------------------------------------
  1          A User 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.

  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.

  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 Planning & Scheduling function.

  5          The Planning & Scheduling function develops or revises the
             observatory activity schedule. The Planning & Scheduling
             function schedules either a Ground Network contact. The
             observatory activity schedule and resources are passed to the
             Command & Control function.

  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. The Priority
             scenes are flagged and handled differently from other image
             data. At the next scheduled Ground Network contact, the
             observatory downlinks all Priority scenes first, instead of
             sending down the oldest data stored on the observatory.

  9          The priority scenes are sent to the DPAS Storage and Archive
             function from the Ground Network station.

  10         The Storage and Archive function makes the priority data
             available to the Image Processing function immediately upon
             receipt.

  11         The Image Processing function generates the requested data
             products and makes them available to the Storage and Archive
             function for temporary storage.

  12, 13     The User Portal 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 Planning & Scheduling function 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 acquisition request.
  ---------------------------------------------------------------------------

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

#### Scenario Timeline

![](media/image12.wmf){width="5.99375in" height="3.76875in"}

Figure 8. Priority Scene Acquisition & Delivery Timeline

Figure 8 presents the timeline established to meet the worst case
scenario 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.

+---------------+-------------+---------------------------------------+
| **Timeline**  | *           | **Notes**                             |
|               | *Scenario** |                                       |
| **Step**      |             |                                       |
|               | **Steps**   |                                       |
+===============+=============+=======================================+
| Request       | 1           |                                       |
| Received      |             |                                       |
+---------------+-------------+---------------------------------------+
| CAP           | 2,3,4       |                                       |
| Processing    |             |                                       |
+---------------+-------------+---------------------------------------+
| MOE           | 5,6         |                                       |
| Processing    |             |                                       |
+---------------+-------------+---------------------------------------+
| Time to Next  | 6           | The worst case is that a pass just    |
| Pass          |             | completed and we must wait until the  |
|               |             | start of the next command uplink      |
|               |             | opportunity on the following orbit.   |
+---------------+-------------+---------------------------------------+
| Upload        | 7           |                                       |
| Revised       |             |                                       |
| Commands      |             |                                       |
+---------------+-------------+---------------------------------------+
| Time to Image | 8           | The worst case is for a scene at the  |
|               |             | southern tip of South America --      |
|               |             | Antarctic scenes would require more   |
|               |             | time.                                 |
+---------------+-------------+---------------------------------------+
| Image         | 8           |                                       |
| Acquired      |             |                                       |
+---------------+-------------+---------------------------------------+
| Time to Next  | 8           | The worst case is for a scene         |
| Downlink      |             | acquired immediately following an LGN |
|               |             | contact.                              |
+---------------+-------------+---------------------------------------+
| Downlink Data | 8           |                                       |
+---------------+-------------+---------------------------------------+
| Transfer Data | 9           | The worst case is to assume data was  |
| to DPAS       |             | downlinked to a station other than    |
|               |             | EROS, so network transfer must take   |
|               |             | place.                                |
+---------------+-------------+---------------------------------------+
| Process Data  | 10,11,12    |                                       |
+---------------+-------------+---------------------------------------+
| Product Ready | 13          |                                       |
+---------------+-------------+---------------------------------------+

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.05in" height="3.9875in"}

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 stream during contacts with stations in the |
|     | ground network.                                                |
+-----+----------------------------------------------------------------+
| 2   | The Ground Network stations forward the telemetry data to the  |
|     | Command & Control function, in real time.                      |
+-----+----------------------------------------------------------------+
| 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]{.mark}). This coordination is to     |
|     | ensure adequate operational safety in the group of satellites  |
|     | flying in the same orbital plane as LDCM.                      |
+-----+----------------------------------------------------------------+
| A2  | The Air Force Cheyenne Mountain staff sends orbital debris     |
|     | monitoring alerts to the Flight Dynamics function. These are   |
|     | position data for orbital debris, which may impinge upon a     |
|     | certain radius of the LDCM spacecraft.                         |
+-----+----------------------------------------------------------------+
| 4   | The FOT operator evaluates telemetry and makes a determination |
|     | as to whether a maneuver is required to maintain orbit and     |
|     | mission safety.                                                |
+-----+----------------------------------------------------------------+
| 5   | The FOT Operator uses the Flight Dynamics function to derive   |
|     | the details of the orbital maneuver(s) required.               |
+-----+----------------------------------------------------------------+
| 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 coverts the observatory       |
| 9   | activity schedule into a command load.                         |
|     |                                                                |
|     | 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.

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

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

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 request.

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

  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. The image
             data is stored on board the observatory for future downlink to
             an LDCM ground station.

  10         In real-time, the observatory transmits the image data as it is
             collected to the IC ground station.

  11         The IC ground station notifies the DPAS Storage and Archive
             function of the receipt of the wideband data and provides
             related information associated with the collection.

  12         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 User Community and Independent CalVal Team
             member(s) who originally placed the request.
  ---------------------------------------------------------------------------

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

###  Communications with TDRSS (LDCM-09)

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

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

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

+-----+----------------------------------------------------------------+
| **  | **Description**                                                |
| Ste |                                                                |
| p** |                                                                |
+=====+================================================================+
| 1   | The FOS MOE Planning and Scheduling function coordinates with  |
|     | the TDRSS White Sands Complex (WSC) for the availability and   |
|     | scheduling of TDRSS resources to communicate with LDCM.        |
+-----+----------------------------------------------------------------+
| 2   | The MOE Command and Control function generates a command       |
|     | sequence, and forwards this to the LDCM Ground Network.        |
+-----+----------------------------------------------------------------+
| 3   | The Ground Network sends the command sequence to the TDRSS WSC |
|     | ground station.                                                |
+-----+----------------------------------------------------------------+
| 4,  | The WSC ground station transmits the S-band communications     |
| 5   | stream to a TDRSS satellite.                                   |
|     |                                                                |
|     | The TDRSS satellite tracks the LDCM observatory and relays to  |
|     | it the S-band communication.                                   |
+-----+----------------------------------------------------------------+
| 6,  | The observatory generates telemetry data and transmits an      |
| 7   | S-band communications stream to a TDRSS satellite.             |
|     |                                                                |
|     | The TDRSS satellite relays the S-band communications stream to |
|     | the TDRSS WSC ground station.                                  |
+-----+----------------------------------------------------------------+
| 8   | The WSC ground station forwards the received S-band telemetry  |
|     | data to the LDCM ground network.                               |
+-----+----------------------------------------------------------------+
| *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 TDRSS (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

-   All segments 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 continuous over-temperature condition occurs that causes a fault
    situation (not intermittent).

-   Observatory enters safehold mode and cannot change modes without
    ground commanding.

-   The observatory successfully enters safe-hold mode.

#### 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   | An over-temperature condition occurs. The observatory detects  |
|     | over-temperature 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-06.                   |
+-----+----------------------------------------------------------------+
| *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 FOT

#### Walkthrough

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

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, Prime Mission Contractor       |
|     | observatory sustaining engineering support, NASA discipline    |
|     | engineering support, DPAS support, and the Independent Cal/Val |
|     | team.                                                          |
|     |                                                                |
|     | If the anomaly occurs prior to on-orbit acceptance, the ART is |
|     | led by PMC with NASA oversight. If the anomaly occurs          |
|     | following on-orbit acceptance, the ART is led by the USGS.     |
+-----+----------------------------------------------------------------+
| 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 and evaluates them using the capabilities within the   |
|     | Trending and Analysis functions. 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

-   LDCM data was acquired as normal, transferred to the DPAS, and the
    resulting data was judged invalid.

#### Walkthrough 

![](media/image18.wmf){width="5.99375in" height="4.047916666666667in"}

Figure 5‑14. Retransmission (LDCM-22)

  ---------------------------------------------------------------------------
  **Step**   **Description**
  ---------- ----------------------------------------------------------------
  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         The Storage & Archive function initiates a request for the
             retransmission of data held on the LDCM Observatory. This
             request can only be placed for data originally flagged to hold
             for retransmission, and only while the MOE Command and Control
             function has not instructed the Observatory to delete the data.

  B2         The Command and Control function transmits a command for
             retransmission from the observatory. This could be done either
             during the normal once per day commanding, or as a priority
             retransmission, as the mode of the data warrants.

  B3         The Observatory sends the requested data back down to the Ground
             Network as requested in the command load.

  B4         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,
without interaction with the primary mission operations center. No
scenario is shown for this because the details of activating the backup
mission operations center are design details. All nominal and
non-nominal operations can be executed from the backup location.

To ensure that the backup capability is ready, operations will be moved
to 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 Policy
for Limiting Orbital Debris Generation, NPD 8710.3.