Flight Data Analysis: A Process in Progress

Air Safety Week, Feb 7, 2005

Since the early 1970s, when the first-generation digital flight data recorders emerged, airlines have realized the benefit of flight data analysis and have sought to extract and analyze flight data. However, extracting the data brought with it a host of problems; the recorder had to be removed from the aircraft and, once removed, the data had to be transferred to another medium. The exercise was a time-consuming one and often the data itself was corrupted in the process. The solution came in the form of Quick Access Recorders (QARs) that had a removable media and provided the airlines with a means to increase the parameters of data recorded by the mandatory flight data recorder (FDR).

The 1972 crash of the BEA Trident G-ARPI at Staines in the UK proved the value of QARs in assessing more than just the accident aircraft's story. It quickly provided across-the-board comparative operating data for the whole fleet. When a Qantas 747 overran at Bangkok, that QAR was spirited away by the airline as it sought quick answers to the mishap's origins. After the Sept. 2, 1998, crash of Swissair 111, it emerged that the MD-11 FDR sourced approximately 250 parameters, whereas the QAR recorded about 1,500 parameters. From both accident prevention and investigation perspectives, the QAR is a priceless tool in aviation safety. Since Jan. 1, 2005, an operator of an aircraft of a certificated take-off mass in excess of 27,000 kg must establish and maintain a flight data analysis program as part of its accident prevention and flight safety program (ICAO Annex 6). As the UK CAA has remarked, Flight Data Monitoring (FDM) is the "pro-active and non-punitive use of digital flight data from routine operations to improve aviation safety." That at least is the theory...

In spite of the progress made in making such data more readily available through the appropriation of the maintainers' QAR output, the battle to analyze operationally relevant data without compromising it is far from over. In a paper titled "Accident Investigation Without the Accident," Michael R. Poole (managing partner of Flightscape and a former Transportation Safety Board of Canada investigator) calls for "an integrated system whereby airlines can routinely access the data and in which the same data set is available to the accident investigator." He also highlights the fact that data analysis hinges as much on the software as the personnel operating it; i.e., do they have the requisite investigative skills? He cites the specific example of how data can be compromised by airlines that use Engineering Units (EU) or Comma Separated Variables (CSV) or Spreadsheets to pass data to their analysis/animation systems. He argues that due to the sheer volume of data, it must first be preprocessed by another application; hence what you are eventually seeing is an artifact of the recorded data instead of the real data. For example, a 64 word/sec rate would require the data printed out in 1/64 time intervals; this means that if you wanted to look at 25 hours of data, you would need 64 data lines for each second; in other words a spreadsheet 5,760,000 lines long.

As Thomas R. Chidester of the NASA Ames Research Center observed, we have "highly sophisticated data collection accompanied by very modest analysis." This problem emerged at the recorder level when it was discovered that the A300-600's FDR was so highly filtered that intermediate events could not be interpolated (i.e., the AA587 accident aircraft's rudder could have quickly swung another interim cycle, yet not been recorded). The current ethos is that data must be reliably complete -- both in the recording and the outputted interpretation.

Flight operational quality assurance (FOQA), the Federal Aviation Administration's (FAA) voluntary flight data monitoring program, reinforces some of the concerns expressed by Poole above. Advisory Circular AC 120-82 (April 12, 2004) titled, "Flight Operational Quality Assurance," (p. 7: FOQA Program Description) underscores the critical function of converting the data into "useable information" by use of a Ground Data Replay and Analysis System (GDRAS). A note in bold on p. 8 states:

"NOTE: The quality and capability of a carrier's FOQA program will be directly dependent on the number of parameters available. The carrier should see that sufficient parameters are available for collection from the acquisition device or FDR (see appendix A, Example of a FOQA Implementation and Operations Plan)."

The AC confirms (p. 16) that the average amount of FOQA data collected per digital aircraft is approximately 7.2 megabytes (MB) per day, resulting in 2.6 gigabytes (GB) per year. It later claims that, "Emerging technologies have the potential to increase the efficiency and effectiveness of all facets of a FOQA program. For example, newer data-capture devices may be able to record more parameters more frequently, the handling of recorded data may require less human intervention..." But you will recall that the over-reliance on software datacrunching was of particular concern to Poole (above).