From the story:

Yeah, ya gotta watch out for those inattentive pilots. :ugh:

These efforts to lay off responsibility and blame the folks who fly these airplanes just never end.

Yer gotta tell them damn inattentive pilots the system exists first.

NG pilots may want to be comfortable about that, also.

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 don't think "they" like it when you ask hard questions like that, Rob.

I hope that they are making false activation of MCAS survivable, and also trying to minimise the frequency of false activations. Although
keeping the hardware unchanged means that the engineers are trying to do this with at least one arm tied behind their backs.

Making MCAS survivable probably entails both minimising its potential effects (e.g. only singe-shot) and providing a practicable SOP for handling it.

Minimising the frequency of false activation probably involves lots of sanity checks on the AoA readings both separately and collectively
(e.g. beware of at-extreme and stuck-at readings).

A major problem with collective AoA checks is that each AoA is only connected to one computer. So both computers have to be fully
operational and communicating with each other to perform them. It would not surprise me if that this unanticipated communicationto disable it in response to some classes of hardware failure.

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.

Correct.. worked as specified..
From hard electrical faults e.g. welded relays, or faults in wiring looms. Or from soft faults aka. SEU (Single-event upset).
I have been wondering why there is so strong belief in that fixing the MCAS algorithm makes the aircraft safe, when it is not unlikely that a SEU generates a runaway even if the MCAS algorithm is deleted from the system. I.e. the risk of a software introduced runaway theoretically exists on the NG, except the NG still have the cut-out switches on the yoke.
My understanding of CS 25.671/25.672 is that, either: A trim runaway must be “extremely improbable”, this require a DAL A architecture all the way from sensor to actuators. Or be capable of continued safe flight and landing following runaway. The last claim have been proven impossible, so DAL A it is.

What remains obvious is that regulatory capture is driving the process.

Thus the only way that the issues actually get resolved will be pilots and the flying public saying no more.

Yes, although, if EASA doesn't simply march in step, that will be very significant.

Question from SLF, if you have systems such as STS and MCAS automatically running the trim at what point does a crew decide they have a runaway?

so what happens if AOA goes fubar etc and says *** you are diving too steep**eg negative AOA > ?? degrees ***- does Mcas trim nose up ? how much, how long ? Phugoid ??

Oh come megan, that will be covered in the extensive iPad 737-MAX training package*.






* Course content increased 100%, now 2 hours in duration.

Boeing will let us know, after the fact, that the crew should have figured that out.

SideNote -- re the Boeing BS described as " Now, according to the Boeing website, it has over 45,000 engineers spread throughout the entire company. Such a deep roster of talent, the aerospace company has incredibly deep and specific expertise for new designs and to manage the safety and airworthiness of the nearly 14,000 Boeing airplanes flying today."

look up the following in the JDA Journal "FAA Insight and Aviation . . ."

:ugh:

45,000 sounds like A LOT of engineers. An American aviation engineer wouldn't get out of bed for less than 100k a year. That makes it $4.5bil in salary alone. That's almost 10% of the company's revenue and over 80% of net profit.

Another number that kind of scratched my brain the wrong way is "14,000 Boeing aircraft flying today". Are there that many flying? Even with military airplanes and helicopters, that looks like a VERY big number.

Where's the missing MCAS automatic trim commands?
 

From the preliminary report of the ET302 accident.
(many copies around the internet)
==============
At 05:40:35, the First-Officer called out “stab trim cut-out” two times. Captain agreed and First-
Officer confirmed stab trim cut-out.

At 05:40:41, approximately five seconds after the end of the ANU stabilizer motion, a third instance
of AND automatic trim command occurred without any corresponding motion of the stabilizer,
which is consistent with the stabilizer trim cutout switches were in the ‘’cutout’’ position
==============
At this point, the trim cutout switches were shutting down the output from MCAS reaching the trim motors. So, why are there no more automatic MCAS trim commands recorded? (Cyan color in the Flight data recorder tracings on page 26 of the report) The trim cutout switches shouldn't inhibit the FCC from issuing commands, just the trim motor being cutout. For approximaty two minutes, MCAS should be issuing 8 or 9 more AND automatic trim commands but, they aren't on the data trace. Flaps are up, AOA is off the chart, A/P is OFF. The only change is the stabilizer trim cutout switches were in the cutout position. How should that change MCAS from issuing more AND automatic trim commands? The trim motor is cutout from accepting the commands, but, they should still be issued from MCAS, unless there is some connection between one or both of the stabilizer trim cutout switches and the FCC MCAS program somehow? Only when the stabilizer trim cutout swiches are turned back to normal, do the automatic trim commands reappear at the end of the flight.

from the SPEEA site www speea org today

