Flight Data Analysis Program (FDAP – Australia), Flight Data Management (FDM – UK) and Flight Operations Quality Assurance (FOQA – USA), all gather data from aircraft systems for use in safety.

Public understanding of flight data collection focuses on the Flight Data Recorder (FDR) and the Cockpit Voice Recorder (CVR) (often combined to be called Combi Recorders) that are used in accident investigation.  These units are designed to be crash protected.  CAO103.19 defines 20 minimum aircraft data parameters that must be fed to the CVR, however modern aircraft and equipment can provide many thousands more.

The data is fed to the Digital Flight Data Acquisition Unit (DFDAU) which in turn feeds both the Quick Access Recorder (QAR) and the FDR. QAR is a non-crash protected unit used to tailor data for FDAP.  After each flight, the data is validated, analysed and flagged for Special Event Search Master Analysis (SESMA).  SESMA will often be known as ‘Events’ or ‘Exceedances’

Individual companies can set ‘Triggers’ for a wide range of events using logical algorithms.

Legislation

The oversight legislation is contained in ICAO Annex 6 Part 1. In Australia CAO 83.3 and CAO 83.5 stipulates FDAP is required for all aircraft exceeding 27 Tonne MTOW. (ICAO also ‘recommends’ FDAP for all aircraft above 20 Tonne MTOW).  UK CAP 739 is considered ‘The Bible’ for guidance for FDM programs.

Note: CASR Part 119 NPRM currently states FDAP will also be required for all commercial rotorcraft operations that exceed 7 Tonne MTOW.  This will affect many HEMS operations and most off-shore oil and gas helicopters 

The CASA CAAP SMS-4(0)  lists 21 operational events to be monitored for FDAP.   However, a modern CASR Part 121 fleet will usually have in the range of 150-300 events set to measure exceedances in flight.

Issues with FDAP

FDAP needs to be used with caution. Misuse or misinterpretation will lead to significant damage to an organisations safety culture.  Data must be ‘ washed’ (incorrect, incomplete or corrupted data is removed) and validated (the data is clean, correct and usable) before being considered. There are significant privacy (and often pilot union issues) with the use of FDAP.

The intent of FDAP is for flight safety and improvement.  However, if FDAP is used for ‘spying on pilots’ leading to punitive actions for errors, the consequences can be grave for industrial relations.

In major airlines, there are usually very clear and documented protocols (often negotiated with pilot unions) about the use of flight data.

Protocols include:

• The purpose of FDAP
• Signed company, and pilot, agreements and obligations under FDAP
• De-identification of data for analysis
• ‘Gatekeeper’ roles if pilot liaison/investigation is required
• Data security and confidentiality
• Program procedures.

The key consideration in using FDAP is to not trust data on face value, there should be respectful distrust until washed and validated.

FDAP outputs

The raw output of flight data are Lists and Traces.  Lists and Traces are interpreted by specialised analysts or programs that are used for interpretation (Austin Digital, POLARIS, Aerobytes are some example programs).

From a safety and efficiency consideration the information can be significant and includes:

• Training deficiencies
• Reports
• SOP issues
• Trend analysis
• Exceedance events
• Engineering issues
• Approach training
• Event visualisation (US Air 1549)
• QF1 Bangkok
• And many more.

FDAP events will normally have Thresholds and an organisation will set the triggers for the levels. For example:

• Level 1 – Trend analysis only
• Level 2 – up to Aircraft or company limits
• Level 3 – exceeding aircraft or company limits.

Level 1 events will generally be considered for tracking or trend purposes. A Level 2 event is sometimes referred to as a ‘soft’ event where the company takes no action other than consideration for potential training or SOP change. Level 3 events are considered ‘hard’ events that will generally result in investigation into the circumstances by a ‘Gatekeeper’ (trusted and experienced Captain on type) with the crew, without any punitive consequence.

FDAP in SMS

FDAP lives within the SMS, although FDAP outputs may cross many company systems (engineering, QA, training etc). The objective is continuous monitoring and improvement. Should an event discovered through FDAP be considered outside acceptable behaviour, then the consequences are managed through the SMS.  Punitive action is never taken as a direct result of FDAP.