Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed

Old 17th Feb 2019, 02:45
  #81 (permalink)  
 
Join Date: Dec 2001
Location: Brisvegas
Posts: 2,558
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?
Icarus2001 is offline  
Old 17th Feb 2019, 14:27
  #82 (permalink)  
 
Join Date: Feb 2019
Location: shiny side up
Posts: 43
MCAS is on all MAX variants.
Smythe is offline  
Old 17th Feb 2019, 22:56
  #83 (permalink)  
 
Join Date: Dec 2018
Location: Dundee
Posts: 1
Originally Posted by Icarus2001 View Post
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?
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..
weemonkey is offline  
Old 17th Feb 2019, 23:16
  #84 (permalink)  
 
Join Date: Mar 2015
Location: North by Northwest
Posts: 276
Originally Posted by Icarus2001 View Post
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?
Apparently not for one crew - but too much for the last crew.
b1lanc is offline  
Old 18th Feb 2019, 00:57
  #85 (permalink)  
 
Join Date: Sep 2018
Location: Laredo, TX
Posts: 81
Originally Posted by Icarus2001 View Post
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?
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.
jimtx is online now  
Old 18th Feb 2019, 03:41
  #86 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 76
Posts: 923
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...
gums is online now  
Old 18th Feb 2019, 06:53
  #87 (permalink)  
 
Join Date: Apr 2008
Location: WA
Age: 79
Posts: 21
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!
radken is offline  
Old 18th Feb 2019, 16:26
  #88 (permalink)  
 
Join Date: Feb 2019
Location: shiny side up
Posts: 43
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.
Smythe is offline  
Old 19th Feb 2019, 07:42
  #89 (permalink)  
fdr
 
Join Date: Jun 2001
Posts: 458
Originally Posted by Smythe View Post
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.
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 is offline  
Old 19th Feb 2019, 13:37
  #90 (permalink)  

Plastic PPRuNer
 
Join Date: Sep 2000
Location: Cape Town
Posts: 1,852
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

Mac the Knife is offline  
Old 21st Feb 2019, 01:41
  #91 (permalink)  
 
Join Date: Dec 2018
Location: Nyc
Posts: 11
Originally Posted by Mac the Knife View Post
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.

Last edited by Turbine70; 21st Feb 2019 at 02:07.
Turbine70 is offline  
Old 21st Feb 2019, 02:33
  #92 (permalink)  
 
Join Date: Aug 2008
Location: Moscow
Age: 39
Posts: 33
Turbine70, the deep flaw in the human-machnie interface seems to be that they forgot to tell human that this specific interface exists.
AlexGG is offline  
Old 21st Feb 2019, 03:42
  #93 (permalink)  
Paxing All Over The World
 
Join Date: May 2001
Location: Hertfordshire, UK.
Age: 62
Posts: 8,719
How many of this 73 Max variant are currently in service?
PAXboy is offline  
Old 21st Feb 2019, 04:31
  #94 (permalink)  
 
Join Date: Mar 2014
Location: WA STATE
Age: 73
Posts: 1
Originally Posted by PAXboy View Post
How many of this 73 Max variant are currently in service?
Boeing 737 Orders and Deliveries

in service/delivered about 330
CONSO is offline  
Old 21st Feb 2019, 05:54
  #95 (permalink)  
 
Join Date: Dec 2001
Location: Brisvegas
Posts: 2,558
the deep flaw in the human-machnie interface seems to be that they forgot to tell human that this specific interface exists.
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.
Icarus2001 is offline  
Old 21st Feb 2019, 10:42
  #96 (permalink)  
 
Join Date: Sep 2018
Location: Laredo, TX
Posts: 81
Originally Posted by Icarus2001 View Post
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.
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.
jimtx is online now  
Old 21st Feb 2019, 11:53
  #97 (permalink)  
Paxing All Over The World
 
Join Date: May 2001
Location: Hertfordshire, UK.
Age: 62
Posts: 8,719
CONSO
in service/delivered about 330
Originally Posted by Smythe View Post
MCAS is on all MAX variants.
And this is the first time the problem has occurred? What checks are being made across the fleet? Is there a directive out?
PAXboy is offline  
Old 21st Feb 2019, 12:31
  #98 (permalink)  
 
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,199
Originally Posted by jimtx View Post


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.
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.
Ian W is online now  
Old 21st Feb 2019, 16:05
  #99 (permalink)  
 
Join Date: Dec 2018
Location: Dundee
Posts: 1
Great advice.
weemonkey is offline  
Old 21st Feb 2019, 22:47
  #100 (permalink)  
 
Join Date: Mar 2002
Location: London, UK
Posts: 426
Originally Posted by Ian W View Post
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.
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>
RomeoTangoFoxtrotMike is offline  

Thread Tools
Search this Thread

Contact Us Archive Advertising Cookie Policy Privacy Statement Terms of Service

Copyright 2018 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.