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 8th Apr 2019, 12:08
  #3601 (permalink)  
 
Join Date: Oct 2004
Location: australia
Posts: 218
Received 1 Like on 1 Post
Originally Posted by alf5071h
DaveReidUK, #3647, Icarus2001, quentinc
“… no evidence that it's the case for electric trim.”

Indications in the EASA reference ‘Equivalent Safety Case’ suggest otherwise.
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.”


Now why would a manufacturer limit the thumb switch trim range to even less than the autopilot trim authority, particularly when it could no longer be shown to trim throughtout the required envelope?
How about non compliance with the out of trim dive requirement as mentioned in said equivalent safety determination?
Perhaps the easiest solution was to use the 30lbf out of trim with the wheel rather than redesign the system to be compliant when 3 seconds of no load electric trim operation is applied?
zzuf is offline  
Old 8th Apr 2019, 12:10
  #3602 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 15,891
Received 248 Likes on 118 Posts
Originally Posted by MemberBerry
The opposite direction, ANU, would be unaffected and should work just fine, even when you are trimmed AND outside the designed range for manual electric trim.
Yes, that was my point, supported by the FDR trace.
DaveReidUK is offline  
Old 8th Apr 2019, 12:37
  #3603 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,257
Likes: 0
Received 1 Like on 1 Post
Thanks MemberBerry, #3655

Your helpful description, interpretation of the EASA text, infers that the trim demand will be as required for the flight condition. Even in extreme ‘normal flight’, in-trim conditions, the trim system should not hold any significant load other than that required for a balanced aircraft, which will fly ‘hands off’.

The situation with MCAS malfunction is that the flight condition is not balanced - ‘abnormal flight’; the trim system is creating the flight path deviation which the crew are attempting to correct. A correcting force has to be applied via the trim motor and elevator; these forces are probably much higher than that for the near trim condition.
Thus are the differences in the required force and direction of motion, at or beyond the capability of the trim elect motor ?

The apparent anomaly towards the end of the FDR could be interpreted as a nose up elect trim demand, but no trim movement, yet shortly after MCAS trim demands nose down and the tail moves. This of course is not evidence of a nose up elect trim limit (stall), but remains a possibility.

Is this above a valid position, is it one which the EASA (FAA, Boeing) text might not have considered ?
alf5071h is offline  
Old 8th Apr 2019, 12:43
  #3604 (permalink)  
 
Join Date: Jul 2002
Location: Ireland
Posts: 596
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by DaveReidUK
That appears to be true for manual (wheel) trim, but there's no evidence that it's the case for electric trim.
Does anyone know whether the friction on the threads of the jackscrew caused by high aerodynamic loading above Vmo is the same whether the motor is trying to trim NU or ND?
Speed of Sound is offline  
Old 8th Apr 2019, 12:44
  #3605 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 15,891
Received 248 Likes on 118 Posts
Originally Posted by alf5071h
Thus are the differences in the required force and direction of motion, at or beyond the capability of the trim elect motor ?
Peter Lemme, in the link you quoted in your previous post, states:

electric trim motor is designed to not stall out under severe out-of-trim conditions

DaveReidUK is offline  
Old 8th Apr 2019, 12:49
  #3606 (permalink)  
 
Join Date: Jun 2009
Location: Toronto
Age: 79
Posts: 118
Likes: 0
Received 0 Likes on 0 Posts
perhaps if the software and sensor device drivers were written in assembler by programmers who understood the hardware inter-relationships,these accidents could have been avoided.
I suppose machine language and assembler are foreign languages these days with few practitioners but the MBA's want things done cheap and dirty especially if they can outsource if offshore.
kilomikedelta is offline  
Old 8th Apr 2019, 12:56
  #3607 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,257
