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.
Let’s put in context a couple of systems that we are going to use in our Dashboard.
AODB (Airport Operational Database):
The AODB system is one fo the most important systems in this architecture. It is the flights information owner in the airport. It mission is to manage the next functionalities:
- Real time flight operation information.
- Flight planning, this includes scheduling, resources assignments (counters, stands, belt, etc.)
- Airline and handling billing.
- Integrate with other systems and organizations. As Eurocontrol (in case of Europe), Handling companies, Airlines, FIDS system, Baggage Handling Systems, CUTE, ATC systems….
So, what data do we want from AODB to our Dashboard?
- Flights data with real time events. Events as new, cancel, delayed flights, take-off and landing times, check-in times, resource assignments, etc.
- We’ll have several type of message types. I put here a very simple one, a departure flight message with the minimmun information required, it is expresed in JSON format:
{“Flight”:”IBE6825″,”ICAO”:”IBE” ,”Destination”:”SAO PAULO /GUARULHOS ” ,”Company”:”IBERIA” ,”Terminal”:”A” ,”STD”:”00:20″ ,”ETD”:”00:20″}
It is an Iberia flight IBE6825 with destination Sao Paulo, Brazil, with an scheduled time for departure at 00:20 and with the same estimated time for departure, the flight will operate in Terminal A.
- The messages will flow from/to the AODB to/from Data Distribution Bus. We then request for information to the AODB and/or subscribe the data issued by AODB.
BHS (Baggage Handling System) and DCS (Departure Control System):
The BHS is the system that handles the baggages from the check-in counters to the flight’s designated belt in order to get boarded in the aircraft. It also provides the inverse baggage path, from an arrival fligth to the recovery baggage belt. Simplified this systems has the following functionalities:
- Transport, clasify and deliver each baggage to its destination belt (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.
For the baggage clasification process we need to mention another key system, the Airline’s Departure Control System (DCS), this system provides the functionality to check the passengers and its baggages, delivering the boarding pass (if it is not autchecked at home :)). To sum up the participation of the DCS in the handling process here it is a sequential activities list, later I will put a diagram.
- A passenger checks a baggage.
- The handling clerk issues the baggage’s printed tags (or RFID), and put it on the baggage. At this time the DCS provides the event of a new baggage checked and the airline host system (DCS backend) publish a message to the SITA Baggage Handling Messages Gateway (I supposed that the airline and the airport works with SITA).
A baggage Tag (source Wikipedia):
- SITA publishes a Baggage Source Message (BSM) with the passenger information, flight, destination, schedule, etc, to the BHS. This is an example (the baggage code as printed in the tag is 851743560)
BSM.V/1TZRH.F/SR10/1/04JAN/JFK/F.N/0/0/851743560/0/ENDBSM
- The handling clerk introduces the baggage in the BHS belts.
- The BHS has a message from SITA that identifies a baggage, and it also has a baggage with 2D printed tag that identifies with the same “baggage number” issued by SITA.
- The baggage pass over a (or several) BHS 2D (or RFID) scanner, the BHS matchs the 2D (or RFID) code with the BSM message, and then knows the baggage’s flight (the flights are taken from the AODB) and knows where to deliver it.
- The baggage gets the formation baggages belt, and the baggage ramp guys put it on containers or in baggage trucks for delivering it to the aircraft. The BHS returns a processed baggage message to the airline through SITA gateway, so the airline has the baggage delivery confirmation.
It’s only a sequential process simplified, there are many other variants in the real world that not use this system components and activities. Also, this process has backup activities to solve problems as, not have BSM, bad tag reading, communication problems, mechanical problems, etc.
The BHS can track the baggage in the full process.
As promised here you have an integration architecture diagram that shows this process:
SITA logo is a registered trademark of SITA
Check-in counter photo is taken by Fran Martinez
So, what data do we want from BHS to our Dashboard?
- General process status and metrics. Bags per hour, first bag delivery time, baggage events per flight, bad reading tag ratio, system status, etc.
Databases component:
Finally I want to talk about the architecture’s Databases component. We will use MySQL for Relational database and MongoDB for NoSQL data.
All the data related to real time events, data composed, log data, etc, will be stored in MongoDB, and some entities that will be modeled in the Business Model Logic component will be stored in MySQL. We will see more about this in following posts.
See you in next posts.
This work by Pedro Garcia is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
