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

AF 447 Search to resume (part2)

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

AF 447 Search to resume (part2)

Old 24th May 2011, 15:47
  #2261 (permalink)  
 
Join Date: May 2008
Location: Belgium
Posts: 26
It really takes me back all this discussion of IT and SE. I worked on the "Green" compiler for a short while and it was very clear when DoD selected Green as the official Ada language, everyone from Jean Ichbiah down accepted that Ada needed a lower level tasking mechanism than that provided by Green. It did not happen until 95.

deSitter might realise that the A320 flies with 60 000 lines of code, something that would not even get a "Hello World" working in Windoze. Small, tight, well tested packages that do a specific task without any excess bloat are the tools that are needed to build ultra-reliable systems. While many could argue with the specification for Airbus' FBW system, few could argue that it does anything other than what the box says (that is good software engineering)
badgerh is offline  
Old 24th May 2011, 16:24
  #2262 (permalink)  
 
Join Date: Jul 2009
Location: France - mostly
Age: 81
Posts: 1,689
Originally Posted by sirgawain123
I recall reading in the forum (...) that A330 SOP for unreliable air speed called for CT and 5degrees up nose.
The 'Maneuvre d'urgence' contains a note that refers to the follow-up procedure 'Vol avec IAS douteuse/ADR Check' that is reproduced in BEA's Interim Report #1, Appendix 9. There you'll find for FL250 - 370, W>190t: 3.5/90%N1.

PJ2 has explained that a pilot would not be expected to go to 5 at FL350 and M.82.
HazelNuts39 is offline  
Old 24th May 2011, 16:41
  #2263 (permalink)  
Thread Starter
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,250
Bad air data? we've been there, done that...

Salute!

The B-2 crash was another topic that got my attention like the AF447 one. Guess I am a FBW freak. STOP ME before I read/post/mull/wonder again!!!!

Most of the links do not work now, but someone might find the accident report referenced in this URL from the F-16.net.

http://www.f-16.net/f-16_forum_viewtopic-t-10556.html

Worth a read, as one of the designers chimes in with some good poop.

Some of the pilot's comments are very revealing., as in "...plane was doing exactly what it was supposed to be doing..." I have heard that this past week or so someplace.
gums is online now  
Old 24th May 2011, 17:15
  #2264 (permalink)  
 
Join Date: Aug 2009
Location: Germany
Age: 64
Posts: 1,809
Cool

Hi,

The 'Maneuvre d'urgence' contains a note that refers to the follow-up procedure 'Vol avec IAS douteuse/ADR Check' that is reproduced in BEA's Interim Report #1, Appendix 9. There you'll find for FL250 - 370, W>190t: 3.5/90%N1.

PJ2 has explained that a pilot would not be expected to go to 5 at FL350 and M.82.


jcjeant is offline  
Old 24th May 2011, 17:30
  #2265 (permalink)  
 
Join Date: Jun 2010
Location: On the ground too often
Age: 45
Posts: 129
Why bother? Back to pilot training. We can also do that. We SHOULD be trained to do it (some are).
But what are the limits of what a pilot can do? Set the pitch and adjust the power, OK. Is your average (or even above average) pilot going to be able to factor in issues such as aircraft weight, CofG, bleed and generator load to name a few and select the right values? Will the pilot have any sort of spatial awareness of what is going on with the aircraft? There was a case when a jet took off with the static ports taped up - somehow setting power/pitch didn't ensure a good outcome in that case.

Computers can tackle problems such as these. There are millions of flight hours worth of data available covering thousands of parameters of an aircraft such as the A330. I can imagine that by processing this data it would be possible to develop a probabilistic model of the actual dynamics of the aircraft. Computer processing power is available to analyse the actual flight parameters against such a reference database real-time and (a) identify any discrepancies, (b) extrapolate to a high degree of certainty any missing parameters. The real challenge will be to get such solutions certified.

