High-level Modeling with THORNs. Oldenburger Forschungs- und Entwicklungsinstitut fur. Informatik-Werkzeuge- und Systeme (Offis)

Transcription

1 High-level Modeling with THORNs Stefan Schof, Michael Sonnenschein, Ralf Wieting Oldenburger Forschungs- und Entwicklungsinstitut fur Informatik-Werkzeuge- und Systeme (Offis) Escherweg 2 D{26121 Oldenburg (Germany) fschoef,sunny,wietingg@informatik.uni-oldenburg.de Abstract Todays complex systems require both, methods for their easy modeling and tools for their ecient handling on computer systems. The language developed by us for those often contradictory goals easy modeling, abstraction, and reusability must be provided to the user and ecient execution must be achieved on a computer is based on a class of hierarchical object-oriented Petri nets with time inscriptions and is called Thorns (Timed Hierarchical Object-Related Nets). In this paper, the concepts of the Thorn simulation language are explained. First, a subclass of Thorns without time or hierarchy aspects is described. Though already quite powerful, the language dened this way oers no concepts to model time aspects of the system, e.g. the duration or starting time of an activity. Those disadvantages are mastered by introducing the time concepts of Thorns. The achieved sublanguage of Thorns has left one major drawback: it lacks the possibilities to reuse models already written, to model various similar or equal complex parts of the system in an appropriate and easy way, and to simply organize a model according to the physical or logical structure of a system. All those shortcomings disappear by introducing hierarchical concepts into the dened subclass, extending it to the full class of Thorns. The presentation of the Thorn language is illustrated by small examples. 1 Aspects of Modeling with Petri Nets Petri nets [Rei85] are well suited for modeling, if the cause-event structure of a system is known and has to be used to dene the model. All events modeled by Petri nets must be discrete in time. Events must be caused by conditions on a local part of the models current state. A Petri net is a graphical structure consisting of four components: places, transitions, arcs, and tokens. Places are container for tokens: each place may hold an arbitrary number of tokens (even zero). The number of tokens a place holds is called its marking, the marking of all places together denotes the state of the modeled system and is called the marking of the net. While places are passive elements of a Petri net used together with tokens to model states of the system, transitions are active elements representing the actions of a system. They execute these actions by state transformation, i.e. by changing the marking of the net. To specify the state transformation, places are interconnected with transitions by directed arcs. Each transition may have zero or more preset arcs (leading in from its preset places) and postset arcs (leading out to its postset places), respectively. The set of places, the set of transitions, and the set of arcs is nite and static, while the set of tokens and the marking may change during execution of the net. Before explaining the dynamic behaviour of a net, we rst identify the dierent components of the net in Fig. 1. There are three places called \Street Part A", \Street Part B", and \Parking Lot" (places are usually drawn as ellipses). The token on place \Street Part A" indicates the presence of a car on part A of the street (tokens are represented as small lled circles residing on the places). There are three transitions called \Pass by", \Drive in", and \Drive out" (transitions are usually shown as rectangles or bars). A transition is said to be enabled, i there is at least one token on each of its preset places. In the net shown in Fig. 1, transitions \Pass by" and \Drive in" are enabled. An enabled transition may re, i.e. it removes one token from each of its preset places and generates one token onto each 1

2 Street Part A Pass by Street Part B Drive in Drive out Parking Lot Figure 1: Petri Net Model (Initial State) postset place. By the ring of a transition former enabled transitions may become disabled and new transitions may become enabled. If transition \Drive in" res, the resulting marking is as in Fig. 2, where only transition \Drive out" is enabled. Street Part A Pass by Street Part B Drive in Drive out Parking Lot Figure 2: Petri Net Model (Next State) In this example, there is a similarity between net parts and parts of the physical system, e.g. places may be interpreted as street parts, tokens as cars, and arcs/transitions as interconnections between the street parts. However, sometimes it must be recalled that places and tokens simply indicate a state in the system, so we should have called e.g. place \Street Part A" better \Number of cars residing on street part A". The introduction of arc weights makes it possible to specify for a transition the number of tokens it consumes from its preset places and the number of tokens it produces on its postset places. A further enhancement is the association of a positive, maybe innite capacity with each place. This can be used to introduce resource limitations into the model (e.g. by giving place \Parking Lot" in Fig. 1 and 2 the capacity \100" we indicate that only 100 cars t into the parking lot. Petri nets with arc weights and place capacities are called place/transition systems (P/T-Systems). In P/T-Systems, a transition is enabled, i there are enough tokens on its preset places and enough free space on its postset places (in each case specied by the arc weights). The original classes of Petri nets and P/T-Systems are well-known to be useful for highly abstract models that have to be analyzed in a formal way for some of its features. But if a model has to respect more details of the system or if time has to be respected in the model, more general classes of Petri nets have to be developed for modeling these aspects. Our class of Thorns generalizes Petri nets in many ways. Tokens are objects of the objectoriented language C++ and transitions may execute code of this language. The ring of a transition may take time and a transition may be delayed from its enabling to its ring for an interval of time. Moreover, Thorns may be structured as a hierarchy of subnets which can be created and deleted dynamically. Of course, Thorn models cannot be analyzed in a formal way, but must be simulated to get information on the models behavior. This paper gives an overview of modeling with Thorns. All examples are taken from a model of car trac in a town. A more detailed description of Thorns and an introduction to the simulation of Thorns is given in [SSW95]. 2

3 2 THORNs 2.1 Object Nets In this section we describe a base subclass of Thorns without time or hierarchy concepts. We call this class object nets. Object nets are an extended form of P/T-Systems. To describe the enhancement of P/T-Systems to object nets, we use the small example in Fig. 3. Here the ow of cars across an intersection controlled by a trac light is modeled. The model is simplied, for instance cars only drive from north to south or from west to east or vice versa. However, it may be easily extended to a real-life model. North InCar Drive South TL West Traffic Light East OutCar Switch Traffic Light South Figure 3: A Crossing Modeled by an Object Net An obvious enhancement of Petri nets is the introduction of distinguishable tokens [Jen90, Gen87, LK91]. In Thorns we use instances of C++ classes as tokens. For example, we may dene a car as struct Car { int Velocity; // actual velocity in [km/h] int Performance; // power of the engine in [kw] int Fuel; // actual amount of fuel in [l] int Weight; // actual weight in [kg] int Consumption(); // determines the fuel consumption in [l/km] (defined elsewhere) double TimeFor(int Distance); // determines the driving time in [s] for a // specific distance given in [m] (defined elsewhere) } and a trac light state as enum TrafficLightState {NorthSouth,WestEast}; indicating that the trac light shows green to the north-south and south-north (west-east and eastwest) trac and red to the other directions. Now, a place must be labeled with a C++-class, determining the type of tokens allowed there. Transitions may in two ways utilize the objects' attributes. At rst, each transition may have a condition function expressed in C++, which must yield true for a transition to be enabled. This 3

4 function may reference preset objects of the transition using variable names inscribed on preset arcs. For instance, the transition \Drive South" may have the enabling condition: TL == NorthSouth to allow its ring (transfer of a car from north to south) only if the trac light shows green for the north-south direction. Secondly, the action code of a transition can be used to determine the postset objects a transition generates by its ring. The transition \Drive South" uses the block OutCar = InCar; OutCar.Fuel = InCar.Fuel - Consumption() / 1000 * 15; // street from north place to south place measures 15 meters as the action code to decrease the cars available fuel according to its consumption for the covered distance. The transition \Switch trac light" toggles the direction for which the trac light shows green in a similar way. In Thorns, a place may have a structure bag, stack, queue, or priority queue to specify the data structure to store tokens on it. In Fig. 3 the places \North", \South", \West", and \East" have structure queue, since cars are expected to cross the intersection in FIFO order. At last, Thorns provide beneath the standard arcs described so far three other arc types to connect transitions to its preset places. Enabling arcs (represented by an arc with a small circle, cf. Fig. 3) yield the same semantics as standard arcs with the exception that objects on places connected by these arcs to the ring transition aren't consumed. Inhibiting arcs prohibit the ring of a transition, i at least the number of objects indicated by the arc weight reside on the connected place. Places connected by consuming arcs to transitions are emptied, if the adjacent transition res. As the example in Fig. 3 shows, simple systems are easily modeled using object nets. However, time aspects can't be modeled in an appropriate way (for instance the transition \Switch Trac Light" toggles the colour of the trac light in arbitrary time intervals). The introduction of time in the next section overcomes these drawback. 2.2 Time In most cases, for modeling real systems it is very important to describe timing behaviour and dependencies to achieve expressive and realistic models. This already became apparent in the crossing example of the previous section. Without time information integrated into the model, one cannot predict how long it takes for a car to drive across the intersection or how long the trac light shows green for a particular direction. Thorns provide two dierent kinds of timing concepts, which are well-known in the theory of Petri nets (cf. [Sta90]). Each transition may be labeled by two specic functions to describe a delay time or waiting period, indicating how long a transition has to be enabled without interruption before it starts to re, and a ring time or duration, indicating the time period necessary for executing the activity represented by that transition. Both functions can be composed of constants, attribute values of objects from preset places, C++ operations, or even stochastic distribution functions. Their domain must be nonnegative real numbers. The semantics of these time functions is as follows: If a transition is enabled by a set of objects for the specied delay time without an interruption, it starts ring by consuming the enabling objects from preset places. After waiting a period specied by the ring time, the transition produces objects on postset places according to postset arcs and the inscription of its action block. With these timing concepts it is possible to improve the model of a crossing shown in Fig. 3, which only describes causal dependencies so far. By labeling each \Drive" transition with a ring time we can express the time period necessary for driving across the intersection. This may be a constant value that abstracts from individual cars and describes an equal crossing time for all cars, or an object dependent value, which can be determined by the method double TimeFor(int) of the class \Car". This method gets the distance as a parameter and returns the driving time taking the Weight, Performance, and Velocity of the car into account. If it is desired to model an even more realistic variable behaviour, the ring time may also be varied by a stochastic distribution function: 4

5 FiringTime = Normal(InCar.TimeFor(15), Sigma); where Sigma is the dispersion of the normal distribution. The usefulness of delay times is demonstrated by the transition that models the switch of the trac light. In Fig. 3 a \TracLightState" object on place \Trac Light" either enables \Drive" transitions in north-south or in east-west direction. By dening a constant delay time of e.g. 180 seconds for the transition \Switch Trac Light" it is possible to model a trac light giving each direction alternately green for exactly three minutes. Moreover, a ring time of 5 seconds can be used to decribe a small period where no trac is allowed to ow useful to avoid car accidents. 2.3 Hierarchy If models become more complex they have to be structured to be manageable. The most usual aspect of structuring is abstraction of details. Models are structured as a multi-level hierarchy of submodels. In such a hierarchy each model is based on an abstract view of features of its submodels. In general there are two dierent ways of hierarchical modeling. First, models may contain elements that are just place-holders for submodels. The semantics of such a model is dened by expanding, i.e. elements representing submodels are replaced by copies of these submodels. This attempt makes models more readable, but it is not really an abstraction mechanism. Petri nets usually oer this attempt by transition renement. To rene a transition, the corresponding subnet has to contain counterparts for the border places, i.e. preset or postset places, of the rened transition. If the model is expanded, the border places of a rened transition and the corresponding places in the copy of the corresponding subnet are represented by the same place. This attempt is also provided by Thorns. Figure 3 shows a subnet modeling a simple crossing. An extended version of this can be used to rene dierent transitions representing crossings in a city net as given in part by Fig. 4. Gray shaded boxes represent rened transitions while gray shaded circles represent places in the border of the subnet. Wechloy Oldenburg Eversten C.v.O. Universitaet Oldenburg Uhlhornsweg Ammerlaender Heerstr. Haarentor To Edewecht Bloherfelder Str. Bloherfelder Str. Figure 4: City Net But this attempt to dene a structure of nets has two major drawbacks. At rst, a rened transition does not behave like a standard transition, because ring of a standard transition is an atomic event for the net, but the behaviour of a rened transition is not atomic in general. Secondly, transition renement makes nets more readable, but semantics of nets with dierent levels of renement may become dicult to understand since rened transitions don't hide any information of the behaviour of subnets. Hence also a counterpart of a procedure call mechanism may be used for transition renement in Thorns as similarly proposed for predicate/transition nets in [Ram93]. The set of border places of a calling transition is divided into the set of input places, the set of output places, and a specic set of share places. The calling transition is enabled, if its input places contain enough tokens according to the weights of arcs from input places to the transition which full its enabling condition. Moreover, output places of the calling transition must be able to store tokens produced by the transition according to the respecting arc weights. If the calling transition res, it creates dynamically 5

6 a subnet. This subnet is used for expanding the calling net, but in contrast to ordinary transition renement only tokens consumed by the calling transitions are passed from its input places to the corresponding input places in the created subnet. A calling transition may create many subnets for dierent sets of tokens on its input places concurrently. While such a subnet is active, it may communicate with the calling net and dierent subnets only by using share places in common. Eects on output places are still not visible in the calling net. The activation of the subnet ends by ring of a special stop transition in the subnet. After nishing all ring transitions that started before the stop transition began to re, the contents of the output places of the subnet are copied to the corresponding places in the border of the calling transition respecting the weights of arcs from the calling transition to these places. Thereafter the called subnet is deleted. This mechanism of subnet invocation contains ordinary transition renement as a special case for a calling transition without input and output places that is rened by a subnet without a stop transition. Dynamically created subnets may be used especially, if a set of tokens enabling a calling transition must not be confused with a dierent set of tokens enabling the same transition concurrently. An example for such a requirement is a calling transition representing the behaviour of a garage which is enabled by a car, a driver, and an order, each represented by a token on a special input place. Of course, a garage must be able to repair some cars in parallel, but an order always refers to a specic car and a car to its driver. So it is useful to handle each order by its own subnet. 3 Tools Several tools are developed or under construction for modeling and simulating Thorns. There exists a graphical net editor for entering Thorn models and starting simulation runs, a net compiler generating executable code and a simulator kernel for an ecient sequential simulation. Currently, the graphical user interface is extended in order to improve simulation control, present statistical results and animate traces of simulation runs. Furthermore, a distributed simulator is under construction which will allow an ecient execution of complex system models on a cluster of workstations or a parallel computer. References [Gen87] [Jen90] [LK91] H. J. Genrich. Predicate/transition nets. In W. Brauer, W. Reisig, and G. Rozenberg, editors, Petri Nets: Central Models and Their Properties, volume 254 of Lect. Notes Comput. Sci., pages 207{247. Springer-Verlag, Berlin, Germany, K. Jensen. Coloured Petri nets: A high level language for system design and analysis. In G. Rozenberg, editor, Advances in Petri Nets, volume 483 of Lect. Notes Comput. Sci., pages 342{416. Springer-Verlag, Berlin, Germany, C. A. Lakos and C. D. Keen. LOOPN language for object-oriented Petri nets. In SCS Multiconference on Object-Oriented Simulation, pages 22{30, Anaheim, CA, Jan [Ram93] F. J. Rammig. Modelling aspects of system level design. In Proceedings of the EURO-DAC '93, pages 534{539, Hamburg, Germany, Sept IEEE Computer Society Press, Los Alamitos, CA. [Rei85] W. Reisig. Petri Nets An Introduction, volume 4 of EATCS Monographs on Theoretical Computer Science. Springer-Verlag, Berlin, Germany, [SSW95] S. Schof, M. Sonnenschein, and R. Wieting. Ecient simulation of Thor nets. In G. De Michelis and M. Diaz, editors, Proceedings of the 16th International Conference on Application and Theory of Petri Nets, Lect. Notes Comput. Sci., pages 412{431, Torino, Italy, June Springer-Verlag, Berlin, Germany. [Sta90] P. H. Starke. Analyse von Petri-Netz-Modellen. Leitfaden und Monographien der Informatik. Teubner Verlag, Stuttgart, Germany, In German. 6