AF 447 Search to resume

[Hyperveloce]

Originally Posted by PJ2

The memorized portion of the UAS QRH drill does NOT require a "5deg" pitch attitude above MSA or circuit altitude. The last memorized item at the bottom of the drill states:

"When at, or above MSA or Circuit Altitude: Level off for troubleshooting."
PJ2

Hi PJ2. Being above MSA and at circuit altitude, according to the aircraft manufacturer's QRH, the AF447 crew should not have implemented the 5°/CLB item, but what should the crew have done according to the operator's UAS procedure ?

Jeff

[HazelNuts39]

Originally Posted by Hyperveloce

It is in line with HN39 computations (Mach number decreasing close to the lower boundary of the A330 flight envelope at high altitude)

Hyperveloce,
I believe you are referring to a graph that was faulty due to a dumb error in the calculation. If you still have it, please destroy it because it is complete rubbish.

EDIT::Although it is no longer relevant, after PJ2 has reminded us of the actual UAS procedure above MSA (see annex 9 of 1st interim report), the corrected version of the faulty graph is here.

Originally Posted by aguadalte

I don't see any reference to the 2:13:14 ACARS message

The 2nd interim report discusses this message on pages 37-38 under the heading "ADIRU2 (1FP2) (2h11)"

regards,
HN39

[aguadalte]

HM39,
This is what's on the last interim report:

F-GZCP - 1st June 2009
37
ADIRU2 (1FP2) (2 h 11)
ATA: 341234
Source: IR2
Identifiers: *EFCS1, IR1, IR3
Class 1, HARD
This message was generated by IR 2. For an ADIRU of this standard, it means
that the IR considered that the three ADRs were invalid, that is to say that at
least one of the three parameters was invalid (SSM status not NO) amongst
pressure altitude, barometric vertical speed and true airspeed. As soon as the
third ADR is rejected, the IR generates a message pointing to its ADIRU. If one
of the IRs considers the three ADRs as being invalid, this must also be the
case for the other IRs. It is therefore logical that, in parallel with this ADIRU 2
message generated by IR 2, an ADIRU 1 message was generated by IR 1 and
an ADIRU 3 message by IR 3, which would explain the presence of the latter
amongst the identifiers.
The fact that EFCS1 was present amongst the identifiers preceded by an
asterisk indicates that EFCS1 had at least generated one class 2 message,
perhaps followed by a class 1 message. There are too few elements available
to determine precisely what the presence of EFCS1 amongst the identifiers
means. Nevertheless, it is possible to state that it concerns a rejection of ADR
by at least two PRIMs. It has not been possible at this stage to understand why
EFCS2, the clone of EFCS1, is not an identifier.
FMGEC1 (1CA1) (2 h 13)
ATA: 228334
Source: AFS
Identifiers: -
Class 1, INTERMITTENT
This message cannot be the trace of a reset which, in particular, excludes the
possibility of a manual shutdown. This message could be the consequence of
inconsistency between the two channels in the FMGEC (COM and MON). Such
an inconsistency could be the consequence of erratic input parameter values.
In any event, the effects of such a message could only be the disengagement
of automatic systems, whose associated cockpit effect messages had already
been transmitted at 2 h 10.
The “INTERMITTENT” nature of the message means that the problem lasted for
less than 2.5 seconds.

and later on on page 40, it gives a list of the ACARS messages, where the one issued at 2:13:14 is not mentioned:

