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 24th Mar 2019, 15:22
  #361 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,122
Originally Posted by silverstrata View Post
Another reason for all modern engines being a long way forward, is so that ‘fly-away’ blades do not go straight through the wing.
With a 4-engined aircraft, you don't have much choice.
DaveReidUK is offline  
Old 24th Mar 2019, 15:33
  #362 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 5,016
Originally Posted by silverstrata View Post


Another reason for all modern engines being a long way forward, is so that ‘fly-away’ blades do not go straight through the wing. (JT8D blades were much smaller, and the diameter if the engine was smaller too).
You might make a case for the turbine stages being under the wing, but you don’t want the N1 or compressor blades under the wing.

Silver
You typically put the engine where it's best for flying the aircraft and later design the wing fuel tanks out of harms way. Holes in wings are not a big deal

In other words design an efficient aircraft first and assess and minimize, mitigate, or shield against damage later
lomapaseo is offline  
Old 24th Mar 2019, 16:19
  #363 (permalink)  
 
Join Date: Oct 2004
Location: NY - USA
Age: 63
Posts: 64
Originally Posted by GordonR_Cape View Post
b1lanc



AOA is not valid without forward airspeed, so it would require a special setup to test AOA disagree before takeoff.
On the ground, the AOA vanes are likely to be in random positions, and can certainly move anywhere from full up to full down if the winds are gusty. As you point out, AOA sensor data is ignored by whatever onboard systems may make use of it until the aircraft is actually airborne.
JRBarrett is offline  
Old 24th Mar 2019, 16:30
  #364 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,056
Software, Hardware

Considering the current views on software problems, does this only relate to the ‘numbers’ (bits), which might have been contained with better choice of software design, or does this also involve an external ‘glitch’, interference or hardware fault.

In the first instance, revising the software should solve the problem (but also involving many ‘wise’ system interface and logic changes - after the fact).
However, with external influence, it would be necessary to first identify the problem in order to created a proven certification solution. How else would we know that software / logic changes would resist external influence if we don’t know what the influence is.
Much of this depends on what has been found during investigation. Software, with hindsight can be matched with many situations to deduce cause, it leaves no trace at the accident site, but bits and pieces in a field less so.
alf5071h is offline  
Old 24th Mar 2019, 16:42
  #365 (permalink)  
 
Join Date: Mar 2015
Location: North by Northwest
Posts: 335
Originally Posted by JRBarrett View Post


On the ground, the AOA vanes are likely to be in random positions, and can certainly move anywhere from full up to full down if the winds are gusty. As you point out, AOA sensor data is ignored by whatever onboard systems may make use of it until the aircraft is actually airborne.
Still doesn't answer my question. The Lion flight prior to the crash flight clearly had an AoA disagree event when airborne. Does that generate a MAINT event which survives shutdown and then presents an annunciation on the FO side ND during pre-flight to the next crew?
b1lanc is offline  
Old 24th Mar 2019, 17:38
  #366 (permalink)  
 
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,265
Originally Posted by fergusd View Post
The mitigation for this issue seems to be that the pilots will realise what is going on and switch the failed system off. This is the oldest trick in the safety case book . . . and regulators in _many_ safety related/critical industries allow the 'human will figure it out' mitigation to be used . . . and in many cases it doesn't because people are tired, bored, stressed, having a bad day, fallible . . .

This is a regulatory failure pure and simple. The safety case would make interesting reading. As would the one for the 'fix' . . .
Systems in all modern aircraft will eventually hand the bag of bolts to the pilot if they cannot make sense of what is happening or there is some occurrence they have not been programmed to respond to. This is because it is cheaper to develop systems that deal with the monotonous tasks and hand non-routine/non-nominal to the pilots (you call it a trick in the safety case book, it is in fact standard practice). It is now becoming obvious as you state above that the assumption that the pilot can handle things is not a safe assumption. For this reason systems are being programmed that are capable of handling the non-routine that the pilots can no longer be expected to handle. These are expensive systems to create as they are safety critical and the certification is long and expensive. However, flight crew are expensive too - so more and more aircraft systems are being designed that handle the majority of non-nominal cases. These systems are counter productive in that the flight crew now get even less hands on time and when they do get it their lack of currency shows - so back around the loop building software that will cope with more non-nominal events.
Eventually, the probability of the pilot being needed AND being capable of solving the problems will pass a point where the safety case can be met more successfully by automation. That point is closer than people would think. As soon as that point is reached AND the lifecycle costs of generating and flying operationally with the certified software is less than the cost of employing pilots, autonomous aircraft will become more widespread than they are now.

