National Oceanic and Atmospheric Administration (NOAA)

Concept of Operations (CONOPS)

For

NPOESS Data Exploitation (NDE)

Version 2.0

![](media/image1.png){width="2.4854166666666666in"
height="2.4131944444444446in"}

Prepared by:

U.S. Department of Commerce

National Oceanic and Atmospheric Administration (NOAA)

National Environmental Satellite, Data, and Information Service (NESDIS)

NOAA/NESDIS

##### Approval Page {#approval-page .unnumbered}

+------------------------------------+---------------------------------+
| Document Numbers: DCN OSDNDECO 2.0 | **MMDDYY**                      |
+------------------------------------+---------------------------------+
| Document Title Block:              |                                 |
|                                    |                                 |
| National Oceanic and Atmospheric   |                                 |
| Administration (NOAA) **CONCEPT OF |                                 |
| OPERATIONS** for National          |                                 |
| Polar-orbiting Operational         |                                 |
| Environmental Satellite System     |                                 |
| (NPOESS) Data Exploitation (NDE)   |                                 |
+------------------------------------+---------------------------------+
| **PROGRAM:** NPOESS Data           | **DOCUMENT RELEASE DATE:**      |
| Exploitation (NDE)                 | August 12, 2005                 |
+------------------------------------+---------------------------------+
| **APPROVALS**                      |                                 |
+------------------------------------+---------------------------------+
| GROUP: Office of System            | GROUP: Office of System         |
| Development (OSD) DATE             | Development (OSD) DATE          |
|                                    |                                 |
| NAME: Mike Mignogno, POES Program  | NAME: H. James Silva, NDE       |
| Manager                            | Project Manager                 |
+------------------------------------+---------------------------------+
| GROUP: Office of System            |                                 |
| Development (OSD) DATE             |                                 |
|                                    |                                 |
| NAME: Richard G. Reynolds          |                                 |
+------------------------------------+---------------------------------+
| GROUP: Office of Satellite Data    | GROUP: Office of Satellite Data |
| Processing and Distribution        | Processing and Distribution     |
| (OSDPD)                            | (OSDPD)                         |
|                                    |                                 |
| DATE                               | DATE                            |
|                                    |                                 |
| NAME: Reginald Lawrence            | NAME: David A. Benner           |
+------------------------------------+---------------------------------+
| GROUP: Office of Research and      | GROUP: Office of Research and   |
| Applications (ORA) DATE            | Applications (ORA) DATE         |
|                                    |                                 |
| NAME: Eric J. Bayler, PhD.         | NAME: Mitchell D. Goldberg      |
+------------------------------------+---------------------------------+
| GROUP: National Weather Service    | GROUP: National Ocean Service   |
| (NWS) DATE                         | (NOS) DATE                      |
|                                    |                                 |
| NAME: Kevin J Schrab, Ph.D.        | NAME:                           |
+------------------------------------+---------------------------------+
| GROUP: Integrated Program Office   | GROUP: Office of NESDIS Chief   |
| (IPO) DATE                         | Information Officer             |
|                                    | (NESDIS/CIO) DATE               |
| NAME: Joseph Mulligan              |                                 |
|                                    | NAME:                           |
+------------------------------------+---------------------------------+
| **CCB RELEASE APPROVAL: DATE**     |                                 |
|                                    |                                 |
| NAME:                              |                                 |
+------------------------------------+---------------------------------+

##### Change Record Page {#change-record-page .unnumbered}

+-----+-------+-------+----------------------------------------------+
| Do  |       |       |                                              |
| cum |       |       |                                              |
| ent |       |       |                                              |
| Tit |       |       |                                              |
| le: |       |       |                                              |
| N   |       |       |                                              |
| OAA |       |       |                                              |
| CON |       |       |                                              |
| OPS |       |       |                                              |
| for |       |       |                                              |
| NPO |       |       |                                              |
| ESS |       |       |                                              |
| D   |       |       |                                              |
| ata |       |       |                                              |
| Exp |       |       |                                              |
| loi |       |       |                                              |
| tat |       |       |                                              |
| ion |       |       |                                              |
|     |       |       |                                              |
| Do  |       |       |                                              |
| cum |       |       |                                              |
| ent |       |       |                                              |
| Da  |       |       |                                              |
| te: |       |       |                                              |
| J   |       |       |                                              |
| une |       |       |                                              |
| 1,  |       |       |                                              |
| 2   |       |       |                                              |
| 004 |       |       |                                              |
+-----+-------+-------+----------------------------------------------+
| Is  | Date  | Pages | Description                                  |
| sue |       | Aff   |                                              |
|     |       | ected |                                              |
+-----+-------+-------+----------------------------------------------+
| 1.2 | 5/    | all   | Provided more specific reference to NDE,     |
|     | 10/04 |       | fewer to NPOESS.                             |
+-----+-------+-------+----------------------------------------------+
| 1.3 | 5/    | all   | Eliminated 10 pages of text                  |
|     | 12/04 |       |                                              |
|     |       |       | -   Deleted Section 1.3 System Overview      |
|     |       |       |                                              |
|     |       |       | -   Deleted Section1.4 NESDIS Information    |
|     |       |       |     Service Enterprise                       |
|     |       |       |                                              |
|     |       |       | -   Changed Section 2. User Oriented         |
|     |       |       |     Description To 2. Background. Deleted    |
|     |       |       |     much text                                |
|     |       |       |                                              |
|     |       |       | Renamed 4 Data Processing Operational        |
|     |       |       | Overview To 3 NOAA Organizational Overview   |
|     |       |       |                                              |
|     |       |       | -   Renamed graphic 4.1 to 3.1 and drew      |
|     |       |       |     dotted box around NDE functions          |
|     |       |       |                                              |
|     |       |       | -   Deleted (from this section) definition   |
|     |       |       |     of SDS                                   |
|     |       |       |                                              |
|     |       |       | -   Deleted Section 4.1.1 ESPC               |
|     |       |       |                                              |
|     |       |       | -   Deleted Section 4.1.2 Field Terminal     |
|     |       |       |                                              |
|     |       |       | -   Deleted Section 4.1.3 Long Tem Archive   |
|     |       |       |     (LTA)                                    |
+-----+-------+-------+----------------------------------------------+
| 1.4 | 5/    |       | -   Created new Operational Overview Diagram |
|     | 13/04 |       |     (top of Section 3)                       |
|     |       |       |                                              |
|     |       |       | -   Edited as per Tom Schott's suggestions   |
+-----+-------+-------+----------------------------------------------+
| 1.4 | 5/    |       | -   Inserted S Bunin edits                   |
|     | 14/04 |       |                                              |
|     |       |       | -   Inserted J Silva edits                   |
+-----+-------+-------+----------------------------------------------+
| 1.6 | 6     |       | Added sections 3.2.2 through 3.2.2.4         |
|     | /7/04 |       |                                              |
+-----+-------+-------+----------------------------------------------+
| 1.8 | 9     |       |                                              |
|     | /8/04 |       |                                              |
+-----+-------+-------+----------------------------------------------+
| 2   | 8/    |       | Complete rewrite, using Standard IEEE format |
|     | 03/05 |       | and excerpts from the Project Plan           |
+-----+-------+-------+----------------------------------------------+
|     |       |       |                                              |
+-----+-------+-------+----------------------------------------------+
|     |       |       |                                              |
+-----+-------+-------+----------------------------------------------+
|     |       |       |                                              |
+-----+-------+-------+----------------------------------------------+
|     |       |       |                                              |
+-----+-------+-------+----------------------------------------------+

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

Table of Contents

