A33Zab, post #1571
I have studied carefully what you posted. I decided to leave your own post in full and add my own commentary/questions in the middle. This is because your post addresses one set of problems and questions, whereas I am using the fascinating factual data you provided to address a different set of questions. Out of honesty I thought I would rather leave your post in full. The data I am using is set in bold, bolding is mine.
Went into the ADIRU today:
ADIRU computes AOAi from sensor resolver cos. and sin. and calculates
AOAc as function of AOAi, FLAPSLAT CONFIG and Sensor position(LH/RH)
If CAS < 60 Kts AOAi & AOAc are set to 0° and SSM (System Status Matrix) is set to NCD (No Computed Data),
this is also valid for TAS 0 Kts if CAS < 60
If CAS < 30 Kts it declares itself invalid and outputs 0 Kts and NCD.
These parameters are send to 8 similar ARINC output busses.
Bus 5-8 are reserved for the engines only. (Bus 7-8 are not used on A33).
Note: GE engine provides its own Air Data, A/C ADR is only used as backup.
PRIM 2 & 3 receives data by ADR's bus 2, FCPC 1 by ADR’s bus 3.
Therefore, failure between "ADR1-and-PRIM2-only", as in WRG:ADIRU1 BUS ADR1-2 TO FCPC2, means it is not a full bus fault, but rather a fault at either end of that line, either ADR1 or FCPC2.
Note: In Back-Up Speed Scale (BUSS) equipped A/C AOA is send via IR bus
Note: Couldn't find if a SSM NCD is taken in account by PRIM but most probably it will.
In the 1st BEA report the unreliable speed logic is explained.
The PRIMs trigger a monitoring process when one of the speeds decreases more than 30 Kts (in 1 sec.) compared to the median value.
This is what happens as a result of what triggered the PROBE-PITOT 1X2/2X3/1X3 message. Very likely high-altitude ice crystals clogging Pitot probes.
My main contention is that a latent software incompatibility between PRIM2 and ADR1 specific software versions revealed itself only under this specific set of circumstances, ie : the monitoring process of ADRs by PRIMs. In all other operating modes, they did cooperate smoothly.
This cannot be reported as a software fault by the system, because such things are not catered for in design, all perfectly logical because it is a high-reliability hard-wired system, not your average PC Operating System. Hence the WRG:ADIRU1 BUS ADR1-2 TO FCPC2 wiring message, which is not wiring at all but the only way the system could report incompatible message exchanging between ADR1 and FCPC2. A software fault.
The PRIM opens a monitoring window during which it operate in ALT 2 Law, the rudder deflection limit is frozen but associated message is inhibited.
At the end of the monitoring window, if the diff. is less than 50 Kts the PRIM returns to normal law.
Return to Normal law is therefore possible at this stage. PRIM2 lost ADR1. This likely happened during this process. Has PRIM2 returned to Normal Law as a result of acceptable difference between remaining two ADRs, unlike PRIM1 & 3 ?
Return to Normal Law would occur after 10 seconds have elapsed. This is important as will be shown.
If not it remain in ALT 2 LAW and at that time the F/CTL RUD TRV LIM FAULTmessage is shown.
This is what happened to PRIM1 which is master by default.
Outlier ADR is rejected and remaining control is on median value of the other 2 ADR’s
Is this what happens when PRIM2 loses connection with ADR1 ? Does it uses median value from ADR2 & ADR3 ?
(Stall warning is generated by highest AOA and not the median value)
This means actual AOA could be indeed 40° while not triggering ABNORMAL ATTITUDE LAW due to a median AOA value below <30° as already mentioned in the BEA ‘leak’.
If 2 ADR outputs are erroneous, but different, and the remaining ADR is correct OR all 3 are erroneous but different:
The AP and A/THR disconnects and if disagree last for more than 10s, the PRIMs trigger the NAV ADR DISAGREEmessage.
ALTERNATE 2 LAW become active and latched for remainder of the flight.
(AP and A/THR can be re-engaged if ADR output was only transient.)
In the case under discussion, NAV ADR DISAGREE was time-stamped by CMC at 02:12, acknowledged on the ground through ACARS at 02:12:51, which means the ECAM warning was generated between 02:11:58 and 02:12:46. Much later in the sequence. This also means that the ADRs monitoring process by the PRIMs from 02:10:05 to 02:10:16 did not generate this ADR DISAGREE immediately, which would have latched Alternate 2 law for all PRIMs. But this designed sequence did not evolve as expected.
What happened around 02:10:16, at the end of the initial monitoring process ?
No ADR DISAGREE yet. A Probe fault and a wiring fault, and PRIM2 in an undefined state, but quite possibly in Normal law.
BEA reports : "from 02:10:05 the autopilot then auto-thrust disengaged and the PF said "I have the controls" ("j'ai les commandes"). This marks the beginning of the monitoring process.
BEA reports : "The airplane began to roll to the right and the PF made a left nose-up input". BEA does not correlate this particular input with any significant change in attitude or flight path.
10 seconds elapsed.
BEA reports : "at 02:10:16 PNF says So we've lost the speeds, alternate law". This marks the end of the monitoring process.
BEA reports then "the airplane -attitude- increased progressively beyond 10 degrees and the plane started to climb".
This marks the beginning of the initial pitch-up event. I contend that it was undesired by PF :
BEA reports : "The PF made nose-down control inputs and alternately left and right roll inputs". Undesired climb.
I contend that this looks very much like an undesired overspeed protection acting on the basis of erroneous airspeed data.
FCOM notes that Overspeed Protection provides "positive static spiral stability" which means neutral stick roll-wise will actively return the aircraft to
zero bank, instead of maintaining
zero roll-rate.
This is a significant departure from the way the pilot usually flies this type of aircraft manually. I contend that this would at least partly explain the roll control difficulties faced by PF from 02:10:16 until the top of undesired climb, compounding his ability to identify a critical flight controls issue on the pitch axis.
Active PRIM could in this case reject the correct ADR data.
That's why crew need to perform the unreliable speed Indic/ADR check QRH procedure and isolate the ADR in error. (Thus it will not be used for faulty PRIM input & indication).
The PF slight but consistent nose up command is a +G request to the PRIMs, the A/C feedback by means of accelerometers however results in a -G.
PRIM deflects elevator and due to negative result drives the THS all the way ANU.
Unfortunate left unnoticed because any hand on the trim wheel had cancelled the PRIM THS orders.
This obvious "emergency exit" only works if the pilots are actually trained to use it against normal practice of Norm/Alt flight laws. The amber PFD indication
USE MAN PITCH TRIM does not appear either in Normal nor in Alternate 1 or 2 laws. Only Direct Law provides it. Direct Law likely did not activate throughout the accident sequence.
Another manufacturer of FBW large civilian transport aircraft leaves speed trimming to pilot control. This helps keeping the habit of using manual pitch trim to assist elevator commands when the need is felt. On the other hand, with a full auto-trim which works perfectly 99.9999% of the time, this habit disappears.