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 16th Mar 2019, 20:53
  #241 (permalink)  
 
Join Date: Jul 2013
Location: Australia
Posts: 116
Originally Posted by Just the fax maam View Post
Likely a source of puzzlement in the Pâtisseries of Toulouse, and no doubt a genuine point, however there might yet be an argument to be made along the lines of:
The likelihood of any inherent 73M aerodynamic instabilty issues causing a genuine and dangerous upset, in such a narrow and rarely visited corner of the flight envelope, is sufficiently remote as to not require constant monitoring of just AOA in all conditions.

Or in other words, software (logic) might yet be able to reliably determine when such a minimal risk exists, based on multiple other available inputs, even if only 2 of those are AOA sensors...

Non?
reading between the lines off the limited information Boeing has put out about this issue, they are going to correlate the two existing AoA sensors* not just one as they have done, with other sensors that are already available, to check that they are telling a consistent story about the state of the plane in flight.*
RickNRoll is offline  
Old 16th Mar 2019, 23:25
  #242 (permalink)  
 
Join Date: May 2011
Location: Finland
Age: 57
Posts: 9
Originally Posted by RickNRoll View Post
All raw data is suspect and all systems working with raw data must be able to tolerate faulty data. It should be a part of the system design and testing that faulty data is going to have to be dealt with.
It sounds reasonable but I am afraid it is in reality only a pipe dream. There are few fundamental issues. For example:

First. At end of the day, control laws works as the data is reliable. Yes, they can work with unreliable information, but the information is made reliable by some means (e.g. (Kalman) filtering, fuzzy sets e.g. in a simple cases).

Second issue is in the testing. There might be hughe testing set to cover all the possible cases. Unfortunately, impossible failure modes that are not recognized and are not tested...

Third is money. Redundancy is kept minimal to avoid costs. Largely maintenance costs. Sensors tend to break down and nobody wants hangar queen. If you have only two sensors you can disable the whole feature with three you can vote one out.

One additional problem with modern distributed automation system, where signals are digital "messages", is that you can't relay even to the causality in the trouble shooting. There are signals with different priorities and paths. So the response can sometimes seen before the action. It can make simple fault analysis complicated. There is role for the humans also in the future. Fortunately, human is very good in the trouble shooting.

When seen MAX as a control system, MCAS can cause positive feedback in main control loop by trimming plane badly. When the nose goes down, the speed increases and stick force increases and speed tend to increase even more. In control theory positive feedback means instability. It can be tolerated in some subsystems but never in the main control loop. That is why, I think that the whole automation system should have consistent "process image" about trimming decisions and it can not be based on opinion of distinct subsystem (beyondtrimming where stick forces are reasonable when speed increases).

The automatic nose down action should be implemented so that it can be reversed without long delays. If not, how can the pilots override control "mad" automation system? When working, the automation system can override pilot actions. It increases safety. On the other hand, automation system has to keep the plane in a condition where the pilot can take the plane in his/here control at any moment, also for safety reasons.

Edit:
I forget to mention one largely ignored fact: In a closed loop systems, the feedback (autopilot, pilot, etc.) restricts the possibility to identify the “state” of the system. So, the automation architecture has to be defined so that it does not restrict pilots situation awareness too much.

Last edited by JPcont; 17th Mar 2019 at 13:22. Reason: Forget to mention
JPcont is offline  
Old 18th Mar 2019, 01:19
  #243 (permalink)  
 
Join Date: Mar 2014
Location: WA STATE
Age: 73
Posts: 1
seems to me that even with an AOA compare- some tolerances must be carefully derived due to yaw and banking and turns. OK- when outside those deined parameters, AOA makes one inout and then quits .-- sound good. But then come cert problems again.

IMHO a third sensor it needed for the above to resolve and act as a uncorruptible judge and jury . .

What I do not understand is whyn BA does not /did not incorporate an INS ( Inertial navigation system ) essentlially as used on 787 ??

measurement in 3 axis plus time can give a reasonable independant compare for much of the same inputs used with AOA

see pages 40 and 41 of the pdf following IntroducingtheB-787.pdf

https://www.google.com/search?client...ducing+the+787

Last edited by CONSO; 18th Mar 2019 at 01:31. Reason: add pdf file
CONSO is offline  
Old 18th Mar 2019, 01:29
  #244 (permalink)  
 
