PW100 wrote:

osiris30 wrote:

I am sure the aircraft didn't nose dive on its own. The trim system (as I understand it) doesn't have enough authority to accomplish that IF the pilots are flying the aircraft.

Not sure if I follow this: STS commands (limited) nose down, pilots not counteract sufficiently (for whatever reason were not pulling up immediately - perhaps because of stall warning/stick shaker?), but you are sure the aircraft did not dive on its own? It seems that's what you just described.

If you look at the flight graphs the auto trim didn't command the (fatal) nose down. It wad far too fast and sudden of a dive for the trim system to be solely responsible. Trim adjusts slowly over seconds and within limits. Given a known delta of 20 degrees max error in the aoa the trim would have obly commanded 20deg nose down max (likely 18.5 or so). The final seconds of the flight were MUCH steeper than that.

The trim system is not what flew this plane into the ground.

mandala499 wrote:

Pilots know runaway stab trim and the procedures...
Pilots know flight with unreliable airspeed and the procedures.
But how many until yesterday, know how to deal with both unreliable airspeed and runaway stab trim at the same time.

I don't see it that way. How many pilots don't know to pull back on the yoke if the plane they are flying starts nosing down? How many pilots have died because they were too eager to pull back when their plane appeared to be heading toward the ground? We are told (by the fishermen) that this plane went into a steep dive and apparently never attempted to pull out.

I don't see how that could be the result of a gradual application of elevator trim.

mandala499 wrote:

let's not assume it's day VMC at the crash location just because it's day VMC at CGK airport..

That suggestion if true would throw this whole analysis so far (by everyone) into the trash can: I don't see how that could be the case and yet never have been mentioned by anyone from Soekarno-Hatta Airport.

dragon6172 wrote:

Even without complying with the runaway stab trim procedure to disconnect the "auto trimming", pilots will always have the ability to over-ride it. If the computer is trimming the aircraft nose down, simply pulling back on the control column stops the trimming. Using the trim switch on the the pilots yoke also will stop the computer controlled trimming. In other words, if the pilot is hand flying it isn't an issue. Either you are holding the aircraft level by keeping back pressure on the control column with a slightly out of trim aircraft, or you are constantly using the control yoke trim switches to trim the opposite direction.

Now, if you take your hands off the controls, don't notice the trim wheel spinning, don't notice the nose of the aircraft starting to point towards the ground (either outside or on the attitude indicator), then you forgot to aviate.

However, since they flew along mostly level at 5000 feet for 7 minutes it would seem to me they were dealing with the issue fairly well. Then they just took their hand off the controls? That doesn't make sense, so I feel like there is some more info to come out.

It doesn't make sense to me either. I believe that people have jumped on this AOA tidbit of information a bit too eagerly.

michi wrote:

Amiga500 wrote:

Starlionblue wrote:

BUSS is quite simple actually. It uses raw AoA from the vanes. There is no speed displayed, just an AoA range. Just keep it in the green. Combine with an appropriate thrust setting and you get expected performance.

Excellent - my question is then - why do the pilots have to deactivate a load of primary instruments to get this information?

You'd think it should be displayed as primary info.

AoA vanes are also prone to unreliable data. A vane might bend if you have a birdstrike directly onto it. Then, when using AoA a primary info, you still need to realise, that something is wrong. This circles back to the biggest challenge that comes with unreliable data: the recognition that you actually have unreliable air data. Here only pitch and power will help stabilising the flight path. When this is done, you should troubleshoot and try to find out, which air data (including AoA) is ok and which is unreliable.
This is not easy, as unreliable air data sometimes does not look unreliable. Blocked pitot tubes will lead to changing speed information on the PFD, when changing altitude. You might end up at an altitude, where all IAS speeds are the same, but still, some are unreliable. By the way, computers will fail to identify the unreliable source (s) in that case.

I have had crews in the simulator that recognised having unreliable air data. They stabilised and flew pitch and power till landing, as all the values where so inconsistent and ambiguous, that they where not able to tell which air data was correct and which not. The combination of failures they had where not that realistic, but still, they had one system, which was not affected at all. They realised, that this one system might be correct, but they where not 100% certain and elected to disregard it.

BUSS is nice. But for me it is more like an instrument, where I can check the correctness of my pitch and power values. BUSS respective AoA is load factor dependent. When you do a turn and pull some more g-force than normal, you will end up in the red area of the BUSS. Therefore, even with BUSS, I fly primarily Pitch and Power. I also will not use more than 15° of bank, as this helps with the g-force issue. Also I will try to do everything regarding airplane control and configuration sequentially. This makes flying with BUSS much easier. So, BUSS is not the holy grail, but it is a very nice tool!

Unreliable air data is complex. Even computers fail to recognise certain failure conditions. I have read suggestions upstream of the thread, that computers should compare all IAS values. And as soon as one IAS differs from the other 2, this value should be rejected by the computer. But what if the rejected value was the reliable one and the other 2 have been unreliable together (e.g.taped static ports)? These problems are known to the industry. Does the industry have solutions? Some are available: BUSS or the A350 use of FADEC data for a speed indication. Still there is no holy grail fighting unreliable air data. Pitch and power is still the best and easiest method for pilots. In the sim the pilots fly the regular approach speed ± 2knots using pitch and power. This is good enough!

Excellent post. This should be required reading before any discussion about airspeed instrumentation.

Any similarity between Fly Dubai Flight 981 and this accident ?

KiloAlfaTango wrote:

Any similarity between Fly Dubai Flight 981 and this accident ?

According to the data so far, and the information released thus far for this flight; only:

1) both aircraft crashed
2) both were 737 variants

Today's NY Times has an article that raises the spectre that the Lion Air isn't truthful about it's maintenance practices.

A former investigator for Indonesia’s National Transportation Safety Committee said that Lion Air repeatedly ignored orders to ground planes for safety issues. Pilots and former safety regulators said that Lion Air flight and maintenance crews regularly filled out two log books, one real and one fake, to hide malfeasance.

https://www.nytimes.com/2018/11/08/world/asia/indonesia-plane-crash-last-moments.html?action=click&module=Top%20Stories&pgtype=Homepage

