Tag Archives: Dashboard

Aeriaa Airport Dashboard. Controlling airport facilities, Jetways

In the last post of the airport’s systems mock-ups, we created the first steps of a DCS system for our airport, after the AODB and BHS, now, we change the scope to the airport’s facilities, a little SCADA system for monitoring the airport’s jetways (also known as Boarding bridges, Jetties, Air Bridges) status on an iPad App, this system will be another event producer for the Dashboard, and itself is a nice tool for operations and maintenance departments. In the tech part of the article, we are going to show how reusability boosts a global architecture system’s plan. We are going to take advantage of previous Web Services we exposed, the integration with MongoDB collections, and the look&feel designed in web apps (AODB and BHS). But, we are going to introduce a new technology for the Web APP, AngularJS, a very interesting front end framework.

Jetways demo aeriaa

Jetway iPad app Monitoring Mock-up. Credit: www.aeriaa.com



These are the features of our new airport’s system mock-up:

  • Show the status of the main jetways and stand modules. 
    • Docking Guidance System (DGS). This system helps the pilot for identifying its stand assigned and the correct aircraft’s alignment and final position on the stand. I also shows practical information data for the pilot as time milestones.

Visual Docking Guiding System in Action. Credit: http://www.sloveniacontrol.si

Visual Docking Guiding System in Action. Credit: http://www.sloveniacontrol.si

GDS showing TSAT time. Credit: Zurich Airport

DGS showing TSAT time. Credit: Zurich Airport

    • 400Hz: this system provides electrical energy to the aircraft when the engines and APU shut down, the frequency is due the size of the aircraft’s module, its size allow to be smaller and lighter.

Ground Power Unit providing energy

Ground Power Unit providing energy

    • Air Conditioning (AA): this system provides fresh conditioned air when the aircraft is stationed.

Air Conditioning provided to an aircraft. Credit: http://www.aircrafttowbar.eu

Air Conditioning provided to an aircraft. Credit: http://www.aircrafttowbar.eu

    • Signals simulator for triggering the events on-off of each subsystem.
  • Look up the flights assigned to each jetway.
  • In the next version these features are expected:
    • Provides information to the Airport’s Dashboard, about jetways availability and alerts for specific flights.
    • More integration with the AODB for the resource’s assignment and events that overcomes new estimated time to departure (ETA) due turnaround affections (TOBT) and in-off block expected times. (IBK/OBK). Enlazar con post de tiempos.
    • Integration with an airport’s maintenance system.

In this case, as DCS, we’ve chose again an iPad App for implementing the main functionalities mentioned above and a Web App for implementing the signals simulator for the DGS, 400Hz and AA modules, as well the main jetway’s general status/availability.

Jetways giving service to an A380. Credit: www.thyssenkrupp.com

Jetways giving service to an A380. Credit: www.thyssenkrupp.com



As my budget is “limited” for acquiring a full electric, modular and fieldbus components, connectors/actuators, etc. I developed a web app that throws the signals. The main use of this app is to change the values for each jetway, each of them, and its modules, is represented in a table’s row. let’s see the main interface.

Jetways Web App simulator.

Jetways Web App simulator. Credit: www.aeriaa.com

When we change any value, the web app and the backend executes the next actions:

  • Call a Web Service and report the new value in real time.
  • The backend receives the data and insert directly in a real time database.
  • So the data is served in real time and the iPad App can have the data updated at any time.

Let’s see the meat of this (techie part of the article), as we said above, I developed the web app using AngularJS, a great frontend framework that gives me a perfect modularity for creating web components and the glue for combining them. So, when I changed a value this part of the web app (named controller) reacts to the change.

Changing values in the simulator. Credit: www.aeriaa.com

Changing values in the simulator. Credit: www.aeriaa.com

Toggle Button component. Credit: www.aeriaa.com

Toggle Button component. Credit: www.aeriaa.com

App directive for the Toggle Button. Credit: www.aeriaa.com

App directive for the Toggle Button. Credit: www.aeriaa.com

With this event we directly call the Web Service and pass the data.

