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

AF 447 Thread No. 7

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

AF 447 Thread No. 7

Old 3rd Apr 2012, 23:04
  #1241 (permalink)  
 
Join Date: Jun 2009
Location: Bedford, UK
Age: 69
Posts: 1,321
Likes: 0
Received 0 Likes on 0 Posts
PJ2 - thanks again. Sorry about all this: was the answer 28000 feet ?
Mr Optimistic is offline  
Old 3rd Apr 2012, 23:22
  #1242 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 75
Posts: 2,482
Likes: 0
Received 0 Likes on 0 Posts
Mr. Optimistic

Re your earlier question about when the captain returned was 20k of altitude sufficient?

The captain returned when the aircraft was in descent passing FL355 just as the stall warning stopped due to "NCD" from the AoA vanes and the VS was about -10,000fpm. The sim exercises showed that recovery could occur with aggressive ND sidestick, held until the airplane began flying again and that took between 18,000ft and 22,000ft depending upon the exercise and when recovery actions began, (SS moved from NU to ND, etc). (that is a 4000ft difference but bear in mind at these descent rates that is also about 12 seconds.

The answer depends more upon the actions taken than it does on the airplane once recovery actions are aggressive and in place. I don't think part ND SS would do it in 20,000ft and it may not do it at all from an AoA of 40deg.

Last edited by PJ2; 3rd Apr 2012 at 23:48.
PJ2 is offline  
Old 4th Apr 2012, 03:54
  #1243 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Aftermath of AF 447 until BEA final report

Hi,

Considering what was learned by operators and pilots until now:

Is it probable a similar case (UAS, cruise) where crew "don't understand"?

What kind of man-machine interface enhancement could be useful to allow immediate crew "understanding" of the issue (UAS), in order to go DIRECTLY to the "fix"? (UAS drill, whatever)
I'm assuming crew never identified the UAS. This (lack of understanding) subsequently being aggravated by inadequate PF SS handling and wrong perception of speed, misleading (PF) persistently to try reduce it (350 to apogee). Always increasing (continuously) the "lack of understanding" of PF/PM then Captain, by several consequences of initial errors.
RR_NDB is offline  
Old 4th Apr 2012, 05:20
  #1244 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 80
Posts: 1,330
Likes: 0
Received 0 Likes on 0 Posts
Originally posted by RR_NDB ...
I'm assuming crew never identified the UAS.
Well, they did. Or at least the PNF announced the loss of speeds and later the change to ALT Law.
From IR#3 .. At 2 h 10 min 10, the PF's nose-up inputs increased the angle of attack and the stall warning triggered twice transitorily. Probably in reaction to this warning, the PNF exclaimed "what is that?". The PF then said "We haven't got good We haven't got a good display of speed" and the PNF "We've lost the speeds". The angle of attack recorded was around 5, for a theoretical stall warning threshold trigger value of slightly over 4.
The crew identified the loss of the speed displays but neither of the two copilots called out the associated procedure. The "Unreliable IAS" emergency manoeuvre requires as a first step to disconnect the automatic flight controls and disengage the Flight Directors. The two copilots had only been trained for the emergency manoeuvre at lower levels, in the course of which the pitch attitude to adopt is 10 or 15.
Page 54/55 of BEA Interim Report No.3 provides detail on what should have been done under the heading:-

1.17.4 Air France crew operational instructions

The real question should be why the PF believed he could manoeuvre the A/C at FL350+ the same way he had been trained to do at below FL100. Ultimately what was done right/wrong and by whom boils down to bad CRM associated with as yet undetermined Human Factors. I do find it "a bit of a stretch" to blame the systems/human interface when many similar situations have been successfully handled by other crews. All this crew were required to do is detailed in AF SOPs.
mm43 is offline  
Old 4th Apr 2012, 14:27
  #1245 (permalink)  
 
Join Date: Jul 2009
Location: Not far from a big Lake
Age: 81
Posts: 1,461
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by MM43
The real question should be why the PF believed he could manoeuvre the A/C at FL350+ the same way he had been trained to do at below FL100. Ultimately what was done right/wrong and by whom boils down to bad CRM associated with as yet undetermined Human Factors. I do find it "a bit of a stretch" to blame the systems/human interface when many similar situations have been successfully handled by other crews. All this crew were required to do is detailed in AF SOPs.
It is all well and fine to put something down in a written SOP, but if you do not test people to verify their understanding of the SOP, then you are asking for major violations of the SOP.

Since PF & PNF had apparently not had a chance to demonstrate flight in cruise in ALT2 law under UAS conditions, they were open to uncorrected misunderstandings.

If the regular sim sessions were not long enough to exercise this capability, then they were not long enough. Any misunderstanding should have been found and fixed. That falls right on the bean counter's and upper management's heads.
Machinbird is offline  
Old 4th Apr 2012, 14:36
  #1246 (permalink)  
 
Join Date: Oct 2011
Location: Lower Skunk Cabbageland, WA
Age: 73
Posts: 360
Likes: 0
Received 0 Likes on 0 Posts
Exclamation

What kind of man-machine interface enhancement could be useful to allow immediate crew "understanding" of the issue (UAS), in order to go DIRECTLY to the "fix"? (UAS drill, whatever)
How about another aural warning? "Unreliable airspeed! Go to memory items!" I realize that this crew was already overloaded with warnings, but if the airplane "knows" it's in UAS, there's no excuse for it not to use every means to notify the pilots.
Organfreak is offline  
Old 4th Apr 2012, 14:56
  #1247 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Lack of minimum understanding: UAS root cause

...when many similar situations have been successfully handled by other crews.


Statistically speaking ONE case of COMPLETE lack of understanding after trigger (3 Pitot's then UAS) among other < 40 cases reccommend attention to EVERYTHING. (HF, man machine interface, etc.). We must remember similar conditions (no visual references, turbulence, etc.) could occur again.

My point is:

1) Considering "frequency" of UAS cases traced to the use of now obsolete Thales probes.

2) Considering some cases were related to the use of competitor probes, currently and still in use.