osiris30 wrote:

Given a known delta of 20 degrees max error in the aoa the trim would have obly commanded 20deg nose down max (likely 18.5 or so). The final seconds of the flight were MUCH steeper than that.

Sorry, unless there's a pitch limit logic within the STS, if you're nose level, AOA is 20deg, it'll put the nose down somewhere just less than 20deg... that's fine... but if you're 20deg nose down and your AOA is 20deg, the airplane still thinks you're stalling, and will put the nose down further... to somewhere near 40degs nose down... and that cycle continues until the AOA stops showing the 20deg error...

If the above is the case, by the time nose is way down they'd pull the yoke back to try to recover...

Zeke's graphical flightpath, seems to indicate the crew did fight it back... but why they failed, or why the airplane nosed over again, we'll have to wait... perhaps stick shaker too?

mandala499 wrote:

osiris30 wrote:

Given a known delta of 20 degrees max error in the aoa the trim would have obly commanded 20deg nose down max (likely 18.5 or so). The final seconds of the flight were MUCH steeper than that.

Sorry, unless there's a pitch limit logic within the STS, if you're nose level, AOA is 20deg, it'll put the nose down somewhere just less than 20deg... that's fine... but if you're 20deg nose down and your AOA is 20deg, the airplane still thinks you're stalling, and will put the nose down further... to somewhere near 40degs nose down... and that cycle continues until the AOA stops showing the 20deg error...

If the above is the case, by the time nose is way down they'd pull the yoke back to try to recover...

Zeke's graphical flightpath, seems to indicate the crew did fight it back... but why they failed, or why the airplane nosed over again, we'll have to wait... perhaps stick shaker too?

But if you are constantly pitching down won't aoa continue to shift as your relative motion through the airflow is changing. My thought was, perhaps incorrectly that in a constant arc aoa would keep changing and thus limit the deflection. Genuine question as if I have it wrong I am happy to have it wrong and learn.

osiris30 wrote:

mandala499 wrote:

osiris30 wrote:

Given a known delta of 20 degrees max error in the aoa the trim would have obly commanded 20deg nose down max (likely 18.5 or so). The final seconds of the flight were MUCH steeper than that.

Sorry, unless there's a pitch limit logic within the STS, if you're nose level, AOA is 20deg, it'll put the nose down somewhere just less than 20deg... that's fine... but if you're 20deg nose down and your AOA is 20deg, the airplane still thinks you're stalling, and will put the nose down further... to somewhere near 40degs nose down... and that cycle continues until the AOA stops showing the 20deg error...

If the above is the case, by the time nose is way down they'd pull the yoke back to try to recover...

Zeke's graphical flightpath, seems to indicate the crew did fight it back... but why they failed, or why the airplane nosed over again, we'll have to wait... perhaps stick shaker too?

But if you are constantly pitching down won't aoa continue to shift as your relative motion through the airflow is changing. My thought was, perhaps incorrectly that in a constant arc aoa would keep changing and thus limit the deflection. Genuine question as if I have it wrong I am happy to have it wrong and learn.

The real AOA changes as you describe, but in this case AOA sensor (or the computer handling the sensor) was apparently indicating wrong AOA value to begin with.

Obviously i reckon these AOA weather vane sensors are on either side of the aircraft ... Should one malfunction, is there a linkage configured to result in the correct reading ?

Why does it incline towards this aircraft having faced a jammed aoa sensor resulting in incorrect reading ... Forcing the nose down in seconds .. leaving the pilots with no time for corrections / recovery...

A latest update ...
https://www.nytimes.com/2018/11/08/worl ... ments.html

michi wrote:

Unreliable air data is complex. Even computers fail to recognise certain failure conditions. I have read suggestions upstream of the thread, that computers should compare all IAS values. And as soon as one IAS differs from the other 2, this value should be rejected by the computer. But what if the rejected value was the reliable one and the other 2 have been unreliable together (e.g.taped static ports)? These problems are known to the industry. Does the industry have solutions? Some are available: BUSS or the A350 use of FADEC data for a speed indication. Still there is no holy grail fighting unreliable air data. Pitch and power is still the best and easiest method for pilots. In the sim the pilots fly the regular approach speed ± 2knots using pitch and power. This is good enough!

Engineer point of view here. Yes the industry have some others solutions, but none that magically solve the authority dilemma inside the cockpit.

One of them is to compute the domain of possible next inputs values given the actual values and state of the system (this is how stateful inspection firewall work for example). In a measuring system, input with impossible values can be filtered out of the redundancy set. In case of an aircraft, it's probably possible to compute the domain of possible next inputs values from the energy state, control surface positions, and external environment given that it will not change abruptly at the sub second scale. Should be very effective against erratic spike like experienced on the QF72.

There is actually a big focus on deep learning neuronal network to train to predictor the next state of a system given as much of inputs as possible. In case of a aircraft the idea is that a variation of the state is not specific to a single input and so it sensibility is minimized in case it go erratic. It's for example maybe possible to have a big chunk of structural force sensors inside the air frame that react with enough sensibility together to approximate some of the primary sensors values. This is highly speculating, I don't even know is someone plan to do that experimentally. Certifying a such system will be a nightmare, if even possible, as most scientists admit that there don't fully understand how there predictor network is actually working in the details. A rather extreme point of view is to say that we don't fully understand the human brain either, and that indications of a deep learning neuronal network could help making a decision. More and more medical diagnostics try to be improved with this innovative approach.

An other way to detect sensors problem is to purposely add a know stimulation to the sensor and to subtract it from the measured values. The stimulation could be continuous; in that case it's designed to have some unique feature that make it easy to recognize and subtract without affecting the desired measuring dynamic. Many RF receivers could be said to work that way because of the local oscillator mix to the input signal. The simulation could be discontinuous. For example many seismic instruments have the capability to inject a periodic test pulse to the sensors. The test pulse is analysed to grant the functionality and calibration of the sensors. It also act as kind of 'ping' in remote deployed sensors network to assert that the sensors it still working as it usually only transmit rare event over a threshold. On a aircraft adding a know stimulation to the sensors would be quit challenging.