Time Fault message with cockpit effect Cockpit effect messages
0210 PROBE-PITOT 1X2 / 2X3 / 1X3 (9DA)
AUTO FLT AP OFF
AUTO FLT REAC W/S DET FAULT
F/CTL ALTN LAW
FLAG ON CAPT PFD SPD LIMIT
FLAG ON F/O PFD SPD LIMIT
AUTO FLT A/THR OFF
FLAG ON CAPT PFD FD
FLAG ON F/O PFD FD
F/CTL RUD TRV LIM FAULT
0210 FCPC2 (2CE2) /WRG:ADIRU1 BUS ADR1-2 TO
FCPC2
MAINTENANCE STATUS EFCS 2
MAINTENANCE STATUS EFCS 1
0211 ADIRU2 (1FP2) FLAG ON CAPT PFD FPV
FLAG ON F/O PFD FPV
0214
Note: this message is necessarily correlated
with a fault message, but this fault message
was not received
MAINTENANCE STATUS ADR 2
Fault messages without cockpit effect
0211 ISIS(22FN-10FC) SPEED OR MACH FUNCTION Note: the flags on the ISIS are not
captured by this CMC
0213 FMGEC1(1CA1)
Note: the only cockpit effects
potentially associated with
this message had already been
generated and could not be
generated a second time
Cockpit effect messages without fault
0210 NAV TCAS FAULT
0212 NAV ADR DISAGREE
0213 F/CTL PRIM 1 FAULT
0213 F/CTL SEC 1 FAULT
0214 ADVISORY CABIN VERTICAL SPEED

The message you are referring to was issued at 2:11 not at 2:13:14

The 2nd interim report discusses this message on pages 37-38 under the heading "ADIRU2 (1FP2) (2h11)"

not this one:

.1/FLR/FR0906010211 34123406IR2 1,EFCS1X,IR1,IR3,,,,ADIRU2
(1FP2),HARD

Am I missing something here?
Thanks,
VF

[HazelNuts39]

Originally Posted by aguadalte

The message you are referring to was issued at 2:11 not at 2:13:14

Just trying to help. The BEA reports use the ACARS timestamp (to the nearest minute) contained in the message itself: 0906010211 (2h11). It was received (the reception time given is that of the service provider’s server processor, p.46 of 1st rpt) at 2:13:14.

regards,
HN39

[aguadalte]

Thanks HN39.

[Backoffice]

A very long time ago, during the initial SAR by the Brasilians an oil slick was reported but at the time dismissed as not necessarilly from AF447.
Also comments here suggested Jet A1 would likely disperse very quickly.

I've never seen it's location plotted, any ideas ?

[JD-EE]

Machinbird, how often does the computer perform that process you speak of. They are digital computers. That means they must sample the data and make what they can with it. That's why I looked at the concept of three things with six holes total plugging up with sufficient simultaneity that it would not be noticed.

If the individual inputs are smoothed from VERY noisy data that smoothing may make the simultaneity credible to me. Without that extreme smoothing process "all at once" really bothers me.

[JD-EE]

Diversification, I was merely simplifying to suggest the process that was going on. Data comes in to the basic computational loop with some periodicity. That periodicity can put limits on what the software can detect. Other characteristics in the software, such as data smoothing, will introduce effective delays on data changes on their way into the computation loop.

I guess the simple question is "how often does the computer recalculate its airspeed estimate?"

And, I suppose if the changes were happening slow enough it could sneak up on a computer without being noticed. (That was the principle behind the GPS dithering that has been, thank God, turned off.) I had the impression that the freeze up process was fairly abrupt as the plane plowed into extreme weather phenomena.

