1 / 29

Software Safety Case

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.

piper
Download Presentation

Software Safety Case

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related