Last on my list is vision analyzing. A camera monitor the system and the images are processed to measure values to assert the safety of the system. Some high risk machines get new feature like this to protect workers. Maybe the AoA could be monitored that way. Pitot will be more interesting...

If you have a system where essentials sensors could fail, you can add multiple copy of it and/or add alternative sensors or way to evaluate the value (maybe less accurate but sill valuable). Then you can use basic redundantly algorithm or/and use next state predictors to detect and filter out defective sensors. One last point, as aircraft control system look more and more like a network of computers, all the network protection and redundancy must apply too: each node act like a sensor for the next nodes.

osiris30 wrote:

I am sure the aircraft didn't nose dive on its own. The trim system (as I understand it) doesn't have enough authority to accomplish that IF the pilots are flying the aircraft.

Afaics exactly that happened.

Under erroneous input conditions the trim system seems to trim in burst until a physical limit is reached.
This happens in manual flight and restarts even if you correct by hand after ~10s.
( at least that is what I get out of the AD and other info )

Not sure what I'd see as worse behaviour. In error going full hog or going in little bouts stealthily in the wrong direction.

WIederling wrote:

osiris30 wrote:

I am sure the aircraft didn't nose dive on its own. The trim system (as I understand it) doesn't have enough authority to accomplish that IF the pilots are flying the aircraft.

Afaics exactly that happened.

Under erroneous input conditions the trim system seems to trim in burst until a physical limit is reached.
This happens in manual flight and restarts even if you correct by hand after ~10s.
( at least that is what I get out of the AD and other info )

Not sure what I'd see as worse behaviour. In error going full hog or going in little bouts stealthily in the wrong direction.

Stealthily? How do you miss the trim wheels moving? Or not hear them?

More the point how do you stop them if you see them moving ?

The SB says to use the electric trim switch, pull back on the column, or grab the trim wheel, then use the cutout if the behavior reoccurs.

There's something else going on here, possibly confusion over stick shaker/pusher, maybe even split column movements breaking away the link.

There is also the question of whether there was enough time to understand/act before the situation was unrecoverable.

dakota123 wrote:

The SB says to use the electric trim switch, pull back on the column, or grab the trim wheel, then use the cutout if the behavior reoccurs.

There's something else going on here, possibly confusion over stick shaker/pusher, maybe even split column movements breaking away the link.

AirlineCritic wrote:

There is also the question of whether there was enough time to understand/act before the situation was unrecoverable.

zeke wrote:

More the point how do you stop them if you see them moving ?

As the AD and bulletin say, to stop the trim from moving you move the control column to counteract the trimming and/or use the yoke trim switches. Both of these should be fairly easy if you are hand-flying, and I don't see any reason why you couldn't continue flying this way forever, although it would be an absolute nuisance.

-Aircraft begins to trim nose down
-Pilot pulls back on control column to hold attitude which causes automatic trim to stop
-Pilot uses yoke mounted trim switches to relieve control column back pressure
-With aircraft back in trim and control column pressure relieved there is a 5 second delay until the cycle starts over

And it would appear they dealt with the issue this way for probably 7 or so minutes, flying somewhat level at 5000 feet.

The question is, what happened at the end to cause the final steep dive?

https://www.youtube.com/watch?v=ARJ8cAGm6JE

Been there, been warned of that.

dragon6172 wrote:

The question is, what happened at the end to cause the final steep dive?

That is EXACTLY the question. To me, it looks a lot like a stall/spin scenario. They kept it flying at 5000' for a few minutes so it seems they were able to handle the initial problem, which may not have been what ultimately caused the plane to crash, but initiated the sequence of events which led to whatever ultimately caused accident.

Pure speculation but possibly pilots distracted while troubleshooting, let the nose drift down, abrupt pull back stalling the plane. 5000' isn't a lot of room to recover from a deep stall or spin.

Has detailed data been released on the portions of the flight where it abruptly pitches down?

PixelFlight wrote:

One of them is to compute the domain of possible next inputs values given the actual values and state of the system (this is how stateful inspection firewall work for example). In a measuring system, input with impossible values can be filtered out of the redundancy set. In case of an aircraft, it's probably possible to compute the domain of possible next inputs values from the energy state, control surface positions, and external environment given that it will not change abruptly at the sub second scale. Should be very effective against erratic spike like experienced on the QF72.

External environment may change very quickly. Microbursts will cause rapid changing wind direction and speed. Temperature inversions have an effect on several parameters at the same time like SAT, TAT, wind speed and direction as well. Those changes may happen very fast. You look at your airspeed indicator, knowing that an inversion will happen, because other crews reported them, and in a split second, you are 20kts slower or faster. The environment can be extreme. I understand your approach, however developing (air data) systems with an integrity to cover all the external factors still sounds like far away to me.
For position computation a system like the one you described already exists. It is called AIME:
http://www.northropgrumman.com/Capabilities/AIME/Pages/default.aspx

The air data computers itself have a monitoring, which will help discarding wrong computer outputs.

PixelFlight wrote:

There is actually a big focus on deep learning neuronal network to train to predictor the next state of a system given as much of inputs as possible. In case of a aircraft the idea is that a variation of the state is not specific to a single input and so it sensibility is minimized in case it go erratic. It's for example maybe possible to have a big chunk of structural force sensors inside the air frame that react with enough sensibility together to approximate some of the primary sensors values. This is highly speculating, I don't even know is someone plan to do that experimentally. Certifying a such system will be a nightmare, if even possible, as most scientists admit that there don't fully understand how there predictor network is actually working in the details. A rather extreme point of view is to say that we don't fully understand the human brain either, and that indications of a deep learning neuronal network could help making a decision. More and more medical diagnostics try to be improved with this innovative approach.

Sounds innovative, for sure. But you need to make that system reliable, understandable and safe for airplane operation. There is no need for another system with it's own set of specific failures. Moderns aircraft are complex. The abnormal sections in the FCOM gets longer and longer. Unless you fully understand this neuronal network I don't want to have it installed in an airplane.
Unfortunately a lot was learned after airplane crashes, not before.

