Computer Weekly is publishing (below), for the first time, a technical analysis of the software installed on the Chinook Mk2 helicopter, the Chinook model which featured in the RAF's worst peacetime crash.
The analysis was carried out by the Ministry of Defence's independent IT contractor, EDS, in July 1993, nearly a year before the notorious fatal crash of a Chinook Mk2 on the Mull of Kintyre in June 1994.
The MoD's IT experts at Boscombe Down warned the MoD's hierarchy in London against relying on the Chinook Mk2's Fadec software to safely control the helicopter's two jet engines on the basis of EDS's report.
But it was not until after the crash in June 1994 that the MoD acted on Boscombe Down's concerns.
Allied Signal, the Chinook engine's contractor, commissioned major modifications to the software - a so-called "Block 1 update" which included change of central processor at its own expense.
The crash on the Mull of Kintyre was one of the RAF's worst in peacetime. It killed all 29 on board, including 25 senior police and intelligence officers. RAF air marshals accused the two dead Special Forces pilots of gross negligence, although an RAF Board of Inquiry was unable to establish the cause of the accident - and it did not rule out software problems as a contributory factor.
EDS's contract with the MoD was to give its view on the quality of the Chinook Mk2 T55 fuel control Full Authority Digital Engine Control - Fadec - software.
EDS put the anomalies it found in the fuel control software into four categories:
Cat 1 - EDS has a high level of confidence that an anomaly relates to a real error in the code or a discrepancy between the code and the documentation,
Cat 2 - The anomaly relates to poor code or poor correspondence between code and documentation but it is likely that it performs the intended function
Cat 3 - These anomalies relate purely to obvious documentation errors such as typographical errors and incorrect commenting of code. They have no direct implication for the correct operation of the code
Cat 4 - These anomalies arise from the 'style' of coding, or the way in which the code has been modelled for analysis. They do not relate to any source language use that will cause incorrect operation.
EDS examined 102 software modules (45.2%) representing 17.8% of the total lines of code (approx 16,000), before it stopped its analysis because of the density of discrepancies. These were its findings:
| Cat 1 | Cat 2 | Cat 3 | Cat 4 | ||
|---|---|---|---|---|---|
| Primary software lane | 13 | 111 | 42 | 81 | |
| Backup [reversionary] lane | 8 | 43 | 15 | 20 | |
| Documentation Traceability | 35 | 39 | 75 | 3 | |
| Total | 56 | 193 | 132 | 104 | 485 |
EDS's findings in detail:
Failure to trace code to documentation
a) algorithms that could not be traced to the documentation (cat 2)
b) Individual actions on paths that could not be traced to the documentation (cat 1 or 2)
c) Paths that not be traced to the documentation (cat 1 or 2)
d) Interfaces to hardware that do not appear to be documented (cat 2)
e) Undocumented values for booleans, constants (cat 2 or 3)
f) Overflow of variables (cat 1 or 2)
g) Undocumented use of persistent local variables (cat 2)
h) Parameters which could not be traced to the documentation (cat 2)
i) Extra code not required in the documentation (cat 2)
j) No documentation at all (cat 2)
k) The variables in the code do no trace (without considerable analysis) to the variables mentioned in the documentation (cat 2)
l) A requirement in the documentation which does not appear in the code (cat 1)
Incorrect Code Comments
a) Incorrect code comments (cat 3)
b) Incorrect specification of a parameter (cat 2)
Redundant Code
a) Unreferenced labels (cat 4)
b) Statements which do not perform any documented/required function (cat 2)
c) Addition of an opcode to test a flag that was set correctly by the previous instruction (cat 2)
d) Entire subprograms that are not used in the FADEC (cat 1)
e) Redundant data declarations (cat 2)
f) Arrays with unusual elements (cat 2)
g) Literals declared and never used (cat 2)
Aliasing
a) Addressing the same location using two different literal names (cat 2)
b) Jumping to an address which may or may not have an associated label (cat2)
c) More than one label associated with an instruction address (cat 1)
d) Multiple names for a single variable or constant (cat 2)
e) Aliasing of a word variable name to the element of an array (cat 2)
f) Aliasing of data variables by allowing the index of one array to be incremented beyond the upper bound of that array into subsequent variables in memory (cat 2)
g) Using mnemonics and literals to represent the same number (cat 2)
h) Locating differently named segments to the same physical location and using these names arbitrarily in the code to address data (cat 2)
Unstructured code
a) Unstructured code due to the handling of RAM failure conditions (cat 4)
b) Unstructured code due to a common block of code bein g used on both paths of an IF_THEN_ELSE statement (cat 2 or 4)
Mismatch of data types
a) Indexing simple word variables (cat 2)
b) Applying a byte operation to a word variable and so leaving the upper byte undefined, rather than clearing it (cat 1)
c) Array used as a single word (cat 2)
d) Using the second element of an un-initialised array giving a rounding error (Cat 1).
Incorrect code
a) Overflow not handled as documented (cat 1)
Documentation Anomalies
a) Incorrect documentation
b) Ambiguous documentation
c) Typographical errors
Campaign for Justice website >>
Tories repeat commitment to review Chinook crash findings >>
22 Feb 2010