Using an Extension of Z. Viktor Friesen. Technische Universitat Berlin

Transcription

1 An Exercise in Hybrid System Specication Using an Extension of Z Extended Abstract Viktor Friesen Technische Universitat Berlin Abstract. The main concepts of ZimOO are illustrated by a small case study, a specication of a protected cooker. ZimOO is an extended subset of Object-Z and allows descriptions of discrete and continuous features of systems in a common formalism. 1 Introduction The primary motivation for the development of ZimOO was the need to describe models for the dynamic simulation of complex energy systems in a readable and abstract but formal style. The investigation of models to be simulated shows that nearly all of them are hybrid in nature. Hence, the application domain of ZimOO has changed from dynamic simulation models to the more general area of hybrid systems [3, 4]. ZimOO is still under development; its present status is described in [2]. ZimOO is based on Object-Z [1], an object-oriented extension of Z [5]. A system specication in Z consists of a description of the global system state and a set of operations describing how this state can be changed. Object-Z provides additional means for describing systems in an objectoriented style, i.e., an Object-Z specication consists of a set of classes, each containing a state description and a set of operations. Z and Object-Z support only specications of discrete systems. ZimOO is an extended subset of Object-Z allowing descriptions of discrete and continuous features of a system in a common formalism. ZimOO supports three dierent kinds of classes: discrete (as in Object-Z), continuous, and hybrid classes. In the current version of ZimOO, discrete classes can inherit only from discrete classes, continuous only from continuous classes, and hybrid only from hybrid classes. Hybrid classes are created by introducing discrete and continuous object-valued variables. The information interchange between discrete and continuous objects is realized by control variables, which transfer data from the discrete to the continuous world and vice versa. A clear distinction between discrete and continuous classes is important in order to adequately treat the dierent aspects of a system. Thus, the system can be structured better and the well-known suitable formalisms can be applied to describe, analyze, and rene the dierent parts of the system. The bridge between the continuous and the discrete world is built by hybrid classes. Forschungsgruppe Softwaretechnik (FR5-6), Franklinstr. 28/29, D Berlin, Germany. friesen@cs.tu-berlin.de 1

2 2 A Specication Example We now illustrate the main features of ZimOO by a simple example: a cooker which is safeguarded against consuming too much power. This cooker consists of several plates which are safeguarded against overheating. In the last step of the specication, some pans containing water will be put to heat on the cooker. In the rst step, we specify a simple heat store which can be described by four continuous variables: temperature T, mass m, specic heat capacitance cp, and the change of heat dq, which are declared in the declaration part of the state schema of the continuous class HeatStore (continuous classes are recognizable by their round corners). Continuous state variables are semantically interpreted as total functions from T (time) to the type of the variable. The types Temperature, Mass etc. are equal to R and serve only to enhance readability of the specication. The relationship between the state variables is governed by the dierential equation T _ = dq =(m cp) described in the predicate part of the state schema, which species the state invariant of HeatStore. HeatStore T : Temperature [K ] m : Mass [kg] cp : SpecicCapacitance [J =kg=k ] dq : dheat [J =s] _T = dq=(m cp) An embedded heat store with a specic area A and a heat transfer coecient (both are constant and are thus declared in the so-called axiomatic part of the class) is a heat store with additional state variables T Env, dqheating, dqtransfer, and dqtransform. T Env denotes the temperature of the environment, dqheating is the power provided to the heat store, dqtransfer is the power transferred from the store to the environment, and dqtransform is the power lost through energy transformation. The two algebraic equations describe how dqtransfer and dq depend on the other state variables. EmbeddedHeatStore HeatStore A : Area [m 2 ] : Coecient [J =K =m 2 =s] T Env : Temperature dqheating; dqtransfer; dqtransform : dheat dqtransfer = A (T? T Env) dq = dqheating? dqtransfer? dqtransform A cooker plate is an embedded heat store which transforms electrical energy into heat. Thus, Plate contains the constant R and the variables U and I to describe the electrical 2

3 Plate EmbeddedHeatStore R : Resistance U : Voltage I : Current [Ohm ()] [Volt (V)] [Ampere (A)] dqheating = I 2 R dqtransform = 0 U = I R behaviour of the plate. A plate fuse consists of a discrete and a continuous part. The discrete class PlateFuseControl describes the computational behaviour of the fuse. The constants T min and T max mark the switching points of the controller. PowerReq is a discrete state variable indicating whether the plate requires energy. Discrete state variables are interpreted as partial functions from time to their types, because they are undened during the execution of operations which may take some time in our approach. Discrete variables can assume only a nite number of values in every nite period of time. T? is a continuous control variable representing the temperature of the process to be controlled (the plate in our example). (Control variables are labelled with a question mark.) The discrete operation VoltageControl species the computation instruction for the new value of PowerReq. PlateFuseControl T min; T max : Temperature T min < T max PowerReq : 0 j 1 T? : Temperature VoltageControl (PowerReq) PowerReq 0 = IF (T? > T max) THEN 0 ELSE IF (T? < T min) THEN 1 ELSE PowerReq VoltageAmplier species a simple \amplier", i. e. it multiplies the ingoing voltage by the value of the discrete control variable Factor? and provides the result as the output voltage. PlateFuse consists of a PlateFuseControl and a VoltageAmplier, and must therefore be described by a hybrid class. The current version of ZimOO does not allow the building of hybrid classes by inheritance from discrete and continuous classes, so we do this by declaring the object-valued variables Control and Ampl. The predicate part of the state schema species the connections between state and control variables. The usual dot notation is used to denote the access to attributes of objects. The control variables are connected by \" to the corresponding state variables of other objects, to distinguish this connection from simple equality (the -relation is weaker than equality because discrete variables may be partial). 3

