What is TMR?
The abbreviation of Trajectory Management Requirements and an item that has been misunderstood in several ways (some quite surprising). Obviously, the CONOPS did not do a very good job of explaining this simplest of elements (mea culpa…). An aircraft flying its 4 dimensional trajectory will do so with an agreed precision and the trajectory to be flown will not deviate from the one agreed by more than prescribed limits. The aircraft system does not need to re-publish its trajectory as long as any deviation that may occur remains within those limits.
TMR is nothing more than an automated instruction to the aircraft containing the applicable limits. In other words all TMR does is set the triggers for re-publishing the trajectory. An aircraft may be given different limits as it flies, depending on the changing requirements along its trajectory, resulting in several TMR messages.
Restricting the number of instances of trajectory publishing to that actually required saves bandwidth and processing resources.
What is the NOP and the NOPLA?
The Network Operations Plan (NOP) is in fact the totality of the aeronautical information (in its expanded sense) available in the air traffic management network and put into context for planning and traffic management purposes.
You could picture the NOP as a sliding window that gives end-users an opportunity to look at the state of the ATM network as it is, as it was or as it will be in the future. Interacting with the NOP is possible through end-user applications and an example is the Network Operations Planner (NOPLA). At the time of writing the CONOPS, unfortunately no differentiation was made between the network operations plan as such and the application(s) used to interact with it. NOPLA is a construct invented afterwards to help clarify things. These end-user applications (also mentioned in the SWIM concept) will be built by third party developers but to technical and functional standards established by Network Management. As such, they will enable end-users to seamlessly interact with the NOP with full protection afforded by access rights. There can be several kinds of NOPLA, each developed and optimized for a specific purpose or combination of purposes and for various end-users. A NOPLA for everyone as it were…
Is the AOP part of the NOP?
Airports are traditionally competitive and independent minded and while they all agreed that the future ATM system must integrate all elements of the ATM network, airports included, when it came to the details, the going became difficult. All worry should go away once people realize that this integration is on the information level only.
Obviously, data generated and used by airports will have to be part of the Network Operations Plan (NOP). At some airports a so called Airport Operations Plan (AOP) is used. This AOP can be seen as just another end-user application, one that is specific for airports.
Conversely, there is no reason why airports that do not have an AOP should not still have a simpler end-user application developed for them so that they too may fully benefit from the NOP and co-operate with it as required.
What is the role of the AOC?
From an ATM perspective, modern airline operations control (AOC) centers are a treasure trove of highly accurate information reflecting the airline requirements, constraints, planning information and so on. With the division of tasks between flight crew and AOC tending more and more in a direction where the flight crew is responsible for safety related decisions and the AOC for commercial and airline operational ones, the importance of the AOC for ATM is growing rapidly.
While accurate trajectory data for aircraft not equipped with ATC digital link can be obtained from the AOC, negotiating trajectory changes, with the exception of tactical ATC interventions, will also happen with the AOC once the required automated tools are implemented.
The AOC is an important part of the ATM network and needs to be fully integrated on the information level.
What is control by constraint?
In the traditional ATM paradigm, aircraft are given instructions and clearances to carry out certain maneuvers in order to maintain separation, establish a queue and so on. The maneuvers requested are not always the most efficient solution for the given aircraft to achieve the objective concerned.
In a control by constraint environment, aircraft are given constraints to meet and it is up to the aircraft operator to decide how they meet the constraint. By selecting the most appropriate method in the given circumstances flight efficiency can be maintained. Extensive information sharing and sophisticated air traffic controller decision making aids are essential in such an environment.
What IS a constraint?
A lot of debate has been going on trying to agree what exactly constitutes a constraint. The CONOPS talks about there being estimates and target times in the trajectory description and how some of the times may become constraints… All a bit confusing I must admit.
My favorite definition of a constraint is a very simple: A constraint is a factor that must be taken into account by the airspace user when constructing or executing the business/mission trajectory for a flight (Mission trajectory is the military version of the term business trajectory. The definition of the business trajectory is in Part 2).
While trying to interpret the text in the CONOPS, one may wonder whether a target time can also be considered a constraint. The answer to that one is really simple: yes. After all, a target time is something that needs to be taken into account in the trajectory (especially if it was set by the AOC) and as such it fully meets the definition.
What is an update and what is a revision?
An update is a mandatory change that can be managed by systems without any need for acceptance by the airspace user or air traffic management. Only the consequences (e.g. new conflict) of such updates may require action by the airspace user or air traffic management. According to this definition, the only data able to trigger an update are new estimates, target times and vertical performance figures when these result in changes in excess of the applicable TMR values.
Revisions are changes that may be subject to negotiation, requested by the airspace user or air traffic management (new trajectory, speed, etc.). Revisions are accepted after agreement between all partners concerned to ensure compliance with the requirements of both the airspace user and air traffic management.
In the trajectory based operations environment of SESAR and based on the principles set out in the trajectory ownership concept, all trajectory changes (whether update or revision) will ultimately be provided by the airspace user, even if the change has originally been initiated by air traffic management.
Automation support will be required to ensure the timely conclusion of all change initiatives.
How will separation service be provided?
The CONOPS is very clear on the issue of the provision of separation service. In managed airspace, a separation service will be provided and the role of the separator may be delegated to the flight crew. This implies that the pre-determined separator is the air traffic controller but he or she may delegate to the flight crew. In unmanaged airspace the separation task rests solely with the flight crew.
A range of separation modes will be available, taking advantage of information sharing between air and ground as well as the enhanced vertical and longitudinal navigation capabilities of modern aircraft. Three broad categories of separation modes have been defined:
• Conventional modes: basically separation modes used also to-day
• New air traffic control modes. These are Precision Trajectory Clearances and Trajectory Control by Ground Based Speed Adjustment
• New airborne modes. These involve the aircraft and the flight crew is the separator either by delegation or, in unmanaged airspace, as the standard case. They include Cooperative Separation (ASAS-Separation) and Self-Separation (ASAS-Self Separation).
An interesting and often overlooked provision in the CONOPS defines how separation service will be provided in managed airspace. When we think of controlled airspace to-day it is almost natural to take as a given that in many airspace classes there is a ground based separation service. The future, if the CONOPS is properly implemented, will bring substantial differences. These differences represent one of the most important paradigm changes being proposed. So what is coming?
While the Flight Information Service and the Alerting Service will be available everywhere in Managed Airspace, Separation Service might not be provided in designated parts of it. The CONOPS gives the example of airspace above Flight Level 450 but this is only an example (and we have that also to-day more or less…). The CONOPS message is clear: if there is no reason to provide a separation service in a given part of Managed Airspace (regardless of level), where FIS and ALR are sufficient (aircraft can safely do their own thing), dispense with separation service and all the expenses it entails. But there is more.
Even where separation service is otherwise provided, its use is mandatory ONLY where it is specifically prescribed (in terms of airspace volume and time). In all other cases, appropriately equipped aircraft may request, and if possible, get approval to precede using self-separation techniques.
This latter provision opens a window on the future that gives airspace users a real choice. Invest in the aircraft capability (that is reusable globally) and enjoy the benefits of self-separation whenever and wherever possible while saving on user charges (a service not being used will not be charged for, either) or pay for the ground based service as it is done to-day.
This CONOPS provision is important also because it adds to the guidance airframe and avionics manufacturers require to decide what should be offered, and in time what should come as standard, on new build and new-designed aircraft.
This aspect of the CONOPS will need substantial work to validate ALL the new separation modes and to establish their real benefit potential. However it is important to remember that these new separation modes were included for a reason: they all are much more than off the wall proposals or a flight of fancy from a few misguided folks. The new modes have all passed the test of feasibility in simulations with flying colors.
What is the meaning of user preferred routing?
We know this also from legacy systems… there are a number of pre-defined routes and the airspace user can choose from them. Not bad but hardly what one would expect from a trajectory based system. The SESAR CONOPS sends a powerful message on what is required.
Managed airspace is a user preferred routing environment. Where (!) traffic complexity or the need to maximize capacity require, structured routes will be implemented. Their use will be suspended when they are not required.
Yes sir, the SESAR trajectory based environment is basically free of structured routes! There are cases where structured routes will be needed but they will be in use only while absolutely essential. For the rest, users will fly their trajectories unimpeded by precooked routes… Now that is a paradigm change if ever there was one.
Do I hear you say “It will not work”? Well, not on its own for sure. But the CONOPS is not the collection of disjointed ideas but a comprehensive and logically built concept for the future system that needs all its components to make sense and deliver the benefits. Leaving anything out or adding anything arbitrarily might be tempting but that is one temptation we should all resist.
What is the role of the human controller in the CONOPS?
The concept certainly recognizes the continued important role humans will play in the future system. There is no proposal of a fully automated ATC system. But there is an important message that must be kept in mind in all plans for the future. The CONOPS contains a concept for a system that will provide the necessary capacity even in environment where traffic density rises beyond the ability of humans to handle using current control techniques.
Inevitably, automation will take over tasks currently performed by humans and the balance will have to be found with due regard to the need to handle precision trajectories (and a lot of them too), an often unstructured environment and separation modes that centre on the aircraft rather than the ground.
This role change is not unlike what has already taken place in the cockpit. Moving from the direct control loop into what is essentially a supervisory loop, air traffic controllers, like pilots before them, will have to learn new tricks. Their job will not be any less demanding or less beautiful, but it will be different. The challenge of learning and maintaining certain basic skills in the more detached environment of the future will be substantial.