**Computational Water, Energy, and Environmental Engineering** Vol.2 No.4(2013), Article ID:38136,6 pages DOI:10.4236/cweee.2013.24011

New Approach to the Diagnosis of Control Hydraulic Systems

^{1}LTII Laboratory, A. Mira Béjaia University, Béjaia, Algeria

^{2}Automatic Control Laboratory, University of Setif, Setif, Algeria

^{3}LCIS Laboratory, INPG Valence, Valence, France

Email: atemnora@yahoo.fr, mostefai@univ-setif.dz, Oum-El-Kheir.Aktouf@esisar.grenoble-inp.fr

Copyright © 2013 Noura Rezika Bellahsene Hatem et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Received September 21, 2012; revised January 5, 2013; accepted February 1, 2013

**Keywords:** Diagnosis; Dynamic System; Hybrid System; Reliability; System Safety

ABSTRACT

A dynamical hybrid system is described by a set of continuous variables and a set of discrete events interacting mutually. The reality imposes to take into account the failures of the components or the uncertainties on the knowledge of the system. Therefore, the systems can work in several modes. Some of these modes correspond to a normal functioning and the others represent failing modes. In this article, we are interested in the evaluation of the probability of occurrence of the failing events in a hybrid dynamic system. Furthermore, we propose an approach to detect on line the failed states and try to find the components responsible for this fault. This approach is based on the knowledge in priori of the system, at least from the point of view of the state of its components in normal functioning. This approach is here described through a simple case study taken from literature.

1. Introduction

The objective of this study is precisely to detect failed states in an embedded system and find the faulty components. Otherwise, we assess the probability of occurrence of these events that lead to the failed state (off line). The hardware and software is a component of a more complex system that must operate independently of human intervention. An embedded system may include some kind of operating systems but often it will be simple enough to be written as a single program. It is a hybrid system which exhibits both continuous and discrete dynamic behavior—a system that can be both flow described by a differential equation and jump described by control graph. Two basic hybrid system modeling approaches can be classified as an implicit and an explicit one. The explicit approach is often represented by a hybrid automata or a hybrid Petri net [1-3]. Once the model has been defined, our approach permits to identify the faulty states and tries to determine the components that are responsible. Furthermore, reliability of the system is calculated. A comparison with previous results of calculation of reliability is provided [4,5].

2. Description of the Method

We represent a system, in a diagnostic point of view as A life cycle, which is interrupted by the occurrence of an event that switches the operating mode of the system from a normal state to a state of failing functioning, is shown schematically in Figure 1. It is considered to be a life cycle which is interrupted by the occurrence of an event that switches the operating mode of the system

Figure 1. Global state of a dynamic system.

from a normal state to a failing state. By adopting this representation, the designer can easily notice that his contribution may not occur at the block level detection and then reconfigure the system. The occurrence of the event could not be more random. A system is a set of components and the component, in our case, is considered as a unit represented by a binary number (bit). The system operation is divided into time steps. Each step is considered as such with all its parameters. We consider a step function as a sub-state of the functioning that can be a normal state as it may be a failed state. n the simplest case, the system can be considered as a single step. The state parameters are the values of bits representing the system components (1 or 0 eg closed, open, off, on ...). The subsystem with the corresponding time step in question is then a combination of bits representative of the components. A step involving N components will be 2^{N} combinations representing 2^{N} deputy possible states (normal and faulty). Each combination indicates the status of each component and indirectly, it also informs us about the components that are the cause of the failed state. Once the sub-states are simulated, the results are analyzed and failed modes are identified. After that, a probability calculation is performed.

3. Algorithm

3.1. Previous Study

● Decompose the total functioning of the system in steps of operation where the components involved have a single state.

● Identify components involved in each step.

● Represent each component by a bit B {1.0} a: 0 state and asked.

● Represent step by a binary number where the number of bits is equal to the number of components involved in the stage in question.

● Expressing representative combinations of step (substates of the functioning step)

3.2. Off-Line Study

● Detect the failing states by analyzing the indicator of each failing event.

● Calculate the probability of occurrence of each failed state

