当前位置:首页 >> >>

An Object-Based Approach to Modelling and Analysis of Failure Properties

An Object-Based Approach to Modelling and Analysis of Failure Properties
Reactor Engineering Division, \Jozef Stefan" Institute, Ljubljana, Slovenia 2 Department of Computing Science, University of Newcastle upon Tyne, United Kingdom

M. Cepin1, R. de Lemos2, B. Mavko1 , S. Riddle2, A. Saeed2

In protection systems, when traditional technology is replaced by software, the functionality and complexity of the system is likely to increase. The quantitative evidence normally provided for safety certi cation of traditional systems cannot be relied upon in software-based systems. Instead there is a need to provide qualitative evidence. As a basis for the required qualitative evidence, we propose an object-based approach that allows modelling of both the application and software domains. From the object class model of a system and a formal speci cation of the failure properties of its components, we generate a graph of failure propagation over object classes, which is then used to generate a graph in terms of object instances in order to conduct fault tree analysis. The model is validated by comparing the resulting minimal cut sets with those obtained from the fault tree analysis of the original system. The approach is illustrated on a case study based on a protection system from the Nuclear Industry.


Keywords: safety analysis, object-oriented modelling, fault tree analysis

1 Introduction
Increasingly traditional technology (hydraulic, pneumatic, electronic) is being replaced by software in process control systems. A typical consequence is that the functionality, and hence complexity, of the software-based system tends to increase, making the system harder to certify as assurance must be provided that the overall system risk is not increased. Evidence for certi cation is normally provided by conducting safety analysis. The quantitative evidence normally provided for traditional systems cannot be relied upon in software-based systems, due to the di culty of obtaining estimates of failure rates. Instead developers will need to place greater reliance on qualitative evidence. The object-based approach we propose begins with a model of an original system implemented in conventional technology, supported by the results of traditional safety analysis. The speci cation is used to derive an abstract object model which is independent of the technology in which it may be implemented. Safety analysis conducted on this model provides the required qualitative evidence that risk has not increased. It also establishes criteria for assessing and certifying the software to be developed, by providing a speci cation which re ects the failure properties of the original system.

2 Method description
The method proposed in this paper consists of a set of techniques from the software and application domains which are used to model the structure and behaviour of the existing system, and to conduct safety analysis. The result of the method is a formalised fault tree which can be directly compared with one produced for the original system. The starting point for the method is a functional model of the original system, and its fault tree with resultant minimal cut sets. The method then proceeds as follows: 1

Object class model of system structure. The original system is analysed and, using the no-

tation of the object view of OMT 5], an object class model is produced which represents the structure of the system. Formal de nition of class structure and behaviour. For each object class, its behaviour and structure is formally speci ed using a modi ed form of interactor 2]. Instead of employing operational techniques (e.g. statecharts) to express the dynamic view of OMT, we employ an axiomatic notation 1]. Causal analysis of object class model. From the object class model and interactor speci cations, a causal model is derived for the propagation of failure behaviours through object classes. This step results in a graph of failure propagation over object classes which is termed an impact structure (modi ed from the form in which it appears in 7]). Fault tree instantiation. The graph of failure propagation over object classes can then be instantiated for a particular top event and used as a basis to build a fault tree over object instances. Minimal cut sets comparison. Comparing the minimal cut sets from the fault tree derived from the impact structure with the minimal cut sets derived from the original system, the validity of the object class model can be assessed: if any new causes are included in the cut sets then safety can be a ected 10]. The techniques used in the method are established techniques employed in the elds of software engineering (OMT and rst order predicate logic) and safety analysis (fault tree analysis and failure mode and e ect analysis), and novel techniques for safety analysis (impact structure). The paper illustrates the method outlined above by introducing as a case study a protection system for a Nuclear Power Plant. We begin by providing an overview of the system itself, and then go through each step in the method to perform the modelling and analysis of the case study.