Last edited by Ian W; 24th Mar 2019 at 17:39. Reason: grammar
Ian W is offline  
Old 24th Mar 2019, 18:44
  #367 (permalink)  
 
Join Date: Jun 2009
Location: UK
Posts: 74
Originally Posted by Ian W View Post
Systems in all modern aircraft will eventually hand the bag of bolts to the pilot if they cannot make sense of what is happening or there is some occurrence they have not been programmed to respond to. This is because it is cheaper to develop systems that deal with the monotonous tasks and hand non-routine/non-nominal to the pilots (you call it a trick in the safety case book, it is in fact standard practice). It is now becoming obvious as you state above that the assumption that the pilot can handle things is not a safe assumption. For this reason systems are being programmed that are capable of handling the non-routine that the pilots can no longer be expected to handle. These are expensive systems to create as they are safety critical and the certification is long and expensive. However, flight crew are expensive too - so more and more aircraft systems are being designed that handle the majority of non-nominal cases. These systems are counter productive in that the flight crew now get even less hands on time and when they do get it their lack of currency shows - so back around the loop building software that will cope with more non-nominal events.
Eventually, the probability of the pilot being needed AND being capable of solving the problems will pass a point where the safety case can be met more successfully by automation. That point is closer than people would think. As soon as that point is reached AND the lifecycle costs of generating and flying operationally with the certified software is less than the cost of employing pilots, autonomous aircraft will become more widespread than they are now.
Alternatively you can see a situation developing where hand flying becomes increasingly rare and the the 'bag of bolts' comes as an increasingly great surprise to the pilots. increasingly and despite advances in the last few years the autopilot is unable to provide the pilots with either explanation or monitoring / assistance around what just dropped in their laps . .
Jetstream67 is offline  
Old 24th Mar 2019, 18:53
  #368 (permalink)  
 
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,265
Originally Posted by Jetstream67 View Post
Alternatively you can see a situation developing where hand flying becomes increasingly rare and the the 'bag of bolts' comes as an increasingly great surprise to the pilots. increasingly and despite advances in the last few years the autopilot is unable to provide the pilots with either explanation or monitoring / assistance around what just dropped in their laps . .
I think that is precisely where we are at the moment.
I also think that operators increasingly skimping on training both initial and recurrent and searching FOQA and similar to ensure that nobody actually 'flies' the aircraft are making things significantly worse.
Ian W is offline  
Old 24th Mar 2019, 20:28
  #369 (permalink)  
 
Join Date: May 2011
Location: Finland
Age: 57
Posts: 9
Originally Posted by alf5071h View Post
Considering the current views on software problems, does this only relate to the ‘numbers’ (bits), which might have been contained with better choice of software design, or does this also involve an external ‘glitch’, interference or hardware fault.
I don't see it as bad software rather than a bad control design. There are two control laws, pilot and MCAS, that don't “change available information”, uses different actuators and tries to control the same “process state”.
If both works actively at the same time, it is about clear that one or the other reaches some constraint. If it is MCAS pilot feels the pain, if the MCAS wins, situation is much worse.
It will be OK if MCAS kicks only once and then awaits manual resetting. It is just unbelievable that nobody in the Boeing saw the big picture, clearly unprofessional design.
JPcont is offline  
Old 24th Mar 2019, 22:09
  #370 (permalink)  
 
Join Date: Jun 2009
Location: UK
Posts: 74
Originally Posted by JPcont View Post
I don't see it as bad software rather than a bad control design. There are two control laws, pilot and MCAS, that don't “change available information”, uses different actuators and tries to control the same “process state”.If both works actively at the same time, it is about clear that one or the other reaches some constraint. If it is MCAS pilot feels the pain, if the MCAS wins, situation is much worse.It will be OK if MCAS kicks only once and then awaits manual resetting. It is just unbelievable that nobody in the Boeing saw the big picture, clearly unprofessional design.
It will be bad software until it reports that it is reaching it's limits and why then hands back with a status report rather than a gong and a giggle
Jetstream67 is offline  
Old 25th Mar 2019, 01:02
  #371 (permalink)  
 
Join Date: Mar 2015
Location: North by Northwest
Posts: 335
FAA tentative approval of SW fixes

It's news so take it for what it is worth. Citing a WSJ article:

