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 15th Mar 2019, 21:40
  #221 (permalink)  
 
Join Date: Jul 2002
Location: Ireland
Posts: 427
At some point in the design phase of the MCAS, the question would have been asked "How many Alpha vanes do we want to feed the active FCC?"

Three would be the best use of redundancy. The problem with two is that all you can really do with a two sensor disagree, is disable the system altogether which then leaves the aircraft without a system required for certification. That leaves one sensor which if it fails 'unsafe', leaves the system in operation therefore good for certification but then relies on the crew to 'catch' the problem.

This may be overthinking things but that suggests to me that the MCAS decision was made very late in the whole process where adding an extra vane to the nose (or anywhere else) would cause a prohibitively long delay so the use of only one vane was the only option open to the designers at that stage of the game, effectively a fait accompli.

There are currently legal cases against Boeing with respect to the Lion Air crash and if that turns out to be down to the MCAS as does ET-302, unless Boeing makes an out of court settlement, the design and testing process will almost certainly have to be revealed to all in open court.
Speed of Sound is offline  
Old 15th Mar 2019, 22:28
  #222 (permalink)  
 
Join Date: Sep 2011
Location: Belgium
Age: 59
Posts: 93
Yep, it is going to take a bright guy to repair a HARDWARE issue with a SOFTWARE update.
Is going to be a funny story to follow...….
Vilters is offline  
Old 15th Mar 2019, 22:57
  #223 (permalink)  
 
Join Date: Feb 2009
Location: Seattle
Posts: 362
Originally Posted by Speed of Sound View Post
At some point in the design phase of the MCAS, the question would have been asked "How many Alpha vanes do we want to feed the active FCC?"

Three would be the best use of redundancy. The problem with two is that all you can really do with a two sensor disagree, is disable the system altogether which then leaves the aircraft without a system required for certification. That leaves one sensor which if it fails 'unsafe', leaves the system in operation therefore good for certification but then relies on the crew to 'catch' the problem.

This may be overthinking things but that suggests to me that the MCAS decision was made very late in the whole process where adding an extra vane to the nose (or anywhere else) would cause a prohibitively long delay so the use of only one vane was the only option open to the designers at that stage of the game, effectively a fait accompli.

There are currently legal cases against Boeing with respect to the Lion Air crash and if that turns out to be down to the MCAS as does ET-302, unless Boeing makes an out of court settlement, the design and testing process will almost certainly have to be revealed to all in open court.
MCAS availability requirement is driven by the handling qualities impact of not having MCAS. 737MAX was not able to certify without MCAS, but the hazard level of not having MCAS must not be so high as to require MCAS availability to be greater than that of a single AOA sensor as that is the current design. If hazard level of not having MCAS is sufficiently low to allow that condition at the twice the failure rate of an AOA sensor then logic that compares two AOA signals and disables MCAS when they don't agree would be fine. We will see if that is part of the pending MCAS control law update.
FCeng84 is online now  
Old 15th Mar 2019, 23:15
  #224 (permalink)  
 
Join Date: Sep 2018
Location: Laredo, TX
Posts: 84
Originally Posted by SteinarN View Post
I have read Bjørns posts.

My questions was more like rhetorical. I have no knowledge regarding the regulations aircraft have to comply with. But I have a feeling that if Boeing really is to comply with the regulations, I suspect it might be very difficult to fit a MCAS system that have the required redundancy. In fact I cant see how it can have any redundancy at all. Only two AoA sensors give exactly... zero... redundancy. Only two FCC gives exactly.... zero.... redundancy. Or might there be two separate processors in each computer? But still that would require at a bare minimum that all four processors was in the loop at any time.

So, if MCAS is a system that is regarded as required for safe flight, and thus might be required to have redundancy, can this be done?
If MCAS was required for safe flight the AD addressing the malfunction of MCAS would advise caution in the flight regime it was designed to keep you safe in.
jimtx is offline  
Old 15th Mar 2019, 23:45
  #225 (permalink)  
 
Join Date: Jul 2014
Location: Harbour Master Place
Posts: 476
Redundancy voting systems

This was posted back somewhere in the JT610 thread. Reaching agreement in the presence of faults. Well worth a read on the required number of sensors to ensure redundancy for decision making in automation with faults.

