Airport AODB goes NoSQL (Part 1)

In previous blog posts I discussed ‘AODB and Big Data‘ and ‘AODB in the Cloud‘. As promised, in this third and largest part of the review, I will look at the NoSQL database approach, design a document datamodel, embed it into a MEAN stack and conclude in looking forward implementing an AODB in a Serverless Architecture using Microservices.

In this new series I will review the benefits and options of using a document-oriented database (NoSQL) and start a transition journey moving away from a relational database model to document database.

Robert Yarnall Richie, DeGolyer Library, Southern Methodist University

Lockheed 12A Electra Junior, Delta Air Lines at Dallas Airport in 1940 by Robert Yarnall Richie (DeGolyer Library, Southern Methodist University)

Before jumping into relational datamodel review and document design we shall have look at some industry initiatives and working groups that strive for standards with semantic models, business models,  information and data models and exchange formats and patterns. While a lot of airport systems have been developed years back in the absence of these models, but with best knowledge and common practice and experience in the field, we cannot ignore further the existence of emerging and established standards. For legacy systems is near to impossible to adopt the models at the core business implementation layer as products are usually designed around a datamodel which cannot be changed without a significant or even total redesign of the system. Here the approach is the adoption of the models at an integration and mapping layer. You can adopt eg. AIDX as messaging exchange format without having to use it as base of the product, though it creates additionally effort to create mappings. An additional challenge is certainly the number of models around because they were created by different organisations with different but often overlapping aviation domains in mind. I have to admit the organisations are cooperating and represented in the working groups to achieve a level of harmonization where possible. We look at IATA, ICAO, ACI, Eurocontrol, EUROCAE as lead organizations here.

Lets list the current models. This list is certainly not complete and only provides a brief overview. We can and should benefit from the availability of these models (most of them are freely accessible). A lot of standardization effort is going on at the moment, please note some models are to be considered as “work-in-progress”, some are quite advanced, major changes are not be expected and some are also due to submission to governing boards soon or in the process of it. Once the models, at least the exchange message formats, start materializing as official standard we will see them appearing in requirement and tender documents and soon to be out there to simplify system integration.

AIDX Aviation Information Data Exchange IATA XML Message Standard ***
AIDM Airline Industry Data Model IATA Model **
AIRM ATM Information Reference Model Eurocontrol Model ***
AIXM Aeronautical Information Exchange Model Eurocontrol Model ***
ACRIS Semantic Model ACI Model *
AMXM Aerodrome Mapping Exchange Model EUROCAE Model ***
FIXM Flight Information Exchange Model Model ***
WXXM Weather Information Exchange Model Eurocontrol Model ***
BAG XML
Baggage Message Exchange Eurocontrol XML Message Standard *

Status as of end 2016
*** official release available
* work in progress

In the context of AODB products I will look at the below models and message standards first, though all of them are important because there is no clear borderline in the heterogeneous IT landscape at airports, eg. it is a common request by users to see weather data being displayed in dashboards of an AODB despite weather is not a key entity. In the further blog entries, while establishing a new datamodel, we will also discuss the individual models. Some models focus more on ATM and less on airport related activities.

AIDX

Aviation Information Data Exchange is a XML messaging standard to allow information exchange between airlines, airports and other parties in the aviation community. It has been initially created in 2005 and was officially released in 2008, endorsed by IATA Recommended Practice 1797A. Being one of the old timer in this list it is already established and adopted by more than 100 entities. It comprises almost 100 distinct fields that cover most aspects of flight, aircraft and handling details, inclusive of A-CDM. The AIDX working group is governed by ASC (Airport Services Committee) and PADIS (Passenger and Airport Data Interchange Standards) board under the custody of PSC (Passenger Service Conference).

Please note that AIDX will be migrated into the AIDM (Airline Industry Data Model) which has a much broader scope than AIDX. We shall not ignore AIDX as it will be around for a long time in its raw format and we can expect the AIDM implementation would be quite close (to be discussed and confirmed).

The current release is 16.1. Please follow below links for schema and implementation guide.

 

AIDM and BAG XML

