**Landsat Data Continuity Mission (LDCM)**

**Functional Description**

**November 1, 2001**

![](media/image1.png)

**Goddard Space Flight Center**

> **Greenbelt, Maryland 20771**

REVISION HISTORY

+-------+---------+----------------+----------------------------------+
| Doc   |         |                |                                  |
| ument |         |                |                                  |
| T     |         |                |                                  |
| itle: |         |                |                                  |
| La    |         |                |                                  |
| ndsat |         |                |                                  |
| Data  |         |                |                                  |
| Conti |         |                |                                  |
| nuity |         |                |                                  |
| Mi    |         |                |                                  |
| ssion |         |                |                                  |
| Funct |         |                |                                  |
| ional |         |                |                                  |
| D     |         |                |                                  |
| escri |         |                |                                  |
| ption |         |                |                                  |
+-------+---------+----------------+----------------------------------+
| Issue | Date    | Pages          | Description                      |
|       |         |                |                                  |
|       |         | Affected       |                                  |
+-------+---------+----------------+----------------------------------+
| In    | 1       | All            | Initial Release                  |
| itial | 1/01/01 |                |                                  |
+-------+---------+----------------+----------------------------------+
|       |         |                |                                  |
+-------+---------+----------------+----------------------------------+
|       |         |                |                                  |
+-------+---------+----------------+----------------------------------+
|       |         |                |                                  |
+-------+---------+----------------+----------------------------------+
|       |         |                |                                  |
+-------+---------+----------------+----------------------------------+
|       |         |                |                                  |
+-------+---------+----------------+----------------------------------+

DOCUMENT CHANGE HISTORY

  -------- ---------- ----------------- ----------------- -----------------
  Mod. \#  Date       CCR \#            Date              Section(s)

                                                          

                                                          

                                                          

                                                          

                                                          

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

**Table of Contents**

