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

Ethiopian airliner down in Africa

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

Ethiopian airliner down in Africa

Old 26th Mar 2019, 14:45
  #2561 (permalink)  
 
Join Date: Feb 2006
Location: USA
Posts: 443
Seattle Times article

https://www.seattletimes.com/busines...cation-process
Boeing has 737 MAX software fix ready for airlines as DOT launches new scrutiny of entire FAA certification process
March 25, 2019 at 1:22 pm Updated March 25, 2019 at 4:46 pm


Dominic Gates By Dominic Gates
Seattle Times aerospace reporter

Flight tests are likely to begin this week on the proposed software fix for Boeing’s 737 MAX flight control system, and the company has invited airlines to order it pending formal approval from the Federal Aviation Administration (FAA).

Boeing said Monday it is finalizing the proposed update. Some airline pilots flew 737 simulators with the updated system software in Renton on Saturday.

Company spokesman Gordon Johndroe said the MAX software fix will be offered to airlines “free of charge” and will be released only after it is certified by the FAA.

Meanwhile, the U.S. Department of Transportation (DOT) announced Monday the establishment of an expert “special committee” to review the FAA procedures for the certification of new aircraft, including the Boeing 737 MAX.

Retired Air Force Gen. Darren McDew, former head of the U.S. Transportation Command, and Captain Lee Moak, former president of the Air Line Pilots Association, will serve as the interim co-chairs of the panel, pending the appointment of other members.

Flaws in a new flight control system, called MCAS (Maneuvering Characteristics Augmentation System), that Boeing introduced on the MAX are suspected as having played a major role in two crashes in less than five months.

Boeing has been working on the software fix since last November after it became clear that MCAS had been inadvertently triggered before the crash of Lion Air Flight 610 the previous month. Evidence pointing again at MCAS in the crash of Ethiopian Airlines Flight 302 this month resulted in the FAA’s March 13 order to ground the plane.

On Saturday, Boeing held an information session for airlines and safety regulators in Renton to share details about the proposed software fix. The jetmaker said it also has invited more than 200 airline pilots, technical leaders and regulators for the next session in Renton on Wednesday.

A person familiar with how Saturday’s session was conducted said it was “very hands-on.” Airline pilots were able to fly the MAX with the updated software patch in a simulator, and were asked for their feedback.

A pilot with a U.S. airline that operates 737 MAX jets, who was briefed on the session, said his contacts “are very pleased with what they’ve seen so far in the software change.”

As early as this week, Boeing is likely to start actual 737 MAX flight tests for the purpose of certifying the new software.

An FAA spokesman said that as of noon Monday, the FAA was still awaiting details of Boeing’s fix. However, he added that “Boeing has kept the FAA in the loop throughout the process and we expect to receive the software from Boeing early this week.”

MCAS is designed to push the nose of the airplane down in certain stall situations by swiveling the horizontal tail. It’s triggered by a signal from a sensor measuring the plane’s angle of attack, which is the angle between the wings and the air flow.

The software fix will revamp how the system operates: One key change is that MCAS will be activated using input from both of the jet’s angle of attack sensors, rather than just one.

The update will also ensure MCAS is not triggered multiple times, as it was in the Lion Air crash. And it is likely to limit the maximum nose-down movement that the system can produce.

In addition to the software fix, Boeing has decided to include on the MAX, at no charge, two angle of attack indicators that were previously optional and available only at extra cost.

A person familiar with Boeing’s plans to get the grounding of the MAX lifted said that a light that warns when the two angle of attack sensors disagree will become a standard feature on the MAX from now on. And for airlines that request it, Boeing will retrofit this warning light at no charge on previously delivered airplanes.

In addition, Boeing will no longer charge airlines that choose an option to place the angle of attack data on the primary flight display.

But it’s unclear if these changes and the MCAS software fix, even if certified, will be enough to lift the grounding of the Boeing jets. For instance, the airplane’s flight manuals and the pilot training protocols will also have to be updated.

