Detection of Zeno Sets in Hybrid Systems to Validate Modelica Simulations

Transcription

1 Bachelor Thesis Detection of Zeno Sets in Hybrid Systems to Validate Modelica Simulations Marcel Gehrke July 20, 2012 supervised by: Prof. Dr. Sibylle Schupp Technische Universität Hamburg-Harburg Institute for Software Systems Schwarzenbergstraße Hamburg

2

3 Eidesstattliche Erklärung Ich versichere an Eides statt, dass ich die vorliegende Bachelorarbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Die Arbeit wurde in dieser oder ähnlicher Form noch keiner Prüfungskommission vorgelegt. Hamburg, den 20. Juli 2012 Marcel Gehrke i

4

5 Acknowledgments I would like to thank Prof. Dr. Sibylle Schupp for the opportunity to write this thesis. I am also very thankful for her valuable feedback and good supervision of my thesis development. iii

6

7 Contents 1 Introduction 1 2 Hybrid Systems Example: Air Conditioning Hybrid Automata General Description Air Conditioning Example: Water Tank Modelica OpenModelica Hybrid Automata Library Bouncing Ball Water Tank in OpenModelica Simulation Zeno Behavior Water Tank Zenoness Simulation Zeno Set Reset Map Detecting a Zeno Set Tool for Zeno Set Detection Control Flow Graph Specification Automaton Grammar General Properties Tool Description Parsing and Cycle Detection Zeno Detection Determining the Zeno Set v

8 Contents Boundary of the Domain Intersection Evaluation Air Conditioning Bouncing Ball Water Tank Another Air Conditioning System Completeness Future Work 47 8 Conclusion 49 Bibliography 51 Appendix 53 1 Test Files Haskell Code Defined Data Structures State and Transition Parsing Cycle Detection Retrieving Restrictions on Domain Intersection Printout vi

9 List of Figures 2.1 Hybrid Automaton of an Air Conditioning as a Heater Water Tank as Graphical Representation Hybrid Automaton of the Water Tank Hybrid Automaton of the Bouncing Ball Water Tank in OpenModelica Water Tank Simulation in OpenModelica Bouncing Ball Simulation in OpenModelica Control Flow Graph of the Tool Boundaries of a Continuous Variable of the Tool Function to Retrieve the Boundaries of a Continuous Variable Function for the Intersection of the Boundaries of a Continuous Variable Input File for the Air Conditioning System Input File for the Bouncing Ball System Input File for the Water Tank System Input File for another Air Conditioning System Hybrid Automaton of the Water Tank with Delay vii

10

11 List of Tables 4.1 Conditions for Zeno Behavior Retrieving the Interval of a Guard for a Continuous Variable Retrieving the Interval of the Interior of a Domain for a Continuous Variable Generating the Boundaries of a Continuous Variable in a Domain Tests for all Conditions for Zeno Behavior Retrieving the Interval of the Interior of a Domain for a Continuous Variable with Tests Intersection of the Interior of a domain with a Guard for a Continuous Variable with Tests Interval for the Guard using Constants as Boundaries with Tests Properties of the Tool ix

12

13 1 Introduction Throughout this thesis, we will focus on hybrid systems [12]. Hybrid systems are interactive systems and combine both continuous and discrete state dynamics [15]. Interactive systems react to events triggered by the environment [8]. While reacting to the event, the system might even change the environment. A simple example of a hybrid system is an air conditioning system. It consists of a heater and a sensor for the current temperature. Based on the current temperature, the heater is either on or off. Hence, the system is interacting with its environment, namely the temperature. Hybrid systems are rather sensitive systems, in the way that a failure of such system could be critical. One only has to think of a power plant. In a power plant many components need to be cooled. Water can be used for the purpose of cooling. The water could be stored in a water tank. Building the system and testing the system by running it, is not a good idea, since if we do not always have enough water in the tanks a possible outcome would be a meltdown. Hence, it is crucial to validate that there is always enough water in the tank. Such a water tank system is a hybrid system. In the water tank, we have sensors measuring the current water level. If the water level drops below a desired level, a source pours water at a constant rate into the tank. Thus, the system is interacting with its environment, since it reacts to an event triggered by the environment and even changes it by reacting on the event. A way to validate a hybrid system is simulation. During simulation, it is possible to test the system. A tool based on the Modelica language could be used for simulating hybrid systems [5]. However, to simulate a hybrid system, we first have to model the system. While modeling the system, we need to abstract the hybrid system. Unfortunately, the process of abstraction can be error prone. Mostly, these errors are due to mathematical complexity and oversimplification [16],[11]. Therefore, the outcome of a simulation of a system can differ from reality [3]. In case a model of a system shows zeno behavior, the outcome of the simulation and the physical system can differ. Zeno behavior can only occur in a model of hybrid [10] or temporal [17] systems, but not in the physical system. Roughly speaking, a hybrid 1