[1 INTRODUCTION 5](#introduction)

[1.1 PURPOSE 5](#purpose)

[1.2 SCOPE 5](#scope)

[1.3 FUNCTIONAL ALLOCATIONS 6](#functional-allocations)

[1.4 ORGANIZATION 7](#organization)

[1.5 APPLICABLE DOCUMENTS 7](#applicable-documents)

[1.6 CONVENTIONS 7](#conventions)

[2 FUNCTIONAL DESCRIPTION 8](#functional-description)

[2.1 SCHEDULE ACQUISTIONS 10](#schedule-acquistions)

[2.1.1 Manage Long Term Acquisition Plan
11](#manage-long-term-acquisition-plan)

[2.1.2 Manage Special Requests 13](#manage-special-requests)

[2.1.3 Manage Scheduler 14](#manage-scheduler)

[2.1.4 Validate LTAP Priorities 14](#validate-ltap-priorities)

[2.2 ACQUIRE DATA 15](#acquire-data)

[2.2.1 Control Observatory 15](#control-observatory)

[2.2.2 Operate Sensor 16](#operate-sensor)

[2.2.3 Downlink Data 16](#downlink-data)

[2.2.4 Generate Archive Data Sets 16](#generate-archive-data-sets)

[2.3 ARCHIVE DATA 17](#archive-data)

[2.3.1 Ingest And Assess Data 17](#ingest-and-assess-data)

[2.3.2 MAINTAIN ACTIVE ARCHIVE 17](#maintain-active-archive)

[2.3.3 Provide Data On Request 18](#provide-data-on-request)

[2.3.4 Long Term Archive 18](#long-term-archive)

[2.4 ORDER DATA PRODUCTS 19](#order-data-products)

[2.4.1 Search & Query LDCM Active Archive
19](#search-query-ldcm-active-archive)

[2.4.2 Order Products 20](#order-products)

[2.4.3 Billing and Accounting 20](#billing-and-accounting)

[2.5 PRODUCE DATA PRODUCTS 21](#produce-data-products)

[2.5.1 Generate Products 21](#generate-products)

[2.5.2 Validate Products 22](#validate-products)

[2.5.3 Distribute Products 22](#distribute-products)

[2.6 CALIBRATE LDCM DATA 23](#calibrate-ldcm-data)

[2.6.1 Characterize Sensor Performance
24](#characterize-sensor-performance)

[2.6.2 Generate Calibration Parameters
24](#generate-calibration-parameters)

[2.6.3 External Validation of Calibration
24](#external-validation-of-calibration)

[2.6.4 Technical Support 24](#technical-support)

[2.7 SYSTEM QUALITY MANAGEMENT 25](#system-quality-management)

[3 EXAMPLE OPERATIONS SCENARIOS 26](#example-operations-scenarios)

[3.1 ACQUIRING GLOBAL LDCM DATA 26](#acquiring-global-ldcm-data)

[3.1.1 Objective 26](#objective)

[3.1.2 Assumptions 26](#assumptions)

[3.1.3 Scenario Description -- Acquiring Global LDCM Data
27](#scenario-description-acquiring-global-ldcm-data)

[3.2 ORDER AND DISTRIBUTE AN ARCHIVED LDCM DATA PRODUCT
30](#order-and-distribute-an-archived-ldcm-data-product)

[3.2.1 Objective 30](#objective-1)

[3.2.2 Assumptions 30](#assumptions-1)

[3.2.3 Scenario Description -- Order And Distribute An Archived LDCM
Product
31](#scenario-description-order-and-distribute-an-archived-ldcm-product)

[3.3 SPECIAL DAR -- LOS ANGELES EARTHQUAKE
33](#special-dar-los-angeles-earthquake)

[3.3.1 Objective 33](#objective-2)

[3.3.2 Assumptions 33](#assumptions-2)

[3.3.3 Scenario Description -- Special DAR -- Los Angeles Earthquake
34](#scenario-description-special-dar-los-angeles-earthquake)

[3.4 UPDATE SENSOR AND CALIBRATION PARAMETERS
36](#update-sensor-and-calibration-parameters)

[3.4.1 Objective 36](#objective-3)

[3.4.2 Assumptions 36](#assumptions-3)

[3.4.3 Scenario Description -- Update Sensor And Calibration Parameters
37](#scenario-description-update-sensor-and-calibration-parameters)

[4 DOCUMENT DATA DICTIONARY 39](#document-data-dictionary)

# INTRODUCTION

The Land Remote Sensing Policy Act of 1992 requires the U.S. Government
Landsat Program Management to "assess options for a successor land
remote sensing system to Landsat 7." The act further requires that the
assessment of options consider the ability to "maintain data continuity
with the Landsat system" and to "incorporate system enhancements \...
which may potentially yield a system that is less expensive to build and
operate, and more responsive to data users." In pursuit of these
objectives, the Government is issuing a Request for Proposals for a
mission formulation study. The ultimate aim is to procure data and
services using a data specification based procurement.

## PURPOSE

This document is intended to describe a potential functional process for
LDCM system by taking the existing Landsat-7 functional flows and
applying them to the LDCM Data Specifications found in the LDCM Phase 1
RFP. This document uses a series of Data Flow Diagrams (DFDs) to enhance
the understanding of these functions and for illustration a minimal set
of potential Operations Scenarios. Great effort was made to make the
process in the DFDs as architecture independent as possible These DFDs
are not part of the requirements; but, do reflect some of the process
metrics called out in the RFP. These sections should offer the
Contractor some perspective, given the specifics of the DFDs presented,
as to what the government\'s involvement would be under these
circumstances.

## SCOPE

This functional process descriptions of the DFDs applies to an
operational LDCM system after the Initial Operational Capability (IOC)
milestone has been achieved. Any development or other pre-IOC activities
are not included, nor are any End-Of-Life activities included. Any
related commercial activities pertaining to data not purchased by the
government are not included in this document.

Because the LDCM is a data and services mission, with government
insight, DFDs pertaining to the calibration verification of the LDCM
data and the Systems Quality Management are included.

## FUNCTIONAL ALLOCATIONS

![](media/image2.wmf){width="5.999305555555556in" height="4.425in"}

> **Figure 1** -- Definition of the functional allocation trade space
> for the LDCM system. The functions the Contractor must perform are
> shown on the left, while functions the Government must perform are
> shown on the right. This does not include procurement-related
> functions or functions that take place before IOC is achieved.

The DFDs in the following section, attempt of break out the
Government\'s functions from the Contractor\'s functions while
indicating the areas of overlap that has to be decided in the
Contractor\'s specific proposal. See Figure 1, above, for the breakout.

The Contractor is responsible for the design, construction, launch and
operation of any system(s) proposed to generate the data requested by
the Government (sections 2.2.1 and 2.2.2). The Contractor must provide
for any ground station services necessary for the operation of the
system(s) (sections 2.2.1 and 2.2.3).

The Government owns & operates the long-term archive, which will receive
and archive all LDCM data generated under the Implementation Phase RFP
(section 2.3.4). The Government will perform it's own on orbit science
validation of data calibration (section 2.6.3); however this does not
preclude the contractor from doing its necessary calibration function.
The Government will also perform other verification processes related to
contract performance, including validation of Long Term Acquisition Plan
(LTAP) priorities (section 2.1.4).

## ORGANIZATION

This document is organized as follows:

Section 2 -- A set of Data Flow Diagrams that describe the LDCM mission
processes and data flows for LDCM data and services.

Section 3 -- A limited set of operational scenarios that illustrate how
the DFDs in section 2 relate.

Section 4 -- A data dictionary for this document.

## APPLICABLE DOCUMENTS

\[1\] The Land Remote Sensing Policy Act of 1992 (Public Law 102-555)

\[2\] LDCM Formulation Phase RFP Package, including contractual
attachments.

## CONVENTIONS

All Contractor and Trade Space processes in the Data Flow Diagrams
(DFDs) are represented by circles. Solely Governmental processes are
represented with rectangles. Each process is labeled with a number and
the name of the process. The lines between the processes represent data
flows and the names of the data flowing between the processes are noted
next to the line. Section 6 contains short definitions for all the data
flows appearing in this document. Related flows, i.e. query / response,
are grouped with circles indicating their association with each other.
The system-level DFD (Figure 2) uses some notational shortcuts to
facilitate comprehension.

Throughout this document the term "Government" is used to refer to the
U.S. Federal Government. The term "Contractor" is used to refer to the
contractor who is responding to this RFP. The term "LDCM User" or "User"
is used to refer to any person who uses the Government\'s LDCM data,
which can include government, academia, commercial users, the general
public and people from other countries.

# FUNCTIONAL DESCRIPTION

![](media/image3.wmf){width="5.997222222222222in" height="5.625in"}

> **Figure 2** -- Data Flow Diagram for the overall LDCM functional
> description. Data flows are summaries and do not capture all those
> defined in section 2. Refer to each process breakdown DFD for the
> fully developed
>
> data flows.

The function of the LDCM is to provide continuity of Landsat data beyond
the Landsat 7 mission. The Government is pursuing buying the LDCM data
through a Data Specification-based procurement. Figure 2 shows one
possible overview of the essential processes to operate a system to
deliver these data. The top level processes are: 1 Request Data
Acquisitions, 2 Acquire Data, 3 Archive Data, 4 Order Data Products, 5
Produce Data Products, 6 Calibration and 7 System Quality Management.
Each of these processes is further described in the remainder of section
2.

The output from the Schedule Acquisitions process is a list of
acquisitions to be made. The list of acquisitions is passed to the
Acquire Data process where the actual data acquisition events take
place. The acquired data is passed on to the Archive Data process where
the LDCM Active Archive resides. LDCM Users can search for and order
LDCM Data Products through the Order Data Products process. Data Product
Orders are passed to the Produce Data Products process where the actual
LDCM Data Products are produced from the Unprocessed Digital Image Data
that is housed in the Active Archive. The completed LDCM Data Products
on media are shipped to the User as requested. The Calibrate LDCM Data
process monitors the LDCM sensor and maintains the system calibration.
The System Quality Management process provides overall statistics and
reporting functions as noted in 427-SPEC-00001, LDCM Data Specification.

In the remainder of section 2 each of these processes is broken down in
more detail. The reader should keep in mind that this process breakdown
is just one possible interpretation of the processes required to
implement a system to deliver LDCM data, as required by 427-SPEC-00001,
LDCM Data Specification.

## SCHEDULE ACQUISTIONS

![](media/image4.wmf){width="5.448611111111111in"
height="5.498611111111111in"}

> **Figure 3** -- Data Flow Diagram for the Schedule Acquisitions
> process. (Circles around dataflow arrows indicate associated flows,
> such as a query and response.)

In order to obtain LDCM data from the system, acquisitions must first be
requested. The bulk of the LDCM data acquired will be scheduled by an
automated process, analogous to the Landsat-7 Long Term Acquisition Plan
(LTAP) software, represented as Manage LTAP process in Figure 3. Special
acquisitions requested by the Government are handled within the Manage
Special Requests process. All the acquisition requests are merged with
the latest cloud cover predictions and system constraints into a single
acquisition list in the Manage Scheduler process.

### Manage Long Term Acquisition Plan

The Government will be procuring an average of 250 Worldwide Reference
System Two (WRS-2) scenes of LDCM data each day. However, on any given
day many more WRS-2 scenes over land could potentially be acquired. In
order to select the "best" 250 scenes for acquisition, an algorithm is
executed to evaluate a number of factors. This algorithm is called the
long-term acquisition plan and is run within the Manage LTAP process.
The Government can modify the parameters of this algorithm, as outlined
in 427-SPEC-00001, LDCM Data Specification, typically by submitting new
seasonality file updates.

#### Landsat 7 LTAP Overview 

The Landsat 7 Long Term Acquisition Plan (LTAP) automates the selection
of Landsat scenes to periodically refresh a global archive of sunlit,
substantially cloud-free land images. By applying a set of algorithms on
a daily basis, the LTAP has evolved to optimally collect Landsat 7 ETM+
imagery for scientific applications, while minimizing the effects of
cloud-cover and system constraints.

The Landsat-7 LTAP includes several aspects that influence whether a
particular scene should be acquired or not. These include:

1\. Seasonality of vegetation, niche-science communities

2\. Predicted vs. nominal cloud-cover

3\. Sun angle

4\. Missed opportunities for previous acquisitions

5\. Quality (cloud-cover) of previous acquisitions

6\. Scene clustering

7\. System constraints (duty cycle, ground station locations, recorder
capacity, etc).

Factors 1-6 feed directly to calculating the priority of each potential
acquisition, while the actual acquisition list is obtained by
incorporating system constraints (factor 7). Factor 4 requires feedback
between the list of archived scenes and the LTAP, while factor 5
requires feedback between cloud assessment of archived scenes and the
LTAP. Each of these factors is discussed in the following sections.

Seasonality -- An objective of the LTAP is to schedule acquisitions more
frequently during periods of change, such as growth and senescence of
vegetation, and less frequently during relatively stable periods, such
as when full growth canopy exists or during winter quiescence. An 8-year
Advanced Very High Resolution Radiometer (AVHRR) Normalized Difference
Vegetation Index (NDVI) data set was used to determine where and when
changes occurred (Goward, et al., 1994, 1999). To flag seasonal change
within a WRS-2 scene, a statistical test was applied to each NDVI 45-km
sample mapped to that scene. Comparing each sample or pixel to the same
pixel two months later revealed periods of significant change in the
NDVI mean and standard deviation, when multiple acquisitions are
meaningful, and periods of minimal change, when only a single
acquisition is necessary.

The year is broken into a set of temporal "windows" for each path-row
location. During each window, a location may be labeled as "acquire
once", "acquire always", or "never acquire", and this information is
stored in the LTAP seasonality file. It should be noted that "acquire
always" does not imply that an actual acquisition will occur for every
overpass during that time window. Instead, that scene will always be a
candidate for acquisition, and other factors within the LTAP
(cloud-cover, system constraints, etc) will govern whether or not an
acquisition actually takes place. Conversely, "acquire once" means that
once a successful acquisition occurs during the time window, that
path-row location is no longer eligible for acquisition.

Niche Science Communities -- Defining acquisitions solely through
semi-monthly NDVI change does not fully capture the science and user
interest in the Landsat mission. To supplement the NDVI-based
seasonality metric, specific niche science communities have requested
locations for more frequent acquisitions. These locations currently
include:

-   282 agriculture (acquire literally every opportunity within season
    when the cloud cover prediction is less than 60%)

-   35 calibration (acquire \"always\")

-   896 reefs (acquire from 2 to 6 times per year)

-   30 fire (acquire \"always\")

-   1392 land ice (acquire once during certain months)

-   3601 Antarctica (acquire once during Jan-Feb)

-   60 oceanic islands (acquire twice per year)

-   1175 rainforest (acquire \"always\" all year)

-   352 sea ice (acquire from 1 to 3 times per year)

-   11 Siberia (acquire \"always\" over 9 months)

-   72 volcanoes (acquire from 2 to 12 times per year, including 33 at
    night)

The exact makeup of these niche science acquisitions varies each quarter
of operations, depending on user needs and science priorities. In
general, approximately 27% of the 250 scenes/day acquired by Landsat-7
are devoted to satisfying "niche" requests, approximately 70% are
devoted to satisfying routine acquisitions from the seasonality file,
and 3% are devoted to night images or special high-priority acquisitions
(natural disasters, national needs, etc).

Predicted Cloud-Cover -- The cloud-avoidance strategy is based on the
near-term predicted cloud cover with respect to the seasonal average
cloud cover for each scene. The LTAP scheduling software compares
near-term predictions to the historical average cloud cover for that
scene for that month, to determine acquisition priorities each day.
Scenes with better-than-average cloud-cover predictions are given a
priority boost, while those with poorer cloud cover predictions are
given a lower priority. Global historical cloud data were obtained from
International Satellite Cloud Climatology Project (ISCCP) records
(Rossow et al., 1996) that give monthly estimates of cloud-cover
percentage for 2.5˚ grid cells from 1989 to 1993. Monthly averages over
the 5 years were computed and mapped to the Landsat WRS grid to produce
a cloud climatology. The National Oceonographic and Atmospheric
Administration (NOAA) National Centers for Environmental Prediction
provide daily global forecasts of cloud-cover percentage at a 0.7˚ grid
scale (Campana, 1994). The forecasts are compiled at 0600 (universal
time system) each day and apply to each 3-hour interval up to 84 hours.
Once received from NOAA, these cloud predictions are translated to the
Landsat WRS-2 coordinate system. The forecast nearest in time to a
candidate acquisition is compared to the ISCCP climatology to determine
whether the predicted observing conditions are better or worse than
typical for that location. Acquisition priority is then adjusted upward
to favor the better conditions or downward to avoid the worst
conditions.

Sun Angle -- Requests for high-latitude scenes are rejected during local
winter when the solar elevation is below a threshold. This threshold is
currently 5 degrees for Landsat-7.

Missed Opportunities -- A request is granted a priority boost as a
function of the number of consecutive past cycles in which the
opportunity to acquire the requested scene was not fulfilled. This
occurs when the scene was not scheduled for acquisition, or when the
acquired image fails to meet minimum quality standards, such as cloud
cover. For example, if the last successfully acquired image of a scene
was 48 days ago, then a request for this scene is granted a priority
boost based on two missed opportunities---from 32 and 16 days ago. In
addition, all new requests (i.e. when an acquisition window opens) are
given a priority boost.

Image Quality -- Quality (cloud-cover) of the best or most recently
acquired image of a WRS-2 scene from past cycles factors into the
relative demand for another acquisition. At high latitudes, the
scheduler also considers the quality of the best image that could be
spliced together as a mosaic of imagery of adjacent scenes acquired in
the recent past. Quality is a function of cloud contamination in the
image, as determined during image processing.

Clustering -- Within the Landsat-7 LTAP, a higher priority is given to
scenes that form "clusters" -- contiguous groups of along-path
acquisitions. This (i) reduces the on-off cycling of the ETM+ instrument
and (ii) promotes the archiving of continuous swath data, which in turn
allows "floating scene" subsetting of user-defined areas without regard
for scene boundaries.

### Manage Special Requests

This is the process of accepting specific data acquisition requests from
the Government. All Government requests will come through one source to
the LDCM system. If an LDCM User wants to request a special acquisition,
this request is submitted to the Government Acquisition Manager, who
will review this request and determine whether the Government wishes to
support the request.

The Manage LTAP process will schedule the bulk of the Government's LDCM
data. The Manage Special Requests process is used for specific
Government requirements, such as coverage of natural disasters,
coordinated acquisitions with other sensors, calibration acquisitions
and others. This process includes providing an ability to see what
acquisitions are planned in the future, and submit specific requests for
a particular path/row on a particular date or dates. Each request is
called a Data Acquisition Request (DAR).

### Manage Scheduler

The Manage Scheduler process assembles a list of pending acquisitions
based on input from processes 1.1 and 1.2, commercial sales and
international cooperators. This includes factoring in engineering and
operational constraints of the data source and resolving conflicting
acquisition requests using a priority-based schema. The most recent
cloud coverage predictions are also applied for requests that have
constraints on allowable cloud cover.

The acquisition list contains future acquisitions, and is updated
periodically as appropriate. This list is passed on to the Acquiring
Data process for use in scheduling the actual vehicle & sensor
activities.

The Manage Scheduler process also tracks the status of acquisitions as
they are acquired, and notifies the Government of the final success or
failure.

### Validate LTAP Priorities

The Validate LTAP Priorities process is where verification of the LDCM
LTAP priorities is performed. The Government intends to perform
validation of LDCM LTAP priorities for the data purchased under an LDCM
contract. The LDCM system may also perform this function for other
long-term acquisition strategies for other customers.

## ACQUIRE DATA

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

> **Figure 4** -- Data Flow Diagram breakdown for the Acquire Data
> process.

The Acquire Data process is where the acquisitions planned in the
Request Acquisitions process are planned and executed. The source is
tasked, the radiances are captured by the sensor and the resulting data
is transferred from the vehicle to a location where the LDCM archive
datasets are generated.

### Control Observatory

The Control Observatory process translates the acquisition list into a
command schedule for the vehicle and sensor. This command schedule is
then transmitted to the vehicle for execution. In a traditional
space-based system, this process would execute as part of a Mission
Operations Center (MOC) through uplink-capable ground station(s). All
the necessary vehicle and sensor management activities execute within
the Control Observatory process. Some examples include station-keeping,
thruster burns, systems management, orbit determination, developing
ground contact schedules and battery maintenance.

### Operate Sensor

In the Operate Sensor process the sensor captures at-aperture radiances.
This process also includes stored vehicle command execution and any
internal data manipulation or translation processes to prepare the
sensor data for transmission to the ground reception facility.

### Downlink Data

The Downlink Data process transfers the sensor data and associated
platform information from the vehicle to one or more data reception
facilities on the ground. For a space-based system this would include
the Tracking Telemetry & Command (TT&C) components of the vehicle,
transmitting the data to one or more receiving stations, and possible
transferring of the data from the receiving stations to a data
processing facility.

### Generate Archive Data Sets

The Generate Archive Data Sets process translates the data transferred
in the Downlink Data process into the LDCM archive elements. This
includes any necessary sub setting or aggregating necessary to produce
the image data, generation of metadata, and other ancillary data and
browse images.

## ARCHIVE DATA

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

> **Figure 5** -- Data Flow Diagram breakdown for the Archive Data
> process.

The Archive Data process is decomposed in the DFD shown in Figure 5.
Data coming in to the archives are ingested in the Ingest And Assess
Data process. The Maintain Active Archive process manages the LDCM data,
while copies of all data are sent to the Government Long Term Archive.
Various processes are then able to access data in order to search for,
and request data, from the archive through the Provide Data On Request
process.

### Ingest And Assess Data

This is the process of evaluating, indexing and distributing new data
into the archives. The Ingest And Assess Data process includes data
generated in the Acquire Data process as well as transfers between
different archives holding LDCM data.

###  Maintain Active Archive

The Maintain Active Archive process maintains the Active Archive data
integrity. Maintenance of the Active Archive can include migration from
aging media, verifying archive contents, managing data, managing
databases and any other activities necessary to protect the data from
loss.

### Provide Data On Request

The Provide Data On Request process provides archived LDCM data to other
processes as requested. The Provide Data On Request process does not
include the production of LDCM Data for users, which is outlined in
2.2.5. This process includes supporting data search and browse
distribution to other internal LDCM processes.

### Long Term Archive

This is the ultimate destination for all the LDCM products that the
Government is procuring, as outlined in 427-SPEC-00001, LDCM Data
Specification.

## ORDER DATA PRODUCTS

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

> **Figure 6** -- Data Flow Diagram breakdown for the Order Data
>
> Products process.

The Order Data Products process is where users of LDCM data search for
and order LDCM data products. The Search & Query LDCM Archive process
provides the functionality for users to search for data products of
interest. Orders are placed through and managed by the Order Products
process, which refers orders to the Billing And Accounting process to
handle the monetary portions of the ordering process. Authorized orders
are passed along to the production processes outlined in section 2.5.
Note that the Calibrate LDCM Data process will place orders through the
same interfaces and methods as the Users in the context of this process.

### Search & Query LDCM Active Archive

The users ability to construct and execute searches of the Active
Archive is provided in this process. This could include inquiries made
by interactive on-line system, phone, FAX, and email.

### Order Products

The Order Products process includes the placing of new orders, tracking
the status of existing orders, and canceling or updating existing
orders. This process coordinates the related activities within the
Billing and Accounting process, prior to scheduling data product for
production.

### Billing and Accounting

This process includes all the monetary-related functions associated with
the ordering of LDCM Data Products. This could include invoicing for
data orders, accepting payments in various forms, and sending receipts,
as appropriate.

## PRODUCE DATA PRODUCTS

![](media/image8.wmf){width="5.219444444444444in"
height="4.552777777777778in"}

> **Figure 7** -- Data Flow Diagram breakdown for the Produce Data
>
> Products process.

The Produce Data Products process is the production of the LDCM data
products to fulfill the customer's order. The Generate Products process
is where all the necessary input data are collected together, and the
algorithms executed to produce the requested products. All data products
are validated prior to being written to media for distribution.

### Generate Products

The Generate Products process starts by pulling data from the archive,
including calibration parameters, engineering data, metadata, ancillary
data, digital elevation models and ground control points (as required).
After all the necessary data are retrieved, the LDCM Data Products are
processed according to that Data Product Order. All the products for the
LDCM data procurement listed in 427-SPEC-00001, LDCM Data Specification
are produced in this process.

### Validate Products

The Validate Products process provides the quality assurance and quality
control checks associated with data product production.

### Distribute Products

The Distribute Products process compiles one or more data products,
specified in the data product order, onto the specified media. For
electronic distribution of products this process simply stages the
products to the appropriate distribution site. For physical media this
process includes the packaging and shipping of the products to the LDCM
User.

## CALIBRATE LDCM DATA

![](media/image9.wmf){width="5.919444444444444in"
height="5.794444444444444in"}

> **Figure 8** -- Data Flow Diagram breakdown for the Calibrate LDCM
>
> Data process.

The Calibrate LDCM Data process maintains the calibration required for
LDCM Data Products to meet their requirements, and provides technical
support. This includes performing an external validation of calibration,
generation of calibration parameters and providing technical support in
these areas.

### Characterize Sensor Performance

The Characterize Sensor Performance process monitors LDCM Sensor. This
can include the analysis of on-board calibration information, analysis
of vehicle heath data, analysis of other calibration imagery, and
incorporation of results from the Product Validation and External
Validation processes. Refinements to the processing algorithms are
developed within this process and passed on to the production processes.

This process can include the determination of any possible changes in
the instrument configuration (detector gain levels, calibration
sequences, modifications to acquisition procedures and so forth). These
parameters are passed on to the Acquire Data process for incorporation
into future payload command files.

### Generate Calibration Parameters

The Generate Calibration Parameters process takes the Sensor
Characterization and derives the Calibration Parameters that enable
production of LDCM Data Products to meet all the geometric and
radiometric requirements specified in 427-SPEC-00001, LDCM Data
Specification.

### External Validation of Calibration

The External Validation of Calibration process collects and analyzes
validation data. LDCM Data are acquired in tandem with other ground-,
air- or space-based sensors with comparable spectral and geometric
characteristics. These data are analyzed to provide an independent
verification of the validity of the LDCM datasets. The Government
intends to independently perform this process for the data it procures.

### Technical Support

The Technical Support process responds to technical questions regarding
the characteristics of the LDCM Data Products. Investigation of product
anomalies and resolution of problems are part of this process.

## SYSTEM QUALITY MANAGEMENT

![](media/image10.wmf){width="4.342361111111111in"
height="4.342361111111111in"}

> **Figure 9** -- Data Flow Diagram highlighting the System Quality
> Management process.

System Quality Management functions are distributed across the six
primary processes. These functions are explicitly defined in processes
1.4, 5.2, 6.3 and 6.4. For processes 2, 3 and 4, generic system metrics
are collected. Data from all these validation functions are analyzed in
the central System Quality Management process. In addition, various
performance and operational statistics are collected from all LDCM
processes. All of this information is made available and can be
retrieved by the Government through a System Quality Management Query.

# EXAMPLE OPERATIONS SCENARIOS

Section 3 covers a series of operational scenarios based on the system
described in section 2. The reader should keep in mind that the system
presented in section 2 is just one possible process breakdown. These
scenarios are intended to provide an outline of how the system described
in section 2 would operate to enhance reader comprehension of the
expected system interactions.

The Landsat 7 operations were used as a model for these scenarios. This
is not meant to imply that LDCM operations must be conducted in this
manner. The five scenarios included with this document are:

> 3.1 Acquiring Global LDCM Data
>
> 3.2 Order & Distribute an Archived LDCM Data Product
>
> 3.3 Special DAR -- L.A. Earthquake
>
> 3.4 New Data Request From International Cooperator
>
> 3.5 Update Sensor & Calibration Parameters

These are intended to highlight the major operational aspects of the
envisioned LDCM system presented in section 2. Each scenario includes a
brief objective statement, a list of assumptions, a data flow diagram
and a corresponding list of operational steps. Steps are indicated on
the diagram in red.

## ACQUIRING GLOBAL LDCM DATA

### Objective

The purpose of this scenario is to highlight the automated global
acquisition planning process. The objective is to acquire a global
dataset of the Earth's land surfaces on a seasonal basis that meets the
requirements established in 427-SPEC-00001, LDCM Data Specification.

### Assumptions

The LDCM system is fully operational. The system successfully imaged
every pre-identified land scene at least once during the previous year
of operations.

### Scenario Description -- Acquiring Global LDCM Data

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

> **Figure 10** -- Data Flow Diagram of the operations concept for the
> automated acquisition of a global LDCM dataset. The red numbers
> indicate the sequence of events.

  ---------- --------------------------------------------------------------
  **Step**   **Processes**

  **1**      Data is not acquired continually. Instead, acquisitions are
             scheduled in advance using a Long Term Acquisition Plan (LTAP)
             in conjunction with a software scheduler. The WRS-2 system
             divides the Earth into a grid of 57,784 scenes, with each
             scene centered on the intersection of a path (groundtrack
             parallel) and row (latitude parallel). The observatory is
             operated such that it follows the WRS-2 grid within tight
             tolerances, overflying the entire global WRS scene grid every
             16 days. A database of just over 14,000 scenes containing
             "land" was compiled for the LTAP
             (http://ltpwww.gsfc.nasa.gov/IAS/htmls/igs.html), including
             continental areas, shallow coastal waters, Antarctic sea-ice,
             and all known islands and reefs. Within any given 24-hour
             period, approximately 850 of these WRS land scenes (descending
             paths only) are in view of the ETM+ and are candidates for
             acquisition. The mission scheduler must select the "best" 250
             scenes for acquisition each day within these constraints.

  **2**      The LTAP priorities are transferred from the Manage LTAP
             process to the Manage Scheduler process.

  **3**      The Manage Scheduler process pulls the most recent cloud
             predict information. The scheduler automatically schedules
             acquisitions in accordance with the LTAP priorities, basing
             these decisions on cloud-cover forecasts, urgency of
             acquisition, and availability of resources to optimize
             fulfillment of mission goals. The output schedule merges the
             LTAP priorities with special requests from the Government and
             any commercial requests on the system. This may involve
             conflict resolution procedures, some of which are laid out in
             the LDCM Data Policy, Attachment D to the LDCM Request for
             Proposal. Scene acquisition priorities are also balanced
             against SSR capacity, ground station locations, and duty cycle
             limitations in order to obtain the final acquisition list
             uploaded to the spacecraft.

  **4**      The conflict-free acquisition list is passed on to the Control
             Observatory process. In the current Landsat 7 implementation,
             this is equivalent to the Mission Operations Center. Functions
             such as orbital maintenance, building of command loads are
             executed here. The conclusion is an Acquisition Tasking sent
             to the Operate Sensor process.

  **5**      The LDCM sensor is actually operated per the commands in the
             Acquisition Tasking. The radiance values are captured and
             encoded in a telemetry system for transmission back to the
             Earth. The output is a telemetry stream encoded for
             transmission.

  **6**      The Telemetry stream is transmitted through the Downlink
             Datasets process. In the traditional space-based architecture
             this process maps to one or more receiving ground stations.
             The output is the telemetry stream in digital form.

  **7**      The digital Telemetry stream is passed to the Generate Archive
             Datasets process. This is where communications formatting and
             artifacts are removed. The output is the Unprocessed Digital
             Image Data as defined in 427-SPEC-00001, LDCM Data
             Specification, together with Browse Data, Ancillary Data and
             Metadata.

  **8**      The Unprocessed Digital Image Data and preliminary ancillary
             data are passed to the Ingest and Assess Data process. This is
             the first step in the Archive Data process. The cloud cover
             estimates are made at this step.

  **9**      All of the archive datasets are passed on to the Maintain
             Active Archive process. This is the process of maintaining the
             datasets in a logical archive. The Active Archive is the one
             from which all LDCM data products will be distributed.

  **10**     All of the archive datasets are also delivered to the Long
             Term Archive, which is operated by the Government at the EROS
             Data Center.

  **11**     The final information on the ingest of data is built and
             passed back to the Manage Scheduler process. This includes
             information on exactly what data was actually acquired, what
             modes the instrument was operating in, cloud cover estimates
             and so on. The Manage Scheduler process updates the status of
             the acquisitions in the Acquisition List, and passes this
             status back to the Manage LTAP process.

  **12**     The Manage LTAP process updates the history tables for the
             land scenes in its database to reflect the latest acquisition
             history information.
  ---------- --------------------------------------------------------------

## ORDER AND DISTRIBUTE AN ARCHIVED LDCM DATA PRODUCT

### Objective

The objective of this scenario is to illustrate how a typical LDCM User
searches, then orders an LDCM Data Product, through processing and
delivery of the order.

### Assumptions

The LDCM User is interested only in an LDCM scene that is already stored
in the Active Archive.

### Scenario Description -- Order And Distribute An Archived LDCM Product

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

> **Figure 11** -- Data Flow Diagram of the operations concept for the
> ordering, production and distribution of an LDCM Data Product. The red
> numbers indicate the sequence of events.

  ---------- --------------------------------------------------------------
  **Step**   **Processes**

  **1**      The User initiates a data search based on their criteria.

  **2**      The search interface translates this into an internal system
             query. This is passed off to a database server.

  **3**      The server performs a search of the active archive to see what
             data match the criteria.

  **4**      The Active Archive returns the Browse Data and relevant
             Metadata for all data meeting the search criteria.

  **5**      This information is passed back to the search engine, which
             reformats the information for display to the users.

  **6**      The user sees the results of their search and selects one or
             more products for ordering.

  **7**      By selecting the place order function, the information is
             passed along to the Order Products function. A new order is
             established in the system.

  **8**      The information on the order is passed back to the User,
             namely an order ID and any other relevant information.

  **9**      The Order Products process requests an accounting
             authorization.

  **10**     An invoice is generated and sent to the user for payment.

  **11**     The user sends a payment in based on the invoice. This might
             be in the form of a purchase order or perhaps a credit card
             number entered through an online order interface.

  **12**     The Billing and Accounting system passes back confirmation
             that the order is ready to pass off to production. The Order
             Products process updates the order status, and generates a
             Data Product Order.

  **13**     The Data Product Order is sent to the Generate Products
             process. This is where all the processing is done to generate
             the LDCM data products requested in the data product order.

  **14**     The Generate Products process sends a request for data from
             the archive to the Provide Data On Request process.

  **15**     The archive data request is translated into an internal data
             request and sent to the Manage Active Archive function.

  **16**     The Maintain Active Archive function returns the archive
             datasets requested for processing, the Unprocessed Digital
             Image Data, Ancillary Data and Metadata.

  **17**     The requested datasets are passed back to the product
             generation process by the Provide Data On Request process.

  **18**     The Generate Products process performs the processing
             necessary to generate the LDCM Data Products requested in the
             data product order. The data products are passed on to the
             product validation process.

  **19**     After the product validation (quality assurance / quality
             control) process is completed, the data products are passed on
             to the product distribution process.

  **20**     The LDCM Data Products are distributed to the users on the
             requested medium. This includes the process of writing
             products to media, verifying the media, packaging, shipping or
             staging of data for electronic distribution as requested.
  ---------- --------------------------------------------------------------

##  SPECIAL DAR -- LOS ANGELES EARTHQUAKE

### Objective

The objective of this scenario is to illustrate how the concept of a
Data Acquisition Request (DAR) is applied. This is an example of a
specific request to acquire an image of Los Angeles (path 42, row 36) at
the first acquisition opportunity.

### Assumptions

All LDCM systems are functioning nominally. The Government identifies
the need for an acquisition over Los Angeles following an earthquake.
The Government decides to submit a DAR for a scene to meet this request.

### Scenario Description -- Special DAR -- Los Angeles Earthquake

![](media/image13.wmf){width="5.985416666666667in" height="7.45625in"}

> **Figure 12** -- Data Flow Diagram of the operations concept for a
> one-time Government Data Acquisition Request (DAR). The red numbers
> indicate the sequence of events.

  ---------- --------------------------------------------------------------
  **Step**   **Processes**

  **1**      A representative of the Government submits a Data Acquisition
             Request. This can be in the form of an email, a telephone
             call, or an input to an online request interface. The special
             requests manager may need to clarify some details with the
             requesting party, eventually developing a Special Acquisition
             List. This is a list of one-time acquisitions to be made to
             fulfill the request.

  **2**      The list of special acquisition requests is passed along to
             the scheduler. The requests have associated priorities and
             optionally some cloud cover constraints.

  **3**      The latest 3-hour cloud prediction information is pulled from
             NOAA to the scheduler process.

  **4**      The Scheduler builds the Acquisition List, which merges
             special requests with the LTAP priorities and commercial
             requests, incorporating relative priority information and the
             latest cloud predictions. Since this is a natural disaster
             response request, this acquisition is at a high priority level
             and will occur for any probability of cloud cover. This
             acquisition list is passed on to the Control Observatory
             process

  **5**      The control observatory process translates the list of
             acquisition requests into acquisition tasking, a set of
             commands for the sensor and observatory. These are transmitted
             up to the observatory.

  **6**      The sensor is operated as commanded and the data are acquired
             successfully. The data are encoded in a telemetry stream that
             is transmitted from the observatory to the ground.

  **7**      The Downlink Data process receives the telemetry and passes it
             on for preparation for the archive.

  **8**      The Generate Archive Datasets process translates the telemetry
             into Unprocessed Digital Image Data, and develops the
             preliminary ancillary data. These are passed on to the archive
             ingest process.

  **9**      The archive ingest process builds the Browse images, Ancillary
             Data, Metadata and Uncorrected Digital Image Data. These are
             passed on to the Active Archive for storage for the life of
             the mission.

  **10**     Copies of all the data ingested are also passed on to the Long
             Term archive maintained by the Government.

  **11**     The successful archive ingest status is passed back to the
             scheduler. This includes information on exactly what data were
             ingested, spatial coverage, date/time information and
             estimated cloud cover. The scheduler updates it's acquisition
             list.

  **12**     The updated acquisition status is passed on to the special
             requests manager.

  **13**     The original requester in the Government is informed of the
             success of the acquisitions. Refer to the scenario described
             in section 3.2 for the data product order & delivery scenario.
  ---------- --------------------------------------------------------------

## UPDATE SENSOR AND CALIBRATION PARAMETERS

### Objective

The objective of this scenario is to outline some of the basic
calibration functions. Specifically, the ways in which this process can
effect changes in both the LDCM sensor and the ground processing
systems.

### Assumptions

The system has been previously calibrated. During routine monitoring, it
is determined that a change in the sensor performance has occurred, and
a change in the Sensor Parameters and the Calibration Parameters will be
required to bring the LDCM Data Products back up to specifications. For
the sake of discussion, the change is assumed to be a detector gain
change.

### Scenario Description -- Update Sensor And Calibration Parameters

![](media/image14.wmf){width="5.459722222222222in"
height="4.855555555555555in"}

> **Figure 14** -- Data Flow Diagram of the operations concept for the
> Update Sensor & Calibration Parameters scenario. The red numbers
> indicate the sequence of events.

  ---------- --------------------------------------------------------------
  **Step**   **Processes**

  **1**      While monitoring the sensor characterization as part of the
             characterize sensor performance process, it is determined that
             the performance of a detector has changed, and a new sensor
             configuration and calibration parameter file will be required.
             A Calibration Acquisition request is built which asks that a
             scene be acquired using a special sensor configuration
             specified in the request (i.e. with the new detector gain
             value). This request is sent to the Manage Special Requests
             process.

  **2**      The Manage Special Requests process deals with this request
             just like any other special request. Refer to steps 2 through
             12 in section 3.3.3 to see how this request flows through the
             system.

  **3**      The special acquisition is successfully acquired, and a
             calibration acquisition request status message is passed back
             to the sensor characterization process.

  **4**      A request is sent to the archive to retrieve the data from the
             special calibration acquisition.

  **5**      The unprocessed digital image data, metadata and ancillary
             data are all transferred from the active archive back to the
             Characterize Sensor Performance process. These data are
             analyzed to confirm that the gain change worked, and the
             response from the affected detectors is appropriately scaled.

  **6**      A permanent change in the sensor parameters is prepared which
             reflects the new detector gain value. This is provided to the
             observatory control process.

  **7**      The observatory control process transmits the new sensor
             parameters up to the LDCM sensor.

  **8**      The observatory/sensor report back to the observatory control
             process that the new sensor parameters have been loaded
             correctly.

  **9**      The observatory control process reports back to the sensor
             characterization process the new sensor and vehicle status,
             which reflects the change in sensor parameters.

  **10**     The new sensor characterization is developed and forwarded to
             the process that generates calibration parameters that are
             used in the processing of LDCM data products.

  **11**     The new calibration parameters are computed which account for
             the detector gain change. The calibration parameters are
             tagged with a date range corresponding to when the change in
             sensor parameters was actually implemented. The calibration
             parameters are passed on to the active archive for storage,
             and to the product generation process for incorporation into
             the production process.
  ---------- --------------------------------------------------------------

# DOCUMENT DATA DICTIONARY

  ----------------------------- -----------------------------------------
  **Element**                   **Definition**

  Accounting Authorization      A request for the Billing and Accounting
  Request                       process to perform necessary procedures
                                to verify and/or bill users for an
                                invoice.

  Accounting Authorization      The response to an AAR regarding the
  Request Response              success or failure of an attempt to
                                verify a payment method or obtain
                                payment.

  Acquisition Engineering Data  Engineering data regarding link status,
                                bit error rates, dropped frames, and
                                other quality information.

  Acquisition List              The list of all future acquisitions that
                                are intended to be captured.

  Acquisition Status            The status of items on the acquisition
                                list (Accepted, Rejected and so on).

  Acquisition Status            The acquisition status for items in the
                                Acquisition List, indicating the success
                                or failure of each acquisition, plus
                                ancillary data regarding the acquisitions
                                (where data was downlinked, actual modes,
                                quality information etc.)

  Acquisition Tasking           A list of individual acquisition commands
                                sent to the vehicle for execution.

  Ancillary Data                Ancillary data as defined in section
                                1.1.2 of 427-SPEC-00001, LDCM Data
                                Specification.

  Annual Cloud Statistics       The cloud climatology for all the land
                                WRS-2 scenes. Refer to the description of
                                the LDCM LTAP in section 2.1.1 and
                                Section 4.

  Archive Contents Query        A query to determine the holdings within
                                the LDCM Archive. The query can be for a
                                specific granule, or for granules that
                                meet one or more criteria.

  Archive Contents Query        A list of granules that meet the criteria
  Results                       given in an Archive Contents Query

  Archive Data Request          A request for one or more granules of
                                Level 0 LDCM Archive Data.

  Archive Ingest Status         A status message from either the Active
                                Archive or an International Cooperator
                                indicating the success or failure of the
                                ingest of data into an archive, including
                                details on what data were ingested.

  Archive Metadata              A complete catalog of all LDCM Data
                                Products contained in the archive.

  Calibration Acquisition       A Data Acquisition Request from the
  Request                       calibration process area. This is like a
                                normal DAR but includes special
                                engineering parameters which the
                                calibration processes can specify for
                                changing sensor configuration.

  Calibration Acquisition       The acquisition status for an associated
  Request Status                Calibration Acquisition Request

  Calibration Parameters        A complete set of parameters that can be
                                applied to Level 0 LDCM data during
                                processing to generate calibrated Level 1
                                products.

  Commercial Acquisition        If the LDCM system is also being used to
  Request                       acquire commercial data products, it is
                                assumed that commercial sales would
                                result in acquisition requests
                                specifically for these data.

  DAR Status Request            Request message asking for status of a
                                particular Data Acquisition Request
                                submitted by the Government.

  Data Acquisition Request      A special acquisition request from the
  (DAR)                         Government. For one-time or non-recurring
                                data acquisition requests, or for
                                night-imaging or other special conditions
                                not handled by the LDCM LTAP.

  Data Acquisition Request      Data Acquisition Request Status response
  (DAR) Status                  to the Request DAR Status message.
                                Information on the success or failure of
                                the Government's special data acquisition
                                requests.

  Data Capture Status           Information from the Transfer Sensor Data
                                process on success or failure of the
                                capture & transfer of Raw Sensor
                                Telemetry from the vehicle(s).

  Data Product Order            The actual order for one or more LDCM
                                data products.

  Data Product Order Status     Status of associated Data Product Orders.

  Data Query                    A search request from a user including
                                search parameters for data products in
                                the LDCM archive.

  Data Query Results            The results of the search based on the
                                Data Query from a user.

  International Cooperator      An acquisition request for data to be
  Request                       supplied to an International Cooperator,
                                which can be either for recurring
                                acquisitions or one-time acquisitions.

  Invoice                       A bill for one or more LDCM Data
                                Products, including information on who
                                will be charged.

  LDCM Data Product             A L0, L1 or L2 LDCM Data Product for
                                delivery to a user (not the format of
                                data in the archive)

  LTAP Change                   A change in the algorithms or underlying
                                tables that comprise the LDCM LTAP.

  LTAP Priority List            A list of priorities attached to a list
                                of WRS-2 path & row frames, including
                                cloud cover constraints.

  Order Status                  In response to an Order Status Query,
                                contains the status of the orders
                                referenced.

  Order Status Query            A query sent by a user looking for the
                                status of one or more orders identified
                                in the query.

  Payment                       US currency.

  Planned Acquisitions          The list of acquisitions actually
                                scheduled for future acquisition.

  Planned Acquisitions Query    A query to search for acquisitions in the
                                Acquisition List.

  Planned Acquisitions Results  Response to the Planned Acquisitions
                                Query, indicating which acquisitions are
                                in the tasking list that met the
                                conditions in the query.

  Preliminary Ancillary Data    The Ancillary Data record filled in with
                                what information is known prior to
                                generation of the archive data.

  Product Generation Package    All information and data required to
                                allow production of an LDCM Data Product
                                specified in an associated Data Product
                                Order.

  Product Order Request         An order for one or more LDCM Data
                                Products from a user.

  Receipt                       Receipt for payment of Money to settle an
                                Invoice.

  Sensor & Vehicle Status       The current status of the sensor and the
                                vehicle(s), as well as a list of future
                                planned outages or changes in status.

  Sensor Parameters             A set of configurable parameters that
                                adjust the operation of the LDCM sensors.

  Tasking Status                The sensor or vehicle status for each of
                                the tasking commands issued.

  Telemetry                     The data stream transmitted by the LDCM
                                vehicle(s).

  Three Hour Cloud Predicts     The most recent cloud cover predictions
                                for the land areas of the world.

  Unprocessed Digital Image     The LDCM Archive Data procured under the
  Data                          data buy, refer to 427-SPEC-00001, LDCM
                                Data Specification.

  Validation Results            A generic name for the results of a
                                validation process.
  ----------------------------- -----------------------------------------