The foundation for collaborative ATM and TBO

Author: Henk J. Hof, Manager ICAO and Concepts, Eurocontrol

Subscribe

Henk J. Hof, Manager ICAO and Concepts, Eurocontrol considers Flight and Flow information for a collaborative environment (FF-ICE)

The subject for this article, Flight and Flow Information for a Collaborative Environment, also known as FF-ICE is the foundation for collaborative air traffic management (ATM) and Trajectory Based Operation (TBO), and a key part of the paradigm change that will be needed for ATM.

WHICH WAY TO GO IN THE FUTURE

Before we tackle the main article, perhaps we should consider why FF-ICE is needed; why it is necessary to change the ATM system. To address that question, we also need to ask, whether the ATM system that we have today is scalable to serve for the future? (Figure 1).

If we think in terms of projected demand growth, top left of the figure, that is a very difficult question to answer in light of current uncertainty, overshadowed by COVID. However, we need to look at this more in the long-term, fifteen or twenty years ahead, and, when we look that far ahead, we still expect demand and traffic to grow, notwithstanding the current circumstances. We can also foresee additional demand from new entrants to the eco-system such as drones or, at greater heights in the airspace, new users including hypersonic and supersonic vehicles which are already under development. High altitude platforms are another consideration Will today’s ATM system be capable of being scaled-up to meet these new demands in addition to the growth in current demand types?

Let’s look at how the system functions today and how it has evolved from the past up to today (figure 2)

The procedures followed by those actors involved in handling flights, the Flight Operating Center (FOC), Air Traffic Flow Management (ATFM), Air Traffic Control (ATC) and the Flight Crew, are mainly voice procedures. As a result, these actors work very much independent from each other while exchanging information through voice-based procedures. There is some form of automation but, in general and crucially, that automation is not interconnected and it’s not a total system automation approach. Because of that, there are disparate plans… Flight Plans that exist in various forms in various systems; they are not always consistent and not always the same so cannot be used as the basis for automation. This results in uncertainty, to a greater degree than is needed, low levels of predictability and plans not being followed; in general, not an optimum situation.

TRAJECTORY BASED OPERATIONS (TBO)

The choice then is whether to further improve and extrapolate the past into the future or whether, instead, to opt for a transformation from the past to a different air traffic management option. Clearly, the choice has to be for the best option which, in this case, happens to be Trajectory Based Operations (figure 3), known by the acronym TBO.

What is fundamental in this new option is that everything is based around System-Wide Information Management (SWIM), sharing information between the different actors in a consistent way so that it can be used for automation. With automation, the actors will be able to directly interact with each other in a system-wide manner, so there will be system-wide automation as well. Of course, there are still human beings in the system who can make use of the information, but the information is developed in a consistent manner across the whole ATM environment. For example, flight information is used between these automated environments consistently and it is maintained consistently.

Sharing and automation

Trajectory Based Operations is very much about the sharing of flight information and flight trajectory information; the maintenance of that information and using that maintained flight trajectory information for advanced automation through the various process that we will see below. With such a consistent and automated environment, it will be possible to achieve higher levels of collaboration. Of course, and this should not be underestimated, this will change the role of the humans in the system: we have already witnessed such a change on the flight deck but it will also be necessary for such a change to take place on the ground: air traffic control, air traffic flow management and flight operations. There will need to be a greater reliance on automation. This will all lead to a further optimization of performance. In fact, the plan set out above already exists in the Global Air Navigation Plan, the ICAO plan that is used to drive changes in ATM.

With what the key functions that are part of this paradigm change – TBO, FF-ICE and SWIM – represent, the ultimate objective is to achieve higher performance through Trajectory Based Operations, the concept implemented through ATM processes (see below). TBO makes use of the exchange of Flight and Flow Information for a Collaborative Environment (FF-ICE) and System Wide Information Management (SWIM) services, for the exchange of information. This is how the three terms relate to each other.

Let’s now look at the various processes that are included in and embraced by TBO (figure 4).

As the header says, TBO brings it all together. What the figure shows is, on the top horizontal axis, the years, months, days hours and minutes before the flight, then the flight departure followed by the In-Flight phase. On the vertical axis are the various concept components in the global operational concepts and the airspace management operations involved in demand-capacity balancing, airspace organization and management, airport operation, traffic synchronization, and conflict management. They all follow various processes through time in order to handle flights and flight information. The airspace user, the airline, starts scheduling months and years before the flight which then goes to flight dispatch, flight planning in the mid-term, and tactical planning. Then, during the flight, we see a re-optimization of the flight, for example, due to weather changes or other operational situations.

With demand capacity balancing, aircraft and airspace organization and management, there’s capacity management, flow management which starts when the flight planning phase commences with submitting the flight plan: flow management also starts with the re-optimization of the flight and flow management effects that need to be taken into account.

