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 2nd May 2019, 01:07
  #841 (permalink)  
 
Join Date: Mar 2005
Location: N/A
Posts: 5,880
Received 362 Likes on 192 Posts
If pilots were improperly trained its absolutely nothing to do with Boeing
Really?? Boeing Misinformed Southwest Airlines About MAX AoA Warnings
Southwest Airlines, Boeing’s biggest customer for the troubled 737 MAX, said this week that the airplane maker’s documentation incorrectly claimed that its aircraft had operable angle-of-attack disagree warning lights. But Boeing informed Southwest that the AoA function was actually inoperative only after the Lion Air crash in Indonesia last October.
AVwebFlash Responsive (Wednesday)
megan is online now  
Old 2nd May 2019, 03:13
  #842 (permalink)  
 
Join Date: Aug 2007
Location: Alabama
Age: 58
Posts: 366
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Loose rivets
I hadn't read that AV item before. Frankly, I'm going to have to go back to it several times to absorb it in its entirety.

By this, I mean the not-quite-so-easy-to-understand second cut-out switch circuitry. Is this contained overview statement correct? Grief, no wonder it wasn't understood in a iPad ramble. Even after a lifetime's love of electronics, stepping on that aircraft and truly understanding the systems would be a serious challenge.


The quotes are one question, split, and in reverse order.


Again, one of the main bee-in-my-bonet's issues. Just what is the truth about that second (underfloor) column switch? I know, it's the third time I've shouted that question.
I am not a pilot, but I have eletrical and automation background.
Based on the wirings that are available on the net the systems are as stated.
MCAS is not stopped by column switches!
MCAS cannot be disabled without cutting off manual electrical trim, which means only wheel cranking can be used if CUT OFF switches are used.
CUT OFF switches are connected in series, and renamed PRI and B/U, either one will CUTOFF all electrical controls (manual thumb on control column, autopilot, STS, MCAS), while on NG one switch will cut off automatic trim, while the other whole cut off the electrics.
Such change has been made to make the system more reliable, in case one of the CUTOFF contacts will fail (?????), note that i could not find any official comment on that by Boeing...so take that as a rumor.
anyway, connecting those switches in series might imply that previous (NG and before) design was unsafe...
my take is that the designers did not want the pilots to be able fo disable MCAS and could not remove one switch from the cockpit wihout incurring in SIM training, or having to explain why has been removed i.e. becuase of MCAS. Experts in certification please call me wrong
cheers
FrequentSLF is offline  
Old 2nd May 2019, 10:21
  #843 (permalink)  
 
Join Date: Dec 2001
Location: Brisvegas
Posts: 3,860
Likes: 0
Received 233 Likes on 99 Posts
MCAS is not stopped by column switches!
MCAS cannot be disabled without cutting off manual electrical trim,
Read the bulletin from Boeing as seen above.

Here is another version without the underlining...
http://www.avioesemusicas.com/wp-con...Due-to-AOA.pdf
Icarus2001 is offline  
Old 2nd May 2019, 10:45
  #844 (permalink)  
Psychophysiological entity
 
Join Date: Jun 2001
Location: Tweet Rob_Benham Famous author. Well, slightly famous.
Age: 84
Posts: 3,263
Received 24 Likes on 15 Posts
FrequentSLF #843

I am not a pilot, but I have eletrical and automation background.
Based on the wirings that are available on the net the systems are as stated.
MCAS is not stopped by column switches!
MCAS cannot be disabled without cutting off manual electrical trim, which means only wheel cranking can be used if CUT OFF switches are used.
CUT OFF switches are connected in series, and renamed PRI and B/U, either one will CUTOFF all electrical controls (manual thumb on control column, autopilot, STS, MCAS), while on NG one switch will cut off automatic trim, while the other whole cut off the electrics.
Well, I found it hard to reconcile the MAX system as described in the AV H's question list - with the outline wiring we'd all been lead to believe was simply a series BackUp configuration. It was too late last night to trace circuits, but 737 Driver did protest it doesn't matter about the details, as long as the crew take the right actions. I have never thought like that and if I'd been on type, (and 40 years younger) I would have known exactly what that circuit did. At least, I hope I would, given I'd got the first clue that something like MCAS was lurking in the background.
Loose rivets is offline  
Old 2nd May 2019, 10:52
  #845 (permalink)  
 