3 ESFAS case study description
The case study system is the Engineered Safety Features Actuation System (ESFAS) employed as part of the protection system in a Nuclear Power Plant 8]. The system monitors parameters in the plant and, in the event of abnormal plant conditions, activates Engineered Safety Features, for example a safety injection signal. These safety features maintain the safety of the reactor by providing core cooling, so reducing the damage to fuel and fuel cladding, and preventing the release of radioactive materials. The ESFAS initiates a safety injection signal if the value of one or more of the parameters (pressurizer pressure, steam line pressure, containment pressure) exceeds a de ned safety limit during normal plant operation. The signal can also be actuated manually. The ESFAS consists of three or four redundant analog channels to measure each of the diverse pressure parameters, and two digital trains employing solid-state logic to vote on the actuation of a safety signal in the applicable conditions. Redundancy is employed to ensure that no single failure can prevent actuation: only two out of the four channels are needed to provide an actuation signal. This is known as 2/4 voting, or 2/3 when there are only three channels. 2/4 voting is used when the same parameter is also used for control functions. Each digital train is capable of producing independently a safety injection signal.

3.1 Structure of the ESFAS


The resolution of modelling is selected so that only one parameter, measured on four channels, is monitored. The system for our purposes consists of two redundant trains, four redundant channels and two manual switches. The case study system is referred to as ESFAS SI Small , the small version of the ESFAS Safety Injection system which is fully developed in 9]. The block diagram presented in Figure 1 represents the functional model of the system.
ESFAS_SI_Small Train_A CH1 CH2 CH3 CH4 Train_B Man_Act_B Train_Logic_ A Man_Act_A Sum_A

3.2 ESFAS Case study simpli cations

Train_Logic_ B


Figure 1: ESFAS SI Small Block Diagram

4 Case study application
Having provided an overview of the system we now illustrate the proposed method in more detail. We begin by forming an object class model of the structure of the system. We use the notation from the object view of OMT for our object class model, which shows the objects in the system and their relationships. The object class model is formed by: identifying object classes - examining components of the system and abstracting common entities; identifying associations - examining structural and inheritance relationships between object classes, which leads to a hierarchical diagram of aggregation and specialisation of object classes. The resulting object class model for the case study is shown in Figure 2. This model decomposes ESFAS SI Small into an aggregation (signi ed by a diamond) of Channel and Train classes. The numbered black circles on the arcs signify multiplicity: there are four channels and two trains. The Channel has an attribute, or state variable, which is the value of the setpoint for that channel (a constant). From the object class model we now go on to formally specify the structure and behaviour of the object classes of the system. An interactor 1, 2] provides a formal axiomatic representation of the structure and behaviour of an object class. It is divided into declarations and predicates in a similar way to a Z schema 4]. Table 1 is an interactor for the ESFAS SI Small class. The declarations consist of a composed of eld (de ning the structure) which says that the object class consists of two instances of Train and an indexed sequence of Channel s. The 3

4.1 Object class model of system structure

4.2 Formal de nition of class structure and behaviour


4 Channel setpoint

2 Train



Manual Actuation

Figure 2: ESFAS SI Small Object Class Diagram
interactor ESFAS SI Small

composed of:

train A; train B chann

constants: setpoint variables: input variables:

Train seq Channel

Pressure setpoint Pressure input readings Manual actuation inputs ESFAS actuation signals Pressure is high if and only if at least two channel setpoints are exceeded

reading manual A; manual B

output variables: esfas A esfas B state variables: high pressure invariant: structure:


seq R


high pressure , (9 i ; j 2 f1:::4g (i 6= j ) ^ (reading (i ) > setpoint ) ^ (reading (j ) > setpoint ))
8 i 2 f1:::4g:chann (i ):reading

= reading (i ) ^ train A:voters (i ) = chann (i ):channel signal ^ train B :voters (i ) = chann (i ):channel signal esfas A = train A:vote esfas B = train B :vote manual A = train A:manual act manual B = train B :manual act

behaviour: normal:
^ ((high

((high pressure _ manual A) , esfas A) pressure _ manual B ) , esfas B )

_ _

