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…
> 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).
How the Boeing 737 Max disaster looks to a software Developer
131–140 of 306 posts
Re: How the Boeing 737 Max disaster looks to a software Developer
#132Sorry, I don't believe that our perspective on this is especially valuable or insightful. Everyone with an average IQ can explain in 5 sentences what went wrong with this plane. Yes new engines didn't fit the plane, fixed with software, well done. But why? It's not profits. Boeing has been for profit from the start. It's something more. We are getting bad at doing hard things. Here in Germany we can't seem to finish…
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...
Re: How the Boeing 737 Max disaster looks to a software Developer
#133This 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…
Architecting solutions is hard. In this case, you need knowledge of motors, flight controls, sensor fusion, etc. It’s easy to find edge cases when they present themself (tragically here). But most electrical-mechanical-software assemblies have similar issues.
In the Lion Air case, painfully inadequate maintenance contributed.
Re: How the Boeing 737 Max disaster looks to a software Developer
#134Sorry, I don't believe that our perspective on this is especially valuable or insightful. Everyone with an average IQ can explain in 5 sentences what went wrong with this plane. Yes new engines didn't fit the plane, fixed with software, well done. But why? It's not profits. Boeing has been for profit from the start. It's something more. We are getting bad at doing hard things. Here in Germany we can't seem to finish…
From my experience I disagree. It's not that we can't do hard things, it's that there's frequently more profitable approaches than taking difficult challenges. This is becoming systemic across our culture as ideas drawn from capitalism begin invading all aspects of our lives (including how we interact in personal relationships), not just business. Pushing quicker time to market and cost saving solutions to the brink…
Re: How the Boeing 737 Max disaster looks to a software Developer
#135Even in the case of MCAS, the side effect of stabilizer nose down trim is to make elevator backpressure on the yoke more forceful. It is not a simulation. That's presumably its design goal is, and why it was so simple without any safeguards for overcorrection or a failed sensor.
I also don't like the suggestion the plane is longitudinally unstable due to the engines. That is simply not consistent with FAR 25.173 (a). A central feature of this stability requirement is the plane will recover from a stall merely be releasing back pressure. Not all airplanes do this because not all airplanes are designed that way nor are they required to, but FAR 23 (normal category) and FAR 25 (air transport category) aircraft are required to exhibit this kind of stability as well as lateral static stability. Yet people keep saying the airplane isn't stable and MCAS makes it stable.
You can't have a damn switch that instantly makes the airplane unairworthy, with a damn airworthiness directive that tells pilots to solve one problem (runaway trim, or MCAS upset) by making the airplane unairworthy. If MCAS is there to make the plane airworthy, turning off autotrim makes the plane unairworthy. That's why I don't buy any claim that MCAS is there to make the plane airworthy, until there's a preponderance of evidence from reputable sources that includes an explanation how in the world such a thing is not a violation of FAR 25.
The sensible explanation is it's a stick force moderator, in order to ensure the FAA didn't require a type certification for this make/model derivative. A plane with a type certificate triggers a requirement in FAR 61 for the pilot to obtain a type rating to fly planes with that particular type certification. I do find the suggestion of conspiracy plausible, among Boeing, the FAA, and airlines, to avoid 737 MAX type certification different from prior 737s. Consistent with that, is this week's ass covering by an FAA board saying they see no reason for additional 737 simulator training for pilots to fly 737 MAX, i.e. paving the way for a software update only solution for the current problem.
Re: How the Boeing 737 Max disaster looks to a software Developer
#136So, 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…
Re: How the Boeing 737 Max disaster looks to a software Developer
#137Earlier quoted context omitted.
[citation needed] idk man, my code is pretty damn clean
Code cleanliness has no correlation with lack of bugs. Also, 1) your sample size is pretty small, and 2) what looks clean to you might very well be despicable to someone else.
Re: How the Boeing 737 Max disaster looks to a software Developer
#138One 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:…
Re: How the Boeing 737 Max disaster looks to a software Developer
#139This 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…
If you mean AoA sensors, AFAIK, there was absolutely no redundancy at all the way MCAS was designed. Exactly one sensor was ever used for MCAS. And last time I've read the Boeing's reported coming software changes, they wanted to keep it so, but just to add the notification to the pilot when the sensors disagree.
Re: How the Boeing 737 Max disaster looks to a software Developer
#140I'm unclear on how moving the engine up causes application of power to cause the attitude to tend to go nose up. I would expect the opposite to happen. I think something else must have changed such as the center line of the engine relative to the center line of the plane. Or did moving the engine forward at the same time cause this effect?