Originally Posted by
Loose rivets
Over these months I've become more and more bewildered by certain design-logic. Now this. What is it supposed to mean? Movements that are un-commanded, presumably meaning by the pilots, must mean movements made by MCAS. These are now going to be stopped automatically.
MCAS did not fail. The specifications/algorithms, altered late in the day, were to blame, inasmuch as they caused a catastrophic overload of warnings and handling difficulties that were beyond 'the average pilots' ability to manage. If MCAS is the only answer affordable answer, the suggested fixes, aired over the last weeks, sound logical.
Where are the erroneous un-commanded movements going to come from, given the quote implies it's not from the pilots and MCAS has been made safe?
I agree, and at first sight it looks like
PR have mangled engineering into something illogical, or the engineering is illogical - after all why would you
stop an erroneous movement, that implies you allowed it to start, why would you allow that if you know it's erroneous, and if you don't know then how will you stop it?
BUT, I think maybe there is an explanation that makes some kind of sense (NB: what follows is pure speculation, I have no non-public info on what they are actually doing):
A while ago I sat down and worked through some implementations of MCAS logic from what we know (I then promptly lost the work, probably why I don't do that sort of stuff for real anymore), I was struck by how simple it actually works out. It is possibly as little as a two state variables, one output, one or two lookup tables and a handful of lines of code - ideal from the point of view of KISS and also for shoehorning into a hard real time control loop that has had decades of mods to use up the future-expansion CPU-time headroom from the original design. The devil is in the reset, you have to wind trim back when AOA drops (or g in original design?) to reduce column force again, but if
anything messes with trim in meantime (pilot, autopilot, speed trim) you can't wind back, otherwise you risk auto-trimming back up into stall, so you must have a reset - but then when does MCAS activate again, it can't be once-per-flight (only protects you the first time), there has to be a re-activation condition too (and still does even in new version)...
this is the point where the cans are opened and the worms are spewing everywhere...
When Boeing announced the revised design there was something about they would ensure the pilot could always pull 1.5g. My first reaction was "very sensible why didn't you do that before", second was "hang on that's going to be non-trivial to calculate" (third being maybe it is trivial but I've forgotten so much aero stuff I don't have a clue how). There is also the issue that the calculation will be using air data that may be incorrect - so we could be no better off than before. The 1.5g seems to have disappeared from the current write up but I suspect it is still there in some form, but now we also have AOA-compare, and other-FCC-compare - my gut-feel-guess at least an order of magnitude more code, inter-FCC comms latency, possible race conditions, orders of magnitude more analysis and testing... how the **** are they going to fit all that in??
Answer - they aren't. Longer answer - assuming FCC has (in effect) multiple real-time control loops I expect MCAS to be in the inner-most loop running many times a second, but there will also be "slower" outer loops for less time-critical longer and more complex processes, imagine "MCAS-watchdog" (or MCAS-sanity-check or whatever) does all the complex stuff and runs in one of those. That would enable allowing for inter-FCC bus latency, reducing race conditions, much larger CPU time allowance. Now we have in effect:
* MCAS (as before plus, probably, simple AOA disagree heck) - inner loop, runs
many times a second (not sure how many, but a lot more than three)
* MCAS-watchdog - calculates pilot can still pull 1.5g, complex airdata sanity checks, cross checks with other FCC, shuts stuff down if it trips -
and runs only three times a second
Now
, this is a system where MCAS
can activate erroneously
but the watchdog process
should catch it and shut it down
within a third of a second (unless all airdata is fubar on both sides in which case good luck with anything). The watchdog process will have to alert the pilot when it shuts MCAS (and other stuff) down, I strongly suspect it will do this via the "speed trim fail" warning light. Therefore it will shut down speed trim at same time as MCAS, perfectly logical because MCAS has always been part of speed trim really, honestly, nothing to do with the fact that we can thereby avoid adding a new warning light which might need sim training. Details on the additional/new meaning of "speed trim fail" will be in a footnote on page nnn of the iPad conversion training. Speed trim fail NNC may get changed to add something like "expect degraded handling with flaps-up, plan flaps-down asap, land nearest suitable".
I think this is roughly what they've done, it matches what they've said before and the recent description, and it's a vaguely sensible way forward from where they were. It still
feels like multiple layers of duct-tape over a weak spot that should never have been there in the first place, but it'll probably be enough, eventually, to get it back in the air.