05.04.2013 Views

The Nimrod Review - Official Documents

The Nimrod Review - Official Documents

The Nimrod Review - Official Documents

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

9.40<br />

9.41<br />

Chapter 9 – Background to Safety Cases<br />

9.39.3 Section 5.3 of the Def-Stan detailed the key appointments in the system safety programme, including a<br />

Project Safety Manager and Engineer, Project Safety Committee and Independent Safety Auditor.<br />

9.39.4 <strong>The</strong> responsibilities of the Independent Safety Auditor included auditing of the project for compliance<br />

with the Standard 59 and the audit was to be documented in an Independent Safety Audit Report which<br />

was, amongst other things, to approve the completeness of the Hazard Log. 60<br />

9.39.5 Whilst Def-Stan 00-56 did not seek to explain precisely how a risk analysis was to be carried out, it<br />

did specify in some detail: (1) the required contents of the Hazard Log; 61 (2) the required activities of a<br />

preliminary hazard analysis and system hazard analysis, and the contents of a preliminary hazard analysis<br />

and system hazard analysis reports; 62 and (3) provided (amongst others) a table of probability ranges and<br />

a table of risk classifications.<br />

It will be clear from the above that Issue 2 of Def-Stan 00-56 was rather prescriptive, an approach somewhat<br />

at odds with that of the ‘goal-setting’ approach advocated by Lord Cullen and the HSE. This was in due course<br />

recognised by the MOD who, on 17 December 200463 published Issue 3 of Def-Stan 00-56, as part of its drive<br />

to make military standards as “civil as possible, as military as necessary. 64<br />

Before turning to Issue 3, it should be noted that Annex D of Issue 2 of Def-Stan 00-56 sought to provide<br />

guidance on the retrospective application of the Standard to projects involving legacy systems. This guidance<br />

included the following:<br />

9.41.1 <strong>The</strong> retrospective application of the Standard should be flexible, its utmost objective being the collection<br />

and collation of as much safety related information as reasonably practicable (para. D.1.1).<br />

9.41.2 A Safety Programme Plan should be prepared and maintained in all cases. Retrospective application of<br />

the Standard was said to require “judicious and justified tailoring of the project safety programme” and<br />

clarification of a number of basic issues, including: (a) the process and safety standards used to design<br />

and build the system; (b) the accident and near-miss history of the system; and (c) the existence of a<br />

prior safety case for the system. This existing information was then to be supplemented with further<br />

analyses and/or by the use of service history (paragraph D.1.2).<br />

9.41.3 A Hazard Log should be established and maintained for all systems. In the case of legacy systems, it was<br />

recognised that the information contained in the Hazard Log could originate from: (a) previous safety<br />

assessments; (b) existing safety certification data; (c) previous design activity quality assurance records<br />

and audits; and (d) experience from service history. It was further noted, however, that the Safety Case<br />

should provide justification for using information from any of these sources as well as explicit arguments<br />

explaining how the Safety Case was supported by such evidence. In particular, if service history was<br />

to be used, all safety related incidents and near-misses should be recorded in the Hazard Log and<br />

mitigating circumstances explained in the Safety Case (paragraph D.1.6).<br />

9.41.4 If a system had previously been certified as compliant with other standards, it may be necessary to<br />

supplement the existing certification data in order to satisfy the requirements of the Standard (paragraph<br />

D.2.2).<br />

9.41.5 Use of service history may allow validation of a safety requirement by comparison to the safety<br />

requirements of similar, in-service certified systems (paragraph D.2.3).<br />

59 Ibid, paragraph 5.3.4.8.<br />

60 Ibid, paragraph 5.3.4.9.<br />

61 Ibid, paragraphs 5.8.7 and 5.8.9.<br />

62 Ibid, paragraphs 7.2.3 and 7.2.4.<br />

63 By this time, as I explain in Chapter 10, the <strong>Nimrod</strong> Safety Case had in fact already been signed-off by the IPT.<br />

64 This remains the policy: “<strong>The</strong> SofS [Secretary of State] safety policy is that civil legislation should be followed unless there is an over-riding imperative<br />

to do otherwise; where exemptions to civil legislation are granted, the measures set in place should be ‘…so far as reasonably practicable, at least as<br />

good as those required by legislation’” (Directorate of Aviation Regulation and Safety Annual Report for 2007, page 7, under Legislation).<br />

173

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!