1. Software Safety Case
Why, what and how…
Jon Arvid Børretzen

2. 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

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 innovation
Using 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
Consistency
Completeness
Identifying and managing the safety impacts of change
Setting safety targets
Confidence 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 evidence
Provide a set of safety arguments that link the claims to the evidence
Make 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!

9. Main elements of a safety case
Claim
Sub-claim
Evidence
Inference rule
Argument structure
Claims
Evidence
facts
assumptions
sub-claims,
Arguments
Inference rules
Claim
Sub-claim
Evidence

10. Types of claims Quality Attributes Reliability/availability Security
Maintainability
Time response
Functional correctness
Usability
Fail-safety
Accuracy
Overload robustness
Modifiability
Etc..
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?

12. Types of arguments Deterministic Probabilistic Qualitative
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 reliability in 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 cases
High level safety case
Subsidiary safety cases for subsystems
Traceability between whole system and subsystem levels
Design for assessment

15. Layered safety cases Starts at top level
System safety
requirement
Safety functions 2
Safety functions 1
System architecture
System part 1
System part 2
Detailed functions
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

16. Traceability between levels
Reliability
Maintainability
Coding Standards
Accessible source code
Testing
Inspection

17. The Safety Case life cycle
Preliminary
Architectural
Implementation
Operation 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 case
Long-term support infrastructure plans
Approval
Long-term monitoring and audits
System 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 description
Safety requirements
System architecture
Planned implementation approach

22. Safety case contents (2)
Subsystem design and safety arguments
Long-term support requirements
Maintenance and operation procedures
Status information
Evidence of quality and safety management

23. Tool support for safety cases
Decision support and elicitation tools.
Drawing out ideas
Tools to generate evidence
Safety analysis tools
Tools for collecting and analysing field experience
Test tools
Safety Management system infrastructure support

24. Notations - ASCAD ASCAD - Adelard Safety Case Development
claims-arguments-evidence motif
Claim
Sub-claim
Evidence
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

26. GSN example

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 useful
Aiding documentation
Trace hazards to solutions
Levels 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