Exclusive | Did Boeing’s machine fail in Air India 171 crash? A chilling sequence of possibilities

Investigations by The Federal have so far revealed parallels between technological faults that caused the crashes of Boeing 737 MAX 8 planes in 2018 and 2019, and those of the Air India flight in June — similarities that cannot be ignored.

Part one of the investigation (read here) focused on a potential design flaw in the Boeing 787 Dreamliner’s Common Core System (CCS), a digital backbone that controls all major systems. Like the earlier Manoeuvring Characteristics Augmentation System (MCAS) failure, the CCS may represent a single point of failure, as evidenced by the simultaneous loss of multiple subsystems in the Air India crash, suggesting that it may have stemmed from systemic digital and electrical failure rather than pilot error.

And why are we suspecting a CCS failure? It’s because pre-flight, AI 171’s core network system (CNS) was already listed as an active fault, as per the preliminary Aircraft Accident Investigation Bureau (AAIB) report.

And the core network doesn’t only have to do with the maintenance of the aircraft — it’s the physical and logical data transport backbone for the Boeing 787’s integrated avionics architecture. And at its heart is the aircraft data hub or Core Network Cabinet, which houses the modules that connect the central avionic computers or Common Computing Resources (CCRs).

Essentially, these core network modules function as the airplane’s data “pipes and switches”, enabling the CCS and CCRs to communicate with one another and with the rest of the aircraft’s systems

Without the core network working properly, CCS can be starved of good data, lose redundancy sync between the main electronics bay or CCR cabinets, or get fed corrupted packets — all of which can cause common-mode CCS failure, confirmed all software engineers and maintenance engineers The Federal spoke to.

While Boeing categorises it as non-flight-critical, in truth, multiple experts The Federal spoke to say that its failure has the potential to disrupt the CCS’s ability to manage flight-critical systems — or, in simpler words, “crash the plane”. And flight engineers who have shared their internal training manuals and training notes with The Federal say this aspect of the core network is something Boeing’s dispatch notes don’t spell out.

So, now, we start Part 2 of the investigation.

Sequential pattern of failures

The failures on the AI 171 don’t seem to be random. They seem to follow a chilling, sequential pattern, each one pointing back to that one ring/core network of a system.

The Federal spoke to multiple sources in India, Europe, and the US, and reviewed the documents and media reports from the past that highlighted this vulnerability.

Also read: Exclusive: Not pilot error? Missing black box data, a clue to systems failure or FADEC collapse

But first, let’s go into the evidence present in the AAIB report:

1. Active faults on AI 171

Air India cleared AI 171 to fly on June 12, 2025 with five active faults and, now, it has emerged that three of those faults had everything to do with “core network” degradation.

Active faults are called Minimum Equipment List (MEL), which is a list of specific equipment or systems that can be broken but still allow a plane to fly safely, as long as certain rules are followed.

And now, let’s quote Boeing on the operations note it provides airlines: “An inoperative Core Network System or supporting component may render the following functions inoperative:

1. ACARS…

2. Airport map function.

3. Flight deck printer…

4. Flight deck door video surveillance.”

Here’s the kicker — AAIB has already listed three of the four things Boeing provides in its operations note as active faults pre-flight. In its report, AAIB says, “there were four (Category) CAT ‘C’ MEL items active on aircraft…these MEL were for flight deck door visual surveillance, airport map function, core network, FD printer.”

So that means core network degradation was already underway, as three functions connected to it had stopped working.

And that means, even going by Boeing’s own operations note, the ACARS (Aircraft Communications Addressing and Reporting System) — which is the digital data link system used in aviation to transmit short messages between aircraft and ground stations — had the potential to fail on AI 171 when it was cleared for take-off.

2. RAT deployment — before the pilots touched anything

The AAIB report states that the Ram Air Turbine (RAT), an emergency generator that deploys only after it loses power from the engine-driven generators, began deploying hydraulic power at 13:38:47 IST, indicating it could have theoretically deployed between 13:38:40 and 13:38:42 IST, if we assume the time taken for it to generate sufficient power is 5-7 seconds.

We don’t know exactly when the fuel switch movements were captured in the forward black box or the Flight Data Recorder (FDR), as the AAIB only says “immediately after” hitting top airspeed at 13:38:42 IST, which means the fuel switch movement (from RUN to CUTOFF) or the fuel valve cutoffs could have happened somewhere between 13:38:42 and 13:38:51 IST.

