(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.
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.
| 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. |
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...
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?
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.
| 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 |
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 intake. But
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
|
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, inconspicuous, non-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