And the ongoing investigations into the two fatal jet crashes may bring other contributing factors to the surface.

The DOT special committee will conduct a broader investigation into how the FAA certifies new airplanes as safe. The way that currently works, in a process mandated by Congress, is that Boeing does most of the safety evaluations itself, then passes paperwork to the FAA for review.

A Seattle Times story this month revealed concern among FAA technical staff that they were not given enough time to do proper oversight of Boeing’s work on the safety analyses during certification of the MAX, and that too much of the analysis was delegated to Boeing employees.

Announcing the special committee Monday, Secretary of Transportation Elaine Chao said, “This review by leading outside experts will help determine if improvements can be made to the FAA aircraft certification process.”

Boeing said in response that the company will work with the special committee “to advance our shared goal of an aviation industry that is safe and trusted by the flying public.”
Zeffy is online now  
Old 26th Mar 2019, 14:53
  #2562 (permalink)  
 
Join Date: May 2000
Location: SV Marie Celeste
Posts: 552
Obviously there are plenty of malfunctions in any aircraft that require "some" pilot input before 40 seconds. EFATO, TRO, Unreliable airspeed, Autopilot disconnect, TCAS. GPWS, runaway stabiliser .... to name but a few. The premise of the article is flawed in my view.
calypso is offline  
Old 26th Mar 2019, 15:15
  #2563 (permalink)  
 
Join Date: Feb 2016
Location: S.E.Asia
Posts: 1,802

Boeing are being quite generous now...
In addition, Boeing will no longer charge airlines that choose an option to place the angle of attack data on the primary flight display.
If they did that from day one we might be in a better place today.

A lot of people died before Boeing decided their optional extra came at a human cost.
Mike Flynn is offline  
Old 26th Mar 2019, 15:36
  #2564 (permalink)  

SkyGod
 
Join Date: Aug 2000
Location: Ft. Lauderdale, Florida, USA
Age: 63
Posts: 1,483
Originally Posted by Mike Flynn View Post

Boeing are being quite generous now...


If they did that from day one we might be in a better place today.

A lot of people died before Boeing decided their optional extra came at a human cost.
Or people died because the pilots crashing had no idea how to shut of a runaway stab trim system?
TowerDog is offline  
Old 26th Mar 2019, 15:48
  #2565 (permalink)  
 
Join Date: Dec 2002
Location: UK
Posts: 1,950
Mike, #2580, et al,




Mark on this instrument the AoA value as reported for the Lion accident; change seats, mark your new instrument similarly.
Which way should you move the stick according to the display - whose display, who holds the stick.
Actually what is required is to hold the stick centrally, against an unexpected and unexplained increasing nose down trim force.
Would these ‘new’ optional displays help with this situation - after what training, for what scenarios. Or are they just another distraction, requiring comprehension by a ‘surprised mind’ already challenged by the need to control the aircraft.

Aero 12 - Angle of Attack

P.S. which other flight instrument parameter would be closely associated with AoA. Airspeed, particularly as this scale has an AoA derived low speed awareness cue.
So why would we expect an AoA dial to be positioned nearer the altitude display?

PPS. The EFIS location and dial format might be better used to display pitch trim
position.

An ill-conceived thought, with trim in mind, cf # 2585



Last edited by safetypee; 26th Mar 2019 at 17:39.
safetypee is offline  
Old 26th Mar 2019, 16:22
  #2566 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 58
Posts: 424
safetypee

PPS. The EFIS location and dial format might be better used to display pitch trim position.
I asked a question earlier in the thread, but it got lost. Do pilots ever look at the stabiliser trim analog scale on the pedestal during flight (after takeoff)?

You are asking a related question. My followup questions: Is there a digital value of stabiliser trim available on the flight control computers? Is this value used, or is trim driven from arbitrary positions by incremental turns of the jackscrew? Are there any software limits on the jackscrew position?