not too sure what the split between engrs and techs really is will try to find out

That's easy: MCAS will not input multiple trim commands unless it is reset. Tugging on the manual trim wheel, successfully or not, won't do that. It is reset by the use of MET (among other possible conditions), which is why it was driving the trim repeatedly in both accident flights. With the cut-out, MET commands don't register, so MCAS is not reset and does not make further inputs.

Or a demonstration that manual trim is operable by the pilot(s) in all parts of the flight envelope that can reasonably be reached.
Or that the risk of an un-contained fan failure sending shrapnel that severe an essential flight control link is low enough.

Yes. From the EASA "statement of clarification" on September 27th of this year:

Emphasis added. We shall see what they mean . . .

I assume that was written after the event(s), though it does seem a little like moving the goal posts after a multi-billion $ investment has been given the go-ahead.

Yes, but I think EASA is more reluctant to "rubber stamp" FAA approvals now than previously, and for good reason.

So, If one uses the MET for one long shot of ANU, going to limit up, then MCAS should fire for 10 seconds of AND, and be done, assuming the MET is never touched again?

Manual Electric Trim (on the stick)
my best guess

Questions.
During flight testing of a new airplane is the plane
actually properly stalled? i.e. Stick hard back and sinking like crazy.

Or do they just validate wind tunnel / simulator results by 'approaching'
the stall?

What will the FAA / foreign authorities require now to be fully assured
that the Max is safe? (with respect to stall characteristics)

The reported tracks of the recent test flights appear to show that some 'vigorous' manoeuvres were repeatedly attempted - whether these were solely recovery from MCAS operation or included unmediated approach to stall is not clear.

Does anyone know how the data from such flights might be incorporated into SIM behaviour?

Deepinsider,

Certification stalls are very demanding indeed. Sometimes very unusual things can happen, listen to the last three podcasts by D. P. Davies in this thread! https://www.pprune.org/tech-log/6029...-aircraft.html

And some of the test pilots who post on Proone I am sure will be able to give you details of modern flight testing.

Is there enough data from wind tunnel tests to program a simulator, for test purposes
which then might be validated by initial actual inflight characteristics (although not actaully
getting to the real stall?)

Each new aircraft is stalled in the air in both clean and full flap landing configurations.
The stall speed and stick force gradient is measured to compare with data derived from previous flight tests.

So are you suggesting that the only reason both aircraft became uncontrollable and crashed is DIRECTLY BECAUSE the pilots attempted to counter MCAS with trim inputs, albeit insufficient?

Further, that if both accident crew simply ignored the initial MACS input and continued to fly the aircraft with the resulting out of trim state that no further MCAS action would have occurred, and they'd have survived?

It seems a highly ironic and depressing thought that the 2 subject flights only became uncontrollable because the pilots tried to fight the effects of MCAS with manual trim.

I assume you mean each new aircraft type or new aerodynamic or control configuration, not every production airplane.

Yes, that is right. A few months ago, a poster who seemed to have a lot of insider knowledge of MCAS explained its workings. Everything he said appears to have been correct.

Yes, they could have simply flown the plane with 2.6 units out-of-trim. MCAS does not repeat after its initial activation unless one of these things happen:
1) Pilots use MET.
2) The autopilot is successfully engaged.
3) The sensed AOA drops below the activation value and MCAS unwinds the trim it previously applied.

Only #1 was a factor in both accident flights.

From the Final Report, section 2.5.1.2.4:

It would have been rather handy, if Boeing had mentioned that after the Lion Air crash. They were adamant that the pilots weren't trimming enough, though. Much commentary was made, here, about those little comments after AUTOPILOT-DISENGAGE, about getting the aircraft back in trim BEFORE cutting off the stab trim switches.

See "Evolution of Stab Trim Runaway Procedure", 737 Runaway Stabilizer Procedure

Indeed you are correct Dave.
I was up early this morning hence my quick post.

Some B1 test flights also check the rudder trim on 737 NG's,at full flap, to be certian that the rudder trim is to spec.

Dave, 586,
for info BAe 146, Avro RJ, DH 125; every production aircraft was stalled clean and as configured for landing.
Risk was managed by fitting a stall panel for comparing cross side AoA vanes and airspeed; this could be used by any operator.

Flight test / certification involved much deeper investigation, extreme manoeuvres, and harsh pilot handling.
High risk flights had additional display and recording of AoA; the aircraft was fitted with a stall recovery parachute. Crew wore parachutes, cabin doors could be jettisoned for escape.

re-certification of the Max probably ranges these types of flights depending on what is claimed for flight with MCAS inhibited - AoA lockout, unreliable stall warning and speed (ADC), reduced stability margin and different feel gearing.