Translation of Modelica Code into Hybrid Automata

Transcription

1 Research Project Madhumitha Hariharan Translation of Modelica Code into Hybrid Automata December 15, 2016 supervised by: Prof. Dr. Sibylle Schupp Mr. Timo Kamph Hamburg University of Technology (TUHH) Technische Universität Hamburg-Harburg Institute for Software Systems Hamburg

2

3 Contents 1 Introduction Motivation About the tool Report Outline State of the art The modeling language Modelica Hybrid Automata Existing research work OpenModelica Algorithm and Implementation The translation algorithm Implementation Input to the tool Parsing and data storage Substitution Translation Result from the tool Tool evaluation 31 5 Conclusion and future work Conclusion Future work Bibliography 39 3

4

5 List of Figures 1.1 Overview of the tool Example of an algebraic loop Low-Pass RLC Filter circuit [7] Modeling RLC circuit using Modelica [7] Thermostat Automaton [8] Simulation result of Voltage in OpenModelica Debug message for RLC Processes performed by the translation tool Variables section in the intermediate representation of RLC model Equations section in the intermediate representation of RLC model Parameters section in the intermediate representation of RLC model Tree structure of equation: i_r = V / R Tree structure of equation: der(v) = i_c / C Tree structure of equation: der(i_l) = (vb - V) / L Tree structure of equation: i_c = i_l - i_r Updated tree structure for figure 3.4: y(2) = x(2) / Updated tree structure for for figure 3.5: der(x(2)) = y(1) / Updated tree structure for figure 3.6: der(x(1)) = ( x(2)) / Updated tree structure for figure 3.7: y(1) = x(1) - y(2) Change in tree structure: 0 = x(2) / (y(2)) Change in tree structure: 0 = x(1) - y(2) - (y(1)) Output file from the translation tool Tool input model Console message for model Output file of model Console messages for RLC model Model 3 (discrete behaviour with if-equation) Console messages for model Output file of model Model with when-equations Console message for model with when-equation

6

7 List of Tables 3.1 C++ STL Map Structure for Variables C++ STL Map Structure for Parameters Substution of equations Translation of equations

8

9 1 Introduction 1.1 Motivation Cyber-physical systems (CPS) are the new and continually evolving technology where the physical and software worlds interact. A CPS is composed of computing devices interacting with each other and with the physical world via physical devices such as sensors in a feedback loop. They are hybrid systems, which means they encompass both discrete and continuous dynamics. Such systems are found in all fields such as automotive, aerospace, and telecommunications. Examples of CPS are smart grids, smart phones, and several sensor based communicational autonomous devices. The modeling of a CPS is an important step in studying such systems as models are the ultimate tools for obtaining and dealing with knowledge[1]. Hybrid systems compose of discrete and continuous sub-systems. Therefore, hybrid systems theory studies the behaviour of dynamical systems, the modeling formalisms that involve both continuous models such as differential or difference equations describing the physical and mechanical part, and discrete models such as finite state machines or Petri nets that describe the software and logical behaviour[2]. There exist several models that represent hybrid systems that include hybrid automata, timed automata, switched systems and hybrid inclusions. There are several modeling languages that successfully model hybrid systems. One such language is Modelica (more about Modelica in chapter 2). There are several simulation tools available for Modelica models such as OpenModelica and Dymola. These tools can be used to test the systems based on the simulation results. Modern CPS applications increasingly operate in social spaces, where humans play an important part in the overall system[3]. Hybrid systems are applied in safetycritical applications, making reliability a prime concern [8]. To ensure the reliability and correctness of the system, it is therefore required to perform verification of the system. Although there are simulation tools, there are no verification tools for Modelica. Existing verification tools can take in models generated by model classes such as Hybrid Automata. A specific tool is thus needed that can convert Modelica models into Hybrid Automata. The research presented here deals with this translation of models created using Modelica into Hybrid Automata models. 9