PixelFlight wrote:

An other way to detect sensors problem is to purposely add a know stimulation to the sensor and to subtract it from the measured values. The stimulation could be continuous; in that case it's designed to have some unique feature that make it easy to recognize and subtract without affecting the desired measuring dynamic. Many RF receivers could be said to work that way because of the local oscillator mix to the input signal. The simulation could be discontinuous. For example many seismic instruments have the capability to inject a periodic test pulse to the sensors. The test pulse is analysed to grant the functionality and calibration of the sensors. It also act as kind of 'ping' in remote deployed sensors network to assert that the sensors it still working as it usually only transmit rare event over a threshold. On a aircraft adding a know stimulation to the sensors would be quit challenging.

This is done already at a certain level. The TAT (Rosemount) probe is used to measure the total air temperature. This will only work if the probe is not full of ice. Therefore the temperature sensing probe is heated. As you know exactly how much energy you put in the probe for heating, you are able to subtract this energy from the measured value and you will get a proper TAT result.
By the way a nice indicator for ice crystal icing. In case the TAT probe will fill up with ice crystals, because there are too many around exceeding the heating capability of the probe, you will get a reading of ±0°C, as the heated probe is measuring the melting point of the ice crystals. So when you are in cirrus clouds and you get a TAT of 0°C all of the sudden, you might experience ice crystal icing. Unfortunately there is no trigger in the TAT system (or flight warning system) that will highlight this sudden change in TAT to the crew. This might be one application possibility of the energy state and value prediction for the future.

PixelFlight wrote:

Last on my list is vision analyzing. A camera monitor the system and the images are processed to measure values to assert the safety of the system. Some high risk machines get new feature like this to protect workers. Maybe the AoA could be monitored that way. Pitot will be more interesting...

A camera gives you an optical image of the probe. You might see that it is bent by a birdstrike for example. But can you see a wrongly installed probe? Are you able to identify, when having different probes, which one is correct? I am not discarding your idea, but I am not convinced so far.

PixelFlight wrote:

If you have a system where essentials sensors could fail, you can add multiple copy of it and/or add alternative sensors or way to evaluate the value (maybe less accurate but sill valuable). Then you can use basic redundantly algorithm or/and use next state predictors to detect and filter out defective sensors.

This is done already. Modern aircraft have 3 or 4 independent sets of pitot, static, AoA, Sideslip probes, TAT an so on. Filtering of defective sensors is already done. Still, computers don't comprehend if there is 1 failed and 2 correct or 2 failed and 1 correct. Of course you put a number x of sensors on a plane and the majority of sensors with the same value wins. But you still have the possibility of all sensors going mad at the same time (Pitot tubes in a volcanic ash environment as an example).

PixelFlight wrote:

One last point, as aircraft control system look more and more like a network of computers, all the network protection and redundancy must apply too: each node act like a sensor for the next nodes.

My answers to your ideas sound totally repellent. Sorry for that. I don't want to be harsh in any way and it sounds like you know your business. On the other hand there are aircraft manufacturers with lots of engineers that know both worlds, aviation and computers (if that is your business). They are constantly researching alternatives to the current designs. However, coming back to unreliable air data, the pitot/static system prevails for a long time already. It looks like there is no easy solution solving unreliable air data.
Still it is good to be open minded. Thinking out of the box is helpful in any case.

Engineering of this sort is inherently conservative. New ideas come along but they need to be studied thoroughly to make sure that they don’t introduce other problems.

I am most curious about the last part of the AD where it says in the event that CUTOFF does not stop the trimming behavior, the pilot can hold the trim wheels to prevent them from moving. They may continue to move uncommanded after pressing CUTOFF?

I want to ask this question again and sorry for dumbing down the conversation..but whatever the technical errors in the pitot tubes or trim system, it seems like the pilots should've been able to hand fly the plane back to the field if they had gone full manual. Without understanding much of what most posts are saying, isn't this what the prior pilot did, and possibly the three before him? A lot of that is unknown right now but it feels like in the final flight the pilots may have been trying to figure out a technical problem and they ran out of room to save themselves by just going manual. I keep thinking that with a recurring problem in prior flights noted in the logs and maintenance documents they should have been anticipating (to some degree) that a similar problem would come up again. I'm not casting blame on the pilots and clearly something was wrong with the instruments or software, but it'll be very interesting, and terrible of course, to listen to the CVR matched against the technical parameters.

All of this made me go back and watch some really great You Tube videos and this is one of my favorites..visually and with very simple explanations how one hand flies a modern jetliner out of very bad stall or AoA situations. I think this is from the SIA Training Center. Not sure if it has any relevance whatsoever to Lion Air but still incredible to see how counter intuitive the solution is to a nose down stall or inverting corkscrew. At one point the Captain makes the comment about glider flying and how that gives pilots valuable experience in recovery situations. It reminded me of Sully's comments of course.
http://www.youtube.com/watch?v=OasrxfOvPr8

Wouldnt the recovered black box have all the pilot inputs recorded in detail ? The CVR would have only the cockpit reactions.
Isn't the flight recorder enough for piecing together the problems and what inputs the pilots gave and when ?
Or are their inputs and readings which are not recorded by the flight recorder ?

JoeCanuck wrote:

Pure speculation but possibly pilots distracted while troubleshooting, let the nose drift down, abrupt pull back stalling the plane. 5000' isn't a lot of room to recover from a deep stall or spin.

Yes. Or, alternatively, started a turn back to the airport and without speed information, and fighting other systems, stalled the plane.

My personal view is it's workload/ distraction from all the errors combined with this auto-trim feature continuously restarting thats got them into trouble here.

The pilots detected and stopped the trim twice (noting at least two dips in altitude) but then distracted by the other issues, missed it until too late the third time.

Hopefully they find the CVR in the mud soon.

While not a pilot, I’ve done training in OS administration where you need a new certification for a new version release and there are fundamental changes to trouble shooting between the versions. (Edit: even if from the user point of view things don’t seem very different)

