Overview of the Tiered Safety Argument Patterns

Posted by GSNAdmin on December 09, 2011
Articles, Tiered Safety Argument Patterns

Software safety argument patterns provide a way of capturing good practice in software safety arguments. Patterns are widely used within software engineering as a way of abstracting the fundamental design strategies from the details of particular designs. The use of patterns as a way of documenting and reusing successful safety argument structures was pioneered by Kelly in [1]. As with software design, software safety argument patterns can be used to abstract the fundamental argument strategies from the details of a particular argument.


Written by Richard Hawkins

It is then possible to use the patterns to create specific arguments by instantiating the patterns in a manner appropriate to the application.There exist a number of examples of safety argument patterns. Kelly developed an example safety case pattern catalogue in [1] which provided a number of generic solutions identified from existing safety cases. Although providing a number of useful generic argument strategies, the author acknowledges that this catalogue does not provide a complete set of patterns for developing a safety argument, it merely represents a cross-section of useful solutions for unconnected parts of arguments. Kelly’s pattern catalogue does not deal specifically with any software aspects of the system. The safety argument pattern approach was further developed by Weaver [2], who specifically developed a safety pattern catalogue for software. The crucial differences with this catalogue were firstly that the set of patterns in the catalogue were specifically designed to connect together in order to form a coherent argument. Secondly the argument patterns were developed specifically to deal with the software aspects of the system.

There are a number of weaknesses that have been identified with Weaver’s pattern catalogue. First, the patterns take a fairly narrow view of assuring software safety, in that they focus on the mitigation of known failure modes in the design. Mitigation of failure modes is important, but there are other aspects of software assurance which should be given similar prominence. Second, issues such as safety requirement traceability and mitigation were considered at a single point in Weaver’s patterns. This is not a good approach; it is clearer for the argument to reflect the building up of assurance relating to traceability and mitigation over the decomposition of the software design. Finally, Weaver’s patterns have a rigid structure that leaves little scope for any alternative strategies that might be needed for novel technologies or design techniques.

A software safety pattern catalogue was also been developed by Ye [3], specifically to consider arguments about the safety of systems including COTS software products. Ye’s patterns provide some interesting developments to Weaver’s, including patterns for arguing that the evidence is adequate for the assurance level of the claim it is supporting. Although we do not necessarily advocate the use of discrete levels of assurance, the patterns are useful as they support the approach of arguing over both the trustworthiness of the evidence and the extent to which that evidence supports the truth of the claim.The catalogue of software safety argument patterns presented in this document builds upon the existing work discussed above, and also takes account of current good practice for software safety, including from existing standards. The software safety argument pattern catalogue contains a number of patterns which may be used together in order to construct a software safety argument for the system under consideration. The software safety argument patterns describe the nature of the argument and safety claims that would be expected for any software safety case. The way the argument is supported may be different for each system but the ‘core elements’ of the argument (as defined by the patterns) remain.

A number of case studies have been used to implement the software safety argument patterns [4]. These case studies have highlighted the benefits of utilising the patterns when developing software safety cases. The pattern catalogue is also included as part of the SSEI standard of best practice for software in the context of defence standard 00-56 [5].


The following argument patterns are provided in the software tiered safety argument pattern catalogue:

High-level software safety argument pattern – This pattern provides the high-level structure for a software safety argument. The pattern can be used to create the high level structure of a software safety argument either as a stand-alone argument or as part of a broader system safety argument.

Software contribution safety argument pattern – This pattern provides the structure for an argument that the contributions made by software to system hazards are acceptably managed. This pattern is based upon a generic ‘tiered’ development model in order to make it generally applicable to a broad range of development processes and technologies.

Software Safety Requirements identification pattern – This pattern provides the structure for an argument that software safety requirements (SSRs) are correct and appropriate for each tier of the software design.

Hazardous contribution software safety argument pattern – This pattern provides the structure for an argument that hazardous errors are not introduced at each tier of software design decomposition. This includes arguing that mistakes have not been made in decomposing the design, and also that no new hazardous behaviour has been introduced.

Software contribution safety argument pattern with grouping – This pattern is an extension of the Software Contribution Safety Argument Pattern. It provides the option of grouping the argument to reflect natural requirements groupings in the software design.When instantiated for the target system, these patterns link together to form a single software safety argument for the software.
[1] T. Kelly, Arguing Safety – A Ystematic Approach to Managing Safety Cases, PhD Thesis, Department of Computer Science, The University of York, 1998.

[2] R. Weaver, The Safety of Software – Constructing and Assuring Arguments, PhD Thesis, Department of Computer Science, The University of York, 2003.

[3] F. Ye, Justifying the Use of COTS Components within Safety Critical Aplications, PhD Thesis, Department of Computer Science, The University of York, 2005.

[4] R. Hawkins, K. Clegg, R. Alexander, T. Kelly, Using a Software Safety Argument Pattern Catalogue: Two Case Studies, in F. Flammini, S. Bologna, and V. Vittorini (Eds.): SAFECOMP 2011, LNCS 6894, pp. 185–198. Springer, Heidelberg, 2011.

[5] C. Menon, R. Hawkins, J. McDermid, Interim standard of best practice on softwarein the context of DS 00-56 Issue 4. Technical Report SSEI-BP-000001, Software Systems Engineering Initiative, 2009.

[6] M. Jaffe, R. Busser, D. Daniels, H. Delseny, G. Romanski, Progress Report onSome Proposed Upgrades to the Conceptual Underpinnings of DO178B/ED-12B, InProceedings of the 3rd IET International Conference on System Safety, 2008.

[7] T. Kelly, Concepts and principles of compositional safety case construction,Technical Report COMSA/2001/1/1, The University of York, 2001.



Comments are closed.