Defence Minister misleads MPs over Chinook accident

Last week in the House of Commons, Labour’s Defence Minister Lewis Moonie unintentionally misled the House of Commons over a Chinook accident in 1989,...

Last week in the House of Commons, Labour’s Defence Minister Lewis Moonie unintentionally misled the House of Commons over a Chinook accident in 1989, saying that it was not caused by the Chinook helicopter’s FADEC software.

Documents not disclosed before, now in the possession of Computer Weekly and Channel Four News, and summarised in this article, contradict Moonie’s claims last week. They show that the Chinook’s manufacturer Boeing, and the software’s three contractors Textron Lycoming, Chandler Evans and Hawker Siddeley had agreed that the FADEC was the cause of the 1989 accident and that the “system needed to be redesigned”.

After the non-fatal 1989 incident, in which a Chinook owned by the Ministry of Defence was severely damaged during a ground test of the FADEC system, the MoD sued the manufacturers. It won a $3m settlement from the FADEC’s contractors Textron Lycoming and the equivalent of $500,000 from Boeing in return for releasing it from any legal claims.

In the House of the Commons last week Moonie denied claims by former Defence Minister, Salisbury MP Robert Key, that the legal action was over the performance of the FADEC. “The suit mentioned by the hon. Member for Salisbury concerned a case of negligence by the manufacturers during a ground test of one of the helicopters - it was not about the FADEC system itself.”

However the Ministry’s legal papers show that the MoD’s US lawyers won their case by showing that Boeing test procedures were “adequate and reasonable” and that the accident was caused by “Textron’s faulty design” of FADEC.

There is no suggestion that Moonie deliberately misled the Commons. He was reading from a text prepared by his officials.

Moonie’s comments were consistent with repeated claims by MoD officials that FADEC is not a safety critical system and has never caused an accident, although the Ministry’s own documents relating to the 1989 accident show otherwise.

Five years after the accident, a Chinook crashed on the Mull of Kintyre, killing all 29 on board including senior police and intelligence personnel. Although the pilots were blamed for the crash on the mull, doubts about whether the FADEC could have played a major role have deepened.

A primary cause of the 1989 accident was an “E5” fault code in the FADEC - the same fault code that was found on a FADEC that survived the crash on the Mull of Kintyre.

For different reasons, the causes of the accident in 1989 are regarded as important by the Ministry and Defence and to campaigners who are seeking to clear the names of the two pilots who were blamed for the crash on the Mull.

Campaigners say that although two air marshals found the pilots grossly negligent FADEC or other problems could have caused the accident on the Mull. It was recognised by the RAF Board of Inquiry into the crash on the Mull that FADEC could have contributed to the accident.

To these campaigners the incident in 1989 is significant because they say it shows not only that FADEC was capable of causing an uncontrollable engine surge and the possible loss of an aircraft, but that this is what happened in 1989.

For the MoD the accident is important because it has made official statements to MPs since the Mull crash that the FADEC is not a safety critical system and cannot cause a potentially catastrophic accident.

Were the Ministry now to accept now that the FADEC caused the accident in 1989, this would not only undermine its claims that the FADEC is not safety critical.

More seriously, it would suggest that the MoD was wrong in the reasons it gave for approving the FADEC for operational service in Chinook Mk2 helicopter types in 1993.

The Ministry’s airworthiness assessors at Boscombe Down had said it was “essential” that the software was rewritten before the FADEC was deployed in an operational aircraft. But the MoD overruled Boscombe Down saying that the FADEC had never caused an accident and was not critical to safety.

Last week, in the first Commons debate on the crash on the Mull of Kintyre, Moonie described the MoD’s official position on the 1989 accident as that which the Ministry had gone to lengths to discredit during the arbitration proceedings.

He said the case brought by the Ministry of Defence after the 1989 accident “concerned a case of negligence by the manufacturers during a ground test of one the helicopters - it was not about the FADEC system itself”.

A similar statement was made by the then Defence Minister John Reid to the Defence Committee in 1998. He said that the legal action arising from the 1989 accident “was not - I repeat, it was not - on account of the failure of the [FADEC] software”. Reid had added that this was “one of the misconceptions that has been unfortunately allowed to flourish … the case was essentially against Boeing and Textron Lycoming for negligence in their testing procedures, not against the software”.

Another Minister Doug Henderson later confirmed the veracity of Reid’s comments in a letter to Bruce George, chairman of the Defence Committee.

Ironically, Moonie’s incorrect statement last week came at the end of a Commons debate in which several MPs criticised the Ministry of Defence for issuing misleading and incorrect statements, many of them related to the FADEC.

In the minds of some MPs and Lords it is not only the blaming of the pilots of Chinook ZD576 that merits an independent inquiry. They feel that the conduct and integrity of the MoD itself should be put on trial.

Read more on IT for small and medium-sized enterprises (SME)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.






  • How do I size a UPS unit?

    Your data center UPS sizing needs are dependent on a variety of factors. Develop configurations and determine the estimated UPS ...

  • How to enhance FTP server security

    If you still use FTP servers in your organization, use IP address whitelists, login restrictions and data encryption -- and just ...

  • 3 ways to approach cloud bursting

    With different cloud bursting techniques and tools from Amazon, Zerto, VMware and Oracle, admins can bolster cloud connections ...