My gut says that the pilots were not trained well enough on the differences between the NG and the Max and this was the sad result. This may also be why the FAA won’t allow pilots to be type certified on 737 classic, NG and Max at the same time. When the shiiite hits the fan, keeping track of the differences could kill you and many other people.

AirlineCritic wrote:

JoeCanuck wrote:

Pure speculation but possibly pilots distracted while troubleshooting, let the nose drift down, abrupt pull back stalling the plane. 5000' isn't a lot of room to recover from a deep stall or spin.

Yes. Or, alternatively, started a turn back to the airport and without speed information, and fighting other systems, stalled the plane.

Were the airspeed indicators working? Also what was the weather like? If they were in IMC, losing spatial orientation is a real danger, especially if you're not confident of the accuracy of your instruments.

ikramerica wrote:

While not a pilot, I’ve done training in OS administration where you need a new certification for a new version release and there are fundamental changes to trouble shooting between the versions. (Edit: even if from the user point of view things don’t seem very different)

My gut says that the pilots were not trained well enough on the differences between the NG and the Max and this was the sad result. This may also be why the FAA won’t allow pilots to be type certified on 737 classic, NG and Max at the same time. When the shiiite hits the fan, keeping track of the differences could kill you and many other people.

I don't think the "differences" had anything to do with it.

The FAA wouldn't let SWA pilots fly the New Gen (300/400/500), Next Gen and Maxes so SWA retired the New Gen's first but the 737 is a single type FAA endoresment from the -100 thru the -900 "B737" (on my license) and I'm guessing the Max is included.

Re: pilot inputs ...

They have the FDR, and that's where control inputs (and all the other data points) are recorded. MAX being brand new, there's likely an ungodly number of parameters in that thing. Instrumentation has come a long, long, way since the first 737 took to the air.

CVR they're still looking for; that's key for audible sounds/speech from the cockpit (hence the name "Cockpit Voice Recorder")

(we should all know this, right? maybe?)

That one could be interesting, because with a 2 hour recording length, it might have a bunch of the previous flight still on it.

7BOEING7 wrote:

ikramerica wrote:

While not a pilot, I’ve done training in OS administration where you need a new certification for a new version release and there are fundamental changes to trouble shooting between the versions. (Edit: even if from the user point of view things don’t seem very different)

My gut says that the pilots were not trained well enough on the differences between the NG and the Max and this was the sad result. This may also be why the FAA won’t allow pilots to be type certified on 737 classic, NG and Max at the same time. When the shiiite hits the fan, keeping track of the differences could kill you and many other people.

I don't think the "differences" had anything to do with it.

The FAA wouldn't let SWA pilots fly the New Gen (300/400/500), Next Gen and Maxes so SWA retired the New Gen's first but the 737 is a single type FAA endoresment from the -100 thru the -900 "B737" (on my license) and I'm guessing the Max is included.

There are certainly times when the little differences will catch you out. You've done the differences course and so on, but familiarity and recency count. Certainly not saying there is a danger to the operation, but flying multiple variants/types isn't without its little traps. (I fly two similar types on a common rating.)

michi wrote:

External environment may change very quickly. Microbursts will cause rapid changing wind direction and speed. Temperature inversions have an effect on several parameters at the same time like SAT, TAT, wind speed and direction as well. Those changes may happen very fast. You look at your airspeed indicator, knowing that an inversion will happen, because other crews reported them, and in a split second, you are 20kts slower or faster.

The engine power settings and control surfaces positions move slowly compared to the inputs sensors sampling rate, so there is a inherent limitation on how fast you can react to a changing environment, with or without predictor.

michi wrote:

For position computation a system like the one you described already exists. It is called AIME:
http://www.northropgrumman.com/Capabilities/AIME/Pages/default.aspx

Good to know. Thanks for the link.

michi wrote:

The air data computers itself have a monitoring, which will help discarding wrong computer outputs.

QF72 have show that a defective unit can produce anything beyond anyone understand and still tag them as valid. While self integrity test are required, there are not enough. Data validation must be done also at each inputs of the next unit, taking advantage of the redundancy of the previous units and maybe predictors.

michi wrote:

Sounds innovative, for sure. But you need to make that system reliable, understandable and safe for airplane operation. There is no need for another system with it's own set of specific failures. Moderns aircraft are complex. The abnormal sections in the FCOM gets longer and longer. Unless you fully understand this neuronal network I don't want to have it installed in an airplane.
Unfortunately a lot was learned after airplane crashes, not before.

I bet that there will be a grey area about this in the future. Common failure mode raise a lot of concern from the safety point of view. Having multiple mode of measurement is a way to not have a common failure mode. There is a reason why there is standby instruments into each cockpit. I would be very exciting on a project that try to use a neuronal network to estimate basic parameters from the wings structural forces. Sure this will be imperfect, but there is no future for machines that suddenly switch from full automation to a Christmas tree inside the cockpit, with unreliably indications, full log of errors, uncommended action, and expecting that a pilot will magically aviate, navitage, communicate, and fix all the mess quickly will full respect to all the published documents. There is a need of progressive degradation of the inputs sensors and computation to allow a more manageable share between the automation that can still reliably work, and the human pilot workload. The Airbus BUSS is a step into that direction. I think there will be more system like this, because there is no point to no automate failure reaction and expect pilot to act like an automate implementing rigid rules documented somewhere. If Boeing confirm that the last EAD is the only way to act, then this way must be automated to keep the pilot in a workable load.

michi wrote:

A camera gives you an optical image of the probe. You might see that it is bent by a birdstrike for example. But can you see a wrongly installed probe? Are you able to identify, when having different probes, which one is correct? I am not discarding your idea, but I am not convinced so far.

I agree that it's a silly example. But as new aircraft get more and more cameras, some data could be extracted from them to assert some states. Images from doors, engines, control surfaces, gears, could help the pilot to quickly understand anomaly. Given the today memory capabilities, I think that someday the video streams, including the cockpit displays images, will be recorded aside of the FDR and CVR.

michi wrote:

