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

221–230 of 306 posts

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

#221

Post by ReGenGen »

bm98 wrote: post #187
ReGenGen wrote: post #177

Earlier quoted context omitted.

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

Yes. Not checking for errors is the feature of the MCAT "solution" which hides the system from pilot's training AND involvement with other 727 system/team engineers. A bureaucratic solution to a marketing problem. I wonder how many programers they had to go though to find it.

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

#222

Post by mncharity »

Xcelerate wrote: post #204

Just a meta-comment, but I've noticed that for every single article posted about the 737 Max on HN, the top comments all tend to say that something in the linked article is dramatically wrong. I'm not sure what this means, but I find it interesting.

> I'm not sure what this means

Medicine is struggling to adopt modern best practices for quality processes from other industries, including aviation. Journalism hasn't yet even noticed they're needed?

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

#223

Post by tonyarkles »

linuxftw wrote: post #184
_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…

Not necessarily go weld it together, but they should be going and spending time with the welders. Ben Rich’s memoirs from the Skunkworks talks about this a fair bit. Around there, having the engineers close to the fabricators was one of their central tenets, and the engineers did occasionally roll up their sleeves in the shop.

With the SR71, at one point when they were fighting with a nasty engine problem, Ben himself was going to go up on a flight so that the pilot could show him what was happening.

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

#224

Post by ReGenGen »

Cacti wrote: post #183
ncmncm wrote: post #156

Earlier quoted context omitted.

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.

The 80K upgrade was simply a AOA disagree warning light and has zero affect on MCAS behavior. There is no evidence that airlines were told about MCAS until the Lion Air accident.

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

#225

Post by cjbprime »

theclaw wrote: post #108
NoNameHaveI wrote: post #68

So, the linked article is an updated version of an earlier article in the EE times. In the comments section, a reader (ie) Frankly, I am astonished that a single point of failure (AOA) could make it through a FMEA (Failure Mode Effect Analysis). For those who are unfamiliar, a FMEA is (basically) looking at each part of a system and saying "What happens if it breaks?". Having worked in commercial vehicle software dev…

I don't work in this field. Do you have to publish the findings from this analysis? Is it possible that no such analysis was done because the MCAS system had to be kept quiet?

Yes, you do, as part of certification. Boeing misrepresented the degree of control MCAS has and was able to avoid making it a redundant system as a result. Layperson's description here:

https://www.seattletimes.com/business/boeing-aerospace/faile...

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

#226

Post by cjbprime »

cjbprime wrote: post #138
amluto wrote: post #81

One thing I really don’t get about MCAS: even disregarding all its bugs, it seems like a really awful style of envelope protection. I’m neither a pilot not an expert, but I can imagine several more reasonable strategies when the pilot pulls up too hard: ignore the problematic yoke input, offset the elevators a bit, or apply more force to the yoke. Moving the stabilizer out of trim seems totally wrong. As an analogy:…

Elevator probably isn't powerful enough to avoid the impending stall once you get there.

... and the 737 MAX control surfaces are mechanical. I don't think there is any ability to ignore yoke input! It's connected to the elevator with a cable. This isn't an Airbus-style fly by wire aircraft where input signals are being interpreted as suggestions for actions for a computer to take.

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

#227

Post by cjbprime »

Xcelerate wrote: post #204

Just a meta-comment, but I've noticed that for every single article posted about the 737 Max on HN, the top comments all tend to say that something in the linked article is dramatically wrong. I'm not sure what this means, but I find it interesting.

I think the takeaway is that it's not usually the case that something this technical makes it to world news. Everyone wants to have an opinion, but even in this article's case of someone who's both a pilot and programmer, they apparently know next to nothing about how a 737 MAX is controlled (mechanically, not with forces artificially applied to inputs) because they fly a Cessna. And there aren't that many 737 pilots with the time or ability to write something frank about this without perhaps getting in trouble with their employers.

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

#228

Post by schraeds »

ncmncm wrote: post #201
Cacti wrote: post #183

Earlier quoted context omitted.

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.

There is more than enough blame to go around. E.g., Congress, for the last N decades, failing to fund FAA at levels clearly needed.

Beyond funding is the issue of regulatory capture. The FAA is too cozy with the plane manufacturers, allowing them to help test,certify,document their own products.

The biggest overarching change I would like to see is the abandonment of allowing manufacturers to extend the type rating of airframes indefinitely and designing to avoid costly recertification and training vs a true focus on safety and innovation.

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

#229

Post by cyphar »

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.

The article is making the point that the MAX is inherently unstable because of the larger engines causing the "pitch up" problem with an increasing angle-of-attack:

> Pitch changes with increasing angle of attack, however, are quite another thing. An airplane approaching an aerodynamic stall cannot, under any circumstances, have a tendency to go further into the stall. This is called “dynamic instability,” and the only airplanes that exhibit that characteristic—fighter jets—are also fitted with ejection seats.

So arguably the existence of MCAS in the first place indicates that the aircraft design is dynamically unstable (otherwise MCAS wouldn't have been necessary).

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

#230

Post by Gibbon1 »

amluto wrote: post #109
AWildC182 wrote: post #90

Earlier quoted context omitted.

tl;dr the first thing you learn doing control systems is NEVER use += 1; when it relates to an electro-mechanical device. I learned this a long time ago by putting a robot through a door-frame at max speed. Edit: To add to this in a way that might actually make it useful to someone, motor outputs should almost always be a continuous function of something rather than their own internal state. MCAS should have been cod…

PID controls do exactly what you are objecting to.

All practical PID controls have anti-windup features.
Post reply on HN