Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

A320 OEB Blocked AOA probes

Wikiposts
Search
Tech Log The very best in practical technical discussion on the web

A320 OEB Blocked AOA probes

Thread Tools
 
Search this Thread
 
Old 19th Jan 2015, 09:36
  #101 (permalink)  
 
Join Date: Jul 2007
Location: uk
Posts: 777
Received 0 Likes on 0 Posts
CONF iture: When I flew A330 it was possible to access the individual AOA values via the CMS using the applicable codes. I assume the A320 has similar functions?
Meikleour is offline  
Old 19th Jan 2015, 13:09
  #102 (permalink)  
 
Join Date: Mar 2001
Location: I wouldn't know.
Posts: 4,499
Likes: 0
Received 0 Likes on 0 Posts
Yup, those values are actually shown without the need to call them up by code, but that might be just a preset on our busses.
Denti is offline  
Old 19th Jan 2015, 13:54
  #103 (permalink)  
 
Join Date: Mar 2012
Location: Having a margarita on the beach
Posts: 2,423
Likes: 0
Received 0 Likes on 0 Posts
Are you supposed to access this kind of data during a flight ?
sonicbum is offline  
Old 19th Jan 2015, 15:01
  #104 (permalink)  
 
Join Date: Jul 2007
Location: uk
Posts: 777
Received 0 Likes on 0 Posts
sonicbum: Yes, easily done in flight.
Meikleour is offline  
Old 19th Jan 2015, 15:09
  #105 (permalink)  
 
Join Date: Mar 2012
Location: Having a margarita on the beach
Posts: 2,423
Likes: 0
Received 0 Likes on 0 Posts
Read the question again : are you supposed to ?
sonicbum is offline  
Old 19th Jan 2015, 15:54
  #106 (permalink)  
 
Join Date: Mar 2001
Location: I wouldn't know.
Posts: 4,499
Likes: 0
Received 0 Likes on 0 Posts
For a test flight like that, yes, of course. In normal line operation? No, not really, just used to check on some facts or for curiosities sake.
Denti is offline  
Old 19th Jan 2015, 17:30
  #107 (permalink)  
 
Join Date: Mar 2012
Location: Having a margarita on the beach
Posts: 2,423
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Denti
For a test flight like that, yes, of course. In normal line operation? No, not really, just used to check on some facts or for curiosities sake.
This is the point. The thread veered from its original meaning.
sonicbum is offline  
Old 19th Jan 2015, 18:43
  #108 (permalink)  
 
Join Date: Jan 2001
Location: UK
Posts: 2,044
Likes: 0
Received 0 Likes on 0 Posts
Except that there is no way to do it ... but good luck.
Posts above appear to disagree with that? I appreciate you appear to have a grudge against Airbus and it's products, but does it really extend to accusing Airbus of writing Test Schedules asking the impossible

Did you get that it was not possible to determine if this message was really presented to the crew ... ?
I do, but the likelihood is it was, and anyway, there was other, more compelling evidence.

Then I am sure the mere 320 line pilot you are would like to know something is wrong with its AOA data before he blindly and religiously follows his Airbus GPWS procedure ...
I am not sure I would? The QF A380 incident, IIRC, is tending towards reducing "ECAM Messages" for everything? I spend enough of my time on the A320 dealing with spurious, unnecessary, and transitory ECAM messages. There needs to be a balance in life, some level of trust in designers and certification procedures re "fault tree analysis". To have an AoA problem such as Perpignan, ignore the signs there was such an issue, and then require a Max Perf GPWS warning I consider "improbable".

Is the Airbus FBW perfect? Of course not. Has it stood the test of time well, for the first mass market FBW commercial airliner? Yes. It has been improved, minor faults ironed out. I think we are now past the stage where the machine is the target of "blame" and "fault" - indeed for the A320 series I do not think it ever was. The FBW is well in the mature "refinement" phase.

