What is a FRED File and why is it so Important?

(Note: This is an update to an article originally published on July 28, 2022)

As I was going over the list of blogs we have written recently, I was somewhat surprised that we have not spent much time on the FRED file, or the parameter data map. It was surprising because it is such an important part of flight data analysis.

If you need to look at the data stored on your Flight Data Recorder (FDR) or Quick Access Recorder (QAR) for any purpose, whether that is Flight Data Monitoring, FOQA, maintenance or accident/incident investigation, you are going to need the parameter  “data map” or “data frame”. It is THE critical piece of information needed to make sense of what is recorded in your flight data.

Many people are somewhat surprised to learn that flight data is stored on an FDR or QAR as a series of ones and zeros (a.k.a. “binary”). Once you have downloaded your flight data file, you cannot simply open the file in a program such as Word or Excel and start looking at altitude and airspeed. If you are particularly tech savvy, you might be able to open that raw binary data in a special software program, but it still will be of no use without the parameter data map.

So, what is the parameter data map or data frame?

The parameter data map is a, uh, “map” of where parameters such as “Airspeed” and “Altitude” can be found in the sea of ones and zeros that are in the flight data file. Without it, the data is fairly useless.

Flight data stored on most modern (civilian) FDRs or QARs is typically stored following one of two standards, ARINC 717 and ARINC 767. ARINC 717 is the older of the two and is still found in the vast majority of aircraft manufactured today. In fact, only a relatively small number of aircraft are using the newer ARINC 767 format, such as the Boeing 787 and Airbus A220.

It is well beyond the scope of this post to go into the details of ARINC 717 and 767, but the concept of the data frame is similar with both: data is stored as a series of ones and zeros so you need the data map to tell you how to “translate” that data into something useful.

If you are interested in learning more about the ARINC 717 standard, I posted a video a few years ago that describes it. The video is due for an update, but the information in it has not changed. You can see the video here:

So, again, whether you are looking to start a new FDM/FOQA program, you need to look at your data for maintenance troubleshooting, or you have an incident or accident investigation, you will need the parameter data map for your aircraft if you want to make sense of the data that is stored on it. It does not matter what software system you use or who the vendor is – you NEED the parameter data map. Your software vendor may already have it in their library, but it will still be a requirement to read the data.

Incidentally, despite what some think, the parameter data map is not a form of encryption. These data storage standards were devised many, many years back when memory storage was expensive and limited. In fact, ARINC 717 dates back to when the data was stored on magnetic tape. That’s right – magnetic tape.

Now that you know WHY you need, how do you get it?

Normally, the parameter data map can be found in Chapter 31 of the Aircraft Maintenance Manual. This would be a section of the manual that describes parameters such as “Airspeed” in terms such as “Words”, “Subframes” and “Bits”. For example, “Computed Airspeed” could be located in “Word 12”, “Subframes 1 to 4”, “Bits 3 to 12”. When you find information such as that, you have most likely found your data map.

Below is an example from an actual parameter data map document. This is from an older aircraft and it is just one section of many from the document, but this is an example of the information that you or your software vendor will need in order to understand how to read your flight data.

FRED and ARINC 767

Acquiring the correct data frame for an aircraft has always been a challenge. I have limited experience in accident investigation, but I have enough to have witnessed the frustration that seasoned accident investigators had in getting this information from aircraft operators, as well as some of the very serious fallout that can occur if the documentation is wrong.

One of the great “features” of the newer ARINC 767 standard is that the FRED file is actually included with the flight data when the data is downloaded. This was simply a brilliant, ingenious idea. If you are operating an aircraft using ARINC 767, such as the 787 or A220, you will have a much easier time locating your data frame – it is already part of your flight data.

However, the odds will be that your flight data will be stored in ARINC 717 format, so you will need to located your data map or data frame information.

Once you do find it, there are some things to be aware of:

Data Maps can be different across a fleet of similar aircraft.

For example, you could have four 737-NG aircraft, but all four could have completely different data maps. Although we have a fairly extensive library of parameter data maps here at Scaled Analytics, we always ask our customers to provide the data map for their specific aircraft. This will ensure that we are using the correct one.

Also worth noting is that there could be similarities between data maps and they might look the same for most parameters, but they might not be identical and there could be parameters that do not get converted correctly. This could be a BIG problem if safety or maintenance decisions are made based on parameters that look reasonable, but are not accurate.