And we are saying this loosely as neither AAIB nor any investigator can determine the physical movement of the fuel switches. All we can say is that an electronic signal was captured by the forward FDR from the Full Authority Digital Electronic Control (FADEC) (on its own protective logic) to close the engine fuel shutoff valves, which in turn shut down the engines. This suggests that the electrical collapse and RAT deployment happened before, and not after, the fuel switch cut-off.

Also read: Exclusive | AI-171 crash triggered by fuel switches or engine failure?

Now, the RAT deploys when both engine-driven electrical generators fail, or when the feeder paths from the engine-generator fail or lose power — a condition that could have been triggered by a core network or CCS failure disrupting the generator power signals.

D Raghunandan, aviation engineer, says, “It’s concerning that the AAIB report failed to provide a timestamp for RAT deployment, while simultaneously asserting that it generated hydraulic power. Such gaps raise more questions than they answer — and that is not acceptable in the pursuit of aviation safety.”

3. Fuel switch anomaly

The AAIB report states that the two fuel control switches for engines 1 and 2 moved from RUN to CUTOFF within one second of each other. Experts say that speed is virtually impossible to replicate manually, especially under high-stress climb conditions.

The fuel-monitoring units are hard-wired to the FADECs, allowing those to receive or initiate a command to open or close the engine fuel valves. Once FADECs operate the valves, they send engine and valve-status data to the CCS via the core network, which pilots can view on their cockpit panel via engine display EICAS.

4. ACARS and SATCOM: Silent

Despite the pilots issuing a “Mayday” over VHF (Very High Frequency radios), the AAIB report does not mention what happened with its automated digital reports i.e. ACARS and its satellite i.e. SATCOM transmissions.

The omission is glaring as they form the aircraft’s last digital heartbeat, and proved vital in discovering what went wrong in the Malaysia Airlines (MH 370) crash of March 2014 and Air France 447 crash of June 2009. Omission of such data “undermines transparency,” says engineer Raghunandan.

On the 787 Dreamliner, both ACARS and SATCOM datalink transmissions rely on the CCS’s applications and the core network’s data backbone to format, route, and deliver digital messages to the radios and satellite terminals. A failure in either would simultaneously silence both ACARS and SATCOM.

In contrast the VHF communication radios are standalone line-replaceable units with their own power feeds.

Also read: Fuel cut in 1 sec? AI-171’s final minutes flag mechanical failure, not pilot error

Another crucial point is when ACARS fails, it doesn’t just cut communication links; it also cripples the pilots’ Electronic Flight Bags (EFBs), the cockpit tablets that stream live weather, NOTAMs (Notice to Airmen or hazard alerts for pilots), operational bulletins, and performance data.

For the crew — Captain Sumeet Sabharwal and First Officer Clive Kunder — that meant flying blind on evolving conditions, stuck with whatever stale information they had loaded before pushback. Every fresh query now had to be worked by voice, slowing responses and spiking cockpit workload—right when they were already battling cascading technical failures.

Experts say this is where AAIB releasing the cockpit recordings from the moment of fuel switch movement to “Mayday” call could prove invaluable.

A source in the industry believes that “ACARS flashed a #EIEM12 R0 as a fault code”. According to engineers, that could be a fault in Engine Interface and Electronic Module (EIEM) in Channel 12 where the system defaulted the signal to zero. In effect, the FADEC may misread the signal as idle or “off”, which could cause the engine to freeze at a low power setting or, in certain cases, shut down as a protective logic.

5. ELT: Emergency beacon didn’t activate

The Emergency Locator Transmitter (ELT), a critical post-crash distress beacon, was never activated, as per the AAIB report. It was recovered intact in the wreckage, yet it was silent.

A CCS/core network failure would not by itself stop the transmission from an ELT’s automatic g-switch — which is a gravity (g) switch with a sensor that detects sudden changes in acceleration (g-forces) that typically occur during a crash.

That is, unless the ELT’s antenna and wiring had melted in a fire — and one possible pointer to that is a Category A fault logged on AI 171’s Nitrogen Generation System (NGS), a safety feature Boeing added to prevent fuel tank fires in the aftermath of the Trans World Airlines Flight 800’s midair explosion due to a central fuel tank ignition in 1996.