M. PEASE, R, SHOSTAK, AND L. LAMPORT SRI Internationall, Menlo Park, California
ABSTRACT. The problem addressed here concerns a set of isolated processors, some unknown subset of which may be faulty, that communicate only by means of two-party messages. Each nonfaulty processor has a private value of reformation that must be communicated to each other nonfaulty processor. Nonfaulty processors always communicate honestly, whereas faulty processors may lie The problem is to devise an algorithm in which processors communicate their own values and relay values received from others that allows each nonfaulty processor to refer a value for each other processor The value referred for a nonfaulty processor must be that processor's private value, and the value inferred for a faulty one must be consistent wRh the corresponding value inferred by each other nonfanlty processor It is shown that the problem is solvable for, and only for, n ≥ 3m + 1, where m IS the number of faulty processors and n is the total number. It is also shown that if faulty processors can refuse to pass on reformation but cannot falsely relay information, the problem is solvable for arbitrary n ≥ m ≥ 0. This weaker assumption can be approximated m practice using cryptographic methods KEY WORDS AND eHRASES, agreement, authentication, consistency, distributed executive, fault avoidance, fault tolerance, synchronization, voting
Note, this is a cut and paste from an OCR .pdf, so errors may appear in the abstract, see original

Boeing know and understand this redundancy & fault tolerance problem extremely well. The fact this kludge was implemented apparently against the basic & fundamental engineering principles and with great silence is highly concerning. There must have been substantial objections about the lack of fault tolerance from engineers who reviewed this fix. One has to wonder just how many were involved in the decision making process to implement this, and at what level.
CurtainTwitcher is offline  
Old 16th Mar 2019, 00:14
  #226 (permalink)  
fdr
 
Join Date: Jun 2001
Posts: 460
Originally Posted by SteinarN View Post
Back to OT.

This is a few questions I have;

Do we know how far from required stall caracteristics the aircraft is without the MCAS?

How serious is this deficiency in (pre) stall characteristics?

How much redundancy, based on the seriousness of the deficiency, will be required by the revised MCAS?

Based on the very old and limited FCC/sensor package/system layout on the 737Max, how much redundancy can feasibly be built into a revised MCAS system?

The issue isn't that stall itself (§ 25.203 Stall characteristics) , if it was, then a pusher would have been mandated. The problem is a longitudinal stability criteria compliance (§ 25.143 General, § 25.145 Longitudinal control, § 25.171 General, § 25.173 Static longitudinal stability, § 25.175 Demonstration of static longitudinal stability (b) and possibly (a)).
fdr is offline  
Old 16th Mar 2019, 01:03
  #227 (permalink)  
 
Join Date: Feb 2019
Location: All-At-Sea
Posts: 6
Originally Posted by Vilters View Post
Yep, it is going to take a bright guy to repair a HARDWARE issue with a SOFTWARE update.
Is going to be a funny story to follow...….
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?

Just the fax maam is online now  
Old 16th Mar 2019, 02:44
  #228 (permalink)  
 
Join Date: Feb 2006
Location: USA
Posts: 322
WSJ

