![](media/image1.jpeg){width="1.3006944444444444in"
height="1.2402777777777778in"}

National Polar-orbiting Operational Environmental Satellite System
(NPOESS) Preparatory Project (NPP)

Science Data Segment

Operations Concept

April 7, 2005

National Polar-orbiting Operational Environmental Satellite System
(NPOESS) Preparatory Project (NPP)

Science Data Segment

Operations Concept

Prepared By: Evelyn Lee Ho, NASA-GSFC

Shahin Samadi,Innovim

Ryan Gerard, Innovim

Reviewed By:

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Robert Schweiss NASA GSFC Date

Lead, SDS

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

James Gleason, NASA GSFC Date

Project Scientist, NPP

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Daniel DeVito, NASA GSFC Date

Systems Manager, NPP

Approved By:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Kenneth Schwer NASA GSFC Date

Project Manager, NPP

**CHANGE RECORD PAGE**

+-------+--------+----------------------+-----------------------------+
| **DOC |        |                      |                             |
| UMENT |        |                      |                             |
| TIT   |        |                      |                             |
| LE:** |        |                      |                             |
| Nat   |        |                      |                             |
| ional |        |                      |                             |
| Pola  |        |                      |                             |
| r-orb |        |                      |                             |
| iting |        |                      |                             |
| O     |        |                      |                             |
| perat |        |                      |                             |
| ional |        |                      |                             |
| Env   |        |                      |                             |
| ironm |        |                      |                             |
| ental |        |                      |                             |
| Sate  |        |                      |                             |
| llite |        |                      |                             |
| S     |        |                      |                             |
| ystem |        |                      |                             |
| (NP   |        |                      |                             |
| OESS) |        |                      |                             |
| P     |        |                      |                             |
| repar |        |                      |                             |
| atory |        |                      |                             |
| Pr    |        |                      |                             |
| oject |        |                      |                             |
| (NPP) |        |                      |                             |
| Sc    |        |                      |                             |
| ience |        |                      |                             |
| Data  |        |                      |                             |
| Se    |        |                      |                             |
| gment |        |                      |                             |
| Opera |        |                      |                             |
| tions |        |                      |                             |
| Co    |        |                      |                             |
| ncept |        |                      |                             |
|       |        |                      |                             |
| **DOC |        |                      |                             |
| UMENT |        |                      |                             |
| DA    |        |                      |                             |
| TE:** |        |                      |                             |
| TBS   |        |                      |                             |
+-------+--------+----------------------+-----------------------------+
| ISSUE | DATE   | PAGES AFFECTED       | DESCRIPTION                 |
+-------+--------+----------------------+-----------------------------+
| Ori   |        | All pages affected.  |                             |
| ginal |        |                      |                             |
+-------+--------+----------------------+-----------------------------+

EOS 420-CM-05 (4/92)

**DOCUMENT TITLE:** **RELEASE DATE:**

National Polar-orbiting Operational Environmental Satellite System

(NPOESS) Preparatory Project (NPP) Science Data Segment

Operations Concept

  ---------- ---------- -------- ---------- -------- ---------- -------- ----------
  **LIST OF                                                              
  AFFECTED                                                               
  PAGES**                                                                

  Page No.   Revision   Page No. Revision   Page No. Revision   Page No. Revision

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

                                                                         

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

EOS 420-CM-04 (4/92)

**TABLE OF CONTENTS**

[Section]{.underline} [Page]{.underline}

