I agree that this is very important \[to decide] . My initial take would be for a very simple AODB. It can get a lot of data from many sources, but it should not do a lot that easily can be done outside of the AODB. Integrations should be on the outside, matching logic must be on the inside.

The term AODB is the Airport Operational Database and it suggests a particular class of application which implementation may vary from Airport to Airport. For example does it include A-CDM or AOP or TAM? Forgive me gentlemen for the acronyms, this area is replete with loads of acronyms. A name like AODB Futures is equally as good. Architecturally, the question is what is the scope in terms of business capabilities, operational processes and data flows today and in future. Has the scope been changing over time and what is the ideal. Can we describe this ideal as a reference architecture with blueprints that enable rapid implementation in several scenarios that include build and buy.

Eden will share the PID and Scott’s presentation. The content of the PID are not hewn in stone. The expectation is that you can suggest modifications to these. 

I personally struggle a bit with the AODB centric naming…

I liked the original name “Airport Operational Information Exchange” a lot. It is imho a semantic fit and from a Zurich Airport point of view exactly what we are at this time mostly interested in – an Airport standard for information exchange (between the operational airport systems). This reaches further than just AODB and doesn’t exclude RMS, D-MAN, De-icing, AOP, TAM, etc. it is system agnostic.

I guess it depends on the effective project scope we agree on, if it’s not only about AODB but rather the information exchange then I would recommend that the project name should reflect that.

What clearly is required is a discussion of scope. It is of course possible to include a lot of stuff, all interesting and necessary at an airport, but we also have to be a bit realistic of our capacity.

If what we want to do is to define a virtual AODB (for a given definition of what an AODB is) then I have no problem with an AODB centric name. Of course, if we want to do something else then the name should reflect that. Just based on the name an “Airport Operational Information Exchange” is something completely different than an AODB. And when I use the term AODB I mean the system that at its core is responsible for defining the state of a flight leg, based on a multitude of inputs. Of course, for an airport oriented AODB it will be arrival/departure state.

Many AODBs add a lot to this core functionality, most of which just as well can be on the outside of the AODB. This will include systems like FIDS, RMS, AMAN, DMAN, AOP, TAM, DeIcing, CDM, ….

All of these can of course be in the AODB, but doesn’t need to be. It is in general not a good idea to make systems more complex than they need to be. Distributed complexity is a term I often use, and I consider that a very good thing.

“Airport Operational Information Exchange” sounds like something that is used to move data between the systems. To what extent something with any real functionality is needed for this task depends on how well the systems are designed, and the general architecture.

I have enjoyed the discussion on the name, and can vouch that many US airports struggle with what exactly is an AODB, and some certainly have a negative connotation to the name.  What I have found, as Ole has pointed out, is that I end up investing time trying to describe the context of the AODB.  I tend to start with a describing it as a focus on flight data, and then go into surface management data; hence Airport Operational Data.  However, It does not, for example, include unstructured data, or finance related data, or Asset data, or does it?

AODB as a name is much more expansive than “just” flight data. The name itself indicates that it holds all sorts of data related to airport operations, from FIDS to de-ice fluid levels, from runway status to gate status. It is very easy to add things since it’s a system that sound like it could have it all. But this thinking creates bloat, and will over time make the AODB very hard to maintain. In my first AODB project Avinor bought one such AODB, which had been developed over many years and contained a lot of airport business knowledge in the included, and configurable, business rules.

Eventually the latest owner of the product, Leidos (significant company), stopped developing it. It was not really a cost effective solution.

Avinor then had to do something, and we decided to basically design our own and get IBM (developer of one of our current AODBs) to implement it. After my previous experience my thinking now is to have the AODB as small as possible, basically a maintainer of FlightLegState. There are no direct integrations to the AODB. All data come via a message bus, are picked up and injected into the AODB through a defined set of services. There are two type of services:

• Services that inject flight oriented data
• Services that inject reference data

Out of the AODB we get three types of messages:

• FlightLegState messages.
• Flight transaction that indicate if a flight oriented input transaction actually changed the state, and which flight leg it was matched to.
• Reference data messages as it is possible to maintain reference data in the AODB, but it is not the master of reference data.

Primarily based on the FlightLegState message we create request services (example: Flight Data Request Service v 2.0) and push applications that can push data to other systems that require flight leg data in close to real time.

Around the AODB there are three types of systems:

• Systems that just send data to the AODB without knowing anything about the AODB. Avinor example: IATA messages, Eurocontrol ATM data, radar, AMAN, ..
• Systems that just get data from the AODB. Avinor example: FIDS, Reporting, Billing, Statistics, Analytics, ..
• Systems that read data from the AODB and updates or adds data. Avinor example: BHS, Docking, CDM, RMS, ..

