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 30th Mar 2019, 11:23
  #2781 (permalink)  
 
Join Date: Nov 2007
Location: Canada
Posts: 25
I would like to know how many similar snags ( Stick Shaker, Unreliable AS, use of Stab Trim cutout switches ) have been logged on the MAX?
dozing4dollars is offline  
Old 30th Mar 2019, 11:39
  #2782 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,895
Originally Posted by WingNut60 View Post
The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.
There's no reference to any maintenance action involving the AoA sensor at Jakarta in the report.

Dave can you point me to the JT incident report please. I just can't find a link.
http://knkt.dephub.go.id/knkt/ntsc_a...y%20Report.pdf
DaveReidUK is online now  
Old 30th Mar 2019, 11:49
  #2783 (permalink)  
 
Join Date: Oct 2008
Location: Melbourne, ɐıןɐɹʇsn∀
Age: 70
Posts: 58
Originally Posted by WingNut60 View Post
The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.

Dave can you point me to the JT incident report please. I just can't find a link.
Maybe this post helps...
Indonesian aircraft missing off Jakarta
LandIT is offline  
Old 30th Mar 2019, 12:05
  #2784 (permalink)  
 
Join Date: Nov 2018
Location: Vancouver
Posts: 63
Originally Posted by WingNut60 View Post
The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.

Dave can you point me to the JT incident report please. I just can't find a link.

FYI - "Cleaning a connector...." is a really dangerous euphemism in Indonesia.
From pp. 7-9 Preliminary Accident Report of Lion Air PK-LQP


AOA was not touched in Jakarta, as MX suspected problem(s) laid elsewhere in the system. He fixed other things as mentioned by the CAPT of JT043: "IAS disagree & ALT disagree and Feel Diff Press Light".

Well, his fixes neither cured the problems nor made things any better for the pilots of the next sector. The rest is history.
patplan is offline  
Old 30th Mar 2019, 12:10
  #2785 (permalink)  
 
Join Date: Jan 2008
Location: Hanoi
Posts: 34
Originally Posted by Water pilot View Post
With the caveat that I have no inside knowledge of Boeing's programs and so could be talking though my hat, I would be surprised if there were anything as complex as a 'process' in this control system. Even the most simple and minimal operating system introduces a heck of a lot of unnecessary complexity. It is likely that everything runs in the same memory space (especially if it is a 286) and looks like one large interrupt driven program. They probably have some sort of minimal 'frame' so they can compile together the various developer's work, but it is probably quite small and simple compared to the millions of lines of code (literally) that you will see in an operating system.
Unless Boeing are literally working with technology from the stone age your description is about as far from reality as is possible for any modern safety related software.

How many safety critical software systems have you designed, had approved, and put in the field ?
fergusd is offline  
Old 30th Mar 2019, 12:20
  #2786 (permalink)  
 
Join Date: Jan 2008
Location: Herts, UK
Posts: 736
Originally Posted by Torquelink View Post
From Bjorn Fehrm of Leeham today:

This week Boeing presented how they plan to get the 737 MAX back in the air again. MCAS has a fix.We look at what the fix tells us about the first implementation and the rationale behind its implementation.



Figure 1. The improved Pilot’s Primary Flight Display presented Wednesday. Source: Boeing.
Boeing’s MCAS fix casts light on the original implementation
Boeing presented its fix for the MCAS problems Wednesday. By it, it spotlights what was wrong with the original implementation.
The reliance on a single triggering signal for MCAS
A lot has been written about the MCAS system relying on a single Angle of Attack input. This is unusual for systems involved in the flight control of aircraft. Normally you have three inputs so a voting procedure can sort out one of them if it has a problem (two singling out the third as faulty).

The 737 has only two Angle of Attack sensors, so no voting can be set up between them. Instead, the system relying on the sensors can be switched off if the sensors disagree and the pilot informed about the missing function.

This is the route chosen for the improved MCAS. It will now be disconnected when the sensed Angle of Attack difference is beyond 5.5 degrees when MCAS activates and over 10 degrees for over 10s when the system is in use.

The wide allowed difference shows what I have written about before. The aerodynamics around these sensor vanes, placed at the nose sides, is dependent on how the aircraft is flown. If there is a sideslip the airflow passing the sensors will be affected and the sensor values will differ.

