That is a circular argument. Aircraft need many items to be certified, many which are either not needed or not used on every flight.

Turn off the stab trim. Avoid unusually high AoA. Is that too complicated?

MCAS is on all MAX variants.

It is if you haven't been informed of the system[s] that are causing your aircraft to start doing it's own jive turkey thing..

Apparently not for one crew - but too much for the last crew.

Salute!

Problem,@ Jim in Texas, is the fatal crew had the stick shaker and other bells and whisltes from WoW. It looks to me from the FCOM that the shaker( one side, if we read the logic correctly) would have kept shaking even if they had disabled the trim using those pedalstal switches. Also seems that the other side should not have the shaker going. I can see how the crew is getting confused.

This is getting beyond something simple like dual engine failure that Sully and Skiles had to deal with compared to this scenario.

There;s a lotta difference between classic runaway trim where the sucker keeps a continuous trim in one direction and the MCAS intermittent trim mechanization. It's especially hard to deal with a new "anomaly" if a "new" installed gizmo is not carefully briefed and the folks that implemented it have not thot of a single point failure as we saw in 610, and possibly the previous flight.

Gums...

Reading all of this from a laymans perspective, it appears to be very simple, the aircraft malfunctioned.

In reading through these posts, it does not appear that anyone has been able to show any information from the manufacturer on how to respond to this malfunction. Nothing in the FCOM or training suggests that there is a procedure and/or training on how to recover from this malfunction. (such as MCAS disconnect procedure) This is coupled with the issue that I see little information from any airline that they were even aware of the feature.

The arrival crew had issues, but it is unclear how the problem affects the departure logic.

Like many other failure mechanisms, it is usually the folks with less experience that expose the weakness of a system.

Possibly true to an extent, however the problem presented as a complex issue that impacts the control of the aircraft to an extent, but that compromising is associated with warnings that suggest other instrument/sensor-flight condition issues.

Some crews may have dealt with this issue, others won't do so successfully. Ascertaining who may or may not is unknown, and suggesting brand A, team X is less susceptible to a problem resolving this is not supported by industry history. Unless you have had compound failures or flight control problems with an aircraft that are outside of the QRH, it is unlikely that the extent of the cognitive demand on the poor pilot is understood. The human is both the strength and the weakness in the system. Note that the event here exceeds the general training and procedural advice of manufacturers, who deal with single failure events at a given time. This crew had a single failure that showed up as two different symptoms, with the second symptom potentially supporting an erroneous mental model condition of the state of the aircraft. If the FAA/ODA and manufacturer didn't see that coming because they are human, then it appears unreasonable to blame the next poor human in the process. This is not a linear causation event under the Reason causation model, it is a non linear event arising from a simple modification using well known and used sensors, but with a failure of imagination. Not the first, and won't be the last. removing humans from the process guarantees failures, check your BSOD, tablet lockup etc to consider how reliable the world of computerisation is, even without cosmic radiation events.

fdr sums it up very well.

When everything is working as it should be and a crew familiar with all the odd little "gotcha's" of the very complex automation then all is well and much safer.
When a minor malfunction causes unbriefed and unpredictable cascading and confusing effects on the man/machine interface there is bound to be trouble.

I speak from some years of man/machine interface programming, by chance with experience of both.
Were I a simple surgeon (who has diligently read the instructions) faced with an anomaly from the reasonably expected behaviour of an instrument,
my reaction will be very different indeed from the "me", who has written the soft/firmware, and is very aware that "gotcha's" can surface at any time,
even though I had tried very hard to prevent their occurrence.

The one says, "Yeah, that always confuses it, just do x, y and z and it'll sort itself out"
The other says, "Why in Heaven's name is it doing that? Let me try q & r, which I seem to remember the book says will fix it!" - Wrong answer...
Accident or incident follows.

The man/machine interface is still in it's infancy - in realtime situations a lot more thought needs to be put into it.

Mac