14 1 Introduction system shows zenoness if it undergoes an unbounded number of discrete transitions in a finite and bounded length of time [10]. Here, my work comes into play. I implemented a tool to detect zeno sets. The tool tells the user when the model of a system can exhibits zeno behavior. Even more, in case the model can show zeno behavior, the zeno set of that model is printed out. The zeno set contains all points to which the simulation can converge while showing zeno behavior. If the simulation converges to one of these points, the modeler of the simulation should check whether the outcome is trustworthy. Hence, one more safety net for validating a hybrid system is generated. Bauer [2] describes another approach to validating hybrid systems. The thesis consists of the following parts: In Chapter 2, we take a closer look at hybrid systems and explain them in more detail. I present the simulation tool OpenModelica, which is based on the Modelica language, in Chapter 3. Further, I demonstrate how a simulation can differ from the real world. In Chapter 4, we discuss how it may occur, that a simulation differs from the real world. Therefore, we need a deeper understanding of how zeno behavior occurs. Hence, we focus mainly on understanding zeno behavior in Chapter 4. In Chapter 5, my contribution starts. Here, I present the tool to detect zeno sets, describing what the tool does and how it works. In Chapter 6, I conduct an evaluation of the tool. For the evaluation of the tool, I show that it works for examples given throughout the thesis, as well as a completeness evaluation. Finally, future work and how one could deal with hybrid systems showing zeno behavior is described in Chapter 7. 2

15 2 Hybrid Systems Hybrid systems are systems that are coupled with the environment. Areas such as aeronautics, automotive vehicles, bioengineering, embedded software, process control, and transportation use hybrid systems. Due to their increasing importance, these systems become of more and more interest [12]. Hybrid systems combine both continuous and discrete state dynamics. A state variable is discrete in case it can just take a finite number of values. A continuous state variable can take any value form the Euclidean space R n [14]. The change of the continuous variables is normally represented as a differential equation. Throughout the thesis, we abbreviate discrete state by state. A formal representation of hybrid systems are hybrid automata. We take a closer look at hybrid automata as representation of hybrid systems, in this thesis. 2.1 Example: Air Conditioning As mentioned in Chapter 1, an example of a hybrid system is an air conditioning system. It can be modeled using two discrete states, on and off, as well as one continuous variable, the current temperature. x 20 start on ẋ = 1 off ẋ = 1 start x 20 x 15 x 15 Figure 2.1: Hybrid Automaton of an Air Conditioning as a Heater 3

16 2 Hybrid Systems Fig. 2.1 shows an air conditioning system as a heater modeled as a hybrid automaton. In the modeled air conditioning system, the current temperature always stays between 15 C and 20 C, as long as the outside temperature is below 15 C. Still, we should check whether the temperature really always stays between 15 C and 20 C. Therefore, let us assume the current temperature is 17 C in the beginning. Further assume the air conditioning system starts in the on state. Hence, the system starts to heat the room. When the current temperature reaches 20 C, the transition to the off state triggers and the automaton switches to the off state. In the off state, the system stops to heat the room and the room starts to cool down again. When the current temperature drops to 15 C, the transition to the on state is triggered and the process starts all over again. Thus, modeling the air conditioning system in such a manner guarantees the temperature to always stay between 15 C and 20 C. 2.2 Hybrid Automata A hybrid automaton is a dynamical system describing the evolution of a set of discrete and continuous variables over time [15]. Definition 1. A hybrid automaton H is a 7-tupel H = (Q, X, Init, D, E, G, R) : [20] Q, denotes the discrete states: {q 1,.., q n } X, denotes the continuous variables from R n with n 1 Init, denotes the initial states from Q D: Q P(X), denotes the domain, the legal region of operation, for each discrete state E Q Q, denotes the edge or transition from one state to another: q i q j Guards G : E P(X), denotes a mapping from a transition to a guard. When the guard holds true, the corresponding transition can be triggered. Reset map R : E X P(X), determines how continuous variables change during a discrete state transition In some papers, the domain is called invariant of the state. 4

17 Marcel Gehrke General Description The set Q consists of all states. We only consider automata where every state contains at least one differential equation, ensuring that we do not have any state in which the system idles. Further, we operate in every state on at least one continuous variable. Every continuous variable from the set X has to be in a differential equation in at least one state. Hereby, we ensure that the value of every continuous variable can change over time. To determine in which state the automaton can start, the Init set is crucial. When starting the automaton, the automaton can only be in one of the states defined by the Init set. The Init set is indicated by a double cycle in the hybrid automaton. Furthermore, every state has a domain, its legal region of operation. A state can only operate as long as the domain of the state holds true. The set E consists of all edges, so called transitions, from one state to another. Every transition has a corresponding guard. The guard declares when a transition can be triggered, by defining the legal region of operation for the transition. Another component of the transition is the reset map. The reset map determines how continuous variables change while taking the corresponding transition. Examples of the use of the reset map are a damping coefficient or simulating a delay Air Conditioning The hybrid automaton in Fig. 2.1 contains all of the elements of Definition 1. The set of discrete states Q = {on, off } are the states the automaton can operate in. The set of continuous variables X = {x} contains only one element, which represents the current temperature. Even though there are two distinct states, on and off, the set of continuous variables X is just from R 1. Both states operate on the same continuous variable. The set of initial states contains the on and off state, meaning the automaton can start in either of these states. The on state has the domain x 20. Therefore, the automaton can only operate in the on state until the current temperature reaches 20 C. The domain of the off state is x 15. While being in the off state, the current temperature can only cool down to 15 C. The set E of the hybrid automaton consists of two transitions, one transition from on to off and another one from off to on. Each of these transitions has a corresponding guard and reset map. The guard for the transition from the on to the off state, x 20, specifies that the transition can be triggered in case the current temperature is at least 20 C. Comparing the guard with the domain of the on state, one can see 5