10 1 Introduction 1.2 About the tool To tackle the problem presented in the previous section, a tool is created using the object-oriented language C++, that can take in Modelica models and translate them into Hybrid Automata. The overview of the tool is shown below in figure 1. The modeling of the CPS is done using the modeling language Modelica. The models thus created are simulated using the simulation tool OpenModelica. The tool generates several simulation results including graphs to track the progress of the variables from the start through the end of the simulation. In addition to this, an intermediate representation of the model is generated as a debug message in the tool. This representation is taken as the input to the tool that translates the Modelica model into hybrid automaton. The representation undergoes several transformations as per the translation algorithm (described in section 3.1), to be modeled as a hybrid automaton. Figure 1.1: Overview of the tool 1.3 Report Outline This report consists of 5 chapters and a reference section. Chapter 2 discusses the state of the art where the basics of Modelica and Hybrid Automata needed to understand the research are presented, and also an overview of existing, similar algorithm is described. In Chapter 3, the algorithm that forms the base of the tool, and each step in its implementation are discussed. Chapter 4 is analyses the results achieved. A summary of what is accomplished, and the future work is presented in Chapter 5. 10

11 2 State of the art This chapter presents the fundamentals of the modeling language Modelica, the modeling class Hybrid Automata, the simulation tool OpenModelica, and an existing algorithm that translates Modelica models into linear hybrid automata. 2.1 The modeling language Modelica Modelica is an object-oriented modeling language used for the physical modeling of CPS. Traditional methods for physical modeling of hybrid systems were not effective in their target of simulation. Modern methods build on non-causal modeling with true equations and the use of object oriented constructs to facilitate reuse of modeling knowledge[4]. In this modeling paradigm, users do not specify the relationship between input and output signals directly (in terms of a function), but rather they define variables and the equations that they must satisfy[5]. There exist several modeling languages following such an approach such as ASCEND, Dymola [4]; Modelica is a unified concept of such languages with the common basic semantics. Hybrid systems are complex in nature and span a large number of physical domains. It is therefore more understandable and readable if the modeling language is hierarchical in nature. Modelica follows hierarchical modeling, which means it models the systems as connected subsystems or submodels on an explicit state-space form[4]: = f(x, u) y = g(x, u) dx dt In the above form, y is the output and u is the input. The connections of outputs and inputs must not lead to algebraic loops[4]. Algebraic loops occur when there is a signal loop at a block where the input value directly controls the value of the output, for example: 11

12 2 State of the art A Modelica model is built from[6]: Figure 2.1: Example of an algebraic loop basic types such as Real, Integer, Boolean, and String structured components, to enable hierarchical structuring component arrays, to handle matrices of real numbers, arrays of submodels, etc equations algorithms that compose of assignment statements connections describe physical connections using a connector class functions implement an algorithm that has public input and output There are different kinds of variables such as the ones mentioned above. There are means to declare the variables, give values for parameters and specify the initial conditions. Let us consider a simple RLC circuit as in the following figure to understand the above mentioned components: Figure 2.2: Low-Pass RLC Filter circuit [7] The resistor with resistance R, inductor with inductance L, capacitor with capacitance C are the components of the model. The behaviour of the model is described by 12

13 2.1 The modeling language Modelica equations. Assume we need to solve for the voltage V and the currents i L, i R and i C that pass through the inductor with inductance L, the resistor with resistance R, and the capacitor with capacitance C respectively. In order to solve for the components, the equations are defined as follows [7]: V = i R R C dv dt L di L = i C dt = (V b V ) i L = i R + i C Modeling this circuit in Modelica is as follws: Figure 2.3: Modeling RLC circuit using Modelica [7] Going through above model line-by-line, line 1 defines the name of the model as RLC1. The text following ("A resistor-inductor-capacitor circuit model") is a small description of the model. The lines 2-6 introduce the types Voltage, Inductance, Current, Resistance, Capacitance, and Inductance specializing the predefined type Real respectively. The types are also associated with their respective units. Lines 7-10 define parameters, that is, the physical characteristics of the circuit. parameter is a specifier for the variable which indicates that the value of the variable is a constant during the simulation run and therefore its derivative is zero. The value can be modified in between simulation runs or during a component reuse. The component name can be followed by a modification to change the value of the component or its attributes [6]. Lines define 13

