CONTENTS

FORWORD 3

PART 1: SMS REMINDER

INTRODUCTION 5

SAFETY RISK MANAGEMENT 9

HAZARD IDENTIFICATION 10

RISK ASSESSMENT 12

Tolerability vs. Criticality 16

RISK MITIGATION 17

SUMP UP 19

SAFETY ASSURANCE 20

SAFETY PERFORMANCE INDICATORS 23

INDICATOR TARGETS 24

CONCLUSION 24

PART 2: FLIGHT DATA ANALYSIS PROGRAMME

INTRODUCTION 26

CONTRIBUTION OF AN FDAP TO THE SRM 28

CONCLUSION ON SRM CONTRIBUTION 32

CONTRIBUTION OF AN FDAP TO THE SAFETY ASSURANCE 33

CONCLUSION ON SA CONTRIBUTION 34

FDA FUNDAMENTALS 35

CONFIDENTIALITY & DATA PROTECTION 35

NON PUNITIVE PROGRAMME 36

COMPETENT FDA TEAM MEMBERS 38

STAFFING 41

1
PART 3: DATA

RECORDING CHAIN DESCRIPTION 44

RECORDERS 44

RECORDING ARCHITECTURE 45

TO SUM UP 48

DATA FRAME 49

RECORDER CAPACITY 49

FRAME ARCHITECTURE 50

RECORDING TIME INTERVAL 52

DATA FRAME DESCRIPTION 54

RAW DATA – ACQUIRED PARAMETER – DERIVED PARAMETER 55

PARAMETER DERIVATION 56

REGULATION 59

RECORDING MEDIA 61

PART 4: EVENTS

EVENT OBJECTIVES 64

EVENT DESIGN 66

EVENT THRESHOLDS 67

FLIGHT PHASES 71

EVENT TYPES 74

EVENT CUSTOMIZATION 76

FDA SOFTWARE 78

FDA TOOL LIMITS 81

CONCLUSION 83

2
 FORWORD

This manual has been conceived to answer to many operators’ questions concerning the Flight
Data Analysis (FDA) topic. In its first version, the objective of this document is to provide the
necessary knowledge for an operator safety department to be able to efficiently run an FDA
programme (FDAP).

It is crucial to understand where the data is coming from, how it has to be converted in an FDA
software to obtain relevant read-outs, what are the induced limitations of such a tool and in fact,
for an analyst, simply to understand what he is looking at. Without this knowledge many mistakes
can be done in the interpretation of the data. It can even jeopardize the safety objective of the
FDAP.

As clearly stated in the International Civil Aviation Organization (ICAO) Annex 6 – Operation of
Aircraft, an FDAP is part of an airline Safety Management System (SMS). Therefore, in order to
understand how an FDAP can be implemented in an airline’s SMS, this FDA document starts with
an SMS reminder. It includes not only a description of its framework, but also developments
related to Safety Risk Management (SRM) and Safety Assurance (SA) where an FDAP can be very
beneficial.

FDA, reporting systems, audits, etc. are tools that help to achieve the SMS goals. However, without
a clear understanding of what an SMS is, and without a clear view of what the final picture should
be, even with the best tools, targets can be missed.

Following this SMS review, the second part of this document develops the contribution of the
FDAP to the SMS.

The third and the fourth part of this document describe the recording systems the data, the
decoding and how it is addressed to get the read-outs.

This getting to grips is not holistic and just focuses of what can be considered as essential to help
at running an efficient FDAP.

3
PART 1: SMS REMINDER

4
 INTRODUCTION

SMS stands for Safety Management System. Each word has its own importance. It means that we
rely on a system, in order to manage safety.

Through the SMS concept, safety is no longer only the responsibility of the pilots, but also of
anybody within the system. Furthermore, the accountability for safety is endorsed by the head of
the system, who most of the time is the CEO.

For a long period of time, there was confusion between the training department activities and the
safety department tasks. Quite often, even today, the management of the safety department is
endorsed by Captains who are also TRIs/TREs, furthering this confusion. Even if a good
relationship (even partnership) is desirable between those two departments a fusion should be
avoided, because it would put the focus on the pilots to improve safety instead of having this global
approach fostered by the SMS.

A safety department should be independent and should have the same level of authority as the
training department or the flight ops department.

Where does the SMS come from?

The SMS comes from the safety thinking and the accident causation.

From the beginning of commercial aviation, the main concern was to improve the safety of
operations. The main focus was made initially on the technical aspect, in order to improve the
reliability of the aircraft, reliability of the engine and the airframe, but also reliability of the
navigation system, of the flight controls, etc. Even today, aircraft manufacturers, in accordance
with the authorities, continue to improve their aircraft for better reliability. For instance, one of
the main risks worldwide is the runway overrun risk. Therefore, several solutions have been
developed on the prevention side with the Runway Overrun Prevention System (ROPS) or the
Brake To Vacate (BTV) system, and on the protective side with the Engineered Materials Arrestor
System (EMAS).

However, even if the improvement of the reliability of the aircraft obviously reduces the accident
rate, accidents still occur. Since the seventies, the analysis of accidents highlighted human factors
as the main contributor to accidents. Therefore, the Crew Resource Management (CRM) concept
has been developed, in order to benefit from understanding of human behaviour in a cockpit. The
notion of Human Performance has been widely taken into account from the cockpit definition by
the aircraft manufacturers to the flight crew training during type rating as well as during the ATPL
study. Those concepts have also been developed at the maintenance level through the
Maintenance Resource Management (MRM).

5
Thanks to the improvement made with the two previous domains, technical and human, the rate
of accidents has considerably decreased. In fact, the number of accidents was so low that
improving safety from the lesson learnt (reactive method) became no longer sufficient. The will
was also to improve safety through anticipation. The safety improvement should come from the
global observation of operations including the organization. This approach led to conceiving, in
the mid-nineties, what is known as the SMS for the operators (in parallel with the State Safety
Programme for the authorities).

Till now, even if many improvements in safety management (by operators, ATC, Authorities and
States) have been observed, it is mainly focusing on individual (organizational) safety
performance with low consideration of the total aviation system context. Today, this is the total
system that has to be considered for the safety management.

Who has defined the SMS and in which Documents?

The ICAO has defined the SMS Standards in the Annex 19 - Safety Management.

Annex 19 gives a high level description of the State safety management responsibilities and its
oversight system as well as the SMS and its framework.

In order to explain the Safety Management concept a bit deeper, the ICAO has produced guidance
in the Safety Management Manual (SMM), Doc 9859 – 4th Edition.

This edition is intended to support States in implementing effective Sate Safety Programmes (SSP).
This includes ensuring that service providers implement Safety Management Systems (SMS) in
accordance with the provisions of Annex 19.

In this SMS Reminder Part we will focus only on the SMS by affected product and service
providers and not on State related aspect.

6
Who are the product and service providers affected by the SMS?

The SMS affects any organization providing aviation products and/or services.
Therefore it encompasses:

 Approved Training Organizations (ATOs)

 Aircraft Operators
 Approved Maintenance Organizations (MROs)
 Organizations responsible for type design and/or aircraft manufacturers
 Air Traffic Service providers
 Certified Airport.

What is the SMS?

The SMS is a systematic approach to managing safety including the necessary:

 Organizational structures
 Accountabilities
 Policies
 Procedures.

Accountability or Responsibility?

The ICAO clearly makes the difference between Accountability and

Responsibility. Accountability cannot be delegated while responsibility can be.

In that order the SMS framework is depicted as follows:

Safety policy and objective encompassing

 Management commitment
 Safety accountability and responsibility
 Appointment of key safety personnel
 Coordination of emergency response planning
 SMS documentation.

Safety risk management encompassing

 Hazard Identification
 Safety Risk Assessment
 Mitigation.

Safety Assurance encompassing

 Safety Performance monitoring and measurement
 Management of change
 Continuous improvement of the SMS.

Safety Promotion encompassing

 Training and Education
 Safety Communication.

7
These elements constitute the 4 pillars of the SMS.

Any safety “tool” may interact with each of these pillars.

For instance, the FDA may contribute to establishing the safety objectives and its output may be
used for safety promotion. However, because our main objective is to describe how to get the best
from the FDA to manage the safety risk and to measure the safety performance, only the safety
risk management pillar and the safety assurance one will be developed in this SMS reminder part.

So let’s go through the description of these two pillars.

8
 SAFETY RISK MANAGEMENT

“The objective of safety risk management is to assess the risks associated with identified hazards
and develop and implement effective and appropriate mitigations”.
ICAO (SMM)
This statement makes reference to many different notions that are worth being clarified.
The first one is safety.

What is Safety?

The definition in the ICAO documentation may be far away from what is commonly thought.
Safety is:
“The state in which the possibility of harm to persons or of property damage
is reduced to, and maintained at or below, an acceptable level
through a continuing process of hazards identification and safety risk management.”
ICAO (SMM)

In the aeronautical world we consider to be safe not because of being out of danger but because
the risk is at an acceptable level. In other words, operations are safe because the risks are
controlled and not because there are no risks.

What is a Safety Risk?

Safety Risk is a product of the human mind intended to measure the seriousness of or to “put a
number” on the consequences of hazards.

In order to be able to put a number on the consequences of a hazard we will have to assess:
“The predicted likelihood and severity of the consequences or outcomes of a hazard.”
ICAO (SMM)
This assessment is one of the key elements to achieving the objective of the safety risk
management.
To achieve this objective a process has to be applied as in the loop below.

Let’s focus now on each step of this loop.

9
 HAZARD IDENTIFICATION
What is a Hazard?

“A condition or an object with the potential of causing:

 Injuries to personnel
 Damage to equipment or structures
 Loss of material, or
 Reduction of ability to perform a prescribed function.”
ICAO (SMM 3rd version)

It is essential to clearly identify what the hazards are. For instance, birds by themselves are not a
hazard, but birds in the vicinity of a takeoff path that an aircraft will fly become a hazard, because
they have the potential of causing damage to the aircraft. At any time, if there is a doubt at
classifying a hazard, do not hesitate to revert to the definition.

Examples of hazard
• CB on the trajectory
• Glide-slope deviation on final
• Load sheet error

The hazard identification is the activity where hazards are detected, using systematic processes
and tools.

How to Identify Hazards

Hazards exist at all levels in the organization and are detectable through different sources, e.g.
FDA, Inspections, audits, reporting systems.

Two main methodologies are described in the SMM.

1. Reactive

“This methodology involves analysis of past outcomes or events. Hazards are identified through
investigation of safety occurrences. Incidents and accidents are an indication of system
deficiencies and therefore can be used to determine which hazard(s) contributed to the event”.

As previously said in the introduction, learning from accident and incident helps to improve the
safety of operations. However, it is definitely not efficient enough if we consider the SMS
objectives.

The corrective actions taken from these lessons learnt may involve not only the operator (e.g.
through procedures updates), but also authorities setting new regulations, and/or manufacturer
improving aircraft design, and/or training organization (e.g. Airplane Upset Prevention &
Recovery Training Aid (AUPRTA)).

Reacting to a mandatory occurrence report (MOR) is still part of the reactive methodology even
if no ”physical” consequences have been encountered. Therefore, the process becomes more
efficient considering the SMS objectives. For instance, a TCAS event enters the MOR scope, and

10
hopefully is not followed by a mid-air collision. It is expected to analyse the circumstances of this
occurrence to avoid escalating to the next step.

2. Proactive

”This methodology involves collecting safety data of lower consequence events or process
performance and analysing the safety information or frequency of occurrence to determine if a
hazard could lead to an accident or incident. The safety information for proactive hazard
identification primarily comes from Flight Data Analysis (FDA) programmes, safety reporting
systems and the safety assurrance function”.

This method is considered highly efficient. Through analysis of this data, the objective is to
anticipate and to prevent the risk from occurring.

The corrective actions taken from this analysis will most of the time, only involve the operators
(e.g. new directives, new objectives, procedure changes, training improvement, and
communication), the authorities, and/or manufacturers remaining out of the loop.

The purpose of the SMS is really to switch from lesson learnt mode to anticipation mode. For such
a switch, safety performance measurement will have to be done. It will be explained in the
dedicated Safety Assurance chapter.

In the last version of the ICAO SMM, the predictive methodology has been removed. The difference
between the proactive and predictive methodologies being too tiny.

Who is in charge of Hazard Identification?

Everybody has a role in the identification of hazards however this is upon the responsibility of the
safety manager as well as the implementation and the maintenance of its process.

11
 RISK ASSESSMENT
The second step of the safety risk management loop is risk assessment.

It needs for each hazard to identify the associated risks and their potential outcomes.

Caution: Obviously, a risk may be linked with several hazards, but a hazard may also be associated
with different risks. They all have to be considered to get a comprehensive assessment.

It is mandatory to establish the link between the hazards, the risks, and the consequences.

Let’s come back to the previous hazard examples.

CB on the trajectory
The associated risks are:
Speed Loss (associated with the Loss of Control in flight –LOC-I risk)
Altitude Loss (associated with LOC-I and the Mid Air Collision – MAC risk)
Turbulence (associated with the LOC-I risk).

Glide slope deviation on Final

The associated risks are:
If below
Reduced altitude safety margin (associated with the Control Flight Into Terrain – CFIT risk)
Landing before runway threshold (associated with CFIT too).
If above
High energy before Touchdown (associated with the runway overrun risk)
High braking (associated with tire burst risk and runway excursion risk)
High vertical speed before touch down (associated with hard landing risk).

