ascad_v11a

7/25/2019 ascad_v11a

1/166

ASCAD/az-kad/

Adelard

Safety Case

Development

Manual

First Published 1998 by AdelardCollege Building, Northampton Square, London EC1V 0HB

Adelard, 1998

7/25/2019 ascad_v11a

2/166

Foreward

Following research for the UK HSE/NII in the 1990's, Adelard published its Safety

Case Development Manual (ASCAD) in 1998. This has successfully been used inmany organisations worldwide since then.

In support of the safety community Adelard has decided to make the manualpublicly available. It can be downloaded, after registration, at our websitehttp://www.adelard.com/resources/ascad

While now available free of charge to individuals, copyright is retained byAdelard. Conditions of use are:

The manual may only be used by the individual who downloads the

document. It may not be passed on to anyone else without permissionfrom Adelard. Other interested parties should download the documentfrom our website. Anyone who has difficulty downloading the documentshould contact Adelard to discuss other options.

The manual may be used freely by registered users, both for commercialand non-commercial use.

While Adelard believes the content to be accurate, it accepts noresponsibility for any consequence of use, either direct or indirect. Use ofthe manual implies acceptance of this and all other conditions.

The content of the manual may not be reproduced in any format (otherthan for backup purposes) without agreement from Adelard in writing.

The document may be used is support of both academic teaching andresearch, and in both cases some of the above restrictions may bewaived. Contact for more information.

The document is available free of charge in softcopy only. Hard copyversions are available at a nominal reproduction charge. Contact for more information.

Published 1998 by Adelard, 3 Coborn Rd, London E3 2DAPublished 2006 by Adelard, College Building, Northampton Square, London EC1V 0HB

All rights reserved. No part of this publication may be reproduced, stored in a retrievalsystem, or transmitted in any form, or by any means electronic, mechanical,photocopying, recording or otherwise without prior permission in writing from Adelard.

British Library Cataloguing in Publication Data

ASCADAdelard Safety Case Development Manual

ISBN 0 9533771 0 5

7/25/2019 ascad_v11a

3/166

Adelard Safety Case Development Manual

Version: 1.0 3

Adelard

Adelard is an independent consultancy founded in 1987 by Robin Bloomfield andPeter Froome. Adelard works on a wide spectrum of problems in the area of theassurance and development of safety related computer-based systems, rangingfrom formal machine assisted verification to the human and social vulnerabilitiesof organisations. We also apply this specialist knowledge to the development andverification of real industrial systems.

http://www.adelard.com

Adelardof Bath

Adelard takes its name from Adelard ofBath, a medieval mathematician andnatural philosopher, a crucial figure in thedevelopment of early European thought,and a major influence in therevolutionary adoption of the Arabicnotation for numbers instead of theintractable Roman numerals.

Adelards most influential works were on mathematics. He translated EuclidsElementsstill the basis of much of todays mathematicsfrom Arabic into Latin,the international language of European scholarship. He was also the author of aLatin version of a treatise on Arabic arithmetic by al-Khwarizmi, the great Saracenmathematician whose name, corrupted to algorism, became the European wordfor the new system of numbers.

7/25/2019 ascad_v11a

4/166

7/25/2019 ascad_v11a

5/166


Version: 1.1 1

Contents

Part 1 Introduction.............................................................................................................7

1 Scope ............................................................................................................................. 7

2 What is a safety case?.................................................................................................. 8

3 The importance of a good safety case...................................................................... 8

4 Basis of the ASCAD methodology............................................................................... 8

5 How to use the manual................................................................................................. 9

6 Feedback..................................................................................................................... 11

7 Acknowledgements ................................................................................................... 11

Part 2 Description of the safety case methodology.................................................... 13

1 Introduction.................................................................................................................. 13

2 Overview of approach ............................................................................................... 14

2.1 Safety case principles ......................................................................................... 14

2.2 Safety case structure........................................................................................... 14

2.3 Types of claim....................................................................................................... 17

2.4 Sources of evidence............................................................................................17

2.5 Style of argument................................................................................................. 18

3 Safety case development.......................................................................................... 21

3.1 Safety case elements .......................................................................................... 21

4 Developing Preliminary safety case elements........................................................ 22

4.1 Definition of system and project ........................................................................23

4.1.1 Operating context ............................................................................................ 23

4.1.2 Identify any defined PES (Programmable Electronic System) or componentsafety requirements..................................................................................................... 24

4.1.3 Existing safety and project information ........................................................ 24

7/25/2019 ascad_v11a

6/166


2 Version: 1.1

4.2 Develop claims from attributes ..........................................................................24

4.2.1 Computer system architecture ......................................................................25

4.2.2 Software attributes ............................................................................................ 26

4.3 Traceability between levels ................................................................................27

4.4 Establish project constraints................................................................................28

4.5 Long term issues....................................................................................................29

5 Developing Architectural safety case elements .....................................................31

5.1 Design for assessment..........................................................................................32

5.1.1 Keeping it simple (KISS)...................................................................................... 33

5.1.2 Partitioning according to criticality ................................................................34

5.1.3 Avoidance of novelty........................................................................................ 35

5.2 Sources of evidence............................................................................................35

5.3 Design assumptions..............................................................................................36

5.4 Choosing a suitable system architecture and safety case ............................36

5.5 Risk assessment and review ................................................................................37

6 Developing Implementation safety case elements................................................39

6.1 Attribute-claim-evidence tables........................................................................40

6.2 Risk Assessment and review ................................................................................41

7 Operation and installation safety case elements ..................................................43

8 Project safety case structure......................................................................................44

8.1 Relationship to project lifecycle and structure ................................................44

8.2 Influence of types of system ...............................................................................46

8.3 Subsystem safety case.........................................................................................47

9 Independent assessment and acceptance of the safety case ............................48

10 Long-term maintenance ..........................................................................................50

11 Contents of a safety case report: documentation issues......................................52

11.1 Environment description.....................................................................................53

11.2 PES safety requirements......................................................................................54

11.3 PES system architecture......................................................................................54

11.4 Planned and actual implementation approach............................................54

7/25/2019 ascad_v11a

7/166


Version: 1.1 3

11.5 PES system architecture safety argument ....................................................... 55

11.6 Subsystem design and safety arguments ........................................................ 56

11.7 Long term support requirements....................................................................... 56

11.8 Status information ............................................................................................... 56

11.9 Evidence of quality and safety management ............................................... 57

11.10 References......................................................................................................... 57

Appendix A System safety context...............................................................................59

A.1 Safety-related standards in the public domain ............................................... 61

A.2 Other safety guidance ........................................................................................ 62

A.3 Example criteria.................................................................................................... 63

A.3.1 Probabilistic criteria ........................................................................................... 63

A.3.2 Deterministic criteria .........................................................................................64

A.3.3 Qualitative criteria............................................................................................. 65

Appendix B Design options to limit dangerous failures............................................. 67

B.1 Computer system defences ................................................................................ 67

B.2 Software defences ............................................................................................... 69

B.3 Operations and maintenance error defences ................................................. 71

Appendix C Checklist of safety documents............................................................... 73

C.1 Planning ............................................................................................................... 73

C.2 Safety cases.........................................................................................................73

C.3 Safety related documentation .........................................................................74

C.4 Project implementation ..................................................................................... 74

C.5 Review and audits .............................................................................................. 74

Appendix D Attribute-claim-evidence tables............................................................ 75

