The National Polarorbiting Operational Environmental Satellite System NPOESS Interface Data Processi

1
The National Polar-orbiting Operational
Environmental Satellite System (NPOESS)
Interface Data Processing Segment Field
Terminal Segment Gerard WittmanNPOESS Program
ManagerRaytheon Company

• October 21, 2004

2
Concept of Operations

• Sense Phenomena
• Downlink Raw Data
• Transport Raw Data to Centrals For Processing
• Process Raw Data into EDRs and Deliver to
  Centrals
• Monitor and Control Satellites and Ground Elements

Reliable and timely collection, delivery, and
processing of quality environmental data
3
NPOESS Mission Objectives and User Needs Drive
System Performance
4
NPOESS Architecture
5
Mission Data Flow
SMD
C3S
C3S
Centrals
Space Vehicle 3
Space Vehicle 3
C3S
C3S
CONUS
CONUS
SMD
SMD
DHN
Gateways
DHN
Gateways
Ground
Ground
Space Vehicle 2
Space Vehicle 2
Long Term Archive
FEP
FEP
(4x)
(4x)
Receptor
Receptor
Space Vehicle 1
Space Vehicle 1
(_at_ IDPS)
(_at_ IDPS)
Mission
Mission
Ground
Ground
Sensors
Bus
Bus
Sensors
Management
Management
Station
Station
Deliver Data Products
Center
Center
Stored Mission Data flow for Centrals and Science
Data Users
HRD
Field Users
Field
Field
LRD
Terminal
Terminal
Software
Software
Field Terminals (LRD, HRD)
Field Terminals (LRD, HRD)
Deliver Data Products
HRD, LRD Data flow for Field Users
SARSAT, ADCS Terminals
Timely, Accurate, Reliable Data from Sensors to
Users
6
NPOESS Satellite
Single Satellite Design with Common Sensor
Locations
7
Payload Team Summary by Sensor Type and Supplier
8
NPOESS EDR-to-Sensor Mapping
Cloud Top Pressure
Precipitable Water
Atm Vert Moist Profile
Cloud Top Temperature
Precipitation Type/Rate
Atm Vert Temp Profile
Imagery
Pressure (Surface/Profile)
Down LW Radiance (Sfc)
Sea Ice Characterization
Down SW Radiance (Sfc)
Sea Surface Temperature
Electric Fields
Sea Surface Height
Sea Surface Winds
Soil Moisture
Snow Cover/Depth
Electron Density Profile
Energetic Ions
Solar Irradiance
Aerosol Optical Thickness
Geomagnetic Field
Aerosol Particle Size
Supra-Therm-Aurora Prop
Aerosol Refractive Index
Surface Type
Ice Surface Temperature
In-situ Plasma Fluctuation
Albedo (Surface)
Active Fires (Application)
Auroral Boundary
Surface Wind Stress
In-situ Plasma Temp
Auroral Energy Deposition
Suspended Matter
Ionospheric Scintillation
Auroral Imagery
Total Water Content
Med Energy Chgd Parts
Vegetative Index
Land Surface Temp
Cloud Base Height
Net Heat Flux
Cloud Cover/Layers
LEGEND
Cloud Effective Part Size
Net Solar Radiation (TOA)
VIIRS (22)
ERBS (4)
Cloud Ice Water Path
Neutral Density Profile
CMIS (19)
TSIS (1)
CrIS/ATMS (3)
ALT (2)
Ocean Color/Chlorophyll
Cloud Liquid Water
OMPS (1)
APS (4)
Cloud Optical Thickness
APS not yet on contract
Ocean Wave Characteristics
SESS (13)
Outgoing LW Rad (TOA)
Cloud Particle Size/Distrib

• Key Performance Parameters

Cloud Top Height
O3 Total Column Profile
NPP EDRs (26) in black font
Change under consideration
9
NPOESS EDR Processing Timeline
End-to-End EDR Latency
Requirement 95 of data delivered within
28 min. Capability Delivering in 24.1
minutes
Requirement gt77 of data delivered
within 15 min. Capability Delivering 80.3
Average lt 10 min
Earliest Data Delivered lt 3 min
10
Average Data Latency
Latency (minutes)
11
Mission Data Flow
SMD
C3S
C3S
Centrals
Space Vehicle 3
Space Vehicle 3
C3S
C3S
CONUS
CONUS
SMD
SMD
DHN
Gateways
DHN
Gateways
Ground
Ground
Space Vehicle 2
Space Vehicle 2
Long Term Archive
FEP
FEP
(4x)
(4x)
Receptor
Receptor
Space Vehicle 1
Space Vehicle 1
(_at_ IDPS)
(_at_ IDPS)
Mission
Mission
Ground
Ground
Sensors
Bus
Bus
Sensors
Management
Management
Station
Station
Deliver Data Products
Center
Center
Stored Mission Data flow for Centrals and Science
Data Users
HRD
Field Users
Field
Field
LRD
Terminal
Terminal
Software
Software
Field Terminals (LRD, HRD)
Field Terminals (LRD, HRD)
Deliver Data Products
HRD, LRD Data flow for Field Users
SARSAT, ADCS Terminals
Timely, Accurate, Reliable Data from Sensors to
Users
12
Interface Data Processing Segment (IDPS)
Functional Diagram
13
IDP Segment Design

