Parameterised Argument Structure for GSN Patterns

Transcription

1 Parameterised Argument Structure for GSN Patterns Yutaka Matsuno Information Technology Center The University of Tokyo, Japan JST, CREST Kenji Taguchi National Institute of Advanced Industrial Science and Technology, Japan JST, CREST Abstract GSN (Goal Structuring Notation) is a graphical notation widely used to construct assurance cases, which are required for the system assurance of safety critical systems. Patterns and their supporting constructs are proposed in GSN, which include parameterised expressions in order to facilitate the reuse of existing assurance cases. Unfortunately the current GSN does not provide the precise account of parameterised expressions, thereby it is hard to automate their consistency check. The aim of this paper is to present a new proposal towards parameterisation of patterns in GSN and to show its formal background. We will present a new parameterised expressions with types, their scoping rules and type checking mechanism, which provide the safeguard to misuses of parameterised patterns and the means to automate checking their type consistency. 1. Introduction System assurance has become a great importance in many industrial sectors. Safety cases (assurance cases for safety of systems) are required to submit to certification bodies for developing and operating safety critical systems, e. g., automotive, railway, defense, nuclear plants and sea oils. There are several standards, e. g. EUROCONTROL [7], Rail Yellow Book [13] and MoD Defence Standard 00-56, which mandate the use of safety cases. There are several definition for assurance cases [3]. We show one of such definitions as follows[1]. a documented body of evidence that provides a convincing and valid argument that a system is adequately dependable for a given application in a given environment. Assurance cases are often written in structured documents using a graphical notation to ease the difficulty of writing and certifying them. Goal Structuring Notation (GSN) is one of such notations [10]. Writing assurance cases and reusing them in a cost effective way is a critical issue for organisations. Patterns and their supporting constructs are proposed in GSN for the reuse of existing assurance cases, which includes parameterised expressions. Unfortunately the current GSN does not provide the precise account of parameterised expressions, thereby it is hard to automate their consistency check. The aim of this paper is to present a proposal towards parameterisation of patterns in GSN and to show its formal background. We will present a new parameterised expressions with types, their scoping rules and type checking mechanism, which provide the safeguard to misuses of patterns with parameterisation and the means to automate checking their type consistency. The paper is organised as follows: the next section explains the background knowledge on this paper. Section 3 presents our proposal for parameterisation of the GSN, scoping rules for variables, and type checking mechanism. Section 4 describes our prototype implementation of parametarised expressions for assurance cases. Section 5 concludes the paper. 2. Background Knowledge 2.1. Goal Structuring Notation (GSN) Goal Structuring Notation (GSN) is introduced by Tim Kelly and his colleagues at University of York [10]. It is a graphical notation for assurance cases. GSN is widely used for safety cases. Some safety cases written in GSN are publicly available [2]. We briefly