The pitot-static system relies on a duplication of the same devices to achieve redundancy. This approach was far too simplistic for the computers - not only are they multiplied - but they are in fact totally different computers. If we expose 3 identical probes mounted more or less on the same place to the same conditions we are far more likely to encounter multiple failures then if we have different devices. Why were not the same criteria as applied to the fbw computers applied to the air-data system?
Golf-Sierra is offline  
Old 24th May 2011, 17:47
  #2266 (permalink)  
 
Join Date: Jan 2005
Location: France
Posts: 2,316
Originally Posted by syseng68k View Post
As for rtos, my (avionics) experience in that area is not current, but iirc,
there are at least two rtos's that are fully qualified to DO178 level, so it's
quite likely that they are being used.
My avionics experience is not current either.....
Wot's an 'rto'? (other than a rejected take-off)?

thanks for your post on state machines.... saved it. We never used that 'notion', but then I'm an analog dinosaur.... Was a good time actually, until the P asteroid hit.
ChristiaanJ is offline  
Old 24th May 2011, 17:48
  #2267 (permalink)  
 
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 876
Redundancy, Fault Tolerance and Graceful Degradation

Hi,

Why were not the same criteria as applied to the fbw computers applied to the air-data system?
Simply, because (it seems) there are no solutions yet available (sensors) to have the (could provide) required redundancy.

In an earlier post you could find patents filed by Airbus SAS on sensors (laser based).

We heard about another solution being prepared for short time UAS. A Software based "hysteresis like" band-aid.

Last edited by Jetdriver; 25th May 2011 at 03:59.
RR_NDB is offline  
Old 24th May 2011, 17:52
  #2268 (permalink)  
 
Join Date: Jun 2009
Location: Toronto
Age: 76
Posts: 117
ChristiaanJ; RTOS= real time operating system K
kilomikedelta is offline  
Old 24th May 2011, 17:58
  #2269 (permalink)  
 
Join Date: May 2008
Location: USA
Posts: 44
Common mode errors

Forgive me if this has already been covered - I have tried to keep up on the thread, but the posting has been very prolific.

I work with sensor driven control systems and have noted that when exposed to slightly abnormal conditions, sensors using the same design initially tend to degrade toward failure in a very similar manner. In redundant sensor systems this can result in a common mode error which may be difficult or impossible to detect. It is only when abnormal conditions become excessive and the sensors become erratic that they provide enough differential error to be detected.

Since the ADR's depend on differential errors to detect potential sensor faults, it seems to me that if all pitot tubes initially began to degrade at about the same rate (perhaps due to water buildup at the drains), such a common mode degradation would not be detected initially and would fool the system into believing that the A/C was traveling faster than it really was. The AP would respond accordingly and slow the A/C down. Then, as water/ice build up continued, the differences in readings would have exceeded the error detection threshold for the system, causing the AP, etc to disconnect. But when that finally happened, the A/C would be going slower and closer to the stall speed than the computed flight envelope would expect.

Could a scenario like this have robbed the crew of precious time needed to make corrections? Are there parameters recorded on the FDR that could be used to determine retroactively that something like this occurred?
areobat is offline  
Old 24th May 2011, 18:05
  #2270 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
gums, #2226

back to my cave, now, as the press is now focusing upon "deep stall" and
such. And my pea-brained background causes me to wonder how a system
that works as advertised can allow ( maybe even cause) the confused
aircrew to wind up in a loss of control accident. I thought all those
control laws and sub-laws, and sub-sub-laws would help just a bit.
Something that's been bothering me for some time as well. I'm really not
concerned what language is used to program the system, or any other software
related issue, as the field is by and large, well proven. What does bother
me is more of a human factors issue. If the whole idea of automation is
to reduce workload and do something predictable under all circumstances,
how is it that the system can max out the crew by too many or ambiguous
warning messages to the point that they have no idea of the state of
the aircraft ?. Speculation ?. Well perhaps, but how did a perfectly
servicable aircraft with a highly competent crew just fall out of the
sky ?.

