Ducks, Geese, and Planes

South Korea’s ARAIB (Aviation and Railways Accident Investigation Board) recently released interim findings on the Jeju Air Flight 2216 that crashed on December 29, 2024. The crash of the Boeing 737-800 was attributed to engine damage caused by ducks (Baikal teals) hitting the engines. The preliminary assessment stated that after a severe bird strike critically damaged the right engine, the pilot may have mistakenly shut down the still functioning left engine while following emergency procedures.

On January 15, 2009, about 100 seconds after takeoff, US Airways Flight 1549’s engines were hit by a flock of Canada geese. The repeated thumps of the geese smashing into the engines was followed by the eerie silence of both engines shutting down. Neither Captain Chesley “Sully” Sullenberger nor First Officer Jeffrey Skiles had initiated the shutdown.

If the pilots did not shut down the engines, who did?

FADEC (Full-Authority Digital Engine Control) can, but did it? We will never know as the Flight Data Recorder records that an event happened; it does not record who initiated the event, the cockpit or FADEC. We just have the pilot statements that they did not do it.

Did the pilots on Jeju Air Flight 2216 shut down a functioning engine?

We will never know as, according to ARAIB’s preliminary report, the last 4 minutes and 7 seconds from the duck hit to the crash was conveniently not recorded in the FDR (Flight Data Recorder) and CVR (Cockpit Voice Recorder), in both the aft and forward black boxes. Not recorded or intentionally not revealed?

Regaining flyer trust will require transparency and truths.

On June 12, 2025, Air India 171, a Boeing Dreamliner 787, crashed in Ahmedabad 32 seconds after takeoff. The engines were cleanly shut down, with the noise of the engines replaced by the whirring sound of the Ram Air Turbine (RAT). AAIB India’s preliminary report stated that there was no significant bird activity observed in the vicinity of the flight path.

Baikal teals and Canada geese are not native to Ahmedabad. If it wasn’t the birds, what could cause a dual engine failure in today’s most technologically advanced and sophisticated aircraft?

Before we answer that, we must first understand the 787 Dreamliner’s advanced digital control systems that incorporate fail-safe features including a triple-redundant fly-by-wire system and real-time engine health monitoring.

The Boeing 787 Dreamliner utilizes a comprehensive set of redundant components, all designed with multiple layers of backups, to ensure safety and fail-safe operations. Redundancy is the existence of more than one independent means of accomplishing a function, each physically separated ensuring no single point of failure.

The 787’s digital nerve center is its Common Core System (CCS), which provides the processing, network, and I/O resources for all flight services and applications. The CCS is housed in two Common Computing Resource (CCR) cabinets, with redundant power, processors, and network switches. The 787 has a forward and an aft avionics (Electrical&Equipment) bay with the flight services, applications, and data replicated and housed in the forward avionics bay.

The FADEC is mounted on the engine. Full-Authority Digital Engine Control means just that, it has the full authority over the engine. There is no direct pilot control or manual control mode. The FADEC system is autonomous, self-monitoring, self-operating, and redundant. The rest of the flight control services run within secure virtual machines in the CCS, which itself is redundant.

The data network uses the AFDX (Avionics Full-DupleX) protocol, which is similar to Switched Ethernet but with QoS (Quality of Service) guarantees. AFDX is a specific implementation of the ARINC 664 standard, which provides a deterministic, high-speed, and reliable data network for safety-critical applications in aircraft. Data is routed using ARINC Remote Switches (ARS) and Remote Data Concentrators (RDC), which convert data between analog, fiber optic, and digital formats. The AFDX data network has redundant data links, data link failure recovery, and switching failure recovery features.

The FADEC is an End System on the AFDX data network and connects to the AFDX network through a Remote Data Connector (RDC). The FADEC has a separate control bus on which it issues commands to the engine. It draws power from the engine and also has backup power from the aircraft’s electrical system. The data from all the sensors in the engines and elsewhere go over the data network and aggregated in the flight control servers, and made available to the cockpit monitors and FADEC.

The 787 is a digital aircraft with the FADEC providing programmed flight-limits envelope protection, eliminating undesirable aerodynamic characteristics and enhancing safety. The cockpit is designed using UX best practices of immersion without intrusion. The redundant systems provide pilots fail-safe controls, and cockpit displays are designed to maintain situational awareness without distraction from intrusive alarms and error codes.