The actual sensor value is also higher than the wing Angle of Attack (the airflow around a fuselage nose is curving upward), therefore a correction table is used to calculate the wing’s Angle of Attack. It’s the wing’s Angle of Attack which determines how close to stall the aircraft is.

Was the use of only one signal OK to trigger the original MCAS? No, it wasn’t. But at least there was a rationale for this decision, whatever one might think about the rationale. A deactivation of MCAS was not an acceptable solution as it would trigger a need for an MCAS not available signal and this would mean more difference training for the Pilots migrating from 737ng to MAX.
The design of the original MCAS function
While the reliance on a single sensor is highly questionable, the architecture and implementation of the original MCAS function in inexcusable.

If you have a flight control function which is triggered by a single sensor, it means the likelihood it being incorrectly activated is there. Then you implement a nonhazardous augmentation function!

You make sure it only injects the minimum correction necessary and you limit its total authority to not jeopardize the safe flight of the aircraft.

Where others focus on a single trigger signal, my biggest problem is with the function itself. If you have a weak trigger architecture, you limit the authority of what you trigger!

There was no need for the authority MCAS got. We know this today as the software fix only trims once for each elevated Angle of Attack event and limits the total trim amount to a safe level. This is regardless of the sensors being wrong or the function running wild.

It was just a very, very bad function design, and there was no need for it.
Designed to not show, it became the centerpiece of attention
MCAS was a function put there to cater for a very remote case. The pilot needs to maneuver close to the limits of the aircraft and way beyond normal flying practice, to save the aircraft from some emergency. Then MCAS kicked in to make the aircraft easy to fly close to its limits.

In the life of a commercial 737 MAX pilot he should never experience an MCAS augmentation, its use case was so remote. Instead, it became the most known and explained function of all on the 737 MAX. And for the wrong, very sad reasons.

There are only a few airliner OEMs in the world. There is a reason for this. It’s a challenging product to get right and the stakes are very high for any mistakes. In today’s very safe air transport system mistakes of this scale are non-acceptable.
Tick, tick and tick... 10/10 👍
HarryMann is offline  
Old 30th Mar 2019, 12:21
  #2787 (permalink)  
 
Join Date: Nov 2018
Location: Vancouver
Posts: 63
Originally Posted by WingNut60 View Post
The AoA sensor was reported as changed in DPS only, I think. Not Jakarta.
I'm talking about Jakarta.

Dave can you point me to the JT incident report please. I just can't find a link.

FYI - "Cleaning a connector...." is a really dangerous euphemism in Indonesia.
Something of interest perhaps...
Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
By Simon Hradecky, created Tuesday, Nov 20th 2018 20:04Z, last updated Tuesday, Nov 20th 2018 20:04ZA
Sunwing Airlines Boeing 737 MAX 8, registration C-GMXB performing flight WG-439 from Punta Cana (Dominican Republic) to Toronto,ON (Canada) with 176 passengers and 6 crew, was enroute at FL350 about 50nm northwest of Washington Dulles Airport,DC (USA) when the captain's instruments began to show erroneous indications. The first officer was handed control of the aircraft as his instruments and the standby instruments remained in agreement. The crew decided to descend out of IMC into VMC as a precaution and descended the aircraft to FL250. Descending through FL280 the weather radar and TCAS failed. The crew declared PAN and worked the related checklists. The left IRS fault light illuminated. The flight continued to Toronto for a safe landing without further incident.

The Canadian TSB reported the left ADIRU was replaced.
=====

I have a suspicion that in Boeing 737 Max 8 [B38M] perhaps the LEFT/CAPT ADIRU is constantly being overwhelmed by new routines [i.e. MCAS/AOA related programmings] which may from time to time corrupt the system.

- Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
patplan is offline  
Old 30th Mar 2019, 12:24
  #2788 (permalink)  
 
Join Date: Oct 2007
Location: Germany
Posts: 4
Originally Posted by Water pilot View Post
With the caveat that I have no inside knowledge of Boeing's programs and so could be talking though my hat, I would be surprised if there were anything as complex as a 'process' in this control system. Even the most simple and minimal operating system introduces a heck of a lot of unnecessary complexity. It is likely that everything runs in the same memory space (especially if it is a 286) and looks like one large interrupt driven program. They probably have some sort of minimal 'frame' so they can compile together the various developer's work, but it is probably quite small and simple compared to the millions of lines of code (literally) that you will see in an operating system.
This is definetly far away from the truth...
ThorMos is online now  
Old 30th Mar 2019, 12:25
  #2789 (permalink)  
 
