Airbus A320 family emergency software update

Joined
May 6, 2005
Messages
15,066
Location
San Francisco Bay Area
It looks like the European Union Aviation Safety Agency issued a directive that about half the A320 fleet can't fly until it getting a specific software update. The issue was corrupting the flight controls.

Toulouse, France, 28 November 2025 – Analysis of a recent event involving an A320 Family aircraft has revealed that intense solar radiation may corrupt data critical to the functioning of flight controls.​
Airbus has consequently identified a significant number of A320 Family aircraft currently in-service which may be impacted.​

https://www.cbc.ca/news/world/livestory/airbus-recall-passenger-disruption-live-updates-9.6996720

I'm not a software or aircraft specialist, but I do understand computer hardware. The thing that solar radiation might do is cause "bit flip". Just zeros and ones being changed randomly. I think most of the time the circuits have some sort of redundancy built in, but perhaps the fix is something to figure out quickly if the data has been corrupted and to recover from it with as little disruption as possible.
 
Here's EASA's order, which is linked to a PDF.

https://ad.easa.europa.eu/ad/2025-0268-E

The worrisome part is this:

This condition, if not corrected, could lead in the worst-case scenario to an uncommanded elevator
movement that may result in exceeding the aircraft’s structural capability.

Apparently around 6000 single aisle Airbuses are involved, more than half the active fleet, with most needing no more than a two hour software update but around 900 needing new hardware.
The software updates appear to be a non-event with most carriers indicating they can get those done quickly, while the new hardware will be another matter for those aircraft needing it.
 
I'm looking at newer articles which mention that the fix is actually to revert to an earlier version of the software. I suppose an upgrade was made that couldn't account for a hardware error due to radiation. But it also sounds as if some of these use a different computer that can't specifically be fixed, although there's no explanation as to why. I have done some work where what would otherwise be done software was essentially mapped into hardware. It was considerably more efficient, but where it really couldn't be patched since it was hardwired.
 
From the Aviation Herald website:

Accident: Jetblue A320 near Tampa on Oct 30th 2025, inflight upset causes injuries​
By Simon Hradecky, created Friday, Oct 31st 2025 16:40Z, last updated Friday, Nov 28th 2025 19:50Z​

A Jetblue Airbus A320-200, registration N605JB performing flight B6-1230 from Cancun (Mexico) to Newark,NJ (USA), was enroute at FL350 about 70nm westsouthwest of Tampa,FL (USA) when the aircraft experienced an inflight upset causing injuries to a number of people. The aircraft descended rapidly, briefly maintained about 20,000 feet and continued the descent for an approach to Tampa. The crew reported they had had flight control problems that caused at least three injuries, head injuries, on board. The aircraft landed on Tampa's runway 01L about 20 minutes after leaving FL350.

Jetblue reported the affected passengers were taken to hospitals, the others were checked by medical staff the airport. The aircraft is now being checked. A replacement aircraft continued the flight but needed to divert to La Guardia before reaching Newark.

A replacement A320-200 registration N537JT continued the flight but diverted to New York La Guardia first and reached Newark with a delay of about 11 hours.

In a service difficulty report submitted to the FAA the operator stated, that the Elevator Aileron Computer #2 (ELAC2) was identified faulty causing an uncommanded pitch down in cruise flight, the autopilot remained engaged. ELAC2 was replaced. Quote of the brief SDRS description: "FLT#1230, CUN-EWR. (AIRCRAFT DIVERTED TO TPA) "F/CTL ELAC 2 PITCH FAULT AIRCRAFT PITCHED DOWN UNCOMMANDED IN CRUISE FLIGHT. AUTOPILOT STAYED ON; PERFORMED INTEROGGATION OF FCDC SYS #2 IAW TSM 27-00-00-810-801-A. ACCORDING TO DFDR REPORTS, TECH SUPPORT IDENTIFIED ELAC #2 COMPUTER TO BE THE CAUSE. DUE TO DFDR, R/R ELAC SYS #2 IAW AMM 27-93-34. OPS CHK GOOD. TEST PASSED. NO FURTHER FAULTS NOTED AT THIS TIME. SYS OK FOR CONT SVC. ALL HYD FLUID QUANTITIES VERIFIED OKAY."

On Nov 7th 2025 the NTSB reported: "During cruise, the aircraft experienced an uncontrolled descent for approximately 4-5 seconds before the autopilot corrected the trajectory. This likely occurred during an ELAC switch change." The occurrence caused 10 injuries on board, the NTSB opened an investigation.

On Nov 28th 2025 Airbus released their Alert Operators Transmission (AOT) advising operators with Airbus aircraft equipped with ELAC B L 104, that their aircraft might be grounded by EASA anticipated Emergency Airworthiness Directive by Nov 29th 2025. Replacement of ELAC B L 104 with ELAC B L 103+ is needed. Airbus reasoned:

An Airbus A320 aircraft recently experienced an uncommanded and limited pitch down event.

The autopilot remained engaged throughout the event, with a brief and limited loss of altitude, and the rest of the flight was uneventful.

INVESTIGATION, ROOT CAUSE AND CONSEQUENCES

The subsequent investigation identified a vulnerability with the ELAC B hardware fitted with software L104 in case of exposure to solar flares.

This identified vulnerability could lead in the worst case scenario to an uncommanded elevator movement that may result in exceeding the aircraft structural capability.


