Select Committee on Public Accounts Minutes of Evidence


Memorandum submitted by Mr Malcolm Perks


  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.


  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.


  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 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.


  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.


  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.


  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.


  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.


  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.


  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.


  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.


  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.


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?


  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.


  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.


  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

previous page contents next page

House of Commons home page Parliament home page House of Lords home page search page enquiries index

© Parliamentary copyright 2000
Prepared 30 November 2000