A Case Study in Tool-Aided Analysis of Discretely Controlled Continuous Systems: the Two Tanks Problem - Abstract Stefan Kowalewski,

Martin Fritz, Holger Graf, Jrg Preuig, Silke Simon, Olaf Stursberg and Heinz Treseler Chemical Engineering Dept., University of Dortmund, D-44221 Dortmund, Germany Email: stefan@ast.chemietechnik.uni-dortmund.de Keywords: Simulation and verification of hybrid systems, MATLAB, GPROMS, BASIP, SHIFT, HYTECH, SMV.

1 Introduction
This contribution reports on a case study in the application of tool-based methods for a systematic analysis of hybrid systems. In particular, the study is focussed on continuous processes controlled by logic controllers, as this class of hybrid systems is widespread among process industry plants. To achieve comparable results, all methods and tools under consideration were applied to the same example. We chose a simple process from our laboratory for this purpose. It will be introduced in detail in the following section. This benchmark example differs from other examples in the literature (as, for example, the train-gate-controller [LS87] or the steam boiler problem [AB+96]) in the following respects: 1. The problem is formulated such that simulation tools as well as verification tools can be applied meaningfully and will find particular challenges. In the case of simulation, the user must identify the worst-cases properly when non-determinism comes into play, whereas the tool has to handle event-triggered switching correctly. The main challenge in applying verification tools is to find a necessary abstraction of the continuous dynamics. 2. Although the plant looks quite simple (two connected water tanks, see next section) and the underlying physics are easy to understand, the continuous dynamics are far from being trivial (as can be seen by the Eqs. (5) - (8)). As a consequence, it is not obvious on first sight how a suitable abstraction can be made, if verification tools based on models with simpler dynamics (e. g. HYTECH with Linear Hybrid Automata) shall be applied. 3. The example is an existing plant and not a purely idealized model. This becomes obvious in the model of the valves' dynamics which was determined experimentally (Eqs. (7) and (8)). Since we are able to check any theoretical results at the real equipment, the effects of modeling errors or uncertainties can be investigated. 4. The problem statement corresponds to an every-day situation in process automation engineering: An already developed control program has to be checked with respect to a natural language requirement specification based on some knowledge about the process to control. Consequently, we use a common industrial representation for the control code in the example. In the following we describe the two tanks benchmark problem in detail, as this characterizes the aims of the study in the best way. After that, the tools under consideration are introduced shortly. These are on the simulation side MATLAB [TK96], GPROMS [BP94], SHIFT [DG+96] and BASIP [WF+96], and on the verification side SMV [CG+94] and HYTECH [HH+96]. The application results and experiences are sketched roughly. Detailed results, comprising simulation runs, particular problems or failures and differences in performance will be presented in the full paper.

2 The benchmark example

2.1 The plant The system under consideration is a small laboratory plant which is used for an practical exercise in continuous control for chemical engineering students at the University of Dortmund. It has been used for research purposes in the past, e. g. as a benchmark for nonlinear control design methods [HE94] or as an illustration of modelling concepts for hybrid systems [HK96, SK+97]. The plant consists of two connected cylindric tanks T1 and T2 which are situated on different levels (see Fig. 1). The diameter of T1 is 12 cm, the one of T2 is 5 cm. Both tanks are 1 m in height. The connecting pipe is attached to T2 at a height of H = 0,39 m. The plant is operated

with water. The incoming flow Vin is controlled by the valve VInput. Since it has only two positions, open or closed, the input flow is given by: if VInput closed, 0 l h , Vin = l 400 h , if VInput open.

(1)

Figure 1: Scheme of the laboratory plant The two other valves, V1 and V2, are control valves which can take on any (normalized) position between 0 (completely open) and 80 (completely closed): P1, P2 [0, 80]. (2) V1 and V2 are controlled by a three-valued signal: open valve, no change and close valve. Opening and closing the valves is relatively slow: The complete process takes approximately 80 seconds. It can be assumed that the opening and closing speed is constant: 1 P (3) 1, P 2 = s = const.

