Safety Case Structure

As noted earlier we define a safety case as:

"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"

To implement a safety case we need to:

1. make an explicit set of claims about the system


2. produce the supporting evidence


3. provide a set of safety arguments that link the claims to the evidence


4. make clear the assumptions and judgements underlying the arguments


5. allow different viewpoints and levels of detail

The following sections describe how we think a safety case should be structured to meet these goals.

        ▪ Elements of a Safety Case
        ▪ Type of Claims
        ▪ Type of Arguments
        ▪ Sources of Evidences
        ▪ Example Arguments

Elements of a Safety Case
The main elements of the safety case are:

  □ Claim: about a property of the system or some subsystem.

  □ Evidence: which is used as the basis of the safety argument. This can be either facts, (e.g. based on established scientific principles and prior research), assumptions, or sub-claims, derived from a lower-level sub- argument.

  □ Argument: linking the evidence to the claim, which can be deterministic, probabilistic or qualitative.
 
  □ Inference: the mechanism that provides the transformational rules for the argument


The use of these elements is illustrated in the figure below:



Note that "evidence" can be a sub-claim produced by a subsidiary safety-case. This means that there can be a relatively simple top-level argument, supported by a hierarchy of subsidiary safety cases. This structuring makes it easier to understand the main arguments and to partition the safety case activities.

It is also possible to have two (or more) independent arguments supporting the same claim, as illustrated below.



By using independent evidence (and possibly different styles of safety argument), the claim can be more robust, i.e. it can tolerate flaws in a single argument. Another section provides background and details of how tools and notations can help with this claim-argument-evidence structured.  

Types of Claims
The safety case is broken down into claims about different attributes for the various sub-systems, e.g.:

• reliability and availability
• security (from external attack)
• functional correctness
• time response
• maintainability
• usability (by the operator)
• fail-safety
• accuracy
• robustness to overload
• modifiability
• [...]

Note that the attributes listed are only examples and further attributes may be safety-relevant. Conversely, for some applications not all attributes need be safety-related, e.g. time response would not be safety-relevant for off-line stress analysis programs, but it would be necessary to have accuracy and functional correctness.

Types of Arguments
Different types of arguments can be used to support claims for the attributes:

 □ Deterministic: application of predetermined rules to derive a true/false claim (given some initial assumptions), e.g. formal proof of compliance to a specification, or demonstration of a safety requirement (such as execution time analysis or exhaustive test of the logic)

  □ Probabilistic: quantitative statistical reasoning, to establish a numerical level (e.g. MTTF, MTTR, reliability testing) or sub-claims, derived from a lower-level sub- argument.

  □ Qualitative: compliance with rules that have an indirect link to the desired attributes (e.g. compliance with QMS standards, staff skills and experience)

The choice of argument will depend on the available evidence and the type of claim. For example claims for reliability would normally be supported by statistical arguments, while other claims (e.g. for maintainability) might rely on more qualitative arguments such as adherence to codes of practice.

Sources of Evidences
The arguments themselves can utilise evidence from the following main sources:

• the design
• the development processes
• simulated experience (via reliability testing)
• prior field experience

The choice of argument will depend in part on the availability of such evidence, e.g. claims for reliability might be based on field experience for an established design, and on development processes and reliability testing for a new design.

Example Arguments
Some example arguments for different claims, using different types of evidence, are shown in the following table.

Functional Correctness	Partitioning according to criticality Design simplicity	Assumption that segregated functions cannot affect each other	Subsystem integrity level Functional segregation requirements	Claim that the composite behaviour of the critical functions implements the overall safety function
Fail-safety	Use of functional diversity Fail-safe architectures	System Hazard Analysis Fault Tree Analysis	Fail safety requirements for subsystems (response to failure conditions)	Claim that safety is maintained under stated failure conditions, assuming the subsystems are correctly implemented
Reliability/Availability	Architecture,levels of redundancy,segregation Fault tolerant architecture Design simplicity	System Hazard Analysis Fault Tree Analysis	Fail safety requirements for subsystems (response to failure conditions)	Claim that safety is maintained under stated failure conditions, assuming the subsystems are correctly implemented
Fail-safety	Use of functional diversity Fail-safe architectures	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