• Combines software and hardware flexibility,
  expandability, and robustness to meet stringent
  performance requirements
• Granule based processing of high quality products
  within latency timelines
• Fault tolerant hardware and software ensures
  maximum data are available to users within
  operational timelines
• Modular software isolates impacts of changes to
  basic architecture provides for rapid, low
  impact recovery from hardware and software
  failures
• Expandable hardware permits addition of new
  capabilities without impact to existing system
• Low level of manning one 24x7 IDPS operator
  position (5 heads), one 8x5 Data Quality Engineer
  position (1 head), one 8x5 IT (SA, DBA, CM)
  specialist (1 head)

High Quality Products Within Latency Timelines
14
IDP Segment Approach

• High performance IBM computing hardware
• Each Central has a complete system that generates
  all products within required latencies
• Each IDPS or Central contains an Operations
  string, an Integration and Test (IT) string, and
  shared disk arrays (RAID)
• Operations string carries 100 reserve capacity
  and additional availability processors
• IT string can be used for integration and test
  of new software, support for technology
  insertion, parallel operations, failover, and
  algorithm development
• Modular, workflow-managed software
• Receives multiple data streams from C3S,
  processes data into RDRs, SDRs, TDRs, and EDRs,
  packages products into form useful for Centrals,
  and delivers requested products
• Centrals have control over what products are
  created, which ancillary data sets are used, and
  how products are delivered
• Dual use IDPS core software is also used in field
  terminals
• Will be made available worldwide via download
  from the internet
• DII-COE, JTA and POSIX standards adherence
• Careful usage of deployable COTS
• CORBA ORB, Notification service, naming service,
  science libraries, HDF5
• ARC GIS isolated in DQM which is NOT supported at
  Field Terminals
• Single source base

15
Mission Data Flow
SMD
C3S
C3S
Centrals
IDP
IDP
Space Vehicle 3
Space Vehicle 3
_at_
_at_
C3S
C3S
CONUS
CONUS
SMD
Centrals
Centrals
SMD
DHN
Gateways
DHN
Gateways
Ground
Ground
Space Vehicle 2
Space Vehicle 2
Long Term Archive
FEP
FEP
(4x)
(4x)
Receptor
Receptor
Space Vehicle 1
Space Vehicle 1
(_at_ IDPS)
(_at_ IDPS)
Mission
Mission
Ground
Ground
Sensors
Bus
Bus
Sensors
Management
Management
Station
Station
Deliver Data Products
Center
Center
IDPS
IDPS
Stored Mission Data flow for Centrals and Science
Data Users
HRD
Field Users
Deliver Data Products
SARSAT, ADCS Terminals
Timely, Accurate, Reliable Data from Sensors to
Users
16
Field Terminal Segment Architecture

NPOESS HRD or LRD
NPP HRD
Signal Processing Subsystem (SPS)
Mission Application Subsystem (MAS)
Data Processor Element (DPE)
FT Technical Specification
Field Terminal Segment

Internet
Mission Support Data Server
NPOESS provides the Data Processing Software and
the Hardware Specifications
17
Field Terminal Segment Design

• Dual use of IDPS software provides a best-value
  design that combines software and hardware
  flexibility, expandability, and robustness to
  meet stringent performance requirements
• IDPS designed with sufficient forethought to
  ensure it meets FTS needs
• JTA and DII COE Level 6 compliance minimize
  impacts to user interfaces and existing/future
  field terminals
• Lower development and maintenance costs
• FT users get timely access to latest algorithms
  ensuring quality EDRs
• Provides interoperability and hardware platform
  options
• Flexible design ensures users get the data they
  need when they need it
• Programmable downlink that favors high-resolution
  imagery and provides flexibility for the future
• Flexible ancillary data approach (critical
  ancillary data via satellite downlink for LRD)
• Data compression, channel selection

18
FTS EDR Performance

• HRD EDR Performance
• 99 of EDR performance attributes meet or exceed
  performance thresholds
• Analysis shows latency requirements achievable
  with current COTS workstations
• As with the IDPS software, the FT software adapts
  to missing channel data or missing ancillary data
  and uses graceful degradation rules
• LRD EDR Performance
• Meets key users needs 0.8 km resolution imagery
  and programmable downlink
• Produces the 8 high priority EDRs at or near LRD
  objective levels
• Produces all 15 lower priority EDRs and required
  predecessor EDR products
• Designed to automatically recognize missing
  channels and ancillary data

Flexibility to Keep Pace with Changing Needs
19
Summary
NPOESS Serving The Nations Needs
20
Questions
21
(No Transcript)