Join Date: Dec 2006
Location: Germany
Posts: 23
Hmmm, the 737 MAX should have an IRS (Inertial Reference System) at least. It has bigger drift, therefore not suitable as the only source for long distance / time navigation. Usually it is backed up by other NAV systems (DME/DME or VOR/DME or GPS).
It will only give position data, though. Especially at the limits of the flight envelope it won't be able to replace air data.
EDML is offline  
Old 18th Mar 2019, 01:34
  #245 (permalink)  
 
Join Date: Mar 2014
Location: WA STATE
Age: 73
Posts: 1
Red face

Originally Posted by EDML View Post
Hmmm, the 737 MAX should have an IRS (Inertial Reference System) at least. It has bigger drift, therefore not suitable as the only source for long distance / time navigation. Usually it is backed up by other NAV systems (DME/DME or VOR/DME or GPS).
It will only give position data, though. Especially at the limits of the flight envelope it won't be able to replace air data.
Thism may be a repeat- but having problems withn link my apologies

IntroducingtheB-787.pdf
shows just how a INS can be an approx backup or judge

https://www.google.com/search?client...ducing+the+787
CONSO is offline  
Old 18th Mar 2019, 02:22
  #246 (permalink)  
 
Join Date: Jun 2001
Location: Surrounded by aluminum, and the great outdoors
Posts: 3,652
Originally Posted by Vilters View Post
Stick pusher? ?

Just another system that will bring you the same result. => With a bad AOA input it will PUSH you into the ground.
MCAS will trim you into the ground, the stick pusher will push you into the ground. => The size of the debris field will be the same.

By the All mighty, attack the problem where it is ; The AOA sensors.
stick pusher is immediately obvious, and doesn’t move the stabilizer to the point where elevators may not have authority to override the nose down force...stick pusher easily overridden by a tug on the control column rendering the aircraft totally controllable at all times, one possible factor in these two accidents could possibly be the “what the hell is going on and why do I keep having to fight nose down tendencies”, with a stick pusher there ain’t no doubt what happened
ironbutt57 is offline  
Old 18th Mar 2019, 03:08
  #247 (permalink)  
 
Join Date: Mar 2014
Location: WA STATE
Age: 73
Posts: 1
stick pusher easily overridden by a tug on the control column rendering the aircraft totally controllable at all times,
NOPE- on MAX it does NOT cutout MCAS. And MCAS simply pauses for 5 to 10 seconds and then starts again . . but pauses only with trim swiches !
CONSO is offline  
Old 18th Mar 2019, 03:12
  #248 (permalink)  
 
Join Date: Jun 2001
Location: Surrounded by aluminum, and the great outdoors
Posts: 3,652
Originally Posted by CONSO View Post
NOPE- on MAX it does NOT cutout MCAS. And MCAS simply pauses for 5 to 10 seconds and then starts again . . but pauses only with trim swiches !
exactly! Therein lies the problem...this “el-cheapo” alpha prot system is a can of worms, need to rethink the whole thing
ironbutt57 is offline  
Old 18th Mar 2019, 03:35
  #249 (permalink)  
 
Join Date: Mar 2014
Location: WA STATE
Age: 73
Posts: 1
Exclamation

Originally Posted by ironbutt57 View Post


exactly! Therein lies the problem...this “el-cheapo” alpha prot system is a can of worms, need to rethink the whole thing
from WSJ a while ago
A grand jury in Washington, D.C., issued a broad subpoena dated March 11 to at least one person involved in the 737 MAX’s development, seeking related documents, including correspondence, emails and other messages, one of these people said. The subpoena, with a prosecutor from the Justice Department’s criminal division listed as a contact, sought documents to be handed over later this month.


Its just a start !
CONSO is offline  
Old 18th Mar 2019, 04:00
  #250 (permalink)  
 
Join Date: Nov 2010
Location: Atlanta
Age: 51
Posts: 288
Originally Posted by CONSO View Post
NOPE- on MAX it does NOT cutout MCAS. And MCAS simply pauses for 5 to 10 seconds and then starts again . . but pauses only with trim swiches !
MCAS will only trim again if it is reset. One of the reset triggers is using the electric trim, so if the pilots don't re-trim the aircraft, MCAS will not trim again.
IMHO the only reason the Lion crash happened after being somewhat controllable for 10 minutes, is that the captain who had re-trimmed to neutral over 15 times (I think), handed over control to the FO, who also retrimmed, but much smaller inputs, letting MCAS run the trim full AND.
hans brinker is offline  
Old 18th Mar 2019, 04:36
  #251 (permalink)  
 
