1. Projects, Lessons Learned and Questions for the Future
FAA Efforts in AIXM
Projects, Lessons Learned and Questions for the Future
AIXM Developer’s Seminar
Navin Vembar
Prakash Mangalathan
10/26/2009

2. Overview Projects using AIXM Lessons Learned Questions for the Future
Airports GIS
Digital NOTAMs
SWIM
SAA and CSE
CSSD
Lessons Learned
Questions for the Future

3. Airports GIS FAA’s system of record on airport survey data
Down to the paint on the runways
Geospatial definitions of the airport elements as well as high-resolution raster imagery
Exposed through WMS and WFS
Moving to AIXM
Gap analysis being conducted between the current data model and AICM
Will be exposing Airport data as AIXM over the SWIM network
The Airports GIS system will allow for digital definition of the airport layout descriptions from the source. It is intended to be a high-fidelity description of the airport layouts usable by any number of systems that would require the features described therein. A good example of this use would be within the context of Digital NOTAMs – a runway closure, it is envisioned, would reference the feature as defined in Airports GIS.
The SWIM network is described in a later slide.

4. Digital NOTAMs End-to-end digital definition of NOTAMs
Input through drop-downs
Visualization through website
Dissemination through web services
Exercising much of the AIXM model
Representing NOTAM activity across the FAA using TEMPDELTAs

5. Digital NOTAM Architecture

6. FAA’s SWIM
FAA’s System Wide Information Management is the agency-wide SOA
Governance
Technology Selection
Guidance
Enterprise Service Bus Selection
IONA FUSE ServiceMix
Productized Apache ServiceMix
Includes Apache CXF, ActiveMQ, Camel, Fuse HQ
The FAA’s SWIM initiative is in its first phase, Segment 1. In this phase, the initial steps have been taken. Governance has been constructed to define what it means to be “SWIM compliant” within the FAA. This includes defining a technology stack and WS-* interoperability standards that must be used (excepting waivers) by SWIM-compliant systems. These systems are meant to reside in the operational environment of the FAA, supproting ATC systems, so there is a focus on high-availability and highly performant systems.

7. Special Activity Airspace
One of the pilot components of the FAA’s System Wide Information Management (SWIM) program
SAAs are airspaces that can be turned on and off based on schedule, generally based on external factors
E.g., Special Use Airspace, Temporary Flight Restrictions, Altitude Reservations
As part of the SWIM effort, a number of problems were selected to be approached by the FAA to demonstrate the use of a SOA within the agency. Within the AIM Group, SAAs were selected.

8. Special Activity Airspace, cont’d
Project to define SUAs and Air Traffic Controlled Activity Airspace (ATCAAs) from end-to-end
Static definition
Using LuciadMap for editing
Schedule management
Status management

9. Sample SUA Data Cape Canaveral
R-2932 Cape Canaveral, FL Boundaries. Beginning at lat. 28°39'21"N., long. 80°42'39"W.; to lat. 28°41'41"N., long. 80°34'59"W.; thence 3 nautical miles from and parallel to the shoreline; to lat. 28°25'01"N., long. 80°30'29"W.; to lat. 28°25'01"N., long. 80°37'59"W.; to lat. 28°34'01"N., long. 80°39'29"W.; to the point of beginning,. Designated altitudes. Surface to but not including 5,000 feet MSL. Time of designation. Continuous. Controlling agency. FAA, Miami ARTCC. Using agency. Commander, 1st Range Operations Squadron, Cape Canaveral AFS, FL. AMENDMENTS 1/20/05 69 FR (Amended) Corr: 69 FR 70887

10. Common Scheduling Enterprise
Tied to the SAA project
Department of Defense to FAA schedule request
Using SAA network to define schedule requests
Moving AIXM outside of FAA