18 2 Hybrid Systems that the transition is triggered exactly when the current temperature reaches 20 C. The on state can warm up the temperature until it reaches 20 C and the transition can be triggered when the temperature is at least 20 C. Thus, the only intersection of the domain and guard is when the temperature is exactly 20 C. The transition from the off to the on state adheres to the guard x 15. Therefore, the transition can be triggered when the current temperature is 15 C or below. However, comparing the guard with the domain of the off state yields that the transition can only be triggered when the current temperature is exactly 15 C, using the same argument as before. The reset map for both transitions is 1, since the continuous variables do not change during taking a transition. 2.3 Example: Water Tank We will now introduce another example of a hybrid system, a water tank system. The example of the water tank system will follow us throughout the thesis to explain what zeno behavior is. Figure 2.2: Water Tank as Graphical Representation 6

19 Marcel Gehrke Fig. 2.2 shows the water tank system of Alur and Henzinger [1]. The water tank system consists of two water tanks, a water source and a hole in each tank. From the hole in each tank, water drains with a constant rate v 1 and v 2 respectively. The water source can only pour water, at a constant rate w, into one tank at a time. Hence, only one tank receives water from the source, while both are draining water at the same time. Furthermore, the variables x 1 and x 2 in the Fig. 2.2 represent the current water level, while the variable r stands for the minimal required water level. To be able to simulate the water tank system, we need an accurate model of it. Therefore, in Fig. 2.3, we can see one approach to model the water tank system as a hybrid automaton. x 1 > r 1 x 2 > r 2 x 1 > r 1 x 2 > r 2 q 1 x 2 r 2 q 2 x 1 = w v 1 x 2 = v 2 x 2 r 2 x 1 = v 1 x 2 = w v 2 x 1 r 1 x 1 r 1 Figure 2.3: Hybrid Automaton of the Water Tank The automaton has two discrete states denoted by the variables q 1 and q 2. They seem to be related to the two water tanks. More accurately said, the states represent that the water source w pours water into either of the tanks. Both states have a corresponding domain: x 2 r 2 for state q 1 and x 1 r 1 for q 2. The set X consists of the variables x 1 and x 2. The two transitions, one from q 1 to q 2 and another one from q 2 to q 1, build the elements of the set E. Each of the transitions has a corresponding guard and reset map. The transition from q 1 to q 2 has the guard x 2 r 2 and the transition from q 2 to q 1 x 1 r 1. The reset map is equal to 1 in both cases. Now, let us check whether the hybrid automaton really reflects the water tank system from Fig In state q 1, the differential equation x 1 = w v 1 reflects the case of the water source being above the first tank and pouring water, for every time interval, with the constant rate of w into it. Water drains with a rate of v 1 from the water tank. The case that water only drains from the hole in the second state, is denoted by the differential equation x 2 = v 2. The domain of q 1, x 2 r 2, defines that the 7

20 2 Hybrid Systems automaton can only operate in the state q 1 as long as the current water level in the second tank is above or equal to the minimal required water level r 2. There is one outgoing transition from q 1 to q 2 with the guard x 2 r 2. Due to the guard, the transition can only be triggered when the current water level in the second tank is equal or below the minimal required water level r 2. Comparing the domain of q 1 with the guard from the transition from q 1 to q 2, one can see that the only possibility for the transition to be triggered is when the current water level in the second tank is equal to the minimal required water level, i.e. x 2 = r 2. So far, the model of the water tank system seems to be reasonable. The state q 2 is similar to the state q 1. The differential equations x 1 = v 1 and x 2 = w v 2 represent the reversed case of the differential equations from the state q 1. While the water source pours water at a constant rate of w into the second water tank, water drains from both tanks with a constant rate of v 1 and v 2 respectively. The domain x 1 r 1 has the same impact as the one from state q 1. Namely, that the automaton can only operate in q 2 as long as there is enough water in the first tank. Finally, there is the outgoing transition to q 1 with the guard x 1 r 1. The guard can be triggered when the current water level x 1 is equal or below the minimal required water level r 1. Comparing the domain and the guard, the transition can only be triggered in case of x 1 = r 1. In the next chapter, we will take a look at a simulation tool for hybrid systems. Further, we will see how the water tank example is modeled in that tool. 8

