Originally Posted by
MurphyWasRight
I would posit that when someone says "MCAS failed" they are referring to the MCAS system as a whole, "inputs, processing and outputs" not just the processing block.
Saying 'MCAS" did not fail when it's (by bad design) single AoA input failed also could be construed as "twisting words".
I have no idea what advantage that pushing the "MCAS did not fail" meme does for any argument, even the posters who push the idea that the pilots were at fault for not correctly responding to the problem acknowledge that there was a problem. A program can correctly implement a bad algorithm. I would guess that over half of the errors that I have corrected over the years were by some definition "programmed correctly." The basic stuff like a misplaced semicolon or null pointer dereference tend to be caught by automated tools and test suites.
To digress slightly into the basics, fault tolerance and avoidance is one of the differences between professional and amateur programming. (The other big one is testing, which Boeing apparently did not do.) Real professional code tends to be a bit complex, boring, and hard to understand because every step has to deal with error. Maybe you want to display a parameter that is dependent on the lift coefficient -- easy, right? Let Cl = L / (A * .5 * r * V^2), do the subsequent calculation, and draw the arrow. Well, what is the lift coefficient when the plane is parked and the velocity is zero? Oops, divide by zero error! Simple fix, just check for V=zero and make CL=0, except now that your fancy 3D arrow indicating lift is drawn one pixel wide causing a confusing display -- so you then check for CL=0 and hide the arrow. Now test wonders why the arrow disappears at random times briefly in flight because something further down that calculates V returned zero in response to a momentary sensor fluctuation. Now you are in the world of professional programming (and testing.)
That is kiddie stuff, actual code on which people's life depend has to deal with unexpected conditions that are far more subtle. "What sensor positions should MCAS be triggered upon?" is the question that is asked on the first hour (of programming, obviously engineering has done a lot of work before this), "How do we validate that the sensor input is correct?" is the question that is asked in the second hour. "Oh, we just put the plane's nose down and let the pilots deal with it" is not a safe answer, designing a system to fail and expecting humans to compensate does not even qualify as poor engineering, it is just plain hackery. There were many things that should have been done to address the second question, many other parameters were available to do a sanity check. The other AOA sensor is obvious, but what about time? What about the existing rudder position? What about the elevator position? If the pilot is pulling the stick back into a stall for more than say 10 seconds with the stick shaker going then there is probably something going on that you (as HAL) do not understand. If the pilot does this repeatedly over the course of minutes then there is definitely something that you (HAL) do not understand. This is basic design and it is still perplexing to me how that could have gotten though Boeing.
The alleged pilot errors are understandable; maybe smarter people would have responded better but there was nothing that they did to crash the plane -- it is the actions that they allegedly did not take which crashed the plane. I do not understand the engineering errors, although I suppose "a million dollars a plane if pilots have to be retrained in the sim" has something to do with it.