Load sheet error

The associated risks are:
Tail strike risk
Loss of control in flight
CFIT.

As you can see, the Hazard/Risk/Consequence model has its own limits. A risk may sometimes
also be considered as the hazard. For instance, a CB on your trajectory is a hazard, the turbulence
that you may encounter flying through this CB is an associated risk, but it is also a hazard by itself.
If we refer to the definition of the hazard, they both have the potential of causing damage to
equipment or injury to personnel. This dialectic issue is a never-ending story.
Many different intermediate steps between the hazard and the consequences may be considered.
However, for risk assessment, which is our topic here, it is the potential outcome that is essential
to define for the efficiency of the following process.

How to Assess the Risk?

By assessing the following for each hazard

• The severity of the potential outcomes
• The probability that they will occur.

Some guidance and tables exist in the SMM, in order to assess severity and probability.
12
The following table helps to grade the severity from A to E:

Severity Table

The following table helps to grade the probability from 1 to 5.

Probability Table

Both probability and severity need to be assessed considering the existing defence barriers.

The combination of severity and probability provides the Safety Risk Index.

13
 Safety Risk Index Table

Finally, the safety risk index, with its colour coding, will provide the Tolerability risk, as per the
table below.

Tolerability Table

The objective is to maintain the risk As Low As Reasonably Practicable (ALARP).

Note: These tables are here only for example and it should be kept in mind that each organization
can set up its own risk matrix to cope with its own situation.

What is crucial in this process is to assess the probability in relation with the
considered severity of the outcome.

Explanation:

On one hand, if you consider that the severity of the potential consequences of a runway overrun
risk may be Catastrophic, with multiple deaths and equipment destroyed, (grade A), you,
therefore, should assess the probability of this kind of outcome occurring. Considering you
operate airfields with long runways without tricky environment, some with EMAS, then you may
assess it as extremely improbable, (grade 1). The safety risk index would be in that case 1A
(yellow), meaning “Acceptable based on risk mitigation”.

On the other hand, if for the same risk you consider, because of the same environment, the
potential consequence is “only” Major, meaning reduction in safety margin with injury to
personnel, (grade C), you may assess the probability as Remote for such consequences (grade 3).
The Safety Risk Index in that case would be 3C, but still with the same colour, yellow.

This is what must be retained from the system. If the proposed process is correctly applied, the
result (colour) will be identical. The difference in the grading will just guide you in the way the
mitigation should be focusing on (prevention/ protection).

14
 Caution: When RED is put on a risk, it means that the risk is unacceptable under the existing
circumstances. It means that you must not operate without doing something immediately
to mitigate the related risk

Because, by the end of the day, what is important, through the risk assessment process, is to know
what must be done considering a dedicated risk and how urgently.

Who is in charge of Risk Assessment?

The safety manager is in charge of the safety risk assessment.

During Safety Action Group (SAG) meetings, the safety manager will present the outputs from the
different safety tools. The objective is to present the current exposure to risks to the operational
managers. It is achieved through the presentation of this risk assessment. Of course, this risk
assessment may be considered as a proposal, and therefore, may be reviewed and adjusted during
this kind of meeting.

15
 TOLERABILITY VS. CRITICALITY

The previous methodology assesses a risk. Is this methodology suitable to assess an occurrence?

To answer this question let’s focus what a risk is and what an occurrence is.

On one hand, a risk is “a state of uncertainty where some of the possibilities involve a loss, a
catastrophe or other undesirable outcome”.
(Douglas W. Hubbard)

The uncertainty of a risk to get outcome is the reason for evaluating the probability as seen in the
previous assessment methodology.

On the other hand, an occurrence is something that happens. Every occurrence takes place in a
specific context and there is an actual outcome. There is no uncertainty in an occurrence.
Therefore, it is not suitable to talk about probability when assessing an occurrence.

This issue has already been addressed in International working group such as ARMS (Aviation
Risk Management Solutions). The objective is to assess an occurrence completely independently
from any other occurrence, instead of considering assessing a risk. To do so, two questions should
be answered when there is an occurrence:

• How close to an accident were we?

• How bad (in terms of severity) would it have been?

Therefore, instead of assessing the probability and the severity of a “global” risk and its
outcomes, this is an assessment of the vulnerability and the severity of an “isolated” occurrence.

To assess the vulnerability, the defence barriers and their effectiveness have, of course, to be
reviewed and evaluated.

On one hand, with the former methodology, the result represents the tolerability to a risk while
on the other hand, with the latter methodology, the result represents the occurrence criticality,
as per Airbus terminology.

(Refer to the ARMS methodology).

16
 RISK MITIGATION
After the assessment, when a risk is considered as unacceptable or acceptable under mitigation,
(either actually present or predicted by trending), remedial actions should be decided and
implemented.

Mitigation = Remedial Actions

To maintain an acceptable level of Safety.

This should be accomplished while bearing in mind that the risk must not be simply transferred
somewhere else in the system.

Example: high vertical G at landing.

If it is one of the main concerns of an airline, the mitigation should not lead the pilots to perform long
flare distance landings to achieve a smooth touchdown. This kind of mitigation displaces the risk
from hard landing risk to runway overrun risk where the consequences may be much more
catastrophic.

While the safety manager is in charge of hazard identification and risk assessment, the remedial
actions should be decided during Safety Action Group (SAG) meetings involving operational
managers. It is important to get a collegial decision to mitigate the risk as the issue may need a
global solution and not only concerning the pilot community. Of course, the safety department
may have some proposals, but the decision is in the scope of the SAG.

When a solution needs a strategic decision, it should be addressed at an executive level. It is done
during Safety Review Board (SRB) meetings, which are usually held at least twice a year and also
on demand for urgent matters. During this meeting, Safety Performance Indicators (SIP) are also
presented by the safety manager.

Example: runway overrun risk

To mitigate the runway overrun risk, a solution could be to reinforce the pilot skills during recurrent
simulator training, this decision being taken during an SAG meeting. Another decision could be to
implement ROPS equipment on board, but because of the cost of such a device, this kind of solution
may be decided during an SRB meeting.

It is the assessment process that leads to a mitigation decision. This mitigation will be based on
the identification of the weakness in the system. The purpose will be to evaluate the existing
defence barriers and to identify a lack of a defence barrier.

The questions considering the defence barriers are:

 Do they exist?
 Are they efficient?
 Are they applied?

For instance, if an SOP exists and has been proved to be efficient, a subsidiary question remains:
Why is it not applied?

17
When a risk log is filled, usually a second assessment, “after mitigation”, is done, to re-evaluate
the defence barrier. Of course, the risk after mitigation is expected to be acceptable.

Technically, mitigation may be done through Prevention and/or Protection.

You can either reduce the probability of encountering a risk. It is what we call Prevention.

Or you can reduce the severity of the consequences. Therefore, it is called Protection.

18
Acting on both axis is highly recommended to put and maintain the risk level as low as possible.

Example: runway overrun risk can be mitigated

• Either by reducing the probability through the on board ROPS = Prevention

• Or by reducing the severity of the consequences through the design of runway equipped
with EMAS = Protection

For the risk mitigation three main domains have to be considered:

• Training
• Technology
• Regulations

SUMP UP

Once a hazard or potential hazard is identified, the next step is to assess if the level of risk is
acceptable. If not, then appropriate action to mitigate the risk needs to be decided and
implemented. Through this mitigation you can either prevent the risk or protect against the
potential outcomes. What is essential is not to displace the risk somewhere else in the system.
That’s the reason why these decisions should be taken collegially through SAG meetings involving
operational managers or during SRB meeting at an executive level for strategic decisions.

Hazard Risk Consequence

azard

Defence barriers

When a mitigation is implemented, an active monitoring should be implemented in order to verify

its effectiveness. This monitoring is achieved through the setting of indicators. It is part of safety
assurance and it is addressed in the next chapter.

19
 SAFETY ASSURANCE

Like safety risk management, safety assurance is an SMS pillar where an FDAP can fully provide
benefits… provided it is clearly understood what safety assurance is.

What is Safety Assurance?

In accordance with the ICAO Safety Management Manual (SMM), safety assurance is “processes
and activities to determine whether the SMS is operating according to expectations and
requirements”.

It is also defined as a complement to Quality Assurance by monitoring the effectiveness of safety

risk controls.

It should include the development and implementation of corrective action.

In other words, safety assurance continually monitors an internal process and operating
environment to detect changes or deviations that may introduce emerging safety risks or
degradation of existing risk controls.

Let’s focus first on this second aspect of safety assurance.

How to Monitor the Effectiveness of Safety Risk Control?

The monitoring of the effectiveness of safety risk control is achieved through the measurement of
safety performance. Therefore, to understand how to monitor, we need to focus first, on what
safety performance is.

What is Safety Performance?

To answer this question let’s imagine first what a nominal flight is.

In an ideal world, a nominal flight may encompass the following conditions:

 It is a usual flight. The crew is familiar with the airfields at departure and destination
 There is no environmental issue: no mountainous area, no complex procedure
 The weather is good at departure, en route and at destination:
No rain, no CB, no turbulence, no icing condition, no significant weather
 There is no Notam affecting the flight
 The flight folder is comprehensive: Computerized flight, Notam, weather info
 The aircraft is perfectly ok: No MEL, no CDL, no failure during the flight
 There is no problem with loading, with refuelling, with boarding
 There is no delay, no traffic congestion (ground and air), no time pressure
 The technical crew is well trained, well experienced, well balanced
 There is good communication: Between the crewmembers, with the ATC
 There is no fatigue issue
 There is no problem with the routing

In real life this ideal world does not really exist. Many drifts may be encountered:

 There is a tricky environment at departure or on arrival, procedures are complex

 The crew is not familiar with the departing or arriving airport
 The crew is tired

20
  The aircraft has a technical issue: MEL affecting takeoff and/or landing performance
 The flight folder is not comprehensive: Documents are missing
 The previous flight is late: The crew is in a hurry
 There is an ATC slot
 The weather is not ok: Tail wind at takeoff or at landing, CBs en route, icing conditions
 A cabin crewmember is missing
 There is a gross weight error in the load sheet
 There is a no-show passenger forcing the unloading of baggage

Safety performance is the way the crew is able to handle each of these “drifts”.

For instance, if CBs are expected en route, the objective is to determine if this threat is properly
addressed through the correct use of the radar and through a relevant weather deviation
(anticipation/ avoidance).
If flying through CBs, is the speed properly adapted to turbulence?
Is the anti-icing properly set and the seat belt sign switched on?
Finally, if the aircraft is in an undesirable state, such as a speed and/or altitude loss, is the crew
able to recognize the situation to properly apply the recovery manoeuvre and how efficiently?

As a general rule, the earlier a condition/situation is addressed the better the safety performance
is. The purpose of safety performance is to measure the development of the drift.

The following graph illustrates this concept.

How to Measure Safety Performance?

By collecting data, and counting the occurrences.

As seen in the SRM chapter, an occurrence may be trivially defined as something that happens.
Even if it is true, this definition is definitely too vague, and to clearly understand what an
occurrence is, we can refer to European regulation N°374/2014:
“Occurrence means any safety-related event which endangers or which, if not corrected or
addressed, could endanger an aircraft, its occupants or any other person and includes in particular
an accident or serious incident”. (Reg n°374 of 3 April, 2014, on the reporting, analysis and follow-
up of occurrences in civil aviation).
21
In other words, an occurrence may be understood as a deviation from a normal “safe” condition
caused by one or various hazards. It can range from a single deviation (latent unsafe condition) to
an accident, with various intermediate statuses (e.g. incident, serious incident).

Some occurrences are quite obvious because they have tangible outcomes, e.g.:
 Bird strike
 Lightening
 Engine shutdown
 Smoke, Fire
 Runway excursion
 Crew incapacitation
 Etc.

Some others are also obvious because they are subject to Mandatory Occurrence Reporting
(MOR), e.g.:
 TCAS
 GPWS
 Wind shear
 Etc.

Some are not so obvious, because they have no tangible and/or immediate outcomes, e.g.:
 A document missing in a flight folder
 A long flare distance
 A harsh braking
 Etc.

As a result, safety performance measurement quantifies all occurrences including those ones
that have low critical consequences, but which may be indicative of emerging safety risks.
It becomes easy to create a link between this occurrence counting and the two different
methodologies (reactive and proactive) to identify hazards, addressed in the previous SRM
chapter.

If we combine the two methodologies with the different occurrence types (and their potential
treatment), and if we superimpose these outputs on the safety performance model, it becomes
possible to visualize one of the objectives of the safety assurance which is to be proactive.

Once again, the earlier the detection is, the better the safety performance will be.

22
 SAFETY PERFORMANCE INDICATORS
To measure safety performance, indicators need to be set up.

Indicators can be split in two main categories: Operational indicators and non-operational ones.

Operational safety indicators will help you to:

 Monitor known safety risks;

 Detect emerging safe risks;
 Identify needs for any necessary corrective action.

They are directly linked with the measurement of the drifts previously addressed.

Safety indicators will be useful to provide objective evidence for the authorities to assess the
effectiveness of the service providers’ SMS and to monitor achievement of its safety objectives.