21 3 Modelica Many simulation and modeling tools are available. However, just a few fit our purpose of simulating hybrid systems. Modelica, gproms, AnyLogic, VHDL-AMS and Verilog-AMS simulators could be used for simulating hybrid systems [5]. We will focus on tools based on the Modelica language. Modelica is a modern, strongly typed, declarative, and object-oriented language for modeling and simulation of complex systems [6]. The Modelica langauge differs in two important aspect from other object-oriented language like Java or C++. The first aspect is that Modelica is a modeling language. Unlike a programming language, a Modelica model is not compiled in the usual sense but is translated into objects that are then interpreted by a simulation engine. A Modelica model is primarily a declarative mathematical description that simplifies further analysis. The second and more important difference, for our purpose, is that Modelica focuses on differential equations. The fact that Modelica focuses on differential equations makes Modelica well suited for simulating hybrid systems [7]. There are many implementations of the Modelica language, such as AMESim, CA- TIA Systems, Dymola, JModelica.org, MapleSim, Wolfram SystemModeler, Open- Modelica, Scicos, SimulationX, Vertex and Xcos 1. We will focus on the open-source tool OpenModelica. 3.1 OpenModelica OpenModelica is a frontend for the Modelica language. It can be used to simulate Modelica models and therefore, hybrid systems. Further, the editor of OpenModelica provides an efficient environment to write Modelica models. In OpenModelica, the Modelica models are translated into C code using a compiler, and then evaluated. Translating the Modelica model to C code has one major advantage: It provides the possibility to have access to a debugger. The OpenModelica debugger makes 1 9

22 3 Modelica OpenModelica unique compared to other Modelica frontends since it is the only one so far with good support for debugging Modelica algorithmic code [5]. Being an open-source tool makes OpenModelica rather transparent compared to other Modelica frontends. Thus, it is possible to modify OpenModelica in a desired way. It is also possible to write own libraries. One of these user-written libraries is the hybrid automata library (HyAuLib). Unfortunately, the hybrid automata library is not maintained anymore and therefore, hardly supported. However, the hybrid automata library helps us modeling our hybrid systems. Hence, we will introduce it now Hybrid Automata Library OpenModelica is already well suited for simulating hybrid systems [4]. However, using the hybrid automata library, it becomes more intuitive to model hybrid systems in OpenModelica. Hybrid systems are formally represented as hybrid automata. Therefore, using the representation as automata for writing models of hybrid systems for simulations is more natural. The library has been derived by extending the free Modelica StateGraph library by Otter and Dressler [18], which is based on the JGraphChart method and provides components to model finite state machines [15]. Instead of having to write the explicit Modelica code, which can be burdensome and error-prone even for very simple models, the hybrid automata paradigm can now be used in a natural fashion. The HyAuLib takes care of all necessary state transitions. There are two basic elements of automata, which are modeled in the HyAuLib, the FiniteStates and the Transitions. FiniteStates: Important elements of the state are the continuous dynamics as well as the state domain or invariant. These two elements also have to be defined. Every state can have a defined number of incoming and outgoing connections. Transitions: The Transitions contain two elements. One element is the guard. Every transition in a hybrid automaton has to have a corresponding guard, which determines when a transition is triggered. The other element is a reset map. There are two possible reset conditions available. The standard reset map is 1, which is the first possibility. The second possibility allows the users to specify their own reset map. 10

23 Marcel Gehrke Having all of these elements it is possible to model a hybrid automata in OpenModelica using HyAuLib. Further, one can specify a transition delay, meaning that a transition is not instantly triggered when the guard holds true, but after a specified delay Bouncing Ball The bouncing ball is a example used rather often in the field of hybrid systems. It can be modeled as a hybrid automaton as shown in Fig q x 1 = x 2 x 2 = g x 1 == 0; x 2 := x 2 c x 1 0 Figure 3.1: Hybrid Automaton of the Bouncing Ball To model the bouncing ball, only one state is needed. The continuous variable x 1 represents the current height of the ball, while x 2 models the velocity. The invariant of the state, x 1 0, determines that the ball cannot go below the surface. In addition to that, the transition is triggered when the ball hits the ground. Further, the reset map states that in this case, x 2, the velocity gets reversed and multiplied with a variable c [0, 1), which represents the damping coefficient. Obviously, one can also write a Modelica flat model to realize such a bouncing ball. However, the zeno behavior of the bouncing ball system causes some problems here. Due to numerical errors, x 1 will eventually become negative and, since the equations used to describe the model are still satisfied, the ball position will keep decreasing [15]. In the next chapter, we will see what zeno behavior is and how the numerical errors occur. The invariant set of the hybrid automaton using HyAuLib solves this problem, by marking negative values for x 1 as infeasible. Therefore, HyAuLib can reduce the problems of numerical errors introduced by zeno behavior. Hence, modeling hybrid systems using the HyAuLib is more intuitive and less error prone than writing Modelica flat code. 11