2 explain constructs and their meanings in GSN. Arguments in GSN are structured as trees with a few kinds of nodes, including: goal nodes for claims to be argued for, strategy nodes for reasoning steps that decompose a goal into sub goals, and evidence nodes for references to direct evidences that respective goals hold. Figure 1 is a simple example of GSN. The root of the tree must be a goal node, called top goal, which is the claim to be argued (G 1 in Figure 1.) For G 1, a context node C 1 is attached to complement G 1. Context nodes are used to describe the context (environment) of the goal attached to. A goal node is decomposed through a strategy node (S 1) into sub goal nodes (G 2 and G 3). The strategy node contains an explanation, or reason, for why the goal is achieved when the sub goals are achieved. S 1 explains the way of arguing (argue over each possible fault: A and B). When successive decompositions reach a sub goal (G 2) that has a direct evidence of success, an evidence node (E 1) referring to the evidence is added. Here we use a result of fault tree analysis (FTA) as the evidence. For the sub goal (G 3) that is not decomposed nor supported by evidences, a node (a diamond) of type undeveloped is attached to highlight the incomplete status of the case. The assurance case in Figure 1 is written with D-Case Editor ( D derives from Dependability), which is our prototype implementation of assurance case editor [12]. We call assurance cases written in GSN as GSN terms GSN Patterns Writing and certifying assurance cases are difficult because they tend to be huge and complex, and they require domain specific knowledge of target systems. To ease the difficulties, it has been recognized that assurance case patterns should be collected and available for reuse, similarly to design patterns in object oriented languages. There have been several publicly available GSN patterns ([9], [14], [4]). Figure 2 is a simple example of GSN patterns in [4]. The top-level goal of system safety (G1) is reexpressed as a number of goals of functional safety (G2) as part of the strategy identified by S1. In order to support this strategy, it is necessary to have identified all system functions affecting overall safety (C1) e.g. through Functional Hazard Analysis (FHA). In addition, it is also necessary to put forward (and develop) the claim that either all the identified functions are independent, and therefore have no interactions that could give rise to hazards (G4) or that any interactions that have been identified are non-hazardous (G3). Goal:G_2 C/S Logic is free from fault A Evidence:E_1 FTA analysis Result Goal:G_1 C/S Logic is free from possible faults Strategy:S_1 Argue over each possible fault Goal:G_3 C/S Logic is free from fault B Undeveloped:U_1 No evidence is currently given Figure 1. A simple GSN Context:C_1 Risk Analysis Result: Possible faults are fault A and fault B Figure 2 includes main GSN extensions for GSN patterns, as defined in [5]: Parameterized expressions. {System X} and {Function Y } are parametarised expressions. We can instantiate X and Y by appropriate (possibly safety critical) system and function, respectively. Uninstantiated. Triangles ( ) attached to nodes indicate that the nodes contain uninstantiated paramerarised expressions. To instantiate the GSN pattern as an assurance case, we need to instantiate the expressions. 1 to many expressions (multiplicity). Number of functions are different by the target system. We can instantiate the number of functions (n) for the target system. Choice. By this extension, we can choose appropriate goals for the target system Assurance Cases and Standardisation Efforts Two major graphical notations for assurance cases are GSN and CAE (Claims, Arguments, and Evidence) [1]. There are two standardisation efforts for assurance cases; the system assurance task force at the OMG (Object Management Group) and GSN standardisation

3 Figure 2. An example of GSN patterns [4] effort [5]. OMG has standardized the meta-model for assurance cases called ARM (Argument Metamodel) [8] by which both notations are in fact interchangeable. The main aim of the ARM is to align two major notations and facilitates the tool support. Unfortunately it only reflects main constructs between the two, and some specific features, which are not compatible are missing from it. For instance, patterns are not included in the ARM. 3. Parameterised Patterns We aim to formalise parametrised expressions with types in GSN patterns in this paper. In order to do so, we introduce types and define the scope of variables appeared in expressions. These two are not new and fairly basic notions in programming languages. However, the current GSN [4] neither incorporates types nor provides the precise account of the scope of variables. As explained in Section 2.2., the intended meaning of the parameterised expression {System X} in the Figure 2 is to instantiate the variable X by some particular instance which belongs to the System class (or type). We believe that introducing types and giving a precise account of the scope of variables will contribute to avoid misuses of parameterised expressions and to detect errors in early stages. For example, we can automatically avoid mis-placement of variables by type checking. In Figure 2, if a user instantiates X with e.g., Railway hazards, then the argument does not make sense. It is fairly obvious that type checking prevents such a mis-placement. If the scoping rules are not precisely defined, we cannot figure out where variables in a node are declared in the first place. We use contexts for type declaration, type assignment, and variable instantiation. We first define the GSN term as follows. Let g, e, c and st be meta-variables for goals, evidence, context and strategies, respectively. Definition 1 (GSN term T ): T ::=(g,, c) (g, e, c) (g, st, (T 1,..., T n ), c) (g,, c) denotes a GSN term, which consists of just one goal g, a context s attached to the goal. Undeveloped is depicted by and any evidence is not given to support g. (g, e, c) is a GSN term of just a goal g with its context c supported by an evidence e. (g, st, (T 1,..., T n ), c) denotes a GSN term whose top goal g is supported by the child nodes T 1,..., T n. Rationale for why the children nodes together support g is indicated by the strategy st. Context c is defined as a triple of (user-defined) type declarations, type