The WSJ says that the software updates will scale back the Maneuvering Characteristics Augmentation System (MCAS) redesigning it “so it won’t overpower other cockpit commands or misfire based on faulty readings from a single sensor,” and will only activate once, for a short duration in the event that there is an issue. The FAA has “tentatively approved,” the update, but it needs to go through simulations and flight testing. If it works and is formally approved, the update could be issued in “the next few weeks.” The agency didn’t comment to the WSJ about the specifics of the changes. Furthermore, Boeing has said that it will include a warning light designed to warn pilots that was previously part of an optional package that carriers could purchase

https://www.theverge.com/2019/3/24/1...oftware-update
b1lanc is offline  
Old 25th Mar 2019, 01:13
  #372 (permalink)  
 
Join Date: Feb 2018
Location: Canberra
Posts: 139
Originally Posted by b1lanc View Post
Furthermore, Boeing has said that it will include a warning light designed to warn pilots that was previously part of an optional package that carriers could purchase
Still looks like an optional feature that Boeing think they can get away with charging an arm and a leg for, instead of being an included standard basic piece of safety equipment.

Boeing will now stop charging for the warning light feature and make it standard in all new 737 Max planes, an anonymous source told the Times. But airlines will still need to purchase the other feature, the angle of attack indicator.
Dee Vee is offline  
Old 25th Mar 2019, 07:25
  #373 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,122
Originally Posted by Dee Vee View Post
Still looks like an optional feature that Boeing think they can get away with charging an arm and a leg for, instead of being an included standard basic piece of safety equipment.
I think you're misinterpreting the post that you quoted from.

But airlines will still need to purchase the other feature, the angle of attack indicator.
That doesn't mean that you have to buy the AoA indicator in order to get the AoA Disagree warning functionality. It means that you get the latter for free whether or not you buy the former.

Personally I think charging for either is indefensible.
DaveReidUK is offline  
Old 25th Mar 2019, 07:33
  #374 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,056
JPcont,

