On the 6th of August 2021, an Airbus A319-131, registration G-DBCF, departed from Edinburgh for a scheduled passenger flight to London Heathrow. There were 101 passengers and five crew on board. The captain had over 16,000 flying hours, with 4,476 on type, and was the Pilot Flying.

As the aircraft picked up speed for departure on runway 06 at Edinburgh, there was a loud bang. The captain said that it felt like they had passed over a centreline light on the take-off roll. As they climbed away through 1,500 feet, the first officer saw an alert appear on his display unit: GPS PRIMARY LOST.

The message disappeared before the crew could take any action. Everything appeared to be working as expected.

But then, as they climbed through 1,500 feet, the first officer, in his role as Pilot Monitoring, saw a message on his Multipurpose Control and Display Unit (MCDU): GPS PRIMARY LOST

Again, he barely had time to read the message before it was gone. The Airbus A319 continued to climb normally. The crew could not see any obvious action that they should take.

As they reached Flight Level 340 (34,000 feet), another message flashed on the first officer’s MCDU: CHECK IRS 3/FM POSITION. The autopilot and auto thrust disconnected and both pilots lost their flight director displays. The Flight Mode Annunciator showed only CAT 3 DUAL INOP. Meanwhile, the Electronic Centralized Aircraft Monitoring (ECAM) displayed a collection of errors: AUTO FLT AP OFF, AUTO FLT A THR OFF and ENG THRUST LOCK.

The captain took control and levelled out the aircraft. The aircraft seemed to be flying fine, but they were flying under Reduced Vertical Separation Minima (RVSM), which requires the autopilot to be controlling the altitude. Now, they were no longer in compliance. The first officer immediately made a PAN-PAN call to ATC. This is effectively a step down from a MAYDAY call: a PAN-PAN call signals that there is an urgent situation which is not life-threatening.

It wasn’t clear what was going wrong. The ECAM errors were symptoms, not causes, and the ECAM did not offer any further messages. When they tried to re-engage the autopilot and the auto thrust, both simply disconnected again. There were no warning lights or other errors on the flight deck. The first officer even checked to see if a circuit breaker had tripped, but that wasn’t the case.

Finally, after about five minutes of trying, the autopilot and autothrust remained engaged, as if nothing had happened.

The crew attempted to diagnose the situation, discussing what they should do. On the MCDU, the display unit the crew used to interface with the Flight Management Computer, they saw that the Inertial Reference System positions weren’t right.

The Air Data Inertial Reference System is a combination of functions which provides flight data to the Flight Management computers, the flight controls, the engine controls, the flight deck display panels and any other system requiring inertial reference information and air data. The system uses information from three Air Data and Inertial Reference Units (ADIRU). In a nutshell, the inertial reference information consists of position and attitude, while the air data includes the airspeed, angle of attack and altitude.

The position information on the display didn’t make sense, with the displayed positions varying by over 30 nautical miles. Normally, the readings would be within a nautical mile of each other.

Knowing they couldn’t trust their position information, the flight crew asked air traffic control for radar vectors and continued to Heathrow. They discussed attempting to realign the Inertial Reference System in flight but decided against it. The aircraft monitor (ECAM) had not highlighted any known errors or instructed them to do so. As the aircraft was flying safely, it seemed better to leave it rather than risking further problems with an unknown fix.

That was the right choice. Airbus later said there is no procedure that ever advises the flight crew to realign the IRS in flight while in NAV mode. The result would have been that the autopilot and the autothrust would have been disabled and the aircraft would fall back into alternate or direct law, changing the flight mode to protect the aircraft from different types of failure. Airbus agreed with the crew’s conclusion that they had the situation under control and it was better to continue.

The crew asked for an extended final approach to allow them additional time to monitor the aircraft. They discussed the expected indications so as to better watch for further anomalous data or instrument failures.

All seemed normal until they descended through 4,000 feet for the instrument approach, flying to intercept the localiser. The autopilot and the autothrust disconnected and the flight director displays were lost. The crew discontinued the localiser approach and rebriefed for a manual approach. The Airbus A319 landed safely a few minutes later.

When the British Air Accidents Investigation Branch (AAIB) looked at the flight data from the Quick Access Recorder, they saw that something had happened as the Airbus was accelerating on the runway at Edinburgh. As the A319 reached 120 knots, the nose landing gear seemed to bounce, without any flight control inputs to explain it. They’d run over something.

After they took off, the Inertial Reference System started to drift until the autoflight rejected the data from one of the Air Data and Inertial Reference Units as they climbed away. There was no error or annunciation to the crew. As they reached cruising height, the autoflight system rejected the data from all three units, which is why the autopilot and autothrust disconnected in the first place. The Air Data and Inertial Reference Units continued to provide attitude and air data information.