14 2 State of the art the variables which need to be solved for. Line 15 marks the beginning of the equations section. Lines define the equations that describe the behaviour of the system and generate solutions when simulated. Finally, line 20 closes the model. 2.2 Hybrid Automata As the Modelica models have to be translated into Hybrid Automata, it is helpful to understand the basics of Hybrid Automata. Hybrid automata result as an extension of finite-state machines by associating with each discrete state, a system of differential or difference equations that describe how in this discrete state the continuous state evolves [1]. A Hybrid Automaton H is a model class consisting of the following components [8]: A finite set X = x 1,..., x n of real-numbered variables where n is the dimension of H. The first derivative during a continuous change on these variables is denoted by the set Ẋ = ẋ 1,..., ẋ n and the values at the conclusion of a discrete change as X = x 1,..., x n. Control graph (V, E) where V, the vertices denote control modes and E, the edges denote control switches. Each control mode v V defines the continuous dynamics in it by predicates from the functions initial (init(v)), invariant (inv(v)) and flow conditions (flow(v)). Each control switch e E is defined by a predicate that comes from a jump condition jump(e). A finite set of events Σ and the function event E Σ assign an event to each control switch. Let us consider an example of a simple Thermostat to be modeled as a hybrid automaton: Figure 2.4: Thermostat Automaton [8] 14

15 2.3 Existing research work Defining each component of the thermostat automaton H: x is the variable that denotes the temperature to be maintained by the thermostat. The control graph consists of two control modes Off and On and two control switches that defines the transitions between the two modes. The initial condition is that the thermostat is off with a temperature of 20 degrees denoted by x = 20 (input to the control mode Off ). The invariant x 18 in the control mode Off denotes that the heater must switch to the control mode On at the latest when the temperature falls below 18 degrees and in the case of the invariant x 22 in the On mode, the heater must switch to the Off mode when the temperature reaches 22 degrees. The jump conditions x > 21 and x < 19 define that, the heater can switch from the mode On to mode Off when temperature is above 21 degrees, and from mode Off to mode On when the temperature is below 19 degrees respectively. The invariant in each of the control mode define the threshold for the continuous dynamics in each mode. When the temperature reaches the threshold, there is a jump to the other control mode governed by the jump conditions. This jump is an event and is denoted by the jump conditions and invariants, which are the event generators [1]. 2.3 Existing research work Conversion from Modelica to Hybrid Automata is not a new research. There have been researches in the same line with slightly different problems and approaches. One such algorithm has already been developed to translate Modelica model to a linear hybrid automaton. The algorithm presented in the paper "Towards automatic generation of model checkable code from Modelica" aims at creating models for HyTech, a tool for the analysis of embedded systems [9]. As HyTech uses linear hybrid automata formalism, the algorithm is designed in a way to build a model equivalent to the original model, isolating the discrete control modes. The algorithm uses program slicing approach to isolate the linear part where there are no dependencies from linear to the nonlinear variables. The discrete variables that do not appear along with the continuous variables are not added in the model. Instead, they appear as synchlabs in the resulting translated model. Synchlabs are synchronization variables that synchronize the control switches. The translation begins by searching for variables. The state variables of Modelica are added as continuous variables. The clock variables and also the discrete variables that come together with continuous variables are also added. The starting control mode is then created using the initial conditions. The when-equations are then identified and subsequent control modes are created for each new transition. The algorithm produces a code for automation in HyTech with information about synchlabs, initial conditions, and locations. 15

16 2 State of the art 2.4 OpenModelica OpenModelica is an open source modeling and simulation tool for Modelica. On simulating the RLC1 model in OpenModelica, the circuit is modeled and simulated for the voltage and currents (as described in section 2.1). A graph view of the simulation generated by the tool helps tracing the evolution of various variables through the simulation. The following graph indicates the evolution of Voltage over time: Figure 2.5: Simulation result of Voltage in OpenModelica The right-most pane in the figure shows the variables of the system and their values. The last variable time is an in-built variable in Modelica that indicates the simulated time. In addition to this, a debug message is also generated. This message is from the Modelica complier, which displays information about the variables, parameters, and the equations in an explicit state-space form. Recalling the equations from the RLC circuit example from chapter 2, the equations described in Modelica will be of the following form: V = i R R C dv dt L di L = i C dt = (V b V ) The last equation is the Kirchoff s current law: i L = i R + i C The explicit state-space form from the debugger will be: i R = V/R der(v ) = i C /C der(i L ) = (V b V )/L i C = i L i R The biggest advantage of Modelica is that the developer does not have to write the equations in this form, but stick to the textbook form [7]. The conversion of the equations from the textbook form to the explicit state-space form is done by the compiler. The debug message for the RLC1 circuit is in the following figure: 16

