PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Tech Log (https://www.pprune.org/tech-log-15/)
-   -   AF 447 Search to resume (https://www.pprune.org/tech-log/395105-af-447-search-resume.html)

Hyperveloce 24th June 2010 20:06


Originally Posted by PJ2 (Post 5772355)
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 ?
http://img718.imageshack.us/img718/8...memoryitem.jpg
Jeff

HazelNuts39 24th June 2010 20:25


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 24th June 2010 20:46

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 24th June 2010 21:14


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 24th June 2010 21:47

Thanks HN39.

Backoffice 25th June 2010 00:06

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 25th June 2010 01:39

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 25th June 2010 01:50

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 25th June 2010 12:33

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 25th June 2010 15:40

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 25th June 2010 19:55

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 25th June 2010 20:26


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 25th June 2010 22:09

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 25th June 2010 22:37


Originally Posted by HazelNuts39 (Post 5774570)
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 25th June 2010 22:59


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 26th June 2010 15:09

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:

http://i958.photobucket.com/albums/a...y17May2010.jpg

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 26th June 2010 23:43


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 27th June 2010 01:13

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 27th June 2010 08:33

@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 27th June 2010 08:53

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

iakobos 27th June 2010 10:38

"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."

The a/c is within the beams of two satellites, it has AOR-E on its right and AOR-W on its left.
I am pretty confident Inmarsat knows through which of them the signals transited.

HazelNuts39 27th June 2010 10:55

RE: What If?
 

Originally Posted by GreatBear
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?

GreatBear;

Pitots are relatively insensitive to variations in the local airflow angle. Significant differences due to angle of sideslip are likely to occur earlier in static pressure and AoA.

EDIT:: Re: "easy in the coffin corner": I've added a few datapoints to the 'coffin corner' graph posted earlier. According to information kindly provided by PJ2, it takes about 4 minutes with T/L at IDLE to decelerate from M.8 to M.6, which is V_alphaMax (Vs1g). It seems that V_alphaMax at FL350 is defined by buffet onset, which probably implies that the airplane can decelerate even lower into increasingly severe buffet before it stalls.

EDIT2::
The graph showed the Mach corresponding to the stall warning AoA of 4.2 degrees at 1g. Since this is the SW threshold at M=.8, it is appropriate to show it as loadfactor at M.8. The graph has been changed accordingly.

regards,
HN39

sensor_validation 27th June 2010 12:54


Originally Posted by HazelNuts39 (Post 5776812)
GreatBear;

Pitots are relatively insensitive to variations in the local airflow angle. Significant differences due to angle of sideslip are likely to occur earlier in static pressure and AoA.

Also difficult to see how the 2 pitots on same side would disagree.

@HN39

How would your plot change with alt = FL370 and/or T = ISA+30

Peter-1959 27th June 2010 13:07

update seabed worker
 
mm43

UNKNOWN
1.. Why the aircraft got into a LOC situation
2.. How long the aircraft continued flying.
3.. Where it impacted with the ocean.

but will this be all affecting its actual position on the seafloor?
shape of wreck, weight, currents at higher depts, I wonder if a simulation has been worked with different scenarios depending on how fast the wreck sank, while going down affected by different current speeds (and possibly directions), with different types of damage to hull and wings. For instance sinking while positioned horizontally with effects from remained wingshape. Or would it possible that the wreck was still drifting occasionally over the ocean floor, until it topped over into the abyss of >4000m, are there any dynamics not taken account for, presumed static

HazelNuts39 27th June 2010 14:38


Originally Posted by sensor_validation
How would your plot change with alt = FL370 and/or T = ISA+30

The data on the graph are not affected by temperature. At FL370 the LF's for buffet onset and SW are reduced by a factor of 1,10; and the severe turbulence speed is M.8. The FCOM gives Vs1g up to M.425 and I have one datapoint at FL350 only. However, I guess that if you read V_alphaMax on the curve reduced by 1,10 at an unchanged LF you wouldn't be far off.

EDIT::
The graph has changed to show SW as a LF at M=0.8. Therefore reference to SW Mach has been removed from above text.

regards,
HN39

mm43 27th June 2010 19:17


Originally posted by Peter-1959 ...

.... but will this be all affecting its actual position on the seafloor?
shape of wreck, weight, currents at higher depts, I wonder if a simulation has been worked with different scenarios depending on how fast the wreck sank, while going down affected by different current speeds (and possibly directions), with different types of damage to hull and wings.
In post #322 I made mention of some contributing factors that will have affected the progress of wreckage from the sea surface to the bottom. The process is complicated by not knowing the exact state of the a/c hull following its impact with the water, but I suspect that it is in three separate pieces, along with the cores of each engine. That makes for five separate paths to the bottom, of which the engines can be considered as straight-down items. Read the above post and then discount sub-surface current affects on the way to the bottom - they are minor. In other words, you are looking for a bottom debris field of about 400m radius, and probably smaller.

mm43

JD-EE 27th June 2010 20:10

Hazelnuts39 asks how far off satellite time might be from aircraft time or ground time.

The satellite would be very close to ground time. The satellite is constantly in touch with several ground stations which can provide it with corrected time certainly within milliseconds accuracy and probably much better. So I think we can stipulate that on terms of seconds the satellite is right on the mark with the ground stations.

Suppose the ACARS protocol does not require precise timing on the aircraft and as such can wander considerably. (I doubt this is the case.) A cheap crystal oscillator without any fancy temperature compensation is cut to about 50 ppm accuracy and wanders 25ppm to 50ppm over various military temperature ranges. Let's suppose it sits 100ppm, 0.01%, in error for an entire 12 hour (43200 seconds) flight. It might be as much as 4 and a third seconds off at the end of the flight.

This, however, is a very artificial scenario. The signal must be precisely on frequency or the satellite will have trouble extracting the modulation. The Inmarsat-M sets I worked on had temperature compensated oscillators, TCOs, good to the 1 ppm sort of level. ACARS is a simpler protocol. It MIGHT only require 5 ppm. I do not have the ACARS specification (or Inmarsat M) at hand anymore. Inmarsat marks them as proprietary so I properly discarded my copies when I left the program.

5 ppm is 20 times better than the scenario above or 0.216 seconds per 12 hour flight. It would be within a second over 10 days.

There is one more consideration, is there any procedure for setting the ACARS time estimate before each flight or is it "automagic?" I would "presume" there is a precision 1 second time tick and other means of sending that tick's actual GPS time value around the aircraft. I'd be pretty sure that ACARS snarfs up that estimate and uses it for continuous internal time updates. So having ACARS a millisecond off timing is not likely. The only real ambiguity is when the time stamp is applied to the signal. It seems to be part of the ACARS message itself. So it must be applied as the message enters or exists the transmission queue. (And, with time a part of each ACARS message it's self-time-correcting to fractions of a second.)

IMAO the time tick should be when it entered the queue. This accident shows that this might have helped unravel some of what happened. (And the NYSE recently discovered that makes a BIG difference when you have computer traders that will game a situation such that the queue becomes longer than 1 trade. There is a credible theory that's what brought the market down in 2008. That shows two things, this is an issue that is often poorly considered in system design and that this may also be the case in the ACARS system used on AF447.)

I hope that swats down ideas that the clock times could be materially off to say 10s of seconds or more.

JD-EE 27th June 2010 20:13

iakobos - the question there is, of course, how fast can it resynchronize to a different satellite? The particular version of Inmarsat protocols with which I am most familiar is not particularly fast. It doesn't happen often enough to worry about for things that float or drive around countries other than the US. The time is measured in 10s of seconds as I recall.

FluidFlow 28th June 2010 00:54

Pitots may have worked properly, ADU error checking may have precipitated the event.
 
I have been silent for 12 months but would now like to raise the following for discussion.

1) The BEA#2 report indicates a sudden increase in speed inconsistency reports (7 times the frequency) from a point about 2 months before the peak in oil prices. Could this coincide with a renewed emphasis on flight plan optimisation with respect to fuel??

2) Speed indication of Mach by pitots can be over-estimated in a Cb and TAT will over-estimate SAT when using the over-estimated M.

Standard atmospheric air (mostly diatomic) has a Cp/Cv ratio referred to as G (gamma). Normally the low humidity, low pressure and low temp air at cruise level means G is relatively constant. Add abnormal % of water (triatomic) and G is no longer constant but decreases (BEA#2 'strong condensation' pg69).
The air density value is required for the pitot to measure air speed but M can be calculated from pitot results if G is assumed. As G decreases, M is overestimated by the pitots. This M value is used to correct static pressure giving an altitude calculation variation (error) even if the altitude has not altered and there has only been a change in G. This M is used to calculate SAT from TAT. SAT is also overestimated.

On a sudden change in Ps (altitude) calculation due to incorrect M, the TCAS (BEA#2 pg 35) ACARS would appear if Ps fails the 'credibility test' @2:10.
The IR may also reject the ADU sudden changes in calculated data (due to the variation in G), hence the ADIRU fault (2:11).

It seems possible that a sudden change in the air property (G) due to the Cb could start the cascading faults shown in ACARS due to internal error checking. This then leads to the A/P and A/THRUST disconnecting although the A/C may not have altered its velocity or altitude.

I don't recall this being raised previously. My apologies if it was. My concern is that AF447 may be somewhat repeatable if 'heat upgraded' pitots are installed as this does not alter the above, albeit rare, scenario.

thanks. Ian

HarryMann 28th June 2010 11:16

Ian,

So that is a genuine instrumentation behaviour in exceptionally high humidity air masses...? Then it throws another potentially broken egg into the basket !

Lonewolf_50 28th June 2010 12:21

Ian, are you suggesting precip/rain/moisture as the air anomaly that sets up your M error, or a vertical column of warm/moister air (which Tim Vasquez had suggested in his analysis), arising from the inherent instability within a Cb?

If I understand you correctly, this M error, due to the combination of factors, ought to have been experienced more frequently. Is it your suggestion that it has been, but the community has been generally unaware since the community wasn't looking for it? :confused:

Mr Optimistic 28th June 2010 12:43

Gamma - do the numbers add up ?
 
to trip the assumed accident chain
eg
http://www.dtic.mil/cgi-bin/GetTRDoc...c=GetTRDoc.pdf

CONF iture 28th June 2010 14:17

Ian,
The 3 Pitot heads, the 3 static ports, the 2 TAT probes will go through the same air mass at the same time, therefore they won't have any reason to disagree.
If I follow your theory, the only risk would be for the A/THR to compensate the over-estimated Mach and get the airplane closer to stall.

GreatBear 28th June 2010 14:54

FluidFlow (Ian): Welcome to the workroom!

I think we are all hoping for successful search and then recovery of the FDR and CVR. The sequence of ACARS messages, however, allows development of plausible scenarios and cause theories. The pitot disagree message has already effected industry changes (Thales to Goodrich).

Dean's 1979 paper on "Atmospheric Effects on the Speed of Sound" linked by Mr Optimistic points to the influence of water vapor at various temperatures in an ideal gas (see his Table 4) and talks about the heat capacity ratio Cp/Cv you mention. Seems the deltas are pretty fine, though...

Two thoughts:

1. Your proposition could be mathematically modeled if we knew the "standard altitude parameter" and the "credibility" test boundaries used by the TCAS software and mentioned by BEA to see if G can decrease sufficiently to increase M sufficiently to trigger an altitude calculation error and the ACARS warning message. Fluid dynamics, I've heard, is the trickiest of the physics disciplines, and the math is way beyond my own pay grade, but with the TCAS source code in hand I should think your what-if question could be ruled in/ruled out.

2. According to mm43, the WRN messages are sent in real time. Reciept of the TCAS NAV message follows the AUTO FLT AP OFF by 44 seconds. In your proposition, the TCAS NAV message, if the trigger, likely would have preceeded the other WRN messages.

GB

iakobos 28th June 2010 16:52

JD, from experience it takes anything between 15 and well over 60 seconds to (re)synchronize on an Inmarsat, most cases falling in the 20-40" braket.

sensor_validation 28th June 2010 18:18


Originally Posted by FluidFlow (Post 5777799)
2) Speed indication of Mach by pitots can be over-estimated in a Cb

I am intrigued by this - the actual density of humid/ saturated air will be lower than that of dry air (the effect that keeps clouds up), so the total pressure observed by the pitot will be lower, and if calculated dry gas density used to convert to speed, the actual calculated air speed under-estimated. The wings will also see the lower density and produce less lift.

I am not aware of pitot tubes being compensated for moisture content of the air, are they ever?

Peter-1959 28th June 2010 18:54

deepsea search
 
mm43

"That makes for five separate paths to the bottom, of which the engines can be considered as straight-down items."

I cant find good information on how they are searching, what sort of sensory equipment.There are laserlight camera's these days, which can be operated till 6000m or more, mounted on a ROV. Certain laserlight wavelengths will give distinguishable reflections on metal surfaces, and meanwhile penetrate deep enough through low density organic sediment layers.

FluidFlow 28th June 2010 21:19

ABNORMAL air properties
 
I am currently on holidays:ok: with a pathetic internet connection:{.

@HarryMann. This is genuine once we agree we are referring to an abnormal situation. I raise it for discussion to see if it is applicable.
@Mr Optimistic. (#1631). Thanks for the link. Most of this appears to be at 1 atm and within the normal humidity levels of air. A link that shows G variation over a larger range of variables would be http://spaceagecontrol.com/AD-InFlig...easurement.pdf fig 62(a) This graph too is for normal humidity but you can see the trend of decreasing G with added moisture ('saturated air' in this case). I cant post the actual formula at the moment but G decreases if air has more triatomic gases in it ie also more CO2 or O3. ie the N2, CO or O2 mix doesnt matter much. This is also one reason why the term 'dry air' is used as the reference numbers quoted (ie R) to the 10th decimal place would all be 'wrong' if the air was not dry.
@Lonewolf. Yes, I am referring to high levels of moisture (not just a saturation of air with water vapour though). ABNORMALLY high amounts of moisture that are brought into the cruise level by a Cb. The M variation falls into the 'who cares' category but it is the effect of this potentially sudden change in M on the calculation of other parameters which are then scrutinised by error checking. If there was no error checking then I suggest there would not have been a problem as the error in flight data is not sufficintly significant within itself. Hence it is the handling of the variations in air properties that I believe may be an issue and may have caused HAL to give up.
@Conf. Yes, the pitots and TAT's will agree with their partners ignoring turbulance. However for a change in G the M error from a TAT/SAT calcualation is about 4 times that from a pitot M calculation. So a program checking for errors may notice an anomoly here as it checks the validity of other calculated parameters even though it is 'turbulance trained'. It all depends on the range allowed before a parameter is deemed 'not valid'.
@GB. Thanks for your welcome and comments. My point could also be phrased in terms that we did not have an 'ideal gas' in this Cb. Yes, it all hinges around the 'credibility' tests within the software which one would expect to have been determined by the range of air properties expected to have been encountered. Enter a Cb with properties outside of this range and HAL may get confused.

rgds Ian

sensor_validation 28th June 2010 22:40


Originally Posted by FluidFlow (Post 5779441)
Hence it is the handling of the variations in air properties that I believe may be an issue and may have caused HAL to give up.

No, the Auto thrust and Auto Pilot disengaged because the speed measurements disagreed, which is most likely due to uneven blockage of pitot tubes and their drains due to ice.

Air properties and computations will be a common-mode problem, but are of considerable interest in understanding the state of the A/C when handed back to the pilots for manual control.

auv-ee 28th June 2010 22:53


Originally Posted by Peter-1959
I can't find good information on how they are searching, what sort of sensory equipment.

I presume you have looked at the information provided by BEA on the search equipment: Sea Search Operations

If you follow the links there, you will find the specs for the sonar on the Orion towed vehicle. If you dig deep, the specs for the REMUS AUVs from Waitt Institute are here: AUV Specifications | Search for Amelia though I don't see mention of the sonar frequency and range. Specs for the sonar on the Geomar vehicle are here: IFM-GEOMAR: The AUV Abyss where it mentions the frequency but not the range.

The search is being conducted with side-scan sonar. The sonars operate with frequencies in the span of 50-250kHz, depending on the required trade-off of range and resolution. The typical ranges used are about 300-500m either side of track, and the achievable resolution allows detection of an object about the size of a 55 gallon oil drum.


There are laserlight camera's these days, which can be operated till 6000m or more, mounted on a ROV. Certain laserlight wavelengths will give distinguishable reflections on metal surfaces, and meanwhile penetrate deep enough through low density organic sediment layers.
Laser scanning cameras have the advantage of reducing the common-volume scattering (water volume that is common the both the path from the light source to the target, and from the target to the camera), and thus the fog effect of underwater photography. That can greatly increase the optical range above the 10-20m typical of conventional photography in the deep ocean. A quick scan of the literature shows that ranges of 4-6 attenuation lengths are achievable, limited by forward scattering, which is not eliminated. See for example: http://jaffeweb.ucsd.edu/files/bathy...m%20L-bath.pdf

Attenuation length (distance in which intensity drops by 1/e) in the deep ocean does not exceed 50m: http://www.nestor.noa.gr/2nd/files/247_252_bradner.pdf Typical AL in the deep ocean is probably less than half that. That puts the range of a laser scanner at a maximum of 6*50=300m, but more typically 4*25 = 100m. That does not compete well with sonar for a wide area search for large objects that are likely sitting proud on the seafloor.

I'm not sure about your point regarding wavelength. The range of wavelengths is quite narrow, in the blue-green range, for which attenuation in seawater is reasonably low. Red, infrared and UV are strongly absorbed.

Do you know of some equipment with specifications that exceed the above numbers?


All times are GMT. The time now is 09:46.


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