Whole Airspace Safety Case Meeting – Overview of Prior Work – 1

Whole Airspace Safety Case MeetingOverview of Prior Work

Tim KellyJohn McDermid

Department of Computer ScienceUniversity of York, UK

Whole Airspace Safety Case Meeting – Overview of Prior Work – 2

Research in YorkHigh Integrity Systems Engineering (HISE) Group

safety, systems and software engineeringstrong links with aerospace industry

BAE SYSTEMS, Rolls-Royceother links

DaimlerChrysler, Siemens

Work on safety cases over nearly a decadeprinciples of structuring safety cases and presenting arguments

goal structuring notation (GSN)GSN supported by commercial tools

SAM, Adelard ASCEongoing research, e.g. to modularise safety cases

Also teaching via MSc and for industrial clients

Whole Airspace Safety Case Meeting – Overview of Prior Work – 3

Safety Case as a ‘Logical Concept’

The Safety Case is the totality ofthe safety justification + all thesupporting material: testingreports, validation reports,relevant design information etc

The Safety Case Report is the document that summarises all the key components of the Safety Case and references all supporting documentation in a clear and concise format

We wish to steer away from the “Safety Case = Document” paradigm

Whole Airspace Safety Case Meeting – Overview of Prior Work – 4

Starting Point: Argument & EvidenceA safety case requires two elements: Supporting Evidence

Results of observing, analysing, testing, simulating and estimating the properties of a system that provide the fundamental information from which safety can be inferred High Level Argument

Explanation of how the available evidence can be reasonably interpreted as indicating acceptable safety – usually by demonstrating compliance with requirements, sufficient mitigation / avoidance of hazards etc

Argument without Evidence is unfounded Evidence without Argument is unexplained

Much of our prior work has focused upon establishing better means of developing, presenting, maintaining and reuse safety arguments

Whole Airspace Safety Case Meeting – Overview of Prior Work – 5

Safety Case Contents

Exact contents depends on regulatory environmentThe following are key elements of most standards:

scopesystem descriptionsystem hazardssafety requirements risk assessmenthazard control / risk reduction measuressafety analysis / testsafety management systemdevelopment process justificationconclusions

However …

Whole Airspace Safety Case Meeting – Overview of Prior Work – 6

Safety Case is NOT just a collection of disparate pieces of information

Safety Argument should form the ‘spine’ of the Safety Case showing how these elements are related and combined to provide assurance of safety

within the limits defined [Scope], the system [System Description] is SAFE because all identified hazards [System Hazards] and requirements [Safety Requirements] have been addressed. Hazards have been sufficiently controlled and mitigated [Hazard Control / Risk Reduction Measures] according to the safety risk posed [Risk Assessment]. Evidence [Safety Analysis / Test] is provided that demonstrates the effectiveness and sufficiency of these measures. Appropriate roles, responsibilities and methods were defined throughout the development of this system [Development Process Justification] [Safety Management System]and defined future operation

Safety Arguments

Whole Airspace Safety Case Meeting – Overview of Prior Work – 7

The Goal Structuring Notation 1

Purpose of a Goal Structure

To show how goals are broken down into sub-goals,

and eventually supported by evidence (solutions)

whilst making clear the strategies adopted,

the rationale for the approach (assumptions, justifications)

and the context in which goals are stated

A/J

Whole Airspace Safety Case Meeting – Overview of Prior Work – 8

C ontro l S ystemis S afe

A ll iden tifiedhazards e lim ina ted

/ su ffic ien tlym itiga ted

S oftwaredeve loped to I.L .

appropria te tohazards invo lved

I.L . P rocess G uide linesdefined by R ef X .

H azards Iden tifiedfrom FH A (R ef Y )

T o le rab ility ta rge ts(R ef Z )

Fau lt T reeA nalysis

Form alV erifica tion

P rocessE videnceof I.L . 4

P robab ility o f H 2occurring

< 1 x 10 -6 perannum

H 1 has beene lim inated

P robab ility o f H 3occurring

< 1 x 10 -3 perannum

P rim ary P ro tectionS ystem deve loped

to I.L . 4

S econdaryP ro tection S ystemdeve loped to I.L . 2

P rocessE vidence o f

I.L . 2

J

1x10 -6 p .a .lim it fo r

C atastroph icH azards

A Simple Goal Structure

Whole Airspace Safety Case Meeting – Overview of Prior Work – 9

GSN: Advantages and DisadvantagesAdvantages:

SimpleStructured Hierarchical BreakdownExpressive (captures the elements most important to safety

arguments) & CapableCan be used at various stages of argument developmentMethod guidance exists (e.g. concerning syntax)Semantics well defined and understood Increasingly being adopted by companies

Disadvantages:Learning curve (Easy to read, harder to write)Doesn’t stop you writing bad arguments!

Whole Airspace Safety Case Meeting – Overview of Prior Work – 10

Existing GSN ApplicationsMoD: Site Safety Justifications (Complex Multi-facility,

Multi-role safety case)BAE SYSTEMS: (Parts of) Eurofighter Safety