I may have this story backwards, but have not seen it discussed in relation to MCAS (nor in the Tech Log forum).
GordonR_Cape is offline  
Old 26th Mar 2019, 16:50
  #2567 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 802
Originally Posted by GordonR_Cape View Post
You are asking a related question. My followup questions: Is there a digital value of stabiliser trim available on the flight control computers?
According to AMM info there certainly was in the NG, specifically "stabilizer position" is shown as an input to the speed trim function. I don't see why it would have been removed, but I guess that is possible.

Whether and how it is used in the MCAS algorithm I don't know - I haven't seen any public info on it, and I don't have access to any non-public info.
infrequentflyer789 is offline  
Old 26th Mar 2019, 16:53
  #2568 (permalink)  
 
Join Date: Feb 2009
Location: Seattle
Posts: 379
Originally Posted by GordonR_Cape View Post
safetypee



I asked a question earlier in the thread, but it got lost. Do pilots ever look at the stabiliser trim analog scale on the pedestal during flight (after takeoff)?

You are asking a related question. My followup questions: Is there a digital value of stabiliser trim available on the flight control computers? Is this value used, or is trim driven from arbitrary positions by incremental turns of the jackscrew? Are there any software limits on the jackscrew position?

I may have this story backwards, but have not seen it discussed in relation to MCAS (nor in the Tech Log forum).
The only time that stabilizer positioning requires or even benefits from reference to the absolute position of the stabilizer is when on ground, preparing for takeoff. When in air, pilot commanded movement of the stabilizer is completely based on establishing pitch trim such that no column input is needed and the pilot is able to maintain the desired pitch attitude / with the column in its spring centered detent. The cue for the pilot to move the stabilizer when in flight is steady column force needed to balance airplane pitching moments to keep the pitch attitude where it is needed to achieve the desired steady state flight path response. Where the stabilizer ends up to achieve pitch trim is a function of CG, weight, thrust, speed, Mach number, flap position, speedbrake position, gear position, and anything else that might impose a steady pitching moment on the airplane.

There are limits on the stabilizer travel both in the software that is used to provide automatic stabilizer control and in the pilot trim input paths via electric wheel mounted trim switch and manual cranking of the mechanical trim wheel. These are designed to allow for the range of stabilizer positions that are needed to be able to achieve pitch trim throughout the flight envelope including the allowable range of loading and flap/speedbrake/gear configurations.
FCeng84 is offline  
Old 26th Mar 2019, 17:04
  #2569 (permalink)  
 
Join Date: Nov 2011
Location: Chicago
Age: 62
Posts: 32
Originally Posted by bsieker View Post
It hasn't been released. It has been shared with the other participants to the investigation, as stipulated by ICAO Annex 13.

It also won't speed up the public release of the data, because only the Ethiopian agency leading the investigation can do that.


Bernd
Can we finally at least expect some leaks of the data?
SquintyMagoo is offline  
Old 26th Mar 2019, 17:08
  #2570 (permalink)  
 
Join Date: Aug 2010
Location: UK
Age: 63
Posts: 20
Flight tests are likely to begin this week on the proposed software fix for Boeing’s 737 MAX flight control system, and the company has invited airlines to order it pending formal approval from the Federal Aviation Administration (FAA)
.

In my opinion, this should not need to be ordered, it should be a mandatory update SENT by Boeing
golfbananajam is offline  
Old 26th Mar 2019, 17:10
  #2571 (permalink)  
 
Join Date: Feb 2009
Location: Seattle
Posts: 379
Originally Posted by gums View Post
Salute!

Great article, pat.
The 40 secind scenario appears to be simply allowing the MCAS to act without the crew using the trim switches. Eventually, unless power is reduced, the aero forces on the elevator and the awesome column forces required will not permit a recovery. And who wants to pull power back just after gear up? ( although I did for my LEF episode as I was light and could easily fly at 200 knots - it was the old " doing O.K. now, so don't change anything" procedure that lets you live to be old and grey) I also feel most of the 737 folks here would have used the trim switches for a time before treating the problem as a FUBAR trim system and then turning off the power as the previous flight crew did.