The other point, again, is the probes. It cannot be beyond the wit of man
to design a probe that doesn't overheat on the ground, yet has enough
capability to melt ice under worse case conditions. Any engineer looking
at this cold would put in one or more temp sensors such as platinum film or
even a simple thermostat, perhaps a 3 term controller and big fat heating
element. No on/off switches or modes needed either, further reducing
workload and possibility of human error.

All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft.

Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
syseng68k is offline  
Old 24th May 2011, 18:24
  #2271 (permalink)  
 
Join Date: Jul 2009
Location: Planet Earth
Posts: 91
When everything is said and done, if the root cause points beyond a doubt to crew action or lack thereof, the approach taken will be, "if it ain't broken, don't fix it". The most recent AIT from Airbus already points in that direction. Given the complexity of systems involved, on the whole, it may the wiser approach. Improvements will come when they are ready. Until then just fly the airplane.

Not saying its good or bad, just the way it is.
CogSim is offline  
Old 24th May 2011, 19:03
  #2272 (permalink)  
 
Join Date: Aug 2009
Location: Texas
Age: 61
Posts: 5,617
All 3 probes are currently of similar design and would thus be expected to fail in a similar way worst case, representing an effective single point of failure. Avoidance of single point failure is the first line of defense in any safety critical work, especially relevant in this case when one considers how important the probe info is for safe operation of the aircraft.

Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
I think this point is worth repeating, in terms of what a redundant system is, and what it isn't. Unless there is something different about each probe, they represent a potential (in terms of being in identical environment) single point of failure in three part harmony. Given the criticality of the probess function, how different can they be and still provide the input that permits airspeed to be used by both the flight crew and the computers in the flight control system?

I'll ask the Airbus drivers a question that has come up before: would an AoA gage (which is apparently not common in any airliner design, and for most regimes of flight a supplemental scan item) be a useful addition to the flying display?

AoA is already detected and provided to the system for protections and laws. Is there a good reason not to feed AoA to the flight crew? Adding "one more thing" to the display or HUD or instrument panel isn't to be done lightly, given ergonomics and scan development.

Or, is the general consensus something like this:

if you are flying, your charge is to stay ahead of the aircraft far enough to avoid getting into marginal AoA conditions? From the comments in this, and a host of other threads regarding varying mishaps, I get the impression that adding an AoA gage isn't perceived as the way ahead.

*shields up*

Last edited by Lonewolf_50; 24th May 2011 at 19:14.
Lonewolf_50 is offline  
Old 24th May 2011, 19:07
  #2273 (permalink)  
bearfoil
Guest
 
Posts: n/a
syseng68k

hello chris. This was a long train on BA038. Redundancy, Reliability, and Reconciliation.

"...All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft...."

************************************************************ *****

Aviation IS "single point". Flying an aircraft is not overly complicated, yet we are discussing complex ways to approach simple things. Of course the solution is complex, it proposes to be so. One Pitot is all one needs. If it plugs, we heat it. If it has a wasp nest in it, my bad. If it has tape over the hole, also my bad, though I did not install the tape. To fix to an a/c three of the same type of pitot is not only redundancy, it is the raison d'etre for three separate flight computers. Collecting, reconciling and determining are slick computer work, but something has to re-simplify to input the single command that keeps the a/c flying. Of course since flight is dynamic, it is composed of sensing trends, and arresting bad behaviour. It is usually no more difficult than juggling one ball. But Nature being who she is, sometimes it requires the panache to juggle two balls. Then Three, etc.

When navigating in a complex system, it takes time, man or machine.
One can have simple, or one can have complex, but one cannot apparently have both. At least not quickly, also apparently. Something about 447's situation caused the autopilot to quit. No big, hand fly. One does not understand why it is called for to "troubleshoot" the thing that caused the issue. Hand fly. She troubleshot herself, hence ACARS, which have nothing to do with aviating.

It really is that simple. If any argument can be proven that these gents got confused, I'll consider it. If they did, who paid them to do it? Who "trained" them to ?

It is counterintuitive. Laugh if you like, intuition in a professional is money in the bank.

It was NOT the pitots. Something got in between a patent and ho hum gotcha and the pilots. Who let the dogs out?
 
