FADEC Software
Twin Act,
I was certainly aware that some, if not the majority, of the BD issues related to the software audit trail and the fact that as far as I can remember the software, which by any normal definition was flight critical, had neither been procured nor tested to UK flight critical software standards - I understand that this is the issue with the Chinook Mk 3 as the contract did not require this data to be provided.
There were also wiring defects, that undoubtedly contributed some problems eg the PTIT gauge on ZD 576 was possibly one of these, and I have been told that many hours were spent resolving wiring defects and indeed wiring configuration problems for the first 20 or so aircraft delivered - again if you can provide it I would welcome further confirmation of this.
However, the fact remains that it was not just an audit trail problem, and the aircraft was suffering real FADEC related problems - see earlier posts.
Witness No 20 to the Board, Sqn Ldr Morgan, a QHI on the Chinook OCU, commented:
“The unforeseen malfunctions on the Chinook HC2 of a flight critical nature have mainly been associated with the engine system FADEC. They have resulted in undemanded engine shutdown, engine run-up, spurious engine failure captions and misleading and confusing cockpit indications.”
In a internal memorandum dated 3 June 1994 Boscombe Down EAS produced a damning verdict on a paper that Textron Lycoming had produced to defend themselves against an independent study from EDS Scicon in July 1993 which in turn had agreed with the Boscombe Down conclusion that the software code was poorly developed and poorly documented, and in the view of one expert employed by MOD "not of sufficient good quality to be used in a saftey critical application". The EAS memo, which is some 4 pages long, referring to the Textron White Paper, makes some 24 statements, none of which are complimentary, such as:
Notwithstanding the claims made in Textron's white paper the problem remains that the product (T55-L-712F software) has been shown to be unverifaible and is therefore unsuitable for its intended purpose (ie the in-flight management of the Chinook engines!).
The traceability study of the documentation revealed inconsistencies such as requirements not being implemented and conversely things appearing in the code which did not appear in the requirements. There were a total of 34 category 1 anomalies and 48 Category 2 anomalies in the traceability study (I do not know the definitions of Cat 1 and Cat 2, but I beleive they were then defined in JSP188).
Given your comments on the content of Block 1 I do not now know how the gaps between the FADEC software standards and documentation in 1994, and what I assume are acceptable standards today, have been bridged - do you?
What we do know is that in late 1993 the DPA (or PE as it then was), presumably under very significant customer pressure to get the already delayed Chinook Mk 2 into service, decided to accept the assurances of Textron and ignore EDS Scicon and its own specialists and issue a RTS for the Chinook Mk 2 - relying upon the flight limitations to try to keep the aircraft safe.
We do not of course know if the accident to ZD 576 could be attributed in whole or in part to the FADEC - but it is certainly a possibility supported by facts not hypotheses. As we know none of this came out at the Board - an outrageous shortfall of TORs and investigation in my view. If it had it is difficult to see how even a balance of probabilities verdict of pilot error could have come about. It was not a conspiracy, people were I am sure trying to do their best in difficult circumstances, but the cynics amongst you might even think that this sorry tale of the development and procurement of the Chinook FADEC software was a major (if not the) reason for the RAF and MOD to cover up some bad news, and even today to continue to defend the indefensible. As they say - you might think that, but I could not possibly comment!
JB