> **LANDSAT DATA CONTINUITY MISSION**
>
> **OPERATIONAL LAND IMAGER (OLI)**
>
> **SPECIFICATION**
>
> **April 18, 2005**

![](media/image1.png)

**Signature Page**

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

                                      

                                      

                                      

                                      

                                      

                                      

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

![](media/image2.wmf){width="1.0416666666666666e-2in"
height="1.0416666666666666e-2in"}**LDCM PROJECT**

**DOCUMENT CHANGE RECORD**

Sheet: 1 of 1

+------------+-------------------------------------+---------+--------+
| REV        | DESCRIPTION OF CHANGE               | A       | DATE   |
|            |                                     | PPROVED |        |
| LEVEL      |                                     |         | AP     |
|            |                                     | BY      | PROVED |
+------------+-------------------------------------+---------+--------+
| Draft      | RFI release.                        |         |        |
|            |                                     |         |        |
| June 10,   |                                     |         |        |
| 2004       |                                     |         |        |
+------------+-------------------------------------+---------+--------+
| Draft      | Updates to RFI release.             |         |        |
|            |                                     |         |        |
| September  |                                     |         |        |
| 24, 2004   |                                     |         |        |
+------------+-------------------------------------+---------+--------+

**Table of TBDs / TBRs / TBSs**

  -------------------------------------------------------------------------
  **Section**   **Type**     **Description**
  ------------- ------------ ----------------------------------------------

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

The term "To Be Determined" (TBD) applied to a missing requirement means
that the contractor should determine the missing requirement in
coordination with the Government. The term "To Be Supplied" (TBS) means
that the Government will supply the missing information in the course of
this contract. The term "To Be Reviewed" (TBR) means that the
requirement is subject to review for appropriateness by the contractor
or the Government, with approval by the Government. The Government may
change TBR requirements in the course of this contract.

**TABLE OF CONTENTS**

Page