The training and oversight / management of the operators would be a more productive target - IMHO. Perpignan an unfortunate, but clear, example - despite Airbus' efforts, man proved it is not uncrashable
NigelOnDraft is offline  
Old 19th Jan 2015, 20:09
  #109 (permalink)  
 
Join Date: Feb 2005
Location: Correr es mi destino por no llevar papel
Posts: 1,422
Received 1 Like on 1 Post
Originally Posted by CONF iture
It seems the A400 has such a switch - Is it the red guarded one on the left side on the upper panel ? - I don't know.
Zee pushbutton is optional and labelled "EVAC". At least, last part of your statement is correct.
Clandestino is offline  
Old 19th Jan 2015, 21:19
  #110 (permalink)  
 
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by NoD
Posts above appear to disagree with that? I appreciate you appear to have a grudge against Airbus and it's products, but does it really extend to accusing Airbus of writing Test Schedules asking the impossible.
Exact same reply stands :
The crew has rushed and was clearly poorly prepared, but how would you want them to check those 3 AOA values when only 2 are available and so only indirectly through the third MCDU ... ?
But what about you actually link the document you mention ... ?

To have an AoA problem such as Perpignan, ignore the signs there was such an issue, and then require a Max Perf GPWS warning I consider "improbable".
As improbable as 2 AOA vanes would lie together to trigger a protection that a crew could do nothing about it ... except by shutting down some computers ... or how to have to publish an improbable red OEB.
CONF iture is offline  
Old 20th Jan 2015, 09:42
  #111 (permalink)  
 
Join Date: Jan 2001
Location: UK
Posts: 2,044
Likes: 0
Received 0 Likes on 0 Posts
The crew has rushed and was clearly poorly prepared, but how would you want them to check those 3 AOA values when only 2 are available and so only indirectly through the third MCDU ... ?
But what about you actually link the document you mention ... ?
BEA Report:
Low speed checks
These are to verify, for an in-service aeroplane, the activation, at scheduled and signalled speeds on the PFD speed band, of the angle of attack protections in normal law.
The description of low speed checks in the ISATM is similar that of low speed tests in the PATM. Ground checks, then checks in flight in clean, then landing, configuration performed between FL100 and FL140, are defined. Before starting low speed checks, the crew must reduce and stabilise speed in order to record the three angle of attack values and compare them to the attitude and pitch.
NigelOnDraft is offline  
Old 20th Jan 2015, 10:10
  #112 (permalink)  
 
Join Date: Jun 2007
Location: Wanderlust
Posts: 3,407
Likes: 0
Received 0 Likes on 0 Posts
NigelOnDraft
Once we leave the ground we are in a hostile territory because since it is not a human habitat we have no instincts whatsoever. Only birds have that and that is why we have procedures. Any deviation from them and you are like a blind man who has missed a cue. There are any number of accidents/incidents which show that whenever a pilot has surprised the airplane by change of plan the aircraft has sprung up a fatal surprise. But you won't prove a point to Conf.
vilas is offline  
Old 23rd Jan 2015, 15:51
  #113 (permalink)  
 
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes on 0 Posts
Blame the crew for not doing the test above 10000ft and not recalling the characteristic speeds during the briefing, but not for not applying a procedure they didn't have.
In the meantime I do maintain that ISATM procedure is erroneous as there is no way to read the data for AOA #3

Originally Posted by vilas
But you won't prove a point to Conf.
Conf wouldn't keep his job much longer if he was not following the procedures.
The system knew something was wrong with the data, all it needed was to advise the crew by a straightforward ECAM MSG :
NAV AOA DISAGREE

As Airbus gave so much priority to the AOA data in its system, it would be logical to at least advise a crew when one single reading differs from the 2 others.
CONF iture is offline  
Old 23rd Jan 2015, 18:38
  #114 (permalink)  
 