The Airline Industry Data Model (AIDM) has a very broad scope and encompass industry terminology, data definitions, relationships, business requirements.
Looking at an evolution from paper (eg. loadsheets ticket), teletype messages to EDIFACT, the emerging new standards as models and XML are the latest step in the evolution and promise to deliver a better consistency of definitions and data formats, as well an improved interoperability and faster system integration times.
AIDM is work-in-progress and give its nature and vast landscape it might be the continuous model for it, though confirmed standards will arise from it. One of the first implementations adopting the AIDM is the BAG XML initiative which improves bag handling related bag messaging, distribution and does away with the traditional type B messages (BTM, BSM, BPM, BUM, BNS, BCM, BMM, BRQ as per IATA RP 1745).
The documents are not public at this stage, only registered member can access the model which is build with Sparx Enterprise Architect.

In part 2 I will review a simplified relational database model for an AODB as starting point for our migration journey. Stay tuned.

Some reference websites and material you find below.

References Organizations

Eurocontrol https://www.eurocontrol.int
ACI Airports Council International http://www.aci.aero
IATA International Air Transport Association http://www.iata.org
ICAO International Civil Aviation Organization http://www.icao.int
EUROCAE European Organisation for Civil Aviation Equipment https://www.eurocae.net
RTCA Radio Technical Commission for Aeronautics http://www.rtca.org

References Standardization and models

ACRIS http://www.aci.aero/About-ACI/Priorities/Airport-IT/ACRIS
AIRM http://im.eurocontrol.int/wiki/index.php/ATM_Information_Reference_Model
https://www.eurocontrol.int/articles/airm-atm-information-reference-model
https://www.eurocontrol.int/sites/default/files/content/documents/sesar/8.1.3.d47-airm-primer-v4.1.0.pdf
AIDM http://www.iata.org/whatwedo/passenger/Pages/industry-data-model.aspx
AIDX http://www.iata.org/publications/Pages/info-data-exchange.aspx
BAG XML http://www.iata.org/whatwedo/ops-infra/baggage/Pages/baggage-xml.aspx
AIXM http://www.aixm.aero
https://ext.eurocontrol.int/aixmwiki_public/bin/view/Main/
WXXM http://www.wxxm.aero
FIXM https://www.fixm.aero
AMXM http://www.amxm.aero

( Model, implementation guidelines or schema available on website without registration.)

References Technology:

Disclaimer: This discussion, datamodel and application is for study purpose solely. It does not reflect or replicate any existing commercial product.

Online IATA Telex Processor

I launched a first version of a Telex processor with a web frontend. It is a beta version and currently only processes MVT standard messages.

Some words about the requirements for a flexible interface processor

  • Though IATA Telexes are defined by a standard, variations are common because some are produced automatically by other systems and some are created manually, which causes more errors. The processing of telexes, the pattern recognition, must be flexible enough to be able to handle extra inline whitespaces and dots, as well extra lines with free text or extra headers and trailer, eg. now it is more common to receive telexes via email and often some extra email information is added as header before it reaches your system. Customers also might create their own telex standards, meaning the whole message is transported as free text message, but inside the message the customer uses his own syntax for data transmission.
    This requires a message interpreter that can be configured for new or non-standard formats on the fly, without the need to change any sourcecode and to redeploy a system.
    (I saw a project at one airport where the change of LDM format interpretation would have cost the customer around 10.000 Euro because one of the cargo airlines send messages with an extra header line)
  • Other standard messages, such as AFTN, NOTAM or CFMU should be processed by the same engine using the same approach. One interface engine with the flexibility of the scripts covers the various aspects of the different types.

A few words about concept and architecture

  • ESB
    Certainly the word ESB sometimes might appear bloated like other IT buzzwords, but it hardly makes sense today to implement distinct own interface systems for every protocol or subsystem type you come across. In a heterogeneous IT landscape like an airport an ESB allows you to easily connect inbound and outbound to a number of other systems via TCPIP, Email, FTP,.. or even talk to other standard systems like SAP, Salesforce.com and so on. We use one connector to talk to the ESB, the rest we orchestrate in the ESB itself. With MULE ESB we have the freedom of an opensource product as well the power of enterprise support. The learning curve for MULE is not too steep.
    For the sample of telexes: Sometimes you ‘receive’ telexes by using the auto export function of the Sitatex application and retrieve the files with the messages via FTP, or you receive the messages as email or via a queuing server from a central corporate entrypoint. We can swing over to another source or run in parallel without touching the main system.
  • Script Engine
    Instead of hardcoding the various formats, we use a Java Script engine executing Groovy Scripts. These scripts, one for each message type, are stored in the DB and can be adjusted or customized easily. The scripts produce an internal XML formatted standard output which easily can be un-marshalled during the downstream processing using proper XSD.
  • Data Processing
    Whatever requirements you have how to handle the received data. In our sample system here, receive from the web frontend and make it human readable.