Likes: 0
Received 1 Like on 1 Post
Dave, depends on what the design (1970s ?) assumed to be ‘severe out of trim conditions’.
The aircraft trimmed state - the pilots flew the aircraft there (as zzuf #3658 dive) or misplaced tail due to an abnormality - elect trim runaway (where restricting the use of pilot elect trim could be required for safety).

In my previous posts ‘force’ is probably misused; the discussion relates more to torque and hinge moment. Thus the relative location of the point of tail hinge to air load is important.


Last edited by alf5071h; 8th Apr 2019 at 13:13. Reason: typo
alf5071h is offline  
Old 8th Apr 2019, 12:58
  #3608 (permalink)  
 
Join Date: Feb 2013
Location: Buckinghamshire
Posts: 34
Likes: 0
Received 0 Likes on 0 Posts
electric trim motor is designed to not stall out under severe out-of-trim conditions
I would imagine the forces at the stabilizer, played some part in the setting of VMO, which had now been exceeded.
quentinc is offline  
Old 8th Apr 2019, 12:59
  #3609 (permalink)  
 
Join Date: Jul 2013
Location: Norway
Age: 57
Posts: 140
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Speed of Sound


Does anyone know whether the friction on the threads of the jackscrew caused by high aerodynamic loading above Vmo is the same whether the motor is trying to trim NU or ND?

The friction per definition should be the same. However the force required will not be the same.
Think of this as pushing a car uphill against a slight inclination versus pushing it downhill the same inclination. The friction from the wheels running on the ground is the same in both cases, but in the first example you have the added force from the uphill inclination to overcome versus in the downhill example the force from the downhill inclination helps you pushing the car.
SteinarN is offline  
Old 8th Apr 2019, 13:22
  #3610 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 15,891
Received 248 Likes on 118 Posts
Originally Posted by quentinc
I would imagine the forces at the stabilizer, played some part in the setting of VMO, which had now been exceeded.
The aircraft was more-or-less level and only just above Vmo at the point where those two brief applications of trim occurred.

The widely quoted 500 kts was subsequent to that, the result of the last episode of MCAS AND trim kicking in and the unrecoverable descent.
DaveReidUK is offline  
Old 8th Apr 2019, 13:22
  #3611 (permalink)  
 
Join Date: Jul 2005
Location: btw SAMAR and TOSPA
Posts: 566
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by kilomikedelta
perhaps if the software and sensor device drivers were written in assembler by programmers who understood the hardware inter-relationships,these accidents could have been avoided.
I suppose machine language and assembler are foreign languages these days with few practitioners but the MBA's want things done cheap and dirty especially if they can outsource if offshore.
This is a serious system design matter. MCAS does its job as planned. It is just the wrong job. There is no need for assembler to speed anything up. It makes code harder readable, less maintainable and certifyable ... oops.
threemiles is offline  
Old 8th Apr 2019, 13:25
  #3612 (permalink)  
 
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Capn Bloggs
Consider AF447. The design team thought that an aeroplane could not be flying below 60KIAS, so they inhibited the stall warning... We know how that ended.
In hindsight that is probably a shortcoming of the risk and hazard assessment of the ADIRUs of the A330, yes. But the rationale for regarding all air data invalid at indicated air speed below 60 knots is that it was simply not known how the aircraft would behave in that regime. And it is sometimes a better idea (although that, too, requires careful evaluation and assessment) to flag all data as invalid (or not deliver it at all) rather than deliver data wich may be wrong.

As far as I recall the A3330 was not flight tested into a full stall, and very few other ways of flying that slow can be envisioned.

On the other hand it is not clear that the "reverse logic" (pitch down in a deep stall: stall warning comes on, raise the nose again: stall warning stops) of the stall warning at very high angles of attack and very low indicated air speeds was a causal factor in the accident: There are some indications that the crew did not only not react to the stall warning, but that they literally did not perceive it. It was lost to cognitive overload.

It could be possible to have an AOA of 75° and appreciate some assistance from the machine (MCAS) to keep the nose from getting there in the first place. The F up was making it reliant on only one sensor.
While the absolute value may be valid (although 75° is probably a bit of a stretch, even AF447 never even reached 50°. but the 25° or so from Lion Air is clearly in an attainable range), some things can also be deduced about the validity by evaluating rate of change, or cross-checking with other values, such as static and total pressures, vertical speed, pitch angle, acceleration, etc., even without cross-checking with the other-side AoA.


Bernd
bsieker is offline  
Old 8th Apr 2019, 13:34
  #3613 (permalink)  
 
Join Date: Jul 2005
Location: btw SAMAR and TOSPA
Posts: 566
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by DaveReidUK
The aircraft was more-or-less level and only just above Vmo at the point where those two brief applications of trim occurred.

The widely quoted 500 kts was subsequent to that, the result of the last episode of MCAS AND trim kicking in and the unrecoverable descent.
Also, they were in a 30 degrees bank turn when things started to really go wrong. Almost no pitch, 340 kts, no ability to pull or trim ANU, how can that work out? Before the bank had increased slowly over 2 to 3 minutes for whatever reason.
Then they were flying at 10000 feet, inside a MSA sector of 14000 ft, heading towards range with a peak of 11000 MSL, with little to no climb rate. Albeit in VMC, this alone is brutal.

Last edited by threemiles; 8th Apr 2019 at 13:45.
threemiles is offline  
Old 8th Apr 2019, 13:39
  #3614 (permalink)  
 
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by kilomikedelta
perhaps if the software and sensor device drivers were written in assembler [...]
That is possibly the worst suggestion so far.

Assembly code is almost impossible to analyse for correctness in any meaningful way. It is far better (and provably so) to write in a well-specified (i. e. not C) language, prove the source code correct (for which scalable and practical techniques exist today), or define and prove correct a finite state machine and have code generated from it. That still leaves one with a need to have reasonable confidence in the compiler, but in many cases the service history for the most-used language core, and, in some recent cases, formally verified compilers, take care of that.

Just because you have one hero programmer who claims to have done it "Right" in assembly does not help you in any way because you need to demonstrate that it does what it is supposed to do (reliability), and never does what it is not supposed to do (safety), and ideally also never fails (availabilitiy). And this cannot be demonstrated by testing alone to the extremely high requirements needed in aviation. Assembly and machine code are avoided like the plague in safety-critical programming, and rightly so. Where some parts require it, extreme care must be taken to get it right, and the amount must be kept to a minimum.

Besides, as threemiles has pointed out, the implementation is not the problem (as far as we can tell, it may be flawless), but the specification. "Working as specified" can also mean that it did the wrong thing.

Bernd

Last edited by bsieker; 8th Apr 2019 at 13:42. Reason: typo
bsieker is offline  
Old 8th Apr 2019, 13:48
  #3615 (permalink)  
 
Join Date: Feb 2015
Location: New Hampshire
Posts: 152
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by kilomikedelta
perhaps if the software and sensor device drivers were written in assembler by programmers who understood the hardware inter-relationships,these accidents could have been avoided.
I suppose machine language and assembler are foreign languages these days with few practitioners but the MBA's want things done cheap and dirty especially if they can outsource if offshore.
Having programmed in machine language, I would NOT recommend it. It would be very difficult to reach the level of confidence for direct machine code (or even assembly) that would be required for this software.

Just to be clear, we are talking about software that must not allow the MAX to do a mid-flight back flip and/or break up while also not dooming the plane to a high-speed nose dive. And if it fails and is disabled, the pilot may not be able to act fast enough to recover. It's hard to image a software component on an ATP flight that is more critical.

The sequence would be: requirements, requirements review, design, design review against the requirements, test development based on the design, test procedure review, coding, code review, code testing. This requires code that can be examined by several team members with no chance of misinterpretation.

So what is needed it a well exercised development environment - one that's been around for several years and has been very widely used - with a good reputation and version release notes that reflect a solid tool.
.Scott is offline  
Old 8th Apr 2019, 13:55
  #3616 (permalink)  
 
Join Date: Nov 2018
Location: madrid
Posts: 47
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by bsieker
In general, the industry does, and overall does a very good job of it. Input value filtering is normal, and even the A330 that nose-dived in cruise had computers which did. It was done inappropriately, but most of the time the erroneous values were rejected.

The problem here lies much earlier, in specifying the requirements for MCAS. More specifically, the failure modes and the severity and likelihood of each were not properly analysed.



Au contraire. Aviation is the industry which mandates appropriate techniques. They are well-known, and used.

Add-on systems that bring airliners back into compliance, which are not by themselves aerodynamically completely compliant to regulations, are literally as old as jet airliners themselves. Many types have stick-nudgers or stick-pushers, and they work fine, and are perfectly sensible to use. But that does not mean one can skip due diligence in developing them, which includes a thorough risk and hazard assessment.

Bernd
I know some plane computers are properly built and programmed and that part of the industry works ok. That's exactly what I meant with 《we know how to do it》.

What I meant is that there is a 《all or nothing》spirit that doesn't quite cut it. Either is a 8 year development with millions of man hours on it ,or a terrific patch that looks like done overnight. No middle ground.

I'm all in for a cheap patch. The cheapest possible, no need to doom the plane and start over. But if the computers in the plane have no room for improvement, a software patch in 1980s style is not going to be enough. We need sanity checks, cross sensor checks and history checks on ALL sensors. Not only AOA.

Precisely, no software patch will fix the issue of mcas being useless for real life (too slow).
ecto1 is offline  
Old 8th Apr 2019, 13:56
  #3617 (permalink)  
 
Join Date: Apr 2014
Location: YARM
Age: 74
Posts: 136
Received 0 Likes on 0 Posts
Originally Posted by CurtainTwitcher
. . .
They faced a continuous cacophony of noise (stick shaker), that has been shown by anecdotal reports in this thread to induce tunnel vision and difficulty doing ANY task, including just flying the aircraft. Two crew were unable to cope, the third had assistance from an additional pilot.

Perhaps as the lawyers are debating and dissecting second by second details, they should do it with the continuous Stick Shaker loop in the background.
Indeed.

unworry is offline  
Old 8th Apr 2019, 14:01
  #3618 (permalink)  
 
Join Date: Feb 2015
Location: New Hampshire
Posts: 152
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by bsieker
It is far better (and provably so) to write in a well-specified (i. e. not C) language, prove the source code correct (for which scalable and practical techniques exist today), or define and prove correct a finite state machine and have code generated from it.
I doubt that they used C or C++, but given appropriate coding standards, I do not have problems with either. In fact, a major issue with keeping the code in alignment with an understandable design is in what kind of awkward and extraneous semantics the programmers needs to go through to getting the code to do what they want. Languages like C# are advertised as "safer" because they prevent certain types of errors - like memory management. But they add a major layer of code that is unrelated to the final functionality. That makes the really important parts of the code diffused and harder to review.

When I say "appropriate coding standards", the issue is reviewability. So using the C++ support for object oriented coding is good. Using polymorphism or the "virtual" keyword is avoidable - and for an application like this, should be avoided.
.Scott is offline  
Old 8th Apr 2019, 14:11
  #3619 (permalink)  
 
Join Date: Feb 2015
Location: New Hampshire
Posts: 152
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by ecto1
I'm all in for a cheap patch. The cheapest possible, no need to doom the plane and start over. But if the computers in the plane have no room for improvement, a software patch in 1980s style is not going to be enough. We need sanity checks, cross sensor checks and history checks on ALL sensors. Not only AOA.

Precisely, no software patch will fix the issue of mcas being useless for real life (too slow).
Interesting. I guess somewhere in this thread is a revelation that the MCAS hardware was too slow - I hadn't heard that. It it's from the 1980's, where they using Ada? That was one of those "safe" languages - but may come with a lot of overhead. If it had been coded in C, there would have been no practical problem with the machine speed.

If I was the FAA, I would not allow the plane to fly without having simulators available that fully simulate operations where the MCAS can work and fail - and then require that the pilots go through the different failure modes before visiting the MAX cockpit. If the MCAS hardware needs to be replaced, replace it.

I think that if Boeing tackles this problem correctly, they could have the planes flying safely in about four months. Or they can go for Micky Mouse fixes and risk either an ineffective fix or a recovery timeline that goes well beyond four months.
.Scott is offline  
Old 8th Apr 2019, 14:17
  #3620 (permalink)  

Only half a speed-brake
 
Join Date: Apr 2003
Location: Commuting not home
Age: 46
Posts: 4,323
Received 4 Likes on 4 Posts
Originally Posted by bsieker
While the absolute value may be valid (although 75° is probably a bit of a stretch, even AF447 never even reached 50°. but the 25° or so from Lion Air is clearly in an attainable range), some things can also be deduced about the validity by evaluating rate of change, or cross-checking with other values, such as static and total pressures, vertical speed, pitch angle, acceleration, etc., even without cross-checking with the other-side AoA.
MelVic's original remark read to me that accepting 75° raises questions how was the input validation done if at all.
FlightDetent 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.