Solar flares and Airbus glitch: software, hardware, both, or what?

You may have seen this news item in late November, but it came quickly and disappeared even more quickly. On October 30, 2025, an Airbus A320 was forced to abort its flight when one of the control computers malfunctioned, apparently due to a powerful geomagnetic storm triggered by an X-class solar flare two days earlier.

These flares are high-energy events and nasty; they are a high-power, high-energy manifestation of our ever-present nemesis, EMI. They burst from the Sun, and their output spans the electromagnetic spectrum—including X-rays, gamma rays, radio waves, and ultraviolet and visible light. They are often followed by huge coronal mass ejections, immense clouds of solar material that are blasted out of the Sun at millions of miles per hour.

Solar flares and other solar events are intensively observed, recorded, and studied by NASA and other solar institutes around the world. Their mechanisms are “sort-of” understood, but the deep physics are still somewhat mysterious or speculative (see sidebar “Solar flares” at the end of this blog).

The news reports said that the flare’s energy induced a software “vulnerability” and data corruption in the Airbus Elevator Aileron Computer (ELAC) controller, version L104. The ELAC unit interpreted this corrupted angle-of-attack data as imminent stall and commanded sharp 2.1° nose-down elevator deflection, so the aircraft descended 190 feet in under 4 seconds (Figure 1 and Figure 2). The crew disconnected the autopilot and recovered control, bringing plane in for an emergency landing (15 passengers requiring medical attention).

Figure 1 The Airbus A320 ELAC system for elevator and aileron control is, as expected, extremely complicated and sophisticated. Source: Facebook

Figure 2 The pilot screen for ELAC is relatively simple but still offers a considerable amount of useful and needed information. Source: Facebook

It’s important to note that there are two computers: one is the active computer (COM, command) and one is the inactive computer (MON, monitoring). Both perform the same calculations based on the same inputs; however, they use different software and hardware.

The immediate solution to this problem was to reinstall (rollback) the previous version (L103) of the ELAC firmware. This was done for thousands of Airbus 320s in control unit and took about 90 minutes per plane. Within a day or so, all potentially affected aircraft rollbacks were completed, and the problem was “old news.” Some A320s had different ELAC units and needed new hardware—another mystery of sorts.

I was especially impressed—actually, “astonished” would be more accurate—by how quickly the fix was approved and implemented; after all, even rolling back to a known version would usually require test and evaluation to make sure the problem had been properly diagnosed and the solution verified. But here it was “just go ahead and do it.”

This entire story seems to have many areas of confusion. Was it a hardware bit flip induced by the flare, and somehow the internal error-detection and correction (EDAC) didn’t catch it? Was the newer software version unable to recognize suddenly out-of-bound data changes? Why would reverting to an older version fix the problem—what had changed in the newer version?

Was it a flare-induced hardware problem, aggravated by the software upgrade? Little of this made sense, based on the fuzzy reported “facts” I had seen. Each of my speculative answers contradicted some other parts of the story. What was I missing?

My next step was to spend a little time on the web, looking for facts as well as opinions on what happened. The facts were sketchy, and websites sounded confident of their information, but hey, it’s the Internet, after all. There were also many comments, especially on Reddit, with some admittedly speculative, and others sounding confident and authoritative, but who knows?

I don’t pretend to know what happened, or the nature of the failure mode, nor the specifics of the apparently simple fix. Very little of it makes sense, except for the initiation of the problem by an intense, documented solar flare. The relationship between the problem—whether a single-event hardware upset, software not clearing erratic data, or something else—and the solution of loading previous software seems a little strange to me. Yet, it was approved almost immediately, and everyone was happy.

I do know that detailed failure analysis is actually a long and frustrating process. It usually starts with speculation or assumptions while the final conclusion is often very different. It’s the classic debug conundrum, where there is contradictory or incomplete evidence leading to uncertain conclusions.

For one standout example, think of the Apollo 13 lunar mission, where the oxygen tank exploded on the way to the moon, when one of the astronauts flipped a switch for a routine turn-on of the stirring fan in the tank, a step used to improve gauging accuracy.

Although there was plenty of immediate speculation as to why the tank exploded, a detailed investigation eventually revealed the root cause: the thermostatic safety switch in the tank was originally a 28-VDC unit. But its power buss had been upgraded to 65 VDC to support quicker tank pressurization. The associated engineering change order (ECO) to upgrade the heater-control thermostatic switches from 28 to 65 VDC got lost in the shuffle.

When the temperature in the tank got high enough (85⁰F), it was supposed to trigger the safety shut-off switch. Here, instead, the 65-V power surge fused the 28-V contacts and the heaters stayed on continuously, allowing the internal temperature to rise to about 1000⁰F. During the eight hours that heaters stayed on, the Teflon insulation on the wires inside the cryogenic tank baked and then cracked open, exposing bare wires. Then, when fan power was switched on, the bare wires set off oxygen.

It will be interesting to see what is revealed by a more-detailed analysis of the solar flare event and resulting implications, including the interplay between hardware and software, as well as the quick-and-easy “solution” used and why it worked without worry.

Have you ever had to deal with solar flares as a possible upset event? If so, at what level of intensity? What steps did you take, and how did you test the design as well as its level of protection?

Sidebar: Solar flares

The number of solar flares increases approximately every 11 years, and the Sun is currently moving toward another solar maximum. While they are only partially understood, as are so many other things about the Sun, their effects are tangible. Those of us down on Earth are largely protected by the atmosphere and the Earth’s magnetic field, but as you go up in altitude, that safety zone decreases dramatically.

The smallest flares are A-class (near background levels), followed by B, C, M and X, as shown in the table below. Similar to the Richter scale for earthquakes or the decibel scale, each letter represents a 10-fold increase in energy output (and within each letter class there is a higher-resolution scale from 1 to 9; X-class flares can go higher than 9).

The energy range of solar flares covers many orders of magnitude and they are classified accordingly. Source: Stanford University/Solar Center

A-class (not shown) are the weakest flares and are barely noticeable above the Sun’s background radiation. C-class and smaller flares are too weak to noticeably affect Earth. M-class flares can cause brief radio blackouts at the poles and minor radiation storms.

The most powerful flare measured with modern methods was in 2003, during the last solar maximum, and it was so powerful that it overloaded the sensors measuring it, as the sensors “maxed out” at X28.

An X-class solar flare appears in the lower right part of the Sun in this extreme ultraviolet image from NASA’s Solar Dynamics Observatory. Source: NASA

Bill Schweber is a degreed senior EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features. Prior to becoming an author and editor, he spent his entire hands-on career on the analog side by working on power supplies, sensors, signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing.

Related Content

• The double-fault is the debugging challenge
• How EVs, EMI/RFI are influencing AM radio’s future
• EMI-resistant ICs provide building-block circuit protection
• Troubleshooting often involves conflicting symptoms and scenarios

The post Solar flares and Airbus glitch: software, hardware, both, or what? appeared first on EDN.