Live data from Hacker News

How the Boeing 737 Max disaster looks to a software Developer

spectrum.ieee.org

171–180 of 306 posts

Re: How the Boeing 737 Max disaster looks to a software Developer

#171

Earlier quoted context omitted.

It was profits. Airbus did effectively same thing with the A320 Neo in 2010, and it became the fastest selling commercial aircraft in history [0]. Boeing clearly was unhappy with that and needed to do something to compete. [0] https://en.wikipedia.org/wiki/Airbus_A320neo_family#Orders_a...

okay let's back up and remember that you can't compete with a plane that crashes all the time. So the reason is clearly not profit, in fact they will lose a big chunk of money from this and that wasn't hard to predict at all.

I think it's a mistake to imply the managers making this decision had our hindsight knowledge. Of course if they knew this would happen they would've taken a different course, for profits and other reasons.

To your larger point, I think as systems get more complex it's much more difficult for management to make accurate risk/benefit decisions. Take the Shuttle Challenger disaster. In Feynman's report, the management estimated something along the lines of a 1-in-100,000 chance of catastrophic failure. I think the actual number was ultimately reported around 1-in 1,000. The exact numbers from memory may be off, but the point is as systems get highly complex, increased interfaces and interactions lead to more failure modes. Understanding them all is really tough

Re: How the Boeing 737 Max disaster looks to a software Developer

#172

Earlier quoted context omitted.

It was profits. Airbus did effectively same thing with the A320 Neo in 2010, and it became the fastest selling commercial aircraft in history [0]. Boeing clearly was unhappy with that and needed to do something to compete. [0] https://en.wikipedia.org/wiki/Airbus_A320neo_family#Orders_a...

okay let's back up and remember that you can't compete with a plane that crashes all the time. So the reason is clearly not profit, in fact they will lose a big chunk of money from this and that wasn't hard to predict at all.

You are assuming long term strategic thinking. I guess that didn’t happen here.

Re: How the Boeing 737 Max disaster looks to a software Developer

#173
post #89

Earlier quoted context omitted.

> As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. Do you use formal methods to prove the correctness of your code? Because that is what Boeing engineers do (I hope).

It's not the logic that's the problem as much as the fact that the systems are meant to work with clean data, and the fact that data could not just be missing, but straight up incorrect was never considered as a valid possibility. This was made worse by the fact that the poorly formulated "solution" was barely communicated to the pilots. I saw somewhere that the plane could be unrecoverable in 40 seconds. You need to…

40 seconds is an eternity to a pilot taking off or landing. Even Air France, taken down by a plugged pitot tube from cruise altitude, was doomed after only two minutes.

Airbus has a lot to answer for on that one: averaging inputs from the pilot's and copilot's game controllers? Game controllers? Turning off the stall warning in deep stall, so that starting to recover sounds it again? Failing to teach pilots what stalls are, what they feel like, and how to prevent and recover from them?

There is more than enough blame to go around for that one.

The Boeing software, like the Airbus's, apparently performed as specified, so there was no problem with execution of the spec. The problem was that it was a bad spec, in too many ways to count.

Re: How the Boeing 737 Max disaster looks to a software Developer

#174

I believe the relative ease — not to mention the lack of tangible cost — of software updates has created a cultural laziness within the software engineering community. -- This --^ As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. I know folks here will deride me for being "inefficient", but in the long term I still maintain from my experience…

Recently, I had someone join my team who was instantly popular and everyone enjoyed this person's personality. I trusted this person more then I should have and during a period when I was unable to give enough attention to their code reviews, they introduced several critical bugs and defects into the production environment. I never figured out if it was ignorance or laziness. But, either way I learned a valuable less…

If the only gatekeeper against shipping bugs is a senior engineer catching bugs in review, then that's possibly a sign that your processes need improvement, rather than the people.

Re: How the Boeing 737 Max disaster looks to a software Developer