The MCAS mod should be interesting and provide a feast of fodder here on PPRuNe, huh?

Gums sends...
One of the key elements to the baseline MCAS logic is that it will only put in a single increment of stabilizer motion as long as no pilot trim command is given. This goes in over no more than 10 seconds (less if operating at Mach number greater than 0.4 where MCAS single increment authority is less than 2.5 degrees). The amount of elevator needed to balance one MCAS increment of stabilizer motion will be approximately 5 degrees due to the 2:1 ratio of stabilizer to elevator pitch control power. That amount of elevator can readily be commanded via the column with plenty of additional pitch control authority available to perform any maneuvers needed to maintain desired flight path and speed (if, for instance, climbing with a fixed throttle while varying path to maintain speed). Even in the presence of errant AOA data causing MCAS to activate when actually at AOA well below the intended MCAS activation point, MCAS will not move the stabilizer more than one increment without the crew making a pitch trim input. The only path to compromised pitch control authority via the column is for the crew to make pitch trim inputs but not make sufficient pitch trim inputs to return the stabilizer to the proper trimmed position.

Where this notion of "40 seconds" comes from is a total mystery - particularly when coupled with the statement "... without the crew using the trim switches". The scenario that led to problems after 40 seconds must have included short, ineffective periods of crew pitch trim switch commands that did not establish column force free pitch trim but did enable MCAS to insert another increment of airplane nose down stabilizer.

FCeng84 provides clarity ...
FCeng84 is offline  
Old 26th Mar 2019, 18:23
  #2572 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,140
Salute1

@FCeng I got the 40 seconds and it is what I posted - 10 ,seconds without pilot trim switch,5 second rest, 10 seconds of trim with no pilot trim, 5 second rest and then 10 seconds trim without pilot trim. That would move the stab well over 5 degrees if stab was trimmed just above zero, but could max it out if trim was zero or more nose down.

One thing all 737 pilots need to understand is this
One of the key elements to the baseline MCAS logic is that it will only put in a single increment of stabilizer motion as long as no pilot trim command is given.
And then tell them that if the trigger event/value is still present that the process repeats.

Those Lion troops did a good job but for treating the problem as an MCAS quirk or STS working backwards as previous crew asserted, or a "runaway trim" that was not continuous. And besides, if they had heard about MCAS, then it was suposed to work making steep turns or slowing way down at cruise altitude or whatever and not be a stall prevention gizmo, and not activating just after flap retraction on takeoff.

Hoping new computer folks at Boeing do a better fault tree analysis this time.

Gums sends...
gums is offline  
Old 26th Mar 2019, 18:30
  #2573 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 58
Posts: 424
FCeng84

Thanks for your multiple clarifications! I appreciate the fact that my 'dumb' questions elecit enlightening responses.

Something that still puzzles me (I refetred to previously) is the contradiction between making MCAS safe under faulty AOA scenario, and effective under actual high AOA conditions.

1. Under the faulty AOA scenario MCAS activates but is only allowed one trim down increment, after which it is inhibited, with a relatively harmless outcome.
2. Under an actual high AOA condition MCAS will activate, and start to trim nose down. If (for whatever reason) the pilot decided to trim the nose fractionally up, this would inhibit MCAS. Following the new rules MCAS is only allowed to make one nose down operation. If the pilot does nothing further for 5 seconds and the AOA remains high, does the remainder of the nose down cycle complete? Or does it remain where the pilot left it, leaving the aircraft in a degraded condition, potentially falling outside regulatory requirements?
3. If an aircraft encounters two high AOA events in sequence, is MCAS inhibited for the second event? What time interval or event, would allow MCAS to be enabled for a second valid high AOA event activation?

Does any of this make sense, or have the details been worked out, and I am creating imaginary difficulties?

Edit: gums is asking the same kind of question.