3.3. On-Line Study

● Identify the failing states by analyzing the indicator of each failing events.

● List the components that are responsible for this state.

● Reconfiguration.

4. The Case Study

The test case consists of a tank containing a liquid whose level h must be maintained with a main pump P1, a backup pump and a drain valve V [5,6]. Each of the three components is controlled by a control loop containing a level detector (Figure 2).

The task ahead is to maintain the liquid level constant in the interval ([6,8]). If the level is below 6, the command closes the valve and opens the backup pump and if the level is above 8, the pumps are stopped and the valve is opened. Two extreme situations can occur: the drying up and overflow. These two cases occur when the order can no longer act on the system components that become failing (1 or more components). We then say that the system is in a failed state even dangerous. The three components of pump P1, P2 pump and valve V are mutually independent and non-repairable.

The continuous variable for the system is the liquid level h which depends on the status of components. Thus, the differential equation for the system is given by:

(1)

where

(2)

There

D is the flow rate of the elements P1, P2 and valve.

The generalized Equation (1) reflects the various possible operating modes of the process. It shows the influence of discrete phenomena on the evolution of the process through, ,. These can take, in the case of this example, the value 1 if the component is active or if a fault blocks it in the open or active position, and 0 otherwise, as expressed by the Equation (2). In nominal conditions, the flow of P1 is equal to the flow of P2 and V.

Then, D = 1.5 m^{3}∙h^{−1} for P_{1}, P_{2} et V.

At time t = 0, the liquid level h = 7 m, the pump P1 works, P2 is stopped and the valve V is opened. The system control laws which define the state of the pumps and the valve as a function of liquid level are given in Table 1 below:

The state of an embedded system is defined by the values of the continuous variables and a discrete control mode. The state changes either continuously, according to a flow, discretely according to a control graph. Continuous flow is permitted as long as so-called invariants hold, while discrete transitions can occur as soon as given jump conditions are satisfied. The system thus defined may be considered as a hybrid controller which takes into account the different modes of continuous operation of the system and the transition from one another on the occurrence of deterministic events which are produced by crossing the thresholds of continuous variables. The elementary automata are given in Figure 3 and the automaton representing the command is given in Figure 4. Events associated with P1, P2, P3 are:

● a_P1 and a_P2: stopping the pumps P1 and P2

Figure 2. Level control system.

Table 1. Control laws of the system.

● d_P1 et d_P2: start of pumps P1 and P2

● o_V: opening of the valve and

● f_V: closing of the valve We distinguish for the components P1, P2 and V the following states:

● ON-P1, ON-P2 and ON-V: active pumps and valve opened

● OFF-P1, OFF-P2 and OFF-V: pumps and valve closed.

For the reservoir we have the states:

● N_n: Normal level of the reservoir ( 6 ≤ h ≤ 8)

● N_ass: Level of drying (h ≤ 4) et

● N_deb: Overflow level (h ≥ 10).

Control laws of the command:

● Initial: C0 – P1 active, P2 stopped et V open

● If h < 6: C2 → C3, P1 active; C3 → C4, P2 active et C4 → C5, V stopped

● If h > 8: C6 → C7, P1 stopped; C7 → C8, P2 stopped et C8 → C1, V open.

5. Main Results

5.1. Online Monitoring: Detection of Failed States

The total operating system can be described by a single step or a single state that is maintain the liquid level h in the interval [6,8]. The simulation of the system without the occurrence of unwanted events gives the normal state, knowing that the initial level is h = 7 m. The system seen like that, keeps the liquid level constant. The simulation of a failure in the 9^{th} iteration (blocked valve closing) the liquid level increases indefinitely and the overflow indicator equals 0 (Figure 5). The simulation of another fault (pump P1 is locked in opening and the pump P2 is locked in the closure, the valve opened), the level drops to the lowest level and the indicator of drying has become 0 (Figure 6). It should be noted that indicators of the two states have been initialized to 1.

5.2. Offline Monitoring: Calculation of Probability