3) Considering they became "rapidly lost" and "increasingly confused"

4) Considering Pitot's data (simultaneous failure) are still today not adequately processed (NO REDUNDANCY AT ALL) by System

5) Considering identification of UAS presently has to be done by scan and feeling (as linked paper put)

6) Consider PF was caught in surprise and acted almost immediately (by "lack of speeds" as you observed)

I ask:

Why not to provide an instantaneous (even non causal, before an eventual Law change) indication to the crews (Airbus SAS, Boeing, Embraer, etc.) (PRECISELY) of UAS?

Complementing: The point is, everything SIMPLE and PRECISE the System (through the man machine interface) provide to the crew, if possible (UAS is) IMO increases the safety of the plane operation.

Surprises (coming from her ) better to avoid.

The mentioned paper (i am considering still valid and "official") led me to this point.

AF447 case was not "triggered just by "tiny ice crystals" affecting "obsolete AS probes" in a System operating without redundancy (Air data).

AF447 case was triggered (it seems to me) by a "lack of understanding" of what was really happening. UAS as everyone know, causes erratic indication in several indicators as mentioned in the linked paper. The Pitot data (considered GARBAGE by the System designers) during a transient phase are still fed to pilots (they receive this "input") that need to rush the scan in order to just identify UAS. As the paper points.

If the System tells you (on UAS) you save time (precious) and could act MUCH more precisely and fast.

IMO, the "interface" should be reviewed. Why? Because in my opinion can be easily improved with good cost benefit relationship.

BUSS could still be an optional. (STD in 380);

An UAS indicator could be Standard. At least before we solve the Pitot's issue.

I do find it "a bit of a stretch" to blame the systems
Evolution (stepwise) is not based in "blaming". Sometimes "a tweak" (as you know) "makes a difference"

Ultimately what was done right/wrong and by whom boils down to bad CRM associated with as yet undetermined Human Factors.

I agree. But remember:

CRM and HF "becomes critical" under extreme difficult conditions. In Portland the crew had time to digest the surprise (gear problem). F-GZCP had few seconds and apparently never understood and realized the "benign" problem: Simply an UAS. That shortly "dissipated".