Edit: Disabling MCAS if AOA disagree would remove gums fault scenario.

Edit: I see similar questions (and answers) being covered in the Stabiliser Trim thread. Potentially the moderators could move this entire discussion, though it follows closely on from earlier posts.

Last edited by GordonR_Cape; 26th Mar 2019 at 19:48. Reason: Other thread questions.
GordonR_Cape is offline  
Old 26th Mar 2019, 18:43
  #2574 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,140
Saute!

Good questions Gordon.

The way FCeng described it on another thread was that the MCAS returns trim to previous/ past position if the trigger event/condition no longer exists after the initial nose down trim command. So you can understand the logic, as the MCAS was only to reduce the nose up pitch moment as AoA approached stall value.

It was obvious with Lion 610 that the abnormal AoA was still present every time the 5 seconds elapsed. And the fact that every time the pilot beeped the trim switch that the uncommanded nose down disappeared.

[added] The sad part of the story is that the same AoA sensor MCAS was using was the one making the stick shake. And it may be that the left/right logic for the flight director and other stuff has a human factor deficiency as well

Gums sends...
gums is offline  
Old 26th Mar 2019, 19:12
  #2575 (permalink)  
 
Join Date: Jun 2009
Location: VA, USA
Age: 54
Posts: 561
Originally Posted by FCeng84 View Post
One of the key elements to the baseline MCAS logic is that it will only put in a single increment of stabilizer motion as long as no pilot trim command is given. This goes in over no more than 10 seconds (less if operating at Mach number greater than 0.4 where MCAS single increment authority is less than 2.5 degrees). The amount of elevator needed to balance one MCAS increment of stabilizer motion will be approximately 5 degrees due to the 2:1 ratio of stabilizer to elevator pitch control power. That amount of elevator can readily be commanded via the column with plenty of additional pitch control authority available to perform any maneuvers needed to maintain desired flight path and speed (if, for instance, climbing with a fixed throttle while varying path to maintain speed). Even in the presence of errant AOA data causing MCAS to activate when actually at AOA well below the intended MCAS activation point, MCAS will not move the stabilizer more than one increment without the crew making a pitch trim input. The only path to compromised pitch control authority via the column is for the crew to make pitch trim inputs but not make sufficient pitch trim inputs to return the stabilizer to the proper trimmed position.

Where this notion of "40 seconds" comes from is a total mystery - particularly when coupled with the statement "... without the crew using the trim switches". The scenario that led to problems after 40 seconds must have included short, ineffective periods of crew pitch trim switch commands that did not establish column force free pitch trim but did enable MCAS to insert another increment of airplane nose down stabilizer.

FCeng84 provides clarity ...
Request for clarification:

Do I understand this correctly?

If MCAS detects an AOA that satisfies whatever criteria is needed, it activates 10 seconds (or less, depending on Mach number) of nose down trim for a maximum of 2.5 degrees nose down trim and stops.

If NO pilot trim input is commanded, MCAS remains disabled?

Thanks, GY
GarageYears is offline  
Old 26th Mar 2019, 19:56
  #2576 (permalink)  
 
Join Date: Nov 2012
Location: New York
Posts: 11
Originally Posted by FCeng84 View Post
FCeng84 provides clarity ...
Thank goodness. But there still appears to be confusion.

Originally Posted by gums View Post
One thing all 737 pilots need to understand is this
Originally Posted by FCeng84 View Post
One of the key elements to the baseline MCAS logic is that it will only put in a single increment of stabilizer motion as long as no pilot trim command is given.
Originally Posted by gums View Post
And then tell them that if the trigger event/value is still present that the process repeats.
FCeng84 and other sources I've read over the course of this and the Lion Air thread seem to say this is not true. In the existing MCAS, there is only a single 10s (or less) nose-down trim provided, even if the trigger event/value is still present, unless the pilot makes a pitch trim input. This resets the MCAS state, resulting in a 5 second delay, followed by more nose-down trim if the condition is still met. If no pitch trim inputs are made, MCAS will not trim further down (but may restore trim). I can understand the logic to reset the MCAS state, because it can no longer make a trim/AOA association once the pilot changes the trim.

