Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Boeing 737 Max8 Aircraft Crashes and Investigations [Part 4] 28

Status
Not open for further replies.

Sparweb

Aerospace
May 21, 2003
5,103
0
36
CA
This is the continuation from:

thread815-445840
thread815-450258
thread815-452000

This topic is broken into multiple threads due to the long length to be scrolled, and many images to load, creating long load times for some users and devices. If you are NEW to this discussion, please read the above threads prior to posting, to avoid rehashing old discussions.

Thank you everyone for your interest! I have learned a lot from the discussion, too.

My personal point of view, since this falls close to (but not exactly within) my discipline, is the same as that expressed by many other aviation authorities: that there were flaws in an on-board system that should have been caught. We can describe the process that "should have happened" in great detail, but the reason the flaws were allowed to persist is unknown. They are probably too complex to reveal by pure reasoning from our position outside of the agencies involved. Rather, an investigation of the process that led to the error inside these agencies will bring new facts to light, and that process is under way, which will make its results public in due time. It may even reveal flaws in the design process that "should have" produced a reliable system. Every failure is an opportunity to learn - which is the mandate of the agencies that examine these accidents.

Some key references:

Ethiopian CAA preliminary report

Indonesian National Transportation Safety Committee preliminary report

The Boeing 737 Technical Site


No one believes the theory except the one who developed it. Everyone believes the experiment except the one who ran it.
STF
 
Replies continue below

Recommended for you

There are always mistakes made by pilots.

Niel Armstrong with all his NASA training made a mistake landing on the moon not turning a radar off and overloaded a computer so he had to fly manually.

Sully didn't run the ditching checklist.

Training is good and things will change. But if the 737 max requires more training than other types then it's dead as a Dodo. They might as well not bother getting it flying again and scrap what they have built.

There would be zero point me doing any of the stuff that's required for flying a max with a dodgy flight control system with ineffective manual trim.



31st of October is a crucial date. Alot of the purchase contracts have cancellation clauses in them that if the plane isn't delivered by then the order can be cancelled and deposits have to be returned.

This power cycling thing is a feature on quiet a few types. The Q400 I always do a power cycle when I take an aircraft over. It only takes 5 mins to come back up though. The old ins systems did used to take a long time to come up. Modern laser gyro ahars is under 60 seconds for them to come up and align.




 
Alistair Heaton said:
There are always mistakes made by pilots. ... Sully didn't run the ditching checklist.

What? Alistair, you are normally so fair, why the sudden slap?

Sullenberger made a conscious decision to touch down at Flaps 2 not 3, to have a higher nose attitude, because he anticipated that the fly-by-wire would not let him flare nose-high enough with Flaps 3. That was later confirmed, and it was also later confirmed that despite dual engine failure the hydraulic system had enough pressure to deliver the Flaps 2 settings as he commanded.

The other item on the checklist that Sullenberger skipped was to set the parking brake to ON.

For the record: I can forgive him for skipping that, while afloat on a river.

No one believes the theory except the one who developed it. Everyone believes the experiment except the one who ran it.
STF
 
He didn't run the ditching checklist which meant three pressurisation large volume flow rate valves weren't closed so it flooded with water alot quicker than it should.

They were full of fuel so that saved them.

I have zero issue with what they did. Btw he is a check airman on 737 500's and knows the plane extremely well. So if he says he can understand the pilots confusion he knows what he is talking about.

 
I have a bit of confusion about whether the pilots followed the checklists correctly.

AFAIK the runaway stabilizer trim memory checklist doesn't require reducing power. It also has using the electric trim to return the stabilizer to an "in-trim" state before cutting power to the trim system as optional. The pilots did neither of these things, one or both of which could have saved them.

Is my understanding correct (based on current published info)? If so, that would mean that they did follow the checklists. Are there other issues with the lists under contention?
 
We've discussed this quite a lot if you read the previous posts. The AD was rather vague and not a checklist in itself as it hadn't been added to the QRH AFAIK and said you could use the electric trim before operating the cut out switches, but not to where you needed to get them.

Now we also don't now know if the electric switches were working correctly due to possible overload of the processor so maybe the ET pilot moved the trim as far as it would go then decided to cut the power to prevent further nose down.

The speed certainly didn't help but even at a slower velocity, the force on the smaller manual wheel from earlier versions of the 737 and the number of turns required may not have been physically possible. This was included as a default manual operation available in theory at any time, but in reality didn't seem to be available to the pilots on ET.

The reduce speed and roller coaster operation wasn't in any recent handbook or manual.

Remember - More details = better answers
Also: If you get a response it's polite to respond to it.
 
What they actually did in the cockpit is now deemed unknown due the the data system issues and processor lock up.


The FDR data is now deemed un certified because it's recording the effect output not the cause in switch movement.

The whole thing can only be described as a complete and utter Custer f*CK
 
The "Processor lockup" is from an artificially applied change. The lack of detail confirms for me that it had nothing to do with the accidents. More particularly, if there was processor lockup there could be no command from MCAS; we know that is not the case.

There is never a way to determine if a switch moved until they put video cameras into the cockpit.

What is known is that every potential cause of an action resulted in a reading of results.


Eufalconimorph - Before there was runaway trim the initial problem was airspeed disagree, which does require reduction of power. It says trim as required. Trimming was required. The Ethiopian pilots chose not to. In five months of warning it is clear that neither pilot went through the steps enough to act correctly on trim runaway and never learned to manage airspeed disagree. Which is no surprise - the airline has concentrated on rapid expansion above all else. Greed and pride.