Join Date: Jul 2003
Location: Somewhere
Posts: 3,067
Received 138 Likes on 63 Posts
I highly doubt you would have found anything about MCAS in a manual let alone circuitry etc
neville_nobody is offline  
Old 2nd May 2019, 12:34
  #846 (permalink)  
 
Join Date: Dec 2018
Location: South Pole
Posts: 10
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by EEngr
Technically, the MCAS software did not fail. But from an overall systems standpoint, it did. The software people may get off the hook for writing code that ran per the specification. But the spec missed an important failure mode. And was written for the wrong level of system criticality.
Yes EEngr! System criticality is the crux of the issue. You can debate for 4000 posts, if the pilots followed the correct procedure or not, why not, what they could have done, did do, didn’t do etc.

But, I t should never have been an issue the pilots should had to have dealt with, because there should have been more system redundancy.

When MCAS fails, it can be catastrophic, so its software cannot be anything else but level A. The hazard assessment appears to be the mistake that was made: the assumption was pilots would quickly treat it as a run away stabiliser, and so it would be relatively minor. Hence, it was safe to use one vane. That’s been shown (twice) to be wrong.

So...does anyone know: is the software now level A (DO-178C) or equivalent? Because I can’t see anyway it can be anything else, and the original issue needs to be corrected, or another gotcha may exist.

Sorry if it sounds like I’m on a soap box.....

Jetthrust is offline  
Old 2nd May 2019, 14:01
  #847 (permalink)  
 
Join Date: Dec 2001
Location: Brisvegas
Posts: 3,860
Likes: 0
Received 233 Likes on 99 Posts
When MCAS fails, it can be catastrophic, so its software cannot be anything else but leve
Once again, MCAS did not fail. It was fed erroneous data from a single AoA vane. Pilot trim input WILL override MCAS trim and the trim can be isolated by switching off the stab trim.

Please stop twisting words and adding meaning with a huge bias.
Icarus2001 is offline  
Old 2nd May 2019, 14:15
  #848 (permalink)  
 
Join Date: Aug 2005
Location: EDLB
Posts: 362
Received 4 Likes on 3 Posts
Originally Posted by Icarus2001
Once again, MCAS did not fail. It was fed erroneous data from a single AoA vane. Pilot trim input WILL override MCAS trim and the trim can be isolated by switching off the stab trim.

Please stop twisting words and adding meaning with a huge bias.
The MCAS system failed. It speared in two almost new airliners with about 350 people dead.
You and Boeing can name the system to your liking and call MCAS an augmenting system when it has effective stab control to the stops where two crews did not manage to recover from.

I donˋt think that playing with words here will improve anything. To the contrary Boeing and the FAA underestimated the consequences of the MCAS system.

That the pilots have a fighting chance to survive a single sensor failure if they do everything right in a quick reaction time only proves the point of a severely wrong designed safety critical system.
EDLB is online now  
Old 2nd May 2019, 14:17
  #849 (permalink)  
 
Join Date: May 2010
Location: Boston
Age: 73
Posts: 443
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Icarus2001
Once again, MCAS did not fail. It was fed erroneous data from a single AoA vane. Pilot trim input WILL override MCAS trim and the trim can be isolated by switching off the stab trim.

Please stop twisting words and adding meaning with a huge bias.
I would posit that when someone says "MCAS failed" they are referring to the MCAS system as a whole, "inputs, processing and outputs" not just the processing block.
Saying 'MCAS" did not fail when it's (by bad design) single AoA input failed also could be construed as "twisting words".
MurphyWasRight is offline  
Old 2nd May 2019, 14:22
  #850 (permalink)  
 
