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 31st Mar 2019, 23:00
  #2841 (permalink)  
 
Join Date: Jul 2007
Location: the City by the Bay
Posts: 530
Is the Boeing 737 MAX Worth Saving?

can Boeing save it?
armchairpilot94116 is offline  
Old 31st Mar 2019, 23:41
  #2842 (permalink)  
fdr
 
Join Date: Jun 2001
Location: 3rd Rock, #29B
Posts: 798
Originally Posted by GordonR_Cape View Post
It is deeply ironic that the issue MCAS was designed to cater for was never flight critical, and might never have occurred during the lifetime of the aircraft. Instead the fix ended up killing hundreds of people.
This highlights the underlying issue that the industry has processes that can bite back. To achieve compliance with a particular rule a simple fix is implemented, and that has a potential for unintended consequences. The failure mode of the compliance fix has it's own unknown interaction with the operating system at the man machine interface; somewhere along the way recognition failed as to the underlying cause, for a crew that had never heard of the "fix" and to another crew that had learnt of the problem due to the revelations of the first crews misfortune. In fact, the knowledge gained in the flight preceding JT610 was lost on the next crew as well, the system doesn't allow for the timely transfer of information, and it probably cannot do so under any process that validates the information and the output to avoid errant information being introduced.

The constant offset once in motion would appear inconsistent with a loss of the sin or cos output alone as far as I understand the use of those functions to derive the A-D output state. Contend as previously commented that the sensor itself is unlikely to be the component that has the fault, which leads to the install, wiring, or processing of the signal as being the point of failure. The loss of a single resolved output is intriguing, giving an erroneous result but it would appear that the offset error would alter with the change of actual AOA. The aircraft was operated from low speed, through to high speed, with substantial change in actual AOA, but the offset appears to be constant.
fdr is offline  
Old 1st Apr 2019, 00:04
  #2843 (permalink)  
 
Join Date: Feb 2011
Location: Leeds
Posts: 0
I think the publicity that the max has generated over the last few weeks especially since the grounding, could kill the airframe off... there may be no way back for it. The public are very powerful and could refuse to fly on it even after Boeing has "updated IOS" or whatever they are doing, I personally wont be going near one with my family even after its "fixed" and i fly for a living, so joe public will be even more cautious.

I honesly think its crazy that we are now in a situation where a plane is crashing and we are saying we need a software update... its gone too far.

People except humans make errors and pilots sometimes screw up, what they wont accept is software in charge of their lives
Livesinafield is offline  
Old 1st Apr 2019, 00:37
  #2844 (permalink)  
 
