3 ms·

Are you making the claim that MCAS made the plane behave similar to previously certified designs? Maybe that was the intent, but the execution seemed very much

by bumby 4y ago

Are you making the claim that MCAS made the plane behave similar to previously certified designs? Maybe that was the intent, but the execution seemed very much the opposite. That's largely the point: the software workarounds don't behave like a hardware-engineered mitigation.

WalterBright 4y ago
The MCAS system is still on the 737MAX. > the software workarounds don't behave like a hardware-engineered mitigation You probably should never get on an Airbus, because they won't fly without computers.
- bumby 4y ago
  I'm aware that MCAS is still in use. You may be conflating what I'm saying. I'm not making a claim that software is inherently dangerous. I'm making the claim that software as a workaround to sound risk mitigation is dangerous, especially when it's a workaround for a hardware problem because of the interaction effects. It's pretty clear from the hazard analysis and subsequent decisions that Boeing didn't understand and mitigate the MCAS risk effectively. And, yes, I'm aware of the two philosophical camps regarding ultimate authority in command (pilot vs. software). That doesn't negate my point. Software, in either case, shouldn't be a workaround solely because it's easier to implement than a hardware change. Using it as an engineered mitigation is ok, but you have to actually implement the mitigations properly. For example, the hazard analysis listed MCAS as "critical". With that classification, it required redundant sensors, yet Boeing didn't make that the default and opted instead to sell it as an option. (Never mind the fact that the classification should have been higher, they didn't even follow through with their own processes based on the mis-classification).
  - WalterBright 4y ago
    > I'm making the claim that software as a workaround to sound risk mitigation is dangerous Mechanical systems aren't inherently better or more resistant to hidden flaws. Remember it was a failure of the mechanical AOA sensor that initiated the MCAS failure. > Software, in either case, shouldn't be a workaround solely because it's easier to implement than a hardware change. Software runs our world now. Mechanical computers on airplanes were around for decades before software, and they were hardly free of fault and problems.
    - bumby 4y ago
      >Mechanical systems aren't inherently better or more resistant to hidden flaws. Besides the fact that failure modes of mechanical systems are generally more understood than software, you're again conflating my point and having an entirely different conversation. This isn't about some "mechanical vs. software" dichotomy. I literally said there is nothing about software that makes it inherently dangerous and that using software as an engineered mitigation is fine if the mitigations are implemented properly. What isn't fine is all the process and design gaps that occurred. Things like using software as a mitigation, not because it was the best alternative, but simply because it was cheaper/faster. Things like not following your own hazard analysis when it comes to mitigation. Or not characterizing the risk accurately or the failure modes because you didn't understand the system interactions. >Remember it was a failure of the mechanical AOA sensor that initiated the MCAS failure. This is exactly why, had they followed their own procedures and hazard analysis, redundant sensors would have been a default. A "critical" item (like MCAS in the hazard analysis) is supposed to get redundant input as a default. My post isn't about mechanical vs. software. It's about the the allure of using software as a workaround that leads to process gaps and bad design philosophy. Like removing sensors because of a supplier/cost issue and assuming "we'll fix it with software" instead of doing the hard work to understand, characterize, and mitigate the risk effectively.
      - WalterBright 4y ago
        > Like removing sensors because of a supplier/cost issue There were more than one AOA sensors. Not hooking the other one up to the MCAS system could hardly be a cost issue. Nor is it an issue of software vs hardware. It being implemented in software had nothing to do with MCAS's problems. The software was not buggy, nor was it a workaround. What was wrong was the specification of how the software should work.
        bumby 4y ago
        I was bringing the context back to the article of this thread, not talking about Boeing there. Sorry if it lead to confusion. You can note that I acknowledged there were multiple AOA sensors in other replies. Further, they were already “hooked up” to MCAS, but Boeing made this safety critical redundancy requirement an option within the software. That’s bad practice, full stop. I still maintain that the software was 100% a mitigation to a hardware change and I think there’s plenty of other evidence supporting that. E.g., has they not updated their engines, would MCAS be installed? If the answer is no, then it was a mitigation to a risk introduced by a hardware change. I’ll say it one more time just to be clear: I’m not saying the concept was bad. I’m saying their design philosophy and implementation was bad. They could have used software mitigation within the right process/philosophical framework just fine. What doesn’t work is using software as an “easy” risk mitigation strategy when you don’t understand the risk or the processes necessary to fully mitigate that risk. The problem arises because software is a seductive fix because it’s relatively easy and cheap on its surface, but if your design philosophy and processes are equipped to implement it effectively, that “easy” fix is rolling the dice.
- diebeforei485 4y ago
  Neither will the Boeing 777 or 787!
WalterBright 4y ago
The 757 was also engineered to behave the same way as the 767, to reduce costs in pilot training and improve safety. The 757 has a stellar safety record.
- bumby 4y ago
  It’s getting tiresome to say this, but you completely bypassed my point to talk about something different. MCAS did not make the airframe operate the same in practice, especially from a human factors perspective. It confused pilots about how it was reacting. The plane acted very differently from previously certified designs and that was a major factor in the accidents.
  - WalterBright 4y ago
    This is just not true. What confused the pilots and caused the accidents was the MCAS was looking at only one faulty AOA sensor.
    - bumby 4y ago
      Sorry, but there are multiple reports that point to pilot confusion. What you're displaying is exactly what Boeing leadership showed: an oversimplification of the problem, leading to poor understanding of the risk and necessary mitigations. MCAS had a built in delay; it wasn't a continuous command. It would push the nose down and periodically disengage and allow pilots to bring the nose back up. This type of intermittent feedback is difficult to resolve in real-time, especially for an untrained pilot under stress. But to the larger point, what you're relating is actually bolstering my point. The design philosophy was poor; they didn't fully understand the interaction effects of the system (to include software, hardware, people, and the environment). In that simplified mental model, they thought software was an easy fix to their problem and they didn't follow through with the necessary risk mitigation. This includes having a redundant AOA sensor feed into MCAS (which their hazard analysis already required), characterizing MCAS properly as having the potential for causing a 'catastrophic' mishap, training for their pilots (which they didn't think was necessary because it was the 'same' airframe, despite different handling characteristics), and an appropriate understanding the human factors that govern its use. If we erroneously simplify our mental model and claim it's "just software" and an "easy fix," we miss all of that.

