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 28th Mar 2019, 16:14
  #2681 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 15,788
Received 196 Likes on 90 Posts
Originally Posted by netstruggler
26bits gives a resolution of approx 1 part in 70 million. What on an aircraft needs to be measured to that resolution?
It doesn't need 26 bits. It needs, amongst others, Bit Number 26 (Bits Nos 17 to 29, in fact).

LSB is 0.044° (though I doubt an AoA vane can actually measure even to that precision).
DaveReidUK is online now  
Old 28th Mar 2019, 16:32
  #2682 (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
Thank you safetypee!!!!!!!!!!!!! That has been my exact point so many times.

If assessed against "unlimited", it would have been hazardous. That must also be assessed in the context of the aft column cutout switch being disabled.

The decision to disable the aft column cutout switch may not have been assessed as a hazard at all. Yet, this was the most threatening change made by Boeing, and very likely took away the last thread for survival on JT610 and I fear ET302.

Last edited by Loose rivets; 29th Mar 2019 at 01:23.
Loose rivets is offline  
Old 28th Mar 2019, 17:02
  #2683 (permalink)  
 
Join Date: Oct 2004
Location: California
Posts: 385
Likes: 0
Received 4 Likes on 4 Posts
Originally Posted by Fzz
If the problem was a fixed offset due to a stuck bit, we'd expect the offset to be constant after the aircraft has airspeed.
Stuck bits are more likely an optical encoder error in the AOA vane, not a software error.
MarcK is offline  
Old 28th Mar 2019, 17:07
  #2684 (permalink)  
 
Join Date: Apr 2018
Location: Sudbury, Suffolk
Posts: 254
Received 0 Likes on 0 Posts
Originally Posted by MarcK
Stuck bits are more likely an optical encoder error in the AOA vane, not a software error.
How likely is that in two different aircraft (or maybe more if we take into account NASA reports)? Is that a possible QC issue at manufacture?

(I realise that I have jumped to more conclusions than a champion pole vaulter)

Last edited by Maninthebar; 28th Mar 2019 at 17:18.
Maninthebar is offline  
Old 28th Mar 2019, 18:56
  #2685 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by MarcK
Stuck bits are more likely an optical encoder error in the AOA vane, not a software error.
Wow! You have just reminded me of something that caused us a great deal of trouble, on a completely different different piece of equipment. Our electric gate motor closing mechanism used to give problems, due to contamination of the digital encoding optical sensor (a glorified rotary counter).

I know the AOA is completely different sensor, but in the context of this thread that might consistently produce a consistent bit-flip (20 degrees) error.

Originally Posted by Maninthebar
How likely is that in two different aircraft (or maybe more if we take into account NASA reports)? Is that a possible QC issue at manufacture?

(I realise that I have jumped to more conclusions than a champion pole vaulter)
Possible QC error that only reveals after a few months service?

In our case it was it was an oil leak from the bearing that got onto/contaminated the optical sensor.
GordonR_Cape is offline  
Old 28th Mar 2019, 19:43
  #2686 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by MarcK
Stuck bits are more likely an optical encoder error in the AOA vane, not a software error.
An absolute encoder is usually encoded with gray code or something similar, and I would expect a SIL3 encoder to have two encoders on the same shaft to make it fault silent.
Is IEC61508 SIL used in aircraft ?
https://www.tr-electronic.com/products/sil.html
HighWind is offline  
Old 28th Mar 2019, 20:09
  #2687 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 81
Posts: 1,330
Received 0 Likes on 0 Posts
Originally Posted by MarcK
Stuck bits are more likely an optical encoder error in the AOA vane, not a software error.
IF the vane had been changed out after displaying the same problem on JT43, then the accident flight JT610 wouldn't have had the same error.

The offset IMO is a downstream A/D problem, that wasn't picked up probably because there was no comparison made between AoA vane physical position and A/D output prior to and after changing the vane.
mm43 is offline  
Old 28th Mar 2019, 21:13
  #2688 (permalink)  
 
Join Date: Dec 2018
Posts: 48
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by BobM2
No, not wrong focus. Nobody is advocating RTO above Vr unless unlimited runway is available. A faulty AOA could give a stick shaker on take-off rotation in any airplane whether it has MCAS or not. The point I am trying to make is if the airplane is climbing & accelerating normally & stick shaker is on one side only, it is an AOA failure & not a valid stall warning. The correct response to this is to return & land the airplane. Get it fixed! You don't accelerate, clean up the flaps & try to continue the flight with an active stick shaker as Lion Air did on two occasions, only one of which was successful (barely).
I guess there's not much on here that hasn't already been written.

