Docstoc

The 4-D Weather Data Cube and Re

Document Sample
The 4-D Weather Data Cube and Re Powered By Docstoc
					              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 ........................................................................................................................................ 1
    1.2          DOCUMENT SCOPE ........................................................................................................................... 1
    1.3          BACKGROUND.................................................................................................................................. 1
    1.4          VIRTUAL DATA CUBE CONCEPT ........................................................................................................... 2
       1.4.1        Cube Domains ......................................................................................................................... 2
       1.4.2        Data Access ............................................................................................................................. 3
2       4-D WX DATA CUBE ARCHITECTURE ................................................................................................ 5
    2.1      NEXTGEN EA .................................................................................................................................. 5
    2.2      NAS EA ......................................................................................................................................... 7
    2.3      FAA CUBE ARCHITECTURE ................................................................................................................. 7
       2.3.1   Architectural Framework ........................................................................................................ 7
       2.3.2   METI Layer .............................................................................................................................. 8
            2.3.2.1           What is Telecommunications Infrastructure? .............................................................................. 8
            2.3.2.2           FAA Telecommunications Infrastructure (FTI) ............................................................................. 9
            2.3.2.3           The Cube and METI .................................................................................................................... 10
        2.3.3        Core Services Layer ............................................................................................................... 10
            2.3.3.1           What is SOA? .............................................................................................................................. 10
            2.3.3.2           The SWIM Program/System (SWIM) .......................................................................................... 11
            2.3.3.3           The Cube and SWIM ................................................................................................................... 13
            2.3.3.4           The Cube and SOA...................................................................................................................... 15
        2.3.4        Weather Services Layer......................................................................................................... 15
        2.3.5        Application Layer .................................................................................................................. 15
            2.3.5.1           Providers .................................................................................................................................... 16
            2.3.5.2           Consumers ................................................................................................................................. 17
            2.3.5.3           Users .......................................................................................................................................... 17
    2.4      LOW-LEVEL ARCHITECTURAL IMPLEMENTATION DETAILS ........................................................................ 17
       2.4.1   Implementation Model ......................................................................................................... 18
       2.4.2   Origin Server ......................................................................................................................... 19
       2.4.3   Distribution Server ................................................................................................................ 20
       2.4.4   Registry/Repository .............................................................................................................. 21
       2.4.5   Cross-Organizational Topology ............................................................................................. 22
3       NNEW COLLABORATIVE EFFORTS ................................................................................................. 24
    3.1          OVERVIEW .................................................................................................................................... 24
    3.1          JPDO .......................................................................................................................................... 24
    3.2          FAA ............................................................................................................................................ 24
       3.2.1        SWIM .................................................................................................................................... 24
       3.2.2        AIM ....................................................................................................................................... 25
    3.3          INTERNATIONAL ORGANIZATIONS ...................................................................................................... 25
       3.3.1        OGC ....................................................................................................................................... 25
       3.3.2        Eurocontrol ........................................................................................................................... 26
APPENDIX A: SWIM STANDARDS ........................................................................................................... 27
APPENDIX B: WEATHER SPECIFIC STANDARDS ....................................................................................... 28
APPENDIX C: ACRONYMS ....................................................................................................................... 34
                                           White Paper
                         4-D Weather Data Cube and Related Infrastructure
                                           Version 2.0
                                    TABLE OF FIGURES
Figure 1: Domains of the 4-D Wx Data Cube _________________________________________________ 2
Figure 2: Conceptual View of the 4-D Wx Data Cube___________________________________________ 4
Figure 3: The Cube’s NAS Architectural Hierarchy _____________________________________________ 5
Figure 4: NextGen Weather Enterprise _____________________________________________________ 6
Figure 5: The Multi-Tiered Framework ______________________________________________________ 8
Figure 6: Multiple Enterprise Networks Forming the METI Layer _________________________________ 9
Figure 7: SWIM - NNEW Responsibilities at 4-D Wx Data Cube IOC ______________________________ 14
Figure 8: High-Level UML diagram of the Cube’s Boundaries ___________________________________ 16
Figure 9: Hub and Spoke/Store and Forward as Applied to the Cube _____________________________ 19
Figure 10: A Cube Node as an Origin Server_________________________________________________ 20
Figure 11: A Distribution Server with a Many-to-One Relationship ______________________________ 21
Figure 12: Cross-Organizational Topology __________________________________________________ 22
Figure 13: SWIM Standards _____________________________________________________________ 27
                                              White Paper
                            4-D Weather Data Cube and Related Infrastructure
                                              Version 2.0

    1 Introduction
      1.1 Purpose
