Mr Malcolm Perks
[Passages in italics are taken from a
letter from the Chairman to Mr Perks]
The Committee which I chair would be grateful
for your help in considering whether FADEC could have played any
part in the crash of ZD576. Before deciding whether we should
ask you to come to London, we should like to know what are your
professional qualifications, and what information you are in a
position to provide us with.
1. Thank you for considering me in relation
to your forthcoming deliberations. Professionally I am a graduate,
a Chartered Engineer and a long-time Member of the Royal Aeronautical
Society. I worked for Rolls-Royce Aero Engines between 1965 and
1985, and again between 1988 and 1993. I have been employed by
Pratt and Whitney Canada since 1997. My speciality, both in the
UK and here in Canada, has been aero-engine control. From the
mid-seventies to the mid-eighties I worked in the field of digital
controls (FADEC) for helicopter engines, and the simulation of
helicopter engines and their controls. I was responsible for the
development of the first FADEC helicopter engine control to gain
Civil Airworthiness Approval in the UK, on the Rolls-Royce Gem
engine. I also worked with MoD during the early eighties to demonstrate
FADEC on an MoD Gem engine: it was my Gem FADEC specification
that I subsequently found had formed the basis for MoD's own specification
for their Chinook engine FADEC. I also found that the reversionary
control on the Chinook FADEC system was based on the Gem FADEC
I had been responsible for developing. During my later time at
Rolls-Royce I was in a more senior management position but I was
still active in the FADEC field, this time on the Rolls-Royce
Trent engine. My current role is as a senior engineer working
on FADEC software for turbofan engines in small regional and business
2. As expert witness, I assisted MoD's US-based
lawyers in preparing and presenting the case against Textron Lycoming
in the period 1993-95. I provided the technical input into the
report that was the cornerstone of MoD's case for negligence against
Textron, and attended as witness in the arbitration hearings.
3. What I can offer to your Committee is
an expert view of helicopter engines from the control perspective,
of FADEC controls applied to helicopter (and other) engines and
of FADEC software issues. I also feel able to review the results
of helicopter simulation work as I worked on such simulations
in conjunction with an MoD team during the late seventies/early
eighties. Specifically, from my work as MoD's expert witness,
I have considerable knowledge about the early design and development
work on the Chinook engine FADEC. I have also studied a lot of
the material made available after the crash of ZD576. You should
be aware that I have volunteered some of my specialist knowledge
on the subject to others involved in this case over the last four
years or so, including to Dr Reid himself, however I would welcome
the opportunity to offer my views directly to your Committee.
We understand that you assisted the MoD in its
claim against Lycoming for damages arising out of the destruction
of a Chinook HC2 engine on test. In para 814 of the minutes of
evidence taken before the House of Commons Defence Committee on
4 March 1998, the Minister stated that the engine ran out of control
because the tester disconnected the FADEC and fuel control. The
report of April 2000 by Fellows of the Royal Aeronautical Society
(para 7) states that the engine runaway was due to a faulty FADEC.
Which of these statements do you consider to be correct, and why?
4. I am not familiar with the Fellows report.
The case put forward during the Arbitration hearings was that
Textron Lycoming had failed to use due care in the design, development
and test of the Chinook FADEC. The case was won but the reasons
for the Arbitration Board's finding and financial award to MoD
were not disclosed, so I cannot say which of the technical arguments
they found most compelling. However, I do not think MoD were told,
either. It is true that the Wilmington incident occurred at the
moment one of the electrical connectors to the main FADEC unit
was taken off, but the test was being conducted in accordance
with an approved test plan and the FADEC was supposed to have
been designed to safely withstand the condition this test simulated.
After the incident, it was found that there was a fault in the
design of the software and the software was subsequently modified.
Originally (before I was involved), MoD had started the process
of preparing a case against Boeing Helicopters and that was primarily
on the grounds of negligence in conducting the test; the case
was settled to MoD's satisfaction well before it came to any formal
hearings. The case against Textron Lycoming clearly went much
further than the test itself, as the report written and tabled
at the Arbitration hearings clearly shows. I have a copy of that
report, if MoD cannot supply one.
5. I found the Minister's statement a strange
one: he was actually using one of the arguments advanced by Textron
Lycoming in their defence against MoD's casethat it was
"only" an issue of testing. It was also Textron Lycoming's
view that Boeing Helicopters were responsible for that test but
since MoD had previously settled with Boeing that issue had already
been taken out of the equation. Had I been an MoD advisor to the
Minister, I would not have recommended defending MoD's position
in this way. Perhaps the Minister was confused as to which case
was being discussed as, in my opinion, if that really had been
the sole case against Textron Lycoming, it is unlikely the case
could have been won.
Do you agree with the proposition contained in
para 7.2 of the Fellows' report, and whether you agree or disagree
can you expand on your answer?
6. A word first about fault codes. The "intelligence"
of FADEC software continuously checks that all its inputs look
good, that its own computed "health" is OK and that,
as far as it can tell, all its outputs are present and correct.
It does all that within the limits of what it is programmed to
recognise. When a condition is detected as outside its programmed
limits, FADEC software takes whatever action it is designed to
take: the aim is to mitigate the effect of the detected fault.
At the same time, it sets a fault code in its memory so that maintenance
people can see what has happened and correct the fault. Generally,
flying with faults present is to be avoided as it becomes increasingly
difficult to cope with another, subsequent, fault unless FADEC
is specifically programmed to deal with it. Fault codes are only
set when FADEC detects a condition that satisfies its pre-programmed
criteria for a fault. If something occurs that does not meet those
criteria it will not set a fault, even if it is a true fault.
It depends on the design of the software, but an example of this
can be the partial loss of a speed signal, so that FADEC measures
a speed as a proportion of its true value. Such a fault could
conceivably cause a runaway (see below). It is indisputably the
case that the condition indicated by the E5 fault code was heavily
implicated in the 1989 Wilmington incident, and that this same
fault code was found in the surviving DECU after the Mull crash.
The Wilmington incident was not caused by the
fault that set the E5 alone, it was in conjunction with another
fault. My memory says the second condition that actually caused
the runaway left no specific trace, though other codes were set
for other conditions caused by the removed connector. I am quite
prepared to accept that, in mid 1994, an E5 condition in itself
could not cause a runawaybut then it never could, there
were always two faults involved. In 1994, what E5 meant was the
same as it meant in 1989, namely, that a speed signal had been
detected as lost and the FADEC was using its second source of
that speed. At Wilmington, the second fault was loss of the second
source of that speed. It was a specification requirement that
FADEC should cope with that, but it didn't, then. By 1994, the
effect of the second fault that led to the Wilmington runaway
had certainly been addressed by the system designers. In fact,
by 1994, E5 was being dismissed as a nuisance fault, of no significance,
in other words it was being accepted that loss of a speed signal
was quite normal. That means a great deal of reliance was being
shown that FADEC would respond correctly to another fault.
7. However, I believe it is possible to
postulate a fault that could have caused an engine to run away,
with an E5 already present. In my opinion, yes, it is a possibility
that a runaway occurred, though I would not wish to put a probability
number on that possibility.
Please confirm in a little more detail what fault
could occur in the FADEC system to cause an engine to run away.
8. There is no simple answer to this question.
FADEC is the name given to the whole systemthe electronic
unit, the sensors, the fuel controller, the pump, everything.
Software is the "glue" that holds the system together,
makes it work and takes care of fault conditions. It is always
an aim of the system designers to prevent runaway, either upwards
or downwards, but usually some possibilities exist. Some faults
the software can do little about, for example, if the fuel pump
drive shears all engine power will be lost, whatever the software
does. Other faults are "managed" by the software so
that they do not affect the engine there and then, for example,
FADEC can detect total loss of a speed signal and use another
similar signal instead. The manufacturer has to do a fault analysis
to show that faults do not lead to loss of control of the engine,
and the worst case to safeguard is the runaway up. Run downs are
easier to accept, as usually the aircraft itself has two or more
engines and is designed to accept the loss of one. Runaway faults,
on the other hand, could cause an engine to "blow up"
(not a very technical expression but it serves the purpose): the
FADEC system used on the Chinook has some built-in protection
against such destructive overspeed but even if the runaway is
contained within the engine's speed limits it can cause major
helicopter controllability issues as it causes the rotor system
to accelerate very quickly indeed.
9. Some faults are relatively easy to take
care of, others can be difficult. Faults that do not meet the
software's criteria for "fault" (sometimes called in-range
faults) are the most difficult to deal with. Loss of one speed
signal (detected) followed by the standby signal reading, say,
half of the correct value is an example of a potential runaway
fault condition, as the software's prime purpose is to keep the
engine speed very close to a fixed value.
If No 2 engine did run away, would you have expected
more traces to have been found than the cumulative faults referred
to in para 184.108.40.206 of the AAIB report to the RAF Board of Inquiry?
If you do not have this, please let the Clerk have a fax number
to which he can send it.
10. I'd like to be reminded of what the
AAIB report said, but I think my answer is "not necessarily",
see (2) above. The evidence contained in the wreckage after the
crash suggests that if a runaway had occurred during the previous
20 seconds or so, it had been of a transient naturenot
an unknown type of event. I would also like to point out that,
in my opinion, the evidence in the wreckage does not support the
reconstruction of the circumstances leading to the crash, much
of which is based on the simulation carried out by Boeing Helicopters.
Can you comment on MoD's response to your suggestion
that the E5 fault code found in the No 2 engine FADEC DECU after
the crash had the same significance as it did in the Wilmington
case? MoD's response is set out in paras 25-26 of a note attached
to a letter from MoD to Robert Key MP dated 22 September 1998;
again, if you do not have this, please let the Clerk have a fax
number to which he can send it.
11. I don't think I ever said that in 1994
an E5 had the same significance as it did in 1989. I have briefed
Mr Key in the past but maybe my technical input led to some confusion.
I'd like to be reminded of the MoD letter, but I think what I
have already said above is a part answer. I don't think what an
E5 means has changed, but much effort was expended after Wilmington
to improve what the software did after a "nuisance"
E5 followed by a subsequent complete loss of the standby speed
signal. So in 1994 the loss of the second speed signal with an
E5 showing would not have had the same effect as it did in 1989.
12. The real issue with the original E5
was that it highlighted the issue of the "quality" of
the softwarehow it had been designed, how it had been documented,
how it had been developed. A lot of testing was undertaken but
that's a form of inspectionand it's now an accepted maxim
that you can't really inspect quality into anything. In my view
that basic quality was in question then, and it could never have
really been corrected to a "flight safety critical"
standard by subsequent patching. What Wilmington showed was that
this new FADEC system had design weaknesses. It was (and still
is) a very different FADEC from anything else flying.
13. I hope you find the foregoing answers
to your questions helpful. When I receive the faxed references,
I will amplify any responses if necessary. In the meantime, please
feel free to ask if you think I can assist on any other points.
4 September 2001
1. I have now had an opportunity to read
through the draft transcripts of the first two days of their Lordships'
Commission reviewing the Board of Inquiry verdict on the Mull
of Kintyre Chinook crash. I am not sure if it is in order for
anyone to comment at all, but since I am not being asked to give
formal evidence, I will offer some observations on one area that
has been briefly discussed, namely the simulation performed by
Boeing Helicopters. You may remember from my e-mail answering
the questions posed by Lord Jauncey that I do have some experience
in helicopter simulations.
2. Much importance has been attached to
trying to establish what happened during the last few seconds
of the flight, what the speed of the helicopter might have been
and what actions the pilots might have been attempting at the
moment of impact. The Accident Investigator, the Board of Inquiry
and now their Lordships have all seen this as vital to a fuller
understanding of the crash. It seems to me that the reconstruction
of those last seconds as simulated by Boeing was treated by both
the Accident Investigator and the Board of Inquiry as if the data
was equivalent to that from an accident recorder. It was never
really questioned at the time, but their Lordships have now asked
some pertinent questions (231-241 in the transcript).
3. Boeing's terms of reference for their
simulation were set by MoD, not the Accident Investigator, and
were very limited. They were asked to construct a scenario that
was consistent with the attitude of the helicopter at impact,
and the positions of its key actuators. Boeing did this, and their
report was apparently taken at face value. However, though they
matched what they had been asked to match, other important parameters
were not consistent with what was deduced from the wreckage, and
so far as I can ascertain, this was overlooked by all those involved
at the time (answer to 236 in the transcript).
4. To be believed, any simulation of an
aircraft has to be validated. This means that for a given transient
manoeuvre, all the key modelled parameters have to be matched
within reasonable limits to actual historical records. Two of
the most important parameters modelled in a helicopter simulation
are rotor speed of the aircraft and the torque from the engines.
In this case, no historical records of either were available,
but Mr Cable's investigations of the wreckage did give some information
that could have allowed some cross-checking of the Boeing model.
5. The Accident Investigation report, based
on good evidence from the rotor speed gauge, said that the rotor
speed of the aircraft at impact was close to normal. However,
the manoeuvre as simulated by Boeing required rotor speed to be
very much lower than normal, and the relevant "traces"
in the Boeing report show this very clearly. The Accident Investigation
report also said that the engine controls in the wreckage were
at normal power settings (answer 183 in the transcript); in fact,
MoD used these findings to conclude that this showed a FADEC malfunction
had not taken place. However, the Boeing simulation manoeuvre
required engine power (or torque) to be at absolute maximum, and
again the relevant "traces" from the Boeing report show
this very clearly. None of the people on the Mull reported noise
from the aircraft suggesting any violent manoeuvring was taking
place, and Mr Cable himself (answer 179 in the transcript) said
that there was no data to suggest the engines had exceeded normal
6. On the Chinook MkII aircraft the engine
control systems have aircraft rotor speed as a primary input,
with collective pitch as a supplementary input. If the rotor speed
is too high, the engine is driven to idle power. If too low, the
engine is driven to maximum output power. If collective pitch
is changed, the engines will also be affected. Any form of extreme
manoeuvring would have forced the engine control systems to respond
immediately. The engine controls should, therefore, have been
anywhere other than at normal settings. Normal settings implies
the engine controls were not seeing major changes in their inputs,
and that is not consistent with the violent manoeuvring postulated
by Boeing. Whatever the pilots were doing, collective pitch was
not being affected, and neither was rotor speed, given the evidence
in the wreckage.
7. In short, I believe the Boeing simulation
cannot be substantiated as a source of any worthwhile data and
should be discounted as "evidence". Mr Cable decided
to believe the simulation but, as far as I have been able to find
out, no searching questions about its validity were asked. As
Mr Cable himself says (answers to 237, 240 in the transcript)
a simulation is a math model. This means it is only as good as
the assumptions in the equations. In my opinion, the difficulties
experienced by Boeing in matching their simulation to the data
they were given (answers to 237, 239 in the transcript) is indicating
only that the assumptions in their simulation model may not have
been valid for ZD576 during the last few seconds of flight. What
that means can only be surmised, but a major mechanical flight
controls failure could be one explanation.
7 October 2001