Join Date: Mar 2001
Location: I wouldn't know.
Posts: 4,499
Likes: 0
Received 0 Likes on 0 Posts
In the meantime I do maintain that ISATM procedure is erroneous as there is no way to read the data for AOA #3
Why wouldn't be there any way? You can read all AoA values from every MCDU as has been explained above. It's easy enough to do, and i would expect it to be detailed in the relevant procedure.

I do agree however that an AoA disagree advisory would be a nice clue about whats up.
Denti is offline  
Old 23rd Jan 2015, 19:02
  #115 (permalink)  
 
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes on 0 Posts
One problem is that this was a 1 vs 2 disagree. So the system used the "2" that agreed. (Just like a pilot would I suspect, given three sources of data where 2 agreed). The most likely scenario for such a case is the "1" is bad, so ignoring it and doing nothing else is a good plan EXCEPT if you are doing flight tests. So if there was a message which just said "take no action" I'm not surprised they decided not to bother line crews with it.

A lot of this comes down to the big topic from this accident - the way such flight tests are (were, rather) conducted.
Mad (Flt) Scientist is offline  
Old 24th Jan 2015, 04:45
  #116 (permalink)  
 
Join Date: Jun 2007
Location: Wanderlust
Posts: 3,407
Likes: 0
Received 0 Likes on 0 Posts
Conf
I said in post 46 the following
"All these protections are triggered from data derived from one sensor or the other but the present system of sifting the data to ensure it's genuineness is being proved inadequate and is the cause of all these incidents. The answer to this will come from better sensors, better system of confirmation of data or even quantum leap of technology in measurement of airspeed,"
So I had already said AB needs to change the method of identifying the faulty ADR/component. That includes change in ECAM messages or even giving the job to the crew to identify it for themselves until a new method of air speed measurement is discovered. I agree that crew was not warned of the ADR3 rejection in some cases it does which can be easily included in the ECAM and the crew advised to confirm it if it was correct.

Last edited by vilas; 24th Jan 2015 at 04:58.
vilas is offline  
Old 26th Jan 2015, 20:22
  #117 (permalink)  
 
Join Date: May 2000
Location: Glorious West Sussex
Age: 76
Posts: 1,020
Likes: 0
Received 0 Likes on 0 Posts
The 1v2 disagree can be fixed quite simply by introducing monitoring over time. The Perpignan a/c had two probes at fixed values for a long period, including speed, altitude, and config changes... if a flight test engineer had monitored them he would have noticed the fault; all we need now is software as competent as humans.
TyroPicard is offline  
Old 26th Jan 2015, 20:43
  #118 (permalink)  
 
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Denti
Why wouldn't be there any way?
Every single parameter is not necessarily available through the ACMS (or is it called AIDS on the 320 ?)
AOA1 and 2 are there but #3 is nowhere to be seen ...
CONF iture is offline  
Old 27th Jan 2015, 00:42
  #119 (permalink)  
 
Join Date: Mar 2009
Location: Prague
Age: 51
Posts: 60
Likes: 0
Received 0 Likes on 0 Posts
All three AOA are available on AIDS and test flight requires write down value for all of them in clean configuration,green dot speed and croscheck/comparation with "angle" obtained from differenece btwn. pitch and flight path angle. Maximum allowable difference is 0,5 degree. Don't know if this procedure was valid at the time when Perpignan happend..

Last edited by LEVEL600; 27th Jan 2015 at 01:02.
LEVEL600 is offline  
Old 27th Jan 2015, 09:58
  #120 (permalink)  
 
Join Date: Jun 2007
Location: Wanderlust
Posts: 3,407
Likes: 0
Received 0 Likes on 0 Posts
One thing which I did not understand is why did the aircraft go in direct law. First the rejection of the third is no different than ADR3 fault should have come on ECAM and the second is any combination of ADR malfunctions is not suppose to trigger direct law. Nobody else also has noticed it.
vilas is offline  


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.