Tom Ryan March 18, 2010 Federal Aviation Administration NextGen Network Enabled Weather

Tom Ryan

March 18, 2010

Federal AviationAdministrationNextGen Network

Enabled Weather

2Federal AviationAdministration

NNEW March 18, 2010

Table of Contents

• Introduction & Background• High-Level Segment 1 View & Transition• Service Adaptors & Data Flow Spreadsheet• Architecture• Demonstrations & Capability Evaluations• Backup


NNEW March 18, 2010

Table of Contents

• Introduction & Background• 4-D Wx Data Cube• Architecture• High-Level Segment 1 View & Transition• Backup


NNEW March 18, 2010

Introduction & Background


NNEW March 18, 2010

The Basis for the NNEW Program


NNEW March 18, 2010

NextGen Goals from NextGen CONOPS v2• Network-Enabled Information Access• Performance-Based Services (now Performance-Based

Operations and Services)• Weather Assimilated into Decision-Making• Layered, Adaptive Security • Broad-Area Precision Navigation (now Positioning,

Navigation, and Timing [PNT] Services)• Aircraft Trajectory-Based Operations (TBO) • Equivalent Visual Operations (EVO) (the characteristics

of which are described throughout this concept) • Super-Density Arrival/Departure Operations.


NNEW March 18, 2010

NNEW Objectives• Provide universal access to required wx data

envisioned by NextGen 4-D Wx Data Cube • Establish SWIM compatible Wx Service Oriented

Architecture (SOA) within FAA • Establish interagency wx SOA • Adopt/develop standards• Develop capability for discovery across different

taxonomies (e.g., JMBL and Climate & Forecast)• Develop capability for dynamic brokering between

heterogeneous clients (e.g., WCS client) and providers (e.g., JMBL providers)

• Develop discovery metadata guidance • Develop FAA wx service-oriented & physical

architecture


NNEW March 18, 2010

4-D Wx Data Cube


NNEW March 18, 2010

What is the 4-D Wx Data Cube?

• Data from various publishing systems—but not the publishing systems themselves

• Software that provides capabilities for – locating and retrieving data– subsetting of data

and a number of other functions

• Service adapters to support legacy systems


NNEW March 18, 2010

4-D Wx Data Cube Functions

• Locating and retrieving data– A feature of a SOA that requires:

• Registry/Repository• SOA services

• Subsetting of data (geographically, by time, & by wx parameter)– Being enabled by adopting new data formats,

namely:• netCDF-4 for gridded data• Weather Exchange Model (WXXM) for non-gridded data


NNEW March 18, 2010

Registry/Repository

• An ebXML reg/rep based on Organization for the Advancement of Structured Information Standards (OASIS) standard is being used for the Cube

• Supports– design-time discovery

• At design-time, a service provider or consumer uses a registry to discover information about an abstract service, including all the details needed to build server and client-side software

– runtime discovery• At runtime, applications discover instance-specific information,

such as the individual addresses of each service

• The reg/rep software is a commercial product developed by a firm working closely with the NNEW Program


NNEW March 18, 2010

Metadata

• Data about data • Resides in the registry/repository• Provided by data providers• Makes it practical to search for data in the Cube• The Content Standard for Digital Geospatial

Metadata (CSDGM), Vers. 2 (FGDC-STD-001-1998) is the US Federal Metadata standard

• U.S. is working toward using the international standard—ISO 19115

• NNEW has developed Metadata Guidelines for the 4-D Wx Data Cube that provides guidance for metadata within the bounds of the standards


NNEW March 18, 2010

SOA Services

• FAA has adopted Open Geospatial Consortium (OGC) Standards—NOAA has not yet made a decision—could adopt JMBL– OGC Standards

• Web Coverage Service (WCS) for gridded data

• Web Feature Service (WFS) for non-gridded data

• Also probably Web Mapping Service for information available only in map form

– Joint METOC Broker Language (JMBL)• Developed and used by DoD

• Software—Reference Implementations (RI)—is currently being developed for WCS & WFS


NNEW March 18, 2010

Wx Data Representation

• netCDF-4– a set of software libraries and machine-independent

data formats that support the creation, access, and sharing of array-oriented, scientific data

• WXXM– Defines a common vocabulary for exchanging

weather information between organizations– Being developed jointly by NNEW and

EUROCONTROL


NNEW March 18, 2010

Data Format Development

• Data encoded in netCDF-4 and WXXM have been or are being developed for numerous products, including, for example:– NEXRAD Level III products & mosaics– METARs, TAFs, SIGMETs, PIREPs– CIWS products– ITWS products– CIP, FIP, GTG– Model data


NNEW March 18, 2010

• Provided by the RIs– Support a variety of geographic projections &

conversions among them– Conversions among measures of height – Archiving

• Provided by the reg/rep– Dynamic brokering between heterogeneous clients

using the ontology

• Complex Retrieval Processing– A set of functions currently being defined

4-D Wx Data Cube Additional Functions


NNEW March 18, 2010

Dynamic Brokering & Mediation

• Dynamic brokering between heterogeneous clients– Provides the ability to search for data among

sources using different terminologies

• Mediation– Provides the ability to change data retrieved from

one terminology to another


NNEW March 18, 2010

Ontology

• The 4-D Wx Data Cube may contain data that use two different sets of terminologies: Climate & Forecast (C&F) and JMBL

• An ontology is needed to enable searching for datasets registered in the Registry/Repository in a vocabulary-independent manner

• This ontology is under development


NNEW March 18, 2010

Complex Retrieval Processing (CRP)

• CRP will include functions such as– Combining data into a single response when

responding to a request for data along a flight path– Archiving data and retrieval of archived data– Centralized auditing– Mediation


NNEW March 18, 2010

Architecture


NNEW March 18, 2010

4-D Wx Data Cube Context

21

Weather Systems (Providers)

4-D Wx Data Cube

NAS Automation(Consumers)

NextGen Wx Enterprise

Present Integrated Weather Information

NAS Automation Developers

Prov ide Weather Products

Weather System Developers

Pilot

Sector Controller

Dispatcher

Prov ide/Designate Data as Single Authoritativ e

Source

Prov ide Net-Enabled Weather Data


NNEW March 18, 2010

4-D Wx Data Cube Conceptual Architecture

22

Terminal Controller

s

TFM Planners

Traffic Flow ManagementTraffic Flow ManagementTraffic Flow ManagementTraffic Flow Management

Dispatchers

Weather RelatedServices

TFMS

ERAM

260250

240230220210200

COA445 X

TT

TTTTT

350330

290280270260250

AAL1274 X

TT

TTTTT

310 T

260250

240230220210200

COA445 X

TT

TTTTT

350330

290280270260250

AAL1274 X

TT

TTTTT

310 T

1

Sector Controllers

STARS

AOC

SystemData Ingest ITWS

RASPAvionics

Pilots

MADIS

Weather RelatedServices

System Data Retrieval

NWP


NNEW March 18, 2010

4-D Wx Data Cube SOA Context

23

Data Acquisition Services

Content Management

Services

AOC Automation

TFMSAutomation

Consumers

Providers

ForecastSystems

MissionServices

ERAMAutomation

ForecastSystems

WeatherSystems

InteractionServices

CRP Services

Basic 4-D Wx Data Services

“Translation Services”

AIMServices

Flow/FlightServices

4-D Wx Data Cube

Other Services

Net-Enabled Services

CRP – Complex Retrieval Processing


NNEW March 18, 2010

4-D Wx Data Cube High-Level Physical Architecture

FTI WANFTI WAN

Weather Data End Users

DistributionServer

ConsumerAutomation

Weather ProviderSystem

Origin Server


ConsumerAutomation


ConsumerAutomation

DistributionServer

DistributionServer

Registry/Repository

Weather ProviderSystem

Origin Server

4-D WxData Cube


NNEW March 18, 2010

Notional Interagency Architecture

25

Origin Servers

Weather Data ConsumersWeather Data Consumers

NOAA Gateway

FAA Enterprise

FAA Data Providers

Core Enclave Support Enclave

External DMZ

NAS OutgoingDistribution

Server

NAS Incoming Distribution

Server

Data Filter

Reg/Rep

Support Enclave

ConsumerAutomationConsumer

Automation

FTI IP WAN

Distribution Server

Distribution Server

NWS DataProviders

Cube Input Edge

Servers

Cube Output Edge

Servers

Weather Data Consumers

NWS IP Networks

Reg/Rep

DistributionServers

Output Edge

Servers

Internal DMZ

Reg/Rep

