Air France Flt 447's Downing (Part one of two)  

==>PART TWO

   
 The QF72 incident is likely to have been similarly ADIRU sensor-related IMHO. The aircraft was equipped with a Northrop Grumman made ADIRS. However the scenario was likely to have been different (only one ADIRU spat its dummy -see the box). The relevance of spikes in the AoA data is apparent.
QF72

...immediately prior to the autopilot disconnect, one of the air data inertial reference units (ADIRUs) started providing erroneous data (spikes) on many parameters to other aircraft systems. The other two ADIRUs continued to function correctly. Secondly, some of the spikes in angle-of-attack data were not filtered by the flight control computers, and the computers subsequently commanded the pitch-down movements.

I believe Airbus advocated a return to the prior software version - perhaps merely as an initial gut reaction, but possibly because the Northrop boxes had recently had an extensive patch applied.
 
If you were to run this AF447 theory [below] past Airbus, I think you'd need to be prepared to give mouth-to-mouth. They'd choke on it. It's precisely what they don't want to hear.
 
You say: "...there is a pattern of alarming incidents involving ADIRU failures on A330 aircraft which cannot be explained by faulty pitots or mere pilot error (although that may have played its part)." I beg to disagree, and the explanation why is below. You'll probably need to read it through twice (at least) to get the simple thrust of its underlying premise.
 
AMA president Richard Hayden, said, "We at AMA are excited to offer this important capability to the entire aviation community. This capability is not only valuable in improving responses to in-flight issues, but in the rare case where an aircraft is lost, this data stream can provide immediate insight into the exact flight path, location, and the possible cause of the accident."
Following the June 1, 2009 Air France ("AF 447") tragedy, whose FDR's are yet to be recovered, calls were made by industry and airlines to develop a "live black box" capable of streaming critical flight information in real time ......which could then provide insight into in-flight incidents and aid in rescue missions and accident reconstructions in the event that an aircraft's black box can not be recovered. Although AF 447 was well equipped with satellite communication technology and ACARS, not having the ability to automatically stream position and flight data in real-time meant that the messages were limited in available diagnostic information.
The afirs system solves this dilemma through a combination of normal transmissions through short burst data, and emergency streaming of critical position and FDR information. The use of Iridium means that there are no coverage gaps in the afirs data streaming anywhere on the globe. This development is a significant contribution to aircraft safety and operational efficiency, especially for aircraft flying outside of radar and terrestrial-based communication coverage areas.

