Design an AODB for a mobile server platform ?

5997469039_0736c09bd7_b

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”

Advertisements

Airport AODB and Big Data

There are 4 technology terms that almost every IT company in any vertical business picked up during the last few years: Cloud, Big Data, Mobile and Internet of Things. In this series I review some of these buzz words in the Airport IT business context.

Today I will review the question: Does AODB data qualify for Big Data ?

What is Big Data ? A term that everyone uses, from consumer, consultants, user to people at CxO level. All have it, want it, need it, do it. Everyone joins the crowd, though few really know what it is and how to apply it in one’s own context or if one actually has a reasonable use-case for Big Data. I would not attempt to explain Big Data in this article, rather pick key elements and try to apply them. Big Data is too big to swallow and it comes in so many use cases, technologies, brands, products, flavours and attributes from Amazon, Google, Facebook to SAP Hana, No SQL, Mongo DB, Map Reduce, Hadoop and NSA. You can google for the term Big Data, read the Wikipedia Page about it or read one of the hundreds of books about, I can recommend a few here that I read.

9390823839_a02d5e07fd_z

Terra Ceia Island Farms gladiolus being loaded onto a U.S. Airlines plane at the Sarasota Airport (by State Library and Archives of Florida)

Do not expect an explicit yes or no answer in the end, though we will do a Big Data compliance check for every paradigm, but still I like to be open to find use cases.

The 3 (+3*) key words for that usually used to define Big Data:

  • Volume
    An enormous amount of data created by human interaction, machines and sensors
  • Velocity
    A massive and continuous flow of data from various sources, usually in real-time, but not limited to.
  • Variety
    Data from many sources in structured and unstructured form
  • Veracity*
    Noise and abnormality in data.
  • Validity*
    Correctness and accuracy of the data
  • Volatility*
    Data relevance. Lifespan of the data in which data shall be considered for any analysis.

(* Only the first 3 V’s – Volume, Velocity and Variety – are the canonical Big Data attributes, the additional V’s show up sometimes in discussion or papers, but they basically apply to all data.)

Some basic facts about an AODB product. An Aiport Operational Database is an enterprise application with a closed and rather predictable user-base. Depending on the size of the airport and the community serving it we might have up to 200 concurrent users and 1000 active accounts. It is not consumer facing, it is not social media, no click-streams and no input of sensors.

Volume

We need to build a data scenario in a typical or average AODB setup to discuss the term volume. I will try to create a typical scenario in order to create a total number of records or attributes over a typical time-span. Please consider this is as a simplified sample, the figures might vary a lot, depending on various factors, like country and region, international or regional, hub, primary airport, etc.
Usually the airport size in publications or comparisons is derived from the number of PAX and or movements of aircrafts per year.
For some references please refer to the ACI website.

A midsized airport around 20 to 30 million PAX a year might have around 500 turnarounds, this will be 1000 movements (arrival and departure).

Lets assume every movement have ..
20 milestones (scheduled, estimated, actual timings, A-CDM milestones or proprietary timings,..). Each of these milestones gets 3 updates (in average!)
10 load attributes (number of pax, total, by class, infants, cargo and weights,..). Each of these attributes gets 2 updates (in average!)
20 network messages (IATA Type B, AFTN, CFMU,..) This can vary extremely depending on the system landscape.
25 various attributes (flight number, registration, tailnumber, flightplan ID, aircraft type, callsign, resources, connecting flights,..) Each of these attributes gets 2 updates (in average!)
This results in 150 attributes (inclusive of updates) per movement. Applied to 1.000 movements day, we will have
150.000 attributes per day,
4.500.000 attributes per month
27.000.000 attributes per season (6 months, one seasonal schedule)

This approach is conservative, it does not cover audit or system logging. It does not consider a situation where the AODB serves as central data repository (warehouse?), with data-feeds from other systems for permanent storage. In more complex environments I saw requirements to process and store 10.000.000 ground radar updates or 1.000.000 updates from the Building Management system a day.

