4
$\begingroup$

For analysing the FDR, data is downloaded to the local computer from the FDR and feed into the Analysing Software. I would like to know what is the file extension of the data stored on the FDR. I came to the conclusion that it must be csv for storing all the data about Height, longitude, latitude and so on. Then this .csv file is feed into the Analysing Software for analysing. But I am not sure if I am correct.

$\endgroup$

closed as too broad by mins, kevin, Ron Beyer, Simon, Firee Mar 26 '16 at 6:28

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    $\begingroup$ it's a custom proprietary file, it's more likely is that it's a densely packed binary file than that they included text processing in a safety critical application. $\endgroup$ – ratchet freak Mar 23 '16 at 14:19
  • 1
    $\begingroup$ To expand on what ratchet is saying, the FDR is not a "Windows" or probably even Linux based operating system. It doesn't take the feeds from the sensor inputs and save it to a standard human readable file. The data is probably stored in circular non-volatile buffers on the FDR and a proprietary software is used to read the buffered data out. The software that reads it then places it in some sort of Windows/Linux file format which I'm sure can be converted to something human readable. Its certainly not stored on the FDR that way though. $\endgroup$ – Ron Beyer Mar 23 '16 at 14:22
  • 2
    $\begingroup$ You might want to rephrase this to ask "what data file format is used by FDRs?" or something similar. You seem to be assuming that the files are in a 'typical' delimited text format, but it looks like it's a lot more complicated than that. $\endgroup$ – Pondlife Mar 23 '16 at 14:24
  • 3
    $\begingroup$ You could, yes, but if you really sat down and thought about how the data comes in and how you have to only keep X minutes worth of data in a finite storage, CSV becomes a lot less practical. When working with embedded systems its a lot easier to work with the memory directly than to try to make a human readable file format that doesn't need to be human readable. Its not like they plug an FDR into a computer and it shows up as a flash-drive. $\endgroup$ – Ron Beyer Mar 23 '16 at 14:46
  • 2
    $\begingroup$ I see VtCs, but I'm not sure this is unclear or too broad. The OP is making some assumptions that we all seem to feel are incorrect, but the comments/answers should serve to correct those misconceptions. Unless different FDR manufacturers use different data formats (entirely possible), I wouldn't think it's too broad. If that's the case it could be narrowed easily by specifying the manufacturer(s) he's interested in. /my 2¢ worth $\endgroup$ – FreeMan Mar 23 '16 at 20:45
7
$\begingroup$

The builders of an FDR must comply with DO-178C (the older DO-178B may also be of interest here) as per AC 20-141B issued by the FAA. These documents do not specifically define a data format but provide requirements for what it must be resilient against. Here is an interesting research paper that covers some of the topics you are asking about. Since most avionics use ARNIC 429 as their standard of communication some FDRs provide ARNIC 429 inputs to record the avionics instructions at the time. I would assume these inputs dump the bus data right to the storage medium (most likely solid state memory these days). Since the formats the device uses may be proprietary as well as very low level (and memory efficient) I am sure they make software to dump it to other formats. For example L3 makes a full unit for their FDRs.

After some more searching I found what may be the most comprehensive answer from this Boeing summary document

What Is a Data Frame?

A flight data recorder (FDR) data frame is the order of the words that are transmitted from the digital flight data acquisition unit (DFDAU) to the digital FDR (DFDR) each second over many seconds (see ARINC 717 for additional information). Most FDR system data frames are made up of four subframes within one superframe. For a 64-words-per-second (wps) FDR system, a DFDAU will output 64 12-bit words to the FDR each second, where each word typically contains the value of an analog parameter. The order of the words (for example, word number 12 of the 64 words) within a subframe, as well as the order of the subframes, define an FDR data frame. This order is important to understand in order to decode the data recorded in the DFDR.

It should also be noted although they may have all been phased out by now, some older cockpit voice recorders and FDRs recorded on analog mediums and may still be inservice doing so.

$\endgroup$
4
$\begingroup$

We can use inductive reasoning to make a guess at a probable answer to your question.

Your premise:

I came to the conclusion that it must be csv

is likely wrong.

The only purpose of a CSV file is to transfer data between a source and a sink which do not understand the way in which the other stores data.

An FDR does not need to be understood by any other sink other than the manufacturer and/or incident investigators.

Adding the ability to store or retrieve data in a CSV format would add some complexity, through additional problems to solve, which is simply not needed.

All that is required is a method to extract the raw data and display it in a format that humans can understand. This is trivially done with a piece of custom software.

The designers will have no requirement to provide data in any format other than that required by the extraction software so they simply won't implement it.

CSV, and other data interchange format files, all have limitations. They lose resolution, they are inefficient in their use of resources and only exist to work around problems introduced by a lack of standards, differing interpretations of standards and attempts by commercial, general purpose software vendors to differentiate themselves or make it more difficult for systems to interoperate.

We can therefore reasonably conclude that an FDR does not store data in a CSV file. Of course, the custom software which does extract the data might contain such a feature but then again, why would it?

$\endgroup$
  • $\begingroup$ Of course, the custom software which does extract the data might contain such a feature but then again, why would it? because once you extract the data you want to save several copies and a format easily readable by most programs offers the lowest possible barrier to the advance of the investigation? $\endgroup$ – Federico Mar 23 '16 at 21:22
  • 1
    $\begingroup$ @Federico Why? What requirement is there to do so? Even if we accept that there is such a requirement, there are more effective common file standards for the kind of data an FDR stores such as tab delimited, JSON etc. but they all have significant limitations. If you asked me to design this, I would simply use a proprietary, raw data format and make the consumer software easily available to those who need it - with graphical plots, flight simulator feeds etc. I wouldn't care about 3rd parties since they are not the consumers of the data. $\endgroup$ – Simon Mar 23 '16 at 21:30
  • 1
    $\begingroup$ I can't imagine other than early in an investigation the data from the FDR will be converted to a variety of formats, including csv (for easy loading into spreadsheets), whitespace-separated unixy files (for ad-hoc analysis with a scripting language), and possibly others. Which of these particular formats comes out of the vendor's reading step is not really important; it is easy enough to interconvert between them. $\endgroup$ – Henning Makholm Mar 23 '16 at 22:13
  • $\begingroup$ Something additional: Critical data contain a mean of integrity verification (CRC-like). The storage space will be managed in binary form for speed and space efficiency, not in a human readable form for the reasons explained (and a boolean flag won't waste a byte). It is not sure data will be linearly stored, as EEPROM cells are limited to a certain number of writing cycles, so the need to optimize where a byte can be stored That should be more similar to chained allocated buffers (malloc-like) than to file records. $\endgroup$ – mins Mar 24 '16 at 0:35
  • $\begingroup$ Simon, I've answered you in chat, if you would like to pass by: chat.stackexchange.com/transcript/message/28471647#28471647 Also, have a look at the question linked by Shalvenay just below. $\endgroup$ – Federico Mar 24 '16 at 7:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.