Pattern Catalogue

This Pattern catalogue has been compiled from previously published items.

Some of the material requires refreshing to bring it into line with the latest version of the GSN standard. However, the intent and approach can still be utilised in advance of such a refresh. If you are aware of any patterns that can be made available under the license shown on the About tab, please contact the ACWG using the links provided on that tab.

Overview of the 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. As with software design, software safety argument patterns can be used to abstract the fundamental argument strategies from the details of a particular argument.

Software Contribution Safety Argument Pattern with Grouping [Tiered Safety Argument Pattern]

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. For example, for an instantiation of the Software Contribution Safety Argument Pattern at the software architecture level, it may be desirable to create groupings in the argument which reflect each of the individual architectural design elements.
Tags: contribution, grouping, software

Hazardous Contribution Software Safety Argument Pattern [Tiered Safety Argument Pattern]

This pattern provides the structure for arguments that potential hazardous failures that may arise at {tier n} are acceptably managed.
Tags: contribution, software, tiers

SSR Identification Software Safety Argument Pattern [Tiered Safety Argument Pattern]

This pattern provides the structure for arguments that software safety requirements (SSRs) from a previous tier of development have been adequately captured at the next tier of development through the allocation, decomposition, apportionment or interpretation of the SSRs from the previous tier. This is achieved either through making design decisions which mitigate the SSR, or through the definition of additional SSRs.
Tags: requirements, software, SSR

Software Contribution Safety Argument Pattern [Tiered Safety Argument Pattern]

This pattern provides the structure for arguments that the contributions made by software to system hazards are acceptably managed.
Tags: contribution, software, tiers

High-Level Software Safety Argument Pattern [Tiered Safety Argument Pattern]

This pattern provides the high-level structure for a software safety argument. The pattern can either be used to create the high level structure of a ‘stand alone’ software safety argument considering just the software aspects of the system, or alternatively can be used to support claims relating to software aspects within a broader system safety argument.
Tags: high level goals, software

Handling of Software Failure Mode

The intent of this pattern is to develop an argument that a software failure mode can be handled by other components (software, hardware or other).
Tags: failure, software

Handling of Hardware/Other Component Failure Mode

The intent of this pattern is to develop an argument that the software functionality can handle failures by hardware or other components.
Tags: failure, hardware

Effects of Other Components

The intent of this pattern is to argue that the effects of other components (software, hardware or other) are acceptable with respect to the hazardous software failure mode under consideration.
Tags: component, effects

Absence of Value Hazardous Failure Mode

The intent of this pattern is to argue that an individual software hazard, which is of the type Value, is absent within a certain component of software functionality in a system.
Tags: failure, value

Absence of Late Hazardous Failure Mode

The intent of this pattern is to argue that an individual software hazard, which is of the type Late, is absent within a certain component of software functionality in a system.
Tags: failure, late

Absence of Early Hazardous Failure Mode

The intent of this pattern is to argue that an individual software hazard, which is of the type Early, is absent within a certain component of software functionality in a system.
Tags: early, failure

Absence of Commission Hazardous Failure Mode

The intent of this pattern is to argue that an individual hazardous software failure mode, which is of the type Commission, is absent within a certain component of software functionality in a system.
Tags: comission, failure

Absence of Omission Hazardous Failure Mode

The intent of this pattern is to argue that an individual hazardous software failure mode, which is of the type Omission, is absent within a certain component of software functionality in a system.
Tags: failure, omission

Software Argument Approach

The intent of this pattern is to identify the argument approach used for demonstrating the acceptability of the hazardous software failure mode. The argument can be made by showing Absence and/or Handling of the failure mode.
Tags: approach, software

Hazardous Software Failure Mode Classification

The intent of this pattern is to provide a type classification for the hazardous failure mode that is the subject of the argument. The failure mode can be classified as one of Omission, Commission, Early, Late or Value.
Tags: failure, software

Hazardous Software Failure Mode Decomposition

The intent of this pattern is to provide a decomposition for the acceptability of software with respect to system level hazards. The pattern identifies the primary claims for developing a software safety argument from a hazard control perspective.
Tags: decomposition, failure, software

Component Contributions to System Hazards

The intent of this pattern is to provide a top level decomposition for the safety argument of a system. In particular, the pattern provides the context for a software safety argument constructed from the Software Safety Pattern Catalogue. The focus for the argument is the identification of hazards and the assessment of the associated risks.
Tags: component, hazard