D.1 Attribute-claim-design tables ............................................................................ 75

D.2 Attribute-claim-argument tables .....................................................................79

Appendix E Review of changes that can affect the safety case............................. 83

E.1 Changed PES system requirements....................................................................83

E.2 Impending obsolescence.................................................................................... 85

E.3 Changes to regulatory environment or safety criteria..................................... 88

Appendix F Safety case review checklist ....................................................................91

7/25/2019 ascad_v11a

8/166


4 Version: 1.1

F.1 Basis for the checklists ..........................................................................................91

F.2 Demonstrable.....................................................................................................91

F.3 Valid.....................................................................................................................91

F.4 Adequately safe ................................................................................................92

F.5 Over its entire lifetime........................................................................................92

F.6 Checklist for the technical adequacy of the arguments ................................93

F.6.1 Completeness of argument .............................................................................93

F.6.2 Credibility of argument ..................................................................................... 94

F.6.3 Integrity of the safety case documentation and system design.............. 94

F.6.4 Checklist for integrity of the operations and maintenance infra-structure94 F.7 Long-term maintainability of the safety case....................................................95

F.7.1 Robustness to system change.......................................................................... 95

F.7.2 Long-term integrity of the safety case support infra-structure ..................95

F.7.3 Impact of technological obsolescence........................................................ 96

F.7.4 Impact of regulatory change .......................................................................... 96

Appendix G Use of field evidence to support a reliability claim...............................97

G.1 Empirical evidence.............................................................................................97

G.2 Theoretical analysis .............................................................................................99

G.3 Application of the theory to COTS..................................................................101

G.4 Application to a new system...........................................................................103

G.5 Estimating residual faults ..................................................................................103

G.6 References .........................................................................................................105

Appendix H Long term issues......................................................................................107

H.1 Introduction ........................................................................................................107

H.2 Incorporating the guidance in existing safety management processes...107H.3 Long-term improvement of the safety methodology...................................109

H.4 Safety case maintenance documentation ...................................................109

Appendix I Maintenance and human factors ..........................................................113

I.1 Individual weaknesses..........................................................................................113

I.2 Supporting materials ...........................................................................................115

I.3 Violations ...............................................................................................................115

I.4 Group weaknesses ...............................................................................................115

7/25/2019 ascad_v11a

9/166


Version: 1.1 5

I.5 Organisational issues ........................................................................................... 116

I.6 Knowledge management .................................................................................. 117

I.7 References ........................................................................................................... 118

Appendix J Example checklist long term issues...................................................... 119

J.1 Basis for the checklists........................................................................................ 119

J.2 Remain acceptable....................................................................................... 120

J.2.1 Demonstrable.................................................................................................... 121

J.2.2 Consistent........................................................................................................... 123

J.2.3 Valid .................................................................................................................... 124

J.2.4 Adaptable ......................................................................................................... 124

J.3 Respond to changes in the equipment, environment, and technical knowledge

..................................................................................................................................... 125

J.3.1 Equipment Changes........................................................................................ 125

J.3.2 Changes in the environment ......................................................................... 126

J.3.3 Changes in technical knowledge ................................................................127

J.4 The checklists ...................................................................................................... 129

J.5 Demonstrable ..................................................................................................... 129

J.5.1 Human resources............................................................................................. 129

J.5.2 Documentation ............................................................................................... 131

J.5.3 Technical resources ........................................................................................ 132

J.6 Consistent............................................................................................................ 132

J.7 Valid ..................................................................................................................... 133

J.8 Adaptable........................................................................................................... 134

J.9 Respond to changes in the equipment ......................................................... 136

J.10 Respond to changes in the environment .................................................... 137

J.11 Respond to changes in the technical knowledge ...................................... 139

J.12 Long-term improvement of the safety methodology ................................. 140

Appendix K Example safety case.............................................................................. 141

K.1 The environment ................................................................................................. 141

K.1.1 The plant ............................................................................................................ 141

K.1.2 Sensors and actuators..................................................................................... 141

K.1.3 Failure modes.................................................................................................... 141

K.2 Trip system requirements.................................................................................... 141

7/25/2019 ascad_v11a

10/166


6 Version: 1.1

K.3 Candidate system architecture........................................................................142

K.3.1 Redundant channels and thermocouples .................................................143

K.3.2 Fail-safe design features ................................................................................. 144

K.3.3 Separate monitor computer..........................................................................145

K.3.4 Simplicity ............................................................................................................ 145

K.3.5 Formally proved software...............................................................................145

K.3.6 1oo2 high trip logic .......................................................................................... 145

K.3.7 2oo2 low trip logic............................................................................................146

K.3.8 Program and trip parameters in PROM .......................................................146

K.3.9 Modular hardware replacement..................................................................146K.3.10 Use of mature hardware and software tools ............................................146

K.3.11 Access constraints..........................................................................................146

K.3.12 Summary of design features contributing to safety ................................146

K.4 Evidence from the development process .......................................................148

K.5 Long term support activities ..............................................................................148

K.6 Arguments supporting the safety claims..........................................................149

K.7 Supporting analyses............................................................................................153

K.7.1 Probabilistic fault tree analysis.......................................................................153K.7.2 Anticipated change analysis.........................................................................155

K.7.3 Analysis of maintenance and operations ...................................................156

K.8 Safety long-term support requirements............................................................157

K.8.1 Support infrastructure ...................................................................................... 157

K.8.2 Maintenance support risks .............................................................................158

K.8.3 Regular analyses .............................................................................................. 159

K.9 Elaboration to subsystem requirements ...........................................................159

K.9.1 Software Functional requirements ................................................................160K.9.2 Safety case design constraints imposed on the software .......................161

K.9.3 Safety case evidence requirements for the software development ....162

K.9.4 Software documentation/QA requirements...............................................162

K.10 References: ......................................................................................................162

Appendix L Index .........................................................................................................163

7/25/2019 ascad_v11a

11/166


Version: 1.1 7

Part 1 Introduction

1 Scope

This manual defines the Adelard safety case development methodology (ASCAD)which seeks to minimise safety risks and commercial risks by constructing ademonstrable safety case. The ASCAD methodology places the main emphasison claims about the behaviour of the system (i.e. functional behaviour and systemattributes) and methods for structuring the safety arguments which are bothunderstandable and traceable.

The overall approach used in ASCAD is generic and applicable across a widerange of technologies. The details of the approach are concerned with safetycases for computer based command, control and protection systems such asthose found in railway signalling, nuclear reactor protection, air traffic control andsafety critical medical devices as well as many diverse military applications.ASCAD can be applied both to new systems, using bespoke or COTScomponents, and to the retrospective development of safety cases.

Many problems in producing an acceptable safety case can arise from anattitude that regards the safety case as a bolt-on accessory to the system(often produced after the system has been built). At this stage it is oftendiscovered that retro-fitting the supporting safety case is both expensive andtime consuming because the design does not minimise the scope of assessmentand the retrospective production of evidence is expensive. The overall ASCADapproach can be applied to existing systems but the safety case options aremore constrained.

The manual assumes that the reader is familiar with the concepts of safetymanagement systems, quality management systems and safety analysis ingeneral. There is already a large body of guidance in these areas and theuniqueness of this manual is its emphasis on addressing the construction of safetycases. We also assume a familiarity with the system safety context as elaboratedin Appendix A.

7/25/2019 ascad_v11a

