This article (part 2 and final) and part 1, published earlier, are part of the investigative analysis by journalist Rachel Chitra on the Air India-171 crash in Ahmedabad last June. The analysis is tentative, based on information the journalist accessed. The tentative analysis and likely conclusions are entirely those of the author and do not reflect in any way the position or views of the TPF – TPF Editorial Team.
In the previous part 1, we discussed how core network degradation likely caused the failure of multiple components. Like “the one ring to rule them all” in The Lord of the Rings, the core network is the one system that connects some 22 flight-critical and 28 flight-non-critical systems, and yet it was flagged only “medium risk” thanks to Boeing certification for the 787.
Now we piece together the final pieces of the jigsaw puzzle — the ACARS fault codes, core network failure, and the FADEC misinterpretation that likely triggered TCMA fuel cutoff mid-air. The moment the airplane’s digital system killed itself.
By Rachel Chitra
The morning, everything went dark
On June 12, when Air India flight AI-171 started rolling at 1:37:37 PM IST and lifted off from Ahmedabad, no one had any reason to suspect anything was wrong. Mothers were settling children into their seats, flight attendants Lamnunthem Singson and Nganthoi Kongbrailatpam had secured the galley latches, and two experienced pilots, Captain Sumeet Sabharwal and First Officer Clive Kunders, guided the Boeing 787 to the runway for what should have been a routine afternoon flight to London.
But disaster struck shortly after liftoff at 1:38:39 PM IST.
Three seconds into takeoff at 1:38:42 IST, AI 171’s systems were screaming… “247450002 597…252490002 597…252390002 597…,” as per data from two independent sources.
Strings of fault codes. Indicating that major systems, including flight control computers, were going down, taking dozens of subsystems and a bunch of sensors in their wake.
Systems failing faster than pilots could run a checklist
Three seconds into takeoff, when the pilots were trying to make sense of what was happening, the “Master caution” light would’ve flashed in their faces; directly in front of them on the glareshield panel.
On the flight, warning display or EICAS (engine indicating and crew alerting system) amber messages should’ve started queuing faster than any human eye could read.
Messages like “ELEC SYS,” “BUS ISLN,” “GEN OFF BUS”, “RAT DEPLOYED”, “SPOILERS”, “STAB TRIM,”…and then the loss of flight critical data….“AIR DATA SYS” “ALT DISAGREE,” “MACH DISAGREE,” “CAS DISAGREE,” “CABIN ALT AUTO,” “PACK,” “ZONE TEMP” “DATA COM” “BAT DISCH.”
But they likely didn’t. Because the plane’s fault reporting system itself had faulted.
A stroke mid-sky: the cockpit blackout
Then whole sections of the cockpit display would have frozen on their last readings as the computing and power backbone feeding EICAS collapsed — a sudden, system-wide blackout, like a stroke cutting off blood flow in the brain.
Cockpit lights would’ve flickered.
And EICAS’s prophecy would’ve turned true in two seconds when the pilots heard a sickening sound…. the sound of the left engine spooling down; and before the plane could yaw with the asymmetric thrust…the right engine winding down as well. And in the eerie silence filling the cockpit, they wouldn’t have been able to hear the loud, rackety sound of the Ram Air Turbine (RAM) spinning in the air.
Computers Rebooted, Went to Ground Mode in the Sky
But the RAM, the only working generator at that point on the plane, housed roughly 23 metres away from the cockpit in the 56.7 metre long body of the 787-8, would need a few more seconds to start generating hydraulic power and even more time to supply electrical power to feed critical flight instruments.
Capt Sumeet and First Officer Clive wouldn’t have known, but the Flight Control Computers (FCC) likely had gone into reboot.
And while rebooting, the logic deep inside the computers would have silently flipped to its fail-safe “ground mode,” before it started up, analysed and flipped back to “air mode.”
Yet in the face of the most bizarre and unprecedented of circumstances.
Two men still did their duty.
Captain Sumeet. The man who took over the aircraft. Started APU. Attempted relight.
And First Officer Clive, who ably assisted him, who ran checklists. Called ATC, who declared “Mayday.”
Engines Dead at 625 Feet — Pilots Still Fought to Bring the Jet Back
At that point, dual engine failure at a height of only 625 feet above sea level (minus Ahmedabad airport elevation of 190 feet) leaves a very narrow margin for relit attempts to have worked, even if they could have.
But both pilots did try, even as the brutal reality of their situation must have hit them like a speeding truck.
The AAIB report says the auxiliary power unit (APU) inlet door had started opening 17 seconds (1:38:54 IST) before the crash. And if it was opening, it could’ve only been the action of the pilots; only they would’ve switched on the auxiliary power, said flight engineers across airlines. Reason being the plane’s auto start logic would’ve been inhibited given the electric arc and the nature of some of the faults underway, which we discussed in part 1 of the investigation.
If the hand on APU start was pilot’s — Suicide theory falls flat on its face
And it’s not just flight engineers, even pilots say the same. “If they were faced with blank screens….at that point more than a memory item from a checklist, the immediate concern of the pilots would’ve been to get the plane’s power back on, and they’d have certainly turned on the APU,” says Sam Thomas, president, Air Line Pilots Association (ALPA).
Even though AAIB in its preliminary report seems to hint it was the system that triggered the APU with this line: “The APU Inlet Door began opening at about 1:38:54 IST, consistent with the APU Auto Start logic.”
“But then if it turns out it was manual action; that the pilots were doing their best to save the plane, it doesn’t fit the whole pilot suicide theory, does it?” asks an Air India pilot.
And here lies the crux of AI 171, where billions are at stake. If you could blame the pilots and not the plane; then more than 1,100 Dreamliners could continue to fly across the globe.
When AI 171 spent more time on the runway than in air
At 1:19:12 PM IST, AAIB reports that Air Traffic Control (ATC) queried if AI 171 required the full length of the runway. Pilot monitoring Captain Sumeet likely told ATC they needed the full length of Runway 23. Standard for a heavy, long-haul Dreamliner on a hot day.
Sometime in that crucial minute between runway roll, takeoff and flight, at 1.38 PM IST, an ACARS code (163600003) shows that there seems to have been a problem with the left and right thrust reversers and their locking sensors, which are the devices that tell the jet’s engine computer FADEC whether the engine’s rear doors are properly sealed for forward thrust.
AI 171’s 62-second roll: when the engine chose safety over speed
If the thrust reverser doors aren’t fully sealed, hot exhaust air could leak forward into the engine’s intake, disrupting smooth airflow and causing the engine to lose power or stall. So, to ward against that, FADEC will limit thrust.
Possibly a reason why AI 171 spent more time on the runway than in air. “It took 62 seconds on the runway. A clean takeoff roll should take only 40-42 seconds,” says Capt Amit Singh, the petitioner in the Air India case in the Supreme Court, and a commercial airline pilot.
The difference isn’t trivial: it points to an airplane struggling to reach take-off speed.
Acceleration on ground vs in air
And this becomes clearer when one looks at the acceleration data. Aviation Herald editor and electronics engineer Simon Hradecky said, “The AAIB report states that between 08:08:35-42 UTC (1:38:35-42 PM IST) the aircraft accelerated from 155 to 180 knots IAS. That’s an acceleration of almost 4 knots a second in air versus acceleration of 2.6 knots a second on the ground.”
Normally, as the plane’s nose begins rising at about 3° per second, lift increases, drag rises sharply, and the aircraft naturally stops accelerating the way it did on the runway. But AI 171 did the opposite. It shot up. Hradecky adds, “the aircraft will still accelerate at takeoff…however, at a much slower pace…in about the range of acceleration on the ground. Certainly not at nearly 4 knots a second.”
Explaining further, he says, once the aircraft begins rotating at about 3° per second, induced drag should rise quickly, even while the aircraft is still on the ground. As the nose comes up and the lift vector tilts further backwards, that induced drag begins to grow and can exceed the drag the tyres were producing. At the same time, as the wings generate more lift, weight is progressively removed from the tyres, so tyre drag falls away until it becomes zero at unstick. But this reduction in tyre drag is replaced by increasing induced drag as lift builds.
He adds that there is another reason acceleration should slow after liftoff. As the aircraft accelerates vertically into the climb, it needs more lift than just enough to balance its weight. A G-load of +1G would merely hold vertical speed constant; to increase climb rate, the aircraft needs more than that. But as lift increases, induced drag rises too, further limiting acceleration until the aircraft settles into a stable climb.
So while an aircraft does continue to accelerate after becoming airborne, Hradecky says that under normal conditions, this is usually only at around one knot per second, so long as the pitch remains reasonably below the climb angle and the aircraft is still rotating at about 3 degrees per second. Only once the aircraft reaches that climb angle does airspeed stop increasing, with thrust and drag coming into balance.
That is why, Hradecky says, an acceleration of 4 knots per second once airborne, especially sustained over seven seconds from 155 to 180 knots IAS, is unrealistic in normal operations. In his view, it indicates that almost immediately after liftoff, the crew were already dealing with an abnormal situation, and the pitch did not increase as per SOP; instead, the pitch angle was unusually low. This, he says, is also supported by the CCTV video, which appears to show a small pitch-down within a second after becoming airborne, after which the pitch does not increase again. Without being able to measure the pitch angle precisely from the CCTV footage, and with no such data published in the preliminary report, Hradecky estimates the aircraft may have been at around 9 degrees of pitch rather than the roughly 15 degrees that would be more normal.
The aircraft accelerating faster after getting airborne than it did across the length of the runway is a telltale fingerprint of something holding the jet back; something like maybe the reversers (ACARS code 163600003), say, pilots and engineers. The AAIB report mentions the physical position of the reverser levers, “that they were bent but in the stowed position.” But AAIB doesn’t mention its digital position recorded in the black box or enhanced airborne flight recorders (EAFR).
Seconds after liftoff, AI 171’s power grid collapse
The aircraft lifted off at 1:38:39 PM IST, as per AAIB. With multiple electrical faults already unfolding, power transients were almost inevitable.
Reverse-engineering the fault sequence, engineers say it’s likely the trigger for RAT deployment happened one second after liftoff at 1:38:40 PM IST. And RAT deployed two seconds later at 1:38:42 PM IST.
In part 1, we discussed how a high-voltage inverter could’ve arced and struck the forward and aft avionics bays (ACARS codes 247450002, 252490002, 252390002, 247460002). Now, this would likely have resulted in a power loss and a reboot of all three flight control computers (FCCs) by 1:38:43 PM IST, four seconds into takeoff. And the possibility of all three flight control computers rebooting mid-air, the FAA warned about as early as 2016, as per a Seattle Times report. To ward off against the eventuality, the FAA recommends a 21-day power cycle. Air India did not respond to whether such a 21-day power cycle was performed by the airline’s maintenance staff or the maintenance arm, Air India Engineering Services Ltd (AIESL).
A jet in the sky — with systems flipped to “on ground”
So that second 1:38:43 PM IST, when all three flight control computers rebooted, nearly every flight parameter on the plane — Weight-on-Wheels, thrust reversers, flaps, spoilers, landing gear, stabiliser trim — would’ve gone to their fail-safe mode, which would be “on ground.” And a second or two later, the rebooted flight computers would’ve analysed data, realised the true position and gone back to “in air” mode.
“Air-ground logic is based on several parameters, so not only WoW. For example, thrust reversers and ground spoilers may only work when WoW is TRUE “on ground”, radio altitude is below a certain altitude, and wheel speed is not zero,” says Joe Jacobsen, a former aerospace engineer with Boeing and deputy director with Foundation for Aviation Safety. He adds, “The details differ for different aircraft models.”
And now let’s see how that power loss and subsequent flight computer reboot would’ve affected each component on board. Let’s start with the landing gears.
FO Cliver raised gear, power cut likely stopped it halfway
If First Officer Clive had commanded gear “UP” at 1:38:42 PM IST, the gear would’ve started retracting, and then milliseconds into the command, it would’ve stopped had the plane faced a major power disruption. Given that the plane was already reporting operational errors in the hydraulic right pump (HYDIF Right) 15 minutes before takeoff at 1:23 IST. And the left hydraulic pump’s primary electrical path was R2, which would put it directly in the line of fire when the high-voltage inverter of the CMSC R2 line arced, as we discussed in part 1.
Possible sequence of events:
- The AAIB report notes that the landing gear lever was found in the “DOWN” position, but this refers to its physical state post-crash and post-fire. Not the blackbox or EAFR recording.
- If three seconds into takeoff, First Officer Clive commanded the gear “UP,” EAFR will record the command.
- And if three seconds into takeoff, there was a power disruption, EAFR will also record its after-effects. And the gear retraction stopping halfway.
With logic flipped to ground: spoilers can deploy, reversers can arm
At the fourth second into takeoff at 1:38:43 PM IST, if the flight control computers had rebooted its logic would’ve flipped to fail-safe mode, which is “on ground.”
Now, if the systems think the plane is landing (“on ground”), the flat panels on the top surface of an aircraft’s wings, called the spoilers, will auto deploy. The intention is to create drag and disrupt the airflow so that the aircraft slows down safely and stays on the runway.
In the air, spoilers are inhibited from deploying, as doing so would break the smooth airflow around the wings and cause the plane to stall. But on AI 171, spoilers likely auto-deployed because the flight computers rebooted and, for a second, went into “ground” mode.
The Reverser–Spoiler Double Blow
Remember the thrust reverser faults (1636000030) we discussed earlier that could have resulted in FADEC limiting thrust on the runway? Well, if the flight computers go from “in air” to “on ground,” then thrust reversers would go from “stowed” to “idle reverse.” At takeoff, engines direct airflow backwards to propel the aircraft forward. But if the thrust reversers were in “idle reverse”, they would redirect airflow in the opposite direction, providing a gentle braking effect, like when the plane needs to land and slow down on the runway.
If both the spoilers and thrust reversers were deployed mid-air, even briefly, the aircraft would have faced an immediate loss of lift and forward thrust — a double blow that could stall the jet within seconds of take-off.
The AAIB report says, “The reverser levers were bent but were in the ‘stowed’ position.” Engineers say this must be taken as proof of pilot integrity as their intentions, at least — going by AAIB’s photographs and words — were clearly for the reversers to stay “stowed.” They also note that the AAIB reports refer to the physical position of the reverser levers, not their digital position, as captured by the black box or EAFR.
AAIB quotes EAFR—just not for the “on ground”-logic-systems
Engineers say it must be noted that when the data supports a neutral interpretation, like with flap angle, airspeed, AAIB quotes the black box or EAFR. When the data would clarify whether the aircraft entered ground-mode before impact—nose pitch, landing gear, reverser levers, TO/GA, autothrottle—the report relies on describing their physical positions post-crash. “The digital capture for the very systems that determine ‘air’ versus ‘ground,’ for whether there was a stall, for whether the fly-by-wire automated jet went into manual mode — are all conspicuously absent,” says an engineer.
The AAIB report also omits many crucial timestamps, such as when the first fuel cut-off occurred, when the relight attempts began, and when the engine fan speed reached idle. Timings that crucially can shed light on the behaviour of the engine computers or FADECs, more than AAIB’s words, which are vague.
AAIB report on FADEC behaviour on AI 171
“When fuel control switches are moved from CUTOFF to RUN while the aircraft is in flight, each engine’s full authority dual engine control (FADEC) automatically manages a relight and thrust recovery sequence of ignition and fuel introduction,” says the AAIB.
FADEC is the plane’s full authority digital engine control. But AAIB refers to it as “full authority dual engine control” on page 15 of its report. Lawyers say this mistake — saying “dual” for “digital” and other wordings — in a sentence talking about how FADEC managed a “relight and thrust recovery sequence” could give AAIB “plausible deniability” if tomorrow it came to light that FADEC’s behaviour was different on AI 171.
In that paragraph, the report describes events such as fuel switches moving back to “RUN” and the APU inlet door opening, with precise timestamps from EAFR. And then…” it does sound as if the AAIB report is referencing how the FADEC procedure should work rather than explaining exactly what did happen on 171…underscoring the need for an independent evaluation of the actual FDR and any ACARS data to understand what was actually occurring with the automated systems,” says US attorney Michael Andrews, who is representing the families of the victims from the AI 171 crash.
When automation can pull the plug
So what did the engine computer FADEC really do on that plane? According to Boeing training manuals, if the plane switches to “on ground” logic in the air, the engine computers’ FADEC can initiate a fuel cutoff. If the conditions for something obtuse, called TCMA or thrust control malfunction accommodation, were met.
What is this TCMA? And why did Boeing design it?
Few phases of flight are as critical as takeoff, when both engines are at full power, and the aircraft is still on the ground. In this phase, there’s almost no time or room to correct an error before the plane hits the aircraft perimeter wall, nearby buildings, or other planes.
TCMA: FADEC’s Watchdog
To prevent accidents on the ground, Boeing and its subcontractors GE Aerospace and Safran designed TCMA — a protection circuit and software logic — for FADEC to prevent dangerous thrust.
When it comes to the question of how much engine power to command, passengers would be surprised to learn it isn’t the pilots but FADEC that calls the shots. Engine computer FADEC continuously compares the pilot’s commanded thrust with the engine’s actual output and calculates whether the thrust is accelerating or decelerating as expected. If the system detects that the thrust is inconsistent with the commands, the FADEC interprets this as a thrust control malfunction. In that case, it automatically shuts off fuel to the engine.
1:38:44 PM IST: Second AI 171 Likely Entered TCMA Kill Zone
As per TCMA patent documents and Boeing literature, for a TCMA event, all of the following conditions must be true:
- Airplane is on the ground
- Airspeed is less than 200 knots
- Altitude is less than 17,500 feet
- Selected N1 (engine fan speed) is more than the TCMA threshold
And in AI 171’s case, at 1:38:44 PM IST, four of these conditions were likely met.
- Airplane is on the ground = Flight computers rebooted, logic went to “on ground”
- Airspeed is less than 200 knots
- Altitude is less than 17,500 feet = maximum altitude reached was around 435 feet, going by ADS-B transponder data minus Ahmedabad airport elevation
- Selected engine fan speed (N1) is more than the threshold = possible given the takeoff thrust
So how did FADEC see TCMA engine’s actual fan speed (N1) as incompatible with the commanded takeoff thrust? Why did it sense danger?
On data recorded in the black box, AAIB says, “EAFR data revealed that the thrust levers remained forward (takeoff thrust) until the impact.”
AAIB’s statement is actually proof of pilots’ integrity, say engineers, “as it shows pilots’ intention – that they kept the thrust in forward from takeoff to crash.” Engineers also say AAIB’s statement that throttles were in “forward”, along with GE documents, can point to a different story.
Inside the Boolean Gating Trap: FADEC’s Blind Spot
Older GE engines had a logic condition (Boolean gating) of “AND.” Meaning throttles “AND” thrust reversers have to be in “idle” for TCMA activation. But pilots found that inconvenient, as for certain ground manoeuvres during taxiing and initial rollouts, they keep the thrust levers in forward and the reverser levers in idle.
So, for newer GEnx engines developed by GE Aerospace in partnership with Safran, the logic condition was changed from “AND” to “OR,” according to sources at GE and Air India. Meaning either throttle “OR” thrust reversers can be in “idle” for TCMA to activate if FADEC feels thrust is not proportional to airspeed.
And on AI 171, we do know that there was both a thrust reverser fault (163600003) and flight control computers likely rebooted; and thrust reverser status could’ve gone to fail-safe mode of “idle reverse.”
So then AI 171 had throttles in forward and thrust reversers, likely in “idle reverse”, so some TCMA conditions were met. But TCMA would also require engine speed (N1) to be disproportionate to airspeed data. So what was happening on AI 171 that caused FADEC to believe the engine thrust was dangerously high?
Airspeed data failure on AI 171
The whole series of ACARS codes accessed and sent to Boeing was topped off with “EM12R0.” EM12R0 indicates a disagreement in airspeed data. Now, on an average day with 1,100 Dreamliners in the sky, nearly 80-100 Dreamliners can fly with this code with no harm, as it just indicates one of the channels for air speed calculation disagreed with another. But on AI 171, it could’ve proved disastrous given some of the other failures underway.
EM12R0 indicates engine monitoring (EM) on channel 12; i.e., the total air temperature (TAT) probe fell to zero (R=0), meaning its inputs were no longer considered valid. This brings us then to the question of whether FADEC got calibrated airspeed (CAS) on AI 171? Was a failure to get CAS the reason for the whole series of failures, topped off by “EM12R0”?
True airspeed: Lion Air 610 crash investigation vs AAIB report
In crash investigations such as Air France 447 and Lion Air 610, authorities published the IAS (indicated airspeed), CAS (calibrated airspeed), and TAS (true airspeed). In contrast, the AAIB report in every reference to airspeed only mentions IAS: “take-off decision speed V1 153 kts IAS…maximum recorded airspeed of 180 Knots IAS.”
Now, one mystery in AAIB’s discussion of indicated airspeed (IAS) is: what was the engine computer FADEC getting? Because FADEC does not accept a raw value like IAS. It only accepts calculated values like CAS and Mach, which represent the aircraft’s speed relative to sound. While IAS requires only pitot tubes to be operational, calculated values like CAS and Mach require additional components, such as the total air temperature probe (TAT), to be operational as well.
Now, before roll, the engine computer FADEC needs valid feeds, including calibrated airspeed (CAS), to set thrust. So at 1:37:35 PM IST — two seconds before roll — FADEC has to have a valid CAS from the flight computers via the core network for it to set thrust.
At this point, the system is not dependent on the TAT probes, but on an inlet cabin temperature probe. This is because the external TAT probe is an aspirated probe, meaning it needs airflow – the plane doesn’t start using it till it crosses 50 knots.
Frozen Airspeed: FADEC voting logic, the pathway to TCMA Activation
At about 1:37:56 UTC, the aircraft crossed 50 knots. And that’s when AI 171 must have switched to using its external TAT probe.
FADEC in normal mode will not accept a single feed for airspeed data, in case it’s false or invalid. FADEC will use voting logic for airspeed data. It will vote on multiple feeds and accept only if two or more readings are consistent.
FADEC takes calibrated airspeed (CAS) data from multiple feeds (internal T12 TAT probe + FCM L + FCM R + FCM C). Only if two or more feeds are consistent will it accept their value. If not, then FADEC will latch onto “last known good value.”
So, for calibrated airspeed (CAS), FADEC might have latched on to “last known good value” of around 176 knots at 1:38:41 PM IST, or 50 knots at 1:37:56 PM IST. With the first timestamp being, if we assume flight computers lost TAT readings only after a power disruption caused by an electric arc. And the second timestamp, if we assume flight computers lost TAT readings at the handover point on roll, when the system stopped using the cabin probe and switched to external TAT once the plane crossed 50 knots.
Triple Redundancy on Paper—TAT A Single-Point Failure in Reality
Now the normal assumption would be that each flight computer has its own TAT probe, so that each of the three flight computers has its own data source, i.e., three TAT probes. The 787 has three pitot tubes and two angle-of-attack sensors.
But in reality, the 787 has mapped all its three flight computers to the same single external TAT probe. So even though the 787 looks like it has triple redundancy for airspeed data on paper. In reality, each FADEC obtains its airspeed data from its own internal TAT and the three flight computers (FCM L, FCM R, and FCM C).
But if all three flight computers reboot at the same time or the TAT probe failed earlier, FADEC will latch onto the last known good calibrated airspeed (CAS) value, which could have been 176 knots or 50 knots. When FADEC’s own internal TAT probe (T12) showed the correct reading of the plane as it accelerated to 187–191 knots IAS at 1:38:43 PM IST, four seconds after liftoff, FADEC will assume its own probe is wrong, generating the ACARS error code “EM12R0.”
A likely catastrophic logic error by FADEC, leading to the death of 260 people.
The last few seconds on AI 171
No altitude. No thrust. No starter power. Capt Sumeet would’ve sensed this reality as early as the 15-16th second into liftoff.
As he was toggling the fuel switches back to RUN for a relight attempt, he’d have known the truth. The plane couldn’t be saved.
But he and First Officer Kunders still did their best.
Capt Sumeet attempted a relight. Started the APU.
First Officer Clive communicated with ATC. Called out “MAYDAY MAYDAY MAYDAY” at 1:39:05 PM IST.
The pilots likely never even received the “Pull up, Pull up” terrain warnings.
Against the deafening silence of blacked-out systems, the only sounds Capt Sumeet and First Officer Clive would’ve heard were passenger screams and ATC’s responses — as the ground closed in on them.
(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 evidence submitted to India’s Parliament and Supreme Court, and remain hypotheses. Also, the ACARS codes mentioned in the story are not a direct map to maintenance faults listed in Boeing’s Fault Isolation Manual, since maintenance faults are 7-8-digit strings. The 9-digit ACARS string is only partially recognisable to engineers as it is Boeing’s proprietary code. For this story on conditions of anonymity, we have spoken to pilots plus flight and design engineers for airlines and Boeing in India, Europe and the US; and for details on actuators, sensors, structural engineering, logic paths to IT, mechanical, electrical and electronics engineers from India who are Boeing subcontractors)
Feature Image: www.livelaw.in
Leave a Reply