17 2.4 OpenModelica Figure 2.6: Debug message for RLC1 17

18

19 3 Algorithm and Implementation The translation algorithm aims at translating the Modelica models into Hybrid Automata. In the previous chapter, an existing research work was presented, which also translated Modelica models into linear hybrid automata. The algorithm targeted on the continuous variables and the part where the discrete variables affects the continuous variables. The discrete variables that did not occur with the continuous variables were added as synchlabs. But this algorithm cannot be used for a CPS because for CPS both the linear and non-linear behaviour need to be modeled. 3.1 The translation algorithm The translation algorithm works on the debug message from OpenModelica, which is the intermediate representation of the model. The algorithm spans over four steps which are as follows: Step one: The file that contains the intermediate representation is parsed to obtain the information needed for converting the code to a Hybrid Automaton - equations, parameters and variables. Step two: The state variables and other algebraic variables are stored with new variable names to be modeled as a hybrid automaton; parameters are stored along with their values and the equations are stored as trees, creating new locations (control modes) in case of discrete jumps, i.e., if equations (more about data structure in section 3.2.1). Step three: The variables and parameters in the equations are substituted by their new names and values respectively. Step four: The equations are transformed to semi-explicit form by modifying the equation trees. The steps three and four are repeated for all equations. The tool processes are summarized in the figure 3.1: 19

20 3 Algorithm and Implementation Figure 3.1: Processes performed by the translation tool 3.2 Implementation Input to the tool The algorithm is implemented by a tool built using C++. The input to this tool is the file that contains the intermediate representation (debug message from OpenModelica) of the Modelica model. It is better to work on the intermediate representation than 20

21 3.2 Implementation the model itself because the former provides equations in their explicit state-space form whereas the latter sticks to the textbook form of the equations as described in the previous section. In this section and the sections to come, the RLC circuit will be used as the example to explain the details. Revisiting the intermediate representation of the RLC ciruit model, there are three sections of the intermediate representation that are of interest: 1. Variables - this section contains a list of variables as in the figure below. Consider the first variable for example: it can be seen that i_c here is the variable name, the description that says VARIABLE means it is an algebraic variable, the unit, and the type that follow are not of interest. Similarly, the third line describes the variable named i_l. The description says STATE which means it is a differential variable. The variables that undergo a differentiation when their values are changed are differential variables. The variables that never undergo differentiation are algebraic variables. Figure 3.2: Variables section in the intermediate representation of RLC model 2. Equations - this section lists all equations that are specified in the model in their explicit state-space form as described in the previous section: Figure 3.3: Equations section in the intermediate representation of RLC model 3. Parameters - this section lists the parameters used and their values as in the figure below. Considering the first parameter, the parameter name here is Vb and its value is The rest of the text is not of interest. 21

22 3 Algorithm and Implementation Figure 3.4: Parameters section in the intermediate representation of RLC model Parsing and data storage The first step is to get the intermediate representation as a file input. Once the input is obtained, the tool starts parsing the file. The process proceeds as follows: The file is read to create objects to hold variables, equations, and location information (control modes). Each time a discrete behaviour (if-equation) by an if is encountered, it leads to the creation of two locations (control modes) - one for the branch that will be executed if the condition (invariant) evaluates to be true and one for the branch that will be executed otherwise. This is because, the if-equation compares the variable inside a bloc (or control mode) to a threshold value. When the threshold value is reached, it triggers a jump to another block (or control mode). Creation of a new location means creation of a new object to hold its equations, invariants, and reference to the respective variables. For example, in the RLC model, assume a switched behaviour the Voltage V should be zero until 0.5 seconds and then should be equal to the parameter Vb: V = if time > 0.5 then Vb else 0 This needs creation of two locations: Location 1: Equation: V = V b Invariant: time > 0.5 Variable: V Parameter: V b = 24.0 Location 2: Equation: V = 0 Invariant: time 0.5 Variable: V This process executes in loop through the Equations section. Once the locations (control modes) are created, it is then the next step, to store them in their respective data structures: 22

