Software Safety Case

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. Inference rule Evidence Evidence Claim Claim Evidence Evidence Sub-claim Sub-claim Inference rule Argument structure Main elements of a safety case • Claims • Evidence • facts • assumptions • sub-claims, • Arguments • Inference rules

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

11. 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? Sources of evidence Evidence

12. Types ofarguments • Deterministic • Probabilistic • Qualitative Choices depend on available evidence and type of claim Inference rule Inference rule Argument structure

13. Example of arguments

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

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

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. Inference rule Evidence Claim Evidence Sub-claim Inference rule Argument structure Notations - ASCAD • ASCAD - Adelard Safety Case Development • claims-arguments-evidence motif

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