Where flight data comes from: FDRs, QARs and readouts

An FDM programme only works if the data arrives. Before a single event is detected or a trend is plotted, something on board has to record the flight, and somebody has to get that recording off the aircraft and into a form an analyst can read. For a safety manager starting a programme, or inheriting one, that chain is worth understanding end to end, because almost every practical problem in flight data monitoring starts somewhere along it.

This article walks through the chain in order: the recorders on board, how they store what they record, how the data leaves the aircraft, what an FDM provider does with the raw file, and what to have ready when you first talk to one.

What is the difference between an FDR and a QAR?

The flight data recorder (FDR) is the crash-protected recorder, the one the public calls the black box. Its purpose is accident and serious incident investigation, so it is built to survive impact, fire and immersion, mounted where it is most likely to be recovered intact, and required to record a defined parameter set for a defined period. Everything about it is designed for one rare, difficult event.

That design is the reason the FDR is a poor day-to-day data source. Getting a recording out of one is a maintenance activity: it needs ground support equipment, an engineer, and on many installations a physical connection to the unit on the aircraft. Operators do it, but not often, and not casually.

The quick access recorder (QAR) exists to solve exactly that problem. A QAR is not crash protected and carries no investigative duty. It sits on the same data stream as the FDR and writes to media that is meant to be removed, copied and put back, often with more parameters and higher sample rates than the mandatory set. A digital ACMS recorder plays a similar role on aircraft where the maintenance system provides the recording function.

On most installations the two recorders are fed from the same place. A flight data acquisition unit (FDAU), sometimes called a flight data interface unit (FDIU), collects parameters from aircraft systems and produces one data stream, which is routed to the FDR and to any QAR fitted. That shared source matters later, both for data quality and for what a regulator will accept.

How is flight data actually recorded?

Recorded flight data is not a table of named values. It is a repeating frame of binary words, and the position of a word in the frame is what identifies the parameter. ARINC 717 is the long-standing industry standard for this kind of frame-based recording, with one-second subframes grouped into frames and slower parameters spread across superframes. ARINC 767 is the more recent standard used on newer types, where the recording path is built on Ethernet rather than a serial stream. Which of the two applies to a given aircraft depends on its generation and on how its recorders are installed.

The important point for a programme is that these standards define the container, not the contents. Which parameter sits in which word position, how it is scaled, and how a raw count becomes a value in knots, feet or degrees is described in a document specific to your aircraft and its recorder configuration, usually called a data frame layout. Without the correct layout, a perfectly good recording decodes into nonsense. With it, the same file becomes altitude, airspeed, attitude, thrust and configuration over time.

This is also why two aircraft of the same type can need different handling. A fleet acquired from different sources, or modified at different times, can carry different acquisition units and different layout revisions. Recorder configuration, not just aircraft type, is what determines whether a file can be read.

How does the data get off the aircraft?

There are a few routes, and most operators end up using more than one.

The traditional route is removable media. A PCMCIA card is taken out of the QAR by a crew member or an engineer, the contents are copied, and the card goes back. It is simple and it works, but it depends on someone being there, and the media itself can fail or be misplaced.

A wireless quick access recorder removes the manual step by transferring the recording over a wireless network after landing. Adding a wireless QAR alongside the recorder system is a common mitigation for the risk of losing flight data, because retrieval no longer depends on a person visiting the aircraft with a card.

Some operators go one step further and have flight data delivered into their FDM system automatically after landing through an integration with an onboard data service, so analysis starts without a manual download at all.

The FDR itself is read out far less often, usually for a recorder serviceability check or an investigation, and normally by maintenance rather than by the safety department.

Whichever route you use, the download interval is a programme decision rather than a technical detail. It sets how fresh your data is when you look at it, how long an emerging trend stays invisible, and how many flights you lose if a card or a unit fails between downloads. Setting a download period that matches your actual data accumulation and your readout capacity is one of the flight data monitoring best practices worth revisiting as a fleet grows.

What does an FDM provider do with the raw file?

Once the raw file reaches a flight data monitoring service, the work is decoding, splitting, measuring and checking, and it is largely automated. With AeroSight FDM you upload an FDR or QAR raw file, and the automated process detects all legs in it, extracts all parameter values converted into engineering units, and performs event detection.

Detection is not the end of it. Data reliability is based on data quality analysis and a parameter check report, which is what tells you whether a parameter was actually recorded as expected rather than silently missing or stuck. A reviewer can then work through the detected events with their correlated parameters and reject inappropriate ones, and once a readout report is accepted it becomes part of the statistics. That sequence, get the data off the aircraft, turn it into readouts and events, validate what was found, and act on it, is the same whether you operate one aircraft or a hundred.

The same decoded data feeds the rest of a programme. Crew-related analysis in pilot performance monitoring and the engine parameter snapshots used for engine condition monitoring both come out of the same readouts, which is another reason the quality of the original recording matters so much.

Does an FDM programme help with recorder serviceability?

It can. European rules require an operator to maintain the serviceability of the flight recorders through operational checks, and the associated acceptable means of compliance recommends an annual inspection of the FDR recording. Where the aircraft is subject to an FDM programme, that inspection can be relaxed under conditions: the data source of the FDR mandatory flight parameters and of the FDM data has to be the same, the FDR has to be fitted with reliable built-in test equipment, which most solid-state FDRs are and magnetic tape FDRs are not, and the integrity of the FDR mandatory parameters has to be monitored by the programme.

That is a practical argument for treating data quality reporting as part of the programme rather than an extra. The detail, including the ICAO, EASA and FAA framework and the changes already scheduled, is on our FDM and FOQA regulatory requirements page.

What should you tell a provider first?

Start with your own aircraft type and recorder configuration. AeroSight has run flight data monitoring programmes across more than 40 aircraft types, so those two facts, together with how you get data off the aircraft today, are enough for a useful first conversation about what your recorded data can show you and what a data frame layout for your fleet involves. Everything else follows from there.

Flight data monitoring is often described as an analysis problem, and the analysis is the visible part. The part that decides whether a programme is trusted is further upstream: a recorder that is working, a layout that matches it, a download habit that does not lose flights, and a check on every file that says whether the data behind a finding was really there.