software safety case
DESCRIPTION
Software Safety Case. Why, what and how…. Jon Arvid Børretzen. Why safety case?. A tool for managing safety A reasoned argument that a system is or will be safe A means to obtain regulatory approval to operate A unique collection of data, information, logical arguments. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/1.jpg)
1
Software Safety Case
Why, what and how…
Jon Arvid Børretzen
![Page 2: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/2.jpg)
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
![Page 3: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/3.jpg)
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.
![Page 4: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/4.jpg)
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”
![Page 5: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/5.jpg)
5
Value of Safety Cases to safety management
ConsistencyCompletenessIdentifying and managing the safety
impacts of changeSetting safety targetsConfidence in meeting safety targets
![Page 6: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/6.jpg)
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]
![Page 7: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/7.jpg)
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
![Page 8: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/8.jpg)
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
![Page 9: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/9.jpg)
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
![Page 10: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/10.jpg)
10
Types of claims
Reliability/availability Security Maintainability Time response Functional
correctness
Usability Fail-safety Accuracy Overload robustness Modifiability Etc..
Claim
Quality Attributes
![Page 11: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/11.jpg)
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
![Page 12: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/12.jpg)
12
Types of arguments
DeterministicProbabilisticQualitative
Choices depend on available evidence and type of claim
Inference rule
Inference rule
Argument structure
![Page 13: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/13.jpg)
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
![Page 14: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/14.jpg)
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
![Page 15: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/15.jpg)
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
![Page 16: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/16.jpg)
16
Traceability between levels
Reliability
MaintainabilityCoding Standards
Accessible source code
Testing
Inspection
![Page 17: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/17.jpg)
17
The Safety Case life cycle
PreliminaryArchitecturalImplementationOperation and Installation
![Page 18: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/18.jpg)
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
![Page 19: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/19.jpg)
19
Main stages of safety case evolution (2)
Integration into final safety caseLong-term support infrastructure plansApprovalLong-term monitoring and auditsSystem updates and corrections
![Page 20: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/20.jpg)
20
Things to have in mind…
Produce a safety case before you find that you needed it!
Changes have safety implications
![Page 21: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/21.jpg)
21
Safety case contents (1)
Environment descriptionSafety requirementsSystem architecturePlanned implementation approach
![Page 22: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/22.jpg)
22
Safety case contents (2)
Subsystem design and safety argumentsLong-term support requirementsMaintenance and operation proceduresStatus informationEvidence of quality and safety
management
![Page 23: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/23.jpg)
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
![Page 24: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/24.jpg)
24
Notations - ASCAD
ASCAD - Adelard Safety Case Developmentclaims-arguments-evidence motif
Claim
Sub-claim
Evidence
EvidenceInference rule
Inference rule
Argument structure
![Page 25: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/25.jpg)
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
![Page 26: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/26.jpg)
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
![Page 27: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/27.jpg)
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
![Page 28: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/28.jpg)
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
![Page 29: Software Safety Case](https://reader036.vdocument.in/reader036/viewer/2022062422/56813e42550346895da8293c/html5/thumbnails/29.jpg)
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