LittleInch - trim is always the same - reduce the load on the controls so the plane remains pointed wherever the pilot points it without having to push or pull or turn the controls. The various estimates are that the Ethiopian pilots turned off the trim with nearly 50 pounds of pull required. Imagine if someone set a 50 pound bomb on your arms while you are typing and all you had to do to make the bomb go away was press the space bar. Instead you power off the computer and sit with the weight of the bomb on you and when you drop it - boom. Yup, as easy as the space-bar. Waiting for the CVR to see if there was some reason they decided to muscle up on the plane rather than push their thumb on the trim switch.
 
It appears that they followed the AD until it became apparent that the AD instructions didn't work.
When they realized that if they continued to follow the AD they would probably die, they tried something else.
It almost worked and it could have worked if they had been aware that there was another Mac attack waiting for them. and turned the switches off between the short electric trim up commands.
Did Boeing or the FAA share that information with the pilots?


Bill
--------------------
"Why not the best?"
Jimmy Carter
 
Grab a copy of the preliminary report. It has the AD but it doesn't have a copy of the airspeed disagree procedure. That's an initial cover-up as airspeed disagree was ahead of the MCAS intervention.

No sequence of steps was correctly identified by the pilots and no sequence of steps performed matched the airspeed disagree, the AD, or the runaway stabilizer procedures. They picked a few items out of order that happened to be on them.
 
I agree processor lock up is unlikely to be a factor but we might never know for sure. Quite the opposite to be honest if it locks up it may be processing only MCAS commands and not the manual trim inputs. ITs not a fail safe with zero output when locked up.

The STS has the trim wheel moving constantly right after rotation. Its not the case that the trim wheel doesn't normally move during this period unless the pilot commands it. The whole point of these systems is the aircraft is never trimmed correctly on purpose and the pilot gets weight feed back on the stick. Even if the pilot does trim it perfectly for zero force finger tip flying the system moves the stab to induce a slightly out of trim situation. The only way to know what's right and what's wrong is via session in the sim. Reading about it on an Ipad is pretty much useless.

Switch positions are wired directly to the FDR for some flight critical systems. The cvr is that sensitive that you can hear switch movement. And comparing the sound track from the ambient mic and the two headset mics means they can work out the location of the switch moved but its not exact.

When you say the intial problem was a airspeed disagree thats not the full story as we are pretty sure that it was a bird strike. And to rip the AOA vane off it must have been a big one. So prior to things happening in the cockpit they would have seen a large bird apprently about to enter through the front window at 240 mph. So they more than likely had there heads down. Then a colossal bang and then things start going off. The startle factor would have been huge. Damage assessment after a bird strike is seat of the pants stuff you basically have to check everything then cross check everything to see whats valid and whats not. There is no QRH listing for it on the Q. They would have been proritising checking the engine on the side that the bang occured for more than a few seconds after they had got over the shock of the bird strike more than enough time to go over the 8 seconds responce time required to keep the aircraft in controlled flight and be able to manually trim.

I don't actually see the MCAS system as the primary issue to get the 737 MAX flying again. The whole trim system needs to be sorted and I can't see a software fix ticking the boxes. I also now can't see it flying again by next summer season.



 
The computer overload may have been a slow down rather than a lockup.
We saw that when computer control was first introduced to industrial control systems.
Input signals (switch operations) are stored in a buffer. The computer deals with each input in turn.
It was quite disconcerting to push an emergency stop and then have to wait a number of seconds for a motor to be de-energized.
A small program may execute with negligible time lag.
However as more functions are added to the workload, the response time may start to increase.
There may be a time lag between information arriving at the buffer and the information being read from the buffer.
Then there may be a time lag between an operation being read from the buffer and an output being generated.
When why and how much delay in execution of commands is system specific and also may depend on the order of instructions in the program.
I realize that this may have nothing to do with the computer problems on the Max.
It is, however typical of early industrial computer systems that an increase in the work load often results in slower response times.
Yes, my information is very old. Almost as old as the 80286.


Bill
--------------------
"Why not the best?"
Jimmy Carter
 
The Seattle Times has crammed so much advertising and tracking on all of their 737 articles, I can barely get their articles to load any more.
Thank you for the link - I did eventually get to read it. Cosmic rays triggering errors in microprocessors... They're really checking everything, aren't they?

No one believes the theory except the one who developed it. Everyone believes the experiment except the one who ran it.
STF
 
Alistair, thanks, that was a good article. The cosmic ray is only for single bit flips, which is a pretty common problem that requires design mitigation for LEO satellites. The scenario described in the article is for 5 arbitrary bit flips, which would be extremely unlikely. Nevertheless, the article at least clears up the incorrect claims that the processor froze or slowed down; it was simply that the pilot's recovery procedure took too long and the solution is to run both processors in parallel so that any disagreement will result in reversion to manual controls.

btw... ad blockers work great; if there were any ads on that site, I didn't see any; still took a while for the photo at the start of the article to show up, but's probably because it was queued up after all the ads that were blocked.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
 
That's pretty normal spar. Everything goes on a vibrator for an hour as well both high G and low G huge deflections and Up and down the frequency ranges.

Its not only cosmic it is also part of the hardening against mobile phones.

Both these accidents occurred below 10 000 ft so its extremely unlikely it had an effect.

If its parallel procs then that a whole heap of further testing being required. I think the trim issue is by far the hardest to crack.

The other tip with these articles is to read them in a private window. It then stops all the data analysis scripts running and your data being sent.
 
Status
Not open for further replies.
Back
Top