4 VoltageAmplier Factor? : R InU ; OutU : Voltage OutU = Factor? InU PlateFuse Control : PlateFuseControl Ampl : VoltageAmplier Control:PowerReq Ampl:Factor? A safe plate consists of a plate Pl and a fuse Fu, whereby the control variable Fu:Control :T? of the fuse inspects the temperature Pl :T of the plate, and the voltage Pl :U of the plate is connected to the outgoing voltage of the fuse. This small hybrid system is described in the hybrid class SafePlate. SafePlate Pl : Plate Fu : PlateFuse Pl:T Fu:Control:T? Pl:U = Fu:Ampl:OutU To specify a cooker with Number plates we start with a description of a control unit. It should ensure that the power consumption of the cooker never exceeds MaxPower. VoltageNeeded denotes the maximal voltage which, if transmitted to the plates, would make the current power equal to MaxPower. The discrete operation VoltageControl species the computation instruction for Factor to adjust the voltage transmitted to the plates. CookerFuseControl Number : N 1 MaxPower : Power MaxPower > 0 InU? : Voltage OutU? : Voltage I? : 1 : : Number! Current VoltageNeeded : Voltage Factor : R VoltageControl (VoltageNeeded ; Factor) q VoltageNeeded 0 = MaxPower (OutU P Number?= i=1 I?(i)) Factor 0 = IF (VoltageNeeded 0 InU?) _ VoltageNeeded 0 = 0 THEN 1 ELSE VoltageNeeded 0 =InU? Similar to PlateFuse, a CookerFuse is built from a discrete control unit and a simple amplier. 4

5 CookerFuse Control : CookerFuseControl Ampl : VoltageAmplier Control:Factor Ampl:Factor? Control:InU? Ampl:InU Control:OutU? Ampl:OutU A safe cooker consists of Number safe plates and a cooker fuse, whereby the i-th output voltage of the cooker fuse is connected to the voltage of the i-th safe plate. SafeCooker Number : N 1 Plates : 1 : : Number! SafePlate Fu : CookerFuse Number = Fu:Control:Number 8 i : 1 : : Number Plates(i):Fu:Ampl:InU = Fu:Ampl:OutU (i) 8 i : 1 : : Number Plates(i):Pl:I Fu:Control:I?(i) In the last step of the example, some pans containing water are put to heat on the cooker. A Pan is an extension of an embedded heat store, whereby the characteristics of Pan (m, cp) are determined by the characteristics of the pan itself and the water it contains. Pan contains two continuous state variants (WaterNotBoiling and WaterBoiling). Such a variant consists of a guard condition and the variant itself. The variant is relevant in a particular point of time only if the evaluation of the guard condition is true, otherwise it can be neglected. Pan EmbeddedHeatStore m Pan : Mass cp Water; cp Pan : SpecicCapacitance r : R [evaporation enthalpy] m Water : Mass cp = (cp Water m Water + cp Pan m Pan)=(m Water + m Pan) m = m Water + m Pan WaterNotBoiling T 373 _ m Water 0 dqtransform = 0 _ m Water = 0 WaterBoiling T > 373 ^ m Water > 0 dqtransform = dqheating? dqtransfer _ m Water =?dqheating=r 5

6 Now we can extend the safe cooker by Number pans and regard the pans as the environment of the plates (the energy transferred from the plate to the air is neglected). CookerWithPans SafeCooker Pans : 1 : : Number! Pan 8 i : 1 : : Number Plates(i):Pl:dQTransfer = Pans(i):dQHeating 8 i : 1 : : Number Plates(i):Pl:T Env = Pans(i):T 3 Conclusion The paper presented a case study in the formal specication of hybrid systems. Owing to lack of space, the presentation was unfortunately quite technical. Nevertheless, the example shows that ZimOO can, in principle, be used to produce descriptions of systems that are suitable for human readers and can be processed by machines. The rst property is achieved by familiar mathematics, object-oriented structuring means, and graphical notations. A wide use of comments can signicantly enhance the readability of ZimOO documents. ZimOO specications cannot be executed directly, because the level of description is too abstract. Nevertheless, such descriptions can be analyzed and manipulated by machines to support the interactive development of executable code. References [1] R. Duke, P. King, G. A. Rose, and G. Smith. The Object-Z specication language. In T. Korson, V. Vaishnavi, and B. Meyer, editors, Technology of Object-Oriented Languages and Systems: TOOLS 5, pages 465{483. Prentice Hall, [2] V. Friesen. Konzepte einer hybriden Spezikationssprache fur Simulationssysteme. Teilbericht der Gruppe H zur zweiten Projektphase des UF 4, Institut fur Angewandte Informatik (Softwaretechnik), TU Berlin, [3] O. Maler, Z. Manna, and A. Pnueli. From timed to hybrid systems. In J. W. de Bakker, K. Huizing, W.-P. de Roever, and G. Rozenberg, editors, Real Time: Theory in Practice, volume 600 of Lecture Notes in Computer Science, pages 446{484. Springer-Verlag, [4] Z. Manna and A. Pnueli. Verifying hybrid systems. In R. Grossman, A. Nerode, H. Rischel, and A. Ravn, editors, Hybrid Systems, volume 736 of Lecture Notes in Computer Science, pages 4{35. Springer-Verlag, [5] M. Spivey. The Z Notation, A Reference Manual. Prentice Hall, second edition,