AODB's Departures Flight new look.

Aeriaa Airport Dashboard. Creating the AODB (I)


Following the aeriaA Airport Dashboard Project series, in this post we will build a little Airport Operational DataBase (AODB) system for our Dashboard’s architecture. This post is mixed oriented, it is a  little introduction of an AODB and a little introduction of the technologies used for building it.

The AODB is one of the central part of the whole project. We simplified a lot the AODB’s features, it is not the intention to build a real one, these are the main features:

  • Manage the Departures Flights of our Aeriaa International Airport.  We can create, update and delete departures flights (We will develop the arrivals flight later).
  • The frontend is a website application. We’ll try in the the future a smartphone app (step by step).
  • The flight’s attributes at the first data model are (alphabetically ordered):
    • AOBT. Actual Off-Blocks Time. It is the time when the fight is ready, doors closed, jetway decoupled, and the towbear available for the push-back.
    • ASAT. Actual Start-Up Approval Time. It is the real time when the flight has the approval for start the engines.
    • Aircraft. The aircraft model.
    • Company. The airline company.
    • Counter. The designated counters for the flight.
    • Destination.
    • ETD. Estimated Time for Departure.
    • Flight. It is the fight’s code.
    • Gate. The gate assigned for the flight.
    • ICAO. Company’s ICAO code.
    • STD. Scheduled Time for Departure.
    • TOBT. Target Off-Block Time. It is the target time for the Off-Blocks Time (see AOBT)
    • TSAT. Target Start Up ApprovalTime. See ASAT.
  • We included some time’s milestones (TOBT, TSAT, AOBT, ASAT) related to A-CDM philosophy in order to approach the AODB to this new work collaboration paradigm. There just a few of the huge times complexity of A-CDM. You can find a big list of time milestones here
  • Billing the services provided by the airport or ground handler that the airline must pay. The services could be the push-back service, the jetways, follow me car, baggage handling, counters, etc.

Building our AODB System mock-up. Image Credit: Pedro Garcia

The following diagram shows the IT architecture of this project, the AODB is included in the Airports Systems box. Among others, the Airports Systems box is composed by the AODB, the BHS (Baggage Handling System), FIDS (Flights Information Display Systems), BMS (Building Management Systems), CUTE (Common Use Terminal Equipment – Counters), etc, etc.

The AODB i one of the Airport Systems.

The AODB is one of the Airport Systems.



For our AODB we will use these tools: NodeJS, REST API, MongoDB, JSON, HTML, jQuery and CSS. Let’s have a look to what offers each technology for the AODB:

  • Node.js is an open-source software platform that is used to build scalable network (especially server-side) applications. Node.js utilizes JavaScript as its scripting language, and achieves high throughput via non-blocking I/O and a single-threaded eventloop. Node.js contains a built-in HTTP server library, making it possible to run a web server without the use of external software, such as Apache or Lighttpd, and allowing more control of how the web server works. (Source: Wikipedia)

We’ll use NodeJS because it is really fast to develop with it the server side (Web Server) and the Web Services (REST API) for managing the flights and the Database connection, in this case we will use MongoDB.

  • MongoDB, is a open-source schemaless database, very very flexible with the data model, it not uses SQL language for interacting with the data, the data is stored as documents (based on JSON format), geospatial index and data, it has Map/Reduce features for aggregating and data processing and it is very scalable. In this demo we will change the data model of the AODB and have a non-schema database will ease our duties.
  • JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. We use it at the preferred exchange data representation, we’ll use XML as well. Here it is a JSON document example with the information of a flight:

{“Flight”:”AAL5534″,”ICAO”:”AAL” ,”Destination”:”NEW YORK-JFK” ,”Company”:”AMERICAN AIRLINES” ,”Terminal”:”4″ ,”STD”:”06:40″ , “Counter”:”380-385”, “Gate”:”B34”, “Aircraft”:”B777″,”ETD”:”06:40″};

  • REST API, is the Web Service flavor we’ll use and it represents the interaction mechanism between the AODB’s data (flights and billing) controlled by NodeJS and MongoDB and the client (browser, smartphone, tablet, etc.). It has the way for request, update and delete information related to flights and billing. It is really powerful because it uses the HTTP protocol and its verbs. GET, POST, PUT and DELETE for performing the actions of Read flights, Create flights, Update flights and Delete flights respectively.
  • HTML, as the standard language for building the frontend of the AODB in a browser.
  • CSS for formatting (styling) any component of the HTML web pages and given them some usability and good looking appearance.
  • jQuery, is a JavaScript library very useful for any aspect of a web page interaction and manipulation, user interface, JSON document parsing, Web Services (REST) requests, multi browser compatibility, etc.