CRPServers

NOAA Enterprise

= NNEW Provided System

= NWS Provided System


NNEW March 18, 2010

Interagency Data Exchange Sequence“Caching Proxy”

26

Registry/RepositoryCIES End User - BDistribution Server (RI) Consumer System(native)

End User - A

Precondition: Registry Populated. SIA has ingested data product. Consumer Developer has discovered the dataset and service

End User Request()

WFS/WCSRequest()

Query for OriginServer()

Origin Server Location()

WFS/WCS Request()

WFS/WCS Response()

WFS/WCSResponse()

Automation Response()

User Request()

WFS/WCS()

WFS/WCSResponse()

Response()

Data retrieved From NWS on 1st data request andthen cached locally.

Subsequent requestsMay be serviceddirectly

FA

A/N

WS

Sec

urity

Bou

ndar

y*

Start: End User Makes request requiring weather information

* details of the security boundary not depicted


NNEW March 18, 2010

Interagency Data Exchange Sequence (cont)

• Basic flow for a request/response exchange with NWS– Consumer Systems initially directed to an assigned Distribution Server

by the Registry

– In response to requests, Distribution Servers collect data from Origin Servers/Cube Input Edge Servers

– Distribution Servers cache data locally for a limited amount of time.

– Caching allows for quicker responses for multiple requests of the same data from the same Distribution Server

• Architecture is configurable and allows for transition of NextGen capabilities– Allows for growth of NextGen capabilities in NAS Automation

– Allows for transition of Weather Data Providers per the NAS Roadmap

27


NNEW March 18, 2010

Ongoing architecture work -Modeling & Simulation

• Goals– Understand how the 4-D Wx Data Cube performs as user loads

increase• Performance with legacy provider and consumer systems integrated via service

adaptors• Performance with provider and consumers that employ NextGen capabilities and

have adopted native, net-enabled interfaces

– Understand trade-offs between latency and bandwidth• Tiered Distribution Server architecture• Number of Distributions Servers• Impact of interagency boundary gateways• Composed services• RMA

• Products– Preliminary Analysis of NNEW Performance – July 2010– Detailed Analysis of NNEW Performance – March 2011


NNEW March 18, 2010

High-Level Segment 1 View

&

Transition


NNEW March 18, 2010

NNEW & NWP Segment 1


NNEW March 18, 2010

FDP2K

Legend

Sensors

/

Sources

End User System

/

Display

Weather Processor (Server )

Interface

Communications Links Terminal

ARTCC

Flight Services

Customer

ADAS

FBWTG

ETMSLocal Displays

SD

ATCSCCETMS

Tower/TRACON ControllerTraffic Flow Specialists

Approach ControllerAirline Operations Center

FSS SpecialistPilot

Traffic Flow Manager

Pilot

En Route ControllerMeteorologists

Traffic Flow Specialists

Oceanic ATC

FIS Pilot

LLWAS -R/S

MDCRSVia

ARINC

Global Sources

External Users

WARP

WINS

ITWS

DSRETMSATOPURET

HOST

FDP2KDOTS

WMSCR

Local DisplaysTWIP

ASOS /AWOS

LLWAS -NETDWR

NOAA Product Generation

Centers

ASR -WSPASR -9 WX

NEXRAD

Vendors

Lightning

Vendor

FS 21

Pilot

CIWSPrototype TFM TFM Specialist

RASP

ITWS ITWS

DOTS

DOTS +

DOTS +

ATOP

FDP2K

2010 Service Adaptor and Wx Architecture Development

2011

ETMS

ETMS

ETMS

ERAM / URET

2012NAS Weather Architecture Segment 1 - 2015

Consumer Cube Service Adaptor (CCSA)

Provider Cube Service Adaptor (PCSA)

NIDSNIDS

NIDSNOAA Product

Generation Centers

4-D Weather Data Cube Prototype

4-D Weather Data Cube

(NNEW Enabled)NWP Prototype

NEXRAD

TWIP

Non- SOA/Cube Connection

SOA/Cube Connection

External Users

NWP


NNEW March 18, 2010

NNEW Program Key Elements

• Standards Development– Data Access Standards

• Open Geospatial Consortium (OGC) standards, principally Web Coverage Service (WCS) and Web Feature Service (WFS)

– Data Format Standards• GML, XML, and NetCDF-4

• Working with EUROCONTROL to develop a common data model

– Metadata Standards

• 4-D Wx Data Cube Architecture– High-level 4-D Wx Data Cube interagency architecture– Lower level architecture for FAA’s portion of 4-D Wx Data Cube


NNEW March 18, 2010

• Software Development– Registry/Repository

• ebXML-compliant reg/rep obtained from a commercial source (Wellfleet)

– Reference Implementations of WCS and WFS• Software that implements the WCS and WFS standards

• Provides the mechanism to connect consumers with providers and return the data that are requested

– Ontology• Enables searching for datasets registered in the

Registry/Repository in a vocabulary-independent manner

– Service adapters• Enables legacy systems to provide data to, or use data from, 4-D

Wx Data Cube without rewriting the legacy system software

NNEW Program Key Elements (cont)


NNEW March 18, 2010

NextGen Infrastructure Program Stack(Long-Term Outlook)

FTIBasic IP Connectivity

Fault-Tolerant Backbone

SWIMMessaging, Security, Monitoring, Core Registry, DNS ?

NNEWWeather-Specific Data Formats & Access Services