Later Nov 28th 2025 EASA released their Emergency Airworthiness Directive 2025-0268-E with basically identical texting identifying Group 1 aircraft with ELAC B L 104 and Group 2 aircraft not having ELAC B L 104 installed requiring:

Replacement:

(1) For Group 1 aeroplanes: Before next flight after the effective date of this AD, replace or modify each affected ELAC with a serviceable ELAC in accordance with the instructions of the AOT.

A ferry flight (up to 3 Flight Cycles, non-ETOPS, no passengers) is permitted to position the aeroplane to a location where the replacement or modification can be accomplished.

Part(s) Installation:

(2) For Group 1 aeroplanes: After modification of the aeroplane as required by paragraph (1) of this AD, do not install an affected ELAC on that aeroplane.

(3) For Group 2 aeroplanes: From the effective date of this AD, do not modify any aeroplane into a Group 1 aeroplane.
 
Very interesting, I work in this industry and have heard of this issue. Don't have much 1st hand experience with it since I work in manufacturing test. I'll have to talk to my buddies over in field service. There are countermeasures at the device level and at the software level to prevent or address these events, so I'll be interested to hear the details on how this wasn't detected and drove the elevator nose down. Normally at least 2 systems or channels must agree for that to happen.
 
Very interesting, I work in this industry and have heard of this issue. Don't have much 1st hand experience with it since I work in manufacturing test. I'll have to talk to my buddies over in field service. There are countermeasures at the device level and at the software level to prevent or address these events, so I'll be interested to hear the details on how this wasn't detected and drove the elevator nose down. Normally at least 2 systems or channels must agree for that to happen.
"Single event upsets (SEUs) are rare and unintended changes in the internal memory elements of an FPGA caused by cosmic radiation. The memory state change is a soft error with no permanent damage but the FPGA may operate erroneously until background scrubbing fixes the upset.
Because of the low chance of occurrence, your design may not require SEU mitigation. However, if your system includes multiple FPGAs and requires very high reliability and availability, consider using mitigation techniques to detect and recover from SEU errors."

See here for the detection script:

https://altera-fpga.github.io/rel-24.1/zephyr-embedded/seu/seu/
 
"Single event upsets (SEUs) are rare and unintended changes in the internal memory elements of an FPGA caused by cosmic radiation. The memory state change is a soft error with no permanent damage but the FPGA may operate erroneously until background scrubbing fixes the upset.
Because of the low chance of occurrence, your design may not require SEU mitigation. However, if your system includes multiple FPGAs and requires very high reliability and availability, consider using mitigation techniques to detect and recover from SEU errors."

See here for the detection script:

https://altera-fpga.github.io/rel-24.1/zephyr-embedded/seu/seu/

Almost any kind of digital electronics are subject to it, not just FPGAs. But memories are the most susceptible.

There are a lot of ways to protect against it, including ECC memories, shielding, etc. But often they don’t necessarily care in some applications, especially where radiation effects are rare.

Back in 2003, Belgium was holding a national election. One of their first where the votes would be cast and counted on computers. Thousands of hours of preparation went into making it unhackable. And when the day of the vote came, everything seemed to have gone well. That was, until a cosmic chain of events caused a single bit to flip and called the outcome into question.​
 
True, but FPGA's are very dense in terms of circuitry and contain on-chip memory as well as digital processing; hence, they are susceptible to SEU's.
FPGA's often contain proprietary circuitry that forms a company's signature design or watermark circuitry.
 
FPGAs hold their defined operation in RAM. Generally this RAM is loaded only once after power up. So if something disrupts this RAM and flips a bit the chip will do undefined things until it is reset. A FPGA "bitstream" is encrypted. The manufacturer won't tell you which bit does what.

I thought that fly by wire airplanes use computers in pairs. The primary computer is the only one that ever has physical control. It is shadowed by a secondary computer which processes the same inputs thus should produce the same outputs. The two computer's outputs are constanty compared. If they don't agree the system declares a computer failure and goes to alternate law-- manual control.
 
Last edited:
True, but FPGA's are very dense in terms of circuitry and contain on-chip memory as well as digital processing; hence, they are susceptible to SEU's.
FPGA's often contain proprietary circuitry that forms a company's signature design or watermark circuitry.

It's a lot more complicated than that. A lot of new FPGAs have hard-wired components in them. I remember back in the 90s, FPGAs were typically just creating all manner of random digital logic with combinational and sequential elements. But these days there might even be something like a dedicated communications interface.

The cost of ASICs for aircraft would likely be too high. I do remember at an early job interview (in the aviation electronics industry) I was told that they targeted their designs towards traditional (mask programmable) gate arrays. Not quite the same performance as ASICs, but cheaper. I'm sure these days they're using tons of FPGAs although I'm thinking my particular industry there is no longer viable.
 
We only have a few airplanes affected by this.

And I’m scheduled to deadhead on one tomorrow.

I am not worried about this because they’ve already been fixed.
 
I remember an Airbus Captain ( recently retired ) who used to worry about flying high ( and high latitude ……avoided WB flying ) altitude due to solar radiation causing cancer.

Boy, after this stuff he would also be worrying about the flight controls and solar activity.

I worry about the quality of the crew meals.

Crazy year for nervous flyers with everything in the news and all those YouTube experts ( amazing how bad their initial analysis is ) around today.
 
Last edited:
Back
Top Bottom