by bumby 4y ago

WalterBright 4y ago

The MCAS system is still on the 737MAX. > the software workarounds don't behave like a hardware-engineered mitigation You probably should never get on an Airbus, because they won't fly without computers.

bumby 4y ago
I'm aware that MCAS is still in use. You may be conflating what I'm saying. I'm not making a claim that software is inherently dangerous. I'm making the claim that software as a workaround to sound risk mitigation is dangerous, especially when it's a workaround for a hardware problem because of the interaction effects. It's pretty clear from the hazard analysis and subsequent decisions that Boeing didn't understand and mitigate the MCAS risk effectively. And, yes, I'm aware of the two philosophical camps regarding ultimate authority in command (pilot vs. software). That doesn't negate my point. Software, in either case, shouldn't be a workaround solely because it's easier to implement than a hardware change. Using it as an engineered mitigation is ok, but you have to actually implement the mitigations properly. For example, the hazard analysis listed MCAS as "critical". With that classification, it required redundant sensors, yet Boeing didn't make that the default and opted instead to sell it as an option. (Never mind the fact that the classification should have been higher, they didn't even follow through with their own processes based on the mis-classification).
- WalterBright 4y ago
  > I'm making the claim that software as a workaround to sound risk mitigation is dangerous Mechanical systems aren't inherently better or more resistant to hidden flaws. Remember it was a failure of the mechanical AOA sensor that initiated the MCAS failure. > Software, in either case, shouldn't be a workaround solely because it's easier to implement than a hardware change. Software runs our world now. Mechanical computers on airplanes were around for decades before software, and they were hardly free of fault and problems.
  - bumby 4y ago
    >Mechanical systems aren't inherently better or more resistant to hidden flaws. Besides the fact that failure modes of mechanical systems are generally more understood than software, you're again conflating my point and having an entirely different conversation. This isn't about some "mechanical vs. software" dichotomy. I literally said there is nothing about software that makes it inherently dangerous and that using software as an engineered mitigation is fine if the mitigations are implemented properly. What isn't fine is all the process and design gaps that occurred. Things like using software as a mitigation, not because it was the best alternative, but simply because it was cheaper/faster. Things like not following your own hazard analysis when it comes to mitigation. Or not characterizing the risk accurately or the failure modes because you didn't understand the system interactions. >Remember it was a failure of the mechanical AOA sensor that initiated the MCAS failure. This is exactly why, had they followed their own procedures and hazard analysis, redundant sensors would have been a default. A "critical" item (like MCAS in the hazard analysis) is supposed to get redundant input as a default. My post isn't about mechanical vs. software. It's about the the allure of using software as a workaround that leads to process gaps and bad design philosophy. Like removing sensors because of a supplier/cost issue and assuming "we'll fix it with software" instead of doing the hard work to understand, characterize, and mitigate the risk effectively.
    - WalterBright 4y ago
      > Like removing sensors because of a supplier/cost issue There were more than one AOA sensors. Not hooking the other one up to the MCAS system could hardly be a cost issue. Nor is it an issue of software vs hardware. It being implemented in software had nothing to do with MCAS's problems. The software was not buggy, nor was it a workaround. What was wrong was the specification of how the software should work.
      - bumby 4y ago
        I was bringing the context back to the article of this thread, not talking about Boeing there. Sorry if it lead to confusion. You can note that I acknowledged there were multiple AOA sensors in other replies. Further, they were already “hooked up” to MCAS, but Boeing made this safety critical redundancy requirement an option within the software. That’s bad practice, full stop. I still maintain that the software was 100% a mitigation to a hardware change and I think there’s plenty of other evidence supporting that. E.g., has they not updated their engines, would MCAS be installed? If the answer is no, then it was a mitigation to a risk introduced by a hardware change. I’ll say it one more time just to be clear: I’m not saying the concept was bad. I’m saying their design philosophy and implementation was bad. They could have used software mitigation within the right process/philosophical framework just fine. What doesn’t work is using software as an “easy” risk mitigation strategy when you don’t understand the risk or the processes necessary to fully mitigate that risk. The problem arises because software is a seductive fix because it’s relatively easy and cheap on its surface, but if your design philosophy and processes are equipped to implement it effectively, that “easy” fix is rolling the dice.
diebeforei485 4y ago
Neither will the Boeing 777 or 787!

WalterBright 4y ago

The 757 was also engineered to behave the same way as the 767, to reduce costs in pilot training and improve safety. The 757 has a stellar safety record.

bumby 4y ago
It’s getting tiresome to say this, but you completely bypassed my point to talk about something different. MCAS did not make the airframe operate the same in practice, especially from a human factors perspective. It confused pilots about how it was reacting. The plane acted very differently from previously certified designs and that was a major factor in the accidents.
- WalterBright 4y ago
  This is just not true. What confused the pilots and caused the accidents was the MCAS was looking at only one faulty AOA sensor.
  - bumby 4y ago
    Sorry, but there are multiple reports that point to pilot confusion. What you're displaying is exactly what Boeing leadership showed: an oversimplification of the problem, leading to poor understanding of the risk and necessary mitigations. MCAS had a built in delay; it wasn't a continuous command. It would push the nose down and periodically disengage and allow pilots to bring the nose back up. This type of intermittent feedback is difficult to resolve in real-time, especially for an untrained pilot under stress. But to the larger point, what you're relating is actually bolstering my point. The design philosophy was poor; they didn't fully understand the interaction effects of the system (to include software, hardware, people, and the environment). In that simplified mental model, they thought software was an easy fix to their problem and they didn't follow through with the necessary risk mitigation. This includes having a redundant AOA sensor feed into MCAS (which their hazard analysis already required), characterizing MCAS properly as having the potential for causing a 'catastrophic' mishap, training for their pilots (which they didn't think was necessary because it was the 'same' airframe, despite different handling characteristics), and an appropriate understanding the human factors that govern its use. If we erroneously simplify our mental model and claim it's "just software" and an "easy fix," we miss all of that.