Examples of operational safety indicators

 Number (and/or rate) of TCAS Resolutions

 Number (and/or rate)of GPWS events
 Number (and/or rate)of Unstabilized Approach
 Number (and/or rate)of Long Flare distance events
 Number (and/or rate)of flights where turbulence has been encountered
 Etc.

Indicators must be relevant for real operations and detailed enough, in order to cope with their
objectives of measuring the exposure to a risk. For instance, unstable approach indicators should
discriminate the nature of non-stabilization (e.g. speed, configuration, thrust settings), and should
also indicate where the event occurs, and under which circumstances, etc.

The indicators should also be put into perspective for a sufficient period of time, in order to be
able to demonstrate the variation of the exposure to a risk (deterioration or amelioration).

Many of the safety performance indicators may be provided by FDA and/or reporting tools.

Caution: an indicator by itself is not sufficient to identify the root cause of the exposition
to a risk.

For instance, setting an FDA indicator to monitor the bank angle at touchdown is not
sufficient to identify the root cause of an engine strike at touchdown risk. In that order a
comprehensive and deep analysis should be conducted including airport environment,
approach procedures, weather conditions, etc.

23
The non-operational safety indicators are to demonstrate internally and externally (for instance,
the authorities) the good health of the providers’ SMS.

Examples of non-operational safety indicators:

 Number (and/or rate) of reports (mandatory or voluntary);

 Number of flight retrieved through the FDA tool compare to number of flights performed
(known as retrieval rate);
 Time interval between the realized flights and the availability of these flights in the FDA
software;
 Etc.

As well as for the operational indicators, these ones should be detailed enough to catch any issue
related with the system. For instance why is there so few reports, why the retrieval rate is so low,
(is it a whole fleet concern or is it a single MSN issue)? What is the trends?

INDICATOR TARGETS
According to the safety management manual, all indicators should have targets and these targets
should be measurable and achievable.

However, there is a lot of subjectivity when setting targets. For instance, if an FDA indicator has a
rate of 0.004%, does it make sense to set the next target at 0.002%? If an indicator has been
triggered only once in a month does it make sense to set the next target at 0 for the coming
months? No answer is completely acceptable.

That is the reason why many operators would like to benchmark their results with some others.
However, there are several issues related to benchmarking. Are we sure that we are comparing
the same data (Refer to the Data Part of this FDA Handbook)? If an operator has a ratio at 5% on
a specific indicator does it mean that this operator is less exposed to the associated risk than
another one with a ratio of 10% on this same indicator? Once again, no answer is completely
acceptable.

CONCLUSION
Indicators are one of the most important aspects of the safety performance measurement.
However, these indicators have their own limitations. They must be put into perspective in order
to properly interpret them. Indicators will help to measure the risk exposure, but they will not
provide the root cause. Therefore a comprehensive and deep analysis should be conducted.

As for the hazard identification process of the SRM, an FDAP and its software solution appear to
be a key element for occurrence collection, the setup of safety indicators and therefore, safety
assurance.

24
 PART 2:

FLIGHT DATA ANALYSIS PROGRAMME

25
 INTRODUCTION

As per the ICAO Annex 6 - Operation of Aircraft - Paragraph 3.3 Safety Management

3.3.2 “An operator of an aeroplane of a maximum certificated take-off mass in excess of 27 000 kg
shall establish and maintain a Flight Data Analysis Programme (FDAP) as part of its SMS”.

The objective of this chapter is to explain how an FDAP can efficiently contribute to an Operator’s
Safety Management System (SMS).

As there is no guidance in Annex 6, the ICAO edited the document 10000 – Manual of Flight Data
analysis Programmes (1st edition 2014). This document contains all of the following:

 Description of the relationship between SMS and FDAP

 Overview of FDAP elements
 Guidance for FDAP establishment and implementation.

This Manual of FDAP is a very relevant document that really worth at being studied. In this
chapter, you will find many references to it that will be commented.

One of the main statements about the FDAP is:

“An FDAP may be described as a non-punitive programme for the routine collection and analysis
of flight data to develop objective and predictive information for advancing safety e.g. through
improvements in Flight crew performance, training effectiveness, operational procedures,
maintenance and engineering, ATC procedures”.
(ICAO Doc 10000 - para 1.4.3)

It completes the definition made by the ICAO in “Annex 6 - Part I” that describes an FDAP as “a
process of analysing recorded data in order to improve the safety of flight”.

To achieve the goal of improving the safety of flight a non-punitive policy should be put in place.
This essential aspect will be treated in the paragraph FDA Fundamentals of this manual.

The objectives of an FDAP are, as per the ICAO doc 10000 – para 1.4.11:

 To determine operating norms

 Identify potential and actual hazards in operating procedures, fleets, aerodromes, ATC
procedures, etc.
 Identify trends
 Monitor the corrective actions effectiveness
 Provide data to conduct cost-benefit analysis
 Optimize training procedures
 Provide actual performance measurement for risk management purpose.

As per paragraphs 1.4.13 and 1.4.14 of ICAO doc 10000:

“FDA aims at continuous improvement of the overall safety performance of an operator and it
should be integrated in the safety assurance component of the operator’s SMS”.
“As part of an operator’s SMS safety assurance processes, an FDAP will have identified indicators
or parameters chosen for measuring and monitoring the operator’s safety performance,”...

26
From these previous statements, we understand that an FDAP is a systematic tool for the proactive
identification of hazards, but also a tool for safety performance measurement. In other words, an
FDAP is a key element for safety risk management and safety assurance, the two pillars developed
in the SMS reminder part of this document.

The following two chapters will explain how an FDAP can contribute to safety risk management
(SRM) and safety assurance.

27
 CONTRIBUTION OF AN FDAP TO THE SRM

An FDAP is a key element for hazard identification.

As developed in Part 3 – EVENT (link with the chapter) of this document, the purpose of an FDA
event is to be generated when a non-desired flight condition is identified.

How to create the link between an FDA event and the hazard identification?

As a reminder, the definition of a hazard is:

“A condition or an object with the potential of causing:

 Injuries to personnel
 Damage to equipment or structures
 Loss of material, or
 Reduction of ability to perform a prescribed function.”
ICAO (SMM 3rd version)

For instance, a “Long Flare Distance” event is a condition in which the aircraft may encounter the
risk of a runway overrun with the potential of causing injury to personnel or damage to equipment
or loss of material etc.

Therefore, in that sense a “Long Flare Distance” is a hazard.

On one hand, the “Long Flare Distance” event may be considered as a precursor of the risk of
runway overrun as it is directly linked with the risk itself. In the same way, a high pitch at takeoff
and it associated event “Pitch High at Takeoff” may be considered as a precursor of a tail strike
risk.

On the other hand, some events may be considered as contributors. For instance, a tail wind at
landing may contribute to the exposure to the runway overrun risk by increasing the landing
distance. Thereby, its associated event “Tail Wind Landing” is a contributor. However, it is still a
hazard because it complies with its definition. A tail wind landing has “the potential of causing…”
but more indirectly.

The difference between precursors and contributors may be very tenuous. For instance the
European Operator Flight Data Monitoring (EOFDM) working groups do not make this difference
but they talk about a hierarchy between precursors considering their “proximity” to the accident.
This notion of “proximity” may be used to make the difference between precursors and
contributors. Caution this “proximity” is not a question of chronology.

Both contributors and precursors may be considered as hazards.

28
 Examples

Contributors Precursors Risk

Tail Wind Landing
Long Flare distance
Reversers Delayed at Landing Runway Overrun
Unstabilized Approach High Deceleration Rate Required

Caution: A “Harsh Braking” event may be considered as a precursor of the runway

overrun risk but it could also be completely de-correlated from it. For instance, when this
harsh braking occurs on a long runway where the crew intends to vacate early on a mid-
taxiway to reduce the taxi-in duration.

That is the reason why, results have to be contextualized to be relevant.

Caution: You can be exposed to the risk of runway overrun without having performed a
long flare distance.

Only a deep analysis will give you your real exposure to a risk and its root causes.

Contributors Precursors Risk

Pitch Rate High at Take Off
Pitch High at Lift Off Tail Strike at Takeoff
Rotation before VR

Contributors Precursors Risk

High Vertical Speed Before
Touch Down High Vertical G at Touch down Hard Landing
Short Flare Time
Bounced Landing

These examples are not comprehensive. For instance, a “Dual Stick Inputs” event may also be a
contributor to each of these risks. The “proximity” of such an event may vary from one case to
another, even for the same risk.

Risk exposure measurement and root cause identification

The challenge of an FDAP is first, to properly measure the exposure to a risk and then to properly
identify the root causes of this exposure. “Close proximity” events may help to measure the
exposure to a risk while events with “low proximity” may be very interesting in order to find the
root cause of a safety issue.

Basic statistics on FDA events without a deep analysis, including proper contextualization, will
definitely not be sufficient to achieve these goals.

One of the solutions allowing at properly analysing a risk it the Bow tie model.

29
Bow Tie Model

Most of the models of risk analysis are based on a basic classification:

Hazard / Risk / Consequence.

Within the basic bow tie model the risk is put at the centre of the system.

Hazard Risk Consequences

Late A/THR Damage to

disengagement Aircraft

Long Flare Runway Equipement

Overrun Destroyed

Tail Wind Injury /Death

This basic classification may be too simple to properly measure the exposure to a risk and to
identify its root causes. As a result, the bow tie model may be extended and re-centred to cope
with these objectives. As seen previously, it may be interesting to discriminate precursors and
contributors and to identify the relationship between them. However it may also be interesting to
identify any intermediate state between the risk and its final consequences.

Example
A long flare event is one of the precursors of the runway overrun risk.
For example, this long flare may be due to an unstabilized approach and/or a tail wind landing.
This unstabilized approach may be due to poor ATC guidance.
Finally a long flare may lead to harsh braking with a potential tire burst.

This detailed approach leads us to reclassify the long flare as an unwanted event and harsh
braking as a risk by itself even if it may also be considered as one of the precursors for the runway
overrun risk. Going even further, harsh braking may also be considered as an unwanted event by
itself. (For more details, refer to the TEM methodology).

With this new classification, the risk is no longer at the centre of the bow tie but the unwanted
event is.
For a successful bow tie, the key is to decide what to put in centre and to focus on the efficiency of
the related defence barriers: Do they exist? Do they work? Are they efficient? On the contrary, the
trap is to switch from one risk to another or from one unwanted event to another in the same
table. The result being to be completely lost in the analysis process.

30
 Extended and re-centred bow tie

Root Cause Proximate Unwanted Event Risk / Outcome Consequence

Hazard Hazard
Harsh Braking Damage to
Dual Side Stick
Aircraft
Inputs

Long Flare Runway

Poor ATC Equipement
Overrun
vectoring Unstabilized Destroy
Approach
High reverse
Tail Wind on use at low Injury /Death
Approach speed

Regardless of the solution used, the events generated through an FDA software help to identify
the hazards and finally, through a deep analysis, to find the root causes. This is definitely not an
easy task and “one size does not fit all”. As a reminder, the objective is to be able to control the
risk through appropriate mitigation actions.

What is the relationship between the level of severity of an event and the criticality of an
occurrence?

As developed in Part 4 – EVENT of this document, the severity level of an event (and its associated
colour) is not systematically related with the criticality of an occurrence or the tolerability to a
risk.
Most of the events have triggering conditions based on thresholds. When a parameter is beyond a
threshold the event is triggered with the corresponding severity level. For instance, a “Long Flare
Distance” event may be triggered with a high severity level (coloured red) when the touchdown
point is beyond 1050 m from the runway threshold. However the event is not contextualized. It
means that this FDA event does not take into account the landing distance available and/or the
status of the runway which may be dry or contaminated.
Some events more sophisticated may improve the quality of the measurement of the runway
overrun risk exposure. For instance, “High Deceleration Rate Required” and/or “Remaining Speed
at 300 meters from Runway End” contribute at this improvement. However, once again, there is
no real contextualization because the status of the runway and/or any runway length reduction
(due to works in progress for instance) reported by Notam, are still today, not taken into account
for the event generation.

Future FDA software will have to contextualize the event. The objective will not to change the
triggering conditions and logics but to assess the criticality of the associated occurrence by
combining different sources of data.
Keeping the current triggering conditions and logics of events as today will continue to make
sense for statistical purposes. For Instance, it will remain relevant to know the distribution of the
touchdown points for a series of landing.

31
 CONCLUSION ON SRM CONTRIBUTION
FDA events constitute with the reporting system the main source for the hazard identification.
Therefore, FDAP is a key element of the safety risk management.

Events are most of the time triggered with a “severity level” which does not correspond to a risk
exposure because of the lack of contextualization.

Today there is no automatic contextualization that will help to assess the risk.
This contextualization has to be done manually by an analyst.

32
 CONTRIBUTION OF AN FDAP TO THE SAFETY ASSURANCE

As stated in the ICAO doc 1000 Chapter 3.3 - Safety Culture:

“Indications of an effective safety culture include:

g) a focus on monitoring fleet trends aggregated from numerous operations, rather than on
specific events. The identification of systemic issues adds more value for safety management than
isolated events;”

From an FDAP perspective, much more can be expected from analysing the whole data rather than
investigating single occurrences. By setting up safety indicators, many of them coming from an
FDA tool, it becomes possible to identify and monitor trends as well as the effectiveness of
corrective actions. These indicators are paramount for the safety risk control.