Old 24th May 2011, 19:10
  #2274 (permalink)  
PJ2
 
Join Date: Mar 2003
Location: BC
Age: 73
Posts: 2,452
syseng68k;
The other point, again, is the probes.

. . . .

Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...
Respectfully, I disagree.

The point in this accident is NOT the probes.

A loss of airspeed information is not cause for Loss of Control.

A series of ECAM messages and chimes, (expected, with such loss of data), is not a cause for LOC.

A loss of attitude information IS cause for LOC but as far as we know, that did not occur here.

In previous pitot incidents, the exact same ECAM messages occurred. The crews continued to fly and within a few moments/minutes indications returned to normal.

We see such "ECAM streams" of multiple faults/failures in the simulator, during practised dual hydraulic failures for example.

As aircraft systems degrade, they engage in their monitoring/BITE behaviours and, according to their individual timings in sending data to the FWC which in turn are distributed to the CMC, DMUs etc, there will be a cascade of re-prioritizing messages until things settle down. I have seen such streams, many times in the simulator, once, during a serious hydraulic emergency in the air. In such circumstances, one must slow things down, wait and respond deliberately, with "pace", but not hurry.

I have previously observed that the UAS QRH drill memorized items to set the pitch at 15, 10, or 5deg and to set the power to the TOGA detent or in the last two cases, to the CLB detent, are intended for immediate "safe" responses right after takeoff, (catering to the Birgenair and Aeroperu accidents). The qualifying condition is at the end of the memorized items, which states that once the aircraft is above the MSA it should be leveled off for "troubleshooting". Such troubleshooting means getting out the QRH and reading-doing the checklist items. The first items involve appropriate pitch and power settings for weights and altitudes.

Ergo, none of the memorized items in the UAS QRH checklist applied here.

The first response would be to do nothing and touch nothing while the QRH was brought out.

The airplane was stable before the event, and, short of significant disturbance either through heavy turbulence, (thunderstorm entry) or intentional alteration of pitch or, (to a lesser extent) power, the aircraft should remain in a stable state for a reasonable period of time while the P1 hand-flies the aircraft and calls for the UAS drill, and the P2 brings out the QRH.

Contrary to some of the ill-informed statements made here and in the media by those who have never flown, or who have never flown the A330, this airplane hand-flies beautifully at all flight levels and is not a "hand-full", unless, like any airplane, it is near/at the boundaries of flight it was designed for and the crew trained for.

The crew could respond to all the messages, once the ECAM had settled down...it doesn't take long, but the professional airline pilots here I'm sure will say that slowing things down a tad (but not dragging it out), and gathering thoughts before launching, is a key to successfull handling of very complex and serious events. One must get one's surprise and rush of adrenaline under control first, then, as a crew, begin.

Even DP Davies advises "lighting up a pipe", (so to speak!), before rushing into drills. He quite markedly states that the only drill which must be done swiftly, accurately, with discipline and deliberation is the rejected takeoff.

However this unfolds on Friday and in the subsequent months, we must bear in mind first, the families whose loved ones died in this accident and set aside any desire to be "first" or "right" with this or that solution to this accident. The presentation of the actual data will not resolve all questions and, as many have already observed, "the crew" are a part of a very complex, dynamic system in which human factors will inevitably play a part.
PJ2 is offline  
Old 24th May 2011, 19:18
  #2275 (permalink)  
 
Join Date: Jul 2009
Location: USA
Posts: 102
What information should we expect from crash investigators later this week? I assume they will not be drawing any conclusions on the likely causes at this juncture; right?
robertbartsch is offline  
Old 24th May 2011, 19:24
  #2276 (permalink)  
 
Join Date: Feb 2008
Location: In the Old Folks' Home
Posts: 401
AoA Works

Snowfalcon2
Some sort of airspeed sensor (as opposed to groundspeed, as provided by GPS and inertial) therefore seems fairly indispensable, at least for critical flight regimes at high altitudes and approach/landing phases where the local wind needs to be considered.
Angle of Attack works just great at approach and landing speeds. AoA is the primary speed sensor for carrier landings. At cruise speeds, it's not sufficiently sensitive.
Smilin_Ed is offline  
Old 24th May 2011, 19:29
  #2277 (permalink)  
 
