swa omg tutorial slides - kelly

Tpk

Description

zzzzzzzzzzSoftware Safety CaseManagementDr Tim KellyDepartment of Computer ScienceUniversity of YorkE-mail: [e-mail]© Copyright Tim Kelly, 2007 Not to be reproduced without permission of authorTutorial OverviewPart One: 1300-1515Introduction to Safety CasesThe Importance of Safety ArgumentsThe Goal Structuring Notation (GSN)Part Two: 1530-1745Software Safety CasesProblems with Current ApproachesThe Structure of a Typical Software Safety ArgumentEstablishing Hazard-Directed Software Safety ArgumentsLinking Process and Product ArgumentsSoftware Safety Case Management Tutorial – Tim Kelly 2© Copyright Tim Kelly, 2007 Not to be reproduced without permission of authorPage 1zzzzzzzzzPart 1: OverviewSafety Case concept and purposeRequirements from standardsSafety Case contentsSafety argumentspresenting clear argumentsGoal Structuring Notation (GSN)Creating Arguments in GSNWhere, When and How to Create Assurance ArgumentsSoftware Safety Case Management Tutorial – Tim Kelly 3© Copyright Tim Kelly, 2007 Not to be reproduced without permission of authorMotivationMany (UK) standards establish the need for production of a safety case, e.g.“Safety Cases are required for all new ships and equipment as ameans of formally documenting the adequate control of Risk and demonstrating that levels of risk achieved are As Low AsReasonably Practicable (ALARP).” (JSP430)A person in control of any railway infrastructure ...

Informations

• Publié par: Phawyar
• Nombre de lectures: 31
• Langue: English

Extrait

Software Safety Case Management

Dr Tim Kelly Department of Computer Science University of York E-mail: [e-mail]

© Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Tutorial Overview

zPart One: 1300-1515 zIntroduction to Safety Cases zThe Importance of Safety Arguments zThe Goal Structuring Notation (GSN) zPart Two: 1530-1745 zSoftware Safety Cases zProblems with Current Approaches zThe Structure of a Typical Software Safety Argument zEstablishing Hazard-Directed Software Safety Arguments zLinking Process and Product Arguments

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 1

2

Part 1: Overview

zSafety Case concept and purpose zRequirements from standards zSafety Case contents zSafety arguments zpresenting clear arguments zGoal Structuring Notation (GSN) zCreating Arguments in GSN zWhen and How to Create Assurance ArgumentsWhere,

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

3

Motivation zMany (UK) standards establish the need for production of a safety case, e.g. “Safety Cases are required for all new ships and equipment as a means of formally documenting the adequate control of Risk and demonstrating that levels of risk achieved are As Low As Reasonably Practicable (ALARP).” (JSP430) A person in control of any railway infrastructure shall not use or permit it to be used for the operation of trains unless (a) he has prepared a safety case … (b) the Executive has accepted that safety case …” (HSE Railway Safety Case Regulations) “The Software Design Authority shall provide a Software Safety Case …” (U.K. Defence Standard 00-55) Software Safety Case Management Tutorial  Tim Kelly  4 © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 2

The Purpose of a Safety Case

Principal Objective: zSafety case presents the argument that a system will be acceptably safe in a given context z be ...System could  zphysical (e.g. aero-engines, reactor protection systems) zprocedural (e.g. railway operations, off-shore) zSafety Cases can be prepared for .. zcommissioning zmaintenance zdecommissioning ...

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

5

Some Definitions

z"A safety case is a comprehensive and structured set of safety documentation which is aimed to ensure that the safety of a specific vessel or equipment can be demonstrated by reference to: zsafety arrangements and organisation zsafety analyses zcompliance with the standards and best practice zacceptance tests zaudits zinspections zfeedback zprovision made for safe use including emergency arrangements” (JSP 430) zshall present a well-organised and reasoned"The software safety case justification based on objective evidence, that the software does or will satisfy the safety aspects of the Statement of Technical Requirements and the Software Requirements specification." (DS 00-5 5) Software Safety Case Management Tutorial  Tim Kelly  6 © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 3

Argument & Evidence

A safety case requires two elements: zSupporting Evidence Results of observing, analysing, testing, simulating and   estimating the properties of a system that provide the   ademfnu tnlafrom which safety can be inferredinformation zHigh 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 zArgument without Evidence is unfounded zEvidence without Argument is unexplained

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

7

Argument & Evidence 2 Safety Requirements & Objectives

Safety Argument

Safety Evidence

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 4

8

Safety Cases vs. Safety Case Reports

zSafety Caseis the totality of the safety justification + all the supporting material: testing reports, validation reports, relevant design information etc

zSafety Case Reportis the document that summarises all the key components of the Safety Case andreferences all supporting documentation in a clear and concise format

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

9

Safety Case Reports

zExact contents depends on regulatory environment zfollowing are key elements of most standards:The zScope zSystem Description zSystem Hazards zSafety Requirements zRisk Assessment zHazard Control / Risk Reduction Measures zSafety Analysis / Test zSafety Management System zDevelopment Process Justification zCosnoisulcn

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 5

10

Safety Arguments

zThe Safety Case is not just a collection of disparate pieces of information z the Safety Case ofThe Safety Argument should form the spine  showing how these elements are related and combined to provide assurance of safety zwithin 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 Software Safety Case Management Tutorial  Tim Kelly  11 © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Safety Arguments  Text Example

