The software safety case

It was discussed in section 2.2.1 how there was a move towards a more product focussed approach

to certifying safety critical systems, rather than appealing to process standards. This requires

that a safety argument be produced which identifies the contribution of the software to the

safety of the system. In [83] Weaver et. al. propose an approach for articulating software safety

Goal Structuring Notation (GSN) to represent the arguments.

GSN is a graphical notation which can be used to record and present safety arguments [29].

GSN provides a notation for representing the elements of the argument and the relationship

between those elements. The principal elements of the GSN notation are shown in figure 2.14.

As described by Kelly in [31], “The principal purpose of a goal structure is to show how goals

(claims about the system) are successively broken down into sub-goals until a point is reached

where claims can be supported by direct reference to available evidence (solutions). As part

of this decomposition, using the GSN it is also possible to make clear the argument strategies

adopted (e.g. adopting a quantitative or qualitative approach), the rationale for the approach

(assumptions, justifications) and the context in which goals are stated (e.g. the system scope

or the assumed operational role).” Figure 2.15 shows an example goal structure in GSN taken

from [83].

Figure 2.14: Main elements of the GSN notation

G1

All identified hazards eliminated or sufficiently mitigated

G2

Hazard H1 has been eliminated

S1 Argument over all identified hazards G3 Probability of H2 occuring < 1x10-3 G4 Probability of H3 occuring < 1x10-6 C2 Tolerability targets C1 Hazards identified from FHA J J1

1x10-6 p.a. limit for catastrophic hazards Sn1 Formal verification Sn2 Fault Tree Analysis

Figure 2.15: An example GSN goal structure

documenting reusable safety case elements. These reusable elements can then be instantiated

for a particular implementation of a system to create a safety argument. In figures 2.16, 2.17

and 2.18 some of the safety argument patterns created by Weaver in [84] for arguing the safety

of software are shown. These are generic patterns that can be used to create arguments about

any safety critical software. The first pattern (figure 2.16) shows the top level decomposition

for the safety argument of a system. This identifies the software as a contributor to system level

hazards. Figure 2.17 then shows the pattern for decomposing the software contribution into a

number of hazardous software failure modes (HSFM). The pattern in figure 2.18 then shows

an approach to demonstrating that the causes of the HSFMs are acceptable by classifying the

software failures into different types. These three patterns represent just one possible approach

to a software safety argument, however they are useful in that they show that it is possible to

construct a safety argument for software. It shall be seen later in the thesis that an alternative

safety argument structure proves to be more effective for OO software. This is discussed in

detail in chapter 5.

Structure

SystemSafe {System} is acceptably safe to operate from a hazard control perspective SysDefn System Definition DefnAccSafe Definition of acceptably safe ReqValid System Safety Requirements are valid

HazAccept All identified system level hazards occur at acceptably low rates SysHaz Identified System Level Hazards Traceability Traceability of safety requirements and safety evidence has been shown

ArgSWHWOther Argument across software, hardware and other parts of {System} that may cause hazards

J

DependExplicit System can be decomposed as all dependencies between different parts of the system are explicit

HWContribAccept Hardware contributions to System Level Hazards are acceptable

SWContribAccept Software contributions to System Level Hazards are acceptable

OtherContribAccept Other contributions to System Level Hazards are acceptable

SWContrib Identified Software Contributions to System Level Hazards = Software Hazardous Failure Modes SWDefn Software Definition HWDefn Hardware Definition HWContrib Identified Hardware Contributions to System Level Hazards OtherDefn Other Components Definition OtherContrib Identified Contributions of Other Components to System Level Hazards

SystemSafe The overall objective of the argument – to provide sufficient support for the claim that the System is acceptably safe to operate.

SysDefn This model should give a clear definition of the system. From the model it should be possible to identify the system level hazards.

Participants

DefnAccSafe To be able to argue that the claim is upheld, it is necessary to give a definition for the term ‘acceptably safe’. This may come from a standard or regulatory body. The definition will be the initial basis from which hazard assessment is made and an argument is generated with respect to the acceptability of the hazards.

Figure 2.16: GSN Argument Pattern for Component Contributions to System Hazards

CHAPTER 2. SURVEY OF RELATED LITERATURE

208

Decomposition

Author(s) Rob Weaver, John McDermid, Tim Kelly

Created 18/09/00 Last Modified 15/04/04

Intent The intent of this pattern is to provide a decomposition for the

acceptability of software with respect to system level hazards. The pattern identifies the primary claims for developing a software safety argument from a hazard control perspective.

Also Known As

Motivation The motivation of this pattern was to identify the three primary

claims which must be satisfied to show the acceptability of software; All software contributions have been identified, Acceptability of Hazardous Software Failure Modes, and Traceability of Safety Requirements and Safety Evidence.

Structure

SWContribAccept Software contributions to System Level Hazards are acceptable

ArgOverSWContrib Argument over all identified software contributions to system level hazards SWContribIdent

All software contributions to system level hazards have been identified

SWContrib Identified Software Contributions to System Level Hazards = Hazardous Software Failure Modes

SWSRTraceability Traceability of software safety requirements and safety evidence has been shown

HSFMAccept All causes of Hazardous Software Failure Mode {HSFM} are acceptable

n

n = # software hazardous failure modes from SWContrib

SWDefn Software Definition

Figure 2.17: GSN Argument Pattern for Hazardous Software Failure Mode Decomposition

212

Hazardous Software Failure Mode Classification

Author(s) Rob Weaver, John McDermid, Tim Kelly

Created 18/09/00 Last Modified 15/04/04

Intent The intent of this pattern is to provide a type classification for the

hazardous failure mode that is the subject of the argument. The failure mode can be classified as one of Omission, Commission, Early, Late or Value.

Also Known As

Motivation By defining the hazard as a particular type, it is possible to focus the

argument on the particular causes and associated evidence for that hazard type.

Structure

HSFMOmissionAccept All causes of Hazardous Software Failure Mode {HSFM} of type Omission are acceptable

HSFMEarlyAccept All causes of Hazardous Software Failure Mode {HSFM} of type Early are acceptable

HSFMValueAccept All causes of Hazardous Software Failure Mode {HSFM} of type Value are acceptable DefOmFM Definition of Omission Failure Mode DefEarlyFM Definition of Early Failure Mode DefValueFM Definition of Value Failure Mode HSFMAccept All causes of Hazardous Software Failure Mode {HSFM} are acceptable

1-of-5

HSFMCommissionAccept All causes of Hazardous Software Failure Mode {HSFM} of type Commission are acceptable DefComFM Definition of Commission Failure Mode HSFMLateAccept All causes of Hazardous Software Failure Mode {HSFM} of type Late are acceptable DefLateFM Definition of Late Failure Mode HSFM Hazardous Software Failure Mode SysHaz System Level Hazard SWDefn Software Definition

Participants HSFMAccept The overall objective of the argument – to

provide sufficient support to the claim that the Hazardous Software Failure Mode under consideration is acceptably safe.