THE RAF CHINOOK MK 2 AND ITS FULL AUTHORITY
DIGITAL ELECTRONIC CONTROL (FADEC) (PAC 1999-2000/85)
Memorandum submitted by Mr Malcolm Perks
PERSONAL BACKGROUND
I have worked for 33 years on the design and
development of aircraft engine controls and have experience on
many different FADEC types. I was the Rolls-Royce manager for
the development of the Gem helicopter engine FADEC which was claimed
to be the basis of the Chinook system. MoD used me as their Expert
Witness in the legal action against Lycoming in 1994-95 for negligence
in the development of RAF Chinook FADEC. I am now based in Canada
but still work on FADEC systems. I am independent of all the parties
concerned in the Chinook FADEC.
EXECUTIVE SUMMARY
The Chinook FADEC was an ambitious project,
which started before the technology was mature. Even today, the
technology is considered challenging, but the claims made for
it at the time and the technical approach taken assumed otherwise.
Once the project had started, events seemed to take their own
course, in part due to the funding and contract arrangements.
Criticisms from within MoD were not seen as helpful but created
a fortress mentality which still seems to exist today. The NAO
reports that FADEC has been technically accepted by the RAF, if
so, it is a tribute to MoD's persistence, not to good management.
The final conclusion of the NAO report (that
FADEC was within budget, on time, etc) implies that the FADEC
project was a success. In my view, it was anything but. It took
13 years from start to finish. During it, at least one aircraft
was severely damaged. Suppliers were sued successfully and disagreements
over the project were rife within MoD. After eight years of effort,
the Mk 2 Chinook had a load-carrying capability some 40 per cent
less than hoped for and 25 per cent less than where it started.
It was another four years before FADEC improvements allowed the
operational restrictions to be lifted. Only then could the hoped-for
benefits of the £200 million spent on the mid-life update
by fully realised.
A BRIEF HISTORY
The Mk 1 Chinook was quite an old US aircraft
type (Vietnam war era), but unique and a vital part of the RAF
fleet. Its engine and control system were also dated, with a high
cost of maintenance. In 1984, a team of control manufacturers
made a direct approach to MoD to update the control systems of
the Chinook's engines. They offered to pay for the control development,
the new system would pay for itself by reduced maintenance costs,
and the new FADEC could be in production within three years. All
MoD had to do was pay the engine manufacturer to put it on the
engine, and the aircraft manufacturer to put it in the aircraft.
MoD agreed to the proposal in 1985, with the aim of making FADEC
part of the longer-term plan for a mid-life update. Their prime
contractors were Lycoming and Boeing Helicopters.
FADEC WAS ESSENTIALLY
A SOFTWARE
PROJECT
FADEC replaces complex mechanical controls with
simpler mechanical units plus a computer with new sensors to feed
information to the computer. It is a very different control technology;
complexity is still there but in the software. FADEC is a smart
system, designed to operate with minimal pilot attention at all
times. In all aircraft (except gliders) engines are critical to
flight, control is critical to engines and safety of control with
FADEC depends on software. This is why FADEC software is designated
Flight Safety Critical—lives depend on its continued, predictable,
fault-free operation. The Chinook FADEC was a unique design, with
two separate computer systems and two sets of software to be developed.
THE FADEC CONTRACTORS
It is not easy to design a FADEC; its software
in particular needs a lot of specialised knowledge. It is difficult
and expensive for companies to acquire a FADEC capability, which
is why there are relatively few major FADEC suppliers in the world—around
six. That number hasn't changed much over the last 15 years, but
some of the names have. The suppliers selected by MoD were not
from that six, they were CECO in the US (for the mechanical parts)
and HSDE in the UK (for the computer and its software). However,
MoD's contracts would be with Lycoming and Boeing, as suppliers
of the engines and airframe respectively. The FADEC suppliers
were overconfident and the relevant experience of the other participants
was minimal.
SOFTWARE PROJECTS
ARE DIFFICULT
Virtually all major software projects cost more
and take longer than planned. Techniques for managing software
projects are not mature even today. Wishful thinking is common
at any proposal stage, partly because the real resources needed
can be commercially unacceptable. Any flight safety critical software
is a major undertaking: this FADEC included two such software
products. Dedicated software development tools that are proven
and automated are key assets of today's major FADEC companies.
This FADEC was attempted from scratch by HSDE without the use
of such tools.
THE PROJECT
MANAGEMENT APPROACH
It is often the practice to subcontract management
of complex projects involving software to "systems houses".
This was not the case here, FADEC was managed by Lycoming. MoD
had no direct control over the software: its developer was too
far down the supply chain. CECO and HSDE were funding themselves
and as software products were delivered it became clear their
money had been spent on their idea of the right job, not MoD's.
THE EARLY
SIGNS OF
TROUBLE
Three years after launch, the Chinook FADEC
project was in trouble. Far from being in production, development
FADECs were only just starting their test programme in a modified
RAF Chinook, loaned for the purpose. In early 1989, during initial
tests on the ground, software conditions that had not been considered
caused an uncontrolled runaway of an engine. The aircraft was
severely damaged, but luckily no one was hurt. The RAF Board of
Inquiry recommended a review of the software design. It was 1990
before testing in the Chinook restarted and it was 1993 before
the first Mk 2 Chinook with a production FADEC was ready.
THEN MOD
SUED THEIR
OWN CONTRACTORS
In the aftermath of the incident, MoD wanted
Lycoming and Boeing to accept some liability for the damage—to
repair the aircraft, $7 million worth of parts were needed from
the RAF. Boeing came to an agreement with MoD before legal actions
started. Lycoming's insurers fought the case but were eventually
obliged to pay $3 million in 1995, after protracted hearings under
American Arbitration Association rules.
SOFTWARE QUALITY
WAS A
REAL ISSUE
In 1994, as Expert Witness to MoD, my investigations
showed the 1988 version of the software had not been designed
and developed in accordance with industry accepted practices.
I also learned that production software with its documentation
had finally been delivered in 1993, for the approval of MoD's
experts, A&AEE at Boscombe Down. They pronounced the software
unverifiable[1].
So, five years after the first version, the software was still
not acceptable. The writing had been on the wall for years that
this FADEC's software was of doubtful quality, but the necessary
actions had not been taken. In the end, as described in the NAO
report, MoD overruled their experts and went ahead anyway with
its release into service.
SO WHY
WAS IT
ACCEPTED INTO
SERVICE IN
1994?
The answer is that by this time there was little
choice. To add FADEC required a major aircraft rework at the manufacturers,
this was planned to take place at the same time as the other mid-life
elements, such as a new transmission. In any case, the upgraded
engines now came with FADEC. Once the upgrade programme was committed,
FADEC had to go ahead. To make the FADEC acceptable to Boscombe
Down a payload limit was imposed. The theory was, if FADEC caused
an engine to be lost, the remaining engine could cope under most
circumstances.
WAS FADEC, IN
FACT, ACCEPTABLE?
The Mk 2 Chinook weight restriction was only
a palliative. Until software can be verified, it has to be considered
unpredictable, as the NAO report says. That means it could do
almost anything; cause an engine to be lost, cause an engine (maybe
both) to produce too much power, light lamps in the cockpit for
no real reason—anything. The evidence produced during and
after the Inquiries into the June 1994 Mull of Kintyre Chinook
crash showed that FADEC in its early days in service was doing
many of these things. Although not provable, it remains a possibility
that FADEC unpredictability was a factor in the Mull accident.
SOME FURTHER
OBSERVATIONS
Why was it done at all?
MoD's fleet of Chinooks was surely too small to justify
the effort. Other mid-life update elements brought operational
benefits, FADEC was developed primarily to reduce cost. The FADEC
contractors had to be interested more in the potential of the
bigger world-wide Chinook market. If Lycoming and Boeing did not
want to initiate such a modification and offer it to all Chinook
operators, was that sufficient justification for MoD to go it
alone?
Timescale
MoD's timescales may reflect funding availability,
but are not good for such projects. It is difficult to assemble
a good software team for even a short time, and impossible to
keep them together for long. After a time, the project skill,
experience and knowledge base goes down.
Relationship
MoD's choice of contractors may have assumed
that a previously satisfactory business relationship guaranteed
future performance. Technology changes, people change, pressures
on companies change. There were probably good intentions at first,
but response is bound to decrease as costs mount and return on
investment worsens.
Risk
Low risk comes from the same people having done
the same task before. The less similarity, the higher the risk.
Communication distances play a part in risk. Risk assessment needs
to be ongoing. Whatever the claims, this FADEC was high risk.
Use of Experts
When MoD doesn't have the expertise to handle
a situation, they should take the advice of experts. Reasons for
rejecting advice should not include "it's not the answer
I wanted".
Conflict of interest
Real conflicts of interest can arise when companies
themselves investigate possible deficiencies in their products.
It is unlikely that they can be fully objective.[2]
Has anyone been blamed?
MoD have never admitted in public that any of
the contractors did a less than perfect job. In fact, MoD Projects
have continued to defend the contractors against all critics,
including those from within MoD itself. It is not clear why, given
the 1995 legal victory against Lycoming for what amounted to negligence.
Neither has it been accepted that FADEC may have played a part
in the Mull of Kintyre crash, despite the evidence that FADEC
was put into service before it was fully developed. The only fault
ever clearly assigned by MoD was to the pilots who crashed into
the Mull while flying one of the early Mk2 Chinooks with its unpredictable
FADEC software!
Malcolm Perks
March 2000
1 At the HCDC hearing, MoD argued this merely meant
Boscombe Down could not "read" the software. This is
not, in fact, a trivial issue. A hardware component for an aircraft
can be checked for quality by inspecting it against its drawing.
If the part and its drawing do not match, either the part or the
drawing is wrong. Either way, the component cannot be used. For
software the process of checking is called "verification",
not inspection. High quality software cannot be seen and measured
but it can be verified against its design documents. If you cannot
verify it, software is not suitable for a Flight Safety Critical
system. The NAO report refers to attempts made by Boscombe Down
to apply Static Code Analysis to verify the software, and to the
use of EDS-Scicon as additional independent verifiers. Leaving
aside the detail, most of the FADEC software should have been
amenable to such analyses, even if not designed for it from the
start. Certainly the documentation should have matched the programme,
and there would have been few errors if the necessary rigour had
been applied to the design process. Back
2
A 1999 report from the US Rand Corporation for the National Transportation
Safety Board describes the conflicts during an accident investigation
and recommends more use of independent experts to reduce such
conflicts. Back
| 
