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

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.

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”

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

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]

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

Safety case structure and content Logical stepping stones Based on: Safety requirements Safety argument Safety evidence Safety case is structure as well as content!

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

Types of claims Quality Attributes Reliability/availability Security Maintainability Time response Functional correctness Usability Fail-safety Accuracy Overload robustness Modifiability Etc.. Quality Attributes

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?

Types of arguments Deterministic Probabilistic Qualitative Choices depend on available evidence and type of claim Inference rule Inference rule Argument structure

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

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

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

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

The Safety Case life cycle Preliminary Architectural Implementation Operation and Installation

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

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

Things to have in mind… Produce a safety case before you find that you needed it! Changes have safety implications

Safety case contents (1) Environment description Safety requirements System architecture Planned implementation approach

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

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

Notations - ASCAD ASCAD - Adelard Safety Case Development claims-arguments-evidence motif Claim Sub-claim Evidence Inference rule Argument structure

Notations - GSN GSN - Goal Structuring Notation goals-strategies-solution form of construction Linked by logical connections to form an argument structure

GSN example

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

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

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