Join Date: Dec 2010
Location: Balikpapan, INDONESIA
Age: 67
Posts: 519
Thanks Dave, et al for links.

Originally Posted by patplan View Post
AOA was not touched in Jakarta, as MX suspected problem(s) laid elsewhere in the system. He fixed other things as mentioned by the CAPT of JT043: "IAS disagree & ALT disagree and Feel Diff Press Light".

Well, his fixes neither cured the problems nor made things any better for the pilots of the next sector. The rest is history.
Correct.
After reading top to tail, nothing to indicate that anything either useful or otherwise untoward was carried out in JKT.
WingNut60 is online now  
Old 30th Mar 2019, 12:26
  #2790 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 58
Posts: 416
ecto

It has a very specific behaviour: 10 or 12 degrees offset, higher on the left at power - up, fairly stable on both sides, then during taxi hardly any real movement at any side, but several (6 or 8) short instances of left AOA vane reading ramping up a few degrees at a time, not vertically (cliff) but at a slope, increasing the offset to about 25 deg, then at rotation the right one increases (normal) the left one decreases (abnormal) and then both set at 22 degrees offset and seem to measure quite faithfully to each other (apart from the offset) for the rest of the flight.
Your analysis is fundamentally flawed because AOA is not valid before takeoff, and any data points prior to that must be ignored. The AOA sensor relies on significant forward speed to align the vane with the airflow, and this is not possible while taxiing.
GordonR_Cape is online now  
Old 30th Mar 2019, 12:50
  #2791 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 58
Posts: 416
Originally Posted by patplan View Post
Something of interest perhaps...
Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures

By Simon Hradecky, created Tuesday, Nov 20th 2018 20:04Z, last updated Tuesday, Nov 20th 2018 20:04ZA
Sunwing Airlines Boeing 737 MAX 8, registration C-GMXB performing flight WG-439 from Punta Cana (Dominican Republic) to Toronto,ON (Canada) with 176 passengers and 6 crew, was enroute at FL350 about 50nm northwest of Washington Dulles Airport,DC (USA) when the captain's instruments began to show erroneous indications. The first officer was handed control of the aircraft as his instruments and the standby instruments remained in agreement. The crew decided to descend out of IMC into VMC as a precaution and descended the aircraft to FL250. Descending through FL280 the weather radar and TCAS failed. The crew declared PAN and worked the related checklists. The left IRS fault light illuminated. The flight continued to Toronto for a safe landing without further incident.

The Canadian TSB reported the left ADIRU was replaced.
=====


I have a suspicion that in Boeing 737 Max 8 [B38M] perhaps the LEFT/CAPT ADIRU is constantly being overwhelmed by new routines [i.e. MCAS/AOA related programmings] which may from time to time corrupt the system.

- Incident: Sunwing B38M near Washington on Nov 14th 2018, multiple system failures
Very interesting information, but raises more questions than answers!

My first question is why did MCAS not activate, unlike the other two cases?
I would speculate 3 possible answers to that:
1. The flight was in autopilot at the time (inhibiting MCAS), and/or FCC was subsequently turned off by crew, or kept on till flaps down.
2. The AOA fault on captain's side may have been nose down (not nose up), so that stick shaker and MCAS were not triggered.
3. On that flight MCAS was active on the co-pilot's flight computer (not captain's side).
They may have survived purely by these chance factors (or good CRM...)

Edit: A question about what happened to the faulty ADIRU: Was it kept and repaired, sent back to the manufacturer, or perhaps handed over to the Canadian TSB? Was this a reportable event, or purely a maintenance issue?
GordonR_Cape is online now  
Old 30th Mar 2019, 14:10
  #2792 (permalink)  
 
Join Date: Jun 2009
Location: Tewksbury Mass USA
Age: 76
Posts: 42
That EASA Link