Example:

An airline having set an indicator about the top 10 high severity events, observes an abnormal
number of events “High Vertical Speed in Approach”. Further analysis of the database reveals that
most of these events occur while operating at an airfield stuck between two close borders that must
not be overflown. The procedure in used at this airport, embedded in a mountainous area, is a tear
one.

The associated risk related with this kind of event is the CFIT. A risk assessment has been conducted
and declared by the safety manager as acceptable under mitigation (Yellow). The safety action group
has decided to change the SOPs, in order to start to configure the aircraft before the IAF.
Accompanying this change of the procedure, safety indicators have been put in place on that airport
(such as ratio of High Vertical Speed in Approach at XXXX; distribution of this event per vertical speed
parameter), in order to monitor the effectiveness of the corrective action.

The EASA has understood the benefit of setting up relevant indicators to monitor known safety
risks as those ones identified in the European Aviation Safety Programme (EASP),e.g. LOC I, CFIT
or MAC. Therefore, EASA has mandated the European Operator Flight Data Monitoring (EOFDM)
group to set up a list of indicators per major risk.
Operators should demonstrate to their authorities that indicators are put in place, in order to
monitor known safety risks as per the State Safety Programme (SSP), as well as those ones
identified by the operators themselves.

The EOFDM working group has also set a list of Flight Data Monitoring (FDM – European name for
FDA) Key Performance Indicators (KPIs) to monitor non-operational safety indicators, but helping
to monitor the “health” of the safety management system of an operator. Once again, FDA software
may help to do this monitoring. For instance, number of flight processed on number of flight
performed, known as: Retrieval rate.

As already said in the previous chapter “SMS reminder”, FDA events constitute the main source of
the safety performance measurement, and in that way to the safety assurance. However, it has to
be kept in mind that these indicators should be manipulated with great caution. For instance, a
huge number of “Long Flare Distance” events may constitute a trend that will help you to measure
your exposure to the runway overrun risk, but not “immediately”. Once again, the results should
be contextualized. A distribution per destination airport and a correlation with other indicators
such as “High Deceleration Rate Required” events may help to fine-tune this measurement.

33
Notes:

- You can have a huge number of “Long Flare Distance” events, but if you operate only on very long
runways, your exposure to the runway overrun risk may be low. However, it can provide you with
information on how aircraft are handled to land, and it can reveal a bad habit from the flight crews,
which could be prejudicial at an airport with short runways.

- The tail strike risk at takeoff may be identified with FDA software through the combination of a
“Pitch High at TO” event and a “Pitch Rate High at TO” event. Even if, the triggering conditions are
different, some handling technics on a short version of an aircraft will not reveal an exposure to the
tail strike risk while the same technics might lead to the exposure to this risk on a longer version of
this aircraft. The arrival of such a different aircraft in a company should be subject to a management
of change where indicators should be put in place to monitor its specificities.

A single FDA indicator can be related to several different risks. The identification of the
proper risk is subject to further investigation. However, indicators are definitely a good
entry for the risk analysis.
A High Vertical Speed on final approach event may be linked to the CFIT risk or the LOC-I
risk or even the Runway overrun risk. Only a deep analysis will be able to properly interpret
the results.

CONCLUSION ON SA CONTRIBUTION
As seen in the previous paragraph concerning the contribution of an FDAP to the safety risk
management and now about the safety assurance, the readouts of an FDA software should be
contextualized for proper interpretation. Without a huge amount of work in analysis, it can be
misleading.
This necessary reserve facing the FDA output may be a little bit disappointing and frustrating
while a common will is to get immediate and non-questionable results. However, to get the best
from the system and especially from an FDA tool, some fundamentals need to be respected as
described in the next paragraph.

34
 FDA FUNDAMENTALS

The purpose of this paragraph is not to entirely rewrite what is already described in the Chapter 3
Prerequisites for an effective FDAP of the ICAO doc 10000, even if we foster reading it because of its
relevancy concerning the data protection and the safety culture. However the purpose is to focus and
to develop what we consider as fundamental for running an FDAP.

CONFIDENTIALITY & DATA PROTECTION

For instance, Paragraph 3.1.2 states:

“The integrity of an FDAP rests upon protection of FDA data. Any disclosure for purposes other
than safety management can compromise the required cooperation of flight crew in clarifying and
documenting an event. Thus, preventing the misuse of FDA data is a common interest of the State,
the operator and flight crews”.

Data protection may be considered as one of the fundamentals for an effective FDAP. It concerns
all the life cycle of the data from its collection to its deletion passing through the occurrence
investigation and/or statistics analysis.

Data protection is tightly linked with the confidentiality aspect of the entire safety system and
more specifically of an FDAP, because of its powerfulness. All flights are recorded and can be
replayed, but without the right analysis it can be subject to wrong interpretation, and without a
proper policy it can lead to wrong decisions. It is very easy to be judgmental but it does not
guarantee at all to reach the goal of improving safety.

Therefore, it is important to define safeguards not only to protect the privacy of the personnel, but
also to assure the efficiency of the system. Data access should be restricted to a limited number of
people, but with a clear security policy agreed between the management and the flight crews
balancing the users’ need and the privacy rights. It is essential to define what the objective of the
system is and how it will be achieved. In fact, this aspect reflects the operator’s safety culture.

We often talk about just culture. All safety managers are convinced about the relevancy of their
safety policies even if they vary a lot from one operator to another. They are convinced about the
proper use of the data even when they use it for disciplinary purposes. They are also convinced
about being right and fair at doing it.

For instance, using the data against an individual is a common practice. Punishing a pilot or even
firing them because of their recordings is not so unusual. However, is it efficient at improving
safety and is there any other available means to fix an identified weakness?

In other words, why does the ICAO Manual of FDAP state the following?

“An FDAP may be described as a non-punitive programme for the routine collection and analysis
of flight data to develop objective and predictive information for advancing safety”.

35
 NON PUNITIVE PROGRAMME
To explain why an FDAP should be a non-punitive programme let’s first, explain the negative
effects of a punitive policy through a real example.

Hard landing is one of the most tracked events by operators. First of all, because it is a very basic
FDA event, easy to tune and to monitor, mainly measuring the recorded vertical G at touchdown
and comparing it to defined thresholds. Then, because hard landing may have immediate
observable outcomes such as damage to the aircraft structure. Therefore, some airlines do not
hesitate to punish pilots who perform landings with high vertical acceleration at touchdown.

This was the case of that airline who, after having measured a high number of events “High Vertical
G at Touchdown”, has decided to put fine on Captain of flights where such an FDA event was
triggered.

The objective of this airline was clearly to reduce the number of events “High Vertical G at
Touchdown” in order to reduce the exposure to the hard landing risk. If we consider this primary
objective, the result after few months may be interpreted as positive because of the decreasing
number of such FDA events.
However, a deep investigation has demonstrated that there were also very negative side effects.
The first one being a huge increase of long flare distance events because of the pilot willing to
perform “kiss landings” to avoid losing money.
The second one being an increase of “harsh braking” events with also potential outcomes such as
landing gear damage. Furthermore, both reveal an increase of the exposure to runway overrun
risk with potential outcomes much more severe than those associated with the hard landing risk.
The third side-effect was the end of the first officer landing, because the captains did not want to
risk to pay for someone else handling skill.
The last, but not least, side-effect was the total loss of the pilots’ confidence in the system
considering the FDA tool not as a safety tool but as a “big brother” tool. Without confidence, you
also kill the benefit of the reporting system, which is as well a powerful element of the hazard
identification.

Therefore, without a non-punitive policy, the first step of the safety risk management is really
jeopardized.

In contrast a non-punitive policy will help to assess the safety performance, to identify the hazards
and the root causes and to measure the exposure to the risk, thanks to the flight crew’s
contribution. The objective is to properly mitigate the risk, avoiding only displacing it somewhere
else in the operations as in our previous example.

Of course, the objective of a non-punitive policy is not to hide anything. It is in fact exactly the
opposite.

For the airlines still having a punitive policy, two cases are often emphasized to justify it.

 The first one is violation. First of all, it must be kept in mind that most of the time violations
are by people who want the job to be done. It is also often people from management who are
in search of higher efficiency. Therefore, before any punishment and even for a violation, the
root cause, as for any event, should be identified. It may reveal a systemic issue. After this
36
 investigation, if an unacceptable individual behaviour is identified it should be properly
addressed.

The purpose of a non-punitive policy is not to relieve individual’s responsibility.

 The second case is related to individual weakness. If an occurrence investigation leads to

identifying pilot weakness as lack of knowledge or handling skills, once again, a root cause
analysis should be conducted. A single occurrence does not necessarily reveal a weakness.
Everybody can have a bad day. However, if individual statistics reveal something that can be
considered as a weakness, the objective is to fix it because it may affect the safety of the
operations. Once again, a root cause analysis should be conducted to determine if there is not
a systemic issue such as a lack in the training programme that could affect not only this single
pilot but the whole pilot community. It is then the responsibility of the training department to
evaluate pilots and to assess their competencies. Transferring this information from the safety
department to the training department should be done through a clear and agreed process
that is in line with the confidentiality policy (for instance involving the gate keeper).
If a pilot is definitely not at the expected level, it is the responsibility of the training
department to take action and not the safety department. Each role must be clearly identified
and respected.
Note: It has to be noticed that this process of taking benefit from the FDA readouts for the
training purpose is completely in accordance with what is promoted through the Evidence-Based
Training (EBT).

Data can be used to identify weaknesses, but the training department is in charge of providing
qualified and competent pilots for the operations.

There is much more risk of violating the confidentiality policy than of respecting it, because crew
confidence in the system is a key element in improving safety.

37
 COMPETENT FDA TEAM MEMBERS
To perform an efficient FDAP, having competent team members is paramount.

The required knowledge to properly interpret the read-outs from FDA software includes:

• Operational knowledge such as aircraft characteristics, SOPs, Route and Airport, etc.
• SMS knowledge including Airline safety policy and organisation, risk management, safety
assurance etc.
• FDA software knowledge such as capability and limitation. The purpose is to be able to
understand what is feasible or not, etc.

As stated in the “FDAP Manual: Paragraph 4.3.2”: “All FDAP team members need appropriate
training or experience for their respective area of data analysis”.

Of course, it is not expected that everybody have the same level of knowledge in each area.

For instance, on one hand, we do not expect a pilot to produce a statistic, but we want a pilot to
know what the tool is capable of, to request the proper support, in order to produce the relevant
data to properly analyse the read-outs. On the other hand, we expect the technical support
member to understand and anticipate the need of a pilot, in order to provide the best and the most
relevant data.

It is expected that any FDA team member can put the data into perspective, and if needed, to
challenge the read-outs. For instance, one of the most important aspects is the limitations
associated with the data source and with the tool, as described in the Data chapter and Event
chapter of this document.

Even if dedicated training is organized in accordance with the domain of analysis, a common
module with all the stake holders may be beneficial to understand the expectations and the issues
of each other. This training may include but is not limited to:

• SMS principles review

• Airlines Policy, Organization, and Confidentiality
• Recorders (data sourcing)
• Decoding process
• Processing (derived parameters and event generation)
• Limitations of the software
• Occurrence investigation
• Statistics
• Safety Performance indicators
• Airline Risk Mapping

38
 Example: The necessity to challenge the read-outs

The flight replay of FDA software shows a VFE exceedance event on an A320 as per illustration below.

No report has been filed and the interviewed captain denied having been in such a situation.

In such a case, the read-outs need to be challenged to unveil the truth.

By calling the right parameters, it becomes possible to understand what happens. As per the graph
below, the flap lever has been set to zero before the CAS exceeds the VFE. However, into the replay, the
VFE does not switch to VMO before the Slats angle reaches the 0 value, which is not the case on board.

In fact, this aircraft, like many others, does not record the VFE parameter. This means that the software
must rebuild the VFE parameter. The ideal would be to use the flaps lever position, because the VFE is
updated from it on board on legacy Airbus aircraft. However, this parameter is not recorded.
Therefore, the next step would be to use the configuration parameter, but this one is not recorded
either, and it has to be rebuilt too. The configuration parameter is rebuilt with the Slats and Flaps
configuration parameters which are not recorded but computed from the Slats and Flaps Angles
parameters which are always recorded. In that FDA software, to recognize the Slats position at 0, the
Slats Angle parameter must be at or close to zero. It is only the only way to get the configuration
39
parameter at the 0 position. Therefore, there is a delay between putting the flaps lever position to zero
on board (with the immediate update of the VFE) and the recognition of this position in that FDA
software. It explains why a VFE exceedance event may be triggered while nothing happens on board.

All FDA software are limited by the recordings. FDA software do not have all the same script logics
to bypass these limitations, but somebody within the FDA team should be able to assess the
reliability of the outcomes.

It should be kept in mind that the objective is to be proactive and predictive. For instance, it is better
to set a High vertical G event with a triggering threshold below the hard landing value. It may help
to identify an issue in the landing technics.

Triggering an event before a real exceedance occurs is one of the main principles of the tool. In the
previous case, keeping this VFE exceedance event may help to evaluate the exposure to the risk of
flight envelope excursion. Therefore, there is a need to have people who are able to segregate the
real exceedance from the “close to” event. Without this capability, the following may occur:

 Loss of time and money for unnecessary maintenance activity

 Loss of time at finding a solution for a non-existing issue and inappropriate mitigation