Is there a reference for what gums says?

Originally Posted by gums View Post
Those Lion troops did a good job but for treating the problem as an MCAS quirk or STS working backwards as previous crew asserted, or a "runaway trim" that was not continuous. And besides, if they had heard about MCAS, then it was suposed to work making steep turns or slowing way down at cruise altitude or whatever and not be a stall prevention gizmo, and not activating just after flap retraction on takeoff.

Hoping new computer folks at Boeing do a better fault tree analysis this time.

Gums sends...
I can understand cirticism of an MCAS that should be more fault-tolerant and pilot-tolerant, and apparently that is what Boeing is designing and documenting. This has been said before, but it appears the engineers didn't consider that the pilot may make pitch trim changes that do not put the h stab into a proper position, and that the resulting state reset then could have bad consequences if the pilot hadn't already turned stab trim off.

I was happy to see data early and often from Lion 610. Having an open, informed discussion of what happened is the best way to improve safety. I hope to see this soon for ET302.
hawk76 is offline  
Old 26th Mar 2019, 20:51
  #2577 (permalink)  
 
Join Date: Sep 2011
Location: Belgium
Age: 60
Posts: 139
Sometimes it is very good to go back to basics. => I have read the lot, and the focus is on the wrong point

IF, and I say ; "IF" , no AOA sensor had failed, not a soul would have heard about what the MCAS was / is / is going to do.

All these events start 'or are triggered by" failing AOA sensors. => And naturally the single probe problem MCAS surfaces, and then what MCAS is trying surfaces, but it all starts with the failing AOA SENSOR/system.
The MAIN FOCUS should be on WHY the AOA probe/system fails.
Vilters is offline  
Old 26th Mar 2019, 21:07
  #2578 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 5,246
Originally Posted by SquintyMagoo View Post
Can we finally at least expect some leaks of the data?
depends

Who has the most to gain?
lomapaseo is offline  
Old 26th Mar 2019, 21:43
  #2579 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,140
Salute!

Good questions, Hawk.

The Lion 610 data clearly shows the MCAS reset and then the 5 second delay. All the while the AoA from the pilot sensor is up at 20 degrees or so from the other side. You can also see the flap position logic in action. So the MCAS worked as designed, but had FUBAR AoA data. I would love to see MCAS act in an approach to stall in a banked turn where the pilot could simply relax back pressure and the AoA would go down. Then see what MCAS does.

Without a data table to check the traces second by second, it is hard to tll if MCAS re-trimmed back to what is was when it first trimmed or that the pilot commanded a whole lotta nose up trim. From the plot, looks like he trimmed up a lo, but all the way back to the original stab angle. Right at the end you can see that the FO did not rettrim as much, so I am questioning the complete reset

Gums sends...
gums is offline  
Old 26th Mar 2019, 21:51
  #2580 (permalink)  
 
Join Date: Jun 2009
Location: Dorset
Posts: 30
Originally Posted by patplan View Post
The MX in CGK didn't suspect the newly replaced vane to be the caused.


This multiple and varied mix of fault reports (all ADIRU related) suggests the problems are nothing to do with a faulty AoA sensor, but a problem within the ADIRU. Perhaps something like a erratic reference voltage to the A to D converter affecting several channels. The AoA sensor was replaced possibly just as a hopeful guess. The assumption then seems to have been jumped on that as the MCAS uses AoA, the errant behaviour of MCAS must have been due to an AoA fault. Possibly the ADIRU fault is 'confusing' the MCAS; perhaps it cannot handle AoA values that are all over the place and gets trapped in a logic loop. Can I ask a question of the many experts on this forum, are the ADIRUs, the displays and MCAS (FCCs) all on the same ARINC bus?

VicMel is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information

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