Data Maps can have errors.

The data map is a document produced by a human and, like anything, is subject to errors. Thankfully, most data maps do not change much over time for a given aircraft type so they are reasonably well refined, but it is still possible to locate an error in the data map documentation.

When we find such an error here at Scaled Analytics, we make sure the manufacturer is notified so that it can be corrected and the data frame updated.

Again, this is quite rare, but it does happen occasionally. Keep that in mind if you run into a parameter that is programmed correctly but just does not look right. There could be an error in the documentation that the manufacturer missed.

Data Maps can be difficult to locate.

For the FDR, this documentation really should be included with the aircraft, but sometimes it is not – especially for older aircraft that may have changed owners over the years. You may need to work with the aircraft manufacturer to get the proper documentation for your aircraft.

If you are looking to recover data from a “programmable” recorder, such as a DAR (Digital ACMS Recorder, more common on some Airbus aircraft), it may just be impossible to locate the correct information. These recorders are “non-regulated” and can be programmed to the operator’s specific requirements (a topic for a future post).

But, unlike the FDR, there is no requirement (that I am aware of) for meticulous record keeping of how the data map was programmed on a DAR. If you have an older aircraft that went through multiple previous owners, the information may be lost forever, in which case you either need to reprogram the unit or use the data from the FDR.

Who or What is FRED and Why Should I Care?

And this brings us to the FRED file.

Once you have located the parameter data map, the information contained in that document needs to be entered into your data analysis software so that it can be used to convert your raw data, as explained above.

Like any technology, there are a number of different software packages that are commercial available for analyzing flight data. Some are specialized for Flight Data Monitoring and FOQA, while others just focus on flight animation. Others still are highly specialized to meet the more unique requirements of accident investigators.

The challenge with this is that many software vendors have their own proprietary formats for storing the information in the data frame. If you are old enough, think of the days when you could not easily open a Word document in Wordperfect, or vice versa.

Today, we take this type of thing for granted because we have robust file converters and industry standards. Think, “PDF file” if you consider the word processor example above.
But in the flight data analysis world, there was no standard. For the typical FDM/FOQA user working only with Software Company XYZ, this was not really a problem. However, it did become a problem when there was a serious incident or accident that required investigation by governmental accident investigators and aircraft manufacturers.
They, almost exclusively, use software that is specialized for accident investigation; not FDM/FOQA. Incidentally, it is not fair to say that accident investigation software is “better” or “worse” than FDM/FOQA software. Each user has unique requirements that are better served by specialized software. The software is really just “different” much like a pickup truck is different than a two door sports car. It is difficult to say one is better than the other.

At any rate, the issue that the investigators had was that, when it came time to investigate an incident or accident, the data frame was available in the operator’s FDM/FOQA system, but it could not easily be read by the accident investigation software. Coding these data maps takes considerable time. Having them readily available would significantly reduce the time required to complete an investigation.

To combat this, a working group made up of experts from investigative bodies, aircraft manufacturers, and industry got together and established the Flight Recorder Electronic Documentation standard, or FRED. You can think of this as the PDF version of parameter data maps. No matter what software system an operator uses for FDM/FOQA, if they can export it to FRED format, it can be exchanged easily with investigators.

At Scaled Analytics, we have adopted the FRED format for our software system. We do not use a proprietary format that many of our competitors do. This is not a poke at our competitors. Our software is relatively new compared to some of the other systems on the market and the FRED standard simply was not available when they designed and built their systems.

There were also limitations in early iterations of the FRED standard. Developers had no choice but to use a proprietary format to get around some of those limitations to handle things such as custom functions.

Today, however, we here at Scaled Analytics are big fans of the FRED file. It is not perfect (nothing is), but it offers quite a bit of flexibility without sacrificing portability. So far, it has been able to handle everything we can throw at it.

It is an XML file, so you can open it in any text editor if you wish. This is great for power users, but if you are not familiar with XML, or if you just need to make minor edits, we also built a FRED Editor that has a user-friendly interface.

XML can be intimidating, but for experienced analysts, working in a text editor such as this can significantly shorten the time required to develop a new FRED file.

If using a text editor is overkill for you, our FRED Editor makes working on FRED files much easier.

Let’s keep in touch