:(

I would agree and offer that a significant implication of this thread is a deep flaw in the human/machine interface.

Near as is described, the automation repeatedly and silently countermanded explicit inputs provided by the crew.

I would anticipate a challenge especially on silently, but invite debate why that is an unreasonable conclusion.

For me, repeat and silent countermand is beyond the agreeable authority of automation, and begs a basic question who versus what was actually in command of the aircraft.

At any point where that isn't explicitly clear, there exists a profound and fundamental problem.

Turbine70, the deep flaw in the human-machnie interface seems to be that they forgot to tell human that this specific interface exists.

How many of this 73 Max variant are currently in service?

Boeing 737 Orders and Deliveries

in service/delivered about 330

True but the human would have been taught many times that if the trim is running un-commanded then select the stab trim cut out to OFF.

CONSOAnd this is the first time the problem has occurred? What checks are being made across the fleet? Is there a directive out?

Definition of 'uncommanded' in a human in the loop system - is that the system action takes place without the pilot initiating it. STS is an uncommanded action. However, if (MCAS - something unknown) is trimming powerfully down repeatedly uncommanded regardless of reason; stop it doing it by switching off stab trim. Worry about why or what was misbehaving later.

Great advice.

If a crew had an accident as a result of following the runaway (i.e. continuous) trim procedure, when the problem turned out, in fact, to be an intermittent one, you'd be the first to point to point out that intermittent is not continuous <Monday morning quarterback>

Play the video below as you read the post.

The biggest issue faced by this and the other crews is trying to figure out what was going on. They had IAS disagree, stickshaker, and intermittent trim runaway only after flap retraction. This was NOT a classic runaway, the runaway did not follow the continuous expectation, it only began after a 5 second period from a manual trim input, then stopped as soon as the trim switch was moved for another 5 seconds. Try workshopping that combination with the published system knowledge that fails to mention that the MCAS even exists, in your second language reading the checklist(s) to figure out your pitch/thrust combination to isolate the failed system, all with this racket in the background.


If you gave this scenario's to 100 crews in the sim, I have no doubt less than 100 would end up turning off the stab trim cutout switches off. Some crews may never have even retracted to flaps to expose the MCAS activation. Unfortunately we won't ever be able to perform the experiment as most 737 MAX pilots are now likely acutely aware of the MCAS and the appropriate deactivation via the stab trim cutout.

I am sure the shaker and warnings were very distracting. Just as they were for the crew on the previous days flight who landed safely.

The basic point though is surely, the trim is running....I want it to stop.....I will turn it off Bloggs unless you have a better idea....... No it is not a classic sim failure, single problem, linear solution now move on to the next exercise. They had the aircraft more or less levelled off then lost control. Got tired or swapped PF?

Is it possible that this is EXACTLY what they did? I seem to recall that an engineer went up with them......

The engineer, according to the airline, was simply a flying spanner whose presence was not connected with the problems that had been encountered with the aircraft.

With regard to the somewhat semantic debate as to whether "stab runaway" applied or not, it might be good to not just look at the title of the procedure, but also at any additional information or training which helps define the condition.

For example, on a DIFFERENT aircraft the corresponding AFM procedure starts:
Thus, while the name of the procedure appears to be narrowly defined, the indications - the conditions under which you are expected to action, or at least consider actioning, the procedure - cover a range of scenarios - and I'll note include the "not by system design" case, so for the B737 STS case, if you know the motion is normal per design, you wouldn't do this procedure. If you don't know that, then it's a contender for "stab runaway"

I don't know if the corresponding B737 materials contain sufficiently similar wording for the comparison to be fully valid ...

I don't have the 737 Max QRH but this is from the 737NG QRH. I'm guessing, since B kept quiet about the MCAS it would be the same!

"RUNAWAY STABILIZER

Condition: Continuing rotation of the stabilizer trim wheel in a manner not appropriate for the flight conditions."

Is 'continuing' the same as continuous which is how it was always presented in the sim? Are there differences in how these words are understood on each side of the Atlantic? I think both crews had previous NG experience, (reversion to past experience under stress?), but also remember English was not their first language.

I suppose the last part, "not appropriate etc", covers the intermittent trim wheel rotation but as suggested probably not all crews would have remembered that part of the conditions for applying the "Runaway Stabilizer" Non-Normal Checklist at the time.

1066

Well yes and no. The presence of the engineer on the flight isn't speculation - the airline has confirmed that.

The reason why the engineer was on board isn't really speculation either, unless we're suggesting the airline might be lying about that.

Whether the engineer was on the jump seat and, if so, what part if any they played in the events, are the only unknowns. My money would be on none.

continuous = without a pause or interruption
continuing = that keeps happening, existing, or doing something

Salute!
Thank you Curtain..
OTOH some here sound like a defense lawyer being picky about the malfunction definition during the upcoming liability suits.
Sheesh.
Then Mad expresses the thots of many
So in a galaxy far away I had this malfunction that had no procedure, and only thing we had in our checklist was called "LEF Malfunction" ; So when I called in after getting heart rate below 150 or so, and altitude of 1,000 feet or so, still climbing ( speed may be life, but altitude is life insurance!), my squad "helper" said to "LOCK" flaps after gear down, as that was the only procedure at the time. I explained that I had a diferent problem. Was second guy with this, and first one over in an EPG country died trying to land but we didn't know the details, so for all practical purposes I was the first and I recorded the approach for a potential accident board ( it's in my interview on the public profile heref - crappy video conversion thru three formats )..
So here's what I saw just after raising the gear:
https://cimg9.ibsrv.net/gimg/pprune....25b9c4e840.jpg
Surprise!
And here's the quote from our checklist and Dash One:
The assymetric flap procedure was added after my episode

