Stephen P. Carroll, Flight Operations Project Manager, Qatar Airways explains an integrated flight tracking system as used in the airline

The main focus of this article will be TOPS (Total Operations System) the flight tracking system we’ve developed at Qatar Airways. But first of all, it will be useful to set the scene with a few facts about the airline. We serve more than 150 destinations worldwide and have an additional 13 routes planned to start in 2016 and 2017. As a global operator Qatar Airways has to track flights worldwide. The routes we serve cover all the Oceanic areas. We operate more than 180 aircraft, including all Airbus types, the A320 family, A330, A340, A350 and A380, plus Boeing 777 and 787. We have more than 300 aircraft on order for delivery over the next five years. Putting it into numbers, we track more than 500 flights daily and we process a phenomenal 1,700,000 position messages every day that come via ADS-B (Automatic Dependent Surveillance – Broadcast). From the aircraft we get FMC (Fixed Mobile Convergence) and M16 position messages. That amounts to 2 billion bits of data every day, which is quite a task to manage and interpret.

We started our flight tracking project in 2013, prior to the March 2014 MH370 incident that brought the subject of flight tracking significantly to the fore. The objective was to give our dispatchers the tools to manage their job in one single application; to improve efficiency, safety and awareness, using integrated and automated intelligent software. We didn’t want them to have to use several different systems, so we wanted everything they required to be in one place: plus, we wanted to optimize the system to allow the creation and implementation of high quality operational solutions in the future, quickly and effectively. The TOPS project started in 2013 to deliver a modular system that included fleet tracking, crew tracking and flight tracking – we also wanted a system to undertake the creation of maintenance checks on our aircraft, allowing complete fleet and maintenance tracking in a single system. The resulting solution is all tied in to one database, so that we’re all working with a single set of data. We wanted to integrate our systems so all required planning and actual data comes in to TOPS and to provide mission management capability to all the dispatchers, IOC and partners. Qatar Airways wanted to know where all our aircraft are at any one time; we’ve got a large fleet and we wanted real-time data and tracking. We wanted to be sure that if anybody asks ‘what’s happening with this flight?’ we can answer right away.

When we started looking at the flight tracking piece of TOPS, we needed to know what technologies were already available on our aircraft and on the ground. Of course, cost is always a factor, so in that vein, we wanted to see how we could achieve flight tracking with the information already available to us and using equipment already on the aircraft. So we needed to establish what messages are already being transmitted and how can we get those transmissions onto a ground system to display on a map? That was one of our thought processes.

 

Naturally, any solution would need to meet the requirements of the end user; so we had many brainstorming and scoping sessions over the next few months with the dispatchers, the Ops controllers, the engineering people and others stakeholders. Having started the project in 2013, we embarked on development early in 2014 once we’d completed all the documentation, which included the detailed requirement specifications and functional specifications. All of that was completed prior to the MH370 incident, the ATTF (aircraft tracking task force) findings and the NATII (Normal Aircraft Tracking Implementation Initiative).

Tracking data comes from different ground systems as well as aircraft generated data, and we had to consider how we could be sure that the data was properly tagged and designated to the correct flights. That’s not as easy as it sounds because data arrives at various times with different time stamps; if we were to put one piece of data before another there’d be a spike in the tracking line that would give a poor representation of the actual operation. We had to think about how we would manage all that data and how we could conduct testing to validate that the information is correct. These were some of the things that we needed to think about. Also, because it was brand new system, we needed to identify providers of specialist products such as weather overlays. When the search couldn’t find anyone who could meet our requirements off-the-shelf, we had to go to a company to develop the weather overlay products for the system.

In addition, there were lengthy GUI (graphic user interface) design discussions with users and business analysts to make sure that the system would be feature-rich but not too complex, i.e. easy to use – there’s nothing worse than getting a new system with loads of icons and a plethora of information of which only a small part is useful. It’s context sensitive as well; if there’s a flight from A to B, there might only be two or three things that flight can do in that phase; so there’s no point in having all the different functions available for selection. We also had to analyze all data sources and ensure that we had robust interfaces to guarantee data integrity.

The flight watch system takes multiple data from, ACARS (Aircraft Communications, Addressing and Reporting System) messages, flight schedules, flight plans, weather information and different types of overlays and the external data supplier that we finally found to do some of the jobs that we needed was Weather Forecast, a company in California. They developed from scratch all our weather overlay products. For the FIR (flight information region) overlays we went to ICAO: ICAO provides the files and Weather Forecast creates the overlay for the FIRs display. We use ADS-B (Automatic Dependent Surveillance – Broadcast) data for Flightradar24 (a live flight tracker that shows air traffic in real time) using a dedicated feed for our own aircraft and another for other airlines’ aircraft. So, if we’re in an airport where the weather situation’s bad, we can see what other airlines are doing at that airport. The maps are from Google and flight plan data comes through a feed from Lido flight planning solution provided by Lufthansa Systems.

 

For the data delivery infrastructure from the aircraft we use ACARS to provide our position reports. These are delivered as FMC and M16 AOC position reports, which have been customized to give us all the data that we need to meet the ICAO requirements for 4D/15 normal aircraft tracking. The M16 is an airline specific message, which is delivered from an aircraft equipped with VHF or satcom; for aircraft not equipped with satcom, it will be delivered via VHF where the limitation is a dependence on the equipment in the ground infrastructure as to whether the message is delivered or not.

The information flow into our system is shown as in the illustration above where readers will be able to see that it is fed into the Hermes server and then into TOPS to be presented to the user as on the inset screen showing the type of data, it’s reading and when it was last updated.