The dynamics of the two levels h1 and h2 can be deferred from the mass balances for both tanks (A1 and A2 are the base areas of T1 or T2, resp.): (V V12 ) (V Vout ) h1 = in , h2 = 12 (4) A1 A2

Applying Toricelli's law yields the following model for the flows V12 und Vout coming out of the two tanks.

Note from Eq. (5) that the autonomous system already shows hybrid dynamics as the valid model for V12 has to be switched from one mode to the other when h2 crosses the threshold H. K ( P ) h1 (h2 H ) V12 = 1 1 K1 ( P 1 ) h1

if h2 > H , if h2 H.

(5)

Vout = K 2 ( P2 ) h2 .

(6)

The coefficients K1 and K2 in (5) and (6) are necessary to represent the dependencies between the flows and the valve positions. The corresponding relations were determined experimentally:
6 106 P13 1,85 10 4 e K1 ( P ) = 5 1 2 0 ms m 2 s
5

if 0 P1 < 80, if P 1 = 80

(7)

5, 7 10 6 P23 2,26 10 4 e K 2 ( P2 ) = 5 2 0 ms

m 2 s

if 0 P2 < 80, if P2 = 80

(8)

2.2 The controller Figure 2 shows the control program for the example process. The representation is in accordance with the international standard IEC 1131-3 for Programmable Logic Controllers [IEC93]. The program is divided into two parts: a declaration part and a program body. For the program body the language Sequential Function Chart (SFC) is chosen because it is particularly suited for sequence control applications.


  
  !#" $&%')(*,+) )-,.)/10 )-1.234(1 5.'%76 !./1.89 :!;$=<>>@?<<<6A" $&%B!./1.8'0''C'%76 :)1D    )
