Safety Case

Definition

Safety Case

the safety work product that provides clear, comprehensive, defensible, and written justification for believing that a potentially-dangerous system will be (or is) acceptably safe when operated in its intended environment over the its lifetime from inception to eventual retirement

Classification

As illustrated in the preceding figure, Safety Case is part of the following inheritance hierarchy:

• Type: Concrete
• Superclass: Document
• Subclasses:
  • None

Responsibilities

The typical responsibilities of a Safety Case are to document:

• Complete and consistent claims that a system will be (or is) adequately safe:
  • That safety requirements are sufficient and met.
  • That the safety integrity levels (SILs) for hazards are sufficiently low.
  • That any residual safety risks are sufficiently low.
• For each safety claim, compelling arguments that it will be (or is being) met.
• For each argument, sufficient supporting evidence and acceptable assumptions exist to justify accepting the argument.
• A safety case demonstrates that:
  • All hazards have been properly identified, analyzed, and where necessary mitigated.
  • Any residual safety risks are acceptable.
  • The system meets its safety requirements (i.e., the claims).
  • The process used to develop the safety requirements, produce the system, and assess the system were carried out with adequate integrity.
• A safety case requires an organisation to think of all aspects of safety.
• A safety case frequently exposes previously unidentified safety issues.
• A safety case demonstrates that an organisation has taken ownership of its responsibility for ensuring safety.
• A safety case enables safety assessors and evaluators to determine if there is sufficient evidence that a system is adequately safe.
• Preparation and delivery of a safety case is typically required to meet the developer’s contractual or regulatory requirements.
• A safety case provides some legal protection from prosecution in case of an accident.

Contents

The typical contents of a safety case are:

• System Overview:
  • System Description
  • Configuration Baseline
• Safety Risks:
  • Overview of Potential Accidents
  • Overview of Hazards
  • Overview of Residual Safety Risks
• Safety Claims:
  • Summary of Safety Requirements
  • Safety Claim X:
    • Statement of Safety Claim X
    • Relevant Hazards
    • Residual Safety Risks
    • Relevant Safety Requirements
    • Safety Arguments:
      • Summary of the Safety Arguments
      • Safety Argument Y:
      • Statement of Safety Argument Y
        • Supporting Evidence:
          • Development Process including Safety Evidence Assurance Levels (SEALs)
          • Requirements Evidence (e.g., formal specification language, evaluations)
          • Architecture Evidence (e.g., architectural safeguards and mechanisms, evaluations)
          • Design Evidence (e.g., design safeguards, design standards, evaluations)
          • Implementation Evidence (e.g., implementation safeguards, coding standards, safe language subsets, evaluations)
          • Integration Evidence
          • Testing Evidence
          • Deployment Evidence
          • Operations Evidence
          • Maintenance Evidence
          • Retirement Evidence
        • Supporting Assumptions
• Appendices:
  • Applicable Regulations, Laws, Certifications and Standards
  • Major Issues
  • TBDs
  • Assumptions

Stakeholders

The typical stakeholders of a safety case are:

• Producer:
  • Safety Team
• Evaluators:
  • Safety Evaluation Team
  • Safety Evaluator
• Approvers:
  • Project Management Team
  • Customer Representative
• Maintainers:
  • Safety Team
• Users:
  • Customer
  • Legal Department
  • Safety Assessor, who monitors performance of the safety engineering process and acts as an arbitrater in cases of disputes between the customer and development organizations.
  • Safety Evaluator, who provides a thorough, independent, and objective review of the validity of the safety case.
  • Safety Certifier, who:
    • Assesses the safety and suitability for service of the system
    • Certifies the system as safe for service

Phases

• Business Strategy: Completed
• Business Optimization: Completed
• Initiation: Started
• Construction: Updated
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

A safety case typically can be started if the following preconditions hold:

• The initiation phase is started.
• The safety team is staffed and trained in safety compliance assessment.

Inputs

A safety case typically has the following inputs:

• Work Products:
  • Safety work products:
    • Hazard List
    • Incident Investigation Reports
    • Safety Compliance Repository
    • Safety Program Plan
    • Safety Risk Analysis Report
    • Safety Status Report
  • Requirements work products and associated conventions
  • Architecture work products and associated conventions
  • Design work products and associated conventions
  • Implementation work products and associated conventions
  • Test work products and associated conventions
  • Deployment work products and associated conventions
• Stakeholders:
  • Customer Representatives
  • Safety Domain Experts

Guidelines

• The safety case may consist of one or more documents and associated data.
• The safety case should be clear, consistent, complete, comprehensible (to all stakeholders), and defensible.
• To provide a clear and understandable structure, safety cases should be organized:
  1. Safety claim
  2. Safety argument
  3. Safety evidence and assumptions
• Tool support for the development and maintenance of safety cases is very helpful because they tend to be very large and complex with numerous complex internal interdependencies due to the:
  • Complex nature of safety-critical systems
  • The large number and variety of safety analyses performed
  • The large amount of safety-related data used as evidence
• Safety evidence may be included in the safety case by reference to data in the Safety Compliance Repository
• Diagrams may be useful for getting an overview of the safety case. Examples include using Goal Structuring Notation (GSN), which was developed for depicting safety arguments.
• The safety case should cover all relevant stages of the system’s lifecycle including development, manufacturing, deployment, operation, and retirement.
• Safety cases should be incrementally developed and delivered at different times during development:
  • A preliminary safety case at the end of preliminary hazard analysis
  • An interim safety case at the end of the inception phase
  • An operational safety case at just prior to system acceptance
• A safety case should be a living document that is updated, reviewed, and delivered:
  • On a regular basis (e.g., before each major milestone)
  • When new hazards are identified and analyzed
  • When safety incidents (i.e., accident or near miss) occur
• A safety case should include all aspects of systems and operations including such “soft” but important issues as management, human safety performance, procedures and organisation, and safety culture.

Conventions

The safety case is typically constrained by the following conventions:

• Content and Format Standard
• MS Word Template
• XML DTD
• Evaluation Checklist

Examples

• Example Safety Case