Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the Boeing 737 Max disaster looks to a software Developer

spectrum.ieee.org

Post reply on HN
Print view View original

181–190 of 306 posts

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

#181

Post by ncmncm »

outworlder wrote: post #166

> When MCAS senses that the angle of attack is too high, it commands the aircraft’s trim system (the system that makes the plane go up or down) to lower the nose. It also does something else: It pushes the pilot’s control columns (the things the pilots pull or push on to raise or lower the aircraft’s nose) downward. Wait a minute. Since when does MCAS include a stick pusher? I haven't flown anything outside simulator…

This is an error in the article. 737-MAX is not a fly-by-wire system. The forces felt by pilots are derived directly from aerodynamic forces on the control surfaces.

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

#182

Post by ReGenGen »

1v1id wrote: post #160
m463 wrote: post #157

Earlier quoted context omitted.

I don't know, I think the 3 points in the article make it glaringly obvious that the root cause is NOT engineering. The decisions made clearly ignored engineering and historical precedent at every turn. It's sad because Boeing has had some wonderful engineers, and Boeing aircraft have traditionally allowed the pilots to have the final say.

> So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail .... Big strike No. 3. The article definitely does partially blame engineering.

We don't know the MAX is inherently unstable. That's still conjecture at this point. MCAS may have altered fight characteristics to match older 737 to avoid additional pilot training. If the MAX is inherently unstable, then this scandal is much bigger and far reaching.

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

#183

Post by Cacti »

ncmncm wrote: post #156
kakwa_ wrote: post #141

Earlier quoted context omitted.

This analysis is completely right, but in my opinion, focuses too much on the technical aspects. Is MCAS a hack? yes. Is it fixable? yes. Will the 737 MAX continue to fly for two to three decades after all the items above have been addressed? yes. But from an engineering perspective, putting an additional system to "fix" another system feels always a bit weird. Sometimes it's not avoidable (ex: cooling), but when it…

Ultimately it was not a technical failure: the failure was in allowing the plane to be sold with such a thoroughly bad design. Thus, a management and regulatory failure. Regulatory, because FAA signed off on it, obviously without applying any of the process that would have prevented it. Management, because the cost of this debacle will be many, many times what they saved by trying to skate by with a faulty design.

The airlines knew what they were doing when they didn’t pay for the “upgrade” and they doubly knew when they didn’t pay for it after the first crash. Airline management is just as culpable in this debacle.

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

#184

Post by linuxftw »

_bxg1 wrote: post #63

"Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not." I wonder if, once basic programming become…

That would be an overworked engineer IMO. Should the engineer that designs the air frame go weld it together?

One issue, if the system resetting and no honoring the maximum authority to do so would not have been caught by a half-software engineer. That's definitely something the software team should have caught if there was any amount of reasonable QA involved.

It's clear to me Boeing doesn't employ capable people on the software side.

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

#185

Post by linuxftw »

adreamingsoul wrote: post #92

Something that stood out to me in this article was the author's opinion of how software developers are removed from the subject matter. From my experience I tend to agree but I hope we can change this. For context, I'm a software engineer and designer with a UX focus. As part of my process to design a system, interface, feature, or fix I first immerse myself into the world of the person who is using the software. Wha…

We're agile now. We don't have a solid view of the problems we need to tackle, we're just given a little user story that says "Plane noses down with these inputs" and we code it up, send it over the wall.

The larger the org, the less likely the actual engineers that will design the system are invited to the planning and arch meetings. So when stupid ideas come up in those meetings, there's no one to say "no, that's dumb" because management only knows how to say yes to their boss.

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

#186

Post by Cacti »

kakwa_ wrote: post #141
ncmncm wrote: 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…

This analysis is completely right, but in my opinion, focuses too much on the technical aspects. Is MCAS a hack? yes. Is it fixable? yes. Will the 737 MAX continue to fly for two to three decades after all the items above have been addressed? yes. But from an engineering perspective, putting an additional system to "fix" another system feels always a bit weird. Sometimes it's not avoidable (ex: cooling), but when it…

There are thousands of “hacks” like this in every modern airliner. That’s how complicated problems are solved, you come up with a basic idea, and you iterate on it thousands of times until you squash all the edges cases.

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

#187

Post by bm98 »

ReGenGen wrote: post #177
kortilla wrote: post #165

Earlier quoted context omitted.

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.

To me this is the crux of the issue. And it's non uncommon in software development:

The developer fails to check for an error condition or raise an exception because doing so would add too much complexity to the system. So instead it is assumed (or hoped) that it simply can't or won't happen. Problem solved...

(Edit: Or that the user will just have to reboot if it happens.)

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

#188

Post by DuskStar »

lisper wrote: post #175
DuskStar wrote: post #146

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 y…

>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.

Agreed - you can certainly sanity check the AOA data with other data sources. Unfortunately, I'm not sure that will always let you pinpoint AOA as the cause - imagine some nice dirt-loving wasps have built nests in all of your pitot tubes, or they've iced over, and now those values are locked in place. So your IAS and altimeter could both be reading normal despite the fact that you're in a dangerously fast descent at a high angle of attack. (A radar altimeter wouldn't have this issue, of course) Things like this have happened before. Of course, this would require your engines to have failed at approximately the same time as your airspeed and altitude data, but I can imagine failure modes in which that would be the case. (A particularly stupid autopilot attempting to reduce speed but not seeing the speed decrease, repeat in loop)

> And it it says that your AOA is 70 degrees (which the Ethiopian airlines AOA sensor did) then it is definitely wrong.

Or it's accurate and you're about to die unless you fix it. Air France Flight 447 comes to mind. (though 70 degrees is probably past the point of being recoverable)

> 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.

No disagreements here.

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

#189

Post by [deleted] »

ReGenGen wrote: post #182
1v1id wrote: post #160

Earlier quoted context omitted.

> So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail .... Big strike No. 3. The article definitely does partially blame engineering.

We don't know the MAX is inherently unstable. That's still conjecture at this point. MCAS may have altered fight characteristics to match older 737 to avoid additional pilot training. If the MAX is inherently unstable, then this scandal is much bigger and far reaching.

[deleted]

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

#190

Post by throw7 »

kakwa_ wrote: post #141
ncmncm wrote: 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…

This analysis is completely right, but in my opinion, focuses too much on the technical aspects. Is MCAS a hack? yes. Is it fixable? yes. Will the 737 MAX continue to fly for two to three decades after all the items above have been addressed? yes. But from an engineering perspective, putting an additional system to "fix" another system feels always a bit weird. Sometimes it's not avoidable (ex: cooling), but when it…

I'm confused with your response. So nothing to see here? Nothing to learn and change? You seem to say we should accept design flaws (like we did with the MD11?)... correct? Or?
Post reply on HN