2SCCS gives us a more elegant encoding of Demos, but is slower when executing on the Concurrency .... (re)set/ obs/ lim/ min/ now/ % usage/ av. wait/qmax.
University of Leeds
SCHOOL OF COMPUTER STUDIES RESEARCH REPORT SERIES Report 97.12
Denotational Semantics for Process-Based Simulation Languages. Part 1: Demos by
G Birtwistle & C Tofts April 1997
Abstract In this paper we present a method for translating the synchronisation behaviour of a process oriented discrete event simulation language into a process algebra. Such translations serve two purposes. The rst exploits the formal structure of the target process algebraic representations to provide proofs of properties of the source system (such as deadlock freedom, fairness, liveness, ...) which can be very dicult to establish by simulation experiment. The second exploits the denotational semantics to better understand the language constructs as abstract entities and to reason about simulation models. Here we give the intuition and present the basic mechanisms using the Demos simulation language and the CCS and SCCS process algebras. The analysis of the synchronisations of full Demos is treated in a companion paper.
1 Introduction Many complex problems are studied by building simulation models that are intended to replicate their behaviour of interest [BFS87,Car88]. Once we have a model, the rst step is to validate it, i.e. show that it exhibits the expected behaviour to within a reasonable tolerance. However since model timings are \randomly" governed, we cannot guarantee that all model paths will be covered by simply running the simulation several times and so harmful behaviours, such as deadlock, may be missed. Recent work has demonstrated the e ectiveness of using a process algebra (CCS [Mil80,Mil89], SCCS [Mil83,Mil89], CSP [Hoa85]) to reason directly about the structure1 of complex systems. It has been applied to a range of problems from the throughput of a factory [VW92] to the behaviour of social insects [Tof90b, Tof91, Tof92a, Tof92b, THF92]. The approach permits formal proofs of such model properties as deadlock, livelock, safety, liveness (see [MP92] for an excellent survey) and its successes suggest that its extension to more general simulation methodologies may prove worthwhile. [BPT93] was a rst (practical) step in that direction and covered several simulation mechanisms including resources and waits until. This paper is a rst step towards formalising the methodology. We give the intuition and present the basic mechanisms using Demos [BT93a], a simpli ed version of Demos [Bir79] with synchronisations restricted to resources and bu ers. A formal treatment of full Demos is covered in a companion paper [TB95]. The most popular styles of programming simulation models are the activity based approach of CSL [Bux62] and ECSL [Cle85], the event based approach of GASP [PK69] and Simscript [KVM68], and the process based approach of GPSS [Sch74] and Simula [BDMN79]. It is quite straightforward to translate from the process based style to the activity and to the event based styles [Bir85,Mat74]. Hence, without loss of generality, we concentrate upon the process based approach as typi ed by the Demos [Bir79,Bir81,Kreu86] extension to Simula. Demos programs are collections of interacting processes in which each entity of interest in the model gets mapped into a speci c object in the program description. An object has its own data values, its own operators (local procedures), and its own action history (a sequence of tasks). Typically 1
By structure we mean the decomposition into objects and the synchronisations, but not the computational detail.
1
- R1
MAIN = O0 :::: R2
- O1 - O2
Rn
:::: - Om
Figure 1: Structure of a Demos program the MAIN program block initialises the system by creating all the system resources and establishing the constituent objects (or object streams) before letting the model run. Each process has its own local sequence control (shown as an arrow in gure 1 above) which keeps track of its own next action. In Demos programs, MAIN can be treated as just another object, which is very handy for non-standard shut-downs. Process-based models are well-structured both at the top-level and within each component, so only a few standard synchronisations are required to cover a wide range of problems. If we strip away all the purely computational aspects (data collection and reporting) from a process-based model, we are left with a description with the same structure but containing only synchronisations. Such skeletal descriptions are closely allied to system descriptions in process algebras for which there exists a considerable body of established techniques. Using these techniques we can test the stripped-down static description of a system expressed in a process algebraic notation to see if it is deadlock-free, livelock-free, etc. Importantly we apply these techniques directly to the static code skeleton, and can establish properties without running the model at all. This saves a considerable amount of expensive development and debugging time. In two previous papers [BT93a,BT94], the authors have given an operational semantics for the synchronisations of Demos. Operational semantics are quite detailed and are best suited to serve as implementation guides or for reasoning about an individual program run. In this paper we present a denotational de nition of a subset of Demos. Denotational de nitions are much more abstract than operational de nitions. Our abstraction replaces the Demos model, say M, by a \coarser" generalisation M' in which structurally irrelevant actions (such as data collection) are omitted, and the strict timings of M become arbitrarily long. The speci c queueing disciplines of M are also generalised. Informally, we can think of M' as being akin to a worst case version of M: if nothing bad can happen however M' unfolds, then the translation guarantees that it cannot happen in M either [BT93a]. The abstraction thus enables us to reason about properties that must hold over all possible model runs, however we modify the random drawings and however we modify the queueing disciplines. The disadvantage of using a (consistent yet) very coarse model is that it will permit some behaviours that are unrealisable in practice (e.g. M' takes a drawing from uniform(10, 20) to be arbitrarily short or arbitrarily long) so that it may report failure when none can occur in M. However every failure in M will be caught by M'. A more re ned target process algebra (see below) should be used when errors unrealisable in M occur in M'. 2
`Hand' translations of process-based simulation language constructs into CCS were presented and demonstrated to be of use in [BPT93]. It is clearly advantageous if the translation between the simulation language and the formal description can be achieved automatically, relieving the simular of that burden. In this paper we give a formal denotational semantics for Demos by providing translation schemata from this subset down to CCS and to SCCS, two of the most simple process algebras, both of which are mathematically well-de ned2. The semantics provide us with a system description in CCS (SCCS) that faithfully represents the original description in Demos. Given such a mapping, we can then exploit such tools as the Edinburgh Concurrency Workbench3 (henceforth the CWB) to examine the properties and consequences of the underlying simulation and thus make our model that much more reliable. Indeed, the presentation of semantics for programming languages of all kinds has many uses. A semantics can be exploited to understand the precise nature of the entities that compose a system, often leading to simpli cations in the presentation of the language, when apparently di erent linguistic constructs are observed to have the same semantic properties. The translation of programming languages into a formal system permits the production of proofs of properties of the language as a whole, constructs within the language, and particular programs written in the language. For example, the proof of conservatism of the (S)CCS representations of Demos [BT93b]. In this initial study, we examine the properties of Demos programs that can be addressed by (relatively) simple process calculi. Since neither CCS nor SCCS permit explicit probabilities, we concentrate on the synchronisation behaviour of Demos programs. This is arguably the hardest part to get right | after all, most deadlocks result from synchronisation and interaction diculties. We also ignore any structures upon queues | our formal proofs hold for all queueing disciplines (see [BT93b]). Restricting ourselves to CCS and SCCS is thus conservative in that we cannot take advantage of behaviours with speci c timings. However the same techniques can be applied to richer process algebras (e.g. the timed algebras of [Tof90a, MT90, Tof94], and also [Pra91] which contains broadcasting and restarts) that allow the description of a larger class of properties of Demos simulation systems. However these process algebras are much more complex and have limited automated support. They are thus not well-suited to initial forays into this research arena. As an aside, notice that our technique is safe in that (for example), deadlocks which may be avoided by precise timing constraints might well occur in practice in a real system in which the physical clocks are subject to skew. In next two sections we present the three languages used in this paper. Section 2 gives a brief description of how models are described in Demos with sample executions. Deadlock and livelock problems of models within the Demos s ystem are then discussed. Section 3 gives examples of how simulation problems can be encoded within the process algebras CCS and SCCS are presented as motivations for the underlying methodology of the translation of full Demos programs into either of the respective languages. In sections 4 and 5 we present translations of Demos into CCS and SCCS respectively. We represent a complete model in Demos as a process, which can then be used to formally derive properties of the original system. In Section 6 we provide an example of the output 2SCCS gives us a more elegant encoding of Demos, but is slower when executing on the Concurrency Workbench [CWB]. For paper and pencil work SCCS is probably superior, but CCS is currently superior for larger examples demanding automated methods 3The Edinburgh CWB can be obtained by anonymous FTP from ftp.dcs.ed.ac.uk
3
produced by an automatic compiler from Demos to CWB input for CCS and SCCS. Finally, in Section 7, we present a class of logics for formally describing the properties of agents which can be used to describe and derive properties of our simulation problems. In a companion paper [TB95] we develop a denotational semantics for the wait/coopt, waituntil, repetition, and conditional commands in Demos. The techniques and methods are presented in two parts as the translation methods needed for the compound statements are reasonably complex and obscure the underlying simplicity of the representation of Demos programs within a process calculus.
2 Modelling in Demos We use this section to introduce the two synchronisations of Demos followed by a small example which is referred to several times in the sequel. Programs in process-based simulation languages like GPSS (Simula, Demos) model major components by processes and abstract away minor components into resources. Demos has two types of resource, the res and the bin. The intention is that the entities represent the behavioural components in a system, res(ources) represent the xed supplies for which entities compete and bins are suppliers of consumables whose total availability is variable.
2.1 Entities Processes (synonyms: agents, entities, objects, transactions) are major system components whose behaviours warrant modelling in detail. In practice, such a behaviour can be described as a sequence (possibly cyclic) of tasks. Each task will usually require extra system resources to be acquired before it can commence. The entity will be blocked if the extra resources it needs for its next task are not available. At the end of each task, resources no longer required are released. The freeing of resources may enable blocked entities to continue. The informal Demos code skeletons below represent de nitions of a class of transient lorries which carry out three tasks and then quit the model, and of a class of vans which initialise themselves and then repeat two other tasks cyclically forever. lorry = lTask1, lTask2, lTask3 van
= vInit, repeat [ vTask1, vTask2 ]
4
2.2 Res(ources) Resources parallel storages in GPSS. The declarations newR("space", 4) newR("crane", 1) result in the creation of two res objects as shown in gure 2. res title avail q
res "space" 4
title avail q
procedure getR(n) procedure putR(n)
"crane" 2
procedure getR(n) procedure putR(n)
Figure 2: Two res objects Resources are created by executing newR whose arguments name the resource and x its initial size. Thereafter, avail is maintained by calls on getR and putR to record the current level of the resource pool and maintain the invariant 0 (VAN | 'putL1.'putC.nextV.VAN | VAN | getC.load.'putC.nextL.LORRY' | putC.CRANE | LOAD3 )\L --- t unload t t t nextV unload t t t t nextV unload t t t nextV unload t t t nextV unload t t t nextV unload
14
---> (VAN | VAN | 'putL1.'putC.nextV.VAN | getC.load.'putC.nextL.LORRY' | putC.CRANE | LOAD3 )\L --- t unload t t t nextV unload t t t t nextV unload t t t nextV unload t t t nextV unload t t nextV t unload ---> ('putL1.'putC.nextV.VAN | VAN | VAN | getC.load.'putC.nextL.LORRY' | putC.CRANE | LOAD3 )\L
Still not quite right | this time the vans have delivered two batches which have been seized by the lorry, but four more van loads have sneaked in before the lorry has seized the crane (perhaps the driver is taking a nap) lling the unloading area. The sixth van has now seized the crane but has nowhere to dump its load. Here is a deadlock free solution | the vans release the crane before announcing the arrival of a load. bi VAN' getC.unload.'putC.'putL1.nextV.VAN' bi SYS'' ( VAN' | VAN' | VAN' | LORRY | CRANE | LOADS ) \ L sort SYS **{load,nextL,nextV,unload} fd SYS'' **No such agents.
3.2 Modelling in SCCS As their names imply, SCCS and CCS are similar approaches to the description of concurrent systems (for a introductory explanation read [Mil89] Chapter 9). The major di erence is the approach to the parallel operator. In CCS we write P jQ for the process P in asynchronous parallel with Q, and in SCCS we write P Q for their synchronous parallel composition. In synchronous parallel, we insist that if the composition is to perform some action, then each of the components must perform some action and the resulting action is the composition of the components behaviour. Temporarily overloading the pre x operator, if we have P def = a:P and Q def = b:Q then P jQ = a:(P jQ) + b:(P jQ) and P Q = (a#b):(P Q). Within SCCS we have a structure upon actions. When we have a complementary pair of actions, say a and a in SCCS then we de ne that a#a = 1. 15
The 1 action witnesses one synchronous time step being performed with no visible computation, so it can also be used to represent the passage of one unit of time. Furthermore, we assume that our action composition operator # is commutative5 and associative, hence the order of formation of a parallel composition will not matter. In the sequel we shall distinguish SCCS and CCS processes by their parallel and pre x operators, we shall use the notation a : P to mean P pre xed by the synchronous action a. We now present a description of the language SCCS. For consistency, it mirrors that given for CCS earlier. The simplest agent within SCCS is the process 0 which does nothing. However, unlike its CCS counterpart, if we compose 0 in synchronous parallel with any other process, then that object can no longer perform any actions.
Pre xing The agent tick : 0 can perform a single tick action. To form a persistent process we write
Clock def = tick : Clock, which can perform any number of tick actions. We can de ne a Crane by Crane def = getC : putC : Crane, which behaves in a similar fashion to the CCS description of a crane. Non-Deterministic choice As in our CCS example if we wish to have a load that can get either 1 or 2 slots then we should write this process as: Loads0 def = putL1 : Loads1 + putL2 : Loads2 def Loads1 = getL1 : Loads0 + putL1 : Loads2 +putL2 : Loads3 Loads2 def = getL2 : Loads0 + getL1 : Loads1 +putL1 : Loads3 def Loads3 = getL2 : Loads1 + getL1 : Loads2 An important use of choice in SCCS is to allow us to de ne an operator that allows actions to wait for their complements. So far all of the actions we have de ned demand to be acted upon at once. For instance the Loads0 agent demands that it be able to perform the putL1 or putL2 actions immediately, if refused it deadlocks and stops the whole system. To permit processes to wait we make the following de nition of an auxiliary operator $: $P def = P + 1 : $P Now P can idle by performing 1's waiting for any process that will synchronise with it. So a more realistic description of the crane might be Crane def = $getC : $putC : Crane, now it can wait until it is wanted, and similarly wait until it is returned. Equally for the loads system: Loads0 def = $(putL1 : Loads1 + putL2 : Loads2 ) def Loads1 = $(getL1 : Loads0 + putL1 : Loads2 + putL2 : Loads3) Loads2 def = $(getL2 : Loads0 + getL1 : Loads1 + putL1 : Loads3 ) def Loads3 = $(getL2 : Loads1 + getL1 : Loads2 ) Formally we have a free abelian group over action names, with operator #, inverses being output actions, and the identity being 1. 5
16
The position of the $ pre x is important, if we simply distribute it before the actions, then some choices would no longer be available after one 1 had gone by. Parallel Composition We form the synchronous parallel composition of agents with the operator. In order to enforce local communication, we have a permission operator which lists those actions a process may perform. To perform actions not in the permission sets components must nd other components willing to synchronise upon that action. Consider the example system with just vans and a crane: Crane def = $getC : $putC : Crane def V an = $getC : unload : putC : nextV : V an
SY S
def
= (V an V an V an Crane)df1; unload; nextV g
In the above there are two forms of synchronisation: one where both the input and output actions are guarded by a $ (the getC action pair); and one where only the input is guarded by a $ (the putC pair). In the rst case these represent two asynchronous actions, in that they can both wait an arbitrary time before ring. Whilst the second case one action can wait, whilst the other must re as soon as it is encounters. Thus, using the above representations, Vans are willing to wait for the Crane to become available, but will return it as soon as they are nished with it. The Crane simply waits to be either taken or returned, and cannot a ect the timing of the behaviours. >From the state SY S there are two possible evolutions: SY S
!1 SY S 1 ! (V an unload : putC : nextV : V an V an $putC : Crane) df1; unload; nextV g
>From the second state we have the following derivation: unload ! t
!
(V an putC : nextV : V an V an $putC : Crane)
df1; unload; nextV g (V an nextV : V an V an Crane) df1; unload; nextV g
so the synchronisation on the putC action pair occurred at the rst opportunity. Whereas in the state SY S , the system need not perform the getC pair straight away. Notice that we can assume that we can always put the crane back at once, but we may have to wait to get it. For a synchronisation on an action pair, say getC we have the following four structures with respect to timing: 1. The pair is of the form $getC : ::: and $getC : ::: in which the actions can wait for an arbitrary time before performing the synchronisation, by performing 1 actions; 17
2. The pair is of the form getC : ::: and $getC : ::: in which the output can wait, but the input will be performed straight away; 3. The pair is of the form $getC : ::: and getC : ::: in which the output can wait but the input must be performed straight away; 4. The pair is of the form getC : ::: and getC : ::: in which they must synchronise at once. Obviously if both actions are not available at the same time step, then the above synchronisation can deadlock. Renaming This is identical to the situation in CCS, with the renaming functions being interpreted in the same manner. The description of our Demos model in SCCS would be the following: Crane def = $getC : $putC : Crane def Loads = Loads0 V an def = $getC : unload : putC : $putL1 : nextV : V an def Lorry = $getL2 : $getC : load : putC : nextL : Lorry def L = f1; nextV; unload; load; nextLg def SY S = (V an V an V an Lorry Crane Loads0)dL We can enter our above description of the Lorries and Vans problem into the workbench in SCCS mode, and demonstrate that it is deadlock free. fd SYS No such agents.
The detection and location of deadlock properties of systems is very important | see [Cla95] for an industrial strength example. The authors know of commercial hardware projects have been delayed for over a year whilst designers attempted to pinpoint a deadlock via simulation. Some commercial systems have been in use for extended periods of time before deadlocks or livelocks showed themselves, often with expensive recall consequences. Essentially our descriptions within CCS and SCCS will have the same behaviour, as Demos processes are deterministic. However, within SCCS we have the ability to form compound atomic actions (e.g., a#b begin a and b performed simultaneously in parallel) which can greatly simplify the de nition of some of the auxiliary processes within the Demos language as we shall see in Section 5. Also for future development SCCS gives us the potential to address simple timing properties of Demos.
4 Translating Demos into CCS In this section we demonstrate how a general Demos program can be represented as a CCS process. To achieve the translation we must nd process encodings for all of the parts that make up a Demos 18
program. In particular process algebras do not (generally) have auxiliary data structures such as monitors, queues or variables. Thus we have to provide explicit process constructions for all of our system components. For comparison, a similar semantic construction for shared-variable While programs is presented in Milner's book [Mil89].
4.1 Translating Resources As we have seen from the earlier examples, the resources used in a Demos program have to be represented explicitly by processes. In our example we had a crane resource, of which there was only one element, which we represented as the following process:
Crane def = getC:putC:Crane To translate a general Demos program into CCS we are going to need to represent arbitrary resources. In particular we need to represent resources that have more than one element. To achieve this we need two things, actions that represent the getting or putting of resources, and a process or processes that keep track of the current state of each resource. In process algebraic terms, by far the simplest way of implementing the above is to have a separate process for each unit of a resource, with all of the units having the same access channel names. Multiple amounts of the resource can be claimed by issuing multiple single requests or releases. For example if we had two cranes then a natural representation of this resource would be the process: TwoCrane def = CranejCrane This process functions as we would expect. That is, it can perform the action getC and reach a state putC:CranejCrane, where one of the Cranes has been taken. Note that as our parallel operator is commutative, it does not matter which. >From this state it can perform another getC to reach the state putC:CranejputC:Crane which cannot perform a further getC action without rst performing (at least one) putC action. In this state both of the cranes have been acquired. So from the point of view of the cranes, it is possible to represent correctly a resource of two cranes by the parallel composition of two Crane processes. But, unfortunately, as it stands, this will not work from the point of view of the processes which use the resources. Consider a lorry which needs two cranes in order to unload. We would describe such a lorry as follows: TwoLorry def = getC:TwoLorry0 TwoLorry0 def = getC:unload:putC:putC:TwoLorry With the appropriate restrictions, this will function satisfactorily on its own in parallel with the cranes. But consider the consequences of using two of these lorries simultaneously. Such a system would be written: 19
(TwoLorryjTwoLorryjTwoCrane)nfgetC; putC g If we regard the getR(crane; 2) action in the Demos program as atomic then we would not expect the above process to deadlock. Unfortunately this translation can by reaching the state: (TwoLorry0jTwoLorry0 jputC:CranejputC:Crane)nfgetC;putC g At this point neither TwoLorry0 is willing to give up a crane. Since both of them require another crane, the system has deadlocked. Within CCS there is no simple way that we can indicate that a collection of actions should be regarded as atomic. Thus if we wish to represent a resource which has amounts greater than one we shall have to use another representation in CCS. Potentially we could use some form of wait until in this case, but for the moment we wish to avoid the complications that introduces. However, even with waits until it is not possible to represent multiple resources as parallel compositions of single resources in an asynchronous calculus. The method we use is to introduce actions that record how much of the resource is being got or how much is being put. In the case of two cranes, depending on its state, we can either get or put one or two cranes. So access to its representing process will be achieved through the actions getC 1 and getC 2 representing getting one or two cranes, and putC 1 or putC 2 representing putting one or two cranes. Getting two cranes has now been represented by an atomic action, and thus interference will no longer be possible. So our TwoCrane process should be rede ned as follows:
TwoCrane0 def = getC 1:TwoCrane1 + getC 2:TwoCrane2 def TwoCrane1 = getC 1:TwoCrane2 + putC 1:TwoCrane0 TwoCrane2 def = putC 1:TwoCrane1 + putC 2:TwoCrane0 Obviously in general we have resources with an amount n, but the structure of the above process indicates how we might implement such a process, and what the access actions will look like. Given a resource named Res, of which there is a maximum amount n available, we shall use the actions getRes1, getRes2, . . . , getResn to represent the acquisition of 1 to n amounts of the resource respectively. The actions putRes1, putRes2 . . . , putResn will represent returning the respective amounts of resource to the resource pool. So the process which represents the resource Res can be written as follows, by taking a generic resource process of size m and renaming its access actions appropriately. A more elegant way of achieving the above is to de ne a general resource of size m
R(m; m) def = Pii==1m geti:R(m ? i; m) ... R(j; m) def = Pii==1j geti:R(j ? i; m)+ Pii==1m?j puti:R(j + i; m) ... R(0; m) def = Pii==1m puti:R(i; m) 20
Then to create a speci c resource process, with its appropriate access channels, we take the above process and rename its actions:
Res(i; n) def = R(i; n) [putRj=putj; getRj=getj j1 j n] from the above we can observe that all resources of a particular size are identical up to the renaming of access channels.
4.2 Translating Bins In Demos a distinction is made between those objects which are claimed and released by the same process, called resources, and those into which items are placed by one process and removed by another, called bins. We could model a generic bin entity by the following CCS process which creates a process for each item currently stored in the bin:
B def = putB:(B jgetB:0) Whilst this representation is very simple, it su ers from the same problems as our attempt to de ne multiple resources as parallel composition of single resources. This representation of a bin has the restriction that only one extra object can be put into it at any instant, which is acceptable. Unfortunately, a bin with two items in it has exactly the same deadlock problems as our earlier example of the two cranes. Since we cannot force the taking of two items to be atomic, but must perform each take separately. With bins we will use actions that not only represent the giving and taking of items, but also represent how many items have been exchanged. Unfortunately6 at this point we shall have to assume that our bins are nite in order to successfully encode them. The only distinguishing feature between a nite bin, and a resource is that we do not assume that the same process gives and takes items from the bin. In terms of its operation it is indistinguishable from a resource of the appropriate size. We choose actions putBi and getBi to represent giving or taking i items from a bin B. Notice that these are both input actions as the bin is assumed to be responding to instructions from Demos processes. With the observation that the bin is the same as a resource we can achieve a bin with a maximum capacity7 of maxbin as the following process:
B (i; n) def = R(i; n) [putBj=putj; getBj=getj j1 j maxbin] In practice this is the case in Demos as well. It is possibly a language design aw that bu ers and bins were distinguished originally { one of the problems of designing languages without a semantic basis at the outset. 7We assume that there is some xed maximum capacity for all bins (max ) before embarking on the translation. bin 6
21
4.3 Translating processes The entities that use resources and bins are Demos processes. It is natural to translate each of these processes as a separate CCS agent. So when in a Demos process we see an action getR(res; i) we shall translate this into getResi, note that this is the complimentary output action to that of the resource. We do no checking to see whether this amount of resource is available, as the action can only synchronize with its dual when the complimentary input can be performed, which implies that the appropriate amount (or more) of the resource is indeed available. All of the other interactions with bins and resources are modeled similarly. We make the sole assumption that processes do not attempt to hand back more of a resource than they took, unlike the operational semantics of [BT93a] which makes considerable e orts to identify such run time errors. A compile time syntactic check could be made to ensure this in any implementation. We use hold(Time) actions as markers | they will be translated directly as sTime:f Time actions for our representative processes. At this point we have analogues in terms of actions for a CCS process for all of the activities of a Demos process. These are summarized below. We write [ Obj ] to mean the translation of a piece of Demos syntax into a piece of CCS syntax. [ getR(R; i)]] [ putR(R; i)]] [ getB (B; i)]] [ putB (B; i)]] [ hold(T )]]
def = def = def = def = def
getRi putRi getBi putBi = sT:f T
To complete our translation of Demos processes we must put the full local sequence of behaviours into CCS. This is naturally achieved by the use of action pre x. We have not permitted any of the Demos processes to branch. In which case each process is either a simple sequence of actions that is performed once, or a sequence of actions executed repeatedly until the simulation time is exhausted. We assume that the body of a Demos process is a list of actions, we shall use the operator :: to denote list concatenation. So to translate a list of actions we simply recurse down the list translating each action in turn and pre xing to the remaining actions. We leave the precise interpretation of the empty list brie y as this depends on whether the action sequence is to be repeated or not. Formally our translation of action sequences is as follows: [ action :: acts] def = [ action] :[ acts] Notice that in some senses we have simply swapped list concatenation for action pre x.
4.4 Translating Demos programs We are now in a position to translate entire Demos programs into CCS. The translation will be upon Demos programs in our compact notation; which are simply lists of de nitions, each one specifying 22
either a Demos process, a resource, or a bin. To achieve our translation we shall simply take each of these entities in turn and convert it into its representative CCS process. We shall then compose that collection of process together in parallel, nally restrict that parallel composition with respect to the communication channels performing the exchanges of information between the parts of the Demos program. The rst translation we make is that for Demos processes, we distinguish the processes that execute once from those that execute repeatedly, assuming that if a repeat is used it starts the process de nition (process de nitions can always be arranged in this way). [ newP (N; repeat acts; time)]] def = X:[ acts] :X def [ newP (N; acts; time)]] = [ acts] :0 All the x point operator does is to produce arbitrarily many copies of the body of the process de nition in sequence. It is merely a di erent way of writing X def = [ actions] :X but avoids extra names. Notice that this implies two di erent interpretations of the empty list of actions, in one case it should be instantiated by a process variable, in the other by the 0 process. When we come to translate the wait-until construct it will be necessary to make this separation clear, but for simplicity we avoid it in this initial translation. To translate resources and bins we use the following translations: [ newR(N; max)]] def = R(max; max) [getNi=geti; putNi=putij1 i max] def [ newB(N; init)]] = R(init; maxbin) [putNi=puti; getNi=getij1 i maxbin]
The de nitions were supplied in a list, so we need to take each of the entities speci ed and replace it by the appropriate CCS representation, then composing those together in parallel. Thus we arrive at the following interpretation of a collection of Demos de nitions: [ Defn :: Defns] def = [ Defn] j[ Defns] def [ []]] = 0 (Remember that P j0 = P .) So far we have translated all of the components of a Demos program but at this point we have not forced them to exchange information, this is achieved by restriction on all the communication labels which have been de ned as part of the representative CCS processes. We call the function that gives us the appropriate restriction set L, and de ne it recursively by cases over the syntax of Demos. For our resources and bins we must ensure that each of the possible giving or taking actions is restricted in the eventual process. So we must add: L(newR(N; max)) def = fgetNi; putNij1 i maxg def L(newB (N; max)) = fputNi; getNij1 i maxg L(newP (N; acts; evTime)) def = fg 23
Formally we de ne the set of restriction actions generated by a list of Demos de nitions as follows:
L(Defn :: Defns) def = L(Defn) [ L(Defns) def L([]) = ; So now the nal translation of a Demos program into a CCS process is de ned as follows:
SIMCCS = ([[Defns] )nL(Defns) The semantics describes Demos as a collection of interacting parallel components, hopefully this matches the original intent of Demos. It should be noted that all of the entity classes of Demos are equal in this representation, they are all processes. The only di erence amongst them is whether the generate input or output actions on channels.
Example 4.1 For the nal version crane system we would arrive at the following translation (with
maxbin = 3):
V an Lorry Crane Loads L SIMCCS
def = def = def = def = def = def
X:getCrane1:stunload:ftunload:putCrane1:putLoad1:X X:getLoad2:getCrane1:stload:ftload:putCrane1:X R(1; 1)[getCrane1=get1; putCrane1=put1] R(0; 2)[putLoadi=geti; getLoadi=putij1 i 3] fgetCrane1; putCrane1g [ fgetLoadsi; putLoadsij1 i 3g = (V anjV anjV anjLorryjCranejLoads)nL
Notice that the above is not as simple as the original hand translation. This is normal when replacing hand compilation with automatic compilation. The above activity has been automated by the production of an SML program which translates Demos programs into workbench code [TB93a]. The translator, which is only 200 lines of SML, is available from CT upon request. Translations for more advanced constructs such as wait until from Demos to CCS follow in much the same way (see the companion paper [TB95]).
5 Translating Demos into SCCS As with our CCS translation we begin by de ning the translation of the xed processes in the environment. Resources are translated as follows: (whilst we overload names, the use of di erent pre xing conventions will distinguish the CCS and SCCS processes)
Res def = $get : $put : Res 24
To produce a resource of size m we simply provide m copies of the above process executing in parallel. We leave its precise de nition to the point where we de ne the translation of Demos de nitions, but we note that, the system (Sys) as de ned below does not deadlock:
Thing def = $get2 : Thing0 def Sys = (Res Res Thing Thing)df1g since we are able to generate atomic actions that represent the simultaneous performance of two gets. To represent our bins, we spawn a agent which when accessed dies, witnessing the presence of an object in a bin. Along with an agent that can produce new copies of witnessing agents: InBin def = $get : $0 def Bin = $put : (InBin Bin) this representation allows for bins with arbitrary capacity, but we only permit one extra item to be placed in the bin at any instant. Obviously we could allow more then one item to be added at a single instant, but for the moment we concentrate on the simpler problem. If we take the bin to be nite, we can represent them in the same fashion as resources. Demos processes are translated by providing an appropriate SCCS action for each process request as before, and each Demos process is represented as a separate SCCS process. The actions generated are those necessary for interaction with the resources, bins and other Demos processes. [ action :: acts] [ getR(R; i)]] [ putR(R; i)]] [ getB (B;i)]] [ putB (B; i)]] [ hold(T )]]
def = def = def = def = def = def
[ action] : [ acts] $getRi putRi $getBi $putBi = $sT : $f T
We use the notation Prn to mean n copies of the process Pr running in parallel. The combination as synchronous compound actions, and the asynchrony operator $ of SCCS permits us to describe the entities of a Demos system in a far more ecient manner. To translate the de nitional part of Demos we proceed as before, converting each de nition into the appropriate process. [ defn :: defns] [ newP (Name; repeat(acts);time)]] [ newP (N; acts; time)]] [ newR(N; amt)]] [ newB (N; amt)]]
def = def = def = def = def
[ defn] [ defns] X:[ acts] : X [ acts] : 0 (Res[getN=get; putN=put])amt = Bin[putN=put; getN=get] 25
To complete our translation we need to de ne the permission set of a collection of Demos de nitions as follows:
P (defn; DEFNS ) def = P (defn) [ P (DEFNS ) def P (newP (Name; acts; time)) = fsstr; fstrjhold(str) 2 actsg So the translation of a Demos program into SCCS is as follows:
SIMSCCS (DEFNS ) def = ([[DEFNS ] )dL(DEFNS )
Example 5.1 For the crane system we would arrive at the following collection of processes: V an Lorry Crane Loads SIMSCCS
def = def = def = def = def
X:$getCrane1 : stunload : ftunload : putCrane1 : putLoad1 : X X:$getLoad2 : getCrane1 : stload : ftload : putCrane1 : X $getCrane : $putCrane : Crane $(putLoad : (Loads $getLoad : $0) = (V an V an V an Lorry Crane Loads) dfstload; ftload; stunload; ftunloadg
In this case our mechanical translation is much closer to our hand translation, as a result of the compound actions of SCCS, and the ability to desynchronise events with the $ operator.
6 Example of automated translation Below we present the translation of our running Demos program into CCS and SCCS.
CCS bi Crane0 putCrane1.Crane1+\ 0 bi Crane1 getCrane1.Crane0+\ 0 bi Loads0 putLoads1.Loads1+\ putLoads2.Loads2+\ 0 bi Loads1 getLoads1.Loads0 +\
26
putLoads1.Loads2+\ 0 bi Loads2 getLoads1.Loads1+\ getLoads2.Loads0+\ 0 bi Van1 'getCrane1.sunload.funload.'putLoads1.'putCrane1.Van1 bi Van2 'getCrane1.sunload.funload.'putLoads1.'putCrane1.Van2 bi Van3 'getCrane1.sunload.funload.'putLoads1.'putCrane1.Van3 bi Lorry 'getCrane1.'getLoads2.sload.fload.'putCrane1.Lorry bi SIM (Lorry|Van3|Van2|Van1|Loads0|Crane1) \ \{getLoads1,putLoads1,getLoads2,putLoads2,getCrane1,putCrane1}
SCCS bi Crane $getCrane:$putCrane:Crane bi LoadsBn $putLoads:($getLoads:$0|LoadsBn) bi Loads $getLoads:$0 bi Van1 $'getCrane^1:$sunload:$funload:$'putLoads^1:'putCrane^1:Van1 bi Van2 $'getCrane^1:$sunload:$funload:$'putLoads^1:'putCrane^1:Van2 bi Van3 $'getCrane^1:$sunload:$funload:$'putLoads^1:'putCrane^1:Van3 bi Lorry $'getCrane^1:$'getLoads^2:$sload:$fload:'putCrane^1:Lorry bi SIM (Lorry|Van3|Van2|Van1|LoadsBn|Crane)\{sload,fload,sunload,funload}
In many respects the SCCS translation seems both more natural and simpler than the CCS one, this is mainly as a result of the ability to form composite atomic SCCS actions. In SCCS we can 27
perform multi-way synchronisation directly, this is unfortunately not possible in CCS resulting in a far more complex translation of Demos programs.
7 Performing Experiments Given that we have expended some e ort to represent a Demos simulation problem as a CCS or SCCS process, we should like to be able to recover properties of the original system by asking questions of the process representation. Within a process algebra there are essentially two methods of gaining information about a processes behaviour: the rst is to demonstrate that it is equivalent to some known process; the second is to demonstrate that the process obeys some logical constraints. Clearly the rst approach is inappropriate for simulation, so we shall concentrate on the second. The demonstration that a process satis es some logical constraints can be regarded as the performance of an experiment upon the process. We state the behaviour we should like to see the process exhibit (within a suitable logic) and observe whether or not that is the case. A suitable logic for processes is Hennessy Milner logic, and its extension for properties of non-terminating systems the modal- calculus. The checking of properties of these logics has been eciently automated within the CWB. The technical details of these two logical systems have been well presented elsewhere and we recommend [Sti87,Mil89] for Hennessy-Milner logic (HML) and [Sti92] for a technical introduction to the modal- calculus. For the related temporal logic observation of properties, see [MP92]. An introduction to the use of process logics to the formal observation of the properties of simulation systems can be found in [BPT93]. We present some simple motivating examples to demonstrate the e ectiveness and simplicity of process logics. The basic modality is < a > C , which states that a process can perform the action a and reach a state where the formula C can be satis ed. A formal presentation of the satisfaction rules for HML can be found in either [Sti87,Mil89]. We can use statements of the above form to demonstrate that nite systems perform correctly, assuming the use of the other standard logical operators. We permit ourselves to write > C to mean that if there is an observable action sequence a which a process can perform, then it can reach a state satisfying C . As an example consider the following Demos program, assuming bins have a maximum capacity of 2:
TEST def = newB(B,0), newP(A, [putB(B,1), hold(a), putB(B,1), hold(a)], 0], newP(B, [putB(B,1), hold(b), putB(B,1), hold(b)], 0], newP(C, [getB(B,2), hold(c)], 0) If such a system is working correctly we must see inputs to the bin, marked by either an sa or a sb action, before we see an output, marked by the sc action. This we can translate as the following HML formula; 28
F1 def = T _ T _ T _ T If we consider the translation of the above system into CCS then we can observe that F1 j= SIMCCS (TEST ). This logic is sucient for properties of nite processes, but most simulation systems contain cyclic components whose behaviour is repeated as often as necessary. HML has been extended with x point operators (to form the modal- calculus) to permit the description of the properties of persistant systems. Whilst modal- is very expressive, its formulae are extremely dicult to read, and therefore most properties are usually expressed via high-level macros. Two important temporal modalities that can be expressed as macros within modal and the \always" (Bx) and \eventually" (Ev) operators. These macros can be found in the standard CWB temporal logic formulae set. The modality Bx checks that at all states in a process graph the formula following it holds. The modality Ev checks that for all states of an agent graph, there is a path leading to a place where the formula it guards holds. As an abbreviation < ? > means any possible transition. So the formula < ? > T means that it is possible to perform some action. Hence, clearly the formula: Bx(< ? > T ) means that at all states it is possible to do some action, or alternatively any process satisfying it is deadlock free. For livelock freedom, < ? > T means that a process can do something other than a , hence:
Bx(Ev < ? > T ) means that a process can always eventually perform a visible action, or in other words it is livelock free. Similarly in the vans and lorries example, the formula:
Bx(Ev < sunload > T ) means that it is always possible that another van will be allowed to unload, in other words the system is live with respect to vans. A further useful macro is Nec a b which states that the action a must occur before the action b can occur, allowing any other actions to occur. In other words in any action trace into the future, we cannot see the action b until we have seen the action a. We can de ne formula which express the correct maintenance of mutual exclusion, and apply them to the following example. newR(R, 1) newP(P1,[repeat[getR(R,1), hold(c1), putR(R,1)]], 0) newP(P2,[repeat[getR(R,1), hold(c2), putR(R,1)]] ,0) 29
If the above system is functioning correctly then P 1 and P 2 should not be able to simultaneously perform their hold actions. We de ne the following modal- formula:
Fsafe1 def = Bx[sc1]((Nec fc1 sc1) ^ (Nec fc1 sc2)) def Fsafe2 = Bx[sc2]((Nec fc2 sc1) ^ (Nec fc2 sc2)) Fsafe def = Fsafe1 ^ Fsafe2 which expresses the property that the two processes cannot be in the critical section together. The following formula states that a process which enters its critical section, can leave it Flive def = Ev(( T ) ^ ( T )) Indeed we can demonstrate using the CWB that the CCS process representing the Demos simulation for mutual exclusion satis es this property.
8 Conclusions and Further Work We have demonstrated how the synchronisation fragment of Demos can be represented within two di erent process calculi. Our translation schemata can be extended to cover some of the remaining constructs of Demos, such as wait until and conditionals, reasonably straightforwardly [TB95]. The mapping of Demos into CCS and SCCS can be regarded as providing a denotational description of a simulation problem described within Demos, and provides a method for formally reasoning about the properties of Demos models. In this paper we have described some methods for testing such systems for deadlock, livelock and other safety and liveness properties. Our choice of the process calculi CCS and SCCS allows us to exploit the Edinburgh Concurrency Workbench [CWB] to automatically examine the poperties of our simulation problems. Further, we have succesfully automated the compilation of Demos programs into CCS and SCCS workbench source code. To examine the faithfulness of our encoding of Demos we are comparing the denotational account of Demos given here, with the operational account of Demos given in [BT93a]. Our claims that this is semantics conserves all of the possible interactions within the Demos system can be justi ed by demonstrating that our system simulates the operational semantics. That is it can match any behaviour of the operational semantics, but may have many other possible behaviours. Hence, any property that can be proved over all the behaviours of the denotational description must hold for the limited subset of those behaviours which would be observed from the operational description. An analysis of these problems can be found in [BT93b]. An interesting observation is the relative simplicity of the SCCS semantics for the Demos language compared with that of the CCS semantics. This results for the ability to construct compound atomic actions in SCCS and suggests that further more detailed studies of general simulation systems should be undertaken in formal languages with this degree of expressiveness [vGSST90, Tof90a, CW90, Tof94]. Equally it will be interesting to compare the e ectiveness of other more expressive process algebras (such as [MT90, Han92]) at expressing the temporal or probabilistic properties of simulations. 30
Acknowledgements The material presented here has been under development some time and has bene tted from many excellent discussions with Faron Moller and Mathew Morley to whom we extend our thanks and gratitude.
Bibliography
[BDMN79] G. Birtwistle, O-J Dahl, B. Myhrhaug and K. Nygaard, Simula Begin, 2nd Edition,
Studentlitteratur, Lund, Sweden, 1979. [BFS87] P. Bratley, B. Fox and L. Schrage, A guide to simulation, second edition, 1987. [Bir79] G. Birtwistle, Demos | discrete event modelling on Simula. Macmillen, 1979. [Bir81] G. Birtwistle, Demos Implementation Guide and Reference Manual, University of Calgary Research Report number 81/70/22, 1981. [Bir85] G. Birtwistle, P. A. Luker, G. Lomow, and B.Unger, Process style packages for discrete event modelling: Experience from the transaction, activity, and event approaches. Transactions on Simulation, 2(1), 27{56, 1985. [BK84] J. A. Bergstra, J.W. Klop, The algebra of recursively de ned processes and the algebra of regular processes, in Proc 11th ICALP, Springer LNCS 172, pp 82-85, 1984. [BPT93] G. M. Birtwistle, R. Pooley and C. Tofts, Characterising the Structure of Simulation Models in CCS. Transactions of the Society for Computer Simulation, 10(3), pp 205{236, 1993. [BT93a] G. Birtwistle and C. Tofts, Operational Semantics for Process-Based Simulation Languages. Part 1: Demos. Transactions of the Society for Computer Simulation, 10(4), pp 299{333, 1993. [BT93b] G. Birtwistle and C. Tofts, The Relationship Between an Operational and a Denotational Account of Demos, Submitted to Eurosim. [BT94] G. Birtwistle and C. Tofts, Operational Semantics for Process-Based Simulation Languages. Part 2: Demos. Transactions of the Society for Computer Simulation, 11(4), pp 299{333, 1994. [Bux62] J. N. Buxton and J. G. Laski, Control and Simulation Language, The Computer Journal, 5, 1962. [Bux68] J.N. Buxton (Ed), Simulation Programming Languages, Proceedings of the IFIP Working Conference on Simulation Programming Languages. [Car88] A. S. Carrie. Simulation of Manufacturing Systems. J. Wiley and Sons, 1988. [Cla95] E. M. Clarke, O. Grumberg, H. Hiraishi, S. Jha, D. E. Long, K. L. McMillan and L. A. Ness, Veri cation of the Futurebus+ Cache Coherence Protocol. Formal Methods in System Design, 6(2), pp 217{232, March 1995. [Cle85] A. T. Clementson, ECSL User Manual, Cle-Com Ltd., Birmingham, England. [CW90] J. Camilleri, G. Winskel, CCS with priority choice. Proceedings of the sixth IEEE symposium on Logic in Computer Science, July 1990. [CWB] The Edinburgh Concurrency Workbench, Technical Note, Faron Moller, Department of Computer Science, University of Edinburgh. 31
[vGSST90] R. von Glabbeek, S. Smolka, B. Ste en and C. Tofts, Reactive, Generative and Strati ed Models of Probabilistic Processes, in proceedings LICS '90. [Han92] H. Hansson, Process with Probability and Time, in Proceedings Euromicro '92, Special
Interest Group on Real Time Systems. [Hoa85] C. Hoare, Communicating Sequential Processes, Prentice-Hall, 1985. [Kreu86] W. Kreutzer, System simulation | programming styles and languages. Addison Wesley, 1986. [KVM68] P.J. Kiviat, R. Villanueva and H.M. Markovitz, The SIMSCRIPT II Programming Language, Englewood Cli s, NJ, Prentice Hall, 1968. [Mat74] S.C. Mathewson, Simulation Program Generators, Simulation, pp 181{189, June, 1974. [Mil80] R. Milner, A Calculus of Communicating Systems, LNCS 92, Springer Verlag. [Mil83] R. Milner, Calculi for Synchrony and Asynchrony, Journal of Theoretical Computer Science, 25(3), pp 267-310, 1983. [Mil89] R. Milner, Communication and Concurrency, Prentice-Hall 1989. [MP92] Z. Manna and A. Pnueli, The Temporal Logic of Reactive Systems: speci cation, SpringerVerlag, New York, 1992. [MT90] F. Moller, C. Tofts, A Temporal Calculus of Communicating Systems, Proceedings CONCUR '90, Springer-Verlag LNCS 458. [Pool91] Towards a standard for hierachical process oriened discrete event simulations, Transactions of the Society for Computer Simulation, 8(1), pp 1{20, 21{32, 33{42, 1991. [Pra91] K.V.S. Prasad, Combinators and Bisimulation Proofs for Restartable Systems, PhD Thesis University of Edinburgh, 1991 [PK69] A.A.B.Pritsker and P.J.Kiviat,Simulation with GASP II, Prentice-Hall, 1969. [Sch74] T.J. Schriber, Simulation using GPSS, John Wiley, 1974 [Sti87] C. Stirling, Modal Logics for Communicating Systems, Theoretical Computer Science 49:311347. [Sti92] C. Stirling, Modal and Temporal Logics for Processes, Research Report number ECS-LFCS92-221, Department of Computer Science, University of Edinburgh. [TB93a] C. Tofts and G. Birtwistle, Process Semantics for Simulation, Department of Computer Science Report, University College Swansea, 1993 [TB95] C. Tofts and G. Birtwistle, Denotational Semantics for Process-Based Simulation Languages. Part 2: Demos. Research Report, University of Calgary and University of Calgary. [THF92] C. Tofts, M.J. Hatcher, and N.R. Franks, The Autosynchronisation of the Ant Leptothorax acervorum(Flavius): Theory, Testability and Experiment, Journal of Theoretical Biology, 157: 71-82. [Tof90a] C. Tofts, A Calculus of Relative Frequency, Proceedings CONCUR '90, LNCS 458. [Tof90b] C. Tofts, The Autosynchronisation of Leptothorax acervorum (Fabricius), Described in WSCCS. LFCS Report number 128, Dept of Computer Science, Edinburgh University. [Tof91] C. Tofts, Task Allocation in Monomorphic Ant Species, LFCS Report number 144, Dept of Computer Science, Edinburgh University. [Tof92a] C. Tofts, Algorithms for Task Allocation in Ants (A Study of Temporal Polyethism: Theory), in press Journal of Mathematical Biology. 32
[Tof92b] C. Tofts, Using Process Algebra to Describe Social Insect Behaviour, Transactions of the Society for Computer Simulation, 227-283, 1992. [Tof93] C. Tofts, Processes with Probability, Priority and Time, Formal Aspects of Computer Sci-
ence, 6(5): 536-564, 1994 [VW92] S. F. M. van Vlijmen, A. van Waveren, An Algebraic Speci cation of a Model Factory, Research Report, University of Amsterdam Programming research Group, 1992.
Graham Birtwistle has been a professor of Formal Methods at the University of Leeds since May 1995, prior to which he was at the University of Calgary for 15 years. He has a BSc in Mathematics (1960), a PhD in Applied Mathematics (1965) and a DSc in Pure Science (1988) all from the University of Sheeld, UK. His research interests lie in the modelling, speci cation and veri cation of system-level models with applications to asynchronous hardware and network hardware and software. Chris Tofts is an EPSRC Advanced Research Fellow at the University of Leeds. His research inter-
ests include the formal representation of probabalistic, prioritized and real time concurrent computation, the semantics of simulation languages and the application of discrete modelling methodologies to biological systems. He received his PhD in Theoretical Computer Science from Edinburgh University in 1991 and worked at the Universities of Bath, Swansea, and Manchester before moving to Leeds in 1996.
Appendix A: Trace of program 1 clock time = 0.000 ********************************************************************** * * * t r a c i n g c o m m e n c e s * * * ********************************************************************** time/ current 0.000 Demos
12.264 van 1 22.142 van 3 23.118 van 1
van 3
and its action(s) schedules van 1 at 12.264 schedules van 2 at 135.552 schedules van 3 at 22.142 schedules lorry 1 at 46.126 holds for 120.000, until 120.000 seizes 1 of crane holds for 10.854, until 23.118 awaits 1 of crane gives 1 to loads releases 1 to crane holds for 9.825, until 32.942 seizes 1 of crane
33
25.968
32.942 van 1 42.127 van 3 46.126 lorry 1 50.148 van 1
van 3 54.600 van 1 63.045 van 3
lorry 1
87.196 van 3 90.226 lorry 1 van 1 92.544 lorry 1 105.908 van 1
van 3 110.199 van 1 116.331 van 3
lorry 1
holds for 2.850, until 25.968 gives 1 to loads releases 1 to crane holds for 16.159, until 42.127 seizes 1 of crane holds for 17.206, until 50.148 awaits 1 of crane awaits 1 of crane gives 1 to loads releases 1 to crane holds for 4.452, until 54.600 seizes 1 of crane holds for 12.897, until 63.045 awaits 1 of crane gives 1 to loads releases 1 to crane holds for 24.151, until 87.196 seizes 1 of crane seizes 2 of loads holds for 27.181, until 90.226 awaits 1 of crane releases 1 to crane holds for 2.318, until 92.544 seizes 1 of crane holds for 15.682, until 105.908 awaits 1 of crane gives 1 to loads releases 1 to crane holds for 4.291, until 110.199 seizes 1 of crane holds for 10.423, until 116.331 awaits 1 of crane gives 1 to loads releases 1 to crane holds for 46.183, until 162.513 seizes 1 of crane seizes 2 of loads holds for 24.966, until 141.296
clock time = 120.000 ********************************************************************** * * * r e p o r t * * * **********************************************************************
d i s t r i b u t i o n s *************************
34
title unload load nextV nextL
/
(re)set/ 0.000 0.000 0.000 0.000
obs/type 6 normal 2 normal 9 negexp 2 negexp
/
a/ 12.000 24.000 5.000&-002 1.000&-002
b/ seed 4.000 33427485 4.000 22276755 46847980 43859043
r e s o u r c e s ***************** title crane
/
(re)set/ 0.000
obs/ lim/ min/ now/ 7 1 0 0
% usage/ av. wait/qmax 83.968 13.005 2
b i n s ******* title loads
/
(re)set/ 0.000
obs/init/ max/ now/ av. free/ av. wait/qmax 6 0 4 2 1.785 0.000 1
35
