Even more Airport Self-Service-Kiosk Designs in 2024

Another 6 months later (December 2023) and Midjourney released 6.0 as alpha for image creation, worth another visit to same and new design prompts. We are going more and more photorealistic without any additional prompt attributes. Some of the design are little practical I guess but certainly create a decorative element in the terminal.

Previous posts: How to design an Airport Self-Service-Kiosk (Jan 2023) and More Airport Self-Service-Kiosk Designs (Aug 2023)

Disclaimer: This is solely for educational purpose and does not reflect any actual products or design I am involved with (until today). No copyright infringement is intended.

Style of 1900s

Style of 1910s

Style of 1920s

Style of 1930s

Style of 1940s

Style of 1950s

Style of 1970s

Style of 1980s

Fantasy Dreamland Style

Mad Max Movie Style

Art Deco Style

Rococo Style

Gothic Style

Lord of the Rings Style

Kids Toy Style

Apple Design

Andy Warhol

Google Design

Neon Design

Joan Miro Design

Design by Pablo Picasso

Hieronymus Bosch Design

Salvador Dalí Design

Colani Design

Zaha Hadid Design

Conclusion: Runing Midjourney V6.0 creates very photorealistic images, that could easily been taken for a real photograph. It is mindboggling how much it advanced in one year. The challenge, create new unique designs that are not just copying the stykle of someone else. Though creativity contains inspiration and copyying.

Airport AODB goes NoSQL (Part 2)

Earlier I embarked on the journey to create an AODB based on a NoSQL datamodel, moving away from a relational model and discuss its benefits. As a quick refresher about What’s an AODB ? for the new reader, the elevator-pitch style version describing an AODB:

AODB – Aiport Operational Database
An AODB system is one of the core IT systems to support the airport ground operations, it integrates with various systems in the heterogeneous airport IT landscape by processing data from airline seasonal flights schedules, flight plan and slot management, ground movement from Radar, air movement from ATC, and other sources. It serves as CDM (Collaborative Decision Making) platform for the various parties and stakeholders forming the airport community, from airport operators, airlines, groundhandling agents, authorities to ATC (Air Traffic Control) and others.
It handles seasonal and operational flights by providing planning, real-time and historical data, supports resource management for facilities, equipment and human resource and feeding information to public via FIDS and other external links. The below diagram shows an exemplary common orchestration of systems where the AODB is embedded at the core.

Now lets have a look at the typical data layout and relation of flight data entities and attributes. These are the common business entities and a relational model is the traditional approach to design it. We need to apply a rather high level of normalization to avoid redundant data, but the relations (typical 1:N) across the model have an impact on the performance of the DB. This can be counterbalanced by tuning, indexing and more powerful hardware underneath. Building SQL statements with joins across several tables becomes challenging (hard to create) and might cause inefficient reads of tables (full table scan). In comparison with a NoSQL design we have a document approach, one document (like a index card in the analog world) would contain all relevant data (ignoring the redundancy problem for now).
At the end of this exercise we have to ask the question: Is NoSQL the right tool for an AODB ? (We will revisit this question later on)

I like to elaborate the redundancy problem on one particular case:
A flight is operated with a specific aircraft (registration, tail number) on a certain date. The related information (AC Type, seats, owner, lease, etc) we retrieve from the relational table (containing all aircrafts in the system,) quite the standard scenario. The problem starts when we keep operational data long term (years) for auditing/research/statistical purpose. It is quite common registrations get transferred due to sale or scrapping of aircraft (find a sample here). Using the relational model with an aircraft registration table that only carries current registrations we would end up looking at the wrong information for a historical flight that operated on the previous aircraft with the same registration. A solution would be introducing the concept of validity for certain entities ,which again adds to the complexity.

The main problem is not solved, we should not replicate or mimic a relational model with NoSQL. Keeping the data redundant will increase the data volume but we would have one document with all relevant information. One usecase which is appealing for the document approach is creating a final snapshot of the flight in an archive like repository. The design question we have to answer, what data or details of the operations lifecyle (schedule, planning, operation, post-operation) we want to keep in the flight “document” ?

As an academic exercise, lets get started and create the most basic (primitive) version of a flight document in JSON format and look at all its weakness to start to evolve to improved versions of it.

{
  "flight": "AA123D",
  "org": "AKA",
  "des": "FRA",
  "service": "J",
  "actype": "A350",
  "position": "Z19",
  "gate": "A5",
  "baggagebelt": "09",
  "scheddep": "2017-11-23T19:35:00.000Z",
  "schedarr": "2016-11-24T13:15:00.000Z",
  "estimatearr": "2016-11-24T13:55:00.000Z",
  "estimatedep": "2016-11-23T19:39:00.000Z",
  "onblock": "2016-11-23T13:35:00.000Z",
  "offblock": "2016-11-23T19:31:00.000Z",
  "landed": "2016-11-23T13:27:00.000Z",
  "airborne": "2016-11-23T19:39:00.000Z",
  "pax": "128",
  "via": [
    "ABR",
    "ACL"
  ],
  "codeshare": [
    "LH123",
    "TG123",
    "AF123"
  ]
}

What is good about this entry level model ? Not too much other than highlighting the benefit to have all info in one document.

Lets look at the problems, at least the highlights. There is quite a number of attributes missing (eg. registration) but here the main flaws:

• There is no clear concept of the flight as entity. Is it a segment or a complete journey ?
• No naming convention, more or less random abbreviation for eg. timings.
• No proper key identifier.No separation of airline code, flight number and suffix, missing schedule departure date (as key).
• Resource should be an array of objects. Multiple resources with different timings might be in use.
  Same applies to any pax or cargo/load data.
• Representing VIA and CS information like this might be good enough for a FIDS system but for a mature model we need to break down the whole entity into segments.
• No links which provide dependencies to other segments, codeshares, arrival or departures.
• Milestones (timings) should be an array too.
• No audit information. (Might not in the scope of our model though.)
• No unique (technical) identifier beyond flight keys.

We will elaborate and finetune in upcoming posts. Stay tuned.

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

Image: Creative Commons, DeGolyer Library, Southern Methodist University on The Commons, “DC-3 Aircraft at Houston Municipal Airport, Eastern Airlines”

Design an AODB for a mobile server platform ?

Mobile clients for AODB (Airport Operational Database) products running on tablets and mobile phones are a standard offering today. These clients allow convenient access to operational data while being on the floor, at the tarmac etc. I remember my first mobile AODB project more than 10 years back operating on a proprietary Nokia platform. Today it is not a major technology challenge any longer with current mobile hardware, platforms and libraries available at hand.
The remaining questions are often: How to design the app for a small screen landscape available, but facing a big amount of operational data ? What features does a mobile user really need, what info is key to be displayed, what updates need to be entered while being mobile ? How to simplify user interaction ? How to handle the data synchronization when being offline, aka in areas without wireless or mobile coverage ? Build a hybrid app or go native ?

I believe we at an interim stage of mobile computing at this moment, while current mobile apps replicate desktop applications (screen, mouse, keyboard) with the means of mobile interaction (touch, swipe, pinch,..), we still sorting out the next evolutionary step. Mobile computing on mobile phones, handhelds, wearable computing, smart watches, AR glasses etc. etc. Ruggedized devices became standard while smart watches are still not taking off.
The next (or this !) generation of mobile apps should make use of the mobile characteristics and sensors built-into most mobile hardware. A few ideas: Location awareness, the app should know where the user is at the apron and already open the relevant flight and information or support manual milestone recording. Depending on the users role, tasks should be highlighted to him/her, eg. a service manager that is closest to a problem location should be notified. NFC reader, barcode scanner and AR glasses should assist the user to identify cargo, baggage, vehicles, etc.

Putting aside this considerations, I like to engage in a little thought-experiment:
Can we run an AODB, aka the server, on a mobile phone (Android) ? (without using any external core service, eg. data storage or rule engine etc. Standalone only, allowing other clients to connect, simple interfaces only)
Lets play with pro and con argument and check on the feasibility.