12/166


8 Version: 1.1

2 What is a safety case?

We define a safety case as:

Adocumented body of evidence that provides a convincing andvalid argument that a system is adequately safe for a given

application in a given environment

The safety case is a living set of documents which evolve over the life of thesystem. In practice the arguments of the safety case are contained in the safetycase report, a document defining and describing the overall safety case, withreferences to a number of supporting documents.

3 The importance of a good safety case

It is important that an adequate safety case is produced for a safety relatedsystem in order to:

1. Ensure an adequate level of safety

2.

Ensure that safety is maintained throughout the lifetime of the system

3.

Minimise licensing risk (being able to demonstrate safety to the regulatorsand assessors)

4. Minimise commercial risk (ensuring implementation and maintenancecosts are acceptable)

A safety case is a requirement in many safety standards and industries. Explicitsafety cases are required for military systems, the off shore oil industry, rail transportand the nuclear industry. Furthermore, equivalent requirements can be found inother industry standards, such as the emerging IEC 61508 (which requires afunctional safety assessment) the EN 292 Machinery Directive (which requires a

technical file) and DO 178B for avionics (which requires an accomplishmentsummary).

4 Basis of the ASCAD methodology

Adelard has developed this methodology over several years. Initially the ideaswere the product of research studies, but this methodology has been applied in:

Specific safety cases for a number of command and control systems

7/25/2019 ascad_v11a

13/166


Version: 1.1 9

The safety case for the DUST-EXPERTadvisory software produced by

Adelard for the Health and Safety Executive.

The development of safety standards such as MOD Def Stan 00-55

A generalised form in Def Stan 00-42 Part 2, as the software reliability case

The development of a Software Assessment Manual to IEC 61508 forFactory Mutual Research Corp.

The approach has evolved during this period, but the evolution is largely throughextensions to the methodology rather than changing earlier ideas. While the

methodology is likely to evolve further, we believe that our current ASCADprovides a good basis for safety case development.

5 How to use the manual

Part 1 of the manual provides some introductory material. The methodology itselfis described in Part 2. Part 2 is structured as follows:

Section 2 provides an overview of the technical approach

Section 3 defines the different elements of safety cases and their relationshipto the project and safety lifecycles. Guidance on the development of thesafety case elements is provided in detail in sections 47.

Section 4 provides guidance on the Preliminary safety case element

Section 5 provides guidance on the Architectural safety case element. Thisleads into the need for design for assessmentcovered in Section 5.1

Section 6 provides guidance on the Implementation safety case element

Section 7 describes the Operation and Installation safety case elementSection 8 describes how to combine the safety case elements into a safetycase structure for a real project

Section 9 discusses the independent assessment of the safety cases

Section 10 deals with the important topic of long term maintenance of thesafety case

Section 11 discusses the contents of the safety case report and referenceschecklists of supporting documents.

7/25/2019 ascad_v11a

14/166


10 Version: 1.1

The main guidance is supplemented by appendices containing supporting

information, checklists, and an example safety case for a simple application.

The manual can be read from a number of different viewpoints.

New to safety cases?

Section 2 provides an overview of the approach. Also consider Appendix Awhich provides an overview of the system safety context. It might also beworth browsing Section 11 to get an idea of the contents of a safety caseand the example in Appendix K.

Wishing to construct a safety case?

It may be worth browsing the introductory material but the main startingpoint is Section 3. This will provide signposts to the guidance on the differentelements of the safety case. Before starting it would be worth looking at theexample in Section K.

An experienced safety case developer?

Again, browse the overview and start with Section 3. One of the differencesbetween this manual and other published material is the emphasis on designfor assessment (see Section 5.1 and the checklists in Appendix D). The

tabular approach to safety case development will also probably be new(see Sections 5 and Section 6.1). Also Section G, which discusses at lengththe use of field experience, may be unfamiliar.

An independent assessor or regulator?

There is a specific section on assessment (Section 9) with a supportingchecklist in Appendix F. Long term issues are often not given sufficient weightso consider Section 10 as well.

Concerned about long term issues?

Section 10 is specifically devoted to long term issues and refers to a numberof supporting appendices.

Developing a safety case retrospectively?

The methodology does not only apply to new systems. However theevidence and arguments used can be different. Of particular interest will beAppendix G, which discusses at length the use of field experience

There are a variety of checklists to support the safety case construction. These areindicated with a tick.

7/25/2019 ascad_v11a

15/166


Version: 1.1 11

6 Feedback

We are keen to receive feedback on this manual. Please send comments [email protected], see our www page at http://www.adelard.co.uk or writeto Robin Bloomfield, Adelard, 3 Coborn Road, London E3 2DA.

7 Acknowledgements

The manual was produced by Peter Bishop, Robin Bloomfield, Luke Emmet, ClaireJones and Peter Froome. Some of the underlying technical work was undertakenin the CEC sponsored SHIP project (ref. EV5V 103). More recent material has comefrom the Quarc project funded by the UK (Nuclear) Industrial ManagementCommittee (IMC) Nuclear Safety Research Programme under Scottish Nuclearcontracts 70B/0000/006384 and PP/74851/HN/MB.

7/25/2019 ascad_v11a

16/166


12 Version: 1.1

7/25/2019 ascad_v11a

17/166


Version: 1.1 13

Part 2 Description of thesafety case methodology

1 Introduction

This manual describes our approach to developing safety cases for computerbased command, control and protection systems. It provides technical rationale,an explanation of how to construct safety cases, and supporting checklists andexamples to help with the efficient and practical development of safety case.

The manual is structured as follows:

Section 2 provides an overview of the technical approach

Section 3 defines the different elements of safety cases and their relationshipto the project and safety lifecycles. Guidance on the development of thesafety case elements is provided in detail in sections 47 below.

Section 4 provides guidance on the Preliminary safety case element

Section 5 provides guidance on the Architectural safety case element. Thisleads into the need for design for assessmentcovered in Section 5.1

Section 6 provides guidance on the Implementation safety case element

Section 7 describes the Operation and Installation safety case element

Section 8 describes how to combine the safety case elements into a safetycase structure for a real project

Section 9 discusses the independent assessment of the safety cases

Section 10 deals with the important topic of long term maintenance of thesafety case

Section 11 discusses the contents of the safety case report and referenceschecklists of supporting documents.

7/25/2019 ascad_v11a

18/166


14 Version: 1.1

The main guidance is supplemented by appendices containing supporting

information, checklists, and an example safety case for a simple application.

2 Overview of approach

2.1 Safety case principles

We define a safety case as:

a documented body of evidence that provides a demonstrable andvalid argument that a system is adequately safe for a given application

and environment over its lifetime.

To implement a safety case we need to:

make an explicit set of claims about the system

produce the supporting evidence

provide a set of safety arguments that link the claims to theevidence

make clear the assumptions and judgements underlying thearguments

allow different viewpoints and levels of detail

The following sections describe how we think a safety case should be structuredto meet these goals.

2.2 Safety case structure

The safety case should:

make an explicit set of claims about the system

provide a systematic structure for marshalling the evidence

provide a set of safety arguments that link the claims to the evidence

make clear the assumptions and judgements underlying the arguments

provide for different viewpoints and levels of detail

7/25/2019 ascad_v11a

19/166


Version: 1.1 15

A safety case consists of the following elements: a claim about a property of the

