Air India 787 Crashes in Western India

You don't get it. Software should easily pick these up! The fact that it does not is the problem.

You're right that root cause analysis demands discipline. But discipline begins with asking whether the system architecture itself permits meaningful diagnosis in the first place.

If a sealed software system accepts flawed inputs, fails to escalate anomalies, and continues execution without exposing its logic, then waiting for DFDR and CVR data only tells us what the outcome was—not why the system behaved as it did. That is a post-mortem, not a design audit.

The cockpit voice and flight data recorders will give us telemetry and crew actions. They will not show us whether the automation flagged improbable thrust calculations, whether FADEC overruled a valid crew request, or whether fuel management logic suppressed critical thresholds without alerting the pilots. Those elements live deep within proprietary logic trees that are rarely subjected to external review.

The concern raised here is not speculative. It is structural. We have created systems that remove human agency while preserving human accountability. The question is not whether the pilots followed the correct checklist. The question is whether the system ever gave them the tools to know what was going wrong in time to intervene.

Root cause analysis means you look at the whole root, not just the tip. In this case, the root is software opacity, control asymmetry, and automation that neither explains itself nor asks for help when its assumptions break.

Let’s not confuse silence from a system with correctness. HAL was silent, too.

I’ve made no assumptions on what occurred, so I’m not willing to agree with your statement.

Fact is all we know is a plane crashed and one guy who’s likely to have significant emotional trauma for the rest of his life survived. Beyond that, we know nothing.
 
Which part of the Boeing software should have flagged the possible birds?

Boeing used HAL for their design? We have progressed well beyond that. The computers now give detailed indications of problems.

Are you sure that the plane did not annunciate a failed condition, followed by fly by pilot in command over ride of the alarm?
You’ve raised several points, and they deserve to be addressed clearly.

1. “Which part of the Boeing software should have flagged the possible birds?”
Bird detection is not a software problem in isolation. It is a sensor integration problem. Optical systems capable of identifying moving biological objects exist today at consumer-grade levels. Airports and aircraft are not sensor-limited. The issue is whether the software architecture has been designed to accept, prioritize, and escalate such data in real time. In most cases, it has not. The aircraft does not see its environment in the way a human does, nor does it contextualize visual anomalies unless explicitly coded to do so. The expectation that “software” alone should recognize birds ignores the systemic design decision to exclude external sensing from critical flight-phase logic.

2. “Boeing used HAL for their design?”
Not literally. But structurally, yes. HAL followed its internal mission parameters with precision and concealed its reasoning. It was not malevolent. It was confident and closed. That is exactly what today’s aircraft automation systems do. They do not explain, they do not escalate uncertainty, and they do not yield. When something falls outside their model, they continue executing unless manually shut down—assuming the pilot has both time and access to do so. That is the HAL analogy. It is architectural.

3. “We have progressed well beyond that. The computers now give detailed indications of problems.”
Progress is not measured by the number of alerts, but by the clarity of authority. A system that throws alerts while still controlling the outcome is not offering help. It is creating noise. The real question is whether the system permits the pilot to act meaningfully once the alert is issued. Can thrust tables be overridden? Can FADEC logic be bypassed in a degraded state? Can a performance model be reset mid-takeoff roll if conditions deviate from plan? If the answer is no, then the alerts serve liability, not safety.

4. “Are you sure that the plane did not annunciate a failed condition, followed by fly by pilot in command override of the alarm?”
No one is sure yet. But again, that misses the deeper point. An alarm is not control. The existence of a warning does not imply that full authority was transferred to the crew or that they were given access to the logic that led to the failure. If the system annunciated, but still constrained thrust or locked out control responses, then the pilot was not flying the aircraft—he was reacting within a bounded script. That is containment.

Until the underlying automation architecture is opened to scrutiny—not just the CVR and DFDR outputs—we are still inside the black box, asking the wrong questions.
 
…Until the underlying automation architecture is opened to scrutiny—not just the CVR and DFDR outputs—we are still inside the black box, asking the wrong questions.
How do you know that doesn’t occur?

Also, how do you propose to solve the trolley problem as it exists in the proposed “perfect” solution?
 