Last edited by Jetdriver; 5th Apr 2012 at 02:43.
RR_NDB is offline  
Old 4th Apr 2012, 15:33
  #1248 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Hi,

Since PF & PNF had apparently not had a chance to demonstrate flight in cruise in ALT2 law under UAS conditions, they were open to uncorrected misunderstandings.
Open to everything specially in EXTREME conditions.

but if the airplane "knows" it's in UAS, there's no excuse for it not to use every means to notify the pilots.
The information (Pitot's "garbage out") is available. The System (a subsystem) could easily process and present the results. How? This must be studied. The interface must be always kept simple. K.I.S.S. principle is mandatory to the interface characteristics.

PS

HF study could be extended to upper management, bean counter's and System designers. .

In order to understand why they fail. And to improve man machine interface.
RR_NDB is offline  
Old 4th Apr 2012, 20:06
  #1249 (permalink)  
 
Join Date: Jul 2002
Location: UK
Posts: 3,182
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by gums
Seems that Doze also tried a recovery in the sim, that right Doze? We need a refresher of your findings.
They're on the last pages of the previous thread and the first pages of this one.
DozyWannabe is offline  
Old 4th Apr 2012, 21:45
  #1250 (permalink)  
 
Join Date: Dec 2010
Location: Middle America
Age: 83
Posts: 1,167
Likes: 0
Received 0 Likes on 0 Posts
SIM Experiences

I wanted to make it a little easier to see each of the SIM experiences, so I put them all together in this post. Each experience is followed by answers to questions by other posters. I didn't post the questions (saving some space) but they should be evident from the answers. Hope this helps....

From CONF iture:

As we got little extra time in the sim today, we did experience a full stall from FL350.
Here is what I can report from the experience :
From the STALL warning we kept a light aft pressure on the sidestick
It was not long before we got a negative vertical speed of 15000ft/min
THS went to 12 deg UP under STALL warning
As we decided to exit the stall, full fwd pressure on the sidestick was applied
But we were unable to lower the nose
THS did not move
THS was then manually rolled fwd
Nose came down
Exit was then possible
I can't remember all the details, too much stuff to look at.
Thrust was kept at idle all the time.

Early fwd pressure on the sidestick at initial STALL warning should prevent a stall to develop.

From DozyWannabe:

What we had was an A320 sim rather than an A330, which comes with some key differences - the most obvious of which is the lack of Alternate 2, the nearest equivalent being Alternate without speed stability, and a different underlying architecture past a certain point.

The first experiment involved setting the conditions to night IMC with CBs in the vicinity, having set the autoflight to take us to 35,000ft and hold us there. We had a friend of his who is a TRE sitting in the LHS to provide guidance and monitor what we were doing. He then failed the ADCs, leading to autopilot disconnect and a drop to Alternate (without speed stability) and we tried to follow through and maintain a 15 degree pitch angle. Things we noted:
I'd suspected it would involve considerable effort to hold the sidestick there for a significant amount of time, but I was genuinely surprised at just how much.
The zoom climb occurred exactly the way we expected
The Alternate Law (no speed stability) on the A320 seems to have a hard trim limit of 3 degrees nose up
It was definitely possible to hold the aircraft in the stall with 3 degrees of nose-up trim and full back stick, but it required effort
The aircraft wanted to nose down and recover itself, and with about 10 degrees of nose-down maintained with the sidestick at the moment we passed about 30,000ft, we managed to effect a recovery with the speed coming back up to a point where we could level out safely at about 20-25,000ft judging by the standby altimeter.
The second experiment was the same as the first, but as my pal had noted, the A320 has a hard limit of 3 degrees NU trim available via autotrim in the secondary Alternate Law. We tried again, this time winding in full nose-up trim manually just prior to the point of stall. This time:
The aircraft seemed more willing to hold pitch with the trim at full-up, but to hold it at 15 degrees still required considerable effort
We had to add a touch of rudder (on the TRE's advice) to control the roll.
Despite full nose-up trim, we elected to start a recovery as we came down through about 35,000ft this time, just to see if it was possible using sidestick only
Following the same 10 degree nose-down sidestick demand as before, the trim rolled forward with the sidestick demand, returning to around neutral within about 5-8 seconds, and we came out of the stall as before.
Based on this, as far as the A320 is concerned at least, recovery is possible using autotrim via sidestick only even when the trim has been manually wound fully nose-up. Given more time we'd have liked to see what happened attempting recovery at lower altitudes, but the general take-away seems to be that with sufficient forward sidestick demand it is possible to recover from stall even with trim forced to where it's not supposed to be.
Further details I've just been reminded of - the stall stabilised at approx 180kts IAS on the sim control with the nose-up trim at 3 degrees (the A320 hard limit). With full nose-up trim the stall was similar, but stabilised at approx. 160kts IAS. The Stall Warning was not only clear, but so loud that the TRE had to cancel it with the Emergency Cancel button in order for us to hear each other. On the second (full nose-up trim) experiment, all I had to do was briefly glance down to my left to see the trim roll forward - smoothly and *very* quickly - following recovery via sidestick pitch down.

Some questions answered:

Having conferred, we loaded extra fuel so that the FMGC showed MAX ALT FL379. C of G was 32% MAC. The ROD in our experiments maxed at approx 6,000ft per minute, with the VSI needle turning amber in the PFD. One of the reasons I hope someone will perform a later experiment will be to see how leaving the recovery till later in the sequence will affect the ROD, and hopefully also find out how a 40% MAC CoG will affect things. The caveat here is that the later you leave it, the further outside the tested flight envelope you go, and the more divergent the sim's performance from the real thing will become.
After the initial NU pitch increase (induced with approximately half back-stick, as in the DFDR traces), we triggered a very short "G" induced stall warning as we climbed, then when the real warning sounded continuously (as happened in the AF447 scenario) we applied TOGA and held 10 to 15 degs pitch on the sidestick - during which full deflection was required in order to come close to maintaining it - as I said, the nose wanted to come down naturally if I released pressure for even a split-second.

Initially, autothrust dropped to Thrust Lock. We pulled the thrust levers back to match the thrust, but as we moved them the thrust increased slightly. The TRE then deliberately staggered the TLs slightly to induce a roll to the right which we trimmed out with rudder and the slightest touch of aileron.

From PJ2:

With weights, CG, SAT mirroring AF447 and a bit of turbulence, following loss of airspeed (all 3 ADRs out), the sim was pitched up at FL350 and held in the climb until stalled, (THS reached 13.6deg). Shortly after the stall we returned the ADRs for use during the balance of the exercise, (to see the FPV during the stall).

Post-apogee (approx FL360), full forward stick was applied and held.

At FL330 the pitch was 8deg ND.

At FL310 the AoA (using FPV) was approx 40deg and the VSI was 18000fpm +. Pitch was about 14deg ND which was all the pitch that could be obtained.

Pitch slowly reduced to about 10degND still with full forward stick. As it was held the THS unwound and returned to normal settings.

We could watch the AoA reducing as the FPV slowly climbed "up" the PFD from past the red ND warning arrows below 30deg pitch marks.

Thirty seconds after the first Stall Warning passing through FL270 the AoA had reduced to 30deg, descent rate was 16000fpm.

Ten seconds later at FL255 the AoA was 12deg, CAS was 250kts, VSI was 7400fpm.

At FL245 the stall warning stopped 40 seconds after it began, the AoA was 10degND, M0.658, VSI 7000fpm down, CAS 278kts.

From an AoA of 40deg to 10deg took 24 seconds and about 6000ft. This exercise took about 22000ft; some were less.

Overspeed was never a problem nor was a secondary stall if one was gentle, (took about another 6000ft IIRC)

Some questions answered:
Normal cruise pitch attitude is between 2.3 and 3deg depending mostly upon weight. A pitch up to 5deg pitch attitude (+2.5deg) results in about an 800 to 1500fpm climb and a gradual loss of energy if held long enough. The UAS QRH checklist and the FCTM cautions strongly against holding such pitch attitudes for long and advises to get the QRH out quickly and set pitch and power. The FCTM also states that the Memory Items are not to be done if the immediate safety of the aircraft is not impacted.

For the purposes of the exercise there was no "judging" of how much to pitch up. We pitched up high enough to stall the aircraft. Fifteen degrees would do it, sometimes we were higher.

The overriding impression of these sessions was how quickly things occurred and how fast was the altitude loss.

My comment about "how quickly things unfold" is an observation on the amount of time it took to lose control. Time is always "relative to perception and familiarity". When a pilot is highly trained, highly experienced and very familiar with his/her airplane, the flow of even huge amounts of information and lots of events flow much more slowly, perceptually, because the mind anticipates much more effectively and easily, (depending upon other factors such as distraction, fatigue) than if one is relatively inexperienced in such circumstances.

In terms of this loss of control, while it unfolded literally over a period of about 40 seconds, oddly that is tons of time to do something, but it is not a lot of time for assessment, discussion, action.

In re the sim exercise, power was at various settings (though never TOGA). Also, there were variations in altitude needed for recovery. In one exercise we "did nothing" and the aircraft happily remained in stable flight at FL350 as power remained in "TOGA LOCK" (last setting before disconnect) and the pitch at 2.5deg, approximately.

gums, you're right about the sim not really being able to teach this kind of thing - you can't feel "the mush"...the slight delay in responsiveness in both changes in attitude and flight path even though the subtle indications may be accurately simulated.

The exercise was a worst-case - fully developed stall, late recovery attempt, thrust was not idle. As I mention to HN39, a smart recovery, (as in brisk forward stick at the first stall warning blip, held fully forward without variation, thrust at idle), can be made which reduces the altitude required. It's still going to take a lot of altitude to a) regain the AoA and b) regain the energy, (due low availability of excess thrust, so its height for energy, initially).

Thanks HN39...the FPV symbol was 10deg below the line dividing blue and brown on the PFD, which to me indicated an AoA of roughy +10deg while the aircraft was still descending rapidly, so it was my clumsy writing even though I think the meaning came through for most others. On the stall warning, in fact the first exercise there was no such warning because we had all the ADRs off, then on for the FPV later - we did it again using a different failure method to get the sim into Alt 2...these are details behind the larger exercise but technically correct - my posts are almost always too long as it is.

In my non-engineering view, the sim "behaved" as I expected the airplane might. I don't have experience with the Cooper-Harper scale although I am familiar with it and my own characterizations of the airplane were probably generous. The warning and cautions which accompanied the CAS and ADR failures were less distracting than I had anticipated.

I gathered from the session that it's difficult to simulate the loss of pitot/static information and get the exact same failures/ECAM messages and the method that got closest was failing ADRs and then re-instituting them to some degree. It didn't affect sim behaviour but it does affect available indications. This is a long way of explaining that I can't answer your question with any meaningful information. On one stall we had no warning which was because all ADRs were still failed and on others we had full FPV indications...a bit ad hoc in this area.
Turbine D is offline  
Old 5th Apr 2012, 00:27
  #1251 (permalink)  
 
Join Date: Jan 2005
Location: W of 30W
Posts: 1,939
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by DozyWannabe
In MANAGED mode, the corrections applied by the autoflight system are displayed in the SELECT window of the FCU panel. I want to make clear at this point that we're not talking about control inputs of a magnitude to effect 5000fpm descent rate immediately, simply that this is the value the software uses in certain configurations. Lower to the ground, you'll see -1500 appear in the window for a split second as corrections are applied, but you don't start descending at 1500fpm.
Never heard read or seen anything like it ... Anyone with valuable experience on 320 to confirm this ?
CONF iture is offline  
Old 5th Apr 2012, 01:51
  #1252 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 80
Posts: 1,330
Likes: 0
Received 0 Likes on 0 Posts
Originally posted by RR_NDB ...

Why not to provide an instantaneous (even non causal, before an eventual Law change) indication to the crews (Airbus SAS, Boeing, Embraer, etc.) (PRECISELY) of UAS?
Let's go back to AF447 Thread No.4 Post #616 - which was directed at you. My point is that if the A/C is to "detect" and "report" UAS, the system may as well be programmed to maintain the "status quo" as I proposed.

Originally posted by Machinbird ...

If the regular sim sessions were not long enough to exercise this capability, then they were not long enough. Any misunderstanding should have been found and fixed.
I can agree with your point, though I believe Airbus would prefer that these sort of "misunderstandings" by third parties didn't impact on its bottom line.
mm43 is offline  
Old 5th Apr 2012, 02:41
  #1253 (permalink)  
 
Join Date: Aug 2011
Location: Near LHR
Age: 56
Posts: 37
Likes: 0
Received 0 Likes on 0 Posts
@mm43,

Originally Posted by mm43
Well, they did. Or at least the PNF announced the loss of speeds and later the change to ALT Law.
I agree sir that the PNF announced those 2 points, but as we see in the CVR transcript, no-one mentioned (i.e. vocalised) the UAS process (memory items - decide whether needed or not, then QRH). If we accept (as I do), that there will be no relevant words omitted from the transcript we've seen (e.g. I don't need to read any "last words" from the crew, if they said things to loved ones etc., so their omission wouldn't surprise me), then either they (especially the PF):

a) did truly recognise the UAS situation, didn't vocalise that recognition, and forgot that there was a procedure to follow (IMHO unlikely);

or

b) did not truly recognise the UAS situation for being that, and (this is speculation by me) treated it as some kind of unknown instrument / system failure, which they then got (terminally) bogged-down in trying to understand - which was not helped when instruments responded in unexpected ways when stalled, even though they were not faulty (e.g. low IAS due to high AoA affecting the pitot probes, leading to intermittent stall warning etc).

