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

> **LANDSAT DATA CONTINUITY**
>
> **MISSION (LDCM)**
>
> **Operations Concept DOCUMENT**
>
> **Revision - Draft**
>
> **December 5, 2006**

NOT A REQUIREMENTS DOCUMENT

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

# [Signature Page]{.underline}

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

# Document Revision History {#document-revision-history .Style-Heading-1-+-Left:--0\"-First-line:--0\"}

This document is controlled by the LDCM Project Management. Changes
require prior approval of the LDCM Project Management. Proposed changes
shall be submitted to LDCM Mission Systems Engineer.

  ------------- ---------- ---------- ----------------------------------------
  **RELEASE**   **DATE**   **BY**     **DESCRIPTION**

  Draft         December              Draft version; reference document for
                5, 2006               OLI Draft RFP
  ------------- ---------- ---------- ----------------------------------------

# List of TBD's/TBC's/TBR's {#list-of-tbdstbcstbrs .Style-Heading-1-+-Left:--0\"-First-line:--0\"}

This document contains information that is complete as possible. Items
that are not yet defined are annotated with TBD (To Be Determined).
Where final numerical values or data are not available, best estimates
are given and annotated TBC (To Be Confirmed). If there is an
inconsistency between two requirements then the best estimate is given
and annotated with a TBR (To Be Resolved). The following table
summarizes the TBD/TBC/TBR items in the document and supplements the
revision history.

  ---------- --------------- --------------------------------------------------
  **ITEM**   **REFERENCE**   **DESCRIPTION**

  TBD        3.2.2           Location of Mission Operations Center

  TBD        3.2.2.8         Location of backup Mission Operations Center

  TBD        3.2.3           Location of backup LDCM ground station

                             

                             
  ---------- --------------- --------------------------------------------------

#  Table of Contents {#table-of-contents .unnumbered}