On the airport side, there is also capacity management in the long- and medium-term planning, the tactical planning and execution; the whole departure management and arrival management. And, on the ATC side, we see the main functions of traffic synchronization and separation provision.

These are the processes and, what is key here and the objective of the figure is to show collaboration, the vertical arrows, which make use of automation, and automation makes use of exchanging flight information. So, all of these processes rely on, make use of and are potential changes to flight information which is done through FF-ICE. FF-ICE is the new flight information, the new flight plan but also the processes that are used to exchange and maintain the flight information as shown through these processes that are part of TBO.

Consistency is the key

Let’s look at a practical example of TBO in practice (figure 5.1).

Assume there is a trajectory that has been agreed in the pre-departure phase, making use of FF-ICE, which includes the flight trajectory shown on the figure in three dimensions and with the times added but also with constraints and tolerances. The tolerances are shown in the time dimension and, when the aircraft gets into the execution phase the ATM service provider monitors the execution of the flight trajectory within the tolerances. Of course, what can happen is that there is a conflict or some other need for change, perhaps due to weather, and, assuming this is not yet in the tactical phase of the flight, ATC is not yet involved, there is still time to look for the best alternative flight trajectory (figure 5.2) to resolve the conflict.

This resolution is done in a collaborative way, so figure 5.2 shows possible trajectory alternatives to be considered and eventually, via collaborative decision making, the trajectory update is selected and agreed between the ATM service provider and the airspace user. Also, of course, this is communicated and agreed with all the ATM service providers along the route of the flight, the trajectory, to ensure that the information is fully shared and remains consistent between actors involved in the handling of the flight (figure 5.3).

Consistency, sharing and maintaining the flight information is very important.

WHY FF-ICE

Taking another look at FF-ICE and why it is needed, we can consider both the short-term and the long-term (figure 6).

We’ve already covered the long-term reason, that FF-ICE enables transitioning to a fully collaborative environment where a flight trajectory is shared and optimized during all phases of flight. But it is also needed to address the limitations and constraints of the current flight plan. The current flight plan is a very rigorous flight plan, but still based on paper formats that stem from the early days of aviation. It has fields with characters and so forth, it’s very difficult to change – we saw with Flight Plan 2012 how costly it is to make a few modifications to the flight plan – this FF-ICE will address all these limitations. The flight plan will be more scalable and it will be much easier to include new flight information that is needed for sharing: for example, new aircraft capabilities, PBN (Performance Based Navigation) codes or other capabilities that can be used to optimize the flight to have a better and more effective handling of the flight. All of these shortcomings are addressed by FF-ICE and, at the same time, FF-ICE supports future environments, TBO environments which is really the paradigm change for ATM.

FF-ICE

Now, looking at FF-ICE, the overview is shown in figure 7.

FF-ICE is provided through services that are used to submit the flight information and to maintain the flight information. In the figure, those services are listed: Planning Service, Filing Services (a replacement of the filing service in use today), Trial Service (a new one), Flight Data Request Service (an upgraded development of an existing service and, with the Filing Service, the minimum capability that needs to be implemented for TBO), then the Publication Service (another new service) and, finally, Notification Service.

In the first phase of FF-ICE (FF-ICE RELEASE 1) we are looking at the pre-departure phase which runs from the submission of the flight plan until when ATC becomes involved. What can be seen in the figure is that these services will all be used in the pre-departure phase but also will remain of use in the post-departure, flight execution phase which is also part of FF-ICE but these services will continue to be of use in all phases of flight with the exception of the planning service of which more later.

The FF-ICE Services

Let’s now look at these services in more detail starting with the Filing Service. It provides a means to submit the flight plan as it is today and includes all the capabilities that we know today such as the change message, cancel message, delay message… they’re all included. The Filing Service offers increased functionality with automated acknowledgements for any identified problems with the submitted plan. So, the FF-ICE flight plan which is referred to as the eFPL is submitted and then it is checked as to where it can be accommodated and the operator will be informed through FF-ICE if there is any issue with it, which will assist the operator in determining what changes are needed. Through FF-ICE it will be possible to include more information than is possible in the current flight plan, not only the flight trajectory but also lots of other information to which more can be added in future without requiring substantial changes to the system.

The next service to consider is the Flight Data Request Service which will replace the RQP (Request Flight Plan) and RQS (Request Supplementary Flight Plan) messages to request a flight plan and to request a supplementary flight plan information. The functionality still exists in the FF-ICE service but the operator can ask for the current status of the flight but also the eASP, which stands for the ATM Service provider which has FF-ICE capabilities can ask the operator to submit the latest version of the flight plan. The Notification Service, shown at the bottom of figure 7, will replace the current Departure and Arrival messages. In FF-ICE, these messages can still be provided but a lot more can be provided as notification information; so, this will be a very useful function indeed.

