In-Service Evidence

The UK Ministry of Defence recently announced that its Chinook helicopter HC3 variants will undergo a £90.1m ($181m) upgrade. The press release itself is rather brief, but the story in Flight Global (‘UK signs £90 million deal to fix grounded Chinook helicopters‘) gives a bit more background. However, to really understand the purpose of the upgrade, you need to cross-reference information from a number of sources: Chinook blunder ‘left RAF short’ (BBC News), Wikipedia entry for Chinook HC3, and a UK National Audit Office report (PDF). I’ll leave the political issues well alone, but some of the technical challenges really interest me.

In brief, the HC3 is based on the US Army’s MH-47E Chinook helicopter, but has been customized for use by the UK RAF 7 Squadron Special Forces flight. The enhancements include improved range, night vision sensors and navigation capability. However, in order to fit all of this additional capability into the cockpit, a unique hybrid digital/analogue avionics system which was reliant on software was employed.

The delivered HC3s fulfilled all the requirements specified in the contract, but unfortunately the contract didn’t specify that the software and documentation should be developed in accordance with UK defence standards (UK MOD Def Stan 00-55/00-56), so it was impossible to prove that the flight systems met these standards. In addition, because the cockpit systems are significantly different from the fully digital cockpit used on other Chinook variants, the in-service evidence for those aircraft is not relevant to the HC3.

Since the delivery of the HC3s, the UK defence standard Def Stan 00-56 has been revised, and the latest version (Issue 4, 2007) makes greater provision for use of processes used in and
software developed under other safety standards (e.g. DO-178B,
ISO/IEC61508), so that shouldn’t present an insurmountable technical
barrier for systems developed according to DO-178B. However, this case does raise some interesting questions in general about the use of in-service evidence in safety certification:

  • When is it appropriate to use in-service evidence as part of a safety case?
  • At what point do customizations to a previously deployed system render the in-service evidence invalid?
  • Is an in-service evidence approach acceptable for avionics systems at different levels of safety criticality; secondary guidance instruments perhaps, but what about primary flight controls?

1 Comment

  1. Amitabh Mukherjee

    I am not familiar with UK MOD Def Std. However, my take on In Service evidence is as follows:
    a) In order to take credit from an in service software, it is essential that the software and associated document, if any, be held in configuration management.
    b) It is essential that each and every problem encountered in service be reported and recorded in a Problem Report that can be traced to the updated software that resolved the problem. This is very important from the safety analysis of the system.
    c) It is an advantage if evidences of testing exists. This includes testing of the updated software.
    c) All modifications made to the baseline software should be subject to regression analysis.
    d) I would clearly identify the core software and subject that to analysis to see how many and the type of problems that have been reported in the past affecting the core software and how they were resolved.

Leave a Reply to Amitabh Mukherjee cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>