On the evidence I've read so far (in all the BEA reports and these threads), I vote for (b). This adds me to the list of other readers who believe that a explicit "You have a UAS condition! Follow the UAS procedure!" warning, may have helped, instead of the procedures assuming that the UAS condition would be correctly recognised by every crew, every time.

As you have pointed out, adding such an explicit UAS warning could then lead to an attempt at automation keeping the "status quo" when that happens, although I see that as a step of development beyond that of just giving a warning.

I'm sure some of the professional pilots will say that a trained ATPL pilot should not need that kind of "spoon-feeding", and I don't disagree. However for various reasons too long to explain right now, experience in my own (non-aviation) field makes me think this sort of explicit warning message should be seriously considered (not that Airbus or Boeing or any other manufacturers care what I think ).

Originally Posted by mm43
I do find it "a bit of a stretch" to blame the systems/human interface when many similar situations have been successfully handled by other crews.
I respectfully disagree that "similar situations have been successfully handled by other crews" (depending on the subjective interpretation of "similar" and "successfully" of course ) as I explain here:
http://www.pprune.org/tech-log/46062...ml#post6673738
http://www.pprune.org/tech-log/46062...ml#post6747450
http://www.pprune.org/tech-log/46839...ml#post6804546

The BEA (in interim report 2, page 51 onwards in the English edition) discuss those UAS events with enough details to examine (13 to be exact). To quote myself from previously:

"Sure, none of the other flights crashed, but several were not handled according to the QRH, not all of them went into Alt* law meaning that subsequent actions cannot sensibly be compared to AF447"

The BEA explicitly mention the lack of other crews following the correct memory items, among other things. Therefore this looks much less like an AF447-only mistake IMHO, and makes the system/ human interface again an area where there should be focus, given that UAS events will continue to occur with current pitot technology.
Diagnostic is offline  
Old 5th Apr 2012, 02:44
  #1254 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
Man machine interface (UAS processing)

Hi,

mm43:

Let's go back to AF447 Thread No.4 Post #616 - which was directed at you.
I agree fully with you. After 7+ months "doing some R&D on that, i became progressively convinced the Man machine interface (very probably) played an important role on this case.

The reason i specified "just indications" (instead of "actions") was twofold;

1) Allow a smooth learning curve (for all "players"). Is stepwise.

2) Doesn't represent "automation". Just another "AID". An extra resource.

Why not a COMBO: (UAS & AOA). Two major "components" here.

I believe Airbus would prefer that these sort of "misunderstandings"


PS

Certainly your post #616 was processed (in batch ) all this months. thank you for remembering. I wouldn't.
RR_NDB is offline  
Old 5th Apr 2012, 03:53
  #1255 (permalink)  
 