Calling the Web Service for updating the jetway data. Credit: www.aeriaa.com

Calling the Web Service for updating the jetway data. Credit: www.aeriaa.com

In the backend, developed with NodeJS and reusing the previous code’s snippets of the AODB, BHS and DCS mockups, we are listening a new call with this data and insert it directly in a MongoDB collection.

Web Services defined in NodeJS Backend. Credit: www.aeriaa.com

Web Services defined in NodeJS Backend. Credit: www.aeriaa.com

Jetway data on MongoDB collection. Credit: www.aeriaa.com

Jetway data on MongoDB collection. Credit: www.aeriaa.com

And that’s all.


In this version, the app, retrieves information about the jetway’s status and the assigned flights to them. This how the app does it:

When the user clicks on any of the jetties, the app requests the info to a Web Service, in the same NodeJS’ backend where the simulator sends the data in real time. The data returned has the jetways status and the flights assigned to it.

When the user clicks on a jetway, the app request the data to the backend. Credit: www.aeriaa.com

When the user clicks on a jetway, the app request the data to the backend. Credit: www.aeriaa.com

Data returned after the user's action. Credit: www.aeriaa.com

Data returned after the user’s action. Credit: www.aeriaa.com


One video worths one thousand words. Enjoy the full demo in the following video, remember that aeriaA has a Youtube channel, please visit it and its playlists. Disclaimer: the app design is very alpha, do not complaint about it :)

For better visualization, please, maximize the video or visualize it at youtube. It also has nice music.

For more info:

Docking Guidance System explanation by Zurich Airport (PDF): Aircraft Docking Guidance System

Docking Guidance System at Wikipedia: https://en.wikipedia.org/wiki/Stand_guidance_system

Please follow us at:

twitter. @aeriaablog

facebook: aeriaA at Facebook

LinkedIn: aeriaA at LinkedIn

Personal LinkedIn: es.linkedin.com/in/pedrogarciafernandez

Youtube: aeriaA at Youtube.

Aeriaa Airport Dashboard. Creating the DCS (I)

In this article we are going to show you the first real combination of three airport systems, the AODB, the BHS and the Departure Control System (DCS). We built the first AODB and BHS functionalities in these articles AODB part I and BHS part I. First we’ll sum up the main functionalities of the AODB and BHS, then we’ll show the a few new functionalities on them for the DCS integration and finally we’ll show the DCS mockup developed for iOS platform in order to test new technologies and how they combine with the other we are using in these article’s series.

Boarding Card issued by our DCS mockup in iOS

Boarding Card issued by our DCS mockup in iOS

Aeriaa Airport Dashboard. Creating the BHS (I)

In the previous article we started to develop the basic airport’s systems four our Airport Dashboard’s Project, the AODB mock-up, in this article we are going to build another airport’s system mock-up that has a relationship with the AODB, the Baggage Handling System (BHS), not the physical system but the Sort Allocation Computer (SAC). Please see this article for a introduction of the AODB & BHS relationship. To sum up, the BHS has the following main features.

  • Transport, classify and deliver each baggage to its destination carrousel (departure and arrival flights).
  • Process the baggages in the integrated security subsystem. As X-Ray machines that look for hazardous substances, material, drugs, explosives, etc.
  • Store the baggages for early check-in flights.

What data do we want from BHS to our Dashboard?

  • General process status and metrics. Bags per hour, first bag delivery time, luggage events per flight, bad reading tag ratio, system status, percentage of manual sorting in comparison to automatic sorting, percentage of bags that are wrongly sorted by the system (sent to a wrong carrousel), average time and standard deviation regarding the time to be sorted by the BHS, etc. Thanks Pablo Roux for some KPI’s suggestions.

What data does the BHS (SAC) need from the AODB?

  • The flights scheduled for a time period (day, week, etc.). Where are they planned to be parked.
  • Any flight’s relevant updating in real time, any new estimated time of arrival or departure (ETA, ETD), cancellation, stand reassignment, etc.