Hardware

This topic triggered the discussion when comparing current hardware in mobile phones with server hardware 20+ years ago when the first generation of AODB products appeared. A standard server of that time was something like a Sun Ultra II with dual 200 MHz processors, 256 to 512 MB of RAM and maybe a SCSI rack with 3x 10GB diskspace, running Solaris, 32bit. Easily priced at 20.000 to 50.000U$ depending on configuration plus various commercial licenses.
Lets look at a current mobile phone like the Huawei P20, Octa-core (4×2.4 GHz Cortex-A73 & 4×1.8 GHz Cortex-A53) with 4GB of memory and 128GB of SD card space, coming at 600U$.

Operating System

Android is obviously not a server OS, it does not give us control over settings that we can rely on under Linux. We cant assign memory and priority, it is actually the OS that controls apps and services, going to the extend of terminating unused apps and similar. The only way of having a persistent app running is as service. Apps are living in sealed sandboxes, only a rooted device would give us more control.

Solution architecture

We cant build a multi-tier solution with the classical database, business logic and frontend layers. Android enforces monolithic applications, the only way to escape this is by building services and relying on ICP (AIDL, Intents, Binder). Anonymous shared memory is only available in Android 8+.

Database and Application/Web-Server

App-server ? Easy to answer, it does not exist. Maybe simple http server is possible.
Database ? Only a few solutions at hand, either the built-in SQLite, not really a DB known for performance, or some alternatives, mostly key-pair and relational DB’s and some NoSQL DB (Comparison chart here).

Scalability

We cant scale vertical, no adding of CPU’s or memory possible. Horizontal scaling would not be easy, unless we deploy more mobile phones to outsource certain services, but implementing a load-balancer would not be possible.

Availability

In terms of network connection we are limited to 1 wireless or (!) 1 mobile connection at a time, no redundancy. Power-failure is less of a problem, we have built-in battery that could last at least 1 hour under heavy usage. Android as OS is quite stable, it can run for prolonged periods, though it is uncertain if services running permanently with load create a problem.

Integration

Integration of interfaces with other systems is a bit more challenging. Though it is no problem to consume webservices, download from ftp server or receive emails as part of interface client, we will have a hard time to provide an interface, eg. to offer a webservice. There is no ESB running on Android.

Conclusion

It is definitely possible to run a very lightweight AODB solution without lots of fancy bells and whistles on a mobile phone, ideally to act both as server and client integrated into one solution (app). All under the premise to limit our requirements to a basic set of features like managing schedule, daily operations, milestone handling, simple resource management.
The longer I review this idea the more arguments I collect against this use-case, the platform is too limited to allow scaling, does not provide real server features and will not be able to run heavy services like rule engines, ESB, etc.
Maybe feasible for small scale operations at an airport with few commercial flights a day, some GA, few users and utilizing third party services in the cloud for billing, ESB, etc.

I suggest we rather invest our thinktank energy in building a serverless AODB by using orchestrated microservices and use the mobile platform solely as client.

Image: Creative Commons, National Library of Ireland on The Commons, “St. Albert at Dublin Airport, circa 1950”

Aviation API – Airline and Airport Webservices

The term API (Application programming interface) is not new, basically a defined access to a set of methods, subroutines and data-types made available by one component/service to be used/consumed by another component or application. You can think of API as the car manual and the library being the engine under the hood.

Since the early days of tinkering with the Windows DLL hell more than 20 years have passed, we have better tools and standards by now. In the space of native apps for Windows, Android and iOS we still work with libraries and SDK’s (still can be challenging when resolving dependencies and deployment).
In the world of web applications today we look mostly at RESTful Webservices responding in JSON or XML, a rather straight forward implementation, the only complexity depends on the authorization mode or the mapping of attributes. A lot of websites, portals, services or products expose their WS for usage by third parties, from Salesforce, Ebay, Amazon to Twitter and infinite more. While these mentioned samples operate independently or work as standalone services there is not much need for standardization of the payload, aka the structure of attributes, naming conventions etc. For others business domain there is a need of standardization of such, despite the availability of AIDX, AIDM and a few more data exchange models, there is no standard widely used in the (public) WS space in aviation.
I have to highlight in ACI ACRIS a Semantic Model is being actively developed and the Open API Shop exists as project as well.

