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.
References
[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.

Author: Richard Hawkins

Last update: 7/12/10

Grouping aspects of the Software Contribution Safety Argument Pattern can help to manage the safety argument where there exist a large number of claims at a particular tier of decomposition by splitting the argument into manageable chunks.

Author: Richard Hawkins

Last update: 8/6/2009

At each tier of software development it is possible that hazardous failures may manifest themselves. This argument demonstrates how the hazardous failures are prevented. This is achieved in two ways. Firstly potential hazardous failure modes are identified, and appropriate SSRs defined in response. Secondly, the absence of design errors which could cause hazardous failures must also be demonstrated. It should be noted that this aspect of the argument will often consider more generally how errors are removed from the design.

Author: Richard Hawkins

Last update: 8/6/2009

Author: Richard Hawkins

Last update: 8/6/2009

It is necessary to consider all of the ways in which errors may be introduced into the software which could lead to the software contribution. The software development process used will vary between different projects, however in all cases the software development is undertaken through varying levels of design. At each level the design must satisfy requirements of the higher level. These requirements may be explicitly captured as part of a requirements specification, or identified implicitly from the design itself. In [6] Jaffe et al propose an extensible model of development which captures this relationship between components at different tiers. Figure 1 illustrates the multi-tiered relationship between successively more detailed requirements and design information. Figure 2 illustrates in more detail the relationship among a tier n component’s requirements, its design representation, and the tier n+1 requirements of the tier n+1 (sub) components identified in the design representation.From a safety perspective, it is necessary to ensure that at each tier, the software safety requirements derived at the previous tier are adequately addressed. This involves making design decisions which mitigate potential failures and adequately allocating and decomposing the software safety requirements (SSRs) through consideration of the design at that tier. At each tier it is also possible to introduce errors into the software which could manifest themselves as hazardous failures. It is therefore important in the software safety argument to also consider additional hazardous contributions that may be introduced at each tier.This pattern therefore reflects the tier model discussed above in order to make it generally applicable to a broad range of development processes.

Author: Richard Hawkins

Last update: 8/6/2009

Authors: Rob Weaver, John McDermic, Tim Kelly

Last Modified: 20/4/2004

The motivation for this pattern is to be able to either identify requirements on the hardware or other component safety arguments, or to develop an argument about other software functionality that will detect and handle the failure.

Authors: Rob Weaver, John McDermic, Tim Kelly

Last Modified: 20/4/2004

The motivation for this pattern is to be identify the ways in which failure modes are detected and handled by the software, depending upon the type of the failure mode.

Authors: Rob Weaver, John McDermic, Tim Kelly

Last Modified: 20/4/2004

The motivation for this pattern is to be able to argue about failure modes in other components to demonstrate they cannot induce a failure mode in the software functionality under consideration. Hardware and Other component failure modes can be address through showing absence, probability of occurrence or handling of the failure. Software Failure Modes can be addressed in the same way as the original failure mode in another pattern.

Authors: Rob Weaver, John McDermic, Tim Kelly

Last Modified: 20/4/2004

The motivation for this pattern is to be able to decompose the possible causes of a Value Failure Mode so as to be able to analyse them individually. These causes are based upon the software in which the failure mode manifests itself, other components of the system that may induce the failure mode within the software functionality and control of the software functionality.