Don't Miss
Home / Blog / Assurance Case Notations

Assurance Case Notations

GSN is the dominant notation for AC constructions. The SACM 2.0 framework enables the model-based AC process with the support of the model-based engineering platforms, and further to link the AC model with the system model automatically. We can envisage the future application in the engineering practice of SACM.

An assurance case(AC) can be defined as “A reasoned and compelling argument, supported by a body of evidence, that a system, service or organisation will operate as intended for a defined application in a defined environment. ”[1]. It is a structured argument to decompose the top-level claims to be argued into different properties, for example, safety, security, reliability, process compliance, performance, etc., among which safety is the most discussed in the form of the safety case. A safety case (SC) is a comprehensive, defensible, and compelling justification of the system safety for a given application in a defined operating environment [2].

Many autonomous systems are safety-critical, such as the autonomous cars, medical robots, nuclear power control, etc.. Therefore, their certification process may require the AC demonstration.

The most widely used notations of AC are the structured graphical forms, including Goal Structuring Notation(GSN) [1] and Claims-Arguments-Evidence (CAE) [3]. The graphics facilitate the system stakeholders’ understanding and communication of information required for arguing the system properties.

In 1998, Bloomfield in Adelard [4] developed CAE as a straightforward notation for structuring safety cases. CAE and GSN share similar notation methods[5].

GSN was developed by Kelly in 1998 [6] at the University of York. GSN comprises 6 main elements, the goal, the context, the justification, the assumption, the strategy, and the solution, as shown in Figure 1.

Figure 1. Main elements of GSN

Figure 2 shows an example of an abstract safety case in GSN, and the relationship between different elements. G1 is the top-level goal, it is decomposed into two lower-level goals G2 and G3. And furtherly G2 is decomposed through strategy S1 into G4, G5, and G6 each of which is supported/justified by the evidence provided in solution. This shows how the argument is structured. For the goal to be satisfied, the context such as C1, assumptions such as A1, and justifications such as J1 need to be valid to support the argument.

Figure 2. An example of a GSN safety case [1]

The graphic notations provide better understanding of the argument, however, lack the foundation for AC process automation. With the Model-based Engineering (MBE) being widely exploited, Structured Assurance Case Meta-Model (SACM) [7] is designed as a meta-model for modelling AC. SACM is an Object Management Group (OMG) standard. It defines AC as a collection of auditable claims, arguments, and evidence created to support the contention that a defined system or service will satisfy certain requirements [8].

SACM is a modelling language, and can create a machine-readable model that facilitates the exchange of information between various systems stakeholders.

SACM has five components shown in Figure 3. AssuranceCase package represents the AC module. Base component defines the fundamental elements of SACM, such as element names and descriptions. The Artifact component captures the concepts used in providing evidence for the arguments made for system properties. The Terminology component captures the concepts used in expressing the claims regarding system properties, such as expressions, and the argumentation component.

Figure 3. Components of SACM [9]

The metamodel of AssuranceCase package is shown in Figure 4. It is the main component to build the argument of system properties, such as safety, security [9]. Assurance case packages are composed of argument packages, artifact packages, and terminology packages.

Figure 4. SACM argumentation component [21]

Figure 5 is an example of a SACM claim. It can have a name and a description, captured by LangString and Description respectively. This is called an asserted claim which is equivalent to the Goal in GSN. A Claim is asserted if it is supported by other Claims.

Figure 5. An asserted claim in SACM [9]

SACM can support different notations including GSN and CAE. The table below describes the mapping from GSN elements onto SACM 2.0 elements which helps the better understanding of SACM framework and facilitates the conversion from GSN to SACM. The Goals in GSN is Claims in SACM, the strategy to show the reasoning logic is the AssertedInference in SACM with sources of low-level claims to targets of high-level claims; the Solution in GSN is represented by the citation of the evidence ArtefactElementCitation which references to the Artifact package that stores evidence files; the Context in GSN can be ArtefactElementCitation that references to the Artifact package when the Context is simply contained in an artefact, or be the Claim with assumed attribute TRUE when Context is making an assumed statement of context. A Claim in SACM that is intentionally declared without any supporting evidence or argumentation can be declared as being assumed (i.e., assertionDeclared = assumed) and it is an Assumption in GSN. The concepts of Away+Element in GSN such as AwayGoal, AwayContext are developed for the purpose of modular AC. The AwayGoal in GSN refers to a goal in another module, and is represented by ArgumentAssetCitation where this cited Asset is Claim in another ArgumentPackage.