Let the picture speak to that.

So the cardinal rule applied, and I followed it. Fly the damned plane, then call for help when you can. Don't change anything if you are not wildly out of control. Do not troubleshoot unless the procedure calls for it AND the original problem is mitigated, otherwise do what the previous 610 crew did and accept the horn/shaker/whatever and fly with manual trim wheel.

I still maintain:
Boeing needed to 1) tell all the users about the MCAS system, 2) change the emergency procedures for ALL perceived trim malfunctions as Mad has shown for brand-x to have the crew simply tiurn off the electric trim and then proceed, maybe with more steps if required, and 3) conduct a better fault tree analysis before fielding this lates kludge

Gums sends...

What was the first sign of malfunction, Gums ? A brutal right roll? What left roll authority did you still have? What approach speed did you choose?

Salute Lion!

First clue was roll, but I thot jet wash from preceding Viper. Control pressure on that gal is light, but it was later determined Ihad about 14 or 15 pounds( max control pressure available was about 16 or 17 pounds, so I was close to losing it). Then the vibration/buffet became very obvious and I glanced left, then right.

I kept speed where it was when I realized the flap had folded up, as I was doing O.K. and kept on keeping on.

Now back to undocumented malfunctions, but mine was a first for USAF and second overall. Least we figured out how to land the thing.

Gums sends...

BTW Lion, I think the loss was a fellow countryman of yours, and I got details much later from F-16.net moderators. So the fact that I did not try to "flare" save me and the jet.

.

Intermittent v Continuous

MCAS has a limited authority, and a continuous sensor fault would result in a single trim error to the limit of the MCAS system authority. That defect would likely be counteracted by any flight crew, as the speed was changing through the flight profile, and so pilot trim would be undertaken as a normal matter of course. Without having any information on the presentation of the fault, it would appear that there was intermittent failure and an ongoing change in the trim condition. It is also possible that didn't happen, and that would be a further human factors investigation issue.

Let's just stick to the facts.

Voting and triple systems
 

