Trajectory Based Operations (TBO) and Service Oriented Architecture (SOA) are two concepts rather new to air traffic management (ATM) and apparently they continue to cause some head scratching when it comes to agreeing what TBO really means or how to define services in the ATM context. In this article I will attempt to explain a few relevant aspects of those concepts and will also try to visualize the concepts using the aircraft turnaround as an example.
Why the aircraft turnaround? Because we see that in spite of the original SESAR Concept of Operations having made clear that the trajectories of flights performed by the same aircraft are in fact always connected via the given airframe, some experts are now laboring to show that this is so and are trying to bring in new constructs to account for this “connection”. The trajectory does go through important metamorphoses during the turnaround and so using that phase of the operation gives us the opportunity to examine TBO and SOA in all their glory.
But first a few basics.
The concept of services.
“Service” is a word that can mean different things depending upon the context in which it is being used. In general, the context is based upon a consumer/supplier relationship. Further, a hierarchy of services can exist with, for example, a high-level service being made up of a number of lower level sub-categories of services. Therefore, it is very important to ensure that the nature, scope and detailed characteristics associated with each service are clear and unambiguous each time it is used, including defining who is supplying what to whom.
Services may be defined from a business perspective or an IT perspective.
Services from the business perspective.
A service from the business perspective is really the consumer’s view of the provider’s capabilities. The services must meet defined characteristics to ensure their efficiency and cost effectiveness. Among others, they must be modular and autonomous, delivered where needed, shareable and reusable and above all, they must drive the underlying IT support and not vice versa.
Services can be defined on several levels of the enterprise but in the air traffic management context, the operational services are the highest level of service. A service can be associated to one or more contracts, a service contract being understood as being an agreement (generally expressed as a Service-Level Agreement) between two or more parties.
Increasing competition, globalization and technology advances are driving airlines, airports and other users of ATM to change their products, business processes and prices more frequently than they did in the past. The structure of services offers the flexibility to adapt more quickly to fast-changing conditions.
SESAR has promoted the vision of creating a performance partnership structure which links the Airspace Users, Airport Operators and ANSPs as the way in which the future ATM System will be defined, created, implemented, delivered and managed. The notion of the supply and consumption of operational services through a set of Service Level Agreements will be the way in which the partners will be bound together from a business perspective but retaining the flexibility afforded by service orientation to be able to efficiently react to changing circumstances and demands.
While the word “business” and air traffic management have not often been used together in the past, it needs to be recognized that the constantly evolving business world of the airspace users must be served by an air traffic management system that is able to evolve with it and remain safe and cost efficient at the same time. This essential business agility can best be achieved by service orientation.
Services from the IT perspective.
From an information technology (IT) perspective, the use of services defines IT services that correspond to real-world business activities or recognizable business functions and that can be accessed according to the service policies that have been established for the business services relationships. In addition to the IT services that are directly supporting the business services, technical services can be defined that can be re-used across the enterprise, providing generic technical functions (data transformation, logging, identification management, etc.). There are many different ways to describe such services depending upon the way in which the interactions between the IT systems are needed to facilitate and enable the business view.
From the specific air traffic management point of view, the highest priority is to define the business services as these will drive the services to be developed in the IT context.
What exactly is TBO?
First and foremost we must look at the basis of the existing operation. Air traffic management has grown historically along an airspace based paradigm. Airspace as such was a given so it stood to reason that early ATM experts set out to define airspace volumes which they thought would best fit the traffic they expected and established air traffic control units to fit the task foreseen in those volumes. When aircraft arrived, they were obliged to fly within the confines of the defined airspace and if their needs differed from that envisaged, the aircraft trajectory was bent to fit the picture. Of course this is a bit of an oversimplification but to this day, ATM is being done on this basis.
The end-to-end trajectory played almost no role in this game. To illustrate the point, juts consider that until recently the Central Flow Management Unit calculated expected sector loads on the basis of a trajectory the vertical dimension of which was famously inaccurate while ground ATC systems generated their own trajectories for their own airspace and these often did not tie up with the trajectory dreamed up by the neighboring unit. All this time however scores of experts everywhere worked furiously on airspace design and organization… Only a blind person could fail to see that this legacy, airspace based paradigm had to go if the volume and efficiency demands of increasing traffic were to be met.
Things were not helped at all by the fact that controllers were handing flights as if they were born just outside their sector boundary and went into the big blue yonder when they exited their sector. In other words, they only ever looked at a small part of the trajectory with little regard to what was or was not happening further downstream. Conflict free handover was almost the only aim.
Because of the way airspace was used in the past, popular ATM wisdom came up with the notion that airspace was a scarce resource and it had to be organized better to save the day. This notion was a dangerous one because for a long time it did divert attention and effort from looking at the real problem. Trajectories…
Airspace is not a scarce resource. In fact it is practically impossible to really saturate any given piece of airspace in normal operations. The problems arise when ground ATC has to deal with aircraft several miles long and wide and the position of which even 10-15 minutes into the future we are rather uncertain of, to put it mildly. Sounds crazy? Well, it is not. This is exactly how the air traffic management paradigm works to-day when we look at the required separation minima and the uncertainties of the predicted trajectories.
There is also a huge mismatch here between what existing ground systems can do and what the flight management system on the aircraft “knows”. The FMS has a pretty good idea of where it is going and where it will be say 15 minutes down the road but until recently nobody on the ground much cared about this. The ground generated trajectory is accurate only to a rather limited extent when it comes to the fourth dimension, time.
The solution? Trajectory based operations!
A few interesting facts about the trajectory.
In all our preoccupation of calculating trajectories it is often forgotten that the conceptual trajectory of a given aircraft is born the day it rolls out from the plant and continues unbroken until the aircraft is scrapped or meets its end in some other way. Between those two important milestones of an aircraft’s life, the trajectory evolves continuously in at least one of four dimensions. These are the three spatial dimensions and the time dimension.
When the aircraft is stationary on the ground, only the time dimension continues to evolve but it most certainly does and as a consequence, resources are still consumed (amortization, costs for parking and guarding and so on).
You might argue that the trajectory of an aircraft not yet delivered to its owner does not affect the owner’s operation but this is not true. Just think of the Boeing 787 and its trajectory. All Nippon Airlines expected to take delivery of their first 787 years ago ad the trajectory of those aircraft should now be evolving from ANA’s stations. But delivery is late and hence the trajectory is still anchored at Boeing’s facilities…
OK, so now we know that in the TBO perspective of the world, the trajectory is in fact tied to a given airframe first and foremost. This may sound strange since we all grew up thinking of the trajectories of given flights… TBO does require that we adjust our thinking just a little.
If the trajectory is something that belongs to an airframe and if this trajectory can be seen as an unbroken whole evolving throughout the life time of the aircraft, any discussion about consecutive bits of the trajectory not being properly connected show only one thing: legacy thinking that does not take into account what TBO is about.
Well, but the aircraft concerned will perform flights and that is what ATM is really interested in, right? Yes that is correct. But looking at things again from the TBO perspective, a “flight” is nothing more than a tag, an identifier attached to a part of the given aircraft’s trajectory (future or actual). In this way we always identify in a single go how the trajectory evolves in space and time and which aircraft’s trajectory that is. Any part of the conceptual trajectory made real by having actual details added become the business trajectory whether SBT (Shared Business Trajectory) or RBT (Reference Business Trajectory) with a precisely known beginning and a precisely known end.
Note: An RBT is a business trajectory which the airspace user agrees to fly and the ANSP and Airports agree to facilitate. An SBT is a published business trajectory that is available for collaborative ATM planning purposes.
Do those trajectory sections always exist end to end? They may or may not but there is always a continuous trajectory even if parts of it are not tagged as a “flight”. If we are talking about a normal turnaround, the incoming leg and the outgoing leg will represent parts of the trajectory that are indeed end to end. If the aircraft spends the night at the airport, there will be a part of the trajectory evolving through time which however is not tagged as a given flight. But even this section of the trajectory must be seen as a Shared Business Trajectory albeit this sharing is strictly local. The aircraft operator, the handling agent, the airport must all know where the given aircraft is parked and what needs to be done to it before it can assume the tag (flight number) for the next section of its trajectory.
If the trajectory is closely tied to the airframe and parts of the trajectory are tagged with a flight number to become SBTs or RBTs or are otherwise identified, you have a continuous, unbroken trajectory through the aircraft’s life time and events at any one point on that trajectory can have profound influence on the rest. This is what TBO is all about when looking at a single trajectory. There are other interesting aspects of TBO when we consider multiple trajectories but that is the subject for a different article.
How do we make all this clearer using a visual representation?
One of the beauties of Trajectory Based Operations is that organizing everything around the trajectory makes things so simple and so relatively easy to show. Even something as complicated as the turnaround can be shown in an easy to understand graphical way.
So where do we start? First and foremost we must agree on two of the important characteristics of the trajectory that are relevant for the turnaround and which we can use to plot the trajectory against.
One such characteristic is the distance of all the positions that build the trajectory from the gate or parking position where the trajectory will become “idle”, i.e. where the aircraft comes to a stop and only the time dimension evolves until it is time to push back for the next flight. This distance can be expressed in yards or miles but we should express it in time-to-go instead. Why? Because the trajectory may in fact change while the distance from the gate does not change yet the aircraft will reach the gate at a time different from that originally foreseen. Just think of a different taxi route where the distance in yards is the same but the time needed to negotiate the turns and bends is longer so that the trajectory will reach its idle state at a slightly later time.
The other characteristic is the evolving position along the life-time of the trajectory. This is actual time, clock time if you want.
We can now draw a coordinate system in which the vertical axis is the distance to go expressed as time needed while the horizontal axis is clock time.
Now look at the following figure.
t’ is the axis showing distance from the assigned gate expressed in time. t is the horizontal axis, showing actual clock time. The blue line descending on the left hand side is the trajectory and it is more or less steep depending on the aircraft’s speed to represent how the distance is decreasing as time passes. When the trajectory reaches the runway, its speed reduces substantially and the flattened sections represent ground movement towards the gate shown here by G. There are two Gs (representing the same gate) since the aircraft remains at the same physical position during turnaround while the time dimension continues to evolve, represented by the thick pink line.
The turnaround must be completed within the time available between the two Gs where after the aircraft pushes back and taxis to the runway then takes off. Here again, the blue line shows how the distance is now increasing from the gate, its steepness once more depending on the speed.
With the trajectory being central to the picture, the promised very clean depiction is now possible.
Now the services. The turnaround is composed of a number of processes and these in turn need certain services to execute. These are not IT services but business services. One of them could be, for instance, the Passenger Flow Information Service which keeps track of how the flow of passengers towards the gates is progressing and generates appropriate information to be shared when all is well or when there is a problem foreseen.
It is clear from the diagram that some processes are fairly independent from the others while some must complete before the other can start (and there is a buffer time between them as is the case with Process 1 and 3). An example of this latter would be cabin cleaning and boarding.
The services generate information on various aspects of the turnaround and this information is accessed by so called end-user applications which in turn interpret that information and display it in the most appropriate manner for the human operator to react or to enable him or her to maintain situational awareness.
We often see in various documents on collaborative decision making (CDM) systems that they generate “warnings”… Well, the core functionality of a CDM system does not know what a warning is. It will only assess the inputs it receives and publishes the results. The end-user applications contain the intelligence that determines whether the information received should result in a warning or alarm for the human operator. The same set of information at a given point in time may be cause for a warning at one end-user (e.g. the airline AOC) while it would not register in any form at another (e.g. the handling agent).
One way to think of this is that the core functionality will publish information categorized into four Levels from 0 to 3. Level 0 information is just a confirmation that everything is nominal. Level 1 indicates that a process is running late but the turnaround is not affected as the buffer time is sufficient to neutralize the delay. Level 2 information indicates that a process is late and immediate action is required if the target times are to be met. Level 3 information indicates that a process is running late and the turnaround scheduling can no longer be maintained, immediate re-planning is required.
What does this figure tell us?
I guess it is not difficult to recognize the turnaround in the middle (marked by the pink line) and the approach and take-off parts as well as the ground movement parts of the trajectory. The processes that must be completed for the turnaround itself to be complete are clearly visible and you will note that some of the processes will start before the aircraft arrives at the gate (e.g. passenger check in). On this diagram I have put only processes that will complete by the time the aircraft pushes back but there might be processes that extend beyond push-back. The processes require certain services and these are indicated by the blue box below the processes. You can define the required services by analyzing the processes that the turnaround needs. For instance, the check-in and boarding of passengers are processes and you would want to have a service which we may call the “Passenger Flow Monitoring Service” which does exactly what its name says: it keeps track of the flow of passengers towards the gate and generates information on eventual delays or potential narrow cross sections to be shared by the end users for the proper remedial action.
End-user applications, customized for the needs of each of the end-users, serve as a “window” on the evolution of the trajectory and the processes and services it needs to properly evolve in line with the pre-defined business needs of the aircraft operator.
It is easy to see that if we change the speed of the incoming aircraft or delay it substantially, the incoming part of the ground trajectory will no longer line up with the gate (G) and will also be out of whack with the processes shown. Time to re-plan and move the processes accordingly.
As befits the trajectory based operations environment, it is the trajectory that is central to this presentation of the turnaround and we can show easily how things unravel if either the trajectory is moved or the processes lag compared to the evolution of the trajectory. The glue that ties everything together is the t axis along which everything happens.
In fact the same presentation can actually be used in a real operational environment where each aircraft of concern to a given end-user might have a similar picture, available on demand, providing a status view at a glance.
The basic display may very well be the customary tabular presentation showing all the significant times and milestones with the overall status shown by the color of the given line. By clicking on the line, the user can pull up the details presented in a way similar to the one above. The original figure was showing a normal turnaround… now imagine the same picture with the incoming trajectory moved just a few minutes to the right…
Rings, bells and whistles!