This is done already. Modern aircraft have 3 or 4 independent sets of pitot, static, AoA, Sideslip probes, TAT an so on. Filtering of defective sensors is already done. Still, computers don't comprehend if there is 1 failed and 2 correct or 2 failed and 1 correct. Of course you put a number x of sensors on a plane and the majority of sensors with the same value wins. But you still have the possibility of all sensors going mad at the same time (Pitot tubes in a volcanic ash environment as an example).

The way it's done yet in the aviation industry is conservative. Basically it try to have some reliability with simple designs and in case this fail it give everything up to the pilot. The early nuclear industry failed that way. Now there require that in every circumstance the system will fully automatically go into a safe stop. Yes it's very hard to automatically safe landing an aircraft in every circumstance but it's where a system that can learn millions of scenarios without forgetting anything and able of analyzing quickly thousand of parameters continually could help. I have heard that Boeing might have some peoples thinking about a concept like this. When peoples will in the future routinely uses autonomous cars and robots like Boston Dynamics try to do, there will found strange that aircraft will not uses the same kind of technology.

michi wrote:

My answers to your ideas sound totally repellent. Sorry for that. I don't want to be harsh in any way and it sounds like you know your business. On the other hand there are aircraft manufacturers with lots of engineers that know both worlds, aviation and computers (if that is your business). They are constantly researching alternatives to the current designs. However, coming back to unreliable air data, the pitot/static system prevails for a long time already. It looks like there is no easy solution solving unreliable air data.
Still it is good to be open minded. Thinking out of the box is helpful in any case.

No problem for constructive criticisms
The aviation industry have achieved a fantastic numbers of historical milestone in about a century, and will continue to go forward. When some technologies have reach there limitation, the industry will use a new technologies. Think how it was perceived back when the first guys installed hydraulic inside an aircraft, or jet engine, or FBW, or glass cockpit, etc.. So many risky additional stuff that precedent aircraft never needed, but so normal today.

litz wrote:

Re: pilot inputs ...

They have the FDR, and that's where control inputs (and all the other data points) are recorded. MAX being brand new, there's likely an ungodly number of parameters in that thing. Instrumentation has come a long, long, way since the first 737 took to the air.

CVR they're still looking for; that's key for audible sounds/speech from the cockpit (hence the name "Cockpit Voice Recorder")

(we should all know this, right? maybe?)

That one could be interesting, because with a 2 hour recording length, it might have a bunch of the previous flight still on it.

My point was that though the CVR is helpful , eventually its the recorded readings ,auto or manual, the inputs the pilots give to the plane, the reaction of the plane to the inputs, the timings of the input, etc , are the reason the plane flew into the ground.
And all these are already available with the investigating team from the FDR.
BUT
Suppose as discussed before, the pilots got distracted after they had levelled the flight at 5000 ft and the plane stalled , the plane speed will still be the one its getting from the pitot tube , which might be wrong , so what conclusion can they come to ? Was the pilot wrong for assuming the plane was at a correct speed based on his instruments and stalled the plane ? What other indicators could he have used ?

7BOEING7 wrote:

ikramerica wrote:

While not a pilot, I’ve done training in OS administration where you need a new certification for a new version release and there are fundamental changes to trouble shooting between the versions. (Edit: even if from the user point of view things don’t seem very different)

My gut says that the pilots were not trained well enough on the differences between the NG and the Max and this was the sad result. This may also be why the FAA won’t allow pilots to be type certified on 737 classic, NG and Max at the same time. When the shiiite hits the fan, keeping track of the differences could kill you and many other people.

I don't think the "differences" had anything to do with it.

The FAA wouldn't let SWA pilots fly the New Gen (300/400/500), Next Gen and Maxes so SWA retired the New Gen's first but the 737 is a single type FAA endoresment from the -100 thru the -900 "B737" (on my license) and I'm guessing the Max is included.

Please explain why what you wrote in any way contradicts what I said? If differences don’t matter then why do they care about the differences so much that you can’t be rated in all 3 gens?

Sounds like 73m flight control design is an incoherent mess...

A single point of failure (one failed AOA probe out of two AOA probes) is allowed to propagate failure to system with pitch authority. There is no fault accommodation it seems.
There is AOA disagree warning, but it appears there is no actual proper safety rated correlation check between two AOA channels. In that case single AOA failure causing pitch issue is not even the biggest problem. The single AOA probe failure can become undetected and hence latent failure. When the second AOA probe fails, correlation check (if present) between AOA probes may not catch the second failure. Now you have an undetectable total AOA sensing system failure, no opportunity to accommodate fault!

SomebodyInTLS wrote:

PixelFlight wrote:

The way it's done yet in the aviation industry is conservative. Basically it try to have some reliability with simple designs and in case this fail it give everything up to the pilot. The early nuclear industry failed that way. Now there require that in every circumstance the system will fully automatically go into a safe stop. Yes it's very hard to automatically safe landing an aircraft in every circumstance but it's where a system that can learn millions of scenarios without forgetting anything and able of analyzing quickly thousand of parameters continually could help. I have heard that Boeing might have some peoples thinking about a concept like this. When peoples will in the future routinely uses autonomous cars and robots like Boston Dynamics try to do, there will found strange that aircraft will not uses the same kind of technology.

The thing is that the certification process and the authorities are all very very conservative, as are the pilots and their unions. I agree with you that we're approaching a point where it might be better to change philosophy with respect to automation handing over to the pilots during events... but that smacks too much of man versus machine for many people. It will take a few more accidents such as this and AF447 before the question of automation handling upsets can even be approached in a meaningful way.

And that brings with it the spectre of fully automated, pilotless aircraft...

When it’s a question of erroneous data shouldn’t there be a more obvious way to A: be made aware of it and B: disengage ALL automations so the pilots can fly the plane into a safe position before troubleshooting? In AF and this crash it seems as if the pilots are fighting against deeper level automation that they weren’t quite aware of.

7BOEING7 wrote:

ikramerica wrote:

While not a pilot, I’ve done training in OS administration where you need a new certification for a new version release and there are fundamental changes to trouble shooting between the versions. (Edit: even if from the user point of view things don’t seem very different)

