3 ms·

This comment is glib and misinformed. Firstly, no the software did not do exactly as it's supposed to. It crashed the plane by rendering it unflyable. It's not

by dTal 7y ago

This comment is glib and misinformed. Firstly, no the software did not do exactly as it's supposed to. It crashed the plane by rendering it unflyable. It's not supposed to do that. And your description of the MCAS specification is vastly over-simplified - it is not an autopilot and its job is to gradually change the behaviour of the plane in different flight modes (which it must detect), not to directly fly the plane as you suggest (and even two AOA sensors would be insufficient for the type of functionality you describe). The behaviour of the MCAS is absolutely in question, in particular the way it kept "re-adding" the correction, with cumulative effect, ending up fully pitched down. Secondly, if by "the doomed Air France incident" you mean AF447, your description of it is flat-out wrong. The pilot, not software, stalled and crashed the plane by manually holding the stick back for 15 minutes. The pitot tubes briefly iced over (they didn't "fail") which is not an uncommon occurrence, and the only consequence of this was that the software guardrails that would have prevented the pilot from crashing the plane were removed. All instrumentation systems were fully operational at the time of the crash.

ganeshkrishnan 7y ago
It kept re-adding because the flap of the aoa sensor was stuck in the "aircraft is pitching up" position. Boeing management did not add a second sensor to some planes and also pilots were not aware of how to switch off mcas. If you worked in large scale project you would know that most devs are assigned components to work on and usually have no idea what other components are or how they will interact.
- gotdevops 7y ago
  This is where testing comes in and from the fact packet it appears that the testing was also outsourced to another Indian firm?
sokoloff 7y ago
Agree with everything you wrote, with the possible exception of referring to the stick-holder in the AF447 crash as a "pilot".
mannykannot 7y ago
> Firstly, no the software did not do exactly as it's supposed to. It crashed the plane by rendering it unflyable. It's not supposed to do that. This belongs in the true-but-trite category. The decision to depend on a single, unverified AofA input was not a programming error, and neither was the increase in power in the second version. These decisions were made by Boeing, and endorsed by the FAA (to the extent that Boeing informed the FAA of them.)

by dTal 7y ago

ganeshkrishnan 7y ago

It kept re-adding because the flap of the aoa sensor was stuck in the "aircraft is pitching up" position. Boeing management did not add a second sensor to some planes and also pilots were not aware of how to switch off mcas. If you worked in large scale project you would know that most devs are assigned components to work on and usually have no idea what other components are or how they will interact.

gotdevops 7y ago
This is where testing comes in and from the fact packet it appears that the testing was also outsourced to another Indian firm?

sokoloff 7y ago

Agree with everything you wrote, with the possible exception of referring to the stick-holder in the AF447 crash as a "pilot".

mannykannot 7y ago

> Firstly, no the software did not do exactly as it's supposed to. It crashed the plane by rendering it unflyable. It's not supposed to do that. This belongs in the true-but-trite category. The decision to depend on a single, unverified AofA input was not a programming error, and neither was the increase in power in the second version. These decisions were made by Boeing, and endorsed by the FAA (to the extent that Boeing informed the FAA of them.)