My dad worked London Heathrow approach in my simulator for about a week. He was upset and he thought I had broken it. He asked a couple of times if I had changed the approach speed of the planes. I knew we were testing the new airport so I dismissed the comment.

A day later, I spoke with my mom. She told me my dad had been complaining about the simulator. So I decided to investigate further.

My first instinct was that it was a bug in a new feature built for Heathrow’s Director position, but everything behaved according to the spec. The Director is the controller who takes aircraft out of the holding patterns and lines them up on final approach. The ILS, the radio beams that guide an airplane down to the runway, was configured according to the charts. And airplane speeds had not changed. So I concluded it was a skill issue.

That should have bothered me more than it did. He worked Mexico City approach for 41 years, he has been flying this simulator for six months, and every fault he has ever reported turned out to be in my code. This was the first time I decided the fault was in him.

It was not a skill issue either. He was flying a technique that works at Mexico City and does not work at Heathrow, and nothing in the simulator was going to tell him which one he was doing.

When I was researching the Heathrow map, I learned that this airport delivers an airplane every ninety seconds from four holding stacks. A stack is a holding pattern where arrivals wait their turn, each at its own altitude. So I pulled four days of its arrivals from public ADS-B, the position reports that aircraft broadcast, and went looking for the playbook. The four days held about twenty four hundred landings on runway 27.

Four days is a short sample. Everything below is westerly operations, aircraft landing toward the west, in a saturated period, and it is a strong signal about how Heathrow was run that week rather than a claim about how it is always run.

Step 1: the geometry (useful, not the answer)

The first step was to understand how far each stack is from the merge on final, the point on the final approach where the streams from the stacks join into the same line, and how long airplanes take to get there.

Stack	Straight line to the merge	Track actually flown	Total turn	Hold exit to 4 NM final
BIG (Biggin)	11 NM	22 NM	358 deg	about 4.5 min
OCK (Ockham)	14 NM	26 NM	216 deg	about 8 min
LAM (Lambourne)	16 NM	24 NM	312 deg	about 6.5 min
BNN (Bovingdon)	21 NM	28 NM	165 deg	about 9 min

The distance and turn columns run from the hold fix to the merge on final ten miles out, and they include whatever was left of the orbit when the aircraft reached the fix. The time column starts when the aircraft leaves the hold and stops four miles out on final.

The straight lines are eleven to twenty one miles, a two to one spread, and the times follow them: BIG is about four and a half minutes out and BNN about nine. BIG sits closest to the merge and its track from the fix turns three hundred and fifty eight degrees, almost a full circle. BNN sits twice as far out and turns the least, a hundred and sixty five.

This is worth knowing and it is not the answer. It tells you who lands first. It says nothing about how far apart they land, and that gap was what he was fighting.

Step 2: the release clock (wrong)

The Director releases an aircraft by taking it out of the hold and sending it toward the final approach. The second step was an experiment. Would a predetermined release order deliver the gap?

No, and this is the most useful thing in the four days. The release interval is the time between one release and the next, and the delivered spacing is the gap between those same two aircraft when they land. The spread in release intervals is about five and a half times the spread in delivered spacing. The releases are all over the place and the landings are not. Fit one against the other and the line is nearly flat: knowing when two aircraft left their stacks tells you almost nothing about how far apart they touch down. One consecutive pair in four lands in a different order than it was released.

The gap is not carried down from the stack. It is built after the release.

Step 3: speed (the answer)

Every arrival converges onto the same speed ramp from the glideslope intercept inward, whichever stack it came from. By speed ramp I mean the series of speeds the aircraft is stepped down through on the way to the runway. The glideslope intercept is the point where the aircraft joins the ILS descent beam and starts down the final approach. The arrivals also fall into wake categories, the weight classes that set how closely the next aircraft may follow, because of the turbulence the aircraft ahead leaves behind. The ramp is the same for all four stacks and all three wake categories.

That is the technique. The stream is normalized, meaning every aircraft in it is brought to the same speed, and it is normalized low, so the last step down in speed, as the aircraft joins the localizer, is small. The localizer is the other ILS beam, which lines the aircraft up with the runway. He was normalizing high, which is correct at Mexico City, and then paying for it with a large step down at the worst possible moment and padding the gap to absorb it. From the controller’s seat it feels like caution. The data says it is the whole problem.

Rolling out the playbook

I put the three findings in a report and gave it to him: the geometry, the speed ramps broken down by wake category, and the ninety second gap as the target.

He flew a session and called me afterwards. “¡Ya lo entendí!” I understand it now.

The Director panel had been in the simulator for two weeks before any of this, showing him which aircraft were eligible for release from each stack. It was answering the question I thought mattered. Release sets the order, and the order is worth something, but the order was never what he was struggling with.

The picture above is a screenshot he sent me from one of his sessions. In the last third of the first session after the report, his median gap was a hundred and one seconds.

#simulation#egll#atc#measurement