The NGS works by continuously flooding the tail fuel tank’s ullage (the empty space above the fuel) with nitrogen-rich air, displacing oxygen and thereby preventing the build-up of flammable vapours.

If the NGS were not functioning, the oxygen levels around the aft-fuel tank bay may have been dangerously high. In that scenario, even a small spark—possibly from an electric arc or surge—could ignite a localised fuel-air vapour fire. That would have burnt the wiring and antenna of the ELT and wiring, connectors, and housing of tail-section black box or the aft Enhanced Airborne Flight Recorder (EAFR). And this scenario would be in line with the AAIB report, which shows the tail section was more structurally intact compared to the nose.

(Note: EAFR can refer to either the FDR or the CVR, or refer to both)

If a thermal event destroyed the ELT’s wiring or antenna, it would have cut off all chances of it transmitting. Even with a functional CCS, the physical damage would have prevented cockpit remote activation. Together (CCS failure + faulty NGS) explains why satellites never received the distress signal (406-MHz) from the ELT.

6. FADEC logic

The AAIB report is vague in describing FADEC behaviour on AI 171. The AAIB says, “When fuel control switches are moved from CUTOFF to RUN while the aircraft is inflight, each engine’s…(FADEC) automatically manages a relight and thrust recovery sequence of ignition and fuel introduction.” This is a subtle but important point: AAIB might be quoting the intended system behaviour rather than confirming it was observed in this case.

Why does this matter? Because, in the next sentence, AAIB does not give a timestamp for saying, “The EGT (or combustion gases) 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.”

So, going by the AAIB’s report, this is the sequence they establish.

• When engines went to “below minimum idle speed”
• When fuel switch movement went from RUN to CUTOFF
• When FADEC attempted relit and
• When RAT deployed.

Now, let’s reverse-engineer the crash. The ELT didn’t transmit at ~13:39:11 IST. That means whatever damage happened to the ELT happened at the point of impact or pre-crash.

So, after talking to aviation, flight and maintenance engineers, the possible sequence of events on AI 171 could be:

Core network degrades → Surge/electric arc in tail section → Burns wiring, housing, and connectors of aft-EAFR, wiring, antenna of ELT → Electrical power to tail section lost → RAT deploys → Simultaneously surge/electric arc impacts main avionics bay/CCR → Common-mode/CCS failure → Loss of multiple feeds, flight parameters triggers FADEC 1 protection logic → Fuel monitoring unit to CUTOFF → One second later FADEC 2 enters protection logic → Fuel monitoring unit to CUTOFF → N2 of engine 1 and 2 spool down, electrical generators/PMAs drops offline → FADECs shifts to secondary power source battery 28 VDC/RAT feeds → Pilot initiates restart, fuel switches move from CUTOFF to RUN → FADECs attempts first relight → Engine 1’s core deceleration stops, reverses, starts recovery. Engine 2 relights, combustion gases or EGT rise → FADECs attempts second or multiple relights → restart conditions unmet → FADECs abort restart → Mayday.

Flight engineers The Federal spoke to said the 2019 All Nippon Airways incident, in which FADEC commanded engine shutdown during taxiing, does not apply to AI 171, as it was at take-off thrust, which FADEC recognises as a “high-energy phase of the flight.

“FADEC is not a switch, but a logic tree with preset conditions. For FADEC to initiate shutdown at take-off, something extreme should have happened, like a loss of critical flight parameters — multiple feeds, and not a single-sensor anomaly,” said a flight engineer with a European airline.

Engineers say FADEC is context-aware and its usual design goal is to maintain thrust at all costs during take-off; so, only a rare incident could cause FADEC to override its primary design objective.

Also read: What India, and the world, can learn from AI-171 Dreamliner crash report

Let’s now look at why FADEC relight attempts might have failed. “FADEC might have aborted the restart attempt because of something called ‘starter availability’. That is, if pre-set conditions are not met, FADEC will abort rather than try,” said another flight engineer.

So, what is this starter availability? In AI 171’s case, when both engines shut down, the 787’s FADEC had electrical power via the RAT and DC battery 28 VDC, but “starter availability” was effectively zero.

So, in AI 171’s case, when both engines quit, starter availability was zero because the electric starter-generator torque (VFSG) was unavailable — as it's power generation was tied to the dead engines, and the APU hadn’t yet come online to supply electrical power (APU inlet door opened at 13:38:54 IST). The RAT and battery backup would've supplied enough power to keep FADEC and flight controls alive, but not to power a starter sequence.

