Is the raw data fetched from the FDR available only in binary format and if so what are the software tools that are used to convert it to readable format?
To simplify explanations:
- FDR: flight data recorder (flight parameters),
- DFDR: digital FDR,
- CVR cockpit voice recorder (audio recording).
In commercial aircraft, aside the mandatory FDR/CVR used by investigation agencies (the scope of the question), there are recorders used for maintenance and operational purposes by the operator. The progress made around these additional recorders influences the regulation around the mandatory recorders.
Short answer to the questions:
Sensor data are collected by a central acquisition unit which, for commercial aircraft, is compliant to standards, e.g. a digital acquisition unit will be compliant to ARINC 717 and use the frame format from the standard.
Data are then distributed to other units under this format, this directly influences the format used by recorders. Today most FDR store data as bits in a digital memory or a on long term media (e.g. optical disc). The FDR required by regulation uses a crash-resistant digital memory.
Since a few years, recorded data format can be described using ARINC 647A specifications in an XML file, known as FRED file. This file simplifies FDR data exchange and interoperability, a current requirement for aircraft parameters monitoring and analysis using products from different manufacturers/editors.
A FRED file can also be stored along with data, and as a matter of fact, mandatory FDR regulation now requires the FRED file to be embedded in FDR.
Readout hardware/software is provided by the recorder manufacturer.
As mandatory and non-mandatory recorders from a given manufacturer are susceptible of using a common format, readout devices are usually combined with monitoring and data analysis software.
Quite surprisingly, there is no mandatory format for storing flight data. International regulations don't require or recommend a specific scheme. They only require data to be provided to the aeronautical authorities in a timely manner if an investigation has to be carried out after an incident/accident.
ICAO Chicago Convention, annex 6 states:
126.96.36.199 In approving the means to make flight recorder data available in a timely manner, the State of the Operator shall take into account the following:
a) the capabilities of the operator;
b) overall capability of the aeroplane and its systems as certified by the State of Design;
c) the reliability of the means to recover the appropriate CVR channels and appropriate FDR data;
d) specific mitigation measures.
ICAO member States implement this international requirement, by requiring a documentation describing how data were calibrated and converted for recording and how to read them back. The related documents are known as Data Frame Layout and Conversion Data. E.g. for the US this is found in FAR 125.226:
Documentation sufficient to convert recorded data into the engineering units and discrete values specified in the applicable appendix must be maintained by the certificate holder.
and more details for DFDR in AC 20-141:
The data stream must be correlated to EU or to discrete states for an accident investigator to use the data. This appendix provides the specific information that operators must provide to the NTSB investigators decoding and converting the raw data stream recorded by the DFDR. This data format information can be contained within an electronic file or in hardcopy document format.
The description of the data frame layout and conversion method encompasses:
- The origin of the recorded parameter, and any computation done
- The method used for parameter calibration
- The method used to encode the value of the parameter
- The unit used.
- The method to be used to convert recorded values into readable values.
In addition there are requirements about the certification of the mandatory recorders themselves, for most countries, the acceptable means of compliance directly or indirectly (e.g. via TSO-124 wrapper) refer to EurOCAE Document 112A (ED-112A) Minimum Operational Performance Specification for Crash Protected Airborne Recorder Systems.
Recording format is influenced by the FDAU
Overall, data are recorded in any efficient format, not a user readable format. Data are compacted as much as possible to save memory and volume requirements of the crash survivable memory unit (CSMU), because of the cost of making this unit highly reliable and protected from the effects of an accident.
On large aircraft, parameters are collected by a flight data acquisition unit: Analog FDAU are compliant to ARINC 573 and digital DFDAU to ARINC 717). Digitalized data can be distributed to other avionics units using a local area network, e.g. the common ARINC 429 LAN. Units receiving data include cockpit displays, ACARS, and mandatory and non-mandatory recorders.
Is the raw data fetched from the FDR available only in binary format?
If we refer to large commercial aircraft, the answer is yes. Using ARINC 429 LAN already means data have been digitalized and streamed over the bus according to a well documented format. The FDAU choice greatly influences in practical how data will be recorded. It is easier to design a DFDR aligned on DFDAU ARINC 717 stream. ARINC 747 is an alternative with data compression for solid state memory.
ARINC 717 DFDR
The logical choice of the DFDR manufacturer is to use ARINC 717 both for a mandatory FDR and the various maintenance recorders. In this standard, the recorded data stream consists of a frame with four subframes.
Each subframes is recorded at the rate of one per second, and contains a certain number of bits grouped into 12-bit words. The actual number of words depends on the need, hence on the aircraft. The cycle repeats after 4 seconds.
DFDR data example: Magnetic heading
Delays are to be taken into consideration, sensor output from the IRU takes some time to get to the recorder, this must be described by the manufacturer as part of the information needed for the recorded parameter readout:
Source CAP 731
Data transits on ARINC 429 bus identified by label 320, a BNR data:
While no recording format is mandatory, the data sampling rate is critical: Transient values may be invisible if sampling is too slow. Therefore regulation mandates sampling rates.
A given parameter may appear only in some subframes, due to its sampling rate, and specific frames (superframes), recorded once per 64 seconds, are used for parameters which vary very slowly (e.g. gross mass). Examples of sampling rates:
Data is recorded at some location in the overall framing of the FDR, this location is a choice of the DFDR manufacturer. For non-mandatory recorders (e.g. Quick Access Recorder, QAR) recorded parameters are chosen by the operator, as well as their location in the frames. For our example:
Last but not least, the documentation describes how the recorded value must be processed to get the original parameter value and unit:
Heading Degree = 0.1758 x FDR Count (11 bit) - 180
Compliance to regulation
In spite of regulation, there are cases where data layout is unknown, e.g. BEA, the French investigation agency noted for a case:
The operator was not able to provide the BEA with any data frame layout documents. A list of recorded parameters and their allocation in the data frame was obtained, but the conversion equations and the calibration reports were missing. The FDR data could not be analyzed.
(Flight Data Recorder Read-Out, §188.8.131.52)
In the same document you may read other cases where the FDR data readout has been difficult or impossible.
The mandatory data frame layout and conversion method documents can be embedded into the FDR, to facilitate the readout and produce a file which can be understood by any compliant software. There is a standard for the documentation: The Flight Recorder Electronic Documentation (FRED) which is described in ARINC 647A.
There have been cases where the missing documentation prevented data interpretation (see below), but since 2016 and ED-112A, the FRED file must be carried in the recorder itself with the data, to ensure the data decoding.
What are the software tools that are used to convert it to readable format?
FDR manufacturers provide the tools required to read out data, based on their own recording techniques. Readout is done using simple hardware/software.
Readout is facilitated by reusing the embedded FRED file or using an external file (a FRED file is an XML file describing in detail the way the recording was done, and the format used):
It should be noted manufacturers usually also sell non mandatory recorders (QAR and the many variants of QAR) and they provide not only readout tools, but also analysis/monitoring tools. Example:
Other readout solutions:
You can see the FDR itself is used for the readout. In case the FDR unit is broken (which is frequent after accidents), the protected memory unit is extracted and read with another working FDR.
Extraction of the memory module protected in temperature resistant foam:
(Source: ATSB accident report)
Readout facilities and readout certification
FDR/CVR readout cannot be trusted unless it's done with appropriate knowledge, skills and documentation. This is the reason readouts used by official agencies, which can be used at courts to try determining responsibilities after an accident, are required to be done by certified personnel in approved facilities.