The system starts with the normal state (101: Pump open P1, P2 pump closed and valve V open). At t = 9th iteration, there is the occurrence of the failed state (one, two or all three components are not in the expected state). To avoid ambiguity with the role of the command, it is in-

(a)(b)(c)(d)

Figure 3. Finite state automata of the three components. (a) Automataof the pump P1; (b) Automataof the pump P2; (c) Automata of the valve; (d) Automataofthe reservoir.

habited to the occurrence of the feared event. Moreover, we are not interested here by the physical cause of the failure. This may be due, in fact, by an external action (closing or opening accidentally), the blocking component’s state (open or closed) or simply, the failure was the consequence of the life of the component (wear).

Figure 4. Automata of the command.

From the normal state, we look at all possibilities of failure. These modes are summarized in the following, noted that only the state 101 is the nominal operating condition.

000: Pump P1 is closed, the pump P2 is closed and the valve is closed. Steady state in the initial state.

001 Pump P1 closed, the pump P2 closed and the valve opened: Drying.

010 Pump P1 is closed, the pump P2 is opened and the valve is closed: Overflow.

011 Pump P1 is closed, pump P2 is opened and the valve is opened. Normal state (rescue).

The backup pump takes over the pump P.

100 Pump P1 is opened, pump P2 is closed and the valve closed: Overflow.

110 Pump P1 is opened, pump P2 is opened and the valve closed: Overflow.

111 Pump P1 is opened, pump P2 is opened and the valve opened: Overflow.

Figure 5. Overflow state of the system.

Figure 6. Drying state of the system.

The simulation results have shown that all faulty modes were detected. Thus, overflow mode appears in four cases, the drying mode appears in one case and the normal state in three cases (Table 2).

Mode corresponding to the combination 000 where all components are closed, the liquid level does not vary from the initial state. For mode (011), the pump P1 is closed and the pump P2 takes over, this state corresponds to the normal state and the liquid level is constant.

The calculation of probability of the occurrence of-

Table 2. Summary table of states.

Table 3. Probability values of each state.

Table 4. Probabilities of access to feared states.

faulty modes gives explicitly the values shown in Table 3 and the Table 4 gives the probabilities of access to feared states in previous studies [4,8]

6. Discussion

The faulty modes are detected and the components responsible of these modes are listed on line. The system can be reconfigured. Furthermore, the results show that the probability of the state drying is 0.125 and the probability of occurrence of the overflow condition is 0.5. The values obtained in previous studies are not accurate and the number of iterations is very important. At 1000 h, the value is not exact. It may take more than this duration to obtain the final value.

7. Conclusion

Our approach allowed us to assess the probability of occurrence of undesirable events. Thus, we have introduced a method leading to identify and locate faulty modes. This approach can be applied to any hybrid system described by its dynamic equations since these equations are considered as the discrete parts of the system.

REFERENCES

- N. R. Bellahsene Hatem, O. Aktouf and M. Mostefai, “Aide au Diagnostic des Systèmes Dynamiques Hybrides,” Colloque d’Informatique, Automatique et Electronique CIAE 2011, Casablanca, Moroccoc 24-25 Mars 2011.
- N. R. Bellahsene Hatem, O. Aktouf and M. Mostefai, “Contribution au Diagnostic des Evénements Défaillants Dans un Système Dynamique Hybride,” International congress for Global Science and Technology (ICGST), Istanbul, 19-21 Décembre 2011, pp. 137-142.
- F. Thedjani, K. Laabidi and S. Zidi. “Classification non Supervisee Pour la Surveillance d’un Système Automatique 8e,” Conférence Internationale de MOdélisation et SIMulation—MOSIM’10—10 au 12 mai Hammamet, 2010, pp. 125-131.
- J. Clarhaut, “Prise en Compte des Séquences de Défaillances Pour la Conception de Systèmes d’Automatisationque,” Thèse de Doctorat, University of Lille, Lille, 2009.
- E. Borgonovo and M. Marseguera. “A Monte Carlo Methodological Approach to Plant Availability Modeling with Maintenance, Aging and Obsolescence,” Reliability Engineering and System Safety, Vol. 67, 2000, pp. 61-73.