Join Date: Mar 2014
Location: WA STATE
Age: 73
Posts: 1
from seattle times

If the final safety analysis document was updated in parts, it certainly still contained the 0.6 limit in some places and the update was not widely communicated within the FAA technical evaluation team.“None of the engineers were aware of a higher limit,” said a second current FAA engineer.The discrepancy over this number is magnified by another element in the System Safety Analysis: The limit of the system’s authority to move the tail applies each time MCAS is triggered. And it can be triggered multiple times, as it was on the Lion Air flight.One current FAA safety engineer said that every time the pilots on the Lion Air flight reset the switches on their control columns to pull the nose back up, MCAS would have kicked in again and “allowed new increments of 2.5 degrees.” “So once they pushed a couple of times, they were at full stop,” meaning at the full extent of the tail swivel, he said.Peter Lemme, a former Boeing flight controls engineer who is now an avionics and satellite-communications consultant, said that because MCAS reset each time it was used, “it effectively has unlimited authority.”
CONSO is offline  
Old 18th Mar 2019, 04:37
  #252 (permalink)  
 
Join Date: Jul 2014
Location: south of old hub
Posts: 2
I don't write much, which is why I can't paste a URL. The Boeing and Aerospace piece in the 17 March Seattle Times is very interesting, the say the least. Some lawyers about to make a lot (more) of money.
libbyj is offline  
Old 18th Mar 2019, 07:46
  #253 (permalink)  
 
Join Date: Jul 2013
Location: Australia
Posts: 116
Originally Posted by JPcont View Post
It sounds reasonable but I am afraid it is in reality only a pipe dream. There are few fundamental issues. For example:

First. At end of the day, control laws works as the data is reliable. Yes, they can work with unreliable information, but the information is made reliable by some means (e.g. (Kalman) filtering, fuzzy sets e.g. in a simple cases).

Second issue is in the testing. There might be hughe testing set to cover all the possible cases. Unfortunately, impossible failure modes that are not recognized and are not tested...

Third is money. Redundancy is kept minimal to avoid costs. Largely maintenance costs. Sensors tend to break down and nobody wants hangar queen. If you have only two sensors you can disable the whole feature with three you can vote one out.

One additional problem with modern distributed automation system, where signals are digital "messages", is that you can't relay even to the causality in the trouble shooting. There are signals with different priorities and paths. So the response can sometimes seen before the action. It can make simple fault analysis complicated. There is role for the humans also in the future. Fortunately, human is very good in the trouble shooting.

When seen MAX as a control system, MCAS can cause positive feedback in main control loop by trimming plane badly. When the nose goes down, the speed increases and stick force increases and speed tend to increase even more. In control theory positive feedback means instability. It can be tolerated in some subsystems but never in the main control loop. That is why, I think that the whole automation system should have consistent "process image" about trimming decisions and it can not be based on opinion of distinct subsystem (beyondtrimming where stick forces are reasonable when speed increases).

The automatic nose down action should be implemented so that it can be reversed without long delays. If not, how can the pilots override control "mad" automation system? When working, the automation system can override pilot actions. It increases safety. On the other hand, automation system has to keep the plane in a condition where the pilot can take the plane in his/here control at any moment, also for safety reasons.

Edit:
I forget to mention one largely ignored fact: In a closed loop systems, the feedback (autopilot, pilot, etc.) restricts the possibility to identify the “state” of the system. So, the automation architecture has to be defined so that it does not restrict pilots situation awareness too much.
I don't mean it has to work despite failure. It has to be tolerant. That can mean failing gracefully. For example, give the pilot a clear warning message and hand control back to the pilot. The MCAS softare could have done this and now will do this.
RickNRoll is offline  
Old 18th Mar 2019, 16:16
  #254 (permalink)  
 