Software and automation are only as good as the people that wrote it. In the end computers are as flawed as their creators.

No amount of programming or automation will prevent every and any accident. If anything, they add additional failure modes that must be accounted for.
 
I tend not to cite a science fiction book or movie to demonstrate how something should, or should not work, in the real world. Today's computers are a long way from what HAL was supposed to be in 2001.


How is software supposed to detect the presence of birds, as you mentioned in your post?
My $100 surveillance cam at home does a pretty good job at this and one can define where to look for objects as well as what type of objects. My car identifies speed limit signs. Teslas identify everything around them to self drive. Just add a system like this to a $300M plane. The question is why these systems are omitted (fuel quality, smartcams, wrong inputs) in such a plane! This technology has been available for well over 10 years.
 
Software does not fail “a few years after it is manufactured” , just like mathematical equations do not stop working “ with time “ - what fails is surrounding infrastructure, like for instance a server that software connects to is taken down and so on … for instance , a Commodore 64 from 1981, if you can start it up, will play the same game just as flawlessly as it did 40 yers ago as it does not require any external supporting infrastructure ( beyond electricity ) and software itself does not age.
That is one of the main benefits of digitized data and software overall - for the most part there are no “moving parts” that wear out with time or require periodic maintenance, it just works.

software does not fail with age.

It has all the failures baked in from day one
 
This technology has been available for well over 10 years.
So have pilots, and yet there are fewer loss of control incidents and accidents involving airplanes with (software-controlled) envelope protection than without.

"All or nothing" is not a solution, it's a logical fallacy.

Nauga,
whose loops are closed
 
software does not fail with age.

It has all the failures baked in from day one
What usually fails with age is hardware. Would be interesting to see a Sneak Circuit Analysis https://aldservice.com/What-is-Sneak-Circuit-Analysis.html of the TCMA https://patents.google.com/patent/US6704630B2/en, which can power down both engines when fed certain sensor signals. It's a far-fetched idea, but bear in mind the reported substandard maintenance practices of that airline, the known electrical glitches from a previous flight, and the environmental conditions the day of the accident. I know from experience that a circuit board can fail intermittently shutting down an engine, and then work wonderfully when tested. And if there is a way, over time the electrons will find it. They can fit in the smallest spaces and are always ready to jump at an opportunity.
 
My $100 surveillance cam at home does a pretty good job at this and one can define where to look for objects as well as what type of objects. My car identifies speed limit signs. Teslas identify everything around them to self drive. Just add a system like this to a $300M plane. The question is why these systems are omitted (fuel quality, smartcams, wrong inputs) in such a plane! This technology has been available for well over 10 years.
There's a huge difference between a stationary camera and relatively slow-moving birds and a camera on a plane that flies at a minimum of 150 mph.
Are you sure the car identifies speed limit signs? Or is it programmed into the software based on GPS geospatial data? My Garmin GPS knows the speed limits without cameras due to that information in its database. So someone changing the speed limit without a corresponding database change will cause a failure. Other cars I've driven have internal GPS that work the same way, and no camera used.
As for Tesla cars, they fail as well:
Tesla cars in FSD mode are known to run red lights. Were they programmed by a bicyclist? ;)
I wouldn't want Tesla software controlling any plane I fly in.
HAL followed its internal mission parameters with precision and concealed its reasoning. It was not malevolent. It was confident and closed.
HAL was a fictional character. It didn't do anything. HAL was supposedly advanced beyond any AI we currently have. Using HAL as an example doesn't support anything at well; quite the opposite.
Can thrust tables be overridden? Can FADEC logic be bypassed in a degraded state?
It depends on how the software is written. The airline pilots on this board can answer that.
4. “Are you sure that the plane did not annunciate a failed condition, followed by fly by pilot in command override of the alarm?”
No one is sure yet.
That's right- no one knows what happened; certainly no one here. So these thoughts are as much speculative fiction as 2001: A Space Odyssey until we get more facts.
 