Join Date: Apr 2009
Location: Hotel Gypsy
Posts: 2,821
Likes: 0
Received 0 Likes on 0 Posts
Ok, the single AOA gauge failed.
MCAS behaved as designed, including winding-in 2.5 units at a time rather than the 0.6 ‘sold’ to the regulator.
Contrary to CFR25.671, the failure of a flight control system was not manifested to the crews via a warning system. (Arguable whether MCAS is an FCS but since it unilaterally shifts a big flight control surface to get its job done......)
The crews did not disable MCAS by using the pedestal switches.

The MCAS system was designed to utilise a single data source, there was not warning system to alert regarding a failure of the system and there was only one failure mitigation put in place (pilots).

Not exactly cutting-edge system design.
Cows getting bigger is offline  
Old 2nd May 2019, 14:47
  #851 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Very lengthy and moderately detailed article just popped up on my newsfeed: https://www.theverge.com/2019/5/2/18...error-mcas-faa

Nothing surprising to anyone on this forum, but a good outline, and quite astonishing to read the whole story from beginning to end.

Typical paragraph, relevant to this thread:
So had anyone checked, they might have flagged MCAS for one of several reasons, including its lack of redundancy, its unacceptably high risk of failure, or its significant increase in power to the point that it was no longer just a “hazardous failure” kind of system.

Last edited by GordonR_Cape; 2nd May 2019 at 16:10.
GordonR_Cape is offline  
Old 2nd May 2019, 15:19
  #852 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 81
Posts: 1,609
Received 52 Likes on 15 Posts
Salute!

Thanks, Gordon..... A super article for all to read.

Gums sends...
gums is offline  
Old 2nd May 2019, 15:26
  #853 (permalink)  
 
Join Date: Aug 2007
Location: Alabama
Age: 58
Posts: 366
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Icarus2001
Once again, MCAS did not fail. It was fed erroneous data from a single AoA vane. Pilot trim input WILL override MCAS trim and the trim can be isolated by switching off the stab trim.

Please stop twisting words and adding meaning with a huge bias.
A control system is made by the Hardware, Software, sensors and actuators. If a sensors fails and the system does not validate the data and use the actuators wrongly, the complete system failed.
In this specific case, MCAS would not have failed if would have discharged the erroneous date from the AoA vane....since he did not, MCAS failed
FrequentSLF is offline  
Old 2nd May 2019, 15:31
  #854 (permalink)  
 
Join Date: Mar 2015
Location: Washington state
Posts: 209
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by MurphyWasRight
I would posit that when someone says "MCAS failed" they are referring to the MCAS system as a whole, "inputs, processing and outputs" not just the processing block.
Saying 'MCAS" did not fail when it's (by bad design) single AoA input failed also could be construed as "twisting words".
I have no idea what advantage that pushing the "MCAS did not fail" meme does for any argument, even the posters who push the idea that the pilots were at fault for not correctly responding to the problem acknowledge that there was a problem. A program can correctly implement a bad algorithm. I would guess that over half of the errors that I have corrected over the years were by some definition "programmed correctly." The basic stuff like a misplaced semicolon or null pointer dereference tend to be caught by automated tools and test suites.

To digress slightly into the basics, fault tolerance and avoidance is one of the differences between professional and amateur programming. (The other big one is testing, which Boeing apparently did not do.) Real professional code tends to be a bit complex, boring, and hard to understand because every step has to deal with error. Maybe you want to display a parameter that is dependent on the lift coefficient -- easy, right? Let Cl = L / (A * .5 * r * V^2), do the subsequent calculation, and draw the arrow. Well, what is the lift coefficient when the plane is parked and the velocity is zero? Oops, divide by zero error! Simple fix, just check for V=zero and make CL=0, except now that your fancy 3D arrow indicating lift is drawn one pixel wide causing a confusing display -- so you then check for CL=0 and hide the arrow. Now test wonders why the arrow disappears at random times briefly in flight because something further down that calculates V returned zero in response to a momentary sensor fluctuation. Now you are in the world of professional programming (and testing.)