Looking to the future, to try and deal with some of these gaps that we have, we’re looking to implement, as already mentioned, the SATCOM on the A320 fleet, HF Data Link (HFDL) via Rockwell Collins and HF Performance Data (HFPD), also via Rockwell Collins; also we’re doing a proof of concept at the moment with Inmarsat to provide information through SBB (smart buffer box) satellite data. We want to ensure that our IOCC (integrated operations control centre) is alerted when they don’t have any connectivity with the aircraft. In that sense, we’ve gone in a different direction but we still get the ‘no connectivity’ alert. We also have linked that to ‘no connectivity at all with the aircraft’, not just position messages. So, for the A320 fleet if we don`t receive any position messages but we’re still connected, we can see that the aircraft is sending data down to trend monitoring, engine monitoring and all the other bits and pieces such as media connections… it is possible to still be connected but not get position reports. As soon as we get a ‘no connectivity’ alert, we can check that.

If we receive a ‘no connectivity’ alert we can click that alert on the screen, the FIR region that the aircraft is in will be highlighted and the aircraft icon on the screen starts to flash. At that point, and if it’s a long time since we’ve received any data, we’d check the flight information and company policy is that the flight watch officer should endeavor to establish contact with the aircraft via VHF or through other nearby aircraft. If contact can’t be established, the ATS (Air Traffic Service) would be contacted for ‘last known position’ assistance in locating the aircraft. If they cannot connect it, that would be the start of the alert phase. Having acknowledged that there is an aircraft with no connectivity, that information gets stored for future reference so that we can go back to work out why the ‘no connectivity’ situation arose… perhaps the pilot had thought that they were too busy at the time to deal with it. Also the duty manager and IOCC would see that.

If we wanted to communicate with the aircraft we’ve integrated our Hermes Messenger system with TOPS so we can send messages direct from the system to the aircraft via ACARS and the aircraft flight crew can respond to the message straight into the system so that everything is available in one place; users don’t have to go into Hermes Messenger to check for a particular flight showing on the map, everything is available in this one application. It’s tabular as well, so it’s possible to have multiple maps open and multiple tabular views open with areas of interest that the user might be working on at the time such as working with flights operating in Europe or flights operating ETOPS (extended twin engine operations). The user can then create a tabular or a map view for flights of interest.

 

The system is flexible in many ways for example controllers can increase the reporting frequency while, say, an aircraft is passing through an area of particularly bad weather and can be monitoring as many flights as they want to. Also, the alert count per flight is variable and, if the user clicks on it, the alert message comes up and alerts are generated based on several parameters; time, fuel, height… plus the user can see the history of all alerts once the current one has been acknowledged. The message icon will allow the controller to see any unread message for that flight. To view the selected flight for, say, destination information, the controller just clicks on the appropriate aircraft icon to filter the map view with just that one flight. It’s all context sensitive so will only give the user options that are available for that particular flight at that time. And, again, it’s all available on just one screen.

Multiple tabs help flight watch officers keep watch on specific areas, aircraft or operational situations, they can go in to the system, look at, say, European flights, change the names of the tabs, for easy tracking etc.

It’s taken us about a year from the start of development to get to this point. Originally, when we were looking at the TOPS project, the flight watch wasn’t planned to be as detailed as this. We’ve taken in to consideration everything going on in the industry since MH370 to deliver a product that fulfils everything our dispatchers require and that staff and partners want as well. We have all of this information shown on our huge video wall; we can take different views, take account of tropical storm or volcanic activity and we can set the system to track a chosen aircraft at various intervals or if necessary, every minute.

Our plan is to automate this process: what I’ve covered in this article is phase one and we plan to bring in phase two in the coming months.

All the findings that have come out of the NATII SARPs (standards and recommended practices) still require some work to be done by the ANSPs (Air Navigation Service Providers) and by operators. One of the main issues operators face is knowing when they’re responsible to be tracking their aircraft, and when the ANSP is meant to be doing it. To cover this we have decided to track from take-off (the first OOOI message when the aircraft leaves the stand) to landing (the last OOOI message when the blocks are put on after the flight).  Another problem that still requires resolution and direction from ICAO is, when one wishes to contact an ANSP, having the correct contact data available in a centralized repository, hosted by ICAO that is  in a machine readable format for keeping operators ground systems up to date is required.

As always, during a complex software development project such as this, where lots of people, corporate departments and outside contractors are involved, we learned a few lessons that will be useful to bear in mind for the future including streamlining the involved project managers to speed up progress, robustly testing data quality and building realistic timelines with necessary buffers. .

We had to undertake a lot of training with the flight watch officers, because it was a new position in the IOCC; we previously didn’t have ‘flight watch’ and worked on the basis that, after take-off, we’d hear from the crew if there was a problem, otherwise we’d hear from them after they’d landed.

We’ve also had to develop and implement a number of new processes and procedures to leverage the best performance from our state-of-the-art system. Looking to the future; we have a road map and are continually developing the product with plans for additional functionality in the coming months and beyond based on additional business requirements, developer enhancements and regulatory requirements.

Stephen has more than 20 years of aviation experience, starting with the RAF. Since leaving the services in 1997, he has worked with various aircraft operators and airlines in flight operations with Business Aviation, Cargo Operations and Airline Operations. Currently, with Qatar Airways, he has had experience as a controller and in flight operations Systems and Processes. For the past three years he has worked as a Flight Operations Project.

Qatar Airways serves more than 150 destinations worldwide. Voted Airline of the Year 2011, 2012 and in 2015 in the prestigious Skytrax industry audit, Qatar Airways has achieved route expansion averaging 30% year on year, flying one of the most modern fleet of aircraft in the skies today. The network spans business and leisure destinations across Europe, Middle East, Africa, Asia Pacific, North and South America, operating from a hub in Doha.