"Runaway stab" was the real problem and isn't normally accompanied by all the other indications and certainly isn't trained that way. Nor did it start until after clean up and certainly wasn't visible at Vr.

I think the correct question is how did two professionally trained crews fly it into the ground?

While agreeing with you the best response, and perhaps many crews would find it, I don't find clean up and climb obviously unintuitive.

Perhaps the nuts and bolts of this is why was a reasonable intuitive response so dangerous?

Last edited by pilot9250; 28th Mar 2019 at 23:35.
pilot9250 is offline  
Old 28th Mar 2019, 22:39
  #2689 (permalink)  
 
Join Date: Jun 2009
Location: California
Posts: 30
Likes: 0
Received 0 Likes on 0 Posts
That no one who wrote the MCAS software for the 737 MAX seems to have even raised the issue of using multiple inputs, including
the opposite angle of attack sensor, in the computer’s determination of an impending stall is mind-blowing. As a lifetime member
of the software development fraternity, I don’t know what toxic combination of inexperience, hubris, or lack of cultural understanding led to this.


But I do know that it’s indicative of a much deeper and much more troubling problem. The people who wrote the code for the
original MCAS system were obviously terribly far out of their league and did not know it. How can we possibly think they can
implement a software fix, much less give us any comfort whatsoever that the rest of the flight management software, which is
ultimately in ultimate control of the aircraft, has any fidelity at all?
https://drive.google.com/file/d/1249...-PSC6nFA5/view


Travis is unequivocal in his assessment of the Boeing 737 MAX. “It’s a faulty airframe. You’ve got to fix the airframe [and] you can’t fix the airframe without moving the engines” back and away from their current position.The root problem with the engine-forward design is “once this thing pitches up, it wants to keep pitching up,” said Travis. “That’s a big no-no,” he continued, because pitch-up on an aircraft increases angle of attack.

....Travis insists that the pilots of the two fatal 737 MAX flights could not have overridden the system no matter how hard they pulled on the yoke. The only way the system could be overridden was by hitting a circuit breaker that should have been prominently displayed among the 737 MAX controls.
https://www.eetimes.com/document.asp?doc_id=1334482#
Towhee is offline  
Old 28th Mar 2019, 22:46
  #2690 (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
The vanes are a supreme bit of kit. As posted earlier, they probably have an AC voltage out, continuously variable, centred on 0, and swinging + or _ . this is derived by a reference AC voltage in, and variable transformer coupling either side of zero - proportional to the vane angle.

Most non-scheduled vane changes are because of heater failure. That constant-ish error 'must' be due to downstream electronics.

Let's get back to the recent thrust of the thread. What other factors added to the vane's error signal and so radically confused two separate crews?
Loose rivets is offline  
Old 28th Mar 2019, 22:47
  #2691 (permalink)  
 
Join Date: Nov 2007
Location: dublin
Posts: 2
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by wiedehopf
I'm really curious why people don't look at the FDR graphs from the Lion Air flight.
They are readily available.
The airspeed difference between left and right side is about 10 to 20 knots.
The FDR readout is not consistent with a blocked pitot.

The pitot readout as well as the static port readout is corrected for AoA slightly, that is were the Airspeed disagree comes from.
This correction for AoA is small so even with the left AoA reading 21 degrees high the magnitude of the error on speed and altitude is there but both are still in the right ballpark.
I've attached the FDR readout from the first pdf report that was available on the Lion Air crash (with some annotations):


In this graph only the left side altitude readout is plotted, in the preliminary report you can see the difference to the side with working AoA:
https://www.flightradar24.com/blog/w...ary-Report.pdf