24 3 Modelica 3.2 Water Tank in OpenModelica Let us revisit the water tank system from the Fig. 2.2 and model it in OpenModelica. Fig. 3.2 shows how the water tank could be modeled using OpenModelica. 1 model WaterTank 2 parameter Real w = 1.8; // Water from the source 3 parameter Real v_1 = 1; // Water drainage in the first tank 4 parameter Real v_2 = 1; // Water drainage in the second tank 5 parameter Real r_1 = 5; // Minimal required water level for the first tank 6 parameter Real r_2 = 5; // Minimal required water level for the second tank 7 parameter Real u_1 = w - v_1 ; // Equation for x_1 8 parameter Real u_2 = - v_2 ; // Equation for x_2 9 Real x_1 ( start = 10) ; // Start value for the water in the first tank 10 Real x_2 ( start = 10) ; // Start value for the water in the 11 equation 12 der ( x_1 ) = u_1 ; 13 der ( x_2 ) = u_2 ; second tank 14 // State change, therefore u_1 and u_2 need to be changed 15 when x_2 <= r_2 then 16 // The reinit function assigns the second argument to the first 17 reinit (u_1, -v_1 ); 18 reinit (u_2, w - v_2 ); 19 end when ; 20 // State change, therefore u_1 and u_2 need to be changed 21 when x_1 <= r_1 then 22 reinit (u_1, w - v_1 ); 23 reinit (u_2, -v_2 ); 24 end when ; 25 end WaterTank ; Figure 3.2: Water Tank in OpenModelica Comparing it to the automaton from Fig. 2.3, there are similarities. For once, we see the same differential equations as the ones in the states q 2 and q 2. Further, the when cases in the equation part look exactly like the guard from the automaton. The only part that is missing is the domain of the state. Here, the HyAuLib helps. So far, it looks like a reasonable model of the water tank. However, we should check the details and see what happens. We have the initial water levels of 10l in both tanks. Both tanks have a minimal required water level of 5l. Both holes have a 12

25 Marcel Gehrke drainage of 1l. The water source can pour water with the constant rate of 1,8l into one tank at a time. We start in the state q 1 of the automaton. The water source is above the first tank. In the equation part, we first state der(x 1 ) = u 1 and der(x 2 ) = u 2, while u 1 = w v 1 and u 2 = v 2. Here, we define the differential equation of x 1 and x 2. Thus, we modeled the state q 1 of the automaton, besides the fact that the domain is missing. When the water level in the second tank drops to the minimal required water level or even below, we change the value of u 1 and u 2. By changing u 1 and u 2, the differential equations also change. After the change, the differential equations are x 1 = v 1 and x 2 = w v 2, which represents the state q 2 in the automaton. Now, the water level in the second tank rises again while the water level in the first tank drops. When the water level in the first tank drops to the minimal required water level or even below, the assignment for u 1 and u 2 change again to the initial assignment and the procedure starts all over again. We can see, even without the domains of the states, it seems that we have a precise model of the water tank system. Let us now see what happens when we simulate the model of the water tank Simulation At first, the simulation does exactly what we would expect, as Fig. 3.3 shows. First, the value of x 1 rises and x 2 drops. When x 2 drops down to 5, the transition is triggered and changes the state in the automaton and x 2 rises again. Since there is less water getting poured into the tanks than its draining out, w < v 1 + v 2, the water levels are converging to the minimal water levels. However, the closer the variables x 1 and x 2 are to converging to the minimal required water level, a strange behavior sets in. Namely, the water in one tank drops monotonically, it would even drop below 0 and the water level of the other tank increases monotonically. Not only the water tank system show such a behavior, but simulating the bouncing ball system from Fig. 3.1 shows a similar phenomenon in Fig While converging to 0, at some point the height of the bouncing ball becomes negative. Therefore, the bouncing ball would be under the surface on which it bounced. In the next chapter we will see how such a phenomenon can occur. 13

26 3 Modelica Figure 3.3: Water Tank Simulation in OpenModelica Figure 3.4: Bouncing Ball Simulation in OpenModelica 14

27 4 Zeno Behavior Zeno behavior is a phenomenon that can only occur in models of physical systems, either hybrid [10] or temporal logic [17]. Therefore, such a behavior can not occur in a physical system, but only in the model of that system. Roughly speaking, a hybrid system shows zenoness in case it undergoes an unbounded number of discrete transitions in a finite and bounded length of time [10]. Zenoness is a problem introduced by abstraction, especially oversimplification [16],[11]. However, abstraction is needed to build a mathematical model of a system. Thus, we do need abstraction in order to validate hybrid systems. Besides the problem of abstraction, zeno behavior is also a problem of certain combination from the domain and the guard. Introducing zeno behavior is a risk we have to take due to the fact that validating hybrid systems is crucial and we need a model to validate the system. Zeno behavior is not limited only to hybrid systems. Zenoness can also occur in systems based on temporal logic. Systems based on temporal logic normally have to adhere to timing constraints. A timed automaton models systems based on temporal logic. A way to deal with zeno behavior for timed automata is described in [17]. Throughout this chapter, we will see how such a phenomenon like zeno behavior can occur in a model of a hybrid system. We start by using the hybrid automaton of the water tank example to show how the model of the system can show zeno behavior. Afterwards, we give a definition when zeno behavior can occur. We end with the requirements for a hybrid automaton to be able to show zenoness. 4.1 Water Tank Considering the hybrid automaton of the water tank system from Fig. 2.3, there are three relevant cases. The first case w > v 1 + v 2 reflects the case that the water source adds more water to the tanks than water drains from the holes combined. In the simulation and the real world, the amount of water in the tanks rises constantly and therefore, no problem occurs. 15

