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
Safety Principle 6 (Defence in Depth) Compliance
The purpose of this pattern is to argue compliance with Safety Principle 6 (Defence in Depth) of the Nuclear Naval Programme Safety Principles and Safety Criteria document.
Tags: compliance, defence in depth, safety principle
Fault Tree Evidence
The intent of this pattern is to show the nature of the claims that can be made from a fault tree representation of the causes of a condition.
Tags: evidence, fault trees
Safety Margin
The intent of this pattern is to create arguments that instil a high degree of confidence in the satisfaction of a goal and are resilient to change and criticism.
Tags: crumple zone, margin, requirements
Diverse Argument
The intent of this pattern is to create arguments that instil a high degree of confidence in the satisfaction of a goal and are resilient to change and criticism.
Tags: diversity, single point of failure
Control System Architecture Breakdown Argument
The intent of this pattern is to illustrate a means of structuring an argument to support a system safety goal (requirement, avoidance of hazard etc.) by decomposition over a generic control system model.
Tags: decomposition, high level goals
Hazard Directed Integrity Level Argument
This pattern is intended to argue that a (sub)system has been developed to an integrity level appropriate to the hazards to which the system contributes.
Tags: hazard, Integrity levels, subsystem
As Low As Reasonably Practicable
This pattern provides a framework for arguing that identified risks in a system have been sufficiently addressed in accordance with the ALARP principle.
Tags: ALARP
GSN Contributors
The following individuals and organizations are acknowledged for their contribution to and support for the GSN standardization process.
Contributors have not necessarily contributed to all versions and the resultant standard does not necessarily entirely reflect the views of those acknowledged here.
|
Individual Contributors |
||
|
Katrina Attwood |
Ben Gorry |
Lisa Logan |
|
Contributing Organisations |
|
|
AACE |
Leonardo |
pattern FAQ placeholder
modular FAQ placeholder
Frequently Asked Questions
This page contains general FAQ about GSN. Further FAQ are also available for the following sub-topics:
What is GSN?
Please see the In a Nutshell section of the website.
How should I start?
You can start by reading the In a Nutshell section, and then the GSN standard and examples provided.
What is the difference between a goal and a claim?
None. Goals in GSN carry the claims of an argument.
How big should a GSN argument be?
As big as it needs to be. GSN arguments represent the reasoning behind the claims that we are prepared to make about a system. If a system is complex and requires complex reasoning, then the GSN argument will eventually be large. GSN does not add complexity to the system, it merely documents the reasoning of the stakeholders (making the implicit, explicit and thus amenable to challenge and consensus).
When in the lifecycle should I use GSN?
There is no specific part of the lifecycle for which GSN is best suited. GSN is used to capture the safety case, which ideally should go hand in hand with system development. With GSN, similarly to other notations (e.g. UML), details are added during each lifecycle stage until we have a established a convincing safety case. GSN semantics provide the necessary expressive richness to capture the information necessary at any lifecycle stage. Experience is useful to find the right balance of abstraction (for your needs) at any development stage.
Is GSN a safety case?
GSN provides better means to graphically capture the constituent elements of a safety case (i.e. argument and evidence). You can still have perfectly valid GSN structures, which however do not offer confidence with regard to the safety of the system (similarly to having a valid UML model for a not so good system).
How does GSN relate to OMG's SACM?
Both GSN and SACM have the same purpose, but GSN is at present more mature and more widely used. GSN is specified by the GSN Working Group whereas SACM by the OMG. SACM was influenced by GSN and there is an ongoing liaison between the GSN and SACM maintenance committees. There is a definition of equivalence of concepts between GSN and SACM available - see GSN Meta-Model.
Why do I need the six step method?
GSN is not merely a graphical notation. It is accompanied by a method that facilitates decomposition of goals in way that will result in a comprehensive and clear argument. The six step method is included in the GSN Standard.
What is a GSN pattern?
A pattern is a generic argument representing a specific strategy to address an issue (usually specified in the top level goal of the pattern). As with software patterns, GSN patterns should be used with care for the right type of problem and may always need some tuning to a specific case.
Do I need to use all GSN symbols when I create GSN?
No. GSN symbols provide you with expressive richness to capture anything that (many years of practice have shown) you may need.
What is modular GSN?
Modular GSN allows to create self contained interrelated argument modules. Modular GSN allows to group logical arguments in a module, that can be referenced from many sources. Modular GSN allows the logical separation of issues which can then be developed by the appropriate stakeholders, thus helping development as well as navigation of the argument (module view). Also, modular GSN allows to information hiding, which is particularly useful in the early stages of the lifecycle when the content of a part of the safety case may still be unclear.
Is GSN only used in the safety domain?
No, GSN could be used to capture any position supported by argument and evidence, even legal arguments.
Historically GSN has be used mainly in the safety domain to document safety cases. However, it has also been used to capture and support requirements (specified as goals). Examples include dependability, security and reliability & availability.