Join Date: Aug 2011
Location: Near LHR
Age: 56
Posts: 37
Likes: 0
Received 0 Likes on 0 Posts
@RR_NDB,

Hi,

I know your post wasn't addressed to me, but I just wanted to say that I agree with all your points above

I wonder why this explicit UAS warning isn't being done already. Is it that plane manufacturers are assuming correct recognition of the UAS situation every time? (A dangerous assumption, IMHO, with confirmation of that danger provided by the BEA report that I mentioned.) Or is there something which we're not considering, that is preventing them providing this explicit warning?

Last edited by Diagnostic; 5th Apr 2012 at 03:55. Reason: Clarity
Diagnostic is offline  
Old 5th Apr 2012, 04:11
  #1256 (permalink)  
 
Join Date: Aug 2011
Location: Grassy Valley
Posts: 2,123
Likes: 0
Received 0 Likes on 0 Posts
A sore spot since the beginning. Rapid understanding is critical, there is no call for delay, imho. Yes, resources. "WARNING: speeds suspect, recall Pitch and Power for conditions and config. No delay."

There was a great pressure, to which BEA succumbed, in releasing a memorandum which Airbus scanned and re-released.

"There are no NEW mechanical issues with our a/c, per BEA"
They needed that for the airshow.

Diagnostic, consider what it would mean in the middle of this investigation, for Airbus to reconfigure their cockpit systems to include UAS/WARN.

