Ethiopian ET302 Crash.

Status
Not open for further replies.
Originally Posted by oil_film_movies
Originally Posted by ZeeOSix
.. why in the world would airline pilots not use AOA information?
Originally Posted by ZeeOSix
Like I said ... and the Boeing article mentions: "AOA is one of the most important parameters for understanding airplane performance and handling."
You asked why don't pilots use AoA. ...Again, it's not important for airline pilots to monitor AoA values below stall AoA when manually flying. They respect Stall AoA, not the AoA state variable, by flying fast enough, as was said above. Airmanship skills are tracking the right airspeed within reasonable pitch angles to avoid stall as Rule Number One. Pilots of course do that while controlling vertical speed (ascent/descent) or positioning an aircraft's velocity vector as needed. .... Basically, if you're going fast enough, you won't stall and you don't think about AoA much.


If flying manually, knowing what your AoA is at any given time (along with airspeed) is certainly valuable information in order to not get yourself close to the stall AoA/airspeed condition defined by the aircraft's performance envelope. Pilots shouldn't be flying and waiting for a stall warning to start thinking about AoA/airspeed conditions. That's my whole point, and that's why knowing AoA at any given time is valuable information when flying manually.
 
Originally Posted by ZeeOSix
... knowing AoA at any given time is valuable information when flying manually.
Workload is too high if you try to track AoA all the time. ..
You could track AoA in an airliner I guess, although it's not as easy to do compared to tracking airspeed targets, I would say. ... Using airspeed is also traditional since pitot-static tubes have been around far longer than AoA vanes. ... It makes more sense to focus attention on airspeed as a Human Factors priority. When a pilot is changing pitch a lot, then he can momentarily divert some attention to Stall AoA limits. Usually flight in an airliner involves small changes in pitch (and roll) and airspeed is King.

That said, PLI & other stall margin visual indications using AoA vanes to see how close to stall the aircraft is, are good to fly with as cross-checks to confirm the airspeed target is sound.
Airline pilots who have PLI on their PFD say they use it to make sure the approach airspeed targets are taking their actual weight into account well, a safety cross-check.
 
Stupid question: Is there a good reason why the MCAS does not have it's own programmed limit where it realizes that it's next move will toss the aircraft into the ground?

Is it not aware of altitude?
 
Originally Posted by oil_film_movies
Airbus aircraft since 1988 have kept the pilots from stalling by pitching down automatically



Umm, no.
Since the advent of the A320, Airbus aircraft in Normal Law simply don't allow a stalling AOA to be reached however hard the PF pulls back on his sidestick. There is no pitching down but rather a limit to pitching up.
AF 447 happened because the crew were relying upon what were erroneous airspeed indications and thought that they were entering a potentially lethal transonic regime. Thinking that they were operating in Normal Law while they were really in Alternate Law with no alpha protection, they applied full back stick and maintained that long enough that the airplane ended up in the Atlantic Ocean in the ITCZ, an area of notoriously bad weather which probably contributed to the icing of the known to have problems Thales probes leading to incorrect airspeed indications.
I kind of thought that the envelope protection dumping things right in the laps of the crew only after things got really bad was a contributing cause of the accident.
If real pilots can fly pitch and power, the software should be able to as well.
 
Originally Posted by DoubleWasp
Stupid question: Is there a good reason why the MCAS does not have it's own programmed limit where it realizes that it's next move will toss the aircraft into the ground? Is it not aware of altitude?
That is a smart question, a solid concept. .... Yes, it could be the software can apply the simple logic: "if pitch angle is less than 5 degrees, then stop MCAS down autotrim." Simple as that. (I picked 5 degrees, might be right. Some small amount of pitch anyway.) After all, we're just trying to arrest pitch-up stall due to the engine nacelles. Note "pitch angle" is triplex redundant on this airplane too, highly reliable, and just used here to disable or enable MCAS anyway, so safe to do that.
Your question specifically involved a radar altitude cross-check, and I wouldn't use altitude since stall at low altitude is a big problem MCAS is there to counter.

Originally Posted by fdcg27
Originally Posted by oil_film_movies
Airbus aircraft since 1988 have kept the pilots from stalling by pitching down automatically
Umm, no. Since the advent of the A320, Airbus aircraft in Normal Law simply don't allow a stalling AOA to be reached however hard the PF pulls back on his sidestick. There is no pitching down but rather a limit to pitching up.
Here is the truth: Every pitch (or alpha) limit must arrest a positive pitch rate into the stall with a down elevator, or, in this case, down pitching moment using the stabilizer tailplane. Its kinda physics. Think of this MCAS and/or Airbus-style pitch/alpha limits as putting the brakes on pitch-up which requires an opposing moment. ...