23 3.2 Implementation Variables are given new names state variables are stored as x(1),..., x(n) and algebraic variables are stored as y(1),..., y(n). The variables are stored in C++ STL Maps. A mapping is required so as to facilitate an easy way to trace the variable back to its old name after the translation or even at the next steps in the algorithm. Parameters are stored in C++ STL Maps. It is important to create a map structure for the parameters so that in the next step, a search can be made with the parameter name and the mapping would help substitute its value. Equations are stored as an in-order tree with the nodes occupied by the operators and the operands (variables) because it is then easy to access each of the variables for the substitution and translation steps and also gives the order of precedence that helps in reconstructing it back from the memory as an equation. The data structure for the variables looks as in the table below. The variables i_c and i_r are algebraic as they do not undergo any differentiation (as indicated by their description in the intermediate representation described under Input section) and the variables i_l and V are differential variables. The variable name from the intermediate representation is the key (left column in table 3.1) and new name in the tool is the data (right column in table 3.1) Table 3.1: C++ STL Map Structure for Variables i_c y(1) i_r y(2) i_l x(1) V x(2) The parameters are stored as in the table below, with parameter names as key (left column in table 3.2) and values as data (right column in table 3.2) Table 3.2: C++ STL Map Structure for Parameters Vb 24.0 L 1.0 R C The tree structures of the equations are presented in the figures below. For example, consider the first equation i_r = V/R The equation is broken at the "=" which forms the root node of the tree. 23

24 3 Algorithm and Implementation The left sub-tree stores the left side of the equation (in this case i_r), and the right subtree stores the right side of the equation (v/r). All the equations are stored following this procedure. Figure 3.5: Tree structure of equation: i_r = V / R Figure 3.6: Tree structure of equation: der(v) = i_c / C 24

25 3.2 Implementation Figure 3.7: Tree structure of equation: der(i_l) = (vb - V) / L Figure 3.8: Tree structure of equation: i_c = i_l - i_r 25

26 3 Algorithm and Implementation Substitution Once the model is parsed and the data are stored, the next step involves changing the variable names and replacing parameter names with values in the equation tree. The substitution process is as follows: For each variable in the variable map structure, an in-order tree traversal on every equation is performed, searching for the variable with its name from the intermediate representation in the tree. When the variable is found in one of the nodes, the new name from the map is retrieved and is replaced with the new variable name. The search spans the entire tree, replacing the name of the variable, in every node the variable is found. For example, consider variable i_r. The equations that make use of this variable are: i R = V/R i C = i L i R The in-order traversal of the equation tree of the first equation will be: i_r = V / R Once the traversal begins, the variable name could be found in the very first node, the mapping would give the new name as y(2) (from table 3.1). The value of the node will then be changed from i_r to y(2). The search will be continued in the same order and replace if any other node contains i_r. The same process is carried on with the other equation. All variables are substituted in all equations similarly. Parameter substitution is also carried out in the same way using parameter name and substituting its value. An overview of the original equations and the substituted equations can be seen in the following table: Table 3.3: Substution of equations Original equations Substituted equations i_r = V / R y(2) = x(2) / der(v) = i_c / C der(x(2)) = y(1) / der(i_l) = (vb - V) / L der(x(1)) = ( x(2)) / 1.0 i_c = i_l - i_r y(1) = x(1) - y(2) The changes to the equation trees are as follows: 26

27 3.2 Implementation Figure 3.9: Updated tree structure for figure 3.4: y(2) = x(2) / Figure 3.10: Updated tree structure for for figure 3.5: der(x(2)) = y(1) / Figure 3.11: Updated tree structure for figure 3.6: der(x(1)) = ( x(2)) /