I researched what webservices are currently offered to the public by airports and airlines, excluding the API’s of system vendors and travel platforms.
So far I found these webservices (last update 2018-07-06):

Airline

International Airline Group British Airways, Iberia, Avios	https://developer.iairgroup.com/
Lufthansa	https://developer.lufthansa.com/
Airfrance, KLM	https://developer.airfranceklm.com/
Alaska Air	https://developer.alaskaair.com/
Transavia	https://developer.transavia.com/
FlyDubai	https://developer.flydubai.com/
Virgin Australia	https://developer.virginaustralia.com/
Ryanair	https://developer.ryanair.com/
Turkish Airlines	https://developer.turkishairlines.com

Airports

Schiphol Airport	https://developer.schiphol.nl/
San Francisco Airport	https://www.flysfo.com/api
Frankfurt Airport	https://developer.fraport.de/
Svedavia Airports	https://apideveloper.swedavia.se/

Others

FAA US	https://app.swaggerhub.com/apis/FAA/ASWS/1.1.0
Flightaware	http://flightaware.com/commercial/flightxml

The usage terms and price models vary but basically all give some kind of developer access to evaluate the services and data at no cost.

To compare a few of the services using a flight status related call, omitting the authentication. The lack of standard, putting aside JSON response format and date format, is quite obvious. It might not be relevant in the space of individual apps to have the same response format, but if you want to combine data from various sources you have to handle the formats separately. Even the request format with the query parameter differs.

British Airways

https://api.ba.com/rest-v1/v1/flights;departureLocation=FRA;startTime=06:00;endTime=11:00

Swedavia Airports

https://api.swedavia.se/flightinfo/v2/query?filter=airport eq ‘ARN’ and scheduled eq ‘180713’ and flightType eq ‘A’ and flightId eq ‘DY4572’

Lufthansa

https://api.lufthansa.com/v1/operations/flightstatus/LH778/2018-07-13

I also tried with RyanAir (still waiting for approval to get api key), Turkish Airlines (no flight status API), Schiphol (no webservice test available on the website).

Image: Creative Commons, Robert Yarnall Richie Photograph Collection, “Models with Oldsmobile Automobile, Lockheed 10B Electra, Delta Air Lines, 1940”

Airport Simulator on Android

Dont rise your expectation to high on this topic for now. Before jumping into the serious use cases for airport process and environment simulations, as well the gamification of enterprise environments, I will review some simulator apps available on Android and PC in a rather humorous way.

I just love simulators, it is amazing to see how current 3D and physic engines running on today’s powerful and affordable hardware can execute real-time simulations that were only possible in well equipped research labs 2 decades ago. I am experimenting with various 3D engines like Unity and CryEngine, both freely available as personal or educational version or for indie games.

OK, lets have a look at simulators available for the Android mobile platform. If you search for the term simulator you will get thousands of apps, and there is a simulator for almost everything and anything you never heard of before, though the majority is plain crap and only exists because Unity makes it so easy to create a game by clicking-together some assets and adjusting some properties, almost without the need to code. Most of them are just badly made and often only serve the purpose to bombard you with ads once installed or running.

We find 100’s of car, truck, train simulation apps, plus dozens of somewhat strange apps to simulate dogs, cats, dinosaurs, Fishing, Fork Lifts, shark attacks, Miami Crime, swimming trains, flying boats and tuk tuk’s and endless more objects.

Finetuning our search towards the term airport (vehicle) simulator we still reveal dozens of results. Here we have a selection of flying, airport construction and all kind of driving around the airport tasks. The majority is made with Unity engine and the free assets, one reason why most of these apps display the same assets like cars, trucks and planes.

