If I could give a word of advice to anyone embarking on a long ATM project (well, any ATM project, they’re all long) it would be ‘keep a good diary’. When Roger-Wilco’s indefatigable editor Steve asked me for a few words on the origins and meaning of UDPP, I struggled to find how and when the idea came about. I knew I had thought of it, and that it was first aired at a SESAR meeting in Bagneux in the Paris Banlieue. But beyond that I was guessing.
I was convinced it must have been ages ago, but even though I don’t have a diary note of a light bulb flashing, I see that it must in fact have been just about 5 years ago, about November 2006. I think the Work Group had been challenged by the Project Directorate to come up with some thoughts on the Network Operating Plan, not a subject I claim to know much about. But it did start me thinking about the way delays are distributed now (or more exactly, were then, but I doubt much has changed).
In the CFMU process flow rates, be they through a sector or in or out of a TMA, are determined by the service provider or passed to it, and slots are allocated on the basis of first applied = first allocated. In stable conditions this can keep the bottleneck well supplied with traffic, but it suffers from at least two flaws: the allocation of the delays is remote from the source, and the whole process is rather inflexible.
To take an example, say that a major airport such as Heathrow is subject to reduced flow rate due to, say, Low visibility Procedures (typically a 50% flow rate reduction). CFMU are told they can allocate say 20 flights/hour to ‘in area’ traffic (flights originating outside the CFMU area are not controlled). So the first 20 flights in the hour that ask to go to Heathrow get their slot to do so, but the remainder ‘bow wave’ through into the next hour (actually the bin size and time is smaller and shorter, but the principle is the same). Flights asking for slots in the next interval will have to wait until the first lot are satisfied and so on. If the situation suddenly improves later, then the slot requests still have to cycle through Brussels and the system takes a long time to recover. The whole process may be fair, but lacks any predictability. No one knows in advance which flights will get though unscathed and which will be delayed to the extent there is no point in flying them. Note also that the most time critical flights, the short ones, are the most affected.
Why not, I thought, put the people closest to the action, the airport and the operator, in direct touch? That way the lines of communication are shorter, the system will react more quickly to both increases and decreases in capacity, and above all the operators will get early warning of, and a choice in, what is happening.
So the principle as it was first explained in the User Driven Delay Allocation Function was for whoever was responsible for the capacity loss to allocated slots to the users proportional to their normal demand (so an operator with 6 slots/ hour would get 3 and so on). It would then be up to the operator to decide exactly how to use the slots that were available to him, and hopefully regain some sort of control about what happened next. They could decide how to prioritise their allocation according to passenger load and connections, aircraft rotation, the colour of the stewardess’s eyes or whatever.
Of course the process needn’t stop there, once the principle was established it would be simple to extend it to trading of slots and dynamic allocation as capacity fluctuated, extending even to those aircraft already in flight.
As I recall it now, the main reaction from Eurocontrol was … that they didn’t like the name, and we were politely requested to get rid of any reference to ‘delay’ in the title… the project duly became User Driven Prioritisation Process, UDPP, which it has remained. What I don’t know is to what extent the original simple, not to mention simplistic, idea has remained intact. It stayed pure until the end of the SESAR definition phase, but after that? Papers circulating in advance of an imminent workshop suggest to me it may have got a teeny bit more complicated. Maybe there will be a part 2 to this article reviewing the latest version.