RR_NDB;
My responses in blue font:
"I need to present 3 (conceptual) questions (important to the analysis and understanding of the intriguing climb):
Let me preface my comments by stating again that I support and advocate for any and all ways to improve flight data recording.
To take FDR from its present state to the state you envision requires an understanding of all aspects of flight data recording and analysis. Any such understanding also requires a keen understanding of how flight data analysis actually works in practise. Such an understanding addresses the view that "if only we had ALL the information we could determine what happened." A detailed recording of "all" parameters is not necessarily a solution to understanding what happened. "All parameters" may not be needed, not because it can't or shouldn't be done but because such fine granularity may not be necessary. I can tell you that such granularity is unbelievably expensive to do, especially any retro-fitting, which brings me to the point I made in my first response - what is available in terms of parameters is driven purely by money, not flight safety or our need to know absolutely everything that goes on in each of the EEPROMs, computers and systems. The industry is just not going to pay for such a system even though, from an understanding POV, a case can be made.
"1) All information (except WX radar) being presented to PF and PNF are normally recorded in the SSFDR used in AF447? RHS not recorded could affect the investigation team analysis capability? Could affect the analysis in order to to understand PF (if confirmed at RHS) behavior?
No, not necessarily. I took some trouble to discuss FDRs in
Post #715, were you able to read it? There are no formal (legal) requirements for recording all such information and I describe why in the post. The fact that the #2 AS was not recorded is nothing more than it likely wasn't considered necessary, the airspeed already being "covered" by recording the #1 and the Standby, (and that is already well beyond minimum requirements).
It must be kept in mind that what is recorded is a matter of LFL, (logical frame layout) construction. Beyond the 88 legally-mandated parameters, this is not a process which is specified beyond the manufacturer. Boeing may have several hundred data frames for the B737 type for example, and they will be very different because the aircraft are very different. For older aircraft especially, DFDR and QAR data frames are specific to the individual aircraft simply because these aircraft get modified by successive owners who may desire certain parameters over and above the legal minimums. Many aircraft flying today only record the legal minimum and (from experience) it is not the case that all parameters are even working or recording correctly.
The SSFDR on AF 447 recorded, we are told, about 1300 parameters. Many of these parameters will have been the engine and engine system parameters, primarily used by maintenance for troubleshooting. Comparatively speaking, the requirement to "troubleshoot" EFCS components is rare - the boxes are pulled from the 800VU rack, sent to the manufacturer for troubleshooting/repair and a new (multi-million dollar) box is placed in the rack. The SSFDR will not have recorded very many EFCS parameters because it is not the airplane manufacturer's job to supply such parameters - it is done as a matter of discussion between the various parties...manufacturers, airlines, sometimes even flight safety people or pilots.
One great frustration in doing flight data analysis work is, as you point out, not knowing what the crew saw in terms of text messages on the FMA, the Lower ECAM, the status page and so on. To do so is very expensive because the data frame must be programmed to receive these parameters in binary format and change them into engineering units or text messages, but it is assumed that the computers (FWC in the A330's case) are correctly sending these messages to be displayed for the crew and the process therefore isn't necessary.
"2) Internal System information like redundant inputs to the System (e.g. individual ADM outputs) are recorded?
For the reasons given above, it can't be said whether they are or not. It can be done, but likely is not.
"3) Internal information (of the System) is recorded to allow a clear analysis of how System operated when something (anything) affects the "redundancy degree" of the System? (causing it to operate less redundantly)"
Again, not necessarily, for the reasons given.
=====Discussion:
The other important approach to flight data analysis work is not making the mistake of believing that "if only one had enough data, we could say exactly what happened". There are two reasons why this mistake is made:
1) Complex accidents such as AF 447 require that the work is very often interpretive and not just a summary of all the parameters in order of "causality". This is not a function of the available information, it is a function of ensuring that, a) human factors, and b) the nature of the data-recording process, are both taken into account when trying to understand (interpret) what the data is saying. How one "builds the story from mere data" is an entirely interpretive act requiring knowledge, skill and experience to do accurately.
2) The second reason is the nature of the recording process itself. In the same way we could never just look at the time-stamps on the ACARS messages and say that's the order in which things occurred, the problem of timings, sequence and therefore causality, is Vast if one is recording every EEPROM state, decision and output. The CAP 731 AAIB document to which I referred discusses data frames, recording frequency and binary-to-engineering conversions. It may be readily understood that recording frequencies can vary from say, every four seconds, (for fuel quantities) to four times a second (for pitch or roll, and pitch/roll rates), to sixteen times every second (for gee). But if you wish deep granularity we could argue that many parameters should be recorded at 26 frames per second, or data at video rates. The processes are entirely open to design capabilities and the imagination and at the same time are limited by the practicalities of cost and need.
One may find answers in the millions of parameters which would be required to capture such a level of data but the questions of practicality, of capability, of need and of expense all have contributions to make in such a discussion regarding whether to create such a system or not.
In most investigative work, (I am not an accident investigator), the number of parameters required to reach good conclusions is surprisingly small where the described knowledge, skill and experience are available. A clear example of this principle at work is the investigation into the QF72 PRIM incident. Indeed, the aircraft is not the only source or place to derive data; the manufacturer will have source code, testing facilities and their own experts who know how the computer(s) should behave and, if they didn't (as in the QF72 case), why they didn't.
While we await the next report from the BEA, I genuinely hope that this is helpful RR_NDB.