system or some subsystem; evidencewhich is used as the basis of the safetyargument; an argumentlinking the evidence to the claim, and an inferencemechanism that provides the transformational rules for the argument. This issummarised in the figure below.

Figure 1: Safety case structure

Note that evidence can be asub-claimproduced by a subsidiary safety-case.This means that there can be a relatively simple top-level argument, supported bya hierarchy of subsidiary safety cases. This structuring makes it easier tounderstand the main arguments and to partition the safety case activities.

Different types of argument can be used to support claims for the attributes:

Deterministic application of predetermined rules to derive a true/falseclaim (given some initial assumptions), e.g. formal proof ofcompliance to a specification, or demonstration of a safetyrequirement (such as execution time analysis or exhaustivetest of the logic)

Probabilistic quantitative statistical reasoning, to establish a numericallevel (e.g. MTTF, MTTR, reliability testing)

Claim

Evidence

Evidence

Subclaim

Inference rule

Inference rule

Argument structure

7/25/2019 ascad_v11a

20/166


16 Version: 1.1

Qualitative compliance with rules that have an indirect link to the

desired attributes (e.g. compliance with QMS standards, staffskills and experience)

The choice of argument will depend on the available evidence and the type ofclaim. For example claims for reliability would normally be supported by statisticalarguments, while other claims (e.g. for maintainability) might rely on morequalitative arguments such as adherence to codes of practice.

In addition the overall argument should berobust, i.e. it should be valid even if

there are uncertainties or errors. For example, two independent arguments couldbe used to support the top level safety claim about a given system. Alternatively,if there are two independent systems that can assure safety, it may only benecessary to have a single argument for each one. Typically the strength of theargument will depend on the integrity level associated with the specific system. Atthe highest integrity level (Level 4) we might expect two independent argumentsfor a single system regardless of the existence of other systems, as illustrated inFigure H0 below

Figure 2: Illustration of a robust claim

The development of the safety case should be alert to the possibility of evidencethat detracts from or possibly refutes the claims being made.

The safety case needs to be viewed at various levels of detail. A top-level safetycase might be decomposed into a hierarchy of sub-claims which are treated asevidence in the top level safety caseso the evidence used at one level of theargument can be:

facts, e.g. based on established scientific principles and prior research

Evidence B

Evidence A

Evidence C Ar ument 2

Argument 1Claim

7/25/2019 ascad_v11a

21/166


Version: 1.1 17

assumptions, which are necessary to make the argument, but may not

always apply in the real world

sub-claims, derived from a lower-level sub-argument

This is a recursive structure which can represent arguments at successively finerlevels of detail. This structure could evolve over the lifetime of the project. Initiallysome of the sub-claims might actually be design targets, but as the systemdevelops the sub-claims might be replaced by facts or more detailed sub-arguments based on the real system. Deviations in implementation can beanalysed to see how they affect a sub-claim, and how changes in a sub-claimripple through the safety argument.

If correctly designed, the top-level safety case should remain substantially thesame as the design evolves, and many of the detailed sub-arguments andevidence can be referenced out to supporting documents or subsidiary safetycases. The evolution of the safety case at the top-level should be confined mainlyto the changing status of the supporting sub-claims and assumptions. For examplethere may be an assumption that some tool will operate correctly, and this maybe later supported by explicit field evidence or analysis. The status of theassumption would then change from unsupported to verified with a cross-reference to the supporting document.

2.3 Types of claim

The safety case is broken down into claims about different attributes for thevarious sub-systems, e.g.:

reliability and availability usability (by the operator)

security (from external attack) fail-safety

functional correctness accuracy

time response robustness to overload

maintainability modifiability

The relevant attributes should be identified and, where possible, quantified. Notethat the attributes listed are only examples and further attributes may be safety-relevant. This is elaborated later in Section 4.2.1.

2.4 Sources of evidence

The arguments themselves can utilise evidence from the following main sources:

7/25/2019 ascad_v11a

22/166


18 Version: 1.1

the design

the development processes

simulated experience (via reliability testing)

prior field experience

The choice of argument will depend in part on the availability of such evidence,e.g. claims for reliability might be based on field experience for an establisheddesign, and on development processes and reliability testing for a new design.

2.5 Style of argument

In safety related systems, we are primarily concerned with dangerous failures, andthe safety argument should be focused on ways of inhibiting a dangerous failure.To do this, we first have to establish whether there is a known safe state for thesafety system or component. In the application described in Appendix K, there isa known safe state so the design can be biased to fail in that direction.

Even in cases where there is no safe state for the hazardous plant (e.g. an aircraft,or an unstable chemical process) it may still be possible to identify a safe state forthe subsystem (such as a transfer to a backup system or manual control). Thenature of the safety case argument will depend on the existence or otherwise ofthese safe states.

This possible strategy for maximising safety is very similar to the one followed forthe top-level plant safety (i.e. hazard elimination, control, and accidentmitigation). For the subsystems, the hazards are more indirecta hazardoussubsystem state could, in combination with other failures, lead to an accident. Atthese lower levels, we need to consider how hazardous subsystem states couldarise (i.e. what random and systematic faults could lead to a hazardous state),and then minimise the probability of occurrence by a combination of faultelimination, fault tolerance, and failure mitigation (normally fail-safety).

We can characterise the various approaches to limiting the dangerous failurerate in the following figure.

7/25/2019 ascad_v11a

23/166


Version: 1.1 19

Figure 3: Model of system failure behaviour

This fault-error-failure model can be applied at the level of a complete system orfor sub-components (e.g. the software level). A faultis a defect in the system andis the primary source of the failure. However a system will probably operate asintended until some triggering input condition is encountered. Once triggered,some of the output values will deviate from the design intent (an error). However

the deviation may not be large enough (or persist long enough) to be dangerous,so the system may recover naturally from the glitch in subsequent computations(self healing). Alternatively explicit design features (e.g. diversity or safetykernels) can be used to detect such deviations and either recover the correctvalue (error recovery) or override the value with a safe alternative (fail-safety).

The chance of a dangerous failure transition would normally be expressed inprobabilistic terms, but it might also be expressed in deterministic terms (this cannever happen), or qualitative terms (e.g. two barriers must fail before this canhappen).

OKState

ErrorState

DangerState

SafeState

Transition depends on: fault tolerance in

design nature of application

(grace time, self-healing?)

Safe failure

Dangerous failure

Fault activation

Error correction

Transition dependson: fail-safe design

partitioning existence of safestates

Transition depends on:fault freenessKISS, partitioning, novelty,implementation quality,past operating experience

7/25/2019 ascad_v11a

24/166


20 Version: 1.1

A particular safety argument can focus on claims about particular transition arcs.

The main approaches are listed below:

A fault eliminationargument can increase the chance of being in theperfect state and can hence reduce or eliminate the OK erroneoustransition. This is the reasoning behind the requirement to use formal methods(e.g. in MOD DS 00-55) which essentially supports a claim that the errortransition rate is zero because the software correctly implements thespecified logical behaviour.

A failure containmentargument can strengthen the erroneousOK orerroneous safetransition. An example would be a strongly fail-safe design

which quantifies the fail-safe bias. This, coupled with test evidence boundingthe error activation rate, would be sufficient to bound the dangerous failurerate.

A failurerateestimationargument can estimate the OK dangeroustransition. The whole system is treated as a black-box, and probabilisticarguments are made about the observed failure rate based on pastexperience or extensive reliability testing.