https://www.easa.europa.eu/sites/def...20ISS%2010.pdf REF TO PAGE 15 OF THIS DOCUMENT > Explanatory Note to TCDS IM.A.120 – Boeing 737
Data Guy is offline  
Old 30th Mar 2019, 14:27
  #2793 (permalink)  
 
Join Date: Oct 2004
Location: NY - USA
Age: 64
Posts: 65
Originally Posted by GordonR_Cape View Post
Very interesting information, but raises more questions than answers!

My first question is why did MCAS not activate, unlike the other two cases?
I would speculate 3 possible answers to that:
1. The flight was in autopilot at the time (inhibiting MCAS), and/or FCC was subsequently turned off by crew, or kept on till flaps down.
2. The AOA fault on captain's side may have been nose down (not nose up), so that stick shaker and MCAS were not triggered.
3. On that flight MCAS was active on the co-pilot's flight computer (not captain's side).
They may have survived purely by these chance factors (or good CRM...)

Edit: A question about what happened to the faulty ADIRU: Was it kept and repaired, sent back to the manufacturer, or perhaps handed over to the Canadian TSB? Was this a reportable event, or purely a maintenance issue?
There is nothing in that report to indicate there was an AOA problem, specifically. The symptoms sound more like a failure of the ADIRU itself. If the air data portion of the ADIRU failed, it would cause a miscompare in altitude or airspeed. If the IRU portion failed, it would cause a miscompare in pitch, roll and heading. Either type of failure would cause an autopilot disconnection.

The weather radar depends on accurate IRU pitch and roll data for stabilization, and IRU data is also used by the TCAS.

Because of the two crashes, now ANY in-flight technical failure on a 737-8 MAX aircraft is going to draw immediate media attention - as we saw just a few days ago with the engine problem on the SWA ferry flight departing MCO.

JRBarrett is offline  
Old 30th Mar 2019, 16:33
  #2794 (permalink)  
 
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 484
RE: EASA Explanatory Note

Originally Posted by Data Guy View Post
https://www.easa.europa.eu/sites/def...20ISS%2010.pdf REF TO PAGE 15 OF THIS DOCUMENT > Explanatory Note to TCDS IM.A.120 – Boeing 737
Very interesting. Well worth reading. Here are the first and penultimate paragraphs:

The aisle stand trim switches can be used to trim the airplane throughout the flight envelope and fully complies with the reference regulation Simulation has demonstrated that the thumb switch trim does not have enough authority to completely trim the aircraft longitudinally in certain corners of the flight envelope, e.g. gear up/flaps up, aft center of gravity, near Vmo/Mmo corner, and gear down/flaps up, at speeds above 230 kts.In those cases, longitudinal trim is achieved by using the manual stabilizer trim wheel to position the stabilizer. The trim wheel can be used to trim the airplane throughout the entire flight envelope.In addition, the autopilot has the authority to trim the airplane in these conditions.
[. . .]
Furthermore, the additional crew procedures and training material will clearly explain to pilots the situations where use of the trim wheel may be needed due to lack of trim authority with the wheel mounted switches.
OldnGrounded is offline  
Old 30th Mar 2019, 16:52
  #2795 (permalink)  
 
Join Date: Nov 2018
Location: madrid
Posts: 47
Originally Posted by GordonR_Cape View Post
ecto



Your analysis is fundamentally flawed because AOA is not valid before takeoff, and any data points prior to that must be ignored. The AOA sensor relies on significant forward speed to align the vane with the airflow, and this is not possible while taxiing.
IMHO,

Any data points before takeoff (or after landing) do not correlate with real AOA values, without significant forward speed the vane will not reflect anything resembling AOA: Obviously correct.

These data points should be ignored? I don't agree. Lots and lots of hints there.

For instance, a constant offset theory (like bad indexing) doesn't hold water:

If the offset were there from the power on, as in a software error, it is an amazing coincidence that the right side vane, supposedly ok, has no noise and very minimal changes on the ground while the left one (suspect) has significant noise and/or large changes in both flights. (true I'm only basing this on 3 taxi events, but each is some minutes long). As opposed as in the air, where you could not tell one from the other if it wasn't for the offset. Wind on the ground will move the vanes randomly, of course, but it is an amazing coincidence that only left side dances in all three taxiing events.

Another example. If the offset were a consequence of a wrong correction table based on airspeed being used in the left side computer, it would be an impossible coincidence that the offset remained after landing with airspeed back to zero, as we can see in the data trace of the previous flight.

I would regard any proposed theory better if it is consistent with that behaviour in the air and on the ground seen in both data traces.

In fact, due to Occam's razor, any theory should also be consistent with the rest of the alarms. Specially the FEEL PRESS DIFF. There must be a root cause for all this.

Don't you agree?




ecto1 is offline  
Old 30th Mar 2019, 17:07
  #2796 (permalink)  
 
Join Date: Jul 2008
Location: en route
Posts: 201
Originally Posted by OldnGrounded View Post
From reading the comments on the mainstream media stories covering this issue, my sense is that a large percentage of pax don't have that faith. I'll be surprised if there isn't widespread reluctance to fly the MAX as SLF, when it returns to commercial service.
Many of us said the same about the early 78, during its 'Firebird' days. Five years later, the 78 gets consistently high ratings by that minority of the passenger community who have any clue what aircraft type they are flying on. Of course, there were no revenue hull losses during the 78's problem period, and one can assume the two crashes will count more against the 73-Max in perception terms. But I suspect in 5 years time most pax will be flying the 73-Max-10/11/12 without a second thought.

Boeing are going to make damn sure branding of the next variant of the Max will be an ocean of clear blue water away from the Max-8/9. They might even drop the 'Max' name, and come up with something touchy-feely that taps into the 'Dreamliner' imagery - The '737-Sunliner', perhaps.
rcsa is offline  
Old 30th Mar 2019, 17:49
  #2797 (permalink)  
 
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 484
Originally Posted by rcsa View Post
But I suspect in 5 years time most pax will be flying the 73-Max-10/11/12 without a second thought.
Agreed. But I don't think that's likely to be true for the year or two after the MAX gets back into the air.

Boeing are going to make damn sure branding of the next variant of the Max will be an ocean of clear blue water away from the Max-8/9. They might even drop the 'Max' name, and come up with something touchy-feely that taps into the 'Dreamliner' imagery - The '737-Sunliner', perhaps.
Indeed. There's probably a branding and imagery team working on it as we type.

OldnGrounded is offline  
Old 30th Mar 2019, 17:52
  #2798 (permalink)  
 
Join Date: Aug 2009
Location: Brussels
Age: 67
Posts: 10
“From reading the comments on the mainstream media stories covering this issue, my sense is that a large percentage of pax don't have that faith. I'll be surprised if there isn't widespread reluctance to fly the MAX as SLF, when it returns to commercial service”

I’m former ATC and I can tell you that even before the MAX was grounded I had checked that my next flight was NOT a MAX, otherwise I would have cancelled it right away. This beeing said, I think that with time, assuming the MAX is allowed to fly again, fewer and fewer people will keep in mind that this version of the venerable 737 has gone a step too far and is probably the last “improved” version of this cable and pulleys dinausaur.
Yet, our last chance of pushing certification agencies to take their mission seriously is for the travellers to refuse to board a plane when they have good reasons to believe their safety was sacrified to better profit for the shareholders which is clearly the case here.

Vincent
vbp.net is offline  
Old 30th Mar 2019, 18:12
  #2799 (permalink)  
 
Join Date: Sep 2006
Location: here and there
Posts: 162



Originally Posted by weemonkey View Post
Interesting choice of aoa information presentation.

Wouldn't a vertical strip type lead to superior intuitive comprehension?
Totally agree, absolutely horrible placement of both AOA indicator and AOA disgree flag. Both should be adjacent to airspeed indicator.
formulaben is offline  
Old 30th Mar 2019, 19:57
  #2800 (permalink)  
 
Join Date: Aug 2013
Location: Washington.
Age: 69
Posts: 494
Originally Posted by formulaben View Post





Totally agree, absolutely horrible placement of both AOA indicator and AOA disgree flag. Both should be adjacent to airspeed indicator.
Band-aid on a band-aid - that's the Boeing design philosophy of the Max. The AoA display makes little, if any, safety contribution to the flight deck (procedure wise) and the AOA disagree light even less. What is a pilot supposed to do when the AoA disagree light illuminates? Hit the trim switches? I wonder how often that light will illuminate, anyway. Probably often enough to get ignored.
GlobalNav 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.