The 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 Scope
This 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 Background
The 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, 2006
2
    NextGen Weather Policy Findings and Recommendations, Version 0.1, October 31, 2007


                                                                                         Page 1
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         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 Concept
The 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 Domains
Since 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
                                           White Paper
                         4-D Weather Data Cube and Related Infrastructure
                                           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 Access
The 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

3
  Aviation Routine Weather Report
4
  Terminal Aerodrome Forecast
5
  Pilot Report


                                                                                     Page 3
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         Version 2.0
from any grid point, or likely more often from multiple grid points, relevant and
available data for 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
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         Version 2.0


 2 4-D Wx Data Cube Architecture
Architecture 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 EA
The 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
                                              White Paper
                            4-D Weather Data Cube and Related Infrastructure
                                              Version 2.0
Figure 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.2
7
  More information on JPDO working groups can be found in section 3.1


                                                                                                     Page 6
                                            White Paper
                          4-D Weather Data Cube and Related Infrastructure
                                            Version 2.0
     2.2 NAS EA
A 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 Architecture
Much 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 Framework
The 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
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         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 Layer
At 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
                                               White Paper
                             4-D Weather Data Cube and Related Infrastructure
                                               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
                                               White Paper
                             4-D Weather Data Cube and Related Infrastructure
                                               Version 2.0
environment11 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 METI
The 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 Layer
The 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



11
     Runtime SOA environment need and definition are discussed in section 2.3.4.2.


                                                                                     Page 10
                                           White Paper
                         4-D Weather Data Cube and Related Infrastructure
                                           Version 2.0
through the use of open standards (HTTP, XML, REST, SOAP, etc).12 With a SOA, a
business 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.



12
   See Appendix B, World Wide Web Consortium (W3C) standards, for more information on these
standards.
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
                                           White Paper
                         4-D Weather Data Cube and Related Infrastructure
                                           Version 2.0
        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
        other 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.




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
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         Version 2.0
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.

The 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 SWIM
The 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
                                                                           White Paper
                                                         4-D Weather Data Cube and Related Infrastructure
                                                                           Version 2.0
                                                 Figure 7: SWIM - NNEW Responsibilities at 4-D Wx Data Cube IOC




                                                                                                                                                                                                            CP Implemented/Deployed
                                                                                                                                                                                     Implemented/Deployed
                                                                                                                       Implemented/Deployed

                                                                                                                                              SMF/NNEW Provided

                                                                                                                                                                  SMF/NNEW Defined
                                                                                        SWIM Provided

                                                                                                        SWIM Defined




                                                                                                                                                                                     SMF/NNEW
                                                                                                                       SWIM
                                              SWIM UDDI Service Registry Software
                Interface
                  Mgmt




                                              Cube ebXML Data Management
                                              Registry Software
CORE SERVICES




                                              Dataset Registry Metadata

                                              SWIM Enterprise Governance/Policy
                  ESM




                                              Cube Governance/Policy
                  Security




                                              Core Services Security Standards

                                              Cube Security Standards
                  Message




                                              Core Service Messaging Standards

                                              Cube Messaging Standards
                Standards




                                              Weather Services Standards
                 Weather




                                              Weather Data Format Standards

                                              SWIM Segment 1 Weather Services

                                              Non-SWIM Weather Services
                  Infrastructure & Services
Other




                                              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




                                                                                                                                                                                                    Page 14
                                        White Paper
                      4-D Weather Data Cube and Related Infrastructure
                                        Version 2.0
2.3.3.4 The Cube and SOA
While 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 Layer
The 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 Layer
At 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



                                                                                    Page 15
                                            White Paper
                          4-D Weather Data Cube and Related Infrastructure
                                            Version 2.0
well: provider CSAs and consumer CSAs. Unless otherwise stated “CSA” refers to
“provider CSA” in the discussion below.

2.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
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         Version 2.0

2.3.5.2 Consumers
Consumers 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 Users
Users 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 Details
The 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
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         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 Model
The 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
                                           White Paper
                         4-D Weather Data Cube and Related Infrastructure
                                           Version 2.0
                Figure 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 Server
The 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
                                            White Paper
                          4-D Weather Data Cube and Related Infrastructure
                                            Version 2.0
The 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 Server
Like 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


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


                                                                                    Page 20
                                            White Paper
                          4-D Weather Data Cube and Related Infrastructure
                                            Version 2.0
same relative structure and components, the Distribution Server is simply an Origin
Server 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/Repository
The 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.



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
                                             White Paper
                           4-D Weather Data Cube and Related Infrastructure
                                             Version 2.0
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.
Legacy 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 Topology
Although 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

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


                                                                                                 Page 22
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         Version 2.0
weather data from provider business services and making those data available as the
Cube.

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
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         Version 2.0


 3 NNEW Collaborative Efforts
   3.1 Overview