4 assignments of variables, and variable instantiations as follows. ([T ype 1,..., T ype m ], [x 1 : τ 1,..., x n : τ n ], [v 1 /x 1,..., v n /x n ]) We do not write c when c = ([], [], []). We explain the above definition. Let τ 1, τ 2,..., σ 1, σ 2,... be meta-variables for types. First, we introduce basic types. Let Int, String, F loat,... be sets of integers, strings, floating point numbers,..., respectively. [x 1 : τ 1,..., x n : τ n ] is type assignments for variables x 1,..., x n (we use meta-variables x 1, x 2,..., y, z, w,... for variables). We assume elements in Int, String, F loat,... have types of int, string, float,..., respectively. Basic types are assumed to be already defined. Furthermore, we will allow user-defined types. GSN is mostly used at early stages of the system development such that it is crucial to support high-level abstract data types. In formal specification languages, these data types are supported. For instance, in the Z notation [15], the given types are introduced for user defined data types. We will also allow these types in our parameterised GSN term. In our context, any user-defined types can be declared using the following format: [T ype 1,..., T ype m ] For instance, [System, F unction] should be declared in the GSN term of Figure 2. As in basic types, we assume that users define sets of elements for their defined types. Let v 1,..., v n be elements either in Int, String,..., and user-defined sets. GSN has uninstantiated icon which signifies that certain variables are not instantiated. Variable instantiation is represented by [v 1 /x 1,..., v n /x n ], in which variables x 1,..., x n are instantiated with v 1,..., v n, respectively. We write ɛ/y if y is not instantiated with any elements. For example, [2/x, ɛ/y, hello /z] represents that x and z are instantiated with 2 and hello, respectively whereas y is not instantiated. Goals, evidences, and strategies are written in strings with/without variables Scoping Rules The scoping rules follow those in programming languages with block structure. The scope of a variable in a context begins with its associated goal and covers all nodes in the sub-trees. For example, Consider a GSN term (g, st, (T 1,..., T n ), c), and c = ([], [x : int], [10/x]). Then all occurrences of x in the GSN term should be given type int and be instantiated with 10. If the same variable already declared is declared again in a context associated with a sub-goal, the scope of the variable covers all nodes in the subtrees under the sub-goal Simple Checking Mechanism We show a simple checking mechanism for type correctness and scoping. We borrow the formalism of type systems for programming languages. For simplicity of our explanation, we assume the following (it is not difficult to extend the mechanism for general cases, but it is just tedious to write): User-defined types are only defined in the top level of the GSN term, and contexts only consist of type assignments and variable instantiations. Variables are only used in goals. Each variable is declared only once in the GSN term. This is similar to Static Single Assignment (SSA) form in compiler optimization [6]. We prepare the following. Let {τ 1,..., τ k } be the set of types including both basic types and user-defined types defined in the top level of the GSN term, and let S 1,..., S k be the sets of elements of type τ 1,..., τ k, respectively. S 1,..., S k are assumed to be pairwise disjoint. Let V 0 = S 1 S k. Let ɛ V 0 and V = V 0 {ɛ}. We use metavariable v for elements in V. We define a function Var(g) which returns the set of all variables used in g. We define a function CorrectType(σ, v) which returns true if 1 i k.σ = τ i v S i, or v = ɛ. We denote Γ for type environments which are mappings from variables to types. Γ is written as {x 1 : τ 1,..., x j : τ j }. We write Γ, x : τ for Γ {x : τ}. We denote domain of Γ as dom(γ). The type judgment is of the form Γ T.