The 787 Dreamliner design ensures that the hardware, power, electronic subsystems, and the data network are fault-tolerant. A failure or a glitch in one component results in a backup seamlessly taking over that function, without cockpit involvement or awareness. While the hardware is designed to be fault-tolerant, that is not enough to guarantee continuous and correct system operations. The software must be designed to be fault-resistant.

Fail-safe software programs are coded to identify incorrect inputs, bad data, and work through errors. Software that is designed for lights-out operations will encounter errors – servers go down, storage disks go bad, networks may fail or exceed capacity, there may be network message delays that could cause timeouts and connections to fail, and often incorrect data and precision loss from sensors.

While writing a fail-safe program, try/catch, and throw are the programming constructs for exception handling, a mechanism to manage errors and unexpected events during program execution.

The catch block allows specifying handlers for different exceptions. The logic for handling different types of exceptions will be distinct. An EngineDown exception must be handled differently from a DataNetworkDown exception. The order of listing the catch blocks is also important; they must be listed from a more specific exception to a more general exception. This allows for targeted error handling and prevents the masking of a specific issue with generic error handling.

The 737 MAX crashes were attributed to software that took an uncommanded action on the basis of a reading from a single sensor. Planes have two Angle of Attack (AoA) sensors, but the MCAS (Maneuvering Characteristics Augmentation System) software did not validate the data from the redundant sensor. Redundancy in hardware is not good enough if the software is not coded to recognize the failure or anomaly in a component that it manages.

On January 29, 2025, an Army Black Hawk helicopter collided with an American Airlines jet on its approach to land at Reagan National Airport at Washington D.C. The NTSB investigating the accident attributed the collision to a faulty barometric altimeter in the helicopter. The helicopter was flying 80 – 100 feet above the reading from the altimeter.

As things get automated, and software blindly relies on readings from sensors and instruments, and makes an algorithmic decision to act, the results as we have seen can be catastrophic. The Lion Air 737 MAX and the Ethiopian Air 737 MAX acted on a faulty reading of an AoA sensor. The Black Hawk helicopter was flying at a height much higher than what was being shown by its barometric altimeter.

Clocks drift, sensors lose precision and require periodic recalibration, and sometimes they fail. When automating functions, it is the software that must take redundant readings, detect anomalies, and pass control back to the cockpit for confirmation and allow override, instead of acting unilaterally.

We now come back to the question that we had originally posed – if it wasn’t a birdstrike, what could cause a dual engine failure in today’s most technologically advanced and sophisticated aircraft?

The FADEC has code where if it detects engine failure (whether by a bird hit, fire, etc.), it will shut down the engine to prevent fuel from catching fire and spreading. Engine failure is detected using data from vibration, temperature, and other sensors that are mounted on the engine. Each engine has its own FADEC and each acts autonomously.

As AI 171 takes off from Ahmedabad, smoke is clearly visible under the left wing, indicating active venting of the Lithium-ion battery through the exterior vent under the aft avionics bay. In our last two articles, we asserted that a thermal runaway event occurred on AI 171 as soon as it took off from Ahmedabad airport. The thermal runaway takes out all the electronic equipment in the aft avionics bay. This includes the switches and the Remote Data Concentrators (RDC) on the AFDX data bus between the FADECs and the CCS. The cockpit is getting data from the forward avionics bay and doesn’t notice anything wrong and no intrusive alarms.

Even with the AFDX data network disconnected, FADEC can still issue control commands to the engine, over its control bus. It is a programming error, where a data network failure (a NetworkDown exception) is handled as a GenericException, and each FADEC independently shuts down the engine. Once the RAT restores a secondary power channel and the RDC powers up, the FADECs and sensors reconnect with CCS. CCS starts receiving engine health data from the sensors and the FADEC algorithm determines that the engines are good, and issues the command to start the  engine.

The 787’s redundant hardware worked as designed. The thermal runaway event caused a catastrophic electrical failure that led to the RAT (Ram Air Turbine) being deployed. The failure disconnects the FADEC from CCS. The RAT powers back electrical functions and restores the AFDX data network between FADEC and CCS.

With the AFDX data network down, the FADECs stops receiving engine health data, and the software wrongly assumes that the engines have been compromised, and algorithmically decides to shut down the engine. It is the software code in the FADEC that made a recoverable critical event into an unrecoverable catastrophic event by shutting down the engines.