28 3 Algorithm and Implementation Figure 3.12: Updated tree structure for figure 3.7: y(1) = x(1) - y(2) Translation Hybrid Automata describe the continuous dynamics inside the discrete control modes using semi-explicit DAE. Therefore, translation is done based on the following conventions: Differential equations: the equations represent the evolution of the state variable in its location (control mode), i.e., the derivative (or the next state) of the state variable stays on the left side of the equation. The tool assumes this structure to be established by the model itself. Algebraic equations: the algebraic expression evaluates to zero, i.e., the equation is altered in such a way that the entire expression remains on one side of the equation. Translation changes the structure of the tree. The left side of the equation is brought to the right side, which will cause a shift in their respective tree nodes. As for the differential equations, there is no change, as the structure in the intermediate representation can be taken as such. In case there is a deviation to the structure of the differential equation, then the model is not accepted. The process of translation goes as follows. Consider the following algebraic equation: y(2) = x(2)/100 Recalling the tree structure of this node, root node contains "=", the left sub-tree contains left side of the equation, and the right sub-tree contains the right side of the equation. The tree after substitution was shown in figure 3.8. Translation on this tree goes as follows, the target is to achieve the equation: 0 = x(2)/100 (y(2)) The left child of the root is assigned to a temporary node, say temp1. The value of this node is then changed to zero, its child nodes (if any) are freed and, the pointers to its left and right child nodes are assigned to NULL. 28

29 3.2 Implementation The right child of the root is also assigned to another temporary node, say temp2. The value of this node is then changed to. The left pointer of this node now points to temp1 and its right pointer points to temp2. The changes to the trees of the two algebraic equations from the example model can be seen as follows: Figure 3.13: Change in tree structure: 0 = x(2) / (y(2)) Figure 3.14: Change in tree structure: 0 = x(1) - y(2) - (y(1)) An overview of the changes brought about by translation is represented by the following table: 29

30 3 Algorithm and Implementation Table 3.4: Translation of equations Substituted Equations Translated Equations y(2) = x(2) / = x(2) / (y(2)) der(x(2)) = y(1) / der(x(2)) = y(1) / der(x(1)) = ( x(2)) / 1.0 der(x(1)) = ( x(2)) / 1.0 y(1) = x(1) - y(2) 0 = x(1) - y(2) - (y(1)) 3.3 Result from the tool As mentioned in the earlier sections, the tool writes the hybrid automaton representation to a file. For the example considered in the previous chapter, the output looks as in figure 4.1. The example considered was a simple model with no discrete behaviour. Therefore, it can be seen that there is no explicit location (control mode) information. In case of a discrete behaviour, there would be distinct locations (control modes) with their respective equations and invariants (more in the section 4.2). It can be seen from the figure 4.1 that the information are represented in three sections - differential equations, algebraic equations and variables. The translated equations are represented in the first two sections; variables with their names from the intermediate representation and new names are shown under the third section. The variables section is helpful when the information about how the variables evolve in the system is needed. Figure 3.15: Output file from the translation tool 30

31 4 Tool evaluation This chapter analyses the tool based on the results from the tool. The models used are from the book "Modelica by Example" ([7]). In order to evaluate the tool, in addition to the output file, the messages on the console are also considered. The messages displayed are intermediate step results. To begin with the tool is given a simple model with one equation involving one variable and no parameters: Figure 4.1: Tool input model 1 The message on the console is as follows: 31

32 4 Tool evaluation Figure 4.2: Console message for model 1 As from the messages, the equations are categorized into algebraic and differential equations. The differential equation in the input is of the acceptable form (as described in section 3.2.4). As there is only one equation in the system and it is a differential equation, it can be seen that the classification is done correctly. The variable name changed is also displayed. Here x being a differential variable, it is assigned the name x(1). The equation displayed after substitution is updated with the new variable name and the translated equation has the same structure as that of the original equation as explained in section The output file thus looks as follows: Figure 4.3: Output file of model 1 Let us now recall the RLC circuit from previous chapters. The console messages for this model are in the following figure: 32

33 Figure 4.4: Console messages for RLC model Here there are equations under both differential and algebraic equation types. The displayed differential equations involve differentiation of one of their variables and the algebraic equations do not contain any differentiation. Therefore the classification is correct. The variables V and i_l are the differential variables, and i C and i R are algebraic variables (from section 3.2.2). Therefore the naming of the variables is also correct. The values of the parameters are extracted from the input file. The substituted equations also have the variable names and parameters substituted. The translated algebraic equations have a zero on the left side. The right side of the new equation shows the difference between the right and left side of the original equation. This is therefore mathematically correct. The output of the RLC model was shown in the section 3.4. Now let us consider a discrete behaviour caused by an if-equation: 33

