A321neo: How a Small Step of Ice Defeated a Massive Automation System
A modern airliner is one of the most complex technical systems ever built. It carries dozens of computers, several independent air data channels, autothrust, a digital flight control system, and multiple layers of redundancy. But the whole system has one fundamental limit: it can only process the physical data it actually receives from the outside world. When that physical input becomes unreliable, the system's complexity guarantees nothing about the correctness of the result. On 2 December 2021, S7 Airlines' Airbus A321-271N VQ-BGU was operating flight 5220 from Magadan to Novosibirsk. After takeoff, several air data systems began producing conflicting readings. The flight control laws then changed, the aircraft began swinging sharply through pitch and roll, and the crew found themselves in a situation where the speed shown on their displays was no longer something they could trust. The cause was not inside the computers. It was far simpler — and physically much closer to the aircraft's outer skin.
Before Takeoff: the Aircraft Was No Longer 'Clean'
It was snowing in Magadan. De-icing had been performed on the wings and the stabiliser before departure, but the upper fuselage — including the nose — had not been fully cleared.
The crew and ground staff assumed that loose snow would simply blow off during the takeoff roll. But aviation has a stricter rule than that: critical surfaces must be free of snow and ice before takeoff begins. This is the clean-aircraft concept.
The problem wasn't the snow itself so much as what it would become: raw material for ice, forming in exactly the place where the air data system was most sensitive to it.
De-icing Fluid: Applying It Isn't the Whole Story
The report examines the properties of the de-icing fluid used in detail. A batch of Type IV fluid, manufactured in 2019, met specification when tested in September 2021. But the fluid drawn from tank No. 3 was a mix of batches 155 and 55, and its dynamic viscosity measured 1,860 mPa·s against a minimum allowable value of 2,000 mPa·s.
On top of that, the recommended anti-icing fluid volume for an A321neo was 230 litres — only 99 litres were actually applied.
This doesn't mean a single 'wrong fluid' caused the incident. The physical chain was more layered: weather conditions, snow on the fuselage, the subsequent melt-and-refreeze cycle, the state of the de-icing treatment, and the failure to detect the ice that formed — all converged at one point.
A Small Step of Ice
Once taxiing began, the snow on the fuselage started to melt. Water ran down the cold nose surface and refroze — forming ice deposits directly ahead of the pitot probes.
This is the crux of the whole case. Ice doesn't have to seal the probe opening to cause trouble. Simply changing the surface geometry just ahead of it is enough to alter the airflow reaching it.
This is what's known as barrier ice: a small ridge ahead of the probe became an aerodynamic obstruction. To the eye, it's a few centimetres of ice. To an air data system, it's a corrupted physical input.
A Pitot Probe Doesn't Measure Speed
It's worth pausing on the physics here.
A pitot probe doesn't measure speed directly — it senses total pressure in the airflow. The system also reads static pressure. The difference between the two gives dynamic pressure, from which airspeed is computed and shown to the crew, and used by other aircraft systems.
The chain runs: air → pressure → sensor → air data system → computed speed → displays and control logic.
If the flow ahead of the probe is disturbed by ice, the sensor can be functioning perfectly and still be reading the wrong physical pressure. The electronics don't 'break.' They faithfully process a corrupted input.
The Problem Wasn't the Tube — It Was the Flow
This sets the case apart from the classic scenario of a fully blocked pitot probe.
In the VQ-BGU case, investigators tied the unreliable readings to a distorted airflow ahead of the probes. During acceleration, speed indications began to diverge, then recovered after a period of time — consistent with the ice formation being shed by the airflow itself.
So the physical fault wasn't necessarily inside the measurement channel. It was upstream of it — in the space through which the air had to travel to reach the sensor.
Three Air Data Systems, One Physical Problem
The A321 carries several independent air data channels. Under normal logic, redundancy should let the system cross-check different sources and catch the failure of any one of them.
But here the situation was different. An external factor acted on several probes at once. The problem didn't look like a simple single-sensor failure — several electronically independent channels could be corrupted simultaneously by one shared physical cause: icing.
This is a textbook common-mode failure: electronic independence between channels doesn't remove a shared external source of error.
The First Minutes: Speed Stops Being a Reliable Reference
After takeoff, the crew noticed the airspeed readings diverging. The captain identified it as unreliable airspeed and selected BUSS — the backup speed scale designed for flight with unreliable airspeed data.
But the problem had already stopped being a single instrument's local issue. Corrupted air data had begun affecting the aircraft's automation.
The Automation Starts to Drift
When the flight control system can no longer fully trust its inputs, it changes the control laws available to it.
On this flight, the starting configuration was already abnormal: pitch was in ALTERNATE LAW, roll in DIRECT LAW. Later, at roughly 7,600 ft, around 225 knots and an angle of attack near 11°, the pitch channel also dropped from ALTERNATE LAW to DIRECT LAW.
This distinction matters. The event can't be described simply as Normal → Alternate → Direct across all axes at once — the laws degraded sequentially, and on separate axes.
The Aircraft Stops Behaving as the Crew Expects
A change in control law isn't just a different message on the screen. It changes the very relationship between a control input and the aircraft's response.
As air data quality degraded and the aircraft moved to less-protected laws, the aircraft's response became less predictable for the crew. Against a backdrop of severe icing and turbulence, large excursions in bank and pitch developed.
At one point the crew even suspected a fault in the left sidestick and handed control to the first officer. That didn't change the aircraft's behaviour.
Turning Back Was No Longer a Simple Procedure
The crew attempted to return toward the departure area. But by now the task wasn't just a change of heading.
The aircraft was simultaneously in severe icing, turbulence, unreliable airspeed, and degraded control laws. The pilots had to fly the trajectory with much of their previous confidence in the primary parameters gone.
This is the point where a simple initial defect starts turning into a systemic situation.
Descent, Acceleration, and a Sharp Climb
From here, the flight parameters changed rapidly. The aircraft descended, then accelerated, then entered a sharp climb.
Throughout, the crew kept working with contradictory speed information and altered handling characteristics. Each subsequent motion shouldn't be read as a separate fault — this was an evolving chain in which a single corrupted physical input was already propagating through several layers of the system.
When the Speed on the Screen No Longer Means the Aircraft's Speed
At roughly 12,900 ft, with an indicated speed near 170 knots and an angle of attack around 13°, a sustained stall warning triggered. The angle of attack then climbed past 30°, and the aircraft entered a rapid descent.
The central paradox of the situation showed itself here: the instruments and computers kept working, but the physical quantity much of the logic relied on was unreliable.
The computer hadn't stopped calculating. It had stopped receiving data it could fully trust.
The Stabiliser Starts Working Against the Control Margin
As the situation developed, the stabiliser's trim position became one of the factors complicating recovery of pitch control.
In DIRECT LAW, the aircraft no longer had its earlier level of automatic protection, and the crew had to compensate for pitch changes directly. A small misjudgement of the aircraft's state could therefore have a far larger consequence than it would in Normal Law.
DIRECT LAW: Still Controllable, but the Protections Are Gone
Dropping into DIRECT LAW doesn't mean the aircraft stops being controllable. It means much of the logic that normally translates pilot inputs and provides automatic protections no longer works the way it did.
In this configuration the crew is effectively handling the aerodynamic object more directly — while still having to work with unreliable air data and an aircraft in high dynamic motion.
Spatial Oscillation
During the worst phase, the aircraft went through sharp oscillations in roll and pitch. Recorded parameters show extreme values around −90° and +47° in bank, with large pitch excursions as well.
It's worth not labelling this a formal 'Dutch roll': the report documents abrupt changes in aircraft attitude, but that specific term isn't necessary to explain what happened.
What matters more from an engineering standpoint: the aircraft entered a regime where the normal relationship between crew inputs, instrument readings, and aircraft response became extremely hard to predict.
Four Minutes With Almost No Normal Pitch Control
The most severe phase lasted several minutes. Pitch control remained badly degraded, and the aircraft went through large attitude excursions.
This no longer resembled an ordinary single-equipment failure. The physical input had been corrupted, the air data system had lost reliability, the control laws had changed, and the crew faced an aircraft with substantially different dynamics.
A Manual Stabiliser Trim Change Restores Control
The turning point came after the crew manually retrimmed the stabiliser — reducing its setting from roughly 9.3° to 7.5°, and then to 6.5° nose-up.
Control recovered after that. About 83 seconds later, the flight control system moved back from DIRECT LAW into ALTERNATE LAW.
This is one of the most telling moments in the whole event: control was recovered not because a computer suddenly 'fixed itself,' but because the crew physically changed the aircraft's configuration.
The Aircraft Survived
Once control was recovered, the crew continued the flight and landed in Irkutsk.
There were 202 passengers and 7 crew on board. No one was injured.
This matters for the engineering analysis: the system didn't just enter a dangerous state — it retained enough capability to recover from it. Redundancy, the aircraft's handling qualities, the crew's actions, and the progressive return to a more protected control law together allowed the flight to be completed.
After Landing, Ice Was Found Where It Shouldn't Have Been
A post-flight inspection found ice deposits on the wing leading edges, as well as on other airframe surfaces.
The inspection photos show the actual zones where ice and frost were found on the right and left wing sections. They matter not as dramatic illustration but as physical confirmation of what happened to the aircraft on the ground and in the first minutes of flight.
The link between the nose condition and the pitot probes' behaviour is especially significant: a disturbed airflow ahead of them could directly affect the air data readings.
This Wasn't a Single Failure
Summed up as 'the airspeed sensors froze,' the incident sounds far too simple.
The actual chain had many links: snow on the fuselage → melting during taxi → water running down the cold surface → refreezing → ice forming ahead of the pitot probes → distorted airflow → unreliable airspeed data → degrading control laws → a sharp loss of controllability.
Weather conditions, the specifics of the de-icing treatment, and insufficient pre-flight inspection of critical surfaces were all contributing factors.
Redundancy Isn't the Same as Independence From the Physical World
This is arguably the case's central engineering lesson.
Three measurement channels can be electronically independent and still share one external source of error. If the same piece of ice disturbs the flow ahead of several probes, the system receives several corrupted inputs that share a common origin.
Genuine fault tolerance requires more than multiple sensors. It requires independence of physical principle, location, environment, and the conditions under which those sensors actually gather information.
Why So Much Automation Turned Out to Be Vulnerable
A modern Airbus isn't designed on the assumption that all physical inputs could become wrong at the same time. Its architecture is built to detect and isolate failures, and to fall back to simpler control laws when individual information sources are lost.
But this wasn't a classical breakdown of the electronics. The external physical world changed the conditions under which measurement happened.
That's exactly what makes this story interesting from an engineering standpoint: the computer wasn't the aircraft's adversary. It was part of a chain that kept working on data that had become unreliable.
The Main Engineering Lesson
The most sophisticated system in the world still can't compute a correct answer from a wrong input.
Here, the point of failure sat almost at the boundary between the atmosphere and the aircraft. A small ice formation changed the airflow ahead of a simple measuring element. Everything downstream was an enormous digital system: sensors, air data computers, displays, control laws, and protections.
That's why the 'clean aircraft' concept isn't a ground-handling formality — it's part of the overall safety architecture. If the surface through which a system gathers physical information is contaminated, the error can propagate through every layer that follows.
In the end, a modern airliner still doesn't fly because of its computer. It flies because of the air. The computer is only trying to correctly understand what that air is doing.