MODELLING LOGISTIC SYSTEMS WITH EXSPECT W.M.P. van der Aalst A.W. Waltmans Department of Mathematics and Computing Science Eindhoven University of Technology P.O. Box 513, 5600 MB Eindhoven The Netherlands e-mail:
[email protected]
Keywords: Dynamic modelling, simulation, logistics, formal speci cation. Abstract A framework for the modelling and speci cation of concurrent systems is introduced. This framework is closely related to Coloured Petri Nets. Within this framework a tool has been developed together with a language called ExSpect. One of the applications of this language is the description and simulation of logistic processes. Therefore the TASTE project (1) was started. The result of this project will be a toolkit of standard logistic components that can be combined graphically, thus yielding a (simulation) model of a real or alternative situation. After a short introduction of the language some examples will illustrate our approach.
1. Introduction There are currently two trends in systems modelling. The theoreticists are divided in many factions: their description methods have a well-de ned semantics, but are biased towards only a few aspects of modelling. The practicalists use a more or less overlapping set of methods that have proven to be useful. However, these methods have no formal semantics and cannot be used for prototyping. Our dream is to combine the advantages of both approaches and bridge the gap between theory and practice. For this purpose we introduce a formal and more structured framework, called discrete event systems (DES), developed at the Eindhoven University of Technology (2). It is much easier to map a complex system into this framework. Our model is a successor of the one in (3). It is related to (coloured) Petri nets ((C)P-nets, (4) and (5)). The fact that our networks are specialisations of CP-nets allows us to use Petri net theory to verify structural properties (6). We use here Petri net terminology to explain our model. Every complex system that ts into this framework is called a des. Not only information systems, such as a distributed data base and an access control system, are desses, but also many other systems, such as an automated guided vehicle system, a banking system and a logistic system. In this paper we will show how we can model these complex systems. We will focus on the last class of systems, the logistic systems. A des consists of two kinds of components: processors and channels (corresponding to respec-
tively transitions and places in Petri nets). A processor is connected to one or more input channels and zero or more output channels. To each association of an input channel to a processor a certain (positive integer) weight is attached (in most cases weights are equal to 1). This allows a channel to be a multiple input channel of a processor. With each channel a type is associated and with each processor a function. The signature of the function of a processor p corresponds with the types and weights of input channels of p and the types of its output channels. Channels may be shared by several processors as input or output channel. At any moment channels may contain triggers (tokens in Petri nets). A trigger has a value that belongs to the type of the channel and a time stamp that belongs to some ordered set T . There may be more triggers in the same channel with the same value and time stamp. So a channel actually contains a certain bag of triggers over its type. At any moment there may occur a transition, which means that the con guration of triggers, called the state, may change (our terminology attaches another meaning to the term transition than Petri net theory). Such a transition occurs instantaneously and is executed by the processors. A processor may execute if it is able to select the right number of triggers from each of its input channels. The number of triggers to be selected from an input channel by a processor p is equal to the weight of the input channel for p. The execution of a processor means that the selected triggers are consumed (deleted) and that new triggers for the output channels of the processor are produced. Note that a trigger can be consumed only once. An event is an assignment of triggers to processors such that each processor can execute. The (simulated) event time at which an event may occur is the maximum of the time stamps of the triggers to be consumed. The transition time of a system in a certain state is the minimum of the possible event times. Being in a certain state, a system will select an event of which the event time is the transition time and execute it, causing a state transition. The time stamps of produced triggers will be at least equal to the event time. It is thus clear that the transition times of successive events will be non-descending. By not specifying any delays, we have a timeless model: events are ordered only by causality and triggers can be consumed only after production. To represent a des we use a diagram technique like for Petri nets. A diagram is isomorphic to an ordered graph containing the network of processors and channels. Such a network can be de ned separately and used as a subnetwork in the complete system. It is thus possible to use a decomposition hierarchy. A high-level DES diagram is very similar to a data ow diagram. For a more detailed treatment of the DES model we refer to (7). In this paper we start by introducing the language ExSpect. Next we describe the modelling of logistic systems. Afterwards we present some examples.
2. ExSpect We have developed a language called ExSpect for the speci cation of a des. Since it is executable, it can be used for prototyping and simulation. A typechecker and an interpreter have been developed. The typechecker checks the speci cation for correctness, completeness and consistency. The interpreter can be used to execute such a speci cation. There are two modes of operation one for prototyping and one for simulation.
Since the user can view or in uence a running simulation, interactive simulation is possible. The software is written in the language C and runs under UNIX at a SUN workstation in a window environment. Also a stripped version of the software is available for the personal computer. More information about the ExSpect system is presented in (8). The language ExSpect consists of two parts: a functional part and a dynamic part. The functional part is used to de ne types and functions. The type system consists of some primitive types and a few type constructors to de ne new types. A `sugared lambda calculus' is used to de ne new functions from a set of primitive functions. ExSpect is a `strong typed' language since it allows all type checking to be done statically. A strong point of the language is the concept of type variables: it provides the possibility of polymorphic functions. A complete description of the functional part is given in (9). The dynamic part of ExSpect is used to specify the network of processors, channels and stores and therefore the interaction structure. The behaviour of a processor is described by functions. ExSpect has ve primitive types: void, bool, num, real and str. The type constructors are set ($), cartesian product (>). From a set of types and type operators we can form type expressions that symbolise new (composite) types. We can attach names to type expressions, thus de ning new types. The following example illustrates some type de nitions: type type type type type type type
weight from real with [x] x >= 0.0; volume from real with [x] x >= 0.0; manufacturer from str; truck from manufacturer >< (weight >< volume); truck id from num; fleet of trucks from truckid -> truck; cargo from weight >< volume;
Note that we can add a with part for restricting the type. Likewise we can construct new functions. Our set of basic functions includes all well-known set-theoretical, logical and numerical constants and functions. These functions are often polymorphic. Because of some `sugaring' it is possible to write these functions in their usual symbolic in x or `circum x' notation. As an example we show two function de nitions operating on the types de ned above: transportable by truck[ c : cargo, t : truck ] := (pi1(c) < coordinate; consumer2 := : coordinate >< coordinate; .. consumern := : coordinate >< coordinate; sys Transport [ in inorder: order >< (origin >< destination), out outorder1 : order, outorder2 : order, ... outordern : order, val noftrucks : num, fun traveltime[x:origin >< destination] : real ] := channel trucks : truck init {}, T(in inorder, trucks, out outorder1, outorder2, .. outordern, trucks) where proc T [ in io : order >< (origin >< destination), it : truck, out oo1 : order, oo2 : order, .. oon : order, ot : truck ] := ot
