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