NNEW White Paper v2

WHITE PAPER

The 4-D Weather Data Cube

Version 2.0

NextGen Network Enabled Weather Program

April 3, 2009

White Paper 4-D Weather Data Cube and Related Infrastructure

Version 2.0

TABLE OF CONTENTS

1 INTRODUCTION....................................................................................................................................1

1.1 PURPOSE........................................................................................................................................11.2 DOCUMENT SCOPE..........................................................................................................................11.3 BACKGROUND.................................................................................................................................11.4 VIRTUAL DATA CUBE CONCEPT..........................................................................................................2

1.4.1 Cube Domains........................................................................................................................21.4.2 Data Access............................................................................................................................3

2 4-D WX DATA CUBE ARCHITECTURE..............................................................................................5

2.1 NEXTGEN EA..................................................................................................................................52.2 NAS EA........................................................................................................................................72.3 FAA CUBE ARCHITECTURE.................................................................................................................7

2.3.1 Architectural Framework........................................................................................................72.3.2 METI Layer..............................................................................................................................8

2.3.2.1 What is Telecommunications Infrastructure?..............................................................................82.3.2.2 FAA Telecommunications Infrastructure (FTI).............................................................................92.3.2.3 The Cube and METI....................................................................................................................10

2.3.3 Core Services Layer...............................................................................................................102.3.3.1 What is SOA?.............................................................................................................................102.3.3.2 The SWIM Program/System (SWIM)..........................................................................................112.3.3.3 The Cube and SWIM..................................................................................................................132.3.3.4 The Cube and SOA.....................................................................................................................15

2.3.4 Weather Services Layer........................................................................................................152.3.5 Application Layer..................................................................................................................15

2.3.5.1 Providers....................................................................................................................................162.3.5.2 Consumers.................................................................................................................................172.3.5.3 Users..........................................................................................................................................17

2.4 LOW-LEVEL ARCHITECTURAL IMPLEMENTATION DETAILS.......................................................................172.4.1 Implementation Model.........................................................................................................182.4.2 Origin Server.........................................................................................................................192.4.3 Distribution Server................................................................................................................202.4.4 Registry/Repository..............................................................................................................212.4.5 Cross-Organizational Topology............................................................................................22

3 NNEW COLLABORATIVE EFFORTS................................................................................................24

3.1 OVERVIEW...................................................................................................................................243.1 JPDO..........................................................................................................................................243.2 FAA............................................................................................................................................24

3.2.1 SWIM....................................................................................................................................243.2.2 AIM.......................................................................................................................................25

3.3 INTERNATIONAL ORGANIZATIONS......................................................................................................253.3.1 OGC......................................................................................................................................253.3.2 Eurocontrol...........................................................................................................................26

APPENDIX A: SWIM STANDARDS.......................................................................................................... 27

APPENDIX B: WEATHER SPECIFIC STANDARDS......................................................................................28

Appendix C: Acronyms.................................................................................................................................34


Version 2.0

TABLE OF FIGURESFigure 1: Domains of the 4-D Wx Data Cube__________________________________________________2Figure 2: Conceptual View of the 4-D Wx Data Cube____________________________________________4Figure 3: The Cube’s NAS Architectural Hierarchy______________________________________________5Figure 4: NextGen Weather Enterprise_______________________________________________________6Figure 5: The Multi-Tiered Framework_______________________________________________________8Figure 6: Multiple Enterprise Networks Forming the METI Layer__________________________________9Figure 7: SWIM - NNEW Responsibilities at 4-D Wx Data Cube IOC_______________________________14Figure 8: High-Level UML diagram of the Cube’s Boundaries____________________________________16Figure 9: Hub and Spoke/Store and Forward as Applied to the Cube______________________________19Figure 10: A Cube Node as an Origin Server__________________________________________________20Figure 11: A Distribution Server with a Many-to-One Relationship________________________________21Figure 12: Cross-Organizational Topology___________________________________________________22Figure 13: SWIM Standards______________________________________________________________27


Version 2.0

1 Introduction

1.1 PurposeThe purpose of this paper is to describe the 4-D Weather Data Cube (“4-D Wx Data Cube” or “Cube”) and some of the work that is being done to develop it.

1.2 Document ScopeThis document provides a general description of the Cube. As explained within the document, the Cube is a multi-agency entity, but for the purposes of this paper, it will be described from a Federal Aviation Administration (FAA) perspective.

1.3 BackgroundThe concept of the Cube is a key element of the Next Generation Air Transportation System (NextGen) vision and is discussed in the NextGen Weather Concept of Operations.1 The Joint Planning and Development Office (JPDO) Weather Policy Study Team2 has described the Cube as a shared, 4-dimensional (three spatial dimensions and one temporal) database of weather information viewed as a conceptually unified source distributed among multiple, physical locations and suppliers. Another aspect of the Cube concept, as identified by the Weather Policy Study Team is that a portion the Cube is “a 4-Dimensional Weather Single Authoritative Source (SAS).” The SAS is defined as network-enabled, machine-readable, geo- and time-referenced weather information that includes current observations, interpolated current conditions, and predictions of future conditions that support probabilistic decision aids and provide a seamless, consistent common weather picture that is available to all Air Traffic Management (ATM) decision makers for integration into operational decisions.

A key enabler of the NextGen vision is its information dissemination capabilities, which are based on net-centric, distributed services. This is in turn an enabler of another aspect of the NextGen vision, which is to provide weather information that can be integrated directly into complex decision-support tools.

In order to meet these high-level goals, the FAA, National Oceanic and Atmospheric Administration (NOAA), and the Department of Defense (DoD) will establish the Cube and its necessary supporting infrastructure. The program within the FAA that is managing the development of the FAA’s portion of the Cube is NextGen Network Enabled Weather (NNEW).

The following strategies are being adopted for developing this capability: Utilizing a Service Oriented Architecture (SOA) to insulate data consumers from

the details of data providers

1 NextGen Weather Concept of Operations, Version 1.4, March 15, 20062 NextGen Weather Policy Findings and Recommendations, Version 0.1, October 31, 2007

Page 1


Version 2.0 Relying on a minimal set of open, common standards for data dissemination Developing a common and flexible security paradigm Participating in standards bodies in order to ensure that needed standards are

evolved as necessary to support Cube operations Pursuing a thorough understanding of the needs of a National Airspace System

(NAS)-wide weather data dissemination system, in addition to world-wide weather needs

Developing in a modular fashion to facilitate the addition of capabilities as requirements, approaches, and techniques evolve over time

1.4 Virtual Data Cube ConceptThe nucleus of the JPDO vision for providing weather information in the NextGen era is the concept of a 4-D Wx Data Cube. The distributed nature of weather data makes the Cube a virtual database that will be composed of multiple, physical databases maintained at different locations. These independently managed data sources will be under the control of the owning agents such as NOAA, FAA, DoD, and possibly other Government and commercial weather information providers. Through the use of an architecture built on SOA principles, the Cube will function and appear to users as a single database. The actual physical locations of the data sources will be transparent to the users. This distributed service model is in keeping with the net-centric dissemination vision of NextGen.

1.4.1 Cube DomainsSince the Cube will be used by a diverse set of users, Cube data will be accessed through the creation of data domains. Though one of the most common uses of the Cube will be to access SAS data, a number of other domains have been defined by the JPDO Weather Policy Study Team. Currently identified Cube domains are shown in Figure 1Error: Reference source not found.