Join Date: Jul 2009
Location: spain
Posts: 7
PJ, respectfully, I understand your explanations, acknowledge your type experience, and consider a nose up command as inappropiate at cruise speed /height for an unreliable air speed event , but No single sentence in the AF card posted here restricts its use to a below_MSA or take_off condition!

And pilots DO Train to follow the card or SOP, not our instinct (provided there is a card /SOP )

Last edited by sirgawain123; 24th May 2011 at 20:09.
sirgawain123 is offline  
Old 24th May 2011, 19:36
  #2278 (permalink)  
 
Join Date: Aug 2009
Location: Texas
Age: 61
Posts: 5,617
PJ:

I will defer to your deeper understanding of this flight problem set.

I will offer, as a point related to training, that since airspeed is an imbedded element of an instrument scan, and a critical performance measure in any instrument scan, the unexpected lack of it disrupts the scan. The "don't pay attention to the airpspeed" scan is a non-standard scan, and (IMO, I am biased due to some years of training pilots) should be practiced so that the PF is flying and crosschecking while deliberately ignoring a fundamental scan item ... while the PNF is doing as you illustrate, and handling the trouble shooting.

EDIT: I don't think I need to tell any experienced pilots this, but for those who aren't -- if you don't practice and use your instrument scan habitually, it tends to start off a touch slow when you begin to use it at need. Also, if you don't practice your degraded mode scan, your scan will tend to be slow (initially) when you need to implement that scan pattern. How much time did this crew have to get into that rhythm? Don't know.

This I have seen first hand, not only in my own flying, but also in hundreds of other pilots, when I gave them instrument checks or was being the SOB at the console for a simulator training event intended to "run them through the wringer." This observation applies to both inexperienced and experienced pilots. How quickly the scan, or degraded mode scan, was established, or re-established, varied with the pilot.

I grant you that crews in some other events where AS became unreliable (under other conditions and variables) were able to manage that transition via one means or another. Based on the points you raise, unreliable airspeed wasn't a new failure mode experienced for the first time by AF 447's crew. What it may have been was that rare failure mode, experienced with some novel other conditions, and most likely for the first time by that crew. (This consideration is related to the question I asked to studi about what Conventional Wisdom is and was among the A330 pilot community in re his described escape maneuver ...)

Friday will hopefully be enlightening.
Lonewolf_50 is offline  
Old 24th May 2011, 19:38
  #2279 (permalink)  
 
Join Date: Jun 2009
Location: Paris
Posts: 691
Hi areobat,
Originally Posted by areobat
Are there parameters recorded on the FDR that could be used to determine retroactively that something like this occurred?
Certainly. This is the main reason why the BEA should be given all the time necessary to make a complete correlation between all the dataset recorded as, of course, some data could have been erroneously displayed (and recorded). Because all the flight parameters are related to each others, it would be possible to find, beyond any doubt, if anything was wrong with the airspeed before the system started to reject it.

In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures. This is also the main reason why a clean probe system would very very unlikely be clogged (in flight) at exactly the same rate and at exactly the same time.

Last edited by takata; 24th May 2011 at 20:10.
takata is offline  
Old 24th May 2011, 19:50
  #2280 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
ChristiaanJ, #2261:

PS : thanks for your post on state machines.... saved it. We never used
that 'notion', but then I'm an analog dinosaur.... Was a good time actually,
until the P asteroid hit.
Thanks for that, and for the record, am a bit of a dinosaur here as well :-).
I originally came into embedded work from a hardware, rather than comp sci
background and still do some analog work from time to time. It never
ceases to amaze me what was achieved in the past with mechanical gyros,
servos, synchros and discreet components. Often straddling many disciplines,
the designers of old were masters of their art...
syseng68k is offline  

Thread Tools
Search this Thread

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

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