(I'm a communications electronics B***h retread as a software bimbo, for reference.)

[GreatBear]

What If?

The first BEA Interim Report organizes the ACARS messages by "Time of Reception" by Inmarsat. In that sequence, the message AUTO FLT AP OFF is received at 02:10:10. About a minute and a half passes before the PROBE-PITOT 1X2 / 2X3 / 1X3 (9DA),HARD message is received at 02:11:49, with other serious messages (like F/CTL ALTN LAW and AUTO FLT A/THR OFF) arriving in-between. The report notes that "the order in which these messages are transmitted does not necessarily correspond to the associated sequence of events."

The second BEA Interim Report reorganizes the messages based simply on their one-minute time stamp window (see aguadalte's post http://www.pprune.org/5772547-post1602.html), and the pitot disagreement message stands out as the only "fault" message to occur in that 20:10 window.

While there seems to be a sensible agreement that blocked pitot tubes may have precipitated this upset, I'm wondering if there are other scenarios or sequences that might contain a "ring of truth." Remembering that the PROBE-PITOT message is NOT about ice or blockage but about disagreement:

From 1st report pg55 english
This message, transmitted by the FCDC2 (EFCS2), means that the FCPCs (or PRIMs) triggered one of the speed monitoring processes: they have detected a decrease of more than 30 kt in one second of the “polled” speed value. The three ADRs were considered valid by the EFCS2 at the time the monitoring was triggered, because the prior rejection of an ADR would have generated a class 2 fault message and there would therefore have been an asterisk in front of the source. In this case, the “polled” value is the median value.

By way of revisiting some of the discussion on the earlier thread, is it then possible that the aircraft was upset by really bad (severe turbulence being an inadequate description) up- down- shear forces at 02:10, stalled (easy in the coffin corner), and entered a developed and unrecoverable flat spin. In such a spin, would there not be greater than 30 kt disagreement between port and starbord pitots as the a/c rotated about its CG? Sufficient difference to trigger the PROBE-PITOT ACARS message?

It is important to note that not all aircraft are recoverable from a spin. The vast majority of large aircraft become inertially locked in a developed spin and are unrecoverable without a drag chute or other test-flight spin recovery devices (if recoverable at all)... [Link]

How would a 205t stalled A330 fall from FL350 to finally enter the water almost flat, in the line of flight? I'd like to see that animation from the Airbus aerodynamics team.

The Flight Path Vector (FLAG ON CAPT PFD FPV and FLAG ON F/O PFD FPV) at 02:11 could have been triggered by the "measured calibrated airspeed lower than 60 kt" criterion.

It's a little difficult to understand why the ACARS message transmit times have been discounted. If the pitot disagreement preceeded the Cavalry Charge (AUTO FLT AP OFF received at 02:10), why was the PROBE PITOT message buffered in the computer (and not sent) for one minute thirty-nine seconds? One would think that if the ACARS messages were intended to be grouped into unsequenced one-minute packages (as presented by the 2nd BEA Report), the system programmers would have designed a buffer and burst transmit routine... One would also think that sequencing could be inferred from the way the source code is written.

GB

[PJ2]

Jeff;

. . . but what should the crew have done according to the operator's UAS procedure

An aircrew is expected to use their collective heads and first, "do no harm". In the end, for those who fly, it's all guidance for the ultimate decision-maker, the pilot, who always answers for his/her decisions in one way or another.

Transport aircraft ARE to be flown by the book, but not absolutely slavishly; we already have people who think that pilotless airliners are a probability; while technically they are, it is not going to happen under the present aviation system.

Like a number of contributors here who's knowledge, experience and capacities I have enormous respect for, I have enough experience on the A330 and other transport aircraft to be able to know when to follow the book (99.9% of the time) and when not to, (0.1% of the time and it may keep one alive). You can't write that kind of stuff in any manual. What's more, no software engineer(s) is(are) presently capable of designing a system that can even mimic such comprehension let alone "decide". Decideability is a philosophical and perhaps pyschological concept, not a technical one.

Pitching an A330 to 5deg NU at FL350, (a 2.5 to 3deg change) would result in an enormous increase in climb rate. Any experienced transport pilot would know this instinctively and never be expected to take such drastic action. I cannot translate the full French QRH précis for the UAS drill in Appendix 9 so I don't know what guidance is offered the crew. The AF drill however, clearly advises, after the memorized items, that the pilots to follow the table which is similar to the one I posted.

None of this means anything against what is on the DFDR/CVR.

PJ2

[grizzled]

As PJ2 states, the information contained on the FDR and CVR is not just important in this case, it is critical to any possible resolution of this horrific mystery.

In that regard I believe it is imperative that the international aviation community exert all possible pressure on France, the BEA, Air France, Airbus, ICAO, and IATA to come together, and cooperatively spend whatever resources are required to locate the aircraft. This is not just "another accident"; this crash could quite possibly be a "game changer" with regard to one or more of the following: significant weather, crew training, computer interface (robotics), composite materials, primary equipment redundancies, and possibly other areas as well.

If the time and resources are committed to it, the technology and equipment exists to locate the major parts of the aircraft. Once that occurs, it becomes a good bet that the CVR and FDR can and will be located.

Yes, it will cost a lot of money to continue the search, but I truly believe it is worth it in this case to do so. In fact I believe pressure should be exerted on the UN, via ICAO, to dedicate specific funds to this effort.

grizz

[mm43]

Originally posted by GreatBear ...

It's a little difficult to understand why the ACARS message transmit times have been discounted. If the pitot disagreement preceded the Cavalry Charge (AUTO FLT AP OFF received at 02:10), why was the PROBE PITOT message buffered in the computer (and not sent) for one minute thirty-nine seconds?

The sequence of ACARS messages is easy to misunderstand if you don't know how the hierarchy works. Fault codes are batched and transmitted in hierarchical order every minute, but warning codes are sequenced in real time - though also time-stamped to the nearest minute. Even though the fault codes are batched with a minute time-stamp, their transmission sequence is still subject to other warning messages taking precedence.

It makes sense if you consider that the pilots get all the warnings in real time, whereas for maintenance purposes the source of the warning(s) is recorded as a fault.

The following interactive ACARS list has the minute attributed to each message highlighted in a different color. Each line will change color as the cursor passes over it, and if clicked will be highlighted in yellow. Click each highlighted line again to restore it to normal.

mm43

[HazelNuts39]

ACARS sequence

mm43;

Your explanation of the hierarchy, supported by the highlighting you added to the list, helps considerably my understanding of the sequencing of the messages. It made me think again if the gaps in the sequence, considered against the hierarchy, can tell us more about a possible loss of communication. BEA's 1st interim report explains on page 47:

There are two possible reasons for the longer gaps: either the aircraft did not have any messages to transmit, or it no longer had the means for doing so (loss of satellite communication performance, for example).

Take the 35s gap between 2:12:16 and 2:12:51. After this gap, at 2:13:08 and 2:13:14 there are two FLR messages timestamped 2:11. These must have occurred before the 2:12:51 0212 WRN message that takes priority after the gap. Doesn't that mean that there were messages to transmit prior to the interruption of the sequence?

HN39

[sensor_validation]

Originally Posted by HazelNuts39

Doesn't that mean that there were messages to transmit prior to the interruption of the sequence

Yes, from earlier posts this probably means bank angle greater than 50 degrees or changing rapidly during that gap.

The BEA also reports there must have been messages queued after the final message, one explanation for which is no engine power.

[mm43]

Originally posted by HN39 ...

Take the 35s gap between 2:12:16 and 2:12:51. After this gap, at 2:13:08 and 2:13:14 there are two FLR messages timestamped 2:11. These must have occurred before the 2:12:51 0212 WRN message that takes priority after the gap. Doesn't that mean that there were messages to transmit prior to the interruption of the sequence?

Good point. One would have to assume so, unless there were SATCOM difficulties in the apparently clear slots.

Didn't the BEA believe there were possibly a couple of FLR/Hard messages still in the system? My understanding is that the transmission of those messages is delayed for 1 min from initiating time - or am I wrong?

mm43

[GreatBear]

mm43, thanks for the detailed explanation re ACARS; makes sense now.

The upset clearly began at or slightly before 02:10. It is fortuitous that the 02:10:34 location message (sandwiched into the long string of dire warning messages) pinpoints where the event was happening. As HN39 and sensor_validation point out, and as inferred from the WRN messages, the aircraft was no longer in controlled flight under normal law.

I am becoming even more convinced, now, that at 02:10 at the Last Known Position the aircraft was in a vertical descent with no forward motion along the track towards TASIL. Which brings me back to the Searches. First, the unsuccessful search for the pingers, which DID cover the area of the Last Known Position but heard nothing, though there has been some re-working of the Emeraude's data which briefly took the search many kilometers southwestward. Then the unsuccessful Phase two and Phase Three sonar bottom searches. Here is the summary:



Grizzled, couldn't agree with you more! The FDR and CVR are critical to understanding. Imagine the collective unease of passengers and crew cruising straight and level in the coffin corner, mulling over Bearfoil's gloomy thesis that among the automatics, the structural technology, CRM, and the hand of God is a deadly unknown Dragon waiting to bring the aircraft down. It's a Dragon we need to characterize through the lens of the FDR and CVR and whatever wreckage might be found. To be prepared against its appearance (again).

Hopefully a Phase Four search effort will focus more on the area of the LKP, where the seabed has not yet been searched. Been a while since we have heard from the BEA, but I cannot believe they will discontinue the search efforts, leaving us all to worry about this Dragon.

GB

[JD-EE]

Originally Posted by mm43

Quote:
Originally posted by HN39 ...

Take the 35s gap between 2:12:16 and 2:12:51. After this gap, at 2:13:08 and 2:13:14 there are two FLR messages timestamped 2:11. These must have occurred before the 2:12:51 0212 WRN message that takes priority after the gap. Doesn't that mean that there were messages to transmit prior to the interruption of the sequence?
Good point. One would have to assume so, unless there were SATCOM difficulties in the apparently clear slots.

Didn't the BEA believe there were possibly a couple of FLR/Hard messages still in the system? My understanding is that the transmission of those messages is delayed for 1 min from initiating time - or am I wrong?

That is why I can believe your scenario where the aircraft executes a fairly sharp left turn for inexplicable reasons. A heavy enough bank left wing down would take the satellite out of the ACARS antenna beam perhaps past the antenna aiming algorithm's attempts to correct it. A right wing down bank would have had to be more severe than a left wing down bank due to the satellite position.

In either case I believe the bank angle would have to be rather large to cause loss of signal.

[ushumgal]

So, based on the timing of the ACARS messages, if the aircraft continued to fly more or less on course for approx. 2 min 16 sec, then made a hard turn to the left lasting some 30 sec (perhaps turning roughly 90 degrees? how far can an A330 turn in 30 sec in a steep bank?) and then continued in flight while descending to strike the ocean roughly 1 min 15 sec later, can someone show on the map the most likely impact region? It sounds to me like it would match pretty well with the very early analysis of the impact location based on drift analysis (the one that showed the sharp left turn).

[sensor_validation]

@ushumgal

In your scenario in which phase does the a/c lose 35,000ft in how long? The bits of the Lockerbie PA103 reportedly took 2 mins to fall from 31,000ft.

[HazelNuts39]

ACARS sequence

I suggest that similar observations can be made for most of the other 'gaps'. To list them all: at 2:11:00 -15s; 2:11:27 -15s; 2:11:55 -15s; 2:12:16 -35s; 2:12:51 -17s; 2:13:14 -31s; 2:13:51 - 23s.

In this connection, I have two questions on timing for anyone familiar with ACARS and satellite communication.

Firstly, the service provider's server clock may not be perfectly synchronized with that of ACARS. What difference is probable?

Secondly, the diagram of the messaging protocol between aircraft and satellite on page 47 of the 1st interim report shows that each message requires eight earth-satellite-earth transmissions. A wikipedia article on satcom states that each takes about 0,5 seconds for the distance alone, i.e. four seconds for the 8 transmissions. Would the server's reception time be for the first 'Request for communication' or the last 'Satellite acknowledgement'?

regards,
HN39