Figure 1: Domains of the 4-D Wx Data Cube

Page 2


Version 2.0

Domain 1 in the figure is equivalent to the SAS. This domain will be freely available to all authorized users of the Cube. Data in this domain constitute those data required for collaborative decision making in ATM operations. That is, these data are used by controllers, Flight Operations Centers, and pilots to make joint operational decisions. Therefore, these data must be consistent such that all users "see" the weather phenomena (observation or forecast) in question in exactly the same place with the same accuracy, intensity, and/or reading at the same point in time.

The Federal weather domain authority (the body that will define and implement clear operating rules for determining the data source to be used for a given time and location) will determine what data from the Cube will be part of the SAS, which may be a unique set of data. The constitution of the domain authority body is being considered by the JPDO Weather Policy Team.

All of the Cube’s data domains will have unrestricted data rights, except for domain 2a and 4b (as denoted in Figure 1), which will contain information with limited data rights (i.e., proprietary) and will only be accessible by authorized users. It should be noted that domains in addition to those shown may exist, e.g., an “experimental 4-D Wx SAS” domain for the research community. Though the primary usage of the Cube will involve the domains shown, the Cube architecture will support flexible, general-purpose domain management mechanisms.

1.4.2 Data AccessThe majority of Cube data will consist of two different types of data: gridded data and non-gridded data. Non-gridded data include such weather information as METARs, 3 TAFs, 4 PIREPs, 5 frontal boundaries, etc. Gridded data are associated with two-dimensional or three-dimensional grids established over an area of interest (e.g., the continental United States, North America).

Many of the data contained in the databases will be gridded data. Depending on the type of dataset, grids may be nested inside each other at various resolutions. For example, a low-level winds dataset may have a higher resolution in the critical terminal area than outside the terminal area.

In order to illustrate the concept of the Cube, Figure 2 focuses on a single grid point over Chicago O’Hare International Airport. The figure depicts data representing various weather parameters being contributed to the Cube by multiple data sources. Each data source in the picture is colored differently to indicate that it is a distinct, separate source of data for the exact same grid point. When the Cube is queried for certain data from any grid point, or likely more often from multiple grid points, relevant and available data

3 Aviation Routine Weather Report4 Terminal Aerodrome Forecast5 Pilot Report

Page 3


Version 2.0for the point or points are returned to the user from the applicable domain or domains. Some data, however, will be restricted due to authorization criteria (discussed in section 2.1). As shown at the bottom right, the figure illustrates a query to the SAS domain, and the user receives a single result set with those items that were specific to the SAS.

Figure 2: Conceptual View of the 4-D Wx Data Cube

Page 4


Version 2.0

2 4-D Wx Data Cube ArchitectureArchitecture provides a means of defining the organization of components and their relationships to one another. This is accomplished by means of mapping functionality to hardware and software in order to achieve a detailed plan for implementation.

The Cube’s architecture work exists on different levels, from integrating into the NextGen and FAA Enterprise Architectures (EAs) to a more concrete definition, such as the low-level details that will support the Cube architectures within the different agencies. Figure 3 illustrates the Cube’s NAS architectural hierarchies, the relationship of the NextGen EA, and the FAA’s portion of the Cube that fits within the NAS EA. The other agencies and their portions of the Cube’s architecture have been omitted in order to simplify the diagram and keep the focus within the FAA. If shown, those parallel efforts would all fall underneath the NextGen EA.

Figure 3: The Cube’s NAS Architectural Hierarchy

The architecture described is based on a number of preliminary assumptions, some of which will be subject to change as the Cube’s requirements and EA roadmaps are further refined. This document will be periodically updated to reflect the most recent architectural decisions.

2.1 NextGen EAThe NextGen EA entails designing a high-level architecture that meets the goals of the NextGen vision, ensuring that each of the contributing agencies’ system architectures integrate well with the design, and ensuring that cross-agency coordination is occurring.

Page 5


Version 2.0Figure 4 shows a high-level, conceptual Unified Modeling Language (UML)6 diagram of how the Cube will fit into the NextGen Weather Enterprise (NWE). The NWE is the portion of NextGen that is specific to the weather domain. The diagram shows some of the relationships that will exist within the NWE. Many relationships and actors have been omitted in order to keep the depiction as simple as possible while capturing the high-level concept of the NWE.

Figure 4: NextGen Weather Enterprise

At the center of the figure is the use case to “Provide Net-Enabled Weather Data,” as stated in the JPDO Weather ConOps. This NextGen weather objective along with the contributors of weather data (FAA, NOAA, DoD, and commercial weather data providers that may participate) combine to form the abstract, high-level Cube. In addition, the Cube falls within the NWE, which encompasses all NextGen weather-related functions, such as integrating weather data into decision-making tools.

The JPDO is spearheading much of the architecture work though working groups7 which have enabled collaboration and coordination on the functional and technical requirements of the Cube’s architecture and design. Additionally, the JPDO Net-Centric Division may be modifying the NextGen EA, which could impact the architecture of the Cube.

6 The stick figures within the diagram are referred to as actors, in UML notation. An actor "specifies a role played by a user or any other system that interacts with the subject." "Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances." Quotes taken from: Object Management Group Unified Modeling Language (OMG UML), Superstructure, V2.1.27 More information on JPDO working groups can be found in section 3.1

Page 6


Version 2.0

2.2 NAS EAA part of the effort of the NNEW Program is to propose changes to NAS EA, as needed to accommodate the Cube’s architecture, while fitting into the NextGen EA. This work is being accomplished as part of the FAA’s Investment Analysis (IA) activity, which is required by the Acquisition Management System (AMS) Policy. As stated in the FAA’s AMS Policy, EA defines the operational and technical framework for all capital assets of the FAA. It describes the agency’s current and target architectures, as well as the transition strategy for moving from the current to the target architecture.

The IA architecture work is being coordinated with the NAS Chief Architect within the Air Traffic Organization’s NextGen and Operations Planning business unit. They are working closely with the NNEW Program to help define the Cube’s architecture within the FAA.

Additional work is also necessary in order to coordinate the NAS EA efforts and the physical implementation details. Therefore, consultants have been staffed in order to collaborate on details between the high-level EA and the system level implementation. This will ensure that the implementation details that are being developed at the lowest level will fit within the framework that is being outlined at the enterprise level.

2.3 FAA Cube ArchitectureMuch of the architecture work for the FAA’s portion of the Cube will involve high-level, FAA focused, Cube architecture work, as well as the coordination work to bridge the implementation details at the lower level to the high-level NAS EA. Although this effort will focus on developing a Cube architecture for the FAA, the work will be shared with other agencies, such as NOAA and DoD. Sharing the work will help the other agencies align their own EA with their portion of the Cube’s architectural work while adhering to a consistent implementation pattern.

2.3.1 Architectural FrameworkThe Cube will span multiple enterprise networks and will be designed in a multi-layered approach based on a SOA paradigm, thus enabling effective opportunities for data dissemination. The architectural framework for the Cube will be comprised of four layers; an Application Layer, a Weather Services Layer, a Core Services Layer, and a Multiple Enterprise Telecommunications Infrastructure (METI) Layer. Figure 58 depicts how these four layers will combine to form the Cube.