Then, when they were on the approach, the autoflight system rejected data from more than one unit, which caused the autopilot and the autothrust to disconnect again.

The mystery of the disconnecting systems now made sense; however, it still didn’t explain why the Inertial Reference System had started to drift in the first place. But British Airways, the operator of the aircraft, had reported the same problem to Airbus before. In fact, they had five similar incidents on their A320 fleet. Based on these reports, and those from other airlines, Airbus concluded that in every instance, the aircraft had a specific type of Air Data and Inertial Reference Unit, a type which Airbus stopped fitting to aircraft in 2015. However, there were 1,459 A320s with these units installed, about 14% of the A320 fleet.

Airbus installed accelerometers on several aircraft to measure the vertical forces acting on the nose landing gear. They suspected that the problem wasn’t the units themselves, however, but the shock absorber. These confirmed that heavy shock to the landing gear on take off and landing was being transferred to the avionics rack, vibrating and jolting the three Air Data and Inertial Reference Units which were in the rack.

In 2010, Airbus revised the servicing tasks for a modified maintenance check of the nose-landing-gear shock absorber every twenty-four months, with additional checks in the case of an “abnormal vibration event”. This reduced the issues of severe IR drift, but it was still not entirely resolved. Airbus began developing new equipment for the nose landing gear shock absorber that they hoped would stop the drift once and for all.

In April 2020, a year before the incident, Airbus released a Technical Follow Up to warn that severe IR drift issues were possible, caused by a combination of issues, especially high vertical loads on the nose landing gear with incorrect servicing of the landing gear shock absorbers. This was focused on ensuring that maintenance teams understood the effects of shock absorber maintenance.

This incident fit right into the pattern and it turned out that yes, the shock absorber had lost effectiveness. For normal take-offs and landings, the shock absorber was correctly able to deal with the vertical forces encountered while taking off and landing.

But when the A319 took off from Edinburgh that day, the weight-on-wheels had toggled off and on again with a sharp vertical jolt. This was more than the normal uneven surface of the runway.

Using the logged data from the aircraft, they were able to estimate how far along the runway the A319 was when the vertical jolt happened. The airport authority then inspected the runway and discovered the issue. The airport authority referred to this as “a slightly uneven patch repair”. Local media referred to it as a pothole.

Presumably using a car, not an aircraft, airport personnel drove over the spot at high speed and the occupants felt a distinct jolt as they drove over the problem spot.

In early 2022, the airport authority reported that the patch had been replaced as a part of scheduled runway maintenance.

So, the mystery was solved. The nose wheel bounced over the pothole which jarred the nose wheel gear. The shock absorber had lost effectiveness and didn’t fully absorb the shock from the airframe and avionics racks. This jolted the Air Data and Inertial Reference Units, which were known to be sensitive to vertical forces, which resulted in severe drift.

Now, the flight crew did not know that there had been previous cases of drift caused by the lack of shock absorption in the nose landing gear; this was a maintenance problem. There was no published information for flight crew that explained that an unexpected jolt could, in certain aircraft, cause severe IR drift. If they were lucky, the problem would present itself clearly and the ECAM messages would point them to the correct checklist.

But in this case, no clear ECAM messages were generated to point to the IR drift. The closest they had was probably an ECAM message which stated: NAV FM/GPS POS DISAGREE. However, although this message appears with a single chime and master caution light, the message will disappear again when the level of disagreement reduces. So that message would correctly only have been displayed for a few seconds. Neither of the flight crew noticed it.

Airbus concluded that although this was not a great situation, in the end, everything worked out as they expected.

The aircraft manufacturer commented that, as demonstrated by this crew, IR drifts can be successful managed by the process it termed ‘fly, navigate, communicate’, and that no specific additional actions are required. The manufacturer considered publishing information to all flight crews about IR drift events, but was concerned that flight crews might then associate any gps primary lost message or AP and A/THR loss with a drift of the IRS. It therefore concluded that such communication would be detrimental.

In other words, releasing information about this specific and rare incident increases the load on flight crew training while not actually having much of an effect. Worse, it could lead crew to misdiagnose more common issues that showed the same symptoms. The crew needed to do exactly what they did: keep flying the aircraft. There was no additional action they could have taken that would have made things any better. The only benefit is that the crew may have spent less time trying to troubleshoot the situation.

You can read the full report in AAIB Bulletin 7/2022

British Airways published an article about the incident, and a previous similar incident, in the company safety magazine, so the details are out there for the curious pilot.

The flight crew, at least, will never forget the incident.