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.
GSN Patterns
Posted by GSNAdmin
on December 09, 2011
Articles, Tiered Safety Argument Patterns / Comments Off on Overview of the Tiered Safety Argument Patterns
Articles, Tiered Safety Argument Patterns / Comments Off on Overview of the Tiered Safety Argument Patterns
Posted by GSNAdmin
on December 09, 2011
Tiered Safety Argument Patterns / Comments Off on Software Contribution Safety Argument Pattern with Grouping
Tiered Safety Argument Patterns / Comments Off on 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. 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.
Posted by GSNAdmin
on December 09, 2011
Tiered Safety Argument Patterns / Comments Off on Hazardous Contribution Software Safety Argument Pattern
Tiered Safety Argument Patterns / Comments Off on Hazardous Contribution Software Safety Argument Pattern
This pattern provides the structure for arguments that potential hazardous failures that may arise at {tier n} are acceptably managed.
Posted by GSNAdmin
on December 09, 2011
Tiered Safety Argument Patterns / Comments Off on SSR Identification Software Safety Argument Pattern
Tiered Safety Argument Patterns / Comments Off on SSR Identification Software 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.
Posted by GSNAdmin
on December 09, 2011
Tiered Safety Argument Patterns / Comments Off on Software Contribution Safety Argument Pattern
Tiered Safety Argument Patterns / Comments Off on Software Contribution Safety Argument Pattern
This pattern provides the structure for arguments that the contributions made by software to system hazards are acceptably managed.
Posted by GSNAdmin
on December 09, 2011
Tiered Safety Argument Patterns / Comments Off on High-Level Software Safety Argument Pattern
Tiered Safety Argument Patterns / Comments Off on High-Level Software 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.
Posted by GSNAdmin
on December 07, 2011
GSN Patterns / Comments Off on Handling of Software Failure Mode
GSN Patterns / Comments Off on 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).
Posted by GSNAdmin
on December 07, 2011
GSN Patterns / Comments Off on Handling of Hardware/Other Component Failure Mode
GSN Patterns / Comments Off on 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.
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.
Posted by GSNAdmin
on December 07, 2011
GSN Patterns / Comments Off on Absence of Value Hazardous Failure Mode
GSN Patterns / Comments Off on 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.
