Document 6514516

The Goal Structuring Notation (GSN)
High Integrity Systems Engineering Group
Introduction
Purpose of GSN
Purpose of a Goal Structure
The Goal Structuring Notation (GSN) is
a framework used to capture and
graphically
represent
assurance
arguments. It has evolved and been
used for over ten years, motivated by
the inadequacy of plain text to clearly
and traceably represent the inferences
in an argument. GSN offers sufficient
concept richness to depict the
reasoning in an assurance case.
To show how goals
are broken down into sub-goals,
and eventually supported by evidence ( solutions)
whilst making clear the strategies
adopted,
the rationale for the approach (assumptions, justifications)
A/J
and the context
GSN Elements
Goal: A goal communicates a claim about the system
and they represent post-conditions.
Context: Captures and enables citation of information
that are relevant to the argument.
in which goals are stated
GSN Six Step Method
The Six step method provides guidance on
how to create GSN structures.
1. Identify goals to be supported
Strategy: Strategies explain the inference between
parent and children goals.
2. Define basis on which goals are stated
Solution: Represents information that can directly
(without further inferences) support a goal.
4. Define basis on which strategy is stated
3. Identify strategy to support goals
5. Elaborate strategy – goto step 1
Solved By: Shows support (decomposition) of
argument elements.
6. Identify solution
In Context Of: Captures association with context.
GSN Structure Example – Industrial (Mechanical) Press Safety Argument
The Goal Structuring Notation
High Integrity Systems Engineering Group
What is an Argument
Reusing Arguments
Patterns: Patterns provide the concepts to capture
a generalised argument. Instantiating the argument
for the system in question and in its context, will
systematically guide the developers through the
considerations of the argument (i.e. the particular
hazards for the system).
An argument is described as being a connected
series of statements or reasons intended to
establish a position. Arguments consist of claims
and inferences.
Evolution of an argument usually takes place until
the claims can be directly supported by the available
evidence. Insufficiency of evidence to support the
developed argument structure reveals the need for
activities that will produce additional evidence (e.g.
additional system testing).
Modular GSN: Modular extensions allow cohesive
arguments to be captured as argument modules,
which can be referenced from other argument
modules. Contracts document the dependencies
between the arguments. Modular arguments benefit
the maintenance of the case as often a change can
be contained within an argument module.
context.
Argumentation can be used to capture any position
about the system that the stakeholders chose to
communicate, irrespective of the viewpoint of this
position. For example although safety and security
use different concepts, assurance about the overall
position regarding these attributes (i.e. secure and
safe system) can be captured using argumentation.
Both argument and evidence are crucial elements of
a dependability case. An argument without evidence
is unfounded whereas evidence without argument is
unexplained. A set of evidence does not constitute
by itself an argument. position.
The way an argument is structured will affect the
confidence with which it supports a position.
Modular GSN
Below: Module view of part of a (safety) case. A
top level safety argument is supported by
individual arguments about the safety of
functions A and B. This in the context of an
argument claiming independence (i.e. the
functions do no have common means of
compromising safety) of the functions.
FnAArgument
Function A Safety
Argument
TopLevelArg
IndependenceArg
Top Level System X
Safety Argument
Functional
Independence
Argument
SysAccSafe
{System X} is
acceptably safe
SRFunctions
Safety Related
functions of
{System X}
ArgOverFunctions
Argument over all identified
safety related functions of
{System X}
FunctionsInd
All functions are
independent
IndependenceArg
FnASafe
Function A operation
is acceptably safe
FnBArgument
Function B Safety
Argument
FnBSafe
Function B operation
is acceptably safe
FnCSafe
Function C operation
is acceptably safe
FnBArgument
Right: Argument modules contain standard GSN.
Additions of modular GSN specific constructs to
enable inter-module referencing. FnBSafe: away
goal, FunctionsInd: away context.
FnAArgument
Safety Argument for
Function A
FnBSafe is
referencing a
Goal in another
module
FunctionsInd is
contained in another
module, and used to
provide context.
Further Reading and Resources (Hyperlinks)
http://wwwusers.cs.york.ac.uk/
~tpk/tpkthesis.pdf
http://wwwusers.cs.york.ac.uk/
~ihabli/Papers/200
7Habli_SSS07.pdf
More details and latest version at
http://bit.ly/cEWA5B
http://wwwusers.cs.york.ac.uk/
~tpk/Compositional
SafetyCases.pdf
http://despotou.eu/index
.php/publications/34conference-papers/93supporting-through-lifesafety-assurance-ofcots-based-upgrades
2010 © University of York
http://despotou.eu/index
.php/publications/35misc/65-managing-theevolution-ofdependability-cases-forsystems-of-systems
http://www.originconsulting.com/gsn
club/
Document maintenance: George Despotou
GSN Reference Card v.1.2