Safety Cases – Benefits and Good Practise

Introduction

A safety case is a type of assurance case where the assured property is safety. The primary purpose of a safety case is to communicate to stakeholders the argument and supporting evidence for the safety of a system.

Benefits

Many people’s first thought is that a safety case is for the benefit of some form of regulator but there are other stakeholders for whom it can be of considerable value even if a safety case is not required by regulations or standards.

Firstly, perhaps the most critical stakeholders in a safety critical system are the developers themselves and it can be challenging to know if you have fully fulfilled requirements of a standard and that you have sufficiently covered all aspects necessary for a safe product. A safety case can be used to pull out the underlying argument for why following a standard helps to make the product safe. It can form a guide to the standard by illustrating the overall structure of a standard and how the requirements and the expected work products of each section fit into the overall argument. With this understanding the safety case and supporting evidence can be reviewed to look for any weaknesses.

Secondly in many cases the developer may be a supplier to a higher level in the supply chain, e.g. a tier 1 sensor supplier into a tier 1 system supplier and be expected to assure them that the work they have done is safe and meets the applicable standards.

Good Practises

There are many sources of guidance for good practise for Safety Cases such as the Assurance Case Guidance from the Safety Critical Systems Club [1]. The following sections will illustrate some that we have found to be particularly useful.

Concurrent Development of Product and Safety Case

The most important practise is to develop the safety case alongside the product. There are several reasons this is important; it helps avoid “solution bias” whereby a retrospective safety case seeks to prove what has been done is right rather than to find faults, it helps guide developers with compliance of a standard, e.g. by highlighting if a required piece of analysis to provide evidence hasn’t been done and it makes the implicit reasoning for the safety of the system explicit so it can be reviewed and challenged and addressed at a time when it is the least effort and cost to make changes.

Graphical Notation

Safety case construction is greatly simplified by use of Goal Structuring Notation (GSN) is a standardized [2] and widely used graphical argument notation which can be used to document explicitly the elements and structure of an argument and the argument’s relationship to evidence. A section of a GSN argument is shown below.

Figure 1 – GSN Argument Example showing a section of a Safety Case

While there are specialised tools available, GSN arguments can be constructed by simple drawing tools but some effort may have to be invested into developing templates for the symbols. In choosing a tool our advice would be; to make sure that it can support version 3 of GSN standard, does not constrain an argument to a particular page size, that it can create hyperlinks between argument sections for ease of navigation and exports in html for wider stakeholder review. If using a simple drawing tool, a useful practise is to create a spreadsheet with the elements, their relationships and the argument modules they support to help consistency of identification and review of the argument.

Style Guidelines

Even using graphical notations such as GSN, the arguments can become complicated so applying some style guidelines to the structure of the argument is important to ensure it can be readily understood. At a simple level this can be breaking down the argument into modules which support a top-level argument. At a more complex level, a safety case will typically have arguments covering how the technical risks of the system are addressed, giving confidence in the capabilities of the people, processes, tools employed in the development of the system and giving confidence in the correct execution of the required processes. A useful practise is to recognise and separate out argument modules dealing with different concerns. GSN version 3 provides a mechanism of “Assurance Claim Points” which can branch off such separate arguments from the main risk argument. In the example shown in figure 1, ACP1 would be a separate argument for the correctness of the concept and scope definition of the system of interest. A practise used by 3sK to augment the GSN Standard is to specifically identify the nature of the argument using symbols in coloured circles as shown in figure 1.

Constructive Criticism

Finally, it is best practice to constructively critique the safety case (“dialectic arguments”) throughout its lifetime. This is best done by those with domain knowledge or analytical skills that can identify the potential weaknesses in an argument. GSN version 3 has specific symbols for creating these counter-arguments which are linked to the original argument. We have found it useful to use colour to easily discriminate the counter-arguments from the original argument as illustrated below.

Figure 2 – GSN Argument Example showing Counter-argument Notation in Red

Conclusion

Safety cases can be a valuable tool to the developers of systems and their customers to constructively review their approach and gain assurance that their work meets their safety objectives and the requirements of standards. This article has pointed out some of the good practises that need to be applied to gain the most benefit from safety cases.

For further information on how to apply Safety Cases or to discuss safety analysis and risk management at your organisation, get in touch with us at [email protected]