[1.0 INTRODUCTION 1-1](#introduction)

[1.1 Identification 1-1](#identification)

[1.2 Mission Overview Assumptions 1-1](#mission-overview-assumptions)

[1.3 Acronyms and Definitions 1-1](#acronyms-and-definitions)

[1.4 Standards 1-1](#standards)

[1.5 Applicable documents -- Moved TO SOW
1-2](#applicable-documents-moved-to-sow)

[1.6 Reference Documents 1-2](#reference-documents)

[1.7 Document Organization 1-3](#document-organization)

[2.0 OLI FUNCTIONAL OVERVIEW 2-1](#oli-functional-overview)

[2.1 OLI Functional Description 2-1](#oli-functional-description)

[2.2 OLI Functional Elements 2-1](#oli-functional-elements)

[3.0 OLI System Level Requirements 3-1](#oli-system-level-requirements)

[3.1 OLI Compliance with GIID and OLI/NPOESS IRD
3-1](#oli-compliance-with-giid-and-olinpoess-ird)

[3.2 OLI LIFETIME REQUIRMENTS and Probability of Success
3-1](#oli-lifetime-requirments-and-probability-of-success)

[3.3 OLI Image DATA Stability and Pointing Knowledge END to End
RequiremeNTs
3-1](#oli-image-data-stability-and-pointing-knowledge-end-to-end-requirements)

[3.4 Single Point failures 3-3](#single-point-failures)

[3.5 OLI Command and Telemetry Interface MIL-STD-1553 Spacecraft Data
Bus
3-3](#oli-command-and-telemetry-interface-mil-std-1553-spacecraft-data-bus)

[3.6 OLI Image and Ancillary Data interface
3-3](#oli-image-and-ancillary-data-interface)

[4.0 REFLECTIVE BAND SENSOR (RBS) REQUIREMENTS
4-1](#reflective-band-sensor-rbs-requirements)

[4.1 Operational, Physical, Mechanical, and Structural Requirements
4-1](#operational-physical-mechanical-and-structural-requirements)

[4.2 Reflective Band Sensor Requirements
4-8](#reflective-band-sensor-requirements)

[4.3 Reserved 4-23](#reserved-2)

[5.0 DATA STORAGE AND PLAYBACK (DSAP) SUBSYSTEM FUNCTIONAL AND
PERFORMANCE SPECIFICATION
5-1](#data-storage-and-playback-dsap-subsystem-functional-and-performance-specification)

[5.1 DSAP Interfaces 5-1](#dsap-interfaces)

[5.2 DSAP Operational Modes 5-1](#dsap-operational-modes)

[5.3 DSAP Data Storage Requirements
5-3](#dsap-data-storage-requirements)

[5.4 Other DSAP Image Data Processing Capabilities
5-4](#other-dsap-image-data-processing-capabilities)

[5.5 Data Playback Capabilities 5-5](#data-playback-capabilities)

[5.6 DSAP Fault Detection and Correction
5-7](#dsap-fault-detection-and-correction)

[5.7 DelETED 5-7](#deleted-2)

[6.0 GSE REQUIREMENTS 6-1](#gse-requirements)

[6.1 System Test Equipment (STE) 6-1](#system-test-equipment-ste)

[6.2 Calibration Test Equipment (CTE)
6-4](#calibration-test-equipment-cte)

[6.3 Handling Fixtures 6-4](#handling-fixtures)

[6.4 Test Fixtures 6-4](#test-fixtures)

[6.5 Shipping / Storage Containers 6-4](#shipping-storage-containers)

[6.6 Environmental Conditions 6-5](#environmental-conditions)

[6.7 Transportability 6-5](#transportability)

[6.8 Marking 6-5](#marking)

[7.0 OLI PROCESSOR(S), SOFTWARE AND COMMAND AND DATA HANDLING
REQUIREMENTS
7-1](#oli-processors-software-and-command-and-data-handling-requirements)

[7.1 On-Board Processors (OLI-OBP(S))
7-1](#on-board-processors-oli-obps)

[7.2 Redundancy Management 7-3](#redundancy-management)

[7.3 OLI flight software 7-4](#oli-flight-software)

[7.4 Failure Detection and Correction (FDC)
7-7](#failure-detection-and-correction-fdc)

[7.5 Command and Data Handling (OLI C&DH)
7-9](#command-and-data-handling-oli-cdh)

######## LIST OF FIGURES {#list-of-figures .unnumbered}

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

[Figure 4‑1. MODTRAN 4 Model Table Values
4-19](#__RefHeading___Toc99425560)

[Figure 4‑2. Coherent Noise Threshold Curve
4-20](#__RefHeading___Toc99425561)

######## LIST OF TABLES {#list-of-tables .unnumbered}

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

[Table 2‑1. RBS Key Performance Requirements
2-2](#__RefHeading___Toc99425571)

[Table 4‑1. Spectral Bands and Band Widths
4-9](#__RefHeading___Toc99425572)

[Table 4‑2. Edge Slope Intervals for RBS Bands
4-12](#__RefHeading___Toc99425573)

[Table 4‑3. GSD / Minimum Slope Specification
4-13](#__RefHeading___Toc99425574)

[Table 4‑4. Absolute Radiometric Uncertainty Requirements
4-15](#__RefHeading___Toc99425575)

[Table 4‑5. Radiance Levels for Signal-to-Noise Ratio (SNR) Requirements
and Saturation Radiances 4-16](#__RefHeading___Toc99425576)

[Table 4‑6. SNR Requirements 4-17](#__RefHeading___Toc99425577)

[Table 0‑1. Allowable Simultaneous Modes of Operation
5-2](#__RefHeading___Toc99425578)

[Table 7‑1. Flight Processor Resource Sizing
7-1](#__RefHeading___Toc99425579)

#  {#section .unnumbered}

# INTRODUCTION

## Identification

This Specification sets forth the requirements for the Operational Land
Imager, henceforth identified as OLI, for the Landsat Data Continuity
Mission.

## Mission Overview Assumptions

The OLI provides Landsat multispectral image acquisition, storage and
playback compatible with the National Polar Operational Environmental
Satellite System (NPOESS). The inherent goal of the OLI is to serve as a
"standard Operational Land Imager" which will be integrated on the
NPOESS Operational Spacecraft (2130 Configuration).

OLI will be required to operate nominally on these platforms to acquire
multispectral scenes (177km x 170km) on a 17 day repetitive basis at the
NPOESS 2130 ascending node nominal orbit of 828km.

## Acronyms and Definitions

Operational Land Imager -- The end item deliverable of this contract
which includes a Reflective Band Sensor (RBS) and a Data Storage and
Playback Subsystem (DSAP).

Reflective Band Sensor (RBS) -- The core Landsat multispectral sensing
instrument for reflective spectral bands in the visible, near infrared
and shortwave infrared

Data Storage and Playback Subsystem (DSAP) -- Provides temporary
on-board storage and rate buffering of RBS image data

All other definitions and acronyms referenced in this document can be
found in the OLI Acronym List and Lexicon.

## Standards

The latest revisions of the following standards apply to this
specification.

ASTM E-595 Standard Test Method for Total Mass Loss and Collected
Volatile Condensable Materials from Outgassing in a Vacuum Environment

ASTM-E1559 Standard Test Method for Contamination Outgassing
Characteristics of Spacecraft Materials

CCSDS-101.0-B Telemetry Channel Coding

CCSDS-301.0-B Time Code Formats

CCSDS-701.0-B Advanced Orbiting Systems - Networks and Data Links:
Architectural Specification

IEST-STD-CC1246D Product Cleanliness Levels and Contamination Control
Program

ISO 14644-1 Cleanrooms and associated controlled environments \-- Part
1: Classification of air cleanliness

ISO 14644-2 Cleanrooms and associated controlled environments \-- Part
2: Specifications for testing and monitoring to prove continued
compliance with ISO 14644-1

MIL-STD-461 Requirements for the Control of Electromagnetic Interference
Characteristics of Subsystems and Equipment

MIL-STD-882 Standard Practice for System Safety

MIL-STD-1541 Electromagnetic Compatibility Requirements for Space
Systems

MIL-STD-1542 Electromagnetic Compatibility and Grounding Requirements
for Space Systems Facilities (November 1991)

MIL-STD-1553 Digital Time Division Command/Response Multiplex Date Bus

MIL-STD-2401 Department of Defense World Geodetic System (WGS)

NIMA TR-8350.2 DOD World Geodetic System

## Applicable documents -- Moved TO SOW 

## Reference Documents

NPOESS Space Segment Specification, Rev. D, 01 August 2002, NGST Doc.
No. SY26-0009

NPOESS Command, Control, and Communications Segment Specification, NGST
Doc. No. SY12-0023

NPOESS Operations Concept, Rev. G, NGST Doc. No. D31400

NPOESS Concept of Operations, NGST Doc. No. D34635

NPOESS System Specification, NGST Doc. No. SY15-0007

NPOESS System Specification, Appendix B, NGST Doc. No. SY15-0007-01

NPOESS External IRD/ICDs, NGST Doc. No. D31410

MIL-A-83577B - Assemblies, Moving Mechanical, for Space and Launch
Vehicles, General Specification for (February 1988)

PPL-21 - Preferred Parts List, Goddard Space Flight Center (updated May
1996)

MIL-HDBK-1547A - Electronic Parts, Materials, and Processes for Space
and Launch Vehicles (6 July 1998)

MIL-HDBK-263B - Electrostatic Discharge Control Handbook for Protection
of Electrical and Electronic Parts, Assemblies and Equipment (Excluding
Electrically Initiated Explosive Devices) (Metric) (31 July 1994)

## Document Organization

Section 1 is an introduction to this document. Section 2 provides a
brief OLI functional overview. Section 3 provides OLI Instrument System
level requirements. Section 4 defines the spatial, spectral, and
radiometric requirements for imagery acquired by the Reflective Band
Sensor to be consistent with the Landsat heritage. Section 5 defines the
Data Storage and Playback (DSAP) Subsystem requirements for providing
temporary storage and playback of acquired Landsat Imagery. Section 6
defines the Ground Support Equipment requirements. Section 7 defines the
OLI processor, software and command and data handling requirements.

# OLI FUNCTIONAL OVERVIEW

This section of the OLI Specification provides a functional overview for
the OLI. As such, the information in this section provides context for
the function, performance, and operations of the OLI. The detailed and
binding OLI functional and performance requirements are found in
Sections 3, 4, 5, 6 and 7 of this document.

## OLI Functional Description

The OLI is required to provide Landsat multispectral image acquisition,
storage and playback onboard the operational NPOESS spacecraft for a
period of 7 years within the prescribed requirements. The OLI consists
of the Reflective Band Sensor (RBS) and the Data Storage and Playback
(DSAP) subsystem. The RBS provides VNIR/SWIR imagery consistent with
Landsat spectral, spatial, radiometric and geometric qualities as
specified in Section 4 of this document. The DSAP subsystem provides
image data storage and playback from the RBS which is required to meet
the Landsat temporal, imaging capacity, and image reconstruction
requirements per Section 5 of this document.

## OLI Functional Elements

The OLI functional elements consist of the RBS and DSAP. The NPOESS
operational spacecraft provides the mechanical, power, thermal and data
interfaces as well as the transfer of collected OLI data to the NPOESS
stored mission data (SMD) Ka-band transmitter.

The OLI-NPOESS 2130 Interface Requirements Document provides a list of
the major unique interface requirements for integrating the OLI
instrument system on the NPOESS 2130 Spacecraft.

### Description and Tables of Key RBS Capabilities 

The RBS includes the optical telescope, Focal Plane Array / Focal Plane
Electronics (FPA/FPE) and instrument control electronics. The optical
telescope includes the optical bench assembly, baffles and mirrors to
gather and focus the optical beam onto the FPA. The FPA/FPE converts
photon energy into electrical voltage signals and converts the voltage
signals into digital signals. The RBS is specified to provide nine
spectral bands with a maximum ground sampling distance, both in-track
and cross track, of 30m for all bands except the panchromatic band which
is specified to have a 15m ground sampling distance. The RBS will have a
177km cross track swath width at the mission nominal NPOESS orbit of 828
+/- 12 km altitude and 98.7 +/- .05° inclination sun synchronous orbit.
The RBS provides both internal calibration sources such as lamps to
ensure radiometric accuracy as well as capabilities to perform solar
calibrations within the field of view constraints. The RBS also includes
all required accommodation hardware or software required to meet all
functional and performance requirements while operating on the NPOESS
2130 Spacecraft.

[]{#__RefHeading___Toc99425571 .anchor}Table 2‑1 RBS Key Performance
Requirements

  -------- -------------- ----------- ----------- --------- --------- -------------- -----------
  **\#**   **Band**       **Minimum   **Maximum   **\       **\       **\            **\
                          Lower Band  Upper Band  \         \         \              \
                          Edge (nm)** Edge (nm)** \         \         SNR\           SNR\
                                                  Maximum   Edge\     @\             @\
                                                  GSD\***   Slope**   L~Typical~**   L~High~**

  1        Coastal        433         453         30 m      .027 / m  130            290
           Aerosol                                                                   

  2        Blue           450         515         30 m      .027 / m  130            360

  3        Green          525         600         30 m      .027 / m  100            390

  4        Red            630         680         30 m      .027 / m  90             340

  5        NIR            845         885         30 m      .027 / m  90             460

  6        SWIR 1         1560        1660        30 m      .027 / m  100            540

  7        SWIR 2         2100        2300        30 m      .027 / m  100            510

  8        Panchromatic   500         680         15 m      .054 / m  80             230

  9        Cirrus         1360        1390        30 m      .027 / m  50             N/A
  -------- -------------- ----------- ----------- --------- --------- -------------- -----------

### Description and Table of Key DSAP capabilities

The Data Storage and Playback Subsystem (DSAP) provides all of the
functions necessary to store, compress and encrypt (if necessary)
digital image data from the FPA/FPE of the OLI. The DSAP provides the
capacity to ingest a high rate data stream from the RBS and temporarily
store up to 150 multispectral scenes (177 km x 170 km) of image and
ancillary data (at mission EOL) before this data must be overwritten or
deleted. The NPOESS Ka band Stored Mission Data link will transmit the
data to the NPOESS ground system (Safetynet@). The DSAP also receives
ancillary data from the RBS sensor and spacecraft bus. Ancillary data
includes spacecraft attitude, navigation, timing data and key telemetry
values from the sensor and spacecraft. OLI ancillary data packets are
periodically inserted into the image data stream to provide all
necessary image reconstruction information for later ground processing.

The DSAP is assumed to be an onboard device that can simultaneously
store, process and output the RBS data stream. Mechanically, the DSAP
may be separate from the RBS and mounted inside the spacecraft bus to
maintain thermal isolation from the RBS. For storage of image data the
DSAP is expected to ingest image and ancillary data packets and store
the data either The DSAP is expected to provide any necessary error
detection and correction to the stored image data to prevent degradation
due to Single Event Upsets (SEU's) or other space environmental factors.
The DSAP will also organize and store image into files and correlate any
necessary image reconstruction information (ancillary data) based on
image receipt time. The DSAP provides the ability to concurrently store
and playback data as necessary to meet the LDCM data collection and
downlink requirements. Playback of data is required to allow for
priority selection of image files by ground command and must be at a
sufficient rate to allow full downlink of all stored data within the
allocated Safetynet@ ground station contacts each day. Additionally, the
DSAP is required to provide self-test modes to exercise internal data
paths.

# OLI System Level Requirements

The OLI consists of the Reflective Bands Sensor (Section 4), the Data
Storage and Playback System (Section 5), and all Flight Software
(Section 7) and associated Ground Support Equipment (section 6). Any
associated hardware or software to accommodate the OLI on the NPOESS
2130 Spacecraft per section 3.1, 3.3 and 4.0 shall be included with the
RBS.

## OLI Compliance with GIID and OLI/NPOESS IRD

The OLI shall meet the requirements of the NPOESS General Instrument
Interface Document (GIID), Doc. No. D31418 Rev. B and the OLI -NPOESS
2130 Spacecraft Interface Requirements Document.

## OLI LIFETIME REQUIRMENTS and Probability of Success

### OLI Probability of Success 

### The OLI shall be designed to operate and meet all specifications herein for 7 years after the initial on-orbit checkout period has completed and meet a minimum probability of success Ps of 0.70 (TBR) for seven years on orbit operations after storage and ground-based testing as specified in the NGIID. {#the-oli-shall-be-designed-to-operate-and-meet-all-specifications-herein-for-7-years-after-the-initial-on-orbit-checkout-period-has-completed-and-meet-a-minimum-probability-of-success-ps-of-0.70-tbr-for-seven-years-on-orbit-operations-after-storage-and-ground-based-testing-as-specified-in-the-ngiid. .unnumbered}

### Performance Requirements

The OLI shall be designed to meet all performance requirements during
and after exposure to ground test, storage, handling, and launch
environmental conditions as specified in the Mission Assurance
Requirements document. These environmental conditions include, but are
not limited to, vibration, thermal, radiation, humidity, and pressure
conditions.

## OLI Image DATA Stability and Pointing Knowledge END to End RequiremeNTs 

### Line of Sight Jitter Suppression

The combined effects of externally applied rotations, as specified in
section 3.2.6.3.2 (IF230805) of the NGIID and section 8.4 of the OLI to
NPOESS IRD, scan rate errors due to both jitter and spacecraft pointing
control errors as specified in section 3.2.4.2.3.3.5.3 (IF230795) of the
NGIID, and internal instrument vibrations induced by external
accelerations, as specified in section 3.2.6.3.1 (IF232960) of the
NGIID, shall be suppressed to the extent necessary to meet the following
requirements:

#### Edge Response and Image Smear

The OLI shall meet the edge response requirements from section 4.2.3.2
of this specification in the specified jitter and acceleration
environment, as described in section 8.4 of the OLI to NPOESS IRD.

#### Sampling and Aliasing Errors

The OLI shall meet the aliasing requirements from section 4.2.3.3 of
this specification in the specified jitter, acceleration, and pointing
environment, as described in section 8.4 of the OLI to NPOESS IRD, such
that the allowable ground sample distance variations due to all sources
are limited so as to prevent aliasing.

### Line-of-Sight Knowledge

The OLI shall provide any necessary auxiliary sensing devices (e.g.,
gyros, jitter sensors) required to provide short-, intermediate-, and
long-term knowledge of the RBS detector lines-of-sight such that, in
combination with the ancillary data provided by the NPOESS spacecraft
(ref. OLI to NPOESS IRD section 6.2), the following image stability and
knowledge requirements are met:

#### Band to Band Registration Accuracy

Knowledge of the relative lines-of-sight of the RBS detectors in all
spectral bands over the time period required for all bands to image a
common Earth target, shall provide band co-registration to an accuracy
of 4.5 meters in the along- and across-track directions at the 90%
confidence level, when projected to the WGS84 Earth ellipsoid surface.
This band co-registration applies to all spectral band pairs and may be
achieved through post-processing based on detector line-of-sight
knowledge.

#### Image Distortion 

Knowledge of the relative lines-of-sight of the RBS detectors in all
spectral bands over a time period of 30 seconds shall provide
scene-to-scene co-registration to an accuracy of 12 meters in the along-
and across-track directions at the 90% confidence level, when projected
to the WGS84 Earth ellipsoid surface. This co-registration applies to
acquisitions of the same ground area acquired at different times and may
be achieved through post-processing that removes location and pointing
biases.

#### Geodetic Accuracy 

Knowledge of the absolute lines-of-sight of the RBS detectors in all
spectral bands shall provide knowledge of the line-of-sight intersection
with the WGS84 Earth ellipsoid to an accuracy of 65 meters circular
error at the 90% confidence level. The knowledge may be achieved using
post-processing to refine the OLI-provided and/or spacecraft-provided
attitude and ephemeris data.

## Single Point failures 

### Credible Single Point Failures

The OLI shall have no credible single point failures that would prevent
the instrument from meeting its requirements as defined in this
specification, where "credible" is defined as having a probability of
greater than 0.02% at EOL.

### Non-Credible Single Point Failures

Non-credible single points of failure shall be identified and shall have
compensating provisions, such as design factors of safety, graceful
degradation, functional redundancy, etc. Cable harness and pin/socket
connections are considered credible failure mechanisms, where an open
circuit would result in a single point failure of any required
instrument function.

### Single Commands that Induce Failure

There shall be no single command that could cause loss of OLI, assuming
no OLI components have previously failed.

## OLI Command and Telemetry Interface MIL-STD-1553 Spacecraft Data Bus

The OLI shall have at least 1 but no more than 2, remote terminal
interface on the MIL-STD-1553 NPOESS 2130 Spacecraft Data Bus to support
command and telemetry processing interfaces with the NPOESS 2130 per
section 6.0 of the OLI-NPOESS 2130 Spacecraft IRD.

This interface shall support the overall commanding of the OLI,
transmission of critical OLI housekeeping telemetry, spacecraft
auxiliary and timing data as defined in Sections 6.1 and 6.2 of the
OLI\--NPOESS 2130 Spacecraft IRD.

### 1 Hz Time of Day Pulse

The OLI shall use the 1 Hz time of day pulse together with the time data
transmitted over the MIL-STD-1553 spacecraft data bus to time tag the
OLI image data per IRD sect 6.3

## OLI Image and Ancillary Data interface 

###  Image and Ancillary Data Output Interface 

The OLI shall provide Image and ancillary data via the DSAP Output
interface which meets the interface and formatting requirements of
Section 5.2 of this specification and Section 5.0 of the OLI-NPOESS 2130
Spacecraft IRD.

### Image and Ancillary Data Output Rate 

When enabled by the NPOESS 2130 Interface, the OLI shall provide Image
and Ancillary data via the DSAP Output interface, per section 5.2, at
the maximum transfer data rate of the interface (i.e. no fill CADU's)
until this interface is either disabled or the DSAP has transferred all
stored data (i.e. empty) .

# REFLECTIVE BAND SENSOR (RBS) REQUIREMENTS

## Operational, Physical, Mechanical, and Structural Requirements

### General

The RBS shall be comprised of the sensor module, all associated sensor
control electronics and power modules, all required control, signal
processing and data formatting electronics, all required hardware and
software to meet sensor performance requirements on the NPOESS 2130
Spacecraft and interface cabling to the DSAP and Spacecraft bus control
interface.

#### RBS Modes of Operation

The RBS sensor shall implement the following modes and functionalities,
as appropriate and defined herein. These modes of operations correspond
to those in the NGIID Sect 3.1.

OFF Mode

Activation Mode

Outgas Mode

Early Orbit Checkout

Standby Mode

Operational Mode

Solar Calibration Mode

Internal Source Calibration Mode

Decontamination Mode

Diagnostic Mode

Instrument Safe Mode

Survival Mode

##### OFF Mode

###### Instrument Power

In the Instrument [OFF Mode]{.underline}, the instrument shall receive
no external power, including survival heater power and operational
power.

###### Sudden Entry into OFF Mode

The instrument shall be capable of withstanding, without damage, the
sudden entry into the OFF mode. This refers specifically to the sudden
removal of operational power without first going through an orderly
shut-down sequence.

Any special sequences required to re-configure from sudden entry into
OFF mode, will be documented in the ICD.

Instrument OFF mode may be used for ground storage and transportation,
launch, and spacecraft power crisis situations.

##### Activation Mode

[Activation mode]{.underline} refers to instrument turn-on, and
subsequent instrument component warm up, or cool down, to the operating
temperatures. [Activation mode]{.underline} terminates when all
instrument temperatures, biases, and currents have stabilized within
specified operational limits. [Activation mode]{.underline} also
includes any deployments and opening of covers or shutters.

The instrument contractor will define, for documentation in the ICD,
what activation sequences / events are required, where they are
necessary, and specific spacecraft control requirements, including
appropriate algorithms to be implemented.

During power up, the instrument shall enable the command and telemetry
functions, and provide for orderly turn-on based on commands to the
instrument.

##### Outgas Mode

The RBS shall implement an [Outgas Mode]{.underline}.  Initial outgas
will occur during Launch and Early Orbit after the satellite has
successfully reached orbit and the solar array has successfully
deployed.

###### Mode Utilization

> This mode shall be utilized to outgas and evaporate contaminants from
> RBS hardware to prevent contamination from jeopardizing performance.

###### Health and Status Data

In this mode, health and status data shall be collected and transmitted,
but not mission or calibration data.

###### Decontamination

This mode shall also be exercised at any time during the mission when
decontamination is required.

##### Early Orbit Checkout Mode

###### Complete Spacecraft Checkout

Once on-orbit, the Early Orbit Checkout period shall be devoted to a
complete spacecraft checkout and the calibration and performance
verification of the payload. These performance verification tests may be
repeated at appropriate times during the operational phase of the
mission. Verification that performance complies with design and meets
requirements defines success in this mode.

###### Early Orbit Checkout and Anomaly Resolution

To support early orbit checkout, and for anomaly resolution, the
instrument contractor shall provide the capability to selectively
disable any on-orbit processing operation that combines or compresses
raw data in any manner.

Examples of such processing operations are: spatial aggregation of pixel
samples; temporal aggregation of pixel samples; averaging of pixel data
acquired while viewing calibration sources; averaging of calibration
instrumentation data such as source temperature measurements; and data
compression.

During this mode, the instrument peak data rate must be maintained. The
instrument contractor may maintain this data rate within requirements by
limiting the portion of the swath or number of bands for which data are
transmitted, or by any other means consistent with providing maximum
flexibility and utility for performing diagnostics.

##### Standby Mode

In the Standby Mode, the RBS shall be in a fully functional
configuration without any science data being collected.

The RBS shall be able to transition upon command from Standby Mode to
Operational Mode or vice versa within 2 seconds.

##### Operational Mode

###### Definition

In the Operational Mode the instrument shall be fully functional,
providing all data needed to satisfy the performance requirements for
the instrument.

###### Necessary Data

This data shall include normal mission data, housekeeping telemetry, and
periodic calibration information, as required.

All allocated spacecraft resources will be available to the instrument
in this mode.

###### During Orbit Correction

The instrument shall be capable of remaining in normal operational mode
without damage while the spacecraft performs orbit correction. The
instrument is not required to meet performance requirements during orbit
correction.

##### Calibration Modes

Instrument [Calibration Modes]{.underline} may be considered as submodes
of the [Operational Mode]{.underline} described above.

###### Solar Calibration Mode

In the [Solar Calibration Mode]{.underline} the instrument shall be in
an operational configuration and deploy any required devices, such as
solar diffusers, and activate any sources or sensors that are required
for solar calibration.

###### Internal Source Calibration Mode

In the [Internal Source Calibration Mode]{.underline} the instrument
shall be in an operational configuration and deploy any required
devices, and activate internal radiometric sources and sensors that are
required for internal calibration.

######  {#section-1 .unnumbered}

##### Decontamination Mode

The RBS shall be configured to periodically evaporate contaminants which
may have been deposited on critical optical surfaces. In this mode,
health and status data will continue to be collected and transmitted,
while mission or calibration data will be excluded. This mode may be
functionally the same as the Outgas Mode described above.

##### Diagnostic Mode

###### Updates to Housekeeping Telemetry and Software

The instrument [Diagnostic Mode]{.underline} shall support updates to
housekeeping telemetry and software.

###### Troubleshooting

The [Diagnostic Mode]{.underline} shall support trouble shooting, by
allowing different telemetry sampling rates as documented in the ICD

##### Instrument Safe Mode 

For instances of an instrument-detected on-orbit failure, where failure
to take prompt corrective action could result in damage to the
instrument, the instrument shall place itself into a [Safe
Mode]{.underline}.

######  Spacecraft Notification

The instrument shall notify the spacecraft that it has placed itself
into the [Instrument Safe Mode]{.underline} and then await specific
further commands via the spacecraft.

######  Data to be Collected and Transmitted

In this mode, health and status data shall continue to be collected and
transmitted, but not mission or calibration data.

######  Pre-Turnoff

The instrument shall configure itself such that no damage will occur if
the next action from the spacecraft is to turn off the instrument. The
instrument may, by choice, utilize this mode as an intermediate state
between [Operational]{.underline} and [Off]{.underline}, or
[Operational]{.underline} and [Survival]{.underline}
[Modes]{.underline}.

######  Command Receipt

The instrument shall also enter this mode upon receipt of a command from
the spacecraft. By example this command could be a forwarded ground
command, or generated by the spacecraft in response to a power system
anomaly. The instrument may also be commanded to enter [Instrument Safe
Mode]{.underline} when the Spacecraft is performing scheduled thruster
activity, such as for orbit maintenance.

######  Autonomous Configuration

The instrument shall autonomously configure to its [Safe
Mode]{.underline} within 45 seconds (TBR) after entry into [Safe
Mode]{.underline} is initiated.

######  Inhibition of Autonomous Entry Initiation

Autonomous [Instrument Safe Mode]{.underline} entry initiation, by the
instrument, shall be inhibitable by command from the spacecraft or by
other mechanism documented in the ICD.

######  Forcing Instrument Safe Mode

The command from the spacecraft for the instrument to enter [Instrument
Safe Mode]{.underline} (i.e., \"forcing\" instrument safe mode) shall
not be inhibitable by the instrument.

######  Transition to Other Modes

The instrument shall not autonomously transition from [Instrument Safe
Mode]{.underline} to any other mode.

######  Entry into Instrument Safe Mode

The instrument shall enter [Instrument Safe Mode]{.underline} upon: a)
receipt of a spacecraft command to enter [Instrument Safe
Mode,]{.underline} b) failing to receive twelve (12) (TBR) consecutive
time code data packets from the spacecraft, or c) deploying protection
for direct solar illumination.

###### Number of Missed time Code Packets

The number of missed time code packets which result in [Instrument Safe
Mode]{.underline} shall be alterable on-orbit over the range of 8 (TBR)
up to a maximum of 63 (TBR) consecutive time code data packets.

##### Survival Mode

[Survival Mode]{.underline} is entered when a critical power shortage
has been identified by the spacecraft. In this low power mode only those
functions required for satellite safety, diagnostics and recovery to
full operational status, will be powered. All instruments on the
spacecraft will be reactivated by ground command upon spacecraft
recovery.

######  Survival Mode Initiation

Initiation of [Survival Mode]{.underline} shall not require commands to
the instrument.

The spacecraft will place the instrument into Survival Mode in the event
of a severe spacecraft emergency. The spacecraft will remove instrument
operational power during Survival Mode. The spacecraft will ensure
instrument survival heater power is enabled during Survival Mode. Note:
if survival heater power consumption threatens survival of the
satellite, the spacecraft may turn off the survival heaters. At that
point, the instrument is in the [Off mode]{.underline}, rather than the
[Survival Mode]{.underline}.

Instrument survival power will be enabled, only if sufficient power is
available.

######  Sun-Pointing Attitude

In [Survival Mode]{.underline}, the instrument shall be able to survive
indefinitely while the spacecraft is in a Sun-Pointing Attitude.

Definition of Sun-Pointing Attitude: As part of entry into the [Survival
Mode]{.underline}, the Spacecraft will transition from an earth-pointing
to a sun-pointing attitude. This attitude is achieved when the solar
array is positioned normal to the sun and the spacecraft slowly rotates
about the sunline at approximately 2 rev/orbit.

In Survival Mode, the spacecraft will be responsible for sampling
critical instrument temperatures via the instrument passive analog
temperature sensors (normal instrument telemetry is not available with
operational power off).

### Allowable Modes of Operation -- per NGIID

The characterization of the allowable modes of operation of the RBS
shall be as shown in Table 4-0.

**Table 4-0 Allowable Modes of Operation**

![](media/image1.wmf)

### RBS Mechanical interface

#### Mounting Interface

The mounting method of the RBS to the spacecraft shall accommodate
manufacturing tolerance, structural, and thermal distortions.

### Reserved 

### Alignment Knowledge 

#### RBS to Spacecraft Alignment Devices 

The external optical alignment device on the RBS shall be located in
such a place as to facilitate optical alignment measurement relative to
the spacecraft inertial reference unit (IRU) and/or star trackers in
conformance to section 3.2.4.2.3.3.2 of the NGIID.

#### RBS Alignment Knowledge

### The orientation of the RBS optical axis, relative to an external optical alignment reference device on the RBS, shall be known to \<= 25urad (1 sigma). {#the-orientation-of-the-rbs-optical-axis-relative-to-an-external-optical-alignment-reference-device-on-the-rbs-shall-be-known-to-25urad-1-sigma. .unnumbered}

###  {#section-2 .unnumbered}

### RBS Purge Fitting

The RBS shall provide a purge fitting to allow a positive dry nitrogen
gas purge within the RBS during all stages of instrument and satellite
integration, test, shipment, launch site processing, and while on the
launch pad up to T-0.

### RBS Thermal Control

#### Heaters

Heaters required for precision temperature control shall be located
within the RBS, controlled by the sensor electronics and using power
from the overall RBS power budget.

### Power Requirements

#### Input Power

The RBS shall be designed to operate from a 28 +/- 6 Volt dc power
subsystem.

### Stray Light Constraints for RBS 

The RBS shall be designed to meet its performance requirements in the
presence of stray light scattered from any portion of the spacecraft
outside the sensor field of view (FOV).

### RBS Optical Surface Cleaning Access

The OLI shall provide easy access for the cleaning of all critical
telescope optical surfaces during all phases of Integration and Testing
(I&T). Easy access is defined as the ability to clean the telescope
optical surfaces in a single I&T shift without major sensor system
disassembly or de-integration from the OLI pallet or de-integration of
the OLI pallet from the S/C bus.

## Reflective Band Sensor Requirements

The following subsections specify the detailed coverage (FOV), spectral,
spatial and radiometric measurement requirements for the RBS generated
image data as well as the required formatting of the RBS data prior to
transmission onto the DSAP interface.

### Coverage

The RBS shall have a minimum field of view that provides a 177 km
cross-track swath width from the NPOESS orbit.

#### Viewing Geometry

The nominal RBS viewing angle at the center of the Field Of View shall
be at nadir.

#### Coverage

The RBS data collected for a nominal scene shall be contiguous with no
gaps.

### Spectral Bands

The RBS shall have spectral bands per the specifications in this
section.

#### Spectral Band Widths 

##### Full-Width-Half-Maximum Points

The Full-Width-Half-Maximum (FWHM) points of the relative spectral
radiance response curve for each spectral band shall fall within the
range of the minimum 50% lower band edge and the maximum 50% upper band
edge as listed in Table 4-1.

##### Center Wavelength

The center wavelength listed in Table 4-1 for each spectral band shall
be located (within the associated tolerance listed in Table 4-1) halfway
between the FWHM points of the actual relative spectral radiance
response curve for each spectral band.

[]{#__RefHeading___Toc99425572 .anchor}Table 4‑2. Spectral Bands and
Band Widths

+---+------------+----------+----------+--------+--------+-----------+
| * | **Band**   | **Center | **Center | **M    | **M    | **Band    |
| * |            | Wave     | Wa       | inimum | aximum | He        |
| \ |            | length** | velength | Lower  | Upper  | ritage/** |
| # |            |          | T        | Band   | Band   |           |
| * |            | **(nm)** | olerance | Edge   | Edge   | **Usage** |
| * |            |          | (±nm)**  | (nm)** | (nm)** |           |
+---+------------+----------+----------+--------+--------+-----------+
| 1 | Coastal    | 443      | 2        | 433    | 453    | ALI/MODIS |
|   | Aerosol    |          |          |        |        |           |
+---+------------+----------+----------+--------+--------+-----------+
| 2 | Blue       | 482      | 5        | 450    | 515    | ETM+ Band |
|   |            |          |          |        |        | 1         |
+---+------------+----------+----------+--------+--------+-----------+
| 3 | Green      | 562      | 5        | 525    | 600    | ETM+ Band |
|   |            |          |          |        |        | 2         |
+---+------------+----------+----------+--------+--------+-----------+
| 4 | Red        | 655      | 5        | 630    | 680    | ETM+ Band |
|   |            |          |          |        |        | 3         |
+---+------------+----------+----------+--------+--------+-----------+
| 5 | NIR        | 865      | 5        | 845    | 885    | ETM+ Band |
|   |            |          |          |        |        | 4/ALI     |
+---+------------+----------+----------+--------+--------+-----------+
| 6 | SWIR 1     | 1610     | 10       | 1560   | 1660   | ETM+ Band |
|   |            |          |          |        |        | 5         |
+---+------------+----------+----------+--------+--------+-----------+
| 7 | SWIR 2\*   | 2200     | 10       | 2100   | 2300   | ETM+ Band |
|   |            |          |          |        |        | 7         |
+---+------------+----------+----------+--------+--------+-----------+
| 8 | Pa         | 590      | 10       | 500    | 680    | ETM+ Pan  |
|   | nchromatic |          |          |        |        | Band/ALI  |
|   | \*\*       |          |          |        |        |           |
+---+------------+----------+----------+--------+--------+-----------+
| 9 | Cirrus     | 1375     | 5        | 1360   | 1390   | MODIS     |
+---+------------+----------+----------+--------+--------+-----------+

\* Minimum bandwidth is 180 nm for band 7

\*\* Minimum bandwidth is 160 nm for the panchromatic band

#### Spectral Band Shape 

##### Spectral Flatness 

###### Flatness Between Band Edges 

The relative spectral radiance response between the lower band edge
(lowest wavelength with 0.5 of peak relative response) and the upper
band edge (highest wavelength with 0.5 of peak relative response) shall
have the following properties:

####### Average Response 

The average relative spectral radiance response shall be greater than
0.8.

####### Minimum Response 

No relative spectral radiance response shall be below 0.4.

###### Flatness Between 80% relative response points

The relative spectral radiance response between the minimum wavelength
with a 0.8 relative response point and the maximum wavelength with a 0.8
relative response point shall always exceed 0.7.

##### Out of Band Response 

###### Beyond 1% Relative Response

The ratio of the integrated relative spectral radiance response beyond
the 1% relative response points to the integrated response between the
1% relative response points shall be less than 2%.

The 1% relative response points are the points closest to the center
wavelength where the relative response first drops to 1% of the peak
relative response on each side of the center wavelength. The integrated
responses will be weighted by the solar exoatmospheric irradiance.
Electrical crosstalk is not included within this requirement.

###### Response at Outer Wavelengths

####### VNIR and Cirrus

For any of the VNIR and Cirrus bands the value of the out of band
relative spectral response at wavelengths which are lower than the lower
band edge of the FWHM point minus 50 nm and the at wavelengths which are
higher than the higher band edge of the FWHM point plus 50 nm shall not
exceed 0.1% (of the normalized peak response). Electrical crosstalk is
not included within this requirement.

####### SWIR

Similarly for the two SWIR and panchromatic bands the value of the out
of band relative spectral response at wavelengths which are lower than
the lower band edge of the FWHM point minus 100 nm and the wavelengths
which are higher than the higher band edge of the FWHM point plus 100 nm
shall not exceed 0.1% (of the normalized peak response). Electrical
crosstalk is not included within this requirement.

#### Edge Slope 

##### Wavelength Intervals -- Case 1

> The wavelength interval between the first 5% and the first 50% of peak
> relative response and the last 50% and the last 5% of peak relative
> response ranges shall not exceed the values in Table 4-2.

##### Wavelength Intervals -- Case 2

The wavelength interval between the 1% relative response points and the
corresponding 50% relative response band edge shall not exceed the
values in Table 4-2.

 

[]{#__RefHeading___Toc99425573 .anchor}Table 4‑3. Edge Slope Intervals
for RBS Bands

  -------- -------------- ------------ ------------ ------------ -------------
  **\#**   **Band**       **Lower Edge **Lower Edge **Upper Edge **Upper Edge
                          Slope        Slope        Slope        Slope
                          Interval\    Interval\    Interval\    Interval\
                          1% to 50%\*  5% to 50%\*  50% to 5%\*  50% to 1%\*
                          (nm)**       (nm)**       (nm)**       (nm)**

  1        Coastal        15           10           10           15
           Aerosol                                               

  2        Blue           25           20           20           25

  3        Green          25           20           20           25

  4        Red            25           20           15           20

  5        NIR            25           20           15           20

  6        SWIR 1         40           30           30           40

  7        SWIR 2         50           40           40           50

  8        Panchromatic   50           40           40           50

  9        Cirrus         15           10           10           15
  -------- -------------- ------------ ------------ ------------ -------------

\* % of peak relative spectral response for the band

#### Spectral Uniformity 

Within a band, all detector bandwidths shall be within ±3% of the mean
bandwidth. Additionally see Section 4.2.4.2.3.

#### Spectral Stability

Band center wavelengths and band edges shall not change by more ± 2 nm
over the expected life of the mission.

#### Spectral Band Simultaneity 

For any point within a single 177 km x 170 km scene, the RBS shall
acquire data for all spectral bands within a (2.5)-second period (TBR).

### Spatial Data Sampling Intervals

#### Ground Sample Distance

##### Multispectral Ground Sample Distance

###### Pixel-to-Pixel Increment

RBS data shall provide a pixel-to-pixel increment, in the in-track and
cross-track directions, equivalent to a Ground Sampling Distance (GSD)
less than or equal to 30 m across the 177 km x 170 km scene for RBS
Spectral Bands 1, 2, 3, 4, 5, 6, 7 and 9.

##### Panchromatic Band

RBS data shall provide a single panchromatic band with a pixel-to-pixel
increment, in the in-track and cross-track directions, equivalent to a
GSD less than or equal to 15 m across the 177 km x 170 km scene.

#### Edge Response

The mean relative edge response slope in the in-track and cross-track
directions (mean of slope between 40%-60%) for RBS data shall conform to
the criteria described in the following subsections.

Note: Table 4-3 lists the bands, their maximum allowable GSD, and the
minimal edge slope. The edge response, in the context below, is the
normalized response of the imaging system to an edge. That is, the edge
response is normalized so that the mean minimum edge response is set to
zero and the mean maximum response is set to 100%.

[]{#__RefHeading___Toc99425574 .anchor}Table 4‑4. GSD / Minimum Slope
Specification

  -------- ------------------ -------------- -------------- -----------------
  **\#**   **Band**           **Type**       **Maximum      **Slope**
                                             GSD**          

  1        Coastal Aerosol    Standard       30 m           .027 / m

  2        Blue               Standard       30 m           .027 / m

  3        Green              Standard       30 m           .027 / m

  4        Red                Standard       30 m           .027 / m

  5        NIR                Standard       30 m           .027 / m

  6        SWIR 1             Standard       30 m           .027 / m

  7        SWIR 2             Standard       30 m           .027 / m

  8        Panchromatic       Sharpening     15m            .054 / m

  9        Cirrus             Atmospheric    30m            .027 / m
  -------- ------------------ -------------- -------------- -----------------

##### Standard Band Edge Response Slope

The mean relative edge response slope for RBS Spectral Bands 1, 2, 3, 4,
5, 6, 7 and 9 (\<=30 m GSD) shall exceed 0.027/meter for RBS Data across
the entire Field-of-View.

##### Panchromatic Band Edge Response Slope

The mean relative edge response slope for the panchromatic band, RBS
spectral band 8 (\<=15m GSD), shall exceed .054 / meter for RBS data
across the entire Field-of-View.

##### Edge Response Overshoot

The overshoot of any edge response for all bands shall not exceed 5% for
RBS data.

##### Edge Response Uniformity 

The mean relative edge response slope shall not vary by more than 10%
(maximum deviation from the band average) in any band across the
Field-of-View and by not more than 20% (maximum deviation from the
multi-band average) between RBS Spectral Bands 1,2,3,4, 5, 6, 7, and 9
for RBS data.

#### Aliasing

The product of the mean relative edge response slope and the GSD
provided by RBS data shall be less than 1.0 for both the in-track and
cross track directions.

#### Stray Light Rejection and Internal Scattering 

The effectiveness of the rejection of stray light and internal light
scattering in the RBS data is defined in terms of a scene with the
following characteristics: The RBS data are collected from a circular
region having a radius = 0.25 degrees and having a uniform target
radiance = LT . That target region is surrounded by an annular region
having an inner radius = 0.25 degrees and an outer radius = 25 degrees
and having a uniform background radiance = LB.

When LB = L T, the RBS radiance measured at the center of the target
region has a nominal value = LT. When LB is not equal to LT, the
magnitude of the change in measured RBS radiance at the center of the
target region shall be less than 0.004 times the magnitude of the
difference between LB and LT. This requirement applies to all spectral
bands for the duration of the nominal RBS mission for target and
background radiance levels ranging from a minimum of zero to a maximum
of LMax, such that LT - L B ranges from a minimum of - LMax to a maximum
of L Max.

#### Ghosting

An extended object with a maximum diameter equivalent to an enclosing
diameter of up to half the normal (177 km x 170 km) scene extent and, at
a radiance level just below the detectors saturation level, anywhere in
the RBS telescope full FOV, shall not produce a significant (as
described below) \"Ghost\" image anywhere in the \"active\" detectors
area of the focal-plane. This absence of a \"Ghost\" image requirement
applies to all spectral bands in the fully populated FPA.

A \"Ghost\" image is a secondary image of an object, which appears as
either an attenuated rendition of the original object or a blurred and
attenuated version of the original object. A \"Ghost\" also has a
constant displacement vector from the original image. A significant
\"Ghost\" is defined as an image artifact when its peak signal after
background level subtraction and radiometric calibration is above 1%
(TBR) of the peak signal in the original object and above the \"white\"
noise (random noise) level.

### Radiometry

#### Absolute Radiometric Uncertainty

The RBS absolute radiometric uncertainty requirements are given in Table
4-4 for the range of Ltypical to 0.9 Lmax (Table 4-5) with all
uncertainties established relative to National Institute for Standards
and Technology (NIST) standards. At any other radiance across the range
of 0.3 Ltypical to Ltypical the absolute uncertainty shall not exceed
the values in Table 4-4 by more than 0.5%. This requirement applies to
extended, spatially uniform, unpolarized targets with a known spectral
shape. Uncertainty estimates include the NIST standard uncertainties.

[]{#__RefHeading___Toc99425575 .anchor}Table 4‑5. Absolute Radiometric
Uncertainty Requirements

  ----------------------------------- -----------------------------------
  **Parameter**                       **Requirement (1-sigma)**

  Radiance                            5%

  Reflectance                         3%\[TBR\] of actual TOA
  ----------------------------------- -----------------------------------

[]{#__RefHeading___Toc99425576 .anchor}Table 4‑6. Radiance Levels for
Signal-to-Noise Ratio (SNR) Requirements\
and Saturation Radiances

  -------- --------------- -------------- ------------- ------------------------
  **\#**   **Band**        **Radiance                   **Saturation Radiances,
                           Level for SNR,               L~Max\
                           L\                           ~(W/m^2^ sr µm)**
                           (W/m^2^ sr                   
                           µm)**                        

                           **Typical,     **High,       **Requirement**
                           L~Typical~**   L~high~**     

  1        Coastal Aerosol 40             190           520

  2        Blue            40             190           545

  3        Green           30             194           510

  4        Red             22             150           433

  5        NIR             14             150           263

  6        SWIR 1          4.0            32            66.8

  7        SWIR 2          1.7            11            22.8

  8        Panchromatic    23             156           483

  9        Cirrus          6.0            N/A           83
  -------- --------------- -------------- ------------- ------------------------

#### Radiometric Signal to Noise and Uniformity

##### Pixel Signal-to-Noise Ratios (SNRs)

The median SNRs required for all RBS data for each spectral band shall
be as listed in Table 4-6**.**

###### Case 1

50% of all detectors for each band shall meet or exceed these SNR
values.

###### Case 2

Any detector below 80% of these values shall be considered out-of-spec
per section 4.2.4.7.3.

[]{#__RefHeading___Toc99425577 .anchor}Table 4‑7. SNR Requirements

  --------------- ------------------------ ---------------- ---------------
  **\#**          **Band**                 **SNR            
                                           Requirements**   

                                           **At             **At
                                           L~Typical~\***   L~High~\***

  1               Coastal Aerosol          130              290

  2               Blue                     130              360

  3               Green                    100              390

  4               Red                      90               340

  5               NIR                      90               460

  6               SWIR 1                   100              540

  7               SWIR 2                   100              510

  8               Panchromatic             80               230

  9               Cirrus                   50               N/A
  --------------- ------------------------ ---------------- ---------------

\* - see table 4.5 for definition of Ltypical and Lhigh

##### RBS Data Quantization

RBS data SNR performance shall not be quantization noise limited at
Ltypical and above, i.e., system noise is greater than or equal to 0.5
Digital Number. If meeting this requirement would force greater than 12
bit quantization, then quantization may be limited to 12 bits.

##### Pixel-to-Pixel Uniformity

###### Full Field of View

For a spatially uniform source above 2\*Ltypical, the standard deviation
of the calibrated values across all pixels within a line of RBS data
within a band shall not exceed 0.25% of the average radiance. Temporal
(within column) noise may be averaged to verify compliance with this
specification.

###### Banding 

####### Case 1

For a spatially uniform source above 2\*Ltypical , the root mean square
of the deviation from the average radiance across the line for any 100
contiguous pixels within a line of RBS data within a band shall not
exceed 0.5% of that average radiance. Temporal (within column) noise may
be averaged to verify compliance with this specification.

####### Case 2

For a uniform source above 2\*Ltypical , the standard deviation of the
calibrated values across any 100 contiguous pixels within a line of RBS
data within a band shall not exceed 0.25% (0.5%) (TBD) of the average
radiance across the line. Temporal (within column) noise may be averaged
to verify compliance with this specification.

###### Streaking 

For a spatially uniform source above 2\*Ltypical, the maximum value of
the streaking parameter within a line of RBS data shall not exceed 0.005
for bands 1-7 and 9 or 0.01 for the panchromatic band. Temporal (within
column) noise may be averaged to verify compliance with this
specification.

The streaking parameter is defined by the following equation:

> $Si\  = \ \left| \ Li\  - \ \frac{1}{2}\ (Li - 1\  + \ Li + 1)\  \right|\frac{\ }{\ }Li$

 where:

L i is the calibrated radiance value measured for a pixel at an input
radiance level;

 Li-1 and Li+1 are similarly defined for the (i--1)th and (i+1)th
pixels.

Note: These requirements apply for target radiances with spectral
characteristics as follows: the spectral radiance from bare soil as
observed through a dry atmosphere (excluding band 9), spectral radiance
proportional to the exoatmospheric solar irradiance, and spectral
radiance from a dense vegetation target as observed through a moist
atmosphere (excluding band 9) (See Figure 4-1 TBD and Top of Atmosphere
Radiance Values, MODTRAN 4 TBD Model table values, Section 1.5,
Reference f). The target radiances are all determined using the same
calibration coefficients.

![](media/image2.wmf)

[]{#__RefHeading___Toc99425560 .anchor}Figure 4‑1. MODTRAN 4 Model Table
Values

##### Coherent Noise

Any uniform scene or dark image in any band acquired by the RBS, after
radiometric calibration, shall not contain coherent noise (CN)
components of any frequency (f, cycles/pixel), with relative percentage
amplitude DN%, that is higher than the DN%max level denoted by the
following formula, DN%max(f)= 8.9936 \[TBR\]\*f+1.9364 \[TBR\]. Where
the DN% is given by the ratio of the individual CN component amplitude
to the overall impulse-feature free Peak-to-Valley (i.e. Peak-to-Valley
of the average scene background excluding any impulse noise of very high
or very low pixels), and the individual CN component amplitude is the
amplitude of the wave pattern generated (for example in the model of a
sine wave it will be the amplitude of a sine wave defined as
Asin(b+phase). This coherent noise components restriction applies to all
spectral bands in the fully populated FPA, from the SCA scale shortest
acquisition image to the Full FPA scale scene (177 km x 170 km)
acquisition time.

![](media/image3.jpeg){width="6.0in" height="5.483333333333333in"}

[]{#__RefHeading___Toc99425561 .anchor}Figure 4‑2. Coherent Noise
Threshold Curve

Definition:

DN% = (Amplitude of Coherent component) / (impulse feature free Dynamic
Range in the image)\*100%

#### Saturation Radiances

The RBS shall detect, without saturating, signals up to the Lmax as
shown in Table 4-5. Note**:** For bands 1-8, this corresponds to the
radiance reflected off of a Lambertian target of 100% reflectance
illuminated by the sun at a solar zenith angle of 30°.

#### Polarization Sensitivity 

The RBS polarization sensitivity, as defined by the linear Polarization
Factor (PF), shall be less than 0.05. Note, PF = (Imax-Imin)/
(Imax+Imin).

#### Radiometric Stability 

##### Case 1

Over any time up to 17 days after radiometric calibration, the RBS data
for radiometrically constant targets with radiances greater than or
equal to L-typical shall not vary by more than +/- 95% (2-sigma
confidence interval) of the *sum of 1% of target radiance and the
equivalent radiance of 1 bit*.

##### Case 2

Over any time period between 17 days and 7 years, after radiometric
calibration, the RBS data for radiometrically constant targets with
radiances greater than or equal to Ltypical shall not vary by more than
plus or minus (95% or 2-sigma confidence interval) the *sum of 2% of
target radiance and the equivalent radiance of 1 bit*.

#### Image Artifacts 

##### Bright Target Recovery 

The RBS data shall be such that for an image pixel that has been exposed
to a radiance level of less than or equal to 1.5 times that of the
saturation radiances (Table 4-5), the pixels outside the 7 x 7 region
around that pixel are not altered by more than 1% of their radiance for
bands 1-7 and 9 and 2% for the panchromatic band for radiances at or
above Ltypical.

##### Pixel-to-Pixel Crosstalk 

The RBS data shall be such that the electrical crosstalk-induced
artifacts in pixels caused by regions of pixels having radiance levels
less than the saturation level and which are more than ten pixels away,
shall not exceed 1% of the affected pixels' radiances at or above
Ltypical, after radiometric correction.

#### Dead, Inoperable, and Out-of-Spec Pixels

##### Dead or Inoperable Pixels 

Less than 0.1% of all RBS image pixels in any 177 km x 170 km scene,
shall be dead or inoperable.

Note: Dead or inoperable pixels may be removed from any performance
averages and standard deviations for determining compliance to
performance specifications.

##### Dead or Inoperable Pixels per Band 

Less than 0.25% of the RBS image pixels in any spectral band in any 177
km x 170 km scene shall be dead or inoperable.

##### Out-of-Spec Pixels

Less than 0.25% of the operable RBS image pixels in any spectral band in
any 177 km x 170 km scene shall fail to meet one or more performance
requirements. Note: Out-of-spec pixels may be removed from any
performance averages and standard deviations for determining compliance
to performance specifications.

### Reserved

> .

### In-Flight Calibration Requirements

The RBS shall have on-board calibration systems that provide sufficient
data with precision and accuracy to meet the calibration and stability
requirements of the RBS as described in this document.

#### Calibration Sources

Sources for the calibration shall include celestial objects such as the
sun or moon, and on-board sources such as lamps.

#### Calibration Systems

The calibration systems shall at a minimum include:

1)  A full aperture full system space-grade Spectralon solar diffuser
    with capabilities to assess the diffuser BRDF stability with time in
    all spectral bands and the diffuser deployment orientation stability
    with time. The in-flight calibration system shall maintain absolute
    radiometric accuracy as stated for the RBS instrument or better.

2)  A lamp calibration source with redundancy that illuminates all
    detectors with both irradiance stabilized and current stabilized
    power sources. This source shall have at a minimum a total power
    output monitor.

3)  A device by which the dark signal of the detectors can be monitored
    before, and after image acquisitions. 

4)  Dark detectors on each end of each detector array to generate enough
    data to track bias changes during daylight acquisitions for each
    band and odd/even columns (At least 16 Dark pixels per line of
    readout in the FPA - TBR).

5)  A device by which the linearity of the RBS with respect to radiance
    can be characterized on orbit.

6)  A source designed to be stable between prelaunch and on orbit
    environments and throughout launch. This source shall be exercised
    prelaunch and postlaunch to test the transfer to orbit stability of
    the RBS.

## Reserved 

# DATA STORAGE AND PLAYBACK (DSAP) SUBSYSTEM FUNCTIONAL AND PERFORMANCE SPECIFICATION 

## DSAP Interfaces 

### RBS Interface

The DSAP shall ingest and store to full storage capacity either
compressed or uncompressed (when enabled) RBS formatted image and
ancillary data.

### DSAP Output Interface

The DSAP shall output stored OLI image and ancillary data per the
requirements specified in section 3.6 of this document and Section 5.0
of the OLI-NPOESS 2130 Spacecraft IRD.

#### DSAP CCSDS Image Data Packetization

Unique CCSDS Packet Application ID's shall be assigned for each Spectral
Band of OLI data output per the interface requirements of 5.4.1 of the
OLI-NPOESS 2130 Spacecraft IRD.

#### DSAP Ancillary Data CCSDS Packetization

Unique CCSDS Packet Application ID's shall be assigned for the ancillary
data associated with the Image Data Packets

#### DSAP Fill Frames 

The DSAP Output interface when enabled by the NPOESS 2130 Spacecraft
shall output stored OLI image and ancillary data at the maximum transfer
rate specified in section 5.0 of the OLI-NPOESS 2130 Spacecraft IRD
without fill CADU's until empty.

## DSAP Operational Modes

The DSAP shall at a minimum have the following operational modes.

### Power Off Mode 

The DSAP shall have a power off mode where all DSAP functions and
elements are powered down, except for survival heaters (if required).
There is no requirement to retain stored image and ancillary data while
the DSAP is powered off.

### Power On 

The DSAP power on mode shall provide an orderly start up and
configuration of the DSAP processing, control, and memory electronics,
including execution of internal diagnostics and activation of the
housekeeping telemetry (TLM) interface to the S/C bus.

### Standby Mode

The DSAP shall enter standby mode after successful completion of all
diagnostic checks. While in Standby mode image data and ancillary data
stored in the DSAP storage memory are retained indefinitely unless power
is cycled off. Standby mode can be entered either from power on mode or
from one of the other operational modes (5.3.4-5.3.8)

### Self Test Mode

#### Image Data Pattern

In self-test mode, the DSAP shall generate a predetermined image data
pattern that is applied to the RBS interface at the full uncompressed
data rate which is then stored up to the full available capacity of the
DSAP.

#### Playback

The DSAP shall be capable of playing back stored image or test data to
the downlink output interface while simultaneously recording the test
data.

### Downlink Test Mode

In downlink test mode, the DSAP shall provide a pseudorandom noise (PN,
PRN) pattern of 32,767 bits length (PN15, 2^15^-1) to either or both of
the downlink output interfaces for bit error rate (BER) testing of the
downlink channel.

### Image Data Ingest Mode

Image data from the RBS interface shall be stored in the file format
designated in section 5.4, concurrently with playback if either or both
of the downlink outputs are in operation.

### Playback Mode

RBS file formatted image and ancillary data stored in the DSAP per
requirement 5.4.2 shall be played back to the downlink interface based
upon priorities of the stored image data.

### Allowable Modes of Operations

[]{#__RefHeading___Toc99425578 .anchor}Table 5‑8. Allowable Simultaneous
Modes of Operation

  -------------- --------------- ---------------- ------------ ---------------
  **Mode**       **Self-Test**   **Downlink       **Data       **Playback**
                                 Test**           Ingest**     

  Self-Test      []{.mark}       YES              NO           YES

  Downlink Test  YES                              YES          N/A

  Data Ingest    NO              YES                           YES

  Playback       YES             N/A              YES          
  -------------- --------------- ---------------- ------------ ---------------

The DSAP shall support the concurrent operation of all operational modes
listed in sections 5.3.4-5.3.8 as shown in Table 5-1. (For example the
DSAP could be simultaneously acquiring and storing image data from the
RBS while transmitting previously stored data to a SafetyNet ground
station.

## DSAP Data Storage Requirements

### Data Storage Capacity

The DSAP shall be able to store, at end of mission life (EOL), the
equivalent of at least 150, 177 km × 170 km Image data scenes along with
all necessary ancillary data required for image reconstruction of the
stored scenes.

### Data Storage File Architecture and File Access

The DSAP shall provide a file system that supports storage of the image
and ancillary data as defined in the following:

#### RBS Image Data

The DSAP shall demultiplex RBS image data into unique image data files
which contain separate and unique band sequential RBS image data
formatted into CCSDS packets concatenated together into a single file of
approximately one-quarter of a 177 km x 170 km scene This requirement
does not preclude the RBS from performing some or all of the band
sequential organization and CCSDS formatting of image and ancillary data
or compression of the image data.

#### IDF File Header

Each file shall have an IDF file header that contains a unique
identifier for the file name, a unique timestamp accurate to 1msec
accuracy (TBD), along with file length, sequencing and configuration
information with respect to the formatting and processing modes of the
DSAP.

#### File Attributes

##### Assigning Attributes

The DSAP shall provide a means to assign file attributes that denote
protected data, test data, and/or data that can be overwritten or
deleted following playback.

##### Listing Attributes

These attributes shall also be provided when a directory listing is
requested.

### Ancillary Data Access and Handling

#### Ancillary Data Record Creation

The DSAP shall acquire any necessary image reconstruction and ancillary
data from the spacecraft bus through the DSAP control interface and
create a unique ancillary data record for each image data file store in
the DSAP.

#### Ancillary Data Content

The ancillary data shall include information regarding spacecraft
orientation, yaw steering position, timing, navigation (GPS information)
as well as all instrument and DSAP telemetry housekeeping parameters
(temperature, voltage, operational configuration information, mechanism
states etc...).

### Error Detection and Correction (EDAC) 

The DSAP shall provide EDAC to ensure data stored on the DSAP has no
more than one error in 10E^12^ bits prior to transfer to the either
downlink interface, assuming data is stored for no more than 48 hours.

## Other DSAP Image Data Processing Capabilities

### Image Data and Ancillary Data Time Tagging

Image data and ancillary data CCSDS packets shall be time-tagged in the
secondary headers. The time tags shall include the time of day from the
MIL-STD-1553 data bus. The time tags shall be accurate to 50 µs (TBR)
relative to the spacecraft 1 Hz pulse. The time tags shall have a
resolution of at least TBD.

### Non-uniformity correction

If the OLI-DSAP (or RBS) performs non-uniformity correction (NUC), then
the following shall apply:

#### Reversible and Reconfigurable NUC Algorithm

The NUC algorithm implemented shall be fully reversible and be
reconfigurable to allow for updates due to changes in detector
operability.

#### NUC Coefficient Recording and Transmission

The OLI shall record and transmit the NUC coefficients used with each
data file.

#### NUC Coefficient Reception and Implementation

The OLI shall receive and implement updated NUC coefficient data.

### Data Compression

#### Lossless Compression

Any data compression algorithm applied to OLI image data or ancillary
data shall be lossless.

#### Command On and Off

Data compression shall be commandable on and off.

#### Location of Compression Function

Data compression may be performed in either the DSAP or RBS.

#### Deleted 

### Aggregation

Spatial aggregation of image data shall not occur for any RBS data
stored in the DSAP.

### Deleted 

## Data Playback Capabilities

The DSAP shall provide the following playback capabilities concurrent
with data storage ingest operations.

### Downlink File Playback Prioritization

The DSAP shall play back priority files first, followed by oldest files
next, when a playback is commanded.

### Playback Operations

#### Playback Requests

The DSAP shall playback requested data based upon commands received via
the command and control interface.

#### Time Tag Priorities

The DSAP shall accept a time-range command to identify priority scenes
for playback.

#### Downlink Time Allocation Coordination

The DSAP shall coordinate with the bus command and data handling (OLI
C&DH) system to determine time allocated for SMD playback opportunities.

#### Repeat Playbacks

The DSAP shall support multiple playbacks of stored data.

#### Directed Playbacks

The DSAP shall playback data corresponding to time tags specified in a
command string at the time specified in the command string.

### Playback Requirements

The DSAP shall be able to multiplex image and ancillary CCSDS packets
into a physical AOS CCSDS CADU data stream.

#### Complete Image Data Files

The DSAP shall ensure that complete image data files are provided to the
downlink interface for the physical AOS CADU stream when a playback
command (request) is executed.

#### Reversible Randomization

The DSAP shall provide reversible randomization of the CADU stream to
ensure that there is at least one transition (from "0" to "1" or from
"1" to "0") occurs every 127 bits (PN7 randomization -- TBD).

#### CCSDS Error Detection and Correction

The DSAP shall provide sequential ordering and CCSDS recommended error
detection and correction, (RS 255,223 ) for the output CADU stream.

#### Corresponding Image and Ancillary Data

Image data and the corresponding ancillary data shall always be output
together.

### Null or fill data generation

The DSAP shall insert fill CADUs and fill packets as required to
maintain a synchronous, constant data rate output to the spacecraft
downlink interface.

### Automatic File deletion

The DSAP shall automatically delete or allow overwriting of any image
data files designated for overwrite after the image data file has been
transferred to the DSAP downlink output interface.

### File data overwrite protection

The DSAP shall allow commands to designate any single or set of image
data file as protected which would disable the automated file deletion
feature.

### DSAP File Directory Listing

The DSAP shall, on command, provide a listing or directory of its file
system including key file attributes, to be transferred as a separate
CCSDS packet type via the wideband interface and/or may be also
transferred through the DSAP control interface via the S/C telemetry
path to the ground.

## DSAP Fault Detection and Correction

The DSAP shall have autonomous internal fault detection and correction
capabilities to provide notification of anomalous operating conditions
through the command and control interface.

### Graceful Degradation

The DSAP shall be designed for graceful degradation of data storage
capacity in the event of failed memory functions, with no more than 5%
of DSAP data storage capacity being affected by any failed memory board
or memory board component per failure.

## DelETED 

# GSE REQUIREMENTS

This specification establishes the functional and performance
requirements for the Ground Support Equipment (GSE) to be used for
verification of the Operational Land Imager (OLI) instrument. The GSE
comprises the unique equipment required to operate, handle, test, and
calibrate the OLI at the contractor's facility and at the spacecraft
integrator's facility.

The OLI GSE shall consist of the following:

a.  System test equipment (STE)

b.  Calibration test equipment (CTE)

c.  Handling fixtures

d.  Test fixtures

e.  Shipping / storage containers

## System Test Equipment (STE)

### OLI Operation

The System Test Equipment (STE) shall comprise the hardware, software,
and cabling and be used to operate the OLI during performance
verification and calibration testing by both by the instrument
manufacturer and by the spacecraft integrator at their respective
facilities and at the launch facility.

### Interfaces

The STE shall provide all possible interfaces, e.g., power, clock,
command, and telemetry.

### Capabilities

The STE shall be capable of recording, displaying, distributing, and
analyzing the data received from the OLI and ground support equipment
including all instrument test points.

### Data Capture and Record

The STE shall be capable of real-time data capture and recording all
data as received from the OLI and GSE

### Dynamic Display

The STE shall be capable of real-time dynamic data display.

### Hard Copy

The STE shall have the capability of generating hard copy print out of
all analysis results, screen dumps, and processed data.

### Hard Media

The STE shall have the capability of generating and receiving hard media
(e.g., Tape, DVD).

### Signal and Power Inputs

The STE shall furnish all power, timing signals, and commands needed by
the OLI and normally supplied by the spacecraft.

#### Power Line Isolation

All power lines shall be physically isolated from signal lines, i.e., by
shielded and separate cables.

#### Short Circuit and Voltage Transient Protection

The power supplies shall have short-circuit protection and
voltage-transient protection.

### Processing Capabilities

The STE capabilities shall include:

a.  Performing a self-test

b.  Sending commands to the instrument

c.  Controlling the simulated S/C interfaces and external calibration
    GSE

d.  Receiving data from the OLI, GSE, and test chamber

e.  Performing health and safety checks to guarantee the safety of the
    instrument (in all states)

f.  Analyzing the data in real-time and in an off-line mode

#### Timeliness

The STE shall be capable of timely, within 2 hours (TBR), data analysis
/ processing during testing.

#### Trending and Sensor Data Analysis Software

The STE shall include engineering and instrument data trending
capability and sensor data analysis tools to determine the performance
characteristics of the instrument.

#### Previously Captured Data

The STE shall simultaneously operate and monitor the instrument and
perform data analysis.

### Display

The STE shall display instrument engineering data as well as external
GSE data.

#### Information Selection

The STE shall have the capability of selecting information to be
displayed from a set of pre-stored display templates.

#### SI Units

The STE shall have the capability of displaying test data in SI Units as
well as raw digital numbers.

#### Operator Interface

The STE shall have an operator interface.

### STE Interface to CTE

The STE shall provide an interface with the OLI CTE so that data will be
entered into the automated data system and correlated (TBR).

###  Power

The STE shall operate from a 115-volt, 60-Hertz (Hz) line.

### Limits Program

The STE shall have the capability of monitoring all command states,
selected voltages, currents, temperatures, and other telemetered and
derived parameters of the OLI and ancillary GSE telemetry in real-time.

#### Critical Function Monitoring

Critical Functions shall be monitored.

#### Critical Fault Handling

The STE shall alarm if a critical fault occurs and will automatically
protect the instrument if appropriate operator action is not taken.

#### Operational Mode Verification

The STE shall be designed to verify all operational modes of the OLI and
record and alert the operator of any out-of-tolerance items as they
occur.

#### Automatic Sequence Bypass

All automatic sequences resident in the instrument or in the STE shall
be capable of being bypassed by commands.

#### Program Operational Availability

At the first application of power during instrument integration and
continuing through all periods of operation and/or test, the limits
check program shall be operational.

#### Command and Operational Time Log

The STE shall maintain a command and operational time log.

## Calibration Test Equipment (CTE)

### Instrument Characterization / Calibration

Calibration Test Equipment (CTE) shall provide the capability to fully
characterize and calibrate the instrument.

### Availability for Spacecraft Level Tests

A sufficient set of CTE shall be provided for use at the spacecraft
contractor\'s facility for all spacecraft-level tests.

## Handling Fixtures

Handling fixtures shall have the capability of moving the OLI, removing
the OLI from and returning it to the shipping/storage container, and for
integration of the OLI onto the spacecraft.

## Test Fixtures

Test fixtures shall be provided to support performance verification,
environmental testing and calibration of OLI.

## Shipping / Storage Containers

The OLI shipping & Storage Containers shall be reusable,
water-resistant, and airtight with filtered pressure control system.

### Purge

The containers shall incorporate means of purging with dry nitrogen or
dry air.

### Temperature, Humidity, Shock and Pressure Monitors

#### Container Measurements

The containers shall incorporate means of measuring and recording
shocks, temperature and humidity within the container.

#### External Container Indicators

Temperature, humidity, and pressure monitors shall have external
indicators on the outside of the containers.

### Airtight Conditions

#### Duration

Containers shall maintain airtight conditions for over 3 (TBR) weeks
with an internal pressure greater than 1.05 atm.

#### Airlifting

Containers shall be capable of being airlifted without loss of internal
pressure.

### Other GSE

For all other GSE, reusable storage/shipping containers shall be
provided.

### Use in Clean Room

All containers shall be suitable for use in the clean room, after a
minimal amount of cleaning.

## Environmental Conditions

### General Conditions

GSE shall generally be subject to controlled environments typical of
instrument manufacturer test and integration facilities.

## Transportability

GSE shall be designed to facilitate mobility within test and integration
facilities of the instrument manufacturer.

## Marking

All GSE assemblies shall be marked with the assembly name, part number,
and connector reference designations.

###  {#section-3 .unnumbered}

# OLI PROCESSOR(S), SOFTWARE AND COMMAND AND DATA HANDLING REQUIREMENTS

## On-Board Processors (OLI-OBP(S))

On-Board Processors refers to the CPU, RAM, ROM, NV-RAM, clocks, and
component interface and monitor circuitry such as temperature, voltage,
and current sensors.

### OLI-OBP(S) Radiation Immunity 

The OLI-OBP(S) shall be sufficiently radiation immune/tolerant and
redundant to support mission lifetime requirements.

### SEUs

The OLI-OBP(s) shall be protected against SEUs and other memory and
processor errors through the use of design features such as radiation
hardened parts, memory error detection and correction (EDAC), periodic
software refresh of critical hardware registers, processor and register
majority voting, watchdog timers, etc.

### Flight Load Non-volatile Memory 

The OLI-OBP(s) shall possess sufficient non-volatile memory to contain
the entire OLI flight software image at launch.

###  Flight Processor Resource Sizing

During development, flight processors providing computing resources for
OLI subsystems shall be sized for worst case utilization not to exceed
the capacity shown below (measured as a percentage of total available
resource capacity):

[]{#__RefHeading___Toc99425579 .anchor}Table 7‑9. Flight Processor
Resource Sizing

  ---------------------- ---------------- --------------- ----------------
  **Resource/Phase**     **S/W PDR**      **S/W CDR**     **S/W AR**

  RAM Memory             40%              50%             60%

  EEPROM Memory          30%              40%             50%

  CPU                    30%              40%             50%

  I/O Bandwidth          30%              40%             50%

  Bus Utilization        30%              40%             50%
  ---------------------- ---------------- --------------- ----------------

#### Resource Utilization Monitors 

The OLI flight software shall provide the capability to monitor the
resource utilization by software subsystems or critical functions.

#### Downlink in Telemetry

The resource utilization monitors shall be available for downlink in
telemetry.

### Watchdog Timer 

The OLI-OBP(s) shall provide a watchdog timer that can cause a hardware
reset to the OLI-OBP(S).

#### Watchdog Timer Enable/Disable 

The OLI-OBP(s) watchdog timer shall be capable of being enabled and
disabled by a hardware ground command.

#### Watchdog Timer Update

The OLI flight software shall update the watchdog timer at a TBS rate
when all critical software functions are executing nominally.

### Reset Hardware Command

The OLI-OBP(s) shall be capable of being reset via hardware command

### Reset/Reboot/Reinitialization Self-test

The OLI-OBP(s) shall be capable of performing an autonomous self-test of
the OLI-OBP(S) hardware (processor, bus, memory, etc.) upon hardware
reset or initial power-on.

### On-orbit Reprogrammability without OLI-OBP(S) Restart/Reboot 

The OLI-OBP(s) shall be reprogrammable on-orbit to allow for new
versions of software segments and table values to be loaded from the
ground without computer restart.

### High Speed Test Access Port

The OLI-OBP(s) shall include a built-in test access port, allowing
high-speed loading and dumping of processor memory to support pre-launch
testing.

### OLI-OBP(S) Clock Accuracy 

The OLI-OBP(s) clock shall provide sufficient resolution and stability
to meet all OLI flight software timing requirements.

### OLI-OBP(S) Timing Interface

The OLI-OBP(s) shall be able to correlate all data and execute
time-tagged commands relative to GPS time standard.

## Redundancy Management

The instrument shall have the ability to autonomously perform
reconfiguration of redundant components as required to enter into a safe
mode.

### Redundant Component Status 

#### Redundant Monitors Telemetry

The status of all redundant components shall be telemetered to the
ground.

#### Ground Override of Component Status

The OLI-OBP(s) shall allow the effective status of any redundant
component to be settable by ground command.

####  Retention of Redundant Component Status 

The OLI-OBP(s) and associated OLI flight software shall provide a means
by which the OLI-OBP(s) retains knowledge of the status of redundant
components following processor restart, processor failover, RAM memory
loss, or bus under-voltage so that the instrument avoids switching to
previously failed components.

#### Component Status Determination

The OLI flight software shall interrogate and determine the status of
instrument components.

### Redundant Component Configuration

#### Autonomous Component Switch

The OLI-OBP(s) shall not autonomously switch control to a failed
redundant component.

#### Commandability of Redundant Component Configuration 

The operational configuration of OLI-OBP(s) redundant components (e.g.,
processor, Instrument bus, memory, non-volatile memory, etc.) shall be
commandable and configurable from the ground.

#### Retention of Instrument Configuration 

The OLI-OBP(s) shall provide a means to retain knowledge of the correct
instrument configuration (i.e., which of the redundant components is to
be used as the active component) through events such as bus
undervoltage, processor reboots, and processor switchovers.

#### Autonomous Reconfiguration Limit

Autonomous reconfigurations shall not be required for normal operations
of the instrument or its components.

#### Ground Override of Autonomous Anomaly Responses 

All OLI flight software autonomous functions, automatic safing, or
switchover capabilities shall be capable of being separately disabled,
enabled, executed, or over-ridden, or aborted by ground command.

#### Reconfiguration Notification

All autonomous equipment reconfigurations initiated by the OLI flight
software shall be reported in normal telemetry, and shall generate a
critical event message.

## OLI flight software

### General Requirements 

All OLI flight software (including firmware) programs and data for the
OLI-OBP(s) shall meet the requirements in this section.

### Software Module Upload 

The OLI flight software shall be capable of being uploaded in modules,
units, segments, or objects.

###  Flexibility and Ease of Software Modification 

The OLI flight software design shall be flexible and table-driven for
ease of operation and modification. It shall be rigid in terms of
scheduling and prioritization of critical processing tasks to ensure
their timely completion. Limits and triggers for anomaly responses shall
be readily accessible and changeable by ground command.

#### Tables 

All OLI flight software data that are anticipated to be modified or
examined by ground operators shall be organized into tables.

##### Table Locations

The OLI flight software shall have knowledge of the location of each
table such that ground operators need only reference a table number (for
the entire table), or a table number and position within the table (for
a partial table).

##### Physical Memory Locations

The OLI flight software shall internally maintain table physical memory
locations such that the ground can load and dump tables without the
knowledge of where the data resides in physical memory, and no ground
software or database change shall be required when the data is relocated
due to a recompilation of the OLI flight software.

#### Command Definition Independent from Processor Physical Memory Locations 

The definition of OLI commands within the ground database shall not be
dependent on physical memory addresses within the OLI flight software.

##### No Usage of Uploaded Physical Addresses

All commands processed by the OLI flight software (with the exception of
7.4.13 ) shall be interpreted by the OLI flight software without the use
of any uploaded physical address.

##### Command Definitions Unaffected by Recompiling

Existing command definitions in the database shall be unaffected when
the OLI flight software is recompiled.

### Responsiveness to Ground Originated Changes 

The OLI flight software design shall accommodate processing of ground
commands, on-orbit revisions to software and telemetry formats, and
computer self checks.

### Software Event Logging in Telemetry 

The OLI flight software shall include time-tagged event logging in
telemetry. The event messages shall capture all anomalous events, and
important system performance events.

### Software Version Number

The OLI flight software shall store the version of the software onboard.

#### Retrievability

The OLI flight software version number shall be retrievable (either in
telemetry or table dump). 

#### Version Number Modifications

The OLI flight software version number shall be modified whenever the
software was modified.

####  Event Message Filter 

The OLI flight software shall provide a means to filter (discard)
individual event messages.

#### Event Counters 

The OLI flight software shall maintain counters for the total number of
event messages generated, for the number of event messages discarded
because of queue overflow, and for the number of event messages
discarded by filters.

### Initialization 

The OLI flight software shall provide for separate Cold Restart and Warm
Restart initialization processing.

#### Cold Restart Initialization

The OLI flight software shall execute the Cold Restart initialization
processing when starting execution from a hardware reset.

##### Cold Restart Initialization Execution Steps

The Cold Restart initialization shall execute from non-volatile memory,
shall reset the command counter, and shall restore default telemetry
contents.

##### OLI flight software Configuration

The Cold Restart initialization shall place the OLI flight software in a
safe, known, deterministic configuration.

#### Warm Restart Initialization 

The OLI flight software shall execute the Warm Restart initialization
processing when restarting the OLI flight software from software
command.

##### Preservation of Statistics, Memory Tables, and Command Sequences

The Warm Restart Initialization shall preserve command processing
statistics, and shall preserve memory tables and command sequences that
were previously uploaded.

##### Avoidance of Warm Restart Loops 

When the Warm Restart count equals or exceeds a predetermined value, the
OLI flight software shall affect a Cold Restart in lieu of the Warm
Restart.

## Failure Detection and Correction (FDC)

The OLI flight software shall continuously monitor instrument health and
safety data and, in the event of an anomaly, safely configure the
instrument and report the anomaly to the ground in telemetry.

### Critical OLI-OBP(S) Function Protection

The OLI-OBP(s) shall protect critical functions from temporary or
permanent faults or errors within all processors, including protection
against such failure modes as infinite software loops, race conditions,
and bus under-voltage conditions.

### OLI-OBP(S) Health and Safety Monitoring

The OLI-OBP(s) shall continuously monitor its health and safety and
report the result of its health and safety checks to the ground in
spacecraft telemetry.

### Failsafe Recovery Mode

The OLI flight software shall provide a failsafe recovery mode that
depends on a minimal hardware configuration with all interrupts disabled
and is capable of accepting and processing a minimal command subset that
is sufficient to load memory and begin execution at a specified memory
address.

###  OLI flight software Monitors

The OLI flight software shall provide a table driven means for verifying
proper execution of critical software tasks or functions, and perform a
corrective action in the event that one or more of the critical tasks
fails to meet performance requirements.

### Health and Safety Monitor Table

The OLI flight software shall provide a table driven mechanism for
defining anomalous conditions and the corrective action(s) to be
performed in response for each condition.

###  Health and Safety Monitor Table Entries

The anomalous conditions defined in the Health and Safety Monitor table
shall include software generated event messages, component status data,
and all subsystem, software, and housekeeping data.

### Monitor Table Actions

The actions defined in the Health and Safety Monitor Tables shall
include execution of one or more stored command sequences.

###  Ground Control of Health and Safety Monitor Table

The Health and Safety Monitor table as a whole, and single entries
within the table, shall be enabled, disabled, loaded and dumped by
ground command.

### Memory Table Verification

The OLI flight software shall implement tables in memory such that
individual segments of tables can be verified, and reloaded from the
ground.

###  Memory Location Load and Dump Capability 

The OLI flight software, and associated on-board computer hardware,
shall provide the capability to load & dump any location of on-board
memory to the ground upon command by referencing its physical memory
address.

### Segment, Module, and Object Upload and Dump 

The OLI-OBP(S) shall support the upload and dumping of OLI flight
software in segments, modules, tables, or objects.

###  Memory Dumps During Normal Operations

The OLI flight software memory dump capability shall not disturb normal
operations.

### Memory Dwell

The OLI flight software shall provide a mechanism to telemeter the
contents of selected addresses in memory to support debugging efforts
and provide additional telemetry points which may have been
unanticipated at development time.

###  Dwell Tables

The memory dwell function shall have the ability to sample selected
memory addresses at rates exceeding the rate at which the dwell data is
reported in the telemetry stream.

###  Dwell Table Control

The dwell table and each entry within the table shall be capable of
being enabled, disabled, loaded, or dumped via ground command.

## Command and Data Handling (OLI C&DH)

### Stored Commands

The OLI-OBP(s) flight software shall provide three types of stored
commanding: stored time-tagged single commands, stored absolute-time
command sequences, and stored relative-time command sequences.

#### Stored Time-tagged Single Commands 

The OLI C&DH shall provide the capability to store time-tagged single
commands, and execute those commands at the absolute time identified in
the command\'s time-tag.

##### Stored Commands Dump

The OLI C&DH shall provide a mechanism to read out the time-tagged
contents of the command storage buffers.

##### Stored Command Modifications

OLI Stored commands shall be modifiable by ground command, including the
addition and deletion of time-tagged commands.

##### Telemeter ID on Execution

A command identifier shall be telemetered upon execution of each stored
command.

##### Command Schedule Uplink

The stored command schedule shall be selectable, interruptible, and
uplinkable via ground command.

##### Stored Command Timing Accuracy 

The resolution of the least significant bit of the specified time shall
be one second.

##### Stored Command Transmission

The OLI flight software shall send stored commands within 0.1 seconds of
the requested time.

#### Stored Command Sequences

The OLI C&DH shall provide both absolute-time stored command sequences
and relative-time stored command sequences. All requirements in this
section apply to both types of stored command sequences.

##### Stored Sequence Modifications

The absolute-time and relative-time stored command sequences shall be
stored in onboard RAM, and be modifiable by ground command including the
addition and deletion of separate command sequences.

##### Command Sequence Table Dumps

The absolute-time and relative-time stored command sequence capability
shall be designed so that each stored command sequence table can be
dumped to the ground by a single, simple command and not by an elaborate
memory dump procedure.

##### Sequence Identification

Each absolute-time and relative-time stored command sequence shall have
a unique identifying name or number.

##### Sequence Thread Identification

The OLI C&DH shall use the unique command sequence identifiers to report
the status of each actively executing command sequence in telemetry.

##### Stored Sequence Control

Individual absolute-time and relative-time command sequences shall be
enabled, disabled, paused, or cancelled by ground command.

##### Command Validation

Absolute-time and relative-time stored commands shall be validated like
other commands, with any command sequence whose command has failed
validation suspending execution and reporting the problem in telemetry.

##### Command Sequence Reports in Telemetry

There shall be indicators in normal telemetry reporting all of the
absolute-time and relative-time stored command sequences that are
currently active, with each command executed from a stored sequence also
being reported in normal telemetry.

##### Scheduled Sequences Reported in Telemetry

A time-ordered preview of pending absolute-time commands and pending
relative-time commands in active stored command sequences shall be
reported in telemetry.

##### Sequence Activation

The OLI C&DH shall provide for absolute-time stored command sequences
and relative-time stored command sequences to be activated by a simple
command that references the identifying name or number of the command
sequence.

##### Activation by Stored Command

Real time and stored single commands shall have the ability to invoke
absolute-time stored command sequences and relative-time stored command
sequences.

##### Stored Command Sequence Capacity

The number of absolute-time and relative-time stored command sequences
and maximum size of any particular stored command sequence shall be
limited only by the size of the Command Sequence Storage Table.

##### Stored Command Timing Accuracy

The resolution of the least significant bit of the specified time shall
be one second.

##### Stored Command Transmission Time

The OLI flight software shall send stored commands within 0.1 seconds of
the requested time.

##### Late Commands

In the event that current time is past the execution time for any stored
command, then the corresponding command sequence shall suspend execution
and report the problem in telemetry

#### Absolute-time Stored Command Sequences

The OLI C&DH shall provide the capability to store multiple sequences of
absolute-time time-tagged commands, and to execute those commands at the
absolute time identified in the time-tag associated with each command in
the sequence.

##### Concurrent Absolute-time Command Sequence Execution

The OLI C&DH shall have the ability to execute TBS (multiple)
absolute-time stored command sequences concurrently.

##### Absolute-time Command Time-Tags

Each command of an absolute-time stored command sequence shall have a
time-tag that references a fixed absolute time.

#### Relative-time Stored Command Sequences

The OLI C&DH shall provide the capability to store multiple sequences of
relative-time time-tagged commands, and to execute those commands at the
time identified in the time-tag associated with each command in the
sequence (see section 7.5.1.4.2).

##### Concurrent Command Sequence Execution

The OLI C&DH shall have the ability to execute TBS (multiple)
absolute-time stored command sequences concurrently.

##### Relative-time Command Time-Tags

Each command of a relative-time stored command sequence shall have a
time-tag that specifies a variable delta time interval relative to the
time that the previous command in the sequence was executed. The first
command of a relative-time command sequence can have a relative-time of
zero to indicate that it is to be executed immediately upon sequence
activation.

##### Nested Sequence Activation

Relative-time stored command sequences shall be capable of invoking
other relative-time stored command sequences, but not themselves
directly.

##### Sequence Activation Loops

The OLI C&DH shall report command sequence activation chains in
telemetry for the ground system to alert operators when a command
sequence execution thread is in a sequence activation loop.

##### Re-entrant Command Sequences

The OLI C&DH shall be capable of executing any relative-time stored
command sequence within the context of multiple different active
sequences concurrently.

##### Sequence Nesting Depth

The OLI C&DH shall provide the capability for command sequences to nest
up to 8 levels deep.

### Schedule Management

One or more daily schedules, i.e. Absolute Time Sequence (ATS), are
created and maintained by the ground system for instrument operations.
These schedules will be stored on-board the OLI and executed by the OLI
flight software. The OLI flight software shall provide the capability
for ground system to select the schedule to be run, or to switch to a
different schedule, or to modify a schedule and switch to a modified
schedule.

#### Stored Command Capacity

The OLI flight software shall provide the capacity to store command
sequences to provide a minimum of two full 48-hour instrument schedules.

### Command Processing

#### Command Sources

The OLI C&DH command processor shall provide four (4) different command
modes: real-time single commands, stored time-tagged single commands,
stored absolute-time command sequences, and stored relative-time command
sequences. Stored commands are defined in the previous section.

#### Concurrent Command Functions

The OLI C&DH shall be capable of processing real-time commands while
concurrently executing long-duration commands such as on-board processor
uploads.

##### Command Source Priority

When commands from more than one source are ready to be executed at the
same time, all of the ready commands shall be executed in sequence
according to a command source priority. Real-time single commands first,
stored time-tagged single commands next, then stored absolute time
sequence commands, then stored relative time sequence commands. When
more than one command sequence of the same type ( e.g. two relative time
sequences ) have a command ready to execute at the same time, the
commands shall be executed in TBD sequence.

#### Common Command Requirements

The requirements listed in this section and subsections apply to all
commands regardless of source.

##### Command Verification 

All commands shall be verified by changes in telemetry data.

##### Command Rejection Indication

The command system shall provide an indication of command rejection.

##### Command Termination

Any on-going command execution shall be capable of immediate
termination.

##### Command Buffer Reset by Ground

All command storage buffers shall be capable of ground-initiated reset
or clear.

##### Command Lockout

There shall be no command lockout.

##### Command Data Tables

Commands shall be capable of accessing information from one or more
separate data tables stored in onboard RAM.

##### Parameter Table Load

The OLI C&DH shall provide the capability to load a parameter of a table
without loading the entire table.

#### Real-time Single Commands

Real-time single commands shall execute immediately following
verification of proper receipt from the spacecraft.

##### Command Execution Sequence

The OLI C&DH shall implement an instrument/ground mechanism to prevent
command execution out of sequence.

##### Command Counter

The OLI C&DH shall implement a command protocol to account (preferably
via command count) for all real-time commands accepted by the instrument
for execution.

#####  Single Function Commands

Each real-time command shall perform only one function, fully identified
in the command data field. For example toggle commands would not be
permitted as they do not fully define the final state.

### Telemetry Parameters

OLI shall provide sufficient spacecraft telemetry to ensure proper
control and monitoring of OLI health and safety, and to identify
anomalous conditions.

#### Parameter Resolution

Each individual data channel shall be sampled at a rate sufficient to
resolve parametric changes in the data being measured.

##### User Defined Telemetry

The OLI C&DH shall provide the capability to accept uploaded
ground-defined telemetry stream definitions consisting of any
combination of parameters and sample rates.

#####  Telemetry Definitions Storage

The OLI C&DH shall provide onboard storage for TBD different User
Defined telemetry streams.

##### Telemetry Stream Activation

The OLI C&DH shall provide the capability to select a telemetry stream
definition from onboard storage via a single ground command.

##### Telemetry Channel Capacity

Transmission of memory and table dumps; special telemetry streams, or
user-defined telemetry streams shall not preclude the transmission of
the normal telemetry stream.