11. Common Status and Structure Data
Newly started effort
Taking disparate authoritative sources across many systems and providing an aggregated view through AIXM and OGC standards
Use Case: Pilot Briefing – describe all the features and NOTAMs that will affect a flight based on a filed flight plan
Exploration will include
Single authoritative source identification
UUID management across multiple systems
Creation of adapters to existing systems to AIXM 5.1
The Common Status and Structure Data initiative is a major step towards the realization of the common operating picture. We envision a scenario in which a pilot can receive a full collection of NOTAMs, airport layouts, procedures, and other information based on their flight plan prior to flight. The backend of the system will transparently aggregate data from different sources, adapting their internal representation of AI into AIXM 5.1 for dissemination to users.
In order to achieve this goal, we must not only identify the single authoritative sources, we must also manage the unique identifiers for the features as they are defined and changed, and support a notification architecture across these systems that will support the user subscriptions to the latest information is available to users at all times.

12. Lessons Learned Overcoming Complexity
Detailed Web Service Definition Descriptions or Interface Requirements Documents aids consumer and developer
Working with developmental complexity when constructing systems dealing with only a specific subset of AIXM (e.g., SAA)
AICM/AIXM simplifies data modeling by providing a largely complete model of aeronautical information
Understanding the core concepts of Features and their Temporality is key
Building blocks: features, objects, messages, timeslices
For consumers or producers of aeronautical information outside the FAA, there are sometimes issues with advertising AIXM as a language to developers on the other side the fence when they have a concern only about a small part of the schema. Additionally, when working with developers new to the environment, an extremely strong, content-relevant set of documents has proven helpful.
In the end, AIXM may require thinking about the problem itself differently than in the past. Rather than focusing on the domain-specific elements, it may be useful to consider the building blocks of AIXM as the core components of development of the model. Start with the concepts of features and their temporarily and constituent components generically, perhaps.

13. Lessons Learned Binding
Were unable to use common Java-SOAP binding solutions: JAX-WS & JAX-B
XMLBeans works
IONA had to develop a number of bug fixes
Settling on a best practice for moving from AIXM to the in-memory model
Seeing more and more commercial solutions becoming available
Very positive
When dealing with development of web services, binding to an in-memory model is often the method of approach. In order to do so, the common tools such as JAX-B and JAX-WS need to work “out of the box” with the AIXM schemas. We found some difficulty in this approach, including problems with the FAA SWIM-selected toolset internally that required bug fixes.
It would be helpful as AIXM 5.1 matures, to settle on best practices for drawing AIXM into memory. This may mean customized tooling, or simply supporting AIXM profiles (i.e., subsets of schemas) and ensuring that JAX-B and JAX-WS work with the schema as generated.

14. Lessons Learned XPath & XQuery promotes rapid development GeoTools
Take advantage of the XLink capabilities to treat the XML as a database
Avoids issues with binding
Allows for flexible addition of new use cases
Very important for Digital NOTAMs for example
GeoTools
Open Source APIs for geographic computations
Provides for intelligent interpretation of GML components of AIXM
The Digital NOTAMs project, rather than using binding, approached the use of AIXM through the use of native XML tools such as XPath and XQuery. This allowed for a deeply flexible environment that supports the future development of new use cases (e.g., new types of NOTAMs or new aspects of AIXM) without directly affecting the codebase of Digital NOTAMs itself.
Additionally, in order to add “intelligence” to the Digital NOTAMs use of AIXM, they employed GeoTools to support geographic manipulation of the XML database.

15. Lesson Learned
Focus on development should be on native XML processing not Java/.NET/etc
Use of tools such as XPath, XQuery, Schematron, XSLT, XForms is key for success in managing what appears to be a large schema from a binding perspective
Based on the Digital NOTAMs project, the use of native XML tools seems to provide a flexible development environment. However, in many scenarios – such as the inclusion of support of legacy systems – this is potentially less viable.

16. Questions for the Future
Proof of SWIM and AIXM compatibility
XML Gateway Compatibility
Software Capability
How to expose AIXM to other agencies?
As AIXM becomes pervasive in the FAA, events like this one will help us transition external consumers to using AIXM
Aggregation through a SOA
Draw together different data sources to single messages based on user need
Software solutions: DXSI? FME in pipeline?
Data Management
UUID Management
Traceability
Exposure using OGC Standards
WFS, WFS-T, Filter