My gut says that the pilots were not trained well enough on the differences between the NG and the Max and this was the sad result. This may also be why the FAA won’t allow pilots to be type certified on 737 classic, NG and Max at the same time. When the shiiite hits the fan, keeping track of the differences could kill you and many other people.

I don't think the "differences" had anything to do with it.

Well, it seems the FAA may not be on the same page.

If these differences had nothing to do with this, surely there would no reason for this Airworthiness Directive not to apply to NG models?

Redundancy was and is the credo of aviation.

The recent cases with the AOA -Sensors and the Pitot-Tubes show that the redundancy can also become a curse.

From a certain number of identical sensors, the reliability is no longer higher because the processing of the data of these many sensors is becoming increasingly complex.

In the case of sensors relevant to flight, in the case of unclear or deviating sensor values, attempts should not be made to provide the pilots with the best possible data and thus contribute to an accident in the worst case, but the automation should step back from the control of the machine in a graduated form at the request of a pilot.

For the further control of the aircraft, however, the pilot must then have alternative data on attitude, altitude and speed available.

A GPS-based emergency control unit could display the current altitude, the altitude change, the speed and the speed change as well as the direction of flight at a non-interfering position in front of each pilot independently of each other and independent of the actual flight sensors.

GPS is not 100% reliable and at least as far as the altitude is concerned, it is not accurate enough to fly with it. But it is by far enough as a handy tool for a pilot to stabilize a plane in unclear attitude and height and to start the troubleshooting of the actual problem.

PW100 wrote:

7BOEING7 wrote:

ikramerica wrote:

While not a pilot, I’ve done training in OS administration where you need a new certification for a new version release and there are fundamental changes to trouble shooting between the versions. (Edit: even if from the user point of view things don’t seem very different)

My gut says that the pilots were not trained well enough on the differences between the NG and the Max and this was the sad result. This may also be why the FAA won’t allow pilots to be type certified on 737 classic, NG and Max at the same time. When the shiiite hits the fan, keeping track of the differences could kill you and many other people.

I don't think the "differences" had anything to do with it.

Well, it seems the FAA may not be on the same page.

If these differences had nothing to do with this, surely there would no reason for this Airworthiness Directive not to apply to NG models?

At the time the MAX was certified, Boeing, the FAA and EASA all agreed on the differences training required so the pilots were "trained well enough" which was what my reply was to. Nobody felt they needed anymore information. A question would be, in the certification process was an erroneous AOA with pitch down trim assumed to be identified as a "runaway stabilizer" by the flight crew?

I agree there are differences betwenn the NG and the MAX, however the procedures remain the same. If you have a "runaway stabilizer" you carry out the same procedures on the NG and the MAX (per AD). The AD only expands on the information provided. It will be interesting to see what if any of that information makes it into the FCOM/QRH.

Does the FDR collect 100% 'real' data?

Last year I had a car engine problem in one cylinder. The dealer and manufacturer argued the vehicle temperature gauge would have have read high before failure, so by not stopping I magnified the cost of repair.

I hired an expert third party, who really knew his cars. The engine had 4 cylinders, but only one actually had a temperature sensor. Using the temperature from the one cylinder (the hottest running - number 3), plus coolant and oil temperature, the ECU predicted the temperatures of the other three.

ECU data extracted by the manufacturer and my expert showed temperature data for all four cylinders was normal (so the gauge did not reveal an impending fault), but only one temperature value was 'real'.

For older generation aircraft receiving model updates, presumably operating a combination of digital, analogue and mechanical components, is every FDR source 'real'?

wingman wrote:

I want to ask this question again and sorry for dumbing down the conversation..but whatever the technical errors in the pitot tubes or trim system, it seems like the pilots should've been able to hand fly the plane back to the field if they had gone full manual. Without understanding much of what most posts are saying, isn't this what the prior pilot did, and possibly the three before him?

I don't think this has been answered definitively but it's been implied. But it's not clear to me that the prior pilots had the exact same problem; the reports I've seen said they had unreliable airspeed, whereas this flight had an AOA sensor problem. I'm not sure if it's just a terminology conflation or if it was really two separate problems. (Or if all flights had both problems.)

The basic thrust of the current investigative track seems to be that the 737 MAX has this AOA protection built in that may cause a pitchover when fed erroneous data, but that the pilots should be able to counteract it. Why this particular crew was unable to do that at the end of this flight seems to be the most important question right now.

I think dragon6172's response above about the process for flying under these conditions, assuming he's got it right (and I have no reason to think otherwise), seems like the best summary I've seen of what the crew was probably dealing with.

7BOEING7 wrote:

At the time the MAX was certified, Boeing, the FAA and EASA all agreed on the differences training required so the pilots were "trained well enough" which was what my reply was to. Nobody felt they needed anymore information. A question would be, in the certification process was an erroneous AOA with pitch down trim assumed to be identified as a "runaway stabilizer" by the flight crew?

OK I see where you're coming from. Makes an awful lot of sense now to me.
Thanks for clarifying.

spacecadet wrote:

737 MAX has this AOA protection built in that may cause a pitchover when fed erroneous data, but that the pilots should be able to counteract it. Why this particular crew was unable to do that at the end of this flight seems to be the most important question right now.

And in my mind this comes back to the fact that this system seemingly can't be switched off, it will seemingly reactivate every 10secs if the data is still erroneous.

Did the pilots think they had dealt with this issue and move onto other tasks/ alerts, only to get caught out again.

ikramerica wrote:

In AF and this crash it seems as if the pilots are fighting against deeper level automation that they weren’t quite aware of.

While we don't yet know what happened with the Lion crash, let's be clear about AF447 - all those people died because the crew did not follow SOP, totally threw CRM out the window and displayed a shocking lack of basic airmanship . A situation that is commonplace around the World on an almost daily basis and is completely recoverable became a shocking disaster.

If automation is going to take control of the plane even with erroneous data, it might be time to add more data points. 5 pitot tubes at various places. 3 AoA sensors. Why?