action
 Loss of flight crew confidence in the FDA programme.

In the FDA team, people must be able to know where data comes from to keep a critical eye on
the produced results. The result depends on recorder and software capabilities.

Putting the data into perspective is a necessity to properly analyse the read-outs.

Challenging the read-outs before a flight crew interview is mandatory to keep the crew
confidence in the safety system.

Lack of competencies associated with a punitive policy jeopardizes the FDAP safety objectives

40
 STAFFING
In chapter 4.3 The FDAP Team of ICAO doc 10000 Manual on FDAP, there is a good description of
the different roles and tasks that should be held within such an FDA team. These roles include:

a) Team leader
b) Flight operations interpreter
c) Technical interpreter
d) Flight crew contact person
e) Engineering technical support
f) Air safety coordinator
g) Replay operative and administrator.

Note: In the EASA GM1 ORO.AOC.130 Flight Data Monitoring – Aeroplanes, there is almost the same
description except that there is no mention of an Air Safety Coordinator and the Flight crew contact
person is called Gate keeper.

It has to be noticed that there is no mention of an analyst function. In addition, a detailed reading
highlights that the words “analyse” or “analysis” are not used to describe the different tasks.
However, it can be understood that this analysis task is shared by the Flight operations
interpreter, the technical interpreter, and even the team leader.

Does this team description correspond to what is really in place in an operator’s

organization?

Most of the time, all the previously described activities are covered but through an organization
encompassing two other positions that are frequently called safety analyst and Flight Safety
Officer (FSO) who are in charge of the analysis task.

The safety analyst activities may be (not exhaustive):

• To validate the database (for instance through a cleaning process)
• To distribute occurrences to the FSOs in accordance with the team leader (for instance
through a flagging process)
• To establish the link with the reporting system
• To generate statistics and trends periodically and on request
• Sometimes to run and administrate the software.

Usually, a safety analyst is an engineer with flight ops experience and is mainly in charge of
supporting the team leader and FSO activities.

The FSO is an active pilot or a former pilot who brings their airline’s operations expertise to
interpret the read-outs of the FDA software. With the support of the safety analyst, they will
identify the root causes of occurrences and safety issues. In that way, they are a key player in the
risk identification process. They work in close cooperation with the team leader.

Notes:

In fact, there are many possible organizations, for instance, the team leader is often also in charge of
the safety coordination ensuring that a safety issue is not addressed independently in two different
departments. Sometimes, the team leader also occupies the role of gate keeper. The gate keeper
function may vary from one organisation to another. Sometimes, they are only in charge of assessing
41
if the identity of the flight crew needs to be unveiled, and sometimes they are also in charge of
investigating an occurrence including the flight crew interview.

All of these organisations may be relevant and justified. However, the most important thing is to
establish and maintain the confidence within the pilot community. To achieve this goal, it is
paramount that the process is understood, approved, and applied by all the stakeholders,
management, and pilots.

How many people are necessary to run an FDAP?

This is one of the most recurrent questions asked about FDAP.

As per the ICAO doc 10000 Manual on FDAP - 4.3 The FDAP Team, it mainly depends on the size
of the airline and all the described various functions do not need a dedicated position. In fact, there
are no official figures. However, the following can be considered but only as good practice:

 For a small airline, with less than 10 aircraft, at least one team leader is needed who could be
the safety manager of the airline in addition to an analyst to run the software and an FSO (even
part time) for the investigation. Therefore, it represents a minimum of three 3 people.
 For an airline that has between 10 and 20 aircraft, the organization may be completed with an
independent gate keeper and also engineering technical support to ease the task of both the
analyst and the FSO. The airline may also consider having one FSO per fleet.
 Above 20 aircraft, an airline may consider having one more person (analyst and/or FSO) per
twenty aircraft. The team leader may be different from the safety manager, but they need to
act also as the air safety coordinator.

Of course, all these figures are only a proposal and one size does not fit all. However, it should be
kept in mind, as per the ICAO doc 10000 – 4.3.3:

“With insufficient human resources the entire programme underperform or even fail.”

Notes:

In order to obtain complementary perspectives, an operator may share knowledge from different
departments. For instance, 2 part-time people (one from the safety department and one from the
engineering department) may provide a more synergistic approach than a single full-time analyst
dedicated to the FDA programme.

When an operator subcontracts its FDA activity to a service provider, it does not prevent it from
taking its responsibility to run the FDA Programme. It means there are still people needed to analyse
the read-outs.

Running an FDAP is not only running software, it is producing something relevant for safety.

42
PART 3: DATA

43
 RECORDING CHAIN DESCRIPTION

There are two kinds of recorders on modern aircraft:

• Recorders dedicated to accident/incident investigation which are Flight Data Recorder
(FDR) & Cockpit Voice Recorder (CVR)
• Quick Access Recorders (QAR) to easily retrieve recorded data for purpose of the Flight
Data Analysis.

The following chapters aims at describing the different recording chains from the aircraft systems
to the recorders.

RECORDERS
FDR (Digital FDR – DFDR / Solid State FDR - SSFDR)

The purpose of an airplane FDR system is to collect and record data from a variety of airplane
sensors onto a medium designed to survive an accident. FDR are usually located in the tail of the
aircraft.

Decoding the data from the FRD system can help investigators to understand an accident and to
identify its root causes. Over the years, data has contributed to safety improvement (e.g. through
airplane system design improvements).

However, even if this reactive method at getting benefit from the data is still effective today, it was
also identified that using data on a more proactive way would be much more beneficial. But
because of the non-easy way of retrieving the data from the FDR for the routine collection and
analysis of the data, another more practical solution had to be developed.

QAR

The aim of the Quick Access Recorder is to provide an easy access to the flight data. This kind of
recorders, located in the avionic bay, was originally designed to produce a copy of the FDR data.
This recorded data is called QAR data.

However depending of its plugging position in the avionic bay a Quick Access Recorder can record
and retrieve another set of data. This other set of data is called Digital ACMS Recorder (DAR) data.

Today modern equipment fully integrated allows to retrieve either QAR data or DAR data or even
both.

This will be explained in the next paragraph.

44
 RECORDING ARCHITECTURE
There are thousands parameters transiting on the aircraft network. Parameters represent the
acquired values by sensors. Sensors measure parameters through electrical signals e.g. an
intensity, a tension, a resistance, a capacity…These analogic values are converted into numeric
signals either inside the sensors themselves or through Analogic-Numeric Converters (ANC).

Basically, analogic data (N1, EPR, AOA, CAS …) is converted into digital word made of a sequence
of “bit” (bit is the basic binary unit which value is either 0 or 1).

The common format of the parameter transiting on the aircraft network is defined by the ARINC
429 (32 bits word) protocol.
To record data on the FDR, the Flight Data Interface Unit (FDIU) is in charge of picking parameters
on the aircraft ARINC network from many aircraft computers. The binary data is then encoded on
the recorder following a data frame. The binary code are sorted and arranged in a dedicated
format which is either the ARINC 717 or 767 containing 12 bits words.

This is the Crash Recording Chain.

FDR is a mandatory recording system with a frozen frame for accident investigation. FDR works
on ARINC 717 protocol; it’s located on the rear pressure bulkhead.

Data acquisition computers centralize and format data coming from sensors, onboard computers
and other instruments and then transfer it to FDRs via a dedicated digital link.
There are four types of input:
• Discrete (logical status detection, indicators, switches, relays);
• Analog (potentiometer);
• Synchronization transmitters;
• Digital bus (ARINC 429).

SSFDR (Solid State Flight Data Recorder)

45
The data recorded on the FDR (DFDR/SSFDR) is not easily accessible. However it is still possible
for the routine data collection in the purpose of the FDA to the use of a Portable Data Loader (PDL)
that has to be plugged on FDR front face. But as the FDR recording capacity is only 25 hours, a very
constraining download process has to be put in place in order to retrieve all flights.

Portable Data Loaders (PDL)

To ease the collection of the recorded data a QAR LRU (Line Replaceable Unit) can be plugged in
the avionic bay right after the FDIU (position 3TU). Recorded data is then called QAR data and is
identical to FDR data.

46
There is another way to collect data by plugging the QAR LRU after the Data Management Unit
(DMU) in the avionic bay (position 2TV).
With this setting it becomes possible to record other parameters from many different computers
because the frame is programmable.
The advantage of such a solution is to accede to any stake holder willing without interfering with
the crash recording chain.
In that case, the recorded data is called Digital ACMS Recorder (DAR) data. The format is identical
to the QAR data (ARINC 717)

Note:
In case of leased aircraft, the new operator has to recover the last DAR data frame definition from
the previous operator to be able to decode it.

Nowadays, new equipment exist combining FDIU and DMU capabilities. For Airbus aircraft they
are called Flight Data Interface and Management Unit (FDIMU).

FDIMU provides an easy access to QAR and DAR data. The recording capacity is fully integrated
and there is no need for an additional box.

47
 TO SUM UP
QAR data is a copy paste of the FDR data.
DAR data frame is fully customizable in order to record any convenient parameters to fulfil any
operator objectives (e.g.: FDA, Maintenance, Fuel Monitoring…) provided they are available on the
ARINC network.
An FDIMU allows to retrieve QAR data and/or DAR data depending on its pin programming.

Notes:
Quite often it is said that an aircraft is equipped with a QAR or with a DAR because there is confusion
between the recorder and the data it produces.

A Quick Access Recorder Line Replaceable Unit is an equipment that can produce different types
of data depending on its plugging position.

A QAR LRU plugged after a DMU will provide DAR data.

A QAR LRU plugged after a FDIU will provide QAR data.

The previous architectures cover the largest part of Airbus fleet.

However the A380 and A350 aircraft had some specificities.

Let’s focus on the A350 recorder architecture

The A350 DFDR System architecture is based on a core unit, the Central Data Acquisition Unit
(CDAU). The Virtual Quick Access Recorder (VQAR) is network task located on the FSA-NG (Fly
Smart with Airbus New Generation). It is used for airline/customer operations purposes (e.g.
FDA). The VQAR records the same data content as the SSFDR. The data could be down linked to
the aircraft operations base via the communication means of the FSA-NG or could be downloaded
from the server to appropriate media if required.
48
 DATA FRAME

The data frame definition provides a description of all the recorded parameters encompassing
source, frequency, resolution, maximum value, minimum value, unit, logics, etc... Thanks to the
data frame definition, an operator can decode the binary data encoded on the recorder through
an FDA software.

Extract of Frame description from Sagem

The data frame is programmed by recorders manufacturers e.g. Sagem, Teledyne, Penny & Giles…
The coding is specific to a manufacturer and to the model of the recorder.

On a data frame, words are organized in a specific order and transmitted from the acquisition unit
to the recorder.

A data frame is also defined by the number of words which could be acquired per second.

RECORDER CAPACITY
The capacity of a recorder is the amount of words that can be recorded every second (wps).

QAR data frame capacity size: 64-128-256-1024 wps

DAR data frame capacity size: 64-128-256-512-1024-2048 wps

49
 FRAME ARCHITECTURE
The acquisition unit sends continuous data blocks made of 4 seconds of flight parameters.

Each block is called a frame. Each frame is divided in 4 subframes.

Each subframe represents one second of data, encompassing the number of words per second in
accordance with the recorder capacity (e.g. 256 wps).

Each word is made of 12 bits. These bits contain the active parameter data (N1, EGT, CAS…).

Notes:
• Each frame is identified by a Data Frame Counter (DFC). This parameter counts the
number of frames on the recording.
• The stream is managed by synchronisation words. These words allow to identify the
beginning of each sub-frame validating the sequencing of the recordings. They are
positioned on the first word of each sub-frame.

On word can contain several parameters.

50
Example of parameters recorded on the same word.

ARINC Sampling int.

Parameter Subframe Bit
word (per second)
10 to7
Time (hours) 37 3 ¼ pps
4 to 1
1 10 to7
Time (minutes) 37 ¼ pps
4 to 1
12 to 9
Date (day) 51 1;3 ½ pps
8 to 5
8 to 5
Date (month) 51 2;4 ½ pps
4 to 1
Date (year) 51 2;4 ½ pps 12 to 9
8 to 5
3
Time in hotel mode 4 to 1
16 ¼ pps
(minute) 8 to 5
1
4 to 1

On this extract of a frame description, we observe that the word 51 is used on the sub-frame 2 and
4 to record:

- from bit 1 to 8 the month of the date

- from bit 9 to 12 the year of the date

In this table we also observe that the word 51 is also used to record from bit 5 to 8 the day of the
date but as shown on the table above, on the subframes 1 and 3.
Those three parameters have a sampling interval of ½ pps (point per second) which corresponds
to ½ Hertz. It will be explained in the next paragraph.

51
 RECORDING TIME INTERVAL
A parameter is also defined per its recording time interval. This is the time interval between two
measures. Most of the time it varies from 0.125 second to 4 seconds. It is a period but it is
commonly called the sampling rate of a parameter. It can also be expressed as a frequency of
recording and therefore the hertz is the unit. In some document it can be expressed as a number
of point per second (pps).

1/x sec = x Hz = x pps

Example