Please feel free to drop by http://tools.airtilus.net:8080/AirtilusTelexR and try by yourself. Please note: Do not process confidential as the data is transmitted unsecured and might be stored (to improve the quality). This is NOT a commercial offering but a technology showcase. There is no warranty that the server is available or the processor correct. You can use the example message and modify it, otherwise copy and paste your own message.

The service is currently running on a Amazon EC2 micro instance, performance might decrease with a lot of traffic.

Online Telex Processor

Outlook

  • Summary for errors and rejected messages.
  • For the next versions I will add some of the other available telex types will follow such as LDM and CPM.
  • Add AFTN message interpretation.
  • Email Reply (send an email to the service and the human readable version is emailed back to the user).

IATA Telex Types Definition

Updates about the online telex processor here

Working in the airport IT industry you are always challenged with integration tasks at each airport. Usually you face a heterogeneous landscape of home-brew or taylored solutions and standard software running on anything from mainframe to virtual instances in a private clouds. Using an ESB we can tackle a lot of interfacing work and focus on the data integration part. One interface that you will find on all airports that operate commercial flights, is a link to the SITA network to send and receive IATA Telexes.

It is hard to find any information online, so I summarised the available message types here. Btw, these telex types are often referred to as SITA Telex types, which is not correct, IATA (Air Transport Association) defines the available telex types and SITA is operating the network to distribute the messages between airlines, airports, ATC, groundhandling agents and other relevant members of the airport community.

This list should be almost complete, giving you the type, the description and the AHM (Airport Handling Manual) or RP (Recommended Practice) reference. The AHM that you can purchase from IATA gives you all the syntax and details for most of the available types.

 MVT  AIRCRAFT MOVEMENT MESSAGE IATA AHM 780
 LDM  LOAD MESSAGE IATA AHM 583
 PTM  PASSENGER TRANSFER MESSAGE IATA RP 1718
 PSM  PASSENGER SERVICE MESSAGE IATA RP 1715
 DIV  AIRCRAFT DIVERSION MESSAGE IATA AHM 781
 BSM  BAGGAGE SERVICE MESSAGES IATA RP 1745
 CPM  CONTAINER/PALLET DISTRIBUTION MESSAGE IATA AHM 587
 UCM  ULD CONTROL MESSAGE IATA AHM 388
 SCM  ULD STOCK CHECK MESSAGE IATA AHM 385
 SLS  STATISTICAL LOAD SUMMARY IATA AHM 588
 ASM  ADHOC SCHEDULED MESSAGE IATA AHM 785
 PAL  PASSENGER ASSISTANCE LIST IATA RP1707b, 1708
 LPM  LOAD PLANNING MESSAGE IATA AHM 580
 ALI  ABBREVIATED LOAD INFORMATION MESSAGE IATA AHM 584
 SOM  SEATS OCCUPIED MESSAGE IATA RP 1712
 TPM  TELETYPE PASSENGER MANIFEST IATA RP 1717
 RQL  REQUEST LIST MESSAGE IATA RP 1709
 PNL  PASSENGER NAME LIST IATA RP 1708
 PFS  PASSENGER FINAL SALES MESSAGE IATA RP 1719
 IDM  INDUSTRY DISCOUNT MESSAGE IATA RP 1714
 ASL  ADDITIONS AND DELETIONS LIST IATA RP 1708
 SAL  SEATS AVAILABLE LIST IATA RP 1713
 RQM  REQUEST INFORMATION MESSAGE IATA AHM 783
 UWS  ULD/BULK LOAD WEIGHT SIGNAL IATA AHM 581
 FMM  FUEL MONITORING MESSAGE IATA AHM 782

Disclaimer: The list might not be correct or complete. It is for educational purpose only. For reliable information please refer to the IATA manuals.

MVT, LDM, PTM, TPM, CPM, PSM, UCM are among the most common telexes from my experience. If you implement a telex interpreter you definitely need to implement these types first.

I am working on an online telex processor, a demo version I will put online soon.