1
  )(* !&EGF=!:#" $&%B*)(*2 )(1.H58 .'0)(*4/18/1.'%76   ?9 !&EGF=!:#" $&%*)(*2 )(1.H58 .'5 .50 4/18/1.'%76   C9 !&EGF=!:#" $&%*)(*2 )(1.H58 .B *)(*4/18/1.'%76 $& %I+ '88J/18/1.7
):4EI )(1.#KBF=!:4E,58 .'%76 :)1D   'L)1
1

0-1.?9
M:&EI
1NO<)1" $&%JP*0 ' 1+4.(,?'%76
0-1.C9
M:&EI
1N)C<)1" $&%JP*0 ' 1+4.(,C%76 ! (18*7 :!;$=<>>@?<<<6'&EQOR<"9$&%B*)((1.'80-10,+ BS.'8./1.8'0''C'%76 !  -10*7 :!;$=<>>@?<<<6'&E,?T<"9$&%'8 U.'80-10,+ BS.'8./1.8'0''C'%76 :)1D    VXWWWWWWWWWWWY Z Z .( < [ WWWWW\ WWWWW] ^ _`_  ^ ab_____c_____d ab_e____________d ^ ^ .( ? f ___g  ^  )(* h _____e _____i h _c___ _________i ^ _`_ $&.(  ?7>=
'j)EI
0-1.?76 ^ ab_____c_____d ab_e____________d ^ ^ .( C f ___g  ^  ? h _____e _____i h _c_____ _______i ^ _`_ $&.(  C7>=
'j)EI
0-1.C76 ^ j ab____ ___g ^ ^ ^ ab_____c_____d ab_e____________d ^k^ ^ .( f ___g  ^  C l ^kh _____eU h _c_____ _______i _____i ^ ^ ^ _`_ $m!./1.8Bn)EI!  -10*76 ^ ^ ^ ab_____c_____d ab_e____________d ^k^ ^ .( R f ___g ^  C ^kh _____e _____i h _c_____ _______i ^ ^ ^ _`_ $m!./1.8Bj)EI!  (18*76 ^ ^ h ____ n ___i :)1D 

Figure 2: Control program for the example The program does the following: After the start command the process is in a "start-up-phase" consisting of the steps 1 and 2. During step 1, T1 is filled by opening VInput (S stands for set) while V1 is kept closed. After the period Time1 the transition to step 2 takes place (the variable <stepname>.T can be used according to IEC 1131-3 to determine the current duration of an active step). When step 2 becomes active, V1 will be opened. After Time2 the "start-up phase" is finished and the "stationary operation" begins in which the process is either 3

in step 3 or step 4. The difference between these two steps is that in step 3 the output valve V2 is opened whereas in step 4 it is closed (R stands for reset). Step 3 is active as long as the level in T2 remains above the lower threshold L_minus. As soon as it drops below, the controller moves to step 4 until the level rises above the upper limit L_plus. 2.3 The requirements The desired behavior of the two tanks system is specified by the following two requirements: 1. No overflow may occur. 2. The process must reach an equilibrium state in finite time. This means, the level in T2 must not swing periodically between L_minus und L_plus in the stationary operation mode. Consequently, the control sequence has to stay in step 3 eventually. 2.3 The problem The requirements given in the previous section are to be checked for four different sets of control parameters (see Table 1). These values were chosen to capture most of the interesting scenarios which can take place in the process. The second set of parameters leads very closely to a situation where one of the requirements is violated. It is especially suited to determine the necessary grade of computational accuracy of the tools.

1 2 3 4 T#90s T#70s T#70s T#60s

T#20s T#26.85s T#20s T#25s



   
160 160 160 300

940 940 940 900

Table 1: Different sets of control parameters for the program TwoTanks In the first step of the analysis, it can be assumed that no disturbances arise during the plant operation. Obviously, in this case the problem is purely deterministic and can be solved by proper simulation. To provide a problem for which the verification tools can employ their particular strengths in handling nondeterminism, the following scenario shall be considered in a second step:  A leakage may appear in tank T1 or in the pipe between T1 and V1. If this happens, approximately 10 % of V12 will be lost. It can be assumed that the leakage will be discovered and closed within 2 minutes and that it will not appear again for the next 20 minutes after repairing.

3 Tool application results

3.1 MATLAB As a part of a project to define a modeling language for a broad class of hybrid systems a hybrid simulation facility for the widely used modeling and simulation environment MATLAB has been developed by Taylor [TK96]. The result is an extended integration algorithm for continuous time systems which supports jumps in the system trajectory as well as switchings of the model structure. Its special strength is the characterisation and handling of state events. Continuous time systems are represented by a set of differential equations x = f(x,m,t) switched according to the mode input m. State-events are detected by zero-crossings of a flag variable involving the state, time and the mode. When a change of sign is detected, the integration algorithm initializes an iterative procedure to find the step h such that the flag variable is zero. Before the integration proceeds, the model state - if desired - is reset and the new mode is calculated as the sign of the flag variable. The mode values are therefore restricted to 1, -1 or 0. Modeling the two tanks system was realized by defining a MATLAB function block which describes the evolution of the position of the valves and the liquid levels depending on the related mode. In case of the valves three different modes have to be distinguished corresponding to opening, stagnating and closing. The related flag variables depend on whether a critical level is reached and on the actual valve-position. To consider the coupling/decoupling of the tanks one more flag variable had to be defined depending on the level in tank two. In this example, a reinitialisation of the state vector at switching points was not necessary. Since the integration algorithm currently does not support the handling of time events, an additional script file has to be created which defines the sequence of integrations. At the beginning of each integration procedure, the flag variables are initialized within the function block according to a global variable that represents the current step in the 4

control procedure. The system was simulated using an extended variable-step Runge-Kutta-Fehlberg integrator. The simulation results can easily be visualized using the routines provided by MATLAB. To summarize, the simulator could handle the benchmark problem correctly. The accurate handling of state events provided correct results for every set of parameters. The decribed restriction due to the calculation of the mode as the sign of a flag variable did not apply in this case because the number of modes was only two. 3.2
GPROMS

The development of the GPROMS package (general PROcess Modelling System) [BP94] was initiated in 1988 at Imperial College, London, and is currently still ongoing. GPROMS provides a general-purpose modeling environment for the entire range of processes from purely continuous to purely batch. In addition, capabilities for dynamic and steady-state simulation, optimization and visualization are included. Particular attention has been paid to handle modeling complexity by the concept of hierarchical submodel decomposition. distinguishes two types of modeling entities: models and tasks. Models describe the physicochemical mechanisms governing a plant behavior, whereas tasks characterize the operating policies and control strategies imposed on the process. Modeling the two tanks plant, the mixed set of algebraic and differential equations as well as its switching discontinuities are defined in a model. The operating procedure of the plant consisting of four different steps is expressed in four tasks executed in sequence. Both modeling entities form the whole process. For the simulation, a relative accuracy of 1E-6 has been set to restrict the local truncation error, and a monitoring step length of 1 second has been chosen. The simulation results have been visualized with the GRMS (GPROMS Results Management System) facility. A typical simulation result can be seen in the figure below. It shows the overflow of the second tank due to its limiting height of 1 m.
GPROMS GPROMS

Figure 3: Visualization of simulation results by GRMS

As a conclusion, it can be said that is well suited for the proof of fulfilment of the specified plant behavior requirements for the chosen sets of parameters. However, for the nondeterministic cases the right choice of the considered cases is left to the user's intuition. GPROMS offers no facilities for a sound verification of the control program. 3.3 SHIFT SHIFT (Hybrid System Tool Interchange Format) is a specification language and simulation tool, currently developed at Berkeley [DG+96]. The theoretical basis of SHIFT is the Hybrid Automata paradigm defined by Alur et al. [AC+93], though some modifications referring to the connection and the synchronization of components have been introduced. In difference to the other tools used in this comparison, SHIFT allows to model and simulate dynamically reconfigurable hybrid systems, i. e. networks which change their structure at run-time, as it appears e.g. in modeling automated traffic systems. The tool comprises a compiler to translate SHIFT specifications to C, an online-debugger and a data visualization and animation facility (TkSHIFT). To model the two-tank example, we created components for each of the systems physical devices (tanks, valves, connecting pipes) as well as for the supervising controller. The links between these components were constituted by defining the continuous quantities (liquid levels, flowrates, valve positions, etc.) as input/output variables and setting the connections correspondingly in a superordinated block. The components discrete 5

states are naturally given by discretizing the range of the continuous variables according to thresholds being important for the control objective (e. g., opening, steady, closing for a control valve). For components inhering continuous dynamics, appropriate algebraic and differential equations are assigned to the discrete states. Specifying the two-tank system in this manner, TKSHIFT produces plots as shown in Fig. 4 for the case of periodic switching of the outlet valve. When applying SHIFT to the example with the different parameters and modes, we found that SHIFT is suitable to model processes of this type whereas some of its main features, as the dynamic reconfiguration or the inheritance of the components properties, were not used. Some restrictions are given by the SHIFT-syntax, e. g. no if-then-else-structures are permitted in the discrete states flow definitions. Furthermore, the simulation algorithm (only a 4th-order Runge-Kutta-method with fixed step-size available in the current version 1.7) does not offer the versatility of tools like GPROMS or MATLAB. Since SHIFT does not offer any verification procedures, tasks like analyzing the example control program in the disturbed case can only be solved by worstcase simulation.

Two-Tank System
1

h1(Tanks0) -vs-TimeClick h2(Tanks0) -vs-TimeClick P1_n(Valve10) -vs-TimeClick P2_n(Valve20) -vs-TimeClick

0.8

h1, h2, P1_n, P2_n

0.6

0.4

0.2

0 200 400 600

Time

Figure 4: The simulation results visualized by TKSHIFT 3.4 BASIP As opposed to the other tools in this comparison, BASIP (Batch Simulation Package) is not a general-purpose modelling and simulation tool, but designed for a specific application domain: recipe driven chemical batch processes [WF+96]. Though this example is not exactly what is generally understood as a batch process, with some modelling tricks and some extensions to the program it is possible to model and simulate this system. BASIP consists of a graphical user interface to model plant and recipes separately, a choice of different simulators (discrete-event, hybrid, interface to GPROMS), and several interfaces to visualization programs. For this example, the hybrid simulator was chosen. The sequence control of the example can easily be translated into a BASIP recipe, as both use the same representation as a sequential function chart. To represent the automatic flow operations between the tanks (flow takes place although no corresponding recipe phase is active), parallel branches with dummy filling operations were included in the recipe. Because modelling in BASIP normally takes place on a higher level than required here, some model blocks had to be extended, while some new ones had to be added. This includes valves that have limited positioning speed or level-dependent flow operations. The disturbed case requires additional modifications of the models, and could not been implemented so far. As a summary, it can be said, that BASIP proves to be apt even for cases it is not designed for, but lacks of flexibility to adapt the program to special cases without modifying the source code. 3.5 HYTECH HYTECH is a model checker for hybrid systems [HH+96]. To analyze systems with HYTECH they must be modeled as linear hybrid automata. For this example a subclass of hybrid automata, namely timed automata was chosen, although a system description with linear hybrid automata would have been less complex and more 6

accurate. Due to a known integer overflow problem in the analysis of hybrid automata, timed automata turned out to be much more suited in terms of feasible complexity. The model of the two tanks system consists of three timed automaton, one describing the levels in the two tanks, one describing the position of the outlet valve and one for the behavior of the controller. The valve between the two tanks was introduced with a constant open position. To create a timed automaton for the continuous behavior the given differential equations had to be discretized. This was done based on simple approximation method which maps the continuous state space into a set of discrete points representing the locations of the discrete model. Then the successors of each location are evaluated by extending the vector of the state variable derivatives until the next plane with discrete points is intersected. Then, all points directly adjecent to this intersection point are taken as the successors. The size of such a discrete model depends on the number of discrete levels considered for the two tanks (DL1, DL2) and the number of discrete positions considered for the outlet valve (DV2). To derive detailed models of the system a MATLAB function was implemented, which takes three parameters, namely the numbers of discrete points given by DL1, DL2 and DV2, and then generates a HYTECH input file with the corresponding timed automaton. The most detailed model which HYTECH could still analyze on a Hypersparc with 100Mb RAM was derived with D L1 = DL2 = 40 and DV2 =20. The resulting timed automaton for the representation of the levels in the two tanks had more than 30.000 locations. The results show that HYTECH is in general suited for problems like the two tanks example, although it soon exhibits its complexity limits. Still, more accurate results could be achieved with less modeling effort, if HYTECHs analysis algorithms performed better on linear hybrid systems. 3.6 SMV SMV (Symbolic Model Verifyer) is a tool for applying the verification technique Symbolic Model Checking [CG+94]. The SMV-System provides a language which allows to describe the considered transition system hierarchically. The model checker uses an Ordered Binary Decision Diagrams (OBDD) based search algorithm to check the specification of the desired behavior given as a Computation Tree Logic (CTL) formula. If the system does not show the desired behavior SMV, produces an execution path with a counter-example. Just as in the HYTECH case, a discrete approximation has to be derived form the continuous model to be able to verify the two tanks system with SMV. Again, this was implemented by means of MATLAB. Here, the approximation algorithm partitions the continuous state space into boxes and calculates the possible residence times in each box from the differental equations. All subsystems, like the valves, the controller and the discretized liquid levels are modeled separately. In contrast to HYTECH, SMV does not offer the possibility to model quantitative time information. Therefore the time had to be introduced as additional automata representing clocks which take one transition at each SMV execution cycle. Since SMV does not provide a synchronisation concept in the sense that transitions can be forced to be executed simultaneously, we keep an image of the discrete state space with the actual state always one time step behind. By this trick, events can be detected by evaluating conditions on the states in two systems. The size of the SMV input file generated by MATLAB obviously grows with the discretization grade. Since SMV imposes a restriction on the input file size, it could applied to the two tanks problem only for very rough discretizations. As a consequence, fine points of the analysis, like the behavior for the second parameter set, could not be determined correctly.

4 Discussion
We applied six tools for simulation or verification of hybrid systems to a simple but real plant and posed the problem to verify requirements for a given control program. To summarize shortly, it can be stated that due to the relatively complex continuous dynamics the two verification tools, HYTECH and SMV, had their problems.. Although automatic abstraction techniques were developed successfully, both tools soon reached their complexity limits (SMV much earlier than HYTECH due to the additional discretization of time). On the other hand, all four simulation tools (MATLAB, GPROMS, SHIFT and BASIP) could solve the problem properly, but have to rely on the user's intuition to identify the worst cases when it comes to nondeterministic occurences of disturbances. To discriminate further, SHIFT had its problems when exact identification of state events was necessary due to the fixed step-width integrator. MATLAB (i.e. the hybrid systems simulation algorithm by Taylor) and BASIP could only be applied after some programming for which deeper knowledge of the tool was necessary. For GPROMS the two tanks example is exactly what the tool is designed for. 7

Acknowledgements
We thank Sebastian Engell and Ingo Hoffmann for helpful discussions and Mario Stobbe for his extensive efforts during installation of the SHIFT tool.

References
[AB+96] J.-R. Abrial, E. Brger, and H. Langmaack: Formal Methods for Industrial Applications: Specifying and Programming the Steam Boiler Control, Lecture Notes in Computer Science 1165, Springer-Verlag, 1996, pp. 265-282. R. Alur, C. Courcoubetis, T. Henzinger and P. Ho: Hybrid Automata: An Algorithmic Approach to the Specification and Verification of Hybrid Systems. In Hybrid Systems II, Lecture Notes in Computer Science 736, Springer, 1993. P.I. Barton and C.C. Pantelides: Modelling of Combined Discrete/Continuous Processes. AIChE Journal, Vol. 40, 1994, pp. 966-979. E.M. Clarke, O. Grumberg and D.E. Long: Model Checking and Abstraction. ACM Trans. on Programming Languages and Systems, 16, 1994, pp. 1512-1542. A. Deshpande, A. Gll and L. Semenzato: The SHIFT Programming Language and Run-time System for Dynamic Networks of Hybrid Automata. PATH-Report, http://www.path.berkeley.edu/shift/. 1996. T. Heckenthaler and S. Engell: Approximately Time-Optimal Control of a Two-Tank System. IEEE Control Systems Magazine, Vol. 14, No. 3, 1994. T.A. Henzinger, P.-H. Ho and H. Wong-Toi: A User Guide to HYTECH. 1996, http://www.eecs.berkeley.edu/tah/HyTech/ I. Hoffmann and K.-U. Klatt: Modeling Hybrid Dynamical Systems. In: Hybrid Systems III, Lecture Notes in Computer Science 1066, Springer-Verlag, 1996. International Electrotechnical Commission: International Standard 1131: Programmable Logic Controllers, Part 3: Programming Languages. Geneva, 1993. N. Leveson and J. L. Stolzy: Safety Analysis Using Petri Nets. IEEE Transactions on Software Engineering, SE-13 3, 1987, pp. 386-397. O. Stursberg, S. Kowalewski, I. Hoffmann and Jrg Preuig: Comparing Timed and Hybrid Automata as Approximations of Continuous Systems. In: Hybrid Systems IV, will appear in Lecture Notes in Computer Science, Springer-Verlag, 1997 Taylor, J. H., D. Kebede: Modeling and Simulation of Hybrid Systems in MATLAB, Proc. IFAC World Congress Vol. J, San Francisco, USA, July 1996, pp. 275-280. K. Wllhaf, M. Fritz, C. Schulz und S. Engell: BASIP - Batch Process Simulation With Dynamically Reconfigured Process Dynamics. In Proc. ESCAPE-6, Supplement to Comp. & Chem. Engng., Rhodos, Greece, 1996

[AC+93]

[BP94] [CG+94] [DG+96]

[HE94] [HH+96] [HK96] [IEC93] [LS87] [SK+97]

[TK96] [WF+96]