That left only a windmill restart, which relies on the aircraft’s forward motion to spin the core. Given that the AAIB said AI 171’s top air speed was 180 kts, N2 of engines 1 and 2 would have been well below the ~15–20 per cent airspeed threshold (250–300 kts), so FADEC would instantly inhibit fuel re-introduction to prevent a hot or hung start (overtemperature ignition or stalled spool-up).

In layman’s terms, the FADEC had the “brains” to manage a restart but no “muscle” to spin the engine fast enough, so it refused to even try.

7. When the black box went dark

The AAIB reported that the tail-section black box or aft EAFR was substantially damaged and could not be downloaded through “conventional means.”

Now, black boxes are expected to survive extreme conditions — up to 1,100-degree fires and 3,400-g impacts. Unlike the forward EAFR, which has an independent battery, the aft unit relies entirely on aircraft power supplied via the engine-driven generators and routed through the core network. If the core network fails, the recorder may never initialise or log any data.

Now, the AAIB report and Boeing literature say both the forward and aft-EAFRs record the same flight parameters. So, if we’ve already got all relevant flight data from the forward EAFR, why do we need the aft?

We need the aft not for the data it recorded, but for when it stopped recording, as that’s crucial and clinching evidence that can pin exactly when systems failure began on AI 171.

Also read: Air India plane crash report: How fuel switches work in aircraft

The black box question — who holds the evidence?

The aft-EAFR on the Boeing 787 Dreamliner is manufactured by GE, whose representatives, as per the AAIB report, flew down to India for this investigation. The AAIB said aft-EAFR data could not be downloaded by “conventional means.”

Unlike Airbus, which has a more open protocol for independent download and examination of black box data, Boeing’s systems typically cannot be accessed without its cooperation. This, experts say, gives the manufacturer considerable control over what investigators can and cannot see.

Allowing the black box to be handled by the very manufacturer, whose equipment is under scrutiny, risks conflict of interest, a group of Indian lawyers said in a representation to the Ministry of Civil Aviation, adding, “this creates serious apprehensions of suppression, manipulation, or loss of crucial evidence”.

Normally, investigators would analyse fire residue and soot composition to trace ignition sources—identifying, for instance, whether the burning came from jet fuel, PVC insulation, or lithium components. Yet, the AAIB’s report is silent on any such forensic analysis — an omission multiple experts, including a crash investigator, flagged as highly unusual in a modern air crash investigation.

If fire residue forensics remain unexamined or unpublished, despite the tail section of the plane remaining largely intact, this is where the story shifts from tragedy into troubling questions on negligence.

Also read: DGCA orders inspection of Boeing 787, 737 fuel switch systems

A plane that flew with 5 active faults

Now let’s take a re-look at the active faults or MELs in AI 171.

As we have explained earlier, at the time of the crash, the plane was operating with five active MELs — four CAT C and one CAT A. These active faults were in:

• Core network — classified as CAT C

• NGS — classified as CAT A

Let’s explain this:

• CAT A — Must be fixed before next flight

• CAT B — Must be fixed within 3 days

• CAT C — Must be fixed within 10 days

• CAT D — Must be fixed within 120–160 days

What’s shocking is that the aircraft’s high-speed data backbone — the core network which links fibre-optic cables, connectors, and network switches linking the CCS’s computers to each other and to other aircraft systems — was classified as a medium-risk “fix in 10 days” item.

And crucially, this also carries data between systems such as the FADEC, cockpit displays, data links, and recorders for monitoring and reporting purposes.

This means that even as the 787’s central spine — the core network — was flagged for repair, the aircraft was legally allowed to keep flying for up to 10 days, raising tough questions about whether treating such a critical system as a moderate-risk item was appropriate.

Meanwhile, NGS — which prevents fuel tank fires by inerting vapours — was considered high-risk CAT A.

So, both the spine and the fireproofing of the aircraft were suspect. But the plane flew anyway.

Also read: Ahmedabad Air India plane crash: A timeline of events

Who cleared this?

That’s the question regulators, airlines, and the public must now confront. Below, we have compiled a set of questions that emerged after conversations with flight engineers, pilots and aircraft crash experts.

• On what basis did the Federal Aviation Administration (FAA) determine that the 787’s core network architecture provided adequate redundancies?