It is also possible to apply the arguments selectively to particular components orfault classes, e.g.:

A design incorporates a safety barrier, which can limit dangerous failuresoccurring in the remainder of the system. The safety argument would thenfocus on the reliability of the barrier rather than the whole system.

Different countermeasures might be utilised for different classes of fault.Each fault class then represents a separate link in the argument chain, andall fault classes would have to be covered to complete the argument chain.For example, design faults might be demonstrated to be absent by formaldevelopment, while random hardware failures are covered by hardwareredundancy.

While normally applied to incorrect logical behaviour, the same approach canbe applied to many of the other safety attributes. For instance to ensuretimeliness, timing errors could be:

eliminated by a design that ensures a maximum response time

mitigated using independent timing checks to force the output to a safestate

A similar strategy could be applied for other safety-related attributes (e.g.accuracy, security and maintainability).

7/25/2019 ascad_v11a

25/166


Version: 1.1 21

3 Safety case development

3.1 Safety case elements

The development of a safety case does not follow a simple step by step processas the main activities interact with each other and iterate as the design proceedsand as the level of component in the system changes. We have identified fourelements from which, in different combinations, one can construct the safetycases required on a real project. The elements are:

Preliminary

Architectural

Implementation

Operation andInstallation

The scale and nature of a project will determine the number and type of safety

case elements required. There may be a recursive structure with multiplePreliminary and Architectural elements within the system and sub- safety cases.The structuring of these elements on real projects is discussed in Section 8.

The characteristics of the safety case elements are, whether one is considering anew or off the shelf system, as follows.

Preliminary safety case element

1. This establishes the system context, whether the safety case is for acomplete system or a component within a system, and the phase of theproject lifecycle

2.

It also establishes safety requirements and attributes for the level of thedesign and interfaces to the system safety analysis

3. It defines operational requirements and constraints such as maintenancelevels, time to repair.

Architectural safety case element

1.

This defines the system or sub-system architecture and makes trade-offsbetween the design of the system and the options for the safety case.

7/25/2019 ascad_v11a

26/166


22 Version: 1.1

2. It defines the assumptions that need to be validated and evidence to be

provided in the component safety cases.

3.

It also defines how the design addresses the preliminary operating andinstallation aspects for the safety case (e.g. via maintainability,modifiability, and usability attributes).

Implementation safety case element

1. This safety case provides the justification that the design intent of thearchitectural safety case has been implemented and that the actualdesign features and the development process followed provides the

evidence that the safety requirements are satisfied.2. Additional assumptions for operation and maintenance are identified

and detail provided on how to meet the operational requirements.

Operation and installation safety case element

1.

This safety case adds detail to the maintenance and supportrequirements identified in the implementation safety case.

2. It defines any safety related operational procedures identified in thepreliminary safety case or Architectural safety case.

3.

For a COTS system, the safety case would include the safety justificationof the specific configuration, and human factors-related issues such asstaffing requirement s and competence levels, training of operators andmaintenance personnel and facilities for long-term support.

4. The safety case would also record and resolve any non-compliances withthe original safety requirements.

Note: the reason for separating out the Architectural safety case is theimportance that good design has in ensuring safety. In our experience this is often

a neglected area of safety engineering and standards.

4 Developing Preliminary safety case elements

A Preliminary safety case element establishes the system and safety context:whether the safety case is for a complete system or a component within a system,the phase of the project lifecycle and defines the safety requirements andattributes. To achieve this it is necessary to:

1. Define the system and equipment that a safety case is being developed

for and assess existing information about the project

7/25/2019 ascad_v11a

27/166


Version: 1.1 23

2. Select relevant attributes and define safety requirements as claims from

them

3.

Provide traceability to system and other sub-system safety cases

4.

Establish project constraints on design options and availability ofevidence

5. Assess potential long term changes to the safety case context

The extent to which this involves just marshalling existing information and theextent to which it requires new analysis is of course very project dependent. Somelegacy systems may have none of this information available.

4.1 Definition of system and project

4.1.1 Operating context

Establish the operating context for the safety system including:

external equipment (e.g. the plant or other equipment)

interfaces to environment (e.g. actuators, sensors, data links)

failure modes of external equipment and interfaces

the safe and hazardous plant states (or equipment states) and targetfailure probabilities

hazardous / safe states of the interfaces

anticipated changes in external equipment, interfaces and operatingmodes

any operational or maintenance requirements such as maintenancelevels, repair times, manning intervals

4.1.2 Identify any defined PES (Programmable Electronic System) or

component safety requirements

Identify any top level safety requirements for the components that have beendefined. These might include:

safety functions

7/25/2019 ascad_v11a

28/166


24 Version: 1.1

reliability requirements

other safety attributes

applicable design criteria and standards

anticipated changes over its lifetime

4.1.3 Existing safety and project information

Establish the extent and quality of the existing safety documentation and the

requirements of any safety management system. A checklist of safetydocumentation is provided in Appendix C.

4.2 Develop claims from attributes

The safety case is broken down into claims about different attributes for thevarious sub-systems. The relevant attributes should be identified and, wherepossible, quantified. Below is a suggested list of safety attributes at two levels: thecomputer system level and the software level.

Note that the attributes listed are only examples and further attributes may be

safety-relevant. Conversely, for some applications not all attributes need besafety-related. For example

security might be addressed by physical barriers

fault tolerance may be implemented in hardware

time response would not be safety-relevant for off-line stress analysisprograms, but it would be necessary to have accuracy and functionalcorrectness

4.2.1 Computer system architecture

Some of these attributes may not be relevant or may be addressed by other partsof the system The appropriate set of safety attributes should be identified for thespecific application.

7/25/2019 ascad_v11a

29/166


Version: 1.1 25

System attributes

Accuracy

Availability

Fail-safety

Logical correctness

Maintainability (e.g. MTTR)

Maximum input and output data rates

Maximum response time

Maximum storage capacity (e.g. permanent records)

Modifiability (with respect to identified functional changes)

Real-time performance

Reliability (e.g. MTTF, pfd)

Response to hardware failures

Response to internal failures

Response to overload (data rate, internal storage)

Security

Timeliness

Usability

Table 1: Computer system attributes

4.2.2 Software attributes

This is a suggested list of safety attributes for the software. Many of therequirements at the computer system level will be converted into functionalrequirements for the software and hardware, so for example logical correctnessat the software level may be needed to implement the security attribute at the

computer system level. Some of these attributes may not be relevant to the

7/25/2019 ascad_v11a

30/166


26 Version: 1.1

software or may be addressed by other parts of the system (e.g. fault tolerance

may be implemented entirely in hardware). In addition, the softwareimplementation must cope with the constraints imposed by the specific choice ofhardware.

Software attributes

Accuracy

Compliance with hardware constraints (e.g. memorycapacity)

Fail-safety

Fault tolerance

Logical correctness (sometimes represented by thesoftware integrity level)

Maintainability

Modifiability (with respect to identified functionalchanges)

Reliability

Response to hardware failures

Response to internal failures

Response to overload (data rate, internal storage)

Time response

Table 2: Software attributes

4.3 Traceability between levels

The top-level requirements are transformed into derived requirements as thedesign proceeds producing a layered safety case. In the example below, a top-level overall safety target (a worst case accident rate) is progressivelytransformed into derivedrequirements for subsystems.

7/25/2019 ascad_v11a

31/166


Version: 1.1 27