All of this has the flight as its core. In Avinor these systems are (mostly) connected via a very simple messaging infrastructure, Active MQ. There are no logic or code associated with the movement of messages, and they are never transformed. Smart endpoints, stupid transportation scales much better than the alternative.

Some of the architectural principles that are at the core of the Avinor solution are:

• Distributed complexity. Do not make components do much more than they need to do. Integrations are easy as long as all data is clearly defined.
• Chronological independence. Do not require multiple components to be updated at the same time.
• Loose coupling of components.
• Transform input data once to the correct, and well defined format.
• Use the same data definitions everywhere.
• Everything real time. Batching adds complexity.
• Keep it simple :-)

But there are of course other operational systems that are airport/runway/stand/de-ice/… oriented. From check in desk management to snow clearing of the runway. All of these are operational systems, and as such might be natural for an AODB.

We should probably pick up some of \[the above] principles and discuss whether they could become ACRIS principles.

For those that do not know me, I have been involved in the supply and support of the AODB’s at Heathrow and Gatwick Airports for over 30 years. 

As a few of you have stated, I do not like the AODB acronym either, Airport Management System is closer to my understanding of what these systems do, help the airport manage the operation of the airport.

Standardising of information exchange from aviation stakeholders is something that would benefit aviation in a big way, the number of interfaces to and from some AODB’s is incredible, many of them sharing something like, Flight XX123 is expected at HH:MM in a slightly different format.

Again many of you have mentioned scope, one airports AODB has many more functions than another, how far do we go in looking at some of the ‘other’ functions AODB carry out at airports?

One area where there has always been an issue, (in the airports I work with at least) is where different stakeholders have different key information to describe a flight, flight leg, flight plan etc.) (Bob will laugh as I have brought this subject up a few times in the past but do not have an answer).

For example Heathrow airport starts with a flight schedule (provided by ACL in SSIM format).

It has the Schedule date/time of operation at the host airport, the flight number, and direction (Arrival or Departure).

• The same as on the passengers ticket, the key details used by stakeholders at the airport.

Messages to and from ATC organisations (I include NATS, EuroControl in the same group here) use a call sign.

• The call sign is not included in the seasonal schedule
• The call sign is set up in a lookup table and associated with a flight,
• The communication of which flights will use which call signs is not standardised at all, they are sent vial email etc. and maintained manually
• They change a little through the season and change a lot at the Summer/Winter schedule change
• I would be interested in how other airports deal with this.

Messages to and from airlines for arrivals use the schedule date of departure from the origin airport, we call it ORGIN_STO.

• The ORIGIN_STO is not included in the seasonal schedule and may not be the same as the schedule date of arrival at the host airport.
• An AODB can calculate it using an average flight time from an airport to the host airport, not all flights have the same average flight time.
• I would be interested in how other airports deal with this.

If these key data items are not correct:

• Messages cannot be matched from ATC organisations, or from airlines, worse still messages can be matched to incorrect flights.
• Messages sent from the Airport, will be of no use to ATC or the airlines and handling agents without the correct key information they use.

If you think you have it hard, then Avinor with 43 airports also has additional challenges like:

• Need to keep track of all flights touching any of the airport, including helicopter flights and small VFR flights.
• Flights can go back and forth between the same city pair many times a day, of course using the same callsign. Shortest flight time is about 10 min. (It takes maaany hours to drive.)
• Rerouting/diversions of multi leg flights. We have multi leg flights with close to 10 legs, and they can be significantly rerouted. Especially challenging in the winter in Northern Norway.
• Need to keep track of all flights flying in Norwegian airspace above XXX feet, as we are also responsible for data to the Central Route Charging Office. This includes data bout where they enter Norwegian airspace.
• Many flights, especially helicopter and small personal airplanes, fly to/from an Avinor airport and XXX. The other end has neither an IATA nor an ICAO code.
• Keeping track of transfer and transit passengers on all airports.

All of this we solve (hopefully) in our new “AODB”, which is limited to really only being a flight leg only system.

Since we have designed it ourselves it’s important to keep it as simple as possible.

I keep asking myself where we as Airports / ACRIS have the most leverage and want to position ourselves. Will it be around defining a generic virtual AODB (on a logical level from my understanding), knowing that what an AODB comprises and should be, might differ in different contexts or is it more about providing general means and tools to help managing this “distributed complexity” which probably boils down to a defined data exchange standard.