Join Date: Aug 2013
Location: Washington.
Age: 69
Posts: 452
The possibility that a single sensor failure can lead to a potentially catastrophic result must not be possible. In system safety terms, the probability of such an event must be Extremely Improbable. This system design apparently accepts a single source of AoA, which cannot possibly meet that fundamental requirement. Neither is there comparison between the two AoA sensors, apparently, to detect an integrity failure and prevent use of an invalid signal. While it may be unlikely that two AoA sensors will be simultaneously erroneous at similar values, that possibility, too, must be considered. News reports (Seattle Times) say that the system safety classification of an MCAS failure condition was Hazardous. But it should have been Catastrophic, and I’m not sure the exact failure condition of these accidents was even analyzed. The possibility of invalid AoA input to the MCAS must be prevented. Will a software enhancement remedy this? I don’t know, but I’m not confident of it. AoA validity/integrity must be ensured. Invalid signals must be detected and not used by MCAS. Personally, I don’t think comparison between two sensors is sufficient.
GlobalNav is offline  
Old 18th Mar 2019, 16:28
  #255 (permalink)  
 
Join Date: Mar 2006
Location: England
Posts: 811
A challenge for Boeing via investigators is to identify how ‘AoA’ came to dominate these accidents, whilst apparently using the same / similar AoA probe on older 737s.
Some confusion for Ppruners is not knowing where the FDR AoA value is taken from -
737MAX Stab Trim architecture
The implication is that something other than the probe / probe output might contribute to the problem - wiring. Whilst the mechanism involves AoA, exactly where an error originates and interacts with MACS system is not known. If the error is not in the computation, then more attention is required on the Max probe failure rate and the aircraft wiring / build standard.

MCAS enhances stability to meet certification requirements. Any other (unidentified) failures affecting MCAS (input or computation) could similarly invalidate the certification; failures might be acceptable for rare occurrences and a safe recovery, but not so for frequent failures, MEL, or a high probe failure rate.

Whether the aircraft can be recovered safely with trim malfunction is central to these accidents. Thus the integrity of the overall trim system (tail jack stall) may require reassessment, including crews’ ability to fly a runaway trim recovery procedure (irrespective of MACS).
The FAA should re-evaluate the trim runway procedure because in these accidents the crew were apparently unable to recover from a severe trim malfunction.
Would the failure and procedure discussed in Boeing advice on "aerodynamically relieving airloads" using manual stabilizer trim still be considered tenable.
Should there be an altitude limit to allow time for recovery, or is the procedure so unrealistic that any cause, risk of failure should similarly be improved.
PEI_3721 is offline  
Old 18th Mar 2019, 16:40
  #256 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 9,929
Originally Posted by CONSO View Post
Thism may be a repeat- but having problems withn link my apologies

IntroducingtheB-787.pdf
shows just how a INS can be an approx backup or judge

https://www.google.com/search?client...ducing+the+787
Hard to tell, as your link just brings up a Google search page, but if you're referring to the synthetic airspeed (aka "AoA airspeed") that's generated on the 787 derived from inertial data and AoA then, yes, that's been discussed in at least one of the current threads.
DaveReidUK is online now  
Old 18th Mar 2019, 20:13
  #257 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 732
Originally Posted by PEI_3721 View Post
[left]A challenge for Boeing via investigators is to identify how ‘AoA’ came to dominate these accidents, whilst apparently using the same / similar AoA probe on older 737s.
Some confusion for Ppruners is not knowing where the FDR AoA value is taken from -
IF it's same as NG, then according to the AMM (CH27 - 27-32-00) the SMYD (Stall Management Yaw Damper) receives analog AOA inputs from sensor and sends digital AOA to FDR (via FDAU).

Edit: Gums has pointed out that apparently it's not the same as the NG, so probs best to disregard most of my speculation...


FCC is listed as receiving digital AOA from the on-side ADIRU (not the SMYD). ADIRU is not listed as getting digital AOA from SMYD, SMYD is not listed as sending digital AOA to ADIRU or to FCC. All of which could mean that ADIRU also gets the analog inputs from AOA sensor - but I can't find confirmation of this in the manual, only in some non-Boeing diagrams online.

The implication is that something other than the probe / probe output might contribute to the problem - wiring.
Yup, wiring gremlins definitely in the picture (until ruled out) in my opinion. Iff analog sensor outputs are in fact going into ADIRU and SMYD then we can probably discount (dual simultaneous) ADC failure, and maybe makes a wiring fault more likely near the sensor than near the FCC/SMYD? Wiring (or connector) fault at near the sensor would also fit Lion Air previous flights with different / intermittent errors until sensor replacement which then made it worse.