8 Adapted from SWIM Functional Architecture Figure, SWIM Technical Overview, Version 2.0, Draft, March 07, 2008, FAA – SWIM Program.

Page 7


Version 2.0

Figure 5: The Multi-Tiered Framework

Each of the four layers within the framework performs unique functions in order to orchestrate data dissemination within the Cube. The METI Layer provides the physical telecommunications networking and monitoring for the communications facilitated by the Core Services Layer. The Weather Services Layer is then built on top of the Core Services Layer and provides the infrastructure necessary to connect and adapt the providers and consumers, at the Applications Layer, to the Cube.

2.3.2 METI LayerAt the lowest layer of the architectural framework is the telecommunications infrastructure. Since the Cube will span multiple agencies, the telecommunication infrastructure will encompass more than just a single enterprise network; it will be a Multi-Enterprise Telecommunications Infrastructure Layer.

2.3.2.1 What is Telecommunications Infrastructure?Telecommunications Infrastructure provides the raw network connectivity and associated monitoring infrastructure. Basic telecommunications services will be provided by each individual enterprise network of the Cube, as shown in Figure 6. The figure shows how each enterprise network of the Cube will include its own telecommunications functions of secure Internet Protocol (IP) network connectivity, naming and addressing, incident detection and response, and identity management. The figure does not intend to assert that these functions are the only services of a telecommunications network; it simply represents of the basic functions of telecommunications.

Page 8


Version 2.0

Figure 6: Multiple Enterprise Networks Forming the METI Layer

2.3.2.2 FAA Telecommunications Infrastructure (FTI)The FTI is the physical telecommunications network that interconnects FAA facilities nationwide. It is used to carry mission and operationally critical data for air transportation needs throughout the NAS.

The Cube will use the FTI Operational IP network as the underlying backbone of data transport within the FAA. Since FAA security policies preclude any direct connection of non-NAS systems to NAS systems,9 security extranet gateways10 will utilize boundary protection mechanisms to allow non-NAS systems to access Cube data residing in the NAS. These extranet gateways are referred to as “ED-8” gateways by FTI, as labeled in the above picture. The current plan is to utilize all operational NAS FTI ED-8 gateways to handle the traffic between NAS and non-NAS systems.

In order to facilitate access without creating a direct connection, boundary protection functions such as Service Delivery Points, Internet Access Points, and Dedicated Telecom Services will be used to allow seamless access to Cube data outside of the NAS while conforming to FAA security policies.

In addition, FTI is currently operating as a closed IP network topology. This means that each system that resides within the network is closed to traffic from other systems until requirements are written and permission is granted for the systems to interact with each other. This type of closed network topology is not conducive to a runtime SOA

9 FAA Order 1370.95 [3]10 The enterprise gateway is a NAS boundary protection security scheme.

Page 9


Version 2.0environment11 and therefore could pose a challenge to implementing the Cube within the FAA. The NNEW Program will resolve this obstacle by working with the FTI and System-Wide Information Management (SWIM) Programs to ensure that the proper information technology (IT) requirements are written and implemented in time for the Cube’s Initial Operating Capability (IOC).

2.3.2.3 The Cube and METIThe METI Layer of the Cube will extend outside the boundaries of the NAS. Figure 6Error: Reference source not found is an example of a high-level diagram of multiple enterprise networks connecting through boundary protection. Security is major concern for the Cube since it will open multiple enterprise networks to data trafficking. In the figure, the FAA’s ED-8 gateway has already been labeled as the connection point to the NAS Operational IP network for the Cube but it has not yet been determined how the connections will be handled for other agencies and non-governmental organizations.

In order to coordinate the security concerns of the Cube throughout all of the enterprise networks, an overarching System Management Function (SMF) will need to be defined. The SMF is envisioned to be a governing body focused on security, governance, and policy of the Cube. The SMF work is not just confined to a single layer of the Cube, such as the METI Layer. The SMF will coordinate, collaborate, and manage all cross-enterprise Cube concerns.

The “TBD” in Figure 6Error: Reference source not found is used to represent that the type(s) of connection(s) that will be used to bridge the networks is/are unknown. These connection types could vary depending upon the security policies of the owning agencies. Options for connecting the enterprise networks could be, but are not limited to, dedicated telecommunications services, virtual private networks, or secure internet connections.

2.3.3 Core Services LayerThe Core Services Layer is comprised of the foundations of an IT system, the SWIM System, built within a SOA. This section discusses the Core Services Layer of the Cube.

2.3.3.1 What is SOA?SOA is an approach to system design where business process and functionality of applications are repackaged into modular, interoperable business services that can be reused to create other services and applications. The goal of SOA is to create an open-standards, IT ecosystem that is technology-agnostic, reducing development costs while achieving greater system agility. This is accomplished by loose-coupling the implementation details of an application from its information technology concerns through the use of open standards (HTTP, XML, REST, SOAP, etc).12 With a SOA, a 11 Runtime SOA environment need and definition are discussed in section 2.3.4.2.12 See Appendix B, World Wide Web Consortium (W3C) standards, for more information on these standards.

Page 10


Version 2.0business service can make its products available using a variety of communication protocols and data formats.

SOA supports service discovery at both design-time and runtime. At design-time, a service provider or consumer uses a registry to discover information about an abstract service interface, including all the details needed to build server and client-side software that conforms to the standard interface. There will typically be multiple instances of a given service that conform to the service's interface, distributed throughout the NAS as needed. At runtime, applications discover instance-specific information, such as the individual addresses of each service, via a runtime registry. These design-time and runtime capabilities are highly complementary. The design-time SOA environment is required for developers working to build new services, while the runtime SOA environment is required once the services become operational in order to provide the loose coupling that results in an agile system.

2.3.3.2 The SWIM Program/System (SWIM)SWIM is an FAA enterprise IT infrastructure program that is implementing a system which will apply the SOA paradigm to NAS applications by utilizing state-of-the-art, net-centric, information management and exchange technologies.13 SWIM will accomplish its goals by providing IT infrastructure capabilities to the NAS enterprise in the form of Core Services and enterprise governance. Core Services enable “business services” to be available throughout the enterprise while maintaining loose-coupling and maximizing reuse and consistent implementation.14 SWIM will define and approve standards for Core Services to enable NAS applications to expose their products and data as NAS business services. SWIM Core Services include the following:11

Interface Management includes interface specification and interface discovery as well as support for managing the schemas that define data format and semantics for interface data elements. Interface Management also covers the runtime capability provided by Service Invocation which covers the connectivity and communication aspects of core services.Messaging covers how data are passed between applications. It includes how the data envelope is structured (SOAP) and how metadata supports content based routing and policy. It also covers reliable delivery.Security covers how both service consumers and providers authenticate themselves, assert privileges, and provide confidentiality for invoking and consuming services at both the application endpoint and security levels.Enterprise Service Management has two aspects. The first is how services are governed. This includes managing the development, deployment, operation, and retirement phases of a service. Services are managed based on the required Quality of Service (QoS) as expressed by a Service Level Agreements (SLA) between the service provider and potentially many service consumers. The

13 SWIM Concept of Use, Version 3.1, Draft, March 26, 2007, FAA.14 SWIM Core Services Concept, Version 1.0, April 14, 2007, FAA.