Table 1. Mapping from GSN elements onto SACM 2.0 node elements [10]

Since SACM is a model-based framework, the mapping with GSN is not a graphic to graphic relationship, instead, it’s a graphic-to-model correspondence. GSN can be seen as an implementation of the ARguemntation package of SACM. GSN diagrams can be fully translated to SACM 2.0 using MBE techniques of model-to-model transformation. For example, in Figure 6 (a) a GSN Goal shows that the goal has a name of Goal_G1 and a description of “System X can tolerate single conponent failures”, the underlying SACM model is represented in Figure 6 (b) where the Claim has one name “Goal_G1” in the language of English, and one description which has one content “MultiLangString”. MultiLangString, as its name suggests, provides a means to describe things using different languages. Further, the MultiLangString has a value that the language is English, and the content is “System X can tolerate single component failures”.

Figure 6a. GSN goal example [11]

Figure 6b. SACM model [11]

GSN is the dominant notation for AC constructions. However, without the formal syntax underpinning, it is difficult to realize the automation of AC construction process to a greater extent. The SACM 2.0 framework enables the model-based AC process with support of the model-based engineering platforms, and may bring benefit in the accuracy and efficiency of AC construction and management, especially the co-evolution of AC model and system models.

SACM version 2.1 beta was published in 2020. Since then, there has not been an industrial application of SCAM published. However, SACM enables the model engineering techniques to be applied to the ACs, and further to link the AC model with the system model automatically. We can envisage the future application in the engineering practice of SACM, and will explore the process and the tool support for the model-based SACM assurance cases.


[1] Assurance Case Working Group, “GSN Community Standard. Version 2.” [Online]. Available:
[2] E. Denney and G. Pai, Tool support for assurance case development, vol. 25, no. 3. Springer US, 2018.
[3] “Claims-Argument-Evidence-Adelard LLP.” [Online]. Available:
[4] R. E. Bloomfield, P. G. Bishop, C. Jones, and P. K. D. Froome, “Ascad—adelard safety case development manual,” Adelard, 1998. ISBN 0-9533771-0, vol. 5, 1998.
[5] M. Tokoro, Open systems dependability: dependability engineering for ever-changing systems. CRC press, 2015.
[6] T. Kelly, “Arguing Safety–A Systematic Approach to Safety Case Management DPhil Thesis,” Dep. Comput. Sci. Univ. York, UK, 1998.
[7] Object Management Group (OMG), “Structured Assurance Case Metamodel (SACM),” 2020. [Online]. Available:
[8] J. L. de la Vara, “Current and necessary insights into SACM: An analysis based on past publications,” in 2014 IEEE 7th International Workshop on Requirements Engineering and Law (RELAW), 2014, pp. 10–13.
[9] R. Wei, T. P. Kelly, X. Dai, S. Zhao, and R. Hawkins, “Model based system assurance using the structured assurance case metamodel,” J. Syst. Softw., vol. 154, pp. 211–233, Aug. 2019.
[10] “Mapping between GSN and SACM 2.0.” [Online]. Available:
[11] “An example of the usage of the argumentation package of SACM 2.0, illustrated using examples of Goal Structuring Notation (GSN).” [Online]. Available:

About the Author: Fang Yan

Fang has her bachelor’s degree in Electronic and Information Engineering at the Civil Aviation University of China and completed her master’s degree in Ecole National Superieur D’ingeneurs De Constructions Aeronautiques. After the university, she worked as a lecturer in a university and had 7 years of part-time experience in aviation certification in terms of system safety and software safety. She has her interest in safety methodology for autonomous systems and chose to continue in academia and therefore into this PhD.