CAA Paper 2002/02 - Final Report on the Helicopter Operations

CAA Paper 2002/02 - Final Report on the Helicopter Operations
Safety Regulation Group
CAA PAPER 2002/02
Final Report on the Helicopter Operations
Monitoring Programme (HOMP) Trial
CAA Contract No. 041/SRG/R&AD/1
www.caa.co.uk
Safety Regulation Group
CAA PAPER 2002/02
Final Report on the Helicopter Operations
Monitoring Programme (HOMP) Trial
CAA Contract No. 041/SRG/R&AD/1
Report prepared by B. D. Larder, Principal Applications Consultant,
Smiths Aerospace, Electronic Systems - Southampton
Important Note
The CAA has made many of the documents that it publishes available electronically (in addition to
traditional printed format). Where practical, the opportunity has been taken to incorporate a clearer
revised appearance to the documents. Any significant changes to the content of this document will be
shown in the Explanatory Note. If no such changes are indicated the material contained in this
document, although different in appearance to the previously printed version, is unchanged. Further
information about these changes and the latest version of documents can be found at www.caa.co.uk.
25 September 2002
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
© Civil Aviation Authority 2002
ISBN 0 86039 877 3
First edition 25 September 2002
Enquiries regarding the content of this publication should be addressed to:
Research Management Department, Safety Regulation Group, Civil Aviation Authority, Aviation House,
Gatwick Airport South, West Sussex, RH6 0YR.
The latest version of this document is available in electronic format at www.caa.co.uk, where you may
also register for e-mail notification of amendments.
Printed copies and amendment services are available from: Documedia Solutions Ltd., 37 Windsor
Street, Cheltenham, Glos., GL52 2DG.
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
List of Effective Pages
Part
Section
Page
Date
iii
25 September 2002
iv
v
Part
Section
Page
Date
Section 4
16
25 September 2002
25 September 2002
Section 4
17
25 September 2002
25 September 2002
Section 4
18
25 September 2002
vi
25 September 2002
Section 4
19
25 September 2002
vii
25 September 2002
Section 4
20
25 September 2002
viii
25 September 2002
Section 4
21
25 September 2002
ix
25 September 2002
Section 4
22
25 September 2002
x
25 September 2002
Section 4
23
25 September 2002
Section 1
1
25 September 2002
Section 4
24
25 September 2002
Section 2
1
25 September 2002
Section 4
25
25 September 2002
Section 2
2
25 September 2002
Section 4
26
25 September 2002
Section 2
3
25 September 2002
Section 4
27
25 September 2002
Section 2
4
25 September 2002
Section 4
28
25 September 2002
Section 2
5
25 September 2002
Section 4
29
25 September 2002
Section 2
6
25 September 2002
Section 4
30
25 September 2002
Section 2
7
25 September 2002
Section 5
1
25 September 2002
Section 2
8
25 September 2002
Section 5
2
25 September 2002
Section 2
9
25 September 2002
Section 5
3
25 September 2002
Section 2
10
25 September 2002
Section 5
4
25 September 2002
Section 2
11
25 September 2002
Section 5
5
25 September 2002
Section 2
12
25 September 2002
Section 5
6
25 September 2002
Section 2
13
25 September 2002
Section 5
7
25 September 2002
Section 2
14
25 September 2002
Section 5
8
25 September 2002
Section 2
15
25 September 2002
Section 5
9
25 September 2002
Section 3
1
25 September 2002
Section 5
10
25 September 2002
Section 3
2
25 September 2002
Section 5
11
25 September 2002
Section 3
3
25 September 2002
Section 5
12
25 September 2002
Section 3
4
25 September 2002
Section 5
13
25 September 2002
Section 3
5
25 September 2002
Section 5
14
25 September 2002
Section 3
6
25 September 2002
Section 5
15
25 September 2002
Section 3
7
25 September 2002
Section 5
16
25 September 2002
Section 4
1
25 September 2002
Section 5
17
25 September 2002
Section 4
2
25 September 2002
Section 5
18
25 September 2002
Section 4
3
25 September 2002
Section 5
19
25 September 2002
Section 4
4
25 September 2002
Section 6
1
25 September 2002
Section 4
5
25 September 2002
Section 6
2
25 September 2002
Section 4
6
25 September 2002
Section 6
3
25 September 2002
Section 4
7
25 September 2002
Section 6
4
25 September 2002
Section 4
8
25 September 2002
Section 6
5
25 September 2002
Section 4
9
25 September 2002
Section 6
6
25 September 2002
Section 4
10
25 September 2002
Section 6
7
25 September 2002
Section 4
11
25 September 2002
Section 6
8
25 September 2002
Section 4
12
25 September 2002
Section 6
9
25 September 2002
Section 4
13
25 September 2002
Section 6
10
25 September 2002
Section 4
14
25 September 2002
Section 6
11
25 September 2002
Section 4
15
25 September 2002
Section 6
12
25 September 2002
25 September 2002
Page iii
CAA PAPER 2002/02
Part
Section
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Page
Date
Section 6
13
25 September 2002
Section 6
14
25 September 2002
Section 6
15
Section 6
Section 6
Page
Date
Section 9
4
25 September 2002
Section 9
5
25 September 2002
25 September 2002
Section 10
1
25 September 2002
16
25 September 2002
Section 10
2
25 September 2002
17
25 September 2002
Section 10
3
25 September 2002
Section 6
18
25 September 2002
Section 11
1
25 September 2002
Section 6
19
25 September 2002
Section 12
1
25 September 2002
Section 6
20
25 September 2002
Section 6
21
25 September 2002
Section 6
22
25 September 2002
Section 6
23
25 September 2002
Section 6
24
25 September 2002
Section 6
25
25 September 2002
Section 6
26
25 September 2002
Section 6
27
25 September 2002
Section 7
1
25 September 2002
Section 7
2
25 September 2002
Section 7
3
25 September 2002
Section 7
4
25 September 2002
Section 7
5
25 September 2002
Section 7
6
25 September 2002
Section 7
7
25 September 2002
Section 7
8
25 September 2002
Section 7
9
25 September 2002
Section 7
10
25 September 2002
Section 7
11
25 September 2002
Section 7
12
25 September 2002
Section 7
13
25 September 2002
Section 7
14
25 September 2002
Section 7
15
25 September 2002
Section 7
16
25 September 2002
Section 7
17
25 September 2002
Section 7
18
25 September 2002
Section 7
19
25 September 2002
Section 7
20
25 September 2002
Section 7
21
25 September 2002
Section 7
22
25 September 2002
Section 7
23
25 September 2002
Section 7
24
25 September 2002
Section 8
1
25 September 2002
Section 8
2
25 September 2002
Section 8
3
25 September 2002
Appendix 1 to Section 8
1
25 September 2002
Appendix 1 to Section 8
2
25 September 2002
Appendix 1 to Section 8
3
25 September 2002
Section 9
1
25 September 2002
Section 9
2
25 September 2002
Section 9
3
25 September 2002
25 September 2002
Part
Section
Page iv
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Contents
List of Effective Pages
iii
Foreword
vii
Glossary of Terms
viii
Executive Summary
Section 1
Introduction
Section 2
FDM Background Information
Section 3
Section 4
FDM – A powerful safety tool with proven benefits
1
The FDM process
8
Integrating FDM into the existing safety management system
11
Some lessons from fixed wing FDM experience
14
The HOMP Trial
Background to the HOMP trial
1
HOMP feasibility study
2
Review of helicopter operational accidents and occurrences
3
HOMP trial
3
HOMP Trial Equipment and Data Analysis
On-aircraft equipment
1
Ground-based equipment
5
HOMP software
5
HOMP data analysis
Section 5
13
HOMP Trial Operational Experience
Project programme
1
On-aircraft system
1
HOMP software
4
HOMP analysis
7
HOMP operational and management experience
25 September 2002
x
14
Page v
CAA PAPER 2002/02
Section 6
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP Trial Results - Flight Data Events
Individual events
Section 7
Section 8
1
Event trends
16
Discussion
24
HOMP Trial Results - Flight Data Measurements
Flight information
1
General flight data measurements
1
Mapping the helideck environment
3
Offshore take-off and landing profile measurements
16
Discussion
24
HOMP Trial results – HOMP operations
Implementing the HOMP within BHL
1
HOMP policy statements and agreements
3
Appendix 1 to Section 8
Section 9
Section 10
Introduction
1
HOMP Philosophy
1
Normal HOMP functions
2
Procedures to be followed during exceptional circumstances
3
HOMP Full Scale Implementation
HOMP requirements
1
Estimated HOMP implementation and operating costs
2
Conclusions
Conclusions related to the objectives of the HOMP trial defined in Section
3.2
1
Additional conclusions
Section 11
Recommendations
Section 12
References
25 September 2002
2
Page vi
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Foreword
The research reported in this paper was funded by the Safety Regulation Group of the
UK Civil Aviation Authority and Shell Aircraft Limited. The work was instigated at
Smiths Aerospace Electronic Systems - Southampton and carried out by Bristow
Helicopters Limited in response to the conclusions and recommendations of earlier
research performed for CAA and reported in CAA Paper 97005.
The CAA considers that the trial has been very successful in demonstrating real safety
benefits, and that it has exceeded all expectations. A measure of its success is that
the UK Industry has voluntarily elected to fully implement HOMP across all its North
Sea helicopters in advance of any regulatory action. This initiative has been led by the
UK oil industry (UK Offshore Operators Association - UKOOA), who are funding the
programme through a levy on the helicopter hourly charter rates.
The CAA is continuing to promote HOMP by funding and otherwise supporting its
extension to a second helicopter type (Sikorsky S76), and to a second helicopter
operator (CHC Scotia Helicopters Limited at Aberdeen). This work is being coordinated with the industry-led full scale implementation and is designed to expedite
and assist that process. Work on enhancing HOMP is also planned and will involve
the addition of: a measure of low airspeed; pilot workload algorithms; facilities for
mapping of helideck environments (turbulence and elevated temperatures); means of
allocating severity values to ‘events’.
In addition, the CAA proposes to use this report to lobby ICAO for the extension of
the recent amendment to Annex 6 Part 1 to Part 3 in respect of flight data recorderequipped helicopters. The amendment effectively made flight data analysis
programmes Recommended Practice for fixed wing aircraft over 20 tonnes from 1
January 2002, and a Standard for fixed wing aircraft over 27 tonnes from 1 January
2005.
25 September 2002
Page vii
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Glossary of Terms
AGL
Above Ground Level
ARA
Airborne Radar Approach
ARINC
Aeronautical Radio Inc.
ASR
Air Safety Report
ATC
Air Traffic Control
BA
British Airways
BALPA
British Airline Pilots Association
BASIS
British Airways Safety Information System
BASIS FDM
BASIS Flight Data Measurements Module
BHAB
British Helicopter Advisory Board
BHL
Bristow Helicopters Limited
CAA
UK Civil Aviation Authority
CAADRP
Civil Aircraft Airworthiness Data Recording Programme
CAP
Civil Aviation Publication
CD-RW
Compact Disk – Read/Write
CQAR
Card Quick Access Recorder
CRM
Cockpit Resource Management
DAPU
Data Acquisition and Processing Unit
EGPWS
Enhanced Ground Proximity Warning System
EHM
Engine Health Monitoring
ES-S
Smiths Aerospace Electronic Systems - Southampton
FAA
Federal Aviation Administration
FAT
File Allocation Table
FDE
BASIS Flight Data Events module
FDM
Flight Data Monitoring
FDR
Flight Data Recorder
FDS
BASIS Flight Data Simulation module
FDT
BASIS Flight Data Trace module
FDV
BASIS Flight Data Viewer module
FOQA
Flight Operations Quality Assurance
FSO
Flight Safety Officer
GAIN
Global Aviation Information Network
25 September 2002
Page viii
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
GPS
Global Positioning System
HLL
Helideck Limitations List, previously known as the IVLL
HOMP
Helicopter Operations Monitoring Programme
HUMS
Health and Usage Monitoring System
IAS
Indicated Airspeed
ICAO
International Civil Aviation Organisation
IFR
Instrument Flight Rules
IHUMS
Integrated HUMS (i.e. HUMS+FDR)
IMC
Instrument Meteorological Conditions
IVLL
Installation and Vessel Limitation List
LAS
Low Airspeed
MDR
Maintenance Data Recorder
MOR
Mandatory Occurrence Report
MTOW
Maximum Take-Off Weight
Ng
Engine Gas Generator Speed
PCMCIA
Personal Computer Memory Card Interface Architecture
RMS
Root Mean Square
SESMA
Special Event Search and Master Analysis
SMS
Safety Management System
SOP
Standard Operating Procedure
UKOOA
UK Offshore Operators Association
VNE
Maximum Speed (Never to be Exceeded)
VNO
Maximum Speed Normal Operation
25 September 2002
Page ix
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Executive Summary
This report presents the results of the Helicopter Operations Monitoring Programme
(HOMP) trial. The objective of this trial was to demonstrate the use of Flight Data
Monitoring (FDM) techniques in helicopter operations and to evaluate the benefits
obtained.
FDM is "a systematic method of accessing, analysing and acting upon information
obtained from digital flight data records of routine flight operations to improve safety."
It is a well-established practice in many fixed wing airlines and has become an
essential part of airline safety management processes with proven safety and other
benefits. As a result, FDM for fixed wing aircraft is to be made an ICAO
Recommended Practice from 2002 and a Standard from 2005.
With support and part funding from Shell Aircraft Limited, the CAA instigated a
research project to trial a helicopter FDM programme, known as the HOMP. The
programme was developed and directed by an integrated project team, with
members from the CAA, Shell Aircraft, and the contractors. Using the Quick Access
Recorders (QARs) and data replay and analysis system provided, the trial successfully
demonstrated the routine downloading and pro-active analysis of flight data from five
FDR equipped North Sea helicopters.
Comprehensive sets of flight data events and measurements were implemented to
monitor the helicopter operations and an effective capability was achieved. The
PCMCIA card based QARs used were very reliable and a total of approximately
11,500 hours of data was gathered, with an impressive data collection rate of 9095%. Significant enhancements were made to the data replay and analysis software
during the trial, which resulted in a very effective analysis tool, well matched to the
requirements of the HOMP Operator.
The programme achieved excellent results. Significant safety issues were identified
and the operator was able to take action to address them. The operator successfully
implemented a closed-loop process for following up significant events, taking
appropriate actions, and then monitoring the effectiveness of these actions. Aircrew
responded positively to the programme and were receptive to any feedback provided.
The large amount of new information produced by the trial enabled operational risks
to be more accurately assessed.
The results obtained clearly demonstrated that the HOMP can bring about
improvements in flying practice, training, operating procedures and coping with the
operational environment. As a result of the success of the trial and the promulgation
of the findings by the project team, UKOOA have committed their members to the
implementation of HOMP on all FDR-equipped UK public transport helicopters
operating over the UK Continental Shelf.
25 September 2002
Page x
CAA PAPER 2002/02
Section 1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Introduction
There is now widespread acceptance in the airline industry that Flight Data Monitoring
(FDM) programmes improve safety, whilst providing a number of other operational
and economic benefits. These programmes were pioneered in the UK by the Civil
Aviation Authority (CAA) and British Airways, and monitor flight operations by
routinely analysing aircraft flight data to detect deviations from normal, expected, or
flight manual practice. They provide continuous operational quality control with timely
feedback on sub-standard practices, and produce valuable information for the
evaluation and improvement of operating procedures and the environment.
The CAA has also, for many years, been working to improve the safety of helicopters
operating over the North Sea. Notable initiatives have included trials of Health and
Usage Monitoring Systems (HUMS), introducing a mandatory requirement to fit Flight
Data Recorders (FDRs), and mandating the fitting and use of HUMS. More recently
the CAA instigated trials of an FDM programme for North Sea helicopters, known as
the Helicopter Operations Monitoring Programme (HOMP), which represented the
first application of FDM to helicopters. As the helicopters were already equipped with
FDR systems, the HOMP represented a near term low risk, and low cost, opportunity
to enhance operational safety by making pro-active use of the flight data which was
already being acquired.
The HOMP trial was jointly funded by the CAA and Shell Aircraft Limited. Smiths
Aerospace Electronic Systems – Southampton (ES-S, formerly Stewart Hughes
Limited) was prime contractor to the CAA for the trial. The HOMP was operated by
Bristow Helicopters Limited (BHL) and involved five Super Puma helicopters based at
Aberdeen and Scatsta (in the Shetland Islands). The helicopters were equipped with
BAE Systems PCMCIA Card Quick Access Recorders (CQARs) to extract and
download the flight data. British Airways (BA) provided the helicopter flight data replay
and analysis software, comprising four BASIS flight data modules. The HOMP trial
consisted of an 8 month development phase followed by a 2 year operational phase.
This report presents the overall results of the trial. Section 2 introduces the concept
of FDM, describes the significant safety and other benefits which have been achieved
on fixed wing aircraft, and defines a generic FDM process which provides the model
for the HOMP. The integration of an FDM programme into an operator’s existing
safety management system is also addressed. Section 3 introduces the HOMP and
describes the trial programme. Section 4 presents a detailed description of the
equipment utilised in the trial and the flight data analysis that was performed. Section
5 gives a detailed description of the HOMP trial operational experience. Sections 6
and 7 present the results obtained from the trial, focussing on the HOMP flight data
event and measurement analysis respectively. Section 8 describes the HOMP
processes and policy statement developed by the operator during the trial. Section 9
summarises the requirements for, and estimates the costs of, a full scale HOMP
implementation. Finally, Section 10 presents the conclusions that have been drawn
from the trial.
25 September 2002
Section 1 Page 1
CAA PAPER 2002/02
Section 2
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
FDM Background Information
2.1
FDM – A powerful safety tool with proven benefits
2.1.1
FDM concept
The world-wide commercial aviation fatal accident rate has not decreased
significantly since 1980-85. The levelling of the accident rate curve suggests that the
safety returns from “traditional” ways of improving safety (e.g. new technologies and
systems, improved training, regulation, inspection and enforcement) are diminishing,
and that it is necessary to find new ways of preventing accidents and incidents.
Reference [1] states:
“Why do aviation professionals who are highly trained, very competent, and
proud of doing what they do well, still make inadvertent and potentially lifethreatening mistakes? Blaming the problems on "human error", even if accurate,
does little to prevent recurrences of the problem. The flattening of the accident
rate curve tells us that the historic focus on the individual, while necessary, is
no longer sufficient. Instead of focussing solely upon the operator, e.g. with
more regulation, punishment, or training, it is time to start sharing information
that can help improve the system in which the operator is operating.”
One of the new (to the world-wide aviation community as a whole) ways the aviation
industry has been adopting is the voluntary, proactive collection and use of
information about aviation safety problems before they result in incidents or
accidents. The collection of information can take two primary forms:
a) Voluntary, non-punitive incident and hazard reporting programmes (e.g. the raising
of Air Safety Reports by aircrew.)
b) Flight Data Monitoring (FDM) programmes. Reference [2] defines FDM as "A
systematic method of accessing, analysing and acting upon information obtained
from digital flight data records of routine flight operations to improve safety."
NOTE: Whilst this report is focussed on (2), it must be appreciated that the above
two forms of information collection are entirely complementary and both are
required for effective safety management.
The power of this approach is explained below through the concepts of the “Heinrich
pyramid” and the “light box” (Reference [1]):
The Heinrich pyramid
The Heinrich pyramid (Figure 2.1) postulates that for every major accident, there will
be 3-5 less significant accidents, 7-10 incidents and at least several hundred
unreported occurrences.
25 September 2002
Section 2 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
ACCIDENTS
INCIDENTS
UNREPORTED
OCCURRENCES
Figure 2.1 The Heinrich Pyramid
Usually these occurrences are not reported because, by themselves, they are
innocuous, i.e. nobody was hurt and nothing was damaged. However, today's
unreported occurrences are the "building blocks" of tomorrow's accidents and
incidents; and when they coincide with the other building blocks from the "unreported
occurrences" part of the pyramid, they may some day generate an incident or
accident.
Obtaining information on what were previously unreported occurrences enables a
pro-active approach to be taken to address operational risks before they result in
incidents or accidents. Only if the risks are known can steps be taken to reduce them.
No information means that no action can be taken.
The light box
Commercial aviation accidents are rare and random events and are analogous to light
coming out of a box without any discernible pattern. The question is why does the
light emerge in such a random fashion? Upon opening the box, it is discovered that it
contains a series of spinning disks with holes, rotating about a common axis. The light
emerges from the box (i.e. an accident occurs) if, and only if, the holes in all the disks
happen to line up in front of the light (Figure 2.2).
Figure 2.2 The Light Box
Each spinning disk could be compared to a link in the chain of events leading to an
accident. A study by Boeing (referred to in Reference [1]), has revealed accident
chains with as many as twenty links, each one representing an event that, with a
different outcome, would have broken the chain and avoided the accident. Every one
of these links, separately, is usually innocuous and resides in the "unreported
25 September 2002
Section 2 Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
occurrences" part of the Heinrich pyramid, but when they happen to combine in just
the wrong way (i.e. when the holes in the spinning wheels happen to line up), the
result is an accident.
Viewed in this way, the objective of proactively collecting and acting on information
to prevent accidents is to obtain information about each spinning wheel (each link in
the chain) separately, in order to try to reduce the number of holes in each wheel (i.e.
operational risks). This effectively dissects a potential incident or accident into its
component parts, facilitating a separate remedy for each component part of the
problem.
2.1.1.1 Non-aviation parallels
The same concept of using information proactively to prevent accidents is being
developed in areas other than aviation, for example health care and information
infrastructure security (Reference [1]).
In health care the Committee on Quality of Health Care in America, created by the US
Institute of Medicine, recently issued a report entitled "To Err is Human: Building a
Safer Health System." It reflects concern that as many as 90,000 people a year die
from medical mistakes, and proposes a system to systematically collect and analyse
information about near-miss mistakes in order to learn more about how to prevent
mistakes that could kill or injure. The premise of the system is described as follows:
"Preventing errors means designing the health care system at all levels to make
it safer. Building safety into processes of care is a much more effective way to
reduce errors than blaming individuals…. The focus must shift from blaming
individuals for past errors to a focus on preventing future errors by designing
safety into the system. When an error occurs, blaming an individual does little
to make the system safer and prevent someone else from committing the
same error."
Similarly, in Presidential Decision Directive 63 issued in 1998, the US President
expressed concern about the vulnerability of the nation's information infrastructures
to computer "hackers" and terrorists. Accordingly, the Critical Infrastructure
Assurance Office (CIAO) was created to develop means of improving the security of
such infrastructures. In order to learn more about the weaknesses of the various
information infrastructures and how to remedy those weaknesses, the CIAO plans to
develop a system to collect information systematically about near-breaches of
information security - exactly the same process that the aviation and medical
communities are developing.
2.1.1.2 FDM programmes
The objective of FDM programmes is to enable proactive safety intervention based
on analysis of exceedances and trends in flight data obtained on a routine basis from
line operations. FDM programmes are owned and operated by the airlines. Such
programmes are powerful pro-active tools for enhancing flight operational safety
standards. They improve safety by continuously monitoring operations, detecting
adverse trends in operational behaviour, and detecting weaknesses in crews, the
aircraft, at certain airports or in Air Traffic Control (ATC).
An FDM programme can involve up to four types of data, which are defined in
Reference [2] as:
a) Event data. This is the traditional approach to FDM that looks for exceedances of
trigger levels which indicate deviations from flight manual limits, standard
operating procedures or good airmanship.
25 September 2002
Section 2 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
b) Routine measurements. Increasingly, data is retained from all flights and not just
those producing events. The reason for this is to monitor for more subtle trends
and tendencies before the trigger levels are reached. A selection of measures are
retained that are sufficient to characterise each flight and allow comparative
analysis of a wide range of aspects of operational variability.
c) Incident investigation. FDR data should be used as part of the follow-up of
Mandatory Occurrence Reports (MORs) and other reports. FDR data obtained for
use in this way falls under the mandatory requirements of JAR OPS.
NOTE: MORs are reports that are required to be issued to the CAA to ensure that
it is advised of hazardous or potential hazardous occurrences, and that
relevant information is disseminated to other organisations. MORs differ
from Air Safety Reports as the latter are part of an organisation’s internal
safety reporting processes.
d) Engineering data. Both measurement and event data can be used to assist the
engineering function. Traditionally, engine monitoring programs have looked for
measures of engine performance to deduce efficiency and predict the approach of
failures. These programs are normally supplied by the engine manufacturer and
feed their own databases. By imaginative use of the many engineering
measurements available, a broader picture of the aircraft's systems can similarly
be achieved.
2.1.2
FDM benefits on fixed wing aircraft
Experience has shown that proactive use of information from an FDM programme not
only improves safety, but can also result in savings in operations and maintenance.
Reference [3] groups the benefits from FDM into four areas; the identification of:
a) Non-compliance and divergence from Standard Operating Procedures (SOPs). This
is probably the most critical and useful part of FDM and is a continuous audit of
pilot performance.
b) Inadequate SOPs and inadequate published procedures. If pilots do not
consistently comply with SOPs it is perhaps sensible to consider first whether the
SOPs could be improved.
c) Ineffective training and briefing, and inadequate handling or command skills. It is
relatively straightforward to use FDM to assess the effectiveness of training,
communication with crew and briefing systems.
d) Fuel inefficiencies and environmental infringements. Statistical analysis of route
fuel and taxi fuel assists in refining flight planning. FDM is also used to identify noncompliance with noise procedures.
FDM data can also used for two other purposes (Reference [3]):
a) Engine health monitoring (EHM): The objective of EHM is to eliminate
unscheduled engine removal through unexpected deterioration or failure, and to
ensure optimum performance (e.g. through Variable Inlet Guide Vane scheduling).
As well as precipitating timely removal it can also provide objective data following
an incident that may enable an engine to be left on-wing until a more convenient
time.
b) Monitoring of aircraft performance and system serviceability: This covers a variety
of areas, e.g.
•
25 September 2002
Validating aircraft performance against the manufacturer's specification.
Section 2 Page 4
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
• Comparing fuel burn across a fleet to identify aerodynamic inefficiencies that
may be caused by inexact door alignment or control rigging.
• Compiling statistical data from analysis of all autolands to ensure no
degradation after certification.
• Use for diagnostics and to resolve design and maintenance problems, for
example, wheel and brake reports.
• Collating data to support cases for change (e.g. runway resurfacing) and
development (e.g. EGPWS).
• Regular checking of FDR parameters to maintain the serviceability of the
FDR system for accident/incident investigation.
The primary benefits from FDM programmes are undoubtedly safety related. Scandia
Insurance has overlaid FAA data with that on non-USA airlines (Figure 2.3). This
shows that airlines which have been using FDM data for 7-14 years now have a lower
accident rate than US airlines, and those airlines which have used FDM for more than
14 years have an accident rate under half that experienced by the US carriers.
Hull Losses as a Percent of Total Turbine Fleet
Flight Data Recorder Users vs. U.S. vs. World
0.3
0.2
Worldwide
FDR Use <7Years
0.1
Total U.S.
FDR Use 7-14 Years
FDR Use >14 Years
0
76-82
83-89
90-96
Years
Figure 2.3 Safety Benefits of FDM
2.1.2.1 Cost benefits
Reference [4] identifies cost savings through the prevention of a catastrophic
accident. Accident costs include the following:
• Compensation costs for loss of life
• Loss of cargo, baggage, mail
• Third party damage costs
• Hull replacement cost
• Cost of bringing a replacement aircraft up to the fleet standard
• Costs associated with resulting actions such as grounding of a fleet
• Other accident related costs, e.g. setting up an emergency centre
25 September 2002
Section 2 Page 5
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
• Loss of revenue due to loss of an aircraft
• Loss of revenue likely through lowering of public confidence
• Reduction in company value due to stock market loss of confidence
Offsetting the above is the insurance payment for the loss, however this generally
only covers the first three items and some element of the fourth. There would be
additional industry costs that would not fall upon the individual airline resulting from
any disruption caused by an accident, or a general loss of confidence in aviation and
increased overall risk levels.
Perhaps more relevant to preventative programmes such as FDM is the cost of
incidents such as tail scrapes, heavy landings, turbulence upsets etc. The costs
associated with these more common events are easier to estimate. Typical common
incident cost factors may be:
• Operational: flight delays, flight cancellations, runway obstruction, alternate
passenger transportation, passenger accommodation, passenger complaints,
catering, loss of revenue, ferry flight, crew change, training/instruction, loss of
reputation.
• Technical: aircraft recovery, aircraft repair, test flight, incident investigation,
technical documentation, spare parts, technical inventory, aircraft on ground, lease
of technical facilities, repair team accommodation, training/instruction, recertification.
Other potential benefits and cost savings include (Reference [4]):
• Insurance savings - based on experience of long term FDM airlines
• Engine savings - postponed/reduced removals, records of use of derate
• Fuel savings - trim analysis, airframe deficiencies
• Fuel tankering - more accurate fuel burn calculations
• Brake savings - better crew awareness and highlighting heavy use
• Flap maintenance savings - fewer overspeeds and use as a "drag flap"
• Inspections savings - reduced number required due to the availability of
measurements for heavy landings, engine over temp', flap placard etc.
• Increased aircraft availability - better/faster fault diagnosis
• Increased simulator effectiveness - better targeted
• ETOPS monitoring - automatic rather than manual
• Warranty support - definitive usage evidence
• Autoland support - record keeping and system health/accuracy
2.1.3
Support for FDM
A number of statements have been made by key personnel in influential organisations
expressing strong support for FDM:
a) “The CAA strongly encourages the adoption of such (FDM) programmes as a key
part of operator Safety Management Systems (SMS). It is the CAA's intention to
work with industry to further improve aviation safety by using FDM methods and
information to enhance safety through knowledge.” David Wright, Senior FDR
Analyst, CAA Safety Regulation Group. Royal Aeronautical Society Conference
paper, March 2000.
25 September 2002
Section 2 Page 6
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
b) "Such systems allow an airline to identify and address specific operational risks and
are strongly encouraged as part of a Safety Management System". Peter Hunt,
Head of the Operating Standards Division of the UK CAA Safety Regulation Group
- Industry Safety Conference, March 1999.
c) "Because of its capacity to provide early objective identification of safety
shortcomings, the routine analysis of digital flight data offers significant additional
potential for accident avoidance". "It is potentially the best safety tool of the 21st
Century." Hon Jane F Garvey, FAA Administrator - FOQA Policy Statement (491013), December 1998.
d) "It is the most important way to dramatically improve flight safety." Captain Lowe,
President Royal Aeronautical Society - The Aerospace Professional, February 1999.
e) "Knowledge of risk is the key to flight safety. Until recently that knowledge had
been almost entirely confined to that gained retrospectively from the study of
accidents and serious incidents. A far better system, involving a diagnostic,
preventive approach, has been available since the mid-1970s." Editorial, Flight
International, December 1998.
2.1.3.1 ICAO State letter AN6/1.2-00/4
ICAO State letter AN6/1.2-00/4 presented recommendations from the Accident
Investigation and Prevention (AIG) divisional meeting in 1999 for amendment of
Annex 6 of the ICAO recommendations for standards and recommended practices.
The following amendments were fully supported by the UK:
3.6.2 "From 1 January 2002, an operator of an aeroplane of a maximum certified
take-off weight in excess of 20,000 kg should establish and maintain a flight
data analysis programme as part of its accident prevention and flight safety
programme."
3.6.3 "From 1 January 2005, an operator of an aeroplane of a maximum certified
take-off weight in excess of 27,000 kg shall establish and maintain a flight data
analysis programme as part of its accident prevention and flight safety
programme."
3.6.4 "A flight data analysis programme shall be non-punitive and contain
adequate safeguards to protect the source(s) of the data."
The above amendments effectively mandate FDM on aircraft above 27 tonnes
MTOW from 2005. In their response to the ICAO State letter, the UK made the
following comment on the future development of FDM programmes:
“The UK believes that a flight data analysis programme should be implemented
within the accident prevention and flight safety programme of all operators of
helicopters having type 4 or 4A recorders. The UK believe such programmes are
demonstrably practical, at least on helicopters already having suitable crash
protected flight recorders and associated systems. Initial results from a UK trial
indicate this is as practicable on helicopters as on fixed wing and shows
significant safety benefits.”
25 September 2002
Section 2 Page 7
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
2.2
The FDM process
2.2.1
The “closed loop” FDM process
The objective of FDM systems is to enable an airline to identify, quantify, assess and
address operational risks. The FDM “closed loop” process (References [2] and [4]) is
described below and illustrated in Figure 2.4:
1. Continuously
Identify and quantify
risks
Yes
4. Was action
Effective?
No
Yes
2. Are risks
Acceptable?
No
3. Take remedial
action
Figure 2.4 The “Closed Loop” FDM Process
1 Continuously identify and quantify operational risks. Identify areas of risk and
measure current safety margins - this will establish a baseline operational metric
against which to detect and measure any change. Then identify and quantify
changing operational risks. In addition to highlighting changes from the baseline
the system should enable the user to determine when non-standard, unusual or
basically unsafe circumstances occur in operations.
2 Are risks acceptable? Formally assess the risks to determine which are not
acceptable. Information on the frequency of occurrence, along with estimations
of the level of risk present, is then used to determine whether the level of risk
associated with an individual occurrence or occurrence trend is acceptable.
Primarily, the system should be used to deduce whether there is a trend towards
unacceptable risk prior to it reaching risk levels which would indicate that the safety
management process has failed.
3 Take remedial action. Where risks are not acceptable, instigate remedial activity.
Once an unacceptable risk, either actually present or predicted by trending, has
been identified then the appropriate risk mitigation techniques must be used to
define and instigate remedial actions.
4 Was action effective? Measure the effectiveness of action and continue to
monitor risks. Once remedial action has been taken it is critical that its
effectiveness is confirmed, i.e. in reducing the original identified risk without
increasing risk elsewhere. When no adverse safety impact is identified, reestablish the baseline operational metric to measure future changes.
25 September 2002
Section 2 Page 8
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The FDM process must be recognised as one which is founded on a bond of trust
between the operator, its flight crews and the regulatory authority. The process must
actively demonstrate a non-punitive, non-disciplinary policy. The focus has to be on
providing positive feedback to improve all elements of the system. This typically
creates a need for:
• Confidentiality, with the identity of individual flight crew being protected by tightly
controlled access to data, data de-identification procedures and restricted contact
with flight crew (often through the Pilot Association).
• Written agreements between flight crew and management on issues such as the
aims and objectives of the FDM programme, restrictions on access to data and
contact with crews, and how information generated by the process can be used.
Detailed information on all the components of the FDM process can be found in
References [4] and [5].
2.2.2
A practical implementation of the FDM process
Figure 2.5 shows the components of a typical operator’s FDM process. This is based
on the process currently followed by BA.
AIRCRAFT
2A. EMERGENCY
ACTION
Structures etc.
QAR data
1. FDR REPLAY
Run media through
analysis programs
Events
2. INITIAL VERIFICATION
Reject false events and bad data
3. PROGRAM IMPROVEMENT
Continuous review and
improvement of program
9. MONITOR
EFFECTIVENESS
OF ACTIONS
10. NON-FDM USERS
Engineering, Planning,
ATC etc
4. FLEET ASSESSMENT
Fleet Pilot’s assessment of hazard
(plus more verification)
6. CONFIDENTIAL
FLT CREW CONTACT
5. ASR CORRELATION
Combine information for best
analysis of significant incidents
7. FDM WORKING GROUP
Review and discuss action to be
taken
8. ACTION
Training, Operations,
Avionics, Propulsion, etc.
Figure 2.5 Typical FDM event process
25 September 2002
Section 2 Page 9
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
1 FDR replay Aircraft QAR data is downloaded and replayed through the FDM data
replay and analysis program.
2 Initial Verification This confirms that any events generated are valid and not
caused by ‘bad data’ due to sensor problems etc. Initial examination of the results
should be carried out as soon as possible after data replay so that, in exceptional
circumstances, step 2A may be triggered.
2AEmergency Action Where the program identifies the need for immediate safety
action, for example a very heavy landing with potential structural damage that has
not been highlighted by other means, then relevant checks are instigated.
3 Program Improvement The process should include a continuous review of the
information being generated to identify required improvements to the data replay
and analysis program, for example the refinement of event definitions to eliminate
‘false events’.
4 Fleet Assessment The events should be grouped by aircraft fleet and examined
in detail by a selected, experienced pilot on each type. These use their knowledge
of each aircraft and the associated operating environment to assess the events.
Safety issues will be identified and initial actions decided upon.
5 Air Safety Report Correlation Where there is a more significant event, there is
likely to be an ASR. Normally an interpreted summary of the FDR data will be
added to the ASR investigation file and the follow-up controlled by the normal flight
safety process within the airline's safety management system. If an event is
deemed to be significant and no ASR is found to exist then, as part of item 6, flight
crew can be prompted to raise one. Improvements in the consistency of raising
and processing of ASRs can be expected as a by-product of FDM.
6 Confidential Flight Crew Contact A Pilot Association representative may be
requested to speak informally with the flight crew concerned to find out more
about the circumstances of an event. If deficiencies in pilot handling technique are
evident then the informal approach, entirely remote from management
involvement, usually results in the pilot self-correcting any deficiencies. If any retraining is found to be necessary, this should be carried out discreetly.
7 FDM Working Group This would typically meet on a monthly basis to assess both
significant individual events and any undesirable trends in event statistics. Events
should be assessed in the context of previous experience to determine whether
they are indicative of a trend or are unique. The assessment should identify the
degree of direct or indirect hazard associated with individual events or event
trends. This will enable resources to be targeted at the most beneficial reduction
in hazard, which may be to prevent a large number of relatively low risk events or
to eliminate a low number of high risk events. The output from this step in the
process should be recommendations on any appropriate actions to minimise
hazards and prevent the re-occurrence of significant events.
8 Action Taking action to address identified hazards is the ultimate goal of the whole
process. In addition to specific changes in SOPs and training, typical actions should
include raising general awareness of identified hazards and providing reminders of
SOPs through the issuing of safety bulletins or providing feedback through crew
newsletters. All actions arising from the FDM process should be recorded to
provide an audit trail.
9 Monitor Effectiveness of Actions After taking action, the final stage in the closed
loop FDM process is to monitor the effect of actions to check that these have
reduced identified risks and to ensure no risks are transferred elsewhere.
25 September 2002
Section 2 Page 10
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
10 Non-FDM Users Information processed by the FDM and associated software may
also be used by other areas of the airline, e.g. engine health monitoring, planning
or ATC services.
2.3
Integrating FDM into the existing safety management system
FDM should ideally become an integral part of an operator’s existing safety
management system. Reference [4] states:
“An FDM programme held remote from all other safety systems within an
airline will have reduced benefits compared with one that is linked with other
safety monitoring systems. This other information gives context to the FDR
data which will in turn provide quantitative information to support investigations
that otherwise would be based on less reliable subjective reports. FDM, Air
Safety Reporting, Technical and Engineering Reporting, Ground Incidents,
Design and finally Human Factor Reporting systems must be linked together to
produce a best estimate of operational risks. Where necessary these links may
have to be configured to restrict data identification while passing useful
information.”
FDM is a closed-loop process which allows an operator to identify, quantify, assess
and address operational risks, then monitor changes brought about by remedial
action. An operator’s existing safety management system can provide the
organisational structure and mechanism for this closed-loop process, and also
provides access to complimentary information on operational risks.
Figure 2.6, extracted from Reference [6], shows the three business pre-requisites for
systematic safety management.
Comprehensive
Corporate Approach
to Safety
Effective
Organisation for
Delivering Safety
Robust Systems for
Assuring Safety
Figure 2.6 Pre-requisites for Successful Safety Management
25 September 2002
Section 2 Page 11
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The business elements shown in the figure provide the following:
Corporate Approach
• Establishes and leads an effective corporate safety culture
• Visible senior management leadership and commitment
• Sound safety policy
• High, well understood, safety standards
• Realistic safety targets and objectives
• Effective motivation and communication
Effective Organisation
• Clearly defined responsibilities/accountabilities for safety
• Effective safety training
• High levels of competency in safety
• Comprehensive planning, procedures and documentation
• Competent safety advisors
Robust Systems
• Systematic hazards and effects management process
• Techniques for measuring safety
• Thorough incident investigation and follow-up
• Audit of safety standards and practices
• Application of Quality Assurance principles throughout
FDM represents a powerful additional “robust system” for measuring safety, which
should benefit from the “effective organisation” already provided for safety
management. The following section presents information from Reference [7] on the
benefits of integrating FDM into an operator’s existing safety management system.
2.3.1
The benefits FDM can provide to existing safety systems
Because of its repeatable and independent nature, FDM event detection and
measurement analysis lends itself well to the active monitoring and audit functions
needed to give safety assurance, and is more effective than traditional means of audit
or inspection. Periodic audits such as check flights do not provide visibility of the risks
encountered during routine operations. In monitoring all flights, FDM can help to fill
in this missing information and assist in the definition of what is normal practice. This
gives assurance that the safety process is managing actual rather than perceived
safety issues.
Current occurrence reporting systems have a very restricted view of the total
operation, whereas FDM gives a depth of information beyond accidents and incidents
that indicates the underlying risk patterns. FDM can be used to extend the knowledge
of issues raised by reporting systems and also extend this to areas where little
information exists.
FDM provides a continuous monitoring function which allows the identification of risk
trends. This enables measures to be put in place to ensure that the level of safety is
at least being maintained or preferably improved. In addition, by providing information
on more frequently occurring lower risk events as well as high risk events, FDM
25 September 2002
Section 2 Page 12
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
allows the identification of potential as well as actual hazards. The frequencies of
lower risk events can be fed into a risk model to investigate the overall probability of
a combination of multiple events leading to a significant hazard.
FDM information can greatly enhance the investigation of reports such as ASRs and
MORs. The quantitative data allows a fuller understanding of the circumstances
surrounding an incident and can provide information on factors such as pilot
technique, handling difficulties, turbulence, structural limit exceedances etc. Because
of its independent nature, FDM can also help to encourage good safety reporting. For
example, FDM may occasionally detect a hazard for which no ASR was submitted. In
this case the persons involved can be encouraged, through confidential contact by a
crew representative or other trusted person, to submit a report. This method of
contact has proved to be very effective in soliciting reports and a good means of
imparting constructive safety advice to those involved.
The act of setting up an FDM programme requires the operator to define the normal
operation and the bounds of acceptability. This process provides a useful insight into
standards and can in itself highlight potential conflicts or unclear areas within current
operating procedures. Similarly FDM information can be utilised in the initial
assessment of risk levels when setting up a new safety management system. These
can be tested against the specified standards to determine if safety levels are
acceptable.
2.3.2
The benefits existing safety systems can provide to FDM
Owing to the way in which FDM has evolved, supporting processes have, in some
cases, tended to be rather ad-hoc, locally implemented, and controlled by informal
procedures. However, the “closed loop” safety assurance processes required for an
FDM programme are very similar to those implemented as part of existing safety
systems. Knowledge of an actual or potential hazard must lead to a safety
assessment and, where necessary, remedial action. Further, where action is taken
some record of this must be kept to provide an audit trail. The existing safety systems
can provide an organisational structure and systematic methodology for assessing
and acting upon identified hazards to manage safety. Therefore, to obtain the
maximum benefits from FDM, the programme needs to be integrated with existing
safety systems, with common safety assessment and action processes and
procedures.
FDM can only identify certain operational risks, and a complementary non-punitive
reporting system (e.g. ASRs) is needed to provide a comprehensive picture of all the
operational risks. Integrating the quantitative information from FDM with the
contextual and qualitative information from ASRs allows a much better understanding
of safety issues raised from both systems. The reports generated automatically from
FDM programmes must be treated confidentially, however where an ASR has already
been submitted, then relevant FDM events can be used to add to the understanding
of the circumstances of the occurrence.
The existing safety systems can provide a standard route for bringing hazards
identified from FDM information to the attention of other operators, Air Traffic
Services, aircraft or equipment manufacturers, or the Regulator. FDM information on
significant risk bearing events can follow the same route as existing safety reports. In
the UK the accepted medium for broadcast is the Mandatory Occurrence Reporting
Scheme. In addition, when it is an integral part of an organisation’s safety systems,
FDM information can be used to provide regulatory assurance and the regulatory
bodies can give credit for the proactive approach to safety being taken by the
operator.
25 September 2002
Section 2 Page 13
CAA PAPER 2002/02
2.4
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Some lessons from fixed wing FDM experience
There is a recognised need for guidance material to help operators to maximise the
benefits of FDM and avoid some of the pitfalls which can result in difficulties or a loss
of benefit. This section briefly summaries some lessons learned from fixed wing FDM
experience.
2.4.1
FDM implementation
An FDM programme will be most successful if senior management have created a
good safety culture within an organisation.
Planning an FDM implementation should start at the top with an overview, but must
also address detailed issues. Overlooking details such as data extraction and replay
system requirements will result in problems.
It is important that the objectives of, and procedures for, an FDM programme are
defined in a protocol which is accepted by aircrew before FDM is implemented.
Agreements must be reached with aircrew, and there must be a good consensus
between all parties if a programme is to succeed.
An FDM programme must be seen to be non-punitive, and operated in a manner
which ensures the trust and co-operation of aircrew. Trust will be lost and the
programme could fail if FDM data is misused.
Different operators have taken different approaches to the positioning of FDM within
their organisation, and to the interface between the programme and the Flight Safety
Officer (FSO). Although there are advantages and disadvantages of different
approaches, there is no single “best solution” and the approach taken must be
tailored to the particular operator’s size and organisational structure.
FDM programmes must be properly resourced. Some operators have failed to
successfully implement FDM because they did not provide adequate resources to
operate and manage the programme.
There is a need to appreciate the limitations of FDM information. It can only identify
certain risk areas, and must be combined with information from other reporting
systems to provide an adequate picture of overall risks.
Some FDM implementations have started as “hobby systems”, have not been well
integrated into the operator’s organisation, and are highly dependent on the skills and
motivation of a specific individual. It is important that a systematic approach to FDM
implementation is taken to prevent this from occurring.
2.4.2
FDM process
It is difficult or impossible to maintain aircrew anonymity in small airlines. Where this
is the case it is vital that the person following up events (e.g. the FSO) maintains
independence, has the right personality for the task, and is trusted and respected by
aircrew.
It is very important to obtain crew feedback when investigating significant events,
otherwise the investigator can make wrong assumptions and come to an incorrect
conclusion.
Different mechanisms have been used to contact crew when feedback is required for
the investigation of significant events. In some cases this is done via a pilot
association representative, in others information is sent in a sealed envelope. The
mechanism used should be tailored to the requirements of the particular operator. If
feedback is required, both crew should be contacted, not just the pilot or co-pilot.
25 September 2002
Section 2 Page 14
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
It is important to communicate the outcomes of FDM programmes to all parties, lack
of communication will erode support for the programme, and diminish the benefits.
2.4.3
FDM equipment
Careful selection of data recorder, recording medium and replay facility is very
important. The reliability of recorders and recording media will affect the data capture
rate and hence programme effectiveness. With current technology, use of a Quick
Access Recorder is the preferred method of obtaining data from the aircraft.
Downloading data from the crash protected memory of digital FDRs is more difficult
and time consuming, and use of tape-based FDRs is too unreliable. The replay facility
needs to be designed to cope with the expected throughput in order to avoid data
processing bottlenecks.
Some operators have experienced an unacceptable rate of loss or damage of data
recording media. As a result, one operator has adopted a systematic approach to
media control, involving the transport of media in sealed boxes marked with a bar
code for tracking purposes.
To ensure FDM systems are accepted, every effort must be taken to minimise the
sources of data errors and to eliminate false event detections.
There would be some benefit from standardising event parameters and detection
criteria to aid the sharing of lessons learned between operators.
Some operators have underestimated the technical expertise required to manage and
support an FDM system.
FDM systems will continue to evolve and software upgrades can cause disruption if
not managed properly.
It is important to provide a secure environment for the FDM data analysis system,
with appropriate access restrictions.
25 September 2002
Section 2 Page 15
CAA PAPER 2002/02
Section 3
3.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The HOMP Trial
Background to the HOMP trial
The history of FDM can be traced back to the beginning of one of the CAA’s longest
running safety research projects: the Civil Aircraft Airworthiness Data Recording
Programme (CAADRP). This programme is managed by the Safety Analysis Unit
within the CAA’s Safety Regulation Group and has its origins in the early 1960s when
ultra-violet paper flight data recorders were used to gather data from the jet transports
then entering service. This led to the development of the Special Event Search and
Master Analysis (SESMA) program – the first ever FDM system. For the last 30 years
the CAA has been working in close co-operation with UK operators such as British
Airways on the development and implementation of FDM.
For many years the CAA has also been working to improve the safety of the public
transport helicopters operating over the North Sea in support of the oil and gas
industry. It initiated trials of the first helicopter Health and Usage Monitoring Systems
(HUMS) in the late 1980s, and introduced a mandatory requirement to fit Flight Data
Recorders (FDRs) in the early 1990s. The CAA actively encouraged the fitting of
HUMS to the North Sea helicopter fleet in the form of integrated HUM/FDR systems
and, in 1999, mandated these systems for UK transport helicopters carrying more
than 9 passengers.
With the support of Shell Aircraft Limited, the CAA initiated a project which brought
together the above two initiatives to extend the scope of FDM beyond the current
fixed-wing implementation and carry out a trial implementation of FDM on helicopter
operations. In late 1998, following the successful completion of an initial feasibility
study (see Section 3.2), the CAA instigated trials of an FDM programme for North Sea
helicopters, known as the Helicopter Operations Monitoring Programme (HOMP).
The HOMP trial represented the first application of FDM to helicopters. The following
factors provide a justification for this initiative:
• FDM is now a well established practice amongst fixed wing operators, with
demonstrated safety and other benefits (see Section 2). Airlines such as BA have
clearly proven the benefits of FDM and are convinced that these programmes
make a difference to their safety performance. BA’s FDM programme, known as
SESMA, is an essential part of the airline’s safety management programme and is
welcomed by aircrew, BALPA and management alike.
• The introduction of helicopter HUM systems has reduced the rate of occurrence
of helicopter accidents due to technical causes by providing better information on
the integrity of the helicopter powertrain. However, accidents are also caused by
operational factors, and there is clear scope for further improving helicopter safety
by providing better information on operational risks. This is particularly true for
operations to/from offshore installations in the North Sea, which involve some
unique difficulties.
• The basic requirement for a helicopter FDM programme – the availability of a flight
data acquisition and recording system – has already been met. Therefore the
implementation of a helicopter FDM programme is potentially a low risk and low
cost opportunity to further improve helicopter safety.
25 September 2002
Section 3 Page 1
CAA PAPER 2002/02
3.2
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP feasibility study
The HOMP trial was preceded by a two phase feasibility study carried out for the CAA
by Stewart Hughes Limited (now ES-S), working in co-operation with BHL.
The first phase was an initial feasibility study (Reference [8]). This involved analysing
a historical database of FDR data recorded over a period of one year from one BHL
Super Puma helicopter. A prototype set of helicopter operational events was
generated and the data was analysed using the Polish company ATM Awionika’s
Flight Data Service (FDS) system, loaned to SHL by the CAA. The study was able to
demonstrate some of the potential benefits which could be achieved from a HOMP.
The second phase of the work was a HOMP implementation study (Reference [9]).
This involved consultations with all the UK-based North Sea helicopter operators to
obtain their views on, and concerns about, a HOMP. In addition, the lessons learned
from BA’s FDM experience were analysed. A review of the available tools and
equipment for a HOMP was carried out and recommendations were produced for a
programme implementation.
The two phase study provided a clear justification for progressing the implementation
of a HOMP, but identified a number of operator concerns and issues which ought to
be addressed prior to any full scale implementation. There was a general perception
that it would be more difficult to effectively monitor the operation of such a flexible
air vehicle as a helicopter (in contrast to fixed wing aircraft which have clearly defined
flight profiles), and that more effort may be required to interpret monitoring results.
In addition, it was not known whether helicopter operations could be monitored in a
way which would provide meaningful safety benefits. There was also widespread
concern over the possible workload involved in managing a HOMP, including the
handling of data from, and providing feedback to, remote operating bases. Other
issues included the need to obtain the support of both the operator’s management
and flight crew for a HOMP programme, and any possible implications for commercial
relationships between the operators and their customers, the oil companies. There
are differences between the management, aircrew and customer relationships in a
typical helicopter operator and those in a large scheduled airline such as BA. It was
not known what potential impact these differences might have.
It was concluded that these concerns and issues could best be addressed by
performing a HOMP trial on a limited number of aircraft. The objectives of this trial
would be to:
a) establish how best to monitor helicopter flight operations.
b) evaluate the safety benefits of this monitoring.
c) evaluate the tools and equipment required for a HOMP and eliminate any technical
risks associated with these.
d) establish and evaluate a programme management strategy.
e) determine the workload a HOMP would impose on a typical helicopter operator.
f) establish agreements between aircrew and management to ensure that the
identity of aircrew is protected, and the focus is on positive feedback.
g) further expose industry to the concept of a HOMP, enabling a more informed
consideration of its full scale implementation.
25 September 2002
Section 3 Page 2
CAA PAPER 2002/02
3.3
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Review of helicopter operational accidents and occurrences
A review of helicopter operational accidents and occurrences was carried out based
on information contained in the CAA Safety Data Department's UK Occurrence
Reporting System (Reference [10]). The review provided an indication of the safety
benefit which might be obtained from a HOMP and identified relevant flight data
'events' which could provide information for the prevention of a re-occurrence of
previous incidents and accidents.
A statistical analysis of the operational accidents and occurrences showed that if the
accidents and occurrences were separated, very different numerical distributions
were obtained when these were categorised according to cause. Whilst the greatest
number of occurrences were associated with the environment in which the aircraft
operates, the analysis indicated that accidents were largely associated with aircraft
handling. This was, in fact, an oversimplification of the situation. Many accidents had
more than one causal factor and there were environmental factors present in a
number of the accidents which were included in an aircraft handling classification.
A HOMP should be able to have a direct impact on the aircraft handling factors in
accidents, and therefore should give a worthwhile safety benefit. In addition, whilst it
may not be able to have a direct impact on the operating environment, a HOMP
should provide better information on it, which would enable the setting of better
operational limitations. A more detailed analysis of individual operational accident and
occurrence records indicated that a HOMP has relevance to a significant percentage
of previous UK accidents and fatal accidents.
The analysis provided an input to the HOMP event specification process to help
ensure that events were targeted at relevant safety issues (the events are listed in
Section 4.4). A number of accidents and occurrences were linked to offshore helideck
environmental problems such as severe structure induced turbulence, rolling and
pitching helidecks, the close proximity of obstacles, and hot gas exhausts from
turbines and flare stacks. Others were linked to problems associated with aircraft
handling and pilot disorientation such as a misjudged landing, disorientation on takeoff, controlled flight into terrain and water, entry into a 'vortex ring' state, and roll over
during taxiing. Further accidents and occurrences were associated with aircraft
management problems such as a lack of fuel and landing with the wheels up.
3.4
HOMP trial
The HOMP trial was jointly funded by the CAA and Shell Aircraft Limited, and included
the following participants:
• Smiths Aerospace Electronic Systems – Southampton, the prime contractor to the
CAA for the trial.
• Bristow Helicopters Limited, providing the helicopters and operating the trial
programme.
• British Airways, providing the HOMP data replay and analysis software and
assisting the project with their long standing FDM experience.
• BAE Systems, providing the PCMCIA Card Quick Access Recorders (CQARs) for
the trial aircraft.
The trial HOMP was developed and directed by an integrated project team,
comprising representatives from the CAA, Shell Aircraft, ES-S, BHL and BA. The
25 September 2002
Section 3 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
project team proved to be very effective in ensuring that the maximum information
and benefits were obtained from the programme.
The trial was performed using five BHL Tiger (Super Puma) helicopters. Although
helicopters moved between bases, the intention was to maintain two HOMP
helicopters at Scatsta on the Shetland Islands and three at Aberdeen. This
arrangement enabled an assessment of the logistics and management issues
associated with the application of a HOMP to helicopters located at a remote base as
well as at main base. The HOMP on-aircraft system is shown in Figure 3.1.
CQAR
SHL 008
IHUMS DAPU (existing)
CVFDR (existing)
PCMCIA card
Removed by maintainer
at end of day’s flying
Download/Replay
PC
Figure 3.1 On-Aircraft System
The CQAR PCMCIA cards were changed once a day by maintenance personnel when
the aircraft returned to the hangar; there was no pilot involvement with the system.
The flight data was downloaded from the PCMCIA cards to a PC and the cards reinitialised for re-use. The HOMP ground-based system is shown in Figure 3.2.
25 September 2002
Section 3 Page 4
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
2 Aircraft
SHL 008
REMOTE BASE
(S catsta)
Download
PC
3 Aircraft
S HL
ES-S
Back-up
S ystem
SHL 008
MAIN BASE
(Aberdeen)
Replay &
Analysis
System
BA
Figure 3.2 Ground-Based System
Every few days the flight data in the download PC at Scatsta was transferred to a zip
disk and sent to Aberdeen for analysis. Approximately 1 Mb of data was recorded per
hour, therefore in a typical day about 7 Mb of flight data and an additional 1 Mb of
ground data were gathered per aircraft. With these file sizes, and no more than two
HOMP aircraft located at Scatsta, it should have been feasible to transfer data
electronically via a company network or the Internet. However the trial sought to
evaluate the worst-case scenario in which such options might not be available, and
the ability to send mail on regular fixed-wing charter flights prevented any significant
data transfer delays.
All data analysis took place on the HOMP replay and analysis system at Aberdeen,
and the trial monitoring programme was managed from there on a part-time basis by
a senior training captain. The data from the Aberdeen aircraft was replayed on a daily
basis, with the data from the Scatsta aircraft being replayed in a batch process
whenever a zip disk was received. All the acquired flight data was retained to enable
re-analysis at a future date.
A back-up HOMP system was installed at ES-S's facility in Southampton to enable ESS to provide configuration, testing and ad-hoc analysis support to BHL. If necessary
for troubleshooting purposes, BA could log into the HOMP systems at BHL and ES-S
using “PC Anywhere”.
The model for BHL’s HOMP data analysis and programme management process is
shown in Figure 3.3.
25 September 2002
Section 3 Page 5
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Flight data
Changes to
Procedures,
Manuals,
Training
etc.
Changes to
HOMP,
Investigations
FLIGHT SAFETY
OFFICER:
Review Meeting
Reporting of
Trend information
to Management
and Staff
HOMP
OPERATOR:
Data Replay,
Analysis and
Verification
HOMP
MANAGER
(PILOT):
Assessment
Crew Feedback
Figure 3.3 Model HOMP Process
The model process involves three key personnel:
• A HOMP Operator. This person is responsible for the routine replay and analysis
of the flight data, and the initial verification of any events.
• A HOMP Manager. The HOMP Manager is a senior current pilot, ideally a training
captain, who manages the overall programme, provides the ‘expert pilot’ input
required for investigating events (calling on type-specific experience as required),
and liases with aircrew if necessary. The HOMP Manager reports findings to the
Flight Safety Officer. Alternatively, if a helicopter operator does not have a full time
Flight Safety Officer, the two roles could be combined.
• A Flight Safety Officer (FSO). The FSO is an existing post and provides the link
through which the HOMP integrates with the operator’s existing safety
management system. This person is responsible for deciding whether any actions
need to be taken on the basis of the information provided by the HOMP Manager.
Such actions could include recommending changes to company operating and/or
training procedures and manuals, the initiation of special HOMP investigations, or
recommending changes to the programme itself.
For the HOMP trial, BHL’s senior training captain on the Super Puma performed the
roles of both the HOMP Operator and Manager. He reviewed and assessed any
events generated and, being a peer of the flight crew rather than a member of BHL’s
management, followed these up with aircrew if necessary. He also issued regular
newsletters informing all BHL personnel of what was being learnt from the trial, and
held periodic meetings with the Flight Safety Officer to review key event information.
25 September 2002
Section 3 Page 6
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
An industry briefing was held for representatives of the North Sea helicopter
operators and oil companies to provide information on what was being learnt from the
trial and to obtain industry feedback. The UKOOA aircraft committee plus
management, flight safety, and pilot association representatives from UK and
European operators, together with representatives from the BHAB and BALPA, were
invited to this briefing. A number of other briefings were also given, including one to
the European Helicopter Operators Committee (EHOC). In addition, papers were
presented at two Royal Aeronautical Society Conferences (References 11 and 12) and
articles were published in three editions of the Helicopter World magazine (April-June
2001) to provide a wider dissemination of information on the HOMP trial.
25 September 2002
Section 3 Page 7
CAA PAPER 2002/02
Section 4
4.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP Trial Equipment and Data Analysis
On-aircraft equipment
The flight data generated by the BHL Tiger IHUMS Data Acquisition and Processing
Unit (DAPU) was written to a PCMCIA card by the BAE Systems Card Quick Access
Recorder (CQAR) Type 612/1/52937 shown in Figure 4.1.
Figure 4.1 CQAR
The CQAR utilises standard high capacity PCMCIA Type II ATA Flash PC cards. Cards
of a capacity greater than 16 Mbytes must be used with the recorder, there is no
upper limit on the capacity (20 and 48 Mbyte cards were used for the HOMP trial). A
‘low’ indicator is illuminated when the available free space on the card falls below
20% of the total card capacity. If the card is full, the CQAR will stop recording data. A
card may be inserted into the unit either before the unit is powered up, or at any time
following unit power up. The card may be removed from the unit at any time providing
the ‘busy’ indicator is not illuminated (i.e. when data is being written to the card from
an internal buffer). Cards are formatted using a DOS 16-bit FAT file system in order to
ensure compatibility across the MS-DOS 6.21, Windows 95 and Windows NT 4.0
operating systems.
The CQAR input signal is an ARINC 573-7 bi-polar RZ (return to zero) signal from the
auxiliary output from the IHUMS DAPU as defined in Attachment 10-5 of ARINC 5737. The CQAR starts recording data when QAR data is received and the QAR interface
(run control) is enabled. The QAR input is a continuous bit stream with the data in
repeated frames and each frame comprising four sub-frames. The CQAR will accept
64, 128, 256 or 512 12-bit word subframes, the IHUMS DAPU outputs 256 word 2
25 September 2002
Section 4 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
second subframes (i.e. a data rate of 128 words per second). ARINC 12-bit words are
stored as 16-bit words. Synchronisation of the data frames is achieved by embedded
sync words in the data stream. The CQAR supports both the ARINC 573 and ARINC
717 standards.
The QAR input interface carries out checks on every frame received. The received
frame is checked for the correct sync word in every subframe and for the correct
frame size. Any failure of the above checks for 35 consecutive seconds will illuminate
a ‘QAR fail’ indicator. Data recording is suspended during a QAR fail condition.
All data transferred to or from the CQAR resides in the card root directory. Files
written to the card by the CQAR have 01-01-80 00:00:00 for the date and time of
creation record in their directory entry. The QAR data files are named QARddd.DAT,
where sequence numbers ‘ddd’ are in the range 0 to 511. During normal operation
data will be appended to the current QAR file. A new QAR data file will be opened
following; power up with the CQAR enabled, a CQAR enable, reception of bad data
frames, power interruptions, or a CQAR hardware reset.
The physical characteristics of the CQAR are as follows:
Weight:
Unit Height:
Unit Width:
Unit Depth:
1.23 Lbs (0.56 Kilograms) (excluding card)
1.50 inches (38.10 mm)
5.75 inches (146.05 mm)
5.12 inches (130.05 mm) (excluding mating connector and earth stud)
For the HOMP trial the CQAR was mounted in the cockpit centre console, the unit
being secured in place by two DZUS quarter turn camlock fasteners. The fasteners
are arranged in standard DZUS rail format in accordance with Attachment 2 of ARINC
601. The CQAR operates from an aircraft +28V DC supply in accordance with RTCA
DO-160D, Section 16.0 Category Z and Section 17.0 Category A. Connection to the
unit is made via a single MIL-C-38999 Series II 37 pin circular bayonet coupling
connector mounted on the rear of the unit.
The BHL Tiger aircraft parameters recorded by the CQAR and de-coded in the groundbased system are listed in Table 4.1, which also shows the parameter sample rates.
25 September 2002
Section 4 Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Table 4.1 BHL Tiger Aircraft Parameters
Parameter Name
Short name
Parameter
Type
Sample
Rate (Hz)
-
-
A/C Registration
A/C Reg
ALT mode engaged
APALT
Discrete
1
ASE 1 Pitch
ASE1PTCH
Discrete
1
ASE 1 Roll
ASE1ROLL
Discrete
1
ASE 1 Yaw
ASE1YAW
Discrete
1
ASE 2 Pitch
ASE2PTCH
Discrete
1
ASE 2 Roll
ASE2ROLL
Discrete
1
ASE 2 Yaw
ASE2YAW
Discrete
1
Captain's R/T
PTTP1
Discrete
1
Collective Pitch
COLLPTCH
Continuous
4
Co-Pilot’s R/T
PTTP2
Discrete
1
Date Day
DATEDD
-
-
Date Month
DATEMM
-
-
Date Year
DATEYY
-
-
DME No.1 Distance
DME1
Continuous
0.5
DME No.2 Distance
DME2
Continuous
0.5
Drift Angle
DRIFTA
Continuous
0.5
Event Marker
EVENT
Discrete
1
Framecount
FRMCNT
-
-
Fuel Contents LH
FUEL1
Continuous
0.5
Fuel Contents RH
FUEL2
Continuous
0.5
Gear Down - LH
GEARDLH
Discrete
1
Gear Down - Nose
GEARDNOS
Discrete
1
Gear Down - RH
GEARDRH
Discrete
1
Gear select up
GEARSELUP
Discrete
1
Glide Slope Deviation
GS
Continuous
1
Ground Speed
GSPD
Continuous
1
HDG Mode engaged
APHDG
Discrete
1
Heading (Magnetic)
HDGM
Continuous
1
Heater
HEATER
Discrete
1
IAS Mode engaged
APIAS
Discrete
1
Ice Detect Liq. Water Content
ICEDET
Continuous
2
Indicated Airspeed
IAS
Continuous
1
Intermediate Gearbox Oil Temp
IGBOILT
Continuous
0.5
Lateral Acceleration
LATA
Continuous
4
Lateral Cyclic Pitch
CYCPTCHLAT
Continuous
4
Latitude
LATLSP
Continuous
0.5
25 September 2002
Section 4 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Table 4.1 BHL Tiger Aircraft Parameters
Localiser Deviation
LOC
Continuous
1
Longitude
LONGLSP
Continuous
0.5
Longitudinal Acceleration
LNGA
Continuous
4
Longitudinal Cyclic Pitch
CYCPTCHLONG
Continuous
4
Main G/box Oil Temp
MGBOILT
Continuous
0.5
Main Gearbox Oil Pressure
MGBOILP
Continuous
1
Main Rotor Speed (Nr)
MRSPEED
Continuous
2
MLS Azimuth
MLSAZ
Continuous
1
MLS Elevation
MLSEL
Continuous
1
Nf 1 (No 1 Free Turbine Speed)
EFTS1
Continuous
2
Nf 2 (No 2 Free Turbine Speed)
EFTS2
Continuous
2
Ng 1 (No 1 Gas Generator rpm)
EGGS1
Continuous
4
Ng 2 (No 2 Gas Generator rpm)
EGGS2
Continuous
4
Normal Acceleration
NMLA
Continuous
8
Outside Air Temperature
OAT
Continuous
1
Pitch Attitude
PITCH
Continuous
4
Pressure Altitude
PALTC
Continuous
1
Radio Altitude
RALT
Continuous
2
RNAV Mode engaged
APRNAV
Discrete
1
Roll Attitude
ROLL
Continuous
4
Rotor Brake
RBRAKE
Discrete
1
Sling Load
SLING
Continuous
2
Sync Bit
SYNCBIT
-
-
T4 1 (No 1 Exhaust Gas Temp)
EGT1
Continuous
2
T4 2 (No 2 Exhaust Gas Temp)
EGT2
Continuous
2
Tail Rotor Gearbox Oil Temp
TRGBOILT
Continuous
0.5
Tail Rotor Pedal
TRPEDAL
Continuous
4
TIME GMT (hrs)
GMTHH
-
-
TIME GMT (min)
GMTMM
-
-
Torque Engine 1
TORQ1
Continuous
2
Torque Engine 2
TORQ2
Continuous
2
Vertical Speed (from DIGITAS)
ALTRATE
Continuous
2
Weight On Wheels
WGHTONWH
Discrete
1
Wind Angle
WINDANGLE
Continuous
0.5
Wind Speed
WINDSPEED
Continuous
0.5
Yaw Rate
YAWRATE
Continuous
4
25 September 2002
Section 4 Page 4
CAA PAPER 2002/02
4.2
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Ground-based equipment
A data download PC was provided for downloading PCMCIA card data from
helicopters operating remotely at Scatsta. The primary method of data transfer to the
HOMP system at Aberdeen was by zip disc, however a modem was installed to
provide an option to e-mail data across the Internet.
A networked PC was provided to run the HOMP software at Aberdeen. This PC
analysed the data downloaded from the PCMCIA cards from the aircraft at Aberdeen
together with the data transferred by zip disc from the PC at Scatsta. When cards
were inserted into the PCMCIA card reader the raw flight data files were
automatically copied to a known directory on the computer’s hard disk to await
processing by the HOMP software. The specification of the PC was as follows:
Processor
Memory
Hard Drive
Floppy Drive
CD-RW Drive
PCMCIA card reader
Monitor
Zip Drive
Modem
Network Card
Tape Backup Unit
Operating System
Application software
Colour printer
Intel 550MHz Pentium III
128MB
15.3GB
1.44MB 3.5" Diskette Drive
21" colour Monitor
Iomega Internal ATAPI Zip Drive
56K Modem with gateway.net Internet Access
3COM PCI 10/100 Twisted Pair Ethernet
TR5 10/20GB IDE Internal
MS Windows NT
MS Office 2000 Professional + MS Access 2000
HP DeskJet 1220C
A third PC was located at ES-S, also running the HOMP software to provide support
for the main system at Aberdeen. Data could be transferred between BHL and ES-S
using the following media; PCMCIA cards, CDs, tapes and email.
4.3
HOMP software
The HOMP software comprised the four flight data modules in the British Airways
Safety Information System (BASIS). Since its inception in 1990, BASIS has become
the leading aviation safety management tool and the de facto standard air safety
reporting tool. The system is used by approximately 150 organisations including major
airlines, regulatory authorities and aircraft manufacturers. North Sea helicopter
operators were already using the BASIS Air Safety Reporting module.
The BASIS flight data modules run on standard PCs and can be network based. One
advantage of the BASIS analysis software is that it has been developed with the
assistance and co-operation of both flight crew and management, both of whom use
the system on a day to day basis. Security safeguards have been built into the various
BASIS flight data modules to ensure that the stored information is appropriately deidentified to all except a few nominated personnel. The four BASIS flight data
modules are described below.
25 September 2002
Section 4 Page 5
CAA PAPER 2002/02
4.3.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Flight Data Traces (FDT)
FDT performs the flight data replay, event and measurement analysis, and displays
flight data traces. The module’s intuitive and user configurable design is intended to
allow non-specialists to operate and maintain the system. The module performs the
following functions:
• Reads in the raw flight data from the aircraft’s onboard flight data recorder.
• Automatically detects events defined by the operator.
• Automatically extracts a set of flight data measurements.
• Stores traces and events for future analysis.
• Displays selected flight data and detected events as a trace or listing on screen.
• Produces outputs to other BASIS flight data modules.
• Analyses flight data associated with Air Safety Reports.
When processing data, FDT automatically replays all the downloaded flight data,
detects events and extracts flight data measurements. When used for data
investigation it provides numerical listings and graphical traces to enable the user to
investigate and classify events. A typical trace display is shown in Figure 4.2. FDT
provides facilities for the user to configure the flight parameter decode, the
calculation of derived parameters from the basic parameter set, the event definitions
and event limits or constants, the flight data measurements, and flight data trace
displays.
The module performs an automatic five-step process when reading the raw flight data
files:
Step 1: Parameter Decode
The FDT software monitors the directory where the copied files have been
placed and will automatically capture and decode any new files found in it. The
decode procedure converts the raw flight data into engineering units using a set
of standard parameter decode equations (specific to the QAR frame layout). For
the HOMP trial, FDT decoded approximately 70 parameters (variables and
discretes). Not all parameters stored on the QAR need to be configured or
decoded in FDT. Indeed, the smaller the number of parameters processed the
quicker the decode phase will be. FDT automatically determines departure and
arrival locations based on the latitude and longitude at take-off and landing.
25 September 2002
Section 4 Page 6
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 4.2 Sample Trace From Super Puma FDT
Step 2: Flight Phases
FDT then determines the flight phases based on the data recorded; there
normally are several flights on each PMCIA card. The user can configure these
flight phases using simple logic statements. The flight phases used in the
HOMP trial were:
1 On-ground (prior to take-off)
2 Take-off
3 Cruise
4 Landing
5 On-ground (after landing)
Step 3: Derived parameters
There are a number of parameters that are not available directly from the QAR
but which are needed for detecting events. Such parameters are referred to as
derived parameters. FDT uses the now decoded QAR parameters and the flight
phases to calculate a number of derived parameters (e.g. Density Altitude for
Vne/Vno). FDT calculates a day/night parameter which can be used to
determine whether an event occurred in daylight or darkness.
Step 4: Event Detection
FDT now searches all of the decoded data for pre-defined events. These events
normally involve applying limits to one or more parameters (or derived
parameters) when in a particular flight phase or phases. The event definitions
25 September 2002
Section 4 Page 7
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
are totally configurable by the operator and can be extremely complex logical
equations if required. A total of 85 events were configured in the HOMP trial
(for comparison, BA monitors 63 events on the B777 fleet).
Step 5: Flight Data Measurements
The final step in this automatic FDT process is the capture of a set of flight data
measurements which are maximum or “worst case” values of selected
parameters (including derived parameters) under specified conditions, or
parameter values at specific points of a flight or when specific events occur.
Approximately 140 measurements were extracted in the HOMP trial (BA uses
70 on the B777 fleet).
Once all the five steps are complete FDT accepts the decoded file as a new record in
its database. The record appears as a line of information on the front screen (browse
list). One of the columns shows the number of events detected and the user can
double click on the line to look at these events in detail (Figure 4.3). Alternatively the
user can review events in a browser which enables all events to be accessed from a
central area, removing the need to access these from individual flight data files.
With experience, the user can normally quickly determine if the event is genuine by
looking at the data trace, the numerical listing and/or the Flight Data Simulation (FDS)
for the event. Nuisance or false events can be marked as such within FDT, these can
then be deleted or excluded from further analysis. If the nuisance or false events are
regular and predictable then the event definition in FDT can be altered to eliminate
these. Once the user has determined which events are genuine, the details of these
events can now be exported to the FDE (Flight Data Events) module. FDT creates
three files for each event:
• A cut-down raw data file just for that event
• A file with the necessary event details for FDE
• A file to simulate the event using FDS
FDT will also export a measurement data file to the BASIS FDM (Flight Data
Measurements) module, irrespective of whether any events have been detected for
a given flight.
In addition to the event and measurement analysis, FDT has an automatic
serviceability output function which enables automatic extractions of flight data to be
scheduled at specified intervals for checking of the FDR parameters.
25 September 2002
Section 4 Page 8
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 4.3 Events Detected List in FDT
4.3.2
Flight Data Simulation (FDS)
FDS recreates the flight just as the pilot saw it, allowing data to be viewed in the form
of a basic flight instrument simulation. The flight controls and autopilot modes are also
displayed and the aircraft flight path is shown. A new version of this module,
simulating a Super Puma cockpit, was produced for the HOMP trial. FDS is a valuable
tool for use in the event investigation process, and is also a powerful debriefing aid
when it is necessary to involve the aircrew to understand the circumstances and
causes of a particular event. The self-contained nature, and very small size, of the
viewing program allows it and the relevant portion of flight data to be e-mailed or sent
on a floppy disk to aircrew for their review on any PC. This can be particularly useful
for debriefing crews at remote operating bases. The Super Puma FDS display is
shown in Figure 4.4.
25 September 2002
Section 4 Page 9
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 4.4 Super Puma FDS Display
4.3.3
Flight Data Events (FDE)
FDE enables further analysis of the events generated by FDT. FDE receives verified
event records exported from FDT and stores these in its database. Events imported
into FDE are given unique reference numbers and stored by fleet type. With the
addition of FDV (the Flight Data Viewer), the user can view the raw data associated
with each event as a trace, listing or flight simulation directly from the event record
within FDE.
The user can add keywords and notes to event forms and track any follow up actions
(Figure 4.5). The system can be (and is at BA) linked to the BASIS Air Safety Reporting
(ASR) module. If the pilot has raised an ASR for the event held in FDE, then this
obviously relevant information can be viewed alongside the event details.
25 September 2002
Section 4 Page 10
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 4.5 FDE Event Form
FDE enables the user to manually allocate a numerical value (severity index) to each
event to indicate the relative severity of that event. FDE also allows the user to enter
severity equations so that it can automatically calculate a severity index for each
imported event. This enables the analysis of event trends based on cumulative
severity measures, rather than simply on frequency of occurrence. The severity index
enables event trends to be related to degrees of operational risk, and is therefore a
valuable management tool. BA have developed severity equations for their SESMA
programme, however these are specific to the fixed wing events, and therefore could
not be applied to the helicopter events implemented in the HOMP trial. As an
alternative to the allocation of severity values within FDE, it is possible to manually
allocate values in FDT and import these into FDE.
The module can be used to analyse events by aircraft type, registration, event type,
location, date, keyword etc. Events can easily be filtered using a range of criteria and
the filtered subset of the data can be displayed in a variety of ways. Trend charts can
be produced using various parameters; e.g. the top events in a given fleet (either by
frequency or severity), worst locations for certain landing events etc. Once created,
these charts can be stored in a trend library for rapid recall. Operational data such as
the number of sectors flown by aircraft type and movements at locations can be
imported into FDE allowing trend charts to show rated data such as the number of
events per 1,000 sectors. An appropriate date range can be specified, and graphs can
be produced showing the change in event numbers over a current period compared
to a previous period. The trend charts can be used to identify adverse trends or
patterns, to measure the effectiveness of past resolutions to problems, and to
monitor the effect of changes to SOPs. A typical trend chart is shown in Figure 4.6.
25 September 2002
Section 4 Page 11
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 4.6 Typical FDE Trend Chart
4.3.4
Flight Data Measurements (BASIS FDM)
BASIS FDM is a tool for analysing the flight data measurements extracted by FDT,
enabling the analysis of flight parameter values on each and every flight and showing
how parameters are distributed over many flights. Exported measurement data from
FDT is imported into FDM and again stored by fleet type.
FDM facilitates a better understanding of operational variables by showing their
‘normal’ distributions and enabling comparisons of distributions across different
locations, fleets etc. Two distributions can be compared on the same chart; e.g. the
same flight data parameter on another aircraft type, registration, location, date range
or against a standard normal distribution. The mean and standard deviation are
automatically calculated for each distribution and can also be plotted to illustrate the
spread of the measurements.
FDM information can be used in conjunction with the analysis provided by FDE. This
can help to determine whether certain events are isolated occurrences or whether
there have been many more “near misses” just below the event limit. Information
from FDM is also useful for the setting of meaningful event limits for FDT. An
example BASIS FDM display is shown in Figure 4.7:
25 September 2002
Section 4 Page 12
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 4.7 Typical BASIS FDM Display
4.4
HOMP data analysis
As explained previously, the HOMP software performs two types of analysis:
• Event analysis, which provides information on the extremes of the operation.
• Measurement analysis, which provides information on the whole operation.
An initial set of flight data events was specified by the HOMP trial project team at the
start of the trial. The flight data measurements were specified part way through the
trial after the events had been implemented. Towards the end of the trial an additional
set of offshore take-off and landing profile measurements were implemented.
The events and measurements were subject to continuous development and by the
end of the trial comprehensive sets of events and measurements had been produced.
These are presented in Tables 4.2 to 4.6. Tables 4.2 and 4.4 show the HOMP events
and measurements grouped by type and the flight phase in which they are calculated.
Tables 4.3 and 4.5 present listings of all the events and measurements. Table 4.6 lists
the additional offshore take-off and landing profile measurements which were
implemented at the end of the trial.
25 September 2002
Section 4 Page 13
On Ground before
Take-off
Descent/Approach/
Landing
Cruise
On Ground after Landing
• Low height in cruise
•
•
•
•
• High taxi speed
• High rate of descent
• High rate of descent at
low airspeed
• Low airspeed
• VNO/VNE exceedance
• High rate of descent
• High rate of descent at
low airspeed
• Low airspeed
• VNO/VNE exceedance
• High rate of descent
• High rate of descent at
low airspeed
• High groundspeed on
approach
• High taxi speed
• High pitch attitude (up/
down)
• High roll attitude
• High pitch attitude (up/
down)
• High pitch rate
• High roll attitude
• High roll rate
• High pitch attitude (up/
down)
• High pitch rate
• High roll attitude
• High roll rate
• High pitch attitude (up/
down)
• High pitch rate
• High roll attitude
• High roll rate
• High pitch attitude (up/
down)
• High roll attitude
P
R
O
F
I
L
E
S
P
E
E
D
Go around
Low height on go around
Gear down late
Downwind flight
Section 4 Page 14
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
• High/Low pitch attitude
at rotation point (for rig
t/o)
• High/Low pitch rate at
rotation point (for rig t/o)
• Early turn at night
• Gear up early
• Downwind flight
F
L
T
A
T
T
I
T
U
D
E
Take-off/Climb
CAA PAPER 2002/02
25 September 2002
Table 4.2 HOMP Events Grouped by Type and Flight Phase
On Ground before
Take-off
C
O
N
T
R
O
L
S
P
O
W
E
R
T
R
A
I
N
Section 4 Page 15
O
T
H
E
R
Cruise
Descent/Approach/
Landing
On Ground after Landing
• Rollover limits
• Autopilot engagement
• Excessive cyclic
longitudinal pitch
• High cyclic lateral rate
• High cyclic longitudinal
rate
• Excessive collective pitch
• Excessive cyclic
longitudinal pitch
• Excessive cyclic lateral
pitch
• Inappropriate autopilot
modes
• Excessive collective
pitch
• Excessive cyclic
longitudinal pitch
• Excessive cyclic lateral
pitch
• Inappropriate autopilot
modes
• Excessive collective
pitch
• Excessive cyclic
longitudinal pitch
• Excessive cyclic lateral
pitch
• Inappropriate autopilot
modes
• Rollover limits
• Autopilot engagement
• Excessive cyclic
longitudinal pitch
• High cyclic lateral rate
• High cyclic longitudinal
rate
• High Deck Motion
Severity Index
• High lateral acceleration
• High longitudinal
acceleration
• High lateral acceleration
• High longitudinal
acceleration
• High normal acceleration
• High lateral acceleration
• High longitudinal
acceleration
• High normal
acceleration
• High lateral acceleration
• High longitudinal
acceleration
• High normal
acceleration
• High normal
acceleration on landing
• High Deck Motion
Severity Index
• High lateral acceleration
• High longitudinal
acceleration
• High main rotor speed
• Heater on during take-off
• High/Low main rotor
speed power on
• High/Low main rotor
speed power off
• High torque
• Single engine flight
• High/Low main rotor
speed power on
• High/Low main rotor
speed power off
• High torque
• Torque split
• Single engine flight
• Heater on during landing
• High/Low main rotor
speed power on
• High/Low main rotor
speed power off
• High torque
• Single engine flight
• High main rotor speed
• Rotor brake application
• Flight through hot gas
• Low fuel contents
• Pilot workload/
turbulence
• Flight through hot gas
• Low fuel contents
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
A
C
C
E
L
S
Take-off/Climb
CAA PAPER 2002/02
25 September 2002
Table 4.2 HOMP Events Grouped by Type and Flight Phase
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
High Pitch-Up Attitude
Below 20 ft AGL
Air
Pitch Attitude, Radio
Altitude
To detect the risk of a tail rotor strike.
01B
High Pitch-Up Attitude
Above 20 ft and Below 500
ft AGL
Air
Pitch Attitude, Radio
Altitude
To detect excessive flare angle i.e. rushed final approach, likely to
alarm passengers or cause crew to lose visual reference.
01C
High Pitch-Up Attitude
Above 500 ft AGL
Air
Pitch Attitude, Radio
Altitude
To detect excessive pitch up attitude in flight.
01D
High Pitch-Up Attitude
Below 90 knots IAS
Air
Pitch Attitude, Indicated
Airspeed
To detect excessive pitch up attitude at lower speeds.
01E
High Pitch-Up Attitude
Above 90 knots IAS
Air
Pitch Attitude, Indicated
Airspeed
To detect excessive pitch up attitude at higher speeds.
02A
High Pitch-Down Attitude
Below 20 ft AGL
Air
Pitch Attitude, Radio
Altitude
To detect excessive nose down pitch attitude during take-off
transition which might result in striking the ground if an engine
failed.
02B
High Pitch-Down Attitude
Above 20 ft and Below 500
ft AGL
Air
Pitch Attitude, Radio
Altitude
To detect excessive nose down pitch attitude during take-off
transition and at other lower level flight conditions.
02C
High Pitch-Down Attitude
Above 500 ft AGL
Air
Pitch Attitude, Radio
Altitude
To detect excessive pitch down attitude in flight.
02D
High Pitch-Down Attitude
Below 90 knots IAS
Air
Pitch Attitude, Indicated
Airspeed
To detect excessive pitch down attitude at lower speeds.
02E
High Pitch-Down Attitude
Above 90 knots IAS
Air
Pitch Attitude, Indicated
Airspeed
To detect excessive pitch down attitude at higher speeds.
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 16
01A
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
High Pitch Rate Below 500
ft AGL
Air
Pitch Rate, Radio Altitude
To detect excessive rate of change of pitch attitude at lower level
flight conditions.
03B
High Pitch Rate Above 500
ft AGL
Air
Pitch Rate, Radio Altitude
To detect excessive rate of change of pitch attitude in flight.
04A
Low Maximum Pitch Rate
on Rig Take-Off
Rig Take-Off
Pitch Rate
To detect a low helicopter rotation rate during rotation on a take-off
from a helideck which could result in a deck strike if an engine
failed.
04B
High Maximum Pitch Rate
on Rig Take-Off
Rig Take-Off
Pitch Rate
To detect a high helicopter rotation rate during rotation on a takeoff from a helideck, which might cause crew disorientation and
passenger alarm.
05A
Low Maximum Pitch-Down
Attitude on Rig Take-Off
Rig Take-Off
Pitch Attitude
To detect a low nose down pitch attitude during rotation on a takeoff from a helideck, which could result in a deck strike if an engine
failed.
05B
High Maximum Pitch-Down
Attitude on Rig Take-Off
Rig Take-Off
Pitch Attitude
To detect a high nose down pitch attitude during rotation on a takeoff from a helideck, which might cause crew disorientation and
passenger alarm.
06A
Roll Attitude Above 30 deg
Below 300 ft AGL
Air
Roll Attitude, Radio Altitude
To detect exceedance of the Flight Manual roll attitude limit for
weights above 18,410 lb at lower level flight conditions.
06B
Roll Attitude Above 40 deg
Below 300 ft AGL
Air
Roll Attitude, Radio Altitude
To detect exceedance of the Flight Manual roll attitude limit for
weights above 17,200 lb at lower level flight conditions.
06C
Roll Attitude Above 30 deg
Above 300 ft AGL
Air
Roll Attitude, Radio Altitude
To detect exceedance of the Flight Manual roll attitude limit for
weights above 18,410 lb.
06D
Roll Attitude Above 40 deg
Above 300 ft AGL
Air
Roll Attitude, Radio Altitude
To detect exceedance of the Flight Manual roll attitude limit for
weights above 17,200 lb.
07A
High Roll Rate Below 500 ft
AGL
Air
Roll Rate, Radio Altitude
To detect excessive roll rate at lower level flight conditions.
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 17
03A
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
High Roll Rate Above 500 ft
AGL
Air
Roll Rate, Radio Altitude
To detect excessive roll rate in flight.
08A
High Rate of Descent
Below 500 ft AGL
Air
Rate of Descent, Radio
Altitude
To detect an excessive rate of descent at low height.
08B
High Rate of Descent
Above 500 ft AGL
Air
Rate of Descent, Radio
Altitude
To detect an excessive rate of descent.
08C
High Rate of Descent
Below 30 knots LAS
Air
Rate of Descent, Indicated
Airspeed
To detect an excessive rate of descent at low airspeed (where
there is danger of entering the vortex ring state).
09A
Low Airspeed Above 500 ft
AGL
Take-Off,
Cruise
Indicated Airspeed
To detect flight at an unusually low airspeed.
10A
Normal Acceleration Above
500 ft AGL
Air
Normal Acceleration, Radio
Altitude
To detect a high normal acceleration in flight due to turbulence or a
manoeuvre.
10B
Normal Acceleration Below
500 ft AGL
Air
Normal Acceleration, Radio
Altitude
To detect a high normal acceleration at lower level flight conditions
due to turbulence or a manoeuvre.
10C
Lateral Acceleration Above
500 ft AGL
Air
Lateral Acceleration, Radio
Altitude
To detect a high lateral acceleration in flight due to turbulence or a
manoeuvre.
10D
Lateral Acceleration Below
500 ft AGL
Air
Lateral Acceleration, Radio
Altitude
To detect a high lateral acceleration at lower level flight conditions
due to turbulence or a manoeuvre.
10E
Longitudinal Acceleration
Above 500 ft AGL
Air
Longitudinal Acceleration,
Radio Altitude
To detect a high longitudinal acceleration in flight due to turbulence
or a manoeuvre.
10F
Longitudinal Acceleration
Below 500 ft AGL
Air
Longitudinal Acceleration,
Radio Altitude
To detect a high longitudinal acceleration at lower level flight
conditions due to turbulence or a manoeuvre.
11A
Excessive Lateral Cyclic
Control
Air
Lateral Cyclic Pitch
To detect movement of the lateral cyclic control to extreme left or
right positions.
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 18
07B
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
Excessive Longitudinal
Cyclic Control
Air
Longitudinal Cyclic Pitch
To detect movement of the longitudinal cyclic control to extreme
forward or aft positions.
12A
Excessive Collective Pitch
Control in Level Flight
Air
Collective Pitch, Rate of
Descent
To detect approaches to, or exceedances of, Flight Manual
collective pitch limits for cruising flight.
12B
Excessive Collective Pitch
Control
Air
Collective Pitch
To detect exceedances of the absolute maximum Flight Manual
collective pitch limit.
13A
Pilot Event Marker Pressed
Air
14A
IAS Mode Engaged Below
60 knots IAS
Air
Autopilot IAS Mode,
Indicated Airspeed
To detect inappropriate engagement of autopilot airspeed hold at
low airspeeds.
14B
ALT Mode Engaged Below
60 knots IAS
Air
Autopilot ALT Mode,
Indicated Airspeed
To detect inappropriate engagement of autopilot altitude hold at
low airspeeds.
14C
HDG Mode Engaged Below
60 knots IAS
Air
Autopilot HDG Mode,
Indicated Airspeed
To detect inappropriate engagement of autopilot heading hold at
low airspeeds.
15A
Gear Selected Up Below
100 ft AGL on Take-off
Take-Off
Gear Select, Radio Altitude
To detect early retraction of the landing gear during take-off.
15B
Gear Not Selected Down
Below 300 ft AGL on
Landing
Landing
Gear Select, Radio Altitude
To detect late lowering of the landing gear during landing.
16A
Excessive Time in Avoid
Area
17A/C
VNO Exceedance
Air
VNO, Weight
To detect exceedance of the Flight Manual VNO limit (this is
weight dependent).
17B/D
VNE Exceedance
Air
VNE, Weight
To detect exceedance of the Flight Manual VNE limit (this is weight
dependent).
To detect when the FDR pilot event marker has been pressed.
Not yet implemented (awaiting low airspeed algorithm).
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 19
11B/C
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
No. 1 (LH) Fuel Contents
Low
Air
LH Fuel Contents
To detect if the total remaining fuel contents fall below the
Operations Manual limit.
18B
No. 2 (RH) Fuel Contents
Low
Air
RH Fuel Contents
To detect if the total remaining fuel contents fall below the
Operations Manual limit.
19A
Heater On During Take-Off
Take-Off
Heater
To detect non-conformance with the Flight Manual requirement
that the cabin heater should be off during take-off.
19B
Heater On During Landing
Landing
Heater
To detect non-conformance with the Flight Manual requirement
that the cabin heater should be off during landing.
20A
Early Turn on Offshore
Take-Off at Night
Rig Take-Off
Heading, Ground Speed
To detect an early turn after an offshore take-off at night.
21A
High Ground Speed Within
20 seconds of Rig Landing
Rig Landing
Ground Speed
To detect a high ground speed on the final approach to a helideck
landing.
21B
High Ground Speed Within
10 seconds of Airport
Landing
Airport
Landing
Ground Speed
To detect a high ground speed on the final approach to an airport
landing.
22A
High Airspeed Below 100 ft
AGL
Air
Indicated Airspeed, Radio
Altitude
To detect high speed flight at low level.
22B
High Airspeed Below 100 ft
AGL and Gear Up
Air
Indicated Airspeed, Radio
Altitude, Gear Select
To detect high speed flight at low level with the landing gear
retracted.
23A
Downwind Flight Within 60
seconds of Take-Off
Take-Off
Indicated Airspeed, Ground
Speed
To detect downwind flight shortly after take-off.
23B
Downwind Flight Within 60
seconds of Landing
Landing
Indicated Airspeed, Ground
Speed
To detect downwind flight shortly before landing.
24A
Low Rotor Speed – Power
On
Air
Rotor Speed, Total Torque
To detect excessively low rotor speed during power-on flight.
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 20
18A
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
High Rotor Speed – Power
On
Air
Rotor Speed, Total Torque
To detect excessively high rotor speed during power-on flight.
24C
Low Rotor Speed - Power
Off
Air
Rotor Speed, Total Torque
To detect exceedance of the Flight Manual minimum rotor speed
limit for power-off flight.
24D
High Rotor Speed – Power
Off
Air
Rotor Speed, Total Torque
To detect exceedance of the Flight Manual maximum rotor speed
limit for power-off flight.
25A
Maximum Continuous
Torque (2 Engines)
Air
Total Torque
To detect more than 5 minutes use of the Flight Manual take-off
rating torque limit
25B
Maximum Take-Off Torque
(2 Engines)
Air
Total Torque
To detect exceedance of the Flight Manual absolute maximum
torque limit.
26A
Pilot Workload/Turbulence
Landing
Changes in Collective Pitch
To detect turbulence encountered during the final approach to a
helideck landing.
27A
Pilot Workload
Landing
Collective, Lateral &
Longitudinal Cyclic
Not yet implemented (awaiting outcome of CAA research project).
28A
Flight Though Hot Gas
Take-Off,
Landing
Outside Air Temperature
To detect if the aircraft flies through the turbine efflux or flare
plume during a helideck take-off or landing.
29A
High Pitch-Up Attitude on
Ground
Ground
Pitch Attitude
To detect high aircraft pitch angles when on a vessel’s helideck, or
on sloping ground.
29B
High Pitch-Down Attitude
on Ground
Ground
Pitch Attitude
To detect high aircraft pitch angles when on a vessel’s helideck, or
on sloping ground.
30A
High Roll Attitude on
Ground
Ground
Roll Attitude
To detect high aircraft roll angles during taxiing, when on a vessel’s
helideck, or on sloping ground.
31A
High Normal Acceleration
at Landing
Landing,
Ground
Normal Acceleration
To detect a heavy landing.
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 21
24B
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
High Rotor Speed on
Ground
Ground
Rotor Speed
To detect possible governor problems on the ground.
33A
Rotor Brake Applied at
Greater Than 122 Rotor
RPM
Ground
Rotor Brake, Rotor Speed
To detect application of the rotor brake above the Flight Manual
limit for rotor speed.
34A
Excessive Long Cyclic
Control with Insufficient
Collective Pitch on Ground
Ground
Collective Pitch,
Longitudinal Cyclic Pitch
To detect incorrect taxi technique likely to cause rotor head
damage.
34B
Excessive Rate of
Movement of Longitudinal
Cyclic on Ground
Ground
Longitudinal Cyclic Pitch
Rate, Rotor Speed
To detect an excessive rate of movement of the longitudinal cyclic
control when on the ground with rotors running.
34C
Excessive Rate of
Movement of Lateral Cyclic
on Ground
Ground
Lateral Cyclic Pitch Rate,
Rotor Speed
To detect an excessive rate of movement of the lateral cyclic
control when on the ground with rotors running.
35A/B
Excessive Movement of
Deck
Helideck
Motion Severity Index
To detect excessive movement of a vessel’s helideck when the
helicopter is on the deck.
36A
High Lateral Acceleration
(rapid cornering)
Ground
Lateral Acceleration
To detect excessive cornering accelerations/speeds when taxiing.
36B
High Longitudinal
Acceleration (rapid braking)
Ground
Longitudinal Acceleration
To detect excessive deceleration due to braking when taxiing.
37A
High Ground Speed
Ground
Ground Speed
To detect excessive taxiing speeds.
38A
Taxi Limit (left gear lifts)
Ground
Lateral Cyclic Pitch, Tail
Rotor Pedal
To detect the risk of an aircraft roll over due to incorrect tail rotor
pedal and lateral cyclic control positions when taxiing.
38B
Taxi Limit (right gear lifts)
Ground
Lateral Cyclic Pitch, Tail
Rotor Pedal
To detect the risk of an aircraft roll over due to incorrect tail rotor
pedal and lateral cyclic control positions when taxiing.
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 22
32A
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
Event
Number
Title
Applicable
Condition
Trigger Parameters
Rationale
Single Engined flight
Air
No 1 Eng Torque, No 2 Eng
Torque
To detect single engined flight.
40A
Torque Split in the Cruise
Cruise
No 1 Eng Torque, No 2 Eng
Torque
To detect a possible engine problem, subsequently found to have
been caused by module 2 stator vane rotation.
41A
Go Around
Cruise,
Landing
Gear Select
To detect a go-around.
41B
Below Minimum Height on
Go Around
Cruise,
Landing
Gear Select, Radio Altitude
To detect a descent below the minimum height limit during a go
around.
41C
Below Minimum Height on
Go Around at Night
Cruise,
Landing
Gear Select, Radio Altitude
To detect a descent below the minimum height limit during a go
around at night.
42A
Autopilot Engaged On
Ground Before Take-Off
Ground
Autopilot Status
To detect premature engagement of the autopilot prior to take-off
which could result in unexpected control movements.
42B
Autopilot Engaged On
Ground After Landing
Ground
Autopilot Status
To detect failure to disengage the autopilot after landing which
could result in unexpected control movements.
Section 4 Page 23
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
39A
CAA PAPER 2002/02
25 September 2002
Table 4.3 Listing of HOMP Events
On Ground before
Take-off
Take-off/Climb
Cruise
Descent/Approach/
Landing
• Press alt at landing
On Ground after Landing
F
L
T
• Press alt at t/o
• Max Press alt
• Max pitch attitude at
rotation (for rig t/o)
• Max airspeed at low
height
• Radio alt at gear down
P
R
O
F
I
L
E
• Max pitch rate at rotation
(for rig t/o)
• Max rate of descent
• Max rate of descent
• Max rate of descent
• Max rate of descent at
low airspeed
• Max rate of descent at
low airspeed
• Max rate of descent at
low airspeed
• Min airspeed
• Max/Min airspeed
• Max/Min airspeed
• Max/Min pitch attitude
• Max roll attitude
CAA PAPER 2002/02
25 September 2002
Table 4.4 HOMP Flight Data Measurements Grouped by Type and Flight Phase
• Radio alt at rotation (for
rig t/o)
• Radio alt at gear up
S
P
E
E
D
Section 4 Page 24
A
T
T
I
T
U
D
E
• Max/Min pitch attitude
• Max/Min pitch attitude
• Max/Min pitch attitude
• Groundspeed on
approach
• Max/Min pitch attitude
• Max roll attitude
• Max pitch rate
• Max pitch rate
• Max pitch rate
• Max roll attitude
• Max roll attitude
• Max roll attitude
• Max roll rate
• Max roll rate
• Max roll rate
• Max yaw rate
• Max yaw rate
• Max yaw rate
C
O
N
T
R
O
L
S
• Max cyclic longitudinal
pitch
• Max cyclic lateral rate
• Max cyclic longitudinal
rate
• Max collective pitch
• Max cyclic longitudinal
pitch
• Max cyclic lateral pitch
• Min airspeeds for
autopilot modes
• Max collective pitch
• Max cyclic longitudinal
pitch
• Max cyclic lateral pitch
• Min airspeeds for
autopilot modes
• Max collective pitch
• Max cyclic longitudinal
pitch
• Max cyclic lateral pitch
• Min airspeeds for
autopilot modes
• Max taxi speed
• Max cyclic longitudinal
pitch
• Max cyclic lateral rate
• Max cyclic longitudinal
rate
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
• Max taxi speed
A
C
C
E
L
S
O
T
H
E
R
• Max main rotor speed
• Max EGT at engine start
Take-off/Climb
Cruise
• Max lateral acceleration
• Max longitudinal
acceleration
• Max normal acceleration
• Max lateral acceleration
• Max longitudinal
acceleration
• Max normal acceleration
•
•
• Max/Min main rotor
speed power on
• Max/Min main rotor
speed power off
• Max torque
• Max EGT
• Max engine gas
generator speed
• Max MGB/IGB/TGB oil
temp
• Max/Min MGB oil press
• OAT at take-off
• Take-off weight
• Fuel contents at t/o
• Wind speed/direction
• Max increase in OAT
• Max/Min main rotor
speed power on
• Max/Min main rotor
speed power off
• Max torque
• Max EGT
• Max engine gas
generator speed
• Max MGB/IGB/TGB oil
temp
• Max/Min MGB oil press
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Descent/Approach/
Landing
Max lateral acceleration
Max longitudinal
acceleration
Max normal acceleration
Peak normal
acceleration on landing
Max/Min main rotor
speed power on
Max/Min main rotor
speed power off
Max torque
Max EGT
Max engine gas
generator speed
Max MGB/IGB/TGB oil
temp
Max/Min MGB oil press
OAT at landing
Landing weight
Fuel contents at landing
Max pilot workload/
turbulence
Wind speed/direction
Max increase in OAT
On Ground after Landing
• Max Deck Motion
Severity Index
• Max lateral acceleration
• Max longitudinal
acceleration
• Max main rotor speed
• Main rotor speed at rotor
brake application
• Max EGT at engine start
Section 4 Page 25
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
P
O
W
E
R
T
R
A
I
N
On Ground before
Take-off
• Max Deck Motion
Severity Index
• Max lateral acceleration
• Max longitudinal
acceleration
CAA PAPER 2002/02
25 September 2002
Table 4.4 HOMP Flight Data Measurements Grouped by Type and Flight Phase
Applicable Condition
Values
Pitch below 20ft AGL
Air
Max +ve, Min –ve
Pitch between 20ft and 500ft AGL
Air
Max +ve, Min –ve
Pitch above 500ft AGL
Air
Max +ve, Min –ve
Pitch below 90kts IAS
Air
Max +ve, Min –ve
Pitch above 90kts IAS
Air
Max +ve, Min –ve
Pitch rate below 500ft AGL
Air
Max absolute
Pitch rate above 500ft AGL
Air
Max absolute
Roll below 300ft AGL
Air
Max absolute
Roll above 300ft AGL
Air
Max absolute
Roll rate below 500ft AGL
Air
Max absolute
Roll rate above 500ft AGL
Air
Max absolute
Yaw rate
Air
Max +ve, Min –ve
Rate of Descent below 500ft AGL
Air (Individual phases)
Max
Rate of Descent above 500ft AGL
Air (Individual phases)
Max
Rate of Descent below 30kts IAS
Air (Individual phases)
Max
IAS above 500ft AGL
Air
Min
Lateral acceleration above 500ft AGL
Air
Max absolute
Lateral acceleration below 500ft AGL
Air
Max absolute
Longitudinal acceleration above 500ft AGL
Air
Max absolute
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 26
Measurement
CAA PAPER 2002/02
25 September 2002
Table 4.5 Listing of HOMP Flight Data Measurements
Applicable Condition
Values
Longitudinal acceleration below 500ft AGL
Air
Max absolute
Normal acceleration above 500ft AGL
Air
Max absolute
Normal acceleration below 500ft AGL
Air
Max absolute
Lateral cyclic control
Air
Max , Min
Longitudinal cyclic control
Air
Max, Min
Collective pitch control
Air (Individual phases)
Max
IAS at which IAS mode engaged
IAS at which ALT mode engaged
IAS at which HDG mode engaged
Air
Min
Min
Min
IAS
Air
Max
IAS below 100ft AGL
Air
Max
Main rotor speed above 10% total torque
Air
Max, Min
Main rotor speed below 10% total torque
Air
Max, Min
Total torque
Air (Individual phases)
Max
Increase in OAT
Air
Max
Ng engine 1
Air (Individual phases)
Max
Ng engine 2
Air (Individual phases)
Max
Engine gas temperature engine 1
Air (Individual phases)
Max
Engine gas temperature engine 2
Air (Individual phases)
Max
Ice detector
Air
Max
IGB oil temperature
Air
Max
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 27
Measurement
CAA PAPER 2002/02
25 September 2002
Table 4.5 Listing of HOMP Flight Data Measurements
Applicable Condition
Values
MGB oil pressure
Air
Max, Min
MGB oil temperature
Air
Max
TGB oil temperature
Air
Max
Pressure altitude
Air
Max
Pilot workload/turbulence (collective only)
Air
Max
Pitch
Ground
Max, Min
Roll
Ground
Max absolute
Main rotor speed
Ground
Max
Longitudinal cyclic control
Ground
Max
Longitudinal cyclic control rate
Ground
Max absolute
Lateral cyclic control rate
Ground
Max absolute
Motion Severity Index (excluding airports)
Ground
Max
Lateral acceleration
Ground
Max absolute
Longitudinal acceleration
Ground
Max absolute
Ground speed
Ground
Max
NMLA datum value
When calculated
Value
Fuel contents tank 1
At take-off
Value
Fuel contents tank 2
At take-off
Value
Fuel remaining tank 1
At landing
Value
Fuel remaining tank 2
At landing
Value
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 28
Measurement
CAA PAPER 2002/02
25 September 2002
Table 4.5 Listing of HOMP Flight Data Measurements
Applicable Condition
Values
Aircraft weight
At take-off
Value
Aircraft weight
At landing
Value
Rad alt at gear selected up
At gear up
Value
Rad alt at gear selected down
At gear down
Value
Normal acceleration at landing
At landing
Max
MR speed at application of rotor brake
MR brake applied
Value
Engine gas temperature, engine 1
At engine start
Max
Engine gas temperature, engine 2
At engine start
Max
Pitch rate, rig take-off
At rotation point
Max
Pitch, rig take-off
At rotation point
Max
Rad alt, rig take-off
At max pitch rate
Value
Ground speed, rig landing
Point before landing
Value
Ground speed, airport landing
Point before landing
Value
Pressure altitude
At take-off
Value
Pressure altitude
At landing
Value
OAT
At take-off
Value
OAT
At landing
Value
Average wind speed
Point after TO & before LDG
Value
Average wind direction
Point after TO & before LDG
Value
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Section 4 Page 29
Measurement
CAA PAPER 2002/02
25 September 2002
Table 4.5 Listing of HOMP Flight Data Measurements
Measurement Point
Comments
Measurements
RIG TAKE-OFF PROFILE
Take-off reference point
Time, Pressure Altitude, Latitude, Longitude
2 Rotation – Maximum Pitch Rate
Usually coincides with start of rotation
3 Rotation – Maximum Pitch Down Angle
Usually coincides with end of rotation
4 35 knots Airspeed
Lift-off point if airspeed greater than 35 kts
at lift-off
Time from Take-Off, Radio Altitude, Pressure Altitude
(AAL), Pitch, Roll, Heading, Airspeed, Groundspeed,
Latitude (N/S distance from take-off), Longitude (W/E
distance from take-off)
5 Vy (Climb Speed)
Obtained from Flight Manual
6 Gear Selected Up
End of take-off phase if gear not retracted
by then
7 200 Feet AAL
Definition of climb out path
8 500 Feet AAL
Definition of climb out path
9 1,000 Feet AAL
Definition of climb out path
RIG LANDING PROFILE
Section 4 Page 30
1 Touch-down
Landing reference point
Time, Pressure Altitude, Latitude, Longitude
2 35 knots Airspeed
Start of low airspeed phase
3 Gear Selected Down
Start of landing phase if gear already down
by then
Time to Landing, Radio Altitude, Pressure Altitude
(AAL), Pitch, Roll, Heading, Airspeed, Groundspeed,
Latitude (N/S distance from landing), Longitude (W/E
distance from landing)
4 1,000 Feet AAL
Definition of approach path
5 500 Feet AAL
Definition of approach path
6 200 Feet AAL
Definition of approach path
7 Maximum Pilot Workload
Workload based on collective only
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
1 Lift-off
CAA PAPER 2002/02
25 September 2002
Table 4.6 Additional HOMP Flight Profile Measurements
CAA PAPER 2002/02
Section 5
5.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP Trial Operational Experience
Project programme
The project started in January 1999. The initial phase, involving development and
production of the CQAR and also development and configuration of the HOMP
software, continued until August 1999. The CQARs were delivered at the end of
August and the gathering of flight data from the trials aircraft commenced in
September 1999. The operational phase of the trial was therefore considered to have
started on 1 September 1999, with the first year of trial operations continuing until 31
August 2000. The first release of the HOMP software was installed at BHL in
Aberdeen in early October 1999. This was followed by a period of system
commissioning, during which the performance of the HOMP software was assessed
prior to the trial going 'live'. All the flight data collected during the commissioning
period was analysed and reviewed, with one of the key tasks being to substantially
reduce the large number of "nuisance events" initially generated. The commissioning
period was completed in December 1999, at which time the trial was considered to
be ‘live’.
The initial period of the operational phase of the trial concentrated on the application
of the event detection process to the downloaded flight data. Work continued on the
specification of the flight data measurements during this period, and the release of a
new version of the HOMP software in early July 2000 enabled all the specified
measurements to be implemented. The configuration of the flight data
measurements was completed in September 2000, enabling the collection of
measurement data to commence.
A contract extension was granted to continue the operational phase of the trial for a
second year from 1 September 2000 to 31 August 2001. During this period there was
an increased emphasis on the generation of event trend information and on safety
management procedures for taking corrective actions based on HOMP events, then
monitoring the effect of these actions. Further HOMP software upgrades between
March and May enabled the manual allocation of severity levels to events and a
prototype severity scale was developed. The completion date of the trial was
extended to the end of October 2001 to enable the gathering of 6 months of trend
data for events with severity levels allocated. Development and refinement of the
HOMP events and measurements continued throughout the second year of trial
operations. A set of offshore take-off and landing profile measurements were
implemented towards the end of the trial. Archived HOMP data for the period
September 2000 to August 2001 was then reprocessed to generate a database of
measurements covering a one year period.
5.2
On-aircraft system
5.2.1
Aircraft installation
It was recognised that there were variations in the types of main gyros and radio
altimeters fitted to BHL's Tiger helicopters. To enable the correct FDR parameter
decodes to be configured for the trials aircraft, the specific aircraft that would be
included in the trial were identified, together with their equipment fits.
Once the necessary CQAR documentation had been received from BAE Systems, the
aircraft modification was completed and the modification kits built. The modification
25 September 2002
Section 5 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
was straightforward, with the CQAR being provided with a power supply and an
ARINC 573 input from the IHUMS DAPU. The kits were subsequently installed in the
aircraft, with the CQAR being mounted in the cockpit centre console.
The DAPU was powered from the battery bus and therefore acquired data whenever
there was power on the aircraft. It was recognised that the CQAR would be recording
data at the same time and would therefore record data during any overnight
maintenance work requiring power to be on the aircraft. The majority of the PCMCIA
cards used for the HOMP trial had a 20MB capacity, which equated to approximately
20 hours of data recording (some 48MB cards were also used). It was therefore
possible that, depending on how often a PCMCIA card was downloaded, occasionally
a card could become full and some flight data be lost. However, this did not occur
provided the cards were changed on a daily basis. All the data files generated when
there was power on the aircraft for maintenance work were deleted during the data
scanning process on the HOMP PC.
For future installations, the CQAR could be made to record data only when the rotors
are turning by utilising a ‘QAR enable’ input, for example connecting this to the right
hand hydraulic pressure switch (which is used for a similar purpose in the rotor brake
aural warning circuit). However, this would prevent any data recording during engine
starts. Although no starting problems were encountered during the trial, one of the
benefits of a HOMP is its ability to monitor “one-off” events, therefore it is
considered useful to be able to monitor engine starts. If the CQARs are used for
combined HUMS and HOMP data recording the PCMCIA cards will be inserted and
removed by pilots before and after flights, which will eliminate the problem of filling
the cards with data acquired during maintenance in the hangar. Therefore there are
currently no plans to utilise the ‘QAR enable’ input.
Early trial experience showed that FDT had to cope with a large amount of ‘bad data’
as a result of spurious outputs from the aircraft DAPU when some sensors or
systems were not powered up (e.g. pitch and roll gyros when AC power was off). The
DAPU outputs were investigated to determine whether there were any parameters
which could be used to determine when sensors or systems were off-line. It was
confirmed that there was no discrete to indicate whether the 26V instrument supply
transformers had been selected on. One proposal was to use a transistor switch to
toggle a normally inactive discrete such as 'Battery Hot' to indicate the presence of
26V AC on the instrumentation bus. However the requirement for any such aircraft
modification was to be avoided if at all possible as the philosophy of the trial was to
have a minimum impact on the aircraft. The preferred solution was to trap bad data
produced by off-line sensors within FDT and, with the subsequent enhancements
made to FDT, false events caused by sensors or systems which were off-line became
an infrequent occurrence.
5.2.2
CQARs
The CQARs were delivered at the end of August 1999 and operated correctly from
first installation in the aircraft. It is estimated that, during the two years of operations,
a total of 13,500 operating hours were accumulated on the five units. Both the CQARs
and PCMCIA cards proved to be very reliable with very few problems being
encountered.
One CQAR was damaged due to incorrect insertion of the PCMCIA card, which
resulted in this becoming jammed in the unit. The CQAR was returned to BAE
Systems for repair, where it was found that the card jam and CQAR damage had been
caused by the card being inserted upside down and then forced in. This was the only
known incidence of an incorrectly orientated card insertion causing a problem. By the
end of the two year period of operations only one PCMCIA card had failed as a result
25 September 2002
Section 5 Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
of damage. Three others showed some evidence of crush damage, but were still
functional.
Due to the tolerance in the CQAR card guides, some difficulty was occasionally
encountered when attempting to insert a PCMCIA card. BAE Systems have
subsequently modified the card guides to eliminate the problem.
One minor problem initially encountered was that, occasionally, a PCMCIA card was
found to have a corrupted file allocation table. It was noted that the corruption only
occurred if the cards were full. When the cards were changed on a daily basis no
further problems occurred. BAE Systems identified a software bug and produced a
modification to correct this. One CQAR was returned to BAE Systems for a firmware
update in May 2000 to incorporate the QAR bug fix. Although not part of the HOMP
trial, the opportunity was taken to install IHUMS Maintenance Data Recorder (MDR)
software at the same time. The MDR functionality was to enable the future storage
of HUMS data files on the CQAR and should have had no effect on the HOMP.
However, when the CQAR was returned to BHL and installed in an aircraft, an 'MDR
fail light' illuminated. The unit was returned to BAE Systems, where it was confirmed
that the illumination of the MDR fail light had been caused by a hardware fault.
The HOMP trial was stopped in September 2000 for what was intended to be a two
week period to enable the remaining CQARs to undergo the firmware update,
however it was a month before the CQARs were returned. All units functioned
correctly upon re-installation.
Occasionally a CQAR file was found to have been closed part way though a flight and
a new file opened. This created problems during the data replay as information on the
affected flight was split over two files. The cause of the ‘split files’ was believed to
be the CQAR opening a new file following a loss of synchronisation after the receipt
of bad data frames from the DAPU. The rate of occurrence of split files was quantified
as 1.7 per week (there were 15 occurrences of file breaks in the 9 week period from
3/2/00 to 5/4/00). Whilst losing the small amount of data associated with the split files
was not significant, they did create some difficulties with the data analysis. To
overcome the problem, BHL produced a small program to re-join split files before
these were scanned by FDT. Although no explanation for it was given, the
occurrence of split files virtually ceased following the CQAR firmware update in
September 2000.
During a period of monitoring data recovery rates it was found that, occasionally (i.e.
typically once every two weeks), the CQAR failed to record a data file. When a case
of a missing file was investigated it was found that no IHUMS data had been recorded
on that flight, thus there had been nothing for the CQAR to record. Unfortunately,
occasional missing IHUMS downloads were not logged or investigated as they only
occurred infrequently and had many potential causes (e.g. a DAPU, MDR, or card
problem, or a card not being inserted). Therefore no single cause of the occasional
missing CQAR files could be identified.
5.2.3
Data collection
A total of approximately 11,500 hours of data was gathered between early September
1999 and the end of August 2001. This included the time the aircraft were poweredup by flight crew before or after a flight.
A very good data collection rate of between 90 and 95% was achieved, excluding the
periods when one CQAR was undergoing repair, and when all the CQARs were
having a firmware update. These exclusions were justified as, in order to collect the
maximum amount of data, a deliberate decision was made to utilise all the CQARs
purchased for the trial, and operate without any spare units. When a loss of data
25 September 2002
Section 5 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
occurred, this was generally because of a failure to change the PCMCIA cards before
they became full (especially over the weekend), or because of the limited fleet fit. For
example, if one of the aircraft participating in the HOMP trial was sent to Scatsta or
returned to Aberdeen (which could happen at short notice), it was necessary for
personnel to remember that it was a HOMP aircraft, transfer the PCMCIA cards
between the locations, and start changing the cards daily at the new location. When
aircraft went into the hangar for heavy maintenance, which could last several weeks,
it was again necessary to remember to re-start changing the cards once the aircraft
was back on line. Typically this did not happen without the intervention of the HOMP
Manager.
Any or all of the following options would further improve the data collection rate:
• Use PCMCIA cards with a capacity of more than 20MB (some 48MB cards were
introduced in the second year of the trial).
• Adjust the installation modification to utilise the QAR enable pin to record data only
when rotors are turning (but this would prevent recording during engine starts).
• Fit the entire fleet with CQARs so that downloading the cards becomes a routine
action.
• Combine HUMS maintenance data recording with HOMP data recording using the
CQAR only. This would ensure that data is downloaded by aircrew after each flight,
which is a requirement for compliance with current CAA legislation for HUMS. This
is the long term solution which is likely to be implemented by BHL.
During the two year trial, only a single instance was identified of a pilot removing a
PCMCIA card during rotors running after realising that he had just done something
likely to trigger a HOMP event. Fortunately, the relevant data had already been
captured and the event was subsequently detected by the HOMP system.
A number of defects in the acquired flight parameters were noted during the trial.
Detecting these defective parameters was a real benefit of the HOMP as rectification
work could then take place, significantly increasing the probability that all FDR
parameters would be available if needed for their primary function of incident/accident
investigation. In the absence of a HOMP, FDR parameters are only required to be
checked once per year. In addition, a number of these parameters had intermittent
faults which may not have been detected during the annual check.
Towards the end of the trial the PCMCIA card reader ceased to function in the data
collection PC at Scatsta. This coincided with the installation of additional printer driver
software on the machine. With no dedicated computer support at this remote base,
rectifying the problem was not straightforward and approximately one week of data
had been lost by the time this was resolved.
5.3
HOMP software
The BASIS FDS, FDE and FDM software modules had previously been used by BA
for their SESMA programme. FDT was a new module and the HOMP trial was the
first application of it. It was also the first application in which FDT was integrated with
the FDS, FDE and FDM modules. The HOMP software was subject to continuous
development and improvement throughout the trial. A brief development history is
given below, the reasons for some of the developments are explained in the following
sections.
25 September 2002
Section 5 Page 4
CAA PAPER 2002/02
5.3.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Software development history
To support the initial development and testing of the HOMP software prior to the
installation of the CQARs, flight data was downloaded from the flight data recorders
installed in two BHL Tiger helicopters. Some problems were encountered with
inconsistencies in the aircraft documentation specifying the FDR parameter decode
equations, which hampered the implementation of the flight data decoding in FDT.
A preliminary release of the HOMP software was installed at ES-S in August 1999 and
evaluated using the downloaded FDR data. The first full release (version 1.0) of the
software was installed at ES-S in September, where it was tested using CD's of
CQAR data sent from BHL. Version 1.0 of the HOMP software was then installed at
BHL in Aberdeen at the beginning of October 1999. Software development
continued, with improvements being implemented in response to operational
experience gained during the trial. There were eight new software versions during the
two years of trial operations, some incorporated minor improvements whilst others
introduced significant new functionality:
• Version 1.1, issued in November 1999
• Version 1.2, issued in November 1999
• Version 1.3, issued in January 2000
• Version 1.4, issued in July 2000
• Version 2.1, issued in March 2001
• Version 2.2, issued in May 2001
• Version 2.3, issued in May 2001
• Version 2.6, issued in September 2001
Some of the functionality improvements are listed below, further explanation of the
reasons for them is given in Sections 5.4 and 5.5.
5.3.1.1 Improvements to system administration and data handling
Automatic re-naming of the CQAR files downloaded from the PCMCIA cards into the
following format: fleet-registration-date-time-number.dat. The file names (QARx.dat
where x is an incremental number) and dates (01-01-1980) generated by the CQAR
provided no information on the origin or time of creation of the data files.
Improved file handling, automatically transferring the many "on-ground - no engines
running" files to a "delete" directory, the "on-ground - engine running" files to a "no
event" directory and all "flight" files to the "flight data" directory. This modification was
required to eliminate the large number of CQAR files created when aircraft power
was on during maintenance in the hangar.
5.3.1.2 Improvements to data analysis facilities
Provision of a facility to import flight information from BHL’s Operations database,
and reference imported flight information (see Section 5.4.3.2).
Incorporation of a status box and notes field for each file in the main browse list (see
Section 5.4.3.5).
Incorporation of a day/night derived parameter and event tag (see Section 5.4.3.4).
A modification to chain together multiple events of the same type which occur within
a configurable time period of each other. This modification prevented the generation
of large numbers of events when a parameter value was close to the event limit,
causing frequent exceedances.
25 September 2002
Section 5 Page 5
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The inclusion of more complex and generic functions for derived parameter
calculation, with the ability to calculate one derived parameter from another. This
enhanced the capabilities and flexibility of the HOMP data analysis and was required
to enable the implementation of some of the more complex events and
measurements which had been specified.
Redesign of the collection of measurement data to improve the flexibility of what
could be measured, including support for conditional measurements. This enabled
the implementation of all the specified flight data measurements.
Implementation of a digital filter for use in derived parameter calculations. This
enabled the implementation of a BHL-specified turbulence measurement based on
multiple rapid collective control movements (see Section 5.4.1.4).
Incorporation of a facility within FDE for the manual allocation of severity levels to
events, or for entering user defined equations for the automatic calculation of severity
levels (see Section 5.4.3.9).
As an alternative to the above, addition of a capability to manually allocate event
severity levels within FDT, and then export these to FDE (see Section 5.4.3.9).
Creation of the ability to export user defined information from FDT to FDE and to use
this information for filtering and trending events within FDE. User defined information
which was exported included; take-off type, landing type, flight type, base
identification, number of passengers, pilot and co-pilot code numbers and any event
severity levels which were manually allocated in FDT (see Section 5.4.3.2).
5.3.1.3 Compensation for aircraft system problems
Inclusion of a configurable airframe-specific correction to the transition of the groundair logic to accurately locate the take-off point. This was required to compensate for
a delay (which varied between aircraft) in the transition of the weight-on-wheels
discrete from ground to air.
Improvements to the ‘bad data’ correction process, and preventing the processing of
events on corrected data. The modifications were designed to overcome the “bad
data” problems described in Section 5.2.1.
Provision of an ability to stop event processing a certain time before shutdown.
Together with the above item, this prevented spurious events from being generated
by stopping event processing prior to any reduction in main rotor speed prior to
shutdown which caused some sensors or systems to go off-line.
Incorporation of a trap for any large numbers of events that were generated as a result
of an aircraft sensor problem. An error log entry was created if the maximum number
of events limit had been exceeded.
5.3.2
Experience with the HOMP software
The functionality of the FDT module improved dramatically during the operational
phase of the trial and by the end of the trial it was very well matched to the HOMP
requirements. Support from BA was very good, with nearly all the requests made for
additional functionality being actioned.
Processing speed was satisfactory with a P3 550MHz computer and the program very
rarely experienced any problems with individual data files during unattended bulk
processing. Replay time was dependent on factors such as the size of the data file,
the number of events and measurements implemented, the number of flight sectors
contained in the file, and the number of events generated. The ‘worst case’
processing rate, with all the measurements implemented (including the additional
25 September 2002
Section 5 Page 6
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
flight profile measurements), was approximately 100x real time, i.e. 36 seconds to
process 1 hour of flight data.
Configuration of derived parameters, events and measurements within FDT was
considered to be something of a specialist task that required some initial training.
With the introduction of a number of new software versions, the complexity of the
FDT module increased somewhat during the trial.
The FDS simulation program proved to be very useful. It was used routinely for
visualising flights for investigation purposes, and was a valuable aid for debriefing
aircrew, either on the HOMP PC or remotely by sending data on a floppy disk.
By the end of the trial the FDE module had good functionality and was able to
generate a range of useful trend charts, utilising new functions such as the importing
of flight operations data. Little use was made of the facility to review the flight data
associated with an event within FDE. Whilst necessary for a networked system in a
large organisation such as BA, this was not found to be needed in the HOMP trial’s
single user system, where all investigations were carried out within FDT.
The BASIS FDM module was useful for routine analysis tasks such as the viewing of
parameter histograms when adjusting event limits. However, MS Access and Excel
were used to perform more sophisticated analyses. The module did not allow general
browsing of the underlying measurements database, for example to determine the
value of a particular measurement for a particular flight and, again, MS Access was
used for this purpose. The link between FDT (where the measurements were made)
and the FDM module had some limitations and did not allow, for example, re-scanning
of a file if a problem was encountered during first scan process (e.g. no matching
operations data). To allow the import of re-scanned data, the original data had first to
be manually deleted from FDM using MS Access or Excel.
5.4
HOMP analysis
5.4.1
HOMP event analysis
The first project steering group meeting in January 1999 included a ‘brain-storming’
session to generate an initial specification of the helicopter events to be applied in the
HOMP trial, based on a review of the following information:
a) The events used in the initial data analysis work reported in CAA Paper 97005
(Reference [8]).
b) The events used by BA on their B757 fleet.
c) The parameters recorded in the FDR data frame of BHL’s Tiger helicopters.
d) A selection of helicopter operational occurrences extracted from an output from
the CAA SDD database (Reference [10]).
A list of the helicopter events which were implemented in the HOMP trial is
presented in Section 4.4.
5.4.1.1 Reduction of false and nuisance events
When the events and event limits initially specified were first applied an average of
approximately 200 events were generated from each data file analysed. In a typical
week of the trial approximately 5 significant events were generated from the
processing of 50 data files. Therefore approximately 99.95% of the events generated
at the start of the trial were classed as false or nuisance. During the commissioning
25 September 2002
Section 5 Page 7
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
phase as many as possible of the false events were eliminated and the number of
nuisance events generated was also substantially reduced.
False and nuisance events continued to be reduced during the early part of the trial
by the ongoing refinement of event definitions and limits, and also by improvements
in the bad data detection and correction process. By the end of the trial, only about
90% of the events were classed as false/nuisance. Although this may still appear
high, it equates to only one or two false/nuisance events per data file analysed.
Approximately one third of the data files scanned generated no events and, of the
rest, most had only two or three. There were also probably more significant events
being generated at the end of the trial as a result of the development of better
targeted event algorithms. When a trace generated a large number of events, this
was normally either a training flight or the result of an FDR parameter defect, where
there were usually multiple instances of the same event. It was necessary to filter out
or eliminate such events to prevent these from distorting event statistics.
Some specific event problems and corrective actions are identified below:
• 08A/C (rate of descent): False events were triggered by a dip in pressure altitude
values just before landing, due to the ground cushion effect. The problem was
eventually cured by stopping event processing at a certain radio altimeter height
above, pressure altitude difference from, and time before, landing. However, a
number of nuisance 08A/08C events continued to be triggered, indicating a need
to review and adjust the event limits. Modified limits were established using the
database of flight data measurements, which substantially reduced the nuisance
event rate. However, as a high rate of descent was not necessarily a safety issue
and its significance depended on circumstances, some nuisance events had to be
tolerated.
• 29A/B, 30A (pitch/roll attitude on ground): Events were triggered just before takeoff due to a delay in the transition of the weight-on-wheels discrete from ground
to air. The problem was overcome by including a configurable aircraft-specific
timing correction for the weight-on-wheels transition (see Section 5.3.1.3).
• 29A/B, 30A, 34A/B/C (pitch/roll attitude and cyclic control on ground): Spurious
events were generated during post flight engine washes when the main rotor
speed was reduced and the alternators went off-line. A minimum main rotor speed
condition was introduced together with a ‘stop processing’ condition to stop event
processing before an engine wash (see Section 5.3.1.3).
• 35A/B (movement of deck): The deck motion severity index (MSI) limit was being
triggered during taxiing at airports (the event was only relevant to floating
platforms and vessels). An additional condition was introduced to only apply the
event if the location was not an airport, as determined from the GPS lat/long data.
The bad data checking process prevented the event from triggering if the GPS lost
its configuration and could no longer identify an airport landing. A few MSI events
continued to be triggered on decks, for example due to the fact that the helicopter
was not sitting parallel to the deck. The limit applied to the MSI parameter was
conservative as the event did not take wind speed into account, and MSI-based
deck motion limits varied with this.
5.4.1.2 Review and refinement of events
After the first year of HOMP trial operations a review of the HOMP events was carried
out to identify requirements for refinements, either by modifying the event logic
(including the parameters used), or by changing the event trigger limits. A statistical
analysis of the events which had been generated was used to identify both the events
which were being triggered too frequently and also any events which were not being
25 September 2002
Section 5 Page 8
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
triggered at all. Where a requirement for changing an event limit was identified, the
database of flight data measurements was used to help to set the new limit.
Of the 85 events implemented, 21 were modified following the review. A summary
of these modifications is given below:
• 10 events had trigger limits increased to reduce their rate of occurrence (events
were considered to be triggering inappropriately during normal operations).
• 1 event had the duration increased for which the event limit must be exceeded
before it was triggered.
• 4 events were found not to be triggering. As a result, 3 events had trigger limits
reduced to increase the likelihood of them being triggered. For 2 of the 3 events,
the event logic was also modified. The remaining event was redefined using
different parameters.
• 5 events had condition limits changed to modify the conditions under which the
events were being tested for. 1 event had a new condition added.
During the review, the purpose of Event 20A (excessive heading change immediately
after an offshore take-off) was questioned. The event was amended so that it was in
accordance with BHL’s Operations Manual which stated that, at night, a height of
deck height plus 200 feet, and an airspeed of 70 knots, should be achieved before a
turn is initiated.
In order to verify the correct operation of all events following configuration changes,
or the release of a new version of the HOMP software, a set of test data known to
trigger events was created. This data could be used to test that all events were
working.
5.4.1.3 Allocation of severity levels to events
Whilst FDE automatically calculates severity indices for the fixed wing events in BA's
SESMA programme, the calculations were not applicable to the helicopter events
implemented in the HOMP trial. The nature of the helicopter events experienced
suggested that calculating severity indices in a similar manner to those for fixed wing
events would be difficult and inaccurate. There was not always a good correlation
between helicopter event types and the operational occurrences detected, and the
significance of events could be very dependent on environmental factors such as
weather.
As a result of the above factors, for the HOMP trial it was necessary to manually
allocate severity levels to events (see Section 5.3.1.2). BHL’s HOMP Manager
recommended that a numerical severity level between 0 and 10 be manually allocated
to each event, and developed the prototype severity scale shown in Table 5.1 for this
purpose.
25 September 2002
Section 5 Page 9
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Table 5.1 BHL’s Event Severity Guide
Severity
Significance of Event
0
No significance
1
Contrary to operational or flight manual procedures or limits but no
actual safety risk
2
Slight risk of problem if combined with several other factors
3
Risk of problem if combined with other factors
4
Slight risk of problem as a stand-alone event
5
Significant risk of problem as a stand-alone event
6
Serious risk of incident
7
Minor incident occurred
8
Moderate incident occurred
9
Major incident occurred
10
Accident occurred
The numbers in the severity scale were defined in terms of the potential erosion of
helicopter operational safety margins and the same assessment criteria were applied
to all events. Severities could be increased or decreased by one step to reflect a
particularly serious or minor case of a particular category. Nuisance events were
allocated a severity level of 0 to enable these to be separated from the genuine
events within FDE.
Consideration was given to the allocation of severity levels to an occurrence that
triggered multiple events of different types. One potential method would be to create
a new user defined ‘composite’ event. The severity of the occurrence would then be
assigned to this composite event and the component events would have severity
levels allocated which are appropriate to each of them individually. A more robust
approach would be to program a new event into the HOMP system based on the
combined logic of the events which had triggered.
5.4.1.4 Future developments
Initial attempts to develop a ‘turbulence’ event based on either normal 'g' (sampled
at 8Hz), or lateral ‘g’ (sampled at 4Hz) proved to be unsuccessful. The most important
effects, however, are loss of lift and the pilot workload created by turbulence, which
can potentially be detected by monitoring collective and cyclic control movements.
For the HOMP trial, BHL implemented an ‘uncalibrated’ turbulence indicator based on
the detection of multiple rapid collective movements using a high pass filter - rectify
- low pass digital filter process (see Section 5.3.1.2). This was shown to correlate well
with pilot submitted turbulence reports.
The CAA is developing a turbulence criterion for inclusion in CAP 437. The underlying
assumptions for this work are that flight safety is inversely proportional pilot
workload, and that pilot workload can be correlated with control activity. Earlier work
using QinetiQ’s Advanced Flight Simulator (AFS) at Bedford had demonstrated good
correlation for a series of stylised military manoeuvres, and established a set of pilot
workload predictors. The workload predictors are calculated from collective and cyclic
control measurements and are calibrated to the Cooper-Harper rating scale for aircraft
25 September 2002
Section 5 Page 10
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
handling qualities. Since the nature of the task of stabilising a helicopter in a turbulent
wind environment is fundamentally different to that of flying a manoeuvre, it had
always been expected that a different set of predictors would be required. The
original military-based workload predictors were, nevertheless, prototyped in the
HOMP system with a limited degree of success. Further trials using the AFS have
been undertaken to generate a new set of predictors tuned to the task of controlling
the helicopter in the presence of turbulence. When available, these predictors are
expected to provide a reliable and robust measure of pilot workload that can be
related back to the turbulence criterion that is to appear in CAP 437. The data from
these trials will also be used to calibrate the BHL turbulence indicator.
New HOMP events for monitoring operations in critical low airspeed regimes could
be developed if an algorithm to accurately infer low airspeed information from other
flight data parameters can be successfully produced and demonstrated (see Section
5.4.3.6).
5.4.2
HOMP measurement analysis
Once the event analysis was performing satisfactorily, attention turned to the flight
data measurements. The final specification of the measurements to be implemented
in the HOMP trial was agreed at a project steering group meeting in April 2000 (these
are listed in Section 4.4). The functionality required to implement the measurements
was provided with the release of version 1.4 of the HOMP software in July 2000 and
all the specified measurements had been configured by September. Some further
measurements were later added and, by the end of the trial, 140 different
measurements were being made on each flight sector. A minor software update was
required to provide an additional function for the calculation of two measurements
needed to “map the helideck environment”, and this was accomplished in March
2001. By the end of October 2001 measurements from 5200 flight sectors had been
stored in the FDM database.
The measurements proved useful when adjusting event thresholds as their mean
values and variability gave an indication of normality. The event threshold could then
be set to an appropriate number of standard deviations away from the mean. The
measurement database could also be ‘mined’ to test hypotheses, or to support the
investigation of event trends.
Additional measurements were added to gain information about the vertical profile of
approaches flown during night operations to offshore helidecks. This information was
used to assist in a CAA helideck lighting project to enable the lighting system
specification to be optimised.
By the end of the trial a significant amount of data existed for the turbulencegenerated pilot workload event. This could be plotted for a particular offshore
installation, along with measured wind direction and strength on final approach, to
give an indication of problem wind sectors at the location (i.e. mapping the helideck
environment). With the limited number of participating aircraft, by the end of the trial
the data for a particular installation was still limited, but with time the data sets will
become better populated. However this data can only be used for fixed installations
as the orientation of movable platforms varies with time.
At the end of the project, after the trial had been completed, ES-S implemented a
further 150 offshore take-off and landing profile measurements and reprocessed one
year of archived flight data with all 290 measurements applied. The measurement
database produced included over 7,900 flight sectors.
25 September 2002
Section 5 Page 11
CAA PAPER 2002/02
5.4.3
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Information to support the HOMP analysis
Early HOMP experience identified requirements for a number of additional items of
information to support the data analysis process and aid the interpretation of events.
This section summarises the key items of information identified.
5.4.3.1 Departure/arrival locations
It was necessary to identify the departure and arrival locations for all sectors flown;
the large majority of these locations were offshore installations. BHL provided a
locations table, identifying the names and latitude/longitude of all the airports and
offshore installations to which they flew. This was used by FDT as a look-up table to
automatically identify departure/arrival locations based on GPS data. As some of the
offshore platforms were mobile, there was a need to keep the locations database up
to date to enable these to be correctly identified. There would also be a need for time
dependent database entries if old data is re-processed by FDT, but this was not
implemented.
5.4.3.2 Flight operations information
Access to flight operations information such as aircraft take-off gross weight, number
of passengers on board, type of flight (e.g. revenue, training, air test), base
identification, and crew identities (suitably encrypted), was vital to the event
interpretation and follow-up process. BHL provided a method of extracting the
information from their Operations database. FDT was developed to import this
operations data file, match it to the files of downloaded flight data, and utilise the
operations data in the event analysis (see Section 5.3.1.2). Subsequent experience
clearly demonstrated the value of this facility. Other modifications allowed the
operations data to be exported to FDE along with event data in ‘user-defined fields’.
The information could then be used for event filtering and trend analysis in FDE, for
example, enabling training and test flights, or flights with no passengers, to be filtered
out when producing event trend displays.
5.4.3.3 Weather information
Access to archived weather information was needed as there was often a weather
factor in HOMP events. BHL stored all offshore installation weather reports in their
Operations database. However it proved very difficult to obtain archived onshore
weather data (Metars), so BHL produced a small program that automatically
downloaded the Metars for selected airfields from the Met Office web site once per
hour, and stored them in a database.
5.4.3.4 Day/night condition
In determining the significance of events, it was important to know whether these
occurred in daylight or darkness, as there could be differences between day and night
operating procedures. An algorithm was therefore implemented in FDT to enable a
day/night flag to be set for any event generated (see Section 5.3.1.2).
5.4.3.5 Status indicator and notes field
To aid the process of reviewing scanned data files in FDT, a status indicator was
added to the main browse list to show which files had been reviewed and a notes
field was added to each record to allow notes on findings to be written and stored
with the data files. These features proved to be very useful (see Section 5.3.1.2).
5.4.3.6 Low airspeed measurement
Although the HOMP trial event analysis proved to be very successful, a capability for
low airspeed measurement would add significant value to the HOMP. The
information could, for example, be used for new events related to time spent in the
25 September 2002
Section 5 Page 12
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
height-velocity diagram ‘avoid areas’, or proximity to a ‘vortex ring’ state, or for new
measurements related to take-off and landing exposure times. However, fitting low
airspeed sensors to all aircraft, then calibrating and maintaining them, would be
expensive and impractical. A more feasible solution is to attempt to synthesise low
airspeed from the existing FDR parameter set using artificial neural networks (ANNs)
or other techniques. Westland Helicopters have been contracted by the CAA to
attempt to develop and demonstrate a suitable algorithm. If the work proves
successful, the low airspeed algorithm will be implemented in the HOMP analysis
software in the form of a derived parameter at a future date.
5.4.3.7 Flight sectors data
FDE needed data on the total numbers of sectors flown to calculate event rates (i.e.
events per 1,000 sectors flown) for trend analysis. This required a separate process
to generate a sectors file from BHL’s Operations database and import it into FDE. To
eliminate the requirement, FDT could automatically generate flight sectors data and
export this to FDE with the event information (to calculate events per 1,000 sectors
analysed), however this was not implemented during the trial.
It was also useful to monitor the data collection rate from the HOMP aircraft, i.e.
processed versus actual flights. This information could be used to maximise the data
collection rate and give early warning of poor performance, either of the project in
general, or of one particular operation or aircraft. This was not implemented within
FDT, but BHL produced a small program that listed any flights on their Operations
database that had not been processed by HOMP. The program could also
automatically generate a percentage data collection rate between two given dates.
5.4.3.8 Raw data associated with an event
Once an event was imported to FDE, it would have been necessary to be able to
review the raw data associated with it if severity levels were to be allocated within
this module. There was no common reference number in FDE and FDT which could
be used to identify the relevant FDT file associated with an event in FDE and, after a
certain period of time, the original file may have been deleted or archived. Although
not an issue for the HOMP trial, the potential difficulty was overcome with the
introduction of FDV, which enabled cut sections of a trace associated with an event
to be accessed directly from FDE.
5.4.3.9 Event severity levels
To perform meaningful event trend analysis it was necessary to allocate severity
levels to events so that trends of cumulative severity levels, rather than simple event
numbers, could be produced. For the HOMP trial the only feasible option was to
manually allocate these severity levels. Modifications enabled a numerical severity
level of between 0 to 10 to be allocated to each event within FDT, and then exported
to FDE (see Sections 5.3.1.2 and 5.4.1.3).
5.4.3.10 Analysis configuration control
Configuration control is an important aspect of the HOMP analysis. Whilst it could be
performed manually, ideally facilities should be provided for automatically recording
configuration changes and identifying any relevant changes during trend analysis. FDT
maintained a log of changes to event definitions and limits, however no information
on limit changes was exported to FDE, and FDE could not identify that changes had
taken place when displaying trends of events in different time periods. A replay
version number and date could be incremented when events are changed, and then
exported for the annotation of event trend plots in FDE, however this was not
implemented.
25 September 2002
Section 5 Page 13
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
5.5
HOMP operational and management experience
5.5.1
Programme workload, resources and facilities
Workload was high during the early stages of the trial as a result of having to process
the incoming data whilst also managing changes to the system (bug fixes, event
refinements etc.). Workload soon eased for routine download and analysis, with
routine programme tasks typically taking about one hour per day. However, without
an assistant, work could quickly accumulate during periods of leave etc. Investigating
significant HOMP events could be time consuming, as could various other duties
such as producing newsletters, or analysing BASIS FDE and FDM data. Workload is,
to some extent, a matter of choice – but the more time allocated to the programme,
the greater the benefits that are likely to accrue.
The trial confirmed that starting with a small number of aircraft was the correct
approach, as this enabled events and procedures to be refined before the
commencement of any large scale data gathering. It is essential to reduce false event
occurrence rates to a low level at an early stage to avoid being overwhelmed by them.
Once this had been achieved, the trial identified no major obstacles to a large scale
implementation.
A recurrent problem faced by the HOMP Manager was the conflict between flying
duties and the requirements of running the programme. The conflict arose because,
in order to maintain the HOMP’s credibility with aircrew, it was necessary to use a
qualified pilot to manage the programme. However, such personnel are expensive
and the exact number required to fulfil a charter company’s contractual obligations is
difficult to predict, whilst there is a long lead time in training new personnel. When
there was an upturn in flying activity, Operations management were naturally
reluctant to agree time off flying duties if the HOMP Manager was needed to meet
the company’s contractual flight requirements. It is difficult to suggest a solution to
this problem, but it is probably the most significant issue likely to prevent a
programme from being effective or, in an extreme case, to cause the programme to
fail. It is probably the case that the smaller a company, the more prevalent this
problem will be and, to ensure the HOMP’s effectiveness, a workable solution must
be found. This might be to involve additional personnel in the programme so that
backup can be provided for the HOMP Manager when necessary, or to contract out
some routine tasks.
The trial demonstrated the importance of having appropriate office facilities for the
programme. Because of the sensitive nature of information held it is essential that
adequate security is provided for the HOMP computer and any associated paper
records. Facilities must also be provided for confidential phone calls and debriefs. The
location of these should ideally be reasonably close to the flight planning area but not
so close that crews can readily be seen entering and leaving by other pilots, or that
conversations are likely to be overheard.
5.5.2
Programme agreements
For the trial no formal agreement was put in place between the company and the
aircrew, but a “statement of intent” was published by the HOMP Manager. Prior to
a fleet-wide implementation it will be necessary to have an agreement between
management and aircrew, specifying how HOMP data can be used, and no obstacles
to this were identified.
Where, in an airline such as BA, aircrew are fully unionised, the best approach is to
implement a written agreement between the company management and the aircrew
union (i.e. BALPA). BHL had only a limited relationship with BALPA, and a significant
25 September 2002
Section 5 Page 14
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
minority of the company’s pilots were not members of the union. Therefore, in this
case, BALPA could not be used to fulfil the same representative role as in BA.
However, as a result of a combination of their flight data monitoring experiences at
BA and BHL’s non-punitive management philosophy, BALPA were very supportive of
the introduction of the HOMP.
To ensure that there was no inappropriate access to, or misuse of, any of the flight
data obtained during the trial, confidentiality agreements were drawn up between
BHL, Shell Aircraft and the CAA. The agreement with the CAA was based on their
existing confidentiality agreement with BA. A non-disclosure agreement was also put
in place between BHL and ES-S.
BHL’s relationship with its customers is very different from that of an airline, as these
are almost exclusively large oil companies which have their own aviation
departments. This results in a much closer relationship with the customer on
technical and safety issues than would be the case with an airline, and hence a higher
probability of a customer expecting to have access to any sensitive HOMP-derived
data. For a full scale HOMP implementation, contracts and confidentiality agreements
may require modifying so that all parties are clear on the requirement to maintain
confidentiality. In particular, operators may need to include clauses in contracts with
their charterers that specifically preclude the release of any HOMP data to them,
except with the permission of all members of the flight crew. However, a charterer
may wish to specify a safety measure derived from the data as a quality check.
5.5.3
Programme operation and management
The HOMP trial raised a number of operational issues for which there was no clear
guidance to the crew, and it was necessary to decide whether any problem existed
and, if so, whether additional guidance should be introduced. Whilst it was clearly
beneficial to raise these issues for discussion, when considering changes to an
already safe system (i.e. helicopter transport), it was necessary to be careful not to
take action which could ultimately reduce overall safety in some subtle way. For
example if, because of the HOMP, crews felt unable to use the full flight envelope of
the aircraft when no passengers were carried, over time their experience of this
envelope would diminish. In an emergency, their response may then be affected as
a result of operating outside their personal flight envelope, and the likelihood of a safe
outcome could be reduced.
For the trial, BHL did not formally include the HOMP in their safety management
process (this will happen as part of a full scale implementation of the programme).
However, the HOMP Manager held meetings with training and safety staff to discuss
certain incidents and, in some cases, action was taken to modify procedures. The
responsibility for carrying out these actions lay with management and training staff,
with the HOMP Manager’s role being to provide recommendations.
The HOMP was highly successful at detecting a variety of potential safety issues.
Sometimes these related to individuals or to procedures, but the HOMP was also a
powerful tool for detecting general issues with a particular operation. However,
detection of a safety issue is only the first step, remedial action may then need to be
taken and this can be much more challenging, especially if it relates to human factors
and cultural differences. For example, there is a unique culture associated with small
satellite bases which appears to be common throughout the aviation industry. These
satellite bases can have the view that procedures are too rigorously applied at the
main base, and may consider themselves to operate more efficiently. There may be
a belief at these bases that it is better to do things differently, however this can result
in more mistakes being made. Tackling such cultural issues is very difficult as they
will probably have been present for many years and a heavy-handed approach is
25 September 2002
Section 5 Page 15
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
unlikely to succeed. The best solution is a gradual inculcation of attitudes. This will be
more easily achieved once the HOMP is fully implemented.
The trial highlighted the importance of the HOMP Manager’s role in achieving a
successful programme. The HOMP must be run by an experienced pilot rather than
a non-pilot manager. Whilst pilots are likely to be receptive to observations from their
peers, they would not accept suggestions from personnel with no flying experience.
The HOMP Manager must have a high degree of integrity and be trusted by his fellow
pilots. Robust confidentiality is essential, and management must allow him a degree
of independence and rely on his judgement as to what action, up to removal of
anonymity, is appropriate. A HOMP must not be seen as a punitive management tool
– it cannot function without the co-operation of the pilots. Management must,
however, give the HOMP Manager every support, including making time available
from flying duties and listening to his concerns on operational issues.
5.5.4
Feedback to aircrew
Obtaining a good response from aircrew to the HOMP was an important element of
the trial. Aircrew are aware that they will be the natural focus of attention if anything
goes wrong, and so can be understandably defensive. It is therefore important to
demonstrate to aircrew that the programme has some benefits to offer them. If their
first encounter with HOMP is to receive a reprimand, they will naturally resent it.
Therefore an initially low key approach to aircrew feedback was essential to build
trust. Aircrew response was good once their initial fears were allayed. Generally,
those who were contacted after significant events were either receptive to the
HOMP Manager’s comments or, in several cases, very pleased to find out what had
gone wrong, or that the circumstances had come to light.
Whilst face to face communications with aircrew at the main base worked well, it
proved to be difficult to achieve good communication with crews at the remote base
(for example by telephone), so dealing sensitively with issues there was much harder.
One possible solution would be to have trusted representatives at remote bases who
could be called upon to deal with any local issues.
One of the few communications difficulties experienced occurred when providing
feedback to aircrew located at Scatsta (i.e. the remote base). With the few days delay
in receiving the downloaded flight data from the Scatsta aircraft, by the time the
HOMP Manager attempted to make contact the co-pilot had already left the base for
a period of 2 weeks off duty, and was out of the country. The captain was still on the
base, but he disagreed with the HOMP Manager’s observations on the flight. The
HOMP Manager sent the captain an extract of flight data on floppy disk for him to
replay, with an accompanying letter indicating that the information was confidential
between the captain, the co-pilot and himself. The captain, however, showed the data
to a number of his colleagues on the base. The HOMP Manager was unable to
contact the co-pilot until after he returned to the operation and had heard about the
event from his colleagues in the crew room. Fortunately he was very understanding,
but it could have been very damaging to the project. The lesson learned from this
experience is never to discuss events or send evidence to only one of the crew - it
should be both or neither.
Another feedback difficulty occurred when it was necessary to bring an event to the
attention of a long-serving pilot who was not well known to the HOMP Manager. He
was defensive and could not be persuaded that the event indicated poor airmanship.
Despite a difficult meeting, there was no subsequent recurrence of the episode.
Although the option of identifying the individual to management was considered, it
was concluded that the best approach was to wait to see whether the meeting had
the desired effect, and in this case it had.
25 September 2002
Section 5 Page 16
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Apart from these two difficulties, crew reaction to individual feedback from the
HOMP Manager was either neutral or appreciative. The aircrews growing trust in the
programme was demonstrated by the increasing number of pilots who visited the
HOMP office to enquire about aspects of their flights.
One of the key objectives of a programme is to ensure good communication of the
lessons learnt to all crews. Probably the best vehicle for this is a periodic newsletter.
As well as recounting the lessons learnt from specific incidents, trend information can
be promulgated for all to be aware of. Many pilots commented on the usefulness of
the HOMP newsletters that were published during the trial.
5.5.5
Feedback to training
HOMP data obtained from line flights was used to provide beneficial feedback to
training. For example, the ongoing triggering of an event related to the risk of a
rollover during taxiing led to a memo, with supporting HOMP graphs, being sent to all
training captains. This reminded them of the importance of imparting knowledge of
the potential pitfalls, and correct technique, of taxiing the Super Puma during initial
and recurrent training, and if appropriate during normal line flying.
There were cases where, after experiencing difficulties flying an ILS approach, crews
were able to view the flight replay to identify where things started to go wrong and
why. This culminated in an FDS replay floppy disk being sent to all training captains,
showing some commonly-found poor techniques, with accompanying notes
explaining the issues and suggesting better methods.
Inexperienced pilots tend to over-control during periods of stress, such as offshore
landings. One of the most difficult aspects of trying to prevent this is a lack of
willingness on their part to accept that they are doing it. Having obtained the pilots
permission, another example of the use of HOMP data for training was to compare
control position data recorded on their flight with an approach and landing flown by a
line-training captain, and highlight the difference.
5.5.6
Feedback to engineering
Flight data monitoring has provided engineering benefits to fixed-wing operators and,
in time, the same is expected to be true for helicopter operators. The helicopters
involved in the HOMP trial were all equipped with HUM systems and during the trial
there was only limited engineering interest in the additional information which could
be provided by the HOMP. However, there was evidence of a gradual change in
attitudes, and it is recognised that it took several years for line engineers to fully
appreciate the benefits of HUMS.
5.5.7
Managing the data analysis
The trial highlighted the importance of identifying all the information required to
support the HOMP process before embarking on a full-scale programme. For
example, in order to draw conclusions from the flight data, the analyser must be in
possession of all the relevant facts, which can include operational and weather
information.
When specifying the HOMP events and flight data measurements, the importance of
understanding what these are trying to achieve was recognised, and one of the
objectives of the trial was to clarify this. Before specifying an event it is necessary to
consider what action will be taken when it is triggered. If the answer is “none”, then
perhaps the event should not be included. However, it may be appropriate to leave in
events which simply act as markers to particular types of flying, but are not
necessarily indicative of a problem, providing the necessary steps are taken to filter
these out of any statistical safety analysis.
25 September 2002
Section 5 Page 17
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
At the commencement of the trial, there were some concerns that helicopter
operations would be too difficult to define and monitor automatically, however the
trial experience proved that these concerns were unfounded. Helicopter operations
are undoubtedly more difficult to automatically monitor than fixed-wing but,
nevertheless, a reasonable degree of automation was achieved in the event
detection. The event thresholds were often set relatively low because experience
showed that the triggering of an event could be a pointer to something more
significant which had not been foreseen. However this did not result in a high number
of nuisance events.
Considerable interpretation could be required to determine whether events were
worth acting upon. The main advantage of helicopters is that they are more flexible
than their fixed-wing counterparts, but this can increase the difficulty of creating
algorithms that define good or bad operating practice. However, although probably
less than for helicopters, fixed wing events still need considerable manual verification
and interpretation. It may be possible to gradually increase the complexity of the
HOMP events to reduce nuisance triggering levels in a full scale programme.
However, the more parameters that are included in an event definition, the more
opportunities there are for it to fail to trigger.
The HOMP trial experience showed that the one or two more significant occurrences
which were detected were not well defined by the specific HOMP events triggered
on the flight. A relatively major occurrence could be indicated by one or more
seemingly minor events, with the significance of the occurrence only becoming
apparent when the data associated with the events was reviewed. In addition, the
degree of significance of an event could be very dependent on circumstances. It was
therefore difficult to devise events specifically targeted at these major occurrences
and, even then, an event could only be devised if its occurrence had been foreseen.
The number of unexpected occurrences detected during the trial highlighted the fact
that it was not possible to foresee all the different types of occurrence that could be
monitored. The ability of events to identify occurrences which had not been
envisaged when they were implemented was shown to be a strength of the HOMP.
Once unexpected occurrences have been identified it is usually possible to
implement new events which are targeted at them. Where this is not possible, the
process can continue to rely on the detection of the event by circumstance and
peripheral events, and a “user defined” event could be manually created in the FDE
module to enable it to be tracked.
The trial demonstrated how the analysis of event trends (with the FDE module) could
provide a useful input to the safety management process. Whilst the trend
information had little relevance to the few major “one-off” occurrences, a key benefit
of the trend analysis was its ability to bring attention to the cumulative risk from more
frequently occurring, but less individually significant, events. The relatively high
proportion of nuisance events did not distort trends as they were allocated severity
levels of zero and were filtered out.
A number of changes to event definitions and limits were made at different times
during the trial, primarily to reduce the occurrence of nuisance events. It is important
to document these changes as they will affect event trends.
5.5.8
Allocation of severity levels to events
Severity levels were assigned to events reviewed in the FDT module using the
severity guide shown in Table 5.1 in section 5.4.1.3. These were then exported with
the events to the FDE module.
25 September 2002
Section 5 Page 18
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Manual allocation of severity does create the possibility of human error or bias
affecting event trends, but with a range of 10 steps an error of one step or so is not
likely to be statistically significant. In a small company, the allocation is likely to be
performed by only one or two personnel and therefore it should be possible to
achieve adequate consistency.
There may be scope for the automatic calculation of severity levels for some events
as is performed by BA. However, the value of this will be reduced because the
flexibility of helicopter operations makes it difficult to define algorithms that can
automatically detect flight safety issues, and circumstances and external factors such
as weather can also be significant. Those events that were simply flight manual
exceedances, for example VNE or bank angle exceedances, were generally allocated
a severity value of 1 (limits were not exceeded by a large margin). A default value
could automatically be assigned to an event, which could then be modified if required
during the event review process. This was not implemented in the HOMP trial, but
could be developed in the future as more experience is gained.
During the trial, the majority of events were assigned a severity value of zero. This
reflected the desire to leave in events which were not really significant in themselves,
but which might point to some other occurrence not previously foreseen.
25 September 2002
Section 5 Page 19
CAA PAPER 2002/02
Section 6
6.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP Trial Results - Flight Data Events
Individual events
The HOMP event analysis produced significant results which clearly demonstrated
that the programme enhances operational safety. A number of examples of individual
HOMP events are described below, the results of the event trend analysis are then
described in Section 6.2.
The example HOMP events include three that were reported by pilots (items 6.1.17,
6.1.18 and 6.1.19). A HOMP involves more that just the detection of events from
flight data, it is the whole system of problem detection and correction. In these cases
the programme provided the facility for pilots to report a problem and to have it
investigated confidentially with the HOMP system. Without HOMP, event 6.1.19 may
not have been reported, and 6.1.17 and 6.1.18 may only have resulted in a tech-log
entry. With no supporting evidence, tech-log entries relating to transient defects
which cannot be confirmed on the ground often result in clearance by “tested on the
ground – no fault found – released to service”. It is also part of the HOMP process to
detect occurrences by any means and then, if appropriate, create new events
specifically targeted at them.
6.1.1
Take-off with full right pedal
HOMP events triggered
Event No
Title
07A
High roll rate below 500 ft AGL
34B
Excessive rate of movement of longitudinal cyclic on ground
38B
Taxi limit (right gear lifts)
The most significant finding of the trial related to an incident involving a take-off with
full right pedal, which the HOMP detected. It was the co-pilot’s sector as pilot flying.
During lift-off from a platform, the aircraft yawed violently right, with associated rolling
and pitching, as the co-pilot regained control. The helideck crew were concerned and
made radio contact to check whether there was a problem. The aircrew did not
understand what had happened. The captain believed that the co-pilot must have
raised the collective too quickly, instead of stabilising the aircraft when it was light on
its wheels. As a result, the co-pilot suffered a loss of confidence, and fully appreciated
the HOMP Manager’s subsequent debrief on the exact cause of the incident, as he
was then empowered with the knowledge required to prevent a recurrence.
The HOMP system showed that, after the autopilot had been engaged at the end of
the rotors running turn-round, there was a two minute delay during which there were
two radio transmissions, implying some distractions. During this time there was a
progressive change in apparent aircraft heading to the left caused by gyro-compass
precession. When this reached 2° left the autopilot, trying to maintain heading,
started to gradually apply right pedal. Full right pedal was achieved after another 30
seconds. The only cockpit cues were a torque indication of 25% (14% would be
normal) and 2° left roll attitude. The co-pilot then started to raise the collective to lift
off. At 11.5° collective pitch he started to reduce the tail rotor pedal but, almost
simultaneously, the aircraft yawed 30° right (probably with tyres still in light contact
25 September 2002
Section 6 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
with the deck). A shaky hover was established. In the debriefing the co-pilot reported
that, when putting his feet on the pedals, he had thought that they were in an
abnormal position, but assumed that this was their position at landing (the captain had
carried out the landing). He did not have sufficient confidence to make a large change
in pedal position before starting to lift off.
Figure 6.1 shows the position of the tail-rotor pedals and collective, and the status of
the autopilot, during the period on deck. It is apparent that no-one had their feet on
the pedals during the period in question. Although not shown on this graph, the cyclic
had also moved slowly to the right in an attempt to compensate for the left roll
induced by the tail-rotor. The total movement was only about 20% of travel, but it
again appears that no-one was holding the cyclic.
Tail Rotor & Collective Pitch
100
16
Autopilot
Tail Rotor Pedal
Collective Pitch
Tail Rotor (%)
80
14
Collective (degrees)
Right
12
60
10
40
8
20
6
Left
AP Engaged
0
0.0
0.5
4
1.0
1.5
2.0
2.5
Time (minutes)
Figure 6.1 Tail Rotor, Collective Pitch and Autopilot vs Time
The HOMP system was used to debrief the crew as to the real cause of the problem,
and to provide positive feedback to prevent a repeat occurrence. The event was
considered to be significant as, in the mid-80s, a Super-Puma was destroyed when
the crew lifted off with full left pedal and rolled over on a training flight. The instructor
was demonstrating how the aircraft could be lifted off with feet off the pedals but,
unknown to him, the autopilot had applied full left pedal prior to lift-off. In addition, a
BHL Tiger rolled over during taxiing because a large amount of right pedal was applied
with insufficient right cyclic.
The HOMP subsequently detected a second occurrence in which the autopilot
applied full right pedal prior to an offshore take-off. After the autopilot had been
engaged the crew were again distracted by radio traffic and other tasks, during which
time the autopilot moved the tail rotor pedals to the full right position. The co-pilot
then placed his feet on the pedals and, detecting the problem, disengaged the
autopilot, centred the pedals, and re-engaged the autopilot. The co-pilot did not
discuss the occurrence with the captain, who remained unaware of it until contacted
by the HOMP Manager. The HOMP Manager publicised the occurrence and briefed
the line training captains on it, highlighting the fact that the controls were not being
monitored.
25 September 2002
Section 6 Page 2
CAA PAPER 2002/02
6.1.2
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Autopilot engaged after landing
HOMP events triggered
Event No
Title
34A
Excessive longitudinal cyclic control with insufficient collective pitch on
ground
The autopilot had not been disconnected after a landing on an offshore platform and
neither of the aircrew were guarding the controls. As a consequence, the cyclic
control motored forward and right until this was at 75% of full forward travel and the
rotor blades hit the flap restrainers. Probably on feeling the vibration, the pilot pulled
back the cyclic and disengaged the autopilot. As a result of the occurrence, two new
events were created to detect instances in which the autopilot remained engaged
beyond a certain time after landing and before take-off.
Following a flight from Scatsta, the HOMP detected another occurrence of the
autopilot being left in after landing. This caused the cyclic to motor forward for about
one minute, at which point the rotor presumably hit the flapping restrainers. The data
file stopped about 3 seconds later. The HOMP Manager contacted the pilot, who
admitted that the CQAR card had been removed at this time.
There were a number of other occurrences of the autopilot being left engaged after
landing. One was at Aberdeen, where the autopilot remained engaged whilst
passengers left the aircraft, and was only disengaged at the time of the crew change.
Generally, these occurrences showed that the post flight checks were not being
properly completed, and also indicated a failure to comply with an Operations Manual
requirement that whilst one pilot is occupied with other tasks, the other must be
guarding the controls.
6.1.3
Inadvertent loss of airspeed
HOMP events triggered
Event No
Title
03B
High pitch rate above 500 ft AGL
During the return to an airfield from offshore, the weather was deteriorating. The copilot (who was the pilot flying) proposed making an instrument approach but, despite
the heavy rain showers, the captain wanted to make a visual approach. The crew
decided at a late stage that the weather was too poor to continue, and the co-pilot
initiated a climb shortly before crossing the coast in order to make an instrument
approach. During the climb, airspeed was generally low and at one point reduced to
30 kts. Figure 6.2 presents a trace view of the event (showing radio altitude, airspeed,
pitch attitude and collective position). The captain failed to monitor or prompt during
this time, which is the primary duty of the pilot not flying. Probably in response to a
very late prompt, the co-pilot then rapidly lowered the nose, and the climb was
continued at 70 kts, which is the minimum recommended climbing speed in IMC.
Airspeed had been below 70 kts for approximately one minute. The captain was
probably busy arranging the IFR approach, hence the delay in monitoring and
prompting. The co-pilot was concerned about the proximity of the terrain and was
attempting to climb at best angle of climb speed (45 kts), although this was well
outside the Flight Manual IMC flight envelope.
25 September 2002
Section 6 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Radio Altitude
Indicated airspeed * 10
Pitch Attitude
Collective Pitch
1200
20
1000
15
800
10
600
5
400
0
200
-5
0
-10
Figure 6.2 Trace View Showing Loss of Airspeed During Climb
Figure 6.3 presents a snapshot from FDS at a point during the climb. The plot at the
right of the screen shows a plan view of the flight profile and the plot at the bottom
right shows a profile view (the aircraft is positioned at the point where the flight profile
changes from green to magenta). The terrain is shown in orange at the bottom of the
profile view. The vertical speed indicator (bottom left) is showing a 1500 fpm rate of
climb and the airspeed indicator (top, right of centre) is showing that the airspeed is
below 40 kts.
25 September 2002
Section 6 Page 4
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 6.3 FDS View Showing Loss of Airspeed During Climb
Although a helicopter cannot stall at low airspeed, the drag curve is very steep and
control can easily be lost in IMC. The dangers of low airspeed had been highlighted
by a previous serious incident on another type. Following a go-around from an
offshore installation at night, the crew decided to climb at low airspeed but, due to
extreme turbulence, they failed to notice that airspeed had fallen below zero. They
lost control of the aircraft at about 1,000 feet and developed a 6,000 feet/minute
descent rate, pulling out of the dive at 75 feet above the sea. The co-pilot involved in
the HOMP event had joined the company since that incident and the training system
had possibly failed to make him aware of the lessons learnt. The co-pilot was
receptive to the HOMP Manager’s points and appreciated the opportunity to discuss
the related CRM issues. Whilst the captain was less receptive to the comments
made, the feedback hopefully made him think about the issues discussed.
6.1.4
Deck out of limits
HOMP events triggered
Event No
Title
30A
High roll attitude on ground
Prior to landing on a vessel, the pilot had been informed that deck pitch and roll was
+1.98 degrees (landing limit = +2 degrees), however after landing he believed that
the actual pitch and roll was much greater than this. The pilot therefore requested a
printout of the HOMP data. This showed aircraft roll angles of up to +4 and -6 degrees
(Figure 6.4). The pilot's request had been made before the HOMP data had been
processed and the system subsequently detected a number of 'roll attitude on-
25 September 2002
Section 6 Page 5
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
ground' events. Unfortunately the calculated Motion Severity Index values were
incorrect owing to a faulty output from the aircraft’s longitudinal accelerometer.
Figure 6.4 Pitch and Roll on Deck
There were a number of occurrences of pilots requesting HOMP traces following
landings on vessels where they believed that the deck pitch, roll or heave was out of
limits. For example, in another case the aircrew had raised an ASR after landing on a
vessel as they believed that the deck was grossly out of limits. The HOMP
subsequently generated MSI and roll events, with the data showing a maximum roll
angle of 5.6 degrees. Pilots have given the HOMP traces to the Fleet Manager for
forwarding to the vessel’s operators. By raising awareness of the importance of
accurate figures, reported deck motion figures should become more reliable. If no
improvement is seen, the HOMP has provided BHL with the evidence to support
further action, which could ultimately include refusing to operate to a specific vessel.
6.1.5
Aircraft hit by a line squall on an offshore platform
HOMP events triggered
Event No
Title
35A
Excessive movement of deck (Motion Severity Index)
The HOMP Manager received a request from an engineer for some HOMP
information when a pilot made an entry in the tech log after a line squall had hit his
aircraft when it was on the Fulmar platform. The wind changed from 20 kts on the
nose to 70 kts on the beam, resulting in abnormal noises from the landing gear and
the helicopter shuffling on the deck (an ASR was raised). When the flight data was
replayed the incident was detected by the HOMP, with a deck Motion Severity Index
25 September 2002
Section 6 Page 6
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
event being generated whilst the aircraft was on the platform, which was a fixed
installation. The incident is an example of how events triggering in seemingly
inappropriate circumstances can identify unexpected occurrences.
By being able to detect and measure weather related effects, the HOMP can help to
ensure that aircraft and crews are well prepared for any poor weather. The line squall
event shows the importance of having the aircraft properly chocked on deck
(something which crews can become complacent about), and of maintaining deck
friction by ensuring nets and non-slip paint surfaces are clean and in good condition.
6.1.6
Go-around following an offshore Airborne Radar Approach (ARA)
HOMP events triggered
Event No
Title
40A
Torque split in the cruise
The HOMP detected a go-around flown offshore in bad visibility following an ARA
because the selection of “bleed offset” fortuitously generated a ‘torque split in the
cruise’ event. Following visual contact with the platform at low level, the aircrew had
inadvertently climbed 50 ft, which put them into cloud approximately 0.2 nm from the
platform. Flying low and slow in cloud close to the platform presented a hazard and
the aircrew took the right corrective action and performed a go-around. BHL’s HOMP
Manager gave the crew a disk containing the data and FDS program for them to
review, and recommended that they raised an ASR. It could clearly be seen that the
problem had occurred when the aircraft slowed to below minimum drag speed. The
pilot correctly applied power to arrest the deceleration and prevent a descent, but
overdid it and the aircraft climbed as a result.
This is another example of a HOMP event leading to an unexpected finding. Following
the discovery of the go-around incident, 3 new events were created to detect a goaround, and also to detect descent below different height limits in daylight and at
night during the go-around.
6.1.7
Below minimum descent height during offshore Airborne Radar Approach
(ARA)
HOMP events triggered
Event No
Title
41B
Below minimum descent height on go-around
Until recently, the minimum descent height in daylight for an instrument approach to
an offshore installation was 200 feet. However, the current rules for an ARA specify
a minimum descent height of deck height + 50 feet, but not lower than 200 feet. For
the Brae Alpha, this gives a minimum descent height of 286 ft. The HOMP showed
that an approach to this platform had been flown at a height of 200 feet, which
decreased to a minimum of 170 feet shortly before a go-around. The HOMP Manager
contacted the pilot, who accepted that his action had been incorrect. Figure 6.5
presents a snapshot from FDS taken during the approach, with the radar altimeter
showing a height of 170 feet.
25 September 2002
Section 6 Page 7
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 6.5 FDS View During an Airborne Radar Approach
Following a second occurrence of an approach being flown well below minimum
descent height, the issue was highlighted in a HOMP newsletter. Airborne Radar
Approaches to offshore installations carry a potential risk but, by monitoring the
approaches with a HOMP, any poor technique or exceedance of limits can be
detected and remedial action taken to ensure that the risk is minimised.
6.1.8
Below minimum en-route height
HOMP events triggered
Event No
Title
22B
IAS greater than 100 knots below 100 feet AGL with gear selected up
After departing and climbing to 600 feet, the pilot flew over an island. When flying
over a hill on the island (which has a significant bird population), the aircraft’s height
was only 58 feet AGL (Figure 6.6). The Operations Manual specifies a minimum enroute height of 500 ft. The HOMP Manager showed the pilot an FDS trace of the
event and reminded him of the correct procedures. However the pilot did not accept
that the matter was a flight safety issue. The HOMP Manager was unsure as to what
to do next, however the pilot subsequently identified himself to the Head of Flight
Operations and to some of his colleagues. The HOMP Manager was therefore able
to discuss the issue with the Chief Pilot. If a similar situation arose in the future, the
HOMP Manager would involve the Flight Safety Officer in the follow-up process as
an independent arbiter.
25 September 2002
Section 6 Page 8
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 6.6 FDS View Showing Flight Over Island
6.1.9
Take-off with cabin heater on
HOMP events triggered
Event No
Title
19A
Heater on during take-off
The HOMP showed that during the winter period 1999 - 2000, on average, one aircraft
a week was taking off from off-shore with the cabin heater on. No doubt the heater
was applied on deck for passenger and crew comfort and possibly demisting but,
apart from being prohibited in the Flight Manual, when the heater is on during takeoff, the maximum available power is reduced and the power turbine inlet temperature
for a given power is increased. In the event of an engine failure, having the heater on
could make the difference between ditching and flying away.
A newsletter was issued drawing this to the aircrew’s attention. During the winter of
2000-2001 there were relatively few such events so it was decided not to include this
item in the already long pre-take-off checklist.
25 September 2002
Section 6 Page 9
CAA PAPER 2002/02
6.1.10
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Taxiing in rollover zone
HOMP events triggered
Event No
Title
38B
Taxi limit (right gear lifts)
When taxiing a Super Puma it is possible to induce a rollover by applying excessive
right pedal without applying sufficient right cyclic to counteract the rolling couple. BHL
had an aircraft rollover in dispersal some years ago, and since then this aspect of its
ground handling has been of concern to the company. The HOMP system generated
several ‘rollover limit’ events during taxiing.
In one case, the co-pilot was in the right-hand seat on his first line flight following a
right-hand seat conversion, and so was unused to taxiing the aircraft (there are no toebrakes on the left, so aircraft are never taxied from the left-hand side). When
contacted after the event, the captain reported he had been aware that the co-pilot
had been close to the rollover zone and, although he had prompted, there was a short
delay before a correction was applied. As the captain was a training captain he agreed
to discuss the topic with the co-pilot again to highlight the potential dangers.
In another case, the controls were placed in very similar positions to those in the
previous accident which, had the aircraft not been heavy and hence had a low vertical
centre of gravity, could have resulted in a rollover. Although the handling pilot was an
experienced captain, he had recently converted from another type. The follow-up
revealed that the pilot involved was not fully aware of the rollover problem and, whilst
the subject was covered in the type conversion, its significance had not been
recognised. As a result, the Chief Training Captain issued a memo to all training
captains reinforcing the need to highlight this issue on initial and recurrent training.
A graph of lateral cyclic and yaw pedal positions (Figure 6.7) was sent to the crew and
provided useful debriefing material. The red line in Figure 6.7 is the edge of the zone
defined by Eurocopter in which the combination of lateral cyclic and yaw pedal
position might cause rollover. The pink joined-up points show the actual data from the
accident on BHL Tiger G-TIGT as it was rolling over, and the blue points are taken from
the HOMP event which had been triggered. Not shown is the roll attitude, which was
approximately 3 degrees left, confirming the proximity to a rollover.
25 September 2002
Section 6 Page 10
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP event control positions
Control positions
Accident control positions
Rollover Line
Full right
100
90
80
70
Cyclic
60
50
40
30
Full left
20
10
0
0
20
40
Full left
60
Yaw Pedal
80
100
Full right
Figure 6.7 Lateral Cyclic and Yaw Pedal
6.1.11
Flight through hot gas
HOMP events triggered
Event No
Title
28A
Flight through hot gas
A number of 'flight through hot gas' events were detected, with temperature rises of
5 to 12 oC in 3 or 4 seconds. The majority of these occurred on the Ninian Central
where there are known problems with the platform’s power generation turbine
exhaust plumes passing close to or over the helideck. In one case an approach had
not been particularly well flown. The aircraft had been descending and slowing with
its engines at a very low power setting when the collective was raised just as the
aircraft flew into hot gas, demanding rapid acceleration from the engines. The sudden
change of ambient air temperature, coupled with the acceleration demand, could
have caused an engine surge, resulting in loss of power. Whilst the Ninian platforms
are normally serviced by Scatsta crews, this flight was performed by an Aberdeen
crew who were less familiar with the characteristics of the Ninian.
In another case, when an aircraft was on the helideck of the Anasuria, the HOMP
detected a deck temperature which was 10 degrees C above normal ambient
25 September 2002
Section 6 Page 11
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
temperature. This was again due to turbine exhaust gases being blown along the side
of the ship and up across the helideck. In this case, because the turbine exhausts
were some distance away, the problem was more one of performance loss rather
than turbulence or engine surge. Whilst the Super Puma is not normally performancelimited by high temperatures, other types certainly are. Due to the unpredictable
nature of this effect, it is very difficult for crews to plan arrival and departure weights
– the effect might arise after the installation weather has been received and
performance calculated. Irrespective of performance limitations, increased
temperatures will always reduce power margins and this could affect the outcome of
an engine failure in the late stages of an approach.
Under certain conditions, flight through turbine exhaust plumes is probably inevitable
on particular installations. However the HOMP can help to ensure that appropriate
operating restrictions are placed in the Helideck Limitations List (HLL).
6.1.12
Overtorque on landing
HOMP events triggered
Event No
Title
25B
Maximum take-off torque (2 engines)
The co-pilot was landing at maximum weight on a platform with a restricted sector
due to turbulence, when the wind was in this sector but below the windspeed limit
for a weight restriction. The existing platform limitations are considered to be
satisfactory provided an approach is well flown. However, a combination of the wind
being in the turbulent sector and the co-pilot’s less than ideal approach resulted in a
short duration overtorque, which was not seen by the aircrew. As a result of the
HOMP event, the co-pilot raised an ASR.
6.1.13
VNO/VNE exceedance
HOMP events triggered
Event No
Title
17C
VNO exceedance by 2 knots IAS
A large number of VNO exceedances occurred at aircraft weights over 18,410lbs,
where there is a step change in VNO/VNE limits. This showed that crews were failing
to remember the change in VNO/VNE limits at high weights. In the past aircrew used
to check VNO/VNE before commencing a descent, but this practice ceased.
In one case, an aircraft also exceeded VNE by one knot when descending to an
offshore platform (this was too small a margin to trigger the VNE event). The aircraft
was heavy and the exceedance was due to a combination of high take-off weight and
short sector distance.
25 September 2002
Section 6 Page 12
CAA PAPER 2002/02
6.1.14
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Temporary loss of control in flight
HOMP events triggered
Event No
Title
10A
High normal acceleration above 500 feet AGL
The HOMP detected a high normal acceleration in the cruise (1.7g) when the co-pilot,
leaning back to retrieve a water bottle, overbalanced and inadvertently pulled back on
the cyclic control at 130 kts, changing the attitude of the aircraft from level to 20
degrees nose up. The captain took the controls, but by the time he had regained
control, the aircraft had climbed approximately 1,000 ft (the aircraft was outside
controlled airspace at the time). Figure 6.8 shows the plot of longitudinal cyclic pitch
(blue), pitch attitude (red), normal acceleration (black) and pressure altitude (green).
The HOMP Manager suggested that the crew raised an ASR.
Figure 6.8 Pitch Up During Loss of Control
25 September 2002
Section 6 Page 13
CAA PAPER 2002/02
6.1.15
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
“Max Ng” check at low height
HOMP events triggered
Event No
Title
39A
Single-engined flight
An air test was performed for a ‘max Ng’ check, which involved setting one engine’s
fuel control lever to idle and demanding full power from the other. The test had been
performed at 1,500 feet, however the aircraft subsequently descended to 200 feet
AGL and one engine was again set to idle and the other to full power. Performing this
test at such a low height created an unnecessary hazard and demonstrated poor
airmanship.
On a previous incident involving a Super Puma, during a Max Ng check the drive shaft
of the engine at full power disconnected. The aircraft lost considerable height in
autorotation until the other engine could be restored to full power, and was only saved
from an engine-off landing or crash by the safe height at which the test was being
conducted. The HOMP Manager discussed the issue with the Flight Safety Officer,
who included it in a routine flight safety newsletter.
6.1.16
Excessive collective pitch in cruise
HOMP events triggered
Event No
Title
12A
Excessive collective pitch control in level flight
At Scatsta it was necessary to fly procedural IFR approaches at night with a 10 minute
separation; if multiple aircraft were returning at the same time an aircraft could be
given a delayed approach time. The HOMP detected examples of aircraft flying with
greater than the Flight Manual limit for collective pitch and torque in the cruise to
achieve a particular arrival time. This may be an example where there is merit in
reviewing local ATC procedures. Collective pitch limits were reduced shortly after the
aircraft first came into service as a result of the low time before degradation of the
gearboxes. Although no relationship could be proved, at the time of the HOMP events
it was noted that there had been an increase in the rate of gearbox replacements.
6.1.17
ILS glidepath indication problem
HOMP events triggered
Reported by pilot
During an ILS approach, the co-pilot's glideslope indicator was not functioning
correctly and the faulty indicator was being used to fly the approach. This was
indicating that the aircraft was on the glidepath, when in fact it was below it and
descending. When the functioning indicator was checked the deviation was detected
and the aircraft climbed back up to the glidepath. The pilot informed the HOMP
Manager of the occurrence.
25 September 2002
Section 6 Page 14
CAA PAPER 2002/02
6.1.18
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Engine problem
HOMP events triggered
Reported by pilot
The pilot reported that, during cruise flight, there had been a loss of power on one
engine and, at the same time, the Ng had increased. After 30 seconds the engine
power reverted to normal. The HOMP data was used to confirm this and a 'split
torque' event was created to capture any repeat occurrence. Other problems with the
engine were subsequently reported and an inspection revealed that the module two
stator vanes had been rotating. The engine was therefore rejected. This example
demonstrated the use of HOMP data to troubleshoot an engine problem.
6.1.19
Full-scale fly up at 200 ft during ILS approach
HOMP events triggered
Reported by pilot
A captain visited the HOMP Manager following an ILS approach flown by an
inexperienced co-pilot in very bad weather. During the latter stages of the approach,
below 500 ft, the captain had been looking out of the cockpit to try to obtain visual
references. Approaching decision height, with no outside visibility, he looked back
inside and saw nearly full-scale fly-up on the ILS glidepath. A go-around was initiated
and the aircraft landed successfully from the second approach. Figure 6.9 shows the
instrument view at approximately 250 ft above airfield elevation, with the aircraft in a
potentially hazardous position.
Figure 6.9 Nearly Full-Scale Fly-Up at 250 ft
25 September 2002
Section 6 Page 15
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Discussion with the captain revealed ways in which the conduct of the ILS approach
could have been changed to make flying the approach easier. ATC had asked the crew
to maintain maximum speed, and so most of the approach was flown at 130 kts IAS
(110 kts is preferred). Despite that, the approach was well flown until around 800 ft
when it was decided to reduce speed to approximately 80 kts.
Many pilots believe that it is easier to land in poor weather if airspeed is low at the
bottom of the approach, as there is more time to acquire visual references. Low
speed is also preferred because ATC normally expect aircraft to turn off the runway
at the first intersection which, in this case, was only about 200 yards past the ILS
touchdown markers. However, a late speed reduction de-stabilises the approach and
markedly changes the drift angle and required rate of descent to maintain the ILS
flight path, making the bottom of the ILS approach very much harder to fly.
During the discussion, the captain realised that improvements could have been made
to the way the approach was flown, for example by declining the high-speed request,
or slowing down earlier and less, and informing ATC that they would not be able to
make the normal turn-off.
Following the reporting of this incident, consideration was given to the creation of a
new HOMP event to monitor for any recurrence. However, problems were
anticipated with a very high nuisance triggering rate and therefore no event was
implemented. Helicopters returning to Aberdeen normally fly a VFR approach, and do
not attempt to maintain the ILS approach angle. However the aircraft may well be
tuned to the ILS frequency, which would lead to apparent severe glidepath deviations.
Even when an aircraft is flying an ILS approach, it would not be possible to determine
when the crew establish visual contact with the runway, after which point they would
be likely to deviate from the ILS approach path to arrive at the helicopter landing area.
It may be possible to devise a complex event algorithm that overcomes these
problems, but this was not attempted during the trial.
6.2
Event trends
6.2.1
The importance of trending
In addition to identifying safety issues from individual HOMP events, important
information can be obtained from reviewing the rates of event occurrence and
detecting any increasing or decreasing trends. For a small operator with only a few
people involved in the HOMP, some trends are likely to be relatively obvious but, in
order to ensure that a significant trend is not missed, it is necessary to perform a
regular review of event trends. In particular, it is important to complete the loop of
identifying recurring events, taking corrective action, and then checking for the
success of the corrective action as demonstrated by a reduction in the event rate.
Monitoring should check that there has been a sufficient reduction in event triggering,
and that the rate does not increase again over time as crews forget the issues
highlighted or as other factors come into play.
6.2.2
Event rates and trends observed during the HOMP trial
The full FDE module functionality required for HOMP event trend analysis was not
available for the first year of the trial, however trends could still be observed
qualitatively by the HOMP Manager. One of the early trends detected was the
frequent occurrence of take-offs with the cabin heater on (see Section 6.1.9). Having
identified this as a recurrent problem, possible actions were considered, and it was
decided not to include the item in an already full checklist. When frequently used
checklists become too long, they can be counter-productive as the lengthy repetitions
25 September 2002
Section 6 Page 16
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
increase the likelihood that items are missed, or are enacted without thought.
Instead, the issue was included in the first HOMP newsletter, published in late
February 2000. Occurrences of this event reduced markedly after the publication but,
as it was nearing the end of winter, it was difficult to determine whether this was
because of the aircrew response, or whether it was simply due to the warmer
weather. However, during the winter of 2000/2001 the occurrence rate remained
low. It was therefore concluded that the issue had been adequately addressed, the
only remaining requirement was to monitor for any future signs of a reappearance.
Having experienced a rollover accident resulting from inappropriate use of tail rotor
pedal and cyclic during taxiing, the flight safety and training departments were
naturally very attentive to the issue. Despite this, a number of occurrences were
detected of the controls being placed in the rollover zone, and in one or two cases the
roll attitude confirmed the proximity to a rollover. Having targeted all the individuals
concerned with an explanatory letter and graphs similar to Figure 6.7, and highlighted
the issue in an edition of the company flight safety newsletter, there was only a
limited reduction in the occurrence rate. This resulted in another campaign, involving
a memo from the Chief Training Captain to all trainers reminding them to give the
issue high priority, and another newsletter. The occurrence rate then dropped to near
zero and remained low, either because all likely offenders had been individually
targeted, or because of the general raised awareness. Although the campaign lasted
well over a year, a successful outcome was eventually achieved. The experience
demonstrated that it is not sufficient to take a single action to attempt rectify a
problem – the outcome must be monitored and, if it is not successful, further
measures must be taken.
Some events (for example deck motion events) are generated by external factors
which are largely beyond pilot control. Attempting to address these events can be
more difficult as they can involve other parties. However, it is still important to
monitor for such trends because, if a significant adverse trend is noticed, the
company has a duty to take whatever measures are required, even if this involves
addressing issues with its clients.
Once the FDE module had been commissioned, various event trend charts could be
produced, making the task of monitoring event rates and trends much easier. Figure
6.10 shows a histogram of all the events within FDE for a 6 month period (i.e. it
includes all nuisance events but no false events), with a filter applied to eliminate
training flights or airtests. These flight types include manoeuvres that would not be
considered normal for passenger transport flights and so tend to generate large
numbers of events. The event algorithms could be modified to only detect events on
the appropriate flight type, but it was considered better to detect events on all flights
and then filter the data. Indeed, badly conducted training flights could generate
unacceptable risks even though no passengers were carried. The data shown in the
following figures was produced part way through November 2001, and so does not
include all November’s flights.
25 September 2002
Section 6 Page 17
CAA PAPER 2002/02
Figure 6.10
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
All Events for Passenger Flights for a 6 Month Period
The large number of events included in this chart is somewhat misleading as the
majority of events seen posed a minimal or non-existent flight safety risk. The
philosophy was to accept a number of nuisance events because occasionally they
pointed to an occurrence not previously thought of. In order to avoid distorting the
trend data, the nuisance events were assigned a severity level of zero, whilst all other
events were given a positive severity level. The chart presented in Figure 6.11 shows
only events assigned a severity greater than zero. In this case training and airtest
flights are included because these generated a few significant events.
25 September 2002
Section 6 Page 18
CAA PAPER 2002/02
Figure 6.11
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Frequency of All Events for All Flights for a 6 Month Period, with
Severity >0
This chart does not take into account the fact that an event with an assigned severity
of 1 has less significance than one assigned a severity of say 4. Thus rather than
plotting events by frequency, it is more meaningful to plot events by cumulative
severity as shown in Figure 6.12. This may change the ranking of the events
appearing on the chart. In the particular cases shown, the ranking of the top 3 events
does not change, although their relative magnitudes do. However, it can be seen that
event 35A (Excessive Movement of Deck) moves up from bottom equal to position
4. This was the result of one occurrence being assigned a severity of 5 as it was
considered to be quite a serious event (roll angles achieved were +3.7 to –5.5 when
the limit was +/-2).
25 September 2002
Section 6 Page 19
CAA PAPER 2002/02
Figure 6.12
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Cumulative Severity for All Events for a 6 Month Period
An earlier production of Figure 6.12 was used to determine the contents of the
September 2001 HOMP newsletter to aircrew. Some of the events (e.g. 28A - Flight
Though Hot Gas, 35A - Excessive Movement of Deck, 26A - Pilot Workload/
Turbulence) related to issues largely outside pilot control. It was therefore decided to
address the pilot-controlled issues relating to events 06A–D (Roll Attitude), 17C (VNO
Exceedance), 41A/B (Go-Around) and 42A/B (Autopilot Engaged On Ground). Whilst
many 41 A/B and 42 A/B events were generated by legitimate operational
circumstances (i.e. were nuisance events), the newsletter was intended to address
those cases where they were inappropriate.
Having published the newsletter, the subsequent trend of these specific events was
monitored using the chart shown in Figure 6.13. This gives the variation in cumulative
event severities between the last 3 months and the previous 3 months, with green
indicating a reduction and red an increase. Even taking into account the slight
reduction in the total data for the last 3 month period, it can be seen that the
cumulative severity of the targeted events reduced markedly, showing the
newsletter to have been very effective. Event 6D was the only exception to this
positive result. The two new cases were both the result of training flights exceeding
the Flight Manual limit for bank angle at high weights whilst carrying out “instrument
recovery from unusual attitude” exercises. The two different training captains
involved in the events were reminded of the Flight Manual limit. It would be
necessary to continue to monitor these trends to detect any signs of a future relapse.
25 September 2002
Section 6 Page 20
CAA PAPER 2002/02
Figure 6.13
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Variation of Severity of Events Covered by September 2001
Newsletter
Event frequencies are of course affected by the amount of flying carried out and so it
may be appropriate to factor the figures. Factoring could be carried out either by flight
hours or by flight sectors, but as the majority of events are triggered during take-off
and landing, it is more appropriate to factor by sectors. FDE permits the importing of
flight sector information, including the departure and arrival locations. This not only
allows factoring by total flight sectors, but also permits more accurate trends to be
observed for individual locations.
For example, Figure 6.14 shows instances of event 28A (Flight Through Hot Gas),
plotted by location. This event relates to the aircraft encountering sudden changes in
air temperature, normally due to the proximity of turbine exhausts on offshore
installations. From this chart it can be seen that the Ninian Central is ranked top, whilst
the Anasuria is some way down. However, after factoring by the number of landings
on each installation, the picture is somewhat different as Figure 6.15 shows. The
Anasuria, with fewer landings, now moves up to second place behind the Ninian
Central, which is consistent with the perceived problems at the two installations.
25 September 2002
Section 6 Page 21
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 6.14
Event 28A “Hot Gas” by Location
Figure 6.15
Event 28A “Hot Gas” by Location, Factored by Number of Landings
25 September 2002
Section 6 Page 22
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Many other types of trend charts can be produced. For example, Figure 6.16 shows
the occurrence rate of event 17C, grouped by operating base. A clear difference can
be seen between the top row and the bottom row, representing the two bases
involved in the HOMP trial. The main reason for this marked difference was that many
of the sectors flown from the top base were relatively short. Therefore the aircraft
were often above the weight at which there was a step change in VNO when at the
top of the descent, giving them a much reduced VNO. There was some difference
between the number of flights analysed from the two bases, but not nearly enough
to account for the different event rates.
Figure 6.16
Event 17C by Operating Base
By use of the encrypted and confidential pilot identities, which only the HOMP
Manager could decode, the sensitive issue of grouping of events by individual pilot
could be examined, as shown in Figure 6.17. The highest ranking individual had 6
occurrences of a particular event over the period, whilst many other pilots had none.
This suggested that there was an issue with the particular individual. In fact the event
did not represent a great hazard as it related to taxiing technique but, if repeated over
a long period, it could possibly result in damage to the aircraft. The individual
concerned was a very experienced pilot but relatively new to this type, and the
technique he was using was appropriate to his old type but not to the Super Puma.
The trend was only identified whilst preparing material for this report, which shows
that some trends are not easy to identify without automatic trend detection.
25 September 2002
Section 6 Page 23
CAA PAPER 2002/02
Figure 6.17
6.3
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Event 34A by Pilot 1 Identity
Discussion
The safety benefits of the HOMP event analysis were identified at an early stage of
the trial when the first events were generated and corrective or preventative
measures were taken. The trial identified safety issues which the operator was able
to resolve and demonstrated that the HOMP is a highly effective tool for enhancing
operational safety.
As well as detecting crew-induced incidents, the HOMP events provided evidence to
support crews concerns about external factors such as severe weather or incorrectly
reported installation data. The HOMP detected a wide variety of events and the
follow-up of these identified a range of operational issues relating to:
• Pilot knowledge and skill
• Gaps in the training system
• Cockpit resource management
• Operating procedures
• Environmental operating limitations
A number of the most notable individual events detected by the HOMP could be
related to previous North Sea helicopter incidents and accidents, or accidents
elsewhere on similar helicopter types. Table 6.1 references five of the events
25 September 2002
Section 6 Page 24
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
described in Section 6.1 and identifies previous incidents and accidents which have
some relevance to these.
Table 6.1 Accidents Related to HOMP Events
Event
reference
6.1.1
Related accident, and
reference
Canadian helicopter accident
Transportation Safety Board of
Canada report circa 1988
6.1.3
G-BKJD near Petrojarl on 6
December 1994
Brief accident details
The AS332L rolled over when the crew
lifted off with full left tail rotor pedal
applied during a training flight.
During a go-around, the 214ST lost
forward airspeed and entered a dive,
recovering at very low altitude.
AAIB Synopsis 5/95
6.1.4
G-BOND DSV Mayo in North
Sea, April 1992
AAIB Report 11/92
6.1.10
G-TIGT Aberdeen Airport
AAIB Bulletin 6/96
6.1.15
G-PUMB Aberdeen Airport
AAIB Bulletin 11/99
Wave hit stern of vessel during rotors
running turn-around causing aircraft to
move backwards on deck, resulting in
HLO being struck by main rotor.
After off-loading passengers, the
AS332L rolled over during a turn whilst
taxiing to the shutdown point.
As a result of a maintenance error, the
AS332 lost drive from one engine during
a “max Ng check”.
There are a number of unique difficulties associated with helicopter offshore
operations which can make them more hazardous than other types of helicopter
transport operation. These include:
• Structure-induced turbulence and downdrafts
• Hot exhaust gas plumes from power generation turbines
• Hot gas, flame and smoke from flare stacks
• Unburned hydrocarbon gas discharge from unlit flare stacks or rapid blow-down
systems
• Obstacles on the final approach or take-off/go-around path
• Poor quality meteorological and installation data reports from inexperienced
observers
• The pitching, rolling and heaving motion of ships and floating platforms during
approach and landing and whilst on deck
• Non-precision instrument approaches to an installation in bad weather using only
on-board equipment such as weather radar
• Lack of flight-manual procedures for take-off and landing at elevated offshore
heliports
• Salt/seawater ingestion
The HOMP trial detected events relating to many of the difficulties listed above.
Without HOMP event information, an operator has no independent information on
operational risks which could lead to future incidents or accidents. A HOMP provides
25 September 2002
Section 6 Page 25
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
the opportunity to identify these risks and take action before they have any serious
consequences. The ability to monitor risks to identify any requirements for
operational changes, and then monitor the effectiveness of these changes, is a key
asset of the HOMP.
Corrective or preventative measures which were taken as a result of the HOMP event
analysis included:
a) Confidential discussion of individual events with flight crew to debrief the crew on
all the relevant factors relating to the event, identify the lessons learned, and to
remind crew of correct SOPs.
b) The issuing of newsletters highlighting individual (de-identified) events or event
trends and, again, reminding crew of correct SOPs.
c) Prompting the raising of Air Safety Reports. The operator’s existing safety
management processes then ensure that necessary actions are taken to improve
operational practices and procedures.
d) Contact with training and safety staff to discuss events and trends, resulting in
training issues being addressed and, in some cases, action being taken to modify
procedures.
Whilst significant events were followed up with flight crew on an individual basis,
event trend analysis was shown to be a valuable tool for identifying undesirable
trends which could best be addressed by the issuing of newsletters to all crew, and
also by feedback into the training process. When such action was taken, the trend
analysis was also able to show the effectiveness of that action, enabling the HOMP
Manager to determine whether further action was required. Analysing trends for
different bases highlighted differences in the rate of occurrence of particular events
between the main operating base and a satellite base. This is a valuable tool ensuring
that consistent standards are maintained across all operating bases.
The analysis of event trends by location confirmed prior experience regarding issues
with particular installations. For example, the analysis highlighted the Ninian Central
and Anasuria as the installations with the most frequent hot exhaust gas problems.
The analysis also uncovered previously undetected trends, for example identifying
that a single pilot was responsible for producing a large percentage of the events in
one particular category.
Including all the events generated by the system in a trend display did not result in a
very meaningful output. However, when ‘nuisance’ events (given a severity value of
0) were filtered out, the resulting trend charts contained useful information. The most
relevant output was generated when severity levels were allocated to events and
trends of ‘cumulative event severity’ were produced.
The event severity scale implemented in the second year of the trial proved to be a
very useful addition to the HOMP system and experience did not indicate any need
to amend the descriptive categories. However, when the category scale numbers
were used to generate cumulative severity, the result was not truly representative.
For example, 10 occurrences of a category 1 event (which includes in its definition
“no actual safety risk”) clearly did not, and would not be expected to, equate to one
event of category 10 (“accident occurred”). Referring to Section 2.1.1, however, it is
also true that the larger the number of lower category events the greater the risk of a
higher category event. The relationship is clearly more complex than the simple linear
scale employed and more development is required. Since it is desirable to work with
a simple scale when assigning severity values during event analysis, the solution may
be to use a non-linear scale, or for FDE to include a lookup table of weightings,
25 September 2002
Section 6 Page 26
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
allowing it to calculate more appropriate cumulative severities. This approach has the
advantage that if the weighting values need to be changed, the results will be
reflected in all the data stored in the FDE system, rather than just new entries.
The FDE module offered a large number of trend chart options. The HOMP Manager
had to decide which charts to produce and, with such a number of possibilities, it was
possible that a significant trend could be missed. There would be benefit in
developing techniques to automatically search for, and then highlight, hidden trends
in event data.
In addition to generating safety benefits, the HOMP event analysis also provided
some useful information to engineering personnel. By detecting excessive use of
collective pitch which could impact gearbox reliability, and monitoring for a reoccurrence of an engine problem, the HOMP trial demonstrated an ability to provide
engineering benefits. The HOMP was also able to detect incorrect FDR parameter
data as a result of aircraft sensor or wiring problems, and should simplify FDR
serviceability checks. All the aircraft involved in the HOMP trial were equipped with
integrated HUM and FDR systems, with the HUMS performing exceedance
monitoring of maintenance manual limits. Additional engineering benefits would be
obtained from a HOMP implementation on any aircraft equipped with FDRs only.
25 September 2002
Section 6 Page 27
CAA PAPER 2002/02
Section 7
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP Trial Results - Flight Data
Measurements
Intended to complement the events, the flight data measurements generated during
the HOMP trial proved to be of significant value. Section 7 presents example results
to illustrate the various types of information which could be derived from the flight
data measurements, and the ways in which this information can be used. The
database of measurements used in all the analyses described below was generated
by reprocessing one year of flight data from the HOMP trial aircraft, and contained
over 7,900 flight sectors.
7.1
Flight information
The flight information contained in the HOMP measurement database consisted of
key information about each sector flown. This included departure and arrival locations,
location type, take-off and landing weights, sector times, numbers of passengers etc.
This information was extracted directly from BHL’s Operational database, and its
primary use in the HOMP was to enable the filtering or grouping of other
measurements in the database. For example, grouping measurements by departure
or arrival location enabled the comparison of measurement values for different
airfields or offshore platforms.
7.2
General flight data measurements
The general flight data measurements are listed in Tables 4.4 and 4.5 in Section 4.4.
One of their main uses in the HOMP trial was to determine appropriate trigger limits
for events. For example, a review of the HOMP events showed that events 21A
(High Groundspeed Within 20 seconds of Rig Landing), and 21B (High Groundspeed
Within 10 Seconds of Airport Landing) were not being triggered. Charts were
produced to determine actual groundspeed values at 20 seconds from a rig landing
and 10 seconds from an airport landing. The groundspeed trigger levels for both
events were originally set to 60 kts but, following a review of the measurement data,
they were reduced to 35 kts. By way of an example, Figure 7.1 shows groundspeed
values 20 seconds from a rig landing; the vertical axis is the number of measurements
and the horizontal axis is the groundspeed.
Similarly, where excessive numbers of events were being triggered, the
measurement data was used to determine appropriate increases in trigger levels. The
measurement data proved to be very useful for this purpose and, without it,
optimizing event trigger levels would have involved a lengthy and time consuming trial
and error process.
25 September 2002
Section 7 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.1 Groundspeed 20 Seconds from Rig Landing
The general measurements could also be used in an investigative process to obtain
background information when investigating a particular event, or to prove or disprove
a theory about a possible operational problem. For example, if an event which had
been triggered suggested a problem with a particular installation, the measurement
database could be used to obtain much more information on that installation, and
thereby help to determine whether a problem actually existed.
There were many other types of analysis which could be performed with the general
measurements. To illustrate this, Figure 7.2 shows a plot of average fuel consumption
vs. sector length. It was also possible to calculate an average fuel consumption for
each airframe.
25 September 2002
Section 7 Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
2,500.0
Average Fuel Consumption - lbs/hr
2,000.0
1,500.0
1,000.0
500.0
0.0
0.0
10.0
20.0
30.0
40.0
50.0
60.0
70.0
80.0
90.0
Average Flight Length - min
Figure 7.2 Average Fuel Consumption vs Sector Length
7.3
Mapping the helideck environment
7.3.1
Structure induced turbulence
A derived parameter was developed by BHL to provide a measure of turbulence on
an offshore approach based on rapid movements of the collective lever (the
background to this was described in Section 5.4.1.4). A histogram of the turbulence
measurements for offshore landings is shown in Figure 7.3; the vertical axis is the
number of measurements and the horizontal axis is the value of the turbulence
parameter. Where pilot initiated turbulence reports were raised they were always
associated with high turbulence measurement values, demonstrating good
correlation between the HOMP measurement data and the actual operating
environment.
Turbulence on take-off and landing offshore can result in a very high pilot workload,
with loss of control or over-torqueing an ultimate possibility. Whilst crews will
normally file a turbulence report following unexpected encounters with such
conditions, these can occasionally be omitted and certainly crews are unlikely to file
a report describing turbulence which was as expected, or a report indicating that there
was no turbulence when the HLL indicated otherwise. Having a measurement and an
associated event to detect turbulent conditions encouraged the filing of reports, and
conditions at the time could be checked against the HLL to determine whether the
level of turbulence experienced was to be expected. If the turbulence was higher
than expected, or if an aircraft limitation was exceeded whilst operating within the
HLL limits, there is clearly a need to look closely at the corresponding HLL entry and
consider an amendment.
25 September 2002
Section 7 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.3 Turbulence Indicator
Experience shows that the vast majority of offshore approaches are non-turbulent
and only a few are significantly turbulent. Therefore the histogram presented in Figure
7.3 provides a means to empirically calibrate the measurement into, perhaps, 3 levels;
low, medium and high turbulence. Values were chosen as follows:
Low:
Medium:
High:
0 to 6
6 to 9
Greater than 9
It is recognised that this calibration is subjective. Efforts are being made to
scientifically calibrate the measurement as part of separate research (described in
Section 5.4.1.4) aimed at developing a pilot workload-based turbulence criterion for
helideck design.
Having developed the turbulence measurement, it could be used to map the helideck
environment by correlating it with GPS-derived flight data measurements of wind
speed and direction. HOMP measurements gathered on routine operations could be
plotted to produce a chart for any platform showing levels of turbulence related to
wind speed and direction. On the assumption that the final approach track was flown
substantially into wind, the resulting charts could then be used to verify the
information in the HLL and to help to indicate when and where revision of the HLL
should be considered.
Figure 7.4 presents a chart of the HOMP-generated turbulence data for the Brae A
platform, which has significant operating restrictions in certain wind directions. Each
plotted point corresponds to a landing and is plotted at a position to reflect the
25 September 2002
Section 7 Page 4
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
measured wind direction (magnetic heading) and strength. Its colour represents the
amplitude of the measured turbulence parameter, split into groups of low, medium or
high values.
000°
345°T
Low
Medium
High
°
319 T
40 kts
30 kts
067°T
20 kts
10 kts
270°
090°
180°
Figure 7.4 Wind Vector and Turbulence Parameter for Brae A Platform
Figure 7.5 shows the restrictions for Brae A as published in the HLL. The restricted
sectors (true headings) have been superimposed on the turbulence data in Figure 7.4,
with a correction applied to account for the difference between true and magnetic
North. High values of the turbulence indicator correlate well with known turbulent
sectors for the platform, showing how the data can be used for ‘mapping’ the
helideck environment. The process is not entirely accurate, for example the measured
wind direction relies on the aircraft being flown in balance during the measuring
period, and the turbulence parameter is influenced by any tendency for the pilot to
over-control. One probable and one possible rogue point can be seen on the chart. A
planned improvement in the control of the wind measurements should improve the
data by eliminating any occasional inaccurate wind direction measurements. With the
large amount of data that will accumulate over time, especially once all the aircraft are
gathering data, a representative picture of the environment should be obtained.
25 September 2002
Section 7 Page 5
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.5 HLL Limitations for Brae A
A similar chart (Figure 7.6) was also produced for the Brae B. However, when
comparing the HOMP-generated turbulent points with the HLL limitations for this
platform (shown in Figure 7.7, with the restricted sector being superimposed on
Figure 7.6), the points did not appear to be in the right place. The turbulence was
being encountered with a northerly wind, whereas the HLL restricted sector was 030°
- 070° and due to the generator turbine exhausts.
25 September 2002
Section 7 Page 6
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Low
345°T
030°T
000°
Medium
High
40 kts
30 kts
20 kts
070°T
10 kts
270°
090°
180°
Figure 7.6 Wind Vector and Turbulence Parameter for Brae B Platform
25 September 2002
Section 7 Page 7
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.7 Old HLL Limitations for Brae B Platform
It was then discovered that the Brae B had been “under watch” by the BHAB
helideck team and, just a few weeks before generating the data for this report, the
HLL limitation was changed as the result of turbulence reports from pilots. The new
limitation is shown in Figure 7.8, and includes the whole sector from 345° to 070°.
The new restricted sector has also been superimposed on Figure 7.6 and it can be
seen that the HOMP-generated turbulence points are much more closely aligned with
this.
25 September 2002
Section 7 Page 8
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.8 New HLL Limitations for Brae B Platform
It is interesting to note that data identifying the need to modify the HLL limitation was
being gathered in the HOMP for some time before the HLL was actually changed.
Although in this case it merely reinforced the correctness of the change, in future it
could be used as the initial trigger for change.
25 September 2002
Section 7 Page 9
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.9 was generated as a control, using the Kittiwake platform as an example of
an installation having no HLL limitations. It can be seen that there were no recorded
encounters with medium or high levels of turbulence.
Low
000°
Medium
High
40 kts
30 kts
20 kts
10 kts
090°
270°
180°
Figure 7.9 Wind Vector and Turbulence Parameter for Kittiwake Platform
The platform is shown in Figure 7.10. The helideck is placed high up on the structure
with no significant obstructions to the airflow (wind) from any direction. Only the
drilling derrick could possibly disturb the airflow, but it is placed well away from the
helideck and has an open structure. There is also a substantial air gap between the
helideck and the accommodation block underneath it. This air gap has a significant
smoothing effect on the air flowing over the helideck, which would otherwise be
affected by mixing with the airflow disrupted by the slab-sided accommodation block
underneath.
25 September 2002
Section 7 Page 10
CAA PAPER 2002/02
Figure 7.10
7.3.2
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Kittiwake Platform
Turbine exhaust gas
Similar plots could be created for offshore platforms to show the wind vectors where
a rapid increase in OAT is detected as a result of flying through hot gas, normally from
the generator turbine exhausts. Unfortunately this was not possible with the existing
HOMP data as, with only one ‘maximum increase in OAT’ measurement being made
per flight sector, it was not known, geographically, where this increase had occurred.
To enable the measurement to be used for mapping turbine exhaust gas problems it
is necessary to have separate measurements applied in the take-off and landing
phases, so that a high value can be directly associated with a particular location. A
modification will be made to the measurement to enable this type of chart to be
generated in the future.
7.3.3
Operating differences by installation
In addition to mapping the turbulence around specific platforms, it is interesting to
review HOMP data from all installations to compare operations to different platforms.
Figure 7.11 shows the average value of the turbulence parameter (calculated over a
number of landings) plotted against installation. In order to reduce the width of the
chart, only the top 9 and bottom 10 installations are shown, which explains the
apparent step change in the middle of the chart. The turbulence parameter is actually
a reflection of pilot workload and so can be triggered not only by turbulence but also
by high workload when trying to land on a moving deck. Therefore the vertical axis of
the chart has been labelled as “average turbulence or workload”.
25 September 2002
Section 7 Page 11
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
3.5
Average Turbulence or Workload
3
2.5
2
1.5
1
0.5
AR
AX
ST
D
AL
G
IS
A
TH
LA
N
D
U
AE
M
AD
AR
R
EB
S7
12
TI
FF
Y
D
JU
N
IN
TC
D
SF
14
0
BR
N
B
AE
PR
O
N
BR
L
R
AF
PS
C
A
U
M
C
AS
AE
BR
AN
C
AP
T
0
Installation
Figure 7.11
Average of Turbulence/Workload Parameter by Installation
The top 10 installations all have features that could be expected to generate high
values of the parameter. The Captain platform (CAPT) has a large slab-sided structure
in the immediate vicinity of the helideck, and has substantial HLL restrictions as a
result. An appreciation of the problem can be gained from Figure 7.12. The
obstruction is the orange/red structure near the centre of the picture.
25 September 2002
Section 7 Page 12
CAA PAPER 2002/02
Figure 7.12
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Captain Platform
The Anasuria (ANAS) is a floating production vessel which can exhibit substantial
motion and also has a problem with generator turbine exhausts blowing over the
helideck. The Brae A has already been discussed as generating structure-induced
turbulence in certain wind directions, and the Brae B is similar though not as bad. The
Maersk Curlew (MCURL), Captain FPS (CAFPS) and Northern Producer (NPROD) are
all floating storage or production ships and are substantially less stable than a typical
semi-submersible drilling rig. The Santa-Fe 140 (SF140) has a mid-position deck which
can be difficult to land on when the wind is coming through the structure, as Figure
7.13 illustrates.
Another measure of the safety of operating to a particular installation might be the
average maximum torque required to land. If an aircraft can routinely land using less
power at a particular installation, there will be more power available to deal with any
contingencies such as unexpected conditions, poor piloting technique or an engine
failure, than there would be at an installation which routinely requires higher power to
land. Thus there is an increased probability of a favourable outcome following such a
contingency. The maximum landing torque depends on a combination of factors such
as the way the approach and landing is flown and the aircraft operating weight.
Turbulence and downdraughts can also result in increased power demands during
critical phases of the approach and landing. Figure 7.14 shows a chart of average
maximum landing torque by installation, again the chart only shows the top 9 and
bottom 10 installations.
25 September 2002
Section 7 Page 13
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.13
Santa Fe 140 Rig
80
Average Maximum Landing Torque %
75
70
65
60
55
KL
B
T
EN
10
1
C
AF
PS
04
AP
C
S7
Y
KI
TT
I
D
JU
O
D
PR
N
F
N
BA
R
T
U
O
TT
SC
W
H
N
U
AN
AS
IC
AL
FS
N
M
IT
TR
R
G
O
U
ST
AR
12
D
S7
SF
14
0
50
Installation
Figure 7.14
Average Maximum Landing Torque by Installation
It is interesting to note that the Captain platform is close to the bottom of this chart
despite its position at the top of the previous turbulence/workload chart, which shows
that turbulence problems do not result in high average power demands when landing
on the platform. This is due to a low aircraft operating weight as the Captain is one of
the nearest platforms to Aberdeen (being only 68 miles out), and only a limited
amount of fuel is required. This is illustrated by Figure 7.15, which shows the average
25 September 2002
Section 7 Page 14
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
landing weight by installation. It can be seen that operations to the Captain are
conducted at by far the lightest average weight. Work is ongoing to establish a robust
relationship between landing weight and torque to enable the data in Figure 7.14 to
be directly related to other factors such as turbulence and downdrafts, and the way
the approach is flown.
17800
Average Landing Weight (lbs)
17600
17400
17200
17000
16800
T
AP
N
F
BA
C
04
R
S7
PS
Y
O
D
N
PR
C
AF
N
JU
D
AU
R
M
AE
G
AL
AX
0
14
C
EB
R
SF
H
TD
U
R
M
IC
N
N
BR
12
T
TA
N
BR
S7
U
IS
H
N
KA
AU
M
AG
N
W
H
U
T
16600
Installation
Figure 7.15
Average Landing Weight by Installation
Figure 7.15 shows the platforms with the top 10 and bottom 9 average landing
weights; the Santa Fe 140 has also been included, even though it is outside the top
10. The chart shows that this installation is close to the top in terms of average aircraft
landing weight. This position, combined with the high average values for the
turbulence/workload parameter (the Santa Fe 140 was ranked number 9 in Figure
7.11), help to explain why the installation has the highest average maximum landing
torque (ranking top in Figure 7.14).
However, an additional factor is that, with the wind blowing through the structure,
and the difficulty of approaching out of wind in the Super Puma, it is difficult to
achieve an optimal approach to the Santa Fe 140 (see Figure 7.13). If the approach is
flown more or less straight towards the installation, there are very poor options for
going around in the late stages of the approach, and serious consequences if the
approach is flown too fast and the helideck overshot. Alternatively, if the normal
approach technique is used and the approach flown to a point sufficiently offset
laterally from the helideck to miss the structure in the event of a single-engine goaround, there is a substantial distance to be traversed after the committal point.
Neither technique is very satisfactory and both can result in pilots flying a slower
approach with a resultant higher torque, their normal technique having to be modified
with a commensurate reduction in safety margin.
25 September 2002
Section 7 Page 15
CAA PAPER 2002/02
7.4
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Offshore take-off and landing profile measurements
A set of offshore take-off and landing profile measurements were implemented in the
HOMP trial to characterise take-offs and landings by combining measurements at
specific milestones or action points. The measurements are listed in Table 4.6 in
Section 4.
For Performance Class 2 helicopter operations to/from a helideck, the main
consideration is the exposure time. Performance Class 2 operations are defined in
JAR-OPS 3.480 as “those operations such that, in the event of critical power unit
failure, performance is available to enable the helicopter to safely continue the flight,
except where failure occurs early during the take-off manoeuvre or late in the landing
manoeuvre, in which case a forced landing may be required”. Exposure time is
defined as “the actual period during which the performance of the helicopter with the
critical power unit inoperative in still air does not guarantee a safe forced landing or a
safe continuation of the flight”. An engine failure during the exposure time can result
in a deck edge strike or a ditching.
7.4.1
Offshore take-off profile
7.4.1.1 Exposure to a deck edge strike
North Sea helicopter Operations Manuals contain advice on offshore take-off profiles,
derived from a Helicopter Airfield Performance Simulation (HAPS) computer model
(developed by Westland Helicopters), and associated validation flight trials. The
modelling defined exposure to a 'deck edge' strike, and was used to produce advice
on optimum rotation heights, rotation rates and rotation angles aimed at minimising
this exposure.
On every offshore take-off the HOMP measured the maximum nose down pitch
angle during the take-off rotation, the maximum rotation rate, and the rotation height.
The data provided information on the extent to which the Operations Manual advice
was being followed.
Figures 7.16 and 7.17 show histograms of measurements of the maximum nose
down pitch angle and pitch rate, respectively, during rotations on offshore take-offs.
The histograms indicate that aircraft rotated to an average maximum nose down
attitude of 10 to 11 degrees at an average rate of 4.5 to 5.0 degrees/second. For a
normal all-engines-operating take-off, the Operations Manual advice is to rotate the
helicopter up to 8 degrees nose down, but no rotation rate is specified. In the event
of an engine failure after the committal point (input of forward cyclic) the advice is to
rotate up to 20 degrees nose down at a rate of 10 degrees/second.
25 September 2002
Section 7 Page 16
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 7.16
Maximum Pitch Angle
Figure 7.17
Maximum Rotation (Pitch) Rate
25 September 2002
Section 7 Page 17
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The optimum nose down attitude actually varies with wind speed. For light winds a
larger nose down angle is needed to clear the edge of the deck and accelerate the
aircraft to the fly-away speed as quickly as possible. As the airspeed starts to build,
the nose down attitude can be reduced to prevent a descent starting so that the
manoeuvre does not result in loss of height. For strong winds, the aircraft will already
be below its single-engine hover weight, so power is not an issue. A large nose down
attitude would almost certainly result in a descending flight path and a reduced angle
is therefore used. The Operations Manual does not refer to wind speed for an allengines-operating take-off, but for engine failure case it advises: “As the wind speed
increases the nose down attitude on rotation may be reduced, such that at 40 knots
wind speed, only approximately 8 degrees nose down is required.”
The charts presented in Figures 7.18 and 7.19 show the maximum nose down angle
during rotation data grouped into flights where the wind was 0 to 10 kts and 30 to 50
kts respectively. The charts showed that the average maximum nose down angle in
light winds was 12-13 degrees, and in stronger winds it was 9-10 degrees. This
indicated that crews were, in general, using the correct technique, employing a
reduced nose down angle at higher wind speeds.
Figure 7.18
25 September 2002
Maximum Pitch Down Angle – winds between 0 and 10 kts
Section 7 Page 18
CAA PAPER 2002/02
Figure 7.19
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Maximum Pitch Down Angle – Winds Between 30 and 50 kts
Figure 7.20 presents a histogram showing the distribution of rotation heights on an
offshore take-off (defined for the measurement as the height at which the rotation
rate was a maximum). The mean rotation height was 35-40 feet. The Operations
Manual advises a height of 25 feet for the committal point, i.e. the input of forward
cyclic. The aircraft will still be climbing as it reaches the HOMP measurement point,
which is at the maximum rate of pitching, a few moments later. The difference
between the mean measurement value and the Operations Manual figure was
approximately as expected, which indicated that the advice was being followed.
Some shortcomings in the take-off manoeuvre characterisation used have resulted in
the falsely extended tails of the distributions. These indicate some of the problems
that can be encountered when attempting to characterise a manoeuvre such as a
take-off rotation from flight parameters. Investigation has shown that the very low
height measurements were incorrect, as a high rotation rate could occur if an aircraft
lifted off into the hover in a strong head wind. There is scope for improving the
measurement to eliminate this effect. In addition, the very high values could be
caused by a small increase in rotation rate well into the rotation manoeuvre. However
some of the high values may well be correct because under certain circumstances it
is quite reasonable to continue the vertical climb even though committal has already
been passed (i.e. rejecting the take-off is no longer an option). Should an engine
failure occur, the aircraft would be rotated nose down and flown away.
25 September 2002
Section 7 Page 19
CAA PAPER 2002/02
Figure 7.20
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Rotation Height
7.4.1.2 Exposure to ditching
After the end of the exposure to a deck edge strike, exposure to ditching continues
until adequate fly-away speed is reached. This 'exposure to a ditching' is more
complex than the deck-edge case as it is dependent upon additional variables –
aircraft weight, wind speed, height of helideck, clear area for drop down and pilot
technique. Exposure to ditching is therefore location dependent. The subject is
further complicated because the prediction from manufacturers is that exposure to
engine failure ends at an air speed (Vfly-away) of between 15 kts and 35 kts, which is
not within current measuring capabilities.
To provide a general indication of the maximum possible exposure time, HOMP data
was used to determine the time taken to reach 35 kts airspeed from the beginning of
the take-off rotation manoeuvre. From this speed, only slight or no loss of height
would be required to reach minimum climbing speed Vtoss (45 kts). The results are
presented in Figure 7.21. The mean of the measured maximum exposure times, as
indicated by the 50% point on the cumulative percentage graph, was 4.5 seconds.
This figure could be used for comparison with an ‘allowed exposure’ determined from
engine reliability data. Most installations have a significantly elevated helideck and so,
once clear of the deck edge, this height can be converted into speed by diving the
aircraft, which will result in shorter actual exposure times.
25 September 2002
Section 7 Page 20
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Rig Take-off: Time to 35kts
700
100
90
600
80
500
70
60
Frequency
400
50 %
Frequency
Cumulative %
300
40
30
200
20
100
10
0
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Time (seconds)
Figure 7.21
Time to 35 kts on Offshore Take-off
For completeness, Figure 7.22 shows a similar plot of the time to 70 kts. This is the
best rate of climb speed (Vy) for the AS332L, and is the point at which the
Performance Class 2 profile ends.
25 September 2002
Section 7 Page 21
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Rig Take-off: Time to 70kts
600
100
90
500
80
70
400
Frequency
60
50 %
300
Frequency
Cumulative %
40
200
30
20
100
10
0
0
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Time (seconds)
Figure 7.22
7.4.2
Time to 70 kts on Offshore Take-off
Offshore landing profile
To provide information on final approach heights and elevations in support of helideck
lighting research, the CAA requested the implementation of 12 flight data
measurements to generate a vertical profile of the final approach to landing. To
overcome the lack of sufficient resolution in the recorded GPS latitude and longitude
data the profile measurements were created by using groundspeed, heading and drift
to calculate the track back from landing.
Figure 7.23 shows the angle of elevation above the helideck in degrees at a point
0.3 nm from touchdown, for night landings on offshore installations. The mean angle
was approximately 5.5 degrees, which was as expected. The peak in the chart at 3
degrees was probably a result of the fact that the data included some Airborne Radar
Approaches in poor weather, where the final approach might have started from as
little as 50 feet above deck height. Figure 7.24 is similar but shows elevation at 0.6
nm from touchdown. The mean angle was approximately 4 degrees. This lower figure
was probably due to the fact that the final approach may sometimes not have started
until nearer than 0.6 nm, which could be the case in bad weather or during shuttling.
25 September 2002
Section 7 Page 22
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Rig Landing at night:Elevation at 0.3nm
35
120
30
100
25
80
Frequency
20
60
Frequency
Cumumlative %
15
40
10
20
5
0
0
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
8.5
9
9.5
10
10.5
11
11.5
Elevation (degrees)
Figure 7.23
Elevation above helideck at 0.3 nm from touchdown at night
Rig Landing at night:Elevation at 0.6nm
40
120
35
100
30
80
Frequency
25
60
20
Frequency
Cumumlative %
15
40
10
20
5
0
0
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
8.5
9.5
10
10.5
Elevation (degrees)
Figure 7.24
25 September 2002
Elevation above helideck at 0.6 nm from touchdown at night
Section 7 Page 23
CAA PAPER 2002/02
7.5
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Discussion
The HOMP flight data measurements enabled the routine gathering of large amounts
of operational data. The resulting information was a valuable complement to the flight
data events. Whereas the events identified exceedances of predefined operational
limits, the measurements could be used to identify variations in the operation caused
by installation, crew or aircraft factors. These variations may be the underlying cause
of events or other increased operational risks.
The general measurements provided the data needed to set effective event limits,
and could be used as reference data for assessing the degree of abnormality of an
event. The measurements also provided a database of information to investigate
hypotheses on potential operational problems.
The HOMP trial also showed that the flight data measurements are a powerful tool
for ‘mapping the helideck environment’. By routinely providing quantitative data on
installations related to wind direction and speed, the measurements produced
significant new information for the development and refinement of HLL entries.
The flight profile measurements generated valuable information on offshore take-offs
and landings, and were used to assess risks such as single engine failure exposure.
By checking that optimal take-off profiles were being flown, the HOMP
measurements could be used to ensure that any such risks were minimised.
The HOMP trial demonstrated the flexibility of the measurement analysis, with new
measurements quickly being implemented to generate information to support a
particular investigation. A good example of this was the implementation of vertical
final approach profile measurements to produce information to support the CAA’s
helideck lighting research.
The trial highlighted the importance to taking care to ensure that measurements are
actually providing the required information, and that results are not distorted by
measurement problems, or by difficulties in characterising a particular flight
manoeuvre.
Performing investigations using the database of measurements could be a time
consuming exercise, and therefore resource constraints may limit the ability to make
full use of it. There is scope for further enhancing the value of the flight data
measurements through the application of data mining tools to the measurement
database.
25 September 2002
Section 7 Page 24
CAA PAPER 2002/02
Section 8
8.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP Trial results – HOMP operations
Implementing the HOMP within BHL
One of the aims of the second year of the trial was to determine how a HOMP might
be integrated into the existing flight safety organisation of an operator. The starting
point was Figure 3.3, presented in Section 3.4, which provides a model for the basic
HOMP management process.
Within the project steering committee there was a diversity of views on how the
HOMP process might best be integrated into existing structures, ranging from
incorporating the HOMP into the Flight Safety Department, to making the HOMP
Manager directly responsible to the Chief Executive. This debate reflected the variety
of different organisational structures adopted by fixed wing FDM operators. After
internal discussions on how a full scale HOMP should be implemented within BHL,
the following proposals were developed.
The HOMP Manager will report directly to the Head of Flight Operations because, as
the AOC-holder, he is ultimately responsible for any incidents or accidents. However,
to maintain crew confidentiality, the Head of Flight Operations will have no right of
access to the identities of any crew members involved in HOMP-detected incidents
or trends.
The HOMP Manager will maintain close links with the Flight Safety Department and
will be able to discuss individual incidents with the company Flight Safety Officer.
Detailed discussions of incidents, especially where an individual’s history might be
relevant, may require the crew’s identity to be revealed to the Flight Safety Officer.
Where an incident involves a fleet on which the HOMP Manager has no experience,
the appropriate Fleet Representative may also be involved.
The HOMP Manager, the Flight Safety Officer and the relevant Fleet Representative
will form a HOMP “inner sanctum”, and will be able to discuss identified incidents.
Crew identities will not be revealed outside this group except in the very exceptional
circumstances laid down in Item 4 of the HOMP Management Statement presented
in Appendix 1 to Section 8.
Regular review meetings, chaired by the HOMP Manager, will be held to allow a
range of HOMP issues to be discussed (e.g. system updates, event trends, training
issues etc.). These meetings will be on one of two levels; either involving only the
“inner sanctum”, in which case there may be no need for dis-identification of data, or
involving other interested parties such as the Head of Flight Operations, Chief
Training Captains, Base Flight Safety Representatives, and/or the Training and Flying
Standards Manager, in which case all data and discussions will be dis-identified.
The proposed BHL HOMP management process is summarised in Figure 8.1, which
is a slightly modified version of Figure 3.3.
25 September 2002
Section 8 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Figure 8.1 BHL HOMP Management Process
The dissemination of (dis-identified) HOMP information will be a very important part
of a HOMP and will take two forms; the regular publication of HOMP newsletters,
primarily aimed at flight crews, and the regular publication of HOMP event rate and
trend information, primarily aimed at the Head of Flight Operations, but also made
available to flight crews. Newsletters and any other lessons learned will also be
passed on to other relevant operators and it is hoped that they will reciprocate.
The use of local Base Representatives will form an optional part of BHL’s structure.
Base Reps would be used to make contact with crew members at their base to
discuss any HOMP-detected events with them, both to gather any necessary data for
the HOMP Manager and to pass on any feedback. Their primary purpose would be to
overcome the human factors difficulties of remotely communicating sensitive HOMP
issues between strangers. The face-to-face approach from a known peer is far
preferable. It is critical that Base Reps are carefully chosen to ensure that the required
standards of integrity, impartiality and confidentiality are maintained.
HOMP events will be assessed for their hazard severity and, where an event or trend
represents an unacceptable hazard, remedial actions must be recommended. It will
be very important to ensure that any recommended actions resulting from HOMP
investigations are followed up to ensure that they have been carried out. Ultimately
many of these actions will be the responsibility of other personnel or departments,
and the HOMP Manager is not empowered to over-rule them if they decline to enact
the recommendations. In such cases, and in any case where it is decided that action
is not appropriate, this should be recorded against the incident with the reasons
given. It will also be necessary to monitor for any recurrence of events to ensure that
any corrective action has been successful. An “audit trail” must be produced for any
significant event or adverse trend identified.
25 September 2002
Section 8 Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The FDE module can be used in the follow-up process as it enables progress to be
recorded, however it does not contain the same depth of follow-up tools as are
provided in the BASIS ASR module (which is not part of the HOMP system). For a full
HOMP implementation it will be necessary to formalise the follow-up process,
possibly including a computer database system to facilitate retrieval of outstanding
issues.
In its relationship with BHL’s existing Safety Management System (SMS), the HOMP
should occupy a similar position to the Flight Safety Department, in that it is
independent of the company’s SMS personnel, but uses processes borrowed from
the SMS and passes information on trends and events back to the SMS Department.
It would, of course, be subject to auditing for effectiveness by SMS personnel from
time to time.
8.2
HOMP policy statements and agreements
When a full scale HOMP is implemented, it will become a formal element of the
company’s Safety Management System and, as such, there will be a need for a
formal statement or agreement on the conduct of the HOMP from senior
management.
The preferred option is to have an agreement between management and aircrew, but
this would require a body representing all the aircrew to be a signatory. Because BHL
aircrew are only partly unionised, it was not thought appropriate for BALPA to be this
signatory and so the only option was to produce a management policy statement.
After some discussions between the HOMP Manager and the Head of Flight
Operations, a document was produced, but by the end of the trial this was still only
in draft form and had not been signed. It will need to be formally adopted and signed
before the programme expands to become company-wide. The document is
presented in Appendix 1 to Section 8. Although it is in the form of a statement, with
minor revision it could become an agreement between management and an aircrew
union or other pilot-representing organisation.
25 September 2002
Section 8 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Appendix 1 to Section 8
Draft BHL Management Statement
Helicopter Operational Monitoring Programme (HOMP)
Statement from Bristow Helicopters Ltd
1
Introduction
The management of Bristow Helicopters Ltd (BHL) recognises the significant flight
safety benefits to be gained from a Flight Data Monitoring (FDM) programme. HOMP
is the programme that is used by BHL.
The technology behind HOMP, like any other tool, needs to be understood and
applied intelligently for it to be useful. We recognise that the key element to the
success of an FDM programme is that information gained from HOMP is used
correctly and not inappropriately or punitively.
The purpose of this statement is to set out the processes that will be followed during
the day-to-day running of the programme, and the special procedures that might be
required under extreme circumstances.
2
HOMP Philosophy
Before the advent of operational flight data monitoring programmes such as HOMP,
flight data was only stored in a crash-protected recorder. This was over-written after
a short time and was only downloaded and reviewed in the event of a reported
incident or accident. The very large volume of data that was never reviewed,
contained information on operating hazards and minor or “near miss” events.
Analysing these events would provide valuable information which could be used to
improve operational procedures and enhance flight safety.
The key benefit is the ability to learn from “near misses”, whether due to crew errors
or external factors. “Near misses” can occur with or without the crew’s knowledge,
and both crews and operational management will benefit from the information
revealed. It is also useful to trend the occurrence rates of such events to alert
management and crews alike to any areas of the operation requiring review.
HOMP also records a large number of measurements on every flight sector, and this
information is used to obtain an indication of normality. It can also be used to generate
information on specific factors such as the turbulence around specific platforms in
specific wind conditions.
Maintaining the confidentiality of the data associated with HOMP events is a vital
component of HOMP. All concerned with HOMP must ensure that the system
remains non-punitive and is not seen as a “spy in the cab”, and to achieve this it is
important that only the minimum number of people are able to identify the crew
involved in a specific incident. In HOMP, crew identities are stored in a database as
encrypted numbers, and only the HOMP Manager is able to decode the number to
reveal an identity. During the course of event investigations and follow-ups, if he
considers it is appropriate he is permitted to reveal crew identity to specified
individuals, these being limited to the Group Flight Safety Officer and the relevant
25 September 2002
Appendix 1 to Section 8
Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Fleet Representative and/or Base Representative, who are not at liberty to pass this
on.
BHL management accept and agree that they have no access to any information or
data from the HOMP system that would allow the identity of a crew member to be
linked to any HOMP-detected events or trends, except under the special
circumstances described in paragraph 4.
External bodies, including the charterers of our aircraft, will not be given information
about particular HOMP events except with the agreement of management and with
the permission of all members of the crew. However, regulatory authorities and
statutory accident investigation authorities may be given access to such information
as is required by statute.
3
Normal HOMP functions
The HOMP shall be run under the control of the HOMP Manager. So that he can
maintain a realistic perspective on company flight operations, he shall be a company
pilot who has carried out regular line flying duties within the last 3 years.
As much flight data as practical shall be gathered and processed by the HOMP
system. Events detected by the system are reviewed to validate the data. Where
events are considered by the HOMP Manager to be significant, they shall be
reviewed by the appropriate Fleet Representative, who will assist the HOMP
Manager in determining whether the crew need to be contacted. If so, the HOMP
Manager will invoke the appropriate procedure. Events may also be reviewed at
routine meetings attended by the HOMP Manager, the Group Flight Safety Officer
and the relevant Fleet Representative.
Review meetings will also be held with other members of staff such as the Head of
Flight Operations, the Flying and Training Standards Manager, and Chief Training
Captains but, in this case, no information that could lead to the identification of crews
shall be revealed.
If the crew are to be contacted, this shall be done by the HOMP Manager, Group
Flight Safety Officer, the appropriate Fleet Representative or appropriate Base
Representative, as determined by the HOMP Manager. The contact may take any
form, such as face-to-face (which is the preferred means), by telephone, letter or
email. The purpose of the contact is to further investigate and validate the event and,
if appropriate, to give feedback on the crew’s actions and allow them to learn from
any mistakes made. If appropriate, and not already done, the crew will be encouraged
to file an ASR.
Where there might be considered to be an element of crew error, both crew
members will be contacted as near simultaneously as reasonably practical and no
data will be given to a crew member until both have been contacted. Crew members
will be advised that they should not divulge the name of their colleague in any
discussions of the event with third parties.
A HOMP newsletter shall be produced from time to time, describing events and
trends that have occurred, in a way that does not identify the individuals involved. The
permission of crews involved shall not be required for this activity.
It may be appropriate to send identified HOMP data to other Bristow employees or
external companies to assist in the investigation of incidents. In this case, the
permission of both crew members shall be obtained before this takes place.
25 September 2002
Appendix 1 to Section 8
Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The HOMP Manager may occasionally consider it appropriate to try to direct routine
training towards remedying a particular problem that an individual is having. This will
only take place following discussion with the individual concerned and after the
permission of the individual is obtained. The Training Captain programmed to give the
training may then be informed of the individual’s name and the nature of the problem.
This information shall be passed informally and in confidence, and it shall not go into
the individual’s training records.
Following an incident or accident that has been detected solely by normal (nonHOMP) means, normal HOMP procedures will be followed and the HOMP data shall
not be available to company investigators unless at least one of the following applies:
a) All crew members give their permission.
b) The company decides to download the aircraft’s FDR, and the relevant flight data
is successfully recovered.
c) The HOMP data is required by the AAIB.
If, in the HOMP Manager’s opinion, the event is of a purely technical nature, relevant
data may be passed to engineering to assist with diagnoses.
An illustration of the company’s HOMP organisation is shown in Annex 1 (not shown
here, but identical to Figure 8.1 in Section 8.1 of this report).
4
Procedures to be followed during exceptional circumstances
Although the company recognises that confidentiality is a vital element of HOMP
they, and all flight crew, also have a duty of care to the company’s passengers.
Therefore under extreme circumstances it may be necessary to consider the removal
of confidentiality of the name of an individual or crew. This might occur following an
incident where gross negligence has occurred, or following a series of incidents
where no progress has been made to reduce the likelihood of recurrence. The
initiative for the removal of confidentiality may come either from the Head of Flight
Operations, the HOMP Manager or the Group Flight Safety Officer.
Under these circumstances a meeting shall be convened to make the decision,
chaired by the HOMP Manager and attended by the Group Flight Safety Officer. The
pilot concerned will be invited to send a representative, either a friend or a member
of the BALPA company council, to attend the meeting if he wishes. The meeting shall
not be attended by company management nor by the pilot in question.
Following examination of any relevant factors, the meeting shall decide the outcome
of the application to remove confidentiality by a majority vote of all attendees. In the
event of a tie, confidentiality shall not be removed. The chairman of the meeting will
give written reasons for its decision to the initiator and the pilot concerned.
………...........................………………..
……...........…………………………...........
Peter Barnes
Head of Flight Operations, Europe
Neill Osborne
Director, Europe
25 September 2002
Appendix 1 to Section 8
Page 3
CAA PAPER 2002/02
Section 9
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
HOMP Full Scale Implementation
This section briefly considers the requirements for a full scale HOMP implementation
and estimates the associated costs.
9.1
HOMP requirements
9.1.1
Equipment
Equipment requirements are summarised below; detailed information on
requirements can be obtained from the HOMP trial equipment description in Section
4.
• PC card QARs to provide ready access to aircraft flight data (it is assumed that the
existing aircraft flight data acquisition units are all provided with auxiliary outputs
for a QAR interface).
• Aircraft modification kits.
• PC cards for the transferring of flight data from the aircraft to the ground (3 cards
per aircraft should be provided).
• Ground based hardware, including a high specification data analysis PC with a large
monitor, large capacity hard disk, A3 colour printer and PC card reader. Also data
download PCs for remote bases, and portable PCs to support away from base
operations, all with PC card readers. It is important that the data analysis PC is
dedicated to the HOMP, and not used for any other purpose.
• Data transfer and archive media. If possible, company networks or the Internet
should be used for the electronic transfer of data from remote bases.
• Data replay and analysis software for the HOMP analysis centre. This software
should provide comprehensive HOMP data analysis and management facilities,
performing both event and measurement analyses, and incorporating the tools for
the review and analysis of data and data trends. Additional copies of the software
might be required to provide a data analysis capability for aircraft detached away
from base for a time.
9.1.2
Facilities
Office facilities are required, with telephone, email, and access to operations
databases, weather information etc. There should be enough space for discussions
between crew and the HOMP Manager, as well as for any full-time HOMP staff.
Secure facilities must be provided for the storage of all HOMP data.
9.1.3
Organisational structures and procedures
It is vital that well defined HOMP organisational structures, processes and procedures
are developed and implemented. Any programme operating without these will only
have limited success. Models for the HOMP procedures are presented in Sections 2
and 8 of the report. Additional guidance can be obtained from References [4] and [5].
9.1.4
Personnel
Numbers of personnel will depend on the size of the operation. A HOMP may include
a dedicated technician who would be responsible for the daily tasks of downloading
and processing data, eliminating obviously spurious events, producing trends and
reports and interacting with software developers. He would need to have some
25 September 2002
Section 9 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
computer skills and knowledge of flight operations, but need not be an expert in
either.
A HOMP Manager will be required, and he should be a current pilot, ideally a training
captain. If no technician is provided, more time would be required from the HOMP
Manager and he would need some computer skills. Another approach would be to
contract out the routine downloading and replay tasks to a specialist third party. While
this would require less time and computing skills from the HOMP Manager, he would
still retain full responsibility for the programme.
Additional input will be required from a Fleet Representative for each of the fleets
included in the HOMP to address fleet-specific issues.
It is very important that the HOMP is properly resourced, a failure to adequately
resource the programme will prevent it from being effective. Procedures must be put
in place to provide adequate cover during any periods of absence of key HOMP
personnel.
9.1.5
Agreements
It is strongly recommended that a written agreement between aircrew and company
management be established before the programme starts. This agreement should
clearly state the objectives of the HOMP, and that the programme is non-punitive and
focussed on providing positive feedback. It should be based on the requirement for
confidentiality of aircrew identity, and management and aircrew must indicate that
they have placed their trust in the HOMP Manager’s discretion. In the case of charter
operations, management must also ensure that their clients are aware that they have
no right of access to crew-identified information under any circumstances.
The agreement should make provision for the removal of anonymity only under the
most extreme circumstances or when all other avenues have failed, and the HOMP
Manager is likely to be the only person in possession of sufficient information to make
that decision. The information contained in Sections 2 and 8 of the report can be used
as the basis for an agreement.
9.2
Estimated HOMP implementation and operating costs
This section estimates costs for the implementation and operation of a HOMP. The
cost data is only intended to be used for assessing the rough order of magnitude of
the HOMP costs.
9.2.1
Assumptions
Costs are estimated based on the following assumptions:
• Operators have total fleet sizes of 10, 20 or 40 helicopters
• The operator typically has 3 helicopter fleets (e.g. S61, AS332, S76)
• The operator has one HOMP data analysis centre
• The operator typically has one main base and other satellite bases
9.2.2
Start-up costs
9.2.2.1 On-aircraft system
The PCMCIA Card Quick Access Recorder (CQAR) costs were estimated by BAE
Systems. It is assumed that there is a 20% spares holding of CQARs (e.g. 12 CQARs
for a fleet of 10 aircraft), that PCMCIA cards cost £125 per card, and that there are 3
cards per aircraft.
25 September 2002
Section 9 Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
The aircraft modification cost has been estimated by BHL and will cover design of the
modification, production of mod kits and embodiment of modification. If BHL
produced the modification for the AS332, S-61, S-76 (various models) and AS365, and
made kits for a total of 70 aircraft, the design, kit manufacture and installation would
be in the order of £1,200 per aircraft.
The on-aircraft system costs for the different total fleet sizes are shown in Table 9.1,
with the total costs rounded up to the nearest £5k.
Table 9.1
Fleet Size
CQARs
PCMCIA
Cards
Aircraft
Modification
Total Cost
10
£71,000
£4,000
£12,000
£90,000
20
£142,000
£8,000
£24,000
£175,000
40
£256,000
£15,000
£48,000
£320,000
9.2.2.2 Ground-based system
It is assumed that there is one main analysis PC, 2 satellite base PCs for remote data
download and transfer to a central analysis facility, and 2 laptop PCs to support data
collection from aircraft detached away from base for a time. Including media, a total
cost of £8,000 has been estimated for the ground based hardware.
HOMP software (excluding aircraft specific configuration) and system configuration
costs have been estimated by BA and ES-S and assume that the HOMP system will
support 3 helicopter fleets. Software costs will vary according to the number of
helicopter fleets, and for 3 fleets costs are estimated to be in the order of £50,000.
The configuration task includes configuring decode equations, reviewing events and
measurements with the operator, configuring them and testing the configured
system. Configuration costs are estimated to be £10,000 for one helicopter fleet and
£20,000 for 3 fleets.
The total ground-based system costs, rounded up to the nearest £5k, are therefore
estimated to be in the region of £80,000. If there is a requirement for a second copy
of the HOMP software to enable data analysis at another base, an additional software
cost of £10,000 should be included for this.
9.2.2.3 System introduction
The operator’s personnel who will have responsibility for managing the HOMP would
be expected to implement the programme (defining procedures, put agreements in
place etc). The Flight Safety Officer would also be expected to have some
involvement in this process.
The same operator’s personnel would be responsible for commissioning the HOMP
system, but an allowance of £10,000 could be made for external training and support
during a period of system commissioning when the data analysis is tuned to control
event rates etc.
9.2.3
Operating costs
9.2.3.1 Programme operation
It is assumed that the HOMP is run ‘in house’ by the operator, and costs will primarily
be determined by personnel requirements. For a total of 30+ aircraft in 3 fleets, these
are estimated by BHL to be:
25 September 2002
Section 9 Page 3
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
• One full-time technician.
• One part-time HOMP Manager, allocating one-third of his time to the HOMP.
• One part-time Fleet Representative for each fleet, allocating one-quarter of his
time to the HOMP.
• The Flight Safety Officer, allocating one-quarter his time to the HOMP.
The manpower costs for operating the HOMP are estimated to be in the order of
£130,000 per annum.
9.2.3.2 Software maintenance and support
Assuming that the cost of software maintenance and support is 20% of the purchase
price per annum, this cost would be approximately £10,000 a year.
9.2.3.3 System management
System management tasks can include the following items (N.B. some or all of these
might be included under the heading of "programme operation"):
• Management of software updates.
• Management of system configuration for events and measurements.
• Periodic system tests to check that all events and measurements are working.
• Periodic review of the events database to identify events not triggering or
triggering too frequently.
• Managing special HOMP investigations and analyses.
• System configuration and document control.
The above tasks could be performed ‘in-house’ by the operator, or performed with
third party support. If some third party support is assumed, an additional allowance of
£10,000 per annum could be included for this.
9.2.3.4 Start-up cost comparison with HUMS/FDR
The total HOMP start up costs shown in Sections 9.2.2.1 and 9.2.2.2 are summarised
in Table 9.2, in which per-aircraft costs are also calculated.
Table 9.2
Total
Fleet
Size
On-aircraft
System
Per
Aircraft
Total
Ground-based
System
Per
Aircraft
Total
Combined Total
Per
Aircraft
Total
10
£9,000
£90,000
£8,000
£80,000
£17,000
£170,000
20
£8,750
£175,000
£4,000
£80,000
£12,750
£255,000
40
£8,000
£320,000
£2,000
£80,000
£10,000
£400,000
It can be seen that the total per-aircraft HOMP start-up costs are in the range £10,000£17,000. This compares with a rough order of magnitude per-aircraft start-up cost of
£250,000 for a complete HUMS/FDR installation (comprising the complete retrofit kit
and the installation work). It is recognised that a significant percentage of this cost
related to the fitting of the FDR which was a mandatory requirement. Because of the
25 September 2002
Section 9 Page 4
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
synergy between the systems, the opportunity was taken to install a HUMS at the
same time and, as a result of its proven safety benefits, this system has now been
mandated for the larger helicopters in the UK.
The existence of an FDR is an essential pre-requisite for a HOMP. With its relatively
low incremental costs, the HOMP benefits from the initial investment made in the
FDR system, whilst being able to unlock significant additional safety benefit inherent
in this.
25 September 2002
Section 9 Page 5
CAA PAPER 2002/02
Section 10
10.1
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Conclusions
Conclusions related to the objectives of the HOMP trial defined in
Section 3.2
Objective 1: Establish how best to monitor helicopter flight operations.
Comprehensive sets of helicopter flight data events and measurements were
developed and then refined throughout the operational phase of the trial
(Section 4.4). The results demonstrated that they successfully monitored
helicopter flight operations (Sections 5.4, 6 and 7).
Objective 2: Evaluate the safety benefits of this monitoring.
Although the trial HOMP implementation was limited to five aircraft it was
extremely successful in identifying significant safety issues, and the operator
was able to take corrective and preventative measures to address them
(Section 6.3). The trial clearly demonstrated that the HOMP is a practical and
cost effective flight safety tool, able to bring about improvements in flying
practice, training, operating procedures and coping with the operational
environment.
Objective 3: Evaluate the tools and equipment required for a HOMP and eliminate
any technical risks associated with these.
The CQAR data recorders were very reliable. A total of approximately 11,500
hours of data was gathered during the trial and a data collection rate of 90-95%
was achieved, which is comparable to the best current fixed wing systems
(Section 5.2). The data replay and analysis software performed well, and
functionality was further enhanced as a result of experience gained during the
trial (Section 5.3).
Objective 4: Establish and evaluate a programme management strategy.
Aided by direction from the integrated project team, the operator was able to
manage and operate the HOMP effectively. Management issues were
identified and addressed (Section 5.5) and, based on the trial experience, a
suitable HOMP management strategy was developed (Section 8.1).
Objective 5: Determine the workload a HOMP would impose on a typical helicopter
operator.
The trial was run successfully by the BHL HOMP Manager (a senior training
captain) on a part-time basis. Typically one hour per day was spent on routine
tasks with additional time being required during the follow-up of specific events.
This was regarded as acceptable by BHL. There was some conflict between
HOMP activities and flying duties during busy operational periods, and the trial
highlighted the importance of properly resourcing the programme (Section 5.5).
Objective 6: Establish agreements between aircrew and management to ensure that
the identity of aircrew is protected, and the focus is on positive
feedback.
A statement of intent was issued by the HOMP Manager at the start of the trial
but, as yet, no formal agreement has been put in place between management
and crew. However, aircrew response to feedback has been positive. A draft
25 September 2002
Section 10 Page 1
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
policy statement has been developed and included in the report as the basis for
a future aircrew agreement (Section 8.2).
Objective 7: Further expose industry to the concept of a HOMP, enabling a more
informed consideration of its full scale implementation.
A number of briefings have been given along with conference papers and
magazine articles to promulgate the results of the trial. As a result, UKOOA
have committed their members to require the implementation of HOMP on all
FDR equipped UK public transport helicopters operating over the UK
Continental Shelf.
10.2
Additional conclusions
1 The trial successfully applied the concept of Flight Data Monitoring (FDM) to FDRequipped helicopters. Helicopter flight data currently remains locked away in a
crash protected recorder until after an incident or accident has occurred. The trial
demonstrated a near term, low risk and cost effective method of making pro-active
use of this flight data to bring about a significant improvement in the safety of
helicopter operations.
2 The HOMP detected a wide variety of events, and the follow-up of them identified
a range of operational issues relating to pilot knowledge and skill, gaps in the
training system, cockpit resource management, operating procedures and the
offshore environment. A number of the most notable events detected could be
related to previous North Sea helicopter incidents and accidents (Section 6.3). In
addition, by being able to monitor the occurrence rate of particular events, the
event trend analysis enabled operational risks to be more accurately assessed.
(Section 6.2).
3 BHL implemented effective processes for investigating events, following them up
with aircrew when necessary, and closing the loop by providing positive feedback
and initiating appropriate safety related actions. A range of feedback mechanisms
were successfully utilised, such as confidential pilot debriefs, prompting the raising
of Air Safety Reports, contact with safety and training staff, and issuing
newsletters. Aircrew were receptive to confidential feedback on significant events
and also, on occasion, requested information from the programme (Section 5.5).
4 Although by the end of the trial 90% of the events being generated were still
classed as nuisance or false events, this apparently high rate was not a problem
owing to the low total number of events being generated and the quickness with
which nuisance or false events could be identified (Section 5.4). The number of
nuisance events accepted is largely a matter of choice, event limits could be
changed to reduce these, however events pointing to significant occurrences could
then be missed.
5 The analysis of flight data measurements from every flight was shown to be a
powerful and flexible tool for assessing information on routine offshore operations
that had not previously been available (Section 7). This was useful in setting event
limits and identifying operational variations that may reveal the underlying causes
of events. Some of the most significant new information generated in the HOMP
trial related to ‘mapping of the helideck environment’, i.e. identifying and
characterising problems such as the effects of turbulence on operations. Flight
profile measurements also generated useful information for the assessment and
minimisation of risks associated with offshore take-offs and landings.
25 September 2002
Section 10 Page 2
CAA PAPER 2002/02
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
6 The helicopter trial has proven very successful as evidenced by the pro-active
response of Industry in advance of any regulatory action. While no such action is
currently proposed, it may form a natural development of the present ICAO
initiative for fixed-wing operations Flight Data Monitoring. The trial has provided
excellent material to support the case for any future action in this regard.
7 This report contains information and guidance material on the implementation,
management and operation of a HOMP. Although it relates to a helicopter FDM
programme, many of the lessons learned and issues addressed are common to
both helicopter and fixed-wing FDM. It will therefore be of value to any fixed wing
operator implementing a FDM programme, particularly smaller operators with
fleets of regional jets or turboprop aircraft.
25 September 2002
Section 10 Page 3
CAA PAPER 2002/02
Section 11
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
Recommendations
The following recommendations are made:
1
Helicopter operators should implement a HOMP on all FDR-equipped
commercial air transport helicopters, incorporating the programme into their
existing safety management systems.
2
The CAA should make representations to ICAO to have the existing initiative on
Flight Data Monitoring programmes for fixed wing aircraft extended to include
FDR-equipped commercial air transport helicopters.
3
The CAA should utilise the experience gained from the HOMP trial to provide
assistance to other operators planning to implement a HOMP (e.g. in the form
of direct support, consultancy, training or guidance material), to ensure that
effective programmes are established. In particular, using reference [4], this
report and other relevant publications as source material, the CAA should
consider producing guidance material (to include a generic event set) on the
implementation of a HOMP in the form of a CAP.
4
In respect of HOMP improvement CAA should, together with the helicopter
operators:
• develop and evaluate a methodology for the automatic allocation of event
severity levels, with the application of context dependent weighting factors
to events.
• develop data mining tools for the efficient analysis of HOMP event and
measurement databases, e.g. to automatically detect event trends and to
identify abnormalities in measurement data prior to the triggering of any
events.
• complete development of additional capabilities, e.g. provision of an
accurate low airspeed measurement capability, and turbulence related pilot
workload measurements from other CAA research projects.
5
In respect of HOMP implementation and operation, helicopter operators should:
• standardise the HOMP events used by different operators where possible to
aid the sharing of lessons learned.
• continue to refine the HOMP events to maximise the safety benefits of the
programme, and optimise the balance between detecting the widest
possible range of operational risks and minimising the nuisance event rate.
• continue to refine the HOMP measurements to maximise their accuracy in
characterising different aspects of the operation, and to develop further
analysis capabilities, e.g. thermal mapping of the offshore environment.
• develop capabilities for the automatic monitoring of data collection
performance to rapidly identify any loss of data and hence maximise the data
collection rate.
• implement additional capabilities as they become available to further expand
the safety benefits which can be achieved, e.g. by adding an accurate low
airspeed measurement capability, and turbulence related pilot workload
measurements.
25 September 2002
Section 11 Page 1
CAA PAPER 2002/02
Section 12
Final Report on the Helicopter Operations Monitoring Programme (HOMP) Trial
References
[1]
“The Global Aviation Information Network (GAIN) - Using Information
Proactively to Improve Aviation Safety.” US Federal Aviation Administration,
Office of System Safety. May 2000.
[2]
"Operational Flight Data Monitoring - Why and How? D Wright, UK Civil Aviation
Authority. Royal Aeronautical Society, London. March 2000.
[3]
“FOQA: Aviation’s Most Important Safety Tool” Capt M Holtom, British
Airways. Joint meeting: 52nd FSF Annual International Air Safety Seminar, 29th
IFA International Conference and IATA. November 1999.
[4]
Operational Flight Data Monitoring - SRG Guide to Best Practice (Draft)" D
Wright, UK CAA. November 1999.
[5]
“Operator’s Flight Safety Handbook, Issue 1.” GAIN Working Group A, Aviation
Operators Safety Practices. June 2000.
[6]
“Aviation Safety Management Systems – Making the Safety Case.” Shell
Aircraft Limited. 2001.
[7]
“Flight Data Monitoring: Its place within a Safety Management System.” D A
Wright and J E Lyons. Safety Regulation Group, Civil Aviation Authority, UK.
2001.
[8]
“Helicopter Operational Monitoring Project.” CAA Paper 97005. March 1997.
[9]
“Helicopter Operations Monitoring Programme Implementation Study.” ES-S
report SHL1334(1). October 1997.
[10] “HOMP - Review of Helicopter Operational Accidents and Occurrences.” ES-S
report SHL1393(2). May 1999.
[11]
“A Trial Helicopter Operations Monitoring Programme (HOMP).” Royal
Aeronautical Society Conference, London, March 2000.
[12] “Application of HOMP to Helicopter Maritime Operations.” B D Larder and Capt
N Norman. Royal Aeronautical Society Conference, London, March 2001.
25 September 2002
Section 12 Page 1
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement