cyboman said:
Hello, just catching up on the latest replies. It's interesting to see the latest information coming out of the crashes. I think what we hypothesized early was fairly accurate. The memory items were not adequate to regain control of the aircraft. And as suggested, there is a software issue.
I can't help but think back to the beginning of this discussion where we discuss the need for a master cut out that essentially let's the pilot command absolute manual control of the airplane. Or direct law. This is exactly how we see the cruise control systems work in cars. It's interesting because with the tesla and the growing automation in these cars, we're seeing these same paradigms shift, so that the automated systems get more and more authority. Perhaps in 90% of use cases this isn't problematic and in fact beneficial statistically, but it's the other 10% when Murphy's law comes into play. Alas, often the impetus in engineering is to run before we can walk consistently and accurately. I think we're in this place with automation and AI.
It's always useful to step way way back when you're deep into a complex problem.
When we look at how MCAS operates on the trim, it seems to me it is over-stepping the bounds of what an automated system should control.
With autopilot, we have a computer working with essentially the yoke and throttle and commanding them to maintain altitude and heading etc... The limits to that system and how to circumvent it are very well understood by pilots. It's a tool for them that they control.
But with MCAS we're employing an automated system that is essentially, working "behind the scenes" to try to create a scenario or desired flight characteristics that is expected by the pilot. This is a big paradigm shift the way I see it. This is not like autopilot or the speed trim system. The pilot is not aware in the general situational sense, that any autonomous system is engaged and the ways to disengage this system are fundamentally different than autopilot. This override scenario is metaphorically akin to doing a sort of "airplane system emergency surgery" to disengage a fundamental system integral to how the plane flies as expected.
I think when they sketched up MCAS they didn't really have the objective, stepped back, forest for the trees approach to understand how this system is very different than anything they've implemented (taking the Boeing model of flight controls in account). It's really not like the speed trim system.
I think they might of thought of MCAS as augmenting the speed trim system. And so from that perspective, the MCAS is just the speed trim system going farther and farther down the direction of increased automation authority.
Anyway, wanted to add my thoughts. Really engrossing discussion here on aerodynamics, HCI and system design.
The first report on the crash reported the co pilot requested to trim stab cut out, was permitted.
That was well into the issue, inputting nose up trim via yoke, then as per mcas, nose down stab trim.
With stab trim off, co pilot tried manual trim. He said it wasn't working. Pilot concurs (did he try? why didn't both try at same time for more power?) Note Boeing's procedural fix is to get trim where you want it first (this is specifically for runaway mcas trim) using yoke inputs; then stab trim cut out. That's just to make it so there no need for a huge manual (with the trim wheels) trim adjustment.
Apparently pilots are (well) aware of the effects of airspeed, altitude ect on aerodynamics. Including that manual trim in such conditions can be very difficult and a valid option is a "relief trim" input and then manually adjust trim; if altitude permits of course.
Odd thing looks like stab trim was re-engaged after that. Likely to try a final nose up trim; followed by a Boeing "correction" designed to avoid the costs of a new type certificate hard nose down; kaput.
Grr...
all the info in here, except for my figure pointing, is from Juan Brown's "debriefing" of the accident from a pilot to the general public lol (his yt channel is called
blancolirio)
Juan's debrief of the initial report
Note in that vid, he mentions a system that may operate the stabilizer trim even with the stab trim cut-off in the off position. Regarding a "mach trim". It was recorded that while the stab trim cut off was in off position that the stab trim move a bit (with no explanation on what moved it), Juan posits it could be a mach trim, given the speed of the craft at the time.
So such "behind the scenes" automation can work, it just needs to have an acceptable logic to it.