A320 FOQA data [Archive]

PJ2

23rd Apr 2009, 20:46

Bagot_Community_Locator;

All very good questions.

To begn, there is no such thing as "FOQA" data. There is only flight data which is recorded by the DFDR and, where installed, the recorders associated with the FOQA installation & program. The data today is almost all digital and is taken off the ARINC 429, 629 & 717 standard data busses, (google ARINC databusses for a full description of these ARINC standards).

A simplified explanation may further assist understanding; the ARINC busses send huge amounts of data between system services, flight controls, instrumentation, secondary computers etc etc. The wiring is the spinal chord of the airplane, so to speak.

Not all data goes to the DFDR - it is not a magic box that records everything when installed. There are required parameters as set by the state of registry of course, and then there is NTK data...Nice To Know.

The following applies to either the DFDR or the FOQA recorder, usually known as a QAR or Quick Access Recorder, which is usually mounted within the actual recorder known as a FDIMU/FDAU, or Flight Data Interface Management Unit and Flight Data Aquisition Unit. You can google these terms to learn more.

For any flight data recording device, DFDR or QAR, for data to be "seen" and interpreted, the engineering data stream (0's, 1's) from the ARINC data busses must be captured; to accomplish this, a data frame or LFL, (Logical Frame Layout) is created in software designed for this job. This frame, depending upon design, available memory space and processing power, fills a typical data frame of 256 or 512 rows by (usually) four columns, something like a spreadsheet.

If you think about it, this answers your first question on data accuracy.

However, a very large mistake that operators can and have made, is to assume that "FOQA" data is of "lesser quality" than the more "robust, government-sanctioned" DFDR but that is not the case at all. In fact, because the QARs are dealt with on a daily basis and because they typically are designed to capture far more information and at higher frame rates (8x, 16x per second, etc), they are generally far more informative than the typical crash recorder. Operators assume too, that data is, for some misunderstood reason, "less accurate". Indeed, if an airline is making operational or commercial decisions based upon the assumption that FOQA data is somehow "less accurate", they are making a fundamental and potentially high-risk error.

Accuracy or inaccuracy is not resident in the data-collection systems; it is, if resident at all, in the sensors, in terms of pure operational capability and robustness as well as, in some cases (g-loading, for example), location on the aircraft. The 'g' parameter on the 777 for example is known for inaccuracy both at the DFDR sample rate of 8x per second and the QAR rate (in most designs) of 10X per second. The data is "spikey" and it seems as though it is the location of the sensors, (cockpit overhead) that is the problem. Lateral 'g' load is another issue which requires some careful thought, especially where it concerns the vertical stabilizer: the yawing moment about the center of gravity of the aircraft can quickly impose high lateral loads on the vertical stabilizer but if the sensors are located at the center of gravity and not near the nose or tail, the sensed lateral 'g' load would have to be mathematically calculated at the very least, as "lateral movement" left or right where the entire longitudinal axis of the aircraft moves laterally without yawing, though uncommon, is differently sensed.

Data character.

Data can be in the form of a discrete, (yes/no, on/off, open/closed etc), or in the form of rates-per-time unit, in the form of position in terms of degrees, or arbitrarily assigned numbers, and in the form of temperatures, pressures and finally in the form of text strings.

It's all zeros and ones, even the text messages which appear on the 320's FMA, and ECAM displays. LFLs for crash recorders and FOQA recorders can be designed to interpret such data as text strings. The letters themselves are not in the data in terms of letters being on the databus; rather, a data string which is sent to the ECAM display is associated with the displayed text on the ECAM; that association-data is assigned a "text string" within the FOQA LFL, once again simply because the letters themselves don't exist in the data - it is engineering data that is sent to the DMU's (Display Management Units) for each of the six screens, not actual text/letters. The LFL must interpret the signals and be programmed with a look-up table of text strings to display the correct one for the airline's FOQA Program data output.

This answers a couple of your next questions about timing. Do things happen (are they displayed/recorded) at the same time they occur?

That is an excellent question and one which is again universally badly understood by almost all airline managements.

"Flight data" is "stroboscopic" in nature. Let me explain. It doesn't have recording rates which are equal to present-day recording video rates of, say, 26 frames per second, etc. While it would be absolutely ideal to record flight data at that rate, the present cost of doing so is prohibitive as well as, most of the time, unnecessary.

So it should be clear now, why flight data is described as "stroboscopic". Each LFL is "turned on" once per second and the dataframe filled with the data that is picked off the ARINC busses. The data is a once-per-second snapshot and not a moving photograph/video/film of flight data.

So, not only will expected timings be "off", (not available), but the position of, say, a control stick or flight control, cannot be known the exact degree/position when the data is not being recorded, (in between snapshots).

This is as true for DFDRs as it is for FOQA QARs. In fact, as described, FOQA QARs are much more detailed in terms of the number of parameters recorded and the times per second such parameters are recorded. For example, vertical 'g' may only be recorded by the crash recorder every quarter of a second, whereas a QAR may record it 8, 10 or even 16 times per second. This is important, because 'g' spikes in sudden events can spike and then look "normal", in between recording events.

There are no "Airbus computer issues" that do not also exist on Boeings and other manufacturers - it is the nature of computers, databusses and recording mediums etc, not the nature of "Airbus" aircraft that is the issue. Other than that, I can't quite understand what you mean by "Airbus computer issues", perhaps you could clarify so I can respond? The "lag" or "the way it is set up" is described, though very simply, in the above paragraphs so hopefully this leads towards an answer for your third point.