PPRuNe Forums - View Single Post - AF 447 Thread No. 11
View Single Post
Old 15th July 2013 | 17:45
  #294 (permalink)  
PJ2
20 Anniversary
 
Joined: Mar 2003
: ATPL
Posts: 2,558
Likes: 155
From: BC
WillowRun 6-3;

Thank you for those examples where confidentiality of exchanges obtains. In fact in some jurisdictions, - Germany, I believe and I would have to confirm this, according to German privacy laws, the flight data captured on their aircraft belongs to the pilots, not to the airline or the state. I suspect in an incident or accident that does not apply and I know it would be more complicated than stated here!

In terms of confidentiality and data protection, when implementing flight data analysis programs great care, expense and energy are expended to ensure the confidentiality of the individual's flight data so that it could accomplish its singular task. It was made clear that confidentiality did not mean anonymity however. If something in the data indicated a serious event, there were and are processes whereby the carrier's due diligence is served. The matter becomes delicate when the data indicates a serious and perhaps even intentional departure from standard operating procedures; very challenging to maintain the integrity of the safety process while addressing such matters effectively in an environment of competing goals and interests.

In re, ". . . there is another dimension here, to be sure, driven by the intensely deep state of knowledge one must have and hold in order to understand the complexities of the flight path (say) of a Triple 7 which might have been in FLCH mode with A/T armed but not on (until it was too late). These facts (if facts they are), a non-driver can recite, but there is much more to understanding the actual data, one would think, yes?"

It is your last comment in the quote passage above that is particularly germane.

Having done flight data work for a number of decades I know only too well that even as one may be an expert in examination, flight data, (which, despite apparent views to the contrary expressed here and elsewhere) is very much an incomplete process and subject to what I would view as "the interpretive gesture". I would venture to say that the FOQA/FDA/FDM community would concur. The flight data process is akin to making up one's mind about what is going on in a pitch-dark room in which there are many people doing things and which is lit by a strobe-light at a "sample rate" of once per second, or perhaps once every eight seconds, or perhaps once every tenth-of-a-second, depending upon how one's "strobe light" is set up. Ideally, a frame rate of 26fps would be wonderful and increasingly possible, (anything is possible with fathomless funding!). But the process of creating, programming and certifying what is called the "Logical Frame Layout" is exceedingly expensive, proprietary to the manufacturer and often the subject of what we call an "STC" - Supplemental Type Certificate, which is an addendum to the aircraft's original type certificate. While not uncommon, the process is extremely expensive and time and resource intensive.

That's just to get more data, (typically onto the QAR - Quick Access Recorder a non-crash-proof box) than is required by the State in its aviation regulations. If parameters are missing and desired, it is anything but a simple matter to fix, even with today's inexpensive and flexible technologies such as Avionica's mini-QARs. The equipment is not the problem.

Once all is up and running, an aircraft may have anywhere from a couple of hundred basic parameters to 40,000 parameters on aircraft like the C-17. The B787 I believe has far more, to the point where if a system event occurs, the recording system reduces parameter capture recording rates for non-related systems and enhances parameter capture rates for specifically related systems.

In older aircraft, the requirements for the number of parameters is tiny depending upon age, type certificate and date of manufacture. Retrofitting aircraft with the necessary equipment beyond what was legally required on the date of manufacture is so prohibitively expensive that the FAA (and other regulatory bodies elsewhere) provide substantial relief in required parameters.

Returning to your last comment then, you have apprehended the matter precisely. For those who do not do this work and therefore do not understand its complexities including the primary need for experience in order to interpret data accurately, the presumption that all one needs is "all the data" just to settle things once and for all, is misplaced.

Whether we are discussing flight data monitoring programs or data from the SSFDR and SSCVR after an accident, there are numerous documents which explain the flight data process quite well. Links to CAP 739 and CAP 731 are among those I have offered previously in order to help others understand the flight data process.

While one does not necessarily have to be a transport pilot to read the data, such experience is immeasurably helpful when interpreting the data. As with any process this complicated there are subtleties and when sample rates are not video rates, interpretation of the "raw" data, (not the binary code but the basic engineering data that is readable) is inevitable.

By the way this is my chief argument against the animations we see increasingly pop up hours or days after an accident when there is nothing but someone's imagination to guide such an exercise. I am similarly quite wary of animations-as-evidence, having done many such videos in FOQA work. The reason is simple: flight data supporting any animations necessarily will require "smoothing", so as to present a smooth flight path and readable, (non-jerky!) set of instrument readings. In fact, all FOQA software I know of will have numerous ways to smooth data, all of them legitimate in the hands of experts who use animations only as a rough guide and briefing tool. While this process is well established, understanding the process of how animations are actually created is important to a correct interpretation simply because any process which involves extrapolation of data in between two recorded data points can (and has, in my experience) led to wrong animations. Animations are extremely powerful in today's visual-image-oriented society and so have the power to convince when there may be no basis whatsoever to conclude. For example, let us say a control stick is sampled once per second. That seems sufficient until we bump up against an event in which rapid movements of the stick during a landing incident would not be captured, and in a not-rare circumstance, we could see two neighbouring control stick parameter data points indicating, say a full-nose-up position, but in between those two points (where there is no data), the stick may have been rapidly placed full-nose-down and returned to the previous position and those reading the data (and viewing the animation) are no wiser. I have seen examples of this phenomenon in ways not described here but no less challenging to interpret.
PJ2 is offline