Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
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?
Turn off the stab trim. Avoid unusually high AoA. Is that too complicated?
Join Date: Dec 2018
Location: Dundee
Posts: 2
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: Mar 2015
Location: North by Northwest
Posts: 476
Likes: 0
Received 0 Likes
on
0 Posts
Apparently not for one crew - but too much for the last crew.
Join Date: Sep 2018
Location: Laredo, TX
Posts: 133
Likes: 0
Received 0 Likes
on
0 Posts
Where has Boeing told us what to avoid if you lose MCAS due to using the cutout switches for an abnormal? We can deduce high AOA past stick shaker from this thread. Is the probability of a wind shear escape maneuver still in the clean config after having an abnormal that disables MCAS so remote that Boeing doesn't need to mention it? It would be a rare occurrence. So would be the rare combination of an MCAS failure and a crew lacking airmanship which we really can't judge until the CVR is made public.
Last edited by jimtx; 18th Feb 2019 at 01:15.
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...
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...
Join Date: Apr 2008
Location: WA
Age: 84
Posts: 23
Likes: 0
Received 0 Likes
on
0 Posts
b1lanc— “Apparently not for one crew - but too much for the last crew”
Think I recall RON mx was done involving the flt control system before the ship was flown for the last time. Therefore, in some ways, some more subtle and impactful than others, the “day shift” did not inherit exactly the same airplane as was delivered the night before. I’d say it’s premature to conclude that the fatal crew faced exactly the same circumstances as those dealt with previously, or, especially, they were something less than professional. I believe the prior day crew most certainly would have pitched a radically different log squawk if things had developed anywhere close to those presented on 610’s short flight. A proper test flight by a fully briefed crew prepared to deal with possible control issues most likely have resulted in a better outcome. Maybe this crew, heaven forbid, would have even been informed of the existence of MCAS...or maybe even how it worked!
Think I recall RON mx was done involving the flt control system before the ship was flown for the last time. Therefore, in some ways, some more subtle and impactful than others, the “day shift” did not inherit exactly the same airplane as was delivered the night before. I’d say it’s premature to conclude that the fatal crew faced exactly the same circumstances as those dealt with previously, or, especially, they were something less than professional. I believe the prior day crew most certainly would have pitched a radically different log squawk if things had developed anywhere close to those presented on 610’s short flight. A proper test flight by a fully briefed crew prepared to deal with possible control issues most likely have resulted in a better outcome. Maybe this crew, heaven forbid, would have even been informed of the existence of MCAS...or maybe even how it worked!
Join Date: Feb 2019
Location: shiny side up
Posts: 431
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Reading all of this from a laymans perspective, it appears to be very simple, the aircraft malfunctioned.
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.
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.
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.
Plastic PPRuNer
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
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
Join Date: Dec 2018
Posts: 48
Likes: 0
Received 0 Likes
on
0 Posts
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
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
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.
Last edited by pilot9250; 21st Feb 2019 at 02:07.
Join Date: Mar 2014
Location: WA STATE
Age: 78
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
the deep flaw in the human-machnie interface seems to be that they forgot to tell human that this specific interface exists.
Join Date: Sep 2018
Location: Laredo, TX
Posts: 133
Likes: 0
Received 0 Likes
on
0 Posts
If the pilots thought the trim was input by the STS they might not think it was uncommanded. Nobody flying the 737 goes to stab trim cutout on takeoff when the STS trims up. They trim against it.
Paxing All Over The World
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Mar 2002
Location: London, UK
Posts: 437
Likes: 0
Received 0 Likes
on
0 Posts
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.