Your alternative perspective (#370) is interesting. Whilst the basic information (AoA) is the same for both ‘systems’, each system has alternative views and thus use of the information. MCAS receives a valid, but inaccurate value of AoA, the computation and activation works exactly as designed - except that the output is not what the aircraft situation, nor crew requires.

Alternatively the crew do not have any direct information about AoA, the validity or magnitude of any error; they can only deduce a problem from the aircraft a motion - which is not as required.

Thus if I reframe my concern (#365) about the possibility of a software error - parity bit (discussed elsewhere), then whatever soft system changes are made, they must also reduce the possibility of inaccurate AoA from any other source, both for use by MCAS and pilots. i.e. any new dual system architecture can still malfunction if both inputs are simultaneously wrong - same software error.

The additional concern is if an AoA error is combined with a hardware fault, or that an independent hard fault can produce a false AoA. Although a new dual system should detect any difference and stop activation, without understanding the origin of a hardware fault, then the theory might not be provable for certification, and further more not eliminate the possibility of such a fault occurring simultaneously in both systems.

Thus if the issue is software related, any solution has to demonstrate both ‘soft’ compliance and tolerance to ‘hard’ faults.
As yet neither view has been disclosed as contributing to the accident, but if it is ‘software’, this and its fix should not be taken as a guarantee of cure.

Last edited by alf5071h; 25th Mar 2019 at 08:22. Reason: typo
alf5071h is offline  
Old 25th Mar 2019, 08:13
  #375 (permalink)  
 
Join Date: Nov 2007
Location: dublin
Posts: 176
Edmund
i have “ flown” the THY scenario in the sim. It seems impossible to ignore the multiple warnings that occurred .
On that fatal day, they did ignore them did but we wondered how if you are a trained pilot. ?
The radio altimeter fault did indeed cause power to reduce to idle. But thanks to Boeing design this is blindingly obvious because the throttles close in front of you. This would not happen on Airbus
Then five separate warnings occur- some automatic some visual, some observational. Then the stall which was recoverable but wasn’t.
This idea that you can’t expect pilots to overcome design faults or complex issues is pretty common on this thread and the Ethiopian thread
Im struggling to understand why but I think Donald Trump got close “ don’t want my pilot to be Einstein”.
No not Einstein who was half blind, but pilots should be extremely well trained with a thorough understanding of systems and aerodynamics and the ability to cope with complex multiple failures. Think QF ex SIN A380 -over 60 faults.
Yanrair
yanrair is offline  
Old 25th Mar 2019, 08:31
  #376 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,122
Originally Posted by DaveReidUK View Post
That doesn't mean that you have to buy the AoA indicator in order to get the AoA Disagree warning functionality. It means that you get the latter for free whether or not you buy the former.

Personally I think charging for either is indefensible.
Though in fact, according to the NYT, Boeing won't be charging for either:

"Boeing will now make the disagree light standard in all new 737 Max planes, and will provide the [AoA] indicator free of charge for customers who want it."

https://www.nytimes.com/2019/03/24/b...imulators.html

DaveReidUK is offline  
Old 25th Mar 2019, 08:37
  #377 (permalink)  
 
Join Date: Aug 2005
Location: EDLB
Posts: 160
Originally Posted by yanrair View Post
but pilots should be extremely well trained with a thorough understanding of systems and aerodynamics and the ability to cope with complex multiple failures. Think QF ex SIN A380 -over 60 faults.
Yanrair
The usual hero pilot which saves the day.
There is a saying in the flying community, that it is better to have a savvy pilot who decides in poor weather conditions not to take off, than using his superior skills to fly and land in that poor conditions.
I think the same goes for the plane.
Better a plane that not tries to kill you, than one that needs superior pilot skills to stay alive.
EDLB is offline  
Old 25th Mar 2019, 08:40
  #378 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,056
Without additional explanation, the installation of an AoA Disagree alert as standard appears to offer little benefit.

IAS and Alt disagree alerts should trigger the need to cross check and compare values with a third system - St By ASI / Alt. However, without a third, independent source of AoA no such comparison can be made, although there may be some value in knowing about an AoA issue.
What is the procedure associate with ‘AoA disagree’; the issue being addressed is MCAS malfunction, and of prime importance to the crew - ‘TRIM’; where are the alerts for these.
The crew would have to deduce whether ‘AOA disagree’ is associated with stick-shake or air-data (IAS / Alt), perhaps adversely biased by the attention getting display of low speed awareness - speed and stick-shake agree.
Such a modification might result is increased workload, possibly confusion, supposedly adding awareness but without a direct course of action. Thus system modifications must focus on the system design and operation, and if engineered appropriately, then the use of additional alerts or displays might be best avoided, reducing workload, or distraction from the primary task of flying the aircraft.

Similarly the ‘additional’ option of an AoA display, without underlying systems improvements this may be of little value - again a distraction. This and the ‘disagree’ alerts appear to be a sop to public views and ill-informed media.

WHBM, #Ethiopian airliner down in Africa




alf5071h is offline  
Old 25th Mar 2019, 08:55
  #379 (permalink)  
Pegase Driver
 
Join Date: May 1997
Location: Europe
Age: 69
Posts: 2,566
yanrair :
On that fatal day, they did ignore them did but we wondered how if you are a trained pilot. ?
Reconstructing a sequence of events after an incident / accident will always be biased , because you know what to look for and you are not in the mindset of the people that were there, at the time.
Only those that survived can explain, and even then, psychiatrists are telling us that memory can be altered after a trauma, so what those pilots say they believed happened might not reflect 100% the facts.
We know that horns and bells do not work , (hearing is the first sense disabled in a high stress situation ) The De Crespigny/QF32 experience in a multi ECAM/warning environment is worth reading in that respect .

For me , expecting humans to take over complex automation in a safe manner is a myth.. Yet we certify systems using this paradigm.

Finally sentences beginning with "they should have" ... are useless in accident investigation . That is why for so many years nearly all accident reports concluded in " pilot errors". No need to change anything , except perhaps a bit more training " recommendations " . Brings us nowhere near to a solution to the original problem .
ATC Watcher is offline  
Old 25th Mar 2019, 13:42
  #380 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,056
The Further to the suppositions at # 365, 376 and also by Loose rivets. Ethiopian airliner down in Africa

Would the software view - ‘bits’, check sum error (?), A to D conversation (?), apply to the following:-

Why the AoA value failed high - both Lion flights, Ethiopian assumed based on outcome.

That the offset could be reset with aircraft power-down, or WoW alternate switching, or Maintenance system self-test (explanations for having the maintenance log recording a fault, but none clearly identifiable by engineers or flight crew before the next flight.)

Would such a ‘failure’ be a random, probabilistic occurrence - just chance, or require an external disturbance - elect spike (FDR AoA error seen during taxi - generator switching? Lion FDRs indeterminate, Ethiopian unknown.)

Caution; however good a theory might be, it would have to match all available information (wait for Ethiopian FDR), and in scientific terms be repeatable elsewhere, thus providing a basis for modification.

Related links:-
https://www.satcom.guru/2019/03/ethi...s-to-lion.html
https://www.satcom.guru/2018/12/angl...ure-modes.html




Last edited by alf5071h; 25th Mar 2019 at 14:40. Reason: Typo
alf5071h 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.