On January 17, 2019, ANA flight NH-985, a Boeing 787, suffered a dual engine shutdown while landing at Osaka Itami Airport. The pilots had deployed thrust reversers after touchdown to slow down the aircraft and shortly thereafter noticed that the engines had shut down. The aircraft rolled down the runway and came to a stop, but the pilots were not able to restart the engines, and the plane had to be towed. The root cause was attributed to the TCMA (Thrust Control Malfunction Accommodation) system in the FADEC being activated as the reverse thrusters were deployed before the aircraft sensors had transitioned to on-ground mode. Pilots were advised to delay deploying thrust reversers on landing.

On January 24, 2025, United flight 613, a Boeing 787, enroute from Lagos, Nigeria to Dulles International Airport, Washington D.C., experienced sudden aircraft movement and altitude fluctuations. The plane was flying over Cote d’Ivoire airspace at 36000 ft and the altitude excursions lasted for 12 minutes, before the pilots elected to do a turn back and returned to Lagos, where the flight landed uneventfully. The preliminary report indicated a failure in two Inertial Reference Units (IRU). An IRU is a critical component in aircraft navigation systems to determine the aircraft’s attitude, velocity, and position, without relying on external references like GPS. IRU failures resulted in uncommanded actions initiated by FADEC.

On July 25, 2025, United flight 108, a Boeing 787, departed Washington Dulles Airport for Munich. Minutes into the ascent, the left engine experienced a failure and shut down and the pilots declared an emergency at near 5000 ft. The plane landed safely after dumping fuel to reduce the weight after being in the air for over 30 minutes.

The determining factor in recovering from an uncommanded action has been plane altitude. Captain Sully’s plane was at 2000 ft when both engines shut down. Jeju Air flight was preparing to land and was at 498 ft when both engines shut down. The Air India pilots had only 400 ft to even attempt a landing and not near any open ground or highway.

Sensor failures, sensor precision loss, and algorithmic overreach, can all have unexpected consequences, if not accounted for and managed in the software. During critical flight phases, uncommanded actions can escalate a critical incident into a catastrophic accident. For instance, an autonomous FADEC might not comprehend that a potentially damaged but running engine is preferable to no engines.

FADEC systems are installed on a wide variety of aircrafts including the A320, A380, 737NG, 777, and 787. The Ethiopian Civil Aviation Authority (ECAA) final report on the 737 MAX  found the cause of the crash to be an uncommanded action in the MCAS module resulting from an incorrect sensor reading. The fix was to compare readings from two AoA sensors and not activate MCAS if the readings varied significantly, and provide a hard override that allowed pilots to take over control of the plane.

Uncommanded actions below a certain altitude can be catastrophic. An incorrect reading from a vibration sensor on the engine could potentially lead to an engine being shut down. There has to be a balance between automation and pilot oversight. These events highlight the need for robust pilot training in handling FADEC anomalies and maintaining situational awareness.

Each FADEC is autonomous and executes independently. Given the same input, their algorithmic response is also going to be identical. If the response of one is to shut down the engine, the other will also respond with an engine shutdown, which could potentially be catastrophic.

As flyers, we are all invested in a reliable and safe flying experience. Under the International Civil Aviation Organization (ICAO) rules, the sole objective of the investigation of an Accident/Incident is the prevention of accidents and incidents and not to apportion blame or liability. Aviation safety needs an informed dialog with stakeholders that include engineers and software professionals. The intent of this article is to initiate that dialog.

The Boeing 787 is an extremely complex and digital aircraft. Technological advancement and complexity are not synonymous with safety.. As we have seen, hardware redundancy by itself does not ensure fail-safe operations. The software must be programmed to detect anomalies, validate instrument/sensor errors, understand and manage delayed state transitions and edge cases, and strike a balance between algorithmic decision-making and pilot oversight. Careful scrutiny of these critical and complex systems will help prevent similar accidents, enhance flyer trust, ultimately fostering industry-wide confidence and ensuring safer skies.

For more details on our analysis of the AI 171 crash in Ahmedabad, read our earlier articles,

Part 1 – Hiding in Plane Sight

Part 2 – Eyes Wide Shut – Deliberate Misdirection or Gross Incompetence

Airplane Rescue and Fire Fighting Information. The Boeing Company. Available at https://www.boeing.com/content/dam/boeing/boeingdotcom/commercial/airports/arff/arff_complete.pdf

A Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Airworthiness Directive. Ruben Santamarta. Available at https://www.ioactive.com/reverse-engineers-perspective-on-the-boeing-787-51-days-airworthiness-directive/

Header Image Credits: Unsplash/James Wainscott, Adobe Firefly, Air India