FDC
Meet Fred
Dave Jesse on October 20, 2014
0

Let me introduce you to Fred.

imagefred

Well, OK, not Fred Astair, famed dancer and partner to Ginger Rogers; I am talking about Flight Recorder Electronic Documentation (FRED). To make matters worse, it is also known as ARINC specification 647. Didn’t take long to get from fun to dull, but that’s work.

For the kids out there who don’t know what I am on about, have a look here for a classic piece of cinematographic entertainment.

FRED’s Origins

Now, the origins of FRED go back many years to a time when the flight data industry started struggling with the problem of too many different formats of FDR recordings. Both operators and accident investigators were finding it progressively harder to manage recovery of data from the various FDRs. Following an accident the investigators always want to get the “black box” replayed as quickly as possible and when the data format is not known, delays are at best infuriating and at worst may delay release of safety bulletins.

The idea was developed by Transport Canada who, in 1998, proposed a Flight Recorder Configuration Standard (FRCS). This defined a configuration file that would identify how to decode the recorded data. The configuration file format would be standardized and anyone with the FDR data and appropriate configuration file could extract the data in an instant.

The standard was raised in issue and then formed the basis for the FRED specification which was released in 2009.

Solid State Recorders

In the same year, the standard for an Enhanced Airborne Flight Recorder (EAFR) was released as ARINC 767-1. This specified a new format of data recording, allowing data, voice, video and other sources to be recorded in a flexible format. It also called for the FRED configuration file to be recorded in the EAFR, so the configuration file would be recovered alongside the crash protected data and recovery would be possible as soon as the black box arrived back with the investigators.

So all was well, and nothing could go wrong.

What Went Wrong

The first aircraft to carry an EAFR is the Boeing 787 and FDS were quickly able to adapt to using this complex new FRED configuration file and the ARINC 767 data format.

We have also used FRED to document existing ARINC 717 data frames. From these experiences we can identify some problems. None of these is insurmountable, and to be realistic, they reflect the teething troubles of a new standard, but let me illustrate some of the things that have gone wrong.

Incomplete Specification

When it came to using FRED to record the configuration of existing ARINC 717 FDR formats, it became evident that there was no mechanism for combining multiple words into a single item. For example, pressure altitude is normally recorded in two words and “glued” together somehow to get a parameter with better resolution than would be possible if we used a single 12-bit word. The same applies to latitude and longitude, and to many Binary Coded Decimal parameters.

To get around this limitation, Flight Data Services have developed extensions to the format which we hope to publish so that they can be used by the industry as an extension to the standard.

Human Error

This new standard does not solve the problem of human error. In old paper-documented systems, the error would be found in the FDR documents – indeed almost every specification we have ever seen contains at least one error. Now, we have the same human errors reflected in the FRED XML file.

As an example, the scaling for the latitude and longitude is slightly in error as someone appears to have used too few decimal places when calculating the scaling factor.

The snag is that when an error is found in a paper document, it is straightforward to configure the data extraction correctly. However, when there are errors in the FRED XML file provided by the aircraft manufacturer, it is not practical (and probably not legal) to edit the file. The solution we have adopted is to add a second stage of post-processing to correct the errors, but this negates the purpose of the FRED file.

While this should not be a surprise, it is still a disappointment and the goal of a “plug and play” system is still beyond our grasp.

A Final Whinge

The FRED file is defined as being written in eXtensible Markup Language (XML). Now, I have to pin my colours to the mast and declare that I am not a fan of XML. I prefer key-value INI style formats, as I think it is easier to read.

Let me illustrate with same definition of airspeed in XML format and in the Flight Data Community LFL which is in INI format:

data

I rest my case.

TTFN

Dave