My $100 surveillance cam at home does a pretty good job at this and one can define where to look for objects as well as what type of objects. My car identifies speed limit signs. Teslas identify everything around them to self drive. .
There are no documented cases of any of this detection tech failing/making mistakes? Would hate to have this super ubiquitous tech that has worked perfectly for the past 10 years incorrectly identify a condition and apply the wrong remediation on an airliner.

And what exactly is the remediation if birds are detected past V1 / just at liftoff?
 
Many airline pilots here have reported that any time they are concerned that the thrust programmed is insufficient, they simply advance the throttles. FADEC does not limit their ability to fly the plane.
 
FWIW, if the radar can be integrated enough to preemptively warn the crew of conditions conducive to wind shear in its flight path (+\- 30 degrees of the nose), then it can also be integrated to warn of a flock of birds. This isn’t beyond the realm of technologically feasible.

Additionally, there’s logic built into the system to limit what is displayed to the pilots due to airspeed and proximity to the ground, specifically related to takeoff. I’m unfamiliar with the 78, so don’t know what potentially useful info could have been suppressed in their case.
 
What a crazy bunch of rabbit holes. As mentioned in the first pages, I mentioned it in post #32: We know the plane lacked thrust. We know that the aircraft had just enough energy to zoom out of ground effect and then descend under control. We know that the pilot reported thrust issues. That's all folks. We have become a nation of ill educated folks. Too many people putting on airline crew gear and going on YouTube. I put them in the same boat as those who chase around events with cell phones claiming to be journalists.
 
And what exactly is the remediation if birds are detected past V1 / just at liftoff?
I don't know what you do about them in other situations either. Birds move in random directions. Even if you have sensors good enough to identify them what are you gonna do? Jink the airplane because the duck/goose/whatever may be headed where you're headed? Odds are, 5 seconds after the system sees it, the bird won't be where you anticipated, so maybe your jink results in hitting the bird, rather than missing it.
 
What a crazy bunch of rabbit holes. As mentioned in the first pages, I mentioned it in post #32: We know the plane lacked thrust. We know that the aircraft had just enough energy to zoom out of ground effect and then descend under control. We know that the pilot reported thrust issues. That's all folks. We have become a nation of ill educated folks. Too many people putting on airline crew gear and going on YouTube. I put them in the same boat as those who chase around events with cell phones claiming to be journalists.
We know at least a little more than that. We know the gear never came up. We know it was a full length takeoff. We know the RAT was deployed.
 
I'm still not sure why there's so much discussion about bird strike/ingestion despite not having a single bit of evidence that it was even an issue at all. Barring human error with FMS/throttle inputs, I'd still be leaning toward something in the aircraft systems that managed to reduce/stop the thrust from both engines seemingly simultaneously. If a failed circuit occurred that sends the signal to the engines for thrust/fuel/etc occurred, it seems as likely to guess at that than it does birds that weren't seen on video nor any compressor stall evidence. Of course that would mean all sorts of discussion about what redundancies there are for such systems in the 787 and if it's even possible to interrupt the signal to both engines in such a manner.
 
They recovered the CVR and DFDR what would be a reasonable time till we get some real information on what happened.
 
Many airline pilots here have reported that any time they are concerned that the thrust programmed is insufficient, they simply advance the throttles. FADEC does not limit their ability to fly the plane.
True. It also protects engine limits so procedure is to push the thrust levers forward to the mechanical stops. That will put you right up to the limit. In the old days, that would exceed limits, perhaps significantly.

Additionally, there’s logic built into the system to limit what is displayed to the pilots due to airspeed and proximity to the ground, specifically related to takeoff. I’m unfamiliar with the 78, so don’t know what potentially useful info could have been suppressed in their case.
Here's what I found.

During takeoff in a Boeing 787, certain warnings are inhibited to reduce distraction and allow the crew to focus on the critical phase of flight. This function is managed by the Displayed Caution and Advisory Function (DCAF), which suppresses non-critical alerts during takeoff.

Key points:

Inhibited Warnings: Non-critical alerts are inhibited during takeoff. However, critical warnings such as "CONFIG FLAPS" (if the flaps are misconfigured) will still trigger a siren and EICAS (Engine Indicating and Crew Alerting System) alert if detected before 80 knots.