Join Date: Mar 2019
Location: Bavaria
Posts: 17
Originally Posted by fdr View Post
The constant offset once in motion would appear inconsistent with a loss of the sin or cos output alone as far as I understand the use of those functions to derive the A-D output state. Contend as previously commented that the sensor itself is unlikely to be the component that has the fault, which leads to the install, wiring, or processing of the signal as being the point of failure. The loss of a single resolved output is intriguing, giving an erroneous result but it would appear that the offset error would alter with the change of actual AOA. The aircraft was operated from low speed, through to high speed, with substantial change in actual AOA, but the offset appears to be constant.
There are not many failure modes which may cause such a constant deviation. If normal checks are in place, it rules out everything except wrong calculation within or after atan(sin/cos). Cabling, loss of ground, ADC error... there are checks for such problems and they do not cause a constant offset.
Again, there are 2 possibilities left if I didn't miss something (I'm evaluating such resolvers for 2 safety relevant systems within electric cars at the moment):
-> Electromagnetic interference (EMI) at exactly the frequency the sensor is working on (or the sensor locks on the interference frequency with it's resonator) I tried to find a correlation between engine running/rpm and sensor failure but could not find any. EMI from the new engines would have been a nice one.
-> Error within the calculation after sin/cos and plausibilisation (sin˛+cos˛=1) -> Software change / bug?

The sin and cos voltage is simply the x and y of a 2D unit vector (look for 'unit vector' on english wikipedia, I'm not allowed to post a link) The receiver simply checks if the unit vector has a length of 1. If a cable breaks or the ADC has an error, it won't.
If there is no need to measure 360°, the electrical full circle is often a fraction of the mechanical one. So the electrical vector would make 2/3/4 turns on one mechanical revolution of the fin. Therefore 22.5° deviation could come from 90° signal error or calculation error. Those 22° somehow smell like some 90° computational error (e.g. wrong sign). Especially since atan calculations in old software only have a table for one quadrant of the unit vector and then switch signs or add/subtract 90°/180°/270°.
Switching cables (sin/cos) would btw. invert the angle (90°-x).

Still: If this sensor design is so bad, why is it still the same for the last decades? What changed on the MAX which tampered the probability of this error that much?

Without an answer to this question I would not trust the AoA signals (and many other) at all! (...and I'm a functional safety consultant)

This SW fix tries to fix the impact of the failure, the root cause seems to be still unknown. But without knowing the cause, other side effects cannot be identified.
TryingToLearn is offline  
Old 1st Apr 2019, 01:11
  #2845 (permalink)  
 
Join Date: Mar 2005
Location: N/A
Posts: 3,544
I honesly think its crazy that we are now in a situation where a plane is crashing and we are saying we need a software update... its gone too far
This is not a first, software code has been responsible for prior accidents, Iberia A320 being one.
The design of the flight control system was such that the actions of both pilots over the flight controls were ignored by the logic of the control system and prevented the aircraft from flaring.

The cause of the accident was the activation of the angle of attack protection system which, under a particular combination of vertical gusts and windshear and the simultaneous actions of both crew members on the sidesticks, not considered in the design, prevented the aeroplane from pitching up and flaring during the landing.
Fixed by a code modification.

http://www.fomento.es/NR/rdonlyres/8...006_A_ENG1.pdf
megan is online now  
Old 1st Apr 2019, 01:59
  #2846 (permalink)  
 
Join Date: Mar 2015
Location: North by Northwest
Posts: 478
Originally Posted by megan View Post
This is not a first, software code has been responsible for prior accidents, Iberia A320 being one.
Fixed by a code modification.
Many years ago while working on a fire-control system, we were evaluating test methodologies between the F-16's Westinghouse, General Dynamics Phalanx fire-control, and Airbus fly-by-wire. The Airbus strategy (as I recall which was about 4 decades back) was to deliver the code to 3 companies in three different countries, none of whom knew of the others existence. AB expected each would find some unique code exceptions by doing so. Not so. Well over 90% were identifed by multiple vendors including all deemed critical bugs save maybe one. The rest were not considered major flight control errors.

Maybe Gums could chime in here, but we had heard rumors (maybe urban legend) that some of the early F-16 deployments in Germany with look-down did on occasion lock on to low flying Mercedes on the Autobahn. As a designer, how many would consider that possibility?

There will never be a perfect balance between automation and human interaction. Automation is programmed by humans - mistakes will happen on both ends.

Last edited by b1lanc; 1st Apr 2019 at 12:26.
b1lanc is offline  
Old 1st Apr 2019, 02:48
  #2847 (permalink)  
 
Join Date: Jul 2014
Location: Harbour Master Place
Posts: 661
I'm not a software person, however, I have been interested in the automation + human factors since a Computer Science friend put me on a lead in the early 1990's with the Therac-25 accidents, this lead to reading more by Nancy Leveson: High-Pressure Steam Engines and Computer Software. This is a great introduction to the larger picture of the interaction between sophisticated hardware racing well beyond the much slower and risky software engineering in historical context with the engineering of steam engine vs dangerous and lagging boiler tech. Public pressure forced the formation of safety laws to protect the end users from dangerously engineered devices. Although written in 1992, I believe it still has many insights that make it relevant. She also has written much on safe software development techniques.

Her homepage: Nancy Leveson Professor of Aeronautics and Astronautics
CurtainTwitcher is offline  
Old 1st Apr 2019, 06:32
  #2848 (permalink)  
 
Join Date: Jul 2007
Location: the City by the Bay
Posts: 530
Originally Posted by Livesinafield View Post
I think the publicity that the max has generated over the last few weeks especially since the grounding, could kill the airframe off... there may be no way back for it. The public are very powerful and could refuse to fly on it even after Boeing has "updated IOS" or whatever they are doing, I personally wont be going near one with my family even after its "fixed" and i fly for a living, so joe public will be even more cautious.

I honesly think its crazy that we are now in a situation where a plane is crashing and we are saying we need a software update... its gone too far.

People except humans make errors and pilots sometimes screw up, what they wont accept is software in charge of their lives
The Max is all in for Boeing. Fastest selling Boeing jet, yada yada. Boeing is going to do whatever it takes to get that bird back in the air. Too much at stake. The only way for the airframe to end production is if the majority of the orders evaporate overnight. This probably won't happen. So if all goes well and the software patch works and airlines don't cancel orders and the general public goes back to flying it . All will be well. But Boeing will be wise to learn that it is time to get cracking at an all new 737 based loosely on the 757 perhaps. Or better, basically copy the A320. And to amortize the costs of the Max quickly so the line can end soon as the new one is ready. When will it be? Ten years? Now if the Max has another accident within the next few years, no matter the cause, that may be it. Boeing can't afford another Max going down.
armchairpilot94116 is offline  
Old 1st Apr 2019, 07:33
  #2849 (permalink)  
 
Join Date: Feb 2015
Location: The woods
Posts: 1
Originally Posted by GlobalNav View Post


The AoA display should be designed to support the pilot’s proper and effective use of it (whatever that is). It should be considered, not in isolation, but in the context of the rest of the flight display(s) and the instrument scan which the pilots are expected to conduct. Does any airline which has aircraft equipped with the AoA display have approved pilot procedures for its use? If a check ride was conducted, in which phases of flight would a pilot be faulted for failure to maintain awareness of the AoA display? If one were to evaluate the AoA display design, what measure of performance would be used? Considering the approved Boeing EFIS with the AoA in the upper right corner, how does that fit Basic T flight display philosophy? Of course it doesn’t, because AoA was never part of the Basic T. But if there was a logical, task performance-based purpose for the AoA display, why would it be placed above the altitude display, about as far from the airspeed and attitude indications as it could be? Yet, we suppose it enhances safety?
Hi Nav,
The purpose of the AoA indicator on the Max is not to read as an additional flight instrument.
It is a position indicator.
Therefore there is no requirement for it to be included in the scan etc.
If you get a disagree warning you can tell quickly which signal is the troublemaker.
To me it makes sense and yes, it is a safety feature.
If, together with the mod on MCAS travel and necessary information to converting crews, it had been incorporated from the beginning, then it would have given a valuable clue and could have prevented these tragic events.
I am still not a fan of the MCAS as a solution to the control force requirement. That doesn’t make me criticise every move Boeing makes, however, when they try to learn from their mistake.
bill fly is offline  
Old 1st Apr 2019, 08:01
  #2850 (permalink)  
 
Join Date: Aug 2000
Posts: 1,412
This could very well be related to something else than just the AOA sensors.
What is different in the MAX AOA system compared to the NG? The sensors are the same.
I have never seen an AOA disagree caution on the NG, so why is does it fail on the MAX?
The sensor may have been installed wrongly on the Lion Air MAX, but that was not the case on the Etiopian MAX.
ManaAdaSystem is offline  
Old 1st Apr 2019, 08:27
  #2851 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 12,315
Originally Posted by ManaAdaSystem View Post
I have never seen an AOA disagree caution on the NG, so why is does it fail on the MAX?
Isn't the AoA Disagree annunciation an option on the NG, as it is/was on the Max? Are you sure it was fitted in your case?

DaveReidUK is offline  
Old 1st Apr 2019, 08:30
  #2852 (permalink)  
 
Join Date: Aug 2000
Posts: 1,412
Originally Posted by DaveReidUK View Post
Isn't the AoA Disagree annunciation an option on the NG, as it is/was on the Max? Are you sure it was fitted in your case?
Not sure if it’s an option or not, but we do have this annunciation on our NGs.
ManaAdaSystem is offline  
Old 1st Apr 2019, 08:52
  #2853 (permalink)  
 
Join Date: Dec 2002
Location: UK
Posts: 2,075
Curtain Twitcher #2872

Thanks for the links; I have read some of the rationale for STAMP, but have difficulty in following the arguments.
Many similar safety initiatives tend to fall foul of hindsight; this is a limitation of this type of thinking - ‘what we could have done for this accident’. Alternatively with beneficial application in foresight, the successful intervention and system design might never be established, because we have not had an accident.
Retrospective safety - focus on accidents for learning, is increasingly limiting in design and operation, thus a forward looking ‘processes’ should improve safety, even if we never know that it has - we never see the accident avoided.

The limit in this approach remains with the human; however good the design and evaluation is, the question ‘have you considered this’ (an aspect of concern*), a human answer ‘yes’ has the rule. Whereas perhaps we need ‘Yyeeees, Probably’, and return to the evaluation - double loop learning, return to the assumptions.

The findings from this accident might identify the problems above (hindsight again), yet we must consider the influences in the existing safety process. Some of the designers and regulators might not have even been born at the time of the initial design and certification. Thus, what has been forgotten, assumption based complacency - does a good accident record bias judgement of the safety of future aircraft variants, whereas treating these as ‘new’ aircraft might question pertinent factors - grandfathers die, let them rest peacefully.

* a machine process designed by humans, subject to our limitations.
safetypee is offline  
Old 1st Apr 2019, 09:28
  #2854 (permalink)  
 
Join Date: May 2016
Location: annecy
Posts: 21
oOftware design

Originally Posted by b1lanc View Post
Many years ago while working on a fire-control system, we were evaluating test methodologies between the F-16's Westinghouse, General Dynamics Phalanx fire-control, and Airbus fly-by-wire. The Airbus strategy (as I recall which was about 4 decades back) was to deliver the code to 3 companies in three different countries, none of whom knew of the others existence. AB expected each would find some unique code exceptions by doing so. Not so. Well over 90% were identifed by multiple vendors including all deemed critical bugs save maybe one. The rest were not considered major flight control errors.

Maybe Gums could chime in here, but we had heard rumors (maybe urban legend) that some of the early F-16 deployments in Germany with look-down did on occasion lock on to low flying Mercedes on the Autobahn. As a designer, how many would consider that possibility?

There will ever be a perfect balance between automation and human interaction. Automation is programmed by humans - mistakes will happen on both ends.
As an ex analyst and software developer this situation frightens me.
Even assuming that the designer can clearly articulate and document what he wants the software to do in my experience, very rare), the coder then needs to understand what the designer wants. The coder then has his job spoiled by software tools claiming to produce rigourous code.He then needs to agree a test suite with the designer assuming it was not part of the specification.
The chances of this chain working are nil in practice. Even for simple things like software drivers for printers there are bugs.
The other core problem is that unless the broad design architecture is right from the beginning there is a limit to retrofitting new features before it becomes impossible to understand the interactions.
As a simple daily example, all cars have been fitted with the an OBD (on board diagnostics) system for decades and this allows diagnostics of all bits of the car including things like the heater as well as lights and brakes and all parts of the engine. This has been around for fifty years and I have three different diagnostic tools for three different cars. Each has bugs since the car systems have bugs and by all accounts ALL cars have bugs and this system is not only simple but its base architectural design is clean and the result of all manufacturers working together to set a standard architecture.It needs to be accepted that ALL planes have software bugs and the solution is simple - a LARGE red button that switches off ALL aids instantly and puts the control in the hands of the pilot instantly.
Might need some new training though
sceh is offline  
Old 1st Apr 2019, 09:39
  #2855 (permalink)  
 
Join Date: Nov 1998
Location: netherlands
Posts: 294
Originally Posted by b1lanc View Post
.............

Maybe Gums could chime in here, but we had heard rumors (maybe urban legend) that some of the early F-16 deployments in Germany with look-down did on occasion lock on to low flying Mercedes on the Autobahn. As a designer, how many would consider that possibility?..........

.
No rumor. In the early f16 years, 81/82, it was easy to lock on to a speeding car in germany. And it was quite fun to fly to it, to make out the model. Later software changes changed the minimum speed for lock-ons and it was no longer possible.
sleeper is offline  
Old 1st Apr 2019, 10:18
  #2856 (permalink)  
 
Join Date: Jan 2008
Location: uk
Posts: 847
Originally Posted by safetypee View Post
I may be dancing around the same tree as in my post in the other thread - #485 Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Where is the value of AoA sampled by the FDR; would this clarify current understanding.
737 NG AMM says that the FDAU (flight data acquisition) gets AOA from the SMYD (stall management and yaw damper) and that analogue resolver outputs go to both SMYD and ADIRU (the latter feeds FCC).

Peter Leeme has previously suggested that MAX no longer has separate SMYD "box" - however he retracted that a couple of days ago in this post:
In prior posts I have postulated whether SMYD had become a function in the FCC on the MAX. I was wrong. The SMYD appears on the 737 MAX pretty much as the 737 NG. This is a significant realization. The AoA vane has one analog resolver output connected to the ADIRU, and one output connected to SMYD.
I would suggest that the most likely source for FDR AOA value is the SMYD, as on the NG.
infrequentflyer789 is offline  
Old 1st Apr 2019, 11:36
  #2857 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 59
Posts: 424
Originally Posted by infrequentflyer789 View Post
Peter Lemme has previously suggested that MAX no longer has separate SMYD "box" - however he retracted that a couple of days ago in https://www.satcom.guru/2019/03/aoa-...oeing-fix.html
The human factors comments in that article are just as interesting as the AOA analysis. Apologies if already quoted:
The response to a stabilizer runaway is to cutout the electric trim. Nowhere does anyone caution the consequences of using manual (turn the wheel manually) trim. The manual trim wheel can be very hard to turn if subject to high aero loads, and particularly if the elevator is commanded significantly (loading the stabilizer).
The standard response to just hit the stabilizer cutout switches and manually trim is actually flawed. If the nose has been pushed down by significant mistrim (nose down stabilizer, nose up elevator), and as airspeed increases, it may not be possible to trim the stabilizer manually nose up without letting the elevator go to a neutral position. The reality, under the MCAS runaway scenario, trimming nose up immediately stops MCAS as well as trims the stabilizer back towards an in-trim position. At that point, you would be best off to cutout the stabilizer.
GordonR_Cape is offline  
Old 1st Apr 2019, 12:57
  #2858 (permalink)  
 
Join Date: Sep 2011
Location: Belgium
Age: 61
Posts: 139
What I don't understand (well I do because building airplanes is all about keeping the costs down) is why they keep using these "obsolete" and fragile vane sensors.

Back in 1979 when we first got the F-16's we where all too happy to see "new" differential pressure activated AOA sensors. => But => But => And that is where it all goes dark => They are more expensive.
Vilters is offline  
Old 1st Apr 2019, 13:07
  #2859 (permalink)  
 
Join Date: Nov 2018
Location: Vancouver
Posts: 67
First the news said this:

Ethiopian Air Report on Boeing Plane Crash to Be Released Monday


And slightly later, the news said this:

No Ethiopia plane crash report on Monday, maybe this week: source


..

So, the WSJ report earlier during the day appeared to be correctly describing what had happened behind the scene...

U.S., Ethiopian Investigators Tussle Over 737 MAX Crash Probe



Patience is a virtue, or so they say...
patplan is offline  
Old 1st Apr 2019, 13:13
  #2860 (permalink)  
 
Join Date: Feb 2015
Location: The woods
Posts: 1
Originally Posted by weemonkey View Post
interesting pov.


The adjacent is your datum, angle A is your actual aoa value and the opposite is the actual strip length which varies with angle a. Clear and coherent information with no need to analyse what a gauge reads...
Thanks Wee
I’ve flown with all types of instruments from dials to strip indicators. I find the strip ideal for cross cockpit engine value info during high thrust phases for instance, compared to dials - but can’t share your view that strip length is clearer than a pictorial representation for an AoA vane - or rather for the information it delivers.
Angle nose up / down is more easily seen on a dial display than a strip - which actually does in this situation require analysis - or at least interpretation.
bill fly 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.