The ‘Planning’, ‘Trial’ and ‘Flight Data Publication’ services are all new. The Planning Service can only be used in the pre-departure phase and it allows the operator to submit a flight plan: this is not a formal submission, not a filed flight plan, but to see how the system will react to the proposed flight plan. It also provides the operator with feedback on the acceptability of the flight as per the submitted flight plan. This is quite a powerful service: both the ATM and the operator can use that information to develop an optimized flight plan in the pre-departure phase, knowing the constraints that exist. The Trial Service is also new so that, when a flight plan has been filed, the operator can test changes to that filed flight plan through a ‘What if’ evaluation which is done through the Trial Service. For example, would it be acceptable if the flight level or route was changed? The ATM system will then provide feedback on that possible change before it is formally requested. The Flight Data Publication Service is also new. At the moment, service providers take published flight data but it is all done in a proprietary manner. Through the Flight Data Publication Service, there will be global standards for the harmonized sharing of flight data.

These, then, are the services that will be implemented through FF-ICE which is the new flight plan but that comes with this set of services that can be used to submit, share and notify flight plan information and maintain the flight information. The whole set is known as FF-ICE.

HOW TO ROLL-OUT FF-ICE

A further question is how to roll-out FF-ICE. The primary focus at the moment is on pre-departure, FF-ICE/RELEASE 1. FF-ICE/RELEASE 2 will include the sharing and maintenance of flight information in the post-departure-flight execution phase which we have discussed above and which is being worked on at the moment. But the first phase of implementation will be the exchange of flight information prior to departure. Also, very important is that this implementation will be on a voluntary basis: the standards are being developed for mixed mode environments in which operators and air navigation service providers that both are and are not FF-ICE capable, will be catered for until some, yet to be determined, point in time. The intention is to make the implementation voluntary, yes, but also benefit driven. For example, to make use of all these services that will improve automation possibilities and will improve performance, an airline will have to go to FF-ICE.

Eventually there will be a sunset date set for the current flight plan, after this sunset date, the current flight plan formats and procedures will no longer be supported but this will only happen when there is sufficient experience with FF-ICE/RELEASE 1 pre-departure use of FF-ICE and all the necessary tools are in place for full FF-ICE/RELEASE 1. No sunset date has been set at the moment.

To illustrate how to roll it out (figure 8), all the concepts will have been developed and are complete.

On the ICAO side, the FF-ICE concept, the ICAO ATM Requirements and Performance panel are developing the provisions for FF-ICE/RELEASE 1 and are close to finalization of the job. The panel is also already working on FF-ICE/Release 2 for the post-departure phase and this might still need some time.

THE ENVIRONMENT FOR NON-FF-ICE OPERATORS

To zoom in on the mixed-mode environment which is quite important (figure 9.1)…

… What can be seen in figure 9.1 is that there is an airline Operations Center that is not FF-ICE capable and has a flight planning system.

It can send, using today’s Flight Plan 2012, ATS messages to the ATC systems and to the ATM Service Provider; plus, the ATM Service Provider can be FF-ICE capable or not FF-ICE capable. If they are FF-ICE capable, they should still have the functionality and capability to process and receive the current Flight Plan 2012. Figure 9.2 shows a situation where the airline is FF-ICE capable but still has to be able to support mixed-mode environments to send current Flight Plan 2012 messages to the non-capable Air Traffic Service providers: with the FF-ICE capable ATM Service providers, it will be possible to exchange FF-ICE information and make use of the FF-ICE Services. So, in a nutshell, that’s how a mixed-mode environment will look.

IN CONCLUSION: WHY FF-ICE?

 We’re still, in 2021, using standards from the early days of aviation. If we want to implement system wide automation, computer to computer connections, we need FF-ICE for consistent flight information that is maintained and shared. We also need FF-ICE for scalability especially with regard to content or, in the long-term, we need more information to be exchanged as part of the flight information to support changes to automation as well as new automation. Also, we’ll need FF-ICE for the paradigm change of ATM through Trajectory-Based Operations. This will provide greater predictability and higher levels of flexibility.

Contributor details

Henk J. Hof

As Head of the ICAO and Concepts Unit, Mr. Hof is responsible for the contribution of the EUROCONTROL Agency to ICAO and for strategic initiation and facilitation on Concept development. He joined the EUROCONTROL Agency in 1991 and is the EUROCONTROL member and the chairman of the ICAO ATM Requirements and Performance Panel (ATMRPP) and chairman of the ICAO Global Aeronautical Distress and Safety System (GADSS) Advisory Group.

EUROCONTROL

EUROCONTROL is a pan-European, civil-military organization dedicated to supporting European aviation. Their expertise spans research, development, operations and performance monitoring. The organization is committed to the European Union’s vision for a Single European Sky and supports Member States and stakeholders (including air navigation service providers, civil and military airspace users, airports and aircraft/equipment manufacturers) in a joint effort to make aviation in Europe safer, more efficient, more cost-effective and with a minimal environmental impact.