Hi Diversification,
Originally Posted by Diversification
I am still surprised by the fact that BEA gave no hints in the short list explaning where the various ACARS were coming from.
Please, read again BEA interim reports 1 & 2 and specific ACARS chapters. Those reports, including the last note, are all completing each others and what could be explained with all informations on hand at the time each report was printed... was explained.
ACARS is designed for aircraft maintenance, not for aircrash investigations. Hence, some informations in ACARS sequence can not be acertained without access to other sources (CVR, DFDR, or by recovering avionics memories). Nonetheless, at this point, most is already explained or very narrowly conscripted.
What is much more disturbing on the subject is in fact this thread's noise/information ratio around some of the ACARS already explained from day 1 (see Bearfoil's posts still denying pitot and subsequent airspeed issues and consequences on flight systems!).
Originally Posted by Diversification
One of the last was about faults in Prim 1 and Sec 1, which were earlier assumed to be either showing serious faults of caused by pilot shut-downs of these systems.
PRIM 1 and SEC 1 ACARS are only ECAM messages (cockpit effects). There was no "fault" correlated with them that was sent by ACARS.
It could be due either to simple manual reset, or an auto-reset if some fault was detected, by its built-in test equipment (BITE); a single function affected may do that. There is no way to know more without looking into other system memories. If it was due to a manual reset, the CVR won't tell anything if nobody was talking about reseting the PRIM/SEC... The seriousness of this fault is quite improbable as there is 2 other PRIMs and another SEC.
Originally Posted by Diversification
Very often it has been assumed in this thread that there was 5 computers involved on AF447
There is effectively five Flight_Control_Computers": PRIM 1, 2, 3 + SEC 1 & 2. They very specific task is to manage pitch, roll, yaw, etc. depending on the various Flight Control Laws, which depend on other imputs (like Air Data, Inertial References, etc.)
Originally Posted by Diversification
however each of the three ADIRUs also contain at least one each and perhaps also one in each of the Air Data Modules.
Most avionic part of the system may be considered as a "computer". But they are very dedicated "computers" performing some straitforward tasks: ie. An ADM (Air Data Module) task is to digitalise the pneumatic source of a sensor for an ADR unit ; the ADR (Air Data Reference) role is simply to compute the various functions derived from those sensors (Speed, Mach, AoA, barometric altitude) for other "computers" like the FMGC, FADEC, PRIM, SEC, FWC...
Originally Posted by Diversification
I am making this conclusion from the australian report about sporadic AoA signals, where it is stated a software update for the ADIRU uncovered an old bug.
I have read the same report and the conclusion was that no "bug" was found on this ADIRU. Nonetheless, something went wrong, twice, with the same unit, but they did not found what it was. AoA spikes filtering was suspected but they could not reproduce it into the lab. Hence, what could have caused it? Was it internal or external? In fact, nobody knows.