So these are the ingredients, let’s cook them and start to build a simple AODB. The basic architecture is showing in the next diagram:

Our simple AODB Architecture

Our simple AODB Architecture


For this first development, we are going to use the public flight’s information of the spanish Madrid-Barajas Airport (MAD) we have copied all the flights of one day and we will play with this data. In an excel sheet we import the data and we added some new fields as AIRCRAFT, ICAO (extracted from Flight code), and the time’s milestones TOBT, AOBT, TSAT and ASAT for completing a bit the basic information for the first development iteration.

Public flight information taken from MAD.

Public flight information taken from MAD.

At MongoDB we’ve created a database called “aeriaa” and the collection (of flights) “departures”.

Let’s build the MongoDB insert sentences for creating the flights on the database. With the excel’s CONCAT formula we built the sentence with the MongoDB syntax and in JSON format. The sentence for one of the flights is as follows:

db.departures.insert({“Flight”:”IBE6825″,”ICAO”:”IBE” ,”Destination”:”SAO PAULO /GUARULHOS ” ,”Company”:”IBERIA” ,”Terminal”:”4″ ,”STD”:”00:20″  , “Counter”:””, “Gate”:””, “Aircraft”:”A346″, “TOBT”:””, “AOBT”:””, “TSAT”:””, “ASAT”:””,”ETD”:”00:20″});

We have inserted all the departures flights (more than 500) on the database, and we already have the database populated with data.


The REST API of our AODB, is built on NodeJS, we basically need three main things.

  • The server where we listen for requests.
  • The routing for the requests based on its URI.
  • The Database’s functions for connecting and managing the data.

The Server, an IP address and a port.

REST Server for the AODB built in NodeJS

REST Server for the AODB built in NodeJS

When a request arrives, the server must know how to response it, the URI says what kind of resource the App wants and what kind of operation with the resource must be executed. For this, first we set the /departures URI as the main entry point for any request related with departures flights, so any request with this pattern. will be routed with the following criteria:

AODB Departures Web Service REST API built on NodeJS

AODB Departures Web Service REST API built on NodeJS

For reading purposes, any request that comes with or (with GET verb) will retrieve from the database all the flights or a specific flight passed by argument.

Requests with POST, PUT and DELETE verbs will create, update or erase the flight passed by argument.

All the requests will be routed to server’s functions that handle the data with the MongoDB database.


For building the app we first need to create the Web Server on NodeJS (in the same file as the Web Services), it is very simple, all the code we need for this purpose is this (we could reduce the code to 6-8 lines of code):

Our Web Server for the AODB app.

Our Web Server for the AODB app.

The Home page for the AODB we’ve built is as follows.

AODB's Home

AODB’s Home

The App has five simple menu options (built with HTML and CSS):

  • Home Page
  • Departures page. Will manage the departures flights.
  • Arrivals page. Will manage the arrivals flights.
  • New Flight. Will manage the creation of any flight.
  • Billing page. Will manage the billing services.

If you liked the menu you can fork it from my little brother’s repository.

In this first development iteration we built the Departures page, we just need:

  • A Web Service call
  • The server will response with the flights and we’ll treat the JSON’s flights formatted data with jQuery and build the flight’s table.

The following code is the JavaScript function we made for request the data and put it on the Departures’ HTML page. (Notice that we did not retrieve all the data fields, we are building a quick mock-up)

JavaScript function for calling the webservice and building the flights table.

JavaScript function for calling the Web Service and building the flights table.

This is the result with a little CSS styling (it is still a quick prototype):

AODB's Departures Flights

AODB’s Departures Flights

The table, and the web app, is responsive (the smartphones and tablets have its own view), you can view the CSS responsive table, also developed by my little brother here.

[Updated 23rd March 2014] In the next article of this series (BHS Creation) we introduced a new look for the AODB.

AODB's Departures Flight new look.

And that’s all for this first development iteration for the AODB. As it is said at the beginning of the post this is just a very little introduction of the AODB concept (please see the AODB and BHS post for more information) and of the technologies used. Remember that we just need a little AODB for the real purpose of the Airport Dashboard, the final goal of this project. In next posts we will complete de AODB, we will probably develop a little FIDS too (we could reuse 90% of the AODB code), a Baggage Handling System (its Sortation SW) and a few more mock-ups for the Airports Systems Box of our Architecture.

All the code will be uploaded to GitHub, but let me finish a bit all the parts.

For more information.

aeriaA Dashboard Project.




Side Navigation Menu and Responsive Table.