Where I currently perceive a big gap / leverage is that there is no Airport (ACRIS) data exchange standard available for the exchange of these airport operational core data objects. One may argue that some of it is in the semantic model but it’s at this time from my understanding not a clearly defined, easily accessible artefact that would produce consistent implementations across different airports. What happens as a consequence of this is a plethora of bespoke implementations and/or other standards such as AIDX/M, FIXM extending into the core airport operations domain. We have to ask ourselves as Airports and ACRIS members if this is the development we want and whether we see value in changing this.

So one of the main questions for me remains

1. Should the priority and focus be on AODB or managing the “distributed complexity” -> defining a standard for operational data exchange?

In the context of data exchange:

1. Do Airports / ACRIS see it strategic to provide a data exchange standard for airport operations data? Or would we want other organizations such as IATA, ICAO/Eurocontrol to lead and just be involved?
2. Can and does ACRIS want to maintain such a standard? (Picking up Eden’s Input here: this is not a one off project)

The ACRIS Semantic Model (ASM) is a community product and its maturity and value is determined by the level of participation in its development including what has been contributed to it. The number of projects undertaken by ACRIS also determine the areas or domains of the ASM that is defined and populated. To my knowledge, much has been done in the areas of ACDM, AOP and these were initiated outside the Airports, that is EUROCONTROL (OATA, Flight Object and FIXM), SESAR (AIRM) and IATA (AIDX and AIDM).

This project is the first time that the Airports are defining their view of shared operational data which will formally define the specifications based on the ASM. Even so, I believe that there are ACRIS materials which you don’t have access to. I look to Bob Logan, the manager of the ASM to share this. Most of the objects in the ASM have a corresponding XML schema implementation.

The UML or visual version of content in attachment will be found on the ASM server in the following directory:

Technical Realisation

        |>      Project Models

          |>       Airport Messaging Services

              |>        Airport Messaging XML Schema 1.0

Re: the lack of an Airport (ACRIS) data exchange standard available for the exchange of these airport operational core data objects

In my world this has been solved to the extent I think possible.

• For data we get from external parties that just send data without regard for my view of data formats 😉, like IATA messages and Eurocontrol, we transform the data to an internal ADD based representation as soon as possible. I have included a few examples of this representation below.
  After this initial transformation it is easy to understand the data, but there might still be issues with correct handling of the data. Especially IATA messages can be a challenge.
• Partners that use our services to read and update data use our data sets in both cases. That makes it easy for us.
• Internally we only use data models based on ADD, but not one single model. We have one model for a flight leg out of our latest AODB, but multiple models for input data.
• If we send data to an external part that require that we use their data format, Amadeus and BagXML/Eurocontrol and DPI for instance, we transform to the partners representation as late as possible.

Given this integrations are fairly simple.

I very much doubt that it is possible with one standard that all will use.

There can't of course be only one, some things are beyond our influence. But maybe we can have standards "from and for Airports" that airports use with preference.

From my perspective it would be solved if we have official ACRIS standards for this, as it would be hard to sell an "Avinor" solution - even if the content is the same. It needs the approval of a recognized body and backing of other airports. It would also need xsd/openapi deliverables to sell it to the implementing folks and continuous maintenance thereof.

Re: Do we want ACRIS to provide and maintain a data exchange standard for airport operations data?

I do not think it is possible with one data model. The requirements for a data model covering load message, a turnaround and a flight leg state are widely different. Having them in one data model, common root, is just a way to solve everything in one place – and that is believing in magic.

But ACRIS can maintain multiple data models, and all within the ASM.

And ACRIS can clearly have a data dictionary as ADD that precisely (hopefully) define all relevant elements used in the data models. The ASM could then be used to explain the semantics of the terms used in different contexts.

If ACRIS managed to create something like that many airports would find it very helpful.

In a procurement process its not very hard to get companies to support your services/data model. It would be even easier if it was ACRIS branded.

Avinor ADD message for a Flight Leg

The core role of our AODB is to match the IATA, ATM and other data and create one FlightLegState.

The figures above can be seen as one way to do it. There are of course an infinite number of alternatives.

Our current AODB is quite different in design than any of the other AODBs Avinor has. The main driver has been to keep it as simple as possible while still doing all it must do.

I like that approach a lot it's what we intend to do when we will renew ours next time if AOP hasn't made it obsolete by then! 

There are two main blueprints of interest \[In the ACRIS semantic model]. These are simply views of the taxonomies in the model.

• A blueprint of business concepts or ideas. This will be found in the ASM at Model Content -> Knowledge ->Concept Blueprint

• A  blueprint of data objects which you will find in Model Content -> Data Element Library -> Data Element Object Blueprint