Because of not finding the recorders it's unlikely that the cause of AF447's downing will ever be much more than informed surmise based upon ample precedent. More newsworthy in my view is the need for something like my Iridian/Roadshow invention of 1998 ( http://tinyurl.com/kv2owv ) - so that such invaluable pre-crash data is instantly available to investigators. It's noteworthy that that giant Canadian Company AeroMechanical Services, who adopted my idea and marketed it, recently capitalized upon the failure to recover AF447's black boxes by upgrading their offering  (on 11 Aug 09 - see this link at http://tinyurl.com/nwqdmr ) and the adjacent box. To date, it's only in service in a number of VVIP jets.

The ADIRS gets a good coverage at this link  - but I'll explain it more simply below (if I can). It does all seem to come back to the characteristics of the ADIRS system - both hardware and software - as having been the origins of that accident and many similar prior incidents. The existence of precedents should never surprise us. It's all about the failings of automation's redundancy.

(see my 2005 ASW article: Thrice Almighty - The Virtues of Triple Redundancy  @   link

To explain...

 
Failures and directives
The ADIRU is a necessary software-driven technical interface between the FBW computers and the raw data of the environmental sensors. It is rather epicentric because of its tentacular effect on downstream systems and it can be vulnerable to "the failure of its feeds". But that doesn't mean that all such failures would have a common cause or be strictly hardware, firmware, input sensor or software related. Design induced failure effects can extend way beyond the "three mile limit" - as I've attempted to point out below. As the name implies, the ADIRU soaks up "air data"...... and integrates it with an inertial data-feed (from ring laser gyro-stabilized "platforms") to produce:
 
a. attitude and flight-path vector (quite essential for flight control and "upset avoidance" - aka maintaining the aircraft within operating limits (g, CAS, Mach crit etc) while in instrument conditions - especially at night or in turbulence)
b. position at any given moment
c. rate of change of position (groundspeed or G/S) - being position integrated with time -
d. directionality (track across the ground) - whether magnetically referenced or true or grid
         
and from that primary resolution can be derived other necessary flight control information...which is where the air data becomes critical. What are these readouts?
 
e. barometric height (and height-change rates), heading / wind and drift angle / indicated airspeed (usually called CAS or calibrated airspeed because it's corrected for airframe and sensor specific factors) / TAS or true airspeed (because the IAS "lies" due to decreased air density with height - for instance 200kts IAS is actually 400kts TAS or 400kts G/S in still air at 40,000ft) and Mach Number (the ratio of the aircraft TAS to the local speed of sound)).
 
The Airbus blurb says:  ADIRU uses multiple redundant inertial sensors for computing attitude and  also selects a best altitude and airspeed from the pitot and static pressure sources. As a result, it provides a single set of data for both the captain and first officer, eliminating cross-channel splits and variance.  There are many sensors involved in capturing raw data - pitot heads / static ports / OAT probes / AoA vanes / accelerometers. These interact via digital/analogue converters and transducers to convert their inputs into usable digital forms that can be factored into software programs and produce information that's usable by pilots and navigational automation (i.e. avionics such as the autopilot, TAWS and GPS). The software is aware of the International Standard Atmosphere (ISA). It "knows" for instance that the hotter a vertical slice of the atmosphere is, due to seasonal changes or weather patterns, the lower the initially achievable cruise altitudes will be etc (or put another way, jet engines like cold dense air).
 
There's quite a few dimensions to that air also. It has temperature, density, pressure, relative humidity, liquid water content and hygroscopic nuclei (particularly downwind of dust-storms and volcanic eruptions). It can also itself be in motion (wind, convective vertical currents, orographic, wake turbulence, airmass subsidence). There are numerous meteorological phenomena that denies us the ability to regard air as a static element of the equation. Unless supersonic, the air passing an aircraft's sensor has already been set in relative motion by the aircraft's own bow-wave.
 
So you can appreciate that there are many dynamic factors involved (i.e. ever-changing calculations and computations) and additionally, great scope for a hardware error (avionics compartment cooling fan-motor seizure let's say),  at board-level an electronic component breakdown (e.g. overheating capacitor) or faulty sensor (blocked pitot head or static port) to mutate the input data and challenge the FBW computer's logic limits. That's where cyclic redundancy checking for software error and BITE (built-in test equipment for revealing hardware unserviceability) comes into play.  But not all sources of error will trigger a system dichotomy of "which input is correct? What divergent factor requires rejection?" "No kidding" you say, "why and how could that be"?
 
If all is according to Hoyle and the software's checks and balances endorse all the inputs  (and the dual and/or triple inputs are in agreement), then the outputs can be evaluated as being within acceptable parameters and applied to FBW, autopilots and auto-thrust, FADECs and navigational sensors.
 
It's a complex orchestration yet it normally runs on rails. To mix the metaphor slightly, what can conceivably drive that apple-cart off those rails? Because of the evaluation capabilities of the software, any unacceptable parameter can be rejected and in most cases triple redundancy can intervene to redress the situation.....usually by easily identifying, alienating and isolating duff inputs. Within given parameters, redundancy is a comparative logic process  i.e. accepting data that's in agreement with consonant simultaneous feeds and rejecting any that isn't  -  by adopting a reversionary mode.  But remember what's underlined above, i.e. "selects a best altitude and airspeed from the pitot and static pressure sources."  What occurs if there are no data differences to motivate any such "best" selection and that duff data is "cogent" (i.e. credible)? What could generate perilously wrong data that's still acceptable?
 
 Well, what if the environment itself perverts the input data? How can that be? The Thales pitot is obviously a unique design and yet has common characteristics to all other pitot heads. It faces the relative airflow, takes in impact air pressure and the static component of this pressure (i.e. the local barometric pressure) is balanced/offset against the purportedly identical static pressure that's being measured by the port and starboard static ports (side-facing, no impact pressures, simply records the outside air pressure like a barometer). And thus the all-important airspeed is derived and fed into the Air data Unit (in digital format - courtesy of the air data modules - ADM's). It's usually accurate to within a few knots. Each pitot feeds a different ADIRU.
 
The A330 will stall at around the same indicated airspeed at 40,000ft as it will at 1000ft. However the higher you go, the more you must factor in the potential hazard  of increasing Mach. The operating band up at coffin corner can be as narrow as 20 knots between the aerodynamic stall and the wild ride induced by flying slightly faster and hitting Mach Crit. That's the "never exceed" Mach number at which shock waves on the wings, empennage and fuselage start behaving erratically and changing aerodynamic and flight control responses. One of these adverse characteristics is called Mach Tuck (see link). Accelerating past the mach number known as Mach Crit, the nose drops, speed increases and that compounds the problem by the diving attitude sustaining a high mach that's still into compressibility (link). Eventually that mach number will decrease as altitude unwinds. However, before that happens, it's quite possible that flight control will be lost as the effects aren't necessarily symmetrical (think wildly rolling outcome or "flick"). So, because A330's had suffered many prior incidents of bogus speed due to flawed Thales pitots, yet survived - what's a reasonable diagnosis for a different outcome - i.e. AF447's terminal upset?
 
The ACARS fault messages transmitted in the last 4 minutes weren't all related to a simple bogus speed indication, but more likely indicative of what happened as a result of it, i.e. a loss of control.... possibly leading to a steep nose-down overstress structural failure, a partial breakup, or a steeply pitched nose-up stall leading to a flat spin or a deep stall..... and if the latter, perhaps because of aft fuel and a non-standard pitch-trim. But why wouldn't the pilots have seen it coming?
One well documented high altitude stall and unrecoverable flat spin airliner accident was this one:

ASN Aircraft accident Tupolev 154M RA-85185 Donetsk

Pulkovo Tupolev 154M

The accident circumstances, weather was similar to AF447
Were they taken suddenly by surprise? Was icing or turbulence a factor? Or was it just because they unexpectedly hit that crumbly brick wall of Mach Crit? That's what the investigation must determine now, and without the two recorders.
 
It's likely that the port and starboard pitot heads had similar environmental "experiences" in the weather enroute (those pitots being mirror images of each other and the 3rd sensor being central and in a slightly different airflow pattern). Pitots 1 & 2 may have clogged - simultaneously becoming filled by CirroStratus ice crystals (an admitted Achilles Heel of that model of Thales pitot head). If you pervert two sources simultaneously and the third is the "odd man out" (yet accurate) it's likely that the odd man out will be rejected and the input data from the two "duds" accepted as gospel. "That's life" in that funky theoretical world of triplicated system redundancy. The system sees no disparity between the two "goodies" and is "trained" to assume that therefore they must be telling the gospel truth - and so the third (although correct)  is perceived to be "the bummer". But what if all three pitots were suffering from the same icing clog (just as likely).... what would be the redundancy scenario there?
 
Exceeding the Envelope but without any Indications of doing that ...
In enroute mode, with the captain in crew rest, the two copilots would have a low level of situational awareness (i.e. cruise ennui) and would probably not detect that the autothrust was increasing incrementally and insidiously to offset a "system-perceived" speed (and Mach) loss trend. The nett result is an A330 moving through the air ostensibly at its scheduled speed but, in actuality, a lot faster than it should be - maybe 25 to 30 knots fast and quickly approaching a borderline (i.e. the upper operating envelope boundary-line) Mach for coffin corner. Available cues? A slightly lower nose-down attitude, a marginally lower Angle of Attack, but with the displayed speed and Mach tapes on both the pilots' screens (PFD's) staying steady, yet both Engine N1's spooled up a fraction - as the autothrust endeavours to maintain the scheduled speed.  Overall gradual and unnoticeable. The autotrim would be very very slowly winding the trimmable horizontal stabilizer nose-down. It all happens so gradually because the ice is building slowly inside the pitot head's intakeBut why even slowly? Isn't there a pitot heat operating to stop icing?
 
The pitot heat can generate (say) 1300x calories/minute heat but the nett heat loss due to the "already frozen" nature of the steady, continuously impacting ice crystals in a layer of CirroStratus cloud might be 1500x (or greater). Respect the uniqueness of flying in layered sheet cloud for lengthy periods. It's completely different to being "in and out" of convective cloud within which there may be relatively short duration encounters with moisture resulting in rapid accumulations of heavy ice (or momentary hail). The nett overpowering result at the pitot heads, over time, is a gradual accumulation of ice in each pitot head. It's all about exposure time It's not due to a prior blockage, just due to the design and the thermal give-and-take - and that's why all three pitots' heating provisions can gradually become identically overpowered and blocked, all at the same non-alarming rate of ice-crystal feed. The stagnating pressure that normally generates the airspeed feed to each ADIRU will reduce linearly and generate a consequent progressive autothrust boost to recover that speed (just as it would if there was to be a genuine speed loss due to the added drag of airframe ice). The process possibly takes 30 minutes or more. Because it happens so gradually, no-one notices the imbalance (thrust too high, nose slightly low, trimmed nose-down). The throttles (aka thrust levers) don't move in the Airbus (like they would in a Boeing). They have detented "settings".  The ADIRS is geared to identify and reject systematic flaws - however it is easily duped by protracted and unique skewing environmental factors.  But what could happen to precipitate the terminal upset into a loss of control ?
 
It would be the autopilot trying to contend with the data conflict and the sudden onset of Mach Crit and disconnecting due to the high aerodynamic out-of-trim loads it's holding. The earlier ACARS transmission recorded that development. Imagine a sudden autorotative roll and the nose dropping and the pilot wrongly assuming a stall/spin, using aileron and fwd stick and adding thrust.  Recollect that he's just not seeing a high airspeed or Mach Number ..... so he could be forgiven for assuming a slow-speed stall and taking the wrong action. It's similar (but opposite) to the Buffalo crash of that Dash 8 recently. Suddenly that Dash8 aircraft stalled and the pilot instinctively took go-round action - which involves raising the nose (but if he'd recognized it as a stall, then of course he should have lowered it).

The reason for the AF447 autopilot disconnect is explained in depth in part two . Why wouldn't this have happened to the numerous earlier incident airplanes? Well there's different thicknesses of Cs cloud and different exposure times. As in most accidents, the adverse factors often "stack" to ultimately generate a catastrophe. The happy outcomes for the earlier incidents tended to generate a false sense of security.

 

Pilot handling skills under threat, says Airbus - PPRuNe Forums

20 posts - 13 authors - Last post: 6 days ago
AA09: Pilot handling skills under threat, says Airbus. ... Such skills as manual flying are often neglected. My personal philosophy is that ...
www.pprune.org/.../388573-pilot-handling-skills-under-threat-says-airbus.html

 

It's the surprise of the suddenly unexpected dynamism that can induce error. Once AF447 began rolling and pitching nose down into the underlying thick cloud and turbulence, further fatal error lurked in any misstep by the pilot in recovering. Just like the Flash Airlines 737 Captain out of Sharm-El-Sheikh, he may have eventually re-focussed upon (yet misinterpreted) the displayed unusual attitude and rolled the wrong way. Who knows? One singular wrong decision like that can write finis to survival  - because a heavy clean jet with power left set will accelerate super-fast. Idle and airbrake might have retrieved the situation, but the AF447 PFD screens initially displayed all the wrong signals for that  to be the cued response and based on all the prior instances, that's a lot more likely than just "quite probably". Indecision or disorientation can bury the nose low enough to be beyond any possible redemption - once in a degraded FBW mode (which they would have been). ... in fact, in which we now know they were
 
FBW controls may be able to stop a pilot from selecting unusual or excessive attitudes however, particularly once degraded automatically by system discrepancies into Alternate Law, at altitude they are quite a handful to even fly straight and level. Recovery from an unusual attitude at high altitude in Alternate Law? "Forget it, ain't gonna happen" seems to be the consensus.
 
So we arrive back at the common denominator of that model of Thales pitot heads (see http://tinyurl.com/p2lfwg - link) and their susceptibility for accumulating ice crystals. I've heard a theory that their tendency to clog up during flight in CS cloud (i.e.  when continually impacted by dense ice-crystals) is related to where the drain-hole is located (just before, at? or just after? the right-angle bend in the pitot). Supposedly the slush would tend to stagnate at the corner and clog that drain -even if it wasn't already clogged (by insects say). I subscribe moreso to the theory that the pitot heater's heating capability is simply overpowered by the greater heat demands of melting "already formed" ice crystals. Think of it in the same terms as the bete-noire of turbo-props (the Roselawn Indiana crash etc) - SLD icing (link) (aka freezing rain or rain-ice). It hits and sticks and overwhelms anti-ice and de-ice systems inflight, causing weight, drag and sudden asymmetric loss of control.  Fly ALONG a warm front collecting freezing rain - and you're a dead man. The same notion applies to flying along in a CirrosStratus layer with Thales pitots, except that it's much more insidious.
 
But don't let me confuse you. It wasn't airframe icing or engine icing that brought on the AF447 accident. It was likely just pitot icing, subtle, inconspicuousnon-alerted, undetected by the crew and easily conning the ADIRU's into mute acceptance - due a lack of an absolute parametric exceedance or any differential discrepancy. It was a dark and stormy night in the ITCZ - and that's all it takes for a terminal upset experience. I wouldn't blame the crew. I'd blame all those who failed to extrapolate the plausible possibilities wrought by negligently soldiering on for years with the known to be faulty Thales pitot heads.
 
If you need a suitable title, try Sic Erat In Fatis ("So it was Fated") - because it most assuredly was.

 

===> PART TWO