(: high pressure ^ ((: manual A ^ esfas A) _ (: manual B ^ esfas B )) (high pressure ^ (esfas A ^ : esfas B )) _ (: esfas A ^ esfas B ) (high pressure ^ (: esfas A ^ : esfas B )) _ (manual A ^ : esfas A) _ (manual B ^ : esfas B )

An actuation signal is produced if and only if pressure is too high, or the relevant manual actuation is present. An actuation signal is produced despite no automatic or manual signal { spurious actuation Benign failure condition - only one actuation signal is produced Failure to produce actuation signal when needed { critical failure

Table 1: Interactor for object class ESFAS SI Small 4

indexed sequence is an abstraction of an array. Constants and variables are dealt with next: each declaration gives name, type and an optional comment for variable listed. The predicates consist of an invariant, a structure eld de ning how sub-classes communicate (via input and output variables) and how these variables relate to the inputs and outputs of the object class being speci ed in the interactor, and a behaviour eld which de nes the possible behaviour modes of the object class. In terms of the variables de ned in the interactor, the requirements that the system must satisfy can be summarised as follows: 1. Whenever the high pressure threshold is exceeded on at least two channels, at least one of the trains must generate a safety injection signal: high pressure ) (esfas A _ esfas B ) 2. The safety injection signal on each train can be independently actuated by a manual switch: (manual A ) esfas A) ^ (manual B ) esfas B ) 3. The injection signal should not be activated spuriously: (esfas A ) high pressure _ manual A) ^ (esfas B ) high pressure _ manual B ) Disjunction of the above requirements characterises the normal behaviour of ESFAS SI Small , speci ed in the interactor (Table 1) as ((high pressure _ manual A) , esfas A) ^ ((high pressure _ manual B ) , esfas B ) A consequence of the normal behaviour is that high pressure ) (esfas A ^ esfas B ). The normal behaviour satis es all the requirements. Failure behaviours are identi ed either by negating the normal behaviour of the object class or by applying the FMEA technique to identify possible failure behaviours of the object class 6]. By negating the normal behaviour predicate for ESFAS SI Small , we obtain (: high pressure ^ (: manual A ^ esfas A) _ (: manual B ^ esfas B ) _ (high pressure ^ (: esfas A _ : esfas B )) _ (manual A ^ : esfas A) _ (manual B ^ : esfas B ) The rst line in this predicate is related with spurious generation of an actuation signal. The remaining lines are related with a combination of critical and benign failures (benign being the case when one train fails but the requirements are still satis ed). This can be rewritten to separate out the failure modes. The benign failure is speci ed as (high pressure ^ ((esfas a ^ : esfas b ) _ (: esfas a ^ esfas b ))) and critical failure is speci ed as (high pressure ^ (: esfas a ^ : esfas b )) _ (manual a ^ : esfas a ) _ (manual b ^ : esfas b ) Each of these failure conditions is represented by a failure mode (spurious, benign or critical) in the behaviour of the interactor. The method de nes an interactor for each object class in the model (Train, Train Logic, Sum, Manual Actuation, Channel ). The Channel is an example of a primitive object class, which is speci ed by the interactor in Table 2. The failure behaviour is obtained from the negation of the normal behaviour in the same way as above: in this case there is no benign failure. 5

interactor Channel

constants: setpoint R variables: input variables: reading R output variables: channel signal B behaviour: normal:

A channel has a constant setpoint pressure value channel output A signal is produced by the channel whenever the input reading exceeds the setpoint. Critical failure of the channel: no signal produced despite input reading exceeding setpoint Spurious signal produced by channel when setpoint is not exceeded

setpoint ) , channel signal setpoint ) ^ : channel signal ) setpoint ) ^ channel signal )