Then note these MCAS accidents on the 737 Max8 had persistent pitch-down moments generated, quite similar to the Airbus A330 issue in 2008 on Qantas 72 ( https://www.atsb.gov.au/media/3532398/ao2008070.pdf ... https://www.smh.com.au/lifestyle/th...es-pilots-powerless-20170511-gw26ae.html ... which was the result of the stall prevention control laws in the Airbus pitching down from a bad AoA number.
 
Originally Posted by ZeeOSix
Originally Posted by oil_film_movies
Originally Posted by ZeeOSix
Originally Posted by Astro14
Most airline pilots are not used to AOA.
AOA and airspeed are two very important parameter of flight dynamics ... why in the world would airline pilots not use AOA information? If you could only have two parameters to use to fly an airplane it would be airspeed and AOA.
Stall AoA is important, not values of AoA less than that. I don't care if AoA is 5 degrees or 10 degrees, for example, if stall AoA is up there at 20 degrees for my current wing configuration.

The key is how airspeed and AoA is used when flying an airliner.


Originally Posted by oil_film_movies
http://www.boeing.com/commercial/aeromagazine/aero_12/attack_story.html


Like I said ... and the Boeing article mentions: "AOA is one of the most important parameters for understanding airplane performance and handling."

And yes, every airplane has it's own flight dynamics envelope defined by the airplane design with respect to airspeed, AoA, gross weight and weight distribution. How did pilots ever fly airplanes before they became automated? [rhetorical]. And obviously the stall speed as a function of all those parameters is what defines the maximum safe flight dynamics envelope of any airplane.

I can certainly see how the flight dynamics envelope has become heavily automated by computer controlled flight systems as airplanes have become larger and more complicated. But I'd assume part of any airline pilot's flight simulator training is how to fly the plane totally manually with basic flight information like airspeed, AoA and altitude if all automated flight systems are lost or need to be shut off for some reason.




We train to unreliable airspeed. Pitot-static failure, in other words.

We also train to manual flying - e.g. visual approach, with no glideslope or localizer , no autothrottles, and no flight director. Pitch, power, airspeed and VSI.

I can't tell you if other airlines train to the latter. Pretty clear from accidents like Asiana 214 that the proficiency in manual flying didn't exist. Perfectly good 777 on a clear day, and they crashed.

We've discussed proficiency previously in this thread, but let me be clear: the simulator itself is NOT enough to maintain proficiency. You learn the skills in the simulator, but they are perishable.

I hand-fly to the greatest extent possible, and I encourage my FOs to do the same. On the 757/767 fleet, it seems to be common to hand fly as much as possible.

That's a good thing.
 
Originally Posted by oil_film_movies
Originally Posted by ZeeOSix
... knowing AoA at any given time is valuable information when flying manually.
Workload is too high if you try to track AoA all the time. ..
You could track AoA in an airliner I guess, although it's not as easy to do compared to tracking airspeed targets, I would say. ... Using airspeed is also traditional since pitot-static tubes have been around far longer than AoA vanes. ... It makes more sense to focus attention on airspeed as a Human Factors priority. When a pilot is changing pitch a lot, then he can momentarily divert some attention to Stall AoA limits. Usually flight in an airliner involves small changes in pitch (and roll) and airspeed is King.

That said, PLI & other stall margin visual indications using AoA vanes to see how close to stall the aircraft is, are good to fly with as cross-checks to confirm the airspeed target is sound.
Airline pilots who have PLI on their PFD say they use it to make sure the approach airspeed targets are taking their actual weight into account well, a safety cross-check.


I disagree.

Knowing the AOA all the time is useful. It's a good crosscheck.

I would impute the AOA in the 747-400 by flying with the Flight Path Vector selected on the Primary Flight Display. The difference between pitch and FPV position is the AOA.

Very interesting to see that airplane climbing out, at 285 KIAS (Vref 30 +100 Knots was clean climb below 10,000', we had a waiver to exceed 250) at 875,000 gross. The pitch would be about 10-11 degrees, but the FPV was only 3 degrees above the horizon.

So, the airplane was "mushing" along at high AOA, despite the high airspeed. It was climbing, but not as much as the pitch alone would indicate.

The most sophisticated of airplanes (those with HUDS) have AOA presented all the time.

I hand flew the F/A-18 all the time. AOA was presented 100% of the time on the HUD. Not at all distracting and very, very useful in all flight regimes. In the F-14, AOA was displayed on the left side of the ACM panel. Again, I used it all the time in flight, and particularly when landing.

AOA is a much more complete picture of what the airplane is doing than just Airspeed.
 
Originally Posted by fdcg27
Originally Posted by oil_film_movies
Airbus aircraft since 1988 have kept the pilots from stalling by pitching down automatically



Umm, no.
Since the advent of the A320, Airbus aircraft in Normal Law simply don't allow a stalling AOA to be reached however hard the PF pulls back on his sidestick. There is no pitching down but rather a limit to pitching up.
AF 447 happened because the crew were relying upon what were erroneous airspeed indications and thought that they were entering a potentially lethal transonic regime. Thinking that they were operating in Normal Law while they were really in Alternate Law with no alpha protection, they applied full back stick and maintained that long enough that the airplane ended up in the Atlantic Ocean in the ITCZ, an area of notoriously bad weather which probably contributed to the icing of the known to have problems Thales probes leading to incorrect airspeed indications.
I kind of thought that the envelope protection dumping things right in the laps of the crew only after things got really bad was a contributing cause of the accident.
If real pilots can fly pitch and power, the software should be able to as well.


Couldn't agree more.


So, the Airbus flight controls consider pilot input, from the stick and rudders, processed via 7 computers, and then, in Normal Law, deliver the requested body rate in that axis.

Pull back on the stick, and the airplane will pitch up. Zero the stick and it will stop pitching, and remain at that pitch. Very easy. No trim required.

Slam the stick back, and the airplane will deliver body rate until it hits a limit, usually Alpha Protection in that case. At that point, there is no nose down, it simply stops giving the pilot the pitch up requested. Makes recovery from stall, windshear, or terrain encounters really easy: full back stick and the airplane will simply maintain the optimum AOA (which is just short of AOAmax).

Alpha Prot and other flight envelope protections are removed when in alternate law.
 
Originally Posted by oil_film_movies
Originally Posted by DoubleWasp
Stupid question: Is there a good reason why the MCAS does not have it's own programmed limit where it realizes that it's next move will toss the aircraft into the ground? Is it not aware of altitude?
That is a smart question, a solid concept. .... Yes, it could be the software can apply the simple logic: "if pitch angle is less than 5 degrees, then stop MCAS down autotrim." Simple as that. (I picked 5 degrees, might be right. Some small amount of pitch anyway.) After all, we're just trying to arrest pitch-up stall due to the engine nacelles. Note "pitch angle" is triplex redundant on this airplane too, highly reliable, and just used here to disable or enable MCAS anyway, so safe to do that.
Your question specifically involved a radar altitude cross-check, and I wouldn't use altitude since stall at low altitude is a big problem MCAS is there to counter.

Originally Posted by fdcg27
Originally Posted by oil_film_movies
Airbus aircraft since 1988 have kept the pilots from stalling by pitching down automatically
Umm, no. Since the advent of the A320, Airbus aircraft in Normal Law simply don't allow a stalling AOA to be reached however hard the PF pulls back on his sidestick. There is no pitching down but rather a limit to pitching up.
Here is the truth: Every pitch (or alpha) limit must arrest a positive pitch rate into the stall with a down elevator, or, in this case, down pitching moment using the stabilizer tailplane. Its kinda physics. Think of this MCAS and/or Airbus-style pitch/alpha limits as putting the brakes on pitch-up which requires an opposing moment. ...

Then note these MCAS accidents on the 737 Max8 had persistent pitch-down moments generated, quite similar to the Airbus A330 issue in 2008 on Qantas 72 ( https://www.atsb.gov.au/media/3532398/ao2008070.pdf ... https://www.smh.com.au/lifestyle/th...es-pilots-powerless-20170511-gw26ae.html ... which was the result of the stall prevention control laws in the Airbus pitching down from a bad AoA number.



Quote
. "Control of the aircraft remains and will remain at all times in the hands of the crew who are the last safety net," a spokesman says. "The Airbus design philosophy is that pilots should be able to take over at all times, as the crew did with QF72."


That's a surprisingly flippant response given the gravity of the situation. Those guys were dealing with a suicidal mental patient. The "Hey, it all worked out in the end. Just like it should." response is uncalled for.

Never read about this one. Shocking that they still don't know what the trigger was.
 
The report has the trigger: bad flight control computer that kept inputting false AOA.

Had a similar experience with an F-14 fuel management computer. It lost its mind and almost lost the airplane as a result as it ruptured a tank and caused a 1,500 pound per minute leak.

I couldn't help but wonder, as I was reading this report, why they didn't kill the FACs. The FACs compute envelope protection. Kill them, put the airplane in Alternate Law and stop the envelope protection.

In Normal Law, the pilots are in control, right up the envelope protection limits (bank angle, AOA, airspeed, pitch). So, no, they're not in control when the envelope protection is trying to kill them.

Probably not in the manual to switch off the FACs (because the engineers never anticipated this failure, so no procedure was written) but the Captain has authority to take whatever action is needed in an emergency.

This was certainly an emergency.

I also wonder if V Alpha Prot was displayed. It should have been, if the airplane was responding to Alpha limits...
 
Last edited:
Originally Posted by oil_film_movies
Looking at your previous post showing the image with the "Airplane Transfer Functions" block:
That block is NOT what the autopilot and/or stability augmentation on-oboard computers implement...



You're mixing up two different posts. I never said this was an "autopilot and/or stability augmentation" block.

What I said was this was a "simplistic" example to show what transfer functions are and the role transfer functions play in Aircraft Control and Stability, since some readers may not have known what was being discussed.
 
Originally Posted by DoubleWasp
Quote
Airbus on Qantas A330 flight 72 AoA-ADIRU problem: "Control of the aircraft remains and will remain at all times in the hands of the crew who are the last safety net," a spokesman says. "The Airbus design philosophy is that pilots should be able to take over at all times, as the crew did with QF72."
That's a surprisingly flippant response given the gravity of the situation. Those guys were dealing with a suicidal mental patient. The "Hey, it all worked out in the end. Just like it should." response is uncalled for. Never read about this one. Shocking that they still don't know what the trigger was.
Airbus PR & Legal Dept. can get a little insensitive at times. True.
That Qantas A330 accident's details have gradually come out over the years, and it demonstrates that the tail causes pitch down whether it's a 737Max8 in MCAS or AirbusA330 in stall protection. I'll explain how Boeing's new MCAS is fundamentally similar to Airbus's stall avoidance actuation. They are not that different as some have claimed above.
There's always a difference in viewpoint between flight control aero engineers and pilots. This is one of those cases that a deeper understanding is needed to understand the root cause and a description of the actual physics of flight, something more than just "I pushed that, and that happened" type of view.


Originally Posted by Astro14
The report {Qantas A330 flight 72} has the trigger: bad flight control computer that kept inputting false AOA.
I disagree. Based on the facts. The trigger was in the ADIRU bus packing, not the flight control computer, obviously, if you ever read the short ATSB accident summary, at least.

Originally Posted by DoubleWasp
Never read about this one. {Qantas A330 flight 72 in 2008} Shocking that they still don't know what the trigger was.
You're talking about the ADIRU bus packing issue trigger. Airbus knows the internal mechanism now. They aren't saying much either. The Australian ATSB didn't know at the time the report came out. It was a hardware-software integration timing problem packing bytes on the bus, along with a memory managment buffer over-run issue, as heard from a software engineer I spoke to a few years ago about some static code analysis done by an outside consultant that leaked the basics out in 'secret' to some peers at a conference in 2014. (Vague, no details from him.)

Originally Posted by Astro14
Slam the stick back, and the airplane will deliver body rate until it hits a limit, usually Alpha Protection in that case. At that point, there is no nose down, it simply stops giving the pilot the pitch up requested.
Right.... ask the pilots of Qantas 72 if "no nose down" is being applied on an Airbus. ... Both Boeing MCAS and Airbus stall prevention apply nose down tail lift. Being a stick jockey, you make statements like that, since it's all you see. Reality is different.

Fact is, the LionAir/Ethiopian/Qantas pitch-down problems were ALL the result of pitch down elevator or stab tailplane actuation, all pitch down moments (lift on tail), Boeing AND Airbus. Emphasis is on pitch down moment (torque).

Originally Posted by Astro14
Originally Posted by oil_film_movies
..are good to fly with as cross-checks to confirm the airspeed target is sound. Airline pilots who have PLI on their PFD say they use it to make sure the approach airspeed targets are taking their actual weight into account well, a safety cross-check.
I disagree. Knowing the AOA all the time is useful. It's a good crosscheck.
You 'disagree' with cross-checking alpha, even though you said cross-check alpha? ...O...K....

Astro14, your examples of flying fighters is a poor comparison to non-aerobatic airliner flying, the subject here. It's a different task. In fighters you could use a higher alpha scan rate.
 
Last edited by a moderator:
Originally Posted by Oil_Film_Movies
...You're talking about the ADIRU bus packing issue trigger. Airbus knows the internal mechanism now...


ADIRU and Flight Anamolies

About Bus Packing:

In Embedded Systems terminology Embedded Systems - Wiki bus packing is the transfer of packets of 8/12/16/ or 32 bits along a serial data bus. A packet may control a specific control surface at any point in time and thus the packed data structure and its timing has to be precise.

At one Avionics company, I was simulating some flight control software in our simulation lab when a "buzz' was heard in the rudder actuator during a programmed flight.

We had some software written by a very capable friend of mine that could intercept the packets and display and capture the data streams. In capturing the data streams, we found the bus packing, timing, and rudder response were inappropriate for the commanded rudder action.

This anomaly of course was noted and sent back to the data bus programming team as a "corrective-action" item and it was corrected.

This is one example where simulation of flight software detected an anomaly before implementation in the actual aircraft.

BTW, For purposes of this discussion, you might find this List of Avionics Acronyms helpful:

AVIONICS ACRONYMS
 
Last edited:
Originally Posted by MolaKule
Originally Posted by Oil_Film_Movies
...You're talking about the ADIRU bus packing issue trigger. Airbus knows the internal mechanism now...
bus packing[/b] is the transfer of packets of 8/12/16/ or 32 bits along a serial data bus. A packet may control a specific control surface at any point in time and thus the packed data structure and its timing has to be precise.

An analogy to understand what happened in the ADIRU bus is: You write something on a Post-It note, and hand it to a courier to take upstairs to another person. You wrote down the wrong number, so you can't blame the courier the note was wrong. The ADIRU wrote the wrong data, and the bus just delivered the "note" as usual.
That is the nature (I don't have details) that caused AoA on the ADIRU bus to get swapped with altitude (labels, values). ...

One important concept related to the Qantas A330 flight 72 accident is that the flight control computers should have recieved parity bits and other error code data from the bus. The fact that it didn't get that is a clue the Airbus's problem was indeed on the ADIRU CPU side of the bus hardware as the ATSB investigators said. That is different than bus firmware-hardware causing a problem.

Comparing the current 737Max8 LionAir AoA problem to the 2008 Qantas Airbus A330 AoA problem, the failure origin was different. The LionAir (and presumably Ethiopian) AoA problem was some bizarre constant offset in one of the AoA vane's data values, while the Airbus A330 AoA value spiked due to digital software ADIRU bus issues. (The intermittent nature of the Airbus AoA spikes saved their lives actually, ending the nosedives in time.)
 
Last edited:
I think others have said this already, and it would work:
Solution to avoid future Qantas72/LionAir/Ethiopian/etc. types of problems: One big red button that Turns All Automation Off.

All these aircraft have forward CG's, making them inherently stable enough to command elevator (and manual trim) directly from the stick.
[Linked Image]
 
This is all definitely a lot to read through. but some very valuable information that I will take into tonight. I just wanted to take a moment to thank you guys in this thread for putting out an explaining a considerable amount of deep technical information. It is very appreciated in demystifying all of these situations.
 
Originally Posted by DoubleWasp
This is all definitely a lot to read through. but some very valuable information that I will take into tonight. I just wanted to take a moment to thank you guys in this thread for putting out an explaining a considerable amount of deep technical information. It is very appreciated in demystifying all of these situations.
Originally Posted by john_pifer
Guys, coming from an A&P, this stuff is very interesting. Thanks for posting...enjoying keeping up with this thread.
A super-lot to read through: Awesome discussion of this at https://www.pprune.org/rumours-news/619272-ethiopian-airliner-down-africa-98.html Those pprune folks are crazy and Good, at the same time! Red meat for them.

One theory of why the Qantas 72 Airbus A330 double-plunge happened is that the programmers of the ADIRU bus-packing software forgot to or misused the "volatile" C keyword in software and the compiler did the dirty deed. Intermittent due to CPU cache states varying there. ( https://www.geeksforgeeks.org/understanding-volatile-qualifier-in-c/ ) It's possible anyway.

https://news.aviation-safety.net/2011/12/19/report-in-flight-upset-of-airbus-a330-near-australia/
 
Astro,

I reread some of your posts about push / pull on the yoke, splitting the rear elevator into a one side up / one side down configuration, if enough force is applied. Is that correct? If so why would they design a rear stabilizer to become what amounts to an aileron? What am I not seeing, or seeing wrong here?
 
Problem with the big red button...and automation...

As I've explained in the autonomous vehicle threads, and with respect to automation in control systems in (lets say complex things like power stations) is that removing the driver from...driving...means that when the whoop hits the fan and after a number of alarms, and unexpected control system reaction to a few stabs at the controls, the driver has to all of a sudden review the entire system and see what world they are currently driving in in terms of positioning and control response...to work out a rational corrective action, or what could be in fact a serious mechanical failure that thye have to diagnose.

It's not as easy as Elon Musk saying .... driver, it's your turn now.
 
Status
Not open for further replies.
Back
Top Bottom