Peter Lemme at satcom.guru did some analysis of possible wiring failures and results on AOA decoded values without coming up with much, however he didn't consider a short (or partial short) between sin and cos. I reckon this might give a fixed AOA offset over a range of AOA - but I am not sure what range, depends on offset and gain values that I don't know. Also I considered only resistance of the short, throw in capacitance, AC signals and result of phase shift on resolver decoding, and, er, well at that point I realised how long it is since I did analog stuff and how much I have forgotten...

Just spotted this from Reuters (https://www.reuters.com/article/us-e...-idUSKCN1QZ1R9 ): now saying that ET FDR shows AOA data "very very similar" to Lion Air.

Last edited by infrequentflyer789; 18th Mar 2019 at 22:09.
infrequentflyer789 is online now  
Old 18th Mar 2019, 21:27
  #258 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 76
Posts: 1,021
Salute!

@ infrequent
IF it's same as NG, then according to the AMM (CH27 - 27-32-00) the SMYD (Stall Management Yaw Damper) receives analog AOA inputs from sensor and sends digital AOA to FDR (via FDAU).
A big "if" and I do not believe it applies now.

Lemme has posted after the Lion Air tragedy that the SMYD functions have migrated to the FCC. Also. the elevator trim/elevator feel shift (EFS) function is a "module:' not a dedicated box like the "old", pre-MAX SYMD. GASP!!!
https://www.satcom.guru/2018/11/737-...mand.html#more 20 November blog


The EFS used to get its data from the ADRIU, and looks like the left/right logic was unchanged. So now we have two processors in the FCC and unless we can find a directly connected box or two, then the FCC is the driver for mach trim, STS, stall warning(shaker), basic trim functions and now the new MCAS. The description for EFS does not sound like the basic control column feel implementation. Some aspects of it include 1) radar altitude >100 feet, 2) a/p disengaged, 3) nose down trim and 4) no indication light it is active. So add this to the STS which 1) waits 5 seconds to activate after manual trim command and 2) doesn't work until 10 seconds after wow.

I am sarting to see some connections with the numbers, and they are all in sfwe!!!!! Remember, the stab is basic trim and elevator trim is used for mach trim, maybe a/p functions but have to review the scant description we have.

And now they are telling us they are gonna do a sfwe mod to "help" !!!! BEAM ME UP!!!!!

Gums sends....

Last edited by gums; 18th Mar 2019 at 21:50.
gums is offline  
Old 18th Mar 2019, 22:32
  #259 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 732
Originally Posted by gums View Post
Salute!

@ infrequent


A big "if" and I do not believe it applies now.

I guess I'll add reading comprehension to my lost skills - I had read that blog post (more than once) and totally missed that paragraph.

Scratching my head to figure out the MAX, seems to be a frankenmix of old and new bits, what design goals required them to change flight proven stuff like the SMYD and EFSM from the NG (nothing to do with the engines) and then hide the differences and claim the MAX is just like the NG?
infrequentflyer789 is online now  
Old 19th Mar 2019, 05:12
  #260 (permalink)  
 
Join Date: Nov 2018
Location: Brisbane
Posts: 19
Not sure how single trim output can work for MCAS stabilisation

What information is available points to a MCAS software update that increases the robustness of the AoA input but restricts stab trim output to one cycle only.

However, I don't understand how a single trim cycle could really create a particularly effective augmented stability. The trouble is, we really don't know much about the characteristics of MAX stability, and only part of the MCAS algorithm parameters. But it is likely that the Cm versus alpha curves for the unaugmented MAX tend to show a pre-stall region of decreased stability (not instability) due to Nacelle lift as below. This makes it easier to pull through the pre-stall region than at lower AoAs, and breaks certification.

A control loop more robust and sophisticated than MCAS that senses AoA and actuates stab trim to make the desired Cm vs. alpha plot might be possible (although not necessarily a good idea). However, an MCAS2 that outputs only one trim event should produce something more like the plot below. Apologies for the large amount of assumptions and simplifications for this plot, but for want of more accurate values, the nacelle lift region stretches from AoA 8' to 14' (where the wing stalls). The MCAS-like system is putting in a single trim event (triggered at 10' AoA) that is effectively trimming the aircraft from AoA 5' to 2' (if the column was returned to neutral).

The single trim event augmented performance is a very ragged approximation of the desired behaviour, in fact if you resisted the trim message from this MCAS2 by pulling through it, you would be back in the lower stability regime again until stall. If the lower stability region breaks certification it seems rather an ineffective fix.

LEOCh 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.