((reading ((reading

Table 2: Interactor for object class Channel

4.3 Causal analysis of object class model

In this section, we describe a systematic method for the derivation of a graph of failure propagation over the modelled object classes which provides the basis for the analysis of causes and consequences of failures. The graph is known as the impact structure 7] and is derived from the information provided within the object class model, and the interactor speci cations. The components of an impact structure are nodes which represent object classes and arrows (connecting classes) which represent an impacts relation between classes. An impacts relation exists between two classes, when the behaviour of one a ects the other. There are two types of impacts relations, impacts between sub-classes of a common aggregate class (intra-impacts) and impacts between a sub-class and its aggregate class (inter-impacts). is depicted by a solid arrow connecting A B to A C . inter-impacts For class A and sub-class A B an inter-impact relation exists if A B impacts A, and is depicted by a broken arrow connecting A B to A.
: : : : :

intra-impacts For classes A B and A C an intra-impact relation exists if A B impacts A C , and
: : : :

There are three ways of composing impacts:

n-impacts For two object classes A and B , B impacts A with multiplicity n if, according to the

interactor speci cation, at least n instances of B must fail in order to impact an instance of A. An n-impacts is represented by annotating the arrow with a circle containing the particular number n . and-impacts For object classes A B and C , instances of both B and C must fail in order to impact an instance of A. An and-impacts is represented by linking the arrows involved in the relation with a symbol. or-impacts For object classes A B and C , instances of either B or C must fail in order to impact an instance of A. An or-impacts is represented by linking the arrows involved in the relation with a symbol.
; ;

The method for generating an impact structure is a three stage process, de ned as follows.










Manual Actuation


Manual Actuation







Figure 3: Impact structure for case study. (a) impact structure for the ESFAS SI Small class, (b) impact structure for Train subclass, (c) complete impact structure for the ESFAS SI Small .

Stage 1: Determine Impacts

The impacts of an aggregate class are derived by an examination of the composed of v and structure elds on an interactor. 1. Intra-impacts. A solid arrow is drawn between any two object classes A B if the behaviour of one object class can a ect the other, as speci ed in the structure eld of the interactor for the aggregate object class. 2. Inter-impacts. A broken arrow is drawn between any two object classes A B and A if A has an output de ned in terms of an output of A B
; : ;

Stage 2: Simpli cation of Impacts

Stage 3: Composition of Impacts

The impacts structure obtained from Stage 1, can be simpli ed by the deletion of arrows and nodes. Firstly, redundant arrows are deleted by examining the transitive closure (impacts+); basically if the removal of an impacts relation will not change impacts+, the corresponding arrow is deleted. Secondly, nodes are deleted by substituting the impact structure of an aggregate class for the aggregate. After the substitution, those components with an impacts relation to the aggregate class will inherit the impacts of that aggregate. The composition of the impacts obtained from Stage 2, can be identi ed in two steps. 1. Multiple composition. When there are multiple instances of a class that impact another class, the interactor speci cations are examined to determine the multiplicity 2. Logical composition. When more than one class participates in an impact relation with another class, the interactor speci cations are examined to determine if the behaviour corresponds to an or-impacts or an and-impacts.

Figure 3 shows the evolution of the impact structure for the ESFAS SI Small case study. Figure 3.a illustrates the impact structure for the class ESFAS SI Small , and depicts an interimpacts relation between the subclass Train and its aggregate class ESFAS SI Small , an intraimpacts relation between the subclasses Channel and Train , and a 3-impacts composition between Channel and Train . Figure 3.b illustrates an and-impacts between subclasses Manual 7

Actuation and Train Logic and subclass Sum , Figure 3.c illustrates a simpli ed structure derived by merging gures 3.a and 3.b, deleting the subclass Train . The impact structure provides a compact representation of failure propagation through object classes, thus facilitating the process for conducting a cause{consequence failure analysis of the object class model. Thereby providing an essential step to the systematic derivation of a fault tree from an object class model. This is achieved by instantiating the impact structure of the object class model, in order to obtain a structure representing failure propagation over object instances, from which a fault tree can be then generated.
This section presents how to derive a fault tree, for a particular failure event, from an impact structure of an object class model and the speci cation of interactors of the classes. A fault tree consists of nodes, which represent failure events, and gates (\and", \or", and numerical) which represent the causal relationships between the nodes 11]. The method for generating the fault tree from the impact structure and the speci cations of the interactors proceeds in two stages:

4.4 Fault tree instantiation

Stage 1: Generating the nodes
Some of the nodes of the fault tree are formed by instantiating the impact structure, thus producing a node for each object instance of the classes in the impact structure. The nodes related to aggregate classes are split into two nodes. A node representing the failure behaviour of the object instance, which is a primitive node, and another node representing those failure behaviours which are to be re ned at lower levels. For the particular failure event being analysed, each resulting node is annotated with the respective axiomatic speci cation of the behaviour from the relevant interactor, and when necessary modi ed to incorporate failure behaviours which are to be re ned.

Stage 2: Generating the gates
The gates of the fault tree are formed by referring to the composition of the impact (and, or, n ) and introducing the relevant gate. An \or" gate is also used to connect two nodes that were produced by splitting the node representing an aggregate class. Figure 4 shows the fault tree resulting from the application of this method to the ESFAS SI Small case study. The top node is annotated with the critical failure of the object class ESFAS SI Small , the failure event for this tree. The fault tree contains primitive nodes SUM A and SUM B representing the failure behaviours of the class Sum . Similiarly primitive nodes are provided for the failure behaviours of Manual Actuation , Train Logic, and Channel . The other intermediate nodes (generated from splitting an aggregate class) of the fault tree represent failure propagation from the primitive failure events to the top failure event. An example of an intermediate node is NO SIGN A, which represent the propogation of failures from lower levels when SUM A exhibits normal behaviour. There is an \and" gate joining the failure events assocaited with the two Sum instances, since the impact structure had an 2-impacts. The Channel s are connected by a numerical gate \ 3", since there are four instances and the impact structure had an 3-impacts. The fault tree produced directly from the original system model is shown in Figure 5. Both fault trees have been \pruned" for reasons of space. In order to validate that the failure properties of the object class model are consistent with the original system model, the minimial cut sets of their respective fault trees are compared 10, 3]. A minimal cut set of a fault tree is a sets of failure, such that if any event of the set occurs the top failure event occurs. For example, one of the minimal cut sets resulting from the fault tree generated from the impact structure: MAN ACT A, MAN ACT B, TRAIN LOGIC A, TRAIN LOGIC B. 8

ESFAS_SI_Small fails to activate
(high_pressure ^ (? esfas_A ^ ? esfas_B)) v (manual_A ^ ? esfas_A) v (manual_B ^ ? esfas_B) ESFAS_SI_SMALL

No Sum A signal
? sum_A.signal ^ (? train_logic_A.vote ^ manual_A.manual_signal) v (train_logic_A.vote ^ ? manual_A.manual_signal) NO_SUM_A_SIGN

No Sum B signal
? sum_B.signal ^ (? train_logic_B.vote ^ ? manual_B.manual_signal) v (train_logic_B.vote ^ manual_B.manual_signal) NO_SUM_B_SIGN

Sum A failure
(? sum_A.signal ^ (train_logic_A.vote v manual_A.manual_signal)) SUM_A

Sum A normal
(? sum_A.signal ^ ? train_logic_A.vote ^ ? manual_A.manual_signal) NO_SIGN_A

(same form as NO_SUM_A_SIGN)

Manual Actuation A switch fails
manual_A.manual_switch ^ ? manual_A.manual_signal MAN_ACT_A

No Train_Logic_A signal
? train_logic_A.vote


Train_Logic A failure
(exists i,j.i<>j ^ chann(i).channel_signal ^ chann(j).channel_signal) ^ ? train_logic_A.vote TRAIN_LOGIC_A

Train_Logic A normal
(exists i,j.i<>j ^ chann(i).channel_signal ^ chann(j).channel_signal) ^ ? train_logic_A.vote AN_CH_FAILURES >=3

Channel 1 fails
((chann(1).reading >= setpoint) ^ ? chann(1).channel_signal) CH1

Channel 2 fails
((chann(2).reading >= setpoint) ^ ? chann(2).channel_signal) CH2

Channel 3 fails
((chann(3).reading >= setpoint) ^ ? chann(3).channel_signal) CH3

Channel 4 fails
((chann(4).reading >= setpoint) ^ ? chann(4).channel_signal) CH4

Figure 4: Fault tree generated from impact structure










(same form as SMALL_SI_A)


















Figure 5: Fault tree generated from original model


If the minimal cut sets are equivalent, we can conclude that the new model is valid with respect to the original system model. If not, the minimal cut sets will either be overlapping or (in the worst case) disjoint. If there is an overlap the reasons must be investigated { a new failure may have been created, or a failure from the original model may have been removed, in the case of disjoint cut sets imply totally incompatible models. For this case study, the minimal cut sets resulting from both fault trees are identical, which serves to validate the model.

5 Conclusions
The proposed method tackles the problems encountered by application domain engineers, when investigating the feasibility of replacing a traditional system with a software based system. The method provides qualitative evidence that a software based system can be developed which exhibits the same failure properties as the traditional system. Thereby, providing assurance that the software will not increase the risk posed by the system. The method has been applied to a larger case study 9], which demonstrates the scalability of the work. Further work includes formalising causality and investigation of applicability of other safety analysis techniques.

The work reported in this paper was carried out as part of the EC Copernicus Joint Research Project ISAT (Integration of Safety Analysis Techniques for Process Control Systems).

1] R de Lemos, B Fields, and A Saeed. Analysis of safety requirements in the context of system faults and human errors. In Proc. IEEE International Workshop on Systems Engineering of Computer Based Systems, pages 374{381, Tucson, Arizona, March 1995. 2] D Duke and MD Harrison. Abstract interaction objects. Computer Graphics Forum, 12(3):25{ 36, 1993. 3] J Gorski and A Wardzi~ski. Formalising fault trees. In Proc. Safety-Critical Systems Symn posium, pages 310{327, Brighton, United Kingdom, 1995. 4] B Potter, J Sinclair, and D Till. An Introduction to Formal Speci cation and Z. International Series in Computer Science. Prentice-Hall International (UK) Ltd, United Kingdom, 1991. 5] J Rumbaugh, M Blaha, W Premerlani, F Eddy, and W Lorenson. Object-Oriented Modelling and Design. Prentice-Hall International Inc., New Jersey, 1991. 6] A Saeed, R de Lemos, and T Anderson. An approach for the risk analysis of safety specications. In Proc. 9th Annual Conference on Computer Assurance (COMPASS '94), pages 209{221, Gaithersburg, MD, June 1994. 7] A Saeed, R de Lemos, and T Anderson. Safety analysis for requirements speci cations: Methods and techniques. In Proc. 14th International Conference on Computer Safety, Reliability and Security: SAFECOMP '95, pages 27{41, October 1995. 8] M Cepin and B Mavko. Identi cation and preparation of case studies. Technical Report TR ISAT 96/8, Jozef Stefan Institute, Ljubljana, Slovenia, June 1996. 9] M Cepin and S Riddle. Object modelling and safety analysis of Engineered Safety Features Actuation System. Technical Report TR ISAT 96/11, University of Newcastle upon Tyne, United Kingdom, December 1996. 11