Page 11


Version 2.0other aspect of Enterprise Service Management is how the operational system is monitored to ensure that SLAs are being met.

NAS weather business service providers, which use SWIM managed, IT services, are referred to as Cube Participants (CPs). Core Services will be implemented by the CPs in one of two ways. SWIM-provided Core Services will be implemented through the use of common, commercial software, while CP-provided Core Services will be developed/procured software that meets SWIM-Program-Office-mandated standards.15

The main vehicle for Core Service implementation is the SWIM-provided Service Container. The Service Container is software that will provide an abstraction layer through which pluggable Core Services will separate business concerns from information technology concerns such as security, policy, transport, and service location.16 SWIM will provide guidance and assistance for the deployment of the Service Container software; however, the implementation, maintenance, and administration will be decided upon by the CPs.

The combination of the Service Container and other adaptation components provided by the CPs is referred to as a SWIM Service Adaptor. Within the Weather Services Layer, CPs will implement those functional components with weather domain specific needs to create a Cube Service Adaptor (CSA). Once the Service Adaptor has been created, metadata about the newly created service will be stored in a UDDI Service Registry/Repository (service registry). The service registry exposes the metadata to make the service searchable for design-time discovery.

SWIM will deliver its full complement of SOA capabilities in three “segments.” Much of this document is focused on SWIM Segment 1 work, which is currently in development and is planned for delivery in time for the Cube’s IOC. SWIM Segment 1 will deliver its federated, IT infrastructure in a design-time SOA environment. SWIM Segment 2, which could potentially consolidate and centralize the SWIM infrastructure in a runtime SOA environment, is currently being defined; it could potentially be in the early stages of implementation at the Cube’s IOC.

The SWIM Program’s main focus for its current scope of work is on IT and service management though the provision of federated Core Services and a service registry. As such, they will focus on interoperability and interface management. For the security and messaging Core Services, SWIM will adopt standards and allow the CPs to implement the standards in the manner that makes the most sense for their business purposes.

15 SWIM Overview and Segment 1 Strategy Brief, September 19, 2007, FAA.16 For more information about SWIM and SWIM Core Services, please see SWIM Concept of Use, Version 3.1, Draft, March 26, 2007, FAA.

Page 12


Version 2.0The SWIM Program is also creating policy to exercise control of SOA activities within the NAS. Among other things, policy is established to ensure quality of service and compliance to standards. The following is a list of some of the SWIM policy categories:

Strategic Management Service Operating Model Service Development Lifecycle Service Runtime/Operations Service Design

These categories will have policy written to satisfy all levels of policy requirements. Since SWIM policy is still in the early stages of development, the list above should not be viewed as the final category list of SWIM policy.

2.3.3.3 The Cube and SWIMThe Cube will leverage and utilize the SWIM System within the FAA to provide most of the IT requirements for the Cube at IOC. It is the intent of the Cube’s developers to fully utilize the SOA capabilities that SWIM is implementing. However, in some cases, the SWIM Program may not be able to implement some of the Cube’s IT requirements by IOC. In this instance, these IT requirements will be delivered by the NNEW Program and transitioned to the SWIM Program, as appropriate, as the SWIM System matures. In order to help minimize the risk of non-delivery of IT requirements, the SWIM Program has agreed to collaborate on the NNEW Program schedule and requirements to better understand timing with respect to IT requirements delivery.

Figure 7 outlines the current roles and responsibilities of the SWIM and NNEW Programs. These roles may change depending upon a shift in responsibility with respect to IT requirements delivery.

Page 13


Version 2.0Figure 7: SWIM - NNEW Responsibilities at 4-D Wx Data Cube IOC

SW

IM P

rovi

ded

SW

IM D

efin

ed

SW

IM

Imp

lem

ente

d/D

ep

loye

d

SM

F/N

NE

W P

rovi

ded

SM

F/N

NE

W D

efin

ed

SM

F/N

NE

W

Imp

lem

ente

d/D

ep

loye

d

CP

Imp

lem

ente

d/D

ep

loye

d

CO

RE

SE

RV

ICE

S Inte

rfac

e

Mg

mt

SWIM UDDI Service Registry Software

Cube ebXML Data Management Registry Software

Dataset Registry Metadata

ES

M

SWIM Enterprise Governance/Policy

Cube Governance/Policy

Sec

uri

ty Core Services Security Standards

Cube Security Standards

Mes

sag

e Core Service Messaging Standards

Cube Messaging Standards

Oth

er

Wea

ther

S

tan

dar

ds

Weather Services Standards

Weather Data Format Standards

Infr

astr

uct

ure

& S

ervi

ces

SWIM Segment 1 Weather Services

Non-SWIM Weather Services

Service Container Software

UDDI Registry Hardware

Cube ebXML Registry Hardware

Cube Node & Cube Service Adaptor Hardware/Software

SWIM Service Container License/Support

SWIM Service Container Training

2.3.3.4 The Cube and SOA

Page 14


Version 2.0While the Cube will utilize the enabling functions of the SWIM system to provide Core Services to CPs within FAA, the Cube will also require Core Services to be provided to non-FAA CPs. This means that the functions provided by SWIM for the FAA must be provided by other agencies and commercial providers for their CPs. In addition, the Cube’s SMF, as mentioned in section 2.3.2.3, must approve standards and provide governance to the Cube. Non-FAA CPs will take on the same responsibilities of implementation that NAS CPs will be required to perform in order to become part of the Cube.

2.3.4 Weather Services LayerThe weather domain concerns of the Cube are addressed by the Weather Services Layer; it is where the majority of the Cube’s infrastructure and standards are being developed and implemented by the NNEW Program. The Weather Services Layer enhances the capabilities of the Core Services Layer with the addition of weather specific standards, formats, and infrastructure. The combination of these additional components will provide the ability to discover Cube data using SAS concepts, the ability to access data using what, where, when queries, and the ability to support those capabilities in a scalable manner.

Figure 5, shows a multi-coloring of the Weather Services Layer. This is due to the cross cutting concerns of the Core Services Layer below it and the Applications Layer above it that must be addressed through coordination of development efforts. Some of the Core Services of the Core Services Layer are cross-colored as well, denoting that additional messaging and security requirements will be handled by the Cube’s developers and implemented as part of the Weather Services Layer.

The work of the Weather Services Layer can be found in section 2.4 where the implementation details of the Cube are discussed at length.

2.3.5 Application LayerAt the top of the architectural framework, the Application Layer consists of aviation weather data users and systems that will provide data through and consume data from the Cube. Together with the standards and infrastructure being developed at the Core Services and Weather Services Layers, these applications/systems will become the business services of the Cube.

Business services, as referred to in section 2.3.3.1, can be broken down into two subcategories: provider services and consumer services.

Since providers and consumers have different business functions, they will require different types of CSAs. Therefore, the CSA is broken down into two subcategories as well: provider CSAs and consumer CSAs. Unless otherwise stated “CSA” refers to “provider CSA” in the discussion below.

Page 15


Version 2.02.3.5.1 Providers Providers are defined as weather applications/systems that will make data available as the Cube by implementing a CSA.17,18 Provider services making data available “as the Cube” is an important distinction from “to the Cube” due to the manner in which the boundaries of the Cube have been drawn in Figure 1. Provider data and the infrastructure necessary to support the Cube (registries, CSAs, etc.), are within the boundary of the Cube. This means that a provider’s data are part of the Cube, while the algorithms, hardware, and other infrastructure of the provider are outside the bounds of the Cube. This concept is illustrated below in Figure 8.