28 4 Zeno Behavior In the case of w = v 1 + v 2, no problem occurs either. The water source adds the same amount of water into the tanks as water is draining from the holes combined. Therefore, the amount of water in the tanks stays the same. In Fig. 2.3, there are also guards to enter the automaton, namely x 1 > r 1 x 2 > r 2. Hence, one can enter the automaton only if there is at least as much water in each tank as required. Due to the fact that we have had enough water to begin with and that the amount of water in the tanks does not change, no problem can occur. The third and last case is the most interesting. In the simulation of the water tank, we ran into trouble when we had the case of w < v 1 +v 2. Here, zeno behavior occurs. In the real world, both tanks would be empty at some point in time. In contrast, the model of the system yields that the water levels converge to the minimal required water level. To explain such behavior, we take a deeper look at the automaton of the system Zenoness The domains and the guards of the automaton are crucial for understanding how the phenomenon of zenoness can occur. As a result from the domains and guards, we switch from q 1 to q 2 exactly when we reach x 2 = r 2 and the corresponding transition is triggered at x 1 = r 1. Let us assume we start in state q 1, having the case of w < v 1 + v 2. Now the water level in the second tank decreases until it reaches its minimal required water level. At that point, the automaton can not operate in state q 1 anymore. The transition from q 1 to q 2 is triggered and the automaton switches to state q 2. Now, we operate in state q 2 until the water level in the first tank drops down to its minimal required water level. The automaton can not operate in state q 2 anymore, but switches to state q 1 again. During every alternation, the overall water amount drops and the time needed to reach the minimal required water level decreases. The continuous variable x 1 is converging to r 1 and the continuous variable x 2 is converging to r 2. Reaching the point of convergence, x 1 = r 1 and x 2 = r 1, the automaton can not operate in either of the states anymore. If the automaton would operate in either state, the state would violate its domain. Thus, the automaton switches the states instantly after entering a state. As we can see, the automaton undergoes an unbounded number of discrete transitions in a finite and bounded length of time. In case a hybrid automaton undergoes such behavior, it shows zeno behavior. Here, we also see the difference between the physical system and the hybrid automaton. In the physical system, the water 16

29 Marcel Gehrke tanks will be empty at some point in time, while in the hybrid automaton, showing zenoness, the water level will never sink below the threshold. The abstraction and the resulting model of the physical system are not completely reflecting the physical system. However, due to oversimplification, the model behaves the way we would want the physical system to behave. One problem we can see here, is that the abstraction can introduce faults. In our case, it does not take into consideration the time the physical system needs to switch the water source from one tank to the other. While the physical system needs some time to change from one water tank to the other, the hybrid automaton switches from one state to another instantly Simulation In Fig. 3.3 and Fig. 3.4, we see a rather strange behavior, while the continuous variables, x 1 and x 2, converge to the minimal required water level. What we see here, can be explained by zeno behavior paired with numerical integration methods. Simulations of hybrid systems use numerical integration for the computation of the differential equations. Even using different numerical integration methods can result in different outcomes for the same simulation [3]. Due to the fact that we have infinite state transitions in a finite time, in case the system undergoes zeno behavior, the behavior we see in Fig. 3.3 and Fig. 3.4 can be explained. For every state transition, an error correction has to take place using numerical integration. Having infinitely many transitions, these error correction may not work correctly anymore and such a behavior can occur [3]. 4.2 Zeno Set For determining the zeno set, we need to examine the zeno executions. Zeno executions are runs of the system that show zeno behavior. A point (q, x) Q X is a zeno point if it is a convergence point of a zeno execution with infinite transitions in a finite time. During simulating, if the continuous variables converge to a zeno point the simulation might yield a false result. The zeno set of a zeno execution is the set of all its zeno points. Having all of the zeno points in a set, makes it easier to validate our simulation results by checking that no continuous variable is converging to a zeno point. In this case, the result is not falsified. If a continuous variable converges to a point in the zeno set, the simulation can show zenoness. Then, the modeler has to check again whether the zenoness falsified the outcome of the simulation. Z Q X denotes the zeno set [20]. 17

30 4 Zeno Behavior There are also different zeno types. In case all executions show zeno behavior, the hybrid system is called strongly zeno. A hybrid system is called (weakly) zeno if at least one run in the system is a zeno run [10]. 4.3 Reset Map The reset map is called identity if the value of a continuous variable does not change during a transition. A reset map is called non-expanding in case: δ [0, 1]s.t. e E, x G(e), x R(e, x) : x δ x. x denotes the euclidean norm of x. The non-expanding reset map yields that the new values of the continuous variables after a state transition can either stay the same as described in the identity case or decrease. The reset map could be used to model a damping coefficient or to simulate a delay. 4.4 Detecting a Zeno Set Detecting a zeno set can be achieved by applying certain steps, which we are going to explore in this section. First of all, we have to determine when a hybrid automaton can show zeno behavior to make a statement about the zeno set. A cycle is a prerequisite for a hybrid automata to accept zeno executions, which is formulated in Proposition 1. Reach H denotes the set, which contains all reachable states for the automaton H. Proposition 1. If there exists a finite collection of states {(q i, x i )} K i=1 such that (q 1, x 1 ) = (q K, x K ) x i+1 = (q i, q i+1, x i ), i = 1,..., K 1 (After taking a transition, the values of the continuous variables are defined by the reset map); and (q i, x i ) Reach H, i = 1,..., K; then the hybrid automaton accepts a zeno execution [20]. 18