[Signature Page 2](#signature-page)

[Document Revision History 3](#document-revision-history)

[List of TBD's/TBC's/TBR's 4](#list-of-tbdstbcstbrs)

[Table of Contents 5](#table-of-contents)

[1 Introduction 7](#introduction)

[1.1 Purpose 7](#purpose)

[1.2 Scope 7](#scope)

[1.3 Background 7](#background)

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

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

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

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

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

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

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

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

[2.4 Launch Services Segment 11](#launch-services-segment)

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

[2.6 Primary Internal & External Users
13](#primary-internal-external-users)

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

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

[3.1.1 Observatory 14](#observatory)

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

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

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

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

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

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

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

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

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

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

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

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

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

[3.4 Launch Services Segment 26](#launch-services-segment-1)

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

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

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

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

[4.1.1 Facilities 27](#facilities)

[4.1.2 Protection 27](#protection)

[4.1.3 Training 27](#training)

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

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

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

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

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

[5.3 Commissioning 33](#commissioning)

[5.4 Operations 34](#operations)

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

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

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

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

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

[5.4.6 Priority Scene Collection & Delivery (LDCM-06)
42](#priority-scene-collection-delivery-ldcm-06)

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

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

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

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

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

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

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

[5.5 Decommissioning 57](#decommissioning)

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

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

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

# Introduction

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

## Purpose

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

## Scope

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

## Background

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

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

## LDCM Mission Objectives

The major mission objectives are as follows:

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

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

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

## Roles and Responsibilities

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

NASA will

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

-   Acquire and manage the LDCM Launch Services Segment;

-   Serve as LDCM mission integrator

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

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

USGS will:

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

-   Manage the development, integration and operation of the LDCM Flight
    Operations Segment

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

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

    -   Manage the operations of the Mission Operations Element
        following observatory on-orbit acceptance

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

## Document Organization

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

## Reference Documents

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

  427-02-06        Dec. 4, 2006  LDCM Acronym List and Lexicon

  427-05-01        Dec. 4        Operational Land Imager (OLI) Statement
                                 of Work

  427-05-03        Dec. 4        OLI Requirements Document

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

  427-05-04        Dec. 4, 2006  OLI Special Calibration Test Requirements
                                 (SCTR)

  427-02-07        Dec. 4, 2006  LDCM World Reference System -2

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

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

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

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

# System Concept

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

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

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

## Space Segment

The Space Segment (SS) consists of the observatory and pre-launch ground
support equipment (GSE). The observatory is comprised of the imaging
sensor(s) and the spacecraft platform. The observatory will operate in a
716 Km orbit with a 16-day repeat cycle and a 10:00 a.m. (+/- 15
minutes) mean local time for the descending node. Imaging sensor and
ancillary data (combined as mission data) will be collected, stored
onboard and subsequently downlinked to ground stations within the LDCM
Ground Network via an X-band communications link. This link will also
include stored housekeeping telemetry. Additionally, a real-time X-band
downlink capability will transmit mission (imaging sensor and ancillary)
data to the LDCM Ground Network and International Cooperators (ICs)
equipped to receive these data. The observatory will also receive and
execute commands and transmit real-time housekeeping telemetry via and
S-band link to the LDCM Ground Network. 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 Element, the Mission Operations Element, and the LDCM Ground
Network Element. The Collection Activity Planning Element (CAPE)
develops a set of image collection and imaging sensor(s) calibration
activities to be performed by the observatory. The Mission Operations
Element (MOE) converts the CAPE input to specific imaging sensor and
observatory activities; plans, deconflicts, and schedules these
activities; commands and controls the observatory; and monitors the
health and status of the observatory and ground operating systems. The
MOE hardware and software systems reside in the LDCM Mission Operations
Center (MOC). There is also a backup MOE (bMOE) which resides in a
geographically separated backup MOC (bMOC). The LDCM Ground Network
(LGN) includes the ground stations that will communicate with the
observatory for commanding and monitoring, and will receive mission data
from the observatory. The LGN will route mission data and observatory
housekeeping telemetry to the Data Processing and Archive Segment.

## Data Processing and Archive Segment

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

## Launch Services Segment

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

## LDCM System Interfaces

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

[NASA Space Network]{.underline}

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

[NASA Ground Network]{.underline}

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

[External Data Sources]{.underline}

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

[]{.mark}

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

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

[Constellation Coordination System]{.underline}

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

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

The ESMO office at NASA GSFC is responsible for the operation of several
NASA Earth science missions. The LDCM orbit will allow LDCM to fly as
part of a morning constellation that includes several ESMO missions, if
they are still operational. (This constellation presently consists of
Landsat 7, Terra, SAC-C, and EO-1.) 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 observatory orbits.

[NASA Flight Dynamics Facility]{.underline}

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

## Primary Internal & External Users

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

[User Community]{.underline}

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

[International Cooperators]{.underline}

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

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

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

[Data Collection Planner]{.underline}

The USGS Data Collection Planner (DCP) manages the data collection
schedules for LDCM. The DCP operates the Collection Activity Planning
Element 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 collection, product
access and format, practical applications, and science opportunities for
new- and past-generation Landsat data. The Team will offer research and
science support to the USGS on topics that will affect the overall
success of the LDCM mission. The USGS and NASA LDCM Project Scientists
will co-chair the Science Team.

[Independent Cal/Val Team]{.underline}

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

# Functional View of Operational Concept

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

## Space Segment

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

### Observatory

Planned for a 5 year minimum mission life, the LDCM observatory will
operate in 716 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 time of the descending node. This will allow imaging sensor data
to be referenced to the second Worldwide Reference System (WRS-2) as
part of the ground processing performed by the Data Processing and
Archive Segment (Section 3.3).

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

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

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

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

[]{.mark}

The observatory will nominally collect image data equivalent to produce
400 individual scenes per 24-hour period plus any required routine
calibration and housekeeping telemetry data needed for processing the
400 scenes. (It is noted that non-routine events, such as lunar
calibrations, may impact the amount of image data collected in a given
day.) All image data collections and corresponding image intervals are
selected and scheduled by the Flight Operations Segment as described in
the next section. Image collections will include data to support global
change research, International Cooperators, special requests, and all
daytime scenes over the United States.

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

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

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

-   Receipt of S-band communications

-   Transmission of real-time housekeeping telemetry

-   Storage of real-time housekeeping telemetry

-   Transmission (playback) of stored housekeeping telemetry

> AND

-   Transmission of real-time mission data

-   Storage of real-time mission data

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

> OR

-   Storage of real-time mission data

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

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

-   Receipt of S-band communications

-   Transmission of real-time housekeeping telemetry

-   Storage of real-time housekeeping telemetry

-   Transmission (playback) of stored housekeeping telemetry

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

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

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

-   Storage of real time housekeeping telemetry

-   Transmission of real-time mission data

-   Storage of real-time mission data

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

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

-   Storage of real-time mission data

> AND

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

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

> OR

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

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

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

### Observatory Simulator

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

### Ground Support Equipment

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

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

## Flight Operations Segment

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

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

### Collection Activity Planning Element

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

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

-   International Cooperator imaging requests

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

-   Calibration-related Earth imaging requests

-   Special imaging requests

Daily cloud cover predictions from the National Center for Environmental
Prediction (NCEP) are input to the CAPE to identify the best
opportunities to collect cloud-free images. Factoring in cloud cover and
any observatory resource constraints provided by the MOE, the CAPE
processes all the requests and performs any de-confliction to develop
the collection activity request. This request is a scene-based list of
images to be collected by the imaging sensor(s). The CAPE will assign
each scene or imaging sensor(s) activity in the request a unique
identifier. (e.g. path, row, and date) The unique identifies will be
shared with the Mission Operations Element and the Data Processing and
Archive segment so that every individual scene requested can be tracked
throughout the entire planning, collection, and production process.

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

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

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

### Mission Operations Element

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

A limited number of MOE functions will be available through remote
access. Remote access to selected MOE functions such as trending data
and observatory subsystem real-time telemetry will allow FOT members or
observatory engineering support staff to support operations without
being present in the MOC. Observatory commanding will *not* be performed
via remote access.

#### Planning and Scheduling

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

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

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

-   Lunar, solar, and other non-Earth imaging calibration activities

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

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

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

-   Upload of operational data tables, flight software updates, etc.

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.
(The MOE will not prioritize image collection activities since this will
be done by the CAPE.) Mission health and safety activities will be given
higher priority over image collections.

Imaging sensor calibration activities that impact opportunities for
nominal Earth imaging, such as lunar calibrations, will be coordinated
between the Cal/Val Team and Flight Operations Team in the MOC.
Calibration activities will typically be given priority over nominal
Earth imaging. Such calibration events will be included in observatory
activity plans that are provided to the CAPE so that Earth imaging is
not planned during these periods.

Other MOE resource management activities include keeping track of ground
systems hardware and software downtimes and preventive maintenance.

[]{.mark}

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

#### Command and Control

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

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

#### Flight Dynamics

The MOE Flight Dynamics functions include

-   Orbit analysis and propagation

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

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

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

-   Processing of on-board ephemeris data to produce predicted ephemeris
    that support planning and scheduling events

-   Processing of on-board attitude sensors data to produce attitude
    history data

#### Trending and Analysis

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

#### Flight Software Management

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

#### On-board Mass Storage Management

The MOE will manage the observatory mass storage by monitoring mass
storage utilization, scheduling data in mass storage for downlink and by
monitoring the downlink of imaging sensor data through data receipt
status messages received from the LGN ground stations. Imaging sensor
data that has been successfully received by the LGN station will be
commanded by the MOE to be unprotected and available for overwriting in
observatory mass storage. Successful receipt will be indicated in the
status messages received by the MOE from the LGN ground stations. It is
anticipated that commanding for un-protection will occur near the end of
the same LGN contact in which the data was received. On a non-routine
basis, certain successfully received data may be retained on board until
the DPAS confirms successful receipt. This could occur for very special,
high priority image collections, and would be managed by the MOE and
coordinated through the CAPE and DPAS.

#### MOE Interface to Simulator

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

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

-   FOT training

-   Procedure validation

-   Maneuver rehearsals and validation

-   Flight software updates testing and validation

-   Anomaly investigation and resolution

#### Autonomy

The MOE will have the capability to support unattended operations for up
to a 72 hours contiguous period.  Unattended operations include
autonomous contacts with ground stations, downlink of housekeeping and
mission data, real-time monitoring of the housekeeping telemetry data,
monitoring of imaging sensor data receipt acknowledgements, and
commanding to unprotect received mission data.  The MOE system will be
capable of autonomously monitoring and reporting MOE systems status.

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

#### Backup MOE and Backup MOC

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

### LDCM Ground Network Element

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

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

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

### International Cooperators (ICs) Interface

The LDCM International Cooperators (ICs) will be capable of receiving
real-time downlinks of X-band imaging sensor data. ICs will submit bulk
requests for imaging sensor data collections in their respective regions
to the CAPE, and the CAPE will provide feedback and downlink schedules
to the ICs. Additionally, the ICs may submit individual scenes
collection requests through the DPAS User Portal Element (Section
3.3.3).

### NASA Space Network (SN) Interface

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

### NASA Ground Network (NGN) Interface

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

-   Norway -- SGS

-   Wallops, Virginia 11.3m -- WGS 11.3m

-   McMurdo, Antarctica -- MGS

-   Poker Flat, Alaska -- AGS

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

## Data Processing and Archive Segment

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

### Storage and Archive Element

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

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

In addition, the Storage and Archive Element:

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

-   Maintains an archive database \-- metadata information that
    describes all LDCM data in the archive.

### Image Processing Element

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

The Image Processing Element generates browse imagery and metadata for
all image collections stored in the LDCM archive. Additionally, all
imaging sensor data is processed to ascertain quality assessment
information. This processing includes verifying any checksum fields,
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 Element extracts archived data granules 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 Element generates all the LDCM data products distributed by
the DPAS, including standard Level 0 and Level 1 products. Standard
product generation includes creating products in the form of WRS-2
scenes.

The Image Processing Element 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 Element
to generate calibration parameters. The calibration parameters are used
by the Image Processing Element to generate data products which meet
performance requirements.

The Image Processing Element 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 Element. This function also performs
analysis of LDCM archive data (both sensor data and telemetry) to
extract detector-level statistics and various calibration-related
parameters and data.

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

### User Portal Element

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

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

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

## Launch Services Segment

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

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

### Launch Vehicle

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

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

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

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

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

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

# Logistics Support and Sustaining Engineering

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

## Logistics Support

### Facilities

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

-   Power, including backup power

-   Heat and air conditioning

-   Environmental services

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

-   Facility maintenance

-   Roads

-   Vehicles

-   Construction

-   Foundations for antenna

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

### Protection

LDCM protection will address:

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

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

### Training

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

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

-   Functionality of MOE software and hardware

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

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

### Management Support

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

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

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

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

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

## Sustaining Engineering

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

Sustaining engineering efforts for the Space Segment will address:

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

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

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

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

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

6.  Maintenance of the Observatory simulator and documentation.

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

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

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

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

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

4.  Maintenance and updating of LGN equipment

5.  Maintenance of network and IT resources

6.  Maintenance of any Communications Security (COMSEC) hardware or
    software

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

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

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

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

4.  Maintenance of network and IT resources

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

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

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

# Operational Phases and Scenarios

LDCM operations are described within the context of five phases:

-   Pre-Launch

-   Launch and Early Orbit

-   Commissioning

-   Operations

-   Decommissioning

## Pre-Launch

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

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

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

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

Within the FOS and DPAS, element to element I&T will be conducted in the
months leading up to segment-level I&T. Approximately 6 - 7 months
before launch, segment-level FOS I&T and DPAS I&T will be completed. FOS
I&T will include interface testing between the CAPE and MOE/MOC, and
between the MOE/MOC and LGN, including I&T of any Communications
Security (COMSEC) hardware and software. DPAS I&T will encompass the
integration of the DPAS elements and the interface to Users.

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

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

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

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

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

## Launch and Early Orbit

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

The LDCM launch countdown will begin when the NASA/KSC, launch service
contractor, LDCM Project, and USAF Western Range (WR) launch teams all
agree that there are no impediments to launch. At T=0, the LV begins its
ascent from the launch facility. During the final countdown and LV
ascent telemetry monitoring and observatory support will be preformed by
the launch team at the launch site. During all powered flight portions
of the launch and ascent through observatory separation, the LV
transmits telemetry to the LV ground tracking stations and/or
instrumented aircraft. After achieving the injection orbit, the LV
releases the observatory. The LDCM FOT assumes full operations of the
LDCM from the MOC after the observatory separates from the LV upper
stage. Following observatory release, the LV will perform a collision
avoidance maneuver.

Early orbit begins at spacecraft separation from the LV. At this point
the launch service contractor will provide the FOS MOE and the NASA
Goddard Space Flight Center Flight Dynamics Facility (FDF) with a valid
observatory separation state vector to support the first orbit
determination. This will be used to update orbit-dependent planning
products such as ground station contact data. []{.mark}

The spacecraft will perform a pre-programmed activation sequence after
separation from the LV to provide power to the observatory and turn on
critical sub-systems. It is anticipated that orbit adjustments will be
made during this phase to move the observatory from its initial parking
orbit to its nominal orbit. This will include any coordination needed to
bring the observatory into the "morning constellation" of Earth
observing satellites. These orbit maneuvers may take several weeks and
will require periodic orbit determination using observatory telemetry
and flight dynamics analysis. The NASA Goddard Space Flight Center
Flight Dynamics Facility will be available to support these early orbit
activities, if needed.

During early-orbit, the proper functionality of observatory command and
data handling functions and attitude and orbit determination and control
functions will be demonstrated. The observatory will be capable of
transmitting real-time S-band telemetry to the SN for routing to the FOS
MOE. Additionally, the observatory may begin transmitting real-time
S-band telemetry to the LDCM ground stations and the NASA Ground
Network.

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

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

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

## Commissioning

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

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

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

-   receiving these data via the Landsat Ground Network

-   DPAS processing of image data

-   Storage of data within DPAS

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

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

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

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

## Operations

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

The LDCM operations are illustrated by a series of scenarios. These
scenarios provide an overview of the major threads through the
Operational Concept to describe how major activities are accomplished.
The set of scenarios help in understanding how the LDCM system behaves,
and serves as a tool to aid in verifying the completeness of the
Operations Concept. The scenarios do not portray every possible
situation that may be encountered during operations but serve as a basis
for further operations planning.

Each scenario includes a brief description, a list of assumptions, a
data flow figure, and a table that describes the key functions and data
flows. The figure below illustrates the graphical convention used for
these scenarios. In this example, a function happens atstep 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 or alternate flow
represented as steps A1, A2 and A3 in the example.

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

Figure 5‑1. Scenario Style Example

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

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

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

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

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

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

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

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

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

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

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

  2          The observatory stores the data on board until the scheduled
             downlink opportunity. The X-band imaging sensor data are then
             downlinked to the LDCM Ground Network.

  3          A ground station within the LDCM Ground Network receives the
             X-band mission data from the Space Segment observatory. In
             near-real time, the ground station sends receipt acknowledgement
             messages to the MOE, providing confirmation of the mission data
             files successfully downlinked.

  4          Near the end of the LGN ground station contact, the MOE Command
             and Control function commands the observatory to unprotect the
             successfully-received mission data, thus allowing this data to
             be overwritten in observatory mass storage.

  5          The mission data is routed from the LGN ground station to the
             DPAS.

  6          The Storage and Archive Element makes the data available to the
             Image Processing Element.

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

  8          The Image Processing Element makes the archive-formatted data
             available to the Storage and Archive Element for archival, and
             makes the metadata for the ingested data available to the User
             Portal Element.

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

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

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

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

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

#### Walkthrough

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

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

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

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

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

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

-   The user is requesting a product from archived data.

#### Walkthrough

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

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

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

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

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

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

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

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

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

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

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

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

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

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

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

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

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

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

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

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

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

#### Walkthrough

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

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

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

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

#### Scenario Timeline

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

Figure 8. Priority Scene Collection & Delivery Timeline

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

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

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

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

### Maintain Orbit (LDCM-07)

#### Description

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

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

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

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

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

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

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

#### Description

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

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

#### Assumptions

-   All segments are functioning nominally.

#### Walkthrough

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

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 to submit individual scene
             requests. The IC interfaces with the Collection Activity
             Planning function to submit an IC-mask of relative scene
             priorities.

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

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

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

  5          The collection activity request is forwarded to the MOE.

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

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

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

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

  11         The IC ground station notifies the DPAS User Portal Element of
             the receipt of the X-band 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.

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

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

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

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

#### Description

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

#### Assumptions

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

-   All segments are functioning nominally.

#### Walkthrough

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

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

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

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

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

#### Description

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

#### Assumptions

-   The FOS and DPAS are functioning nominally.

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

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

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

#### Walkthrough

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

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

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

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

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

#### Description

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

#### Assumptions

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

#### Walkthrough

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

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

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

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

### Retransmission (LDCM-22)

#### Description

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

#### Assumptions

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

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

#### Walkthrough 

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

Figure 5‑14. Retransmission (LDCM-22)

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

Table 5‑13. Retransmission (LDCM-22)

### Backup Flight Operations

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

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

## Decommissioning

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

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

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

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

The DRC column headings are explained in the following table.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See Excel file attachment.