5 This intend to mean that in a type environment Γ, T is well-typed. In particular, for a given GSN term T, if T, In T, each variable is assigned a value of the declared type, or, the variable is uninstantiated. In T, each variable is only used in its scope. The typing rules are shown in Figure 3. We omit the typing rules for T = (g, e) and T = (g, e, c), because they are almost the same as the ones for T = (g, ) and T = (g,, c), respectively. In this short paper, we omit the explanation of these typing rules and the proof. The type checking algorithm should be straightforward. 4. Prototype Implementation of Parameterised Expressions In D-Case Editor, we have prototyped parameterised expressions with types. Current implementation is limited that variables and types can only be declared in the top level of the GSN term. Declaration of variables and types are written in an XML file, as shown in Figure 4. In Figure 4, variables STATUS, CPU, USAGE, and MESSAGE are declared, and given types enum, int, double, and string, respectively. Furthermore, these types are given useful restrictions such that the value of CPU (this variable is intended as the CPU resource usage rate of the target system) is restricted within 0 100%. Users of D-Case Editor can assign values to these variables via the parameter setting window. If a user mis-assigned a value (e.g., 150 for CPU), then D-Case Editor reports the type error. As far as we know, there is not any assurance case editor which has such parameterised expressions and type checking mechanism. We plan to implement the type checking mechanism in Section Conclusion In this paper we have presented a new proposal towards parameterisation of patterns in GSN and to formalise a checking mechanism for type correctness and the scope of variables for them. Our parameterised patterns can include variables with types, which can detect anomalies of wrong instantiations, which help to validate that assurance cases obtained are free from type inconsistency. It can also help to develop a tool to automate type consistency check. One direction is to incorporate this proposal into standardisation efforts for assurance cases. We are planning to propose this to be included in the OMG ARM in order to promote wider adoption of this proposal. We already have started our activities for the goal [11]. References [1] [2] [3] Workshop on Assurance Cases: Best Practices,Possible Obstacles, and Future Opportunities, DSN 2004, [4] Robert Alexander, Tim Kelly, Zeshan Kurd, and John McDermid. Safety cases for advanced control software: Safety case patterns. Technical report, Department of Computer Science, University of York, [5] GSN contributors. DRAFT GSN standard version 1.0, [6] Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck. Efficiently computing static single assignment form and the control dependence graph. TOPLAS, 13(4): , Oct [7] European Organisation for the Safety of Air Navigation. Safety case development manual. European Air Traffic Management, [8] Object Management Group. Argument metamodel (ARM). OMG Document Number Sysa/ [9] Tim Kelly and John McDermid. Safety case patterns - reusing successful arguments. In IEE Colloquium on Understanding Patterns and Their Application to System Engineering, [10] Tim Kelly and Rob Weaver. The goal structuring notation - a safety argument notation. In Proc. of the Dependable Systems and Networks 2004, Workshop on Assurance Cases, [11] Yutaka Matsuno, Kenji Taguchi, and Hiroki Takamura. Standardization of GSN patterns in OMG sysa PTF. System Assurance Task Force, OMG Technical Meeting, September [12] Yutaka Matsuno, Hiroki Takamura, and Yutaka Ishikawa. A dependability case editor with pattern library. In Procs. IEEE 12th International Symposium on High-Assurance Systems Engineering (HASE), pages , [13] Railtrack. Yellow book 3. Engineering Safety Management Issue3, Vol. 1, Vol. 2, [14] Robert Andrew Weaver. The Safety of Software - Constructing and Assuring Arguments. PhD thesis, Department of Computer Science, University of York, [15] Jim Woodcock and Jim Davies. Using Z: Specification, Refinement and Proof. Prentice Hall, 1996.

6 Var(g) Dom(Γ) Γ (g, ) c = ([x 1 : σ 1,..., x m : σ m], [v 1/x 1,..., v m/x m]) {x 1,..., x m} dom(γ) Var(g) Dom(Γ) {x 1,..., x m} 1 i m.correcttype(σ i, v i ) Γ (g,, c) Var(g) Dom(Γ) Γ T 1,..., Γ T n Γ (g, st, (T 1,..., T n)) c = ([x 1 : σ 1,..., x m : σ m ], [v 1 /x 1,..., v m /x m ]) {x 1,..., x m } dom(γ) Var(g) Dom(Γ) {x 1,..., x m } 1 i m.correcttype(σ i, v i) Γ, x 1 : σ 1,..., x m : σ m T 1,..., Γ, x 1 : σ 1,..., x m : σ m T n Γ (g, st, (T 1,..., T n), c) Figure 3. Typing Rules <?xml version="1.0" encoding="utf-8"?> <!-- all element names and attributes are case sensitive --> <datatype> <parameter name="status" type="enum"> <items> <item value="normal"/> <item value="error"/> <item value="running"/> <item value="satisfied"/> </items> <parameter name="cpu" type="int"> <range min="0" max="100"/> <parameter name="usage" type="double"> <range min="0.00" max="999.99" digit="2" inc="0.02" /> <parameter name="message" type="string"> <length min="0" max="20"/> </datatype> Figure 4. Variables and Type Declarations XML file for D-Case Editor