The Defence in Depth principle (P65) has been addressed in this system through the provision of the following: •Multiple physical barriers between hazard source and the environment (see Section X) •A protection system to prevent breach of these barriers and to mitigate the effects of a barrier being breached (see Section Y) ...

zSafety Arguments should clearly describe how a safety objective / requirement / claim has been achieved in the system as proposed zhow it has been interpreted zultimately, what evidence supports the requirements Software Safety Case Management Tutorial  Tim Kelly  12 © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 6

Safety Arguments  Text Problems

For hazards associated with warnings,the assumptions of [7] Section 3.4 associated with the requirement to present a warning when no equipment failure has occurred are carried forward. In particular, with respect to hazard 17 in section 5.7 [4] that for test operation, operating limits will need to be introduced to protect against the hazard, whilst further data is gathered to determine the extent of the problem. znot everyone can write clear English zcan take many readings to decipher meaning zmultiple cross-references in text can be awkward zis there a clear shared understanding of the argument? Software Safety Case Management Tutorial  Tim Kelly  13 © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Presenting Clear Arguments

zIt is possible in text  at least sometimes zuse simple language and short sentences zuse bullet points for key statements zbreak down the argument one step at a time zand refer to following sub-sections zstructure document sub-sections around separate concepts z6.2  Control of Hazard  Inadvertent Chaff Releasee.g. Section  zBut it is easier with pictures! zuse agraphical notationto summarise argument zGoal Structuring Notation(GSN) zClaims Argument Evidence (CAE)

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 7

14

The Goal Structuring Notation

Purpose of a Goal Structure To show howgoalsare broken down into sub-goals, and eventually supported by evidence (solutions) whilst making clear thestrategiesadopted, the rationale for the approach (assumptions, justifications) A/J and thecontextin which goals are stated

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

15

A Simple Goal Structure

Control System is Safe

Hazards Identified from FHA (Ref Y) All identified  Software hazards eliminated  developed to I.L. I.L. Process Guidelines / sufficiently  appropriate to defined by Ref X. Tolerability targets  mitigated  hazards involved (Ref Z)

1x10 -6  Secondary  of H3 Probability  Protection Primary  of H2p.a. Probability Ca l H t i a a m s it t   r f o r o d p r s hic H e 1 li  h m a i s n   a b t e e e d n <  o 1  c x c  1 ur 0 r - i 6 ccruog   n < 1 r er p01 x - i 3 emstyS  r n e oitcetorP p  4 d to I. g L n . edevolepSsyet m za annum annum  developed to I.L. 2

Formal Fault Tree  Process Process vidence Evidence of VerificationAnalysis E of I.L. 4I.L. 2 Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 8

16

A Simple Goal Structure Safety Requirements & Objectives

Hazards Identified from FHA (Ref Y) All identified  Software hazards eliminated  developed to I.L. I.L. Process Guidelines / sufficiently  appropriate to defined by Ref X. Tolerability targets  hazards involved (Ref Z) Safety Argument 1x10 -6  y op.a. Probabi o y a ro occurring Ca H l t i a a m s z i t t r a  f o rd o p r s hic H e 1 li  h m a in s  a b te e d en < 1  a x  n 1 n 0 u -6  1 x01 rur  < p occ nu e an r m - i 3 loved pe Ito. .L tcet noitsyS ed me gn 2 etsyS noitcetorP rymari m P er p P y or dnraeSoc .L4 o I. ped t velom de

Safety Evidence Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

17

Group Exercise zCreate a goal structure to support the claim:

Top This is a good pint of beer

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 9

18

Step 1 Identify goals to be supported

Step 2 Define basis on which goals stated

Step 5 - Elaborate strategy Step 3 Step 6 Identify Identify strateg o y r  t to Basic sup o p als Solution g STOP

Step 4 Define basis Process on which strategy Overview tated

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

19

Step 1 - Identify Goals: Phrasing zGoals should be phrased as propositions zStatements that can be said to be TRUE / FALSE (e.g. The sky is blue or York is a beautiful city) zNB: not limited to statements that can be objectively proven zStatement should be expressed as a single statement (1 sentence) of in the form: <NOUN-PHRASE><VERB-PHRASE> zNoun-Phrase identifies the subject of the goal zVerb-Phrase defines a predicate over the sub ect 1 3 6 2 4 20

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 10

Step 1 Identify Goals: Phrasing - zThe following are examples of correctly stated goals: Subject Predicate <Noun-Phrase> <Verb-Phrase> Component X has no ‘critical’ failure modes All identified hazards for System Y have been sufficiently mitigated Non-destructive examination of has been performed weld-site Z Design A employs triple modular redundancy 5 1 3 6 2 4 21

Software Safety Case Management Tutorial  Tim Kelly © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Step 1 - Identify Goals: Phrasing zThe following are examples ofincorrectlystated goals: Reason:   y “Hazard Log for System Y”  - entitNP – describes an • not a statement •“Fault Tree for Hazard H1” As above • “Perform Fault Tree Analysis of VP - an action - not a   Hazard H1” statement • “How many failure modes does Question - not a component X have?” statement zTest: can we say goal isTRUE/FALSE? 1 3 6 2 4 Software Safety Case Management Tutorial  Tim Kelly  22 © Copyright Tim Kelly, 2007 Not to be reproduced without permission of author

Page 11