Figure 8: High-Level UML diagram of the Cube’s Boundaries

In addition, some of the data that some providers will make available as the Cube will be received from systems that are not CPs. For example, NEXRAD data will be published in the Cube but will not be published by NEXRAD systems. Furthermore, in many cases, a provider, such as ITWS, will also consume Cube data and provide newly created data products back to the Cube for consumption.

17 CSAs are discussed in more detail in section 2.4.18 This refers to legacy system implementation. For newly created systems, the functionality provided by the CSA could be incorporated into the system itself.

Page 16


Version 2.0

2.3.5.2 ConsumersConsumers are applications/systems that utilize a CSA (or with the equivalent functionality built-in) in order to access Cube data. The consumer CSA functions in a much different manner than the provider CSA and is composed of different components. It will be smaller in size and may simply consist of data access libraries that may be obtained and utilized or referenced by developers wishing to create consumer services.

Consumers may be developed to perform routine tasks, such as running an algorithm or model that requires aviation weather data or ingesting certain dataset used for mission-specific functions. For example, a consumer service may be created for integrating multi-institutional data for product generation or to run algorithms which generate or determine the SAS.

Although Figure 8 shows that consumers are within the bounds of the NWE, consumers may be inside or outside the bounds of the NWE.

2.3.5.3 UsersUsers of the Cube, which are by in large human users, will typically access the Cube indirectly. Retrieving Cube data indirectly simply means receiving data through an intermediary, such as a consumer service. These consumer services will determine authentication and check authorization for access to the Cube datasets that the user is eligible to receive. Consumer services will have specific functions, as described in the previous section.

Some users, though, will have direct access to the Cube. These users could be analysts, developers, or administrators. Authorization for all Cube access, whether direct or indirect, will be overseen as part of a governance/policy process as determined by the SMF.

2.4 Low-Level Architectural Implementation DetailsThe Cube will require infrastructure, in the form of hardware and software, to be deployed throughout the NAS in order to become operational. It is the infrastructure that combines the collection of weather business services to create a Cube that operates as a single entity. This infrastructure will be deployed in a data distribution model to ensure that data are disseminated both timely and efficiently.

Most of the infrastructure of the Cube is in the form of hardware and custom software solutions that will connect all the nodes of the Cube. The actual architecture has not been determined. However, the notional architecture includes servers to be deployed at ARTCCs, TRACONs, and FTI Gateway locations. These servers would operate the Cube’s registries, CSAs, and other Cube specific software applications.

Page 17


Version 2.0

As discussed in section 2.3.5.2, additional software will also be developed in the form of consumer services to handle mission-specific business functions that will retrieve data/products to provide solutions for complex problems, such as forecasts for a 4-D route.

This section contains an overview of the low-level implementation details on how the Cube will be implemented in an operational setting. Much analysis must be done to determine if the design will meet the needs of the Cube and therefore the details in this section will be updated periodically, as needed.

2.4.1 Implementation ModelThe Cube will employ a hub and spoke model of data distribution to effectively disseminate its data to customers. The idea behind a hub and spoke model is to reduce the number of point-to-point connections while centralizing data concerns close to the source. While SOA will open the Cube up to limitless connections between consumers and providers, some structure is necessary so that data can be delivered in the most efficient means possible.

The hub and spoke model will be combined with a store and forward data distribution technique. Store and forward uses an intermediary data cache as a primary means of data delivery for distant consumers. This increases the response time from the original data provider to the consumer system in some cases, but also distributes load more efficiently throughout the system. It also increases availability of data by replicating the original provider data to the spokes within the hub and spoke model. These techniques are quite common among content-delivery networks, where performance, scalability, and cost-efficiency are key business drivers. In this sense, the Cube’s data distribution model can be thought of as a content-delivery network.

This framework for implementing the Cube content-delivery network will be employed through the deployment of Cube Nodes. Cube Nodes are highly agile, scalable, and configurable server implementations and will be deployed and configured as either Origin Server or Distribution Servers. Figure 9 shows a single instance of Origin and multiple Distribution servers within the framework described above.

Page 18


Version 2.0Figure 9: Hub and Spoke/Store and Forward as Applied to the Cube

The weather data provider, not pictured in the figure, is a NAS weather system/application that feeds data to the Origin server. The Origin Server ingests data from the provider, transforms that data, and inserts it into a local data store.

On the right hand side of the figure, the Weather Data Client requests or creates a subscription to data that are produced by the distant weather data provider. The request is handled by a local Distribution Server. If the Distribution Server does not have the requested data locally, it makes a request directly to the Origin Server. Once the data are retrieved, the Distribution Server will locally cache the data from the Origin Server in anticipation of additional requests. Furthermore, as a configurable option, the data will automatically begin to replicate and refresh to the Distribution Server as new data updates become available.

2.4.2 Origin ServerThe Origin Server will be as close as possible to the physical location of the data provider. It is comprised of a number of different components, but its fundamental purpose is to provide a Service Adaptor for data providers. Service Adaptor is a commonly used SOA term and is also used within the SWIM System to describe the primary means of systems connecting their NAS applications to the SWIM System, as mentioned in section 2.3.3.2. The Cube will use the SWIM Service Adaptor as the foundation for a CSA. The CSA is simply a modified SWIM Service Adaptor that has been enhanced with software that implements weather domain specific standards.

The Figure 10 depicts a very simplified view of an Origin Server acting as a CSA. In order to help draw a relationship to the multi-tiered framework of the Cube, Figure 10 roughly follows the same color scheme as Figure 5: The Multi-Tiered Framework.

Page 19


Version 2.0The CSA contains the System Ingest Adaptor and the SWIM Service Adaptor; the SWIM Service Adaptor is in the form of the SWIM Service Container and a Geospatial Data Access Service. The SWIM Service Container also provides the pluggable Core Services as discussed in the Core Services Layer section. The Geospatial Data Access Service is broken down into a data store and reference implementations (RI) that provide the service interface.

An RI is software that provides a definitive interpretation and implementation of a standard.19 The Cube’s RIs are highly configurable pieces of software that are implemented based on the WCS/WFS Open Geospatial Consortium (OGC) standards.20 The can accommodate different data models and formats and are the functional software component that allows the Cube’s data to be available. Through the use of open standards provided by the Core Services Layer, RIs will be able to make their data available as the Cube.

A System Ingest Adaptor will also be developed to perform adaptation functions within the CSA. Its purpose is to ingest NAS weather application data and to perform any transformations necessary before inserting it into a data store. The data store is accessed by the RIs mentioned previously.

Figure 10: A Cube Node as an Origin Server

2.4.3 Distribution ServerLike the Origin Server, the Distribution Server is a Cube Node. The main difference is a client read access library which will be responsible for replicating Origin Server data to the Distribution Server as consumers request the data. Since all Cube Nodes have the same relative structure and components, the Distribution Server is simply an Origin

19 For more information on the term “reference implementation,” see: http://en.wikipedia.org/wiki/Reference_implementation20 Cube standards can be found in Appendix B

Page 20