• Why was the core network — the system linking flight-critical systems — classified as CAT C, when its failure could bring down an aircraft? Why is Boeing’s operations note to airlines minimising the potential damage an inoperative core network can do?

• Why did the Directorate General of Civil Aviation (DGCA) or Air India not flag five concurrent MELs on an ultra-long-haul flight?

• Should the FAA’s bulletins have given more weightage to these critical design decisions and not left it to the airlines and manufacturer discretion?

Just like MCAS, this wasn’t just a failure in flight. It could be a failure in design, documentation, and certification.

Flight engineers The Federal spoke to from two European airlines say this is unprecedented. Up to three active faults or MELs would make any responsible airline rotate the plane and not send it on a long-haul flight.

Sources in Air India’s maintenance arm AIESL admit that it is somewhat unusual for Air India as well to give clearance to a plane with five active faults or MELs. “See, sometimes we don’t get parts in time; there are delays. So, it’s understandable why there’s a three- to 10-day bandwidth to fix the issue. But now, what’s concerning is both the risk categorisation and the number of active faults the plane was flying with,” said a maintenance engineer.

The Federal reached out to both Air India and DGCA about the MELs on the AI 171. Neither institution responded at the time of publication of this story. Airbus, the European Union Aviation Safety Agency (EASA), and the Transportation Safety Board of Canada (TSB) declined to comment. The International Federation of Air Line Pilots’ Associations (IFALPA) responded saying, “The crew and passengers of Air India 171 deserve our collective professionalism while the full investigation is conducted.”

Is the core network Boeing’s next MCAS?

The parallels are too sharp to ignore (see below).

And this time, the tail black box that might have proven everything is apparently unrecoverable by “conventional means”.

Air India 171 didn’t just fall from the sky—it may have been brought down by a centralised system approved under safety assumptions that now demand a re-examination. This is a story of risks of eroding redundancies and regulatory culture struggling to keep pace with the complexities of the very machines it certifies, say experts.

“Given the limited data, The Federal’s story is, I believe, very close to the actual account of what has happened. We firmly believe that a transparent and thorough investigation and a professional AAIB would have come to the same conclusion,” said Sam Thomas, president, Air Line Pilots Association.

Industry warnings

The Boeing’s CCS didn’t arrive without warnings. In fact, cybersecurity researchers and aviation engineers have been raising red flags about its architecture for years.

In a 2019 exposé, IOActive researchers dismantled Boeing’s public claims of secure digital compartmentalisation. They described the CCS as a unified hardware/software platform that hosts both critical and non-critical aircraft functions in a partitioned environment — meaning theoretically, failures in one section shouldn’t affect the other. But that theory, they argued, doesn’t hold up in practice. Boeing responded to IOActive that its systems have sufficient redundancy, but it did not provide details.

IOActive discovered software flaws in Boeing’s CCS, including buffer and integer overflows, that compromised the claimed system segregation. It also questioned Boeing’s reliance on CCR cabinets, flagging that without real-world testing, their fault tolerance could not be guaranteed.

The IOActive team’s conclusion was sobering: “Any one of these vulnerabilities, if exploited, could lead to a compromise across supposedly separated functions.” For a system managing everything from flight controls to maintenance alerts, that’s a systemic risk no software patch can easily mitigate.

Media reports have also noted that the FAA flagged a potential single-point-of-failure in Boeing 787 systems tied to backup power architecture; a similar problem that had performance implications just as severe as the truly isolated MCAS scenario.

Seconds to disaster

In the final seconds of AI 171, Captain Sumeet Sabharwal and First Officer Clive Kunder were perhaps flying blind, for the aircraft’s systems were crashing faster than any checklist could track. They probably didn’t know the core network had failed. They probably didn’t know a common-mode failure was underway, while the engines spooled down. They probably couldn’t know why the fuel switches cut off, or why the tail black box would never speak.

And yet, they appear to have fought to stabilise. And then they issued a Mayday.

Just like Captain Bhavye Suneja on Lion Air 610, they were probably left navigating a system that had already decided its fate.

(Disclaimer: The AAIB has not yet released its final report on the AI-171 crash. All the technical scenarios presented here are based on preliminary information and remain hypotheses. Airlines routinely conduct both scheduled and precautionary checks, especially following major incidents. Sources emphasised to The Federal that such checks are standard procedure and do not, by themselves, indicate any confirmed fault in the system.)