Voting is not always the best solution. Try to block 2 pitots tubes on 2 ADMs at FL290 (at night) on the Triple and perform a descend for landing and land.

Triplexed systems have been around for 50+ years. How many times in that period has a good input been outvoted by two bad ones ?

INS versus AoA and software updates
 

I am new to pprune forgive me I dont know how to simply add a comment so I've hit reply to yours, here's my pound or kilo of flesh:-

Basically the MCAS trim override system is a partial “FbW” system. We all know why it was implemented, so I don’t need to discuss its merits/functionality here or the unsettling fact that its bad behaviour was actually notified last year after the Lion Air incident. No one outside of Boeing or whoever is in accident investigations has seen the recorder data sets and heard the recently recovered CVR of that accident. That will remain confidential for ever.

I personally doubt (working in military electronics) whether the latest incident’s recorders would have survived a “direct in” at that terminal velocity. However, this seems to me to be a truly software-related problem. Yes, I know that setting various switches, is supposed to reset or kill a “loop” in the “code” however, in the good old days switches used to get connected to servo actuators by things called “wires” using stuff called “current”. Now each switch (however WW2 clunky) is read into a data set packet and sent along the Manchester bus data-highway of the revised and “simplified” cockpit systems into the various CPUs. Frantically pulling fuses out won’t help. So, ignoring the input side of the AoA sensors on the wings, there is a possibility that the software version now being hastily rolled out, (I’m not sure how the FCS/CPUS is updated, could even be over a USB stick) may indeed have the “corporate cover-up code” required to eliminate the “problem”. (i.e, if the loop executes say, more than 5 times, - it’s probably a sensor failure not a “pilot error”).

If any system which is designed to take a manual input before it re-enters its loops, does NOT read or ignores fresh inputs from switches - then there is also a risk that the “naughty” algorithm will continue to re-execute, despite the operators putting their big feet on the glass displays and yanking back with such enormous force as to bend the panel. In any event, there won’t be any real feedback or pitch reaction by the kite, if the control column is only “connected” to the air-surfaces by dumb electronics and computers. I doubt whether anyone has actually tried to see if the system does indeed go into an unrecoverable loop at FL 35 over the pond while delivering a new freshly painted bus to a punter. After these two incidents, I wouldn’t want to try, unless the hatch was open and I had a parachute - as I’m too fat to squeeze thru the DV window.

This brings me onto point 2).- “Sanity” Displays.
Each aircraft has 1-3 INS systems. They look at 6 DOF (six degrees of freedom, P,Y,R, and Surge Heave and Sway as Noah would say) and they are fully capable of measurements to high orders of angular and rate accuracy. They know exactly what the “vectorial” behaviour of the airframe is at any instant. The strapped down INS actually contains low-drift North-seeking Ring Laser gyroscopes, and 6 very sensitive accelerometers, probably all Honeywell types same as used in TLAAMs. The basic function of it can act as a really high-accuracy vertical reference unit. (remember those?). It can output the true measured “3D” motions of the a/c its - accelerations, pitch angles, rates and an earth-centred attitude reference. Remember - half the battle of flying is defying gravity. So as an engineer, my question is - why rely wholly on attitude sensors that Noah used to trim his boat in a gale? They are subject to bugs (insects), cleaners, de-icers, icing, birdstrikes, electronic failures, corrosion, static from lightning, poor calibration etc etc. The real method of display of an aircraft’s true attitude should, in my opinion, be derived from the “VRU” aspects of the INS and combined/checked against any external physical sensors. A failure warning “disagree” page should be available on the glass display, warning the pilot (by red/green overlaid lines etc) that what’s being “dealt with” is NOT the true attitude of the a/c in motion or its approach to/from instability. Just a thought. I’ve banned my whole family and staff from ever flying on the MAXes for the foreseeable future and I extend my heartfelt sympathies to those affected by this, IMHO, totally avoidable “modern” tragedy.

Excepting again tests in which the situation got provoked (XL888).