Are there other systems closely related to BHS?

  • Yes, the Airlines Departure Control Systems from the BHS will be notified about the baggage checked, through SITA. (see the article mentioned before)


Baggage Handling System Blueprint

Baggage Handling System Blueprint

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 www.aeriaa.com/on-the-aeriaa-airport-dashboard-part-v-time-milestones/
  • 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

On the Aeriaa Airport Dashboard (part VI). Events Logger

Some days ago, a friend of mine, Ram, put me on the track of Splunk, I’ve never noticed it, so I downloaded it and at the first glance I knew it was perfect for the Logger component of the Dashboard’s architecture, let’s remember it (if you are new to this blog see the previous posts):

Aeriaa Dashboard Project - Logger

So, I put to test a little with it. Let see all after the jump.

On the Aeriaa Airport Dashboard (part V) – Time milestones.

Before processing thousands of events, scenarios, etc. for feeding the Dashboard, I would like to show the a dimension that put in context almost every event. The time dimension. Delays are the “Oh, no, a delay again, what was the captain reason this time?” The late arrival of the plane, air regulation over the airport…I heard once that the guilty factor was the “shamefulness of being part of an airline because the ramp handling staff were late….some other details were given by the captain and it was a gesture of honesty”. We, the passengers only concern about only time milestone, the scheduled departure time of our flight, and pray for not have a big delay, but there are always 10, 15 minutes of courtesy. In this post, you will see dozens of time milestones, that impact over all the punctuality process of the flight operation and consequently will be marked in the Dashboard we are defining in this blog (this is the part V of this series).

Airport timetable

On the Aeriaa Airport Dashboard. (part IV) Events

It’s time to talk about the airport’s events, one of the more complex situation in the airport’s management is to monitorize the thousand of events that are fired every day and manage them in order to take decisions. Events as flights delays, long check-in lines, the time milestones of a fligh operation (I will talk about some of them soon), aircraft maintenance, refuelling, weather conditions, security and safety incidents, baggage processing phases, air navigation events, terminal comfort (illumination, heating…), etc, etc. If there is a place where the “butterfly effect” take place this is an airport. A simple event can raise delays not only in the airport, but it will cause delays in other networked airports. It’s familiar to you the Captain’s apologize. “We are sorry for the departure’s delay, it is caused due a ‘late’ arrival of the previous flight…” 

On the Aeriaa Airport Dashboard (part III) – AODB and BHS

Following the Aeriaa Dashboard (see part I and part II), it’s time to talk about data sources, this includes systems that provide information for our Aeriaa Dashboard architecture. In the basic architecture diagram, shown in part II, you can see the Databases and Airport Systems components.

Aeriaa Airport Dashboard Architecture


Let’s put in context a couple of systems that we are going to use in our Dashboard.

On the Aeriaa Airport Dashobard (part II). Architecture

Aeriaa Airport Dashboard

In the previous post (On the Aeriaa Airport Dashobard part I) I introduced the environment of this little demo project. I want in this post define the project scope, in order to develop the “Project Charter”

  • Aeriaa airport, principal stakeholder need an airport dashboard for viewing the status of the primary airport processes.
  • These processes (or flows) are: airplane process, passenger processes (departures and arrivals flows), baggage processes and another group (not less important) with security, power, IT, etc.
  • The dashboard will inform about the status and the future trends and affections of processes and between them.
  • Simple navigation, concise, and simplicity with data visualization.
  • We will access to the dashboad from everywhere.

Also, this dashboard will be used as source for process reengineering.

On the Aeriaa Airport Dashboard (part I)

I would like to start this section with a homemade post. I like planes, I like computers, I like airports, I like the connection between techonology and aviation, so lets make a little application related to airports using some technologies, some of them new for me, to build a demo with some sense. The purpose of this demo is technology self learning and for sharing with you some airports concepts.
Let’s start!

Demo App: The Aeriaa Airport Operation Dashboard.

Imagine that there is a big-size airport called Aeriaa International Airport, with a fake IATA code, AEI (some day I’ll post why the airports code are composed) with about 20 million passengers per year and with one huge terminal building.