31 Marcel Gehrke Using the reset map, it is possible to make statements about the zeno set in case the automaton accepts a zeno execution. Before we can give a statement about the zeno set, we need a few definitions. Let Ū denote the closure of the set U, U 0 its interior, and U = Ū \ U 0 its boundary. Further, we call the set of states, which are infinitely often visited, Q. Theorem 1. A hybrid automaton with a non-expanding reset map, which accepts zeno executions, has the following zeno set: Z = {(q i, x i )} m i=1, m > 0 If G(q, q ) D(q) 0 =, (q, q ) E with q, q Q then x i D(q i ) for all i = 1,..., m. Thus, the zeno set of a hybrid automaton with a non-expanding reset map accepting zeno executions consists of the boundaries of the domain if the intersection of the guard and the interior of the domain is empty for every transition of the cycle. Using this result, the following non-zeno condition follows. Corollary 1. A hybrid automaton with identity reset map does not accept zeno executions if G(q, q ) D(q) 0 =, (q, q ) E, for all cycles {q i } K i=1 with q K = q 1 and (q i, q i+1 ) E, 1 i K 1, K 1 i=1 D(q i) =. Hence, a hybrid automaton does not accept zeno executions if for every transition of the cycle the intersection of the guard and the interior of the domain is empty, and if for every cycle, the intersection of the boundary of the domains is empty. Theorem 1 and Corollary 1 correspond to Theorem 3 and Corollary 1 from [20]. Cycle I NE G(q, q ) D(q) 0 = Zeno Set Zeno Behavior x i D(q i ) YES No clear statement MAYBE No clear statement MAYBE K 1 i=1 D(q i) = NO K 1 i=1 D(q i) YES - do not care NO Table 4.1: Conditions for Zeno Behavior Table 4.1 contains all possibilities whether a hybrid automaton can show zeno behavior. In every case but the last, the automaton contains a cycle. The first case 19

32 4 Zeno Behavior reflects Theorem 1. The hybrid automaton possesses a non-expanding (NE) reset map. Thus, the automaton allows zeno executions. Furthermore, the intersection of the guard and the interior of the domain is empty for every transition of the cycle. Hence, the boundaries of the domain are elements of the zeno set. Since the zeno set is not empty, it is possible for the automaton to show zeno behavior. The second case has nearly the same setup as the first. The only difference is that the intersection, for every transition of the cycle, of the guard and the interior of the domain is not empty. Therefore, we have an overlapping interval between the guard and the domain. Such an overlapping interval makes it impossible to determine when the automaton triggers the transition. Hybrid automata are nondeterministic, hence, the transition can be triggered at any time after the guard holds true. Having an overlapping interval, it is also possible for the automaton to keep operating in the current state. Hence, zeno behavior could occur if the transition would always trigger instantly, but does not if the automaton operates longer in the state. The same argumentation holds true for the third case. In both setups, we can not make a clear statement about the zeno set. Even more, zeno behavior can occur in the automaton but not necessarily, resulting in MAYBE zeno behavior. The fourth and fifth case relates to Corollary 1. The automaton possesses an identity (I) reset map. Furthermore, the intersection of the guard and the interior of the domain is empty. Now, the intersection of the boundaries of the domain for every state in the cycle is important. In the fourth case, the intersection is empty. Therefore, the automaton can not show zeno behavior. In the fifth case, the intersection is not empty. Due to Corollary 1, the automaton is not zeno free but shows zeno behavior. The zeno set consists of the intersection of the boundaries of the domain for every state in the cycle. Finally, we have the case of no cycle. Having no cycle implies that the automaton can not show zeno behavior. Theorem 1 and Corollary 1 and therefore, Table 4.1 are used for the zeno detection in the tool. 20

33 5 Tool for Zeno Set Detection Knowing what zeno behavior is and when it can occur, we now focus on detecting it automatically. In this chapter, we will take a closer look at the tool for detecting zeno sets which I implemented. The tool for zeno set detection is a command-line tool written in Haskell. Generally, the tool goes through the following steps: The tool takes an automaton in a file as input. It parses the automaton into a data structure. The tool uses the algorithm of Robert Tarjan, Enumeration of the Elementary Circuits of a Directed Graph [19], to detect cycles. The cases described in Table 4.1 form the basis for the implementation of the following part of the tool. After the cycle detection, the tool checks whether the automaton contains any cycles. If the tool finds a cycle, it continues with the calculation of the reset map of the first cycle. Otherwise, it stops and generates the output that no zeno behavior can occur. The next step is to intersect the guard with the interior of the domain for every transition in the cycle. After the computation of the intersection, the tool checks if all intersections are empty. In case the intersections are not empty, the tool proceeds to generating the output for the overlaps in a readable format. Otherwise, the tool has to consider the reset map. For the non-expanding reset map, the tool calculates the zeno set as described by Theorem 1. By calculating the boundaries of the domain for every state, the tool generates the zeno set for the cycle and stores the result. For the identity reset map, the tool first has to check whether the intersection of the boundaries of the domains of every state in the cycle is empty. In case the intersection of the boundaries is empty, we know that the cycle is zeno-free. Otherwise, the intersection is the zeno set, which is saved after being formatted in a readable output. Thereby, the tool covers all cases of Table 4.1. In case more than one cycle has been detected, the tool starts over with the next cycle until all cycles are evaluated. At the end, the tool prints the results of the evaluation of all cycles, i.e., the overlap, the zeno set, or the observation that no zeno behavior can occur. To picture the steps of the program more clearly, a control flow graph is given in Fig. 5.1 in the next subsection. The tool was developed using Mac OS X, version , with GHCi, version To execute the tool, the library Data.IntervalMap.Interval is needed. It can be downloaded using cabal (cabal install IntervalMap). Version of Data.IntervalMap.Interval was used for the development. 21

