I have been involved with the design and integration of the software on a number of avionic embedded systems; from a Fault Detection, Recovery and Reporting perspective I have some observations and some questions.
1. Only reporting 'own' failures to ACARS: IIRC on A320 there was an Airbus requirement on avionic systems that they had to have a 90% confidence level for detecting and reporting an internal failure, down to 'sub-system' level. In order to avoid a 'cascade' of messages, it is obviously important not to generate a maintenance message when the fault is known to be external to that particular system. This is possibly significance with the the IR2 message and the TCAS FAULT message; these should not have been generated because of an external ADR problem, but because of internally detected faults. A question for an ISIS expert, would high 'g' loads cause an ISIS system to consider that outputs from its gyros or accelerometers were 'out of spec'? A question for a TCAS expert, what would cause TCAS to generate an ACARS message, a GPS derived value (such as speed or rate of change of heading) out of spec? An earlier post referred to TCAS using Doppler to determine relative speed between aircraft; would 'unbelievable' changes in relative speed cause an internal fault to be flagged?
2. Delay on ACARS messages: Once an Airbus avionic system detects a fault it should immediately mark its outputs as Invalid/Unavailable to its 'users' (including CFDS). However, there may be a significant delay before the system can determine if this fault is a 'hard' internal failure. Its recovery process might include retrying an input a number of times, resets (of sub-elements of the system, or the complete system) or diagnostics (such as running loop-back tests on the ARINC 429 Input Port). So depending on the type of detected fault there might be a significant delay before a system is confident in reporting a failure. For example, the loss of an external communication link for a minute or so may not be considered a 'hard' failure, loss for 10 minutes or so might be.
3. Timing sequence of ACARS messages: As pointed out in other posts, ACARS primary purpose is to provide maintenance data to Ground Crew. There is no particular urgency to providing maintenance data to the ground (as opposed to ASAP for fault information to the flight crew). As it is an inefficient use of processing power to provide data at a rate faster than it is needed, an aircraft system could be designed to schedule a task every couple of minutes to check the system's internal fault log to see if a maintenance message should be composed and sent to ACARS. So the sequence on messages generated by different systems could be quite random.
4. Failures unlikely to be caused by lightning: It is unlikely that any of the ACARS failure messages were due to damage by lightning as it is likely that the system's vulnerable processing capability (CPU, RAM, etc.) would also have been affected to such an extent that the system would not be able to compose and send any messages to the ACARS. It is an important 'fact' that the reporting systems are still running; the failure they are reporting is unlikely to be due to lightning, power supply loss, fire or being shaken to destruction.
5. Setting fault detection levels: Avionic system designers are well aware of the difficulties in getting the right balance between 'nuisance false fault reports' and 'not detecting marginal faults'. The limits within the software that are used to flag a fault on sensor input values (max/min, rate of change, comparison) are based on the 'expected' range of values during aircraft operation; persistent input values that are outside the aircraft's operational limits should be considered as more likely to be an internal fault and hence flagged as such. A system that flags itself as failed and needing maintenance might in fact be working, it is just that what its sensors are telling it is 'unbelievable'!

:=

As always there is the chicken and the egg as to what happened first. I would caution against presuming the composite VS failed first just by looking at the available photos.

I have been trying to work back from the ACARS msgs to what you would see in the cockpit and what the normal responses would be.

If anyone else is interested this seems to be a decent reference.

SmartCockpit - Airbus 330

Fuzzy Data and Speculation
 