The 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 JPDO
Several 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 FAA
Within 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 SWIM
The 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
                                        White Paper
                      4-D Weather Data Cube and Related Infrastructure
                                        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 AIM
The 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 OGC
The 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
                                        White Paper
                      4-D Weather Data Cube and Related Infrastructure
                                        Version 2.0
integrated 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 Eurocontrol
Weather-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
                                              White Paper
                            4-D Weather Data Cube and Related Infrastructure
                                              Version 2.0

Appendix A: SWIM Standards
The 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
                                          White Paper
                        4-D Weather Data Cube and Related Infrastructure
                                          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/2008
25
   http://en.wikipedia.org/wiki/XML_Schema - 05/01/2008
26
   http://www.w3.org/TR/2008/WD-exi-20080919/ - 03/25/2009
27
   http://en.wikipedia.org/wiki/SOAP - 05/01/2008
28
   http://www.w3.org/TR/owl-features/ - 03/25/2009


                                                                                   Page 28
                                              White Paper
                            4-D Weather Data Cube and Related Infrastructure
                                              Version 2.0
Resource 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 the
ebXML 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/2009
30
     http://www.w3.org/TR/rdf-sparql-query/ - 03/25/2009


                                                                                   Page 29
                                        White Paper
                      4-D Weather Data Cube and Related Infrastructure
                                        Version 2.0
Technical 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
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         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
                                        White Paper
                      4-D Weather Data Cube and Related Infrastructure
                                        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
                                        White Paper
                      4-D Weather Data Cube and Related Infrastructure
                                        Version 2.0
ICAO 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
                                           White Paper
                         4-D Weather Data Cube and Related Infrastructure
                                           Version 2.0


Appendix C: Acronyms
  ATM .................................... Air Traffic Management
  ATO ..................................... Air Traffic Operations
  COTS ................................... Commercial Off The Shelf
  CP ....................................... Cube Participant
  CSA ..................................... Cube Service Adaptor
  CSDGM ............................... Content Standard for Digital Geospatial Metadata
  CSML .................................. Climate Science Modeling Language
  Cube ................................... 4-Dimensional Weather Data Cube
  DoD .................................... Department of Defense
  EA ....................................... Enterprise Architecture
  EI ......................................... Environmental Infrastructure
  EXI ...................................... Efficient XML Interchange
  FAA ..................................... Federal Aviation Administration
  FGDC ................................... Federal Geographic Data Committee
  FTI ....................................... FAA Telecommunications Infrastructure
  HTTP ................................... Hypertext Transfer Protocol
  IA ........................................ Investment Analysis
  ICAO ................................... International Civil Aviation Organization
  IOC ...................................... Initial Operating Capability
  IP ........................................ Internet Protocol
  IT ......................................... Information Technology
  ITEST ................................... IT Enterprise Service Team
  ISO ...................................... International Standards Organization
  METI ................................... Multi-Enterprise Telecommunications Infrastructure
  JMBL ................................... Joint METOC Broker Language
  JPDO ................................... Joint Planning and Development Office
  METAR ................................ Aviation Routine Weather Report
  NAS ..................................... National Airspace System
  NextGen ………………… .......... Next Generation Air Transportation System
  NNEW ................................. NextGen Network Enabled Weather
  NOAA .................................. National Oceanic and Atmospheric Administration
  NWE ................................... NextGen Weather Enterprise
  OGC .................................... Open Geospatial Consortium
  OWS ................................... OGC Web Service
  PIREP .................................. Pilot Report
  QoS ..................................... Quality of Service
  RDF ..................................... Resource Description Framework
  Reg/rep .............................. Registry/Repository
  SAS ...................................... Single Authoritative Source
  SLA ...................................... Service Level Agreement
  SMF .................................... System Management Function
  SOA ..................................... Service-Oriented Architecture
  SOAP ................................... Simple Object Access Protocol
  SPARQL ............................... SPARQL Protocol and RDF Query Language
  SWIM .................................. System Wide Information Management



                                                                                                Page 34
                                         White Paper
                       4-D Weather Data Cube and Related Infrastructure
                                         Version 2.0
TAF ..................................... Terminal Aerodrome Forecast
TIM ..................................... Technical Interchange Meeting
UML .................................... Unified Modeling Language
WCS .................................... Web Coverage Service
WFS ................................... Web Feature Service
WG ..................................... Working Group
WMO .................................. World Meteorological Organization
Wx ...................................... Weather
XML ................................... Extensible Markup Language




                                                                           Page 35

				
DOCUMENT INFO