Do 27 million attributes in 6 months qualify for big data volume ?
In this case I would say no, but taking into the account the option to store more than one season of data and maybe to cover more than one location in a multi-airport situation, maybe yes !

Velocity

Do 150.000 attributes a day qualify for big data velocity ?
Braking down to an average of 1,7 updates a second, rather not. It does not require an Big Data architecture to process this.
Compare with Twitter (not a fair comparison though): ~10.000 tweets a second.

Variety

First, we have almost no unstructured data. Once the AODB has been put in place and production there are hardly changes in the structure of the data. Unstructured data might come with free format messages or partial free format content.
The variety also depends on the complexity of the IT landscape and the number of interfaces, AODB’s often play the role of central system integration and we face lot of inbound data streams, but they usually come in an agreed format.

 

Thoughts on Big Data Analysis

One of the selling points of Big Data is the analytic you can apply to the vast amount of data to identify patterns, extract useful knowledge and business value from the data collected. This might help to improve your business strategies or processes or focus on certain areas of value, even predict future scenarios given certain repeating conditions. We can see definitely value added to the AODB context here, though lot of the data is given and can be adjusted only with limitations or not at all, eg. flight schedules provided by airlines (usually result from slot coordination procedures) and the airport physical resources (stands, gates, belts,..). The potential lies in the analytic of actual data, even the airport can’t necessary change schedules, but with patterns emerging from actual data vs. scheduled data (eg. delays in dependency of certain weather, season, etc.), we can optimize the resources. Analysing connecting flight info can help to improve turnaround ground times and avoid delays, detecting frequent aircraft changes can help to improve gate allocation an other scenarios.
And looking at the big picture, if we would be able to collect from a network or countrywide or on a level like Eurocontrol, Big Data analysis certainly will create more valuable insights and improve on-time performance.

Big Data Bookshelf

Big Data: Principles and Best Practices of Scalable Realtime Data Systems

Big Data For Dummies

Ethics of Big Data: Balancing Risk and Innovation

Data Science for Business: What you need to know about data mining and data-analytic thinking

Some assorted links

Airport AODB in the Cloud and Big Data

Working for more than 15 years with IT systems in airport operations I pretty much experienced most areas from development, testing, system integration, documentation, training and project management. I spend many years on and with a classic client-server based system, partially with legacy technology, and designed and built an AODB from the scratch in new technology and deployed it to the cloud. Two topics drew my attention particularly in the last few years, the “AODB in the Cloud” and “AODB and Big Data”, I like to review them in some short articles here. This talk is politics-free and does not refer to specific products or companies.

For the reader without airport operational background my elevator speech description for AODB. (Did you notice ? there is no entry in Wikipedia for AODB.)

AODB – Aiport Operational Database
An AODB system is usually the core IT system to support the airport ground operations, it integrates with various systems from the heterogeneous IT landscape found at the airport, compiling data from airlines flights schedules, flight plan management, communication between airlines and airports to building management systems, live ground movements and many more systems.
It serves as platform for CDM (Collaborative Decision Making) for the various parties forming the airport community, from airport operators, airlines, groundhandling agents to ATC (Air Traffic Control).
It handles seasonal and operational flights by providing both real-time and historical data, supports resource management for facilities and equipment, as well for staff, it is an information portal.

The AODB itself can be reduced to a simple 3-tier piece architecture, a database, business logic processing layer and a frontend.
It can be complemented by ESB (Enterprise Service Bus), BI (Business Intelligence) and other components.

Unlike consumer (software) products, this is rather a niche market, and AODB systems are offered only by a couple of companies. To name a few (in alphabetical order):
Amadeus, Arinc, T-Systems, IBS, Inform, Intersystems, ISO, Ultra,.. I leave it to the reader to find out more about these companies and their products.

The U.S. National Archives At Portland International Airport 05/1973

I like to discuss in the next few blog entries the following topics triggered by the technical and operational evolution AODB systems are going through.

Image: At Portland International Airport 05/1973 by The U.S. National Archives (cc)