Note also that the 100-200 ft altitude dip on rotation is present on the Ethiopian ADSB data as well.
(That alone doesn't mean that there the AoA was misreading in that case as well but i makes it more likely in my opinion)
good analysis Wiedehopf. The ias disagree messsges and stick shakers may have caused confusion. But this was not an airspeed disagree crash like AF447 but a Stabilizer running fully nose down. We know why. It was not noticed &or stopped for reasons yet to be determined. Stopping the STAB and retrimming would have made the plane fly normally. Straight and level. As the day before. Even with IAS DISAGREE The pilots would still have GPS, pitch and power and one IAS would have been reading correctly- possibly two. THE SBY ASI should have been ok. As well as the unaffected side? These are all supposition but are possible scenarios given the info so far. For me the fact that the previous flight had similar problems with totally different outcomes is significant.
I am not sure if the safety office had picked up on the previous incident.
yanrair is offline  
Old 28th Mar 2019, 22:53
  #2692 (permalink)  
 
Join Date: Nov 2007
Location: dublin
Posts: 2
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by concernedengineer
I am glad to see this topic being broached. The present incident has in common with other LOC incidents the feature that the crew is faced with an all of nothing situation. Continue to rely on automation which may exacerbate a bad situation, or choosing to go manual which may be a time consuming and unfamiliar transition in a situation where time is of the essence. This is akin (worse) that a car driver having to disable power steering and brakes because of a malfunctioning cruise control. Surely there should be a lower level of automation the pilot could revert to but still giving him/her power assistance with the control surfaces, and some degree of automatic recovery, while bypassing higher level problems. This lower level should involve only the most basic, reliable components. Does Airbus do this already?
The 737-Max can of course be flown in total manual mode. It’s about the only series of models that can- all 737s can.
You can even lose ALL hydraulic and all AC POWER and it still flies.
yanrair is offline  
Old 28th Mar 2019, 23:15
  #2693 (permalink)  
 
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Turbine70
I guess there's not much on here that hasn't already been written.

"Runaway stab" was the real problem and isn't normally accompanied by all the other indications and certainly isn't trained that way. Nor did it start until after clean up.

I think the correct question is how did two professionally trained crews fly it into the ground?

While agreeing with you the correct response, and perhaps many crews would find it, I don't find clean up and climb obviously unintuitive.

Perhaps the nuts and bolts of this is why was a reasonably intuitive response so dangerous?
My highlight.
Sim training in some places seems from comments here to be very samey. So the expectations of the people writing the NNC and the trained reactions of the crews have diverged significantly.

The designers obviously felt that the worse thing to happen would be a crew switching stab trim off in the highly unlikely event that the AoA failed (they probably checked failure rates in NGs). Seems that for some crews switching stab trim off is very unlikely even when the trim is motoring way down and making things uncomfortably heavy and for some reason the AoA vanes have a lot higher failure rate in the Max.
Ian W is offline  
Old 28th Mar 2019, 23:30
  #2694 (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
It would be interesting to know if when the vanes are stripped by the manufacturer, any fault whatsoever is found.
Loose rivets is offline  
Old 29th Mar 2019, 02:43
  #2695 (permalink)  
 
Join Date: Nov 2018
Location: Jakarta
Posts: 20
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by FCeng84
AOA vane position is not valid until up to an airspeed well above that for taxi. Revised MCAS logic keeps MCAS from acting at all if an AOAs signals differ by anywhere near as much as appears to have been the case with the Lion Air accident data. I don't think the MCAS changes do anything for stick shaker so the shaker on the side with AOA failed high would activate as it did on Lion Air, but no MCAS.
Yes, I think the software fix will be mcas disabled due aoa disagree or limiting it power. Hopefully the aircraft still in stable envelope. The training with mcas should be mandatory. Since there no mention of mcas notification.

The ground aoa sensor system troubleshooting need to be fixed also, since it somehow seems more fragile than NG series, and lion air ground crew can't fix it.

Last edited by Realbabilu; 29th Mar 2019 at 02:55.
Realbabilu is offline  
Old 29th Mar 2019, 04:37
  #2696 (permalink)  
 
Join Date: Nov 2018
Location: Vancouver
Posts: 68
Likes: 0
Received 0 Likes on 0 Posts
Possibly a reposting of what had happened minute by minute on that Lion Air PK-LQP Flight JT610, as found on pp.1-3 of The Lion Air PK-LQP Preliminary Crash Investigation Report:
1 FACTUAL INFORMATION
1.1 History History of the Flight of the Flight
On 29 October 2018, a Boeing 737-8 (MAX) aircraft registered PK-LQP was being operated by PT. Lion Mentari Airlines (Lion Air) as a scheduled passenger flight from Soekarno-Hatta International Airport (WIII), Jakarta1 with intended destination of Depati Amir Airport (WIPK), Pangkal Pinang2. The scheduled time of departure from Jakarta was 0545 LT (2245 UTC3 on 28 October 2018) as LNI610.

At 2320 UTC, the aircraft departed from Jakarta using runway 25L and intended cruising altitude was 27,000 feet. The LNI610 pilot was instructed to follow the Standard Instrument Departure (SID) of ABASA 1C4.
According to the weight and balance sheet, on board the aircraft were two pilots, five flight attendants and 181 passengers consisted of 178 adult, one child and two infants. The voyage report5 showed that the number of flight attendant on board was six flight attendants.
The Digital Flight Data Recorder (DFDR) recorded a difference between left and right Angle of Attack (AoA) of about 20° and continued until the end of recording. During rotation the left control column stick shaker activated and continued for most of the flight.

Shortly after departure, the Jakarta Tower controller instructed LNI610 to contact Terminal East (TE) controller. At 23:21:22 UTC, the LNI60 SIC made initial contact with the TE controller who responded that the aircraft was identified on the controller Aircraft Situational Display/ASD (radar display). Thereafter, the TE controller instructed the LNI610 to climb to altitude 27,000 feet.

At 23:21:28 UTC, the LNI610 SIC asked the TE controller to confirm the altitude of the aircraft as shown on the TE controller radar display. The TE controller responded that the aircraft altitude was 900 feet and was acknowledged by the LNI610 Second in Command (SIC).

At 23:21:53 UTC, the LNI610 SIC requested approval to the TE controller “to some holding point”. The TE controller asked the LNI610 the problem of the aircraft and the pilot responded “flight control problem”.
The LNI610 descended from altitude 1,700 to 1,600 feet and the TE controller then asked the LNI610 of the intended altitude. The LNI610 SIC advised the TE controller that the intended altitude was 5,000 feet.

At 23:22:05 UTC, the DFDR recorded the aircraft altitude was approximately 2,150 feet and the flaps were retracted. After the flaps reached 0, the DFDR recorded automatic aircraft nose down (AND) trim active for 10 seconds followed by flight crew commanded aircraft nose up (ANU) trim.

At 23:22:31 UTC, the TE controller instructed the LNI610 to climb and maintain altitude of 5,000 feet and to turn left heading 050°. The instruction was acknowledged by the LNI610 SIC.

At 23:22:48 UTC, the flaps extended to 5 and the automatic AND trim stopped.

At 23:22:56 UTC, the LNI610 SIC asked the TE controller the speed as indicated on the radar display. The TE controller responded to the LNI610 that the ground speed of the aircraft shown on the radar display was 322 knots.

At 23:24:51 UTC, the TE controller added “FLIGHT CONT TROB” text for LNI610 target label on the controller radar system as reminder that the flight was experiencing flight control problem.

At 23:25:05 UTC, the TE controller instructed the LNI610 to turn left heading 350° and maintain altitude of 5,000 feet. The instruction was acknowledged by the LNI610 SIC.

At 23:25:18 UTC, the flaps retracted to 0. At 23:25:27 UTC, the automatic AND trim and flight crew commanded ANU trim recorded began again and continued for the remainder of the flight.

At 23:26:32 UTC, the TE controller instructed the LNI610 to turn right heading 050° and maintain altitude of 5,000 feet. The instruction was acknowledged by the LNI610 SIC.

At 23:26:59 UTC, the TE controller instructed the LNI610 to turn right heading 070° to avoid traffic. The LNI610 pilot did not respond to the TE controller‟s instruction, thereafter, the controller called the LNI610 twice who responded at 23:27:13 UTC.

At 23:27:15 UTC, the TE controller instructed the LNI610 to turn right heading 090° which was acknowledged by the LNI610 SIC. A few second later, the TE controller revised the instruction to stop the turn and fly heading 070° which was acknowledged by the LNI610 SIC.

At 23:28:15 UTC, the TE controller provided traffic information to the LNI610 who responded “ZERO”. About 14 seconds later, the TE controller instructed the LNI610 to turn left heading 050° and maintain an altitude of 5,000 feet. The instruction was acknowledged by the LNI610 SIC.

At 23:29:37 UTC, the TE controller questioned the LNI610 whether the aircraft was descending as the TE controller noticed that the aircraft was descending. The LNI610 SIC advised the TE controller that they had a flight control problem and were flying the aircraft manually.

At 23:29:45 UTC, the TE controller instructed the LNI610 to maintain heading 050° and contact the Arrival (ARR) controller. The instruction was acknowledged by the LNI610 SIC.

At 23:30:03 UTC, the LNI610 contacted the ARR controller and advised that they were experiencing a flight control problem. The ARR controller advised LNI610 to prepare for landing on runway 25L and instructed them to fly heading 070°. The instruction was read back by the LNI610 SIC.

At 23:30:58 UTC, the LNI610 SIC stated “LNI650 due to weather request proceed to ESALA8” which was approved by the ARR controller.

At 23:31:09 UTC, the LNI610 PIC advised the ARR controller that the altitude of the aircraft could not be determined due to all aircraft instruments indicating different altitudes. The pilot used the call sign of LNI650 during the communication. The ARR controller acknowledged then stated “LNI610 no restriction”.

At 23:31:23 UTC, the LNI610 PIC requested the ARR controller to block altitude 3,000 feet above and below for traffic avoidance. The ARR controller asked what altitude the pilot wanted.

At 23:31:35 UTC, the LNI610 PIC responded “five thou”. The ARR controller approved the pilot request.

At 23:31:54 UTC, the FDR stopped recording.

The ARR controller attempted to contact LNI610 twice with no response. At 23:32:19 UTC, the LNI610 target disappeared from the ASD and changed to flight plan track. The ARR controller and TE controller attempted to contact LNI610 four more times with no response.
The ARR controller then checked the last known coordinates of LNI610 and instructed the assistant to report the occurrence to the operations manager.
The ARR controller requested several aircraft to hold over the last known position of LNI610 and to conduct a visual search of the area.
About 0005 UTC (0705 LT), tug boat personnel found floating debris at 5°48'56.04"S; 107° 7'23.04"E which was about 33 Nm from Jakarta on bearing 56°. The debris was later identified as LNI610.
It appeared At 23:31:09, they started losing their battle to control the aircraft as they could not overcome the MCAS nose down trim. And at 23:31:23, they were still trying their best effort to battle the MCAS, even though it appeared the battle had been already lost some 10-20 seconds ago.


From pp. 14-15 of the Lion Air PK-LQP Preliminary Crash Investigation Report:


..



..


The leaked CVR recording [albeit only partially confirmed by the official] seemed to indicate the two pilots had been very calm and composed even just seconds before the impending crash.
patplan is offline  
Old 29th Mar 2019, 05:38
  #2697 (permalink)  
 
Join Date: May 2000
Location: London, UK
Posts: 387
Received 7 Likes on 4 Posts
WSJ reporting that the SWA contract for the Max had a penalty of USD 1 million per aircraft if ‘additional training’ (undefined) was required to fly it, and that they bought 280 aircraft.
SLF3 is offline  
Old 29th Mar 2019, 06:04
  #2698 (permalink)  
 
Join Date: Aug 2005
Location: EDLB
Posts: 362
Received 4 Likes on 3 Posts
It has probably no bearing here but ATC should question itself if it is a good idea, to vector a plane around in 30 second intervals if it already stated flight control problems. You would think that they immediate trade that as emergency even when not declared. That vectoring distracts the already over 100% mentally loaded crew.

If that WSJ report is correct you might wonder if SWA might get sued by some victims too. By contract forcing an aircraft manufacturer to cut corners on certification sounds strange.
EDLB is offline  
Old 29th Mar 2019, 06:15
  #2699 (permalink)  
 
Join Date: Aug 2005
Location: EDLB
Posts: 362
Received 4 Likes on 3 Posts
I think that Unhook is right in a way, that Boeing installed a “poor mans” version of alpha floor protection in the 737 MAX. However without the redundancy and thorough safety analysis required for flight control surface operations.
EDLB is offline  
Old 29th Mar 2019, 06:31
  #2700 (permalink)  
 
Join Date: Sep 2010
Location: by the seaside
Age: 74
Posts: 558
Received 17 Likes on 13 Posts
Reuter’s article that EASA recognised the problem in 2016 but it wasn’t included in flight manuals.
https://uk.reuters.com/article/us-et...-idUKKCN1RA0DP
blind pew 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.