(Don't know if the full article is behind a paywall.)

WSJ - FAA, Boeing Have Tussled Over Pilot Training for 737 MAX Software Fix

​​​​​​...Boeing has been advocating comparatively limited training, the people said, consisting of new, written materials aviators would receive explaining operation of the automated stall-prevention feature—and how to respond if it malfunctions.

But the FAA, they said, increasingly is pushing for more extensive training, consisting of pilots engaging in self-guided instruction on a laptop computer; the computer-based instruction would include more details and require more time to complete than reading a handout.

The second option gained support, according to one of the people involved in the discussions, after ground-simulator sessions sponsored by the FAA showed computer-based training would be required to ensure average pilots know what the changes mean and how to respond...
The editors obviously missed the point that MCAS isn't a "stall-prevention feature".

​​​​​​...The most important element of the pending software revisions is that in the future, MCAS is expected to use feeds from a pair of sensors measuring the angle of the plane’s nose—instead of the current reliance on a single sensor. The change was prompted by preliminary findings in the Lion Air crash probe, showing that incorrect data fed into a flight-control computer from a single sensor precipitated the deadly chain of events.

The pending software fix also will limit the number of times in succession the MCAS system can push down a plane’s nose and lengthen the interval between such automated commands, according to the person involved in the discussions.

Some Boeing officials were informed about the training decision earlier this week, this person said, but other government and industry officials briefed on the matter said they weren’t aware a formal determination had been made...
Zeffy is offline  
Old 16th Mar 2019, 03:51
  #229 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 76
Posts: 936
Salute!

While we are on the software.....

It has been mentioned that the Aibus FBW models do not have inherent speed stability IAW the Part 25 requirements. This was mentioned because of the 737 STS implementation with its "helpful" trim when changng speed/AoA. This hints at very low drag changes when AoA changes, right? The Airbus prolly has great inherent speed stability but it's hard to find out due to the flight control laws. Same with my Viper.

If you choose a gee command control law for pitch, then the sucker will press on straight ahead and not change pitch to maintain last "trim" speed/AoA. I flew the AFTI sim using a pitch rate law and it wasn't as comfortable as gee command, and didn't have speed stability either. Only an AoA command law had what we old farts were used to. So the Viper pilots and 'bus drivers just point where they wanna go and use power fpr speed. Big deal, and doesn't take two minutes to realize it. With gear down, the Viper law is still gee command but includes an AoA bias and stronger pitch rate dampening. It is like a sloppy Cessna, heh heh.

Gums sends...
gums is offline  
Old 16th Mar 2019, 04:31
  #230 (permalink)  
fdr
 
Join Date: Jun 2001
Posts: 460
Originally Posted by gums View Post
Salute!

While we are on the software.....

It has been mentioned that the Aibus FBW models do not have inherent speed stability IAW the Part 25 requirements. This was mentioned because of the 737 STS implementation with its "helpful" trim when changng speed/AoA. This hints at very low drag changes when AoA changes, right? The Airbus prolly has great inherent speed stability but it's hard to find out due to the flight control laws. Same with my Viper.

If you choose a gee command control law for pitch, then the sucker will press on straight ahead and not change pitch to maintain last "trim" speed/AoA. I flew the AFTI sim using a pitch rate law and it wasn't as comfortable as gee command, and didn't have speed stability either. Only an AoA command law had what we old farts were used to. So the Viper pilots and 'bus drivers just point where they wanna go and use power fpr speed. Big deal, and doesn't take two minutes to realize it. With gear down, the Viper law is still gee command but includes an AoA bias and stronger pitch rate dampening. It is like a sloppy Cessna, heh heh.

Gums sends...
Its opinion, but the difference in control method is why the Bus is nicer to fly than the 777/787 as far as pitch/roll goes... in flight, and in normal modes. The instrumentation sucks, the reversionary modes and the ECAM/checklists/FCOM/OEB's are a PITA. Conventional aileron control on the 777/787 make for happier crosswind takeoffs and landings than the Bus. Manoeuvre demand/g is nice, but the rest sucks.

As the saying used to go...
Boeing: built by rocket scientists for idiots
Airbus: built by idiots for rocket scientists

Both are good aircraft, we have issues with putting humans into them as part of the loop, but taking the human out guarantees failures.
fdr is offline  
Old 16th Mar 2019, 05:55
  #231 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 76
Posts: 1,453
Feel System force levels

Note: On realization of a significant oversight in my thoughts, I have revised my post below.

One of the stabilator equipped jets I used to fly started life with a rather steep stick force gradient in pitch. Pilots were objecting to the force gradient and the Navy requested that the gradient be decreased.
I had opportunity to fly both versions in extreme maneuvering flight. The version with the steep gradient left me with strained muscles in my stick handling arm. The version with the lighter gradient could be flown with fingertips in extreme maneuvering flight.
The transition between the two types was negligible. In event of complete failure of the aircraft feel system (blockage of the feel system pitot) you could overpower the system with comfortable force levels, but you could control the aircraft.

Perhaps the 737 would benefit from lower force gradients in pitch control as well, although if you run out of elevator authority due to THS position, you will still begin to lose control.
If the feel force levels never reached astronomical levels, it would then be easier to reach the limits of the elevator input command travel. Should you reach perhaps 95% of travel, that could be used as a signal to override the THS position commanded by MCAS and reduce any MCAS commanded trim.
Remember, you are not feeling aerodynamic forces through the stick. You are merely wrestling with a hydraulic powered device in the back of the aircraft. The force levels can be adjusted by changing the hydraulic pressure applied.
Arguments against reducing the force gradient probably center on preventing inadvertent over-G events and on maintaining feel commonality with earlier Boeing transports. I suspect that these arguments will be found to be overstated if actual flight testing of a reduced stick force gradient is performed.

Last edited by Machinbird; 17th Mar 2019 at 06:47.
Machinbird is offline  
Old 16th Mar 2019, 12:56
  #232 (permalink)  
 
Join Date: Feb 2006
Location: USA
Posts: 322
Peter Lemme Opines

https://www.satcom.guru/2019/03/what...this-week.html
...The last issue with MCAS is the most significant. The flight condition that MCAS is designed for (accelerated stall) involves the column being pulled back when MCAS needs to trim nose down. This creates a conflict with the aft-column cutout. The aft-column cutout stops a nose-down "mistrim" command.

The aft-column cutout involves a signal from the column cutout switch to the FCC. The FCC software uses the input to turn off its trim commands.

The FCC removed the aft column cutout feature from MCAS commands. MCAS can trim nose down in spite of the aft column cutout being asserted. This is a grave error and must be resolved.

Human factors cannot be denied. In the event of a nose-down stabilizer uncommanded motion, the pilot will pull back on the column. That much is certain. As the airplane pitches over, the pilot will pull back harder. With the aft column cutout, the trim command will cease, the situation will stabilize, the pilot can compose themselves, trim the stab back up, and maybe hit the trim cutout switch.

Without the aft column cutout, some human beings may freeze up. They may not get to the step of trying to trim the stab back up, but instead fixate on pulling the column back. I fear this is exactly what happened in JT610.

The column cutout switches have served aviation well. Boeing NEVER should have removed aft-column cutout for MCAS. Aft-column cutout must be restored. If that means MCAS cannot work as planned, THEN SO BE IT, take MCAS out...
Zeffy is offline  
Old 16th Mar 2019, 14:09
  #233 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 76
Posts: 936
Salute!

Wow, Zeffy , that's what I was hinting at in an earlier post about various functions in various boxes and/or sftwe modules, subroutines, etc. Makes things really hard to do an effective fault tree,
I must agree with the "Guru" to the nth degree.
Then there's basic feel system that apparently increases back stick force requirements just to move the thing, right? Need better description than I can find, but that was mentioned in one of the plethora of threads.

Gums sends...
gums is offline  
Old 16th Mar 2019, 15:30
  #234 (permalink)  
YRP
 
Join Date: May 2005
Location: Ontario, Canada
Posts: 113
Originally Posted by Vilters View Post
Yep, it is going to take a bright guy to repair a HARDWARE issue with a SOFTWARE update.
Is going to be a funny story to follow...….
FWIW, that happens all the time in all kinds of different technology applications, software working around hardware issues. It’s very very common and frankly straightforward if the hardware issue is well understood.

I have even worked on the other way around, modifying hardware to work around software issues, in cases where (for complicated reasons) the software couldn’t be modified. That way it’s quite a bit harder.

Your point though is probably about working around missing ​​​​ but necessary hardware like another AoA vane, which is valid.

YRP is offline  
Old 16th Mar 2019, 15:31
  #235 (permalink)  
 
Join Date: Feb 2019
Location: shiny side up
Posts: 55
The Max is the latest upgrade to the Boeing 737, which has been flying since the late 1960s. Because its engines were larger and heavier than on previous 737s, they were placed higher and farther forward on the wings. That created concern that the plane might be slightly more prone to an aerodynamic stall if not flown properly, so Boeing developed software to prevent that.
MCAS was required to prevent the pilot from pulling up too much, and it pushes the nose down.
Smythe is offline  
Old 16th Mar 2019, 16:24
  #236 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 76
Posts: 1,453
Originally Posted by Smythe View Post
MCAS was required to prevent the pilot from pulling up too much, and it pushes the nose down.
Sorry, but not correct. MCAS strictly plays with the pitch sensitivity at high AOA. The way that it does this is the issue. I have no doubt that you could still pull the aircraft into a stall against a single MCAS activation. The problem occurs when you have inappropriate MCAS activation and you counter trim which resets the system to trim again.
Suggest looking for FCeng84’s explanations of the system to educate yourself.
Machinbird is offline  
Old 16th Mar 2019, 17:27
  #237 (permalink)  
 
Join Date: Sep 2011
Location: Belgium
Age: 59
Posts: 93
Sorry to disagree but in BOTH crashes the elevator trim jackscrew was trimmed to FULL Nose Down.

So even if the system was not supposed to trim, It did so. => And my bet is still on the AOA sensors feeding wrong information to the system.
Vilters is offline  
Old 16th Mar 2019, 19:18
  #238 (permalink)  
 
Join Date: May 2011
Location: Finland
Age: 57
Posts: 5
Originally Posted by Smythe View Post
MCAS was required to prevent the pilot from pulling up too much, and it pushes the nose down.
As an engineer, not a pilot, I have not understand why not just install stick pusher? MCAS is working behind the scenes and don't inform the pilot. It is some kind of grey eminence. A stick pusher would tell the opinion of the automation system and if you disagree, there is clear procedure for that.

Currently, many devices are so complicated that they tends to have similar characteristics as (badly beheving) human. For that reason, the user interface should be implemented so that human can understand the machine.

JPcont is offline  
Old 16th Mar 2019, 19:38
  #239 (permalink)  
 
Join Date: Sep 2011
Location: Belgium
Age: 59
Posts: 93
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.
Vilters is offline  
Old 16th Mar 2019, 19:57
  #240 (permalink)  
 
Join Date: Apr 2017
Location: Europe
Posts: 2
A quick software fix? No problem, piece of cake!

http://www.cnbc.com/2019/03/15/boein...n-10-days.html

So if that obviously minor problem can be fixed in 10 days (and that seems to include checking and verification by the FAA) why then had two planes to go down and a few hundred people to die in the first place?

The corporate cynisism in this PR ploy is hard to believe. But hey, the shares went up, so what.
JoiRide 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.