The Global AIM Blog is Retired

We will be merging this Blog with Semantech's Agile Enterprise Architecture Blog as of today, thank you for stopping by...

AIM Data in Context

One of the most daunting challenges in any IT transformation is the ability to see how all of the pieces will eventually come together - both in terms of organizational or initiative coordination as well as in terms of the eventual solution architectures. One of the challenges that we face with AIM is that traditionally AIM data has risen through the data value chain (of related architectures moving from static to dynamic) rather slowly and often in an indirect fashion. All of this will change when the family of new initiatives arising from a new AIM foundation begins to emerge. In the relatively near future, all civil aviation data will become accessible to all civil aviation IT capabilities and all their related processes.

The diagram below illustrates the point - the tiers of the architecture (which is in fact a set of federated capabilities, systems, services and organizations) roll up into a Common Operating Picture from which all those who participate in the various civil aviation processes can access - according to their respective roles and privileges. This provides centralized access control mechanisms for increased security as well as opportunities for more comprehensive data integrity control - something that will become ever more important as civil aviation processes become more automated.



Civil aviation is compromised of various data domains, temporal domains and architecture tiers, AIM underpins them all...

Copyright 2008, Semantech Inc.

The AIM Data Chain of Custody

One of the primary concerns that needs to be taken in consideration when building a generic reference model for AIM is the data chain of custody. What this refers to is how data is managed across the various steps in its lifecycle, and in many cases those steps will hand data off from one group or organization to another. Knowing from the very beginning that this is going to happen; that this will effect the integrity & accuracy of the data which eventually will be used by pilots and traffic controllers requires us to mitigate the issue up front as much as possible.

There are several key 'zones of data control,' these zones represent the most likely points at which data will pass from one system or organization to another. What makes this even more complicated is the fact that in the near future, these zones of control may not be restricted to one civil aviation paradigm (such as the FAA's NAS or National Airspace System) - the zones will become interchangeable across ICAO member states. Some of the issues may be mitigated by adoption of the AIM canonical data (exchange) model - AIXM, but not all of them will.

The reference model must therefore taken into consideration the following factors:

• How and where to evaluate data integrity near the zone boundaries.
• How to ensure accurate transformations into and out of AIXM.
• How to assign service level metrics and responsibilities to the various participants in the overall data lifecycle.
• How to design for efficiency - to ensure that critical update data reaches end-user operational systems in near-real time.
• How to design "traceability paths" into the architecture.
• How to document transformations from inception to final evolution and to trace back the core authoritative elements (and to assess each transformation against validated rules).
  

Copyright 2008, Semantech Inc.

AIM Process Mapping

In situations where many architectures must be reconciled, the ability to map between them becomes extremely important. The actual development and deployment of modernized AIM solutions will involve quite a lot of such mapping, especially in regards to managing data exchange (i.e. the AIXM model).

As one might imagine though, data architecture is not the only place where complex mapping may need to occur in order for the Global AIM community to arrive upon a common reference model.

Process is especially important to the Global Civil Aviation community given the priority focus on safety. AIM processes involve not just those associated with managing the solution itself (from an IT perspective), it also encompasses the processes utilized to gather, aggregate and validate data and then those processes used to integrate AIM data into operational Air Traffic Management systems.



Copyright 2008, Semantech Inc.

The True Scope of AIM

One of the major questions that has to be asked at the beginning of an endeavor such as this is "what's the scope?" We know how AIS is interpreted now, how it's realized across dozens of existing systems and publications, but AIM is intended to become quantitatively different. AIM as currently defined by most of the major players represents a major extension of the current AIS mission, with specific expectations regarding unified management of core data and universal data exchange. However there are still some separations in the envisioned "to be" architecture which require some consideration in regards to determining just what the scope AIM really should be.

The primary issue is the relationship between the new unified data architecture and operational management of the airspace - variously referred to as Air Traffic Management or Air Traffic Control. There are quite a few implications that come along with new capabilities such as the ones we're discussing. For example, access to near-real time data between systems on airspace modifications will make a huge difference in how airspace and flight management occurs in the future, however it also dramatically impacts current processes and potentially impacts security.

The problem we have here is by subdividing aspects of what we're talking about - CDM, SWIM, AIM we run the risk of losing sight of the synergistic issues and there will be many of them. Once responsibilities are parsed among the pieces of transformation, who will be then responsible for the whole, if we wait until the solution is completed to figure that out it will be entirely too late.

The diagram below begins to illustrate the point - the nature of the data itself is not easily separable any longer from the holistic views that will be required to manage civil aviation. When we design the new AIM can we design without understanding what that holistic picture needs to be and what the Air Traffic Management implications will be?



Copyright 2008, Semantech Inc.

Coordinating Global AIM - The Process

Coordinating a global reference model is no simple task, there are many considerations that must be accounted for. There are existing architectures, varying interpretations of existing requirements, a large group of participants - each one including their own orbit of further participants and a variety of technical approaches already at play (both in terms of architecture description and applied solutions).

There are some areas though of great similarity. We have the starting point of the ICAO Annex 15 requirements as well as a fairly universal adoption of the Unified Modeling Language (UML) in some fashion across most of the participants. The best place to start perhaps is the capture of scenarios that are common across all of those involved with civil aviation in the form of Use Cases. The tools used to capture the Use Cases are not so important as the two elements of any Use Case is a textual description and a graphic diagram - there is no need to deploy a centrally managed CASE tool to capture these. We can view these as unstructured (data) architecture support / artifacts / products (depending on your terminology). They can be captured using wiki technology.

The diagram below represents an initial visualization of how these various factors will relate to one another:



Copyright 2008, Semantech Inc.

The Global AIM Framework

There will be four core reference models as part of the AIM Global reference architecture - these should roughly corrleate to other initatives and at some point will provide specific mappings as we are updated on how the various programs are evolving. All four of these models are derived from core ICAO requirements but some of this extends beyond what has yet been identified in those standards.

The four reference models are:

1. The core Semantic Model
2. The Data Architecture Reference Model
3. The Services Architecture Reference Model
4. The Information Exchange Model (this is mostly already completed as part of the AIXM initiatives although there is some further correlation with the other architectures that might require attention)

Copyright 2008, Semantech Inc.