GSN Patterns

Overview of the Tiered Safety Argument Patterns

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

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.

Continue reading…

Software Contribution Safety Argument Pattern with Grouping

Posted by GSNAdmin on December 09, 2011
Tiered Safety Argument Patterns / Comments Off

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.

Continue reading…

Tags: , ,

Hazardous Contribution Software Safety Argument Pattern

Posted by GSNAdmin on December 09, 2011
Tiered Safety Argument Patterns / Comments Off

This pattern provides the structure for arguments that potential hazardous failures that may arise at {tier n} are acceptably managed.

Continue reading…

Tags: , ,

SSR Identification Software Safety Argument Pattern

Posted by GSNAdmin on December 09, 2011
Tiered Safety Argument Patterns / Comments Off

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.

Continue reading…

Tags: , ,

Software Contribution Safety Argument Pattern

Posted by GSNAdmin on December 09, 2011
Tiered Safety Argument Patterns / Comments Off

This pattern provides the structure for arguments that the contributions made by software to system hazards are acceptably managed.

Continue reading…

Tags: , ,

High-Level Software Safety Argument Pattern

Posted by GSNAdmin on December 09, 2011
Tiered Safety Argument Patterns / Comments Off

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.

Continue reading…

Tags: ,

Handling of Software Failure Mode

Posted by GSNAdmin on December 07, 2011
GSN Patterns / Comments Off

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).

Continue reading…

Tags: ,

Handling of Hardware/Other Component Failure Mode

Posted by GSNAdmin on December 07, 2011
GSN Patterns / Comments Off

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

Continue reading…

Tags: ,

Effects of Other Components

Posted by GSNAdmin on December 07, 2011
GSN Patterns / Comments Off

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.

Continue reading…

Tags: ,

Absence of Value Hazardous Failure Mode

Posted by GSNAdmin on December 07, 2011
GSN Patterns / Comments Off

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.

Continue reading…

Tags: ,