3 ms·

Every MAX already had two AoA vanes, MCAS just wasn't hooked up to both in software.

gpm 8y ago
Yes, two. The standard for critical systems is 3. Two isn't good for much, if they give different readings you don't know which to believe. Either that kills you like in real life, or it kills you because of the stall problem it was invented to fix. Edit: And yes, you could do something more sensible than what they did, but that doesn't "fix" the issue, it merely mitigates it to some extent.
- cjbprime 8y ago
  This seems a little overstated. As I understand it the plane isn't actually aerodynamically unstable and isn't going to stall itself without the pilot pulling into it. The main issue seems to have been software to me. I'm not saying they should avoid using a third sensor. It sounds like a good idea. But I'm not sure it's required for airworthiness, after you move from one to two.
  - gpm 8y ago
    Maybe a little overstated to avoid getting into subtleties, but I stand behind the point. Yes, it seems the plane is probably mostly flyable if you kill the MCAS system (which is the only reasonable step to take in a two sensor system when they disagree). But - The plane no longer handles the same, you definitely need to be alerting the pilots, and put this change into manuals and training. This isn't just a thing you should silently do in software and expect not to kill people. - The plane no longer meets the FAA rules for the class under these conditions. Maybe that's acceptable because it is an error state, but I think that meets the definition of a "workaround" and not a "fix". - At least one of these planes took off when one of the sensors was known to be bad from the previous flight (as I understand it). I can only assume that they don't do that when something critical to the handling of the plane is broken. This is another process bug that needs to be fixed before a software workaround might be acceptable. I don't see any way to interpret this other than "the hardware didn't work as we thought it did", which leads me to say "hardware bug", even if you can maybe work around it with process, training, and software changes.

gpm 8y ago

Yes, two. The standard for critical systems is 3. Two isn't good for much, if they give different readings you don't know which to believe. Either that kills you like in real life, or it kills you because of the stall problem it was invented to fix. Edit: And yes, you could do something more sensible than what they did, but that doesn't "fix" the issue, it merely mitigates it to some extent.

cjbprime 8y ago
This seems a little overstated. As I understand it the plane isn't actually aerodynamically unstable and isn't going to stall itself without the pilot pulling into it. The main issue seems to have been software to me. I'm not saying they should avoid using a third sensor. It sounds like a good idea. But I'm not sure it's required for airworthiness, after you move from one to two.
- gpm 8y ago
  Maybe a little overstated to avoid getting into subtleties, but I stand behind the point. Yes, it seems the plane is probably mostly flyable if you kill the MCAS system (which is the only reasonable step to take in a two sensor system when they disagree). But - The plane no longer handles the same, you definitely need to be alerting the pilots, and put this change into manuals and training. This isn't just a thing you should silently do in software and expect not to kill people. - The plane no longer meets the FAA rules for the class under these conditions. Maybe that's acceptable because it is an error state, but I think that meets the definition of a "workaround" and not a "fix". - At least one of these planes took off when one of the sensors was known to be bad from the previous flight (as I understand it). I can only assume that they don't do that when something critical to the handling of the plane is broken. This is another process bug that needs to be fixed before a software workaround might be acceptable. I don't see any way to interpret this other than "the hardware didn't work as we thought it did", which leads me to say "hardware bug", even if you can maybe work around it with process, training, and software changes.