- Email: [email protected]
FROM STRUCTURAL TO FUNCTIONAL MODELS OF COMPLEX SYSTEMS
FROM STRUCTURAL TO FUNCTIONAL MODELS OF COMPLEX SYSTEMS Marta Capiluppi ∗,1 Marcel Staroswiecki ∗∗
∗ Center for Research on Complex Automated Systems (CASY) “Giuseppe Evangelisti”, DEIS, Department of Electronic, Computer Science and Systems, University of Bologna, Viale Risorgimento 2, 40136 Bologna, Italy ∗∗ SATIE UMR CNRS 8029 Ecole Normale Sup´erieure de Cachan 61, avenue du Pr´esident Wilson F-94235 Cachan cedex, France
Abstract: This paper addresses functional modelling of complex distributed systems via an objective and automatic procedure. The presented methodology uses the structural representation of the system and the notion of causality in structural graphs. The result of the procedure is a functional tree representing c 2006 IFAC hierarchical relations among the system functionalities. Copyright Keywords: Fault tolerance, Structural properties, Tree structures, Complex systems, System models.
1. INTRODUCTION
different possibilities the system still has (or has not) to achieve its objectives. As a consequence, there is need for tools that allow to build and to handle functional models of distributed systems under fault tolerance specifications. A functional model is a structured representation of the activities of a system. Due to the rather loose definition of terms like “activities”, “objectives”, “functionalities”, such models are not easy to develop on an objective basis. Moreover, in distributed (large scale) systems, the global functions are often decomposed into sub-functions associated with different subsystems. This allows the control designer to find a hierarchical structure of objectives which simplifies the analysis of the system, as well as the synthesis of a controller (Bonivento et al., 2005). Many functional modelling approaches have been proposed, giving rise to some standardization, e.g. (Bravoco et al., 1975), a methodology to design functional models through a hierarchical vision of the process, or the IEC Standard 61499
Control engineers are faced with increasingly complex, safety critical, distributed systems. Fault tolerance is needed in order to achieve the system objectives in fault situations, or if this turns out to be impossible, to assign new (achievable) objectives to avoid catastrophic behaviors. The design of Fault Tolerant Systems (FTS) has motivated many recent works such as (Blanke et al., 2003), (Marconi and Paoli, 2005). Most of them use the quantitative system behavior model, for example, state and output equations, in order to design automatic procedures by which faults can be handled. However, integrating these approaches in complex distributed systems, which are often only partially automated, needs also the development of a decision support system capable of analyzing faulty situations from a functional point of view, to inform the operators with the 1
Corresponding author Marta [email protected].
Capiluppi,
E-mail:
1276
(3) The objective P is what the designer wants to obtain. It is a set of properties that must be true in order for the system functionalities to be available to the system user, for example stability, controllability, observability, disturbance attenuation, minimal energy consumption, minimum time for achieving a given task, etc.
(Lewis, 2001); useful tools to represent functional models are the so-called functional trees (Andrews and Moss, 2002). However there is no methodology to build a functional model which is complete and non subjective. This work proposes to build the functional tree needed by the functional view of fault tolerance, by using structural analysis, which describes the system in a univocal way. The paper is organised as follows: Section 2 briefly recalls the Fault Tolerance Problem; Section 3 addresses the problem of functional modelling; in Section 4 the methodology to build functional trees from structural models is described. The proposed procedure is exemplified throughout the paper with the use of a simple example.
The nominal design problem is to find control / estimation algorithms such that system Σ0 achieves property P . The FT design problem is to find control / estimation algorithms such that system Σi achieves property P whatever the fault i ∈ F.
3. THE FUNCTIONAL VIEW OF FAULT TOLERANCE
2. THE FAULT TOLERANCE PROBLEM Fault Tolerance (FT) problems are specified by three components (see (Staroswiecki and Gehin, 2001), (Staroswiecki, 2002a), (Blanke et al., 2003)): (1) a system Σ, (2) a set of faults F , (3) a set of properties P . (1) The system Σ is a set of interconnected components. The behavior of each component is described by a set of variables and a set of constraints that apply to those variables (Staroswiecki, 2002b); the behavior of the whole system is the concatenation of the local behaviors taking into account interconnections. Variables are internal states x, control inputs u or disturbances d, sensor outputs y, while constraints are (static or dynamic) equalities that apply to the variables, e.g. using the classical state space representation : x˙ = f (x, u, d, t)
(1)
y = g(x, u, d, t)
(2)
(2) The faults F change the system constraints. Let Σ0 be the set of constraints that describe the healthy system, and Σi , i = 1, 2, ..., those that describe the system when fault i ∈ F is present. It is assumed that the healthy and the faulty systems are all described using the same set of variables, but faulty situations imply constraints that are different. Faults in process components and actuators would typically change a subset of the state equations (1) Healthy → Fault i ∈ F x˙ = f0 (x, u, d, t) → x˙ = fi (x, u, d, t) while sensor faults would change a subset of the measurement equations (2). A healthy (nominal) system Σ0 being given, analysis approaches like fault trees, FMEA, provide a list of faults that are likely to occur i ∈ F among which only a subset F ⊆ F constitute the specification of the FT problem.
1277
Integrating FT issues in complex systems, where human operators are present, needs the development of a decision support system using a simple and easily understandable language. The way of doing this relates to functional analysis, as described in (Staroswiecki and Gehin, 1999), (Lunze et al., 2001). In the following the terms functionality and service will be used indifferently, with the meaning of “system/subsystem/component behaviour to accomplish a task”. Complexity often calls for the decomposition of the whole system, associated with global functionalities (or services), into subsystems (i.e. subsets of components), associated with local ones. Sensors, actuators, process components are at the field-level. Higher level components can be built from the aggregation of lower level ones. The field level services offered by the elementary components are integrated in order to provide a higher level service. The functional AND tree is a classical representation of services hierarchy. It is a hierarchical graph where nodes are services, and edges exist between a node σ and its followers σ ′ ∈ F (σ) at the next lower level if and only if the availability of service σ needs - and is implied by - the availability of all of the services in F (σ). The functional tree represents necessary and sufficient relationships among functionalities, i.e. necessary and sufficient conditions for the properties on the variables to be satisfied. For this reason it is a powerful tool for control and analysis of distributed systems, since it lets the designer consider the different levels of the tree independently and then exploit the distributed nature of the system, for example controlling each level independently or for FDI and Fault Tolerance considering the effects of faults at each level. A top-down analysis of the tree shows the necessary conditions for a higher level property to be achieved, each level of the tree reports the necessary functionalities for the immediately higher
different exclusive versions that are available to perform it. This means that the AND/OR functional tree introduces the redundancy relations between components. For example if σ1 and σ2 are two nodes of the tree connected with an OR gate to the upper level node σ ′ this means that σ1 and σ2 are two different versions of services through which it is possible to obtain σ ′ . As a consequence, when faults occur such that version σ1 is no longer available, the system operation can be continued thanks to version σ2 .
level functionality to be fulfilled. A bottom-up analysis shows the sufficient conditions for a functionality to be reached. Note that for each node σ all its followers σ ′ ∈ F (σ) must be considered, because of the AND operator that applies to them. Designing the functionality tree can therefore be done by starting from the top functionality and finding all the necessary conditions for it to be available. These conditions can be very easily linked to properties that the controlled system must fulfill. The relation between system properties and services is straightforward. Assume a given subsystem, which is formed by the interconnection of a set of components, is in charge of providing some functionality, for example a set of sensors S provides a set of signals y by which a vector z is estimated. Let the notation O(z/S) stand for the property “z is observable by the set of sensors S”. O(z/S) is obviously a necessary condition for the estimation service to exist. For each service σ provided by a subsystem C let z be a functional of the state and let P be a property such that
4. BUILDING FUNCTIONAL TREES FROM STRUCTURAL GRAPHS The structural model of a system is a qualitative representation of its behavior model, that is objective (it represents the physical constraints that apply to the system components) and easy to obtain (it does not need any parameter identification). Roughly speaking, the structural model represents the links between the system variables that are imposed by the system components. Note that those components have been selected or designed so as to fulfill some given functional goal, which can be translated into properties that some system variables must satisfy. Therefore, it is advisable to take advantage of the structural model to automatically derive one or more functional AND/OR trees from the system structural graph, according to the main functionalities represented by the graph.
P (z/C) =⇒ σ is available. +
Let Γ ⊆ C be a subset of components. Let 2C be the collection of all subsets of C such that +
P (z/Γ) ⇐⇒ Γ ∈ 2C . Therefore, there is a possibility of providing the service σ by using any subset of components Γ ∈ + 2C , which means that different versions σΓ of the service can be designed, using different resources Γ. Let + N (σ) = 2C
4.1 The structural graph of a system Definition 1. The structural graph of a system is a bi-partite graph with two sub-sets of vertices, V : the system variables, and C: the system (static or dynamic) constraints. The set of edges E is defined by:
then, there are N (σ) different versions, that constitute a set v [σ] . Each version of that set is able to provide the service σ. Since only one can be run at time t, they must be ranked using an appropriate procedure (see (Staroswiecki and Gehin, 1998), (Staroswiecki et al., 1997), for details and comments). Assume that at time t there is only a subset Γ(t) ⊂ C of healthy components available, as the consequence of previous faults. The functionality σ is available as long as Γ(t) contains at least + one subset that belongs to 2C , i.e. as long as the set of versions v [σ] is not empty. Let N (σ, t) be the number of versions of σ available at time t (this number is called the redundancy degree of service σ). Since each node σ in the AND tree represents a service which, at time t, can be provided under N (σ, t) versions, the AND functional tree can be replaced by an AND/OR functional tree, where AND and OR nodes alternate : AND nodes display the lower level services that are all necessary for a higher level service to be available, and for each service, an OR node displays the
(v, c) ∈ E ⊆ V × C ⇐⇒ the variable v is an argument of the constraint c. The variables V are decomposed into known and unknown ones: V = K ∪ X. Known variables K are sensor outputs, reference inputs, controllers and observers outputs. To any constraint c ∈ C - resp. to any variable v ∈ V - is associated the set V (c) - resp. the set C(v) - of all the variables - resp. of all the constraints - such that ω ∈ V (c) ⇐⇒ (ω, c) ∈ E resp. γ ∈ C(v) ⇐⇒ (v, γ) ∈ E. Example. The tank system Consider the tank system represented in fig. 1.
1278
replacemen
4.2 Causality in structural graphs
u′ (t)
u(t)
From their definition, structural graphs are non oriented. Matchings do provide an orientation, which can be interpreted in causal terms.
qi (t)
h(t) qo (t)
Definition 2. A matching M on a bi-partite graph is a subset of E such that
uo (t)
Fig. 1. The tank system.
∀ (v, c) , (v ′ , c′ ) ∈ M : v 6= v ′ ∧ c 6= c′ . Given a matching M, different cases can be distinguished:
qo
qi
c3
c1 ˙ h
c2
c6
c′2
c7
h
uo u′
u
(1) |M | = min {|V | , |F |} : the matching is complete with respect to the variables (|V | < |F |) or to the constraints (|V | > |F |) or to both of them (|V | = |F |). A complete matching is maximal, which means that no matching of larger cardinality exists. (2) |M | < min {|V | , |F |} : the matching is not complete, it may be maximal or not.
k
c′5
c4 y
c8
c5
Fig. 2. Structural graph of the tank system.
Let (v, c) be an edge belonging to a matching: v is called the output of constraint c: v , o(c) , while V (c)\ {v} is the set of its inputs: V (c)\ {v} , I(c). The resulting orientation can be interpreted as a causality assignment : the output o(c) depends on the inputs I(c) therefore, for the output to enjoy some given property, the inputs must also satisfy some (other) property. Let {c1 , c2 , ...cq } be a subset of constraints (without repetition) such that
The system is controlled via an actuator acting on the throttling of the valve on the pipe providing the input flow. It has also a redundant actuator (with the corresponding valve and pipe) which is supposed not to act in nominal conditions but it can be used to reconfigure the system in case the nominal actuator fails. The system is also controlled by an actuator acting on the valve of the output pipe. Its behavior model is given by:
i = 1, 2, ...q − 1 : o(ci ) ∈ I(ci+1 ) The path c1 − o(c1 ) − c2 − o(c2 ) − ... − cq is an alternated chain between constraint c1 and constraint cq . A loop is a subset of constraints {c1 , c2 , ...cq } such that for any pair (ci , cj ) there is an alternated chain from ci to cj and another one from cj to ci . If no loop exists (see (Diestel, 2005)) a matching induces a hierarchy on the system structural graph as follows:
˙ h(t) = qi (t) − qo (t) qi (t) = αu(t) qi (t) = αu′ (t) p Output pipe c3 : qo (t) = k(t) h(t) Level sensor c4 : y(t) = h(t) Control algorithm c5 : u(t) = f (y) Control algorithm c5′ : u′ (t) = f (y) dh(t) ˙ Derivative constraint c6 : h(t) = dt Output valve c7 : k(t) = βuo (t) Output control c8 : uo (t) = fo (y) (3) where u, u′ and uo are the actuators outputs, h denotes the liquid level, qi and qo the flow into or out of the tank, while α and β are the valves constants. Each component introduces one constraint. The extra constraint c6 expresses the ˙ fact that h(t) is the derivative of the level h(t); we suppose to know initial conditions, so it is always ˙ possible to know h(t) from h(t) and viceversa. The structural graph of the tank system described by model (3) is depicted in fig. 2. Tank c1 : Input valve c2 : Input valve c2′ :
L0 = {v : ∄c : (v, c) ∈ M } L1 = {v : (v, c) ∈ M =⇒ V (c)\ {v} ⊆ L0 } ... Lk = v : (v, c) ∈ M =⇒ V (c)\ {v} ⊆ ∪i=k−1 Li i=0 The meaning of the above definition of the level sets is the following: • L0 is the set of variables that are not matched, • L1 is the set of variables that are matched to constraints all the inputs of which belong to L0 , • L2 is the set of variables that are matched to constraints all the inputs of which belong to L0 ∪ L1 , • etc.
1279
in any of these constraints, which can be written as v = ∨c∈C(v) o(c). (4)
Table 1. A possible matching for (3). ˙ h, qo ) (h,
(c1 , c3 , c6 ) c2 c′2 c4 c5 c′5 c7 c8
y
1
1
u
1
1 1 1
1
u′
qi
1
1
1 1
1
uo
1
1 1
1
k
Now, if v is matched in constraint c ∈ C(v), then for v to exhibit the property Pn (v) it is necessary that the subset of variables I(c), inputs of constraint c, exhibit some (other) property, say Pn−1 . This is written as
1
Table 2. A possible matching for (3). ˙ h, qo ) (h,
(c1 , c3 , c6 ) c2 c′2 c4 c5 c′5 c7 c8
y
1
1
u
1
1 1 1
1
u′
qi
1
1 1
1
1
uo
1
• v is connected with all constraints c ∈ C(v) by an OR node. Indeed, property Pn (v) can be obtained by a causal link associated with any matching of the set described by (4), • each constraint c ∈ C(v) is connected to its input variables I(c) by an AND node. Indeed, the output v = o(c) can have property Pn only if all the variables I(c) exhibit property Pn−1 .
Table 3. A possible matching for (3). ˙ h, qo ) (h,
(c1 , c3 , c6 ) c2 c′2 c4 c5 c′5 c7 c8
y
1
1
u
1
1 1 1
1
1
u′
qi
1
1
1 1
1
uo
k
1
1 1
(5)
With these considerations it is easily seen that a tree having variable v (which stands for the function that has to be performed) as root has the following properties:
1
1 1
1
∀w ∈ I(c) : Pn−1 (w). k
1
Then to obtain the AND-OR tree it is necessary to choose a root variable representing the main property the system must achieve and detect all the measure and control variables and find all possible matchings in which these variables are not matched (to give an ending point to the tree as explained above). Starting from the root variable the algorithm is: while There are constraints available for matching do for all variables z at level k do associate an OR node which concentrates all constraints available for matching in C(z) for all constraints γ ∈ C(z) do associate an AND node which concentrates all variables V (γ)\z. end for end for end while Level k + 1 is built on all variables that are concentrated by AND nodes.
Example. After graph condensation (see (Diestel, ˙ h, qo it 2005)) to eliminate the physical loop h, is possible to build some possible matchings for system 3. They are reported in tables 1, 2 and 3. Note that some constraints are not matched, and therefore the matchings are neither maximal nor complete wrt the variables or the constraints.
4.3 From structural graphs to functional trees In this section an automatic procedure is presented to obtain a functional tree starting from the structural graph of a system/subsystem. The approach is based on the idea that performing a given system function φn can be translated into providing some system variable v with a given property Pn (v), e.g. v is wanted to track a specific reference trajectory. Note that for each structural graph there can be many different main functionalities, each of them can be considered as a root of a tree. Moreover in the functional tree the leaves represent properties on physical components and among them there are sensors and actuators. The measure and control variables represent then basic functionalities related to sensors and actuators respectively. This means that in our representation measure and control variables will be the leaves of the tree. This would help in knowing when the tree ends and in knowing the starting point of the path to the root variable. Consider the set C(v) of all the constraints in which v is present. Obviously, v could be matched
The procedure ends when the non-matched variables are reached. Note that constraints available for matching are all constraints except those already used in higher levels. It is worth noting that the hierarchy obtained in this way is reflected by the hierarchy given by the level sets, in fact in set L0 all non-matched variables are reported and they will be at the bottom of the tree, variables in L1 are at the immediately upper level and so on until the root of the tree is reached. Even if the level sets give a first rough hierarchy to the system they are not sufficient to establish relations among all the variables. These
1280
Blanke, M., M. Kinnaert, J. Lunze and M. Staroswiecki (2003). Diagnosis and Fault Tolerant Control. Springer-Verlag. Bonivento, C., M. Capiluppi, L. Marconi and A. Paoli (2005). An integrated design approach to multilevel fault tolerant control of distributed systems. 16th IFAC World Congress. Bravoco, R.R., C. Fledmann, D. Ross and D. Thornhill (1975). Structured Analysis and Design Technique Authors Guide. SoftTech Book Product 3045, SoftTech, Inc. Waltham, MA. Diestel, R. (2005). Graph Theory. SpringerVerlag. Lewis, R.W. (2001). Modelling control systems using IEC 61499. Applying function blocks to distributed systems. The Institution of Electrical Engineers Publishing. London. Lunze, J., J. Askari-Marnani, A. Cela, P.M. Frank, A.L. Gehin, B. Heiming, M. Lemos, T. Marcu, L. Rato and M. Staroswiecki (2001). Three tank control reconfiguration. In Control of Complex Systems, editors Astr¨om, Albertos, Blanke, Isidori, Schaufelberg, Sanz. Springer, pp. 241-283. Marconi, L. and A. Paoli (2005). Fault tolerant control of large complex systems. Precongress full-day workshop, 16th IFAC World Congress. Prague, CZ. Staroswiecki, M. (2002a). Fault tolerance systems. In Fault Diagnosis and Fault Tolerant Control, editors P. M. Frank and M. Blanke, Encyclopedia of Life Support Systems (EOLSS). Eolss Publishers, Oxford, UK. Developed under the auspices of the UNESCO, [http://www.eolss.net]. Staroswiecki, M. (2002b). Structural analysis for fault detection and isolation and for fault tolerant control. In Fault Diagnosis and Fault Tolerant Control, editors P. M. Frank and M. Blanke, Encyclopedia of Life Support Systems (EOLSS). Eolss Publishers, Oxford, UK. Developed under the auspices of the UNESCO, [http://www.eolss.net]. Staroswiecki, M., A. L. Gehin and M. Bayart (1997). Faulty resources management in automation systems. IEEE SMC’97. Staroswiecki, M. and A. L. Gehin (1998). Analysis of system reconfigurability using generic component models. UKACC Control’98. Staroswiecki, M. and A. L. Gehin (1999). A formal approach to reconfigurability analysis / application to the three tank bechmark. In Proc. of European Control Conference, ECC’99. Staroswiecki, M. and A. L. Gehin (2001). From control to supervision. Annual Reviews in Control 25, 1–11.
relations are given by the logic gates (AND/OR) in the tree. The level sets are useful in case of big complex systems in which it is necessary to find out a first hierarchy among variables. This will help in finding the group of variables in the matching tables to establish relationships between variables and then build different parts of the tree separately. Example. The presented procedure is now applied to system 3. The main functionality of the system is to make level h reach a certain value h0 . Variable h is chosen as root but due to the loop condensation knowing the level h is equivalent to the knowledge of its derivative and to the knowledge of the output flow qo , this means that the functionality will be the same. Starting from the matchings in tables 1 and 2 and 3 and following the above presented procedure the tree represented in fig. 3 is obtained where it is possible to see that the two redundant actuator variables are related to the upper level variable with an OR gate. Moreover an analytical redundancy is presented here, because the knowledge of the main functionality can be achieved through the measure of the level. But both the knowledge of the inflow and of the output actuator are needed, that is the meaning of the AND gate.
5. CONCLUSIONS The topic addressed by this work is the functional view of fault tolerance using structural analysis, in order to build a functional model in a univocal way. This work is motivated by the fact that existing procedures to build functional models are not based on objective properties of the system in particular when dealing with distributed systems. The presented methodology allows the designer to build a hierarchical functional model of the system starting from its structural properties.
REFERENCES Andrews, J.D. and T.R. Moss (2002). Reliability and Risk Assessment. Professional Engineering Publishing. h
˙ qo h or
and
y uo
qi or
u
u′
Fig. 3. The tank functional trees.
1281
∗ Center for Research on Complex Automated Systems (CASY) “Giuseppe Evangelisti”, DEIS, Department of Electronic, Computer Science and Systems, University of Bologna, Viale Risorgimento 2, 40136 Bologna, Italy ∗∗ SATIE UMR CNRS 8029 Ecole Normale Sup´erieure de Cachan 61, avenue du Pr´esident Wilson F-94235 Cachan cedex, France
Abstract: This paper addresses functional modelling of complex distributed systems via an objective and automatic procedure. The presented methodology uses the structural representation of the system and the notion of causality in structural graphs. The result of the procedure is a functional tree representing c 2006 IFAC hierarchical relations among the system functionalities. Copyright Keywords: Fault tolerance, Structural properties, Tree structures, Complex systems, System models.
1. INTRODUCTION
different possibilities the system still has (or has not) to achieve its objectives. As a consequence, there is need for tools that allow to build and to handle functional models of distributed systems under fault tolerance specifications. A functional model is a structured representation of the activities of a system. Due to the rather loose definition of terms like “activities”, “objectives”, “functionalities”, such models are not easy to develop on an objective basis. Moreover, in distributed (large scale) systems, the global functions are often decomposed into sub-functions associated with different subsystems. This allows the control designer to find a hierarchical structure of objectives which simplifies the analysis of the system, as well as the synthesis of a controller (Bonivento et al., 2005). Many functional modelling approaches have been proposed, giving rise to some standardization, e.g. (Bravoco et al., 1975), a methodology to design functional models through a hierarchical vision of the process, or the IEC Standard 61499
Control engineers are faced with increasingly complex, safety critical, distributed systems. Fault tolerance is needed in order to achieve the system objectives in fault situations, or if this turns out to be impossible, to assign new (achievable) objectives to avoid catastrophic behaviors. The design of Fault Tolerant Systems (FTS) has motivated many recent works such as (Blanke et al., 2003), (Marconi and Paoli, 2005). Most of them use the quantitative system behavior model, for example, state and output equations, in order to design automatic procedures by which faults can be handled. However, integrating these approaches in complex distributed systems, which are often only partially automated, needs also the development of a decision support system capable of analyzing faulty situations from a functional point of view, to inform the operators with the 1
Corresponding author Marta [email protected].
Capiluppi,
E-mail:
1276
(3) The objective P is what the designer wants to obtain. It is a set of properties that must be true in order for the system functionalities to be available to the system user, for example stability, controllability, observability, disturbance attenuation, minimal energy consumption, minimum time for achieving a given task, etc.
(Lewis, 2001); useful tools to represent functional models are the so-called functional trees (Andrews and Moss, 2002). However there is no methodology to build a functional model which is complete and non subjective. This work proposes to build the functional tree needed by the functional view of fault tolerance, by using structural analysis, which describes the system in a univocal way. The paper is organised as follows: Section 2 briefly recalls the Fault Tolerance Problem; Section 3 addresses the problem of functional modelling; in Section 4 the methodology to build functional trees from structural models is described. The proposed procedure is exemplified throughout the paper with the use of a simple example.
The nominal design problem is to find control / estimation algorithms such that system Σ0 achieves property P . The FT design problem is to find control / estimation algorithms such that system Σi achieves property P whatever the fault i ∈ F.
3. THE FUNCTIONAL VIEW OF FAULT TOLERANCE
2. THE FAULT TOLERANCE PROBLEM Fault Tolerance (FT) problems are specified by three components (see (Staroswiecki and Gehin, 2001), (Staroswiecki, 2002a), (Blanke et al., 2003)): (1) a system Σ, (2) a set of faults F , (3) a set of properties P . (1) The system Σ is a set of interconnected components. The behavior of each component is described by a set of variables and a set of constraints that apply to those variables (Staroswiecki, 2002b); the behavior of the whole system is the concatenation of the local behaviors taking into account interconnections. Variables are internal states x, control inputs u or disturbances d, sensor outputs y, while constraints are (static or dynamic) equalities that apply to the variables, e.g. using the classical state space representation : x˙ = f (x, u, d, t)
(1)
y = g(x, u, d, t)
(2)
(2) The faults F change the system constraints. Let Σ0 be the set of constraints that describe the healthy system, and Σi , i = 1, 2, ..., those that describe the system when fault i ∈ F is present. It is assumed that the healthy and the faulty systems are all described using the same set of variables, but faulty situations imply constraints that are different. Faults in process components and actuators would typically change a subset of the state equations (1) Healthy → Fault i ∈ F x˙ = f0 (x, u, d, t) → x˙ = fi (x, u, d, t) while sensor faults would change a subset of the measurement equations (2). A healthy (nominal) system Σ0 being given, analysis approaches like fault trees, FMEA, provide a list of faults that are likely to occur i ∈ F among which only a subset F ⊆ F constitute the specification of the FT problem.
1277
Integrating FT issues in complex systems, where human operators are present, needs the development of a decision support system using a simple and easily understandable language. The way of doing this relates to functional analysis, as described in (Staroswiecki and Gehin, 1999), (Lunze et al., 2001). In the following the terms functionality and service will be used indifferently, with the meaning of “system/subsystem/component behaviour to accomplish a task”. Complexity often calls for the decomposition of the whole system, associated with global functionalities (or services), into subsystems (i.e. subsets of components), associated with local ones. Sensors, actuators, process components are at the field-level. Higher level components can be built from the aggregation of lower level ones. The field level services offered by the elementary components are integrated in order to provide a higher level service. The functional AND tree is a classical representation of services hierarchy. It is a hierarchical graph where nodes are services, and edges exist between a node σ and its followers σ ′ ∈ F (σ) at the next lower level if and only if the availability of service σ needs - and is implied by - the availability of all of the services in F (σ). The functional tree represents necessary and sufficient relationships among functionalities, i.e. necessary and sufficient conditions for the properties on the variables to be satisfied. For this reason it is a powerful tool for control and analysis of distributed systems, since it lets the designer consider the different levels of the tree independently and then exploit the distributed nature of the system, for example controlling each level independently or for FDI and Fault Tolerance considering the effects of faults at each level. A top-down analysis of the tree shows the necessary conditions for a higher level property to be achieved, each level of the tree reports the necessary functionalities for the immediately higher
different exclusive versions that are available to perform it. This means that the AND/OR functional tree introduces the redundancy relations between components. For example if σ1 and σ2 are two nodes of the tree connected with an OR gate to the upper level node σ ′ this means that σ1 and σ2 are two different versions of services through which it is possible to obtain σ ′ . As a consequence, when faults occur such that version σ1 is no longer available, the system operation can be continued thanks to version σ2 .
level functionality to be fulfilled. A bottom-up analysis shows the sufficient conditions for a functionality to be reached. Note that for each node σ all its followers σ ′ ∈ F (σ) must be considered, because of the AND operator that applies to them. Designing the functionality tree can therefore be done by starting from the top functionality and finding all the necessary conditions for it to be available. These conditions can be very easily linked to properties that the controlled system must fulfill. The relation between system properties and services is straightforward. Assume a given subsystem, which is formed by the interconnection of a set of components, is in charge of providing some functionality, for example a set of sensors S provides a set of signals y by which a vector z is estimated. Let the notation O(z/S) stand for the property “z is observable by the set of sensors S”. O(z/S) is obviously a necessary condition for the estimation service to exist. For each service σ provided by a subsystem C let z be a functional of the state and let P be a property such that
4. BUILDING FUNCTIONAL TREES FROM STRUCTURAL GRAPHS The structural model of a system is a qualitative representation of its behavior model, that is objective (it represents the physical constraints that apply to the system components) and easy to obtain (it does not need any parameter identification). Roughly speaking, the structural model represents the links between the system variables that are imposed by the system components. Note that those components have been selected or designed so as to fulfill some given functional goal, which can be translated into properties that some system variables must satisfy. Therefore, it is advisable to take advantage of the structural model to automatically derive one or more functional AND/OR trees from the system structural graph, according to the main functionalities represented by the graph.
P (z/C) =⇒ σ is available. +
Let Γ ⊆ C be a subset of components. Let 2C be the collection of all subsets of C such that +
P (z/Γ) ⇐⇒ Γ ∈ 2C . Therefore, there is a possibility of providing the service σ by using any subset of components Γ ∈ + 2C , which means that different versions σΓ of the service can be designed, using different resources Γ. Let + N (σ) = 2C
4.1 The structural graph of a system Definition 1. The structural graph of a system is a bi-partite graph with two sub-sets of vertices, V : the system variables, and C: the system (static or dynamic) constraints. The set of edges E is defined by:
then, there are N (σ) different versions, that constitute a set v [σ] . Each version of that set is able to provide the service σ. Since only one can be run at time t, they must be ranked using an appropriate procedure (see (Staroswiecki and Gehin, 1998), (Staroswiecki et al., 1997), for details and comments). Assume that at time t there is only a subset Γ(t) ⊂ C of healthy components available, as the consequence of previous faults. The functionality σ is available as long as Γ(t) contains at least + one subset that belongs to 2C , i.e. as long as the set of versions v [σ] is not empty. Let N (σ, t) be the number of versions of σ available at time t (this number is called the redundancy degree of service σ). Since each node σ in the AND tree represents a service which, at time t, can be provided under N (σ, t) versions, the AND functional tree can be replaced by an AND/OR functional tree, where AND and OR nodes alternate : AND nodes display the lower level services that are all necessary for a higher level service to be available, and for each service, an OR node displays the
(v, c) ∈ E ⊆ V × C ⇐⇒ the variable v is an argument of the constraint c. The variables V are decomposed into known and unknown ones: V = K ∪ X. Known variables K are sensor outputs, reference inputs, controllers and observers outputs. To any constraint c ∈ C - resp. to any variable v ∈ V - is associated the set V (c) - resp. the set C(v) - of all the variables - resp. of all the constraints - such that ω ∈ V (c) ⇐⇒ (ω, c) ∈ E resp. γ ∈ C(v) ⇐⇒ (v, γ) ∈ E. Example. The tank system Consider the tank system represented in fig. 1.
1278
replacemen
4.2 Causality in structural graphs
u′ (t)
u(t)
From their definition, structural graphs are non oriented. Matchings do provide an orientation, which can be interpreted in causal terms.
qi (t)
h(t) qo (t)
Definition 2. A matching M on a bi-partite graph is a subset of E such that
uo (t)
Fig. 1. The tank system.
∀ (v, c) , (v ′ , c′ ) ∈ M : v 6= v ′ ∧ c 6= c′ . Given a matching M, different cases can be distinguished:
qo
qi
c3
c1 ˙ h
c2
c6
c′2
c7
h
uo u′
u
(1) |M | = min {|V | , |F |} : the matching is complete with respect to the variables (|V | < |F |) or to the constraints (|V | > |F |) or to both of them (|V | = |F |). A complete matching is maximal, which means that no matching of larger cardinality exists. (2) |M | < min {|V | , |F |} : the matching is not complete, it may be maximal or not.
k
c′5
c4 y
c8
c5
Fig. 2. Structural graph of the tank system.
Let (v, c) be an edge belonging to a matching: v is called the output of constraint c: v , o(c) , while V (c)\ {v} is the set of its inputs: V (c)\ {v} , I(c). The resulting orientation can be interpreted as a causality assignment : the output o(c) depends on the inputs I(c) therefore, for the output to enjoy some given property, the inputs must also satisfy some (other) property. Let {c1 , c2 , ...cq } be a subset of constraints (without repetition) such that
The system is controlled via an actuator acting on the throttling of the valve on the pipe providing the input flow. It has also a redundant actuator (with the corresponding valve and pipe) which is supposed not to act in nominal conditions but it can be used to reconfigure the system in case the nominal actuator fails. The system is also controlled by an actuator acting on the valve of the output pipe. Its behavior model is given by:
i = 1, 2, ...q − 1 : o(ci ) ∈ I(ci+1 ) The path c1 − o(c1 ) − c2 − o(c2 ) − ... − cq is an alternated chain between constraint c1 and constraint cq . A loop is a subset of constraints {c1 , c2 , ...cq } such that for any pair (ci , cj ) there is an alternated chain from ci to cj and another one from cj to ci . If no loop exists (see (Diestel, 2005)) a matching induces a hierarchy on the system structural graph as follows:
˙ h(t) = qi (t) − qo (t) qi (t) = αu(t) qi (t) = αu′ (t) p Output pipe c3 : qo (t) = k(t) h(t) Level sensor c4 : y(t) = h(t) Control algorithm c5 : u(t) = f (y) Control algorithm c5′ : u′ (t) = f (y) dh(t) ˙ Derivative constraint c6 : h(t) = dt Output valve c7 : k(t) = βuo (t) Output control c8 : uo (t) = fo (y) (3) where u, u′ and uo are the actuators outputs, h denotes the liquid level, qi and qo the flow into or out of the tank, while α and β are the valves constants. Each component introduces one constraint. The extra constraint c6 expresses the ˙ fact that h(t) is the derivative of the level h(t); we suppose to know initial conditions, so it is always ˙ possible to know h(t) from h(t) and viceversa. The structural graph of the tank system described by model (3) is depicted in fig. 2. Tank c1 : Input valve c2 : Input valve c2′ :
L0 = {v : ∄c : (v, c) ∈ M } L1 = {v : (v, c) ∈ M =⇒ V (c)\ {v} ⊆ L0 } ... Lk = v : (v, c) ∈ M =⇒ V (c)\ {v} ⊆ ∪i=k−1 Li i=0 The meaning of the above definition of the level sets is the following: • L0 is the set of variables that are not matched, • L1 is the set of variables that are matched to constraints all the inputs of which belong to L0 , • L2 is the set of variables that are matched to constraints all the inputs of which belong to L0 ∪ L1 , • etc.
1279
in any of these constraints, which can be written as v = ∨c∈C(v) o(c). (4)
Table 1. A possible matching for (3). ˙ h, qo ) (h,
(c1 , c3 , c6 ) c2 c′2 c4 c5 c′5 c7 c8
y
1
1
u
1
1 1 1
1
u′
qi
1
1
1 1
1
uo
1
1 1
1
k
Now, if v is matched in constraint c ∈ C(v), then for v to exhibit the property Pn (v) it is necessary that the subset of variables I(c), inputs of constraint c, exhibit some (other) property, say Pn−1 . This is written as
1
Table 2. A possible matching for (3). ˙ h, qo ) (h,
(c1 , c3 , c6 ) c2 c′2 c4 c5 c′5 c7 c8
y
1
1
u
1
1 1 1
1
u′
qi
1
1 1
1
1
uo
1
• v is connected with all constraints c ∈ C(v) by an OR node. Indeed, property Pn (v) can be obtained by a causal link associated with any matching of the set described by (4), • each constraint c ∈ C(v) is connected to its input variables I(c) by an AND node. Indeed, the output v = o(c) can have property Pn only if all the variables I(c) exhibit property Pn−1 .
Table 3. A possible matching for (3). ˙ h, qo ) (h,
(c1 , c3 , c6 ) c2 c′2 c4 c5 c′5 c7 c8
y
1
1
u
1
1 1 1
1
1
u′
qi
1
1
1 1
1
uo
k
1
1 1
(5)
With these considerations it is easily seen that a tree having variable v (which stands for the function that has to be performed) as root has the following properties:
1
1 1
1
∀w ∈ I(c) : Pn−1 (w). k
1
Then to obtain the AND-OR tree it is necessary to choose a root variable representing the main property the system must achieve and detect all the measure and control variables and find all possible matchings in which these variables are not matched (to give an ending point to the tree as explained above). Starting from the root variable the algorithm is: while There are constraints available for matching do for all variables z at level k do associate an OR node which concentrates all constraints available for matching in C(z) for all constraints γ ∈ C(z) do associate an AND node which concentrates all variables V (γ)\z. end for end for end while Level k + 1 is built on all variables that are concentrated by AND nodes.
Example. After graph condensation (see (Diestel, ˙ h, qo it 2005)) to eliminate the physical loop h, is possible to build some possible matchings for system 3. They are reported in tables 1, 2 and 3. Note that some constraints are not matched, and therefore the matchings are neither maximal nor complete wrt the variables or the constraints.
4.3 From structural graphs to functional trees In this section an automatic procedure is presented to obtain a functional tree starting from the structural graph of a system/subsystem. The approach is based on the idea that performing a given system function φn can be translated into providing some system variable v with a given property Pn (v), e.g. v is wanted to track a specific reference trajectory. Note that for each structural graph there can be many different main functionalities, each of them can be considered as a root of a tree. Moreover in the functional tree the leaves represent properties on physical components and among them there are sensors and actuators. The measure and control variables represent then basic functionalities related to sensors and actuators respectively. This means that in our representation measure and control variables will be the leaves of the tree. This would help in knowing when the tree ends and in knowing the starting point of the path to the root variable. Consider the set C(v) of all the constraints in which v is present. Obviously, v could be matched
The procedure ends when the non-matched variables are reached. Note that constraints available for matching are all constraints except those already used in higher levels. It is worth noting that the hierarchy obtained in this way is reflected by the hierarchy given by the level sets, in fact in set L0 all non-matched variables are reported and they will be at the bottom of the tree, variables in L1 are at the immediately upper level and so on until the root of the tree is reached. Even if the level sets give a first rough hierarchy to the system they are not sufficient to establish relations among all the variables. These
1280
Blanke, M., M. Kinnaert, J. Lunze and M. Staroswiecki (2003). Diagnosis and Fault Tolerant Control. Springer-Verlag. Bonivento, C., M. Capiluppi, L. Marconi and A. Paoli (2005). An integrated design approach to multilevel fault tolerant control of distributed systems. 16th IFAC World Congress. Bravoco, R.R., C. Fledmann, D. Ross and D. Thornhill (1975). Structured Analysis and Design Technique Authors Guide. SoftTech Book Product 3045, SoftTech, Inc. Waltham, MA. Diestel, R. (2005). Graph Theory. SpringerVerlag. Lewis, R.W. (2001). Modelling control systems using IEC 61499. Applying function blocks to distributed systems. The Institution of Electrical Engineers Publishing. London. Lunze, J., J. Askari-Marnani, A. Cela, P.M. Frank, A.L. Gehin, B. Heiming, M. Lemos, T. Marcu, L. Rato and M. Staroswiecki (2001). Three tank control reconfiguration. In Control of Complex Systems, editors Astr¨om, Albertos, Blanke, Isidori, Schaufelberg, Sanz. Springer, pp. 241-283. Marconi, L. and A. Paoli (2005). Fault tolerant control of large complex systems. Precongress full-day workshop, 16th IFAC World Congress. Prague, CZ. Staroswiecki, M. (2002a). Fault tolerance systems. In Fault Diagnosis and Fault Tolerant Control, editors P. M. Frank and M. Blanke, Encyclopedia of Life Support Systems (EOLSS). Eolss Publishers, Oxford, UK. Developed under the auspices of the UNESCO, [http://www.eolss.net]. Staroswiecki, M. (2002b). Structural analysis for fault detection and isolation and for fault tolerant control. In Fault Diagnosis and Fault Tolerant Control, editors P. M. Frank and M. Blanke, Encyclopedia of Life Support Systems (EOLSS). Eolss Publishers, Oxford, UK. Developed under the auspices of the UNESCO, [http://www.eolss.net]. Staroswiecki, M., A. L. Gehin and M. Bayart (1997). Faulty resources management in automation systems. IEEE SMC’97. Staroswiecki, M. and A. L. Gehin (1998). Analysis of system reconfigurability using generic component models. UKACC Control’98. Staroswiecki, M. and A. L. Gehin (1999). A formal approach to reconfigurability analysis / application to the three tank bechmark. In Proc. of European Control Conference, ECC’99. Staroswiecki, M. and A. L. Gehin (2001). From control to supervision. Annual Reviews in Control 25, 1–11.
relations are given by the logic gates (AND/OR) in the tree. The level sets are useful in case of big complex systems in which it is necessary to find out a first hierarchy among variables. This will help in finding the group of variables in the matching tables to establish relationships between variables and then build different parts of the tree separately. Example. The presented procedure is now applied to system 3. The main functionality of the system is to make level h reach a certain value h0 . Variable h is chosen as root but due to the loop condensation knowing the level h is equivalent to the knowledge of its derivative and to the knowledge of the output flow qo , this means that the functionality will be the same. Starting from the matchings in tables 1 and 2 and 3 and following the above presented procedure the tree represented in fig. 3 is obtained where it is possible to see that the two redundant actuator variables are related to the upper level variable with an OR gate. Moreover an analytical redundancy is presented here, because the knowledge of the main functionality can be achieved through the measure of the level. But both the knowledge of the inflow and of the output actuator are needed, that is the meaning of the AND gate.
5. CONCLUSIONS The topic addressed by this work is the functional view of fault tolerance using structural analysis, in order to build a functional model in a univocal way. This work is motivated by the fact that existing procedures to build functional models are not based on objective properties of the system in particular when dealing with distributed systems. The presented methodology allows the designer to build a hierarchical functional model of the system starting from its structural properties.
REFERENCES Andrews, J.D. and T.R. Moss (2002). Reliability and Risk Assessment. Professional Engineering Publishing. h
˙ qo h or
and
y uo
qi or
u
u′
Fig. 3. The tank functional trees.
1281