1.0 INTRODUCTION [1](#introduction)

1.1 Purpose [1](#purpose)

1.2 Scope [1](#scope)

1.3 Background [1](#background)

1.4 Document Overview [3](#document-overview)

1.4.1 Document Organization [3](#document-organization)

1.4.2 Compliance Documents [3](#compliance-documents)

1.4.3 Applicable Documents [3](#applicable-documents)

1.4.4 Reference Documents [4](#reference-documents)

2.0 SYSTEM DESCRIPTION [6](#system-description)

2.1 SDS Data Depository and Distribution Element (SD3E)
[8](#sds-data-depository-and-distribution-element-sd3e)

2.2 Project Science Office Element (PSOE)
[8](#project-science-office-element-psoe)

2.3 NPP Instrument Calibration Support Element (NICSE)
[8](#npp-instrument-calibration-support-element-nicse)

2.4 Product Evaluation and Analysis Tool Elements (PEATEs)
[8](#product-evaluation-and-analysis-tool-elements-peates)

2.5 Integration and Test System Element (I&TSE)
[9](#integration-and-test-system-element-itse)

2.6 External Interfaces [9](#external-interfaces)

2.6.1 Archive and Distribution Segment (ADS) Interface
[11](#archive-and-distribution-segment-ads-interface)

2.6.2 Interface Data Processing Segment (IDPS) Interface
[11](#interface-data-processing-segment-idps-interface)

2.6.3 Command, Control, and Communications Segment (C3S) Interface
[11](#command-control-and-communications-segment-c3s-interface)

2.6.4 Ancillary Data Providers (ADP) Interface
[12](#ancillary-data-providers-adp-interface)

2.6.5 Science Team (ST) Interface [12](#science-team-st-interface)

2.6.6 Climate Analysis Research Systems (CARS) Interface
[12](#climate-analysis-research-systems-cars-interface)

2.6.7 NPP/NPOESS Cal/Val Interface [13](#nppnpoess-calval-interface)

2.6.8 NPP Engineering Development Unit (EDU) eXchange Toolkit (NEXT)
Interface
[13](#npp-engineering-development-unit-edu-exchange-toolkit-next-interface)

2.6.9 NPOESS Ground Integrated Support Facility (ISF) Interface
[13](#npoess-ground-integrated-support-facility-isf-interface)

2.6.10 NPP/NPOESS Algorithm CCB (TBR) Interface
[13](#nppnpoess-algorithm-ccb-tbr-interface)

3.0 SYSTEM CONCEPT [15](#system-concept)

3.1 SDS Data Distribution and Depository Element (SD3E)
[18](#sds-data-distribution-and-depository-element-sd3e)

3.1.1 SD3E Ingest Data [20](#sd3e-ingest-data)

3.1.2 Verify Data Ingested [20](#verify-data-ingested)

3.1.3 Manage Data Requests [21](#manage-data-requests)

3.1.4 Manage Data [22](#manage-data)

3.2 Project Science Office Element (PSOE)
[22](#project-science-office-element-psoe-1)

3.3 NPP Instrument Calibration Support Element (NICSE)
[23](#npp-instrument-calibration-support-element-nicse-1)

3.3.1 NICSE Ingest Data [25](#nicse-ingest-data)

3.3.2 Radiometric Calibration [26](#radiometric-calibration)

3.3.3 Geometric Calibration [27](#geometric-calibration)

3.3.4 NICSE Export Data [28](#nicse-export-data)

3.4 Product Evaluation and Analysis Tool Elements (PEATEs)
[28](#product-evaluation-and-analysis-tool-elements-peates-1)

3.4.1 PEATEs Ingest Data [31](#peates-ingest-data)

3.4.2 Store/Catalog Data [31](#storecatalog-data)

3.4.3 Manage Software Configuration [32](#manage-software-configuration)

3.4.4 Process Science Data [32](#process-science-data)

3.4.5 PEATEs Export Data [34](#peates-export-data)

3.5 Integration and Test System Element (I&TSE)
[35](#integration-and-test-system-element-itse-1)

3.5.1 I&TSE Ingest Data [37](#itse-ingest-data)

3.5.2 Algorithm Development Area [37](#algorithm-development-area)

3.5.3 Mini-IDPS Production Area [37](#mini-idps-production-area)

3.5.4 Send to Out-bound site [38](#send-to-out-bound-site)

4.0 OPERATIONS CONCEPT [39](#operations-concept)

4.1 Operations Overview [39](#operations-overview)

4.2 Operations Scenarios [39](#operations-scenarios)

4.2.1 SDS Operations Scenarios [40](#sds-operations-scenarios)

4.2.1.1 SD3E Ingest and Manage (See section 3.1 for concept)
[41](#sd3e-ingest-and-manage-see-section-3.1-for-concept)

4.2.1.2 PEATEs Receive, Process, and Archive Data
[45](#peates-receive-process-and-archive-data)

4.2.1.3 PEATEs xDR Quality Assessment
[49](#peates-xdr-quality-assessment)

4.2.1.4 PEATEs SDR and EDR Algorithm Enhancements
[53](#peates-sdr-and-edr-algorithm-enhancements)

4.2.1.5 PEATEs Product Distribution [60](#peates-product-distribution)

4.2.1.6 NICSE Calibration and Validation Processing
[63](#nicse-calibration-and-validation-processing)

4.2.1.7 NICSE Calibration Service Request
[71](#nicse-calibration-service-request)

4.2.1.8 Anomaly Detection [76](#anomaly-detection)

4.2.1.9 PSOE Coordinate SDS Activities
[82](#psoe-coordinate-sds-activities)

Appendix A TABLE OF TBX [88](#appendix-a-table-of-tbx)

Appendix B ACRONYMS [90](#appendix-b-acronyms)

Appendix C GLOSSARY [93](#appendix-c-glossary)

Appendix D DATA DICTIONARY [97](#appendix-d-data-dictionary)

Appendix E NPOESS SERVICE REQUEST
[114](#appendix-e-npoess-service-request)

Appendix F NPOESS SERVICE RESPONSE
[115](#appendix-f-npoess-service-response)

Figures

[Figure]{.underline} [Page]{.underline}

Figure 1-1 NPP Mission Context Diagram [2](#__RefHeading___Toc511360079)

Figure 2‑1 SDS Conceptual Diagram 7

Figure 3.0-1 SDS Context Diagram [16](#__RefHeading___Toc511360081)

Figure 3.0-2 SDS Data Flow Diagram [17](#__RefHeading___Toc511360082)

Figure 3.1-1 SD3E Data Flow Diagram [19](#__RefHeading___Toc511360083)

Figure 3.3-1 NICSE Data Flow Diagram [24](#__RefHeading___Toc511360084)

Figure 3.4-1 PEATE Data Flow Diagram [30](#__RefHeading___Toc511360085)

Figure 3.5-1 I&TSE Data Flow Diagram [36](#__RefHeading___Toc511360086)

Figure 4.2.1.1-1 SD3E Ingest and Manage Scenario
[42](#__RefHeading___Toc511360087)

Figure 4.2.1.2-1 PEATEs Receive, Process, and Archive Data Scenario
[46](#__RefHeading___Toc511360088)

Figure 4.2.1.3-1 PEATEs xDR Quality Assessment Scenario
[50](#__RefHeading___Toc511360089)

Figure 4.2.1.4-1 PEATEs SDR and EDR Algorithm Enhancements Scenario Part
I [54](#__RefHeading___Toc511360090)

Figure 4.2.1.4-2 PEATEs SDR and EDR Algorithm Enhancements Scenario Part
II [55](#__RefHeading___Toc511360091)

Figure 4.2.1.5-1 PEATEs Product Distribution Scenario
[61](#__RefHeading___Toc511360092)

Figure 4.2.1.6-1 NICSE Calibration and Validation Processing Scenario
Part I [64](#__RefHeading___Toc511360093)

Figure 4.2.1.6-2 NICSE Calibration and Validation Processing Scenario
Part II [65](#__RefHeading___Toc511360094)

Figure 4.2.1.7-1 NICSE Calibration Service Request Scenario Part I
[72](#__RefHeading___Toc511360095)

Figure 4.2.1.7-1 NICSE Calibration Service Request Scenario Part II
[73](#__RefHeading___Toc511360096)

Figure 4.2.1.8-1 Anomaly Detection Scenario Part I
[77](#__RefHeading___Toc511360097)

Figure 4.2.1.8-1 Anomaly Detection Scenario Part II
[78](#__RefHeading___Toc511360098)

Figure 4.2.1.9-1 PSOE Coordinate SDS Activities Scenario
[83](#__RefHeading___Toc511360099)

# INTRODUCTION

## Purpose

The primary purpose of the NPP Science Data Segment (SDS) Operations
Concept (Conops) document is to provide a technical description of the
planned functions and operations of the SDS. The Conops presents a
functional model of the System based on high-level program guidance and
requirements and users needs. From the functional model, defined in a
set of data flow diagrams, a series of operational scenarios describe
sequences of activities for a selected set of mission events, thereby
ensuring all functions are identified and captured as mission level
requirements.

A secondary purpose of the Conops is to provide an overview of the SDS
System and its functions for the more casual reader. Therefore, several
sections offer a high-level description of the system without delving
into the lower level technical details necessary to the engineering
team.

## Scope

The scope of the Conops includes all functions associated with the SDS
as well as external entities that directly provide information to, or
receive information from, the SDS segment. Thus, the Conops encompasses
the acquisition of data by the SDS and processing of the data and making
them available to the users. Physical attributes and implementation
approaches are intentionally omitted to permit the architectural design
activities to take full advantage of potential implementation options.

## Background

The National Polar-orbiting Operational Environmental Satellite System
(NPOESS) Preparatory Project (NPP) is a joint mission between NASA and
the National Polar-orbiting Operational Environmental Satellite System
(NPOESS) Integrated Program Office (IPO). NPOESS is the U. S.
Government's future low-earth orbiting weather and environmental
satellite system, which combines Missions currently performed separately
by three agencies (NASA, DoD, and NOAA). NPP provides a "Bridge" between
current and future missions by providing pre-operational on-orbit test
and risk reduction for key NPOESS instruments and ground-based data
processing capabilities, while maintaining continuity of environmental
data used for long-term climate change research.

The four NPP Instruments are (1) the Visible Infrared Imaging Radiometer
Suite (VIIRS), which provides global observations of land, ocean and
atmospheric parameters; (2) the Advanced Technology Microwave Sounder
(ATMS); (3) the Cross-Track Infrared Sounder (CrIS), which will combine
infrared and microwave measurements to measure atmospheric temperature,
moisture, and pressure profiles; and (4) the Ozone Mapper/Profiler Suite
(OMPS), which monitors global ozone levels.

The purposes of the partnering organizations are:

-   To provide NASA with the continuation of a group of Global change
    observations initiated by the Earth Observing System (EOS) Terra,
    Aqua and Aura missions.

-   To provide the NPOESS operational community (both the DoD and the
    NOAA) with pre-operational risk reduction demonstration and
    validation for selected NPOESS instruments and algorithms, as well
    as ground processing.

The NPP mission provides remotely-sensed land, ocean, atmospheric, and
sounder data that will serve the meteorological and global climate
change to scientific communities while also providing risk reduction for
NPOESS. The NPP system is defined at the highest level in terms of
segments (Figure 1-1, NPP Mission Context Diagram), one of which is the
Science Data Segment (SDS). The NPP Science Data Segment is a prototype
element for discipline-based processing. In this case, the SDS is
intended to be a research tool and as such has no nominal operational
requirements. Operational requirements are met by the two segments of
the NPOESS/NPP data systems, IDPS and the Archive and Distribution
Segment (ADS). The role of the SDS is limited to assessing the quality
of the NPP xDRs (Raw Data Records (RDRs) , Sensor Data Records
(SDRs)/Temperature Data Records (TDRs), and Environmental Data Records
(EDRs)) for accomplishing climate Research and providing algorithm
enhancements when possible.

[]{#__RefHeading___Toc511360079 .anchor}Error: Reference source not
foundFigure 1-1 NPP Mission Context Diagram

## Document Overview

### Document Organization 

This document consists of four sections and six appendices. Section 1
provides the introduction to this document. Section 2 provides a
high-level overview of the SDS Segment. Section 3 provides the SDS
System concept as a series of functions, decomposed to an adequate level
of lower level functions sufficient to understand the system
capabilities and interfaces. Section 4 provides the SDS System
operations concept in the form of operational scenarios for selected
sequences or threads described in terms of the System concept. The
acronym and abbreviations list, the Data Dictionary, Glossary, Table of
TBXs, NPOESS Service Request and NPOESS Service Response are attached in
the appendices.

### Compliance Documents

The following documents have been identified as compliance documents in
the development and preparation of this document.

  ------- --------------------------------------------- ---------------------
  Ref. No Document Title                                Document No.

  C-1     NPOESS to NPOESS Preparatory Project (NPP)    NGST D34645
          Science Data Segment Interface Control        
          Document (ICD)                                

  C-2     NPP Mission Requirements Specification Volume GSFC429-99-02-03-R1
          1&2                                           

  C-3     NASA NPP Level 1 Requirements                 
  ------- --------------------------------------------- ---------------------

### Applicable Documents

The following documents have been identified as applicable documents in
the development and preparation of this document.

  -------- -------------------------------------------------- ---------------
  Ref. No  Document Title                                     Document No.

  A-1      Advanced Technology Microwave Sounder (ATMS)       GSFC
           Performance and Operations Specification (POS), ,  429-00-06-03,
           16.                                                CH-01

  A-2      Cross-Track Infrared Sounder (CrIS) Sensor         ITT Document
           Specification                                      8179802

  A-3      NASA Procedure and Guideline: Security of          NPG 2810.1, 26
           Information Technology                             

  A-4      Performance Specification, Mission Specification   EM17-0011
           for the OMPS                                       

  A-5      National Polar-orbiting Operational Environmental  GSFC
           Satellite System (NPOESS) Preparatory Project      429-00-03-02,
           (NPP) NASA Calibration/Validation Plan             

  A-6      Visible/Infrared Imager/Radiometer Suite (VIIRS)   EM17-0001
           Sensor Requirements Document (SRD) for National    
           Polar-orbiting Operational Environmental Satellite 
           System (NPOESS) Spacecraft and Sensors             
  -------- -------------------------------------------------- ---------------

### Reference Documents

The following documents have been used as reference information in the
development and preparation of this document.

  -------- ---------------------------------------------- ----------------
  Ref No.  Document Title                                 Document No.

  R-1      National Polar-orbiting Operational            GSFC
           Environmental Satellite System (NPOESS)        429-99-02-02
           Preparatory Project (NPP) Mission System and   Original, 11
           Operations Concept                             

  R-2      NPOESS Common Data Format Control Book --      NGST D34862-06
           External Volume VI -- Ancillary Data,          
           Messages, and Reports                          

  R-3      National Polar-orbiting Operational            GSFC
           Environmental Satellite System (NPOESS)        429-03-02-07
           Preparatory Project (NPP) System Integration   
           and Test (SI&T) Plan                           

  R-4      Research Announcement: NPP Science Team For    OMB Approval #:
           CLIMATE DATA Records, 31 March 2003.           2700-0087
  -------- ---------------------------------------------- ----------------

**THIS PAGE INTENTIONALLY LEFT BLANK**

# SYSTEM DESCRIPTION

The Science Data Segment (SDS) principally provides the capabilities to
assess and verify the quality of NPP products identified as Raw Data
Records (RDRs), Sensor Data Records (SDRs), Environmental Data Records
(EDRs), and Temperature Data Records (TDRs). The SDS is composed of the
SDS Data Distribution and Depository Element (SD3E), the Integration and
Test System Element (I&TSE), the Project Science Office Element (PSOE),
the NPP Instrument Calibration Support Element (NICSE), and five Product
Evaluation and Analysis Tools Elements (PEATEs) for each of the
following disciplines: Land, Ocean, Atmosphere, Ozone, and Sounder. The
SDS interfaces with the Interface Data Processing Segment (IDPS), the
Archive and Distribution Segment (ADS), the Command, Control, and
Communications Segment (C3S), other Ancillary Data Providers (ADP), the
Science Team (ST), the NPP Engineering development unit eXchange Toolkit
(NEXT) system, the NPP/NPOESS Algorithm CCB (TBR), and the NPOESS ground
Integrated Support Facility (ISF) as illustrated in Figure 2-1 and
Figure 2-2. The PEATEs are intended to be components of larger
organizations referred to as Climate Analysis Research Systems (CARS).

As of the writing of this document, the NPP/NPOESS Cal/Val System and
the CARS have not been fully defined for the NPP SDS to interface.

The following Level 1 Requirements are considered key SDS design
drivers:

-   The SDS is intended to be a research tool and as such has no
    operational requirements.

-   The role of the NPP SDS is limited to assess the quality of the NPP
    EDRs for accomplishing climate research.

-   The SDS shall be designed with the assumption that the operational
    IPO IDPS generated NPP EDRs do not require reprocessing or
    re-computation in order to support climate research needs.
    Consequently, the SDS will not be designed to routinely generate
    climate data products which require long-term archival in the ADS.

-   The SDS shall acquire RDRs, SDRs and EDRs from the ADS.

-   In developing the SDS, the Project shall assume that EDRs produced
    by the IDPS are climate quality and put in place the capability to
    test that hypothesis in order to contribute to improving the quality
    of future EDRs. The SDS shall provide suggested algorithm
    improvements to the IDPS.

-   The SDS shall use a fully distributed interoperable architecture,
    with 5 (nominally) functionally independent elements (Climate
    Analysis Research System or CARS), organized around key EDRs
    (atmospheric sounding products, ocean products, land products, ozone
    products and atmospheric composition) in support of the ESE Science
    Focus Areas (Atmospheric Composition, Climate Change,
    Carbon/Ecosystems, Solid Earth, Weather, Water/Energy Cycle).

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

Figure 2‑1 SDS Conceptual Diagram

## SDS Data Depository and Distribution Element (SD3E) 

The SD3E performs data acquisition, temporary storage and distribution.
The sources of these data are the IDPS and the ADS. The SD3E performs
all necessary data acquisition protocols and procedures for nominal data
reception and for anomaly resolution according to appropriate Interface
Control Documents with the IDPS and the ADS. The SD3E makes these data
accessible to all SDS internal elements in particular to the five PEATEs
and the NICSE. The SD3E also includes electronic network connectivity to
the ADS and the IDPS with sufficient bandwidth (including adequate
overhead margin for network protocols and for recovery from system
outages) to support data transfer from these sites. The SD3E has no data
processing capabilities. It is strictly a central system dedicated to
storing and forwarding data to the five PEATEs and NICSE. The SD3E
provides local storage for a minimum of 32 days of acquired data. The
acquired data products include xDRs, operational calibration products,
operational algorithms and source codes, and ancillary data.

## Project Science Office Element (PSOE)

The PSOE provides management direction as well as mission and science
guidance to the SDS and reviews algorithm and calibration
recommendations prior to submitting them to the NPP/NPOESS Algorithm CCB
(TBR).

## NPP Instrument Calibration Support Element (NICSE)

The NICSE is responsible for assessing and validating pre-launch and
post-launch radiometric and geometric calibration and characterization
of VIIRS instrument data. The NICSE ingests the xDRs, the operational
calibration look-up table (LUT) updates, and the operational calibration
software updates from the SD3E. Additionally, NICSE will extract
engineering data sets from the C3S. The NICSE will evaluate and, if
necessary, provide recommendations for enhancements of calibration
software and look-up tables (LUTs). The recommended calibration
algorithms and LUTs will be tested in the PEATEs environment before
being submitted to the PSOE for further review.

## Product Evaluation and Analysis Tool Elements (PEATEs)

The SDS Product Evaluation and Analysis Tool Elements include the Ozone
PEATE, Atmosphere PEATE, Land PEATE, Ocean PEATE, and Sounder PEATE.
Each system extracts the data of interest into its respective systems
for xDR quality evaluation, selected subset processing, and algorithm
enhancements. Optionally, the PEATEs may interface with the I&TSE in
order to further validate the performance of the recommended algorithm
enhancement. The PEATEs that use VIIRS data also coordinate calibration
evaluation and validation with the NICSE and submit algorithm and
calibration enhancements and recommendations to PSOE. PEATEs receive
ancillary data, operational calibration updates, and algorithm source
code for generation of data products from the external ADS. The PEATEs
will work closely with the ST to achieve their objectives.

Ozone PEATE will provide support in assessing and validating pre-launch
and post-launch radiometric calibration and characterization of OMPS
instrument data.

Sounder PEATE will provide support in assessing and validating
pre-launch and post-launch radiometric calibration and characterization
of (ATMS and CrIS) instrument data (TBD).

## Integration and Test System Element (I&TSE)

The I&TSE will be available for interactive access by the PEATEs and
Science Team (ST) analysts. It facilitates access to a smaller scale
IDPS production for algorithm enhancement testing, Intermediate Product
(IP) generation, algorithm performance demonstration, and ad-hoc data
processing requests. Nominally, PEATEs or NICSE analysts will connect
into the I&TSE and transfer their data sets of interest, incorporate
their algorithm software changes, and initiate processing. Upon
completion the analysts will transfer their results back to their own
systems if needed. Support will be provided by I&TSE for converting and
running algorithms (TBR).

##  {#section .unnumbered}

## External Interfaces

The external interfaces are those entities that are outside of the
domain of the SDS, but are required for the SDS to meet its objectives.
The external interfaces, as shown in Figure 2-2, provide information to
the SDS and/or receive information from the SDS. The context level
diagram as illustrated in Figure 2-2 shows the SDS contained within a
the middle box and all external entities as outer boxes. The SDS
interfaces with the Interface Data Processing Segment (IDPS), the
Archive and Distribution Segment (ADS), the Command, Control, and
Communication Segment (C3S), other Ancillary Data Providers, the Science
Team (ST), the NPP Engineering Development Unit (EDU) eXchange Toolkit
(NEXT) system, the NPP/NPOESS Algorithm CCB (TBR), the NPOESS ground
Instrument Support Function (ISF), and the Climate Analysis Research
Systems (CARS). The following subsections describe more details on the
external interfaces.

![](media/image5.pct)Figure 2-2 SDS Context Diagram

### Archive and Distribution Segment (ADS) Interface 

The ADS is the Long-Term Archive(LTA) for the NPP mission. The ADS
receives the RDRs, SDRs, TDRs, EDRs, and other related data products
such as ancillary data, auxiliary data, calibration products and
operational source code from the IDPS. All of these data are archived,
as are the associated metadata, upon which users may search and order.
Upon request, data products are distributed to users through the ADS
public interface. The SDS uses the ADS as the primary source for all
data except the RDRs and Telemetry in Engineering Units (TEUs). The SDS
is a "high-priority" user of the ADS public interface. The ADS utilizes
the Comprehensive Large Array-data Stewardship System (CLASS). CLASS is
the National Oceanic and Atmospheric Administration's (NOAA's) mechanism
for safely and securely archiving large-volume environmental data and
making these data available to researchers, commercial users, and the
public.

### Interface Data Processing Segment (IDPS) Interface

The IDPS provides the interface to ingest raw sensor data. The artifacts
from the communication routing are removed, providing RDRs which are
subsequently processed to create SDRs, TDRs and EDRs. Production of EDRs
includes production of intermediate-level processed data files, as
needed. For the NPP Mission, the xDRs (RDRs, SDRs, TDRs and EDRs) and
selected Intermediate Products (IPs) are made available to two
meteorological Centrals for use in application specific weather-related
predictions. The two Centrals are:

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

-   Air Force Weather Agency (AFWA)

The data records are provided to the Centrals on a time-critical basis
(three hours from sensor acquisition). Additionally, the IDPS also
provides an operational level of calibration and validation of the
algorithms and the performance of the payload sensors. The RDRs, SDRs,
TDRs and EDRs are forwarded to the Archive and Distribution Segment
(ADS) for archiving and broader user access.

The SDS interfaces with the IDPS nominally for RDR acquisition as
specified in NPOESS to NPOESS Preparatory Project (NPP) Science Data
Segment (SDS) Interface Control Document (ICD) (See reference C-1).

### Command, Control, and Communications Segment (C3S) Interface

The Command, Control, and Communications Segment (C3S) provides the NPP
satellite operations capabilities, communication, and routing of mission
data to the ground receive stations. The C3S also provides for the
overall mission management and coordination of joint program operations
needs. Mission Management represents both the operational and scientific
communities.

The satellite operations capabilities include the mission planning and
scheduling, resource coordination, command loads building, verifying and
sending satellite commands, real-time attitude determination, and
satellite databases maintenance. Off-line activities include satellite
simulation, flight software maintenance, mission trending and analysis,
and, as necessary, anomaly resolution. The communication routing
functions include activities associated with the planning, scheduling,
and coordination of network communication links. The polar ground
station coordination and intra-segment communication services are also
provided.

The SDS interfaces with the C3S Mission Management Center Web Server for
telemetry engineering data acquisition as specified in NPOESS to NPOESS
Preparatory Project (NPP) Science Data Segment (SDS) Interface Control
Document (ICD) (See reference C-1). The SDS may also request services
from C3S by generating instrument service requests or engineering
service requests.

### Ancillary Data Providers (ADP) Interface

The SDS may generate EDRs locally with ancillary data other than the
NPOESS official Ancillary Data Sets. Ancillary Data are acquired from
outside of the NPP mission system and used to generate NPP products,
(e.g., NWP, DEMs). Other ancillary data may be used as an alternative to
official Ancillary Data. If SDS decides to exercise this option, it uses
this interface to obtain the alternate Ancillary Data sets from
Ancillary Data Providers (ADP). Some sources for these products are the
NOAA/NESDIS, National Aeronautics and Space Administration (NASA),
United States Geological Survey (USGS), Jet Propulsion Laboratory (JPL),
NOAA Space Environment Center, and United States Naval Oceanographic
Office (USNAVO).

### Science Team (ST) Interface

The SDS draws on the scientific expertise of the Science Team (ST),
NASA-funded investigators from the broader science community, identified
as contributors to the SDS by NASA HQ and the NPP Project Scientist. The
individuals in this pool of investigators work closely with one or more
PEATEs on the basis of discipline affinity. As algorithm errors are
uncovered, or enhancements generated, the Science Team interfaces with
the PEATEs and PSOE. The PEATEs are the primary facilities for data
analyses and evaluations. The PEATE will provide access to data and
tools for ad-hoc analysis of xDRs and algorithms. The PEATEs process the
RDRs, creating higher-level products. The higher-level products are
comparable to the IDPS SDR product, but are generated using algorithms
provided by the ST. The ST also provides support to validate NPP science
calibration algorithms and LUTs in coordination with NICSE.

### Climate Analysis Research Systems (CARS) Interface

The SDS relies on the processing environment of a distributed and
heterogeneous set of discipline-based organizations referred to as CARS.
Nominally, the CARS will interface with the NPP Science Team/Science
Investigators through the PEATEs according to a set of operations
procedures directed toward evaluation and enhancement of the NPP data
products. In light of not having the fully defined CARS fully defined,
the PEATEs have been selected based on other factors.

### NPP/NPOESS Cal/Val Interface

As of the writing of this document, the NPP/NPOESS Cal/Val System has
not been defined for the NPP SDS to interface.

### NPP Engineering Development Unit (EDU) eXchange Toolkit (NEXT) Interface

The NEXT serves as the NPP Pre-Launch repository of Government held data
for distribution to the NPP Government user teams (NASA, NOAA/NESDIS,
and AFWA) and NGST. It supports the pre-launch scientific
characterization and calibration for the ATMS, CrIS, VIIRS, and OMPS
Engineering Development Units (EDUs) and Flight Units. It serves as a
repository for NPP instrument algorithms (SDRs, EDRs) and support files
(ancillary data, LUTs). It also provides the ability to receive,
catalog, store and distribute data and algorithms to authorized users.

### NPOESS Ground Integrated Support Facility (ISF) Interface

The Ground Integrated Support Facility provides immediate technical
support to the NPOESS mission operation in any of the following five
areas of expertise and assistance: nominal operations, anomaly
resolution, Launch, Early Orbit, and Activation (LEO&A), NPOESS System
Modification, and Intensive Calibration and Validation activity. In
reference to the SDS, the NPOESS Ground ISF will package and ship all
the necessary IDPS operational software to run the on I&TSE.

### NPP/NPOESS Algorithm CCB (TBR) Interface

The NPP/NPOESS Algorithm CCB (TBR) receives science algorithm
improvement recommendations from the PSOE. It is the responsibility of
the NPP/NPOESS Algorithm CCB (TBR) to process such recommendations for
approval in operational usage.

**THIS PAGE INTENTIONALLY LEFT BLANK**

# SYSTEM CONCEPT

A context level data flow diagram for the SDS with external interfaces
is provided in Figure 3.0-1, SDS Context Diagram. The SDS interfaces
with the Interface Data Processing Segment (IDPS), the Archive and
Distribution Segment (ADS), the Command, Control, and Communications
Segment (C3S), other Ancillary Data Providers (ADP), the Science Team
(ST), the NPP Engineering development unit eXchange Toolkit (NEXT)
system, the NPP/NPOESS Algorithm CCB (TBR), and the NPOESS ground
Integrated Support Facility (ISF).

A level one data flow diagram for the SDS components is provided in
Figure 3.0-2. This element-based diagram depicts the five elements of
the SDS---the SDS Data Distribution and Depository Element (SD3E), the
Integration and Test System Element (I&TSE), the Project Science Office
Element (PSOE), the NPP Instrument Calibration Support Element (NICSE),
and the Product Evaluation and Analysis Tools Elements (PEATEs)---along
with their relationships with each other and with external entities. The
single PEATE node in the diagram represents the core capabilities of the
five PEATEs. The NPP Engineering Development Unit (EDU) eXchange Toolkit
(NEXT) system serves as the NPP Pre-Launch repository of Government held
data for distribution to the NPP Government user teams (NASA,
NOAA/NESDIS, AFWA) and Northrop Grumman Space & Mission Systems Corp.
Space Technology (NGST). It supports the pre-launch scientific
characterization and calibration for the ATMS, CrIS, VIIRS, and OMPS
EDUs and Flight Units. Each element is functionally described by a set
of Data Flow Diagrams (DFDs) and textual descriptions. The DFDs are
arranged in a hierarchical format to show a structured, top-down view of
the end-to-end system. Element descriptions and their respective data
flow diagrams are provided in the following sections.

To simplify the SDS DFD naming scheme, the data flow names do not show
accurate product names as described by the ICDs. The naming convention
has been simplified on the diagrams to show the source and destination.
Descriptions of the data flow contents are provided in the data
dictionary. See Appendix D.

Throughout the document, the italicized words in the text descriptions
represent the data flow names used in the diagrams.

[]{#__RefHeading___Toc511360081
.anchor}![](media/image6.pct){width="8.93125in"
height="5.627777777777778in"}Figure 3.0-1 SDS Context Diagram

[]{#__RefHeading___Toc511360082
.anchor}![](media/image7.pct){width="8.93125in"
height="5.877777777777778in"}Figure 3.0-2 SDS Data Flow Diagram

## SDS Data Distribution and Depository Element (SD3E)

Input: SD3E-IDPS response, SD3E-ADS response, NICSE Requested listings,
PEATEs Requested listings, SD3E management direction

The SD3E supports the function for data acquisition and temporary
storage of NPP data delivered to the SDS. The sources of these data are
the IDPS and the ADS. The SD3E supports all necessary data acquisition
protocols and procedures for nominal data reception and for anomaly
resolution according to appropriate IDPS and CLASS Interface Control
Documents. The SD3E also makes these data accessible to PEATEs and
NICSE. The SD3E component provides network connectivity to the NOAA/ADS
and NESDIS/IDPS with sufficient bandwidth (including adequate overhead
margin for network protocols and for recovery from system outages) to
support transfer of the data from these sites. This component also
provides local storage for a minimum of 32 days of acquired data. The
SD3E DFD is provided in Figure 3.1-1.

Output: SD3E-IDPS product queries, SD3E-ADS product queries, NICSE
Requested listings response, PEATEs Requested listings response,
SD3E-PEATEs operational algorithms, SD3E-PEATEs science data, SD3E-NICSE
xDRs, SD3E-NICSE calibration product, SD3E-NICSE operational algorithms,
SD3E management reports.

[]{#__RefHeading___Toc511360083
.anchor}![](media/image8.pct){width="8.93125in"
height="5.752777777777778in"}Figure 3.1-1 SD3E Data Flow Diagram

### SD3E Ingest Data 

Input: SD3E-IDPS response, SD3E-ADS response, NPOESS Data Product Query
and Requests, ADS data queries and requests

Process: The SD3E Ingest Data function serves as the primary interface
for querying, requesting, and ingesting data products from the external
segments, the IDPS and the ADS. This function receives the IDPS product
subscription, *NPOESS Data Product Query and Requests*, and the ADS
product subscription, the *ADS data queries and requests* from the
Manage Data Request function. SD3E Ingest Data then sends the IDPS
product subscription, *SD3E-IDPS product queries*, and the ADS product
subscription, *SD3E-ADS product queries,* to the corresponding segment.
The IDPS and ADS data products may be ordered as aggregates, data are
ordered as aggregates by time or by orbit. SD3E specifies this in the
product subscription.

The SD3E Ingest Data function receives a status, the *SD3E-IDPS
response* and the *SD3E-ADS response,* as a result of submitting the
product subscription. The status indicates whether or not the data
request has been accepted. If IDPS accepts the data request, then the
*IDPS data delivery report* is sent. The *IDPS RDR products* are sent to
the directory location specified by the Manage Data Requests function in
the product subscription. If ADS accepts the data request, an *ADS data
query and request status* is provided. This status includes a delivery
notice/report with instructions to the SD3E Ingest Data function on how
to retrieve the requested products. The *ADS Data*, *SD3E Ingested ADS
Data*, includes the xDRs, Intermediate Products (IPs), ancillary data,
operational algorithms, and calibration product.

The SD3E Ingest Data function then transfers the acquired data (*IDPS
data delivery report, IDPS RDR products, and SD3E Ingested ADS Data*) to
the Verify Data Ingested function. Statuses as a result of the IDPS or
ADS data request are provided to the Manage Data Request function. The
*NPOESS Data Product Query and Request status* from IDPS and the *ADS
data query and request status* from ADS provide status regarding the
data transaction.

If SD3E Ingest Data receives either an IDPS or an ADS ad-hoc request
from the Manage Data Requests, it sends the request to the appropriate
segment.

Output: SD3E-IDPS product queries, SD3E-ADS product queries, ADS query
and request status, NPOESS Data Product Query and Request status, IDPS
data delivery reports, IDPS RDR products, SD3E Ingested ADS Data

### Verify Data Ingested 

Input: IDPS data delivery reports, IDPS RDR products, SD3E Ingested ADS
Data

Process: The Verify Data Ingested function parses the data transmission
log to verify if all of the data products received match the data
expected. This function uses a checksum or a digital signature to verify
completeness of the acquired data. The acquired data includes the *IDPS
data delivery reports*, *IDPS RDR products*, and the data *SD3E
Ingested* from *ADS Data*. In the event this function unsuccessfully
verifies the products received, it sends an *Incomplete data status* to
Manage Data Request in order to generate ad-hoc requests for
retransmission of the bad data files. The *Verified data* are stored in
the In-bound store.

Output: Incomplete data status, Verified data

### Manage Data Requests 

Input: PEATEs Requested listings, NICSE Requested listings, Data product
listings, Incomplete data status, NPOESS Data Product Query and Request
status, ADS query and request status

Process: The Manage Data Request is responsible for managing data
requests submitted by PEATEs or NICSE by generating product
subscriptions and/or ad-hoc requests to the appropriate external
segment. The PEATEs or the NICSE may submit *Requested listings*. This
listing may be a listing of files for SD3E to ingest, a list of data
files with problems, or a request to check the SD3E for the current
products residing in the Out-bound data store.

If the request is for a listing of the current files in the SD3E
Out-bound data store, then the *Data listing request* is sent to the
Manage Data function. As a result of the request, it receives the *Data
product listings,* a list of files currently in the SD3E Out-bound data
store from the Manage Data function. It sends the results to the data
requester.

If the request is a list of data files for the SD3E to ingest, Manage
Data Requests determines the segment to retrieve the requested data from
and generates the corresponding IDPS and/or ADS product subscriptions.
The IDPS product subscription is sent to the SD3E Ingest Data function
as the *NPOESS Data Product Query and Requests*. The ADS product
subscription is sent to the SD3E Ingest Data function as the *ADS data
queries and requests*. Statuses from the external segment, as a result
of submitting the product subscriptions, are provided by the SD3E Ingest
Data function. The IDPS status, *NPOESS Data Product Query and Request
status*, and the ADS status, *ADS query and request status* provide a
status with regards to the data transaction.

If the request is a list of data files with problems, Manage Data
Requests determines the segment the problem data files are from and
generates an ad-hoc request to the appropriate segment. The ad-hoc
requests are sent to the SD3E Ingest Data function to send to the
external segment. Additionally, if Manage Data Requests receives an
*Incomplete data status* from the Verify Data Ingested function, it
automatically generates an ad-hoc request to the appropriate segment for
retransmission of the files in question.

The status, as a result of the requests, is provided to the PEATEs and
the NICSE. A *PEATEs Requested listing response* is returned to the
PEATEs. A *NICSE Requested listing response* is returned to the NICSE.

Manage Data Requests is also responsible for scheduling with the
requester when to transfer the products, logging all data transactions,
and updating the internal SD3E ingest status report.

Output: PEATEs Requested listing response, NICSE Requested listing
response, ADS data queries and request, NPOESS Data Product Query and
Requests, Data listing request

### Manage Data

Input: In-bound Data, Data listing request, SD3E management direction,
Product listings

Process: Once data becomes available in the In-bound store, the Manage
Data function moves the *In-bound Data* from the In-bound store to the
Out-bound store. This function manages these data by storing them in
groups that can be logically isolated from each other. All products
stored are logged. These products include the xDRs, all available IPs,
calibration product, operational algorithms, and ancillary data. This
function refers to these products collectively as the *SD3E Out-bound
data*.

Manage Data receives a *Data listing request* from the Manage Data
Request function. This data listing is a request for a list of the
current data products residing in the Out-bound store. Manage Data
Requests checks the Out-bound store for the *Product listings*. It then
sends a list of current data products in the Out-bound store, as the
*Data Product listings*, to the Manage Data Request.

Manage Data makes the data in the Out-bound store available to all other
SDS elements. The PEATEs retrieve the science data, *SD3E-PEATEs science
data*, and the operational algorithms, *SD3E-PEATEs operational
algorithms*. The *SD3E-PEATEs science data* includes the xDRs, IPs,
calibration product, and ancillary data. The NICSE retrieves the xDRs
(*SD3E-NICSE xDRs*), calibration product (*SD3E-NICSE calibration
product*), and the operational algorithms (*SD3E-NICSE operational
algorithms*) from the Out-bound store. The I&TSE retrieves the available
RDRs or SDRs, *SD3E-I&TSE xDRs*.

Manage Data is also responsible for removing data products that are
older than 32 days (i.e. xDRs) and other files (i.e. IPs) that are older
than five days from the Out-bound store.

This function also receives management directions from the PSOE. These
*SD3E management directions* provide guidelines to the SD3E on science
data product ingest and volume priorities. Manage Data will provide the
PSOE with *SD3E management reports* regarding the status of SD3E.

Output: SD3E-PEATEs operational algorithms, SD3E-PEATEs science data,
SD3E-NICSE xDRs, SD3E-NICSE calibration product, SD3E-NICSE operational
algorithms, SD3E management reports, SD3E Out-bound Data, Data product
listings, SD3E-I&TSE xDRs

## Project Science Office Element (PSOE)

Input: NICSE cal LUT recommendations, NICSE cal software
recommendations, SD3E management reports, NICSE management reports,
PEATEs management reports, PEATEs Instrument service request, PEATES
science algo imp rec, PEATES status, xDR eval results, I&TSE management
reports, I&TSE status, I&TSE science algo imp pkg, PSOE-C3S response,
ST-PSOE recommendations, NICSE-PSOE instrument service request

The PSOE provides management direction as well as mission and science
guidance to all elements of the SDS and reviews algorithm and
calibration recommendations prior to submitting them to NPP/NPOESS
Algorithm CCB (TBR). The project science office serves as the interface
to the C3S for instrument service requests from the SDS elements and to
forward calibration enhancement recommendations.

Output: PSOE science algo imp rec, PSOE-C3S instrument service request,
NICSE management direction, I&TSE management direction, PEATEs
management direction, SD3E management direction, ST-PSOE feedback,
NICSE-PSOE response

## NPP Instrument Calibration Support Element (NICSE) 

Input: NICSE-C3S response, NICSE-ADS response, NICSE-ADP response,
NICSE-PEATEs quality control response, Result of cal evaluation,
NICSE-NEXT response, SD3E-NICSE calibration product, SD3E-NICSE xDRs,
SD3E-NICSE operational algorithms, NICSE management direction,
NICSE-PSOE response

The NICSE's responsibilities include independently assessing and
validating pre-launch and post-launch radiometric and geometric
calibration and characterization of NPP VIIRS instrument data. The NICSE
ingests the xDRs, the calibration product, and the operational
algorithms from SD3E. Additionally, NICSE will acquire engineering data
sets from C3S. The NICSE will evaluate and, if necessary, provide
recommendations for enhancements of calibration software and look-up
tables (LUTs). The recommended calibration algorithms and LUTs may be
tested in the PEATEs environment to validate changes before being
submitted to the PSOE for further review. The NICSE may also request
data products from the ADS, if SD3E no longer has the data in storage,
and request alternate ancillary data from the ADP. The NICSE DFD is
shown in Figure 3.3-1.

The Ozone PEATE is responsible for independently assessing and
validating pre-launch and post-launch radiometric and geometric
calibration and characterization of NPP OMPS instrument data.

The Sounder PEATE is responsible for independently assessing and
validating pre-launch and post-launch radiometric and geometric
calibration and characterization of NPP ATMS and CrIS instrument data.

Output: NICSE-C3S engineering data request, NICSE-ADS product queries,
NICSE-ADP product queries, NICSE cal LUT recommendations, NICSE cal
software recommendations, NICSE-PEATEs quality control request, NICSE
cal LUT updates, NICSE cal software updates, NICSE-NEXT request,
NICSE-PSOE instrument service request, NICSE management report, NICSE
Requested listings

[]{#__RefHeading___Toc511360084
.anchor}![](media/image9.pct){width="8.80625in"
height="5.877777777777778in"}Figure 3.3-1 NICSE Data Flow Diagram

### NICSE Ingest Data 

Input: NICSE-C3S response, NICSE-ADP response, NICSE-ADS response,
NICSE-NEXT response, Result of cal evaluation, NICSE-PEATEs quality
control response, NICSE-PSOE response, NICSE management direction,
SD3E-NICSE calibration product, SD3E-NICSE xDRs, SD3E-NICSE operational
algorithms, NICSE Requested listings, Rad Quality control and response,
Geo Quality control and response

Process: The NICSE Ingest Data function serves as the interface to
external elements for data ingests, to all other SDS elements for data
transfers, to the PEATEs for calibration data quality control, and to
make the ingested data available to the Radiometric and Geometric
Calibration functions.

The NICSE Ingest Data determines the data products to ingest based on
the needs of the Radiometric and Geometric Calibration functions. NICSE
Ingest Data submits a list of files, *NICSE Requested listings*, for
SD3E to ingest from the external segment. Once these products are
available in the SD3E, NICSE Ingest Data retrieves xDRs (*SD3E-NICSE
xDRs*), calibration product (*SD3E-NICSE calibration product*), and the
operational algorithms (*SD3E-NICSE operational algorithms*). This
function refers to the data products from SD3E as the *NICSE Ingested
SD3E Data*. If the SD3E no longer has the requested data available, then
the NICSE Ingest Data generates an ad-hoc request, *NICSE-ADS product
queries*, to the ADS for the data. If ADS accepts the request, ADS sends
a delivery notice/report as a part of their response. This *NICSE-ADS
response* includes instructions on how to retrieve the requested
products. Once all products have been retrieved, NICSE performs a basic
level of validation on the acquired data by determining if the data
received matches the data expected. If NICSE Ingest Data finds problems
with data files retrieved by the SD3E, they will request those files in
question to be retransmitted, by sending a *NICSE Requested listings* to
SD3E.

NICSE Ingest Data is also responsible for ingesting products from the
ADP, C3S, and the NEXT. If alternate ancillary data are needed, this
function generates a data transfer request, *NICSE-ADP Transfer
Request*, and sends it to ADP for the *ADP Data*. The *ADP Data* is the
*Earth polar motion* needed for Geometric Calibration. If engineering
data are needed, this function submits a request to C3S, *NICSE-C3S
engineering data request*, for data such as the Two Line Elements (TLE)
sets. If instrument services are needed, this function submits an
instrument service request, *NICSE-PSOE instrument service request*, to
the PSOE. If *Pre-launch algorithms and test data* and *SDR
algorithm/source code* are needed, this function logs onto the NEXT
system and retrieves the data. From PEATEs, this function receives the
*Results of calibration evaluation*. These results are based on the
PEATEs evaluation of the NICSE's recommended calibration LUT and
software updates. The *Results of calibration evaluation (Rad cal eval
results)*, *RDR*, *Calibration RDRs (TBD)*, *SDR algorithm/source code*,
*Pre-launch algorithm and test data*, and the *NICSE* *Ingested SD3E
Data* are provided to the Radiometric Calibration function. The *Results
of calibration evaluation (Geo cal eval results)*, *RDR*, *VIIRS
Geolocation SDR*, *EDR*, and the *Earth polar motion* are provided to
the Geometric Calibration function.

The NICSE Ingest Data function will also provide requests and responses
between the PEATEs and the NICSE functions for calibration data quality
control. The NICSE calibration functions send their corresponding
*Geometric Quality control request* and *Radiometric Quality control
request* to the NICSE Ingest Data function. This function then sends the
request, *NICSE-PEATEs quality control and response*, to the PEATEs.

The NICSE Ingest Data also receives management directions from the PSOE.
These *NICSE management directions* provide guidelines to the NICSE on
processing priorities, schedules, etc... NICSE Ingest Data will provide
the PSOE with *NICSE management reports* regarding their processing
status.

Output: NICSE-C3S engineering data request, NICSE-ADP product queries,
NICSE-ADS product queries, NICSE-NEXT request, NICSE-PEATEs quality
control request, NICSE-PSOE instrument service request, NICSE management
reports, Earth polar motion, EDR(Geometric), VIIRS Geolocation SDR, RDR
(Geometric), Geo cal eval results, NICSE-PEATEs quality control request,
NICSE Ingested SD3E Data, Pre-launch algo & test data, SDR
algorithm/source code, Calibration RDRs (TBD), RDR (Radiometric), Rad
cal eval results, NICSE Requested listings response, Rad quality control
request, Geo quality control request

### Radiometric Calibration

Input: NICSE Ingested SD3E Data, Pre-launch algo & test data, SDR
algorithm/source code, Calibration RDRs (TBD), RDR (Radiometric), Rad
cal eval results, Geo Cal Data Response, Rad Quality control response

Process: The Radiometric Calibration function assesses and validates
VIIRS pre-launch and post-launch calibration and characterization data.
This function receives the *Pre-launch algorithm and test data*, *SDR
algorithm/source code*, the *Calibration RDRs (TBD)*, *RDRs*, *NICSE
Ingested SD3E Data*, and the *Radiometric calibration evaluation
results* from the NICSE Ingest Data function. The algorithms are
designed because of an improvement, developed, and tested. For
pre-launch calibration and characterization, the following instrument's
characteristics will be evaluated:

-   Radiometric: SNR/NEdT, linearity, response dynamic range, etc.
    (including some on-site TV test data analysis support)

-   Relative spectral response (RSR) and center wavelengths

-   Response versus scan angle (RVS)

-   Polarization sensitivity for reflective solar band (RSB)

-   Solar diffuser (SD) BRDF and SD screen characterization for RSB

In addition, the following planned activity includes:

-   Key look-up tables (LUTs) validation and improvements.

The planned post-launch calibration and characterization activities
include:

-   Radiometric calibration from VIIRS on-board calibrators (solar
    diffusers (SD), solar diffuser stability monitor (SDSM), and black
    body (BB)).

-   SDR LUTs development, test, and updates

-   Lunar calibration for RSB radiometric stability

-   SD screen vignetting function analysis for RSB

-   Analyzing calibration data sets collected during spacecraft
    maneuvers.

-   Assessing the impact of any artifacts discovered following the
    launch

-   Monitoring and performing long term trend analysis of the
    instruments characterizations and mission data,

The resulting *Radiometric calibration LUT updates* and *Radiometric
calibration software updates* are sent to the NICSE Export Data. The
Radiometric Calibration function may also submit a *Geometric
Calibration Data Request* to the Geometric Calibration function. The
Geometric Calibration function responds with providing the latest
*Geometric Calibration Data* for the RSB calibration. Additionally, this
function interfaces with the PEATEs through the NICSE Ingest Data
function for *Radiometric Quality control and response* of the
calibration data updates.

Output: Geo cal data request, Rad cal software updates, Rad cal LUT
updates, Rad Quality control request

### Geometric Calibration

Input: Earth polar motion, EDR (for Geometric), VIIRS Geolocation SDR,
RDR (for Geometric), Geo cal eval results, Geo Quality control request

Process: The Geometric Calibration ingests the *RDR*, *VIIRS Geolocation
SDR*, *EDR*, the *Geometric calibration evaluation results*, and the
*Earth polar motion* from the NICSE Ingest Data function. The Geometric
Calibration's responsibilities include providing updates to the
geometric calibration LUT and software as a result of:

> • Performing geometric characterization on selected data products to
> generate along track and across track calibration parameters,
>
> • Determining the instruments field angle knowledge and profiles
>
> • Assessing band-to-band registration
>
> • Providing ground control point matching algorithm and data to assess
> the mission data accuracy,
>
> • Assessing the impact of any artifacts discovered following the
> launch,
>
> • Monitoring and performing long term trend analysis of the
> instruments characterizations and mission data,
>
> • Verifying and running characterization algorithms, and
>
> • Determining the misalignment between the satellite navigation base
> reference and instrument lines of sight.

These *Geometric calibration LUT updates* and *Geometric calibration
software updates* are made available to the NICSE Export Data.
Additionally, this function provides a *Geometric Calibration Data
Response* to *Geometric Calibration Data Requests* from the Radiometric
Calibration function for geometric calibration data. Additionally, the
Geometric Calibration function interfaces with the PEATEs through the
NICSE Ingest Data function for *Geometric Quality control* *and
response* of the calibration data updates.

Output: Geo cal data response, Geo cal LUT updates, Geo cal software
updates, Geo Quality control request

### NICSE Export Data

Input: Rad cal LUT updates, Rad cal software updates, Geo cal LUT
updates, Geo cal software updates

Process: The NICSE Export Data function is responsible for making the
calibration LUT and software updates available to the PSOE and to the
PEATEs. The NICSE Export Data receives the *Radiometric calibration LUT
updates* and *Radiometric calibration software updates* from the
Radiometric Calibration function. It also receives the *Geometric
calibration LUT updates* and *Geometric calibration software updates*
from the Geometric Calibration function. The NICSE Export Data function
may submit the *NICSE calibration LUT updates* and the *NICSE
calibration software updates* to the PEATEs for evaluation. This
function may also send the *NICSE calibration LUT recommendations* and
the *NICSE calibration software recommendations* to the PSOE.

Output: NICSE cal LUT updates, NICSE cal software updates, NICSE cal
software recommendations, NICSE cal LUT recommendations

## Product Evaluation and Analysis Tool Elements (PEATEs)

Input: SD3E-PEATEs science data, PEATEs-ADS response, PEATEs-ADP
response, PEATEs-NEXT response, PEATES Requested listings response,
PEATES-C3S response, NICSE-PEATEs quality control request, SD3E-PEATEs
operational algorithms, PEATES management direction, ST algo src code
recommendations, ST ad-hoc processing requests, I&TSE algo status, NICSE
cal LUT updates, NICSE cal software updates, PEATES-PSOE response, ST
data requests

The SDS PEATEs are comprised of the Atmosphere PEATE, Land PEATE, Ocean
PEATE, Ozone PEATE, and Sounder PEATE. Each system acquires the data of
interest into their respective systems for xDR quality evaluation,
selected subset processing, and algorithm enhancement. Optionally, the
PEATEs may interface with the I&TSE in order to further validate the
performance of the recommended algorithm enhancements. The PEATEs also
coordinate calibration evaluation and validation with the NICSE and
submit algorithm and calibration enhancements and recommendations to
PSOE. It receives the ancillary data, the calibration product, and the
operational algorithms for generation of data products from the SD3E, or
from the external ADS segment, its secondary data source. The PEATEs
support the Science Team (ST) by providing resources for analyses and
evaluations of xDRs and algorithms. The Science Team coordinate
processing requests and provides suggested algorithm enhancement
requests to the PEATEs for development and implementation. A DFD
describing common PEATE functionalities is shown in Figure 3.4-1.

Output: PEATES Requested listings, PEATEs-PSOE instrument service
request, PEATES science algo imp rec, PEATEs status, xDR eval results,
PEATEs management report, PEATEs Science algorithm imp pre-pkg, ST data
request response, PEATEs-NEXT request, PEATEs-ADP product queries,
PEATEs-ADS product queries, ST science data pkg, PEATEs engineering data
request, NICSE-PEATEs quality control response, Result of cal evaluation

[]{#__RefHeading___Toc511360085
.anchor}![](media/image10.pct){width="8.93125in"
height="5.877777777777778in"}Figure 3.4-1 PEATE Data Flow Diagram

### PEATEs Ingest Data

Input: SD3E-PEATEs science data, PEATEs-ADS response, PEATEs-ADP
response, PEATEs-NEXT response, PEATEs Requested listing response,
PEATEs-C3S response

Process: The PEATEs Ingest Data function provides the capability to
ingest data from various external segments and SDS elements.
Additionally, it is responsible for performing a basic level of
validation on the acquired data products.

The PEATEs Ingest Data function submits a request to the SD3E for files
to ingest from the external segment, *a PEATEs Requested listings*. Once
the files become available in the SD3E, this function retrieves the
science data (*SD3E-PEATEs science data*). The science data includes the
xDRs, IPs, calibration product, and ancillary data. If the PEATEs Ingest
Data function determines that there are problems with specific data
files, they will submit a list of files to the SD3E to retransmit those
specific data files from the external segment. If the SD3E no longer has
the requested data available, the PEATEs Ingest Data generates an ad-hoc
request, *PEATEs-ADS ad-hoc request*, and submit it to the ADS. If ADS
accepts the request, it sends status, *PEATEs-ADS response*, with
instructions on how to retrieve the requested products.

If the PEATEs Ingest Data require the ancillary data products, then it
submits a data transfer request, *PEATEs-ADP Transfer Request*, to the
ADP. For Pre-launch algorithms and test data, this function logs onto
the NEXT system, submit a *PEATEs-NEXT request* for products, and
retrieves the requested data. If engineering data are needed, then an
engineering data request, *PEATEs engineering data request*, is
submitted to the C3S for reports such as the TLE sets.

The PEATEs Ingest Data function performs a basic level of validation on
all acquired data to determine that the data files received matches the
data files that are expected. If not, this function generates the
appropriate request to the external segment or to SD3E for the data.

The verified data are sent to the Store/Catalog function. The verified
data includes the *PEATEs Ingested SD3E Data, PEATEs Ingested ADS Data,
PEATEs Ingested ADP Data, Pre-launch algorithm and test data, and
Engineering data*. The PEATEs Ingest Data function opens and checks the
metadata files associated with the xDRs in order to provide a list of
cataloged data products that will be searchable by the Science Team.

Output: PEATEs-ADS product queries, PEATEs-ADP product queries,
PEATEs-NEXT request, PEATES Requested listings, PEATES Ingested SD3E
Data, PEATES Ingested ADS Data, PEATES Ingested ADP Data, Pre-launch
algo and test data, PEATES engineering data request, Engineering data

### Store/Catalog Data

Input: PEATES Ingested SD3E Data, PEATES Ingested ADS Data, PEATES
Ingested ADP Data, Pre-launch algo and test data, Engineering data

Process: The Store/Catalog Data function manages the PEATEs data storage
system by keeping track of the entries in a small database. It stores
all of the data ingested from the SD3E (*PEATEs Ingested SD3E Data*),
the ADS (*PEATEs Ingested ADS Data*), the ADP (*PEATEs Ingested ADP
Data*), the *Pre-launch algorithms and test data* from the NEXT, and the
*Engineering data* from the C3S. Additionally, this function catalogs
products generated during science data processing. If the Science Team
request data for ad-hoc analysis, the Store/Catalog function can provide
the Science Team with a catalog of data products available in their
PEATEs data store. These *Cataloged data* products may include the xDRs,
analysis data products, ancillary data, auxiliary data, correlative data
from other instruments, diagnostic products, calibration and validation
products, or newly generated xDRs, IPs, and its associated metadata
produced during science data processing.

Output: Cataloged data

### Manage Software Configuration

Input: Algorithms/source code

Process: The Manage Software Configuration is a system that maintains
the source code configuration control for the operational and science
*Algorithms/source code* used in processing the science data. These
algorithms could also include science algorithms acquired by the Science
Team. The Process Science Data function retrieves science
*Algorithms/source code* needed for processing and stores any updated
science algorithms to this system. This function also makes available
the *Recommended algorithms/source code*, the science algorithms with
enhancements, for retrieval by the PEATEs Export Data function.

Output: Algorithms/source code, Recommended algorithms/source code

### Process Science Data

Input: NICSE-PEATEs quality control request, SD3E-PEATEs operational
algorithms, PEATES management direction, ST algo src code
recommendations, ST ad-hoc processing requests, I&TSE algo status, NICSE
cal LUT updates, NICSE cal software updates, PEATEs-PSOE response,
Science products, Analysis products, Correlative data, Algorithms/source
code

Process: The Process Science Data function encompasses the execution and
processing of science algorithms, the analysts involved in the
evaluations, and the scheduling of various resources and priorities
based on specific *PEATEs management direction* from the PSOE. This
function provides the PSOE with *PEATEs management reports* on their
science processing status.

In support of xDR quality assessment for climate research, the Process
Science Data function retrieves the *Science products* (xDRs, ancillary,
and metadata), the *Analysis products* (analysis and comparison tools),
and the *Correlative data* from the PEATEs data store. From the SD3E, it
retrieves the operational algorithms, *SD3E-PEATEs operational
algorithms*. The PEATEs performs processing for the Science Team to
assess the accuracy of the xDRs. If the science algorithms were updated
as a result of the evaluation, the software configuration management is
used to maintain a history of the science algorithm updates. If
requested by the Science Team, the PEATEs may submit the *xDR evaluation
results* and a *PEATES status* to the PSOE.

In evaluating impacts of improving the SDR and EDR algorithms, xDR
assessment and pre-launch and initial post-launch assessment of xDRs and
IP algorithm are performed. The Science Team provides their algorithm
recommendations, *ST algorithm/source code recommendations*, to the
PEATEs. The Process Science Data function retrieves the *Analysis
products* (pre-launch test data, analysis and plotting tools), the
*Correlative data*, and the *Science products* (xDRs and the operational
algorithms) from the PEATEs data store. The PEATEs provide the
capability to the Science Team to assess the SDR and EDR algorithm
functionality and its suitability for making climate products by
generating the necessary *xDRs, IPs, and the associated metadata* needed
for evaluation. Additionally, the Process Science Data function may
develop analysis tools and produce *Analysis products* that the Science
Team needs for analysis. All developed tools and products generated are
stored in the PEATEs data store. Any updates to the science
*Algorithms/source code* are maintained in the software configuration
management system. The Process Science Data function may optionally use
the I&TSE to validate the algorithm enhancements. I&TSE provides Process
Science Data an *I&TSE algorithm status*, as a result of I&TSE
processing of the recommended science algorithms. The *I&TSE algorithm
status* will indicate to the Process Science Data function whether or
not their recommended algorithm enhancements will generate the expected
output in the operational IDPS environment.

For calibration and validation activities, this function receives a *ST
ad-hoc processing request* from the Science Team to resolve possible
calibration artifacts that they may have identified or a *NICSE-PEATEs
quality control request* from the NICSE to verify their *NICSE cal LUT
updates* and *NICSE cal software updates*. The Process Science function
retrieves the *Science products* (i.e. xDRs), *Analysis products*,
*Pre-launch algorithms and test data*, and *Engineering data* from the
PEATEs data store. From the SD3E, this function acquires the operational
algorithms, *SD3E-PEATEs operational algorithms*. The analyst will
analyze the suspect data sets for anomalies by re-running their science
algorithms and generating a Level 1B or higher product. The *Result of
the calibration evaluation* is sent to the NICSE. Additionally,
processing status, problem reports, etc..., and the *NICSE-PEATEs
quality control response* are returned to the NICSE.

The Process Science Data function may submit a *PEATEs-PSOE instrument
service requests,* such as maneuvers, to the PSOE. The PEATEs that are
not working with the VIIRS are responsible for calibration and
validation of their respective instrument.

The Ozone PEATE will perform their own independent analysis of
calibration and validation activities in support of OMPS calibration and
validation. The Ozone Radiometric Calibration function assesses and
validates OMPS pre-launch and post-launch calibration and
characterization data. The Ozone PEATEs need the pre-launch algorithm
and test data, the Calibration RDRs (TBD), RDRs, SDR algorithm and
source code, available SD3E data, and calibration evaluation results to
determine enhancements to the SDR algorithms. The algorithms are
designed because of an improvement, developed, and tested. For
pre-launch calibration and characterization, the following instrument's
characteristics are evaluated:

-   Radiometric: SNR, linearity, response dynamic range, dark current,
    smear, etc. (including some on-site TV test data analysis support)

-   Spectral registration (to determine bandcentered wavelengths) and
    bandpass.

-   Solar diffuser goniometry

-   Solar diffuser BRDF (for nadir sensors) and BTDF (for limb sensor)
    characterization

-   Polarization sensitivity.

Additionally, the following activity is planned:

-   Key look-up tables (LUTs) validation and improvements.

The planned post-launch calibration and characterization activities
include:

-   Radiometric calibration from OMPS on-board diffuser, dark current,
    and lamp measurements.

-   SDR LUTs development, test, and updates

-   Bad pixel determination

-   Calibration analysis and trending

-   Analyzing calibration data sets collected during spacecraft
    maneuvers.

For Ozone Geometric Calibration, the Ozone Geometric Calibration ingests
specialized spatially unbinned RDRs, SDRs, and EDRS produced during the
intensive post-launch calibration period to evaluate the geolocation of
the OMPS measurements from the PEATEs data store. This function
interfaces with the PEATES Export Data function to send the resulting
calibration evaluation analysis product to the Science Team.

The resulting updates to the ozone radiometric and geometric calibration
LUTs and software are sent to the PEATE data store.

The Sounder PEATE will perform their own independent analysis of
radiometric and geometric calibration and validation activities in
support of ATMS and CrIS calibration and validation. As of the writing
of this document, their characterization activities has not yet been
defined. (TBS)

Output: NICSE-PEATEs quality control response, PEATEs management
reports, PEATES status, Result of cal evaluation, PEATEs-PSOE instrument
service request, Analysis products, xDRs, IPs, metadata, xDR eval
results

### PEATEs Export Data

Input: Recommended algorithms/source code, PEATES stored products, ST
data request

Process: The PEATEs Export Data function is responsible for receiving
data requests and matching the available data products in the PEATEs
data store to a requester's order. If the Science Team submits a data
request, *ST data request*, for specific data products, the PEATEs
Export Data function checks the PEATEs data store for the current
products available, the *PEATEs stored products*, that match the order
placed by the Science Team. If the request includes science algorithms,
the PEATEs Export Data retrieves the *Recommended algorithms/source
code* from their Manage Software Configuration system. If desired, the
Science Team may request the PEATEs Export Data function to provide the
requested data as a package, *ST science data package*, to their remote
site. Or the Science Team may choose to acquire the science data package
from the PEATEs Export Data at their convenience.

If the PEATEs decide to use the I&TSE to perform algorithm enhancement
check-out, the PEATEs Export Data function generates a science algorithm
data package, *PEATEs Science algorithm improvement pre-pkg*. This
package includes the Recommended Algorithms/source code, xDR subsets,
ancillary data, calibration product, sample data output, and any test
cases or files necessary to build and run the science algorithms.

If requested by the Science Team, the PEATEs Export Data function will
submit the science algorithm updates, *PEATEs science algorithm
improvement recommendations*, to the PSOE.

Output: PEATES science algo imp rec, PEATEs Science algorithm imp
pre-pkg, ST data request response, ST science data pkg

## Integration and Test System Element (I&TSE)

Input: I&TSE management direction, IDPS Operational Software, PEATEs
Science algorithm imp pre-pkg, SD3E-I&TSE xDRs

The I&TSE will be available for interactive access by the PEATEs and
Science Team analysts. It facilitates access to the baselined
operational environment for algorithm enhancement check-out, IP
generation, access to production software, and ad-hoc data processing
requests. Nominally, team members connect into the system, transfer
their data sets of interest, incorporate their algorithm changes, and
initiate processing and transfer their results back to their own
systems. The I&TSE DFD is provided in Figure 3.5-1.

As of the writing of this document, the data flow of RDRs and/or
application packets, used for science data product generation, into the
I&TSE is TBD. The interface of the mini-IDPS has not been fully
designed.

Output: I&TSE management report, I&TSE status, I&TSE science algo imp
pkg, I&TSE algo status

[]{#__RefHeading___Toc511360086
.anchor}![](media/image11.pct){width="8.93125in"
height="5.627777777777778in"}Figure 3.5-1 I&TSE Data Flow Diagram

### I&TSE Ingest Data

Input: PEATEs Science algorithm imp pre-pkg, SD3E-I&TSE xDRs

Process: The I&TSE Ingest Data function is responsible for ingesting the
algorithm recommendations from the PEATEs and any RDR or SDRs,
*SD3E-I&TSE xDRs*, from the SD3E and storing those data in the I&TSE
data store. The PEATEs provide the I&TSE a package with files needed to
execute the science algorithms under the I&TSE environment. This data
package, the *PEATEs Science algorithm improvement pre-package,*
includes all of the xDR data sets needed for testing, calibration
product, recommended algorithm/source code, ancillary data, alternate
ancillary data, sample data output, and build files needed for I&TSE to
check algorithm enhancements. All acquired products, *I&TSE Ingested
Data*, are stored in the I&TSE data store.

Output: I&TSE Ingested Data

### Algorithm Development Area

Input: I&TSE management direction, Algo Dev Products

Process: The Algorithm Development Area is responsible for adding the
science algorithm recommendations to the production software, providing
and setting up a compatible environment, and providing the necessary
build files in order to execute the PEATEs recommended science
algorithms in the I&TSE. This function retrieves the *Algorithm
Development Products* from the I&TSE data store. These products include
the files provided by the PEATEs in the science algorithm improvement
pre-package. This function then sets-up the I&TSE environment in order
to run the science algorithms. The resulting files used to build and
set-up the environment and the science algorithm package are sent to the
Mini-IDPS as a *Data Package*.

The PSOE may send the I&*TSE management direction* to the Algorithm
Development function to request algorithm processing status or to
provide schedules and priorities. This function will also provide an
*I&TSE management report* with the status of their processing to the
PSOE.

This function maintains a store of all ingested products and accounts
for and maintains all versions of the operational algorithms in use.

Output: I&TSE management reports, Data package

### Mini-IDPS Production Area

Input: Data package, IDPS Operational Software

Process: The Mini-IDPS Production Area is responsible for performing the
algorithm enhancement check-out. Additionally, it is responsible for
updating and maintaining the various versions of the *IDPS Operational
Software*. This function receives the *Data package* from the Algorithm
Development Area. The *Data package may* include the science algorithms,
sample data output, calibration product, ancillary data, test files,
etc... The Mini-IDPS will execute the science algorithms under the
operational environment and compare the output generated in the I&TSE
environment to the sample data output provided by the PEATEs. The
resulting *I&TSE products* are sent to the Send to Out-bound site
function. The *I&TSE products* include the processing results, SDR, EDR,
or IPs generated.

The Mini-IDPS has the capability to run different version of the *IDPS
Operational Software*.

If there are upgrades to the *IDPS Operational Software,* the NPOESS
Ground Integrated Support Facility (ISF) sends the latest versions to
the Mini-IDPS. This function is responsible for maintaining the
CM-approved *IDPS Operational Software* and documentation upgrades.
Additionally, it is responsible for maintaining and operating the
operational IDPS software and tools.

Output: I&TSE products

### Send to Out-bound site

Input: I&TSE products

Process: The Send to Out-bound site is responsible for making the
products generated in the I&TSE available to the PEATEs and the PSOE.
The *I&TSE products* generated by the Mini-IDPS are stored. These
products include the processing results, the SDR, EDR, or IPs generated
during processing. This function provides the PEATEs with an *I&TSE
algorithm status* based on their processing of the PEATEs science
algorithms. If requested by the PSOE, this function will provide the
PSOE with their status, *I&TSE status*, and results from the science
algorithm enhancement check-out, the *I&TSE science algorithm
improvement package*.

Output: I&TSE status, I&TSE science algo imp pkg, I&TSE algo status

# OPERATIONS CONCEPT

The SDS operations are described by a series of scenarios developed
within the framework of the Structured System Concepts defined in
Section 3 of this document. These scenarios provide an overview of the
major threads throughout the System Concept to describe how activities
are accomplished. The set of scenarios described here help in the
understanding of how the System behaves and serves as a tool to aid in
defining the concepts and verifying the completeness of the System
Concept. The scenarios do not portray every possible situation that may
be encountered during operations but mostly serve as a basis for further
operations planning.

Each scenario is designed to achieve a specific objective, with a given
set of assumptions. Together, the objective and assumptions set the
stage for the scenario. Assumptions include any pre-requisite activities
required before the scenario begins. The scenario is illustrated by a
diagram depicting the sequence of data flows between functions that were
introduced in the System Concept. Each data flow is numbered to show the
order in which the activity occurs within the scenario. A letter
immediately following a sequence number indicates more than one activity
is occurring concurrently. While the sequence numbers are included to
aid in following the scenario, there may be more than one valid sequence
of activities to accomplish a scenario objective.

A scenario description is included with each diagram to provide a
narrative of the major activities.

## Operations Overview

The operations associated with the NPP fall into three operational
modes---Pre-Launch/Launch Readiness, Launch and Early Validation, and
Post-Launch Operations.

The majority of the operational scenarios defined here are for the
Post-launch phase, but are applicable to other phases with minor
modifications.

## Operations Scenarios

The following operational scenarios have been identified as part of a
structured system analsyis effort being used to identify requirements:

-   SD3E Ingest and Manage Data

-   PEATEs Receive, Process, and Archive Data

-   PEATEs xDR Quality Assessment

-   PEATEs SDR and EDR Algorithm Enhancements

-   PEATEs Product Distribution

-   NICSE Calibration and Validation Processing

-   NICSE Calibration Service Request

-   Anomaly Detection

-   PSOE Coordinate SDS Activities

All scenarios will be validated during pre-launch System Integration and
Test (SI&T) activities. During these integration and test activities,
formal and informal interface and compatibility tests are performed.
Simulated and real instrument data, if available, are utilized to verify
interfaces and functional requirements in an operational mode. This
phase also includes Mission Readiness activities and System Integration
and Test (SI&T) activities to test the external interfaces and segment
level 2 requirements.

### SDS Operations Scenarios

The Post-Launch Operations includes the routine data handling and
processing activities performed throughout the life of the mission. A
representative set of operational scenarios is described in the
following sub-sections. While not exhaustive, the scenarios represent an
operation sequences of steps, for a specific objective, to be performed
based on the functional model (the DFDs) found in Section 3.

#### SD3E Ingest and Manage (See section 3.1 for concept)

Objective:

The objective of the SD3E Ingest and Manage Data scenario is to identify
the steps for ingesting data, verifying data, and managing the data
store.

Assumptions:

-   The PEATEs have checked the ADS product catalog for a list of valid
    files for SD3E to ingest.

-   The PEATEs have provided SD3E with a listing of the valid data
    products that they need from IDPS and/or ADS.

-   The IDPS and ADS have the data in their archive and can fill data
    requests immediately.

[]{#__RefHeading___Toc511360087
.anchor}![](media/image12.pct){width="6.18125in"
height="8.318055555555556in"}Figure 4.2.1.1-1 SD3E Ingest and Manage
Scenario

Scenario Description:

The PEATEs provide a list of data products to the SD3E. As a result, the
SD3E generates product subscriptions (i.e. standing orders) to the IDPS
and/or the ADS using the list of data products requested. SD3E submits
the product subscriptions to the IDPS and ADS. The SD3E ingests and
verifies the data provided by the external segment. SD3E uses a checksum
or a digital signature provided by the segment to determine if the
products received matches the products expected. If SD3E determines that
the acquired products are incomplete, SD3E generates ad-hoc requests to
the external segment for retransmission of the products. The segment
provides the requested products, if available. The ingested products are
verified by SD3E. If SD3E verifies that the data are complete, then SD3E
stores the data into logical groups in the out-bound store and makes
them available to the PEATEs.

Scenario Steps:

1.  PEATEs submit *PEATEs Requested listings*, a list of data products
    for SD3E to ingest, to the SD3E Manage Data Requests.

2.  Manage Data Requests generates *IDPS product subscription and ADS
    product subscription*, based on the data products the PEATEs have
    requested. It sends the product subscriptions to SD3E Ingest Data.

3.  SD3E Ingest Data sends the *IDPS product subscription* to the IDPS
    and the *ADS product subscription* to the ADS.

4.  IDPS and ADS receive the product subscription.

    a.  IDPS fills the order by sending the *NPOESS Data Product Query
        Request status*, a status regarding the data request.

    b.  ADS sends SD3E Ingest Data an *ADS query and request status*.
        This status includes a delivery report/notice with instructions
        to SD3E Ingest Data on how to retrieve the *ADS Data*.

5.  IDPS and ADS make the data available to SD3E Ingest Data.

    a.  IDPS sends the *IDPS Data* to the SD3E Ingest Data to a
        directory location specified by SD3E in the *IDPS product
        subscription*. The *IDPS Data* includes the IDPS data delivery
        report and the IDPS RDR products.

    b.  ADS sends the *ADS Data* to the SD3E Ingest Data. The *ADS Data*
        includes the xDRs, all available IPs, operational algorithms,
        calibration product, and ancillary data.

6.  Verify Data Ingested receives the *Ingested Data* from the SD3E
    Ingest Data function. The Verify Data Ingested function reads the
    delivery reports/notices and uses the checksum or the digital
    signature, included in the transmission, to verify that the data
    received matches the data expected.

7.  If the verify is unsuccessful, then Verify Data Ingested sends an
    *Incomplete data status* to Manage Data Requests.

8.  Manage Data Requests generates an ad-hoc request to the appropriate
    segment for retransmission of the incomplete data files, as
    indicated by the *Incomplete data status*. Mange Data Requests logs
    all transactions and updates the SD3E internal report. It sends the
    *IDPS ad-hoc request* and the *ADS ad-hoc request* to the SD3E
    Ingest Data.

9.  SD3E Ingest Data submits the *IDPS ad-hoc request* and/or *ADS
    ad-hoc request* to the appropriate segment.

10. IDPS and ADS receive the ad-hoc request.

    a.  IDPS fills the order by sending the *NPOESS Data Product Query
        Request status,* a status regarding the data request. If the
        data are available, IDPS sends the *IDPS Data* to SD3E Ingest
        Data.

    b.  ADS sends SD3E Ingest Data an *ADS query and request status*.
        This status includes a delivery report/notice with instructions
        to SD3E Ingest Data on how to retrieve the *ADS Data*.

11. Repeat step 5.

12. Repeat step 6.

13. If the Verify Data Ingested function successfully verifies all
    acquired products, it sends the *Verified data* to the In-bound
    store.

14. Manage Data retrieves the *In-bound data* from the In-bound store.

15. Manage Data is responsible for managing the *SD3E Out-bound data*
    products in groups that can be logically isolated from each other in
    the Out-bound store. All data acquired are logged.

Mange Data checks the Out-bound store and removes science data files
(i.e. xDRs) older than 32 days and other products (i.e. IPs) older than
five days from the Out-bound store. The SD3E Ingest and Manage
Operational Scenario Diagram is shown in Figure 4.2.1.1-1.

#### PEATEs Receive, Process, and Archive Data 

Objective:

The objective of the PEATEs Receive, Process, and Archive Data scenario
is to identify the steps for receiving, processing to higher-level
products, and archiving the NPP data products.

Assumptions:

-   The SD3E has submitted product subscriptions to the IDPS and ADS for
    the science data products.

-   Requested products have been received by SD3E and verified.

[]{#__RefHeading___Toc511360088
.anchor}![](media/image13.pct){width="6.18125in"
height="8.565277777777778in"}Figure 4.2.1.2-1 PEATEs Receive, Process,
and Archive Data Scenario

Scenario Description:

The PEATEs retrieve the data products that they need for science data
processing from the SD3E. If the SD3E no longer has the data available
in the data store, then the PEATEs submit an ad-hoc request to the ADS
for the necessary products. The PEATEs receive an ADS data query and
request status. This status includes a delivery notice/report with
instructions on how to retrieve the requested products. Additionally, if
the PEATEs need alternate ancillary data, they submit data requests to
ADP. If engineering data reports are needed, they request the data from
C3S. All acquired products are then verified by performing a basic level
of validation to determine that the data received matches the data
expected. The PEATEs store and catalog the verified products. The PEATEs
processes the data, develops the necessary tools, and evaluates and
assess data and algorithm improvements in support of the Science Team's
investigations. Any NPP products generated by the PEATEs as a result of
xDR assessments or algorithm enhancements are stored and cataloged in
their data store.

Scenario Steps:

1.  PEATEs check the SD3E Out-bound store for the available *SD3E-PEATEs
    science data and operational algorithms*. If the SD3E Out-bound
    store no longer has the requested products, the PEATEs Ingest Data
    generates a *PEATEs-ADS ad-hoc request*.

2.  PEATEs Ingest Data submits the *PEATEs-ADS ad-hoc request* to the
    ADS.

3.  PEATEs Ingest Data receives a status. This includes a delivery
    notice/report on how to retrieve the data from the ADS. PEATEs
    Ingest Data retrieves the *ADS Data*. The *ADS Data* may include the
    xDRs, available IPs. calibration product, ancillary data, and
    operational algorithms.

4.  PEATEs Ingest Data sends a transfer request, *PEATEs-ADP Transfer
    Request*, to the ADP.

5.  The ADP sends the requested alternate ancillary data, *ADP Data*, to
    the PEATEs Ingest Data.

6.  PEATEs Ingest Data sends a *PEATEs engineering data request* to the
    C3S for the engineering data reports such as the two line elements
    (TLE) sets, etc...

7.  PEATEs Ingest Data performs a basic level of validation on all
    acquired products. The validation includes verifying that the data
    received matches the data expected, and that the received data are
    in the appropriate format and complete. The *Verified data* are sent
    to the Store/Catalog function.

8.  Store/Catalog Data stores and catalogs the *Verified data*. The
    *Cataloged data* are stored in the PEATEs data store.

9.  Process Science Data retrieves the *Science products*, the *Analysis
    products*, the *Correlative data* from the PEATEs data store.
    Additionally, it retrieves *Algorithms/source code* from the Manage
    Software Configuration.

10. Process Science Data produces the NPP products such as *xDRs, IPs,
    its associated metadata*, science algorithm enhancements, and any
    *Analysis products* developed as a result of their science data
    processing. These generated products are stored in the PEATEs data
    store. The Manage Software Configuration stores updates to the
    science *Algorithms/source code* generated during processing.

The PEATEs Receive, Process, and Archive Operational Scenario diagram is
shown in Figure 4.2.1.2-1.

#### PEATEs xDR Quality Assessment

Objective:

The objective of the xDR Quality Assessment scenario is to identify the
steps involved in assessing the quality of xDRs for making climate data
records.

Assumptions:

-   The PEATEs have the ancillary and/or alternate ancillary products it
    needs for xDR evaluation.

-   The PEATEs will obtain or create the needed IPs.

-   The PEATEs have access to existing comparison data from other
    instruments.

-   The PEATEs have developed or acquired analysis and plotting tools to
    perform data comparisons.

-   Requested products have been received by SD3E and verified.

-   C3S has made the necessary engineering data products available to
    the PEATEs.

-   NEXT has made the necessary pre-launch test data and algorithms
    available to the PEATEs.

-   Science Team has requested the PEATEs to assess the quality of
    specific xDRs.

[]{#__RefHeading___Toc511360089
.anchor}![](media/image14.pct){width="6.30625in"
height="8.440277777777778in"}Figure 4.2.1.3-1 PEATEs xDR Quality
Assessment Scenario

Scenario Description:

In supporting the Science Team in assessing the quality of xDRs, the
PEATEs ingest the necessary products from the SD3E. If SD3E no longer
has the products needed, then the PEATEs submit an ad-hoc request to the
ADS. The ADS returns a status with instructions on how to retrieve the
data products. The PEATEs send a data transfer request to the ADP for
the alternate ancillary data. The PEATEs ingest all of the acquired data
products, verifies, stores, and catalogs the data in the PEATEs data
store. The PEATEs provide the necessary science data, develop or acquire
the tools (i.e. software), and provide the production system or
environment needed for the Science Team to evaluate the quality of the
xDRs for making climate data records.. All products generated by the
PEATEs during this processing are stored and cataloged in the data
store. The PEATEs Manage Software Configuration stores updates to the
science algorithms. The Science Team may again submit ad-hoc requests to
the PEATEs for additional products or processing to aid in their
investigation.

Scenario Steps:

1.  PEATEs Ingest Data checks the SD3E Out-bund data store for the
    available *SD3E-PEATEs operational algorithms and science data*. The
    *SD3E-PEATEs science data* includes the xDRs, IPs, calibration
    product, and ancillary data.

2.  If the requested data are no longer available in the SD3E Out-bound
    data store, then the PEATEs Ingest Data generates an ad-hoc request,
    *PEATEs-ADS ad-hoc request*, and submits it to the ADS.

3.  The PEATEs Ingest Data receives a status from ADS. This status
    provides a delivery notice/report with instructions on how to
    retrieve the *ADS Data*. PEATEs Ingest Data then retrieves the *ADS
    Data*. The requested *ADS Data* may include the xDRs, IPs,
    calibration product, ancillary data, and operational algorithms.

4.  PEATEs Ingest Data submits a transfer request, *PEATEs-ADP Transfer
    Request,* to the ADP for the *ADP Data*.

5.  The ADP transfers the *ADP Data* (i.e. alternate ancillary data) to
    the PEATEs Ingest Data function.

6.  PEATEs Ingest Data ingests and verifies the *ADS Data* and the *ADP
    Data*. This function performs a basic level of validation on all
    acquired products. The validation includes verifying that the data
    received matches the data expected, and that the received data are
    in the appropriate format and complete. The *Verified data* are sent
    to the Store/Catalog function.

7.  Store/Catalog stores and catalogs the *Verified data* from the
    PEATEs Ingest Data function. The *Cataloged data* are stored in the
    PEATEs data store.

8.  Process Science Data retrieves, from the PEATEs data store, the
    *Science products* (i.e. xDRs, Pre-launch algorithms and test data),
    *Analysis products* and tools, and *Correlative data* (i.e.
    spacecraft data sets, ground based observations, comparison data
    from other instruments, etc...). It also retrieves the science
    *Algorithms/source code* used in their production system from the
    Manage Software Configuration.

9.  Process Science Data provides or develops tools, provides the data,
    or provides the production system necessary to support the Science
    Team in evaluating the xDRs for accuracy and in EDR assessments for
    accomplishing climate research. The PEATEs data store stores all
    *Analysis products* and any *xDRs, IPs, or its associated metadata*
    generated during xDR quality assessment. Manage Software
    Configuration system maintains versions of the new or updated
    science *Algorithms/source code*.

10. PEATEs Export Data retrieves the *xDR evaluation results* and any
    related data products from the PEATEs data store.

11. If there are updates to the science algorithms, PEATEs Export Data
    retrieves the *Recommended algorithms/source code* from the Manage
    Software Configuration.

12. The PEATEs Export Data function provides the Science Team with the
    *xDR evaluation results* and a *ST science data package*. The *ST
    science data package* may include the *Recommended algorithms/source
    code* and the related science data subsets.

13. The Science Team may request additional processing or products from
    the PEATEs Process Science Data to further aid in their
    investigation by submitting a *ST ad-hoc processing requests*.

The PEATEs xDR Quality Assessment Operational Scenario diagram is shown
in Figure 4.2.1.3-1.

#### PEATEs SDR and EDR Algorithm Enhancements

Objective:

The objective of the SDR and EDR algorithm enhancement scenario is to
identify the steps involved in assessing and developing SDR and EDR
algorithm enhancements.

Assumptions:

-   The Science Team has provided the alternative look-up tables or the
    alternative science algorithms and source code to the PEATEs.

-   The Science Team has identified that changes to the production
    processing scheme would produce data suitable for climate research.

-   The Science Team has the operational algorithms.

-   Pre-launch and initial post-launch assessments of the SDR, EDR, and
    IP operational algorithms have already been performed.

-   XDR Quality Assessments are being done. (see PEATEs xDR Quality
    Assessment Scenario, Section 4.2.1.3)

-   C3S has made the necessary engineering data products available to
    the PEATEs.

-   ADP has made the necessary alternate ancillary data products
    available to the PEATEs.

-   Requested products have been received by SD3E and verified. All
    products needed by the PEATEs for processing are available in the
    SD3E.

[]{#__RefHeading___Toc511360090
.anchor}![](media/image15.pct){width="6.18125in"
height="8.315277777777778in"}Figure 4.2.1.4-1 PEATEs SDR and EDR
Algorithm Enhancements Scenario Part I

[]{#__RefHeading___Toc511360091
.anchor}![](media/image16.pct){width="6.43125in"
height="8.190277777777778in"}Figure 4.2.1.4-2 PEATEs SDR and EDR
Algorithm Enhancements Scenario Part II

Scenario Description:

In supporting the Science Team in developing candidate SDR and EDR
algorithm enhancements, the PEATEs request the science data and the
operational algorithms from the SD3E. Additionally, the PEATEs request
pre-launch algorithm and test data from the NEXT system. The PEATEs
ingest all acquired data and performs a basic level of validation. That
validation includes verifying that the data received matches the data
expected and that the received data are in the appropriate format and
complete. The Store/Catalog function stores and catalogs the verified
data. The Process Science Data function retrieves the necessary science
data and tools from the PEATEs data store, and any science algorithms
from the Manage Software Configuration to aid in the evaluation. The
PEATEs identifies the problems of concern, implements the suggested
algorithm enhancements, processes the data by generating xDRs to support
evaluation, and evaluates the results of the enhancements. The PEATEs
then forward their results to the Science Team. The Science Team
compares the SDR and EDRs generated using the recommended algorithms to
the SDR and EDRs generated using the operational algorithms. If problems
still exist, then the Science Team requests additional processing from
the PEATEs until the proposed correction resolves the target problem or
achieves the desired results without introducing other artifacts. Once
all identified artifacts have been resolved, the PEATEs may optionally
send their science algorithm updates to the I&TSE to check if the
recommended science algorithms will generate the expected data products
in the operational IDPS environment.

The PEATEs provides the I&TSE with a science data package. This package
includes the xDR subsets, science algorithms, ancillary data, alternate
ancillary data, build files, sample data output, test data files, and
any other files needed to build the scenario in order to run the science
algorithms. The I&TSE will set-up the environment and build the files
necessary to run the science algorithms. The I&TSE will then check
whether the output from the I&TSE is consistent with the sample data
output provided in the PEATEs science data package. The I&TSE may send a
status and their results from the science algorithm processing to the
PSOE. If there are problems identified in the I&TSE run, then the I&TSE
returns a status to the PEATEs. The PEATEs will repeat their problem
identification and processing steps until all problems have been
resolved.

Once all problems have been resolved in the science algorithm
enhancements, the PEATEs retain a version of the science algorithm in
the Manage Software Configuration. The PEATEs send their results and the
science algorithm recommendations to the Science Team. The Science Team
may decide to submit it to the PSOE for further action. After reviewing
the recommendations, the PSOE may then submit the recommendations to the
NPP/NPOESS Algorithm CCB (TBR).

Scenario Steps:

1.  PEATEs Ingest Data retrieves the *SD3E-PEATEs science data and
    SD3E-PEATEs operational algorithms* from the SD3E Out-bound data
    store. The *SD3E-PEATEs science data* includes the xDRs, IPs,
    ancillary data, and calibration product.

2.  The PEATEs Ingest Data logs onto the NEXT system and retrieves the
    *Pre-launch algorithm and test data*.

3.  The PEATEs Ingest Data function ingests and verifies the acquired
    data. The validation includes verifying that the data received
    matches the data expected, and that the received are in the
    appropriate format and complete. The *Verified data* are sent to the
    Store/Catalog function.

4.  The Store/Catalog function catalogs the *Verified data*. The
    *Cataloged data* are stored in the PEATEs data store.

5.  The Process Science Data function retrieves *Science products* (i.e.
    all available RDRs), *Analysis product* and tools, and *Correlative
    data* from the PEATEs data store. It retrieves the science
    *Algorithms/source code* from the Manage Software Configuration
    system. The Process Science Data function identifies the problems of
    concern and implements the suggested algorithm enhancements.

6.  The Process Science Data processes the data by generating *xDRs,
    IPs, and its associated metadata* using the science algorithm
    recommendations, and any *Analysis products* needed to support
    evaluation. This function evaluates the results of the enhancements.
    The resulting products from the processing and evaluation are stored
    in the PEATEs data store. The Manage Software Configuration stores
    new or updates to the science algorithms.

7.  The PEATEs Export Data function retrieves the *Recommended
    algorithms/source code* from the Mange Software Configuration.

8.  The PEATEs Export function retrieves the *PEATEs stored products*
    from the data store.

9.  The PEATEs Export Data creates a *ST science data package*. The *ST
    science data package* includes the xDR assessment results, the xDRs
    generated using the science algorithms, and the input xDRs (or any
    subset of) used in the evaluation. The PEATEs Export Data function
    forwards the *ST science data package* to the Science Team.

10. The Science Team compares the SDR and EDRs generated using the
    recommended algorithms to the SDR and EDRs generated using the
    operational algorithms. If the problems still exist, the Science
    Team sends a *ST ad-hoc processing request* to the Process Science
    Data function. The evaluation process repeats until the proposed
    correction resolves the target problem or achieves the desired
    results without introducing other artifacts. Steps 5 through 10 are
    repeated.

Figure 4.2.1.4-1, PEATEs SDR and EDR Algorithm Enhancement Scenario,
Part I.

11. Once all identified artifacts have been resolved, the PEATEs Export
    Data retrieves the *Recommended algorithms/source code* from the
    Manage Software Configuration. PEATEs Export Data retrieves the
    *PEATEs stored products*. This includes the xDR subsets, calibration
    product, ancillary data, alternate ancillary data, sample data
    output, and any other associated files needed to build and run the
    source code. These products are needed to build the *PEATEs Science
    algorithm improvement pre-package.*

12. The PEATEs may optionally send the science algorithms to the I&TSE
    to perform consistency checks of the outputs between the two
    systems, I&TSE and PEATEs. If the PEATEs decide to use the I&TSE,
    the PEATEs Export function, sends the *PEATEs Science algorithm
    improvement pre-package*.

13. The I&TSE ingests the *PEATEs Science algorithm improvement
    pre-package* and stores the *I&TSE Ingested Data* in the I&TSE data
    store.

14. The Algorithm Development Area will retrieve the *Algorithm
    Development Products* from the I&TSE data store. This function uses
    the *Algorithm Development Products* to correctly set-up their
    environment to execute the PEATEs science algorithm recommendations.
    The *Algorithm Development Products* include the products from the
    *PEATEs Science algorithm improvement pre-package*. The *Algorithm
    Development Products* and any environment or build files that were
    modified by this function are provided to the Mini-IDPS as a *Data
    package*.

15. The Algorithm Development Area then sends the resulting *Data
    package* to the Mini-IDPS.

16. The Mini-IDPS runs the science algorithms under their operational
    environment to check that the output from their execution of the
    algorithm enhancements are consistent with the sample data output
    provided by the *PEATEs Science algorithm improvement pre-package*.
    The Mini-IDPS sends the *I&TSE products*. These products include the
    processing results, SDR, EDRs, or IPs to be stored in their local
    data store in the Send to Out-bound site function.

17. The I&TSE may then send the *I&TSE status* and the I*&TSE science
    algorithm improvement package* to the PSOE. If I&TSE identifies
    problems with the code enhancements, the PEATEs Process Science Data
    will receive an *I&TSE algorithm status*. Steps 11 through 17 are
    repeated until all identified problems have been resolved. If the
    PEATEs Process Science Data receives an *I&TSE algorithm status*
    indicating problems, then the PEATEs Process Science Data identifies
    the problems and again processes the data by generating xDRs to
    support evaluation, and evaluates the results of the enhancement
    problem.

18. The resulting *PEATEs xDR products* from the science data processing
    are stored in the PEATEs data store.

19. The Store/Catalog function catalogs the new data products stored in
    the data store. The *Cataloged data* are stored in the PEATEs data
    store.

20. The PEATEs Process Science Data sends any updated science
    Algorithms/source code to the Manage Software Configuration. The
    PEATEs Export Data retrieves the PEATEs stored products from the
    PEATEs data store and the Recommended algorithms/source code from
    the Manage Software Configuration system. The PEATEs Export Data
    then creates *PEATEs science algorithm improvement recommendations*.

21. The PEATEs Export Data function sends the *PEATEs science algorithm
    improvement recommendations* to the Science Team.

22. The Science Team reviews the *PEATEs science algorithm improvement
    recommendations.* The ST may decide to submit the PEATEs
    recommendations, as the *ST algorithm source code recommendations*,
    to the PSOE. The PSOE may provide feedback to the Science Team
    regarding the recommendations.

23. The PSOE reviews the science algorithm recommendation package and
    may submit it to the NPP/NPOESS Algorithm CCB (TBR).

Figure 4.2.1.4-2, PEATEs SDR and EDR Algorithm Enhancement Scenario,
Part II.

#### PEATEs Product Distribution

Objective:

The objective of this scenario is to identify the steps for distribution
of the PEATEs products.

Assumptions:

-   The Science Team has pre-registered for a user account.

-   The PEATEs archive is populated with NPP data and its associated
    metadata.

-   If the Science Team requests certain EDR products or Level 2 and
    higher products that are not stored in the PEATEs archive, the
    PEATEs will generate the requested products.

-   Pre-determined order options (standing orders) are defined
    (compressed, non-compressed).

[]{#__RefHeading___Toc511360092
.anchor}![](media/image17.pct){width="8.80625in"
height="5.627777777777778in"}Figure 4.2.1.5-1 PEATEs Product
Distribution Scenario

Scenario Description:

The Science Team initiates a data request to the PEATEs function to
solicit information on available science data products cataloged in the
PEATEs data store. If there are problems with the request, the PEATEs
return a status to the Science Team. These data requests may also be
standing orders. The PEATEs data store is checked for data availability
against the order. If data are available, the requested products are
retrieved from the data store. The PEATEs automatically send the
requested products to the Science Team's remote computer. If the data
are currently unavailable, PEATEs will automatically send those
remaining or unfilled products to the Science Team as soon as the data
become available in the data store. If desired, the Science Team may
chose to acquire the products from the PEATEs at their convenience.

Scenario Steps:

1.  The Science Team submits an *ST data request* to the PEATEs Export
    Data to solicit information on the available science products. If an
    errors occurs during the search/order, then a status is returned to
    the Science Team.

2.  The Store/Catalog function provides a list of the *Cataloged data*
    products currently available in the PEATEs data store.

3.  The PEATEs Export Data matches the available data products, *PEATEs
    stored products*, in the data store to the order. The matched
    products are retrieved from the PEATEs data store.

4.  The PEATEs Export Data sends the *ST science data package,* a
    package of the science data or science algorithms requested*,* to
    the Science Team. Or the Science Team may acquire the products from
    the PEATEs Export Data.

The PEATEs Product Distribution Scenario diagram is shown in Figure
4.2.1.5-1.

#### NICSE Calibration and Validation Processing

Objective:

The objective of the NICSE Calibration and Validation Processing
scenario is to identify the steps to support calibration and validation
activities.

Assumptions:

-   I&TSE has the latest operational algorithms used in the IDPS
    operational environment.

-   Scientists have determined that there are possible calibration
    artifacts and that the data needs to be examined more closely.

-   NICSE has made calibration updates and recommendations available to
    the PEATEs.

-   IDPS will provide Calibration RDRs (TBD) to the SDS.

-   Requested products have been received by SD3E and verified.
    Necessary data and operational algorithms are available in the SD3E.

-   C3S has made the necessary engineering data products available to
    NICSE.

[]{#__RefHeading___Toc511360093
.anchor}![](media/image18.pct){width="6.30625in"
height="8.190277777777778in"}Figure 4.2.1.6-1 NICSE Calibration and
Validation Processing Scenario Part I

[]{#__RefHeading___Toc511360094
.anchor}![](media/image19.pct){width="6.30625in"
height="8.440277777777778in"}Figure 4.2.1.6-2 NICSE Calibration and
Validation Processing Scenario Part II

Scenario Description:

With support from the PEATEs, the Science Team has performed an analysis
of the calibration process and of the software and has identified that
there are possible calibration artifacts in the data. The Science Team
has provided a description of potential calibration problems and may
also provide recommendations for fixing those problems to the NICSE. The
NICSE has requested the PEATEs to help validate their calibration LUT
and calibration software updates. As a result, the PEATEs need to
retrieve the science data (i.e. xDRs, IPs, calibration product, etc...)
and the operational algorithms from the SD3E. The PEATEs acquire the
pre-launch algorithm and test data from the NEXT system. The PEATEs
ingest and verify all acquired data. A basic level of validation is
performed to ensure that the data received matches the data expected.
All verified data are stored in the PEATEs data store.

To verify the nature of the impacts to the calibration artifacts on
EDRs, the PEATEs analyst analyzes the suspect data sets for anomalies by
running their science and calibration algorithms to validate the
changes. Any products resulting from the analysis are stored and
cataloged in the data store. New or updated science algorithms are kept
track of in the Manage Software Configuration.

Optionally, the PEATEs may send the science algorithms to the I&TSE to
check if the calibration changes will generate the expected output in
the operational environment. The I&TSE's Algorithm Development Area will
use the science algorithm data package provided by the PEATEs to setup
the I&TSE string in order to run the science algorithms under the I&TSE
environment. The Mini-IDPS performs consistency checks between the
sample data output provided by the PEATEs and the I&TSE output generated
using the operational algorithms. The results of I&TSE's processing are
sent to the PEATEs. The I&TSE may optionally be requested to send their
status and the results of the science algorithm processing to the PSOE.

The PEATEs may then perform additional evaluation and processing based
on the results from the I&TSE findings. The PEATEs, except for the Ozone
and Sounder PEATE, subsequently sends the results of their calibration
evaluation to the NICSE. The NICSE analyzes the calibration evaluation
results. If further analysis is needed, the NICSE retrieves the science
products from SD3E, the alternate ancillary data from the ADP, and the
pre-launch algorithm and test data from the NEXT, if needed. The NICSE
performs radiometric and geometric analysis and tests of the identified
updates and determines whether or not additional updates are needed to
the calibration LUT and software. The NICSE may again request the PEATEs
to validate their software and LUT recommendations. If so, the PEATEs
and the NICSE repeat their validation processing steps until all
identified problems are resolved.

Once all identified problems have been resolved, the NICSE sends the
calibration LUT and software updates to the PSOE. The PSOE reviews the
recommendations and may decide to submit the science algorithm
recommendations to the NPP/NPOESS Algorithm CCB (TBR).

Scenario Steps:

1.  PEATEs Ingest Data function retrieves the *SD3E-PEATEs science data
    and operational algorithms*. The *SD3E-PEATEs science data* includes
    the xDRs, all available IPs, calibration product, and ancillary
    data.

2.  PEATEs Ingest Data logs onto the NEXT system to retrieve the
    Pre-launch algorithm and test data.

3.  PEATEs Ingest Data performs a basic level of validation to ensure
    that all acquired data matches the data expected. The *Verified
    data* are sent to the Store/Catalog function.

4.  The Store/Catalog function receives the *Verified data*. It stores
    and catalogs the verified products. The *Cataloged data* are stored
    in the PEATEs data store.

5.  The Process Science Data retrieves the *Science products* (i.e.
    xDRs, calibration product, ancillary data, etc...) and the *Analysis
    products* (i.e. plotting tools). From the Manage Software
    Configuration system, the Process Science Data retrieves the
    *Algorithms/source code* or analysis software needed for calibration
    and validation.

6.  The Process Science Data verifies the impacts of the calibration
    artifacts on the EDRs by analyzing the suspect data sets for
    anomalies. This function runs the recommended science and
    calibration algorithms provided by the Science Team to validate the
    changes. The Process Science Data stores the resulting *Analysis
    products* (i.e. software tools, cal/val products, etc...) and the
    resulting *xDRs, IPs, and the associated metadata* generated during
    processing in the PEATEs data store.

7.  The PEATEs Export Data retrieves the *Recommended Algorithms/source
    code* and any related files as a result of their evaluation from the
    Manage Software Configuration.

8.  PEATEs Export Data retrieves the *PEATEs stored products* from the
    data store to create a science algorithm pre-package. The *PEATEs
    Science algorithm improvement pre-package* includes the calibration
    and validation related xDRs, calibration product, ancillary data,
    sample data output, and any other associated files such as test
    scenarios needed to build and run the science algorithms.

9.  Optionally, the PEATEs Process Science Data, may send the *PEATEs
    Science algorithm improvement pre-package* to the I&TSE.

10. If requested by the PEATEs to perform algorithm enhancment
    check-out, then the I&TSE Ingest Data function ingests the *PEATEs
    Science algorithm improvement pre-package* and stores the *I&TSE
    Ingested Data* to the I&TSE data store.

11. The Algorithm Development Area retrieves the *Algorithm Development
    Products* from the I&TSE data store. These products are used to
    build and set-up the appropriate environment for execution of the
    PEATEs provided science algorithm recommendations. The Algorithm
    Development Area will add the science algorithms to the I&TSE
    production code and generate the necessary environment and build
    files needed to run the science algorithms in the Mini-IDPS
    environment.

12. The Algorithm Development Area subsequently sends the *Data package*
    to the Mini-IDPS. The *Data package* includes the build files,
    environment files, and the science algorithms, sample data output,
    etc..., as described in the *PEATEs Science algorithm improvement
    pre-package*.

13. The Mini-IDPs checks if the calibration changes generate the
    expected output in the operational environment. This function
    performs consistency checks between the sample data output provided
    in the *PEATEs Science algorithm improvement pre-package* versus the
    data output generated with the science algorithms executed in the
    I&TSE system. The *I&TSE products*, the processing results, SDR,
    EDRs, or IPs generated are stored in the I&TSE data store.

14. Once the I&TSE completes processing, the Send to Out-bound site
    function sends an *I&TSE algorithm status*, a status and results of
    their processing, to the PEATEs. If requested by the PSOE, this
    function will send the *I&STE science algorithm improvement package*
    and the *I&TSE status* to the PSOE. These are the results from the
    science algorithm run along with the related xDR subsets and sample
    data outputs.

See Figure 4.2.1.6-1, NICSE Calibration and Validation Processing
Scenario, Part I for a diagram of the above steps.

15. The PEATEs Process Science Data function may then perform additional
    evaluation and processing based on the results from the I&TSE
    findings. The PEATEs, except for the Ozone PEATE, subsequently sends
    the results of their calibration evaluation to the NICSE Ingest Data
    function.

16. The NICSE Ingest Data analyzes the PEATEs *Results of* the
    *calibration evaluation*. If further analysis is needed, the NICSE
    Ingest Data retrieves the *SD3E-NICSE xDRs, calibration product, and
    operational algorithms* from the SD3E.

17. NICSE Ingest Data sends a *NICSE-ADP Transfer Request* to the ADP
    for the *ADP Data*.

18. NICSE Ingest Data receives the *ADP Data,* the alternate ancillary
    data.

19. NICSE Ingest Data logs onto the NEXT system to retrieve the
    Pre-launch algorithms and test data.

20. The NICSE Radiometric Calibration and Geometric Calibration
    functions retrieve their corresponding data products from the NICSE
    Ingest Data. The *Radiometric Calibration Data* includes the PEATEs
    calibration evaluation results, the RDRs, Calibration RDRs (TBD),
    SDR algorithm/source code, pre-launch algorithm and test data, the
    xDRs, calibration product, ancillary data, and operational
    algorithms. The *Geometric Calibration Data* includes the
    calibration evaluation results from the PEATEs, RDRs, VIIRS
    Geolocation SDRs, EDRs, and earth polar motion. The analyst analyzes
    and tests the identified updates and determines whether or not
    additional updates are needed to the calibration LUT and software.

21. The Radiometric Calibration and the Geometric Calibration may make a
    request to the PEATEs for quality control of the recommended
    calibration updates. If the Radiometric and/or Geometric request the
    PEATEs to validate their calibration software and LUT updates, they
    send the quality control request to the NICSE Ingest Data.

22. NICSE Ingest Data sends the corresponding *Radiometric quality
    control and/or Geometric quality control request* to the PEATEs
    Process Science Data function.

23. Repeat step 5.

24. Repeat step 6.

25. The PEATEs Store/Catalog stores and catalogs all products generated
    by the Process Science Data. The *Cataloged data* are stored in the
    PEATEs data store.

26. The data products generated during processing, *PEATEs stored
    products,* are sent to the PEATEs Export Data function.

27. The PEATEs Process Science Data function returns the results of the
    their evaluation with any problems identified to the NICSE Ingest
    Data function.

28. NICSE Ingest Data receives the PEATEs quality control and sends the
    results to the Radiometric and Geometric Calibration functions. The
    PEATEs and the NICSE repeat their validation processing steps, steps
    21 through 27, until all identified problems are resolved.

29. If all identified problems have been resolved, then the Radiometric
    and Geometric Calibration functions send their corresponding
    *Radiometric calibration LUT and software updates* and *Geometric
    calibration LUT and software updates* to the NICSE Export Data.

30. NICSE Export Data submits the *NICSE calibration LUT and software
    recommendations* to the PSOE for further action.

31. The PSOE reviews the recommendations and may decide to submit the
    calibration recommendations, as the *PSOE science algorithm
    improvement recommendation*, to the NPP/NPOESS Algorithm CCB (TBR).

See Figure 4.2.1.6-2, NICSE Calibration Validation Processing Scenario,
Part II for the diagram.

#### NICSE Calibration Service Request

Objective:

The objective of the NICSE Calibration Service Request is to identify
the steps in requesting calibration service activities.

Assumptions:

-   IDPS will provide the Calibration RDRs (TBD) to the SDS.

-   Requested products have been received by the SD3E and verified.

-   C3S has made the necessary engineering data products available to
    NICSE.

[]{#__RefHeading___Toc511360095
.anchor}![](media/image20.pct){width="6.43125in"
height="8.190277777777778in"}Figure 4.2.1.7-1 NICSE Calibration Service
Request Scenario Part I

[]{#__RefHeading___Toc511360096
.anchor}![](media/image21.pct){width="6.30625in"
height="8.190277777777778in"}Figure 4.2.1.7-1 NICSE Calibration Service
Request Scenario Part II

Scenario Description:

The NICSE checks the SD3E data store to determine if the xDRs,
calibration product, and operational algorithms for the selected time
period are still available in the SDE3 data store. If the data are no
longer available in the SD3E data store, then the NICSE will generate an
ad-hoc request to the ADS for the necessary data products. If the
alternate ancillary data are needed by the Geometric Calibration
function, NICSE submits a data transfer request to the ADP for the data.
The NICSE requests the pre-launch algorithm and test data from the NEXT
system. Once all products have been acquired, the NICSE analysts will
analyze the acquired products to determine if calibration services are
needed. If so, the NICSE provides their calibration recommendations and
an instrument service request to the PSOE. The PSOE reviews the
recommendations. If the PSOE determines that a calibration service is
needed, then the PSOE sends an instrument service request to the C3S.

Scenario Steps:

1.  NICSE Ingest Data checks the SD3E Out-bound data store for the
    *SD3E-NICSE xDRs, calibration product, and operational algorithms*.

2.  If the desired products are no longer available in the SD3E data
    store, NICSE Ingest Data generates a *NICSE-ADS ad-hoc request* to
    the ADS for the data products it needs.

3.  The ADS responds with a status. This status includes a delivery
    notice/report with instructions on how to retrieve the requested
    data products from the ADS. The NICSE Ingest Data acquires the
    requested *ADS Data*.

4.  The NICSE Ingest Data submits a *NICSE-ADP Transfer Request* to the
    ADP.

5.  The ADP provides the NICSE Ingest Data with the *ADP Data*, the
    requested alternate ancillary data products.

6.  NICSE Ingest Data logs onto the NEXT system to retrieve the
    Pre-launch algorithm and test data.

See Figure 4.2.1.7-1, NICSE Calibration Service Request, Part I for a
diagram of the above steps.

7.  The Radiometric and Geometric Calibration functions retrieve their
    corresponding *Radiometric Calibration Data* and *Geometric
    Calibration Data* acquired by NICSE Ingest Data. The *Radiometric
    Calibration Data* includes the PEATEs calibration evaluation
    results, the RDRs, Calibration RDRs (TBD), SDR algorithm/source
    code, pre-launch algorithm and test data, the xDRs, calibration
    product, ancillary data, and operational algorithms. The *Geometric
    Calibration Data* includes the calibration evaluation results from
    the PEATEs, RDRs, VIIRS Geolocation SDRs, EDRs, and earth polar
    motion.

8.  The Radiometric and Geometric Calibration functions analyze their
    corresponding products and determine if calibration services are
    needed. If so, any updates to the *radiometric and geometric
    calibration LUT and software updates* are sent to the NICSE Export
    Data function.

9.  The NICSE Export Data function submits the *NICSE calibration LUT
    and software recommendations* to the PSOE. Additionally, NICSE
    Export Data also submits a specific *NICSE instrument service
    request* to the PSOE.

10. The PSOE reviews the recommendations and request from NICSE. After
    reviewing the recommendations, the PSOE may decide to send an
    instrument service request to C3S. C3S provides mission guidance and
    responds to the request with a status or when the calibration
    activity request will be scheduled.

See Figure 4.2.1.7-2, NICSE Calibration Service Request Scenario, Part
II for a diagram of the steps.

#### Anomaly Detection

Objective:

The Anomaly Detection scenario is to identify the steps necessary to
react to a data anomaly.

Assumptions:

-   The PEATEs has determined a change in the quality of an xDR.

-   C3S has made the necessary engineering data products available to
    PEATEs and NICSE.

[]{#__RefHeading___Toc511360097
.anchor}![](media/image22.pct){width="6.30625in"
height="8.190277777777778in"}Figure 4.2.1.8-1 Anomaly Detection Scenario
Part I

[]{#__RefHeading___Toc511360098
.anchor}![](media/image23.pct){width="5.980555555555555in"
height="8.565277777777778in"}Figure 4.2.1.8-1 Anomaly Detection Scenario
Part II

Scenario Description:

The Science Team detects an anomaly in the data and sends a problem
report to the PEATEs. As a result, the PEATEs analyze the problem and
submit an ad-hoc request to the ADS for the products in question. The
PEATEs receive instructions from the ADS on how to retrieve their
requested data products. The PEATEs perform a basic level of validation
to ensure that the products received matches the data expected. All
verified products are stored and cataloged. The PEATEs process the data
using independent and operational algorithms to determine if the
problems are in the science data, the algorithms, or the calibration
data. If the PEATEs determine that the problem is in the data, they
submit a problem report to the ADS. The PEATEs analysis is completed. If
the PEATEs determine that it is a science algorithm problem, then the
PEATEs will resolve the problems in their production algorithms. These
steps are described in the PEATEs SDR and EDR Algorithm Enhancement
Scenario. See Section 4.2.1.4. If the PEATEs (except Ozone and Sounder)
determine that the problem is in the calibration parameters, then a
problem report is sent to the NICSE. The Ozone and Sounder PEATE will
perform an independent analysis of their calibration parameters. The
NICSE analyzes the problem and identifies the questionable calibration
product. The NICSE generates an ad-hoc request to the ADS. The ADS
provides instructions to the NICSE on how to retrieve the requested data
products. Additionally, the NICSE will submit a data transfer request to
the ADP for the alternate ancillary data and a NEXT request for the
pre-launch algorithm and test data, if needed. NICSE analyzes the
calibration data products and the processing steps. Upon completion of
the analysis, any changes to the calibration LUT and algorithms are
tested. The recommended calibration resolution is submitted to the PSOE
for further action. The PSOE may decide to submit the recommendations to
the NPP/NPOESS Algorithm CCB (TBR).

Scenario Steps:

1.  The Science Team detects an anomaly in the data and sends a *Problem
    Report* to the PEATEs Process Science Data. The Process Science Data
    analyzes the *Problem Report* and determines the data products that
    are in question.

2.  The PEATEs Ingest Data generates a *PEATEs-ADS ad-hoc request* to
    the ADS for the products in question.

3.  The ADS provides a status to the PEATEs Ingest Data. The status
    includes a delivery notice/report with instructions on how to
    retrieve the requested ADS products. The PEATEs Ingest Data
    retrieves the *ADS Data*. This function performs a basic level of
    validation by checking to see if the data received matches the data
    expected by using the checksum or digital signature provided along
    with the requested product. The *Verified data* are sent to the
    Store/Catalog function.

4.  The *Verified data* are sent to the Store/Catalog function to
    catalog all acquired products.

5.  The *Cataloged data* are stored in the PEATEs data store.

6.  The PEATEs Process Science Data retrieves the *Science products*
    (i.e. xDRs, calibration product, ancillary data, etc...) and the
    *Analysis products* (i.e. plotting tools). From the Manage Software
    Configuration system the Process Science Data retrieves the
    *Algorithms/source code* or analysis software needed for calibration
    and validation.

7.  The PEATEs Process Science Data processes the data using independent
    and operational algorithms to determine if the problems exist in the
    science data, the algorithms, or the calibration data. If the
    Process Science Data determines a problem in the science data, they
    submit a *Data Problem Report* to ADS. The PEATEs have completed
    their analysis.

8.  If the PEATEs Process Science Data function determines a problem in
    the science algorithms, then the PEATEs will resolve the problem in
    their production science algorithms. The steps are described in the
    PEATEs SDR and EDR Algorithm Enhancement scenario (See Section
    4.2.1.4). The Process Science Data stores the resulting *Analysis
    products* (i.e. software tools, cal/val products, etc...) and any
    resulting *xDRs, IPs, and the associated metadata* generated during
    the processing in the PEATEs data store.

9.  The PEATEs Export Data retrieves the *PEATEs stored products*, the
    resulting products generated during the data analysis of the
    problem.

10. The PEATEs Export Data retrieves any updated science algorithms from
    the Manage Software Configuration.

11. PEATEs Export Data sends the *PEATEs science algorithm improvement
    recommendation* package to the Science Team. These are the results
    from resolving any problems identified in the science algorithms.
    This package may include the xDRs used to test the algorithms, a
    sample data output, and the science algorithm recommendations.

12. The Science Team reviews the science algorithm improvement package
    provided by the PEATEs. As a result, the Science Team, may then
    submit their *ST algorithm source code recommendations* to the PSOE.
    The process for resolving the problems identified in the algorithms
    are complete.

See Figure 4.2.1.8-1, Anomaly Detection Scenario, Part I for the
diagram.

13. If the PEATEs Process Science Data (except for Ozone and Sounder)
    determine that the problem is in the calibration parameters, then a
    *Calibration Problem Report* is sent to the NICSE Ingest Data.

The Ozone and Sounder PEATE are responsible for supporting their own
independent calibration activities.

14. The NICSE Ingest Data submits a *NICSE-ADP Transfer Request* to the
    ADP for the alternate ancillary data.

15. The NICSE Ingest Data ingests the requested *ADP Data* from the ADP.

16. The NICSE Ingest Data generates a *NICSE-ADS ad-hoc request* to the
    ADS for the calibration products in question.

17. ADS sends NICSE Ingest Data function a status with a delivery
    notice/report. This report provides instructions on how to retrieve
    the data. NICSE Ingest Data retrieves the *ADS Data* and uses the
    checksum or a digital signature provided in the delivery report to
    check that the data received matches the data expected.

18. The NICSE Ingest Data logs onto the NEXT system to retrieve the
    Pre-launch algorithms and test data.

19. The Radiometric Calibration and Geometric Calibration functions
    retrieve the acquired products from the NICSE Ingest Data. The
    *Radiometric Calibration Data* includes the PEATEs calibration
    evaluation results, the RDRs, Calibration RDRs (TBD), SDR
    algorithm/source code, pre-launch algorithm and test data, the xDRs,
    calibration product, ancillary data, and operational algorithms. The
    *Geometric Calibration Data* includes the calibration evaluation
    results from the PEATEs, , RDRs, VIIRS Geolocation SDRs, EDRs, and
    earth polar motion.

20. The Radiometric and Geometric Calibration analyst analyzes the data
    products and the processing steps. Upon completion of the analysis,
    any *Radiometric and Geometric calibration LUT and software updates*
    are tested. The *Radiometric and Geometric calibration LUT and
    software updates* are sent to the NICSE Export Data.

21. The *NICSE calibration LUT and software recommendations* are
    submitted to the PSOE for review.

22. The PSOE reviews the recommended resolution and may submit the *PSOE
    science algorithm improvement recommendation* to the NPP/NPOESS
    Algorithm CCB (TBR).

See Figure 4.2.1.8-2, Anomaly Detection, Part II.

#### PSOE Coordinate SDS Activities

Objective:

The objective of this scenario is to identify the steps involved in
approving the algorithm and source code recommendations.

Assumptions:

-   The Science Team through the PEATEs has performed their independent
    analysis, tests, and validation of their recommended
    algorithm/source code enhancements.

-   The I&TSE has been requested by the PEATEs to perform science
    algorithm recommendations check-out.

-   The NICSE has performed their independent analysis, tests, and
    validation of their recommended radiometric and geometric
    calibration enhancements. (See NICSE Calibration and Validation
    scenario, Section 4.2.1.6).

[]{#__RefHeading___Toc511360099
.anchor}![](media/image24.pct){width="6.18125in"
height="8.440277777777778in"}Figure 4.2.1.9-1 PSOE Coordinate SDS
Activities Scenario

Scenario Description:

The PEATEs send their science algorithm improvement recommendations to
the Science Team. The Science Team reviews the enhancements and sends
the science algorithm recommendations to the PSOE. If there are
calibration LUT and software recommendations from NICSE, NICSE sends
them to the PSOE. If the PEATEs use the I&TSE to validate their science
algorithm recommendations, then the I&TSE sends their results from the
science algorithm processing to the PSOE. The PSOE may also request the
I&TSE to verify the PEATEs science algorithm recommendations and/or the
NICSE calibration LUT and software recommendations by running them in
the I&TSE environment. The PSOE reviews the recommendations and any
results from the I&TSE processing. If the PSOE determines that
additional information is needed for analysis, they will request the
provider of the recommendations for more supporting data. If the PSOE
does not approve the recommendations, the results of the analysis and
recommendations are returned to the originator for further evaluation
and testing. If the PSOE approves the recommended algorithm
enhancements, the PSOE may submit the recommendations to the NPP/NPOESS
Algorithm CCB (TBR). The science algorithm updates, including change
logs, documentation, and any other files associated with the
recommendations are stored in the PSOE's configuration management system
(TBD). Additionally, the PSOE provides management directions to the
PEATEs, NICSE, I&TSE, and SD3E regarding schedules, priorities, etc...
Status reports from each of the elements are provided to the PSOE.

Scenario Steps:

Each of the elements may submit their recommendations to the PSOE in any
order. The sequence numbers are used to describe the scenario and to
show the flow of activity within each of the elements.

1.  The PEATEs Manage Software Configuration provides the Science Team
    with the *PEATEs science algorithm improvement recommendations*.

2.  The Science Team reviews the *PEATEs science algorithm improvement
    recommendations*. If they approve of the updates, they submit the
    *ST algorithm source code recommendations* to the PSOE. The *ST
    algorithm source code recommendations* are the PEATEs science
    algorithm improvement recommendations.

3.  The PSOE reviews the *ST algorithm source code recommendations* and
    provides feedback to the Science Team. The feedback may include a
    status of their review or a request for additional information to
    support the recommendations made by the Science Team.

4.  If additional information is requested, then the Science Team
    submits a data request to the PEATEs Process Science Data for
    additional data (i.e. data to support the need for updates to the
    science algorithms).

5.  The PEATEs Process Science Data processes the *ST data request* and
    provides any updated or new *Algorithms/source code* and related
    data sets from the Manage Software Configuration.

6.  Additionally, the PSOE may send *PEATEs management directions* to
    the PEATEs such as processing schedules and priorities, etc... The
    management directions may be direct feedback from the PSOE with
    regards to the science algorithm improvements or a request for
    data/information. The PEATEs Process Science Data function sends
    processing status reports to the PSOE.

7.  If there are calibration updates from NICSE, NICSE Export Data sends
    the *NICSE calibration LUT and NICSE calibration software
    recommendations* to the PSOE.

8.  PSOE may send *NICSE management directions* on processing priorities
    and/or a request for more information regarding the *NICSE's
    calibration LUT and software recommendations*.

9.  The NICSE Ingest Data ingests the management directions from the
    PSOE. The Radiometric Calibration and Geometric Calibration fulfill
    the PSOE request for data.

10. The NICSE Radiometric and Geometric Calibration provide the
    *Radiometric calibration LUT updates and Radiometric calibration
    software updates* based on the PSOE's request. The Geometric
    Calibration provides the *Geometric calibration LUT and Geometric
    calibration software updates* based on the PSOE's request. The
    updates from the Radiometric and Geometric functions are sent to the
    NICSE Export Data to again send to the PSOE, if necessary.

If the PEATEs use the I&TSE to validate their science algorithm
recommendations, then the I&TSE science algorithm improvement package
and I&TSE status are also sent to the PSOE.

11. The PSOE may send *I&TSE management directions* on processing
    priorities and/or request the I&TSE to run the recommendations that
    the PSOE has received in the I&TSE environment.

12. The I&TSE's Algorithm Development Area responds to the management
    direction from the PSOE by sending a *Data package* to the
    Mini-IDPS. This *Data package* includes data, algorithm, and
    processing requests.

13. The Mini-IDPS sends the *I&TSE products* to the Send to Out-bound
    site.

14. The resulting processing status and output from the Send to
    Out-bound site are then provided to the PSOE as the *I&TSE's science
    algorithm improvement package*. This package contains the results
    from the I&TSE processing of the PEATEs science algorithms or NICSE
    calibration updates.

15. The PSOE stores all science *Algorithm/source code* updates,
    documentation, etc... in their Configuration Management system.

16. The PSOE may decide to submit the science algorithm or calibration
    recommendations to the NPP/NPOESS Algorithm CCB (TBR) for further
    action.

17. The PSOE also provides the SD3E with management directions such as
    ingest and storage priorities. The SD3E provides reports on their
    current ingest status to the PSOE.

See Figure 4.2.1.9-1, Anomaly Detection Scenario.

**THIS PAGE INTENTIONALLY LEFT BLANK**

# Appendix A TABLE OF TBX {#appendix-a-table-of-tbx .unnumbered}

**Table of TBD**

  ------ ---------- ------------------- -------------------------------------
  TBD    Document   Section             Description

  TBD1   Ops        2.4                 Sounder PEATE will provide support in
                                        assessing and validating pre-launch
                                        and post-launch radiometric
                                        calibration and characterization of
                                        (ATMS and CrIS) instrument data.
                                        (TBD)

  TBD2   Ops        All                 Calibration RDRs

  TBD3   Ops        3.5                 As of the writing of this document,
                                        the data flow of RDRs and application
                                        packets, used for science data
                                        product generation, into the I&TSE is
                                        TBD.

  TBD4   Ops        4.2.1.9, Data       PSOE's configuration management
                    dictionary --       system (TBD).
                    Algo/Src Code       

  TBD5   Req        3.6.6 CARS          CARS Interface (TBD)
                    Interface (TBD)     

  TBD6   Req        3.6.7 Cal/Val       The SDS shall interface with the
                    Interface           Cal/Val as described in TBD ICD.

  TBD7   Req        3.7.1 Mission       The NPP SDS shall be ready at Launch
                    Support             (TBD).
  ------ ---------- ------------------- -------------------------------------

**Table of TBR**

  ------ ---------- ------------------------- -------------------------------------
  TBR    Document   Section                   Description

  TBR1   Ops        All                       NPP/NPOESS Algorithm CCB (TBR)

  TBR2   Ops/Req    2.5 Integration and Test  Support will be provided by I&TSE for
                    System Element            converting and running algorithms
                                              \[TBR\].

  TBR3   Req        3.2.1.5 Forward Algorithm The PSOE shall have the capability to
                    Improvement/Enhancement   forward algorithm
                    Recommendation            improvement/enhancement
                                              recommendations to the NPP/NPOESS
                                              Algorithm CCB (TBR).

  TBR4   Req        3.6.1 Archive and         The SDS shall interface with the ADS
                    Distribution Segment      through their public interface for
                    (ADS)                     NPP, xDR, IPs, and ancillary data.
                                              (TBR).

  TBR5   Req        3.7.3 Availability        The NPP SDS shall have an operational
                                              availability, Ao, of .96 \[TBR\].

  TBR6   Req        Appendix D -- Glossary    High Rate Data (HRD): Refers to the
                                              realtime data link to field terminals
                                              which contains data at all channels
                                              (TBR) at the smallest scale
                                              horizontal spatial resolution (or
                                              cell size) required.
  ------ ---------- ------------------------- -------------------------------------

**Table of TBS**

  ------ ---------- --------------------- -------------------------------------
  TBS    Document   Section               Description

  TBS1   Ops        3.4.4 Process Science The Sounder PEATE will perform their
                    Data                  own independent analysis of
                                          radiometric and geometric calibration
                                          and validation activities in support
                                          of ATMS and CrIS calibration and
                                          validation. As of the writing of this
                                          document, their characterization
                                          activities has not yet been defined.
                                          (TBS)

  TBS2   Req        Appendix D --         State of Health: TBS
                    Glossary              
  ------ ---------- --------------------- -------------------------------------

# Appendix B ACRONYMS {#appendix-b-acronyms .unnumbered}

A listing of the acronyms and abbreviations used in this specification
is provided below.

A~o~ Operational Availability

ADS Archive and Distribution Segment

ADP Ancillary Data Providers

AFWA Air Force Weather Agency

Anal. Analysis

ANSI American National Standards Institute

ATBD Algorithm Theoretical Basis Document

ATMS Advanced Technology Microwave Sounder

BB Black Body

BRDF Bidirectional Reflectance Distribution Function

BTDF Bidirectional Transmissive Distribution Function

C3S Command, Control and Communications Segment

CARS Climate Analysis and Research Service

CCB Configuration Control Board

CCS Climate Calibration Service

CDMS Climate Data Management Service

CDPs Climate Data Products

CDRs Climate Data Records

CLASS Comprehensive Large Array-data Stewardship System

CM Configuration Management

CMS Climate Mission Storage

COTS Commercial Off-the-Shelf

CrIS Cross-Track Infrared Sounder

DCAVS Distributed CDR/EDR Algorithm Validation Service

DDR Data Delivery Report

DEM Digital Elevation Model

Demo. Demonstration

DFD Data Flow Diagram

DN Delivery Notification

DoD Department of Defense

DQM Data Quality Management

EDRs Environmental Data Records

EDU Engineering Development Units

EOS Earth Observing System

EOSDIS Earth Observing System Data and Information System

ESE Earth Sciences Enterprise

GSFC Goddard Space Flight Center

I&TSE Integration and Test System Element

ICD Interface Control Document

IDPS Interface Data Processing Segment

Insp. Inspection

IP Intermediate Products

IPO Integrated Program Office

IRD Interface Requirements Document

ISF Integrated Support Facility

IT Information Technology

JPL Jet Propulsion Laboratory

LEO&A Launch, Early Orbit, and Activation

LSS Launch Support Segment

LTA Long Term Archive

LUT Look-up Tables

MDT Mean Down Time

MODIS Moderate Resolution Imaging Spectrometer

MODAPS MODIS Data Processing System

MRS Mission Operations Concept

MTBDE Mean Time Between Downing Events

N/A Not Applicable

NASA National Aeronautics and Space Administration

NESDIS National Environmental Satellite, Data, and Information Service

NEXT NPP EDU eXchange Toolkit

NGST Northrop Grumman Space & Mission Systems Corp. Space Technology

NICSE NPP Instrument Calibration and Support Element

No. Number

NOAA National Oceanic and Atmospheric Administration

NPOESS National Polar-orbiting Operational Environmental Satellite
System

NPP NPOESS Preparatory Project

NWP Numerical Weather Prediction

OMPS Ozone Mapper/Profiler Suite

OSHA Occupational Safety and Health Administration

PDR Product Subscription Request

PEATE Product Evaluation and Analysis Tool Element

POS Performance and Operations Specification

POSIX Portable Operating System Interface for Computer Environments

PSOE Project Science Office Element

PST Project Science Team

RDRs Raw Data Records

RSB Reflective Solar Band

RSR Relative Spectral Response

RVS Response Versus Scan Angle

SD Solar Diffuser

SD3E Science Data Distribution and Depository

SDRs Sensor Data Records

SDS Science Data Segment

SDSM Solar Diffuser Stability Monitor

SER Scientific, Engineering and Research

SI&T System Integration and Test

SRD Sensor Requirements Document

ST Science Team

TBD To Be Determined

TBR To Be Resolved

TBS To Be Supplied

TDR Temperature Data Record

TEB Thermal Emissive Band

TEUs Telemetry in Engineering Units

TV Thermal Vac

UTC Universal Time Coordinate

VIIRS Visible Infrared Imager Radiometer Suite

VDD Version Description Document

xDRs RDR, SDR, EDR, and TDR

# Appendix C GLOSSARY {#appendix-c-glossary .unnumbered}

**Ancillary Data:** Data outside of the NPP mission system used to
generate NPP

products, e.g., NWP, DEMs.

**Application Processing Systems:** Institution systems located at the
Centrals which receive data from IDPS.

**Authentication:** Security measure designed to establish the validity
of a transmission, message, or originator. Authentication provides the
assurance that information transmitted from a claimed source (i.e., a
source\'s identity) actually came from that source.

**Auxiliary Data:** Data generated/provided by the spacecraft to be
either included with the instrument data and/or transmitted as part of
the S-band telemetry data

**Browse:** A sub-sampled product used as an extension of the metadata
to aid users in data mining activities.

**Calibration maneuver:** A spacecraft attitude adjustment made to view
a calibration source (i.e. deep space, moon).

**Climate Data Record (CDR):** Climate data records are products of the
science processing segment only and are science products that are
different from or further processed than the operational EDRs. CDRs are
products generated from Level 2 processing or higher.

**Climate Users:** Global change and climate research communities.

**Cloud:** An aggregate of minute non-precipitating water and/or ice
particles in the atmosphere above the Earth's surface. "Cloud" is always
to be interpreted to mean "detectable cloud".

**Data Delivery Report:** A data delivery report (DDR) from the
Interface Data Processing Segment (IDPS) is delivered to the SDS and
summarizes all products delivered to SDS. The report contains
information about the distributed data products including filename,
directory, location, and other information. A DDR corresponds to a data
delivery request and identifies the data that is delivered to the
directory specified in the data delivery request (or product
subscription). The DDR is stored in the same directory as that specified
in the data delivery request. A report is produced describing multiple
data products delivered over a pre-defined time period (1 minute to 105
minutes inclusive) or if the number of products delivered reaches a
threshold (between 50-150 inclusive).\*

**Encryption:** Security measure designed to prevent unauthorized access
to data. Encryption is achieved by converting plain text to equivalent
cipher text by means of a

code.

**Environmental Data Record (EDR):** Data records that contain the
environmental parameters or imagery required to be generated as user
products as well as any ancillary data required to identify or interpret
these parameters or images. EDRs are generally produced by applying an
appropriate set of algorithms to Raw Data Records (RDRs).

**Global Positioning System (GPS):** A constellation of satellites
broadcasting position and time reference information.

**High Rate Data (HRD):** Refers to the real-time data link to field
terminals which contains data at all channels (TBR) at the smallest
scale horizontal spatial resolution (or cell size) required.

**Intermediate Products (IPs):** An intermediate product is defined as a
data subset or retrieval by-product that is required within another
primary data product's generation sequence or is used as an input to
secondary processing or analysis; it can be conveniently and efficiently
produced during the primary processing. IPs are fundamentally defined as
both of the following:

1.  \"Product-level\" having a physical significance such as the cloud
    mask or surface reflectance products, and

2.  \"Truly intermediate\" to the processing of EDRs, in that they are
    predecessors to EDR production following SDR generation:

```{=html}
<!-- -->
```
a)  IPs that are required in EDR processing do not necessarily require
    short-term retention for access or long term archiving (LTA), in
    that they may exist only during EDR processing.

b)  IPs are not just \"inter-modular\"; for EDRs produced from common
    core modules, they may also be \"intra-modular\" and not be easily
    accessed or archived without separation of their code in the
    operational system.

**Level 1B Products:** Raw instrument data that has been radiometrically
corrected and geolocated. Similar to RDRs, except they are fully
time-ordered, overlap removed, and usually reprocessed.

**Metadata:** Information about data. Provides a description of the data
including: instrument, type of data, location of data, and quality of
data.

**Mission Lifetime:** The duration of the on-orbit phase of the NPP
satellite.

**Mission management:** Overall mission operations management
responsible for managing, tracking, reporting, and decision making
aspects of activities throughout the mission lifetime; includes space
and ground management and represents both Programs (EOS and NPOESS) in
accomplishing mission objectives.

**Operational Algorithms:** CM approved algorithms and source codes run
under the operational IDPS environment.

**Operational availability (Ao):** The probability that a system is
operable and ready to perform its mission at any given time. Ao is a
function of mean time between critical failure (MTBCF) and mean time to
restore function (MTTRF) and shall be calculated as:
Ao=MTBCF/(MTBCF+MTTRF)

**Position Knowledge:** On-orbit position of the Satellite navigational
reference base, determined through the use of GPS and on-board
processing.

**Preventative Maintenance:** Planned maintenance or upgrades to
systems. Preventative maintenance is not assessed against Ao.

**Probability of success (Ps):** The probability that a given segment,
element, and/or component of the mission will continue to operate over a
specified time. Typically applies to the launch vehicle and the
Satellite.

**Raw Data Record (RDR):** Full resolution, unprocessed digital sensor
data, time-referenced and earth (GEO) located (or orbit-located for
in-situ measurements), 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 should be unprocessed
with the following exceptions: time delay and integration (TDI),
detector array non-uniformity correction (i.e. offset and responsivity
equalization), and lossless data compression are allowed. All
calibration data will be retained and communicated to the ground without
lossy compression. Note that for the real time transmission of raw data
to field terminals, lossy compression is allowed. Additionally, reduced
resolution is allowed in transmission of raw data to low data rate field
terminals.

**Real-Time S-band Telemetry:** Real-time engineering data concurrent
with either stored engineering data or processor data dump.

**Reliability:** The probability that an instrument can perform its
intended function of producing radiances of sufficient quality to meet
the EDR requirements over the designed operational life.

**Reprocessing:** Processing of the accumulated data holdings with new
algorithms and/or calibration information in order to maintain a climate
record.

**Safe Hold Mode:** A nadir-facing, power-positive, and thermally safe
mode.

**Satellite Commands Types:**

**Relative Time Sequence** - commands that are required to be executed
in a relative sequence to one another

> **Realtime** - commands executed upon receipt and acceptance by the
> spacecraft
>
> **Absolute** - commands that are to be executed at a specific time
>
> **Loads** - a set of commands that are stored and executed at a future
> time

**Science Algorithms:** Algorithms and source codes used in generating
science (xDR, IPs, etc...) related products.

**Sensor Data Record (SDR):** Full resolution sensor data that are time
referenced, earth (GEO) located (or orbit-located for in-situ
measurements), and calibrated by applying the ancillary information
including radiometric and geometric calibration coefficients and
georeferencing parameters such as platform ephemeris. These data are
processed to sensor units (e.g. radar backscatter cross section,
brightness temperature, radiance, etc.). Calibration, ephemeris, and any
other ancillary data necessary to convert the sensor units back to
sensor raw data (counts) are included.

**Spacecraft clock correlation:** The accuracy of Satellite on-board
time determination, using GPS and on-board processing.

**Spacecraft diary:** Information on spacecraft position, velocity,
temperatures, telemetry and time provided to the instrument to be
included in the instrument packets.

**State of Health:** TBS

**Stored Mission Data (SMD):** CADUs (frames) containing packets of
science data packets from the instruments, and engineering, health, and
safety packets from the Spacecraft and instruments.

**Uptime Availability:** is the probability that a system is operable
and ready to perform its mission at the time required to operate given
the operational scenario for the system.

Uptime Availability is a function of mean time between maintenance
(MTBM) and mean time to restore (MTTR) scaled by the operational duty
cycle (C), where duty cycle is fraction of time the system will actually
be required to operate to achieve its stated purpose. Uptime
Availability shall be calculated as: Uptime

Availability=MTBF/(MTBF+MTTR \* C) Preventive Maintenance downtime is
included only to the extent that it impacts the expected operations
scenario of the system.

**Verification:** The process of ensuring mission/segment requirements
is satisfied. Verification occurs using one or more methods (analysis,
test, demonstration, or inspection).

# Appendix D DATA DICTIONARY {#appendix-d-data-dictionary .unnumbered}

**ADP alternate ancillary data**

> \*The alternate ancillary data are data from outside of the NPP
> mission system used to generate NPP products (e.g. NWP, DEMs). SDS may
> generate EDRs locally with ancillary data other than the NPOESS
> Official Ancillary Data sets. This data is generated/provided by the
> spacecraft to be either included with the instrument data and/or
> transmitted as part of the S-band telemetry data.\*

**ADP Data**

> \*The ADP Data are data requested by the PEATEs, NICSE, or SD3E. These
> data include the ADP in-situ data and the ADP alternate ancillary
> data.\*

**ADP in-situ data**

> \*The Ancillary Data Providers (ADP) in-situ data are post-launch data
> collected in-situ from the instruments on the ground at the time when
> the image spacecraft image was collected.\*

**ADP transfer request**

> \*SDS sends a transfer request for the alternate ancillary data from
> the Ancillary Data Providers (ADP).\*

**ADS ad-hoc request**

> \*Ad --hoc requests are requests for a few specific products that
> otherwise would not require the use of product subscriptions or
> standing orders. These requests are fulfilled using currently
> available data or the first available data that matches the request
> criteria.\*

**ADS ancillary data**

> \*This includes the official ancillary data and the auxiliary data.
> The official ancillary data required by some algorithms to generate
> NPOESS Data products. NOAA acquires the Official Dynamic Ancillary
> Data from sources external to NPOESS. The list of official dynamic
> ancillary data files that SDS ingests are described in the Common
> DFCB-External, Volume VI, D34862-06, section 2.0. The ancillary data
> also includes the auxiliary data. The auxiliary data includes the two
> line elements (TLE) and the IDPS Processing Coefficients. The TLEs is
> a file representing two lines of ASCII data. The data included in the
> file provides a compact means of predicting NPP/NPOESS ephemeris. The
> IDPS Processing Coefficient Tables define the coefficient values used
> in the generation of data products (2 types: IDPS coefficients used in
> SDR/TDR processing, and IDPS coefficients used in EDR processing).\*

**ADS calibration product**

\*

1.  Sensor bias data, which is a DQM product, a monthly product from
    IDPS to the ADS. It contains records of sensor calibration changes
    and records required to characterize sensor biases.

2.  Sensor calibration tables are data that is used to calibrate sensor
    measurements on-board the spacecraft. These data are under CCB
    control, to ensure that the proposed baseline updates have met the
    appropriate criteria (testing, validation, verification)

3.  Data quality threshold tables are parameters that determine when
    IDPS generates data quality notification messages. Only the
    CCB-controlled baseline version of the data quality threshold tables
    are in the ADS.\*

**ADS Data**

> \*The ADS Data are the data requested and ingested by the SDS
> elements. The data includes ADS xDRs, ADS IPs, ADS ancillary data, ADS
> calibration product, ADS operational algorithms.\*

**ADS data queries and requests**

> \*Data queries and requests searches for products that are currently
> available in the ADS Long Term Archive (LTA).\*

**ADS IPs**

> \*SDS receives selected Intermediate Products (IPs) from the ADS or
> selected IPs with substitute ancillary data.

IPO has agreed to release the following IPs to ADS:

> . Total Column O3 (CrIS)
>
> . O3 Nadir Profile
>
> . VIIRS Cloud Mask
>
> . Active Fire Mask (pixel level)
>
> . Quarterly Surface Type

. Also under consideration:

> . Cloud Top Temp & Pressure (pixel level)
>
> . Surface Reflectance (VIIRS)\*

**ADS operational algorithms**

> \*The Configuration Management (CM) approved operational algorithms
> and source code (i.e. xDR algorithms, calibration software, etc...)
> run under the operational IDPS environment. These files include source
> code files and any other related support files needed to run the
> software on compatible system. Also included can be the Data Exception
> Threshold tables, Algorithm LUTs, Official Static Ancillary data and
> Database updates. Also included can be the APID/VCID Mapping (SMD).
> The Software Version Description Document (VDD) will also be delivered
> with software upgrades. \*

**ADS product subscription**

> \*The product subscriptions are standing orders/requests. These
> subscriptions are fulfilled whenever the appropriate data is available
> or becomes available in the future.\*

**ADS query and request status**

> \*A response or status as a result of submitting the product
> subscription or an ad-hoc request. A data delivery notice (DN) is
> provided based on the request.\*

**ADS xDRs**

> \*The xDR products from ADS include the RDRs, SDRs, EDRs, TDRs and
> their associated metadata.\*

**Algo Dev Products**

> \*The algorithm development products are the items needed to build the
> source code and setup the environment to correctly run the science
> algorithms in the I&TSE environment. These products include the
> recommended algorithm enhancements, a subset of the xDRs needed for
> testing, a sample data output, calibration product, ancillary data,
> alternate ancillary data, and other associated files such as test
> scenarios or build files.\*

**Algo/Src Code**

> \*The science algorithms and source code recommended by the SDS
> elements that the PSOE may decide keep track of in their configuration
> management system (TBD).\*

**Algorithms/source code**

> \*The version controlled science algorithms and source code (i.e.
> production software) developed by the PEATEs or acquired from the
> Science Team.\*

**Analysis products**

> \*Analysis tools (comparison, plotting) previously developed or
> acquired by the PEATEs that aid in the analysis of the data. (i.e. IDL
> code, data visualization tools, etc...) The analysis products are also
> products generated by the PEATEs during their processing. These may
> include the new tools that they've recently developed or science
> products generated during processing.\*

**Calibration Problem Report**

> \*The PEATEs submit a report to the NICSE regarding a calibration
> problem. The report may include the date/time of the data in question,
> a detailed description of the problem, sample data output, the
> calibration look-up table or software that are in question, etc...\*

**Calibration RDRs (TBD)**

> \*The calibration RDRs are Science RDR with calibration data unpacked.
> The calibration RDRs are produced by the sensor for express purpose of
> determining/monitoring sensor calibration.\*

**Cataloged data**

> \*The PEATEs keep track of the data files and products that it ingests
> and the data files and products generated as a result of their
> internal processing in a small database.\*

**Correlative data**

> \*Data from the PEATEs existing processing environment (i.e. MODAPS
> for Land, OMIDAPS for Ozone, etc...) that may include flagging and
> masking algorithms, ground truth measurements, coincident instrument
> comparison data, instrument data, pre-launch algorithms and test data,
> etc. \*

**Data package**

> \*This data package includes the same items in the Algo Dev Products;
> however, the environment and build files have been developed and
> correctly setup to run the recommended science algorithm package. This
> data package could also be a request from the I&TSE Algorithm
> Development Area for data based on I&TSE management directions from
> the PSOE.\*

**Data product listings**

\*A listing of the current products stored in the SD3E.\*

**Data Problem Report**

> \*The PEATEs submit a formal problem report to the ADS. The report may
> include the date/time of the data in question, a detailed description
> of the problem, sample data output, etc...\*

**Data listing request**

> \*Internal to the SD3E processing, this data listing request provides
> a list of the current data files residing in the SD3E data store. This
> request can be a request made by the SDS elements or for SD3E to check
> what data files are currently in the data store.\*

**Earth polar motion**

> \*Predictions and measurements of the motion of the Earth\'s
> geographic pole about the Earth\'s mean rotation axis. It also
> contains the difference between time based on the Earth rotation
> corrected for polar motion (Universal Time 1 \-- UT1) and time based
> on atomic clocks (Universal Time Coordinated \-- UTC), including
> leap-seconds.
>
> .\*

**EDR**

> \*An Environmental Data Record (EDR) contains the environmental
> parameters or imagery required to be generated as user products as
> well as any ancillary data required to identify or interpret these
> parameters or images. EDRs are generally produced by applying an
> appropriate set of algorithms to RDRs.\*

**EDR (for Geometric)**

\* See EDR.\*

**Engineering data**

> \*The engineering data include the two line elements, the telemetry
> engineering units, the instrument logs, the STA reports, etc\... A
> complete list of the reports are shown in the C3S Extranet Web Data
> Table in the NPOESS to NPP SDS ICD.\*

**Geo Cal Data**

> \*The geometric calibration data needed for performing Geometric
> Calibrations may include Geo cal eval results, RDR (for Geometric),
> VIIRS Geolocation SDR, EDR (for Geometric), and Earth polar motion.\*

**Geo Cal Data Response**

> \*The latest geometric calibration look-up tables and software needed
> by the Reflective Solar Band Calibration.\*

**Geo Cal Data Request**

> \*A request from the Radiometric Calibration function to the Geometric
> Calibration function for the latest geometric calibration look-up
> tables and software.\*

**Geo cal eval results**

> \*The results from the PEATEs evaluation of the calibration look-up
> table and/or software updates. The Geometric Calibration uses these
> results to determine if additional updates or if the current updates
> provide the data output products they are expecting.\*

**Geo cal LUT updates**

> \*The updates as a result of fixes or enhancements to the geometric
> calibration look-up tables.\*

**Geo cal software updates**

> \*The updates as a result of fixes or enhancements to the geometric
> calibration software.\*

**Geo Quality control and response**

> \*Geo Quality control request
>
> The interface between the NICSE Geometric Calibration and the PEATEs
> for quality control of the calibration updates. The NICSE may
> occasionally use the PEATEs to test changes and updates made to the
> calibration look-up tables and software.

Geo Quality control response

> The response to the quality control request.\*

**I&TSE algo status**

> \*The I&TSE provides an informal status to the PEATEs regarding the
> processing results of the PEATEs Science algorithm improvement
> pre-pkg.\*

**I&TSE Ingested Data**

> \*The ingested data include the recommended algorithm enhancements, a
> subset of the xDRs needed for testing, a sample data output,
> calibration product, ancillary data, alternate ancillary data, and
> other associated files such as test scenarios or build files needed to
> correctly set-up the I&TSE environment to run the codes for data
> processing checks.\*

**I&TSE management direction/reports**

\*I&TSE management direction

> The PSOE provides management direction on processing, schedules,
> priorities, mission and science guidance, algorithm enhancement
> check-out, etc...

I&TSE management reports

The I&TSE provides processing status reports to the PSOE.\*

**I&TSE products**

> \*The processing results, SDR, EDR, or IP products generated in the
> I&TSE environment. See also definition for SDR, EDR, and IP. \*

**I&TSE science algo imp pkg**

> \*This is the science algorithm recommendation package provided by the
> PEATEs to the I&TSE, that the I&TSE has performed checks. These
> consistency checks are to determine if the recommended science
> algorithm enhancements produce the expected output when executed in
> the IDPS operational environment. The package includes the algorithm
> recommendations, a sample output of the run, and the results of the
> algorithm execution. The I&TSE submit this package to the PSOE, if
> requested by the PSOE.\*

**I&TSE status**

> \*The informal status reports that the I&TSE submit to the PSOE
> regarding the science algorithm processing. The report may include the
> status of data reprocessing, data processing, performance statistics,
> etc...\*

**IDPS ad-hoc request**

\*See NPOESS Data Product Query and Requests\*

**IDPS Data**

> \*The IDPS Data are the data requested and ingested by the SDS
> elements. The data includes the NPOESS Data Products including
> Metadata (or IDPS RDR products) and the IDPS Data Delivery Report.\*

**IDPS data delivery reports**

> \* A data delivery report (DDR) from the Interface Data Processing
> Segment (IDPS) is delivered to the SDS and summarizes all products
> delivered to SDS. The report contains information about the
> distributed data products including filename, directory, location, and
> other information. A DDR corresponds to a data delivery request and
> identifies the data that is delivered to the directory specified in
> the data delivery request (or product subscription). The DDR is stored
> in the same directory as that specified in the data delivery request.
> A report is produced describing multiple data products delivered over
> a pre-defined time period (1 minute to 105 minutes inclusive) or if
> the number of products delivered reaches a threshold (between 50-150
> inclusive).\*

**IDPS Operational Software**

> \*The CM-approved IDPS operational algorithms and software that are
> being used in the IDPS operational environment to produce the
> necessary NPP products. \*

**IDPS product subscription**

\*See NPOESS Data Product Query and Requests\*

**IDPS RDR products**

\* See NPOESS Data Products including Metadata\*

**In-bound Data**

> \*The data products stored in the SD3E in-bound data store include
> IDPS RDR products, ADS xDRs, ADS IPs, ADS ancillary data, ADS
> calibration product, and ADS operational algorithms.\*

**Incomplete data status**

> \*The incomplete data status consists of information that indicate if
> the IDPS or the ADS data transfer was incomplete and which files are
> incomplete or unverifiable. This status results in an ad-hoc request
> for retransmission of the data from the corresponding segment.\*

**Ingested Data**

> \*The data that SD3E has ingested from the IDPS and ADS. See
> definition for IDPS Data and ADS Data.\*

**NICSE-ADP Transfer Request**

> \*NICSE request transfer of alternate ancillary data from the ADP. See
> also ADP transfer request.\*

**NICSE-ADS ad-hoc request**

> \*NICSE generates an ad-hoc request to the ADS. See also ADS ad-hoc
> request.\*

**NICSE cal LUT recommendations**

> \*The NICSE has tested and validated, with the PEATEs, their
> recommended calibration look-up table updates. The NICSE submits these
> recommendations to the PSOE for review.\*

**NICSE cal LUT updates**

> \*The NICSE has made updates to the calibration look-up tables. The
> NICSE provides the PEATEs with their recommended updates so that the
> PEATEs may validate the recommended changes to the calibration look-up
> tables.\*

**NICSE cal software recommendations**

> \*The NICSE has tested and validated, with the PEATEs, their
> recommended calibration software updates. The NICSE submits their
> recommendations to the PSOE for review.\*

**NICSE cal software updates**

> \*The NICSE has made updates to the calibration software. The NICSE
> provides the PEATEs with their recommended updates so that the PEATEs
> may validate the recommended changes to the calibration software.\*

**NICSE engineering data request and C3S response**

> \*NICSE-C3S engineering data request
>
> The NICSE engineering data request may include: two line elements, the
> telemetry engineering units, the instrument logs, the STA reports,
> etc\... A complete list of the reports are shown in the C3S Extranet
> Web Data Table in the NPOESS to NPP SDS ICD.

NICSE-C3S response

> The C3S response is the status as a result of the exchange of the
> requested data and reports.\*

**NICSE Ingested ADP Data**

> \*If the NICSE requires alternate ancillary data, the NICSE directly
> request the data from ADP. These data may include the ADP in-situ data
> and the ADP alternate ancillary data.\*

**NICSE Ingested ADS Data**

> \*The NICSE uses the ADS as a secondary source for data if the SD3E no
> longer has the data in their data store. The data NICSE ingests from
> the ADS may include:.ADS xDRs, ADS IPs, ADS ancillary data, ADS
> calibration product, ADS operational algorithms.\*

**NICSE Ingested SD3E Data**

> \*These data includes the SD3E-NICSE calibration product, SD3E-NICSE
> xDRs, and SD3E-NICSE operational algorithms.\*

**NICSE instrument service request and PSOE response**

> \*The NICSE determine that an instrument service request may be
> needed. The NICSE submit their request to the PSOE. The PSOE reviews
> the request and determines whether or not one is needed. If so, the
> PSOE submits the request to C3S.

NICSE-PSOE instrument service request

See Appendix E for a list of possible requests.

NICSE-PSOE response

> See Appendix F for a list of possible responses to the request\*

**NICSE management direction/reports**

\*NICSE management direction

> The PSOE provides management direction on processing, schedules,
> priorities, mission and science guidance, etc...

NICSE management reports

The NICSE provides processing status reports to the PSOE.\*

**NICSE-PEATES quality control and response**

> \*NICSE-PEATEs quality control request
>
> The interface between the NICSE and the PEATEs in ensuring the quality
> of the calibration updates.

NICSE-PEATEs quality control response

> The PEATEs response to the quality control request.\*

**NICSE product queries and ADP response**

\*The transfer of data products between ADP and NICSE includes:

NICSE-ADP product queries

> . ADP transfer request

NICSE-ADP response

> . ADP in-situ data
>
> . ADP alternate ancillary data\*

**NICSE product queries and ADS response**

\*The transfer of data products between the NICSE and the ADS includes:

NICSE-ADS product queries:

. ADS product subscription

. ADS ad-hoc requests

.ADS data queries and requests

NICSE-ADS response:

.ADS xDRs

.ADS IPs

.ADS ancillary data

.ADS calibration product

.ADS operational algorithms

> .ADS query and request status\*

**NICSE request and NEXT response**

\*NICSE-NEXT request

> The NICSE is provided a NEXT account to log onto the NEXT system. The
> NICSE will search the NEXT system for the products they need.

NICSE-NEXT response

> The NEXT response is the status as a result of the user logging onto
> the system and the response to the request for pre-launch algorithms
> and test data.\*

**NICSE Requested listings and SD3E response**

\*NICSE Requested listings

> Requested listings may be in the form of a query, a product
> subscription (standing orders), or an ad-hoc requests for a list of
> files in SD3E, an order for new files that are in addition to the
> nominal file set already ingested by SD3E, or a request for
> retransmission of data files with problems as determined by the NICSE.
> It is assumed that the NICSE have checked the ADS catalog for valid
> files before making such a request to SD3E.

NICSE Requested listing response

> The SD3E response to the NICSE request for data to be ingested.\*

**NPOESS Data Products including Metadata**

> \*The NPOESS Data Products generated by the IDPS for the SDS consists
> of RDRS. The RDRs include the Science RDRs and Diagnostic RDRs.
> Metadata is generated for all NPOESS RDRS and is included in the HDF5
> files delivered to the SDS with the RDRs.\*

**NPOESS Data Product Query and Requests**

> \*NPOESS, through the IDP Data Delivery Subsystem, provides the
> capability for the SDS to interact with NPOESS to place queries and
> requests for NPOESS Data Products. The data products that can be
> ordered via this interface include RDRs (science RDRs, diagnostic
> RDRs) This interface provides the capabilities to query the IDPS
> system catalog on data currently available for retrieval, placing
> requests for data for distribution of data to SDS, modifying existing
> requests, and requesting status of existing requests. GUIs/API provide
> the ability to query NPOESS for an inventory of data currently
> available for distribution. Requests for NPOESS Deliverable Data
> Products may be either standing request or ad-hoc type requests.
> Standing requests are fulfilled whenever the appropriate data is
> currently available or becomes available. The ad-hoc requests are
> fulfilled by currently available data or the first available data that
> matches the request criteria. Existing requests can also be modified,
> and the status of existing requests may be requested.\*

**NPOESS Data Product Query and Request status**

> \*This interface responds to requests from the NPOESS Data Product
> Query and Request. Specifically, a response or status information is
> returned for each of the four types of requests: response to a query
> of the system catalog returning data currently available for
> retrieval; response to a request for data delivery to the SDS;
> response to a request to modify an existing data delivery request; and
> response to a request for the status of an existing data delivery
> request.\*

**PEATEs-ADS ad-hoc request**

\*See ADS ad-hoc request.\*

**PEATEs-ADP ad-hoc request**

\*See ADP ad-hoc request.\*

**PEATEs engineering data request and C3S response**

> \*PEATEs engineering data request
>
> The PEATEs engineering data request may include: two line elements,
> the telemetry engineering units, the instrument logs, the STA reports,
> etc\... A complete list of the reports are shown in the C3S Extranet
> Web Data Table in the NPOESS to NPP SDS ICD.

PEATEs-C3S response

> The C3S response is the status as a result of the exchange of the
> requested data and reports.\*

**PEATES Ingested ADP Data**

> \*The data the PEATEs request from the ADP may include the ADP in-situ
> data or ADP alternate ancillary data.\*

**PEATES Ingested ADS Data**

> \*If the SD3E no longer has the requested data available, the PEATEs
> use the ADS as a secondary source to retrieve the science data files
> and algorithms. These products include: ADS xDRs, ADS IPs, ADS
> ancillary data, ADS calibration product, and ADS operational
> algorithms.\*

**PEATES Ingested SD3E Data**

> \*The data that PEATEs retrieves from the SD3E, primary source, may
> include: NPOESS Data Products including Metadata (RDRs), ADS xDRs, ADS
> IPs, ADS ancillary data, and ADS calibration product.\*

**PEATES Instrument service request and PSOE response**

> \*The PEATEs determine that an instrument service request may be
> needed. The PEATEs submit their request to the PSOE. The PSOE reviews
> the request and determines whether or not one is needed. If so, the
> PSOE submits the request to C3S.

PEATEs-PSOE instrument service request

See Appendix E for a list of possible requests.

PEATEs-PSOE response

> See Appendix F for a list of possible responses to the request\*

**PEATEs management direction/reports**

\*PEATEs management direction

> The PSOE provides management direction on processing, schedules,
> priorities, mission and science guidance, etc...

PEATEs management reports

The PEATEs provides processing status reports to the PSOE.\*

**PEATES product queries and ADP response**

\*The transfer of data products between ADP and PEATES includes:

PEATEs-ADP product queries

> . ADP transfer request

PEATEs-ADP response

> . ADP in-situ data
>
> . ADP alternate ancillary data\*

**PEATES product queries and ADS response**

> \*The transfer of data products between the PEATEs and the ADS
> includes:

PEATEs-ADS product queries:

. ADS product subscription

. ADS ad-hoc requests

.ADS data queries and requests

PEATEs-ADS response:

.ADS xDRs

.ADS IPs

.ADS ancillary data

.ADS calibration product

.ADS operational algorithms

.ADS query and request status\*

**PEATES request and NEXT response**

\*PEATEs-NEXT request

> The PEATEs is provided a NEXT account to log onto the NEXT system. The
> PEATEs will search the NEXT system for the products they need.

PEATEs-NEXT response

> The NEXT response is the status as a result of the user logging onto
> the system and the response to the request for pre-launch algorithms
> and test data.\*

**PEATES Requested listings and SD3E response**

\*PEATEs Requested listings

> Requested listings may be in the form of a query, a product
> subscription (standing orders), or an ad-hoc requests for a list of
> files in SD3E, an order for new files that are in addition to the
> nominal file set already ingested by SD3E, or a request for
> retransmission of data files with problems as determined by the
> PEATEs. It is assumed that the PEATEs have checked the ADS catalog for
> valid files before making such a request to SD3E.

PEATEs Requested listing response

> The SD3E response to the PEATEs request for data to be ingested.\*

**PEATEs Science algorithm imp pre-pkg**

> \*The PEATEs may optionally use the I&TSE to perform algorithm
> enhancement check-out. If so, the PEATEs provide the science algorithm
> improvement pre-package to the I&TSE. The package includes the
> recommended algorithm enhancements, a subset of the xDRs needed for
> testing, a sample data output, calibration product, ancillary data,
> alternate ancillary data, and other associated files such as test
> scenarios or build files needed to correctly set-up the I&TSE
> environment to run the codes for data processing checks. The package
> must be complete and require minimal modification to run.\*

**PEATES science algo imp rec**

> \*This is an update to science algorithms either as a result of a
> correction to a problem discovered in the data or the source code or
> an enhancement to the algorithms based on recommendations from the
> Science Team. If requested by the Science Team, the PEATEs submit
> these recommended science algorithm updates to the PSOE.\*

**PEATES status**

> \*The informal status reports that the PEATEs submit to the PSOE. The
> report may include the status of data reprocessing, algorithm
> processing, data processing, performance statistics, results, etc...
> based on xDR evaluation results and algorithm enhancements.\*

**PEATES stored products**

> \*All products ingested, developed, acquired, or generated during the
> PEATEs processing are housed in their local data store. These products
> include the Cataloged data, Science products, Analysis products,
> Correlative data, and xDRs, IPs, metadata.\*

**PEATEs xDR Products**

> \*The xDRs that the PEATEs generate during their science data
> processing, during algorithm enhancements, or during xDR quality
> assessments.\*

**Pre-launch algo & test data (or Pre-launch algo and test data)**

> \*The NPP instrument algorithm and source code for SDRs or EDRs and
> any support files such as ancillary data files, look-up tables, etc...
> These data are retrieved from the NEXT system and used for pre-launch
> characterization and calibration for the VIIRS instrument.\*

**Problem Report/Response**

> \*The problem report is a report from the Science Team regarding
> problems with the science data (i.e. xDRs, etc...) to the PEATEs. The
> report may include date/time of the data in question, a detailed
> description of the problem, a sample data output, etc... The PEATEs
> responds to the Science Team with their results from the analysis of
> the problem.\*

**Product listings**

> \*A listing of the current products stored in the SD3E.\*

**PSOE instrument service request and C3S response**

> \*PSOE-C3S instrument service request
>
> A list of instrument service requests are in Appendix E.

PSOE-C3S response

> A list of the instrument service response reports are in Appendix F.\*

**PSOE response**

> \*The PSOE may respond with feedback to the recommendations made by
> the Science Team. The feedback may be a request for additional data or
> to provide status regarding submission of algorithms to the NPP/NPOESS
> Algorithm CCB (TBR)\*

**PSOE science algo imp rec**

> \*The PSOE submits the recommendations from the PEATEs/ST or NICSE to
> the NPP/NPOESS Algorithm CCB (TBR). The science algorithm improvement
> recommendations may include updates, corrections, or enhancements to
> the operational xDR algorithms or calibration LUT and software.\*

**Rad Cal Data**

> \*The data needed by the Radiometric Calibration function for
> processing. These data may include Rad cal eval results, RDR (for
> Radiometric), Calibration RDRs (TBD), SDR algorithm/source code,
> Pre-launch algo & test data, and NICSE Ingested SD3E Data.\*

**Rad cal eval results**

> \*The results from the PEATEs evaluation of the calibration look-up
> table and/or software updates. The Radiometric Calibration function
> uses these results to determine if additional updates or if the
> current updates provide the data output products they are expecting.\*

**Rad cal LUT updates**

> \*The updates as a result of fixes or enhancements to the radiometric
> calibration look-up tables.\*

**Rad cal software updates**

> \*The updates as a result of fixes or enhancements to the radiometric
> calibration software.\*

**Rad Quality control and response**

> \*Rad Quality control request
>
> The interface between the NICSE Radiometric Calibration and the PEATEs
> in ensuring the quality of the calibration updates. The NICSE may
> occasionally use the PEATEs to test changes and updates made to the
> calibration look-up tables and software.

Rad Quality control response

> The response to the quality control request.\*

**RDR**

> \* Full resolution, unprocessed digital sensor data, time-referenced
> and Earth (GEO) located (or orbit-located for in-situ measurements),
> 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 should be unprocessed with the following
> exceptions: time delay and integration (TDI), detector array
> non-uniformity correction (i.e., offset and responsivity
> equalization), and lossless data compression. All calibration data
> will be retained and communicated to the ground without lossy
> compression. Note that for the real time transmission of raw data to
> field terminals, lossy compression is allowed. Additionally, reduced
> resolution is allowed in transmission of raw data to low data rate
> field terminals. Raw Data Records as they are distributed to the SDS
> are a collection of one or more granules plus metadata describing the
> granules. A granule is a minimum unit of managed and delivered data
> for an instrument or subsystem. An RDR granule consists of several
> contiguous sets of \"application packets\" (APs) delivered by the
> space vehicle for some predetermined period. RDRs are delivered by
> instrument and include sensor data, calibration data, and position
> data as delivered in the Space Vehicle (SV) APs. The RDR granule
> contains one or more APs and a metadata description of the granule
> contents. It also contains any telemetry data required to create the
> associated SDR.\*

**RDR (for Geometric)**

\*See RDR. \*

**RDR (for Radiometric)**

\* See RDR.\*

**Recommended algorithms/source code**

> \*The version controlled science algorithms and source code developed
> by the PEATEs or acquired from the Science Team. These science
> algorithms are new/modified/updated science algorithms that the PEATEs
> may submit, if requested by the Science Team, to the PSOE.\*

**Result of cal evaluation**

> \*The PEATEs results from evaluating the NICSE's recommended updates
> to the calibration look-up tables and software.\*

**Science products**

> \*Data files needed for science data processing. These items may
> include the ADS xDRs, ADS IPs, ADS calibration product, ADS ancillary
> data, or ADS operational algorithms.\*

**SD3E-I&TSE xDRs**

\*RDRs or SDRs\*

**SD3E Ingested ADS Data**

> \*The data that SD3E has ingested from the ADS. These products
> include: ADS xDRs, ADS IPs, ADS ancillary data, ADS calibration
> product, and ADS operational algorithms.\*

**SD3E management direction/reports**

\*SD3E management direction

> The PSOE provides management direction on ingest and volume
> priorities, schedules, etc...

SD3E management reports

> The SD3E provides ingest status reports to the PSOE.\*

**SD3E-NICSE calibration product**

> \*The SD3E ingests the calibration product from the ADS and makes the
> product available to the NICSE. See ADS calibration product.\*

**SD3E-NICSE operational algorithms**

> \*The SD3E ingests the operational algorithms from the ADS and makes
> them available to the NICSE. See ADS operational algorithms.\*

**SD3E-NICSE xDRs**

> \*The SD3E ingests the xDRs (RDRs \-- Science, Diagnostic, EDRs, SDRs,
> TDRs) from the ADS and makes the products available to the NICSE. This
> also includes the ADS ancillary data products. See also ADS ancillary
> data products.\*

**SD3E-NICSE xDRs, calibration product, operational algorithms**

> \*See definitions for SD3E-NICSE xDRs, SD3E-NICSE calibration product,
> and SD3E-NICSE operational algorithms.\*

**SD3E Out-bound data**

> \*The data products stored in the SD3E out-bound data store. These
> products are stored in groups that can be logically isolated from each
> other. The groups of products include IDPS RDR products, ADS xDRs, ADS
> IPs, ADS ancillary data, ADS calibration product, and ADS operational
> algorithms.\*

**SD3E-PEATEs operational algorithms**

> \*The SD3E ingests the operational algorithms from the ADS and makes
> them available to the PEATEs. See ADS operational algorithms.\*

**SD3E-PEATEs science data**

> \*The SD3E ingests the xDRs, all available IPs, ancillary data, and
> calibration product from the ADS and makes these products available to
> the PEATEs.\*

**SD3E product queries and ADS response**

\*The transfer of data products between the SD3E and the ADS includes:

SD3E-ADS product queries:

. ADS product subscription

. ADS ad-hoc requests

.ADS data queries and requests

SD3E-ADS response:

.ADS xDRs

.ADS IPs

.ADS ancillary data

.ADS calibration product

.ADS operational algorithms

.ADS query and request status\*

**SD3E product queries and IDPS response**

> \*The transfer of data products between the SD3E and the IDPS
> includes:

SD3E-IDPS product queries:

> . NPOESS Data Product Query and Requests

SD3E-IDPS response:

> .NPOESS Data Products including Metadata
>
> .IDPS data delivery reports
>
> .NPOESS Data Product Query and Request Status\*

**SDR algorithm/source code**

> \*The NPP instrument algorithm and source code for SDRs used for
> pre-launch characterization and calibration for the VIIRS
> instrument.\*

**ST ad-hoc processing requests**

> \*The Science Team may request the PEATEs to perform processing or
> reprocessing of specific data sets as a result of algorithm
> enhancements, as a result of anomalies in the data, or to provide
> support for xDR assessments. \*

**ST algo src code recommendations**

> \*The Science Team algorithm and source code recommendations. These
> recommendations may include problem fixes or enhancements, etc...\*

**ST algo src code recommendations & PSOE response**

> \*The recommended algorithm and source code updates that the Science
> Team submits to the PSOE. The PSOE may respond to the recommendations
> by providing feedback, requesting additional data, or providing status
> of submission to the NPP/NPOESS Algorithm CCB (TBR)\*

**ST data request and response**

> \*ST data request
>
> The Science Team may generate data requests to the PEATEs for the
> available products in the PEATEs data store.

ST data request response

> The PEATEs respond to the request by providing the Science Team with
> the requested products which may include EDRs or Level 2 and higher
> products.\*

**ST recommendations and feedback**

\*ST-PSOE recommendations

The recommended science algorithm updates to the PSOE.

ST-PSOE feedback

> The PSOE's response to the Science Team's science algorithm
> recommendations.\*

**ST science data pkg**

> \*The package is provided by the PEATEs to the Science Team. This data
> package can be the recommended algorithm enhancements and any
> associated the science (xDRs) data needed for evaluation of the
> algorithm enhancements. Or this package may also be the Science Team's
> requested data products from the PEATEs\*

**Verified data**

> \*The Verified data products are products where a basic level of
> validation has been performed to determine if the data received
> matches the data expected. A checksum or a digital signature is used
> to check the product. Verified data includes all products ingested
> (i.e. xDRs, calibration product, ancillary data, operational
> algorithms, delivery reports/notices, etc...)

**VIIRS Geolocation SDR**

> \*A product that contains the Earth location and other related spatial
> information for the various VIIRS data products. The related spatial
> fields include the product's viewing, solar, and lunar geometry.\*

**xDR eval results**

> \*The PEATEs send, if requested by the Science Team, the results of
> their xDR evaluations to the PSOE. These results from the PEATEs
> evaluation in support of the Science Teams assessment of the quality
> of the xDRs for making climate data records.\*

**xDRs, IPs, metadata**

> \*The xDRs, IPs and its associated metadata generated during the
> PEATEs science processing, algorithm enhancement processing, or data
> quality assessment.\*

# Appendix E NPOESS SERVICE REQUEST {#appendix-e-npoess-service-request .unnumbered}

  ------------------------------------------------------------------------
  Data Name                           Data Mnemonic        Nominal Update
                                                           Frequency
  ----------------------------------- -------------------- ---------------
  KSAT Ground Contact Schedule        C3_NU-LW2160-000     24 Hours

  HRD/LRD Monitoring Report           C3_NU-LW2080-000     24 Hours

  Mission Notices                     C3_NU-LW2060-000     As needed

  Mission Schedule                    C3_NU-L00070-070     24 Hours

  Network Service Operational         C3_NU-LW2070-000     24 Hours
  Statistics                                               

  STA Ad Hoc Telemetry Report         C3_NU-LW2110-000     As needed

  STA Report Request Form             C3_NU-L00060-150     Always
                                                           Available

  STA State Checking Report           C3_NU-LW2125-000     24 Hours

  STA Limit Checking Report           C3_NU-LW2100-000     24 Hours

  STA Trend Report                    C3_NU-LW2120-000     24 Hours

  STA SDS Telemetry Report            C3_NU-LW2090-000     14 times per
                                                           day

  System Data Availability Report     C3_NU-L00060-060     24 Hours

  System Latency Report               C3_NU-L00080-080     As needed

  Two Line Element Sets               C3_DP-L00100-100     24 Hours
  ------------------------------------------------------------------------

# Appendix F NPOESS SERVICE RESPONSE {#appendix-f-npoess-service-response .unnumbered}

  --------------------------------------------------------------------------
  Report Name       Description                            Periodicity
  ----------------- -------------------------------------- -----------------
  Mission Schedule  Contains the events and activities     Daily (M - F)
                    that comprise the mission schedule.    
                    Events are included in terms of time,  
                    and activities are included in terms   
                    of specific tasks, the resource        
                    allocated for the task, and the time   
                    the task is being performed. Schedule  
                    is a rolling 72 hr schedule that is    
                    published daily M-F. (i.e. updated     
                    every 24 hrs M-F for the next 72 hr    
                    period)                                

  Geographic        Geographic registration performance on (Common-TBD-08)
  Registration      a per sensor basis.                    
  Performance                                              
  Metrics                                                  

  Radiometric       Radiometric calibration performance on (Common-TBD-09)
  Calibration       a per sensor basis.                    
  Performance                                              
  Metrics                                                  

  Subsystem Fault   Faults by Subsystem, by Node Name, by  Daily
  Reports           site, by severity                      

  System Level Data System Level Data Accountability       Daily
  Accountability    reports - compiled reports of each IDP 
  reports           DA report and C3S data delivery        
                    reports                                

  C3S Data Delivery Includes number of data recoveries     Daily
  Report            attempted, number of successful data   
                    recovery attempts, total amount of     
                    data delivered to IDP...               

  Security Report   Security Report - failed logins, etc.. Daily

  Mission Notices   Mission notices posted on the home     Posted as
                    page of internal and external servers  submitted.

  Network Service   Bandwidth usage, availability, etc...  Daily
  Operational                                              
  Statistics                                               

  HLM Monitoring    Report APIDs from AP Primary Headers   Daily
  Report            &\                                     
                    Link Quality:\                         
                    Center Frequency\                      
                    Spectral Characteristics\              
                    Received Signal Strength\              
                    Data Rate\                             
                    Modulation Quality\                    
                    Signal to Noise Ratio                  

  STA SDS Telemetry Selected telemetry                     After each
  Report                                                   contact

  AD-HOC Telemetry  Plot or tab delimited ASCII file of up As requested
  Report            to eight vehicle LRVs                  

  SO Task Execution A description of the execution status  Based on
  Status            of a given procedure.                  procedure
  --------------------------------------------------------------------------

NPOESS Mission Schedule Report Events

  ----------- ----------- ----------- ----------- --------- ------- ----------
  Event ID    Start Time  Stop Time   Duration    Event     SC/GS   Resource
                                      (min)       Type              

  VIIRS_Out   03 Mar 2003 04 Mar 2003 1,440       Outage    C1      C1_VIIRS
              16:38       16:38                                     
  ----------- ----------- ----------- ----------- --------- ------- ----------

Scheduled Tasks

  ---------------- ---------- ---------- ---------- ------------- ---------- --------------
  Task ID          Start Time Stop Time  Duration   Task Type     SC/GS      Resource
                                         (min)                               

  C1_ATMS_ON       3/3/2003   3/4/2003   1,440      Collection    C1         C1_ATMS
                   0:03       0:00                                           

  C1_CrIS_ON       3/3/2003   3/4/2003   1,440      Collection    C1         C1_CrIS
                   0:03       0:00                                           

  C2_VIIRS_ON      3/3/2003   3/4/2003   1,440      Collection    C2         C2_VIIRS
                   0:05       0:00                                           

  C2_REC_CONTACT   3/3/2003   3/3/2003   6.983      Rec_Contact   C2         C2_SMD
                   1:09       1:16                                           

                                                                  Svalbard   Svalbard_TTC
  ---------------- ---------- ---------- ---------- ------------- ---------- --------------

**THIS PAGE INTENTIONALLY LEFT BLANK**