A parameter with a sampling rate of 2 hertz is recorded twice per second with a constant interval
of half a second. It appears twice in each sub-frame with a constant number of words between
each recorded value, the parameter occupying the same position in each word.

The sampling rate of a parameter depends on its refreshing rate on board and also on the need to
be updated in order to provide an accurate situation. For instance this is the case of the vertical
acceleration which is a parameter recorded at least 8 times per second or the pitch which is
recorded at least 4 times per second.

Some other parameters do not have this need to be frequently “refreshed” but they are at least
recorded once per frame meaning with a frequency of ¼ of hertz (e.g. the landing gear lever
position on some data frame).

To be comprehensive, some parameters which have no or few variation during the flight do not
need to be refreshed even once per frame (1/4 pps). Therefore in order to save room on the data
frame these kind of parameters are compressed in what is called super-frame. Parameter
recorded on a super-frame will be refreshed once every 64 seconds.

This is the case of the gross weight, the destination or the flight number parameters as per the
extract of the data frame description below.

Flight number 8 to 5; thousands in BDC on 4 bits

113 1 1/64 pps
(super-frame 1, position 1 from FDAU) 4 to 1; hundreds in BDC on 4 bits
Flight number 8 to 5; tens in BDC on 4 bits
113 1 1/64 pps
(super-frame 1, position 2 from FDAU) 4 to 1; units in BDC on 4 bits
A/C ident (airline rank)
113 1 1/64 pps 0 to 255 in binary code
(super-frame 1, position 6 from FDAU)

Notes:

Increasing the sampling rate of parameter requests to have words available on the existing frame.
So, the sampling rate must be adjusted and relevant with the parameter to be recorded.

The sampling rate of a parameter is defined for the whole flight. For instance, it is not possible to
have a parameter with a high frequency during takeoff and landing and with a low frequency during
cruise.

52
Recording interval / sampling rate

Frequency in Hertz Time interval in second Points per second Per frame (4 sec)
¼ Hz 4 sec ¼ pps 1
½ Hz 2 sec ½ pps 2
1 HZ 1 sec 1 pps 4
2 Hz 0.5 sec 2 pps 8
4 Hz 0.25 sec 4 pps 12
8 Hz 0.125 sec 8 pps 32

The table below shows 16 seconds of recording of several parameters each of them with a
different sampling rate. Each line represents 1 second of recording.

We observe 8 values of the vertical acceleration within the same second (one line) and only 1
value every 4 seconds for the N1 Target.

53
 DATA FRAME DESCRIPTION
The data frame description is a document that will allow to identify the position of a parameter
on the frame, its resolution and its sampling rate.

Without this description it is almost impossible to decode the data recorded. Recorded data is only
a succession of words of 12 bits with no identification. To use an FDA software a mapping of all
the parameters needs to be performed to be able to decode the data (it will be detailed in the next
chapter).

The schematic below illustrates the position of the VHF transmission parameter in accordance
with the data frame description.

Interpretation: VHF 1 is emitting when the bit 1 of the word 14 return 0.

54
RAW DATA – ACQUIRED PARAMETER – DERIVED PARAMETER

Parameters extracted from avionic buses and sensors have not mainly been designed for FDA use.
A noticeable amount of work is consequently needed in order to generate information of a high
quality level for FDA purposes.

FDA tool has to be tuned in accordance with recording configuration which depends on the
aircraft type, the engine type, and the type of recorder. There are many existing configurations
with many types of frames. The amount of data, the resolution and the sampling rate vary from a
frame to another. Some parameters can exist on some frames but may not exist on some others.
Sometimes FDA tool has to rebuild parameters which are not available on frame.

An FDA tool must convert the binary value recorded on board into relevant information for the
analyst. This is done in two steps:

First step

The recorded values are called raw data. Thanks to the frame definition this raw data can be
decoded into engineering values that can be interpreted into the FDA tool. The parameters
generated are called acquired parameters.

55
Second step

These acquired parameters must then be converted into an understandable format for the
purpose of the flight data analysis. These parameters are called derived parameters.

FDA software detects spurious parameter behaviours (e.g. a jump during recording). The
derivation enables an automatic smoothing of the erratic values. For instance, if an altitude jump
is observed during 1 s (delta of 10 000 ft.), the software is able to understand that this altitude
value observed during 1 s is erroneous. As a result, the software can extrapolate the previous
value to correct it, and smooth the altitude variations.Examples

PARAMETER DERIVATION
Case 1 – No need for a conversion

In several cases, there is no need for a conversion of the acquired parameter.

This is the case of Boolean parameters. Their values being either 0 or 1.

However, even if the conversion is not needed, if it is done, it is basic:

Derived Parameter = Acquired Parameter

The frame definition is mandatory to properly understand the status of a 0 or 1. For instance the
VHF transmission status is “emitting” when the parameter returns 0 (as the Master Warning
status is “ON” when at 0).

Why to derive such parameter?

The reason is in the way an FDA event is built. The source and the name of an acquired parameter
are not always the same from one frame to another. Deriving the parameter will allow to standardize
the naming that will be used in the event script logic. The event construction will be explained in the
next chapter “EVENT”.

56
Case 2 – Unit conversion

In other cases, the initial unit from the aircraft equipment is not the same unit as directly used in
the cockpit by the pilot.

For pilot or analyst, the unit used are:

• For the EGT: °C or °F
• For the trust: N1 or EPR
• For the fuel flow: Lb/m or L/S.

As a result, a derived parameter is created to convert the acquired value into a known unit.

Example: Flaps position

Parameter Word number Subframe PPS Nb bits Conversion laws

Flap position 7;39 1;2;3;4 2 12 Value = 0.1739*R+12
Value = 0.1782*R+11,93
Value = 0.1408*R-132,2

The conversion laws provides logics to recover the understandable values. They have to be
integrated in the FDA tool.

Derived Parameter = Acquired Parameter X Coefficient + Offset

The table below shows the acquired flaps and slats angle positions and the derived ones.

57
Case 3 – Complex conversion

To illustrate this case, let us take as example of the VFE recovery. Most of the time VFE is not a
recorded parameter. In accordance with its on board logic on legacy aircraft the easiest way to
retrieve this parameter would be to use the position of the flaps lever. Unfortunately this
parameter is not recorded. So the next step would be to consider the aircraft slats/flaps
configuration parameter which is once again most of the time not recorded.

The solution is to use the actual slats and flaps angles to rebuild the desired parameters.

Case 4 – Parameter creation

The derivation also enables the creation of new parameters.

For instance, the vertical speed is quite often not recorded on data frames up to 256 wps, but it
can be easily computed using the altitude and time parameters.

58
 REGULATION

There is no regulation concerning the data to be recorded for FDA purposes.

Regulations on parameters to be recorded only applies to the FDR.
However, as the QAR data is a copy of DFDR, these regulations also apply to it.

These regulations are:

 ICAO - Annex 6 Part I – International Commercial Air Transport -Aeroplanes Chapter

6Para 6.3 - Appendix 8

 EASA - AIR OPERATIONS - Commercial Air Transport

AMC CAT.IDE.A.190 Flight Data Recorder

 EUROCAE - MOPS (European Organisation for Civil Aviation Equipment) – (Minimum

Operational Performance Requirements)
For Crash Protected Airborne Recorder Systems ED-155 / ED-112 / ED-112 A

 FAR 121.334 Digital Flight Data Recorders - Appendix M to Part 121 - Airplane Flight
Recorder Specifications

Whatever the regulation, for each parameter, the range, the sampling rate, the accuracy and the
resolution are defined.

Example: Extract from ICAO Annex 6 Appendix 8

The list of mandatory parameters is very short compared with the need of an FDA programme.

According to the above regulation the number of mandatory parameters varies from 78 to 91,
only.

Airbus has also added to these lists, parameters identified as a minimum necessary, to have an
efficient FDA or to run efficient Handling Quality analysis at Airbus.
All these parameters, required by regulation and defined by Airbus, are mandatory parameters
identified by an M in their label.

M06a = Pitch Attitude

59
On the DFDR data frame there are also parameters recorded on request of Airbus internal
stakeholders.
They are called documentary parameters and are identified by a D in their label.

D09 = Vertical Speed

For the DAR Data Frame there is no regulatory requirement but most of the previous parameters
(Mandatory and Documentary) are recorded.
Standard DAR Data Frames exist but they are fully customizable by the operator.
The modifications of the standard frame will obviously affect the final picture of a flight into FDA
software. Without a comprehensive process these customizations can even prejudice the proper
decoding of the frame.

Note:

There are about 150 standards of QAR Data Frame and almost the same of DAR Data Frame.
150 standards means no real standard!

60
 RECORDING MEDIA

Currently there are 2 ways to retrieve the data from an aircraft:

Solid media (e.g. Optical Disc or PCMCIA Card)

Or

Wireless System called WGL

PCMCIA Card

An integral PCMCIA Interface will allow a rapid data transfer of the complete flight data memory
contents to an extractable ATA Type PCMCIA card. This allows the complete 25 hours of flight data
contents of a 256 wps SSDVDR (36 MB) to be transferred in approximately 150 seconds (2.5
minutes).
The cartridge slot will accept commercially available memory cartridges and AT Attachment
(ATA) cartridges for data transfer applications.

A human action is require to swap PCMCIA card during aircraft rotation.

The common size of a PCMCIA card is from 128 MB to 1 GB.

Currently SD cards can be used through PCMCIA card adaptor allowing bigger memory size.
PCMCIA card can be used (programmed) for recording ACMS data (Reports, SAR data, DAR data)
and/or FDR data (QAR data). Such a PCMCIA recording option has proved to be suitable to a large
number of operators for flight data recording, particularly sparing the need for using an external
QAR 3TU or 2TV LRU equipment or both.

The capacity of the PCMCIA card must be chosen in accordance with the selected recording speed
to allow longer recording autonomy and to avoid frequent downloading.

Recording capability

1 word = 2 bytes = 16 bits (12 useable)

On a 256 wps frame each second represents 512 bytes (1s = 256 *2 bytes =512 bytes)

One hour of recording with a 256 wps frame represents about 2 MB (512 * 3600 = 1 843 200
bytes)

256 wps → ~ 2 MB per flight hour

61
 Example

A 512 MB PCMCIA card with a 44% memory allocation to the DAR data with a 256 WPS frame
allows at recording around 120 hours of flight. This number of flight covered will however depend
on the programmed trigger conditions and the way the aircraft is operated. A speed programming
of 128 WPS will multiple the above autonomy by a factor 2 and so forth.

Wireless system

Wireless system enables automatic transfer of the recorded data when the aircraft is on ground
shortly after landing. It uses cellular/PCS phone communication means and internet network up
to the ground base station computer for data processing.

On 3G GSM, it is also possible to customise the type of data transferred (depends on force signal
availability).

The wireless functionality can be achieved through:

- An additional box plugged after the QAR LRU, or

- A QAR LRU equipped with an antenna for the transmission, or
- A GSM slot directly on the PCMCIA card.

62
PART 4: EVENTS

63
 EVENT OBJECTIVES

A Flight Data Analysis Programme provides a systematic tool for the proactive identification of
hazards.

In that order one of the key elements of an FDA software is to generate events to detect exceedance
« such as deviations from flight manual limits or SOPs…» as per the ICAO 10000 document
(Manual of FDAP).

In that document it is also clearly stated «A set of core events/parameters establishes the main
areas of interest to an operator ». It means there is no standard set of events and it is upon the
operator responsibility to define the events of interest. Even if today most of the operators are
using FDA software provided with a default set of events with defined triggering conditions there
is no standard set of events and no standard triggering conditions. It’s up to the operator to set it
up even if there are some international working groups helping at finding a common way at
generating events (e.g. EOFDM).

Note:

There is a common expectation from operators to get an FDA tool with a benchmarking capability.
It must be highlighted this benchmarking will be relevant only if Airlines compare comparable data.
It seems to be obvious but it means same sources, same decoding logics, same triggering conditions
and even same operations. Therefore it could be necessary to step back in front of FDA forum
proposing to share gross FDA results without a compatibility check.

The purpose of an FDA event is to be generated when a non-desired flight condition is identified.

Most of the time it is said that an event is triggered with a severity level. Depending on the
software used we talk about Low, Medium and High severity event or Class 1, Class 2 and Class 3
event. Some other operators are talking about Test but most of the time a three scale classification
is used with an associated color coding (e.g. Yellow, Amber and Red). This classification is only
based on deviation thresholds and does not necessary represent an actual severity level.

An event by itself is neither a criticality nor a tolerability. It is not a risk assessment.

Example: “Long flare distance” event

In an FDA software a long flare distance event is triggered with a medium severity (Amber event)
when the touchdown occurs beyond 900 m from the runway threshold and with a high severity (Red
event) when the touchdown point is beyond 1,050 m.

If a touchdown occurs at 1,040 m from the threshold, the event will be generated with a medium
severity while if it occurs at 1,060 m the event will be presented with a high severity. But if the first
event occurs on a 2,500 m wet runway and the second one on a 4,000 m dry runway we immediately
understand that the first case can be more critical than the second one.

Events have to be contextualized in order to be risk-assessed.

Unfortunately, as in our previous example, most of the time the first event is not investigated and
only the second one is looked up. The color coding, fostering at only focusing on the red events,

64
creates a huge confusion for people not fully aware about the difference between the triggering
conditions and the risk assessment principles.