Version 2.0Server that has been configured to be a Distribution Server. In this manner, Cube Nodes can be scaled-up or scaled-down to become Origin or Distribution Servers, relative to the needs of local data consumers.

Distribution Servers will also have a many-to-one relationship with Origin Servers. This means that many Origin Servers will feed a single Distribution Server with data as updates become available. This also means that a Distribution Server will require enough storage capacity to meet caching requirements whereas Origin Servers will require a larger persistent data store. Figure 11 shows a simple representation of the many-to-one relationship between Origin and Distribution Servers.

Figure 11: A Distribution Server with a Many-to-One Relationship

2.4.4 Registry/RepositoryThe Cube’s infrastructure also includes an ebXML Data Management Registry/Repository (data management registry). The data management registry is the business driver of the Cube. It will store metadata about the datasets of the Cube, segregate those datasets into domains, and provide a semantically enhanced,21 data-discovery mechanism.

The data management registry of the Cube is somewhat similar in form to the service registry of SWIM, but the SWIM service registry will be used to manage service interfaces while the Cube’s data management registry will be used as a semantically enhanced, dataset-discovery mechanism. This will occur through the use of an ontology which is being developed for the Cube. The ontology will allow, for example, a DoD user to use a DoD-specific term for a weather parameter and be returned a list of results that includes not only DOD datasets, but relevant FAA and/or NOAA datasets as well.

In addition, the data management registry will also be utilized as a runtime registry to search for and dynamically request and subscribe to Cube data. A runtime environment will provide the Cube with system agility, which is a Cube requirement for SAS functions. 21 Herein, semantically enhanced means using synonymous terms from different languages to describe a single search term. For example, a registry search for the term AirTemperature would return all entries related to AirTemperature and TemperatureAir because they are semantically linked.

Page 21


Version 2.0Legacy systems tend to rely on static datasets and service address information. Putting the dataset and service address information in a registry and allowing it to be discovered at runtime allows that information to be subject to centralized governance. This makes it quite straightforward to change the address of a service should the need arise (fault-tolerant scenarios, end-of-life scenarios, etc.).

The concept of the SAS for a given weather product is central to the Cube concept and requires that datasets are classified as being in the SAS domain or not. Datasets that comprise the SAS will periodically change, and may ultimately be automatically changed in real time based on algorithms that will evaluate the relative “goodness” of various datasets. In view of this, runtime discovery is a requirement of the Cube.

2.4.5 Cross-Organizational TopologyAlthough the main focus of this document is the Cube from the perspective of the FAA, it is important to briefly note the multi-organizational structure of the Cube and describe some of the implementation details. Figure 1222 is a high-level depiction of the Cross-Organizational Topology.

Figure 12: Cross-Organizational Topology

At the top of the figure, NOAA and FAA Weather Data Servers, equipped with data management registries, are federating their registry information across enterprise boundaries to keep dataset metadata, domain information, and service provider information up-to-date. Those Origin Servers could also potentially be ingesting weather data from provider business services and making those data available as the Cube.

22 The figure does not intend to assert that the only sources of data available within NOAA are the Supercomputers

Page 22


Version 2.0

In addition, NOAA is acting in the role of the primary data provider while the FAA is acting as a distributor of weather data within the NAS and as a secondary data provider. Through the use of the hub and spoke model and store and forward techniques, the Cube is operating as a content-delivery network distributing its datasets efficiently and timely even across multiple enterprises to distant users of weather information.

The vertical dotted line denotes the enterprise boundary. In addition, the firewall is representative of the gateways that will be traversed in order to create the virtually unified, single-source 4-D Wx Data Cube.

Page 23


Version 2.0

3 NNEW Collaborative Efforts

3.1 OverviewThe FAA’s NNEW Program has interactions with programs and organizations internal and external to the FAA as part of its effort to further the goal of ensuring a successful development and implementation of the Cube. These collaborative efforts stretch from JPDO NextGen and NOAA to complimentary programs, such as SWIM and AIM, within the FAA.

3.1 JPDOSeveral of the NNEW Program staff and associated developers are working in conjunction with the JPDO to ensure that appropriate coordination is occurring. The NNEW Program is represented on or interfaces with the following JPDO groups:

JPDO/Weather Working Group/IOC Planning Team, including its two sub-teams, the Information Technology Enterprise Services Team (ITEST) and Environmental Information Team (EI Team)

JPDO NetCentric Task Force JPDO Wx Demonstration Team JPDO/Weather Working Group/Policy Team

Under the auspices of the JPDO as represented by the above groups, the NNEW Program works in partnership with NOAA and DoD to plan the development of the Cube. NOAA is essential to the development and population of the Cube since they will be the primary source of weather data for the Cube and at some time in the future will own the responsibility for running the Cube for the U.S. Government.

3.2 FAAWithin the FAA, the NNEW Program is collaborating with two key programs that will help to ensure the success of the Cube. The SWIM Program, which will provide the underlying SOA infrastructure, and the Aeronautical Information Management (AIM) Program, which is focused on developing a flexible data model for collecting, validating, storing, maintaining, and disseminating aeronautical data concerning the United States and its territories.

3.2.1 SWIMThe NNEW Program is currently engaged in technical and program coordination with the SWIM Program. The primary reasons for NNEW to engage SWIM are to coordinate technology adoption, to coordinate and reconcile IT requirements and potential allocation to SWIM infrastructure in the Segment 2 time frame, and to obtain SWIM technical guidance when necessary. Below are outlined some of the details on the current collaborative efforts:

Page 24


Version 2.0

Schedule gap analysis (combined effort) and proper programmatic changes Requirements analysis to identify requirements overlap Collaboration on NNEW and SWIM SOA approaches and issues Collaboration on NNEW and SWIM registry approaches All development efforts as they apply to IT concerns NNEW participation in SWIM SE Team Governance and Information

Management activities NNEW participation in other SWIM working groups and activities where

SWIM Implementing Programs (SIP) are being collectively engaged including the Architecture Working Group (AWG) and the COTS Working Group (COTSWG).

Access to SWIM resources such as KSN sites, the SWIM Wiki, and other resources.

Additionally, the NNEW Program is currently participating in the following SWIM working groups and meeting:

SWIM/NNEW Technical Interchange Meeting (TIM) SWIM SIP TIM SWIM AWG SWIM COTSWG

3.2.2 AIMThe NNEW Program is collaboratively working with AIM on a number of different fronts including participating in OGC Testbeds and offering NNEW’s Registry for use in publishing AIM data.

The OGC Web Services, Phase 6 Testbed (OWS-6) is part of OGC's Interoperability Program, a collaborative program designed to test OGC specifications, where they are formalized for public release. The OGC international team of providers is working together to solve specific geo-processing-interoperability problems posed by sponsoring organizations. OGC initiatives include testbeds and other efforts that are designed to encourage testing, validation, and adoption of OGC standards.

Current working groups and meetings: AIM/Flight Services/NNEW TIM

3.3 International Organizations

3.3.1 OGCThe NNEW Program is adopting many of the OGC standards as being the most appropriate basis for weather data dissemination. The OGC standards are broadly used across many domains and form a good baseline for domain-agnostic data interchange. This cross-domain capability is especially useful given that weather data will be

Page 25


Version 2.0integrated with aeronautical, topographical, and other geospatial information for use in decision making.

