1

Software Safety Case

Why, what and how…

Jon Arvid Børretzen

2

Why safety case?

A tool for managing safetyA reasoned argument that a system is or

will be safeA means to obtain regulatory approval to

operate A unique collection of data, information,

logical arguments

3

Goal-based vs. Prescriptive regulations

Problems with prescriptive regulations: Safety responsibility, regulator or service

provider? Prescriptive regulations tend to be based on

past experiences. Software development is often innovative.

Best practice vs. evolving technologies

Goal-based regulations are more flexible, yet aim to ensure the safety in a system.

4

Motivation for safety case

Provide an assurance viewpoint Provide a focus and rationale for safety activities Provide a reviewable approach Demonstrate a clear link between risk/hazards and implemented

solutions Allow interworking between standards and innovationUsing safety case, the emphasis should be on the behaviour of the

product, not the development process.

“What has been achieved, not how hard you have tried”

5

Value of Safety Cases to safety management

ConsistencyCompletenessIdentifying and managing the safety

impacts of changeSetting safety targetsConfidence in meeting safety targets

6

What is (a) safety case?

“A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment”

[Adelard]

7

Implementing a safety case

Make an explicit set of claims about the system

Produce the supporting evidenceProvide a set of safety arguments that

link the claims to the evidenceMake clear the assumptions and

judgements underlying the arguments

8

Safety case structure and content

Logical stepping stones

Based on: Safety requirements Safety argument Safety evidence

Safety case is structure as well as content!

Safety Requirements& Objectives

Safety Evidence

Safety Argument

9

Main elements of a safety case

Claims Evidence

facts assumptions sub-claims,

Arguments Inference rules

Claim

Sub-claim

Evidence

EvidenceInference rule

Inference rule

Argument structure

Claim

Sub-claim

Evidence

Evidence

10

Types of claims

Reliability/availability Security Maintainability Time response Functional

correctness

Usability Fail-safety Accuracy Overload robustness Modifiability Etc..

Claim

Quality Attributes

11

Sources of evidence

The design The development

process Simulated

experience (for example from reliability testing)

Prior field experience

Evidence requirements What evidence is

needed? How can it be

provided? What will be

adequate? Argument from

simulation?

Evidence

12

Types of arguments

DeterministicProbabilisticQualitative

Choices depend on available evidence and type of claim

Inference rule

Inference rule

Argument structure

13

Example of arguments

Attribute Design Features

Assumption/

Evidence

Subsystem Requirements

Claim

Reliability/

availability

Architecture,levels of redundancy,segregation

Fault tolerant architectures

Design simplicity

Reliability of components,CMF assumptions Failure rate,diagnostic coverage,test intervals,repair time,chance of successful repair

Prior field reliabilityin similar applications

Hardware component reliability

Software integrity level

Component segregation requirements

Fault detection and diagnostic requirements

Maintenance requirements

Reliability claim based on reliability modelling and CMF assumptions, together with fault detection and repair assumptions

Reliability claim based on experience with similar systems

14

How is safety case used?

Throughout the whole of the software life cycle

Layering of safety casesHigh level safety caseSubsidiary safety cases for subsystems

Traceability between whole system and subsystem levels

Design for assessment

15

Layered safety cases

Starts at top level Overall safety target

Derived requirements for subsystems

At high level of abstraction: Reliability,security etc.

At more detailed level: Design requirements

implemented in subsystem

System safetyrequirement

Safety functions 2

Safety functions 1

System architecture

System part 1 System part 2

Detailed functions

Detailed functions

16

Traceability between levels

Reliability

MaintainabilityCoding Standards

Accessible source code

Testing

Inspection

17

The Safety Case life cycle

PreliminaryArchitecturalImplementationOperation and Installation

18

Main stages of safety case evolution (1)

Safety functions and top-level safety attributes identification

System architecture and outline safety case identification

Preliminary assessment of design options

Progressive elaboration of the design and safety case in parallel

19

Main stages of safety case evolution (2)

Integration into final safety caseLong-term support infrastructure plansApprovalLong-term monitoring and auditsSystem updates and corrections

20

Things to have in mind…

Produce a safety case before you find that you needed it!

Changes have safety implications

21

Safety case contents (1)

Environment descriptionSafety requirementsSystem architecturePlanned implementation approach

22

Safety case contents (2)

Subsystem design and safety argumentsLong-term support requirementsMaintenance and operation proceduresStatus informationEvidence of quality and safety

management

23

Tool support for safety cases

Decision support and elicitation tools.Drawing out ideas

Tools to generate evidenceSafety analysis toolsTools for collecting and analysing field

experienceTest tools

Safety Management system infrastructure support

24

Notations - ASCAD

ASCAD - Adelard Safety Case Developmentclaims-arguments-evidence motif

Claim

Sub-claim

Evidence

EvidenceInference rule

Inference rule

Argument structure

25

Notations - GSN

GSN - Goal Structuring Notation goals-strategies-solution form of construction

Linked by logical connections to form an argument structure

Goal or Sub-goal

Strategy

Context

Evidence

26

GSN example

The Airspace is safe

Base argument ongeographical areas

Each Area is safeAssumptions for Area

safety cannot beviolated

Area safety based onbasic ATM rules

Whole-airspace andout-of-area events

cannot violate safetyassumptions

Basic ATM rulesimplemented safely in

each areaBasic ATM rules are

safe

Whole-airspace eventsknown, do not violatesafety assumptions

Out-of-area eventsknown, do not violatesafety assumptions

Definition of ‘safe’

Evidence thatbasic ATM rules

are safe

Evidence thatbasic ATM rules

implementedsafely in each

area

Evidence thatwhole-airspace

events known, donot violate safety

assumptions

Evidence thatout-of-area

events known, donot violate safety

assumptions

27

Coupling with other safety-critical methods

PHA and Hazop to identify risks and safety concerns that the safety case will handle

FMEA and FTA for evidence generation

28

The business-critical setting

Safety case very comprehensive

The main concept and structure usefulAiding documentationTrace hazards to solutionsLevels of abstraction

Methods, tools and experience exist

29

Concluding remarks

Emphasis on claims about system behaviour and suitable arguments

Simple structuring ideas, but allows quite complex safety cases which are understandable and traceable

Layered structure of the safety case allows the safety case to evolve over time