Just saw this and got curious. Does anyone here know about this software update and what it entails? Is Ada involved?
We sure it wasn’t hacked?
There’s no evidence it is a cybersecurity issue. The announcement states that “intense solar radiation may corrupt data critical to the functioning of flight controls.”
Here’s the EASA EAD, FAA EAD and the AIRBUS AOT.
AVHerald has a good summary of the incident, excerpts:
JetBlue Flight 1230, operating from CancĂşn International Airport (CUN) to Newark Liberty International Airport (EWR), experienced an uncommanded drop in altitude approximately one hour after departure. The aircraft, registered N605JB , rapidly lost about 14,500 feet in five minutes, followed by another 12,200 feet in the next five minutes. The crew diverted to Tampa International Airport (TPA) and landed at approximately 1420 local time.
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.
The subsequent investigation identified a vulnerability with the ELAC B hardware fitted with software L104 in case of exposure to solar flares.
I found this paper AIRBUS FLY-BY-WIRE: A TOTAL APPROACH TO DEPENDABILITY, which contains some detail about the redundant setup of the ELACs. There’s also a Boeing paper referencing that one and comparing it to their implementation.
3 Likes
I guess the 4-5 seconds are the time needed to switch to an other computer (an eternity if the plane is uncontrolled). Then what should be the main way to avoid solar eruption issues ? (I guess the difference between L104 and L103+ version)
@JeremyGrosser Thank you for the info and the papers! Very interesting.
@F-Loyer Yes, that’s what I wonder too. How does a software update relate to the potential impact of solar flares? A change in data redundancy? Error correction? Storage medium (less shielded memory chip)?
Hi, I’ve designed for SEU before. To be safe, you need to take a layered approach: design your HW so single-bit-flips are detected (and corrected if at all possible). So you correct and report that there was an Event in a couple of nanoseconds (literally - it’s what we HW people do). Then you report the failure up to the SW system. You have redundant HW (DO-254 DAL-B/DAL-C and DO-178 DAL-B/DAL-C for FAA; I forget the EU’s equivalents), and the SW monitors all the redundant HW and if it detects variation or reports of uncorrectable errors, it reboots the failing system and flies “single point of failure” doing the reboot.
In other words - airlines only design for single-point-of-failure. Not more than one. So if one computer gets hit and is in reboot, and then the other reports a failure and has uncorrectable data corruption - you have no source of truth. Or if the governing SW itself gets zapped, how does it know?
Imagine if every time you go to run an opcode, you need to have error-correction logic running, because a cosmic ray might have flipped the bit…
I did this type of work for some years.
3 Likes
Ever tried to hack ARINC429? Without access to the avionics racks it would be a rather fruitless endeavour.
Just in case anyone is looking for redundant hardware, or wonders what’s involved, Texas Instruments offers two families of dual redundant ARM processors, as the TI Hercules series. Both CPUs execute the same code, but 2 clock cycles out of step, with a comparator between the CPUs.
An SEU would affect one of the CPUs; a power glitch or EMI may affect both but on different instructions; in either case the comparator should trigger (and IIRC, raise an interrupt). Logging and recovery are then down to software.
One family is automotive oriented (CANbus etc), the other is oriented towards medical equipment. IMO both would make good targets fro Ada in embedded systems…
Yeah, but you need three CPUs. When one gets thrown off, you need to know which one is wrong. You need to be able to keep going w/o stopping.
Also: you need to make sure that you have ECC on all your memory, data-busses, etc. going in/out of the CPUs, because if there’s a SEU on any shared data, both CPUs will be wrong (but also in sync).
I spent several years designing SEU-tolerant space HW. It’s very easy for people to miss things.
what you really need to do is use a fault-injection tool to inject SEU all over, so that you can verify it gets detected and corrected. It’s just not realistically possible to think of all the cases.
1 Like
In ARM world, this is called lockstep CPUs. Several manufacturers sell this kind of chips (NXP, Renesas, AMD (Xilinx)…) for the automotive market.