[1 Scope 6](#scope)

[1.1 Document Purpose 6](#document-purpose)

[1.2 Background 6](#background)

[1.3 Project Goals and Objectives 6](#project-goals-and-objectives)

[2 Reference Documents 8](#reference-documents)

[3 Current Systems 11](#__RefHeading___Toc110832886)

[4 Justification for Proposed Changes
12](#justification-for-proposed-changes)

[4.1 Consolidation and Cost Savings 12](#consolidation-and-cost-savings)

[4.2 Technology Improvements 12](#technology-improvements)

[4.3 Implications for the User Community
14](#implications-for-the-user-community)

[5 Concepts for the Proposed System
15](#concepts-for-the-proposed-system)

[5.1 NOAA Satellite Operations Facility (NSOF)
15](#noaa-satellite-operations-facility-nsof)

[5.2 NPOESS Interface Data Processing Segment (IDPS)
16](#npoess-interface-data-processing-segment-idps)

[5.3 NDE Product Generation and Dissemination
17](#nde-product-generation-and-dissemination)

[5.3.1 NDE Product Data Flows 18](#nde-product-data-flows)

[5.3.2 Enterprise Tools 18](#enterprise-tools)

[5.3.3 Algorithm Development 19](#algorithm-development)

[5.3.3.1 Algorithm Development on the IDPS Algorithm Development Area
20](#algorithm-development-on-the-idps-algorithm-development-area)

[5.4 NOAA Environmental Satellite-data Processing Center (ESPC)
21](#noaa-environmental-satellite-processing-center-espc)

[5.4.1 Security 22](#security)

[5.4.2 Data Base Administration 22](#data-base-administration)

[5.4.3 Disaster Recovery 23](#disaster-recovery)

[5.4.4 Customer Services 23](#customer-services)

[5.4.5 Configuration Management 23](#configuration-management)

[5.5 Long Tem Archive (LTA) 24](#long-term-archive-lta)

[5.6 NPOESS Mission Management Center (MMC)
24](#npoess-mission-management-center-mmc)

[5.6.1 Official Ancillary Data 25](#official-ancillary-data)

[5.6.2 xDR Subscription Requests 25](#xdr-subscription-requests)

[5.6.3 The xDR Data Flow 26](#the-xdr-data-flow)

[5.6.3.1 Format 26](#format)

[5.6.3.2 Quality Control of xDRs 26](#quality-control-of-xdrs)

[5.7 Interoperability 27](#interoperability)

[6 Operational Scenarios 29](#__RefHeading___Toc110832942)

[6.1 Quality Assurance 29](#quality-assurance)

[6.1.1 Ingest Quality Control 29](#ingest-quality-control)

[6.1.1.1 Ingest Log 29](#ingest-log)

[Product Control Data Base 30](#product-control-data-base)

[6.1.1.2 30](#product-control-data-base)

[6.2 Requests for NPOESS Data 31](#requests-for-npoess-data)

[6.3 Customer Order Management 33](#customer-order-management)

[6.4 NPOESS Data Denial 34](#npoess-data-denial)

[6.5 Science Support 35](#science-support)

[6.6 Algorithm Support Capability 35](#algorithm-support-capability)

[6.7 Impact of Satellite Maneuvers 36](#impact-of-satellite-maneuvers)

[6.8 SARSAT/ADCS 36](#sarsata-dcs)

[6.9 IDPS Element Problem Resolution 37](#__RefHeading___Toc110832955)

[6.10 NDE Problem Resolution 37](#nde-problem-resolution)

[6.11 Homeland Security 38](#homeland-security)

[6.12 Contingency Operations 38](#contingency-operations)

[7 SUMMARY of IMPACTS 39](#summary-of-impacts-tbd)

[8 Analysis of Proposed System 40](#analysis-of-proposed-system)

[9 NOTES 41](#notes)

[10 Appendices 42](#appendices)

[11 GLOSSARY 43](#glossary)

**Table of Figures**

[Figure 1: NPOESS SafetyNet 14](#__RefHeading___Toc110755600)

[Figure 2: NOAA Central 15](#__RefHeading___Toc110755601)

# Scope

## Document Purpose 

This ConOps is a user-oriented document that describes system
characteristics for the proposed NPOESS Data Exploitation (NDE) system
from the users' viewpoint. The document is used to communicate overall
quantitative and qualitative system characteristics to the user,
developers, and other NOAA stakeholder in Line Offices and in support
organizations. It describes the NDE mission and organizational
objectives from an integrated systems point of view.

The contents are organized according to "IEEE Standard 1362-1998 IEEE
Guide for Information Technology -- System Definition- Concept of
Operations (CONOPS)."

## Background

The National Oceanic and Atmospheric Administration (NOAA)
Polar-orbiting Operational Environmental Satellite (POES) and the
Department of Defense (DoD) Defense Meteorological Satellite Program
(DMSP) will be replaced by the National Polar-orbiting Operational
Environmental Satellite System (NPOESS) in the next decade. NPOESS will
provide environmental remote sensing capability for both civilian and
military applications.

NPOESS will provide data to four central processing facilities, called
"Centrals," via its Interface Data Processing Segment (IDPS) and to
remote field terminals via direct radio links. The Centrals will be
responsible for providing NPOESS data to environmental satellite users.

NOAA's National Environmental Satellite, Data and Information Service
(NESDIS) will operate the NOAA Central. Air Force Weather Agency (AFWA),
Fleet Numerical Meteorology and Oceanography Center (FNMOC), and Naval
Oceanographic Office (NAVOCEANO) will operate the other three Centrals.

NOAA's NPOESS Data Exploitation (NDE) system will receive data from the
NPOESS IDPS, process and package it to meet user requirements, ensure
NDE unique products are archived, distribute data to authorized users,
and provide customer service to users of its products.

## Project Goals and Objectives

NDE's primary mission is to provide products derived from NPOESS
observations to NOAA's operational and climate communities and to other
civilian customers. In order to fulfill the mission, NDE will acquire
the resources necessary to achieve the following objectives:

-   Disseminate NPOESS Data Records to customers

-   Generate and disseminate tailored NPOESS Data Records (versions of
    NPOESS Data Records in previously agreed alternative formats and
    views)

-   Generate and disseminate NOAA-unique products (augmented
    environmental products constructed from NPOESS Data Records)

-   Deliver NOAA-unique products and associated metadata to the NOAA
    Long-Term Archive

-   Provide services to customers, including a Help Desk, NDE product
    training, product enhancement, and implementation support across
    NOAA

-   Coordinate NPOESS-related activities across NOAA

    -   Assist with planning for the implementation of NPOESS data by
        user systems

    -   Ensure end-user preparedness for NPOESS data

-   Perform the NOAA Lead Central role for the development and
    verification of processing capability

-   Develop a sustainable system that meets its customer needs

-   Provide software for NPOESS Data Record format conversion and other
    data manipulations

Two National Weather Service (NWS) field terminals will be installed for
NPOESS: one in Alaska and one in Hawaii. These terminals incorporate
much of the IDPS software and have the capability, therefore, of
providing remote sites with NPOESS data through a direct pathway to the
satellites rather than through NDE, the NOAA Central. These terminals
incorporate NPOESS software, will receive and process real-time data
broadcast directly from NPOESS satellites while the satellites are
within the field terminals lines of sight. The nature of NDE's support
for these two field terminals is to be determined (TBD).

# Reference Documents 

-   NOAA's NPOESS Data Exploitation Charter
    <http://projects.osd.noaa.gov/nde>

-   [NPOESS IPO, Integrated Operational Requirements Document II (IORD
    II), version 6, 2002]{.mark}.

-   [NPOESS to National Oceanic and Atmospheric Administration (NOAA)
    Interface Control Document (ICD), NPOESS Draft, 03/03/2005, NO.
    D31413, Rev C.]{.mark}

-   Information Processing Division National Polar-Orbiting Operational
    Environmental Satellite System (NPOESS) Concept Of Operations,
    Baseline Issue, June 20, 2002, Version 1
    [http://216.33.118.202/EPSData/DOC/Synopses/3055/NOAA-ESPC-04-04-2003/AppendixE.pdf](http://216.33.118.202/EPSData/DOC/Synopses/3055/NOAA-CEMSCS-04-04-2003/AppendixE.pdf)

-   National Oceanic and Atmospheric Administration**\
    **Information Quality Guidelines, September 30, 2002,
    <http://www.noaanews.noaa.gov/stories/iq.htm>

-   Concept of Operations (CONOPS) for the National polar-orbiting
    Operational Environmental Satellite System (NPOESS) Program,

-   Version 1.2, September 15, 2003

-   NPOESS DATA EXPLOITATION (NDE) SYSTEM REQUIREMENTS, 13 August 2004

-   [NPOESS Integrated Operational Requirements Document (IORD)-II, 10
    December 2001]{.mark}

-   NPOESS Concept of Operations, Draft, February 21, 2003

-   Comprehensive Large Array-data Stewardship System (CLASS) Archive,
    Access and Distribution System Allocated Requirements, Version 1

-   NESDIS, A Strategic Approach for the New Millennium, 2001

-   Concept of Operations for the National Environmental Satellite,
    Data, and Information Service: 2010-2020, 2002

-   Interface Requirements Document (IRD) for National Polar-orbiting
    Operational Environmental Satellite System (NPOESS) Preparatory
    Project (NPP) Science Data Segment (SDS) and Interface Data
    Processing Segment (IDPS) Interface, GSFC 429-00-02-13, July 23,
    2001

-   NPOESS Operations Concept (OPSCON), TRW D31400, 1 August 2002

-   [NPOESS to NESDIS ICD, Northrop Grumman Space & Mission Systems
    Corp. Space Technology, 23 May 2003]{.mark}

-   Concept of Operations for the Archive, Access and Distribution
    System As part of Comprehensive Large Array-data Steward-ship System
    (CLASS) Version 1, CLASS-1004-CLS-REQ-CONOP, October 25, 2002

Comprehensive Large Array-data Stewardship System (CLASS) Dual Site
Architecture and Operational Concept (1.0), CLASS-1038-CLS-RPT-DLSTE,
June 27, 2003[]{#__RefHeading___Toc110832886 .anchor}Current Systems

# Current System

NPOESS is the follow-on to both NOAA's National Polar orbiting
Operational Environmental Satellite (POES) system and its military
counterpart, the Defense Meteorological Satellite Program (DMSP). The
primary mission of the Polar-orbiting-Operational Environmental
Satellite (POES) system is to provide daily global observations of
weather patterns and environmental measurements of the Earth's
atmosphere, its surface and cloud cover, and the proton and electron
flux at satellite altitude; and to establish long-term data sets for
climate monitoring and change predictions. Since the beginning of the
POES program, environmental data and products acquired by its satellites
have been provided to users around the globe.

[The Current Polar Ground System]{.underline}\
\
Today, the NOAA Polar Ground System (PGS) receives telemetry and science
data from a large array of Low Earth Orbiting (LEO) satellites. In
addition, the PGS controls the LEO set of satellites using various
commanding schemes. The vast array of LEO satellites consists of NOAA's
legacy Polar-orbiting Operational Environmental Satellites (POES) and
DoD\'s Defense Meteorological Satellite Program (DMSP). Also, the PGS is
collecting data from various non-NOAA satellites such as Advanced Earth
Observing Satellite (ADEOS), Earth Observing System (EOS), Jason, Quick
Scatterometer (QuikSCAT), Sea-viewing Wide Field-of-view Sensor
(SeaWiFS), Tropical Rainfall Measuring Mission (TRMM), WindSat/Coriolis,
and etcetera.\
\
Instruments that are carried aboard the satellites mentioned above
perform measurements of temperature and humidity in the Earth\'s
atmosphere, surface temperature, cloud cover, water-ice boundaries,
greenhouse gases, and proton and electron flux near the Earth. The POES
satellites also have a capability, via their on-board Argos system, of
receiving, processing, and retransmitting data from weather balloons,
buoys, and remote automatic data collection stations distributed around
the world. In addition, the POES satellites have an onboard Search and
Rescue transponder and processor for receiving transmissions from people
in distress.\
\
The PGS is comprised of the Satellite Operations Control Center (SOCC)
and Environmental Satellite Processing Center (ESPC) located in
Suitland, Maryland, and the NOAA Command and Data Acquisition (CDA)
Stations at Fairbanks, Alaska (FCDAS), and Wallops Island, Virginia
(WCDAS). Command and data acquisition control of the polar-orbiting and
geostationary operational satellites is conducted from the SOCC, through
communications links with the ground system facilities at the CDAS.

NOAA polar satellite data are processed centrally at the Suitland,
Maryland site within the ESPC.

**NOTE**: For NPOESS, the SOCC and its links to the CDAs will be
replaced by new facilities, to be described later in this document. The
proposed NDE Systems are "back end" only, and will be implemented using
only one segment of the current PGS, the ESPC in Suitland, Maryland.\
\
The global images are processed into polar stereographic and Mercator
maps of cloud cover. The sounding data are processed for use by the
National Meteorological Center (NMC) and placed on the Global
Telecommunication System (GTS) for national and international
distribution. Drivers of Change

# Justification for Proposed Changes

## Consolidation and Cost Savings

The U.S. Government has been merging the Nation's military and civil
operational meteorological satellite programs into a single, integrated,
satellite system capable of satisfying both civil and national security
requirements for space-based remotely sensed environmental data. Under
direction of the National Performance Review (NPR) and the Presidential
Decision Directive-2 (May 1994), the missions of the existing DoD
Defense Meteorological Satellite Program (DMSP) and the NOAA POES
programs are being combined and replaced by NPOESS.

The Integrated Program Office (IPO) is a management organization with
responsibility for developing, acquiring, managing and operating the
NPOESS satellites as well as the ground systems necessary for capturing,
processing, and delivering the data to the Centrals, including NDE. IPO
coordinates the interests of the three NPOESS stakeholder agencies; the
Department of Commerce (DOC), the National Aeronautics and Space
Administration (NASA), and the Department of Defense (DoD). IPO has
established an umbrella, performance-based contract with Northrop
Grumman Space Technologies (NGST) for all of these tasks. Under the
terms of the contract, NGST and their subcontractor Raytheon are Shared
System Performance Responsibility (SSPR) partners with the Government.
(NGST/Raytheon will be referred to as "the SSPR" throughout this
document.)

NESDIS, in participation with the DoD, the National Weather Service
(NWS), and other user agencies, defined and documented a set of
requirements to jointly meet the needs of the nation's civil and
military users for polar satellite data. These requirements are
documented in the NPOESS Integrated Operational Requirements Document
(IORD). The IORD identifies 56 atmospheric, oceanic, terrestrial,
climatic, and solar-geophysical data products and related attributes to
guide the development of advanced technology instrumentation. The new
NPOESS sensors will provide enhanced capabilities to users and improve
the accuracy and timeliness of observations.

## Technology Improvements

NPOESS will provide new and improved remote sensing data in comparison
to existing polar satellites. The NPOESS space segment consists of a new
suite of instruments:

-   Visible-Infrared Imager Radiometer Suite (VIIRS)

-   Conical Microwave Imager Sounder (CMIS)

-   Cross-Track Infrared Sounder (CrIS)

-   Advanced Technology Microwave Sounder (ATMS)

-   Ozone Mapping and Profiling Suite (OMPS)

-   Earth Radiation Budget Sensor (ERBS)

-   Space Environment Sensor Suite (SESS)

-   Aerosol Polarimetry Sensor (APS)

-   Altimeter (Alt)

-   Advanced Data Collection System (A-DCS)

-   Search And Rescue Satellite Aided Tracking (SARSAT)

-   Survivability Sensor (SS)

Because there will be so many new instruments introduced over the course
of the NPOESS program, the first satellite in the program will be unique
in that it will not be certified as operational. The purpose of the
first satellite is to mitigate the risks presented by all of the new
technologies that will be implemented for NPOESS, not to provide
operational products. In 2008, the risk-reduction NPOESS Preparatory
Project (NPP) satellite will be launched. NDE will use products from the
NPP satellite to develop product prototypes, a distribution network, and
the core of its product packaging systems.

On the ground, fundamental technology changes will require new modes of
data processing. NPOESS will have a new ground station architecture that
will provide more data at a faster rate. By 2013, NPOESS will deliver
about 8 terabytes of data to NESDIS every day. The products will be
available for assimilation into user systems within minutes of
observation instead of hours. Through the use of the 'SafetyNet'
Command, Control, and Communications (C^3^) concept (Figure 1),
providing automated, schedule-driven connectivity to the Space Segment
through 15 globally distributed commercial Stored Mission Data (SMD)
receptors linked to the Centrals via commercial fiber optic
communications lines, the time from observation to delivery of
Environmental Data Records (EDRs) to the user will be dramatically
reduced under NPOESS. It is anticipated that greater than 77% of the
data will be delivered in 15 minutes from observation, and 95% of the
data delivered within 28 minutes; average data delivery will be less
than 10.5 minutes. This compares to current delivery times of 35 to 135
minutes from observation for the most commonly used polar satellite
products. Two or three times a day, a current polar satellite's orbit
does not bring it within transmitting range of a ground station. The
interval between delivery and observation for these "blind orbits" is
236 to 336 minutes. There will be no blind orbits during NPOESS.

These very short latency periods will not apply during the NPP period,
since the SafetyNet is not scheduled to be operational until the first
NPOESS satellite is flown. The data from the NPP satellite, therefore,
will be routed to NDE from a ground station located at Svalbard, Norway.
NPP data will be available within 35 to 135 minutes after observation.
Since Svalbard is at high latitude, there will no NPP blind orbits.

![](media/image2.png){width="6.620138888888889in"
height="3.3819444444444446in"}

[]{#__RefHeading___Toc110755600 .anchor}Figure 1: NPOESS SafetyNet

##  Implications for the User Community

> [Improved Weather Forecasts and Hazard Warnings]{.underline} - The
> ability to receive high-resolution data from polar satellites within
> minutes of observation is expected to significantly improve the
> accuracy and timeliness of weather forecasts and hazard warnings.
>
> [New Research and Development]{.underline} - Measurements and richer
> detail of NPOESS instrument observations will create opportunities for
> experimentation and innovative analyses of environmental models.
>
> [Upgraded Information Systems]{.underline} - Organizations who would
> like to take advantage of these opportunities will upgrade their
> systems to accommodate the NPOESS environmental products and data
> sets.
>
> [Informed Climate Policy]{.underline} - Over the long term, the higher
> resolution data and new observations will provide better data for
> climate studies which, in turn, will provide policy makers with the
> ability to make decisions based on better information.

# Concepts for the Proposed System

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

[]{#__RefHeading___Toc110755601 .anchor}Figure 2: NOAA Central

## NOAA Satellite Operations Facility (NSOF)

The NOAA Satellite Operations Facility (NSOF) is located in Suitland,
Maryland, providing facilities for satellite command and control and for
the generation and distribution of products derived from satellite data.
The facility provides operational capabilities for NOAA satellites, as
well as for various non-NOAA satellites including those of America's
foreign scientific partners under the terms of various treaties and
agreements. The NOAA Central, as well as the NPOESS Command, Control and
Communications Segment (C3S), will be at NSOF.

For NPOESS and NPP, NOAA provides the floor space, a secured facility
and connectivity to the NPOESS spacecraft through roof-mounted antennae.
The costs and responsibilities for connectivity to Svalbard and the
SafetyNet through exclusive fiber optic networks will be borne by IPO.
IPO also assumes the costs and responsibilities for internet and other
telecommunications between Suitland and other Centrals.

Stored Mission Data (SMD) will be delivered to NOAA from the NPOESS
downlink facility, and passed through a firewall into the IDPS.
Firewalls will also be required between the IDPS and the NDE system, the
LTA, and possibly NASA's Science Data Segment (SDS) (an entity
responsible for the generation of Climate Data Records (CDRs) from the
NPP satellite). Firewalls will be maintained separately by the SSPR, to
prevent unauthorized access via NOAA connections, and by NESDIS to
protect against incursions from the NPOESS side.

The two NPOESS systems at NSOF are the Mission Management Center (MMC)
and an instance of the Interface Data Processing Segment (IDPS). The
SSPR will acquire all necessary equipment for these systems and will
have full and exclusive responsibility for their operation.

NESDIS has operational responsibility for the Environmental Satellite
Processing Center (ESPC) and all of the systems that use its
infrastructure, including NDE. NDE will be logically separate in the
sense that its processing will be segregated. The resources that NDE
will use to accomplish its mission are those of the ESPC environment.

## NPOESS Interface Data Processing Segment (IDPS)

The IDPS is a hardware/software suite that is capable of producing the
full set of NPOESS products. The collective name for the various data
records that are generated by the IDPS is "xDR." Metadata, consistent
with Federal Geographic Data Committee (FGDC) standards, is attached to
each record. The xDR record types are categorized as follows:

**Raw Data Record (RDR)** -- An RDR is the IDPS first phase product. It
is a full resolution digital sensor data file, time referenced, with
radiometric and geometric calibration coefficients appended, but not
applied, to the data. Aggregates (sums or weighted averages) of detector
samples are considered to be full resolution data if the aggregation is
normally performed to meet resolution and other requirements. \[Sensor
data will be unprocessed with the following exceptions: time delay and
integration, detector array non-uniformity correction (i.e., offset and
responsivity equalization), and data compression.\]

**Temperature Data Record (TDR)** -- A TDR is an intermediate IDPS
product created from the application of algorithms to microwave sensor
RDRs. It consists of geolocated, antenna temperatures with all relevant
calibration data counts and ephemeris data. TDRs also provide an audit
trail from the raw data (RDR) to the TDR.

**Sensor Data Record (SDR)** -- A SDR is an intermediate IDPS product
resulting from the application of an algorithm to non-microwave sensor
RDRs. It consists of geolocated and calibrated brightness
temperatures/radiances with associated ephemeris data. SDRs provide an
audit trail from the raw data (RDR) to the SDR.

**Environmental Data Record (EDR)** - An EDR is the end product of
complete IDPS processing. It is a collection of data that represents one
or more related environmental variables, generally referenced to the
source location. Environmental variables are reported in physically
significant units at the source, and geometrically referenced with
respect to the Earth or another appropriate coordinate reference system.

Each EDR will include metadata, data that describes and provides context
for the subject data.

**Application-Related Product (ARP) --** ARP is a subcategory of an EDR.
An ARP is an application of another EDR. ARPs are subject to the same
requirements as EDRs.

**Intermediate Product (IP)** - An IP is produced by the IDPS during the
process of generating an EDR. Although not specified in the IORD, a
selected group of IPs will be made available as end products by the
IDPS.

(**NOTE:** For reference purposes, Figure 2 shows two external data
flows from the IDPS. These are outside the scope of this document and
will not be described. They are the flow of xDRs to NOAA's Comprehensive
Large Array-data Stewardship System (CLASS) for long-term archiving and
a similar xDR data flow will provide NASA with NPOESS products.)

Therefore, the IPO is singularly responsible for the entire IDPS
operation and all the configurations/inputs used in that operation. This
includes

-   Acquiring, installing, operating, monitoring, trouble-shooting and
    maintaining the IDPS

-   Managing and controlling the IDPS configuration. (Although each IDPS
    will maintain a revolving archive that stores IDPS products produced
    over the last 24 hours, this capacity is primarily in support of
    internal IDPS operations. It can be used to support the NOAA Central
    on an emergency/contingency basis. However, since the interface is
    bandwidth and processor constrained, it is not intended to serve as
    an on-line data repository/database for the Central.)

-   Distributing patches and new versions of the IDPS software

-   Acquiring, installing, and maintaining the hardware suite for the
    Algorithm Development Area (ADA)

-   Training NOAA Central personnel on how to configure and operate the
    ADA.

-   Managing the prioritization of IDPS enhancements/new capabilities
    within the NPOESS Configuration Control Board (CCB) process.

-   Managing the Engineering and Manufacturing Development (EMD)
    Contractor and Operations and Support (O&S) contractors (as
    applicable), who are responsible for:

    -   Tuning IDPS algorithms

    -   Calibrating all data

    -   Monitoring and providing quality control of products

    -   Identifying ancillary data requirements and sources and
        coordinating with external agencies to make necessary ancillary
        data available

    -   Supporting the NOAA Central in enhancing its local exploitation
        of NPOESS products, but only as funded by the Centrals under
        separate tasking

A Memorandum of Understanding (MOU) between the NOAA Central and the IPO
will capture hosting arrangements/constraints where the IPO's ability to
provide services is reliant upon the NOAA Central. The IPO is
responsible for initially coordinating and updating the MOU with the
NOAA Central to ensure the operation and hardware maintenance of NPOESS
elements.

##  NDE Product Generation and Dissemination

NOAA customers will be the recipients of NPOESS products according to
their data requirements and NOAA products will be disseminated to them
according to their preferences. Creation and dissemination of these
products to customers are the core missions of NDE.

### NDE Product Data Flows

[The xDR Data Flow]{.underline} - The IDPS is a hardware/software suite
that is capable of producing the full set of NPOESS products. The
collective name for the various data records that are generated by the
IDPS is "xDR." Metadata, consistent with Federal Geographic Data
Committee (FGDC) standards, is attached to each record. Customers may
opt to receive products exactly as provided by the IDPS.

[The Tailored Product Data Flow]{.underline} - Products tailored by NDE
provide alternative views of the data record to facilitate assimilation
by the customers' systems. Whenever possible, NDE will provide the
software to enable the end users to do the tailoring on their own
systems. Many, however, will prefer to have NDE do this tailoring. NDE
will offer customers the following tailoring options:

-   Format: NPOESS' IDPS will deliver all products to NESDIS in
    Hierarchical Data Format 5 (HDF5), a standard used by only a few of
    NESDIS' customers. Optional formats will include: HDF5, BUFR,
    geoTIFF, NETCDF

-   Alternative map projections (Polar Stereographic, Mercator)

    -   Coverage areas (Global, Regional, Local)

    -   Aggregations (Daily, Weekly, Monthly)

    -   Grid Spacing (xyz, qjr)

    -   Compression approaches (None, JPEG, MPG, etc.)

[The NOAA-unique Data Flow]{.underline} - NOAA-unique product
development is necessary to support missions that are specific to NOAA,
as opposed to data used by all Centrals. NOAA-unique products are
augmented environmental products constructed from NPOESS Data Records.
They will be generated by procedures (e.g., algorithms) that use NPOESS
Data Records (xDRs) as a basis of products containing data values that
are different from those in the xDRs as received from NPOESS. NDE will
generate NOAA-unique products by combining products from different data
sources to provide other environmental information.

NDE will receive Search and Rescue Satellite Aided Tracking (SARSAT)
telemetry from the NPOESS satellites. The telemetry will be routed to
NOAA's U.S. Mission Control Center (USMCC) in Suitland, Maryland without
any tailoring.

### Enterprise Tools

NDE software developers will identify and deliver shareable, reusable
data processing capabilities. These capabilities are necessary in order
to reduce the risks associated with developing and operating many
product generation applications in a single environment. NOAA will not
treat each NPOESS product generation system as a unique challenge.
Rather, NDE seeks to establish a common tool set that will allow the
scientific product development teams to focus on the science, using
functionality available to all of them to perform the more mundane data
processing tasks.

These capabilities will operate within NESDIS' ESPC. NDE will cooperate
closely with ESPC, whose contract vehicles will be used to procure the
technologies that enable both the development and the operation of NDE's
enterprise capabilities. In this relationship, NDE provides the
requirements for technologies such as:

-   Relational Data Base Management System (RDBMS)

-   Object Repositories

-   Fourth Generation Languages

-   Test Tools

-   Configuration Management Systems

-   Work Management Tools Schedulers

-   Help Desk Software

-   Reporting tools

-   Process/Project Management tools

-   Etc.

As the initial, primary users of these technologies, NDE will assist
ESPC operations staff to configure, install, and test the products in
the appropriate environments.

The NPP satellite's products offer ESPC opportunities to prototype some
of the high performance computing, high volume data management, and
product distribution capabilities that will be required for ESPC. The
first geostationary satellite to carry the new technologies, GOES R, is
not scheduled for launch until 2013 - after C1 and C2 are already
operational. NDE, therefore, is the first project that will deliver the
next generation of satellite products using ESPC capabilities.

### Algorithm Development 

Within the Enterprise NDE system, the key executable elements are the
algorithm objects, the unique software that is specifically developed to
process each xDR. The Enterprise Tools (above) are there to reduce the
amount of coding and testing the algorithms will require. Because of the
very broad Customer base and the anticipated high demand for NPOESS
products, NDE will coordinate the identification, prioritization, and
high-level management of the many algorithm development projects that
NOAA will conduct during the NPP and NPOESS eras.

The algorithm development projects will, for the most part, be conducted
by the NESDIS Office of Research and Applications (ORA). Science teams
from across NOAA will also develop algorithms using the NDE Enterprise
Toolset.

An important algorithm development project prioritization factor is
whether an EDR has been designated as a Key Performance Parameter (KPP).
Products in this category have been identified by the user community in
the IORD as the most important deliverables from the NPP/NPOESS program.
KPPs are:

-   Atmospheric Vertical Moisture Profile

-   Atmospheric Vertical Temperature Profile

-   Imagery

-   Sea Surface Temperature

-   Sea Surface Winds

-   Soil Moisture

During NPP, NDE will release as many products as possible so NOAA
customers can take advantage of the risk reduction opportunity to
upgrade their systems. These quasi-operational releases will begin
toward the end of 2008, soon after the IDPS begins feeding xDRs to the
NDE system.

#### Algorithm Development on the IDPS Algorithm Development Area 

NOAA scientists and developers will have access to an IDPS capability
known as the Algorithm Development Area (ADA). The ADA is situated
within the IDPS' Integration and Test (I&T) string. Uses of the I&T
String include

-   Redundancy in case of Operations string failure

-   Algorithm development capability

-   Installation and testing of new baselines prior to promotion to
    Operations

-   Transition support for new baselines and technology insertion

-   Operator training and certification

-   Parallel operations

The NPOESS I&T String is identical to an Operations String except that
the Operations (Ops) String has a 100% reserve capacity. The two strings
are connected to one another through two IBM Federation Switches that
allow high-speed data transfers between the two strings. While each
string contains large capacity disk storage, each storage subsystem is
also shared between strings. This interconnectivity and shared disk
storage allows the Ops String to transfer processing over to the I&T
String in the event that the Ops String experiences a total failure.
Access to the ADA will not be allowed in circumstances if the I&T String
is being used by the NPOESS program concurrent with the Ops String. This
will occur when new IDPS software versions are being tested.

The Algorithm Development Area (ADA) consists of one or more domains
using the Integration and Test (I&T) IDP string where the domains are
used for software development activities in support of developing
algorithm modifications and prototype algorithms. The ADA provides:

-   Software development area and tools to develop/modify algorithms

-   Existing NPOESS algorithms source for modification

-   Algorithm "templates" to develop new algorithms in IDPS I-P-O
    (Input-Processing-Output) format

-   Lightweight versions of Infrastructure and Data Management

    -   Enables algorithm execution without full IDP software

    -   Infrastructure controls algorithm via command line/file
        interface, logging and status

    -   Data Management provides utilities to populate and provide
        access to storage

The algorithm development environment allows development of prototype
algorithms by NESDIS using operational SMD and algorithm specific test
data. Beta EDR algorithms developed in the ADA can be migrated to the
parallel operations string within I&T resources where they can be
applied to SMD data.

In the event of a "total" failure of OPS server, the IDPS operator dumps
all processes running on the I&T machine, reboots the I&T server, points
the I&T to appropriate disk storage, loads the IDP software system into
the I&T server, and continues operation. The I&T String then effectively
replaces the OPS String as the current operations string.[^1]^2^
**Note** that there is disk storage on the I&T string specifically set
aside for algorithm development; it is preserved throughout the
operations process and available to the ADA when the I&T string is
returned to service.

## NOAA Environmental Satellite Processing Center (ESPC)

ESPC's responsibilities include:

-   NDE operations:

    -   infrastructure acquisitions

    -   technology support

    -   product generation

    -   product distribution

    -   telecommunications

    -   customer service

    -   product order management

-   Continuity of operations for the above in the event of normal
    operational failure

-   Provide System Development infrastructures

    -   Algorithm development/test

    ```{=html}
    <!-- -->
    ```
    -   Enterprise tool development/test

-   Implement and operate a stand-alone System Test Environment

```{=html}
<!-- -->
```
-   Replicate all significant characteristics of the Operational
    Environment

-   Provide a temporary backup environment in which products can be
    generated and distributed to customers in the event of operational
    environment failure

-   Evaluate candidate system elements for operational fitness,
    performing appropriate

    -   Parallel tests

    -   Stress Tests

    -   Regression Tests

```{=html}
<!-- -->
```
-   Certify candidate system elements for operational fitness

NDE will be responsible for providing requirements and specifications
for all of the technologies needed for these environments. The NDE
Project Manager will direct funds to OSDPD for these purposes. The NDE
System Architect provides guidance and direction to ESPC personnel in
the following domains:

-   Software Engineering

-   NDE product generation requirements

-   NDE systems management requirements

-   NDE infrastructure requirements

-   NDE data retention and archive requirements

-   NDE external interfaces

-   NDE communications and distribution requirements

Depending on decisions to be made in the context of NDE's System
Architecture, as well as ESPC's design efforts with regard to shared
data processing and collaborative environments, some development
equipment may be installed at remote sites. ESPC will provide authorized
developers with high speed access to NSOF development resources (test
databases, Configuration Management (CM) tools, documentation libraries,
procedure libraries, etc.).

### Security

ESPC is responsible for the security of NDE's Operational, System Test,
and Development capabilities. ESPC will establish and enforce security
procedures to ensure the data integrity of all operational and
developmental applications that run under its auspices, including NDE's.
ESPC provides protection from access to NDE's automated resources by
unauthorized users. ESPC will withhold specified NPOESS datasets from
unauthorized users when so ordered by National Command Authority (e.g.,
data access). Aside from these data access requirements (TBD), NDE has
no security requirements different from those ESPC will provide for all
of the applications that operate under its auspices.

### Data Base Administration

ESPC will provide maintenance and support for a selected Database
Management System (DBMS) as well as of the data content to be
established on that system. NDE is committed to sharing this essential
resource with all of NOAA. The NDE System Architect will coordinate the
creation of data models by the various development organizations (CLASS,
ORA, ESPC, NOAA's National Data Centers, NDE product developers, etc.).
The Architect's coordination activities will focus on the identification
of as many opportunities to share and reuse the maximum number of data
entities and object classes. This coordination of conceptual data models
is the foundation of NDE's "enterprise approach." In turn, ESPC's
database administrators (DBAs) will be responsible for maintaining the
integrity of the operational forms of the models -- the data itself.

### Disaster Recovery

ESPC will develop an ability to recover from disruptions of NDE product
deliveries and services resulting from disasters. NDE has no disaster
recovery requirements different from those ESPC will provide for all of
the applications that operate under its auspices.

### Customer Services

ESPC will provide customer services including:

-   Product order tracking

```{=html}
<!-- -->
```
-   Management of trouble reports (logging and appropriate follow-up)

```{=html}
<!-- -->
```
-   Routing of customer product inquiries to qualified specialists

At the present time, NDE has no customer service requirements different
from those ESPC will provide for all of the applications that operate
under its auspices. However, NDE may levy the following customer service
requirements on ESPC if requested during Customer Coordination Phases of
NDE Build Cycles:

-   Product order placement

-   Service request management such as:

    -   Capturing enhancement requests

    -   Managing the resolution process for determining whether to
        undertake an enhancement

    -   Conducting customer satisfaction surveys

    -   Maintaining a database of customer requests to enable reporting
        by customer, by product, by request type, by status, and by date

    ```{=html}
    <!-- -->
    ```
    -   Management of online product training materials and other
        distance learning capabilities

    -   Extending operator working hours to provide customer assistance
        beyond eight hours on week days

ESPC will negotiate Service Level Agreements (SLA) with all of its
product customers. These agreements will guarantee levels of performance
in terms of product deliveries, availability of access to system
resources, and the availability of support from ESPC, either from
operators or from automated Help applications. ESPC will establish
similar agreements with selected NOAA offices chosen as representative
of those who will use ESPC resources to develop products, including
NDE's. At the present time, NDE anticipates no performance baselines
different from those ESPC will provide for all of the applications that
operate under its auspices.

### Configuration Management

Important aspects of the relationship between NDE and ESPC can be
illustrated in terms of Configuration Management (CM) and System
Testing. New or enhanced algorithms, for example, will be run in a
System Test environment that simulates ESPC operations. In order for an
algorithm to be certified as Operational, it must perform without
causing errors (regression testing) or degrading performance (stress
testing) when using the same configuration of enterprise resources (the
DBMS, object repositories, shared procedures, etc.) as those running in
the ESPC operational environment. The algorithm will be submitted for
System Testing as part of a package that might also include additional
test data, enhanced versions of shared elements, documentation for new
test procedures, and (in all cases) updated documentation for each of
the enhanced components to be certified. New or enhanced enterprise
tools will, likewise, be required to undergo the same level of system
testing.

## Long Term Archive (LTA)

Number range CHAPTERThe NPP and NPOESS Long Term Archive (LTA)
functionality is provided by NOAA's Comprehensive Large Array-data
Stewardship System (CLASS) to ensure data availability during and beyond
the NPP and NPOESS missions. The LTA will archive all sensor data,
including when the sensors are in diagnostic mode, and provide access to
users.[^2]

NDE will archive its product tailoring tools, its NOAA-unique
development tools, and the NOAA-unique products. Tailored products will
not be archived on the assumptions that Customers will be able to
retrieve xDRs from CLASS and, using the tailoring tools provided by NDE
through the CLASS interface, tailor them for their purposes

## NPOESS Mission Management Center (MMC) 

The SSPR performs the following functions at the MMC: Flight Operations,
Satellite Operations, Mission Management, and Enterprise Management.
**Note:** MMC's data flows (Figure 2) touch the ESPC boundary, not
NDE's. This indicates that the interaction is between NPOESS and ESPC's
operators, who are responsible for the common interfaces available to
all ESPC-resident applications, including NDE.

The data flow "NPOESS Status" represents messages to the ESPC operators
about conditions, either at the spacecraft or on the ground, that might
have an [impact on NDE data processing](#impact-of-satellite-maneuvers).
Based upon predetermined circumstances, documented in an Operators'
Manual, the ESPC operators determine whether the message should
influence NDE processing. If so, they will carry out the actions
necessary to accomplish the change. In some cases, they may inform NDE
management of the message content. In turn, NDE management can authorize
NDE process changes.

"Trouble Tickets" are sent by ESPC operators to notify NPOESS that NDE
has detected conditions in XDRs that require attention. The MMC's
Enterprise Management System (EMS) is the function that accepts NDE
Trouble Tickets as well as "Work Requests." Work Requests are more
specific than Trouble Tickets in that they suggest changes to NPOESS.

The EMS maintains a Work Request System (WRS) with a Graphical User
Interface (GUI) permitting authorized personnel at the Central to submit
Trouble Tickets or Work Requests. Internal NPOESS procedures, including
submission of Work Requests to the NPOESS Change Control Board (CCB),
will determine a response to any Work Request. The results of these
procedures as well as the status of actions taken in response to Trouble
Tickets will be available to ESPC operators as "Work Request Status"
messages through the WRS interface.

NDE serves as the representative of NOAA's users to the NPOESS program.
Certain requests will be forwarded to the IPO in the event that they
cannot be satisfied by NDE. The IPO is responsible to a tri-agency board
for developing, implementing, operating and maintaining NPOESS. The IPO
has an obligation to the tri-agency boards to produce products that
satisfy the threshold and strive for the objective performance of
products listed in the IORD and, in the future, preplanned product
improvements.

### Official Ancillary Data

To generate EDRs, the IDPS acquires ancillary data from external sources
via the C3S Data Routing and Retrieval (DRR) and the NOAA Central LAN.
Ancillary data is data that is not produced by the NPOESS system but
which NPOESS EDR algorithms require to deliver the EDR attributes as
documented in the NPOESS System Specification's Appendix D (e.g.,
terrain height data base, conventional surface and atmospheric
observations, 12 hour temperature forecasts, etc.).

Periodic transfers such as FTP transfers are initiated by the IDPS
according to a schedule. Notification transfers allow external sources
to notify IDPS when updated ancillary data is available. All "official"
ancillary data, including backup data, whether or not used, is sent by
the IDPS to the LTA for archiving.

###  xDR Subscription Requests

Requests for data products will be submitted either through a GUI form
or as an Application Program Interface (API), both of which will be
maintained and supported by IDPS. Requests may be "standing" or "ad
hoc." Standing requests are used to receive repeated data product
delivery. Ad hoc requests are used to receive specific products over a
specific time range or geographical region. As soon as the ad hoc
request is fulfilled, the request expires. Data requests are made via a
local electronic interface or through a web-based mechanism.

Depending on the preference chosen on the request from NDE or recorded
in the user profiles in the IDPS, the product will either be sent
directly to NDE for distribution to the user, or the user will be
notified how the requested information product can be retrieved. NDE
(and civil users through NDE) will be given an opportunity to provide
feedback to the IDPS about the process responsiveness and the utility of
the data provided. NDE will also provide reports on the timeliness,
quality, and availability of the data delivered.

It is the responsibility of the NDE system to pull/receive the xDRs from
IDPS.

### The xDR Data Flow

#### Format

The IDPS will make available requested xDRs to the NDE system as the
products are produced. All IDPS processed data and its associated
metadata are stored as Hierarchical Data Format v5 (HDF5) files. All
xDRs sent to the NDE system will be in this format.

The IDPS stores xDRs as "granules" for a period of 24 hours. Storage is
based on the data type and descriptive metadata that corresponds to the
desired data. A granule is a contiguous temporal segment of data. The
boundary between one granule and the next granule occurs at the
completion of a scan line or collection intervals. The size of a granule
will vary by sensor, but will be a constant number of scan lines or a
collection interval for each sensor. By dividing the NPOESS data
products into smaller segments (granules of data), the IDPS processes
many granules concurrently across multiple high performance processors
to achieve the NPOESS EDR latency requirements. Since granule boundaries
are chosen to optimize processing, they are different from Stored
Mission Data (SMD) transmission boundaries, which are a function of
contact time with the spacecraft. The last RDR granule received in an
SMD transmission is likely to be incomplete. Therefore, the first sensor
data in the new SMD transmission must be combined with the sensor data
in the last SMD transmission to assemble a complete RDR granule.[^3]

Studies are ongoing to determine the precise delivery protocol of
granules/files. Once the data is received within the NDE architecture,
the data will be delivered to end users in HDF5 or, in some
circumstances, be converted from HDF5 to formats required by the
internal legacy product application or the end user.

#### Quality Control of xDRs

NDE is assured that the data it receives from the IDPS will conform to
the quality thresholds defined in the IORD. At all times, the SSPR will
monitor the performance of the payload sensors and perform operational
level calibration and validation of algorithms. The IPO Data Quality
Engineer (DQE) provides updates to application processing coefficients
used in IDPS processing and updates to sensor calibration tables for
uplink to the satellites.

The SSPR is responsible for the quality of EDRs produced by the IDPS
Element using Configuration Control Board (CCB) approved inputs and
algorithms; even though NOAA has the flexibility of using different sets
of ancillary data as input to their unique product algorithms. The IPO's
responsibility ends after it has made products available and supported
the ensuing delivery of products.

## Interoperability 

The NDE system components will be designed and maintained to interface
with the IDPS. The IDPS will be installed and demonstrated at least one
year prior to the launch of the NPP satellite. This NPP configuration
will be used to debug the software and conduct the calibration and
validation of the VIIRS, CrIS, ATMS, and OMPS sensors and their
products. The IDPS will then be upgraded/replaced prior to the launch of
the first operational NPOESS. As part of its evolutionary development,
the NDE system will also be upgraded to ensure interoperability.

# Operational Scenarios 

## Quality Assurance

### Ingest Quality Control

Upon receipt of an xDR from the IDPS, before routing for distribution
and/or additional processing, NDE will examine three external
characteristics of the data package:

-   Size, to test whether the data package received is the same as the
    one that was sent,

-   Quality Flags, to determine whether NPOESS marked the data package
    to indicate that special handling might be required

-   Metadata, to determine whether the data package includes the
    information necessary for retrospective processing (i.e., climate
    studies, archive retrieval, reprocessing, etc.)

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

#### Ingest Log

For each granule received by NDE, a record of the date and time the data
package was received, along with the granule's unique identifier, will
be created as an xDR record by the "Validate Checksum" procedure,.
Additional information will not be added to this record unless a problem
is detected. The xDR Ingest Detail will be established and reside in the
Ingest Log, available for update throughout the Ingest Quality Control
cycle. (Figure 5.1.1)

If a problem is detected during the Ingest Quality Control cycle, the
Ingest Detail will be updated with the appropriate information. In such
an event, a copy of the Ingest Detail will be created and sent to the
Product Processing subsystem along with the xDR. (This does not preclude
access to the Ingest Log by a Product Processing subsystem if its
internal rules require the date and time of ingest.) The presence of an
xDR Ingest Detail is an indication to the processing subsystem that
special actions might be required. The interpretation of the Ingest
Detail record's content, including the determination of any actions that
might be required, is the obligation of the Product Processing subsystem
associated with the xDR.

The Ingest Log will be sent to CLASS at regular intervals (TBD) to
provide the permanent history of granule transmission between NPOESS and
NOAA. After transmission to CLASS, the Ingest Log will be purged of the
archived xDR Ingest Detail records.

#### Product Control Data Base

A[. Quality Flags]{.underline}

The IDPS evaluates the quality of satellite data during the creation of
xDRs. IDPS assesses data quality according to whether the products meet
the delivery standards established in the IORD and published in the
External Data Format Control Book (EDFCB). Should NPOESS detect data
values outside of these published thresholds, Data Quality Management
(DQM) procedures will be invoked to investigate the problems. Among
these procedures are creation and transmission of a Quality Flag that
will accompany the xDR and indicate the nature of the deficiency. NDE,
then, can adjust its processing appropriately. *However, in all cases,
the data will be delivered to NDE.*

This approach obligates NDE to establish written Standard Operating
Procedures to detect the presence of Quality Flags and to respond
appropriately. For example, compensatory adjustments to operands might
be possible for some predictable types of data deficiencies. In other
cases, normal processing might continue. Of course, there will be cases
when the products are simply unusable. For mission-critical products,
NOAA's instrument experts may be notified to help work the problem.
Programmers and operators may be notified or asked to perform
predetermined tasks. Whether Customers are to be informed will also be
determined.

To the extent possible, it is desirable for these procedures to be
automated and to take place at the earliest possible stage in the
product life cycle. Accordingly, NDE will establish and maintain a
database of machine-readable information about how each product
processing subsystem is to respond to Quality Flags. Representatives for
each subsystem will be responsible for determining the values contained
for its xDRs. Access to the data base by the Analyze Quality Flag
process is shown in Figure 5.1.1.

B. Metadata Standards

Imposition of a single checkpoint for the quality control of metadata
supports the needs of a broad community of current and future users of
polar satellite data.

## Requests for NPOESS Data

The primary method the NDE system's operators will use to request data
(for themselves and NOAA civil users) from the IDPS is through a
web-based graphical user interface mechanism enabling data to be
selected based on satellite, sensor, data product type, channel, spatial
extent, and temporal extent. To request a product, the NDE operator will
start a web browser, enter the web address for the IDPS, and log in to a
menu-driven interface.[^4]^3^

The NDE operator has two options for requesting data; ad-hoc and
standing requests. Ad-hoc requests are limited-time requests for data in
a certain region or for a specific timed event and can be used to
request one-time delivery of a NPOESS data product or to request
repeated deliveries through a specified time period. Ad-hoc requests
expire after they have been filled. Standing requests refer to regularly
scheduled requests for data products to meet recurring requirements;
standing requests do not expire when filled. This interface provides the
NDE system with the capability to generate, modify, or delete requests
as well as monitor the status of existing requests.

To generate an ad-hoc request, an NDE operator will perform the
following steps through the interface:

-   Types in a request name

-   Filters the data products display (if desired) by entering product
    type (e.g. EDR, SDR), sensor, or spacecraft

-   Chooses the specific product (e.g. Aerosol Optical Thickness) or
    products

-   Selects the 'Ad-hoc' request type

-   Selects aggregation and length of aggregation (if desired)

-   Enters data about the area of interest such as latitude/longitude
    and time of observation

-   Sets a distribution time, which is either 'as available' or at a
    user-defined time

-   Selects the destination(s) for the data

-   Selects the submit button

For standing requests, an NDE operator follows the same process but
chooses 'Standing' request type instead of 'Ad-hoc'. The user is then
given the opportunity to specify a distribution time:

-   'As available' -- data are packaged and shipped as soon as the data
    arrives

-   Periodically -- for example, every satellite space-to-ground
    downlink communication

-   After the specified amount of data are gathered -- for example, one
    orbit

Once requests have been made, ESPC has the ability to do the following:

-   Suspend or resume requests

-   Modify existing requests

-   Use existing requests as a template for a new request

-   Delete requests

-   Request a retransmission

For any active request, the NDE operator can monitor the real-time
status of the request for the information listed below:

-   A User defined name and unique ID for the request

-   The product type

-   The destination of the requested data

-   The last time the request was fulfilled

-   An estimate of the next time the data request is to be fulfilled

-   The status of the request (e.g. waiting, formatting, transferring)

-   Messages

An alternate method available to the NDE system to request and receive
data is through an Application Program Interface (API). The API invoked
by an NDE application program sends a request to the IDPS for data. The
API is a set of library functions that are resident on NDE's machine
that will make the data request. These library functions are part of the
IDPS distributed software and must be installed on the NDE machine (IBM
AIX and Microsoft Windows 2000 are supported operating systems). NDE may
make API calls using C, C++, or Fortran. There are two different types
of API available to NDE: an API that delivers files and an API that
streams raw data to NDE. To use either one of the API's, NDE embeds the
library function calls into its application; these function calls are
executed when the application is run. These function calls contain all
of the necessary information to select a particular data product. A
Username and password is required to authenticate the request. If the
request fails to be authenticated or the request parameters are invalid,
the requesting application is sent an error message indicating the
problem.

The API that delivers files has the same exact functionality that the
GUI provides. This API can place both 'Standing' and 'Ad-hoc' requests
and accepts all the parameters that can be entered using the GUI. All of
the functionality that is present in the GUI can also be found in the
file delivery API (e.g., suspend, delete). Once the API has submitted
the request, the IDPS fulfills the request based on the request
parameters and returns a file for retrieval by ftp.

Parameters to be supplied include SpaceCraft, Sensor, and Product. Data
requests (via the GUI or API) may also include several optional
criteria. These options include: Temporal Range, Spatial Range, Orbit.
In addition, NDE may specify that individual granules satisfying the
request be aggregated into a larger file or delivered as separate
granules.

There are two defined methods of transferring data from IDPS:

-   File Transfer Protocol (ftp) for NPP only (State 1)

-   File Transfer Protocol over SSL (ftp-s) for NPP and NPOESS (States 2
    and 3)

For ftp and ftp-s, files are written in HDF5 format.

## Customer Order Management

ESPC will provide a secure subscription capability that will allow
customers to order products online. "Products" are either unchanged xDRs
as received by NDE from the IDPS, or repackaged xDRs, or NOAA-unique
products. Customers will be able to view the available products with an
online capability similar to the current SATPROD database. The product
list will be linked to an NDE subscription form allowing product
selection directly from the list.

Customers will be able to place orders for products on a standing basis
(e.g., a "subscription") or as an *ad hoc* request for specific NDE
product(s) for a designated period of time. A*d hoc* orders expire once
the order is fulfilled. A customer may place an *ad hoc* order in
addition to a standing subscription.

The process associated with a customer's initial order will be NDE's
primary means for capturing customer information. Products will be
distributed only to those select NOAA customers who have provided NDE
with a "customer profile" that includes organizational, contact, and
electronic connection information. Customers will be eligible to receive
products after their profiles have been approved by an NDE
administrator. Customers will have online, update access to their
customer profiles and subscriptions. Security procedures (TBD) will
ensure that no one other than authorized users will be able to update
data items associated with customer profiles and orders.

An "order", whether standing or *ad hoc*, will specify the product(s)
requested, the delivery schedule desired, the means of delivery ("push"
or "pull"), and the delivery address (if available for a particular
product), tailoring options (i.e., geolocation, data format, projection
scheme, etc.) will be included on the order. The default form of any
product will be the HDF5 version provided by the IDPS. NDE will offer
tailoring options selectively, on a product-specific basis.

The delivery schedules available will be limited to near-real time;
products will be distributed as soon as possible after receipt from the
IDPS. 77% of the data will be delivered to NDE by the IDPS within 15
minutes from observation. 95% of the data will be delivered within 28
minutes. The average data delivery interval from observation to receipt
by NDE will be less than 10.5 minutes. Tailoring and NOAA-unique
processes will be applied as soon as possible after receipt of the
necessary xDRs. It is expected that the processing of tailored products
not requiring external data sources will no more than five minutes to
the overall delivery speed.

If an order must be recreated within 24 hours of its scheduled delivery
time, NDE will reprocess the product using the appropriate xDRs from
NDE's 24 hour repository. Replacements for products delivered more than
24 hours previously will be obtained by customers from the Long Term
Archive.

NDE will have the capability to withhold orders (e.g., "deny data") to
unauthorized users when directed by National Command Authority through
the Department of Defense. Authorized users (U.S. Government agencies
and selected foreign meteorological offices with whom NOAA has formal
agreements for the sharing of satellite data) will be informed
immediately of these "data denial" events. In turn, the authorized users
must not disseminate the NDE data to any of their downstream customers
unless they have been authorized as recipients according to standards
(TBD) that will be provided by the Department of State.

Orders for product tailoring tools will be placed with the LTA; NDE will
not provide them directly to customers. However, NDE's available
Customer Services will include Help with regard to tailoring tool usage.

NDE will provide reports on the timeliness, quality, and availability of
all orders.

## NPOESS Data Denial

For NPP, following DoD determination as circumstances warrant, data
denial of the NPP HRD can be implemented by turning the HRD broadcast
off. For the NPOESS satellites, following DoD determination as
circumstances warrant, data denial of NPOESS direct broadcast and SMD
will be implemented through data encryption; the A-DCS and SARSAT
downlinks and A-DCS/SARSAT data included in the SMD, HRD, and LRD links
will not be denied. Authorized users, including the C3S and decryption
registered field terminals, will have the capability to automatically
decrypt the data downlinks. The NOAA Assistant Administrator for
Satellite and Information Services will be notified when data denial has
been authorized.

When data denial has been enabled, the NDE system and CLASS/LTA will
ensure unauthorized users do not receive the appropriate data. There are
a number of technical solutions that can be pursued.

1.  Develop advanced dissemination capabilities that enable an operator
    to quickly isolate unauthorized users from getting data. Server and
    internet technologies can be part of these capabilities. For
    example, FTP sites or portions of FTP sites could be restricted to
    specified ". mil" or ".gov" addresses.

2.  IDPS product generation and distribution system could be upgraded to
    allow NOAA to specify whether a product should be data denied
    automatically if regional and data type requirements are met.

## Science Support

Calibration, validation and unique command activities will require
additional sensor command activities. Related requests will be submitted
by the NOAA Central through the IDPS to the Operations Director and the
MMC for approval and execution.

## Algorithm Support Capability

The NOAA Central will use the algorithm support capability to support
activities ranging from algorithm development to testing algorithms in
parallel to Operations using the SMD stream from the NPOESS/NPP
satellites. The algorithm support capability aggregates the algorithm
development and algorithm support features provided by the IDPS at the
NOAA Central. The Algorithm Development Area (ADA) consists of one or
more domains within the Integration and Test (I&T) IDP string where the
domains are used for software development activities in support of
developing algorithm modifications and prototype algorithms. The ADA
resides in a logical partition on the I&T String and supports the
capability to test new algorithms against pre-recorded or live SMD
without the results being delivered into the production data stream. The
Algorithm Support Area is a location in the Central facility where
scientists/algorithm developers have workstations to access the
Algorithm Support Capability to develop and test algorithms. For a NOAA
user to use the ADA to modify an existing algorithm, the user must first
obtain the algorithm, data sets, etc. from the NOAA Central. The next
step is to log on to the ADA as an authorized user. The user will then
modify the algorithm as desired and execute the algorithm against static
data sets; the I&T Cal/Val can be used for analysis. Once completed, the
test results from the modified algorithm will be sent to NOAA Central
test users for evaluation. Once the modified algorithm is accepted by
the NOAA Central test users, it will be submitted to the IPO for CCB
evaluation. (See Section 3.2.2 for NDE/NPOESS shared use description.)

## Impact of Satellite Maneuvers

NPOESS Mission Management Center (MMC), housed at the NOAA Central, will
alert NESDIS of all planned satellite maneuvers and also provide data on
the results of such maneuvers. MMC will also provide this information to
the LTA.

Orbit changes are accomplished by reorienting the satellite to burn
attitude, then implementing the rocket firing process; maneuvers are
performed using thrusters (versus reaction wheels). Both maneuvers and
burns occur in eclipse (for inclination changes only). Satellite
maneuvers are made under three specific instances: Orbital insertion
trim, Drag Make-up, and Inclination Adjustments. During maneuvers, the
satellite will continue to collect all available sensor data. Scheduled
on-orbit mission data collection resumes after maneuver operations are
concluded.

During Orbital Insertion trim an 'Altitude Increase' maneuver is
required to eliminate any orbital injection abnormalities following
launch vehicle separation. This occurs once in each satellite's
operational lifetime at beginning of life.

Drag make-up maneuvers require an 'Altitude Increase' maneuver to
eliminate the effects of orbital drag on ground track parameters. They
also satisfy the VIIRS refresh rate requirements and the requirement to
prevent satellite contact time conflicts at the ground receptors and
ground stations. For the satellite carrying the Altimeter, it is
predicted that the ground track requirement imposes executing a drag
make-up maneuver every 2 months during peak solar activity and every 7
months during minimum solar activity. For the other satellites, it is
predicted that the VIIRS refresh rate and contact conflict prevention
requirements impose executing a drag make-up maneuver once a year during
peak solar activity and once every several years during minimum solar
activity. The sensors are left in operational mode for drag make up
maneuvers.

An 'Inclination Adjustment' maneuver eliminates the effects of orbital
dynamics on the inclination of the satellite. Inclination changes are
infrequent: one is planned in the first year and another during the
third year of the mission.

## SARSAT/A-DCS

The NPOESS space segment incorporates components of the SARSAT system
and Advanced Data Collection Subsystem (A-DCS). The onboard SARSAT
transponder receives signals from emergency location transmitters (ELT)
and relays the information to any SARSAT local user terminal (LUT)
within the satellite's field of view. This data is forwarded through the
SARSAT system to the SARSAT Mission Control Centers, where it is
distributed to international search and rescue teams. The onboard
component also includes an instrument that performs onboard processing;
i.e., the Search And Rescue Processor (SARP). The SARP generated
products are interleaved in the broadcast to the LUTs (not sent down in
the SMD).

**The only SARSAT data that comes through at the Central interface is
the telemetry. The IDPS forwards these data to the NOAA Central for
distribution to the US SARSAT Mission Control Center (USMCC).**

SARSAT telemetry is also included within the SMD downlink. The IDPS
processes this telemetry into RDRs and provides it to the NOAA Central
for distribution to the USMCC. The NOAA Central is also responsible for
distributing the following information from the IDPS to the USMCC;
NPOESS auxiliary data[^5], notification of planned NPOESS operations
(i.e., maneuvers) that may impact the SARSAT mission, and periodic
NPOESS activity reports. In the event of ad hoc NPOESS activities or
anomalies that may impact the SARSAT mission, the NPOESS Associate
Director for Operations will notify the USMCC directly.

Mission data and full orbit housekeeping telemetry from the A-DCS are
transmitted in the SMD and processed by the IDPS. On a specified basis,
the IDPS provides the A-DCS mission data and sensor telemetry to the
NOAA Central for distribution to the US Global Processing Center
(USGPC). The NOAA Central is also responsible for distributing the
following information from the IDPS to the USGPC; NPOESS auxiliary data,
providing notification of any planned NPOESS operations that may impact
the A-DCS mission, and periodic NPOESS activity reports. In the event of
ad hoc NPOESS activities or anomalies that may impact the A-DCS mission,
the NPOESS Associate Director for Operations will notify the USGPC
directly.

## NDE Problem Resolution

Three basic types of problems are anticipated with the NDE system;
network, hardware, and software/configuration based. When a problem is
detected, operations will be redirected to a hot backup set of resources
either automatically or by the NDE system operator; the NDE system will
be programmed to alert the NDE system operator when a failure is
detected, allowing the operator to initiate a fault detection routine.
The recovery concept is that since the NDE system has a 100% reserve
capability, the first step is to replace the problematic unit with an
onsite spare. If reserve capability is not available, logistic spares
will be used to return the NDE system to operations as soon as possible;
these spares are the responsibility of NESDIS. If service will be
degraded, the NDE system operator will follow Standard Operating
Procedures, including notification of OSDPD management.

If no hardware or network failures are indicated, but a system
malfunction has been identified, the first step is to determine whether
the problem is being experienced at all four Centrals or whether it is
unique to the NDE system. If the problem is found to be unique to the
NDE system, a decision will be made whether or not to conduct a clean
install of the current configuration of NDE software. If the problem is
common to all Centrals or a clean install of the NDE software does not
clear the problem, a decision will be made by the NDE operator on what
the next step will be and the urgency with which it is taken. If the
problem has an impact on critical production or impacts other Centrals,
the problem will be worked immediately. If the impact is not critical,
the problem will be worked during regular hours. The NDE operator's
response to a problem will be driven by Standard Operating Procedures.

## Homeland Security

TBD

## Contingency Operations

Contingency of operations will be required for localized non-critical
failures as well as catastrophic failures of the entire NOAA Central.
The criticality and timeliness of the response will be dependent on the
local action plans defined within the framework of the NOAA Continuity
of Operations Plan (COOP).

In the event of a failure of the entire NOAA Central or one of its
components, continuity of products and services is essential to the
NPOESS system and user community. These products and services are
anticipated to be provided through local actions (e.g., onsite sparing)
and transitions to remote redundant services. For example, in the event
of a local power loss, the NOAA Central is responsible for ensuring the
availability of power and environmental services to the local NPOESS
systems. In the event of a failure of the CLASS-Suitland interface, the
CLASS Asheville site will provide an interface to archive and access
services.

In general, localized non-critical failures will be handled through
onsite sparing and temporary periods of degraded service. Critical
functionality will be immediately backed up through onsite or remote
redundant systems; e.g., in the event of a total failure of the NOAA
Central, it is anticipated that needed ancillary data will be provided
by the other IDPS systems.

# SUMMARY of IMPACTS (TBD)

## Organizational Changes

## Technology Changes

# ANALYSIS OF PROPOSED SYSTEM

This section to be completed by the NDE/ESPC development team by June
30, 2006

# NOTES

tba

# Appendices

## Acronym List

  --------------- ---------------------------------------------------------
  **A-DCS**       Advanced Data Collection System

  **AFWA**        Air Force Weather Agency

  **APS**         Aerosol Polarimeter Sensor

  **ATMS**        Advanced Technology Microwave Sounder

  **AWIPS**       Advanced Weather Interactive Processing System

  **C1**          NPOESS First Satellite

  **C2**          NPOESS Second Satellite

  **C3**          NPOESS Third Satellite

  **CASE**        Computer Assisted Software Engineering

  **CDR**         Climate Data Records

  **CDR**         Critical Design Review

  **CE**          Capital Expenses

  **CLASS**       Comprehensive Large Array-data Stewardship System

  **CM**          Configuration Management

  **CMIS**        Conical Scanning Microwave Imager/Sounder

  **CO**          Contract Officer

  **CONOPS**      Concept of Operations

  **COOP**        Continuity of Operations Plan

  **COR**         Contract Officer Representative

  **CM**          Configuration Management

  **CrIS**        Cross-Track Infrared Sounder

  **CrIMS**       Cross-Track Infrared Sounder + Advance Technology
                  Microwave Sounder

  **DBA**         Data Base Administrator

  **DBMS**        Data Base Management System

  **DCS**         Data Collection System

  **DMSP**        Defense Meteorological Satellite Program

  **DoA**         Department of Agriculture

  **DOC**         Department of Commerce

  **DoD**         Department of Defense

  **DOS**         Department of State

  **DRO**         Direct Readout

  **ECMWF**       European Center for Medium-range Weather Forecasting

  **EDR**         Environmental Data Record

  **EOS**         Earth Observing System (NASA)

  **ERD**         Entity Relationship Diagram

  **ESPC**        Environmental Satellite Processing Center

  **EUMETSAT**    European Organisation for the Exploitation of
                  Meteorological Satellites

  **FAA**         Federal Aviation Administration

  **FNMOC**       Fleet Numerical Meteorology and Oceanography Center

  **FOC**         Final Operational Capability

  **HDF**         Hierarchical Data Format

  **HDF5**        Hierarchical Data Format version 5

  **I&T**         Integration and Test

  **IDPS**        Interface Data Processing Segment

  **IORD**        Integrating Operational Requirements Document

  **IPO**         Integrated Program Office

  **IPP**         Integrated Program Plan

  **ITAT**        Information Technology Architecture Team

  **JARG**        Joint Agency Requirements Group

  **JCSDA**       Joint Center for Satellite Data Assimilation

  **KPP**         Key Performance Parameter

  **LTA**         Long-term Archive

  **METOP**       Meteorological Operational

  **MMC**         Mission Management Center

  **NAVOCEANO**   Naval Oceanographic Office

  **NCDC**        National Climatic Data Center

  **NCEP**        National Centers for Environmental Prediction

  **NDE**         NPOESS Data Exploitation

  **NEB**         NOAA Executive Board

  **NGDC**        National Geophysical Data Center

  **NIC**         National Ice Center

  **NMFS**        National Marine Fisheries Service

  **NOAA**        National Oceanic and Atmospheric Administration

  **NODC**        National Oceanographic Data Center

  **NOS**         National Ocean Service

  **NPOESS**      National Polar-orbiting Operational Environmental
                  Satellite System

  **NPP**         NPOESS Preparatory Project

  **NSOF**        NOAA Satellite Operations Facility

  **NWS**         National Weather Service

  **O&M**         Operations and Maintenance

  **OAR**         Office of Atmospheric Research

  **OMB**         Office of Management and Budget

  **OPC**         Ocean Prediction Center

  **ORA**         Office of Research Applications

  **OSD**         Office of Systems Development

  **OSDPD**       Office of Satellite Data Processing and Distribution

  **PD**          Product Development

  **PDR**         Preliminary Design Review

  **PIR**         Post Implementation Review

  **POES**        Polar-orbiting Operational Environmental Satellite

  **POP**         Product Oversight Panel

  **PPBES**       Project Planning, Budgeting, and Evaluation System

  **PPI**         Plan For Product Implementation

  **PPI**         Program Planning and Integration

  **PSDI**        Product Systems Development and Implementation

  **R2O**         Research To Operations

  **RDBMS**       Relational Data Base Management System

  **RDR**         Raw Data Record

  **RTS**         Requirements Tracking System

  **SARSAT**      Search and Rescue Satellite Aided Tracking

  **SDLC**        System Development Life Cycle

  **SDR**         Sensor Data Record

  **SDS**         Scientific Data Stewardship

  **SDS**         Science Data Segment (NASA)

  **SMB**         Senior Management Board

  **SRR**         System Requirements Review

  **SST**         Sea-Surface Temperature

  **STI**         Science and Technology Infusion

  **SUAG**        Senior Users Advisory Group

  **TBC**         To Be Confirmed

  **TDR**         Temperature Data Record

  **UKMetO**      United Kingdom Meteorology Office

  **USMCC**       United States Mission Control Center

  **VIIRS**       Visible/Infrared Imager Radiometer Suite

  **WBS**         Work Breakdown Structure

  **xDR**         any NPOESS Data Record
  --------------- ---------------------------------------------------------

# GLOSSARY

## tba {#tba .unnumbered}

[^1]: ^12^ Prototype algorithms must be compatible with and execute
    under the deployed baselined operating system, i.e., AIX 5.n.

[^2]: Distribution of diagnostic data will be limited to scientists and
    engineers supporting NPOESS cal/val efforts and members of the
    scientific community characterizing long-term instrument
    performance.

[^3]: ^9^ There may be a need for greater overlay between
    orbital/granule segments depending on the specific product
    requirements

[^4]: ^13^ A configurable number limits the number of concurrent users.

[^5]: Auxiliary data are data types produced by NPOESS that are not
    sensor data but which the NPOESS EDR algorithms require to deliver
    the attributes documented in the NPOESS System Specification (e.g.,
    ephemeris data, sensor calibration coefficients, sun angles, etc.).