#175

This article reads well. Unfortunately, it's filled with fundamental mistakes. > In the old days, when cables connected the pilot’s controls to the flying surfaces, you had to pull up, hard, if the airplane was trimmed to descend. You had to push, hard, if the airplane was trimmed to ascend. With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.” Whoo…

> There isn't a visual indication for AOA

Private pilot here. What you say is, strictly speaking, true but that doesn't mean that you can't tell an awful lot about what's going on by looking out the window, and, more importantly, at the other flight instruments. If your attitude, airspeed, and rate of climb are all looking normal, then if the AOA says you're stalling it's almost certainly wrong. And it it says that your AOA is 70 degrees (which the Ethiopian airlines AOA sensor did) then it is definitely wrong.

MCAS was designed to blindly trust a single AOA sensor, which was known to be prone to failures. To call that inexcusable would be quite the understatement.

Re: How the Boeing 737 Max disaster looks to a software Developer

#177

Earlier quoted context omitted.

> Regarding #6...Boeing charged $80k to unlock the software feature to gather data from more than 1 angle of attack sensor. 80k for a _light_ in the panel, not to have MCAS take the two sensors into account - which it couldn't do anyway. With two sensors, how do you know which one is right and which one is faulty?

Well you can’t get quorum but you can certainly shut off when you detect a conflict.

you can't shut MCAS off AND also NOT train the pilots on the system and MAX flight characteristics. Conflicting system goals.

Re: How the Boeing 737 Max disaster looks to a software Developer

#178

This article reads well. Unfortunately, it's filled with fundamental mistakes. > In the old days, when cables connected the pilot’s controls to the flying surfaces, you had to pull up, hard, if the airplane was trimmed to descend. You had to push, hard, if the airplane was trimmed to ascend. With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.” Whoo…

> No, you can't. There isn't a visual indication for AOA - the author is confusing this with pitch. You can have a 45 degree AOA while still having the nose of the plane pointed at the horizon. (The author mentions using the artificial horizon for this purpose, too) If you could read AOA from sensors that didn't require being exposed to the airflow, planes would use them.

I think you may have missed the context of that part of the article. The author was talking about diagnosing a possible AoA sensor malfunction.

Changes in AoA should generally correlate with changes in attitude according to the artificial horizon and with changes to what you see looking out the window. So if you have an AoA sensor that claims you are at, say, a 70 degree AoA for several minutes (like the one in the Lion Air crash did), but you can see out the window that the plane alternating between pitching up and down relative to the ground, you've probably got a busted AoA sensor.

Re: How the Boeing 737 Max disaster looks to a software Developer

#179
post #74

This is a very good analysis, but fatally incomplete. One really essential reason those planes crashed was that each time the MCAS triggered, it acted like it was the first time. If it added 1 degree of trim last time, it adds a second this time, a third next time, up to the five degrees that runs the trim all the way to the stops. A second reason is that, under the design still on file at the FAA, it could only add…

Stab trim cutout is not the only way to disable MCAS. Extending the flaps any amount also disables MCAS.

Turning on autopilot also disables MCAS, though this isn’t entirely effective since spurious AoA readings may quickly disable the autopilot again.

Re: How the Boeing 737 Max disaster looks to a software Developer

#180

Could someone please ELI5 what exactly went wrong that caused the crash? I read the article but I still don't understand if the crash was caused by (a) The MCAS doing something it wasn't programmed to do (by specification) (b) MCAS was working as expected, but the expectations/assumptions were wrong (excluding pilot mistakes). (c) MCAS worked as designed, and the design was correct IF the pilots behaved like Boeing e…

It is none of the above.

The MCAS worked as specified. The specification was criminally stupid. It violated at least two bedrock principles of avionics design. It would not have been approved at all if Boeing had not bent over backwards to draw attention away from it, for fear that pilots might have needed extra training, or the plane need more exanination.

Post reply on HN