34 4 Tool evaluation Figure 4.5: Model 3 (discrete behaviour with if-equation) This model has a single equation involving one variable and one parameter. The console messages for this model are as follows: Figure 4.6: Console messages for model 3 The first line says "1 objects created for location 2". On reading the file, the tool automatically creates an additional object for location 2 whenever a discrete behaviour is detected. Therefore it can be seen that the tool has created 2 control modes. The 34

35 equation is a differential equation and therefore the naming and translation is done similar to the above two models. The output file looks as follows: Figure 4.7: Output file of model 3 In the input file, the condition of the if-equation was: noevent(sin(6.28 f req time) > 0.0) when the condition is true, then the equation der(x) = 2.0 should be executed. On the other hand, when noevent(sin(6.28 f req time) 0.0), then the equation der(x) = 0.0 should be executed. In the output file, it can be seen that location 1 is allocated for the true part and location 2 for the false part along with their respective invariants. The output thus has an automaton with two control modes. The tool cannot process discrete behaviour with when-equations. For example: 35

36 4 Tool evaluation Figure 4.8: Model with when-equations The console messages for this input is as follows: Figure 4.9: Console message for model with when-equation The tool stops processing once a when-equation is encountered. with when equations will not be translated. Therefore models 36

37 5 Conclusion and future work 5.1 Conclusion Verification of CPS triggered the need to develop a specific tool for Modelica models to translate them into Hybrid Automata. The algorithm thus presented translates the models created using Modelica into Hybrid Automata. The tool that takes the intermediate representation (debug message from OpenModelica) of the Modelica model, parses the input, stores data in the tool, and further translates the model to a hybrid automaton which is written out to a file. The evaluation of the tool analysed the tool based on its results. The console messages from the tool reveals the results of the intermediate steps in the tool. The evaluation presents which models can be translated and which types of models cannot be processed by the tools. The output thus produced can be parsed and used for verification and further analyses. 5.2 Future work The tool can translate Modelica models that exhibit discrete behaviour caused by ifequations. The research presented does not ensure the translation of all types of discrete behaviours in the Modelica models. For instance, there are discrete behaviour that are also caused by when-equations. It is therefore possible to continue along this path to investigate the possibility of a discrete behaviour in the Modelica model by equations other than if-equations. 37

38

39 6 Bibliography [1 ] B. De Schutter,W.P.M.H. Heemels, J. Lunze,and C. Prieur. Survey of modeling, analysis, and control of hybrid systems, Chapter 2 in Handbook of Hybrid Systems Control Theory, Tools, Applications (J. Lunze and F. Lamnabhi-Lagarrigue, eds.). Cambridge, UK: Cambridge University Press, ISBN , pp [2 ] W.P.M.H. Heemels, D. Lehmann, J. Lunze, and B. De Schutter. Introduction to hybrid systems, Chapter 1 in Handbook of Hybrid Systems Control Theory, Tools, Applications (J. Lunze and F. Lamnabhi-Lagarrigue, eds.). Cambridge, UK: Cambridge University Press, ISBN , pp [3 ] Shiguang Wang, Dong Wang, Lu Su, Lance Kaplan, and Tarek Abdelzaher. "Towards Cyber-physical Systems in Social Spaces: The Data Reliability Challenge," DOI [4 ] Hilding Elmqvist and Sven Erik Mattsson. "MODELICA THE NEXT GEN- ERATION MODELING LANGUAGE AN INTERNATIONAL DESIGN EFFORT" [5 ] Luca P. Carloni, Roberto Passerone, Alessandro Pinto, and Alberto L. Sangiovanni- Vincentelli. "Languages and Tools for Hybrid Systems Design," in Electronic Design Automation Vol. 1, No 1/2 (2006) [6 ] Modelica. "Modelica T M - A Unified Object-Oriented Language for Physical Systems Modeling". Version [7 ] Michael M. Tiller. "Modelica by Example". [8 ] Thomas A. Henzinger. "The Theory of Hybrid Automata". Berkeley: University of California [9 ] Hakan Lundvall, Peter Bunus, and Peter Fritzson. "TOWARDS AUTOMATIC GENERATION OF MODEL CHECKABLE CODE FROM MODELICA". Sweden: Link o ping University. 39