Initially these might be attributes such as security or maintainability, but at amore detailed level of implementation these requirements will be converted intodesign requirements that are implemented in one or more subsystems. It isimportant that there is traceability between these levels so that there is a clear linkbetween the design features and the safety attributes. The subsidiary safety casesfor the subsystems should identify the design features and present arguments tosupport claims that they implement the safety attributes. The traceability between

levels is illustrated in the figure below:

Plant SafetyRequirement

SafetyFunctions 1

SafetyFunctions 2

SoftwareFunctions

System

Architecture

ComputerSystem Functions

HardwareFunctions

ComputerSystem Functions

Target for top event

(Accident probability)

Dangerous failure rateAvailabilityIntegrity attributesPerformance attributes

Dangerous failure rateAvailability

Integrity attributesPerformance attributes

Dangerous failure rate

AvailabilityResidual attributes

Dangerous failurerateAvailability

7/25/2019 ascad_v11a

32/166


28 Version: 1.1

In this way layered safety cases are developed, i.e. a top-level safety case withsubsidiary traceable safety cases for subsystems.

4.4 Establish project constraints

The extent to which the design can be changed and the availability and costs of

different types of evidence are two very important considerations in thedevelopment of the safety case strategy. Each project will be faced with differentimmutable realties and these should be established as early as possible in thesafety case development. Two extreme examples are:

The development of a new safety case in conjunction with a new system

The development of a safety case for an existing legacy system

The first is characterised by freedom to choose design options and an absence ofoperating experience. The latter has no design freedom but a potentially largebody of operating experience.

Availability

Modifiability

Security

Additional softwareallow parameterisation

Recovery routines

Hardware

Voting algorithmsRedundant channels

Data encryptionmechanisms

Password authenticationnetwork isolation

7/25/2019 ascad_v11a

33/166


Version: 1.1 29

Checklist of project constraints

Design freedoms

To what extent can the design of the system be influenced?

If the design of the component is frozen are there other design optionsavailable? e.g. add additional systems or components

Is there scope for design for assessment which takes into account thecosts and complexity of the safety case as well as the design?

Availability of evidence

Is there operating experience with the component? If so, how much,how similar?

Is there evidence about the engineering process used to develop andassure the component? If so, what type of data, of what quality? If not,what are the likely costs of obtaining the evidence?

Is there analytical or empirical evidence about the behaviour of the

component? Does the data include safety relevant situations? Is itrelevant to this application?

Are there existing safety cases e.g. for generic system, or similar system?

4.5 Long term issues

The safety case context should include an assessment of the expected changesover the lifetime of the safety case. A checklist of issues to consider is provided inTable H0. The background to the lists is provided in Appendix E.

7/25/2019 ascad_v11a

34/166


30 Version: 1.1

Checklist of potential changes

Support environment changes

Changes to equipment maintenance and operation procedures (e.g. toincrease the intervals between maintenance)

Obsolescence of test and analysis hardware and software

Obsolescence/ upgrades of support tools (compilers, linkers, archivingtools, document browsers, etc.)

Hardware changes

Obsolescence of computer hardware

Obsolescence / replacement of interface equipment (sensors,actuators)

Interfaces to new systems

Software changes

Data changes (trip levels, configuration options)

Functional changes (new safety logic, support for new interfaces)

Changes to other attributes (timing, accuracy, storage capacity)

Changes in safety criteria

More stringent requirements on diversity of subsystems

More stringent requirements for system and channel isolation

Increased integrity requirements for software

Additional / stronger safety arguments to support claim

Table 3: Checklist of potential changes

There is also the need to plan ahead in the design of the safety case andconsider long term support issues. These are discussed in Section 10 and inparticular it may be necessary to conduct asafety case infrastructure assessment

(see Appendix H.2).

7/25/2019 ascad_v11a

35/166


Version: 1.1 31

5 Developing Architectural safety case elements

A Architectural safety cases provides the first level of detail of the safety case. Itinvolves:

1.

Establishing the safety requirements either by importing the Preliminarysafety case and/or repeating it for the changes that have occurred (e.g.revised safety analysis, more detail of design).

2.

Evaluating design options or existing features to assess their relevance tothe safety case claims and attributes.

3.

Adopting a design for assessment approach to develop a solution foreach safety attribute claim.

4. Elaborating the evidence to show that the claim is met and more usuallyfor this type of safety case defining the evidence that is required to becollected.

5. Identifying the requirements that will be passed onto subsystems toimplement the architectural requirements.

6.

Undertaking a risk assessment to identify any additional hazards arising

from: random failures, systematic faults or human errors in operations andmaintenance.

7. Assessing any additional risks introduced by the subsystem to ensure theyare acceptable in the context of the overall safety case.

The development of the Architecture safety case can be seen as theprogressive completion of a table for each attribute:

7/25/2019 ascad_v11a

36/166


32 Version: 1.1

Example tables are provided in Appendix D.

5.1 Design for assessment

In systems where there is design freedom to influence the design a design forassessment approach is advocated where the safety system and the safety casearguments are designed in parallel. In other more constrained situations thedesign features that can contribute to the safety argument need to be identifiedand evaluated.

By integrating the safety case into the design, the feasibility and cost of the safetycase construction and maintenance can be evaluated in the initial design phase.This design for assessment approach should help exclude unsuitable designsand enable more realistic design trade-offs to be made. The need todemonstrate safety can be a very significant factor in the overall costs. Forexample the Darlington computer-based reactor trip software was considered tobe too complex to understand and difficult to maintain. As a result, around 50

This is from thePreliminarySafety Case.See Section 4

These are selected orthose presentevaluated using thefault avoidance, thetolerance and fail-safe bias approach.See Section 5.1.

Used todocument andtraceassumptions.See Section 5.3

The evidenceeither needed(assumption) orused tosubstantiate the

claim is recordedhere.See Section 5.2

Attribute: Functional Behaviour

Claim Design Features Assumption

/Evidence

Subsystem

Requirements

Design optionsSee Section 5.1 and checklists in Appendix B

Attribute Fault Avoidance Error Tolerance Fail-safe bias

7/25/2019 ascad_v11a

37/166


Version: 1.1 33

man-years of effort was expended in software analysis, combined with extensive

statistical testing of the software using simulated trips. This resulted in severalmonths of licensing delay and the loss of several million pounds in lost generation.Further costs will be incurred, as the software must be rewritten to make it moremaintainable. In this case, a design that permitted a more convincing safety casewould have been very cost-effective, even if the implementation costs werehigher.

The design should incorporate defences against anticipated hardware failures,design flaws and human errors that could affect the functional behaviour of thesystem. Three main strategies exist for ensuring safety: fault avoidance, errortolerance and fail-safe bias. The tables in Appendix B identify potential defences

under these three main headings.

It is difficult to be specific about the choice of appropriate design and safetycase options that are likely to be both cost effective and convincing, but somegeneral design strategies are given below.

5.1.1 Keeping it simple (KISS)

Simplicity has many benefits: it can reduce the costs of implementation, thesafety case is easier to understand and, as a consequence, the risks of licensingdelays are reduced. While this may sound obvious, actually achieving simplicity is

quite difficult and it is all too easy to introduce unnecessary design complexitywhich then has to be justified with a more complex safety case and moreextensive evidence.