NNEW continues to work to extend, enhance, and incorporate OGC standards into the developmental efforts of the program. By developing weather-specific extensions to the OGC standards, a large degree of commonality is preserved while enabling weather capabilities in the 4-D Weather Data Cube. The NNEW program is involved with multiple groups that are adopting and/or using OGC standards as guidance. These groups include: the OGC OWS-6 Testbed, AIM, and Eurocontrol.

3.3.2 EurocontrolWeather-specific standards are necessary for exchanging weather data. These include standards concerning the protocol by which data are exchanged (i.e., the weather service standards) as well as those that describe the way in which data contents are exchanged. The FAA and Eurocontrol are now on a path to alignment with respect to both Aeronautical (the AIXM standard) and Weather information (the emerging WXXM standard). The efforts in both areas utilize a common, underlying ISO/OGC framework.

Participants in the new joint effort on the WXXM standard include: NNEW, NWS, the Air Force Weather Agency, U.S Navy, and Eurocontrol. The group began with version 1.0 of WXXM, produced by Eurocontrol in the fall of 2008. The FAA is the lead for insertion of additional capabilities and features of interest to the U.S., and is working on WXXM 1.1 for release in spring, 2009. Subsequent versions will be jointly developed in a working group in a similar fashion to current AIXM development.

Page 26


Version 2.0

Appendix A: SWIM StandardsThe proposed SWIM Technical Architecture Framework is shown in Figure 13. The standards indicated with shading in the figure are considered ready for implementation in Segment 1. The other standards may be implemented in SWIM in Segment 1, or may be implemented in subsequent segments, depending on their maturity and commercial acceptance.23

Figure 13: SWIM Standards

23 SWIM Technical Overview, Version 2.1, redacted, March 28, 2008, FAA – SWIM Program

Page 27


Version 2.0

Appendix B: Weather Specific Standards

World Wide Web Consortium (W3C) Extensible Markup Language (XML)

XML is a general-purpose specification for creating custom markup languages. It is classified as an extensible language because it allows its users to define their own elements. Its primary purpose is to facilitate the sharing of structured data across different information systems, particularly via the Internet, and it is used both to encode documents and to serialize data.24

XML Schema An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntax constraints imposed by XML itself. An XML schema provides a view of the document type at a relatively high level of abstraction.25

Efficient XML Interchange (EXI) EXI is a very compact representation for the Extensible Markup Language (XML) Information Set that is intended to simultaneously optimize performance and the utilization of computational resources. The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of data types, it reliably produces efficient encodings of XML event streams.26

SOAP SOAP is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built.27

Web Ontology Language (OWL) The OWL Web Ontology Language is designed for use by applications that need to process the content of information instead of just presenting information to humans. OWL facilitates greater machine interpretability of Web content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing additional vocabulary along with a formal semantics.28

24 http://en.wikipedia.org/wiki/XML - 05/01/200825 http://en.wikipedia.org/wiki/XML_Schema - 05/01/200826 http://www.w3.org/TR/2008/WD-exi-20080919/ - 03/25/200927 http://en.wikipedia.org/wiki/SOAP - 05/01/200828 http://www.w3.org/TR/owl-features/ - 03/25/2009

Page 28

http://www.w3.org/TR/owl-features/

http://en.wikipedia.org/wiki/Web_services_protocol_stack

http://en.wikipedia.org/wiki/Web_services_protocol_stack

http://en.wikipedia.org/wiki/HTTPS

http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol

http://en.wikipedia.org/wiki/Computer_network

http://en.wikipedia.org/wiki/XML

http://en.wikipedia.org/wiki/Protocol_(computing)

http://en.wikipedia.org/wiki/SOAP

http://www.w3.org/TR/2008/WD-exi-20080919/


http://en.wikipedia.org/wiki/XML_Schema

http://en.wikipedia.org/wiki/Serialization

http://en.wikipedia.org/wiki/Internet

http://en.wikipedia.org/wiki/Extensible_language

http://en.wikipedia.org/wiki/Markup_language



Version 2.0Resource Description Framework (RDF)The Resource Description Framework (RDF) is a directed, labeled graph data format for representing information in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, copyright and licensing information about a Web document, or the availability schedule for some shared resource. However, by generalizing the concept of a "Web resource", RDF can also be used to represent information about things that can be identified on the Web, even when they cannot be directly retrieved on the Web. Examples include information about items available from on-line shopping facilities (e.g., information about specifications, prices, and availability), or the description of a Web user's preferences for information delivery.29

SPARQL Protocol and RDF Query Language (SPARQL) SPARQL is query language for RDF. SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports extensible value testing and constraining queries by source RDF graph. The results of SPARQL queries can be results sets or RDF graphs.30

Organization for the Advancement of Structured Information Standards (OASIS)

ebXML Registry The ebXML Registry provides a set of services that enable sharing of information between interested parties for the purpose of enabling business process integration between such parties based on the ebXML specifications.

ebXML Registry Services (ebRS) The ebXML Registry Service is comprised of a robust set of interfaces designed to fundamentally manage the objects and inquiries associated with the ebXML Registry.

ebXML Registry Information Model (ebRIM) The Registry Information Model provides a blueprint or high-level schema for theebXML Registry. Its primary value is for implementers of ebXML Registries. It provides these implementers with information on the type of metadata that is stored in the Registry as well as the relationships among metadata Classes.

International Standards Organization (ISO)ISO is an international standards body that is made up of public and private organizations working to develop a common set of international standards. ISO

29 http://www.w3.org/RDF/ - 03/25/200930 http://www.w3.org/TR/rdf-sparql-query/ - 03/25/2009

Page 29


Version 2.0Technical Committee 211 (TC/211) is concerned with the generation and maintenance of geospatial data standards. These standards are foundational in nature - one typically uses them as building blocks for higher-level standards. The OGC, for example, refers to many of these standards in their service specifications. The names of the standards most relevant to NNEW are provided below.

ISO 19101.2002 Geographic Information - Reference Model ISO 19103.2005 Geographic Information - Conceptual Schema Language ISO 19107.2003 Geographic Information - Spatial Schema ISO 19108.2002 Geographic Information - Temporal Schema ISO 19108.2006 Geographic Information - Temporal Schema - Corrigendum 1 ISO 19109.2005 Geographic Information - Rules for Application Schema ISO 19110.2005 Geographic Information - Methodology for Feature Cataloging ISO 19111.2007 Geographic Information - Spatial Referencing by Coordinates ISO 19115.2003 Geographic Information - Metadata ISO 19115.2006 Geographic Information - Metadata - Corrigendum 1 ISO 19118.2005 Geographic Information - Encoding ISO 19119.2005 Geographic Information - Services ISO 19121.2000 Geographic Information - Imagery and gridded data ISO 19123.2005 Geographic Information - Schema for coverage geometry and

functions ISO 19127.2005 Geographic Information - Geodetic codes and Parameters ISO 19136 Geography Markup Language (GML) ISO 19139.2007 Geographic Information - Metadata - XML Schema

Implementation ISO 8601.2004 Data Elements and Interchange Format – Representation of

Dates and Times

Open Geospatial Consortium (OGC) OGC Web Service Common