That is kiddie stuff, actual code on which people's life depend has to deal with unexpected conditions that are far more subtle. "What sensor positions should MCAS be triggered upon?" is the question that is asked on the first hour (of programming, obviously engineering has done a lot of work before this), "How do we validate that the sensor input is correct?" is the question that is asked in the second hour. "Oh, we just put the plane's nose down and let the pilots deal with it" is not a safe answer, designing a system to fail and expecting humans to compensate does not even qualify as poor engineering, it is just plain hackery. There were many things that should have been done to address the second question, many other parameters were available to do a sanity check. The other AOA sensor is obvious, but what about time? What about the existing rudder position? What about the elevator position? If the pilot is pulling the stick back into a stall for more than say 10 seconds with the stick shaker going then there is probably something going on that you (as HAL) do not understand. If the pilot does this repeatedly over the course of minutes then there is definitely something that you (HAL) do not understand. This is basic design and it is still perplexing to me how that could have gotten though Boeing.

The alleged pilot errors are understandable; maybe smarter people would have responded better but there was nothing that they did to crash the plane -- it is the actions that they allegedly did not take which crashed the plane. I do not understand the engineering errors, although I suppose "a million dollars a plane if pilots have to be retrained in the sim" has something to do with it.
Water pilot is offline  
Old 2nd May 2019, 15:57
  #855 (permalink)  
 
Join Date: Jan 2011
Location: Seattle
Posts: 715
Likes: 0
Received 1 Like on 1 Post
Originally Posted by FrequentSLF
A control system is made by the Hardware, Software, sensors and actuators.
And the flight crew. Had Boeing come clean with the existence of this system from the outset and provided training in what to do with anomalous operation, this would all be a non-issue. Undesired pitch down due to invalid AoA input would probably still warrant a fix. But given the crew's awareness of the system, it's failure modes and relatively simple work-around procedures, the updates could have been implemented with a more economical and lower operational impact plan rather than as a crisis. Not to minimize the 300-odd people that would still be alive.
EEngr is offline  
Old 2nd May 2019, 16:06
  #856 (permalink)  
 
Join Date: Dec 2002
Location: UK
Posts: 2,451
Likes: 0
Received 9 Likes on 5 Posts
Water Pilot,
Your lack of ideas about the advantage of accurate description for the overall system (Maneuvering Characteristics Augmentation System), does not bode well for software programming; less so for pilot interaction, and the identification and intervention in adverse situations which result from errors in the original ‘lack of idea’.


Last edited by safetypee; 2nd May 2019 at 17:43. Reason: Typo
safetypee is offline  
Old 2nd May 2019, 23:15
  #857 (permalink)  
 
Join Date: Mar 2015
Location: Washington state
Posts: 209
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by safetypee
Water Pilot,
Your lack of ideas about the advantage of accurate description for the overall system (Maneuvering Characteristics Augmentation System), does not bode well for software programming; less so for pilot interaction, and the identification and intervention in adverse situations which result from errors in the original ‘lack of idea’.


I'm sorry but that is a complete non-sequitur to me. Care to try again? I'm sure you have a point in there somewhere and I would love to understand it.

Edit: oh yes, and I think that the software industry is in a very poor place right now (think "children of the magenta line" and multiply to infinity), which is why I pretty much only do hardware projects now.
Water pilot is offline  
Old 3rd May 2019, 02:14
  #858 (permalink)  
 
Join Date: Mar 2019
Location: On the Ground
Posts: 155
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Water pilot
Real professional code tends to be a bit complex, boring, and hard to understand because every step has to deal with error.
Well, I'm a pilot, not a programmer, but by reverse-engineering the functions and performance we have seen from the MCAS, the programming must have looked something like this:

Is the AoA above some trigger value?
No---wait five seconds---repeat the question.
Yes---drive the nose down for ten seconds---wait five seconds ---repeat the question.