Avoidance of complexity should be considered at an early stage in the designprocess. It is often possible to choose a safety system architecture that eliminatesor at least reduces dependence on complex computer-based systems andhence reduces the problems of constructing safety software. Take for example aproposal to replace existing pressure limit switches (illustrated below).

Figure 4: Original design

The operational goals are to improve availability and reduce time-consumingmanual checks (e.g. valving off a pipe to perform an over-pressure test). Onepossibility is to replace each switch with a smart sensor; intelligent cross-

Safety logic

Pressure limitswitch

HighPressurePipe (1,000 metres)

7/25/2019 ascad_v11a

38/166


34 Version: 1.1

comparisons between sensors can identify failures and hence improve fault

diagnosis and availability. However the safety justification would be extremelydifficult without detailed analysis of the smart sensor software and hardware. Infact it is possible to produce a simple design which meets the safety andoperational requirements without excessive reliance on computer-basedelements as shown below.

Figure 5: Simple replacement design

The main difference is that an analoguepressure measurement is made in the

pipe rather than using a binary switch. By adding some spy-points, theperformance of the external pressure switches can be continuously monitoredand cross-compared by a single computer. It is relatively easy to justify the mainsafety logic as it uses well-established, simple components. Failure of thecomputer will interrupt monitoring but this has no immediate safety impact, so themonitoring functions could be readily implemented on the existing station dataprocessing system or a simple low-integrity PLC.

5.1.2 Partitioning according to criticality

Even in cases where computers are assigned a safety critical function, it is possibleto minimise design complexity by partitioning the design according to criticality.For example the Digital Trip Meter developed for Ontario Hydros Pickering Bnuclear power station is a simple device which trips on a single parameter. Tofurther minimise the complexity, the basic trip function is implemented in anentirely separate computer. The more complex but less critical display andmonitoring functions are implemented in a second computer. This makes it easierto justify the integrity of the main trip function. A similar approach is used in railwaycomputer-based safety interlocking equipmentthe interlocking and monitoringfunctions are implemented on separate computers.

Safety logic

spy-points for monitor computer

Isolatedrepeatersignals

Limit Switch

4-20 mA signal

(1,000 meters)

AnaloguePressure SensorHigh

Pressure

Pipe

7/25/2019 ascad_v11a

39/166


Version: 1.1 35

The reactor trip system design in Appendix K provides a further example of

partitioning. Complex diagnostic functions are excluded by implementing themon a separate machine. The choice of this architecture simplifies the design of themain safety software, which is then easier to implement, analyse, test and justify ina safety case.

5.1.3 Avoidance of novelty

Established systems and components have an established track record and pastfield experience. The availability of existing evidence of fitness for purpose (e.g.failure rates, failure modes and resistance to environmental attacks) reducesuncertainty in the safety case arguments and the need to produce new

evidence to support the safety argument. The over-pressure switch example citedearlier is an example of a system design that uses established analoguecomponents to simplify the associated safety case arguments.

Where computer-based systems are used, a similar approach can be employed.Commercial off the shelf (COTS) systems and software components can benefitfrom past experience. Mature versions of software are likely to be more reliablethan new ones. This also applies to complex hardware chips. For example, over100 design faults have been reported in the five generations of the Intel processorchip (from the 8086 to the Pentium). Of these faults, most were present in the earlyversions of each chip design and were subsequently removed in the later versions

of the chip.

Even with established components, it is difficult to extrapolate from existingexperience if the operating conditions are novel. Risks can be reduced byavoiding unusual modes of use and operating environments.

5.2 Sources of evidence

A preliminary safety case argument should be developed for the outlinearchitecture, which shows why the candidate design satisfies the safety relatedrequirements. This could use evidence from:

System Hazard Analysis, Fault Tree Analysis, etc.

Human Error Analysis (addressing the safety impact of maintenance andoperational actions, and the safeguards)

probabilistic design assessments (of reliability, availability, fail-safety andperformance)

qualitative design assessment studies (of complexity, analysability and

novelty)

7/25/2019 ascad_v11a

40/166


36 Version: 1.1

resource estimates for the implementation and the associated safety

case (effort, cost, time)

prior evidence about specific design techniques

independent certification (e.g. for COTS products)

experience from existing systems in field operation

5.3 Design assumptions

Almost inevitably, the safety case for the top-level design will have to makedesign assumptions that need to be verified at a later stage. It is also necessary toidentify how the integrity of the design and the associated safety case will bemaintained over the lifetime of the safety system. It is therefore necessary toidentify:

requirements for additional safety case evidence to be produced duringthe project (e.g. specific tests and analyses)

requirements for the long term maintenance and operation of theequipment

requirements for long-term safety case maintenance (e.g. to handlepossible changes in safety function or technology)

5.4 Choosing a suitable system architecture and safety case

It can be seen from the example tables in Appendix D that there are manypossible arguments and architectures that could be used to meet the safetyrequirements, and the choices can affect the requirements placed on the

subsystem components. For example, a triple modular redundant hardwaredesign (TMR) could minimise the need for software-based hardware integritychecks. Equally it may be feasible to reduce the criticality of the software by usinghardware safety devices, diverse safety functions or diverse softwareimplementation. Some safety standards such as Def Stan 00-56 define basic rulesfor system architectures for a given integrity level. There may also be specificdesign criteria, based on prior design consensus, that are deemed essential for asafety system.

Typically, some candidate design options will be identified and a preliminarysafety case will be constructed. This will normally be an iterative process, which

involves the identification of hazardous subsystem states (e.g. through some form

7/25/2019 ascad_v11a

41/166


Version: 1.1 37

of hazard analysis), and appropriate countermeasures (elimination, reduction and

failure mitigation, see Appendix B). The design and safety case are then assessedto establish whether:

the design implements the safety functions and attributes

the design criteria are satisfied

the design is feasible

the associated safety arguments are credible

the approach is cost-effective

A more detailed review checklist is given in Appendix F. In this assessment process,the costs of implementing the safety system andthe associated safety caseshould be considered during the architectural design phase. This analysis shouldalso include a consideration of the long-term safety risks and lifecycle supportcosts involved in:

changing the safety functions

changing the hardware (e.g. due to obsolescence)

maintaining the equipment

maintaining the associated safety case

A checklist of potential changes is given in Table H0. An explicit list of anticipatedchanges should be constructed, and the initial system should be designed tocater for these changes.

5.5 Risk assessment and review

Having produced the outline design and safety case argument, a risk assessmentshould be performed, to identify any additional hazards arising from:

random failures

systematic faults

human errors in operations and maintenance

This could utilise techniques such as FMEA, Hazops, and Human Reliability Analysis.

7/25/2019 ascad_v11a

42/166


38 Version: 1.1

The additional risks introduced by the subsystem should be assessed to ensure

they are acceptable in the context of the overall safety case. The feasibility andcost should also be reviewed. This will require the involvement of the primecontractor, and subsystem developer. Any changes and trade-offs will require theagreement of the affected parties (e.g. regulator if safety case is changed,operator if functionality changed).

It is also necessary to assess the safety case feasibility and cost. This assessmentshould consider:

Implementation risk (addressing cost, novel designs and techniques,design complexity, and need for ALARP).

Supplier risk assessment (if known). This could be based on factors such aspast track record, technical skills, documentation standards, qualitymanagement standards, etc.

Licensing risk (addressing credibility of arguments, assumptions andevidence, analysability of design, risks in obtaining the required evidence,and compliance with design criteria and standards).