10] M Cepin and A Wardzi~ski. On integration of probabilistic and deterministic safety analyn sis. In Proc. 3rd Regional Meeting: Nuclear Energy in Central Europe, Portoroz, Slovenia, 1996. (To appear. Also Technical Report TR ISAT 96/9, Jozef Stefan Institute, Ljubljana, September 1996). 11] WE Vesely, FF Goldberg, NH Roberts, and DF Haasl. Fault tree handbook. NUREG 0492, US NRC, Washington, 1981.


毕业设计 外文翻译 CAN总线系统的实时对象调用
which allows the convenient modelling of hardware...an object-based approach where objects encapsulate ...In this case they fail to guarantee anything. A...
Genre-based approach
Genre-based approach_文学研究_人文社科_专业资料。Genre-based Approach to ...The language focus displays a text to students for them to analyze and so...
优秀论文 未经允许 归档资料 切勿外传 The Application of Task-based Approach ...That is, pre-task, task, planning, report, analysis, practice. In the ...
...to 5 are based on an interview. At the end of th...
The older students are pretty good at modelling and supporting the younger ...I use a project/performance-based approach where technology is integrated ...
irrigation districts. It is based on the solution of an ...
Novais $ 31.50 modelling framework Show preview ...Multistage operation-based approach 5.1.3. Test ...Analysis of specific OP literature 5. Conceptual ...
UML-based tools are often used for J2EE/.NET applic...
UML-based tools are often used for J2EE/.NET...analysis and design,both because UML’s object ...technique that’s (70) to the OO approach.(66...
Failure Properties of Fractured Rock Masses as ... the use of an alternative approach based on ...A standard dimensional analysis of this problem ...
...Task-based Approach to Teaching Language and Cul...
Integrating Task-based Approach to Teaching Language and Culture_初二英语_英语_初中教育_教育专区。探讨任务型教学法在大学英语教育中的应用...
On Application of Task-based Approach to Reading Teaching in ...
On Application of Task-based Approach to Reading Teaching in English Classes_英语学习_外语学习_教育专区。英语专业毕业论文On Application of Task-based ...
A Process—based Approach to Teaching Listening
A Process—based Approach to Teaching Listening_英语学习_外语学习_教育专区。龙源期刊网 http://www.qikan.com.cn A Process—based Approach to Teaching ...

All rights reserved Powered by 甜梦文库 9512.net

copyright ©right 2010-2021。