Home About Archives Search Feed


How the Boeing 737 Max Disaster Looks to a Software Developer - IEEE Spectrum

🔒 spectrum.ieee.org

This is a fantastic read on the Boeing 737 Max situation.

I’ll say it again: In the 737 Max, the engine nacelles themselves can, at high angles of attack, work as a wing and produce lift. And the lift they produce is well ahead of the wing’s center of lift, meaning the nacelles will cause the 737 Max at a high angle of attack to go to a higher angle of attack. This is aerodynamic malpractice of the worst kind.

It is very interesting to hear from someone who knows this space what the 737 Max was trying to achieve in it’s design.

In a pinch, a human pilot could just look out the windshield to confirm visually and directly that, no, the aircraft is not pitched up dangerously. That’s the ultimate check and should go directly to the pilot’s ultimate sovereignty. Unfortunately, the current implementation of MCAS denies that sovereignty. It denies the pilots the ability to respond to what’s before their own eyes.

So Boeing essentially had unworkable hardware and said Hey, we’ll fix it in the software!”. But then the software doesn’t let the pilot work the way all other planes let them work.

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 (angle-of-attack indicators) and did not appear to include even rudimentary provisions to cross-check the outputs of the angle-of-attack sensor against other sensors, or even the other angle-of-attack sensor. Big strike No. 3.

Anyone writing software that can mean life and death should make sure to learn from this situation.

Posted on April 22, 2019








← Next post    ·    Previous post →