This blog will look into the concept of Airport Collaborative Decision Making (A-CDM) and assess why the framework has not fully delivered on its promise. The blog will suggest ways in which airports, airlines, ground handlers and air navigation service providers can build on the existing A-CDM framework and use new AI technologies to increase capacity, lower costs and improve sustainability within the aviation industry.
Once upon a time, when there was no A-CDM
The rise in demand for air travel
The aviation industry has massively expanded over the last few decades. Advancements in aircraft design, developments like open-skies agreements and the introduction of the low cost carrier have all contributed to flying becoming available to an ever increasing group of people. Aviation has evolved from an extreme luxury to a mere commodity. The rise in demand for air travel has however not been fully matched with increased airport capacity. The fact that infrastructure is typically not very flexible, expensive and very time consuming to realise has resulted in an increased pressure on airport and airline operations.
Outdated communication and collaboration methods
In the early days, the management of airport operations was simple and straightforward. Visual line of sight and binoculars were used for observations and radios or phones were used for communications. However, with the rise in aircraft movements, these tools are no longer sufficient while oversight and real time awareness between different stakeholders is ever more important to operate in this high pressure environment. It might be hard to imagine but not too long ago airport stakeholders updated each other on flight updates via phone calls, often using different definitions and therefore not fully understanding each other. As an example, airport A would call airport B that a flight had left. For some, flight departure might mean that the aircraft went off-block, whereas for others it might mean that the aircraft took off. Actually in many parts of the world airports and airlines still rely on this very primitive means of communication and collaboration.
A-CDM to the rescue
Emergence of A-CDM framework
The rise in demand for air travel was highest in North America and Europe. It is therefore not surprising that these regions started introducing more advanced collaboration methodologies in order to manage operations more efficiently. The concept of CDM was originally introduced in the USA first and included the use of common definitions and sharing of data to create a common operating picture. Around that same time the European Air Navigation Service Provider (ANSP), Eurocontrol, was looking for ways to better manage the European airspace and adopted the CDM concept and introduced the Airport CDM (A-CDM) framework. As in the USA the main components of this framework were to use common definitions, create data about certain key milestones of a flight and share these milestones in real time with all stakeholders.
The benefits of A-CDM include increased capacity, better on time performance, lower cost through decreased fuel burn and increased sustainability. Within the A-CDM framework the European airlines, ground handlers, airports and ANSPs defined the key milestones of a flight, and agreed on sharing these milestones with each other in real time. The idea is that the effects of one party’s operation are visible to all other stakeholders directly and they can therefore act accordingly. The operation of the ground handler and/or airline feeds into the overall airport operation and the airport operation, in turn, feeds into the overall management of the airspace. Better insight into the individual components means that airports and ANSPs can better optimize their scarce resources and therefore sustain a further expansion of the demand for air travel and/or minimise the negative effects of the pressure on the system.
The creation of the A-CDM framework was a major challenge as all stakeholders in many different countries needed to align on a single way of working. Furthermore, the implementation of A-CDM at airports has proven to be an even bigger challenge as hundreds of thousands of employees across hundreds of airports in different countries had to change their ways of working. Airports, airlines and ground handlers have invested heavily in consultancy, business change support and digital tools to help them get A-CDM certified. By now we know that these efforts have not been in vain as studies have shown that the introduction of A-CDM has indeed rendered positive results on the benefits that were mentioned before.
There are however some major shortcomings in the A-CDM framework that prevent it from reaching its full potential. Especially, as the demand for air travel has only further increased since the introduction of A-CDM, the need for the full potential of the framework is bigger than ever. In the next sections I will discuss some of these shortcomings and ways to address these.
The issue of manually generated data
Scheduled, target & actual off-block time
As the A-CDM framework was being designed and implemented, it was clear that automatically generated data for the key milestones would be preferred over manually generated data. For most of the milestones within the framework there are scheduled, target and actual values to be shared. The scheduled value, scheduled off-block time (SOBT) for example, is when the ground handler is scheduled to be done with handling the aircraft and it is ready to be pushed back. Obviously, scheduled times are almost never exactly met as the day of operation is not static and many different variables impact the actual execution of the schedule. To accommodate this reality, A-CDM provides the target values. In our example, the target off-block time (TOBT) is the time the ground handler estimates he will be ready with handling the aircraft. This time can (and should) be updated continuously to always represent the most current target time. Finally, there are the actual times which in our example is the actual off-block time (AOBT). This is the time when the ground handler was actually ready with handling the aircraft and when it was pushed back.
Off-block time automation
Both the scheduled and actual times can be quite easily automatically generated or pulled from a system that holds this information. A SOBT would for example be present in the ground handler’s resource management system or might be calculated from the scheduled departure time. The actual off-block time could be generated as the airport’s ground radar picks up the aircraft moving backwards from the stand onto the taxiway. However, the target times are much harder to automate as they currently rely on the ground handler’s knowledge and experience. It is worth noting that from all timestamps, the target times are actually the most valuable in terms of operations management. As mentioned before, the scheduled value does usually not represent reality and the actual times do not have any proactive power as they merely represent a record of what has already happened.
Issues with off-block time updates
What we see in reality is that the practice of the TOBT is very far off from the theory. Typically ground handlers are busy with many activities in parallel and often forget to update the TOBT. Furthermore, when looking at TOBT performance we see that ground handlers typically only update the TOBT once instead of more frequently as would be desired. Finally, ground handlers typically update the TOBT very shortly before the SOBT which means that the ability for all other stakeholders to act proactively is lost. If we empathise with the role of the ground handler, it does not come as a surprise that they are typically acting as described above. It is however also easy to imagine that this behaviour prevents the system from performing in the most efficient way.
As an example, imagine a ground handler that is running behind schedule. He thinks he might be able to make up the lost time and decides not to update the TOBT. Now he has to work even harder and in the process he does not realize that he will not make up the time already lost. Only when the SOBT approaches he realizes that he needs to update the TOBT and he sets a new TOBT. In the meantime the airline has already decided to rebook some passengers onto another flight as they were not able to make their transfer based on the TOBT they used to evaluate this case. The airport’s gate planner has also not implemented a gate change so the aircraft that is scheduled to use the stand next, is now waiting (and burning kerosene) until our flight will vacate the stand. Air traffic control has planned both runway and airspace usage for this flight based on the TOBT which now goes unused. As you can see, the entire system depends on when an aircraft is introduced into this system. A more accurate and timely insight into when an aircraft will go off-block will help optimize many other areas downstream.
Technology as a superior means for data generation
Computer outperforms humans in off-block time predictions
Humans are great creatures and can outperform other species or technology in many aspects. However, there are certain tasks in which computers have proven to very easily outperform humans. From the example above you can imagine that continuously updating an accurate TOBT might be one of them. As the proof of the pudding is in the eating, we have conducted several experiments where we have used Machine Learning algorithms to continuously calculate a predicted off-block time (POBT) based on available data. We have compared the computer’s predictions against the ground handler’s target times and have unanimously found the computer to beat the human at this job. These findings might not be as groundbreaking as IBM’s Deep Blue beating Kasparov in chess in 1997 or Google’s AlphaGo beating Lee Sedol in Go in 2016 but they can for sure further contribute to a more efficient and sustainable aviation industry.
Why does computer outperform humans in off-block time predictions?
The reason why the computer outperforms the human at this task is interesting to consider. First of all, the computer program that calculates POBTs is fully dedicated to this task. It does nothing else all day, everyday but calculating POBTs. This means that we always have a predicted time, not only when the human agent has thought about updating the TOBT. Furthermore, no more forgetting to update the TOBT as it is a continuous exercise. Second, the reason why the computer is more accurate is because it does a better job of taking into account multiple data sources. A human can only comprehend so much information while a computer is typically good at taking information from an endless amount of sources. Also, the computer has a better memory. For the creation of the algorithm thousands of turnarounds have been used to train the algorithm to detect patterns and relationships in historical data. The algorithm uses these patterns to predict the off-block time based on the data that is available to it at any point in time.
The devil is in the detail
Granularity issue of A-CDM milestones
As we know by now, the A-CDM framework has aimed and partially succeeded to create a common, more detailed and real time insight into ongoing operations among all stakeholders. The word ‘milestone’ nicely defines itself. It is a marker that is set at every mile. Not at every inch. One can question though if the distance between the milestones is ideal. Reverting back to our turnaround example, there is an in-block and off-block milestone. However, a lot can happen between these 2 milestones. Especially in the turnaround which is the culmination of the baggage process, passenger process and aircraft process, a lot of things have to come together at exactly the right time in order to make the turnaround happen as planned. It is therefore no surprise that many delays actually find their origin in the turnaround process. Furthermore, for many of the other milestones, or the distance between the milestones there is actually real time progress data available. If we consider taxi time or flight times, we can use ground radar or ADS-B data about the real time position of the aircraft. So even though the milestones are not more narrowly defined, at least we have real time data about the aircraft’s progress between these milestones. For the turnaround, this data is lacking and the turnaround is therefore pretty much a black box. One last reason that makes this fact especially problematic is the amount of actors involved in a turnaround. Fuelers, caterers, ground handlers, airport operators, ATC, airlines, cleaning companies, etc. They all have a role to play and more actors require more coordination to reach an optimal outcome which can unfortunately not be achieved with real time insight into the situation that they are trying to optimise.
Let’s take an example to try and prove my point. If none of the parties above coordinate with each other, they will basically come to the aircraft (after Actual-In-Blocks-Time “AIBT”) whenever it is optimal for them. This might mean that the fueler, caterer and baggage unloaders might arrive at the aircraft all at the same time. Typically, space on the aircraft stand is already limited due to the fact that average aircraft size has increased over time. So now all these parties are fighting for the same scarce space to perform their subprocess within the overall turnaround. What makes matters even worse is that some processes prohibit another process to be performed at the same time (i.e. Waste Water and Potable Water cannot be handled simultaneously).
Why do we need more detailed milestones and real-time data?
Our analysis of turnaround data shows that when these actors are all active at the same time, they take longer than when they are not. So the fueling truck might need more time to connect to the aircraft because others are in the way. And also the catering and unloading process might take longer due to the crowdedness on the stand. Now let’s imagine a CDM 2.0 scenario where we would have more detailed milestones for each of the key turnaround processes. Rather than all actors coming to the aircraft whenever is optimal for them individually, we could create a situation where the actors come at the optimal time for the overall turnaround performance. We would break the silos and be able to create an integrated optimization that would yield benefits to the airline (shorter turnarounds and less delays), airport (more capacity) and even the turnaround actors (shorter process times means they can handle more aircraft with the same amount of equipment and staff).
Besides the coordination argument, there is actually a second reason why more granular, real time data about turnarounds would yield even more benefits. The POBT that we discussed before, is only as good as the data that it can use to predict. In our experiments about POBT performance we have found that the predictor already outperforms the TOBT without having any more granular turnaround data available. However, a true performance leap is achieved when we add real time data about turnaround progress to the equation. The more (relevant) and higher quality data sources go into the predictor, the better the predictions get. Therefore, more granular turnaround data also further boosts the benefits that were already described as a result of introducing a POBT instead of the TOBT.
Email us at firstname.lastname@example.org to learn how you can bring your A-CDM efforts to the next level.
Christiaan Hen has spent his entire career in the aviation industry. He worked for over 8 years at Amsterdam Airport Schiphol in different roles like Airport Development, Capacity Management and Operations Management. The last three years at Schiphol Christiaan was Head of Innovation. At the end of 2018 Christiaan joined Assaia to become their Chief Customer Officer. In this role he is primarily responsible for ensuring that Assaia customers derive maximum value from the Apron AI product. Christiaan uses his extensive knowledge of the aviation industry to help make the apron more efficient, safer and more sustainable.
Get in touch