You may recall that a while ago I had written an article with the same title, expressing concern that this all important element in the SESAR Concept of Operations was apparently still not properly understood by some of the “experts” working on the subject.
Recently another paper dealing with trajectory management crossed my desk and on reading it I started to wonder: have these people not read the CONOPS at all? Mind you, the paper comes from a major SESAR partner who should know better… But apparently they do not.
The paper is entitled “Use of the SESAR RBT in ATM Systems”. RBT in case you did not know stands for Reference Business Trajectory and this is the trajectory that “the airspace user agrees to fly and the ANSP agrees to facilitate” to quote the relevant part of the SESAR Concept of Operations (CONOPS).
The purpose of the paper, by its own admission, is to prompt discussion of the trajectory issues within the SESAR program and in particular to ensure that they are addressed by Work Package B. In other words, the paper is arguing that alongside the RBT, the various other types of trajectories that exist in local systems must also be recognized and treated in SESAR. Since the CONOPS already contains references to all those “other” kinds of trajectories, one cannot but wonder: what do the authors of the paper have in mind? Why would SESAR ignore the CONOPS references to those other trajectories? Or have the authors not read the CONOPS and are now thinking that they have discovered a gap in that document?
I will not even attempt to figure out this aspect. There are many other elements in the paper that should make anyone familiar with trajectory based operations want to cry.
First of all, the paper seems to totally ignore the trajectory life-cycle as described in the CONOPS and talks only about the RBT as if there was no trajectory life before it. Pulling the RBT from the magic hat as the first step confuses everything and the rest of the paper shows this confusing clearly.
This sad fact is highlighted very strongly in paragraph 5.3 which says nimbly: the RBT will supplement, and not replace, the range of existing trajectory types… In other words, the legacy system will remain and this new fangled thingy called RBT will come and augment it. DEAD WRONG!
The issue is that trajectory based operations (TBO) will replace airspace oriented operations (as said clearly in the CONOPS) and therefore all the legacy trajectory types need to be put in the new context, they must be evaluated against the RBT and then a decision must be made on how to interpret the CONOPS words talking about the additional types of trajectories (beyond the RBT). One also needs to consider that the RBT will be shared between all the actors (and not just down-linked as said in the paper… When will they finally grasp the difference anyway????) and even a local ”what-if” will be evaluated against the totality of the RBT. As the paper now stands, they are still talking about the legacy system view where a given controller does not see beyond his or her centre walls at maximum with just a lame mention of multi-sector planning.
I think the paper is correct in saying that there needs to be a transition (where the legacy trajectory types are still the same as in the old days) and also that mixed operations need to be catered for. But without properly describing the end-state, talking about a transition is also meaningless.
My biggest concern is that the paper seems to suggest that in a system working as usual they will add the RBT and the pre-existing other trajectory types remain as if nothing has happened.
This is the wrong approach. First agree what TBO means and then look into what can or cannot remain from the old elements. But to say that the RBT will just supplement the old bits and pieces shows that the writers did not correctly understand the essence of TBO. No wonder they fail to talk about the other trajectory types preceding the RBT as described in the CONOPS.
It is often heard these days that the original airspace user orientation in SESAR (the concept of the business trajectory with its lifecycle and the trajectory ownership principle) while still nominally present, has been distorted in several ways and those concepts are now being (ab)used by certain airframers to conceive their aircraft and by ANSPs and ATM manufacturers to build and operate ground systems. The much hoped for paradigm change is there except that the paradigms being changed are apparently not always the ones originally intended by the airspace users.
This paper is a small fish in the big scheme of things. But it shows where things hurt. Unfortunately, many small papers like this add up to a major disease.