Safety case support risks concerning the long-term ability to sustain thesafety case (e.g. impact of functional changes, specialist skills, tools,

hardware obsolescence, regulatory changes).

Having identified the risks, the options and possible trade-offs should be reviewed.This review will include the viewpoints of the developer, operator, licenser,purchaser and maintainer. Also, the candidate design, system requirements,safety case evidence and arguments, and the long term support requirements,should be agreed with these stakeholders.

Appendix F provides a checklist for safety case reviewing.

6 Developing Implementation safety case elements

The Implementation safety case element completes the safety case in the sensethat it provides arguments and evidence to support the safety claims being madeabout the component being implemented. Developing the Implementationsafety case element involves:

1. Establishing the component safety requirements either by importing themfrom a Preliminary safety case element and/or by activities specific to thiscase.

2.

Elaborating the evidence to show that the claims are met.

7/25/2019 ascad_v11a

43/166


Version: 1.1 39

3. Documenting the results and providing traceability to the appropriate

Preliminary and Architecture safety case elements.

The preliminary subsystem (or component) and architecture safety case elementsshould have identified the evidence needed for the implementation safety case(e.g. test results, proofs, checks of assumptions, justification of tools, etc.). Thisevidence is now gathered either as part of the normal development processes or,for some retrospective safety cases, through additional technical investigations.The key distinction between this and the other safety cases is that the evidence isnow provided to support the claims.

The evidence can be a combination of:

design features and supporting analyses (e.g. failsafe bias anddemonstration of the strength of the feature)

process features and results of the process (e.g. worst case timinganalysis)

experience either real or simulated (e.g. via statistical testing) and, moreusually for this type of safety case defining the evidence that is requiredto be collected.

and could arise from:

normal verification and validation activities

tests and analyses to check specific safety attributes (e.g. time response,response to overload, fail-safe bias, fault diagnosis performance, etc.)

tests of design assumptions (i.e. fail-safety, fault detection coverage, etc.)

more general safety analyses on the system design such as failure modesand effects analysis (FMEA) and common cause failure analysis (CCF)

The completed implementation safety case for a subsystem will provide evidencethat:

the design features, V&V and safety analysis demonstrate that therequired attributes were implemented

all sub-contracted components have been implemented to specification,and implement their required attributes

7/25/2019 ascad_v11a

44/166


40 Version: 1.1

all deviations are documented, and their impact has been analysed and

justified

As the project evolves the results of this subsidiary safety case will be incorporatedin the higher level system safety case. The actual subsystem components wouldthen be integrated into the overall system according to an integration plan. Aspart of this process, the safety case may require evidence from:

conventional V&V tests

tests for specific system attributes

tests of design assumptions

hazard analyses on the final design

6.1 Attribute-claim-evidence tables

The development of the safety case can be seen as the progressive completionof an attribute-claim-evidence table for each attribute. The following tableillustrates the types of claim that might be made for the correctness of the safetyfunction or other safety-related attributes of the software which have been

identified in the system-level safety case, and which are apportioned to thesoftware for the system. The text in italics refers to additional evidence which isderived by V&V activities when the system has been partially or whollyimplemented.

7/25/2019 ascad_v11a

45/166


Version: 1.1 41

AttributeCorrectness

Claim Argument Evidence/Assumptions

There is nological fault inthe softwareimplementation

Formal proof ofspecified safetyproperties

Formal proof that codeimplements itsspecification

The design is simple enough to beamenable to proof

Proof tool is correct (or unlikely tomake a compensating error)

Compiler generates correct code(sub-argument might use formal

proof, past experience, or compilercertification)

High quality V&V process

Unit test results

Softwarereliabilityexceeds systemrequirement

Reliability can beassessed undersimulated operationalconditions

Statistical test results

Table 4: Example safety arguments in safety case for functional correctness.

More examples are provided in Appendix D.2. The tables could also be used torecord the evidence that might refute or undermine the claim being made.

6.2 Risk Assessment and review

At the completion of the subsystem implementation, the safety case evidenceshould be reviewed to establish:

7/25/2019 ascad_v11a

46/166


42 Version: 1.1

the acceptability of the implemented subsystem (e.g. consistency with

requirements, and compliance with agreed standards criteria)

the acceptability of the subsystem safety case (e.g. completeness,consistency, credibility, non-compliances)

whether it is consistent with the systems safety case

If problems are identified, a resolution to the problem has to be agreed betweenthe stakeholders (such as re-implementation, more extensive testing, reworking ofthe subsystem safety case, or adjustments to the top-level safety case).

When a subsystem safety case is completed, the impact of the subsystem safetycase results on the overall safety case should be assessed, e.g.:

the impact of sub-system non-compliances on the overall safety case

whether independence and diversity assumptions have been satisfied

the strength of subsystem evidence and supporting documentation

The completed system safety case (including subsystem evidence and system-level evidence) should be reviewed to assess whether:

all identified hazards have been tracked and resolved

the safety case is complete (implementation and traceability of all

requirements)

the information is consistent and accessible (e.g. indexing and crossreferencing)

the supporting evidence is available in a suitable archive

It will also be necessary to check that an appropriate system supportinfrastructure is identified, including:

a supporting document set

system operations and maintenance requirements

technical resources (e.g. for document archiving, safety analyses, andtests)

safety case maintenance infrastructure

7/25/2019 ascad_v11a

47/166


Version: 1.1 43

Appendix F provides a checklist for safety case reviewing.

7 Operation and installation safety case elements

The operational, maintenance and installation aspects of the system will havebeen addressed in part by all the previous safety case elements.

The Preliminary safety case element will have defined requirements in thisarea and identified any operating constraints that might apply (seeSection 4)

The Architecture safety case element will have addressed the need todesign for usability, maintainability and modifiability (see Section 5)

The Implementation safety case element will have implemented thesefeatures and assessed whether there are any new operating constraintsor procedures required as well as adding the detail now available to themaintenance, use and support aspects (see Section 6)

This safety case element then adds to these by:

defining any safety related operational, installation and maintenance

procedures and requirements identified in the Preliminary safety case orArchitectural safety case

assessing whether the assumptions and operating constraints defined inthe Preliminary safety case are still valid and updating them as necessary

recording and resolving any non-compliances with the original safetyrequirements

putting in place acceptable measures for dealing with outstandingconcerns (e.g. periodic tests, gathering field evidence, further analyses,etc.)

for a COTS system, including the safety justification of the specificconfiguration

The types of information that will be new to this safety case are those aspects ofoperation, installation and maintenance that the developer may not becompetent to define. For example, specific grades of staff to undertake thedifferent types of maintenance, training requirements for operators, the exact userspecific permit to work system that should be used, the identified operating

7/25/2019 ascad_v11a

48/166


44 Version: 1.1

procedures needed to mitigate failure modes that require knowledge of the

wider system and environment to draft.

The development of the safety case may require particular trials or experiments tobe undertaken to confirm the adequacy of the operation and maintenanceaspects.

It will also be necessary to check that an appropriate system supportinfrastructure is identified, including:

a supporting document set

system operation and maintenance resources

technical resources (e.g. for document archiving, safety analyses, andtests)

appropriate user safety management systems

Over the lifetime of the system, there will almost inevitably be changes to thesafety case to accommodate changes in regulations, technology andorganisations so it will be necessary to establish a safety case maintenanceinfrastructure (see Section 10).

ascad_v11a

Documents