JustificationsRailtrack / Siemens: Dorset Coast Re-signalling ProjectBAE SYSTEMS: (Parts of) NimrodBAE SYSTEMS: South African HawkMoD: HarrierInformative parts of CAA SW01RR: Various Submarine Propulsion JustificationsRAF: UK ASACS – Military Air Traffic ManagementWestinghouse: Underground Jubilee Line ExtensionSwedish Air Traffic Control Systems…

Whole Airspace Safety Case Meeting – Overview of Prior Work – 11

Safety Case PatternsRather than successful ways of putting buildings or

software objects together ...Capture successful argument approaches that can be

used within the safety case‘Best practice’ arguments, capturing:

Company expertiseSuccessful certification approaches ‘Tools of the trade’

Dealing with the semantics rather than the syntax of the safety case

Combines the two elements of GSN & Patterning

Whole Airspace Safety Case Meeting – Overview of Prior Work – 12

G 1: {System X }is Safe

G 2: {Function Y }is sa fe

S 1: A rgum ent bycla im ing sa fe ty o f a ll

system safe ty-re la tedfunctions

C 1: S afe ty R ela tedFunctions o f {S ystem X }

(n = # functions)

n

G 3: In teractionsbetw een system

functions arenon-hazardous

G 4: A ll systemfunctions areindependent

(no in teractions)

P rovides {Function Y }

Instantiate andDevelop

Develop

Instantiate

Choose

GSN Pattern DescriptionGSN extended to support structural & entity abstraction

in order to represent generalised arguments.

Multiplicity

Whole Airspace Safety Case Meeting – Overview of Prior Work – 13

Safety Case Pattern ExamplesPatterns emerge at many different levels in a safety

argument:Top Down: e.g. Hazard Directed BreakdownBottom Up: e.g. Fault Tree EvidenceGeneral Construction: e.g. Safety Margin

There are opportunities for both:Horizontal Reuse (across domains)e.g. Software Integrity Argument, ALARPVertical Reuse (within a specific domain)e.g. against MoD Safety Assessment Principles

Examples of Domain Specific, Company Derived, GSN Pattern ‘Catalogues’ exist – e.g. Westinghouse Jubilee Line work, ongoing NATS work (Process Arguments)

Whole Airspace Safety Case Meeting – Overview of Prior Work – 14

Modular Safety CasesAn attempt to establish a modular, compositional,

approach to constructing safety cases that has a correspondence with the structure of the system underlying architecture

Many possible uses Integrated Modular Avionics (Application and Infrastructure)

Safety Cases ‘System of Systems’ Safety Case interrelationSystem Software Safety Case interrelation

Whole Airspace Safety Case Meeting – Overview of Prior Work – 15

Safety Case Module Partitioning(Assuming a top-down progression of objectives-argument-evidence) Safety cases can be partitioned into modules both horizontally and vertically:

Vertical (Hierarchical) Partitioning - Claims of one safety argument serving as objectives of another (e.g. simple system-software safety case split)

Horizontal Partitioning - One argument providing the assumed context of another (e.g. argument that “All system hazards have been identified” assumed context of an argument that “All identified system hazards have been sufficiently mitigated”)

Whole Airspace Safety Case Meeting – Overview of Prior Work – 16

Safety Case Module InterfacesSafety case module interface must identify:Arguments, evidence and context of the module itself +How safety case module depends upon the arguments,

evidence or assumed context of other modulesExample interface format:

1. Objectives addressed by the module2. Evidence presented within the module3. Context defined within the module4. Arguments requiring support from other modulesInter-module dependencies:5. Reliance on objectives addressed elsewhere6. Reliance on evidence presented elsewhere7. Reliance on context defined elsewhere

Whole Airspace Safety Case Meeting – Overview of Prior Work – 17

Handling ‘Modules’ in GSNfig 1

Argument over all identifiedsafety related functions of{System X}

ArgOverFunctions

IndependenceArg

All functions areindependent

FunctionsInd

FnASafeFunction A operationis acceptably safe

FnBArgument

Function B operationis acceptably safe

FnBSafe

Safety Argument forFunction A

FnAArgument

Function C operationis acceptably safe

FnCSafe

Safety Relatedfunctions of {System X}

SRFunctions

SysAccSafe

{System X} isacceptably safe

‘Away’ Goal

Safety Case

Module

Whole Airspace Safety Case Meeting – Overview of Prior Work – 18

GSN Based Safety Case Interface (1)

S afe ty C aseM odule Context

Defined

'Away'Goal

'Away'Context

Goals Supported

Goal to beSupported

EvidencePresented

'Away'Solution

'Away'Goal

ContextDefined

Whole Airspace Safety Case Meeting – Overview of Prior Work – 19

Safety Case ‘Contracts’Explicitly recorded basis of agreement between two

interrelated safety case modules

Whole Airspace Safety Case Meeting – Overview of Prior Work – 20

SummaryThe Goal Structuring Notation provides means of

explicitly developing and presenting safety argumentsMost benefit if applied early in lifecycle

Safety Case Patterns help capture common forms of argument that exist in safety casesCan be useful in attempting to standardise structure of

arguments constructed

Safety Case Modules provide means managing partitioned safety case arguments and the interrelationships that exist between partitionsUseful concept for planning safety cases ‘in-the-large’

Already considerable take up of GSNExpect patterns and modules to help with broader acceptanceProbably necessary to deal with a “whole airspace” safety case