Please log in using either your email address or your membership number.
Please register with your name, email address, password and email preferences. You will be sent an email to verify the address.
Please enter the email address used for your account. A temporary password will be emailed to you.
This area of the SCSC website hosts Goal Structuring Notation (GSN) standardisation information and related guidance.
It can be reached through scsc.uk/gsn or goalstructuringnotation.info.
The GSN information is created and maintained by the GSN Standard Working Group (GSN_SWG), a sub-group of the SCSC's Assurance Case Working Group (ACWG).
The principal objective of this site is to disseminate information and resources related to GSN.
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.
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.
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.
This pattern provides the structure for arguments that potential hazardous failures that may arise at {tier n} are acceptably managed.
Tags: contribution, software, tiers.
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
This pattern provides the structure for arguments that the contributions made by software to system hazards are acceptably managed.
Tags: contribution, software, tiers
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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