Curiously, only the thinnest information about the search and recovery effort for the the AF447 FDR/CVR and hull has been disseminated to the public. With the French BEA tasked to lead the investigation under ICAO rules for incidents occurring in international airspace/waters, a hugely expensive joint effort has been orchestrated using assets and expertise from France, Brazil, United Kingdom, United States, and Holland. The Brazilians have been providing imagery and consistent daily updates about the recovery effort for debris and remains found on the surface (http://www.fab.mil.br/portal/voo447/) and BEA are providing occasional press releases (News) including a "Sea Search Operations" summary document created on 17/06/09 (http://www.bea.aero/anglaise/actuali...search.ops.pdf).

But the granularity of official data is remarkably bland, hardly even suitable for media infographics and newsbites and certainly inadequate for reasoned analysis: never a lat/long reference; never a note about hull search areas and sensor towing depths; never a factual description of the ACARS "maintenance messages."

Officially "validated" facts on 17/06/09 per BEA (News):

# The airplane was in cruise at flight level 350 (about 10,500 metres).

# No messages indicating problems were received on the air traffic control radio frequencies.

# Close to the planned route of the airplane above the Atlantic there were significant convective cells characteristic of the equatorial regions;

# The last position message from the airplane was broadcast by the ACARS automatic system at 2 h 10 UTC.

# Between 2 h 10 and 2 h 14 UTC, 24 maintenance messages were transmitted by the ACARS, including 14 between 2 h 10 and 2 h 11.

# Analysis of these messages shows inconsistencies between the various speeds measured. Most of the messages appear to result from these inconsistencies; they correspond to the loss of several flight assistance systems.

That's it! The official sum of "validated" information on 17/06/09. Thin. At every opportunity, BEA cautions "avoid any hasty interpretation or speculation".

With such thin data, what else is there but speculation?

On the upside, what this and the Techno AF447 PPruNe threads have proven is that details can be flushed from the most fuzzy material. And all the speculation offered on these threads is, indeed, REALLY valuable, from possible meteor strikes (glowing dots reported on the sea surface) to faulty AOA processing algorithms. To finally solve this puzzle and generate credible answers about why this event occurred, ALL these speculations will be "weighted" and fed into an equation, where they will end up being ignored or adding value to a solution. Most commendable to this thread's participants, in almost 2000 posts there has been little interest in blame, simply a driving need to know what happened to upset this aircraft. That's being professional.

GreatBear,

Very well said. All accident investigation is really gradually more informed speculation until this gets converted into hard facts, unless the cause is immediately apparent (rare). There is nothing wrong with reasoned speculation unless it makes one blind to contradictory evidence.

-drl

A330 Oeb 74-4
 

RED OEB – RED OEB – RED OEB – RED OEB – RED OEB – RED OEB – RED OEB
Issued by STL
File in FCOM Vol 3
OEB N°: 74/4 DEC 08
Associated with QRH OEB PROC N°: 74/4
- This OEB covers a significant operational issue. Non-compliance with this OEB should have a significant impact on the safe operations of the aircraft. The Operators shall distribute its content to all flight crews without delay. An extract of this OEB is provided for insertion in the QRH.
- It is strongly recommended that all Operators accelerate the incorporation of all corrective Service Bulletins as soon as they are available.
SUBJECT:
IR FAILURE OR ATT FLAG ON PFD
APPLICABLE TO:
All A330 aircraft fitted with NORTHROP GRUMMAN - LITTON ADIRU
CANCELLED BY:
TBD
R
REASON FOR ISSUE 4:
RRRR
The previous OEB revision requested to de-energize the affected ADIRU if the IR and/or ADR OFF lights did not illuminate. The OEB procedure is now revised in order to recommend that the IR mode rotary selector be set to OFF in all cases in order to address all identified failure cases.
Page 1 of 5
Operations Engineering Bulletins are issued by Airbus as the need arises to quickly transmit technical and procedural information. They are distributed to all FCOM holders and to others who need advice of changes to operational information.
Information in this bulletin is recommended by Airbus but may not be approved by Airworthiness Authorities.
If the procedures contained in this OEB differ from the procedures in the AFM, the AFM remains the reference.
OEB N° Page 2 of 5
74/4
REASON FOR ISSUE:
This OEB is issued in order to provide a procedure enabling to mitigate the probability of occurrence of a sudden nose down order.
EXPLANATION:
An A330 aircraft experienced a sudden nose down order during cruise. This order was preceded by an automatic autopilot disconnection and triggering of the NAV IR 1 FAULT ECAM caution.
Investigations highlighted that at the moment of the event the ADR 1 was providing erroneous and temporary wrong parameters in a random manner. This abnormal behavior of the ADR 1 led to several consequences such as unjustified stall and over speed warnings, loss of attitude information on the Primary Flight Display, several ECAM warnings.
Among the abnormal parameters, the provided Angle of Attack value was such that the flight control computers commanded nose down movement.
The aim of the following procedure is to isolate both the IR and ADR when an IR is detected faulty in order to prevent the ADR from providing erroneous data to other aircraft systems.
TO BE CONTINUED ON NEXT PAGE
PROCEDURE:
RRRR
OEB N° Page 3 of 5
74/4
RRRR
• If all ADIRU operative before failure:
If one IR is self detected faulty or if the ATT red flag is displayed on the Captain or First Officer PFD, the affected IR and the corresponding ADR must be disconnected.
NAV IR 1(2)(3) FAULT, or ATT flag displayed on CAPT (F/O) PFD
-IR (affected) pb …………………………..…… OFF
The affected IR is the one self-detected faulty or supplying the PFD displaying the ATT red Flag.
The OFF light may not illuminate
-ADR (corresponding) pb ………..………...… OFF
ADR 1 corresponds to IR 1.
ADR 2 corresponds to IR 2.
ADR 3 corresponds to IR 3.
The OFF light may not illuminate
-IR (affected) MODE rotary selector ……….. OFF
The IR mode rotary selector is set to OFF in order to de-energize the ADIRU. The OFF lights of the IR and ADR pushbutton will go off.
Setting the IR mode rotary selector to OFF is an irreversible action. Therefore, both PF and PNF must clearly identify the corresponding selector before setting it to OFF.
• If IR 1(2) affected:
In order to prevent possible failure of ADIRU 3, the flight crew must switch the AIR DATA and the ATT HDG in the following order:
-AIR DATA SWTG …........………..……... CAPT (F/O) ON 3
-ATT HDG SWTG ..…….......…………….. CAPT (F/O) ON 3
TO BE CONTINUED ON NEXT PAGE
CAUTION
RRRRR RRRR
• If one ADIRU already disconnected before failure:
In case of dispatch with one ADIRU under MMEL or one ADIRU already disconnected in flight, and an IR failure occurs, either detected by an IR 1+2 (1+3)(2+3) FAULT or with ATT red flag displayed on CAPT or F/O PFD, the affected IR and the corresponding ADR must be disconnected.
NAV IR 1+2(1+3)(2+3) FAULT, or ATT flag displayed on CAPT (F/O) PFD
-IR (affected) pb ………………..…….…...…… OFF
The affected IR is the one self-detected faulty or supplying the PFD displaying the ATT red Flag.
The OFF light may not illuminate
-ADR (corresponding) pb ……………...…….. OFF
ADR 1 corresponds to IR 1.
ADR 2 corresponds to IR 2.
ADR 3 corresponds to IR 3.
The OFF light may not illuminate
-IR (affected) MODE rotary selector ……….. OFF
The IR mode rotary selector is set to OFF in order to de-energize the ADIRU. The OFF lights of the IR and ADR pushbutton will go off.
Setting the IR mode rotary selector to OFF is an irreversible action. Therefore, both PF and PNF must clearly identify the corresponding selector before setting it to OFF.
CAUTION
• If IR 1+2 affected:
In order to prevent possible failure of ADIRU 3, the flight crew must switch the AIR DATA and the ATT HDG in the following order:
-AIR DATA SWTG ..........………………….CAPT ON 3
-ATT HDG SWTG .......………...…..………CAPT ON 3
Note: First officer can recover IR information, by using the EFIS DMC selector (copy of the opposite side).
SPD BRK ………………………………….…….. DO NOT USE
• IF CG AFT 32%:
-T TANK MODE………………….……….. FWD
F/CTL ALTN LAW (PROT LOST)
MAX SPEED ………………………..………..…. 330/.82
OEB N° Page 4 of 5
74/4
OEB N° Page 5 of 5
74/4
OEB REMINDER:
On aircraft that have the OEB reminder function, the procedures of NAV IR 1(2)(3) and NAV IR 1+2(1+3)(2+3) FAULT ECAM cautions may be flagged.
The “refer to QRH PROC” line will then be displayed instead of the procedure itself.
To flag those procedures, the following codes should be entered in the FWC OEB database.
Code WARN STS
NAV IR 1 FAULT YES NO
34/10/050/061
NAV IR 2 FAULT YES NO
34/10/060/063
NAV IR 3 FAULT YES NO
34/10/070/065
NAV IR 1+2 FAULT YES NO
34/10/020/055
NAV IR 1+3 FAULT YES NO
34/10/030/057
NAV IR 2+3 FAULT YES NO
34/10/040/059
CORRECTIVE ACTION:
Under investigation
Note: The interchangeability code, given in the Illustrated Part Catalog (IPC), indicates the conditions for interchangeability of equipment. After installation of corrective modification(s)/SB(s), if an Operator reinstalls any equipment affected by this OEB it is the Operator's responsibility to ensure that the recommendations given in this OEB are applied again for the applicable aircraft.

More Pics
 

More pics up on the Brazil Military site .. also wondered what this box / container was and are those bits of structure sticking into it?

http://www.fab.mil.br/portal/voo447/...ite/foto_2.jpg

http://www.fab.mil.br/portal/voo447/...ite/foto_1.jpg

341115
 

It is really not clear that all pitots were disagreeing (at least from what we have - maybe the ACARS message line was cut to be printed).

From the A330 TroubleShooting Manual:
Source EFCS2 Class : 1 HARD
Identifiers : EFCS1,AFS
341115 - PROBE-PITOT 1+2 / 2+3 / 1+3 (9DA)
Le TSM (Trouble Shooting Manual) utilisé il y a deux jours indique :



34-11-15 EFCS2 : TASK 27-91-00-810-822
Disagree of the Pitot Probe Data in the FCPCs
1. Possible Causes

• pitot probe

2. Job Set-up Information

• A. Referenced Information
  • AMM 34-11-15-000-801 Removal of the Pitot Probe (9DA1, 9DA2, 9DA3)
  • AMM 34-11-15-200-801 Inspection/Check of the Pitot Probe (9DA1, 9DA2, 9DA3)
  • AMM 34-11-15-400-801 Installation of the Pitot Probe (9DA1, 9DA2, 9DA3)

3. Fault Confirmation

• A. Test
  • (1)Not applicable, you cannot confirm this fault on the ground.

4. Fault Isolation

• A. If the crew made a report that the F/CTL ALTN LAW or F/CTL DIRECT LAW warning was shown on the EWD for some seconds only:
  • - no trouble shooting is necessary.
• B. If the F/CTL ALTN LAW or F/CTL DIRECT LAW warning is shown and stays on during the flight:
  • (1)Do the inspection of the pitot probe (9DA1, 9DA2, 9DA3)
    AMM TASK 34-11-15-200-801
  • replace the defective pitot probe (9DA1 or 9DA2 or 9DA3)
    AMM TASK 34-11-15-000-801 and AMM TASK 34-11-15-400-801

As stated earlier, the difference between a mechanical gyroscope (spinning bicycle wheel on gimbals) and a laser ring gyro is significant. However, don't overstate this. Laser ring gyros are significantly superior to mechanical gyros in every way. They have drift specs that far exceed the best mechanical gyros, are smaller, lighter and more robust than any mechanical gyro. They can be sampled faster (1000 deg/s, 3000 deg/s^2) and combined with high quality accelerometers allows you to integrate to find your attitude.

The downsides of mechanical gyros far exceed their utility. They have inferior drift specs (friction sucks) and they're far less reliable. Just because something is old and mechnical doesn't mean it's better...

The Isis Fault
 

It seems the ISIS fault refers to anemometric problem. Then it could relate to total/static pressure sensors.

From a french site:

Eurocockpit - Accueil

From the same site, however:

Basically saying that the IR2 fault/disagree wouldn't be affected by air data inputs.

The large item is likely the other (back) side of the galley we see being recovered, (without all it's bins in place). Notice the support structure on what is likely the bottom of the galley installation, punctured upwards and to the galley's right, (we don't know which way this structure was installed in the aircraft so we don't know if the support structure is bent to starboard or port).

Second photo:
- We see a long section of the overhead bin support structure in the middle of the photo.
- a flourescent yellow/green box similar to the orange one seen in earlier photos - perhaps the defibrilator - or not.
- another part-bulkhead structure similar to the one recovered which had the F/A's seats; one can see a mounting structure which may have held a fire extinguisher.
- cabin interior structure, with windows
- an Oxygen bottle (green bottle, lower center-left
- sections which appear to be the bottoms of ULD's, (unit-load-cargo devices), although they appear in pretty good shape given their relatively light structure
- a large section of a flight control - hard to say which one
- galley bins, (top right)

Adiru2
 

Gents,


Could one of you inform me whether the raw airspeed data fed to EFCS2(?) in order to detect faulty pitots comes from the ADIRUS or directly from the ADMs ?

If it comes from the ADIRUs, maybe we already have a decent explanation for almost all those ACARS messages.

A simple question
 

I have followed this thread as much as possible and understandably much is quite technical but I have a simple question, can bad weather alone bring down a modern airliner?

I just a member of the public interested in aviation and have been under the impression for years that there is no turbulence that could bring down modern aircraft at cruising height. Am I being naive?

Apologies if this question is a bit 'aviation for the under 5's':bored:

Yes, although weather usually needs some human assistance, like driving the plane into the weather.

PS

Falconer, by refering to modern I think he accepted that earlier aircraft were susceptible to weather. By modern he was hoping that 'weather' had been removed as a risk.

a simple answer..
 

and no, Smithm, no apology needed here..

Absolutely, YES..

and modern or not does not have anything to do with it..

EVERY plane can be flown into a weather situation that will break it..

weather has always and will always be a prime factor

unfortunately it is us, in the industry, that need to remind ourselves of these facts... sometimes they seem to be forgotten..

The world's largest distributor of used aircraft parts:
Thunderstoms.

PJ2,

Thanks for that info - the control surface seems to be an airfoil, perhaps part of an elevator panel? The HS itself is too big I think for the debris to be part of that. Any information that leads to identifying that piece of debris would be very interesting.

Here is a good view of the underside of the HS/elevator

http://www.samchuiphotos.com/QFnew/DSC_5440.jpg

Edit: the notch in one side of the unknown control surface part shown among the debris could very well be a hinge recess for the elevator panel.

-drl

Trying to understand how a faulty ADR can generate a NAV IR fault report (Qantas), how it can contaminate the automated systems without being detected/cross checked as an outlier (although there are two other valid measures):
The QANTAS Airbus A330 Inflight upsets
maybe of interest. There were two different cases for Qantas. This risk was also present with the Boeing777 (FAA emergency AD 2005-18-51)

A contributor with a professional experience in avionics failure modes raised the possibility that the IRU declared itself as faulty as it was measuring (true) accelerations or rotations known as outside from the normal flight enveloppe.
Jeff

Thank you.

From the deck photograph and the side view it does indeed seem to be the defibrillator container. I'm surprised it floated as those things are very heavy.

Suddenly a bunch more debris
 

Two possible explanations come to mind:

• AF447 was significantly off track dodging CBs when it ran into trouble. Now that the search has broadened to include the actual track including subsequent drift, debris is turning up.
• The buoyant pieces worked loose under water and floated up some days later -- a lesser probability.