Selection of simulator apps

Most of them have in common: Well rendered icons and preview images in the play store to catch your interest, generous with requested permissions and truckloads of ads.
Surprisingly all of them have downloads of well beyond 100.000 ! Guess we don’t know the uninstall-rate though, but if you look at the user comments you know.

Permissions galore inclusive to run as service during startup, snooping accounts and location, downloading files.

Here some actual screenshots of the often weird gameplay or scenery I found.

Factory Airport ? Not much room to maneuver. Where are taxiways, positions, gates ? But 3 Towers !

If your are short of pushbacks, go for a regular truck as fallback !

Personal pickup service for MIB passengers in Area 51 ?

Taking off from a construction site with speed limits and stop signs. Here the tower also a bit too close to the runway maybe.

Disembarking Zombie passengers walking down from the service staircase to the waiting Cobus(?)

Driving a heavy duty tow truck between the planes parked on the grass. Nothing else to do. Maybe one of these defunc airline desert airplane parking grounds ?

This time we drive an airport security car in a totally static airport. Someone forgot to add tarmac lines here ?

This plane looks like the airport fire brigade drill setup. But in this app all planes look like this model (front part is mocking a war train from the 1930’s). Not so standard cargo handling either.

Interesting, floating mobile stairs supported by a RC wreck. Walls at the tarmac ?

Winter wonderland. Random assets like palms, lamp posts and others stuff thrown at the scene. Big Christmas trees at the end of the runway… Walls again.

Gives the term Greenfield Airport a more genuine meaning ! Randomly appearing zombie passengers again. Leave the boarding gate through the window ?

Oh yes, that is a smart way to avoid a potential IP conflict with a famous airline ! Bonus: Floating bridge and you fly with a 1:5 scale plane ?

Smart parking, what to say ? Smart as in stacking cars on the back of a truck or smart as in placing this thing at the end of the runway ?

Conclusion: Dont expect anything when downloading these simulators, other than uninstalling it again and potentially being spied or bombarded with ads. None of the app I tried even remotely comes close to any real operations. These are games – confirmed – nothing else.

In the next blog entry we will look at Simulator Software available for Windows PC’s.

Stay tuned.

 

Read My Boarding Pass App

In the previous blog post I discussed the underlying standards of the BCBP (Bar Coded Boarding Pass) following IATA Reso 792. Today I will built an Android mobile app that scans the PDF417 barcode and shows the raw content as well the decoded fields.

The are 3 main challenges for building the app, scanning/reading the barcode and decoding the text to individual attributes and as last, not to use any internet connection (to assure the user the users privacy and avoid any potential identity theft discussions)

As we build a native Android app we can rely on third party libraries to scan and decode barcodes. There is a number of commercial libraries in the market, but as I build a free app I will use the zxing-android-embedded library, which is a port of the ZXing (“Zebra Crossing”) barcode scanning library for Android with added embedding features, ZXing only provides the decoding logic. Both are licensed under Apache 2.0, ZXing can decode all the common types, such as EAN-8, EAN-13, UPC, ITF, PDF417, QRCode, Aztec, Data Matrix and a few more.

Integration Barcode Library ZXing

With the library the integration becomes as simple as adding a few lines of code only.

Add the dependency to the build gradle file

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    compile 'com.android.support:appcompat-v7:25.3.1'
    compile 'com.android.support.constraint:constraint-layout:1.0.2'
    testCompile 'junit:junit:4.12'

    compile 'com.journeyapps:zxing-android-embedded:3.5.0'
}

Trigger the scan and read the result

public void scanCode(View view){
        new IntentIntegrator(this).initiateScan();
    }

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        IntentResult result = IntentIntegrator.parseActivityResult(requestCode, resultCode, data);
        if(result != null) {
            if(result.getContents() == null) {
                System.out.println("Scan failed or cancelled.");
            } else {
                System.out.println(result.getContents());
            }
        } else {
            super.onActivityResult(requestCode, resultCode, data);
        }
    }