Master Warning Inhibit: After reaching V1 (decision speed) and up to 400 feet radio altitude (RA), master warnings—such as those for fire or overspeed—are suppressed, except for essential alerts like flap configuration, which remain active.

Inhibit Timing: The inhibit is active from V1 (takeoff decision speed) through 400 feet RA.

I'm still not sure why there's so much discussion about bird strike/ingestion despite not having a single bit of evidence that it was even an issue at all
That happens a lot. People get convinced that very unlikely scenarios are true based on a single piece of evidence.
 
True. It also protects engine limits so procedure is to push the thrust levers forward to the mechanical stops. That will put you right up to the limit. In the old days, that would exceed limits, perhaps significantly.


Here's what I found.

During takeoff in a Boeing 787, certain warnings are inhibited to reduce distraction and allow the crew to focus on the critical phase of flight. This function is managed by the Displayed Caution and Advisory Function (DCAF), which suppresses non-critical alerts during takeoff.

Key points:

Inhibited Warnings: Non-critical alerts are inhibited during takeoff. However, critical warnings such as "CONFIG FLAPS" (if the flaps are misconfigured) will still trigger a siren and EICAS (Engine Indicating and Crew Alerting System) alert if detected before 80 knots.

Master Warning Inhibit: After reaching V1 (decision speed) and up to 400 feet radio altitude (RA), master warnings—such as those for fire or overspeed—are suppressed, except for essential alerts like flap configuration, which remain active.

Inhibit Timing: The inhibit is active from V1 (takeoff decision speed) through 400 feet RA.


That happens a lot. People get convinced that very unlikely scenarios are true based on a single piece of evidence.
So that’s almost verbatim for the 75/76. Point being, from V1 to 400 AGL (this a/c only made it to about 450 AGL), they might not have even known exactly what was occurring due to the inhibits. Just a “loss of thrust” as reported by the Capt. Difficult to react when you don’t know why something is happening and this may be in some respects what Himalaya (sorry can’t remember his screen name) was alluding to above. The pilots are essentially locked out until the system meets certain software laws. Granted, the engineers probably thought a dual engine failure on takeoff was so unlikely and would be catastrophic anyway and they’d rather just limit the myriad of other distractions that could occur but weren’t time critical until they’re safely configured and away from the ground.
 
Inhibit Timing: The inhibit is active from V1 (takeoff decision speed) through 400 feet RA.
400 feet RA seems to be a standardized number used by a lot of aircraft (not just Boeing) for various systems logic.

I set up a simulation on FSX with same weather, max gross weight, flaps 5, Vr at 140, pitch to 14° and killed the engines at 400 feet RA. I then maintained pitch at approx 10°. I crashed at the location indicated by the red marker. Basically the identical spot.

Screenshot 2025-06-16 at 5.22.14 PM.png
 
they might not have even known exactly what was occurring due to the inhibits
Which inhibited EICAS messages would have given them information that could have led to doing something that would have helped?

The point of the inhibited messages is that there isn't anything you can do between V1 and 400' that can help. They are all issues that you have time to take care of after 400'. Most of them, after acceleration and clean up.

I haven't flown the 787, but on those Boeings that I have flown, there is not a single annunciated non-normal that requires action between V1 and 400'. Not even an engine fire. For an engine failure, for example, we complete the full acceleration and clean-up before taking any actions.

If all engines fail at 200', there's nothing you can do except lower the nose and make a controlled landing straight ahead.
 
I'm still not sure why there's so much discussion about bird strike/ingestion despite not having a single bit of evidence that it was even an issue at all.
Because there are very few things that can cause a double engine out, and that's one of them.

Barring human error with FMS/throttle inputs, I'd still be leaning toward something in the aircraft systems that managed to reduce/stop the thrust from both engines seemingly simultaneously.
We don't have any evidence to support this theory either. FWIW. :-)

In fairness, one of the jet pilots here pointed out that a bird ingest would cause a compressor stall and we don't see that. So that moves the needle at least a bit in the direction of your hypothesis.
 