Federated Registry/Repository and Registry ExtensionsDeployed weather data distribution hubsRuntime Registration (required for weather (especially for SAS) SWIM may or may not provide thisMetadata tagging massive quantities of information for contentInteragency coordinationEnsuring appropriate weather info is available and publishedRetrieving only needed weather informationDefine business logic within the service container

Mission & DomainSOA Infrastructure/Extended Services

Cross-DomainSOA Infrastructure/

Core Services

Physical Network Layer Infrastructure

WeatherSystems/Programs(Data Producers/

Consumers)

AIM Flow Flight CATM . . . . .

. . . . . . ITWSRASP NWP. . . . .


NNEW March 18, 2010

BACKUP


NNEW March 18, 2010

WARP Briefing Terminal (BT) Replacement

• When WARPs are decommissioned, the functions of the BTs needed to be accommodated

• All data needed/used by the BTs will be net enabled

• Recommendation: Utilize NIDS displays as the replacement for WARP BTs


NNEW March 18, 2010

Service Adaptors

&

Data Flow Spreadsheet


NNEW March 18, 2010

Service Adaptors (SA)

• Purpose– Provide the capability for legacy systems to

communicate with the 4-D Wx Data Cube

• SAs come in two flavors– Provider Cube Service Adaptors (PCSA)– Consumer Cube Service Adaptors (CCSA)


NNEW March 18, 2010

• Currently identified Segment 1 SAs– PCSAs

• RASP (complete)• ITWS (scheduled for FY10)

– CCSAs• DOTS (scheduled for FY10)• ATOP (scheduled for FY10)• FDP2K (scheduled for FY11)• ITWS (scheduled for FY11)• TFMS (scheduled for FY11)• NIDS (scheduled for FY12)• ERAM/URET (scheduled for FY12)

Service Adaptors (cont)


NNEW March 18, 2010

• Service Adaptor Plan– For each identified system documented the

• Current data flows (i.e., the sources and sinks for the weather products)

• The presumed data flows at Segment 1 timeframe

– Plan includes NWP even though no SA is required

Service Adaptors (cont)


NNEW March 18, 2010

Wednesday, October 28, 2009

NEXRADTDWR MADIS GOES

External Users

Radar Data

METARsMesonetMaritime

IR and VISGOES Satellite

ProductsNEXRAD Level III

Data

CIWS Products

CIWS Products

CanadianWeather Radar

CIWS

CONVOL Unfiltered Reflectivity Product

Indicates that future data flow willchange (or not exist)

NWS FTP Server

RUC Model Data

OMOsLDD

ADAS/RASP

TFMS

CIWS Products (0-2): VIL Mosaic, VIL Mosaic Data Quality Flags (0 minute), VIL Phase Forecast (0 minute), VIL Quantized (0 minute), VIL Forecast, VIL Forecast Quantized, VIL Phase Forecast, VIL Mosaic Data Quality Flags, Echo Tops Mosaic (0 minute), Echo Top Mosaic Data Quality Flags (0 minute), Echo Tops Quantized (0 minute), Echo Tops Forecast Mosaic, Echo Tops Forecast Quantized, GOES Satellite Mosaic, Storm Info (Echo Top Tags, Leading Edges, and Motion Vectors), VIL Contours (Standard and Winter Mode), Echo Tops Contours, Growth and Decay Contours, Forecast Accuracy (Echo Tops, Standard Precip, and Winter Precip), Lightning

SA Plan Diagrams – CIWS Transition

Wednesday, October 28, 2009NEXRAD

Physical Network

MADIS GOES

External Users

METARsMesonetMaritime

IR and VISGOES Satellite

Products NEXRAD Level III Data

CIWS ProductsCoSPA Products


Sfc Obs, IR and VIS GOES Satellite Products, NEXRAD Level

III Data, LDD, CONVOL,Model Data, OMOs, TDWR Data

NOAA

Sfc Obs, IR and VISGOES Satellite Products,NEXRAD Level III Data,Model Data, CONVOL

NWP

Capabilities-Internal SA Functionality-WARP Radar Mosaics-0-6 hr Convective Wx Forecast


ADAS/RASP

OMOs

TDWR

TDWR Data

Canadian Weather Radar

CONVOLUnfiltered Reflectivity Product

ITWS

TDWR Data

PCSA

PCSA

PCSA NNEW Developed PCSA

TFMSCC

SA

NNEW Developed CCSACCSA

ASR-9

WeatherChannel

CoSPA Products (2-8 hours):VIL Forecast, VIL Mosaic Data Quality Flags, VIL Phase Forecast, Echo Tops Forecast, WAF Forecast, Uncertainty Estimates, Probabilistic Forecast, VIL Contours (Winter and Standard Mode), Echo Top Contours, Forecast Accuracy (Echo Tops, Standard Precip, and Winter Precip)

CIWS Products (0-2 hours):VIL Mosaic, VIL Mosaic Data Quality Flags (0 minute), VIL Phase Forecast (0 minute), VIL Quantized (0 minute), VIL Forecast, VIL Forecast Quantized, VIL Phase Forecast, VIL Mosaic Data Quality Flags, Echo Tops Mosaic (0 minute), Echo Top Mosaic Data Quality Flags (0 minute), Echo Tops Quantized (0 minute), Echo Tops Forecast Mosaic, Echo Tops Forecast Quantized, GOES Satellite Mosaic, Storm Info (Echo Top Tags, Leading Edges, and Motion Vectors), VIL Contours (Standard and Winter Mode), Echo Tops Contours, Growth and Decay Contours, Forecast Accuracy (Echo Tops, Standard Precip, and Winter Precip), Lightning

TBD

LDD

Current CIWS Flows Future


NNEW March 18, 2010

SA Plan Diagrams – WARP Transition

Friday, October 23, 2009

NEXRAD

ADAS/RASP

WARP

FBWTG HIPS/BLM HWDS

OMOLightning-coupled

METARs

GRIB Messages

Alaska LDND

NWS DataNLDN Data

NEXRAD Level IIIData

ARTCC WARP

WARP

WARP to WARPConnectivity

WARP to WARPConnectivity

DOTS

URET/DSR

WMSCR

FDP2K

CAPER

MEARTS

ATOP

ERAM

GFS &UKMET

GRIB Messages

Reflectivity Mosaics*

GFS GRIB Messages

NAM V,N GRIB Messages

RUC WGRIB Messages

RUC Q GRIB Messages

CWA, CWS, PIREPS



Reflectivity Mosaics*: Composite (dsr_cr), Highest Layer Composite (dsr_crhi), Low Layer Composite (dsr_crlo), Super High Layer Composite (dsr_lrms)

Indicates that future data flow will change (or not exist)

ITWS

Model Data

Monday, October 05, 2009NEXRAD

NWP

NEXRAD Level III Data

NOAA

CWSU (N-AWIPS)

Physical Network

NEXRAD Level III DataLDD

DOTS+

ERAM (URET/DSR) FDP2K

ATOP

GFS &UKMET

GRIB Messages


GFS GRIB Messages

NAM V GRIB MessagesUpper Air Model

Winds and Reflectivity Mosaics*

NEXRAD Level III Data andWx Data for other Users

CWACWS


CCSA

CCSA

CCSA

CCSA


NEXRAD Level IIIData and Meteorologist Only Data

CCSA NNEW Developed CCSA


ITWS

CCSA

Model Data

PIREPs

CWACWS


NIDS

Regional Mosaic Data, National Mosaic Data,

WARP Image Product Data,NWS Graphic Product Data

NEXRAD ProductsSatellite Data

CCSA

LDD

TBD

Current WARP Flows Future


NNEW March 18, 2010

Tuesday, October 27, 2009

AWOS/ASOS

OMO SCS

RASP WMSCRITWS METARsOMOLDD

OMO

WARP

NLDN

LDD

LAD

LAD


OMOMETARs

CIWS

OMOLDD

SA Plan Diagrams – ADAS/RASP Transition

Current ADAS/RASP FlowsTuesday, October 27, 2009

AWOS/ASOS

OMO SCS

OMO

RASPITWS

Physical Network

CCSA PCSA

OMOLDD

OMO METARs

OMOMETARs

LDD

LAD

LAD


NWPCapabilities-Internal SA Functionality-WARP Radar Mosaics--0-6 hr Convective Wx Forecast


WMSCRMETARs

NLDN

LDD

TBDLDD

Future


NNEW March 18, 2010

Tuesday, June 09, 2009

ATOP

Physical Network

UKMet and GFS Thin GridsGRIB Messages


CCSA

UKMet and GFS Thin GridsGRIB Messages

NOAA



NWPCapabilities-Internal SA Functionality-WARP Radar Mosaics-0-6 hr Convective Wx Forecast





ATOP



WARPRAMP WINS

Reflectivity Mosaics*UKMet and GFS Thin Grids

GRIB Messages

FBWTG

UKMet and GFS Thin Grids

GRIB Messages

NEXRAD


SA Plan Diagrams – ATOP Transition

Current ATOP Flows Future


NNEW March 18, 2010

Wednesday, May 06, 2009

DOTS+

Physical Network

GFS Thin GridsGRIB Messages

CCSA

GFS Thin GridsGRIB Messages

NOAA



DOTS+

WARP


GFS Thin Grids

GRIB Messages

RAMP WINS

FBWTG

GFS Thin Grids

GRIB Messages

SA Plan Diagrams – DOTS Plus Transition

Current DOTS Plus Flows Future


NNEW March 18, 2010

Tuesday, October 27, 2009

Physical Network


40km model data

ERAM(URET/DSR)

CCSA

NOAA

NEXRAD Level III Data40km model data

NEXRAD Level IIIData Reflectivity Mosaics*


NWPCapabilities-Internal SA Functionality-WARP Radar Mosaics-0-6 hr Convective Wx Forecast

Reflectivity Mosaics*: Composite Reflectivity Mosaic, Highest Layer Composite Reflectivity Mosaic, Low

Layer Composite Reflectivity Mosaic, and Super High Layer Composite Reflectivity Mosaic

Wednesday, August 05, 2009

URETERAM


NEXRAD


Reflectivity Mosaics*: Composite Reflectivity Mosaic, Highest Layer Composite Reflectivity Mosaic, Low

Layer Composite Reflectivity Mosaic, and Super High Layer Composite Reflectivity Mosaic

WARPRAMP WINS

Reflectivity Mosaics* 40kmmodel data

SA Plan Diagrams – ERAM/URET Transition

Current ERAM/URET Flows Future


NNEW March 18, 2010

Friday, October 23, 2009

FDP2K

Physical Network

NAM V GRIB MessagesSIGMETs

CCSA

NAM V GRIB Messages,METARs,SPECIs,

SIGMETs

NOAA


RASP

METARsSPECIs

PCSA

WMSCR

METARsSPECIs


Tuesday, August 18, 2009

FDP2K

WARP

NAM V,N GRIB Messages


WMSCR

NOTAMs, SIGMETs, METARs, SPECIs

WINS

SA Plan Diagrams – FDP2K Transition

Current FDP2K Flows Future


NNEW March 18, 2010


ITWSPhysical Network

ADAS/RASP

TRACONs(ITWS Display)

ARTCCs(ITWS Display)

ATCTs(ITWS Display)

OMOs

Model Data, Aircraft Observations,



Model Data, Aircraft Observations,NEXRAD Level III

Data, LDD,Terminal Winds, OMO’s

CCSA

ITWS Products

ITWSProducts

ITWSProducts

MDCRS

AircraftObservations

NOAA

NEXRAD

ITWS Products, TDWR

Radar Data


TDWR

Radar Data

ASR-9

WeatherChannel

LLWAS

Airport Wind, Runway Wind,Microburst Alert, Wind Alert


PCSA

External Users

ITWSProducts

TBD

LDD

ITWS Products: Microburst TRACON Map, Gust Front TRACON Map, Gust Front ETI, Terminal Winds Profile, Tornado Detections, Tornado Alert, Configured Alerts, Microburst ATIS, Wind Shear ATIS, Terminal Weather Text, Airport Lightning Warning, AP Status, AP Indicated Precipitation, Precipitation 5nm, Precipitation TRACON, Long-Range VIL, SM_SEP 5nm, SM_SEP TRACON, SM_SEP LR, Hazard Text 5nm, Hazard Text TRACON, Hazard Text LR, VIL Forecasts, Forecast Accuracy, VIL Forecast Contours, Runway Configuration.


TDWR

ITWS

ADAS/RASP

ASR-9

TRACONs(ITWS Display)

ARTCCs(ITWS Display)

ATCTs(ITWS Display)

Radar Data

ITWS Products

ITWS Products

ITWS Products

LDD and OMOsWeatherChannel

RUC and NEXRAD LevelIII Data

MDCRS

FBWTG

AircraftObservations,

RUC 40km, PRI model

NEXRAD


LLWAS

Airport Wind, Runway Wind,Microburst Alert, Wind Alert

ITWS Products ITWS ProductsExternal

UserVOLPE

WARP

Model Data

ITWS Products: Microburst TRACON Map, Gust Front TRACON Map, Gust Front ETI, Terminal Winds Profile, Tornado Detections, Tornado Alert, Configured Alerts, Microburst ATIS, Wind Shear ATIS, Terminal Weather Text, Airport Lightning Warning, AP Status, AP Indicated Precipitation, Precipitation 5nm, Precipitation TRACON, Long-Range VIL, SM_SEP 5nm, SM_SEP TRACON, SM_SEP LR, Hazard Text 5nm, Hazard Text TRACON, Hazard Text LR, VIL Forecasts, Forecast Accuracy, VIL Forecast Contours, and Runway Configuration.

SA Plan Diagrams – ITWS Transition

Current ITWS Flows Future


NNEW March 18, 2010


TFMS

CIWS Products

CoSPA Products

Physical Network

Sfc Obs, IR and VISGOES Satellite Products,NEXRAD Level III Data, Model Data, CONVOL

NOAA

CCSA



TBD

LDD

CoSPA Products (2-8 hours):VIL Forecast, VIL Mosaic Data Quality Flags, VIL Phase Forecast, Echo Tops Forecast, WAF Forecast, Uncertainty Estimates, Probabilistic Forecast, VIL Contours (Winter and Standard Mode), Echo Top Contours, Forecast Accuracy (Echo Tops, Standard Precip, and Winter Precip)


Sfc Obs, IR and VIS GOES Satellite Products, NEXRAD Level

III Data, LDD, CONVOL,Model Data, OMOs, TDWR Data

NWP



ADAS/RASP

OMOs

TDWRTDWR DataITWS

TDWR Data

PCSAPCSA

Monday, October 05, 2009


CIWS Prototype

TFMS

CIWS Products


SA Plan Diagrams – TFMS Transition

Current TFMS Flows Future


NNEW March 18, 2010


NIDS

Regional Mosaic Data National Mosaic Data

WARP Image Product DataNWS Graphic Product Data

NEXRAD ProductsSatellite Data, Textual Products

NWP


Physical Network

NEXRAD Level IIIData, Satellite Data,

NWS Graphic Product Data,Textual Products

NOAA

NEXRAD Level IIIData, Satellite Data, LDD


WARP Image Product Data

??

??NNEW created SA OR functionality will be

built into the system

TBD

LDD

Tuesday, August 18, 2009


WARPRAMP WINS

NIDS

NWS Graphic Product DataNEXRAD Products

Satellite Data


WARP Image Product DataTextual Products

SA Plan Diagrams – NIDS Transition

Current NIDS Flows Future


NNEW March 18, 2010

BT

BT Supporting System

Friday, August 28, 2009

Regional Mosaic Data National Mosaic Data

WARP Image Product DataNWS Graphic Product Data

NEXRAD ProductsSatellite Data

Textual Products

NWP


Physical Network

NEXRAD Level IIIData, Satellite Data,

NWS Graphic Product DataTextual Products

NOAA

NEXRAD Level IIIData, Satellite Data


WARP Image Product Data


CCSA

TBD

LDD

Wednesday, August 26, 2009

WARP


MDS


WARP Image Product DataTextual Products

NWS Graphic Product DataNEXRAD Products

Satellite Data

BT

Data

SA Plan Diagrams – BT Replacement Transition

Current BT Replacement Flows Future


NNEW March 18, 2010

• Based primarily on SA Plan, but provides more detail

• Identifies—or will—each individual product, and for each, items like– Source and sink (Segment 1 timeframe)– Update frequency; max, min, average size; number

of instances (e.g., there are 155 CONUS NEXRADs)– Whether or not a data format is completed or when it

is due

Data Flow Spreadsheet


NNEW March 18, 2010

IOC Product Flow Sheet

• The IOC Product Flow Sheet originated from the EI Team list as well as NNEW’s “Service Adaptor Plan (SA Plan).”

4-D Weather Data Cube Native Format

Update FrequencySize - Minimum

Observed (bytes)

Size - Maximum Observed

(bytes)

Size - Worst Case Maximum (bytes)

Multiplier (i.e., multiple files such

as multiple NEXRADs)

Current Minimum Latency

Current Average Latency

Required Latency

4-D Grids Hourly 50KB 120KB



Product GroupNNEW Specific Product

Format Due DateProduct

Data Flows Directly to Sink System (i.e., data are not

published by source system)Source System Sink System

Source System

Sink System

WRF-RR Model Data

10/30/2009 (FAA) WRF-RR windsED-8

GatewayED-8

GatewayNWP

10/30/2009 (FAA) WRF-RR TempsED-8

GatewayED-8

GatewayNWP

HRRR Model Data

11/30/2009 (FAA) 15-Minute VILED-8

GatewayED-8

GatewayNWP

User/ConsumerGeographic Coverage

Vertical Coverage

Human Interaction

Model Input Requirements

Radar Input Requirements

Satellite Input Requirements Other Input Data

CIWS, CoSPA, FSS North America 1000-10hPa None WRFVertical Azimuth Winds, NEXRAD

Reflectivity

GOES IR, Vis; POES Winds, GOES & GPS total

precipitable water est., SSM/I

Obs, TAMDAR, Wind Profilers

CIWS, CoSPA, FSS North America 1000-10hPa None WRFVertical Azimuth Winds, NEXRAD

Reflectivity



Obs, TAMDAR, Wind Profilers

CIWS, CoSPA, FSS CONUS MSL - 100 mb None WRF-RRNSSL 3-D Gridded Radar Reflectivity



Many observations


NNEW March 18, 2010

Demonstrations &

Capability Evaluations


NNEW March 18, 2010

• IT demonstrations conducted on 2007, 2008, and 2009

• FY10 4-D Wx Data Cube Capability Evaluation planned for September 2010

• Additional Capability Evaluations planned for FY11 & FY12

• Initial NextGen Weather Capability planned for FY13

Demonstrations & Capability Evaluations


NNEW March 18, 2010

FY07 and FY08 IT Demonstrations: NNEW

FY07 Objectives and Accomplishments− Developed and refined the standard data formats and services − Became familiar with the SOA development/test environment at the

FAA William J. Hughes Technical Center (WJHTC)− Established basic connectivity between the Government laboratories

and the WJHTC− Built a display capability that is flexible enough to adapt to a variety of

future data display needs.

FY08 Objectives and Accomplishments− Utilized Open Geospatial Consortium (OGC) standards− Published data using Service Oriented Architecture (SOA)− Established a working registry/repository (reg/rep)− Constructed a data visualization tool− Made data available from various locations in order to demonstrate

the virtual data Cube concept.


NNEW March 18, 2010

FY2009 demonstration results: NNEW

• Objectives: Demonstrate interagency data sharing through the use of federated registries/repositories and NNEW standards− Utilize version 1 of standards implementation software − Utilize Cube data formats to allow for interoperability between both

systems and agencies − Utilize federated registries to allow for data discovery between

organizations− Use of Ontology to demonstrate a level of searching and translation

between different weather formats − Demonstrate use of NNEW Metadata Guidelines, to enable the

discovery of specific weather data

• Coordinated with the NOAA/NWS and DoD


NNEW March 18, 2010


• Artifacts– NextGen Network Enabled Weather (NNEW) Federal Fiscal Year

2009 Information Technology Demonstration Implementation Verification Procedures

– NNEW Test Report for the FY 2009 IT Demonstration

• Results – Utilized NNEW standards software to successfully publish and

subscribe to weather data– Demonstrated the receipt of NWS data through NNEW software:

Surface wind speed from NDFD Thunderstorm probabilities from LAMP Turbulence and icing grids (Alaska)


NNEW March 18, 2010


• Results (continued)– Demonstrated registry/repository capabilities

Displayed searches demonstrating federation Discovered various services and data sets Use of metadata IAW NNEW Metadata Guidelines

– Demonstrated Ontology capabilities USAF Weather data formats supported

– Demonstrated trajectory-based retrieval First instance of a 4-D retrieval for eventual support of TBO


NNEW March 18, 2010

FY10 Capability Evaluation: NNEW• Primary Objective: To simulate operational Cube functionality

as closely as possible to show how the Cube will operate at the Initial Operating Capability (IOC), including all applicable Cube

standards and any available hardware and software infrastructure. o Providers will publish data, enabling it to be part of the Cube by utilizing a

Provider Cube Service Adaptor (PCSA), or NOAA equivalent.o Consumers will consume data from the Cube utilizing a Consumer Cube

Service Adaptor (CCSA), or NOAA equivalent. o 4-D Weather Data Cube Technical Architecture Framework of standards

will be utilized. o Dissemination of data via FTI and NOAAnet through boundary protection

schemes (ED-8 gateway, NOAAnet gateway, etc) to the maximum extent possible.

o Deployed Registry/Repository data will be federated across agency boundaries.

o Current requirements for WCS/WFS RI functionality are implemented o Include partner prototypes/capabilities


NNEW March 18, 2010

FY10 Capability Evaluation: NNEW (cont)• Secondary Objective: To test performance and security of data

dissemination utilizing Cube standards.o NAS Automation Simulator will make data requests to demonstrate

satisfaction of query responses. o NAS Automation Simulator will help to measure data product latency. o Enable FAA security provisions in SWIM container between Origin

Server and CCSA, supported through the use of a key management service.

o Include Network-Enabled Verification Service (NEVS) prototype data publisher


NNEW March 18, 2010

DRAFT High-Level FY10 Capability Evaluation Architecture: NNEW

NOAAnet

Internet 2

Internet

William J. Hughes Technical Center

Atlantic City, NJ

MIT/LLLexington, MA

NCARBoulder, CO

AIMWashington D.C.

NWSSilver Springs, MD

EUROCONTROL

GSDBoulder, CO


NNEW March 18, 2010

DRAFT WJHTC FY10 Capability Evaluation Architecture: NNEW


NNEW March 18, 2010

DRAFT NOAA/NWS FY10 Capability Evaluation Architecture


NNEW March 18, 2010

FY10 Capability Evaluation: NWP NNEW Evaluation

• Planning to incorporate NWP prototype into NNEW FY10 Capability Evaluation– Prototype NWP will generate RAMP radar mosaics

• Purpose: Show that NWP can subscribe to services to ingest sensor data for processing and publish the product that NWP generates to the 4-D Wx Data Cube


NNEW March 18, 2010

FY11 Capability Evaluation: NNEW

• Transition additional data sources to operational sources

• Publish additional products• Use version 3 of WCS & WFS RIs• Evaluate mediation• Add additional SAs (FDP2K, ITWS CCSA, TFMS)• Evaluate additional security functionality• Use and evaluate an architecture that more closely

resembles the proposed operational architecture


NNEW March 18, 2010

FY12 Capability Evaluation: NNEW

• Transition additional data sources to operational sources

• Publish additional products• Use version 3 of RIs• Evaluate initial CRP capability• Add additional SAs (NIDS, ERAM/URET)• Refine 2015 security requirements• Evaluate additional security functionality • Use and evaluate an architecture that approaches

the proposed operational architecture


NNEW March 18, 2010

Proposed Initial NextGen Weather Capability – FY13• Essentially all current & new products, including

the following categories, will be net enabled– ITWS– CIWS/CoSPA– NEXRAD mosaics– TDWR (but not base data)– METARs– NOAA-produced produced products such as satellite imagery,

NEXRAD Lvl III, GTG, FIP/CIP, NCV, SIGMETs, AIRMETs, METARs TAFs, model data, etc.

• System changes– NWP will incorporate WARP RAMP functionality & CIWS– 4-D Wx Data Cube will replace FBWTG functionality &

products from NOAA will be received from NOAAnet• Demonstrate the above at key sites in shadow

operations


NNEW March 18, 2010

NNEW Program Key Interactions

• JPDO 4-D Weather Data Cube Team (Tom Ryan Co-Lead)

• Bi-Lateral meetings with NWS for discussing details of 4-D Wx Data Cube Development

• FTI-NNEW meetings• SWIM-AIM-NNEW meetings• AIM-FS-NNEW meetings• EUROCONTROL for development of WXXM• JPDO Net-Centric Operations Division and Working

Group


NNEW March 18, 2010

SA Additional SA Plan Diagrams


NNEW March 18, 2010

Architecture


NNEW March 18, 2010

Primary Actors

72

AFAA Operations

AAir TrafficManager

AATCSCCPlanner

AAir TrafficController

AAccident

Investigator

AAirport Ground

Crew

AAirport Manager

AAirport Operations

AFlight Operations

AAir TransportOperations

AATC

Coordinators

ADispatchers

AFlight Briefer A

Pilot

AEnterprise

Consumers

AMeteorologist

AGA Pilot

AMilitary

PilotA

CommercialPilot

End User


NNEW March 18, 2010

Secondary Actors (Part 1)

73

AWx ProviderDeveloper

ACube Developer

AWx SOA

Developers

AWx SOASupport

AWx SOA Admin

ACube Admin

AWx Provider

Admin

ASOA Infrastructure

DeveloperA

ConsumerDeveloper

ASOA Developers

AConsumer

Admin

ASOA

InfrastructureAdmin

ASOA Admin

ASOA Support


NNEW March 18, 2010

Secondary Actors (Part 2)

74

AForecastSystems

SensorSystems

WeatherSystems

AWx System as

Provider

AProvider System

ANAS System as

Provider

ANAS System

AWx System as

Consumer

AConsumer

System

ANAS System as

Consumer AutomationSystems

DisplaySystems

AProvider

Infrastructure

AProvider

Data

Avionics


NNEW March 18, 2010

System Actors

75

4-D Wx Data Cube DoD Portion 4-D

Wx Data Cube

FAA Portion 4-D Wx Data Cube

NWS Portion 4-D Wx Data

CubeCommercial Portion 4-D Wx

Data Cube

International Portion 4-D Wx

Data Cube

Provider Data

Wx Enterprise Services

Networks

SOA Infrastructure


NNEW March 18, 2010

The Origin Server

Source: Based on material provided by MIT-LL, NCAR and NOAA GSD

Wx DataOrigin Server

Provider Cube ServiceAdaptor (PCSA)

SWIM Service Adaptor (SSA)

76


NNEW March 18, 2010

SWIM Service Adaptor (SSA)

The Distribution Server

77

DistributionServer

Source: Based on material provided by MIT-LL, NCAR and NOAA GSD


NNEW March 18, 2010

Consumer Cube Service Adaptor

78

End User

ConsumerAutomation

System


NNEW March 18, 2010

ParameterProduct [in red: under

development] Source Format

Convection Forecast

0-2hr Storm Vertically Integrated Liquid Water (VIL) FAA 3-D Grids

0-2hr Echo Tops FAA 3-D Grids

2-6hr Storm VIL FAA 3-D Grids


Terminal Aerodrome Forecasts (TAFs) NWS/DOD Text

Convection - Current Observations

Echo Tops FAA 3-D Grids

Lightning Strikes Commercial Service/NWS Graphic Product

Terminal Doppler Weather Radar (TDWR) Base Data FAA Radial format

NEXRAD Level III Data FAA/NWS/DoD Radial format

Enhanced Mosaic FAA Graphic Product

Satellite Images NWS Graphic Product

METARs/Specials/OMOs FAA/DoD Text

Turbulence Forecast0-12hr Graphical Turbulence

Guidance NWS 3-D Grids

Turbulence - Observations

Graphical Turbulence Guidance NWS 3-D Grids

MDCRS Airlines/ARINC/NWS Text

G-AIRMET NWS Graphic Product

PIREPs FAA Text

Segment One 4-D Wx Data Cube Products


NNEW March 18, 2010

ParameterProduct [in red: under

development] Source Format

Convection Forecast

0-2hr Storm Vertically Integrated Liquid Water (VIL) FAA 3-D Grids


2-6hr Storm VIL FAA 3-D Grids


Terminal Aerodrome Forecasts (TAFs) NWS/DOD Text

Convection - Current Observations

Echo Tops FAA 3-D Grids

Lightning Strikes Commercial Service/NWS Graphic Product

Terminal Doppler Weather Radar (TDWR) Base Data FAA Radial format

NEXRAD Level III Data FAA/NWS/DoD Radial format

Enhanced Mosaic FAA Graphic Product

Satellite Images NWS Graphic Product

METARs/Specials/OMOs FAA/DoD Text

Turbulence Forecast0-12hr Graphical Turbulence

Guidance NWS 3-D Grids

Turbulence - Observations

Graphical Turbulence Guidance NWS 3-D Grids

MDCRS Airlines/ARINC/NWS Text

G-AIRMET NWS Graphic Product

PIREPs FAA Text

Segment One 4-D Wx Data Cube Products


NNEW March 18, 2010

WFS & WCS Requirements


NNEW March 18, 2010

WFS# WFS Requirement Text V1.0 V2.0 V3.0

4.1.1 The WFSRI shall provide the capability for the Service Provider to specify the supported features. X

4.1.2 The WFSRI shall provide the capability for the Service Provider to configure the following for each feature offered by the WFSRI:

1. Name of the feature. 2. Descriptive metadata for the feature.

X

4.1.3 The WFSRI shall support the relational database data store. X4.1.4 The WFSRI shall provide output in an ISO 19139 format. X4.1.5 The WFSRI shall provide a lifecycle management system that will delete data beyond a certain time period or archive data

for a specified period of time.X

4.2.1 The WFSRI shall allow subsetting by zero or more fields (e.g., temperature, reflectivity). If no fields are indicated, all available fields shall be returned. All fields specified as mandatory by the data provider will be returned, irrespective of the user request. The mandatory fields will be specified by the data provider at the time of registration of the feature type.

X X

4.2.1.1 The WFSRI shall support geometric filtering of features, including the following: X

- 3D Volume. For this case, a 3-dimensional bounding box may be specified with dimensions defined by X, Y, Z value (such as latitude, longitude and altitude) ranges. A user can query for data that coincides with this volume.

X

- Horizontal 2-D Cross-section. If a constant altitude level is specified, a horizontal (latitude/longitude) slice will be taken through the feature volume.

X

- Vertical 2-D Cross-section. For this case, a vertical slice is taken through a feature. The path for the cross-section is defined by a set of XY waypoints and a sample density.

X

- Sounding. A feature may be subsetted by requesting a vertical column of data whose location is specified by a latitude/longitude point.

X

- Point. A feature may be subsetted by requesting a single point specified by X, Y, and Z values. X

- Trajectory. A feature may be subsetted along a trajectory, or a 3-D path, by specifying the latitudes, longitudes and altitudes of two or more ordered waypoints. The returned feature will be a “line” of data along a 3-D path, where the geo-locations of the interpolated data points are determined with either Euclidean or Great Circle geometry.

X

- Corridor. A feature may be subsetted by extruding a rectangular area along a trajectory. A rectangular cross-section, orthogonal to and along a trajectory can be extracted from the feature volume by specifying the two or more ordered waypoints, the vertical range and the horizontal range. This rectangular cross-section is a corridor. In addition, this is a superset of the horizontal and vertical cross-sections, and may be used for cross-section subsetting.

X

4.2.1.2 The WFSRI shall provide support for arbitrary geometric subsetting beyond rectangular bounding boxes. X


NNEW March 18, 2010


4.2.2.1 The WFSRI shall be capable of providing a list of valid times from datasets that are temporally aggregated. X

4.2.2.2 The WFSRI shall provide the capability to constrain features by requesting a single valid time. X

4.2.2.3 The WFSRI shall provide the capability to constrain features by requesting a range of valid times. X

4.2.2.4 The WFSRI shall provide the capability to constrain features by requesting additional time constraints such as transaction time and request time, for accident reconstruction.

X

4.3.1 The WFSRI shall require the use of GML(OGC 03-105R1) to express features within the interface and at a minimum, be used to present features. The GML version will conform to the version specified in WFS specification.

X

4.3.3 The WFSRI shall support WXXM 1.1 encodings of XML as input and output formats. X

4.3.4 The WFSRI shall support an efficient XML encoding of WXXM 1.1 output. X

5.0.1 The WFSRI shall support the WFS version 1.1.0 /2.0 specifications. X X

5.0.2 The WFSRI shall be designed to support future WFS specification versions. X

5.0.3 The WFSRI shall support version negotiation as outlined in the WFS 1.1.0 specification. X

5.1.1 The WFSRI shall provide support for the European Petroleum Survey Group (EPSG) CRS. The 4-D Wx Data Cube Registry/Repository will likely contain these definitions.

X

5.1.2 The WFSRI shall allow the user to request a CRS that is not the default and is supported by the WFSRI. X

5.1.3 The WFSRI shall return data using the default CRS if no CRS is specified. X

5.1.4 The WFSRI shall use Uniform Resource Locators (URL) wherever it is appropriate for CRS identifiers. X

5.2.1 The WFSRI shall provide a means for the Service Provider to enable/disable the WFS operations by encoding type. (For example, the Service Provider may wish to disable POX-style WFS operations.)

X

5.3.1.1 The WFSRI shall support Key-Value Pair (KVP) encoding over HTTP GET for the GetCapabilities operation. X

5.3.1.2 The WFSRI shall support Plain Old XML (POX) encoding over HTTP POST for the GetCapabilities operation. X

5.3.1.3 The WFSRI shall support Simple Object Access Protocol (SOAP) encoding over HTTP POST for the GetCapabilities operation.

X

5.3.2.1 The WFSRI shall provide an XML document indicating services, capabilities and features. X5.3.3.1 The WFSRI shall support Key-Value Pair (KVP) encoding over HTTP GET for the DescribeFeature request. X5.3.3.2 The WFSRI shall support Plain Old XML (POX) encoding over HTTP POST for the DescribeFeature request. X5.3.3.3 The WFSRI shall support Simple Object Access Protocol (SOAP) encoding over HTTP POST for the DescribeFeature

request.X

5.3.4.1 The WFSRI shall initially provide an XML document in GML 3.1 or 3.2. If no version of GML is indicated, a default version corresponding to the most recent WFS specification is to be used.

X X

5.3.5.1 For the GetFeature operation, the WFSRI shall support Plain Old XML (POX) encoding over HTTP POST. X5.3.5.2 For the GetFeature operation, the WFSRI shall support Simple Object Access Protocol (SOAP) encoding over HTTP

POST.X

5.3.6.1 The WFSRI shall provide an XML document containing the feature member elements for each requested feature. X


NNEW March 18, 2010


6.0 The WFSRI installation shall include, a description of the procedure for adding and removing offered feature types, and updating the metadata for those feature types.

X

6.1.1 The WFSRI shall provide an event-based mechanism to distribute filtered data (such as geometric and temporal subsets) to interested data consumers as the data arrives in near real-time. The mechanism used here shall be consistent with what is used by other 4-D Wx Data Cube fundamental components, such as the WCSRI, to distribute filtered

X

6.1.2 The WFSRI shall enable guaranteed delivery of data and/or notifications that are pushed to data consumers. X X

6.2.1 The WFSRI shall be capable of acting as a consumer of WFSRI services. X

6.2.2 Request delegation – The WFSRI shall be capable of acting as a proxy or request delegate to another upstream WFSRI. X

6.2.3 Dataset aggregation - The WFSRI shall be capable of aggregating two or more upstream WFSRI datasets into a single (aggregate) logical dataset which is stored locally.

X

6.2.4 Filtered data push - The WFSRI shall be capable of acting as a consumer of one or more upstream WFSRIs using their data push mechanism to cache data locally.

X

6.2.5 Caching request delegation - The WFSRI shall be capable of acting as a consumer of one or more upstream WFSRIs using their request/response data services and caching data or subsets of data locally as necessary.

X

6.2.6 The WFSRI shall provide the capability to configure a variety of architectural patterns on a product-by-product basis (i.e., different features may warrant different WFSRI communication patterns). Those patterns are described above and include delegation, aggregation, filtered data push, ad-hoc data cache, etc.

X

6.3.1 The WFSRI shall support the WFS-Transaction protocol to allow Service Providers to publish data to the WFS server X

6.3.2 The WFSRI shall provide support infrastructure to enable Service Providers to create the appropriate relations for storing feature data, if desired

X

6.4.1 The WFSRI shall provide a mechanism for describing metadata. X

6.5.1 The WFSRI shall provide remotely accessible monitoring information relating to the configuration status, WFSRI service status, health of upstream and downstream WFSRI node interactions, dataset availability, data storage size, data availability, data scrubbing information, web service request counts, web service performance, and error tracking/reporting. This capability shall be configurable to permit different levels of monitoring detail and will leverage the SWIM monitoring infrastructure.

X

6.5.2 The WFSRI shall be capable of notifying Service Providers or system maintainers of critical errors in realtime or near-realtime. This may be through email, notifications, or other means. This may be implemented based on SWIM mechanisms.

X

6.6.1 The WFSRI shall provide auditing capabilities that allows an authorized client to gather historical (i.e., 15 days minimum) information regarding system usage and health. This information will include request/response details.

X


NNEW March 18, 2010


6.6.2 The WFSRI shall provide the capability to “duplicate” a request and its precise response (including the data), for a rolling configurable time period.

X

6.7.1 The WFSRI shall provide the capability to configure the level of logging and specifics as to what is logged. This will be consistent with SWIM infrastructure and other 4-D Wx Data Cube components.

X

6.7.2 The WFSRI shall record information sufficient to support audit reporting. The information and mechanism for logging shall be consistent with SWIM infrastructure and other 4-D Wx Data Cube components.

X

6.8.1 The WFSRI shall perform data validation for communications, including but not limited to requests for data and messages/notifications sent from upstream nodes.

X

6.8.2 The WFSRI shall be compliant with the 4-D Wx Data Cube security policies and implementation(s), if these are available. X

6.8.3 The WFSRI shall provide configurable role-based access to WFSRI web service endpoints. Implementation of this requirement will leverage SWIM infrastructure security solutions.

X

6.8.4 The WFSRI shall provide configurable role-based access to WFSRI-offered features and their data fields. Implementation of this requirement will leverage SWIM infrastructure security solutions.

X X

6.8.5 The WFSRI shall provide security credentials (i.e. a user, group, or role) to interact with upstream and/or downstream WFSRI data providers and consumers. This information shall be configurable by the Service Provider. Implementation of this requirement will leverage SWIM infrastructure security solutions.

X

7.1 The WFSRI shall implement infrastructure capabilities in a manner compliant with the SWIM service container, and shall leverage SWIM mechanisms wherever appropriate.

X

7.2 The WFSRI installation shall include WSDL definitions of the web services that it provides. X

7.3 The WFSRI shall support the deployment and installation of the WFS operations (e.g., GetCapabilities, DescribeFeatureType, GetFeature into the SWIM service container, either through installation scripts or documentation for Service Providers.

X

8.1 The WFSRI shall run on Linux and Windows platforms. X X9.1 The WFSRI shall provide a flexible means to add new data formats for native data storage. X

9.2 The WFSRI shall provide a flexible means to add new data formats at the interface level. X

9.3 The WFSRI shall allow for two versions of the WFSRI to be run concurrently. This allows users to continue using the current version while making necessary changes to accommodate the newest version.

X

10.1 The WFSRI shall be capable of running a self-test diagnostic following installation. Canned datasets and default configurations will be provided with the software release for that purpose. A separate test document will specify these diagnostic tests.

X

10.2 The WFSRI shall include or allow the use of WS-I compliance-checking tools. X


NNEW March 18, 2010

WCS# WCS Requirement Text V1.0 V2.0 V3.0

4.1.1 The WCSRI shall provide the capability for the Service Provider to specify the available coverages or datasets that will be served by the WCSRI.

X X

4.1.2 The WCSRI shall provide the capability for the Service Provider to configure the following for each dataset offered by the WCSRI:

1. A unique identifier for the coverage.

2. Name of the coverage.

3. The directory for the coverage data files.

4. Descriptive metadata for the dataset.

X X

4.1.3 The WCSRI shall provide the capability to serve virtually aggregated datasets X X

4.1.4 The WCSRI shall provide configuration capability for required information regarding the files that comprise an aggregated dataset, such as file storage directories, file names and geographic extents (in the case of tiling)

X X

4.1.5 The WCSRI shall provide a lifecycle management system that will delete data beyond a certain time period or archive data for a specified period of time

X X

4.2.1 The WCSRI shall allow subsetting by zero or more fields (e.g., temperature, reflectivity). If no fields are indicated, all available fields shall be returned

X

4.2.1.1 The WCSRI shall support geometric subsetting of coverage volumes, including the following: 3-D Volume Horizontal 2-D Cross-section Vertical 2-D Cross-section Sounding 1-D Point Trajectory Corridor

X X

4.2.1.2 The WCSRI shall allow subsetting by arbitrary 3-dimensional spatial volumes (such as an air traffic control sector) X X

4.2.2.1 The WCSRI shall provide the capability of retrieving coverage subsets with a resolution that may differ from the native grid resolution. Re-gridding will be done using nearest neighbor interpolation wherever appropriate.

X X


NNEW March 18, 2010


4.2.2.2 The WCSRI shall support a variety of geographic projections (including projection-specific parameterizations such as projection origin, standard latitudes, etc.) for native data files, and applicable re-projection capability for the following minimum set of projections:

Lambert Conformal Conic Lat/Lon Mercator Stereographic (including polar) Polar Radar NAS Projection (i.e., NAS Plane)

X X

4.2.2.3 The WCSRI shall support the following set of measures of height, and conversions among them: Flight Level Meters – above mean sea level (MSL) Feet – above ground level (AGL) Feet – above mean sea level (MSL) Standard Pressure

X X

4.2.3.1 The WCSRI shall be capable of providing a list of valid times from datasets that are temporally aggregated X

4.2.3.2 The WCSRI shall provide the capability to constrain coverages by requesting a single valid time X

4.2.3.3 The WCSRI shall provide the capability to constrain a coverage by an analysis time and valid time combination (e.g., retrieve a coverage subset that was generated as part of the 12:00Z model run cycle, and is valid for 14:00Z)

X

4.2.4.1 The WCSRI shall provide the capability to aggregate coverages over valid time resulting in a time series of coverages for a given set of constraints (e.g., geometry of temperature)

X X

4.2.5.1 The WCSRI shall support temporal trajectories for trajectory-related geometries (e.g., trajectory, corridor, etc) X X

4.3.1 The WCSRI shall support CF-NetCDF4 as a native file format X

4.3.2 The WCSRI shall expose CF-NetCDF4 as a file format at the protocol level X

4.3.3 The WCSRI shall support GRIB2 as a native file format X

4.3.4 The WCSRI shall expose GRIB2 as a file format at the protocol level X X

5.1 The WCSRI shall support the version 1.1.2 specification X X

5.2 The WCSRI shall be designed in a manner such that future specification versions are supported through a pluggable protocol layer

X

5.3 The WCSRI shall support version negotiation as outlined in the 1.1.2 specification X X

5.1.2 The WCSRI shall use Uniform Resource Locators (URL) wherever it is appropriate for coordinate reference system (CRS) identifiers

X X


NNEW March 18, 2010


5.1.3 The WCSRI shall provide electronic definitions, identified by Uniform Resource Locators (URL), for the compound coordinate reference systems used by the WCSRI implementation wherever it is appropriate

X X

5.1.4 The WCSRI shall support coordinate reference system (CRS) parameterization X X

5.2.1 The WCSRI shall provide a means for the Service Provider to enable/disable the WCS operations by encoding type X X

5.3.1 The WCSRI shall support Key-Value Pair (KVP) encoding over http GET for the GetCapabilities operation X X

5.3.2 For the GetCapabilities operation, the WCSRI shall support encoding over HTTP POST X

5.3.3 The WCSRI shall support the Sections parameters X X

5.4.1.1 The WCSRI shall provide a means for the Service Provider to statically configure metadata describing the server for the following GetCapabilities elements: ServiceIdentification, ServiceProvider, OperationsMetadata and Contents

X X

5.4.2.1 The WCSRI shall provide a means for the Service Provider to statically configure the endpoints for the GetCapabilities, DescribeCoverage and GetCoverage web services, for KVP, SOAP

X X

5.4.3.1 The WCSRI shall provide a means for the Service Provider to configure the path for storing temporary files and scrubbing instructions (e.g., maximum file age) for stored request results and other temporary file purposes

X X

5.4.4.1 The WCSRI shall provide the capability to determine the following, on a per-coverage basis, either through programmatic means or Service Provider configuration:

Unique Coverage Identifier World Geodetic System 1984 (WGS84) Bounding Box for the coverage Supported coordinate reference systems (CRS), including geographic projections, vertical and compound. Native CRS

X X

5.4.4.2 The WCSRI shall support “application/x-NetCDF” as the value for the supportedFormat attribute. This is the Multipurpose Internet Mail Extensions (MIME) type for CF-NetCDF4 binary coverage data

X

5.4.4.3 The WCSRI shall support the Multipurpose Internet Mail Extensions (MIME) type for GRIB2 binary coverage data as an optional value for the supportedFormat attribute

X X

5.5.1 For the DescribeCoverage operation, the WCSRI shall support encoding over HTTP POST X

5.6.2.1 The WCSRI shall provide a means for the Service Provider to configure metadata for each of the fields within each offered coverage

X X

5.6.2.2 The WCSRI shall provide a capability to support a spatial interpolation method of “nearest neighbor” X X

5.6.2.3 The WCSRI shall provide Units of Measure for each field within a coverage as part of the CoverageSummary results X X

5.7.1 For the GetCoverage operation, the WCSRI shall support encoding over HTTP POST X

5.8.1 The WCSRI shall provide a mechanism (and potentially configuration capability) for notifying the Service Provider of storage problems (e.g., out of space) encountered when trying to write temporary data files

X


NNEW March 18, 2010


5.9.1 The WCSRI shall support a GetMetadata operation. The level of metadata requested (e.g., dataset, field), as well as the particular metadata content, shall be specified in the operation request

X

6.1 The WCSRI installation shall include, at a minimum, a description of the procedure for adding and removing offered coverages, and updating the metadata for those coverages

X X

6.1.1 The WCSRI shall provide a low-latency means to distribute filtered data (such as geometric and temporal subsets) to interested data consumers. The mechanism used to distribute filtered data shall be consistent with what is used by other 4‑D Wx Data Cube fundamental components, such as the WFSRI

X

6.2.1 The WCSRI shall be capable of acting as a data consumer of WCSRI services X X

6.2.2 The WCSRI shall be capable of acting as a backup instance for another physical node for failover purposes (e.g, NWS as primary source, FAA as backup source)

X X

6.2.3 The WCSRI shall be capable of acting as a backup instance within an NNEW node for failover purposes i.e., two pieces of hardware in the same 4‑D WX Data Cube node, such as how Experimental ADDS has multiple hosts that are used for failover)

X X

6.2.4 The WCSRI shall be capable of acting as a participant in a load balancing group for a dataset within a node. (i.e., two pieces of hardware in the same 4‑D WX Data Cube node, such as how Experimental ADDS has multiple hosts that are used for load balancing)

X X

6.2.5 The WCSRI shall be capable of acting as a proxy or request delegate to another upstream WCSRI X6.2.6 The WCSRI shall be capable of acting as a consumer of one or more upstream WCSRIs using their data push

mechanism to cache data locallyX

6.2.7 The WCSRI shall provide the capability to configure a variety of architectural patterns on a product-by-product basis (i.e., different coverages may warrant different WCSRI communication patterns)

X

6.5.1 The WCSRI shall provide remotely accessible monitoring information relating to WCSRI status, transaction statistics, errors, configured elements, data product latency, performance characteristics, and other WCSRI-specific information. This capability shall be configurable to allow for different levels of monitoring detail and will leverage the SWIM monitoring infrastructure

X X

6.5.2 The WCSRI shall be capable of notifying Service Providers or system maintainers of critical errors in realtime or near-realtime. This may be through email, notifications, or other means

X X

6.6.1 The WCSRI shall provide auditing capabilities that allows an authorized client to gather historical (i.e., 15 days minimum) information regarding system usage and health. This information will include request/response details

X X

6.6.2 The WCSRI shall provide the capability to “duplicate” a request and its precise response (including the data), for a rolling configurable time period

X X

6.7.1 The WCSRI shall provide the capability to configure the level of logging and specifics as to what is logged X X

6.7.2 The WCSRI shall record information sufficient to support audit reporting X X


NNEW March 18, 2010


6.8.1 WCSRI shall perform stringent data validation for communications, including but not limited to requests for data and messages/notifications sent from upstream nodes

X X

6.8.2 The WCSRI shall be compliant with the 4‑D Wx Data Cube security policies and implementation(s) X X

6.8.3 The WCSRI shall provide configurable, role-based access to WCSRI web-service endpoints. Implementation of this requirement will leverage SWIM infrastructure security solutions

X X

6.8.4 The WCSRI shall provide configurable, role-based access to WCSRI-offered coverages and their data fields. Implementation of this requirement will leverage SWIM infrastructure security solutions

X X

6.2.5 The WCSRI shall be capable of acting as a proxy or request delegate to another upstream WCSRI X

6.2.6 The WCSRI shall be capable of acting as a consumer of one or more upstream WCSRIs using their data push mechanism to cache data locally

X

6.8.5 The WCSRI shall provide security credentials (i.e., a user, group, or role) to interact with upstream and/or downstream WCSRI data providers and consumers

X X

7.1 The WCSRI shall implement infrastructure capabilities in a manner compliant with the SWIM service container, and shall leverage SWIM mechanisms wherever appropriate

X X

7.2 The WCSRI shall include WSDL definitions of the web services that it provides X X

7.3 The WCSRI shall support the deployment and installation of the WCS operations (e.g., GetCapabilities, DescribeCoverage, GetCoverage) into the SWIM service container, either through installation scripts or documentation for Service Providers

X X

8.1 The WCSRI shall not be tightly coupled to a particular service container. At a minimum, the WCSRI shall be deployable within Apache Tomcat as well as the SWIM service container

X X

8.2 The WCSRI shall run on Linux and Windows X

9.1 The WCSRI shall provide a means to add new data formats for native data storage X

9.2 The WCSRI shall provide a means to add new data formats at the interface level X

9.3 The WCSRI shall allow for two versions of the WCSRI to be run concurrently in the same environment on the same node

X

9.4 The WCSRI shall allow for additional protocols to be implemented and deployed alongside the WCS protocol X

10.1 The WCSRI shall be capable of running a self-test diagnostic following installation. Canned datasets and default configurations will be provided with the software release for that purpose

X X

10.2 The WCSRI shall include or allow the use of WS-I compliance-checking tools X X


NNEW March 18, 2010

RWI


NNEW March 18, 2010

Convective Weather Avoidance Models (CWAM)

• CWAM creates Weather Avoidance Fields (WAF) from gridded, deterministic forecasts of VIL and echo tops– WAF are the foundation of weather impact algorithms (weather

translation techniques) needed for weather-aware decision support

– CIWS-based WAF currently used in RAPT / IDRP; could be used in TMA decision support

– WAF for other phenomena are possible; concepts for use need to be developed

• CoSPA supports 2-8 hour WAF forecasts, making automated decision support possible– Enables decision support for strategic planning (AFP, SEVEN)


NNEW March 18, 2010

Translating Weather to Impacts

Weather Translation Techniques

Estimated AirspaceAvailability

Precipitation Echo Tops

Pilot Deviation Prob

Weather Avoidance Field (WAF) -10 min

+10 min

+20 min

0 min

FCAA05

-10 min

+10 min

+20 min

0 min

FCAA08


NNEW March 18, 2010

Current Weather Forecast Information

CCFP LAMP

CCFP is a human-generated convectiveforecast product depicting polygons of convective coverage, echo tops, growth, confidence at +2, +4, and +6 hours, Updated every 2 hours from 1 Mar to 31 Oct

LAMP is an automated convectiveforecast product depicting probabilities of convection (i.e. lightning) over two-hour periodsfrom 0-2, 2-4….22-24 hours, updated everytwo hours and running year round


NNEW March 18, 2010

4-D Wx Data Cube Technical Architecture Framework


NNEW March 18, 2010

Single Authoritative Source (SAS)

• Will be those wx data that must be used by ANSPs to make ATM decisions

• SAS data will be a subset of the data that are in the 4-D Wx Data Cube

• A process or a set of processes, manual and/or automatic, outside the Cube will determine which data are designated as SAS


NNEW March 18, 2010

Some Context

Documents

Tom Ryan March 18, 2010 Federal Aviation Administration NextGen Network Enabled Weather