On June 24, 1982, British Airways Flight 9, a Boeing 747, en route from Kuala Lumpur to Perth, flew into a cloud of volcanic ash from the eruption of Mount Galunggung in Indonesia. The volcanic ash deprived the engines of sufficient oxygen and clogged the engines, causing all four engines to flame-out at 37,000 feet. The pilots carried out a glide descent towards Jakarta. At 13,500 feet, the engine restart procedure worked and all four engines restarted; and the pilots were able to land the badly damaged plane at Jakarta’s airport with no fatalities.
Three weeks later, on July 14, 1982, Singapore Flight SQ21A, a Boeing 747, en route from Singapore to Melbourne, flew into volcanic ash from another eruption of Mount Galunggung. The abrasive ash choked the jet engines, causing a flame-out in three of its four engines at 30,000 feet. The aircraft plummeted 8,000 feet before another engine could be restarted and an emergency landing was made in Jakarta on two engines.
On December 15, 1989, KLM Flight 867, a Boeing 747, lost all four engines after flying into an invisible cloud of volcanic ash from Alaska’s erupting Mount Redoubt. The ingested ash melted inside the hot engines and solidified on turbine blades, causing a flame-out in all four engines. The aircraft dropped about 14,000 feet before the crew successfully restarted the engines and landed safely at Anchorage International Airport with no fatalities.
These incidents influenced the International Civil Aviation Organization (ICAO) to establish Volcanic Ash Advisory Centers (VAACs) to track volcanic plumes in real time using satellite imagery. Nine VAACs were established to monitor and warn aviation about volcanic ash movements in their assigned airspaces.
These three incidents involved the Boeing 747. The planes suffered significant damages but all landed without any fatalities. The British Airways and Singapore Airlines aircrafts were Boeing 747-200 series aircraft. The 200 series had traditional engine controls that used mechanical or hydromechanical controls via cable linkages. Later models of the 200 series were equipped with a Power Management Control (PMC), which assisted with engine parameters but fell short of full digital authority. The KLM Boeing 747 was a 400 series aircraft with Electronic Engine Control (EEC), one of the earliest versions of a full authority digital engine control (FADEC), which managed engine limits, thrusts, and parameters.
With the VAACs monitoring volcanic ash movements, an aircraft entering a volcanic ash cloud is an extremely remote possibility, an edge case, but given climate change and unpredictability in weather patterns, such an incident cannot be ruled out. Modern aviation maintains a strict avoid-at-all-costs rule, where pilots are trained to reduce thrust, exit the ash coordinates and initiate emergency descent protocols. In the remote event of a modern fly-by-wire aircraft encountering volcanic ash and all engines flame-out, and pilots follow the emergency protocols, will they be able to relight the engines?
We examine the evolution of jet engines, review aircraft accident reports, and assert that a modern fly-by-wire aircraft will not be able to relight an engine in the event of an engine flame-out.
PMC to EEC to FADEC
PMC (Power Management Control), EEC (Electronic Engine Control), and FADEC (Full Authority Digital Engine Control) represent the evolutionary steps of jet engine automation, moving from mechanical linkages with electronic trim to fully computerized, fly-by-wire engine management. The transition from Power Management Control (PMC) to Full Authority Digital Engine Control (FADEC) represents a shift from analog-supervisory control systems to fully automated digital engine management systems.
The EEC was a transitional phase to the full authority digital control of FADEC. EEC monitored engine parameters and improved engine performance, while the mechanical system still maintained primary control. If an EEC fault occurred, the engine would revert to hydromechanical control, without the same level of engine optimization and performance.
FADEC was a complete technological shift, where the technology transitioned from being an assistant in optimizing engine performance to taking full control of engine operations. FADEC optimized engine operations, provided built-in protection by limiting operations to within the aircraft’s safety envelope, and enabled predictive maintenance. Dual redundant digital channels ensured fault tolerance; analog control signals were converted to digital messages, with the FADEC executing algorithmic control and override over engine operations. Unlike the limited-authority PMC and EEC, FADEC has millions of lines of software to control 100% of the engine’s functions, with no mechanical fallback option. Similar to software applications, FADEC software updates and patches are released by engine manufacturers whenever a specific enhancement, performance fix, bug correction, or regulatory mandate is required.
On January 8, 1989, a British Midland Airways Boeing 737 crashed, while making an emergency landing at East Midlands Airport, because the pilot shut down the wrong engine. The accident report [1] confirmed that the pilot had shut down his apparently good right engine after a turbine blade broke in the left engine and set it on fire. The flight data recorder proved that cockpit instruments had shown correctly that it was the left engine that was in trouble.
For the FADEC software, this scenario becomes a use-case. A use-case is how a software enhancement request is communicated. If the sensors detected the failure correctly, couldn’t the FADEC software automatically shut down the faulty engine preventing further engine damage and fire from spreading? A goal of FADEC is to minimize pilot error. A software rule gets added to FADEC – on detection of engine damage, initiate engine shutdown sequence and cutoff fuel.
Once this new software rule is added, it is tested by test pilots under various scenarios and if the tests pass, a software patch is created and an advisory is issued to airlines to update to the latest revision. Following this FADEC patch, an in-flight shutdown could be initiated by FADEC, if sensor data indicated damage to the engines, excessive temperatures, or out-of-tolerance operations.
FADEC works by receiving multiple sensor inputs of current flight conditions, including air density, throttle lever position, engine temperature, and engine pressure. These input variables are used to compute optimal engine operating parameters, including fuel flow by controlling the fuel valve position, bleed valve position, and stator vane angles. If the FADEC stops receiving sensor inputs, it cannot compute these engine operating parameters, and it reverts to a safe operating mode, throttles down, and shuts the fuel control valve.
On May 9, 2015, an Airbus A400M Atlas military transport aircraft crashed near Seville Airport, Spain, killing four of its crew of six [2]. The plane had climbed to 1725 feet when three of its four engines shut down. The aircraft was on a pre-delivery test flight, to test a new FADEC patch update, prior to its delivery to the Turkish Air Force.
Investigations into the incident revealed that delivery delays and schedule pressures had contributed to vulnerabilities in the testing protocols. Three engines had been simultaneously upgraded to a new FADEC software before the test flight, departing from standard operating procedures that mandated upgrading engines one at a time. The applied FADEC patch was missing engine torque calibration parameters. The lack of this data prevented the FADEC from functioning correctly, and it reverted the engine to a safe operating mode by initiating an engine shutdown.
The A400 crash is the first instance of an accident directly attributed to FADEC software, where the lack of configuration data led the FADEC to initiate an engine shutdown. We know that the FADEC can initiate an engine shutdown. Once the FADEC shuts down an engine, can it be restarted from the cockpit?
Engine Relight Failures
An engine flame-out occurs following disturbances in the inlet airflow which leads to the extinguishment of the flame in the combustor. The loss of flame can have a variety of causes, including reduced oxygen due to excessive altitude, or foreign object damage from birds, hail, or volcanic ash. The lack of oxygen and engine damage is detected by sensors and if sensor parameters are above a certain threshold, FADEC is programmed to initiate an engine shutdown.
On October 14, 2004, Pinnacle Airlines Flight 3701, a Bombardier CRJ200, crashed while attempting an emergency landing at Jefferson City Memorial Airport in Missouri [3]. Flight 3701 was a repositioning flight with only two pilots on board. The pilots intentionally deviated from standard operating procedures and aggressively maneuvered the aircraft to 41,000 feet. At 41,000 feet, both engines flamed out. The pilots followed the high-altitude dual engine failure checklist to relight the engines.
Four APU-assisted engine restarts were attempted, but the N2 speed of both engines remained at zero throughout the restarts. Following the APU-assisted engine restart attempts, a windmill restart was attempted. The engines did not relight, and the altitude loss during the windmill attempt resulted in the plane crashing short of the airport.
On January 15, 2009, about 100 seconds after takeoff from New York City’s LaGuardia Airport, US Airways Flight 1549, an Airbus A320, engines were hit by a flock of Canada geese [4]. Multiple attempts were made to relight the engines, but all attempts failed despite the APU being switched on. The pilots landed the plane in the Hudson River with zero fatalities.
On January 17, 2019, ANA flight NH-985, a Boeing 787, suffered a dual engine shutdown while landing at Osaka Itami Airport. The pilots deployed thrust reversers after touchdown to slow 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 unable to restart the engines, and the plane had to be towed.
On December 29, 2024, Jeju Air Flight 2216, a Boeing 737-800, was approaching Muan International Airport, South Korea, when a bird strike occurred with both engines ingesting birds [5]. The FDR and CVR stopped recording immediately after the bird strike, and data on pilot action has not been made available. The preliminary report confirmed that the engines did not restart.
Pinnacle Air Flight 3701 was a Bombardier CRJ200, US Airways Flight 1549 was an Airbus A320, ANA Flight NH-985 was a Boeing 787, and the Jeju Air Flight 2216 was a Boeing 737. All were different aircraft, with the only thing in common being the fact that in each case, FADEC had initiated the shutdown. Multiple engine restarts were attempted, but none succeeded.
In our previous article, we had referenced NTSB accident reports and made five assertions. The engine relight failures provide the data to make a sixth. These six assertions can easily be verified and are key to answering questions about China Eastern Flight 5735, Jeju Air Flight 2216, and Air India Flight 171.
The Five Assertions and a Sixth
In our previous article, Aviate, Navigate, Communicate, Educate [6], we researched accident final reports and made five assertions. The five assertions are listed below.
Assertion 1 (Fuel Valve vs Fuel Switch) - The Flight Data Recorder records the position of the fuel valve and not the position of the fuel control switch in the cockpit.
Assertion 2 (Cockpit-initiated vs FADEC-initiated) - The FDR data cannot distinguish between a FADEC-initiated fuel shutoff and a cockpit-initiated fuel shutoff. The only way to disambiguate is to check the CVR for corresponding fuel control switch movement clicks. If clicks are audible in the CVR, the fuel shutoff was initiated from the cockpit; otherwise, it was initiated by the FADEC.
Assertion 3 (Fuel Switch Position) - If the FADEC initiates a shutoff, the fuel valves will close, and the fuel control switch in the cockpit will remain in the ON (RUN on Boeing aircraft) position. An engine-restart attempt from the cockpit will require the switch to be moved to OFF (CUTOFF on Boeing aircraft) and then back to ON (RUN on Boeing aircraft).
Assertion 4 (APU-assisted Restart) - If the FADEC initiates a shutdown, when it detects a damaged engine, the engine cannot be restarted from the cockpit by moving the fuel control switch to OFF (CUTOFF on Boeing aircraft) and then to ON (RUN on Boeing aircraft). The FADEC will ignore the restart command. This is usually the second step in a dual-engine failure checklist in the Quick Reference Handbook (QRH) for relighting an engine. The first step is to ensure that the Air-Driven Generator (RAT) and the Auxiliary Power Unit (APU) have been switched on.
Assertion 5 (Windmill Restart) - The dual-engine failure checklist in the QRH includes steps for a windmill restart. The windmill restart is an option only if the aircraft is flying at a high altitude. If the FADEC had initiated the shutdown on detecting engine damage, a windmill restart will also fail to relight the engine.
For the sixth assertion, a high-level understanding of the FADEC software is required. FADEC software is best understood as a Finite State Machine (FSM). FSM is a theoretical computer science technique for modeling certain classes of event-driven software systems. Modern cars employ lane-keep assist (LKA) technology. LKA uses a front-facing windshield-mounted camera to monitor lane lines on the road. When the vehicle drifts, LKA triggers an action: a slight steering torque or braking corrections to keep the vehicle within the lane. How does the car algorithmically decide between an intentional lane change and an unintentional lane drift?
It does this using a technique called state management - if the turn signal is on, then the lane change is intentional. The turn signal deactivates LKA. LKA can be modeled as an FSM, with two states (turn signal off, turn signal on), with different behaviors. If the car is in the turn signal off state and the wheels cross a lane line, a corrective torque is applied to the steering wheel. If the car is in the turn signal on state, LKA is deactivated. Cars provide the option to a driver to switch off LKA.
Similar to LKA, the FADEC can also be modeled as an FSM, with multiple internal states, with sensor inputs driving state transitions. However, unlike the LKA, FADEC cannot be switched off nor can its actions be overridden by pilot action. State management ensures aircraft safety and integrity by deactivating commands inappropriate for its current state.
On January 28, 2025, an F-35A on a training sortie from Eielson Air Force Base, Alaska, experienced nose landing gear (NLG) issues and did not fully retract after takeoff. The pilot attempted two touch-and-go landings to correct the issue, after which the aircraft became uncontrollable and the pilot had to eject. After the NLG issue was noticed, the pilot spent 50 minutes in the air talking to ground engineers, which included a software engineer, on the course of action to correct the issue. The ground engineers had recommended the touch-and-go landings to correct the NLG issue.
The NLG issue was attributed to water-contaminated hydraulic fluid, which froze in the sub-zero temperature and jammed the landing gear. After the second touch-and-go, the ice buildup tricked the Weight on Wheels (WoW) sensors into thinking that the aircraft was on the ground and transitioned the aircraft to ‘on-ground’ mode.
On Page 23 of the final accident report [7], Section 6d Flight Control Law (CLAW) states,
If an aircraft is airborne but still in the “on-ground” CLAW, it will experience significant degradation in flying qualities and loss of control can be expected. This is because CLAW software is designed to provide the desired aircraft response rather than direct control by the pilot. When the MA (Mishap Aircraft) went airborne following the second touch-and-go attempt, it remained in the OG CLAW and control of the aircraft was not possible.
The Flight Control software is a finite state automaton that transitions between three states; OG CLAW (On Ground), PA CLAW (Power Approach), and UA CLAW (Up & Away). The Power Approach (PA) state of the engine is during takeoff and landing. After takeoff, the engine must transition to the Up & Away (UA) state. The Flight Control Law (CLAW) determines the valid operations for each of the engine states - OG, PA, and UA.
The findings from the F-35A crash final report are the basis for our sixth assertion.
Assertion 6 (Engine state management) - when the aircraft state is set to ‘in-flight’, a fuel cutoff action from the cockpit will be ignored by the FADEC. The FADEC will not initiate an engine shutdown. The FADEC is an FSM (Finite State Machine) that will only respond to pilot actions that are valid for the mode it is in. A fuel shutoff is not a valid action when an aircraft is in the ‘in-flight’ state.
On March 21, 2022, China Eastern Flight 5735, a Boeing 737, from Kunming was cruising at 29,100 feet, when fuel to both engines was shut off. On June 12, 2025, Air India Flight 171 had just taken off from Ahmedabad airport, when fuel to both the engines was shut off. In both cases, media and aviation ‘experts’ on social media were quick to blame the pilots. Assertion 6 states that once an aircraft has transitioned to ‘in-flight’ mode, a cockpit-initiated fuel shutoff will be ignored by the FADEC. The FADEC is a finite state automaton that is designed to preserve the integrity of the aircraft. The root cause of either crash could not have been pilot action.
Engine Relight Success
On June 12, 2025, Air India Flight AI 171, a Boeing 787-8 aircraft, suffered a dual-engine failure and crashed 32 seconds after take-off from Sardar Vallabhai Patel International Airport, Ahmedabad, India.
AAIB India’s preliminary report [8] on the AI 171 accident states,
The EGT was observed to be rising for both engines indicating relight. Engine 1’s core deceleration stopped, reversed and started to progress to recovery. Engine 2 was able to relight but could not arrest core speed deceleration and re-introduced fuel repeatedly to increase core speed acceleration and recovery.
AI 171 is the first reported instance of an ‘in-flight’ engine relight success on modern aircraft. What was different in the case of AI 171?
The preliminary report stated that the aircraft’s air/ground sensors transitioned to air mode, consistent with liftoff at 08:08:39 UTC. By Assertion 6, a successful in-flight (air mode) engine shutdown can only be initiated by FADEC. By Assertion 4, the successful engine relight could not have been initiated from the cockpit. What caused FADEC to shut down the engines and then subsequently relight the engines? The root cause of the AI 171 crash is in the answer to this question.
The successful relight means that FADEC had not detected any engine damage. In the absence of engine damage, there is one other instance where the FADEC shuts down the engine. If the FADEC stops receiving sensor inputs and aircraft data, it cannot compute the engine operating parameters, and it reverts to a safe operating mode, throttles down, and shuts off the fuel control valve.
We have maintained that a thermal runaway event in the Lithium-ion battery in the aft avionics bay created a catastrophic electrical failure, which caused the RAT to deploy [9,10]. The electrical failure powers down the network switches and Remote Data Connectors (RDC), resulting in the FADECs losing their connection to the Common Core System (CCS). This disconnection from the CCS, stops aircraft and sensor data from reaching the FADEC, and each engine's FADEC, after a network timeout, initiates a shutdown. It is only after the RAT restores power, and the network switches and the Remote Data Connectors (RDC) are rebooted that the connection between FADEC and CCS is restored. Once the network connection is restored, and when the FADECs start receiving aircraft and sensor data, each FADEC individually initiates an engine restart.
Decisioning at the Edge
In finite state machines, state transitions where a system shifts from one state to another must manage the instability at the edge. State changes are not atomically communicated to all subsystems and without appropriate safeguards and constraints, system behavior can be unpredictable at the boundaries. Furthermore, systems must be equipped to detect and block inappropriate state changes triggered by invalid inputs.
On August 3, 2016, Emirates Flight 521, a Boeing 777, from Thiruvananthapuram, India to Dubai, crashed while landing at Dubai International Airport. During landing, a sudden shift in wind direction pushed the aircraft past the runway’s touchdown zone, prompting the crew to initiate a go-around. The pilot pushed the TO/GA (take off/go around) switch and raised the landing gear. What the pilots did not realize was that the wheels had already touched the runway, triggering the Weight on Wheels (WoW) sensors to transition the system to an ‘on-ground’ state. In this state, TO/GA switch is deactivated and has no effect on the auto throttle, which ultimately led to the crash.
Emirates Flight 521 highlights the disconnect that might happen at the edge of state transitions. The WoW sensors triggering a state transition may not synchronize with the pilot’s perception of whether the landing gear has touched the ground. Deactivating the TO/GA switch immediately on state transition is poor human-machine interface design. As automation increases, it is these edge cases that will warrant attention. The safety recommendation in the final accident report [11] was additional pilot training and enhanced training standards for a normal go-around initiated close to the runway and after touchdown when the TO/GA switches are inhibited. There were no recommendations for improving the human-machine interface.
On January 17, 2019, ANA flight NH-985, a Boeing 787, suffered a dual engine shutdown while landing at Osaka Itami Airport. The pilots deployed thrust reversers after touchdown to slow the aircraft and shortly thereafter noticed that the engines had shut down. The root cause was attributed to reverse thrusters being deployed before the WoW sensors had transitioned the aircraft state to ground mode. The safety recommendation was to advise pilots to delay the deployment of reverse thrusters till the aircraft was firmly on the ground. Again, there were no recommendations for improving the human-machine interface.
Additional pilot training cannot compensate for poorly designed software and unintuitive human-machine interfaces. The 737 Max crashes were attributed to MCAS (Maneuvering Characteristics Augmentation System), which relied on a single AoA (Angle of Attack) sensor to initiate its ‘nose down’ action. A defective sensor reading could activate MCAS and push the nose down without any pilot action. Relying on a single sensor for critical decision-making is a classic anti-pattern in dependable systems engineering, referred to as a Single Point of Failure (SPOF). It is a basic Fault Tolerant Software 101 programming mistake. Boeing eventually implemented a software patch that relied on readings from two AoA sensors. It did not activate MCAS if the readings varied significantly and provided a pilot override.
Similarly, the WoW sensor readings can be validated using the Radio Altimeter. Instead of asking pilots to delay the deployment of reverse thrusters on landing, the Radio Altimeter can provide a threshold altitude below which reverse thrusters can be deployed. In the case of the F-35A crash in Alaska [7], the Radio Altimeter would have indicated that the aircraft was not on ground. Similar to the MCAS patch, if there was an inconsistency between the WoW sensor reading and the Radio Altimeter reading, and the pilot were given an option to override the state from ‘on-ground’ to ‘in-flight’, a $196 million fighter jet could have been salvaged.
In the case of AI 171, despite aircraft data not being available to the FADEC, it did have the last set of parameter values. The FADEC knew that the aircraft was in PA (Power Approach) mode, knew its last altitude, and knew that the engine was not damaged. Below a certain altitude, when the aircraft is in PA mode, losing aircraft data is critical, but shutting down the engine is catastrophic. The FADEC had enough information, and with predictive analytics, could have delayed shutdown and continued the ascent till it reached a height threshold.
The impact of volcanic ash or bird strikes on an engine is not deterministic. Canada geese (US Airways Flight 1549 [4]), Baikal teals (Jeju Air Flight 2216 [5]), and European starlings (Ryanair Flight 4102 [12]) have been responsible for dual engine failures and have brought aircraft down. Canadian geese and Baikal teals are larger and heavier birds, and in both incidents, the FADEC shut down the engines. In the case of starlings, which are smaller birds, engine performance was greatly diminished but the vibration sensors did not cross the threshold for initiating a shutdown.
Determining root causes in modern aviation accident investigations extends far beyond the traditional reach of pilots, journalists, lawyers, social media commentators, and even software engineers. As full operational authority ultimately is governed through software, investigating these failures will require deep expertise in computer science - specifically in areas like automata theory, data forensics, event causality, clock synchronization, hardware redundancy, failover and graceful degradation, atomicity, human-machine interface design, and fault-tolerant architectures.
While edge cases cannot be exhaustively evaluated in laboratory environments, fostering transparent dialogue regarding algorithmic decision-making and conducting open evaluations of guardrails at state transition boundaries remain crucial steps toward restoring flyer trust.
References
[1] British Midland Flight 92. Available at https://www.faa.gov/lessons_learned/transport_airplane/accidents/G-OBME
[2] 2015 Seville Airbus A400M crash. Available at https://en.wikipedia.org/wiki/2015_Seville_Airbus_A400M_crash
[3] Crash of Pinnacle Airlines Flight 3701 Bombardier CL-600-2B19 N8396A Jefferson City, Missouri, October 14, 2004. Available at https://www.ntsb.gov/investigations/accidentreports/reports/aar0701.pdf
[4] Loss of Thrust in Both Engines After Encountering a Flock of Birds and Subsequent Ditching on the Hudson River, US Airways Flight 1549, Airbus A320-214, N106US, Weehawken, New Jersey, January 15, 2009, Accident Report NTSB/AAR-10/03, available at https://www.ntsb.gov/investigations/AccidentReports/Reports/AAR1003.pdf
[5] Preliminary Report of Jeju Air (HL8088, 7C2216). Available at https://araib.molit.go.kr/USR/BORD0201/m_34591/DTL.jsp?id=eaib0501&idx=262906&mode=view
[6] Aviate, Navigate, Communicate, Educate. Available at https://hawkai.net/aviate-navigate-communicate-educate/
[7] United States Air Force Aircraft Accident Investigation Board Report, F-35A, T/N 19-5535. Available at https://www.pacaf.af.mil/Portals/6/documents/3_AIB%20Report.pdf
[8] Preliminary Report Accident involving Air India’s B787-8 aircraft bearing registration VT-ANB at Ahmedabad on 12 June 2025. Available at https://aaib.gov.in/Reports/2025/Accident/Preliminary%20Report%20VT-ANB.pdf
[9] Hiding in Plane Sight. Available at https://hawkai.net/hiding-in-plane-sight/
[10] Eyes Wide Shut - Deliberate Misdirection or Gross Incompetence. Available at https://hawkai.net/eyes-wide-shut-deliberate-misdirection-or-gross-incompetence/
[11] Accident - Final Report - AAIS Case No: AIFN/0008/2016 Runway Impact during Attempted Go-Around. Available at https://web.archive.org/web/20210121194733/https://www.gcaa.gov.ae/en/ePublication/admin/iradmin/Lists/Incidents%20Investigation%20Reports/Attachments/125/2016-Published%20Final%20Report%20AIFN-0008-2016-UAE521%20on%206-Feb-2020.pdf
[12] ANSV Final Report Accident occurred to the aircraft B737-8AS registration marks EI-DYG, Ciampino Airport, 10th November 2008. Available at https://www.ansv.it/cgi-bin/ita/Report%20EI-DYG.pdf
Credits
Header image generated using the prompt "airplane flying through and coming out of an erupting volcano towards you" from Gemini 3.1 (with Nano Banana 2) by Google, Adobe, 2026, firefly.adobe.com.
All our articles on Data Forensics are available at https://hawkai.net/data-forensics/
Learn more about Hawkai Data at https://hawkai.net, follow us on LinkedIn at https://www.linkedin.com/company/hawkai-data/, or talk to us at info@hawkai.net.
