Upload
hector-eaton
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
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
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