Data in flight recorders is stored in crash-protected memory. But when a recorder is recovered from an accident scene, it can take weeks to decipher what the data means-to translate it into useful information. Investigators may have to acquire a paper "map" of the data stored in an aircraft’s recorder and key the translation information manually into their readout and analysis systems. Although there are some rough guidelines, such as the Federal Aviation Administration’s (FAA’s) Advisory Circular 20-141, no real standard exists regarding how or what parameter "decoding" information should be stored. (A parameter is a flight data element, such as altitude, airspeed, engine thrust, propeller speed or throttle lever position. More than 1,000 parameters can be recorded in new flight data recorders.)
In the past, there "has been great difficulty in investigators’ being able to rapidly access the parameter database information," says Frank Doran, vice president of engineering for L-3 Communications’ Aviation Recorders unit. The information may be difficult to locate, or "changes could have been made to the aircraft that have not been reflected in the [documentation]."
Accident investigators, aircraft operators and avionics suppliers all would benefit from a more standardized approach to decoding flight data. Engineers at Transport Canada took the first step toward this goal some years ago. They came up with the idea of a standard electronic formatting guide, known as the Flight Recorder Configuration Standard, or FRCS. Manufacturers using the standard would provide a file that could be used to interpret recorded data values and as an input to an automated replay system.
Several avionics manufacturers adopted the standard and provide documentation using the FRCS format. Teledyne Controls, for example, generates FRCS files for its new data acquisition units, says Armen Nahapetian, the company’s vice president of engineering. The FRCS file "documents what data we are sending to the recorder, how many times per second we’re sending the parameters, how many bits each parameter has, and what the engineering unit conversion formula is," he explains. L-3 Communications also supports FRCS compatibility with its flight recorder data display software.
Since Transport Canada is not a standards body, it decided to turn its work over to the Airlines Electronic Engineering Committee (AEEC), to be converted into an internationally applicable ARINC standard. Work on what’s known as ARINC Project Paper 647 began last year within the Flight Recorder Electronic Documentation (FRED) group under the Digital Flight Data Recorder (DFDR) Subcommittee. The first draft of the ARINC 647 document was completed in January 2004. The final standard is expected next year.
What is FRED?
The best way to describe FRED is to say what it will enable. The ultimate goal is to convert a recorder’s output into usable parametric information for ground replay systems. FRED will provide a standard means of "information interchange"-a standard data conversion file format.
The guideline will allow users who need to play back data from a compatible recorder to see it displayed on a screen in engineering units-feet, knots, etc. Users range from accident investigators at the National Transportation Safety Board (NTSB), to airline maintenance departments viewing maintenance or incident data, to airline safety departments looking at flight operational quality assurance (FOQA) data. Manufacturers of flight recorders, maintenance recorders and data acquisition units will provide FRED-compatible software modules for different equipment models. The modules will convert company-specific, internal data formats to a standardized, FRED presentation that is machine-readable and more easily decipherable by humans (using a text editor), when necessary.
"FRED will describe a consistent method of defining what’s in a recorder," explains Dan Martinec, secretary of AEEC’s DFDR Subcommittee. Manufacturers in the future will use an ARINC 647-type file, rather than a piece of paper or a spreadsheet, to convey that information to users. Since all these electronic files will be formatted identically, ground replay systems can be programmed to automatically decode the information in a standard way.
The specification will adopt a standard syntax and naming conventions, says Stylian Cocalides, vice president of Avionica. His company makes quick access recorders and provides flight data analysis software and services used by airline maintenance departments to play back flight data. Each manufacturer will write "import" and "export" software routines that convert its proprietary database format to the common FRED format, he says. The formatting also needs to be both forward- and backward-compatible, so that new readout software can understand old FRED files, and old software can read new files.
Impact on Data Acquisition
"FRED also will simplify life for the operators," Nahapetian says. "They won’t have to maintain different documents in different formats for the recording systems that they fly. A single file in a standard format will be kept for each recording system." The standard will be important to data acquisition unit manufacturers because their equipment puts the data in specific locations in the data stream, thus determining how ground replay systems retrieve the data and apply engineering unit conversion algorithms. Data acquisition unit manufacturers will start generating FRED files once the standard is published, Nahapetian says.
The points of discussion in the FRED group are fairly technical and include:
-
The syntax and length of a FRED file,
-
Which parametric elements have to be in a file vs. which elements can be considered optional, and
-
Which naming convention should be used to describe each stored parameter.
There is also strong interest from the accident investigation community in being able to store the "decoder ring"-the FRED file-in the flight recorder. The file could be stored in the data acquisition unit and then transferred to the flight recorder on power-up, if needed. But doing this would be a problem with current equipment. Current data acquisition units would have to be modified, and a higher-bandwidth link between the acquisition unit and the recorder would be required-changes that the airlines are unlikely to adopt on existing aircraft.
But the goal of storing FRED files in onboard equipment makes sense and may be adopted in the next generation of multipurpose aircraft recorders. AEEC’s DFDR Subcommittee is addressing this issue in its work on ARINC Project Paper 767, which defines an enhanced recording system for future airplanes.
COMPANIES
Aerospace Monitoring & Systems Ltd. www.ams.co.za
Ampol Systems www.ampol-tech.com
Avionica Inc. www.avionica.com
Demo Systems www.demosystems.com
Honeywell www.honeywell.com
Kaman Aerospace Corp., Memory Systems Division www.raymond-engrg.com
L-3 Communications www.l-3com.com
Meggitt Avionics www.meggitt-avionics.co.uk
Muirhead Avionics www.muirheadaerospace.com
Penny & Giles www.pgcontrols.com
Photo-Sonics Inc. www.photosonics.com
SFIM Inc. www.sfiminc.com
Smiths Aerospace www.smiths-aerospace.com
SPACEAGE Control Inc. www.spaceagecontrol.com
Spirent Systems www.spirent-systems.com
Star Navigation Systems Group www.star-navigation.com
Systran www.systran.com
TEAC America Inc. www.teac.com
TEAM Inc. www.team-avionics.com
Teledyne Controls www.teledyne-controls.com
Thales Avionics www.thalesgroup.com
Universal Avionics Systems Corp. www.universalavionics.com
Vista Controls www.vistacontrols.com