Date: May 2012
Aeronautical Information Management
Modernization Segment 2
Preliminary Concept of Operations
Manager, Service Organization; Bob McMullen
Manager, Advanced Operational Concepts Division; John Marksteiner (ANG-C4)
Manager, NAS Requirements Services Division Kimberly Gill (ANG-B1)
Table of Contents
1. Introduction and Scope .................................................................................................. 1
1.1. Background ............................................................................................................. 2
1.2. Problem Statement .................................................................................................. 2
1.3. AIMMS2 Concept Overview ................................................................................... 2
2. Current Operations and Capabilities .............................................................................. 6
2.1. Description of Current Operations ........................................................................... 6
2.2. Current Supporting Infrastructure ............................................................................ 6
3. Justification and Description of Changes ....................................................................... 7
4. AIMM Segment 2 Concept of Operations ...................................................................... 9
4.1. Assumptions and Constraints ................................................................................... 9
4.2. General Operations, Functions, and Capabilities ...................................................... 9
4.2.1. Data Ingest Capability ...................................................................................... 9
4.2.2. Digital Data Entry and Capture Capability .......Error! Bookmark not defined.9
4.2.3. External Service Interface Capability ................................................................ 9
4.3. Data and Information Management ........................................................................ 10
4.3.1. Business Process Capability............................................................................ 10
4.3.2. Business Rules Capability .............................................................................. 10
4.3.3. Information Management Capability ............................................................... 11
4.3.4. Information Transformation Capability ........................................................... 11
4.3.5. Data Storage Capability .................................................................................. 11
4.3.6. Data Security Capability ................................................................................. 11
4.3.7. Data Discovery Capability .............................................................................. 11
4.4. Business Service Capabilities ................................................................................ 12
4.4.1. Airspace Conflict Resolution (Deconfliction) Capability ................................ 12
4.4.2. Post-Operational Metrics Capability ............................................................... 12
4.5. Data and Information Relay and Exchange Capability ........................................... 12
4.5.1. Complex Data Query Capability ..................................................................... 12
4.5.2. Data Notification Capability ........................................................................... 12
4.5.3. Data Mapping and Charting Capability ........................................................... 13
4.5.4. OSS Data and Information Exchange Capability ............................................. 13
Preliminary ConOps AIMM S2 May 2012 Page ii
4.6. Benefits to be Realized .......................................................................................... 13
5. Operational Scenarios .................................................................................................. 14
5.1. Military SUA Schedule Change ............................................................................. 14
6. Summary of Impacts .................................................................................................... 15
7. References ................................................................................................................... 16
7.1. FAA Documents .................................................................................................... 16
7.2. International Standards Documents ....................................................................... 17
8. Appendix 1: Stakeholders ............................................................................................ 19
9. Appendix 2: Integration and Dependencies .................................................................. 22
9.1. Integration ............................................................................................................. 22
9.1.1. Relationship to Current Systems ..................................................................... 22
9.2. Initial ACS Prototypes ........................................................................................... 27
9.2.1. SWIM SAA .................................................................................................... 28
9.2.2. SAA Operational Database Prototype ............................................................. 28
9.2.3. OGC Efforts ................................................................................................... 28
9.2.4. ACS Prototype ................................................................................................ 29
9.3. Anticipated Obstacles and Issues for AIMMS2 Development ................................ 29
9.3.1. Altitude Query with FES ................................................................................ 29
9.3.2. UUID Management ........................................................................................ 30
9.3.3. Consolidated vs. Federated Databases ............................................................. 30
9.3.4. Scheduling Database ....................................................................................... 31
10. Appendix 3: Architecture Framework ....................................................................... 32
10.1. Data & Information ............................................................................................ 32
10.1.1. Data/Information Types ............................................................................... 32
10.1.2. Data & Information Storage ........................................................................ 41
10.2. Common Services .............................................................................................. 45
10.2.1. Data Collection Services ............................................................................. 45
10.2.2. Data Management Services ......................................................................... 46
10.2.3. Information Exchange Service ..................................................................... 50
10.2.4. Geodetic Calculation Service ...................................................................... 52
10.3. Business Services ............................................................................................... 53
10.3.1. BPS ............................................................................................................. 53
10.3.2. BRS ............................................................................................................ 55
Preliminary ConOps AIMM S2 May 2012 Page iii
10.4. Applications ....................................................................................................... 57
10.4.1. OSS............................................................................................................. 58
10.4.2. Analyst UI................................................................................................... 61
10.4.3. System Administration UI ........................................................................... 61
10.4.4. Digital Data Capture Tools .......................................................................... 62
10.5. Infrastructure ..................................................................................................... 63
10.5.1. FAA Network Infrastructure ........................................................................ 63
10.5.2. SWIM ......................................................................................................... 63
Preliminary ConOps AIMM S2 May 2012 Page iv
List of Figures
Figure 1: AIMMS2 internal functions and interfaces to external systems............................... 4
Figure 2: A Conceptual Architecture of the ACS within AIMM ............................................. 7
Preliminary ConOps AIMM S2 May 2012 Page v
1. Introduction and Scope
This document describes a Concept of Operations (Conops) for the Aeronautical Information
Management Modernization Segment 2 (AIMMS2) effort. It describes the capabilities, functions,
and some brief examples of use for the new AIMM services. In addition, this document identifies
the functional aspects that will provide the required capabilities to users.
AIMMS2 will provide Aeronautical Common Services (ACS) as the single trusted access point
of Aeronautical Information (AI). This segment will include Special Activity Airspace (SAA)
and airport configuration data. AIMM S2 will also expand the distribution of Notices to Airmen
(NOTAMS) included as part of the Federal NOTAM System (FNS).
AIMM S2 is a Next Generation Air Transportation System (NextGen) enabler supporting
Operational Improvements (OIs) for Improved Management of Airspace for Special Use [OI
108212) and On-Demand NAS Information [OI 103305], as well as additional SAA OIs, in the
bravo timeframe. AIMM S2 also supports RTCA, Task Force 5 Operational Capability 35 by
delivering digital Special Activity Airspace (SAA) information to all NAS users.
This ConOps describes AIMMS2 from a user viewpoint and a technical standpoint. From a user
viewpoint, it describes how users will interact with the system for data entry, request
interrogation, display of information, and system management. From a technical standpoint, it
describes the systems and services that comprise AIMM S2, the transformation of disparate data
into uniformly formatted information, and the data and service standards that govern the system.
The scope of AIMM S2 includes the following:
Digital Data Ingest: The development of digital data input capability is essential to
AIMM. This includes the exchange of data with authoritative providers using automated
tools and systems. This Conops describes sources of data and describes the tools that will
be used to capture that data. This Conops describes the types of data to be captured and
issues related to connectivity and data formats.
Aeronautical Common Services (ACS): The ACS system will manage AI data capture.
It will then transform, validate (for integrated products), verify, store, and distribute the
resultant AI to users and systems through AIM enterprise web services. The ACS has
four main functional capabilities: (1) business rules/services, (2) data capture, (3) data
exchange, and (4) data and information management.
System Integration and Data Exchange: The new AIMM system will establish
functional two-way data exchange using Service-Oriented Architecture (SOA) principles.
AIMM S2 will establish and develop a link to provide data to National Airspace System
(NAS) consumer systems and users through the System Wide Information Management
External Web Internet Portal: The new AIMM system will establish an interface for
users outside of FAA NAS systems to relay AI via the public Internet. This web portal
will become an Operational Support System (OSS) for external aviation operations
personnel to obtain needed AI. It will also work with systems from within the NAS.
Preliminary ConOps AIMM S2 May 2012 Page 1
As air traffic increases over the next 20 years, the Federal Aviation Administration (FAA) needs
to modernize its automation and information systems to meet its mission. The AIMM program
will develop systems and services to address future air traffic requirements. AIMM consist of
segments 1 and 2 as well as future Work Packages (WPs). AIMM Segment 1 (AIMMS1) is
currently in process and focuses on improvements to the Central Altitude Reservation Function
(CARF), FNS, and providing the infrastructure that will host AIMM enhancements. These
enhancements will be implemented by AIMMS2 and a series of WPs that will be approved by
the Joint Resources Council (JRC), and will use software development and integration to deliver
additional mission support services. AIMM S2 and the WPs will be implemented by the Air
Traffic Organization (ATO), Enterprise Services, Program Management Organization (PMO).
AIMMS2 is a NextGen enabler supporting OI 108212, Improved Management of Airspace for
Special Use, and OI 103305, On-Demand NAS Information, as well as additional SAA OIs.
AIMMS2 will support the future global Air Traffic Management (ATM) environment, expanding
access to authorized NAS users by leveraging the SWIM CSS infrastructure. AI will be made
available to all NAS users utilizing web services-based system-to-system interfaces and a single
portal (i.e., One-Stop Shop (OSS)) human to system interface. These users include, but are not
limited to, the Department of Defense (DOD), Air Traffic Control (ATC) facilities, airlines, and
general aviation. (See Appendix 1 for all stakeholders.) A fully implemented SOA will increase
return-on-investment (ROI) today as well as into the future.
1.2. Problem Statement
Currently, the AI sources and delivery methods lack integration. These sources include flight
constraints as well as airport, airspace, and obstruction data necessary for shared common
situational awareness. NAS users do not have consistent access to NAS status information that
could affect flights. In addition, adding new services is a challenge without a fully compliant
SOA to facilitate efficient development and implementation of enhancements.
1.3. AIMMS2 Concept Overview
AIMMS2 will be designed to ensure compatibility and extensible enhancement of the system and
its components through a modular, standards-based design. The long-term goal of AIMMS2 is to
have an integrated architecture that manages and distributes AI to both internal NAS systems
users and external consumers. AIMMS2 will be provided as an enterprise service to all of the
NAS, thereby allowing other system and users to make the greatest practical use of its
The SOA design principle will be the foundation for AIMMS2. It separates the functionality of
the system into distinct modules or “services” that support a single function. AIMMS2 will
Airport Geographic Information System (GIS) data and
Preliminary ConOps AIMM S2 May 2012 Page 2
SAA information, but will be designed such that it can incorporate other types of AI as
The Federal NOTAM System (FNS), developed in AIMMS1, will be connected to SWIM
for distribution of NOTAMs by AIMMS2.
As AIMMS2 interfaces with relevant legacy systems, authoritative data from these systems can
be distributed and integrated with other AI.
The functionality provided by AIMMS2 in addition to supporting data integration and
distribution of information from the designated authoritative source will ensure that the integrity
of the data is maintained. It will ensure that the information is secure, and provided in a standard
format that can be transformed to meet the needs of the users. The stewarding organization of
the integrated products is Aeronautical Information Management, and the trusted access point is
the Aeronautical Common Service.
Figure 1 provides a high-level view of AIMMS2 functionality in support of NextGen and future
operations. The primary enhancements to be provided by AIMMS2 will reside in a new software
entity entitled AIM Common Services (ACS). Two of the three functions provided by AIMMS2
will make use of ACS to provide enhanced services to the user. And all three of the functions
will receive requests and distribute products through SWIM.
Preliminary ConOps AIMM S2 May 2012 Page 3
Federal NOTAM NOTAMs distributed via SWIM NESG
Data validation of the
integrated products using t SWIM
Airport Geographic business rules e SWIM
Information Systems r
f Distribution of
a aeronautical data
Special Activity Other Authoritative Sources
Figure 1: AIMMS2 internal functions and interfaces to external systems
Information made accessible by AIMMS2 can be used to create plans for adding infrastructure to
an airport – that improve the utilization of an airport’s existing resources. The data and
information made available by AIMMS2 could also be used to create more optimal plans for the
use of airspace as is highlighted in the National Special Activity Airspace Project (NSAAP)
ConOps. This enables future-planning benefits in addition to the direct operational benefits of the
new AIMMS2 system.
The full benefit that stakeholders will receive from AIMMS2 will be defined and refined by
individual consumers of the AI themselves as their needs and requirements evolve and are
clarified. Implementation of metrics, such as utilization efficiency of SAA, will help clarify
NAS performance and provide a measure of benefits to users.
Integration of the AI and information from other domains will provide an enhanced
understanding of the NAS environment and an integrated picture of its complexities. The better
the complexities and interdependencies of the NAS are understood, the more sophisticated the
plans for its management can become. Today, the exchange of AI is essential to support
Preliminary ConOps AIMM S2 May 2012 Page 4
numerous NAS operations. Modernization of systems and services will enable safer and more
efficient management of the NAS and help make NextGen a reality.
For the provider and consumer of AI information, the improvements delivered by AIM Segment
2 will provide
The authoritative source for aeronautical products
The trusted access point for aeronautical information
An extensible and flexible portal, through SWIM, for requesting and receiving
aeronautical information as an integrated data product.
Updates with a minimal delay between generation of the data by producers and receipt of
the information by consumers.
Examples of derived and computed data
NOTAM event data: When digital NOTAMs provide a geographic reference, AIMMS2
can look up the reference to retrieve a graphic of the runway or airport feature.
An SUA schedule with an airspace definition: AIMMS2 will validate the definition with
business rules. AIMMS2 can look up the definition to retrieve a graphic of the affected
If necessary AIMMS2 will use existing databases to store (not simply cache) AIXM data:
Airports GIS, NASR, and SAMS. AIMMS2 will not revalidate data already validated by the
source. It will validate derived and computed data.
Preliminary ConOps AIMM S2 May 2012 Page 5
2. Current Operations and Capabilities
AI has often been managed using procedures and systems that are very specific in scope and
focus. Legacy systems only interact and communicate with specific systems to the minimum
extent necessary in order to accomplish narrowly-defined and individual purposes. The current
state does not have sufficient flexibility for future integration with NextGen systems and
services. Significant potential for improving efficiencies of function and cost savings for aviation
users/customers has been identified.
Legacy systems and procedures often do not use common standards, protocols, or design
principles. This contributes to interoperability and compatibility shortfalls. Legacy systems are
single purpose in nature and somewhat uncoordinated with other related systems. This leads to a
lack of efficiency and raises the potential for inaccuracy when users reference needed aviation
planning data for airborne operations.
2.1. Description of Current Operations
Currently, the FAA manages AI via manual interface with input sources and internal data
management systems, many of which are antiquated systems characterized by different data
formats, end of life hardware and software, and a lack of digital data sharing. Due to these issues
with the present-day automation systems and a lack of unified digital distribution methodologies,
the AIM group currently relies on paper publications, Compact Disks (CDs), and manual data
exchange to facilitate sharing of AI in the NAS.
The AIM organization must often use paper charts, hardcopy publications, and other non-digital
means in addition to computer hosted systems and physically delivered digital media to
distribute AI. Consumers must manually access multiple data sources and individually analyze
these uncoordinated AI elements to meet their needs.
2.2. Current Supporting Infrastructure
Existing hardware and network infrastructure is in place to facilitate both internal and external
data exchange for the purposes of the system, therefore, no further hardware acquisition is
Preliminary ConOps AIMM S2 May 2012 Page 6
3. Justification and Description of Changes
Current systems and functional realms are not properly linked using business processes or
technical interfaces to facilitate efficient use of AI. Without appropriate business process and
technical interfaces, AIM cannot efficiently gather AI from disparate sources, manage the data,
and disseminate it to personnel and organizations that need it. Without appropriate data
transformation, even information that is gathered and disseminated is not in the most effective
format to facilitate efficient use of the NAS.
The proposed system can be broken down into four conceptual layers: data, service, business
processes, and application functionality. Figure 2 below shows a breakdown of the system based
on this conceptual architecture.
These layers can be further broken out into functional modules. Each functional module provides
a unique capability to the system. This section provides a description of each of the layers of the
proposed system and the functional modules, including an identification of specific solutions,
infrastructure, and technologies that will be used in the development of the AIMMS2 AIM
Common Service (ACS) system.
Figure 2: A Conceptual Architecture of the ACS within AIMM
Preliminary ConOps AIMM S2 May 2012 Page 7
Using the above model AI can be taken from original sources, transformed and formatted and
‘piped’ out to users via SWIM and through the Internet portal using the One Stop Shop
methodology described elsewhere in this document.
Preliminary ConOps AIMM S2 May 2012 Page 8
4. AIMM Segment 2 Concept of Operations
4.1. Assumptions and Constraints
The AIMMS2 program will be implemented in the NextGen midterm Bravo timeframe, 2016-
AIMMS2 will use the SWIM infrastructure to disseminate AI to systems in the NAS network.
Therefore, AIMMS2 will provide the information to SWIM, which will then disseminate that
information appropriately. SWIM will perform message routing, ensure message security, and
ensure message delivery as indicated in the Final Program Requirements (FPR) for SWIMS2.
4.2. General Operations, Functions, and Capabilities
AIMMS2 will collect aeronautical data from the designated authoritative sources, validate and
verify the data, and maintain the data in a database. The system will then integrate that data with
appropriate data from other sources and provide output as AI to authorized users that require it
for safe and efficient airborne operations. These operations can be broken down into four main
functional capabilities to users: (1) data capture capabilities, (2) data and information
management capabilities, (3) business services capabilities, and (4) data relay and exchange
capabilities. The four functional capabilities are divided into sub-capabilities as described below.
4.2.1. Data Ingest Capability
Data capture capabilities support the input of digital aeronautical data from the authoritative data
producers, as defined by policy and enforced by business rules.
Data entry tools and services will support digital data ingest and validation in accordance with
FAA regulations and procedures. The capture of the data directly from the source in a digital
format as well as the relay of this data directly to the AIMMS2 system will eliminate manual
transcription and data input errors while facilitating rapid processing.
In addition, AIMMS2 systems will provide a Internet web portal interface for users external to
FAA NAS systems to send and receive AI. For example, the airport survey information users
will log into the One Stop Shop facility and fill out predefined airport survey forms.
The SAA system will ingest data associated with the Central Altitude Reservation function
(CARF) in order to ingest airspace definitions and schedules.
4.2.2. External Service Interface Capability
AI data exchange with NAS systems is a key item of support for airborne operations. Numerous
NAS systems require AI to perform ATC management safely and efficiently. AIMMS2 systems
will exchange data with other NAS systems and will also be able to calculate statistics and
metrics for future analysis and improvement of services. The current environment, uses compact
disks (CDs), paper publications, voice telephone calls, and telefax exchanges that often result in
inefficient and error-prone manual management by specialists and other personnel. Within the
Preliminary ConOps AIMM S2 May 2012 Page 9
NAS (as with external data sources), many systems have unique data formats and incompatible
data exchange methodologies that preclude the direct exchange of digital information.
AIMMS2 will connect to the SWIM infrastructure to support direct connections to internal NAS
systems for AI data exchange. This will provide a common digital interface methodology. In
addition, AIMMS2 will institute the use of a standardized format (i.e., AIXM) for AI content for
data exchange and storage.
In order for these external systems to benefit from this information sharing, they must be
modernized to be able to process AIXM-formatted data for use in their individual systems. As
many of these NAS systems are presently also undergoing modernization efforts, the AIM group
has been engaged with the appropriate service units to communicate the use of AIXM as a
standard, receive feedback regarding the data model to ensure the information provided meets
the operational needs, further develop AIXM, and work with the individual groups to develop
transition plans to support these stakeholders as they prepare to transition to being able to ingest
AIXM. The transition plans will likely require legacy data formats and system connections to be
supported for a finite amount of time as external systems become SWIM and AIXM compliant.
4.3. Data and Information Management
Processes within AIMMS2 will support data capture, transformation, validation and verification,
integration, and information exchange and will adhere to FAA standards for data management
and information exchange. These processes will assure that the data provided comes only from
authoritative sources of data (reference paragraph 4.3.6) and provide data governance enforcing
information handling and manipulation (reference paragraph 4.3.1). These capabilities include
data and information management, business process, business rules, information management,
information transformation, data storage, data security, and data discovery.
4.3.1. Business Process Capability
The business process capability supports the management of workflows for the creation,
validation and verification, transformation, storage, and dissemination of AI. This ensures that
data is configuration-managed, ensuring that the proper procedures are used for the creation,
approval, management, and exchange of the data and that data history is maintained for analysis.
The business processes are developed from present-day AIM and FAA data management
processes in compliance with FAA policy. This will be supported by automation tools and will
streamline the current labor-intensive processes, saving time and reducing the opportunity for
4.3.2. Business Rules Capability
The business rules capability ensures that the required rules governing AI validation,
transformation, management, use, and dissemination are followed and enforced. Business rules
automate the restrictions and constraints contained in FAA policies and other AIM data
management guidelines. Business rules will also support data integrity checks. Automating AI
processing rules will ensure that AI management follows pre-defined authorization and
verification steps as the data is used, moved, or processed. In this way, the business rules
Preliminary ConOps AIMM S2 May 2012 Page 10
capability integrates closely with the business process capability, ensuring that the correct rules
are followed at each step in data management.
4.3.3. Information Management Capability
The Information Management capability provides the ability to tie related but distinct pieces of
data together in order to accurately provide users a comprehensive set of linked data.
4.3.4. Information Transformation Capability
Information transformation provides the ability to rationalize incoming, potentially incongruent
data into common sets of standards, terms, references, etc. Transformation further incorporates
the ability to translate and record data into a standardized language format to be shared with
4.3.5. Data Storage Capability
The data storage capability supports storing and archiving of AI for future reference and
analysis. This capability includes maintaining a history of AI change and status. This will
include AI and other types of information in support of the required system capabilities. For
example, user account and authority information will be stored to support the data security
capability. Business rules to ensure the integrity of the AI will also be stored. Details regarding
the types of data stored are detailed in Section 10.1.
4.3.6. Data Security Capability
Data security envisioned for AIMMS2 ensures that data can only be accessed or manipulated by
authorized users and that data and information cannot be repudiated. Data security will require
user and system authorization and authentication. It will also include management and storage of
user authority details.
Data integrity is another component of data security. This ensures that the data provided by
AIMMS2 is not corrupted or unintentionally changed by transfer, storage, retrieval, or any other
nominal data or information handling operation.
4.3.7. Data Discovery Capability
The data discovery capability supports the identification of services for aeronautical and other
NAS information. This capability allows individual NAS users and NAS system owners to
determine what capabilities and information are provided by NAS services. The NAS Services
Registry and Repository (NSRR) provides for the identification of data providers and consumers
during the design of the service (not during operations). Exchange of this information allows
users to search for and discover services that will meet their operational needs and thus identify
where they can go to retrieve the required information. This capability provides the registration
and discovery of data services through a web interface.
Preliminary ConOps AIMM S2 May 2012 Page 11
4.4. Business Service Capabilities
Business service capabilities are complex capabilities that are unique to the individual business
unit being supported by the data management tools. For the FAA, these are services that are
required for conducting and managing air traffic operations. The ACS will provide three
business service capabilities including an airspace conflict resolution capability and a post-
operational metrics capability.
4.4.1. Airspace Conflict Resolution (Deconfliction) Capability
The airspace conflict resolution or deconfliction capabilities within AIMMS2 ensure that the
creation or scheduling of airspace does not conflict with the protected airspace of any currently
existing airspace restrictions or reservations. This capability also helps controllers and
schedulers ensure that the appropriate separation between airspaces and aircraft is maintained in
the definition and use of the airspace. Airspace deconfliction analysis will use latitude,
longitude, altitude, and time.
4.4.2. Post-Operational Metrics Capability
Digital archives and logs will enable post-operational metrics capabilities and allow users and
AIMMS2 system administrators to conduct statistical data research. This will let personnel
evaluate performance in the broader context of general NAS information. Using input from
other, non-AIM information domains including weather, surveillance, and traffic flow can enable
better, in depth performance analysis. Although the AIMMS2 system will not provide specific
analysis tools of this type, the archives and logs in this context will support a wider
understanding of operating efficiencies and will greatly facilitate improved planning and
operations when employed using tools made by other programs and systems.
4.5. Data and Information Relay and Exchange Capability
Data and information exchange capabilities support data query, notification, mapping, data
subscriptions, and other capabilities. Parallel avenues for exchange of information to users will
accommodate situation-tailored information gathering and operations planning. Information will
be provided using Open Geospatial Consortium, Inc.® (OGC) and SWIM compliant services
both within the FAA NAS network and externally through the web portal via the public Internet.
4.5.1. Complex Data Query Capability
The data query capabilities within AIMMS2 allow internal NAS network users and external
users to request and retrieve, or subscribe to, multiple user-defined subsets of AI. The users will
be able to query any AI managed by the AIM group. User-defined queries based on user
authority can be stored for future reference and shared with other system users. In addition,
custom queries can be created to facilitate recurring automatic information subscriptions.
4.5.2. Data Notification Capability
Data notification capabilities will support the automated dissemination of notifications to NAS
users and systems on a recurring basis and alert users when changes in specified AI have
Preliminary ConOps AIMM S2 May 2012 Page 12
occurred. Thus, the data notification capability will also serve as a subscription capability that
facilitates the ability for users to keep up-to-date on AI changes based on scheduled need,
immediate operational planning, or any other parameter with appropriate filters for user
specifications. Notifications can be delivered via internal NAS network systems, external email,
or other methods if practical.
4.5.3. Data Mapping and Charting Capability
Mapping capabilities support the transformation of base aeronautical data to predefined and user-
defined aeronautical charts in order to display and format map and geographic data. This
capability supports the overlay of map and chart images for customization and reference. Map
and chart capabilities will support standard cartographic functions and geodetic calculations.
Standard cartographic functions are: cartographic projection, layering, display, legend, lat/long
4.5.4. OSS Data and Information Exchange Capability
The external web portal using the public Internet provides users outside of the NAS network an
OSS single point of access for AI. It also provides these users with a way to manage their own
user settings and information. This includes access to the digital data capture tools, validation
and verification capabilities, AI, chart and map capabilities, data interrogation capabilities, etc.
The external web portal will also serve as an access point for external systems developers to
connect their systems to the AIMMS2 systems and services. Access to capabilities will be
limited based on user authority. For example, only airspace management personnel will have
access to the airspace design tools.
4.6. Benefits to be Realized
Pre-flight support capabilities provide NAS users and systems with the base AI and constraint
information to assist in pre-flight planning and aid flight support operations. The base
information provided to users includes NAS infrastructure information for airports, reference
Navigational Aids (NAVAIDs), and SAA. Constraint information may include SAA schedules,
NOTAMS, and other knowledge that impacts airborne planning and operations. Relay of
multiple types of AI to users from a single location will streamline the information gathering and
flight planning processes. Tailored information request capabilities will enable users and NAS
systems to request only the relevant AI and constraint information and reduce manual gathering
and sorting activities.
Improved flight planning based on higher confidence information and ease of access to that
information combined with automation will facilitate more efficient flight route planning with a
commensurate savings in fuel and time and a reduction in emissions.
Preliminary ConOps AIMM S2 May 2012 Page 13
5. Operational Scenarios
5.1. Military SUA Schedule Change
Operational Scenario 1
The Patuxant River Naval Air Station on 20 March 2012 canceled exercises involving the use of
Unmanned Air Vehicles (UAVs) in the reserved 4006 airspace over and around the Chesapeake
Bay originally scheduled for 1 April through 16 April 2012. As a result, the schedule for SUA
associated with R-4006 is redesignated as “cold” for that time period in the Special Use Airspace
Management System (SAMS)/ Military Airspace Data Entry (MADE) system alerting other
military and law enforcement services that flight in and through that airspace is permitted.
The AIMMS2 system “taps” that system to receive the schedule change and checks the data
against known business rules to ensure that it is both rational and valid. It then updates all
services managed within the ACS, showing that the airspace is released for normal General
Aviation (GA) or FAA controlled operations as appropriate. This update is then “pushed” out via
the web portal to systems and personnel who have subscribed to user-defined alerts regarding
situations involving this airspace.
As a notional example, both Southwest Airlines, a major air carrier out of Baltimore (BWI), and
Dave Williams, a private pilot operating his Cessna 310 out of Martin State Airport, were alerted
that flights may be planned through that airspace without the need to divert around it. This
allowed each airplane to safely fly the shorter route with less fuel carried onboard. This reduced
Southwest’s cumulative fuel consumption and emissions by 1380 gallons (at $4.07 a gallon) and
4 tons respectively as a result of shorter flight distances for the 192 SW airlines flights that
transited through that airspace during that time. It saved Dave Williams 7 gallons of aviation
gasoline (at $7.68 / gallon) and reduces his emissions by 42 pounds on his flight to Myrtle Beach
to see his fiancé. This also facilitated ATC personnel and other FAA controllers and planners to
manually direct traffic through that airspace, contributing to fuel savings and emissions
reductions for many other flights.
Operational Scenario 2
Preliminary ConOps AIMM S2 May 2012 Page 14
6. Summary of Impacts
AIMMS2 will capture airport, airspace, and other aviation-related data from legacy sources and
transform it into AI in a common digital format in a central location. Using the SWIM network,
this AI will be shared with internal NAS systems and users. AIMMS2 will also share data with
authorized external users via a web interface over the public Internet. This will have a significant
impact in several domains. The ACS within AIMMS2 will become a single, trusted source of
unified AI. This vastly improves over the current state, which involves multiple systems and
services that are often difficult to use and are sometimes not specifically appropriate for the
needs of the users.
In addition, AIMMS2 will facilitate modernization efforts on the part of users as well as with
regards to FAA NextGen future planning. Users and services will now be able to develop their
own personalized systems and methodologies to gather AI using the AIMMS2 OSS capability
while NextGen programs within the NAS can more readily plan and develop systems to connect
to AIMMS2 via SWIM for future benefits. Thus, AIMMS2 is both a facilitating system that
enables better, more efficient use of AI by users and a transformational system that advances the
goals of FAA modernization efforts by enabling data and operational harmony with NextGen.
Preliminary ConOps AIMM S2 May 2012 Page 15
7.1. FAA Documents
1. Aeronautical Information Management (AIM), National Airspace System Adaptation
Environment (NASE), Concept of Operations (ConOps), Version 0.7, February 16, 2011.
2. FAA Advisory Circulars 150/5300-16, -17, and -18
3. Aeronautical Information Data, Final Report, March 6, 2009, NextGen & Operations
Planning, NAS Requirements & Interface Management.
4. Federal Aviation Administration, Advisory Circular 150/5060-5 Airport Capacity and
Delay, September 23, 1983.
5. Federal Aviation Administration, Advisory Circular 150/5300-18B, General Guidance
And Specifications For Submission Of Aeronautical Surveys To NGS: Field Data
Collection And Geographic Information System (GIS) Standards, May 21, 2009.
6. Federal Aviation Administration, Aeronautical Information Management CSSD Program
Plan, Version 1.0 Final Draft, February 28th, 2010
7. Federal Aviation Administration, CompSys Description, Available at
8. Federal Aviation Administration, Concept of Use – Tower Flight Data Manager (TFDM),
Version 1.0 Final Draft, March 25, 2010.
9. Federal Aviation Administration, Functional Requirements Document for National
Special Activity Airspace Project (NSAAP), Draft Version 1.0, June 30, 2011.
10. Federal Aviation Administration, JO 7210.3W Facility Operation and Administration,
March 11, 2011.
11. Federal Aviation Administration, JO 7400.2, Procedures for Handling Airspace Matters.
12. Federal Aviation Administration, JO 7610.4, Special Operations.
13. Federal Aviation Administration, Operational Information System website,
14. Federal Aviation Administration, Order 5100.39A, Airports Capital Improvement Plan,
August 22, 2000.
15. CGH Technologies, Inc. ACS High Level Design Summary, Version 0.6.
16. A Concept of Operations for an Airports Geographic Information System (AGIS),
Version 0.4, September 2010.
17. Concept of Operations for Common Status and Structure Data (CSSD), Version 1.0, June
18. Concept of Operations for Special Activity Airspace (SAA) Editor, Version 1.0, June
19. A Concept of Use for Airport Configuration Information Management, Version 0.2,
Preliminary ConOps AIMM S2 May 2012 Page 16
20. National Airspace System Adaptation Environment (NASE) As – Is Logical Data Model
(OV-7), 18 February 2011.
21. Operational Concept for Special Activity Airspace, Version 1.0, September 2010, Federal
22. Special Activity Airspace in SWIM, Policy Analysis, Version 1.1, March 3, 2010.
23. System Wide Information Management (SWIM), SWIM Final Program Requirements
Segment 2, Version 10, June 23, 2010.
24. System Wide Information Management (SWIM), Identity and Key Management (IKM)
Overview and Strategy Brief, February 24, 2011.
25. System Wide Information Management (SWIM) Governance Policies, Version 1.1,
August 13, 2010.
26. Title 14, Part 77: Objects Affecting Navigable Airspace, Code of Federal Regulations,
27. Title 14, Part 139: Certification of Airports, Code of Federal Regulations, 2011 Edition.
28. JPDO NextGen Conops Version 2.0, June 13, 2007
29. NextGen Mid-Term Concept of Operations for the National Airspace System Version 2.0
April 30, 2010
7.2. International Standards Documents
30. AIXM 5 Feature Identification and Reference, Version 1.0, April 29, 2011,
EUROCONTROL and the Federal Aviation Administration.
31. AIXM 5.1 Metadata Profile, Draft, 2010.
32. AIXM Version 5.1 Temporality Concept, Version 1.0, September 15, 2010,
EUROCONTROL and the Federal Aviation Administration.
33. ICAO, Annex 15 to the Convention on International Civil Aviation, 13th edition, July
34. ISO 19115:2003, Geographic Information – Metadata.
35. North American Profile (NAP) of ISO 19115: Geographic Information – Metadata.
36. Open Geospatial Consortium, SAA Pilot Study Engineering Report, 2011.
37. Open Geospatial Consortium, OpenGIS Filter Encoding 2.0 Encoding Standard, Version
2.0.0, November 22, 2010.
38. Open Geospatial Consortium, OpenGIS Web Feature Service 2.0 Interface Standard,
Version 2.0.0, November 11, 2010.
39. Open Geospatial Consortium, OpenGIS Web Map Server (WMS) Implementation
Specification, Version 1.3.0, March 15, 2006.
40. Open Geospatial Consortium, OWS-7 Aviation – AIXM Assessment Report, Version 1.0,
June 30, 2010.
Preliminary ConOps AIMM S2 May 2012 Page 17
41. Open Geospatial Consortium, OWS-7 Information Sharing Engineering Report,
September 8, 2010
42. Open Geospatial Consortium, OWS-8 AIXM Metadata Guidelines Engineering Report,
July 19, 2011
43. Open Geospatial Consortium, Styled Layer Descriptor profile of the Web Map Service
Implementation Specification, Version 1.1.0, June 29, 2007.
44. Open Geospatial Consortium, Symbology Encoding Implementation Specification,
Version 1.1.0, July 21, 2006.
Preliminary ConOps AIMM S2 May 2012 Page 18
8. Appendix 1: Stakeholders
The following individuals and organizations play a major role in producing, managing, and
consuming the airport, SAA (SUA, ATCAA, MTR) definition, and SAA scheduling data that
will be stored by the AIMMS2 system. A brief description of the role of each stakeholder
Airspace Services (AJV-1) – Final authority and steward for reviewing and approving
SUA data before it can be disseminated to NAS stakeholders unless otherwise stated in
Aeronautical Information Management (AJV-2) – Collects and disseminates data
from designated authoritative sources and creates, manages, and disseminates SAA
o National Airspace System Resource (NASR) Specialists – NASR is currently
the authoritative repository for static SUA data. NASR specialists translate the
legal descriptions of SUAs into digital format and provide this in a 56-day
o AeroNav Service – Similar to NASR specialists, AeroNav specialists also
translate the legal definitions of SUA into a digital format for charting and other
Aeronautical Products (AJV-3) – Validates SAA geometry descriptions and compiles
and publishes FAA paper and digital Aeronautical Products to support Civilian and
Military Pilots, Terminal and En Route ATC, Airport and Airspace Planning, and
Authorized Chart Agents and sales outlets. Aeronautical Products also uses this
information to support the development and dissemination of Navigational Products and
Services through the DoD, National Oceanic and Atmospheric Administration (NOAA),
and other Federal Agencies.
Terminal Automation Group (AJT-13) – Requires airport definition and configuration
data to support the development of the Tower Flight Data Manager (TFDM). TFDM will
use this information to improve airport resource management and airport surface
movement awareness to integrate legacy systems and automate operations in the
Aviation System Standards (AJW-3) – Assesses impact of changes in airport data to
existing flight procedures and, if necessary, develops new procedures that are made
accessible via AIMMS2. AIM and Aviation System Standards coordinate the publication
of new data with the development and publication of procedures.
Navigation Services Group (AJW-91) – Collects airport surveys to support the
development of Wide Area Augmentation System (WAAS) instrument flight procedures.
The Navigation Services Group submits these surveys through AGIS and works with the
National Flight Data Center (NFDC) to verify the survey data, update NASR, and publish
airport aeronautical information. The Navigation Services Group uses the published data
to develop and finalize instrument flight procedures. Survey collection supporting the
WAAS Program is scheduled for completion in Fiscal Year (FY) 2012-2013.
Preliminary ConOps AIMM S2 May 2012 Page 19
Airport Engineering (AAS-100) – Serves as the authoritative source for airport survey
data and a customer of airport AI. Airport Engineering is responsible for setting FAA
standards for the collection of airport surveys, managing airport survey projects,
maintaining electronic Airport Layout Plans (eALP) and electronic Airport Obstruction
Charts (eAOC), and providing survey data to AIM for quality control and dissemination.
Airport Engineering is developing AGIS to improve and automate the collection of
airport surveys and maintenance of eALPs and eAOCs. Airport Engineering is also
responsible for the Airport Safety Data Program (5010 Program) in place to collect
airport data and coordinate publication of the data.
Airports Regional and District Offices – Responsible for the planning, development,
and oversight of a safe and efficient airport system. Airports’ Regional and District
Offices share responsibility in verifying airport data and provide airport information to
AIM for dissemination.
Public-Use Airports – Conducts airport planning, design, and construction in order to
ensure safe air navigation, meet regulatory and funding requirements, and improve
capacity. Public-use airports are consumers of airport infrastructure information and
participate in the validation of airport data in support of the airports division prior to
National Geospatial-Intelligence Agency (NGA) – Maintains airport data for domestic
civilian airports collected through its Stereo Airfield Collection (SAC) Program. AIM
has agreed to take on the responsibility of storing this data and provide NGA with the
capability to update and access this information as needed. NGA also participates in
processing DoD non-procedural Flight Information Publications (FLIP) data through
National Geodetic Survey (NGS) – Performs quality control of airport surveys, provides
expertise in performing AI surveys, and provides technical assistance and public
education in reference to geodetic and surveying issues. NGS performs verification of
surveys submitted to the FAA and resolves any data discrepancy issues resulting from the
Air Traffic Control Agencies (ATRCC/TRACON/CERAP) – Review SAAs, provide
input, and approve SAAs during the development process when deemed necessary by
FAA documentation. Also responsible for reviewing and approving/denying SAA
scheduling requests and analyzing the subsequent usage data to assist in optimizing the
use of the NAS.
o En Route Automation Modernization (ERAM) – System that will not only be
the recipient of SAA data, but may also provide real-time SAA reservation status
Service Centers (Eastern, Central, Western) – Review SAAs, provide input, and
approve SAAs during the development process when deemed necessary by FAA
documentation. Also consume SAA usage data to assist in optimizing the use of the
Military – Works with AIM to process DoD non-procedural FLIP data through NFDC.
NFDC has integrated the military Flight Information List (FIL) process into its process
Preliminary ConOps AIMM S2 May 2012 Page 20
for handling airport data changes. The FIL process defines how changes to data for
military airfields are collected and validated with the appropriate Flight Standards
Agency. Also responsible for producing and reviewing SAA geometry, schedule, and
user data as well as scheduling SAAs for operational use and consuming the SAA usage
data afterwards for post-op analysis. Post-operational usage metrics and reports for
analysis are used to fulfill SAA usage reporting requirements for the FAA. Military users
include the Army, Air Force, Navy and Marine Corps, and Coast Guard.
General Aviation and Airlines – Provide input on SAA proposals during the public
review process and while part of the safety risks panel for ATCAAs. Also consumers of
SAA and airport data to create flight plans and help optimize the usage of the NAS.
Other Agencies (DoE, Department of State, NASA, United States (U.S.) Secret Service, U.S.
Park Service, U.S. Department of Interior’s Bureau of Land Management) – Provide input
on SAA proposals during the development process based on requirements laid out in FAA
Orders. Schedule SAAs as needed.
Preliminary ConOps AIMM S2 May 2012 Page 21
9. Appendix 2: Integration and Dependencies
9.1.1. Relationship to Current Systems
AIMM will relate and interface to a number of current systems including the FNS, SWIM
system, National Airspace System Resource (NASR) system, NAS Adaptation Services
Environment (NASE), Facility Aeronautical Data Distribution System (FADDS), SAA
Operational Repository (OR), and several others. Below is a discussion of operational and
functional concepts associated with these interfaces and the capabilities they will enable.
NOTAMS are a type of AI used to communicate temporary changes to components of, or
hazards in, the NAS. The FNS is the new NOTAM management system designed to digitize the
collection, storage, and dissemination of NOTAM information. FNS contains a subset of
temporary changes to published AI (e.g., airports, runways, navigational aides, obstacles,
procedures, routes, etc.) that are communicated through the U. S. NOTAM System (USNS).
FNS provides the capability for the origination, management, and distribution of NOTAM
information. FNS maintains a database of NOTAM data published by the USNS and includes
digital NOTAMS originated using direct digital capture or transformed into digital format in
addition to legacy NOTAMS embedded in a digital wrapper for distribution. Digital NOTAMS
are defined using AIXM. Having access to current NOTAM information is essential to air traffic
FNS provides multiple interfaces for access to and maintenance and distribution of the NOTAM
information data. NOTAM origination can occur using a web-based standard NOTAM template
or using existing systems that will submit the digital NOTAM information directly using a
system interface. NOTAM Originators are responsible for the accuracy and maintenance of their
NOTAM information. The NOTAM information inputs are verified against static baseline data
and policy-driven business rules and immediately published in the USNS. The NOTAM
information is then distributed using a web-based User Interface (UI) and through a distribution
system interface. NOTAMS are also currently available through a number of legacy interfaces,
including, but not limited to Pilot Web, NAS Integrated Web Service (NIWS), Aeronautical
Integrated Data Access Portal (AIDAP), NOTAM Distribution Service (NDS), and Extensible
Markup Language (XML).
126.96.36.199.1. Segment 1
SWIM Segment 1 provided standards for the SOA environment in the FAA supporting the
interoperability of systems undergoing modernization or yet to be built. In addition, SWIM
Segment 1 provided a Registry and Repository for services that will be on the SWIM network.
Preliminary ConOps AIMM S2 May 2012 Page 22
In order to be supported on the SWIM network, a system must be SWIM-compliant, which is
measured by adherence to the standards set forth in SWIM Segment 1.
The ACS will be fully SWIM compliant and will be registered in the SWIM
Registry/Repository. External systems will be able to access the SWIM Registry/Repository and
discover the services provided by AIM.
188.8.131.52.2. Beyond Segment 1
Later segments of SWIM are investigating and proposing solutions for the NAS Identity and Key
Management (IKM) requirements for NAS systems and users supporting multiple functions.
These include identity lifecycle management; authentication; federated authentication; attribute
management; credential management; privilege, access and authorization management; and
auditing and reporting. Each of these is discussed briefly below. (Note: These descriptions were
extracted directly from the SWIM IKM brief dated 2/24/2011
SWIM segment 2 will provide four core SOA services for mission services. The ACS, as a
mission service, will leverage these SOA services to integrate with external systems for system
monitoring and security requirements. The four SWIM Segment 2 SOA capabilities include
messaging, enterprise service management, interface management, and security. Each of these is
discussed briefly below.
The SWIM program will develop a messaging infrastructure to support message exchange
between NAS and non-NAS systems. This messaging infrastructure is termed the NAS
Enterprise Messaging Service (NEMS) and will be developed using the DEX information
sharing platform developed by Harris Corporation (www.harris.com). The messaging service
will route messages between service providers and service consumers and will ensure
delivery of messages. The messaging service will support publish-subscribe and request-
response service invocation styles.
Enterprise Service Management (ESM):
SWIM Segment 1 provided governance requirements for enterprise services. SWIM
Segment 2 extends these requirements to identify the protocols and requirements for service
registry, management and discovery. In addition to governance the Enterprise Service
Management capability also supports monitoring of Quality of Service (QoS). QoS
requirements are defined by Service Level Agreement (SLA) between service consumers and
service providers. The ESM monitoring capability monitors systems activity and message
exchange using performance metrics to ensure they are consistent with service requirements
for throughput, reliability, availability, latency, response time, accuracy and fault.
Preliminary ConOps AIMM S2 May 2012 Page 23
Interface Management capability allows 1) service providers to expose services and 2)
service consumers to discover services. It includes the capability to manage service
descriptions and manage data exchange requirements.
The security capability enforces security requirements for message exchange. This inclu des
assuring confidentiality of messages exchanged and protecting information integrity. The
security capability will also provide Enterprise Boundary Protection (EBP) between NAS
and non-NAS entities and may leverage the NAS Enterprise Security Gateway (NESG) to
184.108.40.206. National Flight Data Center (NFDC) and NAS Resource
The NFDC serves as the principal element within the FAA responsible for collecting, collating,
validating, verifying, storing, maintaining, and disseminating AI detailing the physical
description and operational status of all components of the NAS.
NFDC maintains the national AI database – the National Airspace System Resources (NASR).
NASR is the primary source for U.S. aeronautical data for external aviation authorities and third-
party data providers. NASR manages temporary and permanent changes to fixed AI (airports,
runways, navigational aids, instrument landing systems, fixes, airways, military training routes,
towers, and the remaining fixed assets of the NAS).
NFDC is responsible for managing and assigning location identifiers for airports, navigational
aids, communications facilities, and weather stations, as well as five-letter fix names, in the
NAS. NFDC supports the day-to-day management of NAS data used by the FAA to produce
various aeronautical publications by providing data products and reports on a daily basis and on
charting cycle schedules. NFDC also provides AI to government, military, and private producers
of aeronautical charts, publications, and flight management systems.
The NASR provides official government source data that defines and describes the infrastructure
of the NAS. The data originates from a wide spectrum of authorized sources, including Federal
Government offices and systems, FAA air traffic facilities, airway facilities operations, regional
offices, airport district offices, procedure developers, the Department of Defense, airport owners
and operators, inspectors, and state governments. Multiple agencies, companies, and systems
within the civilian government, military, and commercial aviation community use this data.
The NASR System provides two subsystems for access to and maintenance of the data; NASR
Forms and eNASR. NASR Forms is an intranet web-based system providing an interactive UI
via browser forms for data manipulation, query, reporting and management. eNASR is a web-
based system providing authorized external users the ability to retrieve or submit data via a
browser or application programming interface (API).
NFDC currently supports web applications to manage various NFDC business processes,
including airport data change requests, inquiries about airport data, and change requests to
aeronautical charts such as Airport Diagrams. These applications provide workflow
Preliminary ConOps AIMM S2 May 2012 Page 24
management and user and project tracking to enable NFDC to conduct its operations efficiently
and analyze its performance. The current system includes the Airport Data Change (ADC),
Airport Data Inquiry (ADI), and Aeronautical Chart Change (ACC) applications, which will be
maintained operationally including second-level engineering efforts to enhance functionality.
The BPS capabilities and related GIS functionality of ACS will support the business processes
and operations performed through NFDC Applications. The NFDC portal provides access to the
AGIS, TPSS, and FADDS sites. The NASE portal also provides access to NASR data, and the
Airport Location Identifiers site relies on NASR data.
220.127.116.11. SAA Static Repository (SR)
The SAA SR is an enhancement to the NASR database that stores static SAA definitions for the
NAS. As the SR is the authoritative store for static SAA definitions, the ACS will receive SAA
definitions from this system and distribute them to the NAS users. The data is accessed through
the FADDS web site, which provides an AIXM download of SUA definitions, as well as through
SOAP and JMS web services
18.104.22.168. Facility Aeronautical Data Distribution System (FADDS)
FADDS provides an updated, centralized repository of digital aeronautical information with
customizable search, accessibility, and distribution features. FADDS is a secure, online portal
with access to lists of aeronautical products (data for viewing and downloading).
22.214.171.124. SUA Management System
SAMS automates the scheduling of several types of SAA between the FAA and DoD. SAMS
includes the Consolidated Special-Use Airspace Repository (CSAR) for storage of schedule
information, the MADE tool for DoD entry and review of schedule requests, and the SAMS
interface for FAA approval of schedule requests. SAMS submits SAA schedule data to the SAA
Operational Repository, which is the authoritative store for SAA schedule data. SAMS is a
system that will likely be enhanced to support the NSAAP Concept.
126.96.36.199. SAA OR
The SAA OR is an enhancement to SAM that stores SAA schedule data for the NAS. As the OR
is the authoritative store for SAA schedules, the ACS will receive schedules from this system
and distribute them to the NAS users. The data is accessed through the SUA website
(sua.faa.gov), which provides a list and map of SUA and Military Training Routes (MTR) that
are active or scheduled to be active in the next 24 hrs, as well as through SOAP and JMS web
188.8.131.52. NAS Adaptation Services Environment (NASE)
The NASE is a portal that provides customized working environments for the acquisition,
processing, and dissemination of source aeronautical data required to maintain the various NAS
components. Where NASR is a database, and serves as the authoritative source for many types of
data, NASE is primarily a data portal, serving as an OSS for consumers’ data needs. NASE
provides data translation and integration between systems that have disparate data formats.
Preliminary ConOps AIMM S2 May 2012 Page 25
NASE translates the data provided by data producers into the formats required for many NAS
systems including ERAM, STARS, AADR, CARTS, DOTS, ECG, DACS, NASR, NFDC,
TVM, URET, ACES, and AVN. After this data has been translated into unique formats, the data
is provided through a portal to the individual systems administrators. Whenever a change to the
data occurs, the system administrators can log onto the NASE portal, download the newest
version of the data and then upload it to their operational system.
Much of the data provided through NASE comes from NASR and related aeronautical
publications. As consuming systems modernize to be able to accept AIXM, the need for receipt
of aeronautical data from NASE will diminish. However, in the interim, NASE provides a
critical function supporting required data transformation. In addition, if some systems never
undergo modernization, legacy formats may be required to be supported indefinitely. In this
situation, the ACS could leverage the transformation capabilities of NASE to convert AIXM to
legacy format and provide the aeronautical data to those consuming systems.
184.108.40.206. Third Party Survey System (TPSS)
The TPSS (https://tpss.faa.gov/tpss/) allows users to electronically submit survey data for
verification, update, and publication by NFDC. Users provide survey data as UDDF text files
that are used to perform verification, assess impact to procedures, and update the AIRNAV and
NASR databases. Surveys submitted through TPSS include Airport Improvement Program
(AIP) and other airport surveys processed through AGIS, surveys supporting the development of
WAAS procedures, and, previously, surveys that conformed to the FAA 405 Specification.
TPSS provides verification and acceptance workflow to track these surveys, and relies mainly on
the legacy UDDF format for exchanging data between users, systems, and databases. The BPM
capabilities and related GIS functionality of ACS will support the business processes and
operations performed through TPSS.
AGIS (https://airports-gis.faa.gov/airportsgis/) is a web application that manages the process for
submitting, verifying, and providing airport survey data and other airport-related aeronautical
data to the FAA. AGIS currently manages workflow, provides user and project tracking,
performs automatic verification of submitted data, and provides GIS visualization of airport
surveys according to FAA Advisory Circulars 150/5300-16, -17, and -18. In the future, AGIS
will manage and integrate the various surveys and types of surveys at an airport to create
electronic Airport Obstruction Charts and electronic Airport Layout Plans. AGIS is currently a
source of airport survey data for AIM and is used to update the NASR database. AGIS will
continue to be a source of airport survey data for ACS, which will receive the data using
standardized exchange formats or extract, transform, and load data from the original survey
formats before going through AIM business processes to quality control, create, and disseminate
airport aeronautical information.
AIRNAV is a database that stores airport and NAVAID data to support the development of flight
procedures. AIRNAV is a component of the Instrument Flight Procedure Automation (IFPA)
Preliminary ConOps AIMM S2 May 2012 Page 26
system, which aims to improve and modernize the creation and maintenance of IFPs. As part of
this modernization, AIRNAV will be updated to AIRNAV 2.0 to more efficiently support the
workload associated with developing procedures by improving its temporality and data control
capabilities. AIRNAV was previously managed by Aviation System Standards within Technical
Operations, and is currently under the purview of AIM within Mission Support Services. AIM is
integrating AIRNAV into its current operations to determine how AIM will use AIRNAV and
NASR operationally in the future. ACS will integrate and exchange information with both
AIRNAV and NASR as needed to support operations for SAA and airport information.
Currently, some data is added to the AIRNAV database through AGIS and TPSS. AIRNAV data
is accessed through the AVN Data Sheet (avnnet.jccbi.gov).
220.127.116.11. Obstacle Repository System (ORS)
The ORS is a database that stores obstacle data to support the development of flight procedures.
ORS is used to generate the Digital Obstacle File (DOF), which describes all known obstacles of
interest to aviation users in the United States including manmade obstructions reported under 14
CFR Part 77. ORS is managed by the Terrain and Obstacle Data (TOD) group, which was
previously part of Aviation Systems Standards within Technical Operations and is currently
under the purview of AIM within Mission Support Services. ACS will use ORS as a source for
18.104.22.168. Facility Directives Repository (FDR)
The FDR contains a subset of airport configuration information in the form of Standard
Operating Procedures, Letters of Agreement, and Facility Orders that derive from the airport
operational plans drawn up by airport terminal facilities. This information will be available for
all airports in the NAS, with the fullest complement of data likely to be available only for FAA
Focus Airports (particularly the Core 30 airports). Information is available as electronic scanned
copies of the original agreement documents from airport management in PDF format. The FDR
website is at https://loa.faa.gov. ACS may use FDR as a source for airport configuration
22.214.171.124. Operational Information System
As required by FAA Joint Order 7210.3, airport operators must report airport runway
configurations and their capacity ratings to the ATCSCC twice per year who then updates the
information in the Operational Information System (OIS) database. The Operational Information
System includes a website that displays the runway configurations along with their capacities in
a tabular format. In addition, some of the airports have traffic management tips posted in a free-
form text format at this site. ACS will coordinate with OIS to determine how to update and
exchange airport configuration definition data.
9.2. Initial ACS Prototypes
This section describes the status of current prototype development related to ACS and identifies
any significant findings or issues. This section describes how the current prototypes are
progressing toward defining the proposed system.
Preliminary ConOps AIMM S2 May 2012 Page 27
Current Prototypes include:
9.2.1. SWIM SAA
The SWIM SAA prototype includes a prototype for the digital data capture tool (SAACE) and a
prototype for a static and operational repository that will house SAA definitions and SAA
schedules, respectively. The SAACE will be described in more detail below. The Static
Repository is an AIXM database that receives SUA definitions through a web service call and
notifies consumers of updates through a Java Message Service (JMS) topic. The Operational
Repository is used to receive and manage SAA schedule requests, and provide scheduling
information, using web services.
The SAACE is a prototype that has been developed and provided to the National Flight Data
Center. NFDC specialists will use the SAACE to translate the text of SUA legal definitions into
AIXM format. This prototype has all of the necessary features for creating digital SUA
definitions. This prototype will provide a starting point to identify requirements for workflow,
other SAAs, the review process, and generation of legal definitions. A brief description of each
of these is provided.
Workflow – Since NFDC is working with the final approved legal definition, they are
only translating from a paper copy to a digital definition. When the SAACE is used
during the design and approval process, it will need a workflow and authority for this
Other SAA – The prototype is focused on SUA, but the ACS will need to handle all
types of SAA.
Review – The ACS will need to manage review and comments. This will be handled by
the Review and Comment System, which has undergone preliminary prototyping.
Legal definition – The ACS will need to generate plain-text descriptions of AIXM
objects. Using the prototype to identify all SAA generation scenarios will ensure that all
plain-text scenarios are covered. A prototype Legal Definition Generator has been
developed for an early prototype of the SAACE.
9.2.2. SAA Operational Database Prototype
The SAA Operational Database Prototype builds off of the prototyping effort of the OR from the
SWIM SAA project to include TFR and CARF. These are temporary SAAs that are currently
created and managed with separate systems.
9.2.3. OGC Efforts
The Open Geospatial Consortium, Inc.® is an organization dedicated to promoting open
standards and architectures. They have investigated several issues relating to the ACS effort.
They have accepted for some of the standards that the ACS prototype is using, including Web
Feature Service and Web Mapping Service. An emerging standard that is especially applicable to
the ACS is the Event Notification Service. This standard may be used to notify consumers about
changes to relevant information.
Preliminary ConOps AIMM S2 May 2012 Page 28
Two recent OGC studies have been the SAA Pilot (which implemented SAA notification and
dissemination services) and the OWS-8 Test Bed (which looked at information fusion standards).
The SAA Pilot demonstrated communications and information portrayal using the Event Service,
WFS, FPS and other standards. The workflow studied in the SAA Pilot has many similarities to
the ACS, and most of the components could be re-used in some form.
9.2.4. ACS Prototype
To detail and understand what is required for the management of SAA and Airport data and gain
a better understanding of functionality to be supported by the ACS, the AIM program is engaged
in developing an ACS prototype. There are a number of goals that AIM hopes to accomplish
with the creation of this prototype, including:
Demonstrate the concepts and proposed functionality of the ACS.
Validate the functional requirements and ensure they capture the stakeholders’ needs
related to information management and exchange.
Further define and detail the requirements for the ACS.
Investigate and demonstrate the viability of using OGC, SWIM, and AIXM standards for
AI exchange, including the identification of any technical limitations of these standards.
Test the interoperability of the system with the SWIM infrastructure.
Use prototyping activities to estimate the cost of the final system to be developed in
The prototype activity is occurring simultaneously with the development of requirements and
cost/benefit analysis for the acquisition package for AIMMS2. All of these activities are
integrated and help further define the methods by which AIM will be able to realize its goals of a
modernized system for airport and SAA information management for the NAS.
9.3. Anticipated Obstacles and Issues for AIMMS2 Development
There are a number of issues and potential obstacles that may present significant hurdles to
overcome for AIMMS2 development. These include problems with Filter Encoding Standard
(FES) queries, Universally Unique Identifier (UUID) management complexity, and database
architecture and format issues.
9.3.1. Altitude Query with FES
When researching how to query Airspace data and data sets by any altitude range, the ACS
prototype development team came across two issues regarding querying with FES for ACS. The
Filter Encoding Specification is limited in its capabilities, and cannot properly query by altitude
an Airspace with multiple geometry components. Furthermore, even if FES could handle
multiple components, the AIXM Airspace geometry definition requires pre-processing to resolve
the final, single Airspace volume from its discrete component “operations” (e.g. BASE, UNION,
Preliminary ConOps AIMM S2 May 2012 Page 29
9.3.2. UUID Management
The AIMM system will either propagate a UUID from outside authoritative sources or create
new one within ACS. There are significant issues related to the handling of UUID generation
based on application of ID to the particular information item. One example is when an SAA
references a geoborder (object), such as a river. The river is requested from the USGS WFS.
AIMMS2 will have three options:
1. Maintain an AIMMS2 managed replica of the USGS feature database (with or without
the USGS UUIDs).
2. Persist the entire feature reference in the AIM database (with or without the USGS
3. Only store the UUID to the USGS feature and request that feature as needed.
9.3.3. Consolidated vs. Federated Databases
Due to the large number and diversity of data sources in AIM, it is not in scope for the ACS to
deploy as a consolidated database, housing all AIM data in a single database instance. Individual
data sources, such as those mentioned in section 9.1.1, will still be the authoritative sources of
data for the ACS.
Data sources will need to be individually evaluated for inclusion into the ACS database.
Situations where the ACS will need to consolidate data into its own database may include:
When network performance requires data to be accessed in a centralized location.
Performance may be driven by frequency of data access and complexity of operations
(e.g., when a single feature incorporates references from multiple data sources).
When data is maintained in legacy formats, and the ACS needs to convert to AIXM for
dissemination or other use.
When data is not persisted in the legacy database for enough time (e.g., to provide
metrics or post-operational analysis).
When data or information must be transformed or computed as derivative data or
information from the source data.
When metadata is generated to manage or describe the data.
ACS designers will need to work closely with legacy data providers to ensure compatibility
between their systems and the ACS. Lack of careful planning could lead to a situation where
most AIM data must be consolidated in the ACS.
The ACS database will be designed as extensible and to easily accommodate new AIXM
features. When the requirement is identified to incorporate additional aeronautical data, system
administrators will only need to perform an incremental amount of work. Such extensibility will
probably be difficult to achieve in practice, and will require careful planning and design.
Even when using a federated approach to database architecture, the ACS will provide a
“consolidated” interface/experience for consumers and data providers. These users will use a
Preliminary ConOps AIMM S2 May 2012 Page 30
single access point to the ACS, and use a single set of services, regardless of whether the data is
stored in a single consolidated, or multiple federated, databases.
It should also be noted that the ACS is not built strictly to serve a present need. It is built to serve
a future need as well. The modularity and extensibility of its services will enable legacy and
future systems to make use of components (business data management, Identity management,
metrics, AI dissemination, etc.) as needed. This will reduce development effort, ensure consistent
standards are followed for data and architecture, and provide a common service to consumers.
Even though the ACS will receive data from a number of federated sources, the result will be
greater than the sum of the parts due to the reuse of common services and capabilities.
9.3.4. Scheduling Database
Legacy AIM architecture included separate databases for static aeronautical data (NASR) and
operational SAA scheduling data (SAMS/MADE). These databases resided on different security
networks – the mission support and NAS networks. Early SWIM prototyping efforts have started
using web services to connect databases residing on these networks through the NESG.
In addition to the issue of consolidation vs. federation, described in section 9.3.3,
communications across the NESG must be evaluated, such as whether it is best for the GIS
database to be replicated on either side of the NESG, or for users on either side to communicate
with a single database. Prototyping, and the results of the SWIM development work, will shed
more light on the constraints imposed by the NESG, and the most effective means to collect and
provide AIM information between FAA networks.
Preliminary ConOps AIMM S2 May 2012 Page 31
10. Appendix 3: Architecture Framework
10.1. Data & Information
10.1.1. Data/Information Types
This section identifies the data and information that the AIMMS2 system will provide. It will
also identify types of data that are not specifically aeronautical data but will be stored and
maintained in the system to support associated system and services functionality. Although the
technical difference between information and data is an important one, the AIMMS2 systems
will handle both as essential business service elements and will apply specific differentiation to
10.1.1.1. Aeronautical Data and Information
AI is the fundamental information domain in aviation that describes and defines the existing
features and procedures that comprise the NAS. ICAO Annex 15 defines aeronautical data as
“…A representation of aeronautical facts, concepts or instructions in a formalized manner
suitable for communication, interpretation or processing.” It defines AI as “Information
resulting from the assembly, analysis and formatting of aeronautical data.” This information
may be either static or dynamic. Static data defines the properties of, or relationships between,
entities that either do not often change or are planned and scheduled in advance with the
understanding that no sudden changes will be made without exceptional circumstances arising.
Dynamic data provides information about the status or condition of entities that due to their
nature are subject to unscheduled changes in condition with little notice.
The AIMMS2 ACS system will serve both as a central authoritative access point of static
aeronautical data and as an operational reference source for two basic types of AI: airport data
and SAA data. The final purpose of the AIMMS2 system will expand to provide access to
additional types AI and operational reference data as required.
10.1.1.1.1. Airport Data
10.1.1.1.1.1. Static Airport Infrastructure Data
Static airport infrastructure data describe the fixed features that constitute an airport. Reporting
the existence and details of these features is a requirement of airport certification as outlined in
14 CFR Part 139, and is also a requirement of the Airport Improvement Plan that funds the
majority of planning and development for public airports.
Official standards describe how to conduct airport surveys to meet the data collection
requirements of these regulations. These standards define the following feature categories as
critical airport data:
Airfield information such as airport elevation and location (latitude and longitude of the
“airport reference point”), runways and associated elements (e.g., runway blast pads,
landing thresholds, stopways, shoulders, and any airplane arresting gear), taxiways,
aprons, ramps, and helipads
Preliminary ConOps AIMM S2 May 2012 Page 32
Non-movement areas such as gate and deicing areas
Cadastral data such as airport property boundary and related property boundaries
Environmental interest regions such as flood areas, contaminated areas, bird strike and
other animal hazards, wetland, noise monitoring regions, and hazardous materials storage
Artificial structures such as buildings, fences, and towers
NAVAIDs, Instrument Landing System (ILS) antennas, visual glide slope equipment,
and wind indicators
Roads and other surface transportation features
Utility features, such as towers, tanks and power lines
Geospatial data, such as airport control points
Obstacles comprise another category of static airport data. This class includes features from the
artificial structures, utilities, transportation features, and environmental interest area categories
that may affect the safe operation of the runways or present a hazard to arriving or departing
Airport-associated data refers to features that are not part of an airport but are involved in or
have an impact on takeoff and landing procedures at a given airport. In particular, off-airport
vertical structures and other obstacles may fall under this category. Due to the 14 CFR Part 77
regulations governing obstacle definitions, structures situated closer than 6 nautical miles of the
airport reference point (or center of all runways) have a lower obstacle threshold than the
standard threshold of 500 feet. Within 3 nautical miles (nm), the threshold is 200 feet. The
regulations further define civil airport imaginary surfaces around an airport that would classify
any object rising above such a surface as an obstacle. Any obstacles defined in terms of these
airport-associated constructs are, by extension, associated with that airport. An obstacle may be
associated with more than one airport or area of operation if they are in close proximity to each
All categories of data listed above are “…Critical information for the operation and safety of the
National Airspace System (NAS)” ICAO Annex 15 defines data as critical when “…There is a
high probability when using corrupted critical data that the continued safe flight and landing of
an aircraft would be severely at risk with the potential for catastrophe.” For this reason, the
airport survey standards outline a process where the National Geodetic Survey (NGS) verifies
collected data for consistency and accuracy before dissemination. This survey process and
verification workflow is part of the AGIS system maintained by the Airports GIS program.
The critical role of the geodetic survey process and importance attached to validation of the
geodetic description of airport data underlines the important role this data plays in the creation of
accurate charts and the safe and reliable operation of the NAS. In particular, ILS and future
automation systems designed to safely direct and optimize aircraft traffic both in the airspace
near the airport and on the ground depend critically on high precision coordinates for the details
of all aircraft movement and gate areas.
Preliminary ConOps AIMM S2 May 2012 Page 33
10.1.1.1.1.2. Static Airport Configuration Data
Static airport configuration information describes the predefined plans of an airport for arriving
and departing aircraft. This information includes the definition of runway configuration options,
restrictions on runway configuration use, traffic management tips, static airport capacity
information for each configuration, and any other static information associated with airport
configuration use. The Terminal Facility Manager at the Air Traffic Control System Command
Center (ATCSCC) designs and reports the airport configuration in accordance with FAA Joint
Order 7210.3 “Facility Operation and Administration” and FAA Advisory Circular 150/5060-5
“Airport Capacity and Delay”. This information is then stored in the Facility Directives
Repository (FDR) and Operational Information System (OIS), which are discussed further in
sections 126.96.36.199 and 188.8.131.52, respectively.
Weather, visibility, runway use programs for noise abatement, and other considerations
determine the operational state and procedures in effect at an airport at any given time. Although
the actual airport configuration in use is dynamic information, the static definitions of the
configuration given the determining factors allow Decision Support Tools (DSTs) to present
solutions to the airport tower controllers that optimize both safety and capacity.
A complete definition of an airport configuration consists of a set of runway operational
configurations (optionally ranked according to preference), along with airspace operational
agreements, ATC terminal operations, and ATC service agreements. The complete definition of
a configuration will also consist of procedures to follow when the configuration is in effect, and
restriction conditions under which the configuration (or individual runways) must, may, or may
not be used. The airport configurations themselves may be ranked in order of preference for
given traffic and meteorological conditions.
Airport configuration information plays a key role in linking airport data to information in the
Terminal, En Route, and Traffic Flow Management (TFM) flight domains, describing the
interrelationship of these domains and the flow of a flight from one domain to another as a flight
proceeds from departure to free flight and ultimately to arrival. The operational decision to
activate a particular airport configuration is made in real time with regard to weather as well as
en route and ground traffic. Therefore, airport configuration information also links flight and
flow, surveillance, and weather information domains to AI. The result of integrating information
from these various domains provides a Common Operating Picture to the NAS operators
required for decision support. (Figure 1 provides a graphical depiction of this concept.)
The need to link across multiple flight and information domains raises the importance of
providing airport configuration information in a standardized digital format that can be readily
used by a wide array of automated decision support tools and human users alike. Much of the
airport configuration information is captured in Standard Operating Procedures (SOP) for an
airport and Letters of Agreement (LOAs) between the airport and other entities. However, the
information in these documents does not follow a standardized organization or format. Names
for and presentation of the same pieces of information vary from airport to airport. Furthermore,
full documentation of many types of airport configuration information exists for only a few
Preliminary ConOps AIMM S2 May 2012 Page 34
10.1.1.1.2. SAA Data
10.1.1.1.2.1. Static Data
The definition of an SAA, from the SAA ConOps, is:
An airspace of defined dimensions
Where restrictions may be placed on aircraft in the airspace
Whose status is published or broadcast
The establishment of which is coordinated between a using and controlling agency
This definition above for SAA is used throughout this document; however.
The components of SAA static data include the geometry of the airspace (a 2-D shape plus
altitudes – also called 2.5-D), a static schedule (which is different from the schedule/status data),
using and controlling agencies, and additional information about the SAA.
Some of this additional information, such as specific constraints on when an SAA can be
scheduled, can be captured in LOAs or SOP. These are used to document specific constraints,
procedures, and/or information for use within a facility (e.g., SOP) or between facilities/agencies
10.1.1.1.2.2. Schedule/Status Data
The NSAAP FRD defines an SAA schedule as containing the following informational elements:
SAA description (including any limitations/qualifiers on type of activity)
Names of linked SAA if any
Type of activity designated as aviation/non-aviation, if applicable
Lights-out night vision goggles (NVG) (if applicable)
Entry and exit points for MTRs
True airspeed for MTRs
A schedule may also contain:
Type of activity
Preliminary ConOps AIMM S2 May 2012 Page 35
Type(s) and number of aircraft and navigation equipage
The NSAAP ConOps states that SAA schedules will be managed for the following types of
Aerial Refueling (AR) Tracks
Altitude Reservations (ALTRV) – Stationary
Air Traffic Control Assigned Airspace (ATCAA)
Instrument Routes (IR)
Military Operations Areas (MOAs)
Temporary Flight Restrictions
Temporary SUA (TSUA)
10.1.1.1.3. Aeronautical Reference Data
SAA data, especially the geometry definitions, contain references to other aeronautical features.
Some referenced data include:
The position of NAVAIDs, Airports, Fixes, Waypoints, and other significant points, or
distances and directions based off of those points.
Airspaces, including other SAAs, class airspace, airways, National Parks, and
environmentally sensitive areas.
Civil features including state and country boundaries, roads, and railroads.
Geographic features including rivers and coastlines.
Graphical overlays. While these are not truly data, visual depictions of AI are usually
presented on a Visual Flight Route (VFR) Sectional Aeronautical Chart.
Other parts of the SAA data that contain reference data are schedule (local time offset from
Greenwich Mean Time (GMT), daylight savings time), and using/controlling agencies (these
agency definitions are maintained separately from SAAs).
Geometrical references for SUAs are maintained in two fashions, depending on the type of
feature that is referenced. When the reference corresponds to an MOA excluding a Restricted
Area, then any changes to the Restricted Area are automatically propagated to the MOA. This is
allowed because the MOA and Restricted Area are both used together, and the overall area of the
MOA will not increase if the Restricted Area changes. In all other reference situations, the
referencing feature must be explicitly updated when an update to the reference data occurs. If it
Preliminary ConOps AIMM S2 May 2012 Page 36
is not updated, the referencing feature must identify that it uses the previous definition of the
Airport-associated data may also reference aeronautical features that are not within an airport.
Due to the 14 Part 77 regulation governing obstacle definitions, structures situated closer than 6
nautical miles (nm) of the airport reference point (or center of all runways) have a lower obstacle
threshold than the standard threshold of 500 feet. Within 3 nm, the threshold is 200 feet. This
regulation further defines civil airport imaginary surfaces around an airport that would classify
any object rising above such a surface as an obstacle. As such obstacles are of particular
importance to safe takeoffs and landings, they are reference data pertaining to one or more
Likewise, off-airport NAVAIDs are also reference data if they are used to define airport
approach and departure fixes that are part of the landing and takeoff procedures for an airport.
Airport reference data may be associated with more than one airport when airports are
sufficiently closely collocated.
10.1.1.2.1. Authoritative Source Metadata
Metadata is defined as data about the data. For AIMMS2, it is data about the acquisition,
processing, and dissemination of the AI and will store and associate information such as the
username of the individual that updated the data, time of update, reason for modification and so
on. This metadata will be captured and defined in the ACS metadata profile. The capture of this
metadata throughout the data and information management processes will be enforced using
AI metadata can be broken down into two types. The first is data about the data itself. Examples
of this type of metadata includes the decimal precision of numbers in the data, identification of
reference data that are not explicitly included, and identification of map projections that were
used to display and/or draw SAAs. This type of Metadata is typically incorporated with the AI
and thus not segregated as metadata. For this reason it need not be discussed here.
The second type of metadata is about the handling of the data. This includes when and by whom
data was created, modified, and made effective. This second type of metadata is important to
support traceability in case of an incident where the data is audited, and because users often must
contact the data (or change-to-the-data) source to validate it or to ask further questions.
The AIMMS2 system will derive its metadata profile for aeronautical data from legacy systems
that manage airport and SAA data, industry standards such as International Organization for
Standardization (ISO) 19115 and ICAO metadata standards, and AIXM metadata standards. The
following sources will be used to identify required metadata for aeronautical data.
NASR – Collects data and information that could be considered metadata related to the
collection and management of fixed assets for the NAS.
AIRNAV – Collects data and information that could be considered metadata related to
airport and NAVAID data collection and management.
Preliminary ConOps AIMM S2 May 2012 Page 37
The following organizations define metadata standards or use existing metadata standards to
derive metadata profiles. ACS will use the standards and profiles developed by these
organizations to derive a metadata profile for aeronautical data.
International Civil Aviation Organization (ICAO) – Publishes Annex 15 to define
requirements for Aeronautical Information Services (AIS) supporting international civil
aviation. Annex 15 references ISO 19115 and describes how ISO 19115 should be used
to define a metadata profile for a data product, application schema, or other specification.
Federal Geographic Data Committee (FGDC) – Establishes the standard for a
common set of terminology and definitions for the documentation of digital spatial data.
FGDC endorses non-Federally authored standards that play an important role in enabling
geospatial interoperability. Many of these endorsed standards relate to geospatial
International Organization for Standardization (ISO) – Defines the ISO 19115:
Geographic Information – Metadata standard for geographic information. ISO also
publishes several standards related to the collection of metadata, including the North
American Profile (NAP) for ISO 19115; ISO 19110: Geographic Information –
Methodology for Feature Cataloguing; ISO 19115 – 2: Geographic Information –
Metadata – Part 2: Extensions for Imagery and Gridded Data; ISO 19119: Geographic
Information – Services – Amendment 1: Extensions of the Service Metadata Model; and
ISO 19139: Geographic Information – Metadata – XML Schema Implementation.
EUROCONTROL/FAA – Is deriving a metadata profile for AIXM 5.1 that focuses on
the collection of metadata elements suitable for information exchange.
RTCA – Publishes user requirements and interchange standards for aerodrome mapping
data, including metadata. DO-272B, User Requirements for Aerodrome Mapping
Information and DO-291A, Interchange Standards for Terrain, Obstacle, and Aerodrome
Mapping reference the ISO 19115 standard and specify specific metadata elements.
OGC – Specifies several standards that codify the documentation of content associated
with Web Mapping, Web Processing, and Catalogue services as well as standards for
encoding data such as GML, Filter Encoding, and Symbology Encoding. OGC also
publishes engineering reports from their Interoperability Program, which document
metadata issues that were considered during the IP.
Different subsets of the AIMMS2 metadata profile as used in the ACS will apply to airport data
and SAA data. This is necessary because airport and SAA data and information follow different
rules and procedures governing collection and management.
10.1.1.2.2. Airport Metadata
This section describes the additional metadata that will need to be collected for airport data.
AIMMS2 will use the following sources to identify required metadata for airport data.
Airports Geographic Information System (AGIS) / Advisory Circular (AC)
150/5300-18 – Describes metadata required for survey data, such as its source, accuracy,
and reference coordinate system. AC 150/5300-18 requires 29 elements of the 409
Preliminary ConOps AIMM S2 May 2012 Page 38
defined in the ISO 19115 standard. However, AC 150/5300-18 excludes some of ISO
19115 elements because they are captured within the AC 150/5300-18 standard itself.
Third Party Survey System (TPSS) – Collects data and information that could be
considered metadata related to the collection of airport survey data, such as user actions,
creation dates, and modification dates. However, there is no defined metadata profile for
National Flight Data Center (NFDC) Applications – Collects data and information that
could be considered metadata related to the collection and processing of aeronautical data
changes and inquiries, such as user actions, creation dates, and modification dates.
However, there is no defined metadata profile for this system.
10.1.1.2.3. SAA Metadata
This section describes the additional metadata that will need to be collected for SAA . AIMMS2
will use the following sources to identify required metadata for SAA data in the ACS:
NFDC Applications – Same as Airport metadata description above. For SAA, NFDC
stores the raw XML code that is submitted to NASR. This creates a digital data “paper
SAA Creator Editor and Review and Comment System – Collects data and
information related to the development and approval of airspace definitions, including
user actions and dates. Also provides map projection data.
SAA Operational Repository – Collects data and information related to submission and
approval of schedules, including user actions and date/times for all actions in the
scheduling process. These times will be used in the development of process latency
10.1.1.3. Historical Data
To ensure that all changes to the aeronautical data have occurred by the appropriate mechanisms,
AIMMS2 will perform detailed tracking and create an audit trail for all data alterations. In order
to support post-operational analysis of data, AIMMS2 will also maintain a history of aeronautical
data within the ACS. By design, AIXM supports the temporal nature of aeronautical
information. The “AIXM 5 Temporality Model” document details how AIXM supports
temporality. Based on the AIXM temporality model, when a temporary change expires or is
replaced by another temporary change to the data, the previous version of the data can be
considered historic data. In addition, if a permanent change to the data is made, the previous
version of the data can also be considered historic data.
Therefore, to support the management of AI and capture how the information has changed
(either temporarily or permanently) the requirement exists to store both permanent and
temporary changes to data and keep a record of these changes. The GIS database(s) that will
store the airport and SAA data will implement the AIXM temporality model and thus will
support the storage of both temporary and permanent data changes. However, although the GIS
databases will support this historic data storage requirement, the GIS database is not designed to
Preliminary ConOps AIMM S2 May 2012 Page 39
support the amount of data that can amass over years and years of changes, especially when
considering temporary changes to airspace features may occur rather frequently. .
10.1.1.4. Document Data
Document data consists of supporting files that are stored as documents and not as raw data in
the system. Some documents are required to support or provide context to other functionalities
for the system. For example, the system will be required to store copies of sectional and terminal
area charts for use by the mapping service as a map overlay. Other documents provide a record
of the development of data. The document types that will be stored in the systems include, but
are not limited to:
Charts (for reference map layers)
o VFR Sectional Charts
o En Route Low Altitude IFR Charts
o Terminal Area Charts
o Approach Plates
Templates (for the business process management solution and report generation service)
LOAs (for reference by the SAA scheduling systems)
Records of airspace development, review, and approval
Supporting documentation used to verify survey data, assess impacts of changes in data
on existing flight procedures, and process aeronautical data changes
10.1.1.5. Identity Management Data
In conjunction with the functions of identity management that will be managed by SWIM,
AIMMS2 will provide identity management services for users that access the AIM system.
Users will have different authority based on need and functional roles in the NAS. The system
must also identify systems that access AIM and enforce their limitations on the authority.
Identity management can be divided into: User Identity Management Data and System Identity
Management Data. A few examples of the types of data that fall into each of these categories are
1. User Identity Management Data
a. User Roles
i. Users Roles are predefined sets of authority based on the various
operational positions in the NAS
b. User Authentication Data
i. User Name
iii. Email address
Preliminary ConOps AIMM S2 May 2012 Page 40
c. User Authorization Data
i. User’s role(s)
ii. User Permission(s)
iii. User’s Facility(ies)
2. System Identity Management Data
a. System Certificates and Keys
The requirements for the full set of identity management data that will be required and stored
will be defined by the requirements of the legacy and external systems that must interface with
the AIMMS2 system. Allowances will be made for data required for identity management that
must be stored in other systems. For example, if an FAA enterprise system is available for user
authentication, that system may store the username and password of the individual for
authentication. This external system would then send the data regarding the user authentication
to AIMMS2 systems. That authentication data would be used to determine the user’s authority
based on a comparison with the authorization data stored by the AIMMS2 system.
10.1.1.6. System Activity Data
For auditing purposes all transactions between the AIMMS2 system and other systems will be
logged and stored as system activity data. Some examples of the activities that will be logged in
the system include creation of new users, dissemination of subscription data, requests for new
data, and all updates to the aeronautical data made by authoritative sources.
10.1.1.7. Metrics Definition Data
AIMMS2 will provide AI data to support the post-operational metrics capability discussed in
section 4.4.2. AI metrics evaluate the performance of the National Airspace System based on the
AI stored in AIM.
10.1.2. Data & Information Storage
10.1.2.1. Operational GIS Database
This database will store geographic data optimized for operational use. Such data includes AI
categorized as AIXM features that have a location (such as the Designated Point in AIXM) or a
combination of location and geographic extent. “Geographic extent” means a defined line, area,
or volume involving horizontal dimensions, the vertical dimension, or both.
The GIS database will employ special database extensions for storing, querying and performing
calculations on geographic data types efficiently.
Preliminary ConOps AIMM S2 May 2012 Page 41
10.1.2.2. Non-GIS Data Store
The non-GIS data store will contain AIXM objects and other non-geographical data that does not
require special geographic database extensions. This data store will contain metadata as well as
temporary items, or “working data,” created in the process of using, querying, or maintaining the
ACS, but may not need to be permanently stored. The SAA Project Repository is a specific
example of such working data, as it temporarily holds documents and other data associated with
the approval workflow for airspace creation and editing.
10.1.2.3. Data Warehouse
The data warehouse will store and archive historical data optimized for querying and generating
metrics. It will contain historical AIXM feature data (in the form of complete AIXM feature
time slices), AIXM object change history, and dynamic data history (such as SAA schedules and
Any change to a record in an AIXM feature table automatically triggers a of copy of the new
feature time slice to the corresponding AIXM feature archive table along with change log
information: the nature of the change (Insert, Update, or Delete), the timestamp of the change,
and the user requesting the change (if user information is being stored and tracked). The Archive
Data Transformation Service described in Section 10.2.2.1.4 will enable archival of AIXM
objects and dynamic SAA data.
The data warehouse will be a virtual repository (based on federated database structures) of
changes made to every feature since the time of system inception, as well as a complete history
of SAA activation status and schedules. In the future, data warehousing and business
intelligence techniques could be used against this data to identify specific changes by specific
users, examine SAA status and usage history, and analyze many other trends.
10.1.2.4. Storage Design Supporting Information Management
An important capability of the ACS database and services is the ability to transform data into
information. Information Management is the ability to tie related but distinct pieces of data
together, to accurately maintain those relationships as the data are separately maintained, and to
provide users a comprehensive set of linked data. This capability is provided through the
processes of data linkage and data fusion.
10.1.2.4.1. Data Linkage
Data linkage is a concept where properties of an individual feature can be linked to properties of
a different feature. For aeronautical information, this concept supports exchange of context to
each individual aeronautical element. In the National Airspace System most features are
associated with other features, be it due to location (a NAVAID located at a runway), inheritance
(a VHF Omnidirectional Radio Range (VOR) is a type of NAVAID), ownership (NAVAID is
the property of the Airport), or a myriad of other types of relationships. Understanding these
complex relationships is critical to the management of AI in the future as each feature does not
exist in a vacuum but instead exists as one small component of a complex and integrated
environment that is the NAS.
Preliminary ConOps AIMM S2 May 2012 Page 42
Data linkage is a concept that can be supported by intelligent design of the systems that manage
and store the individual features. Critical to the exchange of linked data is a data model that
describes the relationships of each individual AI element with other information elements. The
AIXM Conceptual Model (AICM) has been developed through collaboration with
EUROCONTROL, the International Civil Aviation Organization, and the FAA. AICM will be
used as the basis for the design of the aeronautical data stores for the AIMMS2 system.
Linked data features residing in a single system can be designed such that a link within the
associated feature to the referenced feature definition can be defined by the data model. If the
linked data features reside in different systems, the same links can be established using the data
model of the primary feature, and the source (a hard link to the service, or the URN) where the
features reside. The users can resolve the link to subscribe to changes in the reference feature
data so that the system ‘pulling’ the data is aware of changes to the reference data.
Through this relational model, data linkage ensures that primary features that reference other
features, are always linked to the authoritative source of the reference data and always references
the most current version of the reference data even if it changes.
This also supports the exchange of information to users in new and complex ways. For example,
if there are linkages between different features in a database, the system can be designed to allow
users to query based on linkages and provide all linked features to users including an
identification of how the features are linked. This allows users to understand what features may
be impacted if a change is made to a reference feature. For example, a user could look for all
information linked to a NAVAID and they could find any airspace that would be impacted by a
change to that NAVAID.
10.1.2.4.2. Data Fusion
Data linkage lays the foundation for data fusion. Data fusion regulates how input of data from
various authoritative sources is integrated and the linkages of that data to other data elements are
resolved and maintained. Data fusion also integrates relevant AI to a single cohesive package for
users based on the relevant associations. The first of these requirements, integration of
authoritative source data and feature linkages, occurs on the input side of the system – Fusion In.
The second, integration of information to a cohesive package for users, occurs on the output side
of the system – Fusion Out.
10.1.2.4.2.1. Fusion In
Fusion in is a concept that regulates the connection between features and their authoritative
sources, and the management and resolution of the links between relevant features that will result
from changes made to data by the authoritative source. As each individual aeronautical element
may be provided by a different authoritative source, the ACS must support the integration of this
discrete data into one cohesive data set, while maintaining the author of the data.
For example, an SAA definition is provided by an airspace designer, but the single authoritative
source for the NAVAID, upon which that SAA geometry is based, is Tech Ops. When the
airspace is defined, the system must ensure that the definition links to the appropriate NAVAID
and the appropriate definition of that NAVAID, as the properties of the NAVAID itself may
Preliminary ConOps AIMM S2 May 2012 Page 43
change over time. To provide this ability, the authoritative source for each individual element
must be known and enforced in the system. This functionality is provided through the identity
management and business rules capabilities discussed previously. Once data has been provided
from the authoritative source, it must be integrated with the rest of the AI through update of the
When data is updated in the AICM database, the AIXM temporality model dictates that it will be
integrated as a new time slice (based on Baseline or Permdelta) for that data feature, with the
effective dates of the element identified as the start and end points of the time slice. However,
there may be multiple data elements that have a relationship with that data particular, updated
feature. Because the associations to that data feature were defined based on the previous version
of the data (not the new version of the data), the associations between the features must be
maintained for the previous version of the data. To support this, associations in the AICM data
model have distinct identifications and also have their own temporality. Leveraging a
combination of identity management, business rules, business process, and database design
characteristics the ACS can thus be designed to receive data only from the authoritative source,
integrate that data into the database, and regulate the associated linkages that that data element
has to other features.
10.1.2.4.2.2. Fusion Out
Fusion out is a concept that provides for integration of information into a cohesive and
comprehensive package for users. The determination of what information should be packaged
together comes from a thorough understanding of the needs of the user community. One
example of the packaging of logical information can be highlighted with SAA information. If a
user requests a specific Special Activity Airspace, and the definition of the geometry of that
airspace references a NAVAID location, it makes logical sense to provide the location of the
NAVAID to the user in combination with the airspace definition. A similar concept applies for
an SAA schedule. If a user requests a schedule for a specific SAA, it makes logical sense to
provide some components of the definition of the SAA with the schedule request to provide the
user with the contextual information that is required to understand the airspace schedule. Thus,
the concept of Fusion Out, is one that provides context for AI by integrating features into one
message for the users.
As mentioned, the information packages will be defined by the needs of the using communities
and can be pre-defined for the ACS. The packaging of information will be based on the NAS
and AIM Information models that are currently being defined by the AIM and NAS information
10.1.2.4.3. Data Convergence
Data convergence takes data linkage and fusion one step further, and automates the process of
identifying changes to features that affect other linked features for users and “actioning” based
on the change. When a reference feature is modified, through data fusion, the system can identify
which version of the features the information is associated with. However, it does not support
the identification of how the new feature is related to the features with which it was previously
associated. For example, if an SAA definition is based upon the location of the NAVAID, and
Preliminary ConOps AIMM S2 May 2012 Page 44
the definition of the NAVAID changes, the question arises as to whether the linkage between the
SAA definition and the NAVAID still holds. Likely, whether or not this relationship is still
relevant will depend on which attribute(s) of the NAVAID were changed. If the location of the
NAVAID was changed, the relationship will not hold. If the frequency that is emitted by the
NAVAID changes, the relationship would hold. The concept of data convergence would support
the automatic identification and update of associations that are still relevant and the modification
of relationships that are no longer relevant.
A system that supports data convergence will be designed to automatically update a linked
airspace definition (if permitted by business rules) to include the new definition of the reference
data. If further action is required in this process the system will provide notification to the
authoritative source of the airspace definition indicating that the reference feature has changed
and the definition of the airspace and its association with the reference data needs to be updated.
This would alleviate the need for authoritative sources of AI to constantly monitor the currency
and validity of the reference data.
Data Convergence will not be supported in the initial releases of the ACS. The ways in which
data convergence can be implemented are numerous and complex and require further
investigation. In addition, present-day policies governing information exchange such as the 56-
day charting cycle further complicate the implementation of data convergence. However, as the
ACS will be designed to support data linkage and fusion, data convergence could be supported
through subsequent modification after the appropriate research has been conducted.
10.2. Common Services
10.2.1. Data Collection Services
The data collection services support the capture of digital data from authoritative sources of
information. The data will be integrated into the ACS data stores. Digital data capture tools that
support external processing of the data and provide data that has been validated and verified
prior to receipt by the ACS, can directly update into the databases. This requires a connection of
external systems and digital data capture tools to the service for updating data in the database.
For the ACS, the OGC transactional Web Feature Service (WFS-T) will be used to update data
in the data stores. Some data, however, cannot be directly updated in the data stores as it
requires additional validation and verification steps before it is approved and can be integrated
into the database. Data that requires processing prior to update in the database will be routed
through the Business Process Service (BPS) (discussed in section) that will enforce business rule
verification and the other steps required to be performed prior to database incorporation. All data
capture workflows regulated by BPS end at the ACS data stores through the WFS-T.
10.2.1.1. Transactional Web Feature Service
The Transactional Web Feature Service is an Open Geospatial Consortium standard that
specifies a web service that provides transactions on geographic features contained in a data
store, independent of the underlying data store. The transactions supported by this standard
include insert, update, replace, and delete. However, to adhere to the AIXM temporality model,
only the insert operation is relevant for an AICM-based data store and will be implemented in the
Preliminary ConOps AIMM S2 May 2012 Page 45
ACS. Using the WFS-T standard complex, multi-threaded features may be inserted in a single
10.2.2. Data Management Services
Data Management Services support the Data and Information Management Capabilities
discussed in Section 4.3. These services support the distinct operations performed by AIM that
allow them to provide authoritative, accurate, consistent, secure, and commonly represented
information to consumers. These services include Data Transformation Services, Data
Verification Services, Airspace Deconfliction Service, Universally Unique Identifier (UUID)
Management Service, and an Identity Management Service.
10.2.2.1. Data Transformation Services
Ideally, the AIMMS2 system is to have all of its services use AIXM natively. This would mean
that the data capture tools would move data from the user input screens directly into an AIXM
format, transmit AIXM messages to the ACS database which is configured to store AIXM data,
and then provide AIXM data to consumers. When parts of the system, typically interactions with
systems external to AIM, do not use AIXM then the ACS will need to convert to and from
AIXM. In addition, as NAS users may not be familiar with AIXM a service to transform AIXM
to human-readable text is also required. These types of transformations will be discussed in the
10.2.2.1.1. Survey Data Transformation Service
The future concept for collecting airport survey data is to have systems responsible for
processing airport surveys exchange data with AIMMS2 via web services using AIXM. For
example, AGIS currently uses various geospatial vector file formats to submit, verify, and
download survey data, while TPSS uses its own legacy file format. Ideally, these systems would
process and transform data to AIXM before providing it to AIM for dissemination. However, to
support legacy users and file formats, AIMMS2 will also need to be able to transform survey
data from its original file format before loading data into its database. This survey data
transformation service will provide the ability to transform data from the ACS database format
into various survey file formats. Depending on integration plans, the survey data transformation
service may be developed to have the capability to:
Transform survey data to and from Autodesk AutoCAD, ESRI Shapefile, and
MicroStation Design File formats, as specified in AC 150/5300-18.
Transform survey data to and from Universal Data Delivery Format (UDDF) file format,
as required by TPSS and current NGS verification applications and tools.
Transform survey data to and from Keyhole Markup Language (KML) format.
Transform and translate data between a set of pre-defined coordinate systems.
10.2.2.1.2. Legacy format to and from AIXM transformation
As the AIMMS2 system is implemented and becomes standard, there will be a need to interface
with those systems that do not yet use AIXM. When conversion to AIXM is not available, the
Preliminary ConOps AIMM S2 May 2012 Page 46
ACS will convert data to and from AIXM. Since legacy data exists in a variety of formats, these
transformations will require case by case analysis. The ACS will transform the SAA and airport
data into AIXM and back as required to interface with these legacy AIM systems.
10.2.2.1.3. AIXM to Human-Readable Format Transformation
10.2.2.1.3.1. Legal Definition Service
SUAs are currently defined using a free text “legal definition” in addition to a graphical
depiction. The problem with free text is that this often leads to ambiguous descriptions,
transcription errors, and the same feature being described in different ways. The ACS legal
definition service will translate AIXM into standardized English-language descriptions. The
benefit of this service is that the legal definitions will be unambiguous, consistent, and accurate.
For AIMMS2, only the SUA systems will use the legal definition service but this service will be
extensible and generate legal definitions for other aeronautical objects as needed. This service
will incorporate a business rules interface where a user can “program” the system to associate
terms and phrases with specific AIXM objects without needing to rewrite the service itself.
10.2.2.1.3.2. AIXM to Human-Readable Format Transformation Service
In addition to the structured SAA legal definition, users may want to view data in other human-
readable formats. This is especially the case for NAS users that are non-technical and therefore
would not be familiar with AIXM. Decisions need to be made regarding how AIXM should be
represented in plain language. However, it should be consistent across all tools that use AIXM;
the format for representation could take many forms, from a table of attributes to a narrative
10.2.2.1.4. Archive Data Transformation Service
The Archive Data Transformation Service will transfer data in the operational databases to the
data warehouse. Any change to a record in an AIXM feature table triggers the database to copy
the new feature time slice to the corresponding AIXM feature archive table along with change
log information such as the nature of the change (e.g., baseline insert, perm delta,
decommissioning, etc.), the timestamp of the change, and the user requesting the change.
As mentioned in the Data Warehouse section 10.1.2.3, additional capabilities for automated and
ad hoc archiving will enable the recording of change histories for records in AIXM object tables
and SAA Operational Repository schedule and status history to the archive. The Archive Data
Transformation Service will add change log information, as done for the AIXM feature archive
tables. Additionally, it may need to translate a changed database record into an altered database
schema in the data warehouse or provide additional indexing to enhance analytical query
capabilities and efficiency.
10.2.2.2. Data Verification Services
Before data can be integrated into the ACS data stores and provided to the NAS it must first be
verified ensuring that it comes from the appropriate authoritative source, that it is in the correct
Preliminary ConOps AIMM S2 May 2012 Page 47
format, makes logical sense, and is complete. For the ACS, data verification will be performed
using a business rules verification service and an AIXM schema verification service.
10.2.2.2.1. Business Rules Verification Service
The verification of the data will occur both internally and externally to the ACS based on
specified parameters that sufficient data verification has not occurred. The determination of
whether or not the data will pass through the business rules verification service will be pre-
defined based on the external data input mechanisms. If the data requires verification, it will be
processed using a combination of a business process management service and a business rules
10.2.2.2.2. AIXM Schema Verification Service
The AIXM schema verification service verifies that the data provided as AIXM are in the correct
format. Data that passes the AIXM schema verification can continue on for further processing or
update in the database. For data that does not pass AIXM schema verification, the system will
generate an exception report identifying what part of the message failed verification.
Identification of the part of the AIXM message that failed verification provides the source of the
message with the information required to restructure the message correctly ensuring it will pass
verification in the future.
10.2.2.3. Airspace Conflict Resolution (Deconfliction) Service
The Airspace Deconfliction Service supports the airspace conflict resolution capability. As
discussed in Section 4.3.1, the airspace deconfliction capabilities within ACS ensure that the
creation or scheduling of special activity airspace does not conflict with of other airspace
restrictions, definitions, or reservations. This service performs the deconfliction analysis for the
airspace definition or schedule requested. The deconfliction service will analyze all airspace
definitions and schedules stored in the system and identify any areas where a conflict exists.
The service will generate a report detailing any conflicts and the airspace with which the request
is in conflict. This service will also identify if the conflict is permissible or non-permissible as
some conflicts are not allowed by policy and others are permitted with a requirement for the
involved parties to be made aware of the conflict. Further details regarding airspace conflicts are
provided in the NSAAP Functional Requirements Document.
10.2.2.4. UUID Management Service
AIMMS2 will be integrating data from and providing data to many systems and uniquely
identify data elements from origination to dissemination, throughout its entire ‘life’ cycle. One
approach is to use a UUID, a 16-byte hexadecimal number that is linked to the data. The
generation of identical UUIDs by two separate systems is nearly impossible due to the extremely
large number of ID numbers generated and the low chance probability involved.
Therefore, by tagging data with a UUID one can identify the data as unique from other data from
other sources. This also supports the requirement to ensure that the data provided comes from
the authoritative source of the data as data will be assigned a UUID at origination and will be
Preliminary ConOps AIMM S2 May 2012 Page 48
tracked with this UUID throughout its' lifecycle. The ACS will contain a UUID Management
Service to automatically generate a single or multiple UUIDs to tag the data when originated and
mechanisms and track any UUID throughout its lifecycle.
10.2.2.5. Identity Management Service
The identity management service supports the Data Security Capability described in section
4.3.6. Data and information management requires that the data is secure and changes to the data
are only made by the appropriate authoritative sources of that data. In addition, due to the
nature of some of the information provided, not all users will have access to the full set of
information. For example, some of the information pertaining to SAA schedules could be
construed as a risk to National Security, and thus only those individuals with the need and
authorization to know are privy to that information. Therefore each user will have different
authority congruent with their needs and functional roles.
To support this requirement for filtering of data based on the individual user and their
operational role, the AIMMS2 system will uniquely identify users and enforce their individual
user authority. The new system will also uniquely identify connected systems and enforce the
authority of those systems. This functionality will require both a user identity management
capability and a system/interface identity management capability.
10.2.2.5.1. User Identity Management System
Management of individual identities and roles is functionality common to many information
systems. As such, there are numerous Commercial off-the-Shelf (COTS) tools available for
identity management. Many of these tools utilize Role-Based Access Controls (RBACs) to
determine user permission, meaning the role of the user defines what information and
capabilities they can access. For the ACS, a role-based identity management system will be
required. In addition, the identification of an individual user’s home facility will also be
information required to determine the individual’s authority. This is highlighted with an
example from SAA scheduling: For the SAA scheduling process each Air Traffic Control
facility is responsible for a subset of all Special Activity Airspaces and they can only approve
schedules for those airspaces for which they are the controlling authority. So in addition to the
role of an airspace approving authority, the system must determine the individual facility of the
user to identify the airspaces for which they can approve schedules.
The SWIM group of the FAA is investigating the use of an enterprise User Identity Management
System for systems adhering to SWIM standards and operating on the NAS network. AIM may
be able to leverage parts of or all of this functionality to meet the ACS user identity management
requirements. Any functionality required for the ACS, but not provided by SWIM will need to
be supported by the ACS. (Further details on the SWIM Segment 1+ activities are provided in
10.2.2.5.2. System Identity Management System
The ACS must also identify systems that access the ACS and enforce the authority of those
individual systems. This will be supported by a System Identity Management System. The
AIMMS2 system will make use of a SWIM-provided system identity management. The SWIM
Preliminary ConOps AIMM S2 May 2012 Page 49
Segment 2 FRD details the certificate and key management capabilities proposed for SWIM
Segment 2. If provided, the ACS will leverage these capabilities to uniquely identify and
10.2.3. Information Exchange Service
Information exchange capabilities as detailed in Section 4.5 support the exchange of digital AI to
all required NAS users and NAS systems. The information exchange capability supports a
number of ways in which the information can be provided to users. The various ways in which
the information can be provided allows the information and method of exchange to be tailored to
the individual needs of the user or system and thus streamlines the information acquisition
process. Users will be able to access information provided by the ACS through the OSS,
whereas NAS systems will be able to access the information exchange capabilities through direct
connections to the exchange services listed below via the SWIM infrastructure. The information
exchange services include a data mapping service, data query service, feature portrayal service,
metrics service, and data update notification service.
10.2.3.1. Data Mapping Service
Most aeronautical data can or must be portrayed in a geo-referenced format for navigation
purposes. The Airport and SAA information that will be provided by the ACS is no exception.
In addition, exchange of this information in a spatially-referenced manner provides further
context and information to the users of the information. For example, being able to visualize the
location of a Special Activity Airspace in relation to a user-defined route can allow the user to
make decisions regarding the possible flight paths.
10.2.3.1.1. Web Map Service (WMS)
The OGC WMS interface standard will support this geo-referenced information display
capability for the AIMMS2 system. The OGC WMS dynamically produces geo-registered map
and chart images from geographic information provided by the ACS (and potentially other
sources), along with reference data such as aeronautical charts. The WMS can also support an
optional capability to provide information about a selected feature on the map. The maps from
the WMS are provided as layers which can be overlaid and viewed simultaneously.
10.2.3.2. Data Query Service
In the current environment, users receive AI via hardcopy publications, digital media distributed
via post or online, and assorted other sources. This information is not tailored or sorted to meet
the needs of an individual, but instead to meet the needs of the whole. The user must sort
through the mass of information provided to find the elements pertinent to their needs. To
provide tailored AI, the ACS will support user-defined querying, filtering, and sorting of AI to
more specifically meet user needs without extraneous data ‘clutter’.
Preliminary ConOps AIMM S2 May 2012 Page 50
10.2.3.2.1. Web Feature Service (WFS) with Filter Encoding
The OGC WFS Standard combined with the OGC Filter Encoding Standard (FES) will support
these querying, sorting, and filtering capabilities for the ACS. The WFS provides the ability to
access aeronautical features and properties from the database based on constraints defined by the
user in the query request. The FES enhances the capabilities of the WFS to provide more
complex filtering and querying capabilities based on spatial, temporal, comparative, and any
combination of these constraints.
The WFS standard also supports service discovery operations and operations to manage and
store customized queries. Discovery operations provide information on the capabilities of the
service and describe the information types that can be queried. Through the WFS, users can
create and store queries, view stored queries, review descriptions of stored queries, and delete
stored queries. The storage of custom queries on the WFS allows these custom queries to be
reused by the originator or other information consumers.
10.2.3.3. Feature Portrayal Service
Styling of maps and map feature data is a key characteristic of cartography and a requirement for
aeronautical maps and charts. In the current environment many users receive the AI required to
operate in the NAS through aeronautical charts and publications. To allow users to continue to
receive the aeronautical data in a format with which they are familiar, the ACS will support
representation of the feature data by a Feature Portrayal Service (FPS). The FPS will provide
data symbolization in a manner that is consistent with the aeronautical charts and other products
that are published to support air navigation, thus enhancing the usability of the system. In
addition, as each type of chart has its own specifications regarding charting rules and symbols,
the system will be designed to support representation of the data in multiple standard symbology
formats. The users will be able to choose from this predefined list the symbology format they
desire for portrayal based on user-familiarity or as need dictates. Additionally, the use of the
FPS standard for defining the portrayal of aeronautical products will allow users to easily define
their own representation styles as the need arises. This will facilitate access to desired AI by
future consumers of the ACS.
The charting symbols supported within AIMMS2 systems include ICAO standard symbols, high
altitude and low altitude chart symbols, and Controller Chart symbols. The ACS will not provide
automatic production and replication of navigation charts. This activity requires the expert skills
of a cartographer.
10.2.3.3.1. Styled Layer Descriptor and Symbology Encoding Specification
The OGC Symbology Encoding Specification (which supports styling of features based on
individual attributes) combined with the OGC Styled Layer Descriptor (SLD) profile (which
describes how the standard language provided through the Symbology Encoding can be applied
to a WMS or WFS) will support the user-defined symbolization of feature data for the ACS. A
key characteristic of the combination of these two standards is that multiple Symbology
Encoding definitions can be created to symbolize the same data. This allows the user to choose
Preliminary ConOps AIMM S2 May 2012 Page 51
the symbology most relevant to their needs. Other systems can also query and access the SLD
and Symbology Encoding to use for representation of ACS data on other NAS systems.
10.2.3.4. Data Update Notification Service
In the current environment AI is distributed through scheduled publications. For example, data in
NASR is made effective based on Aeronautical Information Regulation and Control (AIRAC)
cycles and users download the full set of data (including both old and updated data) on the
AIRAC dates. In this environment, users also receive notification of changes to AI through daily
National Flight Data Digest (NFDD) publications. For SAA schedule data, users receive updated
information by logging into a web site that provides schedule updates. When changes to SAA
information meet certain requirements, such as a schedule change on a short notice, then a
NOTAM will also be issued. The myriad of disparate methods by which users access updated
AI significantly complicates AI exchange in the NAS.
The ACS will update and streamline the way users are notified of changes to the information.
Ideally, updates to AI should be provided to users and NAS systems from a single source, via
digital means, and include only the needed or desired information. This reduces the bandwidth
requirements for digital transmissions and highlights the relevant information changes for the
user. In addition, these updates should only be provided to those users that require or desire the
information and not the entire user community.
The ACS will include a notification service that will provide users with single-source airport and
SAA information updates thus reducing the user workload gathering AI updates and eliminating
many redundant or unnecessary notifications. These update notifications will include only the
information that has been modified, and include a link back to the source data to enable retrieval
of the full feature definitions if required. Users and NAS system administrators will be able to
specify their needs through a subscription/publication capability and receive only those updates
available within their defined parameters. The SWIM messaging infrastructure will be employed
providing a direct connection from data source to their NAS systems. External users can specify
other notification methodologies such as email, Cellular SMS (text) messaging, or other services.
10.2.4. Geodetic Calculation Service
Geodetic calculations are used to determine locations (geodetic coordinates) on the earth based
on reference locations and bearings and distances from the reference locations and are
calculations commonly used by surveyors to create and verify airport survey data. Geodetic
calculations are also used in the development of procedures and aeronautical charts. The
National Oceanic and Atmospheric Administration's National Geodetic Survey provides
standards for geodetic surveys, the base equations for geodetic calculations, and also is the
authoritative source for spatial data defined using their National Reference System. The FAA
primarily uses nine geodetic calculations based on the two NGS base equations of forward and
inverse. These nine geodetic calculations are Forward, Inverse, Segment/Segment,
Bearing/Bearing, Segment Distance, Circle Bearing, Circle/Circle, Segment Bearing, and Airport
Preliminary ConOps AIMM S2 May 2012 Page 52
As these calculations are regularly used to verify aeronautical survey data and are used in the
development of procedures and aeronautical charts, they will need to be supported in the ACS.
Geodetic calculation capabilities will be provided by the Geodetic Calculation Service of the
ACS and will include the nine geodetic calculations used by the FAA to support data verification
and information creation requirements. The service will replicate the functions contained in the
windows-based COMPSYS 21 geodetic computation software.
10.3. Business Services
Business services provide functionality to support the data and information validation and
verification functionality required for AIM to provide AI to systems and users. These business
services include the Business Process Services (BPS) and the Business Rules Services (BRS).
The business process service is used to define the process steps the aeronautical data must follow
prior to dissemination. The steps are standard processes that are currently managed mostly
manually but can be supported through automation to ensure the appropriate steps are followed.
The business rules service integrates directly with the business process service at the verification
step ensuring that the data has passed verification before it can proceed on to update in the
A business process is a collection of tasks and activities that support a business goal often
referred to as workflow. BPS ensures that data received by the ACS from the authoritative source
is validated and verified prior to implementation in the aeronautical data store and dissemination
to users. The BPS ensures this through enforcement of requisite data processing steps. The
system will be used to facilitate activity flow throughout an entire business process, automate
many activities to improve efficiency, and monitor process activities for transparency.
The National Flight Data Center group of AIM is responsible for many of these manual
processes which can be partially or fully automated, thus streamlining the tasks and automating
adherence to quality control requirements. Even though the individual workflows may be unique
for each information type, they often involve similar steps such as data receipt, draft data storage,
data validation and verification and culminate with update in an AIM Data store.
For AIMMS2 many of the business processes for SAA and airport data processing will be
automated and streamlined using the business process service. The individual processes that will
be automated are discussed in Section 10.3.1.3. The Business Process Execution Service (BPES)
is the part of the BPS that actually regulates the adherence to the workflow. The Business
Process Management Service (BPMS) is the component of the BPS that allows an analyst to
create new and modify existing data workflow.
The BPES is the part of the BPS that executes the workflows modeled through the business
process management service. For each workflow some development will be required to develop
the web page/front ends for the users involved in the process. The BPES will direct users
through the process and ensure that each step in the process is followed and completed prior to
Preliminary ConOps AIMM S2 May 2012 Page 53
moving on to the next steps. It will also automate many of the steps in the process such as
dissemination of email notifications, calls to web services, and generation of verification reports.
The BPMS allows an analyst to create, model, and modify the individual workflows for
aeronautical data processing. This capability will support the changes that occur to data
processing as new requirements are identified and processes are further streamlined. In addition,
this capability will support the integration of new types of information in the future through the
addition of new workflows. Business processes modeled by analysts are stored in a standard
language called the Web Services Business Process Execution Language (WS-BPEL). Using
this standard, processes can be developed to reference and exchange data with other web services
to support the functionality required at each step. For example, using this service orchestration
capability BPEL a user can model the process to request data verification from the business rules
service, geodetic calculation from the geodetic calculation service, database updates through the
WFS-T and so on. The integration of a BPS with an SOA highlights how the services are
reusable as the same verification service, data collection service, and other services will be
reused for the myriad of workflows contained in the system.
10.3.1.3. Business Processes
This section identifies the individual workflows that will be supported in the ACS. These
business processes will be stored in a business process store and accessed by the BPMS for
required changes and the BPES for execution.
10.3.1.3.1. Airport Data Business Processes
Airport data business processes are a set of comprehensive activities associated with the
collection, verification, and storage of airport data. Airport data business processes include
airport survey data verification processes and airport data change requests processes. Types of
airport data processed include infrastructure such as airports, runways, obstacles, and
navigational aids. NFDC performs airport data business process activities to fulfill their role as
managers of the collection, verification, storage, and dissemination of AI within the FAA.
10.3.1.3.1.1. Airport Survey Data Verification Processes
Airport survey data verification processes include the submission of survey data by third party
surveyors and contractors. The survey data is stored in a database and labeled according to its
status. Airport survey data is independently verified by NGS for completeness, proper
formatting, and adherence to established verification guidelines. NFDC also verifies airport
survey data by comparison of existing and calculated data to new airport data. Resolution of any
errors found during verification is attempted through coordination with relevant entities, and the
survey data is ultimately updated or rejected based on feedback during coordination. Results of
survey data verification are provided to National Flight Procedures Office (NFPO) for
assessment. The database activation is set and modified as needed based on feedback from
Procedures or Flight Inspection. On the database activation date, the status of the existing survey
data is changed to historical, and the status of the new survey data is changed to active and made
available for dissemination.
Preliminary ConOps AIMM S2 May 2012 Page 54
10.3.1.3.1.2. Airport Data Change Requests Processes
Airport data change requests processes include the submission of data change requests for public
use or military airports. The appropriate Military Flight Standards Agency must review data
change requests submitted for military airports, and NFDC must review data change requests for
both public use and military airports. If the type of airport data is from a survey, the data is
processed according to the airport survey data verification process described in the previous
section. The processing of all other airport data includes verification that the submitter is the
authoritative source, verification by comparison of new data to existing data, coordination to
resolve errors as needed, database storage, and dissemination.
10.3.1.3.2. SAA Business Processes
10.3.1.3.2.1. SAA Creation and Review
To ensure that SAA definitions are accurate and meet the needs of all stakeholders before they
are submitted to their designated database, there are multiple development and review steps. The
SAACE and Review and Comment System (RACS) tools follow these business processes to
guarantee that the data provided to users and systems is complete and accurate.
Depending on the type of SAA that is being developed, there are different business processes
that must be followed. These include informal review and coordination between the airspace
proponent and the FAA, creation of the formal proposal package, and formal approval and
certification steps within the FAA. The SAACE, with a staging database that is used for working
data, will support the creation of a preliminary digital definition that is used during coordination
and discussion, followed by the formal digital definition stored in the ACS. The RACS will
support the coordination and approval process that the airspace must follow.
10.3.1.3.2.2. SAA Scheduling Business Processes
There are multiple scenarios that need to be accounted for when requesting and using SAAs.
These include the actual scheduling procedure, schedule amendments both before and while the
airspace is being used, schedule cancellations, and schedule activation/deactivation. The type of
SAA and the identity of the user also play a role in the business processes that must be followed.
A request to use a SUA (schedules/altitudes) is submitted by a DoD, or other, airspace
scheduling agency. An approving specialist at the controlling agency (usually an Air Route
Traffic Control Center (ARTCC)) is notified of a pending schedule. The approving specialist
approves, denies, or performs additional coordination with the scheduling agency based on the
conditions surrounding the specified airspace during the requested time period. The scheduling
agency will be informed of the decision and, if required, a justification for denial.
The BRS will be integrated with the BPS to support verification of data by AIMMS2. The data
required to be verified will follow the pre-defined workflow for the specific information as
described in section. One of the steps the data will be required to traverse will be a verification
step. The Business Rules Verification Service (BRVS) will perform this verification. The BRS
Preliminary ConOps AIMM S2 May 2012 Page 55
will also have a mechanism for modifying and creating new business rules to adapt to changes in
AI processing requirements. This will be supported by the Business Rules Management Service
At the data verification step of the workflow the business process execution service will identify
the data that requires verification. It will then request that the BRVS determine the appropriate
business rules for the data. The BRVS will receive the data to be verified from the BPES and the
appropriate business rules from the business rules store. Upon receipt, the BRVS will evaluate
all the data for adherence to the business rules. A verification report will be generated by the
BRVS and provided to the authorized users during relevant activities throughout the process.
This verification report will identify the data that failed verification and it will also indicate
which business rule was broken resulting in the error. The BPES will ensure that any data that
does not pass verification cannot be updated in the database and thus it must be corrected prior to
proceeding to the next step.
The business rules management service is the component of the BRS that will allow an analyst to
create new business rules and modify existing business rules. It will also be used by an analyst
in combination with the BPMS to identify and tag data being processed through the BPS with the
appropriate business rules as required for data verification. The BRMS will be required to
support versioning of business rules and storage of historic business rules so that the analyst can
access the rules used to verify historic data if required. It must also ensure that the business rules
used to verify sets of data are not in conflict with each other.
10.3.2.3. Business Rules
This section identifies the types of business rules that will be applied to the data and business
processes. The business rules will be accessed by the Business Rule Verification Service for
verification of aeronautical data and by the Business Rules Management System for updates and
AIMMS2 will verify data according to a pre-defined set of business rules. There will be general
data verification business rules, which are logical rules about the data, common AI business
rules, and business rules specific to the information type or feature being examined. Logical
rules indicate that the data makes sense, for example, ensuring that a start time is before an end
time, or that an airspace geometry definition is a well-formed polygon. Common AI-specific
business rules will be applicable to all AI that is managed by AIMMS2. Examples of each of
these three types of business rules are provided below.
Logical Business Rules:
The start time of a schedule must be prior to the end time of the schedule.
All times stored in the database must reference Coordinated Universal Time (UTC).
Preliminary ConOps AIMM S2 May 2012 Page 56
Common AI Business Rule:
In the US, the transition from Mean Sea Level (MSL) to Flight Level (FL) is at 18,000
All latitude and longitude values must be within the following ranges:
Latitude Range: -90<DD<90; 0≤MM<60; 0.0≤SS.S<60.0
Longitude Range: -180<DDD<180; 0≤MM<60; 0.0≤SS.S<60.0
AI Specific Business Rules:
Airport data specific business rules:
o The reported airport elevation must be the highest point on all runways.
o For each low runway end designator value, a corresponding high runway end
designator value must be reported. (i.e. If a runway end designator value of “9” is
reported, then a runway end designator value of “27” must be reported.)
o Each reported Obstacle Identification Surface (OIS) surface type must correspond
with reported OIS zone type.
o Each runway end designator value must be between 1 and 36.
SAA data specific business rules:
o Restricted Areas have no limits on the upper altitude.
o MOAs have an upper altitude limit of 18,000 feet MSL.
Initially these business rules will be used for verification of airport and SAA data. Specifically,
each workflow and corresponding business analyst that checks the verification will recognize
and use a subset of the business rules stored in the system. NFDC verification process business
rules are used to direct calculations for certain data elements, compare reported data to calculated
data, and compare new data to existing data. NGS verification process business rules check
airport data for completeness, proper formatting, and adherence to NGS verification guidelines.
SAA processing business rules are used to ensure SAA static definitions follow FAA guidelines
for geometry, altitudes, and times of use. In the future, all of the rules that are not information-
type specific will also be applied to other AI added to the ACS.
Data business rules in AIMMS2 will be stored in the business rules store connected to the
BRVS. Business rules will direct system functions and prompt the system to access the
appropriate business rules from the business rule store during appropriate verification activities.
The use of business rules in AIMMS2 will significantly improve the efficiency of processing
aeronautical data by replacing current manual methods with automated methods.
The application layer is the layer of the system with which the users will interact. As such, it
will provide the users access to the functionality supported by the Service Layers, Business
Preliminary ConOps AIMM S2 May 2012 Page 57
Layer, and Data Layer. Four main sets of UIs will be developed to support access to the
different capabilities of the system based on the roles of the users. These four sets of interfaces
include a data and AI interface for general user access to the data and system functionality, the
digital data capture tool applications, an analyst console for access to the business services, and
an administrator console for access to the system for maintenance and monitoring functions. The
ability of users to access each of the applications and the data and functionality provided by
those applications will be determined based on the functional role and associated permission of
the individual users. To support access control, each application will be integrated with the User
Identity Management System described in Section 10.2.2.5.1 and will require sign on for access.
Currently, users access AI through a number of methods and from multiple sources. These
sources include websites, portals, paper publications, PDFs, and CDs of data. A single data and
AI interface access point for all airport and SAA data will be provided as part of the ACS. This
access point will be the OSS of the ACS. Some of the websites and portals likely to be
subsumed by the OSS are ones accessed for SUA data (sua.faa.gov), Temporary Flight
Restrictions (tfr.faa.gov), Flight Aeronautical Data Distribution System (nfdc.faa.gov/fadds), the
National Flight Data Center (nfdc.faa.gov), and AVN Data Sheet (avnnet.jccbi.gov). Some other
sites which may be included are those for Telephony
(faa.gov/air_traffic/publications/atpubs/CNT/3-3.htm), Airport Master Records and Reports
(gcr1.com/5010web), PilotWeb (pilotweb.nas.faa.gov), NASE (nase.amc.faa.gov), NOTAMS
(notams.aim.faa.gov), and Airport Location Identifiers
The OSS will also provide users with access to services and data stored in the AIMMS2 system.
Some NAS users will be able to access some functionality via SWIM connected NAS systems
that leverage the service layer of the ACS. However these may not enable all capabilities of the
ACS. Thus, the access to AIMMS2 capabilities through the OSS is critical to maximize the
utility for all users. The OSS will also provide a secure web portal on the public Internet,
dramatically increasing the number of users that have access to AI provided by AIM.
10.4.1.1. OSS General Use Functions
A number of the functions that will be required on the UI are capabilities common to standard
information exchange websites. These are the general use functions and include links to a sign
in page, a help page for assistance navigating the page, a page to manage user account settings, a
link to request a new account, links to more information about the portal and the portal owners,
and a site map.
To facilitate ease of access, and truly create an OSS, the portal will also provide links to other
relevant AIMMS2 services including the digital data capture tools, the business analyst UI, and
the system admin UI.
10.4.1.2. OSS Search
Through the OSS, users will be able to search the current and historic AI contained in the ACS.
Querying will be supported through a query pane, where users can either perform pre-defined
Preliminary ConOps AIMM S2 May 2012 Page 58
common queries that will be built into the application, or they can customize their own query.
Customized queries and query results will be able to be saved and shared with other users
through the OSS interface. The query functionality will be provided by the ACS Web Feature
Service with the Filter Encoding Standard Query Service. Using the query service users will be
able to access all functionality supported by the WFS FES service including querying by spatial
constraints, by temporality, attributes, attribute values, geometries, and any combination of these
types. Users will be able to refine queries to further investigate results returned to them.
Query results, and other AI provided by OSS, will be available in both human-readable format
and as AIXM data. To support display of information in a user-friendly manner, the OSS will
leverage the AIXM to human-readable text translation service described in Section 10.2.2.1.3.
The user will be able to sort query results by any of the attributes displayed and filter the results
based on feature type. To receive more information on the individual features returned, the user
will be able to select a feature and obtain additional in-depth information about that feature.
When a query result has an associated geometric object, that object will be displayed and
highlighted on a chart display (See Section 10.4.1.3 for more information on the OSS map
10.4.1.3. OSS Map
A main component of the OSS will be a large map for visualization of all ACS AI that contain
geometries. This chart will allow users to view the AI in a geo-referenced display. The OSS map
will also be customizable by the user to support their individual AI needs. The main
requirements for the OSS map are as follows:
The map will display all AI that contains geometries
AI will be displayed as an overlay on the appropriate reference charts to provide context
Users will be able to filter information display including AI query results on maps
The map will display geodetic calculations performed by users
User will be able to choose the symbologies and formats used to portray the AI
The map will support common viewing functionality, such as pan, zoom, caching, and
The map will support common cartographic functions such as redlining the display.
Users will be able to perform geodetic calculations on using position information or
aeronautical features locations
To provide the base charts and mapping of the aeronautical data, the OSS will access and display
the ACS Web Map Service. In addition to the ACS WMS, the OSS map will also provide users
with access to, and the option to choose to view, other relevant Web Map Services and Web
Feature Services provided by external systems as layers. Two examples are street maps and
hydrology features, which are used as references in creating SAAs. As other NAS systems start
providing OGC-compliant map layers the ACS can include them in the OSS view as well.
Through the map interface, users will be able to select the WMS layers they desire to have
displayed, allowing the user to customize the map display.
Preliminary ConOps AIMM S2 May 2012 Page 59
Display of query results will be rendered and displayed by the Web Feature Service of the ACS.
The query results will be highlighted and linked to the underlying feature information. By
selecting individual features, users can access more information regarding that feature. This is
the same capability that is provided in the OSS search function. The ability to choose the
symbologies and formats for the rendering of AI will be supported by the Feature Portrayal
Service of the ACS described in Section 10.2.3.3.
The geodetic calculations capability will be provided through integration with the Geodetic
Calculation Service of the ACS described in Section 10.2.4. Users will be able to select which
geodetic calculation to perform and be able to insert locations, bearings and distances to use in
geodetic calculations or select individual aeronautical features on the map to be used in the
calculations. A graphic representation of the geodetic calculation will be included on the map as
the user is defining the calculation request and after the calculation has been performed to allow
users to interpret the results of the calculation. Results of the calculation will be provided to the
user in text and graphic format.
10.4.1.4. OSS Data Download
In addition to being able to access and view information contained in the ACS, users will also be
able to download query results and data for individual features. The OSS will also support
download data in multiple formats, including AIXM and human-readable text. Features with
geometries will be also able to be downloaded in formats including, but may not be limited to,
Geography Markup Language (GML), KML, and ESRI Shape file format, to support use in other
10.4.1.5. OSS Information Subscriptions
Through the OSS interface, users will be able to subscribe to the information provided by the
ACS. This capability will leverage the Data Update Notification Service described in Section
10.2.3.4 and will provide users with the most up-to-date AI, without requiring them to
investigate for themselves if changes have occurred. Users will be able to set the parameters of
their individual subscriptions, including the subset of AI to include in the subscription, the
format of the information provided, the method by which they would prefer to receive their
subscription, and the frequency of update.
10.4.1.6. OSS Metrics Analysis Page
Based on their operational role, certain users will be provided with enhanced functionality and
data analysis capabilities through the metrics and data analysis page of the OSS. Through the
metrics analysis page users will have access to historic data, metrics definitions, and the metrics
analysis results. Users will be provided with the ability to view and download NAS performance
metrics results as raw data or in report format. This capability will be supported by the ACS
10.4.1.7. OSS Data Dictionary
The ACS will significantly increase the numbers of users provided with AI as it is a publicly-
facing web portal, some users may be unfamiliar with the gamut of information provided by the
Preliminary ConOps AIMM S2 May 2012 Page 60
service. On the OSS users will be provided with a data dictionary detailing the meaning of the
information elements provided, their relationship to other information and data, the usage of the
element, and other information required to provide a user with the resources to understand the
10.4.1.8. OSS Service Registry Information
Users will be able to access the functionality of the new AIMMS2 system through the OSS while
NAS systems will be able to access it through the Service layer. User access will be facilitated
using a web interface. System access the service layer is more complicated and will require use
of the SWIM Registry and Repository. This will also require a Service Level Agreement
between AIM and the ‘owner’ of the connecting system(s). Details regarding how to access
ACS services for external systems will be provided through a link on the OSS.
10.4.2. Analyst UI
Analysts will have access to the business services functions through a dedicated UI. This
interface will include access to the BPMS and the BRMS.
10.4.2.1. Business Process Management UI
The business process management (BPM) UI application will provide a UI for a business analyst
to view, implement, change, and monitor business processes and create reports describing
business process performance. Business process performance reports will capture data about the
execution of the processes. For example, a business process report could identify the step in the
process that takes the most amount of time. These reports can be used to identify areas with
room for improvement in the process.
The application will also provide UIs for external parties involved in executing processes. For
example, a UI would be required for an AIM data specialist to receive verification reports, verify
data, and commit the data to the database. Each individual that is part of the process workflow
would have a UI to assist them fulfilling their operational role.
10.4.2.2. Business Rules Management UI
The business rules management (BRM) UI application will provide a UI for a business analyst to
view, implement, manage, and change business rules. It will also provide a mechanism for users
to evaluate if a business rule conflicts with other rules stored in the system.
10.4.3. System Administration UI
Administrators and users will perform their administrative tasks through a UI that enables the
management of system parameters and application modules. A user authorization feature will
allow administrators to grant or deny access to specific application modules and data creation
authority on a per-user basis based on the operational role of the user.
The interface will also provide convenient tools for administration and maintenance of the
component databases and services in the ACS. This toolset will include database performance
Preliminary ConOps AIMM S2 May 2012 Page 61
monitoring and tuning, managing database access authority, database cleanup, and data
extraction operations. It will also provide access to system logs generated from system
monitoring functions. These logs will be able to be searched and analyzed for auditing purposes.
10.4.4. Digital Data Capture Tools
Digital data capture tools support the digital data capture capability for the ACS through receipt
of digital data directly from the authoritative source, through automated means, using design
tools and capture systems. Only authorized data originators will have access to the digital data
capture tools that are used to create aeronautical data, thus ensuring capture of digital
aeronautical data directly from the authoritative source. The digital data capture tools will be
designed to send the data collected in those systems directly to the ACS for further processing (if
required) and storage. As mentioned in the digital data capture capability (Section 4.2.1), the
capture of the data directly from the source will eliminate transcription errors caused by
manually input data. The data capture tools that will be integrated with the ACS within AIMMS2
are listed below.
10.4.4.1. SAA Creator Editor
The SAA Creator Editor (SAACE) tool is a new system that facilitates the establishment of
special airspace and is documented in reference. This tool provides both geophysical and
temporal resources that allow authorized personnel to create detailed, three-dimensional, digital
definitions of SAA and submit them to the AIMMS2 system.
10.4.4.2. SAA Review and Comment System
The next data capture tool is the SAA Review and Comment System (RACS), which is also
documented in reference. The RACS will allow users to enter and view comments about a
candidate airspace design. It will also support the workflow for an airspace project as it moves
through different stages in the review and approval process. The RACS provides a simplified
alternative to the SAACE when users do not need to make changes to the airspace being
10.4.4.3. SAA Scheduling Tool
Finally, there will be a schedule entry and approval tool, which is documented in reference. This
tool will be the ACS analogue of SAMS for scheduling of SAAs between a Using Agency and a
Controlling Agency. Through this tool users will be able to enter requests to schedule SAA, and
to approve requests. Once a schedule has been coordinated between the two agencies and
approved by the Controlling Agency, it will be provided to the ACS and disseminated to the
10.4.4.4. Airports Geographic Information System
AGIS is a web application that supports the digital capture of airport survey data and Airport
Layout Plans (ALPs) for the FAA. AGIS will be comprised of two modules to support these
functions. The survey data collection module will manage the process for submitting, verifying,
and providing airport survey data to the FAA. A second module will use surveys to support the
Preliminary ConOps AIMM S2 May 2012 Page 62
creation, approval, and maintenance of electronic ALPs. AIM initially developed AGIS using its
infrastructure to support the operations and functional requirements of Airport Engineering
10.4.4.5. NFDC Applications
NFDC currently processes change requests and inquiries related to airport data and products
through a series of web applications referred to as NFDC Applications. These applications
currently provide minimal workflow capabilities to users and capture airport-related data through
free-text fields and document attachments. ACS will modernize NFDC Applications to digitally
capture airport data elements and automatically update operational databases. These modernized
web applications will eliminate NFDC manual processes by automating workflow using the
business process service and leveraging standardized web services to exchange and update data.
10.5.1. FAA Network Infrastructure
The FAA network infrastructure is divided into two components – the Mission Support network,
and the NAS Operational IP network. Systems directly involved in air traffic control reside on
the NAS network, while other administrative systems are located on Mission Support. Additional
consumers and providers of information, such as the military and airlines, reside on networks
which include the World Wide Web and NIPRNet. The NAS Enterprise Security Gateway
(NESG) provides a secure environment to transfer information between these networks. Since
AIM interacts with data producers, consumers, and stakeholders on all networks, the ACS will
need to communicate across the NESG. These communications will be supported by SWIM.
Based on the SWIM Segment 2 Requirements, the SWIM program is planning on providing the
messaging infrastructure required to support communication between NAS and non-NAS
systems in a SOA environment. The ACS will make use of SWIM infrastructure and capabilities
to communicate with all data consumers regardless of where the ACS hardware is located. To
fully support the ACS, SWIM must support open standards that rely on SOAP over HTTP(S),
REST, and JMS.
Preliminary ConOps AIMM S2 May 2012 Page 63