For now, the app (“ReadMyBoP – Read My Boarding Pass”) does nothing but scan the barcode, identify if it is a valid boarding pass barcode, display the raw content and makes the content more human-readable. You can download from Google Playstore. It works with Android 4.1 and above.
There is one extra feature for now, it decodes the IATA fare codes (First, business, economy classes and the various discounted codes, it follows IATA Reso 728 if you want to look for the complete codeset.

Decoding the Raw Text

Given the fact, this is a fixed-length field text, it is no big deal to split the relevant info by substring’ing it using the decoding table that we started in the previous post. As basic validation we can use the mandatory “M” on position 1 and a length of not less than 59 characters (mandatory fields).

#	Element	Mandatory	Size	Sample	Remark
1	Format Code	M	1	M	Always “M”
2	Number of legs encoded	M	1
3	Passenger Name	M	20
4	Electronic Ticket Indicator	M	2	E
5	Operating carrier PNR Code	M	7
6	Origin IATA Code	M	3	FRA	Airport Code
7	Destination IATA Code	M	3	SIN	Airport Code
8	Operating carrier IATA Code	M	3	LH	Airline
9	Flight Number	M	5	3456
10	Date of Flight	M	3	280	Julian Date
11	Compartment Code	M	1	B	First, Business, Economy
12	Seat Number	M	4	25A
13	Check-in Sequence Number	M	5	0012
14	Passenger Status	M	1	00
15	Size of optional Block	M	2	5D	hexadecimal
16	Start Version Number		1	>	Always “>”
17	Version Number		1	5
18	Field Size of follow ing structured message		2
19	Passenger Description		1
20	Source of check-in		1
21	Source of Boarding Pass Issuance		1
22	Date of Issue of Boarding Pass (Julian Date)		4
23	Document Type		1
24	Airline Designator of boarding pass issuer		3
25	Baggage Tag Licence Plate Number 1		13
26	Baggage Tag Licence Plate Number 2		13
27	Baggage Tag Licence Plate Number 3		13
28	Field Size of follow ing structured message		2
29	Airline Numeric Code		3
30	Document Form/Serial Number		10

Is there a roadmap ? For sure, if I find the time I will add the optional fields, an airline and airport code dictionary (must check the size of a local sqllite db if we want to stay offline). Maybe add baggage tag reader feature and local barcode image storage for boarding. Stay tuned !

Application Disclaimer: The application is for educational and research purpose. It is provided as-is, no warranty included. It does not transmit data over the internet and does not store any data upon exiting the app.

What’s in my boarding pass barcode ?

Since more than 10 years passengers are used to the barcode imprinted on the traditional ticket boarding pass slip, the home printed boarding pass or the boarding pass displayed in the mobile app provided by the airline. To be more precise the 2004 IATA Passenger Service Conference approved Resolution 792 setting the BCBP (Bar Coded Boarding Pass) standard as part of the STB (Simplify The Business) program.

The barcode simplifies passenger handling as the barcode can be read automatically by barcode readers along the passenger journey for bag-drop, security check area access and boarding. It significantly reduces the error rate to the time before barcode and eventually saved millions of Euros/Dollars due to mishandling and delays. Today we see self-boarding gates that remove the need for an agent, though business and first class passenger are still welcomed by a human gate agent. Btw, the magnetic stripe on the back of the old tickets expired in 2010.

Old Passenger Ticket without barcode (Image Public Domain)

The BCBP standard defines PDF417 (public domain standard, no fees or licenses) as the barcode symbol format as well defines the encoded content. The content in the barcode contains the same information as printed on the standard boarding pass, though some airlines omit information on the self-printed version in favor of simplicity, some extra info is optionally encoded.

Sample PDF 417 barcode

M1SMITH/JOHN          EHJK345 FRASINLH 3456 280C015A0001 100

The standard covers 3 additional barcodes that are not used for printing, but used for mobile apps, these are Aztec and QR Code.

The encoding is straight foward using fix-length fields and the code can carry up to 4 legs of a journey.

Element	Size	Sample	Remark
Format Code	1	M	Always “M”
Number of legs encoded	1	1
Passenger Name	20
Electronic Ticket Indicator	2	E
Operating carrier PNR Code	7
Origin IATA Code	3	FRA	Airport Code
Destination IATA Code	3	SIN	Airport Code
Operating carrier IATA Code	3	LH	Airline
Flight Number	5	3456
Date of Flight	3	280	Julian Date
Compartment Code	1	B	First, Business, Economy
Seat Number	4	25A
Check-in Sequence Number	5	0012
Passenger Status	1	00

These are the mandatory fields, there are additional optional fields and blocks for baggage info, document info, frequent flyer number or security data.

To be noted, the IATA PADIS XML message standard shall be used for the exchange of BCBP data between systems, defined in Resolution 783 – Passenger and Airport Data Interchange Standards.

I like to add also, the printed barcode is the current common nominator for international travel, but there are initiatives on the way to simplify the passenger journey even further with newer technology such as biometric ID’s and identity management, eg. IATA OneIdentity Initiative.

In the next post we will assemble a simple Android application to read the boarding pass barcode. Stay tuned.

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

IATA Type B Bag Messages and Baggage Messaging Refresher

There is quite some movement in baggage handling and its associated messaging needs and requirements at the moment.  Though the IATA recommended practices RP 1745 and RP 1800 are around for quite a while, the IATA Resolution 753 (baggage tracking and custody) has to be implemented by June 2018 and the new BAG XML message standard is shaping up and will most likely released first time in 2017. Traditionally any handling of baggage requires a type-B message to be sent to the relevant parties. This is a push-based approach and due to the nature of type-B messages prone to errors (format) and accumulate costs by the distributing network operators and its transaction based charges. According to a IATA study/business case in the year 2012 26 million of bags have been mishandled, mostly for transfer bag handling and a good share of this is caused by missing or wrong messages.

This article is meant to provide an overview or general introduction, aka baggage messaging for starters. Baggage Handling is very complex process with dependencies and actors, including airlines, airport, handling agent and eventually the passenger and his baggage.

Main Systems involved in the process of baggage handling

DCS	Departure Control System
BHS	Baggage Handling System
BRS	Baggage Reconciliation System

DCS
The Departure Control System is the operational backbone of every airline. It supports the check-in, baggage acceptance, boarding process and other related activities like load control, immigration.

BHS
The Baggage Handling System (usually owned by the airport) is a complex system of conveyor belts, chutes and bag drops that transports and buffers any checked-in luggage. It ensures that luggage that is checked-in, transferred or received from arriving flights is tracked, counted, scanned, screened and transported to the right bag chute or belt.

BRS
The Baggage Reconciliation System, usually used by the handling agent, helps to match passenger, bag, flight and container.

Traditional Type-B Messages for Baggage Handling (defined in IATA RP 1745)
RP 1745 defines the formats of the messages exchanged between the systems for automated baggage and passenger reconciliation, baggage sortation and other baggage services.

BTM	Baggage Transfer Message
BSM	Baggage Source Message
BPM	Baggage Processed Message
BUM	Baggage Unload Message
BNS	Baggage Not Seen Message
BCM	Baggage Control Message
BMM	Baggage Manifest Message
BRQ	Baggage Request

Baggage Tag Number or License Plate Code
A unique 10 digit number as reference for each piece of baggage, defined in IATA RP 740.
The bag tag number is part of the baggage messages.
According to resolution 751, effective June 1st 2013, the format contains only numbers.
Sample: 0220208212 (0-220-208212)

1	1 digit	Leading digit	0
2	3 digit	Airline code	220	Lufthansa
3	6 digit	Bag number	208212

The printed barcode is a regular ITF-14 code, any smartphone can read the barcode. The number is also printed on the bag tag.

KLM is printing a “KL” in between but the barcode only contains numbers. “074” for KLM.

BTM
The Transfer Message contains bag information for the outbound carrier of incoming transfer passengers. Part of a through check-in transaction.

BSM
The Source Message is sent from the DCS to the baggage handling system upon checkin at the airport or bag drop.

BPM
The Processed Message is an status update sent locally, eg. baggage handling to carrier. BPM’s are often batched.

BUM
The Unload Message is the instruction to unload (or not to load) a specific bag, eg. no-show PAX at the gate.

BNS
The Not Seen Message contains bag info for baggage that could not been transported together with the passenger.

BCM
The Control Message serves secondary level information, such as
BAM Baggage Acknowledgement
FOM Flight Open
FMM Final Match
DBM Delete Baggage

BMM
The Baggage Manifest contains baggage details for down line stations.

BRQ
The Baggage Request asks for bag info from a baggage handling system.

Sample Message
A very simple sample of a transfer message

BTM
.V/1TOFRA
.I/LH123/14OCT/CPH
.F/LH234/14OCT/SIN
.N/0220588615021
.P/SMITH/JOHN   
.L/7FABC
ENDBTM

1	.V	Version and suppl. data	Transfer Station	FRA (Frankfurt)
2	.I	Inbound	Flight Number and date	CPH (Copenhagen)
3	.F	Outbound	Flight Number and date	SIN (Singapore)
4	.N	Baggage Details	10 digit bag tag id	0220588615021
5	.P	Passenger Name		John Smith
6	.L	PNR	Passenger Name Record	7FABC

Message Flow for interline flight

The below is rather simplistic view (sunshine scenario) of the messaging that happens around bag management for a 2 segment interline flight with through-check-in of bags.

A passenger is flying on LH 401 from JFK to FRA and SQ 025 from FRA to SIN. An interline flight with baggage checked through Singapore.

Relevant Documentation or References

IATA	RP 1745	Baggage Service Messages
IATA	RP 1796	Baggage System Interface
IATA	RP 1701f	Self Service Baggage Process
IATA	RP 1800	Baggage Process Description for Self-Service Check-in
IATA	RES 753	Baggage Tracking

Online References
Remark: Most of the IATA documents are not available freely and have to be purchased, here only links to public documents or pages.

IATA	RES 753	https://www.iata.org/whatwedo/stb/Documents/baggage-tracking-res753.pdf
IATA	BAG XML Initiative	http://www.iata.org/whatwedo/ops-infra/baggage/Pages/baggage-xml.aspx

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

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.

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:

• https://linuxacademy.com/blog/amazon-web-services-2/serverless-architecture/
• http://martinfowler.com/articles/serverless.html
• https://en.wikipedia.org/wiki/NoSQL
• https://en.wikipedia.org/wiki/MEAN_(software_bundle)

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

Visualization Use Case Part 2: Airline Arrival Delays in the US (Tableau)

After reviewing the flaws of the previous visualization of the DOT Airline performance data in part 1, I created an improved version with the same recordsets. It is a separate viz because the first version have some mistakes due to the number conversion during the csv import. I cleaned up, checked the data and used calculated fields to derive the sum of delays.

Airline Performance in the US 2015

The basic concept is still the same, the matrix on the top left controls the dashboard, initially you see all data for 2015 combined, clicking into cells drills down.
I changed the barchart to stacked bars comparing total to delayed flight in one bar for each month.

Bar Chart

I moved the split delay reasons into a separate bar chart and added a pie chart which reveals the main reason for delays (surprisingly weather and security have the smalles share!) The 2 lists are a Top 10 style lists highlighting the airports and airlines with the most delays.

Airport Performance

 

Airline Performance

 

How does the visualization transport information ? Let’s look at the strong and weak points of the second iteration.

+ The key information presentation is improved. We can see the viz is about delays.

– The dashboard starts to look a bit disorganized and the viewer eyes are moving around without a centre of attention.

+ The barchart now makes sense, you can compare total flights and delays.

– The detail delay reason over time does not create too much value as the distribution of reason is quite similar.

Conclusion: Spending more time on both data and visualizations improved the overall impact, though a bit cluttered.

Lets try to apply to some more tweaking..