One input, one output. No comparison of inputs, because there is only one. No check for reasonableness, though many parameters are available...airspeed, VVI, pitch attitude, and of course another AoA. No question of whether or not the MCAS has trimmed down recently, no question of where the stab trim is, now...no questions. It didn't even look to see if the trim motor was working, as in one of the FDR plots, it was obvious that MCAS was trying to move the stab, but the trim motor was turned off.

Boeing will never let anyone see the code, because it's three lines long.
Takwis is offline  
Old 3rd May 2019, 03:03
  #859 (permalink)  
fdr
 
Join Date: Jun 2001
Location: 3rd Rock, #29B
Posts: 2,944
Received 847 Likes on 251 Posts
Originally Posted by Cows getting bigger
Ok, the single AOA gauge failed.
MCAS behaved as designed, including winding-in 2.5 units at a time rather than the 0.6 ‘sold’ to the regulator.
Contrary to CFR25.671, the failure of a flight control system was not manifested to the crews via a warning system. (Arguable whether MCAS is an FCS but since it unilaterally shifts a big flight control surface to get its job done......)
The crews did not disable MCAS by using the pedestal switches.
The certified out of trim case is for 3 seconds of trim input. That MCAS had 10 seconds at a time, with a rinse and repeat cycle should have caught the attention of the certification group, but it did not (hopefully that is...). Even then, all could have been saved had the crews been aware of the propensity of the MCAS to mimic a HAL9000 moment. The crews were in the dark, and the last x,000 posts indicate the extent of the darkness that existed and still remains.

8 months post event, and in the comfort of arm chairs this matter still raises debate. None of the commenters are at risk of life and limb making their comments, deliberations and judgements. The flight crew were faced with system behaviour that was not comprehended, and which put them quite quickly into the severe out of trim condition that the aircraft needs a recovery procedure that was occasionally taught in the dark ages in earlier times, but doesn't come out in clear language in the FCTM, or in any current training that the crews would have received.

Frankly, the crews were let down by the industry on all sides, from the regulator, manufacturer, and the following information and training provided to them. Some crews may have survived this through exceptional headwork and flying skills, but that is not the basis of system reliability or even permitted to be relied upon under the certification of Part 25 aircraft.

The industry is what we have ended up with, due to the commercial imperatives. Overall, it is a disjointed, fractionated and irrational system in many respects, managed as fiefdoms by the avrious countries and with nonsensical requirements akin to removing spurs before alighting the cockpit. The passengers have achieved the outcome of low cost tickets, governments have their regulatory bodies pushing nonsensical changes to programs from their court jesters, and there is a fundamental shortfall of competency in the global regulatory bodies. There are good people in there, one or two good ones are going to get slammed over the Max8 and that is the consequence of the workloads and management of the systems we now have guiding the industry.

Low cost doesn't mean no cost, it gets paid in various currencies, including blood sadly.

In our own neck of the woods, we have a regulator that has just completed making a system that was weird but functional into an updated incomprehensible one, that is unable to be complied with, and where the undermanning of the regulator means that the simple processes that should be 30 minutes take 60 days or more to complete. Hot on the heals of this painful transition of a Part, the system now intends to wreak the same havoc on larger aspects of operations and maintenance, such that the whole sectors of the industry are alarmed at the inability to achieve compliance or to make the more restrictive processes function. In the period between the demonstrated disastrous transition of a part of the regulations, to the impending major changes, the regulator has continued to bleed skill and manpower; dark clouds mass on the horizon. Change management is a risk management process, and we seem to be dropping the ball at present.
fdr is offline  
Old 3rd May 2019, 03:14
  #860 (permalink)  
 
Join Date: Feb 2019
Location: shiny side up
Posts: 431
Likes: 0
Received 0 Likes on 0 Posts
Simple fix:

Increase the height of the landing gear (which should have been done 15 years ago) and put the damn motors back where they are supposed to be.

That $2 billion it was gonna cost looks pretty cheap right now...
Smythe is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

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