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

  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 case—that 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 runaway—but 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 system—the 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 7.3.2.4 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 nature—not 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 software—how 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 inspection—and 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 values.

  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