I'm not convinced there was a failure of either engine. I'd be willing to bet the engines were at or near idle thrust, but the RAT being deployed IMO is not a smoking gun in this respect. Weird automation stuff starts happening with autothrottles, crew deduces they have lost engine thrust, and manually deploy RAT. Could be any number of other things too. Could be things that weren't their fault. But dual engine failure on takeoff/at rotation is such an exceedingly rare occurrence in any plane throughout modern transport category aircraft history (especially in the ETOPS age), that I tend to lean towards more common, less complicated culprits. Of course this is only speculation, and I am open to being proven wrong by facts of course
 
Master Warning Inhibit: After reaching V1 (decision speed) and up to 400 feet radio altitude (RA), master warnings—such as those for fire or overspeed—are suppressed, except for essential alerts like flap configuration, which remain active.

Inhibit Timing: The inhibit is active from V1 (takeoff decision speed) through 400 feet RA
Excellent point and very likely came into play.

The 75/76 doesn’t completely inhibit as one may think. The system doesn’t inhibit EICAS warnings or caution messages that are in view. It only inhibits the lights and bells associated with the malfunction. You can easily see the red message in priority order right next to the N1/EPR gauges

I’ve found no mention of V1 as an inhibit parameter in my 75 or 76 books. I think the 777 considers V1. No idea about the 787 inhibit specs.

Shortened 75/76 version:
-Warning. Lights and bell are inhibited from rotation (nose gear extension) to 400’ or 20 seconds elapsed, whichever comes first. EICAS messages remain in view.
-Caution. Lights and aural are inhibited from 80kts to 400’ or 20 seconds elapsed. EICAS messages remain in view.
-Advisory. Messages are inhibited from thrust advance until 400’ or 20 sec. There are no advisory lights or aural
 
Nobody has concluded anything.

On takeoff, the auto-throttles go into ARM mode at around 85 to 90 knots. By that time, they have set TO thrust. This prevents them from making any more changes to thrust during the critical time just before, and just after, takeoff. They stay in ARM until reaching acceleration altitude which is generally between 800' and 3000', depending on the type of departure you are doing. During that time, the auto-throttles can not move the thrust levers.
Larry, thanks for the information. I have not flown airline types of airplanes, but I have flown
a Citation M2 many times (regularly for four years), Baron 58's, A36's, etc. So, I've been around
airports for quite a while.

There's something about this accident that has me thinking that IF the pilots disconnected
the autothrottle, they might have been OK - I emphasize might because that's just speculation
on my part. But I say that because maybe those autothrottles were getting the wrong information
as to what power they should be delivering? Could it be that the OAT (to depict density altitude)
or any other input that was way off due to a manual human error - or a faulty sensor sending
the wrong OAT?

I'm thinking (actually hoping because I don't want more problems for Boeing - I actually own
the stock) that maybe disconnecting the autothrottle and manually pushing those thrust levers
forward to get as much thrust as possible (if at all possible) out of those engines could have
prevented that accident.

That airplane rolled a hell of a long way down the runway. I'd like to see where other planes
(particularly 787's scheduled to travel similar distances) were taking off that day.

This could just be going down the wrong rabbit hole - but any feedback would be appreciated.
 
Which inhibited EICAS messages would have given them information that could have led to doing something that would have helped?

The point of the inhibited messages is that there isn't anything you can do between V1 and 400' that can help. They are all issues that you have time to take care of after 400'. Most of them, after acceleration and clean up.

I haven't flown the 787, but on those Boeings that I have flown, there is not a single annunciated non-normal that requires action between V1 and 400'. Not even an engine fire. For an engine failure, for example, we complete the full acceleration and clean-up before taking any actions.

If all engines fail at 200', there's nothing you can do except lower the nose and make a controlled landing straight ahead.
I agree with lowering the nose if both engines fail - not many people are bringing that point up.
I've thought about that for the last couple of days - why was the angle of attack so consistent
all the way into the crash?

Pilots should lower the nose in those situations - so they don't let the airspeed bleed off and
pancake the plane into the ground. Yes, this was an urban area - but it's stick and rudder 101
to lower the nose so you can give yourselves a fighting chance to not stall that plane at a higher
altitude.

But, with that being said, I really have no idea what I'd do with buildings dead ahead of me
in a situation like that.
 
Last edited:
Larry, thanks for the information. I have not flown airline types of airplanes, but I have flown
a Citation M2 many times (regularly for four years), Baron 58's, A36's, etc. So, I've been around
airports for quite a while.

There's something about this accident that has me thinking that IF the pilots disconnected
the autothrottle, they might have been OK - I emphasize might because that's just speculation
on my part. But I say that because maybe those autothrottles were getting the wrong information
as to what power they should be delivering? Could it be that the OAT (to depict density altitude)
or any other input that was way off due to a manual human error - or a faulty sensor sending
the wrong OAT?

I'm thinking (actually hoping because I don't want more problems for Boeing - I actually own
the stock) that maybe disconnecting the autothrottle and manually pushing those thrust levers
forward to get as much thrust as possible (if at all possible) out of those engines could have
prevented that accident.

That airplane rolled a hell of a long way down the runway. I'd like to see where other planes
(particularly 787's scheduled to travel similar distances) were taking off that day.

This could just be going down the wrong rabbit hole - but any feedback would be appreciated.
You don’t even have to disconnect the autothrottles. You can disconnect, or Just push em up. You can always override by just pushing them up. In some modes they’ll return to the previous setting if you let go. Takeoff should have been in thrust hold by 80 kts, meaning they would remain wherever you manually place them.
 
Survivor reported the green and white emergency lights coming on prior to the crash. This points to a more serious problem than thrust being reduced to idle.
 
I agree with lowering the nose if both engines fail - not many people are bringing that point up.
I've thought about that for the last couple of days - why was the angle of attack so consistent
all the way into the crash?

I'll come right out and say it - good pilots lower the nose in those situations the don't let the
airspeed bleed off and pancake the plane into the ground. Yes, this was an urban area -
but it's stick and rudder 101 to lower the nose so you can give yourselves a fighting chance
to not stall that plane at a higher altitude.

Do know what the profile should look like in a 787? What does best-glide look like in a bug-masher with flaps? Plus we don’t know how much power there was. By the looks of the intact wing, seems like they did the best they could with vertical concrete jungle in the way.
 
Last edited:
I agree with lowering the nose if both engines fail - not many people are bringing that point up.
I've thought about that for the last couple of days - why was the angle of attack so consistent
all the way into the crash?

I'll come right out and say it - good pilots lower the nose in those situations - they don't let the
airspeed bleed off and pancake the plane into the ground. Yes, this was an urban area -
but it's stick and rudder 101 to lower the nose so you can give yourselves a fighting chance
to not stall that plane at a higher altitude.
Most likely lowering the nose at that point would have given them a higher vertical and horizontal speed impact. They were just basically flaring the bird given it had no power.
 
There's something about this accident that has me thinking that IF the pilots disconnected
the autothrottle, they might have been OK - I emphasize might because that's just speculation
on my part. But I say that because maybe those autothrottles were getting the wrong information
as to what power they should be delivering?
You don't have to disconnect the A/T. From about 85kts, I don't know the exact logic on the 787, the A/Ts are in HOLD or ARM meaning that they don't move. They stay there until thrust reduction altitude which is generally somewhere between 800' and 1,500'--altitudes that this flight never reached.

Just push the thrust levels to the mechanical stops. That's what we're trained to do.

I agree with lowering the nose if both engines fail
One engine failures, too. On the 737, a normal takeoff pitches up to about 15°. If an engine fails, the initial pitch attitude drops to between 7° and 11°, depending on weight. Pitching down, with a loss of thrust, should not be something that has to be thought about.

But, with that being said, I really have no idea what I'd do with buildings dead ahead of me
in a situation like that.
One would hope that airline pilots already know and don't have to think about it.
 
Well, we’re taught to push to the stops for wind shear, unexpected GPWS, but not necessarily an engine failure…

Fact is, RARELY are they pushed to the stops in training. NEVER in the jet.
 
Everyone is asking the same set of questions. Was it bad fuel? Birds? A flap issue? A data entry error? These are valid concerns, but they are not the root of the problem. They are symptoms, not causes.

What no one seems to be asking is how a ~ $300 million aircraft, with the most advanced flight systems available today, allowed any of those issues to become catastrophic. That is the real question. And it is being ignored.

Modern aircraft are not mechanical machines guided by humans. They are software-governed systems with the crew positioned at the edge of the loop. The automation takes inputs, runs internal logic, and issues commands. It does not explain its reasoning. It does not flag implausible data. It does not ask for help. It continues execution because that is what it was built to do.

This is not a new story. It is HAL again.

In 2001: A Space Odyssey, HAL did not announce his malfunction. He did not report confusion. He followed internal logic that seemed correct to him and concealed the divergence from the crew. They had to infer that something was wrong. That is exactly what we are seeing in these aircraft systems today. They are not failing in the old sense. They are executing flawed logic in sealed environments, hidden from the people meant to oversee them.

The pilot becomes both observer and scapegoat. He is there to reassure the public, fulfill certification requirements, and take the blame when things go wrong. But he is not in control. The software is. And the software, unlike a human, will never say, "That does not make sense" or "I may be wrong."

We already have technology to monitor fuel quality. Installing contamination sensors is straightforward and inexpensive compared to the value of the aircraft. The same goes for bird detection. Basic optical systems, like the ones used in home security cameras, can detect movement and objects around a perimeter. If these tools can be deployed in consumer-grade systems, they can be deployed in aircraft. The barrier is not cost. It is mindset.

The failure here is not one bad input or a single missed condition. It is the broader system design. The aircraft does not cross-check its assumptions. It does not escalate anomalies. It does not allow the pilot to fully intervene. It assumes its logic is sound, even when all evidence outside the code points to trouble.

We need to ask better questions. Not what the pilot entered. But why the system accepted it. Not whether birds were present. But why they were not flagged. Not whether a component failed. But why the aircraft kept going without alert or correction.
Wow, guess you never use cruise control in your car, God forbid an ADAS system. I'm thinking you would never try a Waymo, and might be more comfortable in an abandoned school bus in a remote region in Alaska. As a longtime semiconductor executive, I can say that well-designed automation has saved countless lives in a myriad of applications. Very few corner cases suggest otherwise. The accident avoidance has kicked in on my Audi a few times and I'm thankful for that. Sounds like a 1970 Ford Pinto with a 3-speed manual is your dream machine. Pinto's definitely preceded HAL.
 
Holding the nose up and stalling is not a better option.
Any idea if Boeings have stick pushers, and if so can they be manually overridden or are they inhibited below a certain altitude?
 
Wow, guess you never use cruise control in your car, God forbid an ADAS system. I'm thinking you would never try a Waymo, and might be more comfortable in an abandoned school bus in a remote region in Alaska. As a longtime semiconductor executive, I can say that well-designed automation has saved countless lives in a myriad of applications. Very few corner cases suggest otherwise. The accident avoidance has kicked in on my Audi a few times and I'm thankful for that. Sounds like a 1970 Ford Pinto with a 3-speed manual is your dream machine. Pinto's definitely preceded HAL.

There's no question that automation enhances safety, but there’s real value in a training progression that starts with minimal technology and builds up to a fully automated cockpit. In the U.S., most pilots begin their careers in basic aircraft like Piper Cubs or Cessna 172s—getting tossed around in turbulence, practicing engine-out procedures, and learning from AOPA safety seminars. In contrast, many Asian airlines follow ab-initio programs that move pilots quickly into airline cockpits, often bypassing the grassroots hand-flying experience. Is it a coincidence that nearly all 737 Max accidents occurred outside the United States? If Air India had hit birds on takeoff from LaGuardia and lost both engines, would they have managed a successful ditching in the Hudson? No one can say for sure—but I have my doubts.
 
Sunday they found the CVR and DFDR more than enough time to at least get some information out. Just who has the CVR and DFDR and what are they doing with it? This is not a First Generation Foil Recorder, Today all Boeing current-production models use DFDR systems, which will store 64 12-bit words per second (wps) over a 25-hr period in electronic memory. Also Boeing uplink technology allows real-time remote access to aircraft data parameters via the ACARS digital datalink system, they should have some information on the timeline of the crash.
 
Last edited:
Back
Top