Next. Gen Network Enabled Weather Tom Ryan March 18, 2010 Federal Aviation Administration
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 Federal Aviation Administration
Table of Contents • • • Introduction & Background 4 -D Wx Data Cube Architecture High-Level Segment 1 View & Transition Backup NNEW March 18, 2010 Federal Aviation Administration
Introduction & Background NNEW March 18, 2010 Federal Aviation Administration
The Basis for the NNEW Program NNEW March 18, 2010 Federal Aviation Administration
Next. Gen Goals from Next. Gen CONOPS v 2 • 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 Federal Aviation Administration
NNEW Objectives • Provide universal access to required wx data envisioned by Next. Gen 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 Federal Aviation Administration 7
4 -D Wx Data Cube NNEW March 18, 2010 Federal Aviation Administration
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 Federal Aviation Administration
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: • net. CDF-4 for gridded data • Weather Exchange Model (WXXM) for non-gridded data NNEW March 18, 2010 Federal Aviation Administration
Registry/Repository • An eb. XML 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 Federal Aviation Administration
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 Federal Aviation Administration
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 Do. D • Software—Reference Implementations (RI)—is currently being developed for WCS & WFS NNEW March 18, 2010 Federal Aviation Administration
Wx Data Representation • net. CDF-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 Federal Aviation Administration
Data Format Development • Data encoded in net. CDF-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 Federal Aviation Administration
4 -D Wx Data Cube Additional Functions • 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 NNEW March 18, 2010 Federal Aviation Administration
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 Federal Aviation Administration
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 vocabularyindependent manner • This ontology is under development NNEW March 18, 2010 Federal Aviation Administration
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 Federal Aviation Administration
Architecture NNEW March 18, 2010 Federal Aviation Administration
4 -D Wx Data Cube Context NNEW March 18, 2010 21 Federal Aviation Administration 21
4 -D Wx Data Cube Conceptual Architecture Automation Systems Weather Systems TFM Planners TFMS Weather Related Services 4 -D Wx Data Cube Weather Related Services NWP ERAM Sector Controllers System Data Retrieval System Data Ingest ITWS AOC STARS Dispatchers NNEW 22 RASP Avionics MADIS Pilots March 18, 2010 Terminal Controllers Federal Aviation Administration 22
4 -D Wx Data Cube SOA Context Consumers Forecast Systems AOC Automation TFMS Automation Interaction Services Mission Services Content Management Services Data Acquisition Services “Translation Services” CRP Services Basic 4 -D Wx Data Services AIM Services Providers Net-Enabled Services Flow/Flight Services 4 -D Wx Data Cube Other Services CRP – Complex Retrieval Processing 23 Weather Systems Forecast Systems ERAM Automation NNEW March 18, 2010 Federal Aviation Administration 23
4 -D Wx Data Cube High-Level Physical Architecture Weather Data End Users Origin Server Weather Provider System Distribution Server Consumer Automation Distribution Server 4 -D Wx Data Cube Registry/ Repository FTI WAN Consumer Automation Origin Server Distribution Server Consumer Automation Weather Data End Users Weather Provider System Weather Data End Users NNEW March 18, 2010 Federal Aviation Administration 24
Notional Interagency Architecture Support Enclave External DMZ Output Edge Servers Reg/Rep NOAA Gateway Reg/Rep NAS Incoming Distribution Server Data Filter Origin Servers NAS Outgoing Distribution Server CRP Servers Internal DMZ NWS Data Providers Cube Input Edge Servers Weather Data Consumers NOAA Enterprise Cube Output Edge Servers NWS IP Networks FAA Enterprise FTI IP WAN Reg/Rep Distribution Servers Distribution Server Consumer Automation Weather Data Consumers Core Enclave 25 FAA Data Providers Consumer Automation Weather Data Consumers Support Enclave NNEW March 18, 2010 Federal Aviation Administration 25
Interagency Data Exchange Sequence “Caching Proxy” Start: End User Makes request requiring weather information FAA/NWS Security Boundary* Data retrieved From NWS on 1 st data request and then cached locally. Subsequent requests May be serviced directly * details of the security boundary not depicted NNEW 26 March 18, 2010 Federal Aviation Administration 26
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 Next. Gen capabilities – Allows for growth of Next. Gen capabilities in NAS Automation – Allows for transition of Weather Data Providers per the NAS Roadmap NNEW March 18, 2010 27 Federal Aviation Administration 27
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 Next. Gen 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 Federal Aviation Administration
High-Level Segment 1 View & Transition NNEW March 18, 2010 Federal Aviation Administration
NNEW & NWP Segment 1 NNEW March 18, 2010 Federal Aviation Administration 30
NAS Weather Architecture Segment 1 - 2015 2010 2011 2012 Service Adaptor and Wx Architecture Development Legend TWIP Sensors Sources Pilot LLWASR/S End User System Display / Weather Processor (Server ) / Communications Links ASR WSP ASR -9 WX Interface Consumer Cube Service Adaptor (CCSA) LLWAS -NE TDWR Provider Cube Service Adaptor (PCSA) Non- SOA/Cube Connection ITWS ETMS Local Displays SD NIDS NWP Prototype NWP (NNEW Enabled) NEXRAD Lightning Vendor External Users ASOS /AWOS RASP ADAS Global Sources WMSCR MDCRS Via ARINC FBWTG NOAA Product Generation Centers Terminal 4 -D Weather Data Cube Prototype WARP WINS Local Displays TWIP ARTCC DSR ETMS ATOP URET ERAM / URET HOST DOTS + DOTS FDP 2 K NIDS ATCSCC ETMS DOTS + Vendors Customer Tower/TRACON Controller Traffic Flow Specialists Approach Controller Airline Operations Center Pilot En Route Controller Meteorologists Traffic Flow Specialists Oceanic ATC Traffic Flow Manager NEXRAD External Users Flight Services FS 21 FSS Specialist Pilot FIS CIWS Prototype Pilot TFM Specialist NNEW March 18, 2010 Federal Aviation Administration 31
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 Net. CDF-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 Federal Aviation Administration
NNEW Program Key Elements (cont) • Software Development – Registry/Repository • eb. XML-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 March 18, 2010 Federal Aviation Administration
Next. Gen Infrastructure Program Stack (Long-Term Outlook). . . NWP RASP Weather Systems/Programs (Data Producers/ Consumers) ITWS NNEW Weather-Specific Data Formats & Access Services AIM Flow Flight CATM . . . Federated Registry/Repository and Registry Extensions Deployed weather data distribution hubs Runtime Registration (required for weather (especially for SAS) SWIM may or may not provide this Metadata tagging massive quantities of information for content Interagency coordination Ensuring appropriate weather info is available and published Retrieving only needed weather information Define business logic within the service container SWIM Mission & Domain SOA Infrastructure/ Extended Services Cross-Domain SOA Infrastructure/ Core Services Messaging, Security, Monitoring, Core Registry, DNS ? FTI Basic IP Connectivity Fault-Tolerant Backbone Physical Network Layer Infrastructure NNEW March 18, 2010 Federal Aviation Administration
BACKUP NNEW March 18, 2010 Federal Aviation Administration
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 Federal Aviation Administration
Service Adaptors & Data Flow Spreadsheet NNEW March 18, 2010 Federal Aviation Administration
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 Federal Aviation Administration
Service Adaptors (cont) • Currently identified Segment 1 SAs – PCSAs • RASP (complete) • ITWS (scheduled for FY 10) – CCSAs • • DOTS (scheduled for FY 10) ATOP (scheduled for FY 10) FDP 2 K (scheduled for FY 11) ITWS (scheduled for FY 11) TFMS (scheduled for FY 11) NIDS (scheduled for FY 12) ERAM/URET (scheduled for FY 12) NNEW March 18, 2010 Federal Aviation Administration
Service Adaptors (cont) • 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 NNEW March 18, 2010 Federal Aviation Administration
SA Plan Diagrams – CIWS Transition Current CIWS Flows Future NNEW March 18, 2010 Federal Aviation Administration 41
SA Plan Diagrams – WARP Transition Current WARP Flows Future NNEW March 18, 2010 Federal Aviation Administration 42
SA Plan Diagrams – ADAS/RASP Transition Current ADAS/RASP Flows Future NNEW March 18, 2010 Federal Aviation Administration 43
SA Plan Diagrams – ATOP Transition Current ATOP Flows Future NNEW March 18, 2010 Federal Aviation Administration 44
SA Plan Diagrams – DOTS Plus Transition Current DOTS Plus Flows Future NNEW March 18, 2010 Federal Aviation Administration 45
SA Plan Diagrams – ERAM/URET Transition Current ERAM/URET Flows Future NNEW March 18, 2010 Federal Aviation Administration 46
SA Plan Diagrams – FDP 2 K Transition Current FDP 2 K Flows Future NNEW March 18, 2010 Federal Aviation Administration 47
SA Plan Diagrams – ITWS Transition Current ITWS Flows Future NNEW March 18, 2010 Federal Aviation Administration 48
SA Plan Diagrams – TFMS Transition Current TFMS Flows Future NNEW March 18, 2010 Federal Aviation Administration 49
SA Plan Diagrams – NIDS Transition Current NIDS Flows Future NNEW March 18, 2010 Federal Aviation Administration 50
SA Plan Diagrams – BT Replacement Transition Current BT Replacement Flows Future NNEW March 18, 2010 Federal Aviation Administration 51
Data Flow Spreadsheet • 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 NNEW March 18, 2010 Federal Aviation Administration
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). ” NNEW March 18, 2010 Federal Aviation Administration
Demonstrations & Capability Evaluations NNEW March 18, 2010 Federal Aviation Administration
Demonstrations & Capability Evaluations • IT demonstrations conducted on 2007, 2008, and 2009 • FY 10 4 -D Wx Data Cube Capability Evaluation planned for September 2010 • Additional Capability Evaluations planned for FY 11 & FY 12 • Initial Next. Gen Weather Capability planned for FY 13 NNEW March 18, 2010 Federal Aviation Administration
FY 07 and FY 08 IT Demonstrations: NNEW FY 07 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. FY 08 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 Federal Aviation Administration 56
FY 2009 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 Do. D NNEW March 18, 2010 Federal Aviation Administration 57
FY 2009 demonstration results: NNEW • Artifacts – Next. Gen 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 Federal Aviation Administration 58
FY 2009 demonstration results: NNEW • 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 Federal Aviation Administration 59
FY 10 Capability Evaluation: NNEW • Primary Objective: To simulate operational Cube functionality as closely as possible to show 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 Federal Aviation Administration 60
FY 10 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 Federal Aviation Administration
DRAFT High-Level FY 10 Capability Evaluation Architecture: NNEW March 18, 2010 Federal Aviation Administration
DRAFT WJHTC FY 10 Capability Evaluation Architecture: NNEW March 18, 2010 Federal Aviation Administration
DRAFT NOAA/NWS FY 10 Capability Evaluation Architecture NNEW March 18, 2010 Federal Aviation Administration
FY 10 Capability Evaluation: NWP NNEW Evaluation • Planning to incorporate NWP prototype into NNEW FY 10 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 Federal Aviation Administration
FY 11 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 (FDP 2 K, ITWS CCSA, TFMS) • Evaluate additional security functionality • Use and evaluate an architecture that more closely resembles the proposed operational architecture NNEW March 18, 2010 Federal Aviation Administration
FY 12 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 Federal Aviation Administration
Proposed Initial Next. Gen Weather Capability – FY 13 • Essentially all current & new products, including the following categories, will be net enabled – – – ITWS CIWS/Co. SPA NEXRAD mosaics TDWR (but not base data) METARs NOAA-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 Federal Aviation Administration
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 Federal Aviation Administration
SA Additional SA Plan Diagrams NNEW March 18, 2010 Federal Aviation Administration
Architecture NNEW March 18, 2010 Federal Aviation Administration
Primary Actors Airport Ground Crew ATCSCC Planner Airport Operations Air Traffic Controller Air Traffic Manager Airport Manager Flight Operations ATC Coordinators FAA Operations End User Accident Investigator Air Transport Operations GA Pilot Flight Briefer Meteorologist Enterprise Consumers Pilot Dispatchers Military Pilot Commercial Pilot 72 NNEW March 18, 2010 Federal Aviation Administration 72
Secondary Actors (Part 1) Wx Provider Developer Cube Developer SOA Infrastructure Developer Wx SOA Developers Wx SOA Support SOA Admin Wx SOA Admin Cube Admin 73 Consumer Developer Wx Provider Admin SOA Infrastructure Admin Consumer Admin NNEW March 18, 2010 Federal Aviation Administration 73
Secondary Actors (Part 2) Provider Infrastructure Provider Data Avionics Forecast Systems Wx System as Provider System NAS System as Provider NAS System Weather Systems Sensor Systems Wx System as Consumer System NAS System as Consumer Display Systems Automation Systems NNEW March 18, 2010 74 Federal Aviation Administration 74
System Actors NNEW 75 March 18, 2010 Federal Aviation Administration 75
The Origin Server • Wx Data Origin Server • System Ingest Adaptor Wx Data Origin Server Provider Cube Service Adaptor (PCSA) • Service Container • Geospatial • Data Access • Service RI • Query Engine Source: Based on material provided by MIT-LL, NCAR and NOAA GSD • WCS Reference Implementation • Server Read/Write Interfaces • WFS Reference Implementation • Data Store/Cache • Request /Reply SWIM Service Adaptor (SSA) • Publish /Subscribe NNEW 76 March 18, 2010 Federal Aviation Administration 76
The Distribution Server • Service Container • Geospatial Data Access • Service RI Source: Based on material provided by MIT -LL, NCAR and NOAA GSD 77 • WCS/WFS Client Interfaces • WCS/WFS Server Interfaces SWIM Service • Query Engine Adaptor (SSA) • Data Store/Cache NNEW March 18, 2010 Federal Aviation Administration 77
Consumer Cube Service Adaptor End User Consumer Automation System • Consumer Automation • Consumer Cube Service Adaptor (CCSA) • Data Access Libraries • Registry/Repo sitory Libraries • Format Converter NNEW March 18, 2010 78 Federal Aviation Administration 78
Segment One 4 -D Wx Data Cube Products FAA 3 -D Grids 2 -6 hr Storm VIL FAA 3 -D Grids NWS/DOD Text 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/Do. D Radial format Enhanced Mosaic FAA Graphic Product Satellite Images NWS Graphic Product METARs/Specials/OMOs FAA/Do. D Text 0 -12 hr Graphical Turbulence Guidance NWS 3 -D Grids MDCRS Airlines/ARINC/NWS Text G-AIRMET NWS Graphic Product PIREPs Turbulence - Observations 3 -D Grids Terminal Aerodrome Forecasts (TAFs) Turbulence Forecast FAA 2 -6 hr Echo Tops Convection - Current Observations Format 0 -2 hr Echo Tops Convection Forecast Source 0 -2 hr Storm Vertically Integrated Liquid Water (VIL) Parameter Product [in red: under development] FAA Text NNEW March 18, 2010 Federal Aviation Administration 79
Segment One 4 -D Wx Data Cube Products FAA 3 -D Grids 2 -6 hr Storm VIL FAA 3 -D Grids NWS/DOD Text 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/Do. D Radial format Enhanced Mosaic FAA Graphic Product Satellite Images NWS Graphic Product METARs/Specials/OMOs FAA/Do. D Text 0 -12 hr Graphical Turbulence Guidance NWS 3 -D Grids MDCRS Airlines/ARINC/NWS Text G-AIRMET NWS Graphic Product PIREPs Turbulence - Observations 3 -D Grids Terminal Aerodrome Forecasts (TAFs) Turbulence Forecast FAA 2 -6 hr Echo Tops Convection - Current Observations Format 0 -2 hr Echo Tops Convection Forecast Source 0 -2 hr Storm Vertically Integrated Liquid Water (VIL) Parameter Product [in red: under development] FAA Text NNEW March 18, 2010 Federal Aviation Administration 80
WFS & WCS Requirements NNEW March 18, 2010 Federal Aviation Administration
WFS# WFS Requirement Text V 1. 0 4. 1. 1 The WFSRI shall provide the capability for the Service Provider to specify the supported features. 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. The WFSRI shall support the relational database data store. The WFSRI shall provide output in an ISO 19139 format. 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. 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 The WFSRI shall support geometric filtering of features, including the following: V 3. 0 X 4. 1. 2 V 2. 0 X 4. 1. 3 4. 1. 4 4. 1. 5 4. 2. 1. 1 X X 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. - Point. A feature may be subsetted by requesting a single point specified by X, Y, and Z values. - 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 - 4. 2. 1. 2 3 D 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. Corridor. A feature may be subsetted by extruding a rectangular area along a trajectory. A rectangular crosssection, 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. The WFSRI shall provide support for arbitrary geometric subsetting beyond rectangular bounding boxes. X X X NNEW March 18, 2010 Federal Aviation Administration 82
WFS# WFS Requirement Text V 1. 0 4. 2. 2. 1 The WFSRI shall be capable of providing a list of valid times from datasets that are temporally aggregated. 4. 2. 2. 2 The WFSRI shall provide the capability to constrain features by requesting a single valid time. 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. 4. 3. 1 The WFSRI shall require the use of GML(OGC 03 -105 R 1) 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. 5. 0. 1 The WFSRI shall support the WFS version 1. 1. 0 /2. 0 specifications. 5. 0. 2 The WFSRI shall be designed to support future WFS specification versions. 5. 0. 3 The WFSRI shall support version negotiation as outlined in the WFS 1. 1. 0 specification. 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. 5. 1. 2 The WFSRI shall allow the user to request a CRS that is not the default and is supported by the WFSRI. 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. ) 5. 3. 1. 1 The WFSRI shall support Key-Value Pair (KVP) encoding over HTTP GET for the Get. Capabilities operation. 5. 3. 1. 2 The WFSRI shall support Plain Old XML (POX) encoding over HTTP POST for the Get. Capabilities operation. 5. 3. 1. 3 The WFSRI shall support Simple Object Access Protocol (SOAP) encoding over HTTP POST for the Get. Capabilities operation. The WFSRI shall provide an XML document indicating services, capabilities and features. The WFSRI shall support Key-Value Pair (KVP) encoding over HTTP GET for the Describe. Feature request. The WFSRI shall support Plain Old XML (POX) encoding over HTTP POST for the Describe. Feature request. The WFSRI shall support Simple Object Access Protocol (SOAP) encoding over HTTP POST for the Describe. Feature request. 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. For the Get. Feature operation, the WFSRI shall support Plain Old XML (POX) encoding over HTTP POST. For the Get. Feature operation, the WFSRI shall support Simple Object Access Protocol (SOAP) encoding over HTTP POST. The WFSRI shall provide an XML document containing the feature member elements for each requested feature. V 3. 0 X 4. 2. 2. 3 V 2. 0 5. 3. 2. 1 5. 3. 3. 2 5. 3. 3. 3 5. 3. 4. 1 5. 3. 5. 2 5. 3. 6. 1 X X X X X X NNEW March 18, 2010 Federal Aviation Administration 83
WFS# WFS Requirement Text V 1. 0 V 2. 0 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. 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 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. 6. 3. 1 The WFSRI shall support the WFS-Transaction protocol to allow Service Providers to publish data to the WFS server 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. The WFSRI shall be capable of notifying Service Providers or system maintainers of critical errors in realtime or nearrealtime. This may be through email, notifications, or other means. This may be implemented based on SWIM mechanisms. 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. V 3. 0 X 6. 5. 2 6. 6. 1 X X X NNEW March 18, 2010 Federal Aviation Administration 84
WFS# WFS Requirement Text V 1. 0 V 2. 0 V 3. 0 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. 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. 7. 1 The WFSRI shall implement infrastructure capabilities in a manner compliant with the SWIM service container, and shall leverage SWIM mechanisms wherever appropriate. 7. 2 The WFSRI installation shall include WSDL definitions of the web services that it provides. X 7. 3 X 8. 1 9. 1 The WFSRI shall support the deployment and installation of the WFS operations (e. g. , Get. Capabilities, Describe. Feature. Type, Get. Feature into the SWIM service container, either through installation scripts or documentation for Service Providers. The WFSRI shall run on Linux and Windows platforms. The WFSRI shall provide a flexible means to add new data formats for native data storage. 9. 2 The WFSRI shall provide a flexible means to add new data formats at the interface level. 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. The WFSRI shall include or allow the use of WS-I compliance-checking tools. X 10. 2 X X X NNEW March 18, 2010 Federal Aviation Administration 85
WCS# 4. 1. 1 4. 1. 2 WCS Requirement Text 1. 2. 3. 4. 1. 3 4. 1. 4 4. 1. 5 4. 2. 1. 1 V 2. 0 X X X V 3. 0 X A unique identifier for the coverage. Name of the coverage. The directory for the coverage data files. Descriptive metadata for the dataset. The WCSRI shall provide the capability to serve virtually aggregated datasets 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) 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 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 The WCSRI shall support geometric subsetting of coverage volumes, including the following: 3 -D Volume 4. 2. 1. 2 4. 2. 2. 1 V 1. 0 The WCSRI shall provide the capability for the Service Provider to specify the available coverages or datasets that will be served by the WCSRI. The WCSRI shall provide the capability for the Service Provider to configure the following for each dataset offered by the WCSRI: X X X X Horizontal 2 -D Cross-section Vertical 2 -D Cross-section Sounding 1 -D Point Trajectory Corridor The WCSRI shall allow subsetting by arbitrary 3 -dimensional spatial volumes (such as an air traffic control sector) 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. NNEW March 18, 2010 Federal Aviation Administration 86
WCS# WCS Requirement Text V 1. 0 V 2. 0 V 3. 0 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: 00 Z model run cycle, and is valid for 14: 00 Z) 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 4. 2. 5. 1 The WCSRI shall support temporal trajectories for trajectory-related geometries (e. g. , trajectory, corridor, etc) X 4. 3. 1 The WCSRI shall support CF-Net. CDF 4 as a native file format X 4. 3. 2 The WCSRI shall expose CF-Net. CDF 4 as a file format at the protocol level X 4. 3. 3 The WCSRI shall support GRIB 2 as a native file format X 4. 3. 4 The WCSRI shall expose GRIB 2 as a file format at the protocol level 5. 1 The WCSRI shall support the version 1. 1. 2 specification 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 X X NNEW March 18, 2010 Federal Aviation Administration 87
WCS# WCS Requirement Text V 1. 0 V 2. 0 V 3. 0 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 Get. Capabilities operation X X 5. 3. 2 For the Get. Capabilities 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 Get. Capabilities elements: Service. Identification, Service. Provider, Operations. Metadata 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 Get. Capabilities, Describe. Coverage and Get. Coverage 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 (WGS 84) 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-Net. CDF” as the value for the supported. Format attribute. This is the Multipurpose Internet Mail Extensions (MIME) type for CF-Net. CDF 4 binary coverage data X 5. 4. 4. 3 The WCSRI shall support the Multipurpose Internet Mail Extensions (MIME) type for GRIB 2 binary coverage data as an optional value for the supported. Format attribute 5. 5. 1 For the Describe. Coverage 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 Coverage. Summary results X X 5. 7. 1 For the Get. Coverage 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 X X NNEW March 18, 2010 Federal Aviation Administration 88
WCS# WCS Requirement Text V 1. 0 V 2. 0 V 3. 0 5. 9. 1 The WCSRI shall support a Get. Metadata operation. The level of metadata requested (e. g. , dataset, field), as well as the particular metadata content, shall be specified in the operation request 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 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) 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) The WCSRI shall be capable of acting as a proxy or request delegate to another upstream WCSRI 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 X 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 X X X X 6. 7. 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 The WCSRI shall be capable of notifying Service Providers or system maintainers of critical errors in realtime or nearrealtime. This may be through email, notifications, or other means 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 The WCSRI shall provide the capability to “duplicate” a request and its precise response (including the data), for a rolling configurable time period The WCSRI shall provide the capability to configure the level of logging and specifics as to what is logged 6. 7. 2 The WCSRI shall record information sufficient to support audit reporting 6. 2. 4 6. 2. 5 6. 2. 6 6. 5. 2 6. 6. 1 6. 6. 2 X X X X X NNEW March 18, 2010 Federal Aviation Administration 89
WCS# 6. 8. 1 6. 8. 2 6. 8. 3 6. 8. 4 6. 2. 5 6. 2. 6 6. 8. 5 7. 1 7. 2 7. 3 8. 1 8. 2 9. 1 9. 2 9. 3 9. 4 10. 1 10. 2 WCS Requirement Text V 1. 0 WCSRI shall perform stringent data validation for communications, including but not limited to requests for data and messages/notifications sent from upstream nodes The WCSRI shall be compliant with the 4‑D Wx Data Cube security policies and implementation(s) The WCSRI shall provide configurable, role-based access to WCSRI web-service endpoints. Implementation of this requirement will leverage SWIM infrastructure security solutions 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 The WCSRI shall be capable of acting as a proxy or request delegate to another upstream WCSRI 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 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 The WCSRI shall implement infrastructure capabilities in a manner compliant with the SWIM service container, and shall leverage SWIM mechanisms wherever appropriate The WCSRI shall include WSDL definitions of the web services that it provides The WCSRI shall support the deployment and installation of the WCS operations (e. g. , Get. Capabilities, Describe. Coverage, Get. Coverage) into the SWIM service container, either through installation scripts or documentation for Service Providers 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 The WCSRI shall run on Linux and Windows The WCSRI shall provide a means to add new data formats for native data storage The WCSRI shall provide a means to add new data formats at the interface level The WCSRI shall allow for two versions of the WCSRI to be run concurrently in the same environment on the same node The WCSRI shall allow for additional protocols to be implemented and deployed alongside the WCS protocol 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 The WCSRI shall include or allow the use of WS-I compliance-checking tools X V 2. 0 V 3. 0 X X X X X X X NNEW March 18, 2010 Federal Aviation Administration 90
RWI NNEW March 18, 2010 Federal Aviation Administration
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 • Co. SPA supports 2 -8 hour WAF forecasts, making automated decision support possible – Enables decision support for strategic planning (AFP, SEVEN) NNEW March 18, 2010 Federal Aviation Administration
Translating Weather to Impacts Precipitation Echo Tops FCAA 05 +20 min +10 min Weather Avoidance Field (WAF) 0 min -10 min +20 min +10 min -10 min FCAA 08 Pilot Deviation Prob Weather Translation Techniques Estimated Airspace Availability NNEW March 18, 2010 Federal Aviation Administration
Current Weather Forecast Information CCFP is a human-generated convective forecast 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 convective forecast product depicting probabilities of convection (i. e. lightning) over two-hour periods from 0 -2, 2 -4…. 22 -24 hours, updated every two hours and running year round NNEW March 18, 2010 Federal Aviation Administration 94
4 -D Wx Data Cube Technical Architecture Framework NNEW March 18, 2010 Federal Aviation Administration
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 Federal Aviation Administration
Some Context NNEW March 18, 2010 Federal Aviation Administration
Скачать презентацию Next Gen Network Enabled Weather Tom Ryan March
c3d5c446d356e4b8ad48ae0123ad402a.ppt