34 5 Tool for Zeno Set Detection Control Flow Graph input file parse input file into the data structure detect cycles yes automaton correct? no error automaton contains cycle? yes take intersection of the guards with interior of the domains intersection empty? no generate overlap yes reset map? identity non-expanding take intersection boundaries of the domains intersection empty? yes no no zeno free generate zeno set yes more cycles? no printout Figure 5.1: Control Flow Graph of the Tool In the next section, we give requirements the modeler has to follow to ensure that the tool works correctly. 22

35 Marcel Gehrke 5.1 Specification There are a few properties of the automaton in the input file that have to hold. First, we have the grammar which defines the syntactic structure of the input files. Second, we have general properties. The general properties add requirements not captured by the grammar as well as some invariants Automaton Grammar A file has to contain exactly one automaton. The grammar of the file is defined the following way: Automaton; ((State T ransition) ; ) + State = State, Name, Start, Domain, Equations Name = [a z, A Z, 0 9] + Start = T rue F alse Domain = Conditions Equations = Equation Equation(, Equation) + Equation = [a z, A Z, 0 9, =, ] + T ransition = T ransition, Source, Dest, Guard, Reset Source = Name Dest = Name Guard = Conditions Reset = 1 (0.[0 9] + ) Conditions = Condition( AND Condition) Condition = ContinuousV ariable Comp (V ar Number) ContinuousV ariable = ([0 9] [a z, A Z] + [0 9] ) + V ar = ([0 9] [a z, A Z] + [0 9] ) + Number = ([0 9] + ) ([0 9] + ).([0 9] + ) Comp = (< >) ((< > =) =) General Properties The additional properties that have to hold are: The hybrid automaton has to be correct and specified as a set of states and transitions. 23

36 5 Tool for Zeno Set Detection Neither the state set nor the transition set is permitted to be empty. There exists only one transition from one state to another. Therefore, the combination of source and destination is unique in the set of transitions. More formally said, the transitions have to be deterministic. A continuous variable must not be restricted more than twice in either a guard or a domain. In case a continuous variable is bounded with another continuous variable, the reversed case has to be inserted, meaning x 1 <= x 2 and x 2 >= x 1. The boundaries of the guard of a transition have to lie inside the boundaries of the destination state in case the continuous variables are bounded from the same side in both state and guard. If a continuous variable is restricted twice, it must be restricted with < <= and > >=, but not any other combination. x > >= < <= == Figure 5.2: Boundaries of a Continuous Variable of the Tool To elaborate on the last point, Fig. 5.2 shows the operations that can be applied to a continuous variable. If only one restriction is applied on a continuous variable, no problem can occur. For the case of having two restrictions, one from above and one from below is the only reasonable pair. However, if a continuous variable is bounded twice from the same side in either a guard or a domain, the tool does not consider the second restriction. Having more than two restriction is not reasonable either. If the automaton of the input file violates either of these properties, I can not guarantee a correct result of the tool. 24

37 Marcel Gehrke 5.2 Tool Description In this section, we give a more detailed description of the tool. Further, we will see how the tool makes use of the requirements defined in the previous section Parsing and Cycle Detection The tool requires a representation of a hybrid automaton in Haskell. A data structure for a hybrid automaton is used for that purpose. The data structure allows parsing of the automaton from the input file. While parsing the input file, the tool parses every line separately. The end of a line in the file is represented by the symbol ;. Due to the grammar, the first line of the file must only contain the word Automaton. If the first line does not start with Automaton, the execution stops and returns an error. Otherwise, the tool proceeds to parse the next line. From now on, every new line has to start with either the word State or Transition, as defined by the grammar. In case the new line does not start with one of the words, the tool returns an error. If the new line starts with the word State, the tool checks whether all elements of the state are defined. By separating the line after each, the tool retrieves the elements and checks whether the line consists of at least four elements after State indication. Otherwise, it returns an error. Next, the tool proceeds to parse every element by itself. While parsing the elements the order, as specified in the grammar, is crucial, e.g. the first element after State is parsed as the name of the state. For the conditions, we recursively check if there is an AND, and combine the restrictions. In case there are more than four elements, the state has more than one equation. These elements are recursively added to the other equations. If either of the elements do not meet the grammar, the tool returns an error. In case the new line starts with the word Transition, the tool behaves similarly to the case of State. It checks whether there are at least four elements separated by the symbol, after the Transition. If there are less than four elements, the tool returns an error. In case enough elements can be found, the elements are read as follows: The first element is parsed as the source of the transition. The second element is translated into the destination. The source as well as the destination should refer to the name of a state. Parsing the third element, the conditions, works exactly like parsing the condition in a state. The tool recursively parses the input file until all lines are parsed. After the file is parsed, the tool continues with a cycle detection. For the cycle detection, I implemented the algorithm Enumeration of the Elementary Circuits 25