The future of FDA tool will have to help to identify the risk exposure, through a proper
contextualization and/or a more relevant event definition. For instance, taking into account the
status of the runway and/or measuring the actual deceleration compare to the required one.

What is the benefit of such triggering conditions if they do not represent the exposition to a risk?

In fact these triggering conditions take sense as soon as you produce statistics and/or trends from
the data base. With such an event using this kind of triggering conditions the statistics will help to
identify a more systemic issue. Here, in our previous example, it could be the trend of the pilots at
landing longer and longer. Querying the DB will tell you where it happens, when, on what king of
aircraft, in which configuration etc…for a complete analysis and a good understanding of the
situation.

The future of FDA tool will also have to keep this trending capability but once again with a proper
contextualization that would potentially be automatic.

Note:

Some event doesn’t really need to have a severity level and could be triggered for information only.
These events usually provide contextual information on the flight.

Example: “Rolling takeoff” event

This event is generated when the aircraft does not stop between the runway alignment and the
takeoff phase. Such an event precludes false “High Thrust on Ground during Taxi” events occurring
at the start of the takeoff roll.

65
 EVENT DESIGN

To be triggered an event is following a script logic.

This script logic compares the current value of one or several parameters to some defined key
values or to some other variables/parameters and as soon as these values are exceeded an event
is triggered with an associated “severity level”.

Most of the time events must also be circumstantial.

To ease at identifying in which circumstances an event must be triggered it is possible to split the
data stream in flight phases inside the FDA tool. For instance to generate an event “speed high in
approach” the flight phase must recognize as the “approach phase” in the FDA software. Without
a proper flight phase identification an event could either be not triggered or irrelevantly triggered.
Most of the events are flight phases related but not all.
Flight phases are explained in the eponym paragraph of this chapter.

Example: “Speed high in approach at 500 ft AGL” event

This event is associated with the monitoring of the unstable approach.

Its script logic compares the calibrated airspeed (CAS) to the approach speed (Vapp), acquired or
computed, and generates an event with a “severity level” in accordance with the bellow triggering
conditions but provided the altitude parameter (Alt) is equal to 500 ft and the aircraft is in approach
phase. Without these circumstantial conditions the event could be triggered anywhere, even at
takeoff.

If Alt = 500 ft AGL and Flight Phase = Approach and

CAS > Vapp + 5 kts → Yellow / low severity level / Class 1

CAS > Vapp + 10 kts → Amber / medium severity level / Class 2
CAS > Vapp + 15 kts → Red / high severity level / Class 3

Sometimes a Time Over Limit (TOL) condition is added to the script logic to confirm the deviation.

Example: “Speed high in approach below 2,500 ft AGL” event

The script logic compares the calibrated airspeed (CAS) to the below key values to trigger an event
with the according severity level provided the aircraft is in approach phase, the altitude parameter
is below 2,500 ft and the deviation is realized for at least 10 consecutive seconds (TOL 10 sec).

If Alt ≤ 2,500 ft AGL and Flight Phase = Approach and

CAS > 220 kts for a TOL ≥ 10 sec → Yellow / low severity level / Class 1
CAS > 230 kts for a TOL ≥ 10 sec → Amber / medium severity level / Class 2
CAS > 250 kts for a TOL ≥ 10 sec → Red / high severity level / Class 3

66
 EVENT THRESHOLDS

As we have seen it in the previous paragraph, the severity level is not a risk assessment however
it takes fully sense as soon as you think about statistics and trends. One of the main issue is to
determine the triggering values. For instance where to put the threshold for declaring a high
severity or class 3 event?

Let’s talk about the “High vertical G at touchdown” event. Setting the high severity threshold at
the hard landing value from a maintenance point view will prejudice the proactive objective of an
FDA programme. Such an event will be triggered only if a hard landing occurs while it is much
more interesting to identify, with an FDA software, a trend at landing with higher and higher
vertical G in order to mitigate the risk of hard landing before it occurs.

On Airbus A320, a load report 15 is generated as soon as the vertical acceleration parameter
exceeds 2.65 g at touchdown and a hard landing should be considered. Setting the high severity
event threshold at this value (2.65 g) will bring the system only on a reactive mode and divert the
FDA software from its original aims. An FDA software, even if, as per the ICAO doc 10000, can
contribute to some aircraft monitoring (e.g. fuel consumption), is not a maintenance tool.

There is another issue at setting the high severity event threshold at 2.65 g.
What about a 2.0 g landing for instance? Can it be considered as “normal” or even “acceptable”
because there will be no red event? Definitely not. We want the FDA software to help at being
proactive. Therefore, the thresholds should be adapted to what is consider as “normal” and not
only to be set at the structural limits or flight envelop limits.
On our “high vertical G” example a high severity may be triggered when the recorded vertical
acceleration at landing is beyond 1.75 g.

Thresholds determination

Even if the aim of an event is now understood the way to determine the triggering threshold is not
always so easy and obvious?

The event threshold determination can be done taking into account:

- the aircraft limitations,

- the flight envelop,
- the Standard Operating Procedures (SOPs),
- the operational experience,
- the context,
- the flight operational analysis.

Thresholds can be set with (as seen previously) or without margins in accordance with what has
to be monitored. For instance, if an event monitors the overweight landing situation, the threshold
can be set directly at the MLW with, as associated event snapshot parameter, the value of the
vertical speed at TD.

Note:
Here, it could also be interesting to get, for each flight, the weight at touchdown to monitor through
a distribution graph of this parameter, potential overweight landing situations. This derived
parameter is easy to build because using the same logic than the event one (without thresholds).
Many derived parameter snapshots could be computed following the event logic to ease monitoring.
67
In Airbus, as far as it is possible, we try to determine these thresholds on a scientific way based on
the flight operational analysis principles. Customers’ data are aggregated to generate gossan
curves or clouds of points, out of which we are able set area that would be considered as “normal”
and beyond or below which events should be triggered.

The following graphs provide a vertical acceleration distribution for the A330 type at landing.

By studying these graphs it makes sense at setting the first threshold of the event “High vertical G
at Touchdown”, at 1.5 g.

Notes:
The triggering conditions for events related with the aircraft limitations or envelop should not be set
beyond these limits.

On a maintenance point of view hard landing conditions are not the same on all aircraft types. For
instance on some legacy aircrafts vertical acceleration has to be combined with the vertical speed to
trigger a load report 15 while on A350 this is the roll angle parameter associated with the vertical
and lateral acceleration to generate a SOMF report (equivalent to LR 15 on legacy). An FDA software
is not a maintenance tool therefore the logic for the “high vertical g at landing” event does not have
to comply with a maintenance logic.

For an Airlines operating several types of aircraft e.g. A320 and A330 as the landing technics are
comparable the thresholds should be considered as being identical. However and once again it is
upon the operator responsibility to set the thresholds in accordance with its interest.

Because the event threshold determination is a key element in the building of an FDAP it should
be done by competent stakeholders e.g. experienced pilots, engineers and analysts.

Except for events which are using Boolean parameters, which are true or false, most of the events
are based on the magnitude of deviation and sometimes combined with the duration of this
deviation.

68
Magnitude and duration

An event with a high parameter deviation on a short

period of time (E1) can be generated with a lower severity
than another one with lower deviation but for a longer
period of time (E2).

Example: “Speed high in approach below 2,500 ft AGL” event

As a reminder this event is triggered red when the calibrated airspeed exceeds 250 kt for a time over
limit period of 10 seconds.

In the table above we observe a higher CAS on the amber highlighted event (252.50 kts) than on the
red ones. This is due to the time over limit condition which is not realized. In other words the CAS
was beyond 250 kts but not for 10 consecutive seconds.

Severity interpretation

As it has already been highlighted the gradation of an event is mainly based on magnitude of the
deviation and it is not directly associated with a risk assessment. So how to consider this
gradation?

A “low severity” or yellow or class 1 event represents a low deviation from what is consider as
“normal” or “acceptable”. By itself a single one “low severity” event doesn’t represent an
exposition to a specific risk and therefore doesn’t need to be further investigated. However a huge
amount of “low severity” events could indicate a systemic issue that could leads to events of higher
severities if no corrective actions are taken. This kind of severity level give a picture on the
operations it is useful for statistics and trends.

Example: “long flare distance” event

A very high number of low severity long flare distance events could indicate an issue concerning the
landing technics. A further database investigation will allow at identifying the root cause of such a
deviation in order to take action before higher severity events occur, exposing the Airlines to the risk
of runway overrun.

69
A “high severity” or a red or a class 3 event is triggered when the deviation is considered high.
Today, most of the operators, focus on it, investigate it, because they consider it seriously,
because…it is red.

On one hand, the investigation may reveal a real risk exposure with a systemic issue and therefore
it takes full sense. On the other hand, the investigation may unveil nothing because it is just an
isolated case without being expose to a risk.

Future FDA tool will have to help to focus on occurrences that worth at being investigated and to put
aside, without deletion, the others. Once again, contextualization and/or better event definition are
the keys for a better analysis.

Example: “over reaction during TCAS event” event

It could be an isolated case generated only because of the on time circumstances or it can indicate a
misunderstanding of the procedure due to a lack of training affecting all the pilots within the Airlines.
The safety department may communicate on that occurrence and propose, based on its investigation,
a reinforcement of TCAS exercise during recurrent simulator sessions. It will allow at correcting this
issue to mitigate the associated risks.

Between the yellow and the red events there is usually a third intermediate gradation: the
“medium severity” or amber or class 2 event. It helps at providing a finer vision on the operations.
Usually when an event has a triple graduation, there is a lot of yellow, less amber and few red.
However as it has been illustrated in the introduction of this chapter “Event”, in some occasion an
amber event can unveiled a more critical situation than a red one depending on the circumstances.
Today, this is only the expertise of the personnel involved in the safety department that will help
to identify such a situation. Expertise in the operations, the network, the SMS concept, the safety
tool etc…, to be able to contextualize the occurrence in order to assess the associated risk.

As it has been already said the future of the FDA tool will propose a contextualization of the event
to be more risk oriented. However the events based only on the magnitude will continue to bring
interesting information on the way aircrafts are handle whatever the circumstances are. For
instance would we consider that a touchdown occurring at 2,000 m from the threshold on a dry
4,000 m dry runway is a normal way of landing because we are not expose to the risk of runway
overrun?

70
 FLIGHT PHASES
As it has been previously explained, to simplify the triggering conditions in the script logic of an
event the data stream is split into flight phases. Most of the events, but not all, can be then flight
phase related. For instance to generate the event “Vertical speed high before touch down” the
FDA flight phase must be recognized as the landing phase.

FDA flight phases do not correspond necessary to the FMS/FWS flight phases.

Notes:

Defining flight phases is not an easy task. For instance, what are the triggering conditions for a go-
around? The easiest way to identify a go around would be to consider the thrust levers angles. So as
soon as an aircraft is on approach and the TLA is set to TOGA then you are in go-around phase. In
fact using this logic will prevent you at identifying a go-around where the TOGA detent is not set,
voluntary or not, while this is probably the most interesting thing to catch when analysing a go-
around. That’s the reason why, the logic to recognize a go-around can be based on the vertical speed
and the altitude change.

Hereafter, an example of a FDA data stream sequencing

When the flight phases are properly defined the event script logic could be simplified as followed:

If [flight phase = desired flight phase]

and
[selected parameter is beyond defined threshold]
then [trigger event]

71
A flight phase should be as generic as possible, and its computation must use only a reduced list
of basic and reliable parameters. The aim is to use the same flight phase detection logics for all
recorder/frame combination.

Simplification of the script is definitely not the only reason for defining the flight phases. The flight
phases are also used to identify hazards, their associated risks and finally defining events
revealing precursors and/or contributors.

Example: Takeoff flight phase

Hazard Associated events

• High pitch at take-off
• High pitch rate at lift-off
Low energy after lift-off • Overweight take-off
• Take-off configuration warning
• Over rotation at take-off
Windshear • High vertical acceleration at take-off
• Windshear warning
Being out of protected trajectory • GPS Primary Lost

Events can be flight phase related or not. For instance, a GPWS warning event can be triggered
without a flight phase condition.

When flight phase related, the events can be conditioned to one or several flight phases. For
instance, the “High EGT” event is triggered either at takeoff or go-around to comply with the
manufacturer limitation.

72
If an event monitors the deviation of a parameter but with different triggering conditions, function
of the flight phases, it could be then more relevant to create several events to achieve their
operational goals, because they are not necessary similar.

Example: “High vertical acceleration” events

It is interesting to monitor this vertical acceleration at lift-off, in flight and at touchdown but, of
course, with different triggering conditions.

Thresholds at lift-off

Thresholds in flight

Thresholds at landing

Even if, it would be possible to create a single event with different triggering values in accordance
with the flight phases, here it is much more relevant to create three events because their operational
goals are not identical.

At lift-off the purpose of such an event is to identify precursors or contributors for the tail strike risk.
In flight, it is associated with the loss of control in flight (LOC-I) risk. At touchdown, it is the hard
landing risk.

73
 EVENT TYPES
There are two types of event:

• Single event monitoring deviation of one or several parameters (as described in the
previous paragraph) and are triggered with a severity level in accordance with the
thresholds definition,
• Combined event using several single events in order to identify specific condition.