The OpenGIS® Web Services Common (WS-Common) Interface Standard specifies parameters and data structures that are common to all OGC Web Service (OWS) Standards. The standard normalizes the ways in which operation requests and responses handle such elements as bounding boxes, exception processing, URL requests, URN expressions, and key value encoding. Among its uses, this document serves as a normative reference for other OGC Web Service standards, including the OpenGIS Web Map Service (WMS), Web Feature Service (WFS), and Web Coverage Service (WCS) standards. Rather than continuing to repeat this material in each such standard, each standard will normatively reference parts of this document.

Page 30


Version 2.0 OpenGIS Web Coverage Service (WCS)

The WCS Implementation Specification supports electronic retrieval of digital geospatial information representing space-varying phenomena. The information returned is often referred to as gridded data.

A WCS provides access to potentially detailed and rich sets of geospatial information, in forms that are useful for client-side rendering, multi-valued coverages, and input into scientific models and other clients. The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); as it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria.

OpenGIS Web Feature Service (WFS) The WFS Implementation Specification allows a client to retrieve and update geospatial data encoded in Geography Markup Language (GML) from multiple Web Feature Services. The specification defines interfaces for data access and manipulation operations on geographic features, using HTTP as the distributed computing platform. Via these interfaces, a Web user or service can combine, use and manage geodata -- the feature information behind a map image -- from different sources.

OpenGIS Catalogue Services Specification The Catalogue Services Specification specifies the interfaces, bindings, and a framework for defining application profiles required to publish and access digital catalogues of metadata for geospatial data, services, and related resource information.

OpenGIS Sensor Model Language (SensorML) The SensorML Implementation Specification provides the general models and XML encodings for sensors and observation processing. SensorML is useful for describing sensors such as radars, surface observation stations, satellites, and other sensors and is a leading candidate for use with the 4-D Wx Data Cube. Information from the common descriptions will be stored in a registry (or catalog), allowing searches based on sensor capabilities, location, and other attributes.

Joint METOC Broker Language (JMBL)JMBL is a specification, developed by DoD, for a standard language (XML) that brokers the exchange of information between meteorological and oceanographic (METOC) data providers and user applications. JMBL allows for a standardized interface to access METOC data for users and their applications. The way this information is exchanged is with a Web service.

Federal Geographic Data Committee (FGDC)The FGDC is an interagency committee that promotes the coordinated development, use, sharing, and dissemination of geospatial data on a national basis.

Page 31


Version 2.0

Content Standard for Digital Geospatial Metadata (CSDGM) The CSDGM, Vers. 2 (FGDC-STD-001-1998) is the US Federal Metadata standard. According to Executive Order 12096 all Federal agencies are ordered to use this standard to document geospatial data created as of January, 1995. The standard is often referred to as the FGDC Metadata Standard and has been implemented beyond the federal level with State and local governments adopting the metadata standard as well. The objectives of the standard are to provide a common set of terminology and definitions for the documentation of digital geospatial data. The standard establishes the names of data elements and compound elements (groups of data elements) to be used for these purposes, the definitions of these compound elements and data elements, and information about the values that are to be provided for the data elements.

World Meteorological Organization (WMO) GRIB

GRIB (GRIdded Binary) is a mathematically concise data format commonly used in meteorology to store historical and forecast weather data. It is standardized by the WMO’s Commission for Basic Systems, known under number GRIB FM 92-IX, described in WMO Manual on Codes No.306.

BUFR The Binary Universal Form for the Representation of meteorological data (BUFR) is a binary data format maintained by the WMO. The latest version is BUFR Edition 4. BUFR Edition 3 is also considered current for operational use.

Unidata NetCDF

NetCDF (network Common Data Form) is a set of software libraries and machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data.

British Atmospheric Data Centre Climate Science Modeling Language (CSML)

CSML is a standards-based data model and GML (Geography Markup Language) application schema for atmospheric and oceanographic data with associated software tools developed at the Rutherford Appleton Laboratory.

Eurocontrol/FAA WXXM/WXCM

The WXXM is part of a family of platform (technology) independent, harmonized and interoperable information exchange models designed to cover the information needs of ATM. This first release WXXM is a proof of concept for the exchange of a limited set of

Page 32

http://www.fgdc.gov/standards/projects/FGDC-standards-projects/metadata/base-metadata/index_html


Version 2.0ICAO Annex 3 type of products. During the second half of 2007, the scope of weather information exchange was broadened and the first draft release of the overarching Weather Exchange Conceptual Model (WXCM) was build.

The WXCM is developed in close cooperation with all the stakeholders. For that purpose, a working group is set up which has a concise number of experts representing ATM users, MET providers, other ANS providers and Industry. Arrangements are made to guarantee efficient coordination with WMO, International Civil Aviation Organization (ICAO) b and the FAA on harmonizing efforts performed within the MET data exchange domain.

Page 33


Version 2.0

Appendix C: Acronyms ATM ....................................Air Traffic ManagementATO .....................................Air Traffic OperationsCOTS ...................................Commercial Off The ShelfCP .......................................Cube ParticipantCSA .....................................Cube Service AdaptorCSDGM ...............................Content Standard for Digital Geospatial MetadataCSML ...................................Climate Science Modeling LanguageCube ...................................4-Dimensional Weather Data CubeDoD .....................................Department of DefenseEA .......................................Enterprise ArchitectureEI .........................................Environmental InfrastructureEXI .......................................Efficient XML InterchangeFAA .....................................Federal Aviation AdministrationFGDC ...................................Federal Geographic Data CommitteeFTI .......................................FAA Telecommunications InfrastructureHTTP ...................................Hypertext Transfer ProtocolIA ........................................Investment AnalysisICAO ....................................International Civil Aviation OrganizationIOC ......................................Initial Operating CapabilityIP .........................................Internet ProtocolIT .........................................Information TechnologyITEST ...................................IT Enterprise Service TeamISO ......................................International Standards OrganizationMETI ...................................Multi-Enterprise Telecommunications InfrastructureJMBL ...................................Joint METOC Broker LanguageJPDO ...................................Joint Planning and Development OfficeMETAR ................................Aviation Routine Weather ReportNAS .....................................National Airspace SystemNextGen …………………...........Next Generation Air Transportation SystemNNEW .................................NextGen Network Enabled WeatherNOAA ..................................National Oceanic and Atmospheric AdministrationNWE ....................................NextGen Weather EnterpriseOGC ....................................Open Geospatial ConsortiumOWS ....................................OGC Web ServicePIREP ...................................Pilot ReportQoS .....................................Quality of ServiceRDF .....................................Resource Description FrameworkReg/rep ...............................Registry/RepositorySAS ......................................Single Authoritative SourceSLA ......................................Service Level AgreementSMF .....................................System Management FunctionSOA .....................................Service-Oriented ArchitectureSOAP ...................................Simple Object Access ProtocolSPARQL ...............................SPARQL Protocol and RDF Query LanguageSWIM ..................................System Wide Information Management

Page 34


Version 2.0TAF ......................................Terminal Aerodrome ForecastTIM .....................................Technical Interchange MeetingUML ....................................Unified Modeling LanguageWCS ....................................Web Coverage ServiceWFS ....................................Web Feature ServiceWG ......................................Working GroupWMO ..................................World Meteorological OrganizationWx ......................................WeatherXML ....................................Extensible Markup Language

Page 35

Documents

NNEW White Paper v2