Everyone knows the problem, but so long as Airbus do not address it with upgrades, it does not "exist".

To react is to confess. In the case of Air France, they had a reason and an excuse to r/r the Pitot Probes. The PILOTS would not fly until they were changed.

It would be impossible for pilots to gather to protest a fleetwide problem caused by the aircraft itself........and not just a subcontractor eg Pitots, or Duff "pipe"

No amount of soothing words can alter the fact that UAS remains a problem for the platform, not just the pilots.
Lyman is offline  
Old 5th Apr 2012, 04:46
  #1257 (permalink)  
 
Join Date: Jun 2009
Location: NNW of Antipodes
Age: 80
Posts: 1,330
Likes: 0
Received 0 Likes on 0 Posts
@Diagnostic
... adding such an explicit UAS warning could then lead to an attempt at automation keeping the "status quo" when that happens, although I see that as a step of development beyond that of just giving a warning.
Thanks for your well thought-out post.

That "step beyond" was an attempt to stop the initial "misunderstanding" and/or "startle factor" that has previously been discussed. It may be viewed as problematic to an outcome, but we are currently dealing with an outcome that became a "problem".
mm43 is offline  
Old 5th Apr 2012, 06:25
  #1258 (permalink)  
 
Join Date: Aug 2005
Location: fl
Posts: 2,561
Likes: 0
Received 0 Likes on 0 Posts
Since hand flying skills are not required any more maybe the autopilot should just go to attitude hold and autothrottles freeze in their cruise mode. No more stalls at 35,000 and training doesn't have to be changed. New guys with 350 hrs would love it.
bubbers44 is offline  
Old 5th Apr 2012, 06:52
  #1259 (permalink)  
 
Join Date: Jul 2009
Location: France - mostly
Age: 83
Posts: 1,688
Likes: 0
Received 0 Likes on 0 Posts
Not all UAS scenarios are as obvious as AF447. The high altitude / ice particle scenario is a relatively recent addition to the family.

Last edited by HazelNuts39; 5th Apr 2012 at 07:32.
HazelNuts39 is offline  
Old 5th Apr 2012, 09:01
  #1260 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes on 0 Posts
"wonder why this explicit UAS warning isn't being done already."

Hi,

Diagnostic:

Or is there something which we're not considering, that is preventing them providing this explicit warning?


Important question. Some possibilities. Will comment ASAP.
RR_NDB is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell or Share My Personal Information

Copyright © 2023 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.