The computer can then warn the pilots that one AoA (or 1 or 2 pitot) is failing but the computer can also be confident that the remaining sensors are accurate based on parity. And if none match then it can also know that nothing can be trusted and warn the pilots of well and disconnect automation.

Current aircraft design seems to be adapting manual flying era designs from half a century ago to the modern computer age rather than starting from the question “of this were designed to be flown by a modern powerful computer from day 1, what would we want and need?”

Just having a backup without proper parity checking seems to be a problem we see again and again.

In computer terms, you need mirroring and parity. 2 pairs of mirrored pitots plus a parity pitot tube. 1 pair of mirrored AoA sensors plus a parity sensor. When data integrity with no downtime is critical, this is the way to get it.

asdf wrote:

Redundancy was and is the credo of aviation.

The recent cases with the AOA -Sensors and the Pitot-Tubes show that the redundancy can also become a curse.

From a certain number of identical sensors, the reliability is no longer higher because the processing of the data of these many sensors is becoming increasingly complex.

In the case of sensors relevant to flight, in the case of unclear or deviating sensor values, attempts should not be made to provide the pilots with the best possible data and thus contribute to an accident in the worst case, but the automation should step back from the control of the machine in a graduated form at the request of a pilot.

For the further control of the aircraft, however, the pilot must then have alternative data on attitude, altitude and speed available.

A GPS-based emergency control unit could display the current altitude, the altitude change, the speed and the speed change as well as the direction of flight at a non-interfering position in front of each pilot independently of each other and independent of the actual flight sensors.

GPS is not 100% reliable and at least as far as the altitude is concerned, it is not accurate enough to fly with it. But it is by far enough as a handy tool for a pilot to stabilize a plane in unclear attitude and height and to start the troubleshooting of the actual problem.

GPS can do quite a bit better. Three antenna systems can give you very accurate point, yaw, pitch. roll, and rates of, and a much better altitude than given credit for with high quality units. The data errors from the sats that cause most of the inaccuracy re irrelevant because all three antennas are getting the same data, so errors cancel out. They don't need absolute accuracy. Only position relative to each other.

ikramerica wrote:

In computer terms, you need mirroring and parity. 2 pairs of mirrored pitots plus a parity pitot tube. 1 pair of mirrored AoA sensors plus a parity sensor. When data integrity with no downtime is critical, this is the way to get it.

raising the numbers of sensors is not the solution
if there is a reason why three sensors can fail at the same time, then theres is no reason why not even five sensors could fail
and it doesnt help if you have a failure in a common part of the datastream and there always is one where the redundanz ends

it needs to be a complete other system to keep the pilots shure to thrust on the data and GPS could be one

3 sensors
1 sensor fails
2 sensors give same data
pilots only get the info about the degradation of redundance but thats it

3 sensors
non of the sensors give reliable data
pilots gets information about unreliable data
GPS backup control display lights up on both sides
and pilots are asked to take manual control

spacecadet wrote:

But it's not clear to me that the prior pilots had the exact same problem; the reports I've seen said they had unreliable airspeed, whereas this flight had an AOA sensor problem. I'm not sure if it's just a terminology conflation or if it was really two separate problems. (Or if all flights had both problems.)

This brings up a few questions. In a situation where there is both unreliable speed and unreliable AoA,

- did the crew recognise one or both problems and would the last maintenance write-up have influenced their expectations of whatever trouble this aircraft might bring them
- did they complete the checklists as they moved on to other issues
- did they get lulled into a false sense of security that everything was stabilised when the other problem crept up unbeknownst to them

ikramerica wrote:

If automation is going to take control of the plane even with erroneous data, it might be time to add more data points. 5 pitot tubes at various places. 3 AoA sensors. Why?

The computer can then warn the pilots that one AoA (or 1 or 2 pitot) is failing but the computer can also be confident that the remaining sensors are accurate based on parity. And if none match then it can also know that nothing can be trusted and warn the pilots of well and disconnect automation.

In one of his posts up-thread, michi implied that this would still cause doubt. And I followed up with an example of an A320 crash where the computer accepted erroneous data from 2 frozen AoA sensors (were in agreement with each other) and rejected the 3rd sensor which had the correct values despite disagreeing with the other two.

Erebus wrote:

spacecadet wrote:

But it's not clear to me that the prior pilots had the exact same problem; the reports I've seen said they had unreliable airspeed, whereas this flight had an AOA sensor problem. I'm not sure if it's just a terminology conflation or if it was really two separate problems. (Or if all flights had both problems.)

This brings up a few questions. In a situation where there is both unreliable speed and unreliable AoA,

- did the crew recognise one or both problems and would the last maintenance write-up have influenced their expectations of whatever trouble this aircraft might bring them
- did they complete the checklists as they moved on to other issues
- did they get lulled into a false sense of security that everything was stabilised when the other problem crept up unbeknownst to them

ikramerica wrote:

If automation is going to take control of the plane even with erroneous data, it might be time to add more data points. 5 pitot tubes at various places. 3 AoA sensors. Why?

The computer can then warn the pilots that one AoA (or 1 or 2 pitot) is failing but the computer can also be confident that the remaining sensors are accurate based on parity. And if none match then it can also know that nothing can be trusted and warn the pilots of well and disconnect automation.

In one of his posts up-thread, michi implied that this would still cause doubt. And I followed up with an example of an A320 crash where the computer accepted erroneous data from 2 frozen AoA sensors (were in agreement with each other) and rejected the 3rd sensor which had the correct values despite disagreeing with the other two.

S--t happens but that's why we still have pilots on the airplane. Like your example where the frozen AOA vanes were one link in the chain of events (the other three were flight crew related) I'm guessing we'll find the flight crew will share some blame in this event.

moa999 wrote:

And in my mind this comes back to the fact that this system seemingly can't be switched off, it will seemingly reactivate every 10secs if the data is still erroneous.

But it can be switched off -- with stabilizer trim cutoff switches located to hand on the pedestal. The fact that Boeing quickly issued a bulletin and the FAA issued an emergency AD reminding flight crews of that strongly suggests that they know that the accident crew failed, for whatever reason, to follow the procedure.