Example: “Continuously high in approach” event

It is possible to use the slope deviation in approach measured at different gates, for instance, 1,000
ft, 500 ft and 50 ft, each of these measures generating a single event and to combine them into a
unique event to provide the information about the aircraft position on the slope during the whole
approach.

Combined events are not only rated with the sum of the severity of the relevant single events but
also by taking into account the trends. If there is a degradation of the situation, the combined event
will have a higher severity than if there is a recovery.

The same principle can be applied for LOC deviation and approach speed (high or low).

Examples of combined events:

• Continuously low/High on approach

• Continuously Slow/Fast on approach
• Continuously Steep during final
• Bank Continuously excessive close to ground

74
In these examples each combined event, combines single events measuring the deviation of an
identical parameter but at different gates. It is also possible to combine events which are not
similar. For instance, the “Tail Strike hazard at takeoff” event may combined the “Pitch high at
takeoff” event and the “Pitch rate high at takeoff” event.

Notes:
Today there is a huge willing at using the FDA to identify unstable approach conditions. The
combined event principle can be used to achieve it. The logic to trigger an “Unstabilized Approach”
event may have to be in that case an “or” condition instead of an “and”, because an approach can
be unstabilized because of the speed or the vertical speed or the vertical flight path or the lateral
flight path or the configuration or the thrust setting etc…

Again, as it has been explained in the “Event Threshold” paragraph, it could be interesting to get, for
each flight, a derived parameter snapshot, representing here, the stabilization altitude to create a
distribution graph to monitor the unstabilized approach complementary to the event.

75
 EVENT CUSTOMIZATION
FDA software are provided, most of the time, with a set of core events with default logics and
thresholds defined by the software provider. As per the ICAO standards it is upon the
responsibility of the operator to review and validate this set.

Therefore events are customizable in order to suit to the Airlines’ safety policy, their SOPs and of
course their operational constraints.

Usually, the fine tuning of the events is done after the acquisition of an expertise by the safety
department practicing the software. It’s a continuous process where the FDA results are analysed
and evaluated.

The customization should be done with the objective of increasing the relevancy and the efficiency
of the read-out of the software. The purpose is really to improve the identification of hazards and
not to hide anything.

Threshold Customization

Threshold Customization should follow some basic rules. For instance, the new thresholds should
be tested to confirm their relevancy. This testing can be done either by reprocessing data known
as containing incidents that should be identified by the new event or by running the software with
both events, the old and the new one, in parallel during a testing period which can last several
weeks or months. After this period of time, if the test is positive, the new event, providing better
results, will replace the old one.

Example: “High vertical speed in final” event

The vertical speed thresholds for this event are set accordingly with a standard 3° flight path angle.
The vertical speed is directly linked with the flight path angle and the approach speed of the aircraft.
If the final path on a specific airport is well above this standard 3° flight path angle the current
vertical speed could be too close to the event triggering values. Therefore too many events can be
triggered and finally pollute the database where interesting occurrences may be hidden. In such a
situation reviewing the thresholds should be considered.

Be careful with event threshold customization, not to hide real events or real safety issues!
The tuning of a threshold must be done and review with pilots, engineer and flight safety officer;
and must be validated on the next occurrence/statistic report.

76
Logic Customization

Sometimes the threshold customization does not answer completely to the operator expectation
and this is the event script logic that has to be customized. For instance, in our previous example,
the customization of the thresholds will have to be set only for specific airports with high flight
path angle in final. This is achievable through the customization of the event script logic.

An event can also be disable in specific conditions. A final approach with a continuous turn will
generate events like “high bank in final” and/or “heading deviation” if they are not disable in such
conditions. It is very important to disable these events for such an approach within the script logic
otherwise the statistics on those events will be polluted by the outcomes on that approach.
Usually, if an event customization is not implemented, what is known as an operational cleaning,
has to be performed. This cleaning process is time consuming, therefore a relevant script logic
customization is preferable when possible.

The logic customization could finally concern the use of specific parameters available on the frame
which could be more relevant than those ones used in the current script logic. For instance, as
seen is the chapter “Data”, the VFE is often a not recorded parameter. To trigger the “over speed”
event, the script logic uses the recomputed VFE using the slats and flaps angles parameters. It is
known that this script logic induces a delay in the actualization of the VFE. Therefore, it is much
relevant to customize the script logic with the real VFE, if it is an acquired parameter available on
the data frame.

77
 FDA SOFTWARE

Configuration and principle

Whatever an FDA Software is, all the following steps have to be performed in order to make
aircraft data readable and to give sense to it:

• Decoding: the format of the raw data file recorded on board has to be recognized and the
data to be decoded in accordance with the frame definition. The decoding provides
engineering values called acquired parameters.
• Transcription: acquired parameters need to be treated in order to be understandable by
the end-users (e.g. safety analyst or pilot). These parameters need to be filtered or soften
in case of gap or spike in the recording. Some parameters which are recorded may need to
be completely rebuilt. All these tasks are achieved through script logics and provided what
is usually called derived parameters.
• Event creation: to comply with the FDA tool objectives events haves to be created to
identify specific situations. It is done through script logics (including thresholds) using,
most of the time, the derived parameters.

The two last steps are often known as the processing. It means that processed data refered to
derived parameters and events. However, sometimes, the processing is understood as the full
process encompassing the decoding. It is very important to be able to make the difference between
all of these data when talking to the authorities, to the aircraft manufacturers, to software and/or
service providers etc… Because, depending on the need, you may have to provide different data.

Calibration file

To achieve the full process an FDA software needs a calibration file.

To elaborate this calibration file, the following must be known:

• Aircraft type

It must be as accurate as possible e.g. A320-214, A320-271N.

An aircraft type has limitations and envelop that can vary from one version to another. It could
impact the decoding and the transcription of the data and finally the specification of the events.

• Engine type

Each aircraft type can be equipped with engines from various suppliers e.g. CFM, GE, Roll-Royce.

78
Each supplier can provide various engine types and version with different limitations.

Different engine type version: CFM 56-5A1 / CFM 56-5A3 …

Different Engine unit: EPR / N1
Different limitation: EGT, Vibration…

• Recorder type

An aircraft can also be equipped with different recorders. On the same aircraft type with the same
engines, recorders can be from many different suppliers e.g. Teledyne, Sagem with many different
pin-programs. The amount of available data and its format is therefore affected.

• Event specification

According to the previous information the replay and events are adjusted to provide the most
relevant read-outs in the FDA software. For instance if the engine setting is EPR the replay should
display EPR and not N1. The “overweight landing” event must be adjusted to maximum landing
weight which can vary from one version to another on the same aircraft type.

The result is a calibration file. And once again, whatever the FDA software is, without a calibration
file the decoding, the transcription and the generation of event is not achievable.

Note: on AirFASE this file is called a FAP - “Flight Analysis Program”.

79
Caution:

In an Airline operating several aircrafts but only a single type with the same engine type, on a pilot
point of these aircrafts are similar but on an FDA point of view the result may be completely
different from one aircraft to another because of the recording installation. On one of these
aircrafts you may have a frame of 1024 wps (words per second) while on another one the frame
has only 128 wps. Obviously the image of those two aircrafts, provided by the FDA software, will
be different. (This will be reviewed in the FDA tool limits paragraph)
The frame of 1,024 wps will provide more parameters, with a better resolution and with a higher
sampling rate. It will be then possible to create more events and the events will have a better
accuracy.

As the consequences the level of analysis may be different from one aircraft to another.

Finally, the statistics will also be impacted.

Example: Landing Gear parameter

On a 128 WPS frame, the landing gear position is barely never recorded. In AirFASE, to compensate
the lack of this parameter and to avoid at showing, either a flight with the landing gear permanently
extended or a landing without the landing gear extended, the landing gear is arbitrary set up shortly
after takeoff and down passing 2,000ft in approach.
As the consequence, for instance, the event “Late landing gear extension in approach”, which is
normally triggered when the landing gear is not set down below 1,000 ft to monitor this criteria for
unstabilized approach, cannot be triggered. On a 1,024 wps frame, this parameter is available and
the former event can be triggered. So if a statistics is done, without taking into account this setting,
it may lead at identifying a wrong issue and wasting time at finding solutions e.g. new aircrafts
generating events VS old aircrafts.

80
 FDA TOOL LIMITS
An FDA tool, even if very powerful, is limited. Limited by the data itself but also by the software
settings and its script-logics. This paragraph presents some of these limits.

Recording

As seen in the previous paragraph, for a same aircraft type, the data frame capacity may vary from
1 to 8, from one MSN to another. The retrieved image of a flight will be obviously affected by this
difference. Furthermore, nothing will provide this information, into the software, to the end-user.
Only a deep parameter study may unveil this fact.

Refreshing rate

The refreshing rate of a parameter sent to a recorder is not the same than the refreshing rate of
this parameter sent to an aircraft computer. For instance, the pitch angle is refreshed on board at
20 Hz while the best sampling rate for this parameter on a recorder frame is 8 Hz.

Resolution

The resolution of a parameter sent to a recorder is also not the same than the resolution of this
parameter sent to an aircraft computer. For instance, on board, the pitch angle resolution is
0.0005° while the highest recording resolution is 0.17°. Of course this resolution is well enough
for replaying a flight but it characterises the fact that what you are looking at, in the software, is
not identical to what has been seen by the pilot, on board.

Rebuilt parameters

Many parameters are not recorded. Some of them are paramount to properly run an FDA software.
Therefore these parameters have to be rebuilt inside the software.

The sampling rate and the resolution of a rebuilt parameter will depend on the acquired
parameters that have to be used to rebuild the missing parameter. It can be completely distorted
from the reality.

Once again, inside an FDA software, you may have, for a same aircraft type but for different MSN,
sometimes the acquired parameter and sometimes the rebuilt one.

Replay

There is a lot of issues at replaying a flight.

The sampling rate is not identical for all parameters. Therefore, the replay will either extrapolate
the values of parameters with lowest sampling rates or hide values of parameters with the highest
sampling rate. On the former case, the software will show values with no idea on the confidence
we can put on it. This may provide a wrong picture of what really happens during very dynamic
phases like takeoff or landing. On the latter case (hiding values), the question is, which values have
to be shown and which ones have to be hidden. As consequences, you are never sur that the replay
image represent exactly what happens and only a deep parameter investigation, as using the List
& Trace module in AirFASE, will allow at understanding and correctly analysing some situations.

81
Some software propose a replay at 1 Hz. In that case, snapshot values are put at the beginning of
each second whatever the moment of recording within the second is. Parameters with high
sampling rate, have only one value displayed. It can be either the first recorded one or the highest
recorded value within the second regardless of its time position on the frame. Therefore, a 1 Hz
replay may have a lag that may lead to a misinterpretation.

Some software propose a replay at 30 Hz. In that case, the image is very fluid and it seems to be
very realistic. However, it must be kept in mind that what you are looking at, is mainly a
reconstruction. It is much more difficult to put the data into perspective facing a replay with such
a high visual quality.

Data & Script-logics

As already developed, an FDA software provides automated event detection through script-logics.
These scripts are parameter-based. If the status of Boolean parameter changes from false to true,
if a discreet parameter exceeds certain values etc…, an event is triggered.

Therefore, the validity of an event will depend of the parameters used.

Experience shows that parameters recording may be affected by:

• Sensor failures
• Offsets (BIAS)
• Temporary erratic values

A set of consistency tests allow automatic detection of some, but not all, recording errors, which
leads to degraded or rejected flights.

Engineering Cleaning

Therefore, an engineering cleaning has to be performed to put aside or to delete events that are
wrongly triggered due to recordings errors (sometimes it is even the entire flight that has to be
put aside or deleted). For instance, an overweight landing at 430 Tons on an Airbus A320 is
obviously false. The event overweight landing should be deleted or invalidated. If it is not done
these kind of events (and/or flights) will pollute the database and therefore the statistics.

Operational Cleaning

Sometimes, an event is correctly triggered in accordance with its script-logic and its threshold
settings but is not representing the operational deviation that it should monitor. For instance,
performing a circle to land after an ILS approach, events such as, Loc deviation or G/S deviation
will be triggered, but they do not correspond to the operational goal of monitoring the ability of
the pilot at following an ILS.
In that case, an operational cleaning is necessary to confirm or to put aside the events.

Without the two previous cleaning the database cannot be exploited. Cleaning is the first and most
important task of the flight data analysis.

Script Limits

Sometimes, the script-logic used to generate an event does not answer comprehensively to the
situation it is supposed to monitor.

82
In AirFASE, the “Level Bust” event is monitoring if the aircraft altitude vary from the altitude set
in the FCU window. For instance, during a level off, if your altitude exceed by more than 350ft the
target altitude a red event will be generated. This event will cover many situations, but not all. For
instance, if you are clear to climb to the FL 120 and you select in the altitude FCU window the
FL130, when levelling off at this flight level you will really be in a situation of level bust but the
FDA software will not trigger any event.

CONCLUSION
As explained in all the previous chapters of this document, FDA team members must be competent
and therefore, well trained in order to understand all the different aspects of an FDA programme.
They need to have the necessary knowledge to understand what they are looking at in order to be
able to challenge the read-outs and to efficiently run the programme. This knowledge
encompasses data and the way it is treated inside an FDA software. Once again, it is crucial for the
achievement of the SMS goal.

83