Behavioural equivalence in simulation modelling

Simulation Modelling Practice and Theory 15 (2007) 1–20 www.elsevier.com/locate/simpat

Behavioural equivalence in simulation modelling Rob Pooley School of Mathematical and Computer Sciences, Heriot-Watt University, Mountbatten Building, Edinburgh EH14 4AS, UK Received 15 March 2005; received in revised form 30 August 2006; accepted 31 August 2006 Available online 20 October 2006

Abstract Discrete event simulation has grown up as a practical technique for estimating the quantitative behaviour of systems, where direct measurement is undesirable or impractical. It is also used to understand the detailed functional behaviour of such systems. Its theory is largely that of experimental science, centering on statistical approaches to validation, rather than on the verification of detailed behaviour. On the other hand, much work has been done on understanding and proving functional properties of systems, using techniques of formal specification and concurrency modelling. This article presents an approach to understanding equivalence of behaviour of discrete event simulation models, using a technique from the concurrency world, Milner’s Calculus of Communicating Systems (CCS). This yields a significant advance over the main previous work, Schruben and Yu¨cesan’s simulation graphs. CCS allows for the use of observational equivalence, which can capture a more flexible, behavioural notion of equivalence than the structural equivalence defined there. A common framework based on the process view of models is constructed, using a hierarchical graphical modelling language (Extended Activity Diagrams). This language is shown to map onto both the major constructs of the DEMOS discrete event simulation language and the corresponding CCS models. A graphically driven tool based on such a framework is presented, which generates both types of models. Using the CCS model, behavioural equivalences and differences in simulation models are demonstrated. Ó 2006 Elsevier B.V. All rights reserved. Keywords: Model equivalence; Process view; Process algebra; Graphical interface

1. Introduction In designing complex systems, simulation is often used to establish both quantitative (performance) and qualitative (behavioural) properties. For quantitative properties analytical or numerical modelling, using queues or stochastic extensions to Petri nets, are often attempted. For qualitative properties, Petri nets, process algebras and formal specification techniques are increasingly proposed. However, for both purposes, simulation remains the only way to handle large models with complex interactions, because of the restricted classes of models suitable for exact solutions and the state space explosion when generating the underlying Markov chains or transition systems.

E-mail address: [email protected]. 1569-190X/$ - see front matter Ó 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.simpat.2006.08.001

2

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

Discrete event simulation tools are traditionally categorized as being based on one of a small number of views of a model. A number can support or use the process view as defined by Franta [7]. Several have diagram conventions for users to define their models and some support model construction via graphical interfaces based on these. Unfortunately, whereas Petri nets generated from graphical tools can be analysed for both functional and performance behaviour, the use of diagrams for simulation is usually specific to one simulation tool and offers no help in understanding the behaviour of models without actually simulating them. Since discrete event simulation is in effect a (pseudo-)random walk through the state space of the model, it is not possible to guarantee to visit all states without pre-analysis by other means. This article assesses the possibility of a formal understanding of behavioural equivalence for process based discrete event simulation models. These are expressible in terms of diagrams suitable for direct graphical input on PCs or workstations. At the same time, they are amenable to a priori functional analysis and have a well developed semantics. The vehicle for this is a mapping from a graphical language of models (known as Extended Activity Diagrams) both to a discrete event simulation language – an extended form of Birtwistle’s DEMOS) [3] – and to a process algebra – Milner’s Calculus of Communicating Systems (CCS) [15,14]. The rest of this article is structured as follows. An overview of Extended Activity Diagrams is given in Section 2, along with their mapping into DEMOS. Section 3 contains a short description of the Calculus of Communicating Systems (CCS) and its temporal extension TCCS [16]. Section 4 presents a definition of the mechanisms of extended activity diagrams in terms of the DEMOS language and of CCS. Some problems with such definitions are identified and remedies discussed. Section 5 presents a tool which supports the ideas in this article. Section 6 contains a number of examples which demonstrate the use of CCS to establish equivalences and differences in these models. Not all questions are found to be easily addressed, but some clear benefits are claimed. Section 7 draws together the strands of the earlier sections and assesses the outcome. Open issues and areas for further research and development are identified. 2. DEMOS and extended activity diagrams Graphical model construction is not new, but it has never been formalised. Nor has a theory of behavioural equivalence for discrete event simulation models been fully developed. Previous work on simulation graphs [30] concluded that establishing behavioural equivalence of event based models was not even feasible. The approach of this article is based on models represented by the process view, which proves to be more successful. 2.1. Process based discrete event simulation The process based view takes as its starting point the idea that the world consists of active and passive components. The term was in common use for several years before the appearance of Franta’s book [7], but he gives the first complete description of the approach, using SIMULA as the implementation language. Active components (processes) are described by their life histories, which often form cycles. They interact with the world, in competition or co-operation, through resources, which are passive. This division into two classes is acknowledged to be arbitrary and Franta gives examples where the same object may be seen as active or passive, according to the perspective of the modeller. The main benefit claimed for the process based approach is that it expresses the model in terms of the structures observable in the real world and so makes modelling more intuitive and interpretation of results easier. It can also have significant implementation benefits. 2.2. Extended activity diagrams The key to the method described in this article is the definition for the first time of a complete, formally understood graphical notation for hierarchical process based models. This is a development of the proposal made in [20]. For a full definition, including a formal grammar, see [22]. This definition of Extended Activity Diagrams has allowed reasoning about the behavioural properties of simulation models, independently of their execution for performance evaluation.

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

3

Graphical description of a process class requires both a way of showing the flow of control through such a process and a way of representing interactions and synchronisations engaged in by instances of it. Construction of a model or sub-model defines the linkages between instances of processes, by mapping their required interactions onto instances of objects which support such interactions. Many synchronisations among processes can be mapped onto queues, which is the only mechanism in queueing network based formalisms such as PAWS [11]. However, the use of higher level abstractions, such as resources in GPSS [25], adds to the ease of description and widens the range of mechanisms which can conveniently be represented. Activity diagrams were used informally by Birtwistle [3] to provide a convenient flow of control description, based on flow charts, and to allow easy description of a wide range of useful synchronisation mechanisms, based on activity cycle diagrams, first described by Tocher [27]. This made them a good starting point for building a complete diagramming convention for process interaction, as described in [22]. A simple example of process based model description is shown in Fig. 1. The model is the reader/writer model from [3, Chapter 4]. The model has two processes, a reader and a writer. These interact through a shared resource, called buffer, since the system represents a simplified database, where records are each held in one of the three buffers. We see simple resource contention, since the Reader must acquire a buffer to read from and the writer must acquire all three buffers before they can update the records, in order to make sure the three records are always consistent. The example includes standard symbols of a rectangular box for a delay, annotated with a description of the associated activity, and a circle for a resource, annotated with a description of the resource and, optionally, the initial amount available. Further symbols are needed to complete even this simple example. Thus, the lower semi-circle, annotated with the process name, marks the start of the process life cycle, and an inverted form of the start symbol, with no annotation, marks the termination of the process. Synchronisation nodes (small circles on lines) are used to show where resources are acquired and released. This allows the exact order of all such synchronisations to be specified. Differing forms of arrowed line might be used to represent the various possible types of a link, but this is fully determined by the types of the nodes which it joins plus, for synchronisation links, the direction of the link. Thus those lines joining delay to delay, start to delay or delay to termination nodes represent control flow in the process, in the same manner as in conventional flow charts. On the other hand, those lines joining resources to synchronisation nodes represent acquisition or release of amounts of those resources. Acquisition and release constitute, respectively, a potential blocking of the flow of

Reader

Writer

1

3

Acquire Read Delay

Acquire Write Delay

Buffers 3 Release 1

Release 3

Fig. 1. Mutually exclusive resource contention – the Reader/Writer model.

4

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

control in the process due to contention with other processes and a potential freeing of another process currently blocked by this process. The amount to be acquired or released is shown as an annotation to the link, while the direction of the arrow on the line determines which action is intended. All external interactions are shown by synchronisation nodes. In this sort of process description, the objects to which synchronisation nodes are linked are there purely to show the type of synchronisation by which any instance of this type will be linked to other process instances. This example uses the process types Reader and Writer, but their definitions are independent of each other, being linked solely through the intervening Buffers resource. In such simple cases the model can be completely described by suitable annotation of the process description, with amounts of resources and inter-arrival times added. A menu of symbols used is given in Fig. 2. The presence in more complex models of loop-start/end nodes removes the need for cycles in these graphs. A decision or loop-start node is associated with the next succeeding branch/loop-end node. Communication through a passive object, such as a resource or a condition queue, is shown by an outgoing arrow to the passive object from a synchronisation node in the output process and an incoming arrow from the passive object to a synchronisation node in the input process. 2.3. DEMOS Many languages and packages claim to be process oriented or to be capable of representing process oriented models. Rather like the term ‘‘object oriented’’, process oriented has become a victim of its own success in appealing to the ease of understanding. There are, in fact, several suitable languages which might support

Start process

Synchronisation point

End process Resource bounded, initially full Conditional branch

Delay

Loop start

Bin unbounded resource, initially empty

Store bounded resource, initially empty

Branch or loop end

Flow of control

Control flow

Synchronisation link

Resource synchronisation

Fig. 2. The symbols used in Extended Activity Diagrams.

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

5

Extended Activity Diagrams, but here we use the DEMOS package [3,4], which is an extension of SIMULA [2,18]. SIMULA supports layers of packages, each refining and extending the earlier ones. In this way, the DEMOS package is provided. This has a time ordered event list and a class ENTITY, which is the building block for active components in models. A model defines a number of ENTITYs, each describing the behaviour of one type of process. In the main program section of each model, instances of these are created, using the new command, and are linked via calls which access instances of RESOURCE. Each RESOURCE instance is also created by a new command. In addition to these basic features, DEMOS has automatic statistics collection and reporting and optional output of event traces. Thus, it allows a wide range of models to be solved to establish their dynamic behaviour, both in terms of quantitative performance (response time, queue lengths, etc.) and event based behaviour traces. 3. CCS and TCCS The calculus of communicating systems forms the core of the formal semantics for process based simulation developed below. It was created to model the behaviour of systems which can be described in terms of communicating agents. 3.1. The basic calculus The basic calculus [15] contains the following primitives for defining agents: Sequential composition Parallel composition Choice

aÆB A|B A+B

Restriction Relabelling The null agent The divergent agent

AnM A[a1/a0, . . .] 0 ?

after action a the agent becomes a B type agent agents A and B proceed in parallel the agent behaves as either A or B, but not both, depending on which is able to act first the set of labels M is hidden from outside agents in this agent label a1 is renamed a0 this agent cannot act (deadlock) this agent can cycle indefinitely and unobservably

P The summation operator is used as a shorthand for a multiple choice among a set or indexed range of agents. Identifiers starting with lower case letters denote the labels of complementary action pairs, where the use of a label with an overbar, c, or without one, c, distinguishes two sides (output and input) of an action, both of which must be possible before it can proceed. Identifiers which begin with an upper case letter define agents. Agents are constructed from the forms given above. Symbolic names for agents are defined using the binding symbol, ¼ def. In the examples in this article, we use sequential composition to show control flow and we use complementary actions to show synchronisation and choices where an ENTITY or RESOURCE can make more than one next step. The components of a model are defined as agents and these are combined in parallel to show how they make up a model. 3.2. Observation equivalence In developing simulation graphs [30], Schruben and Yu¨cesan showed that the sequence of states through which a simulation can pass as it executes forms a graph, where the nodes are states and the edges are labelled with events. Using this as a canonical representation, they showed that two simulation models are equivalent where their underlying simulation graphs are isomorphic.

6

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

CCS uses instead a notion of observation equivalence, which depends on the assumption that two agents are equivalent if any differences in their behaviours cannot be distinguished by an observer. Where two agents containing the two sides of a complementary action are combined in parallel, the resulting agent may hide that action and regard it as internal. CCS calls such internal actions ss. Under many circumstances, but not all, such internal actions have no effect on the observable behaviour of agents and so may be ignored. Where they make no difference we have two different, but observationally equivalent, models. In a simulation graph, all actions are significant and no hiding is allowed, which limits the notion of equivalence significantly. Milner [15] was able to demonstrate that it was not necessary for the property of graph isomorphism to hold, for two models to be observationally equivalent. Instead, a more general notion of equivalence, bisimilarity, can be used. With bisimulation as its basis of equivalence, CCS is able to detect equivalence for a wider class of models than the use of isomorphism would permit. CCS is also inherently compositional, allowing bisimulation results proved for sub-models to be preserved when these are combined, so reducing the effort of proving properties of larger models constructed hierarchically. For instance, if sub-model A is observationally equivalent (bisimilar) to sub-model B and sub-model C is observationally equivalent (bisimilar) to sub-model D, the parallel composition of A with C (A|C) is observationally equivalent to the parallel composition of B with D (B|D). 3.3. Temporal CCS Temporal CCS [16] is an extension to CCS, which allows both explicit delays and wait-for synchronisation (asynchronous waiting), in a manner superficially similar to DEMOS. It adds the primitives: Fixed time delay

(t)

Wait for synchronisation

d

Non-temporal deadlock

0

where the agent requires t time units to elapse before it can perform its next action where the agent may idle indefinitely until its next action is possible where the agent may idle indefinitely and never engages in further actions

We use time delays in an obvious way, to represent the delays in our models. The d is used where an agent may have to wait passively for an active agent to provide the matching half of a complementary action. This is most important when modelling RESOURCEs, which have to wait indefinitely for ENTITYs to make acquire or release requests. 3.4. Concurrency workbench The concurrency workbench (CWB) [6,17] is a tool that automates the checking of assertions about CCS models in order to establish properties of the systems they describe. It supports the basic calculus (CCS), the temporal extension to this (TCCS) and a synchronous variant of the basic calculus (SCCS) [14]. The CWB supports both certain built in queries, such as checking for deadlocks, and testing of expressions in the modal l-calculus [26]. In the approach developed in this article, the CWB is used for the behavioural analysis of CCS models generated automatically from Extended Activity Diagrams, while DEMOS is used to solve them for their performance measures.

4. Extended activity diagrams in DEMOS and CCS Before we continue, it is perhaps worth summarising the way the three notations, EADs, DEMOS simulation models and CCS process algebra models, are used.

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

7

Summary of equivalent features in EADs, DEMOS and CCS EAD

DEMOS

CCS

Processes Process Synchronisations

Entity new ENTITY Resource.Acquire and Resource.Release

Activities

Hold statements

Control flow links

Sequences of actions within an ENTITY LOOP:/Repeat if statement The keyword end for an ENTITY

agent definition ¼ def Parallel composition of agents Complementary actions, shared by active and passive agents composed in parallel Disregarded (un-timed models) or delays (timed versions) Prefixing of an agent with an action or a time delay Recursive agent Choice The non-temporal deadlock agent 0

Loop start/end Decision Process termination

Fig. 3 shows the DEMOS and CCS for parts of the EAD from Fig. 1. The DEMOS model contains the definition of a type of ENTITY called Reader. In the CCS, an agent called Reader is defined to be a sequence of actions ending with the deadlock agent, 0, indicating that it does not repeat indefinitely. The behaviour of the DEMOS model is shown by a sequence of three actions, enclosed in bracketting begin and end keywords. The actions in turn send an Acquire request for one unit of resource Buffers, a time delay of three units and the release of the Buffers resource. The CCS model has matching output actions interacting with the resource and a time delay of three units. Loops are represented by recursive agent definitions. Fig. 4 shows a simple example of this.

Fig. 3. A DEMOS sequential Entity and a corresponding TCCS agent.

Fig. 4. A DEMOS repeating Entity and a corresponding TCCS agent.

8

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

Fig. 5. Demos Res object used by Entities and corresponding TCCS.

One obvious correspondence that holds in all the following mechanisms is that synchronisations which can block are formed by a communication, preceded by the indefinite wait (d) in TCCS. Fig. 5 shows this in terms of elements of the reader writer example given above and used in the case study in Section 6.1.1 of this article. Note that in the temporal calculus, it is necessary to decide whether an action is allowed to block indefinitely or to have the effect of killing the process if it cannot be satisfied immediately. All acquire requests made by a process may lead to that process being blocked, awaiting freeing of a resource held by another process, and so such actions are prefixed with the indefinite waiting action d. On the other hand, release requests should only be permitted in cases where there has already been a matching acquire, leaving the matching resource always ready to accept it. Therefore, releases are not prefixed with d. Resources must be able to wait indefinitely in all states (i.e. no model should be blocked because nobody wants to use a particular resource) and so all their actions are prefixed with d. Thus Fig. 6 defines

Fig. 6. General definition of a DEMOS Res in TCCS.

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

9

a general model of a resource in TCCS. In the basic calculus, where all actions are instantaneous, no ds are needed. 5. A tool for model generation In this section, a tool called Demographer is introduced, which allows both DEMOS discrete event simulation models and CCS process algebra models to be generated from a common EAD graphical description. The former can be solved by the DEMOS discrete event solver, while the latter can be analysed by the Concurrency Workbench. 5.1. Related tools Several tools have appeared which combine simulation and exact quantitative solvers using a common input format [29,1]. A series of tools, beginning with the SIMMER Process Interaction Tool [19], have shown the potential for generating DEMOS models from graphical input. In independent work, the translation of a subset of unmodified DEMOS syntax into Concurrency Workbench (CWB) [6] code for either CCS or Synchronous CCS (SCCS) [15], a fully synchronous version of CCS, was implemented by Tofts [28], permitting the conversion of DEMOS programs into process algebra and the use of the Concurrency Workbench to prove properties of the systems. GreatSPN [5] and DSPNExpress [12], graphically based stochastic Petri net tools, allow both simulation and structural analysis of their underlying place transition net models. 5.2. Demographer Demographer is a simple graphical editor for creating both modified DEMOS discrete event simulation models and CCS models directly from extended activity diagrams as described above. The current version runs under MS/DOS and is written entirely in SIMULA. An earlier version, written jointly with Emma Osman and using a less complete definition of extended activity diagrams, exists for X Windows under UNIX [21]. Compilation and execution of modified DEMOS models is currently done separately, but it is intended that they should be integrated into the graphical front end. CCS is generated in the syntax of the Concurrency Workbench for most constructs of Extended Activity Diagrams. Both the basic calculus and its temporal extension can be generated. The Concurrency Workbench remains a separate tool, but it is trivial to load the output of Demographer into it. By integrating the two types of modelling in a pair of compatible tools, the benefits of both approaches are more easily obtained. At the same time, the process of modelling is simplified and consistency between the two solvable forms of the model is ensured. 5.3. The basic tool Demographer allows the user to draw enhanced activity diagrams, by selecting symbols from a menu and placing them on a canvas, which is divided into a grid of squares. Each symbol occupies one square in the grid. Symbols are connected by drawing linking symbols in the squares between them. The types of the symbols joined and the direction of the links determine their meaning, in line with the formal grammar for extended activity diagrams developed in [22]. Many symbols require additional information to be supplied in order to complete the description of the model. For instance, the Hold symbol requires a description of the duration of the delay it represents. Additionally many symbols can usefully be annotated by a short comment or description. This is possible by selecting a symbol and invoking an open form operation. This will cause an input form menu appropriate to that symbol to be displayed. The user may then enter the required information by typing into this form. When a model’s description is believed to be correct and complete, the user may request that a DEMOS program or a text file suitable for input to the Concurrency Workbench be generated from it.

10

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

6. Does a change to a model change its behaviour? In order to make execution of simulation models tractable, it is often desirable to simplify areas of detail. This leads to questions such as ‘‘Can the detailed modelling of this sub-model be replaced by a stochastically determined hold?’’ and ‘‘Does it change the behaviour of the model if I replace a sub-model with a formula?’’ There are different approaches to dealing with each of these two questions. To deal with the first, one needs to formulate rules for simplifications which are guaranteed to leave behaviour unaltered. Since models are expected, at least in part, to be generated by composing predefined instances of components, it would be surprising if this did not cause redundant states to be included. The approach to the second is to make some simplification and to have a means of testing whether important properties are unaltered. In this section, the two approaches to simplification described above are considered in turn. First the possibility of identifying, from the CCS model, simplifications which leave the simulation models behaviour unaltered is considered. Then ways of identifying equivalence of models simplified by intuition are considered. 6.1. Identification of redundancy in models Some conditions for eliminating actions and states are identifiable in terms of the CCS representation of a model. In some cases these may in themselves identify useful information about the system being modelled.

Boat

Acquire 1

Acquire 2

Dock Release 2

Unload Jetties

Tugs

Acquire 1 Leave

Release 1

Fig. 7. A simple harbour model.

Releaase 1

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

11

6.1.1. Elimination of transitions To show how elimination of potential transitions is possible, irrespective of timings, the example in Fig. 8 uses the basic Calculus, generated automatically by Demographer, to model a harbour, shown as an Extended Activity Diagram in Fig. 7. This is a version of a classic model used in many simulation texts over the years. Boats arrive at a harbour and wish to dock, unload and leave. To dock and to leave a boat needs to acquire two and one tugs, respectively, After docking a boat releases its tugs and then tries to acquire a tug once unloading is complete. In this version we create only three, terminating boats and reduce the initial number of tugs to two. This simplifies analysis by hand without invalidating the approach for larger models, where the Concurrency Workbench will be used. It has also been used to investigate deadlock [22]. Restricting MODEL by the sort, LðMODELÞ, of its unrestricted self, i.e. hiding all the actions that are currently visible within MODEL, allows its components to be simplified, since they can no longer engage in any outside communications, only in ss. By applying the CCS Expansion Law [15], any choices in agents within MODEL which begin with a label in M, where M is the set of all labels not matched by a complementary action within the same scope, i.e. which are not partners in ss, may be eliminated. In other words, if the model is prevented from engaging in any outside activity, any branches guarded by actions which cannot be satisfied internally can be pruned without changing the overall behaviour of the model. This significantly reduces the complexity of the Jetties resource, as shown in Fig. 9, allowing edges in the resulting transition graph to be removed. In the current example, it does not lead to a simpler simulation model, but in some models it would have an even greater effect, eliminating states in the transition graph not just transitions. State elimination is examined in Section 6.1.2. In fact such simplifications are possible at any point where restriction is applied. This means that each submodel definition is a potential point for elimination of transitions. Taking the reader/writer model from Section 2.2, as it would appear if the two processes were first modelled separately and then combined, the resulting CCS model is as given in Fig. 10. As in the harbour model, not all of the possible actions in the resource are matched by complementary ones in Reader or Writer. They cannot be removed until they are restricted, but can then form a simplification. The Buffers resource no longer needs those actions using buffSAcq2 or buffSRel2 and these are eliminated in Fig. 11. 6.1.2. Eliminating complete states One major claim for Petri net models as a formalism for simulations has been their ability to identify redundant states, in the context of a particular initial marking, and so allow simplification of the model at run time. Yu¨cesan and Schruben also show how to eliminate states in their event based simulation formalism. In very

Fig. 8. CCS of a simple harbour model.

Fig. 9. Simplified CCS of Jetties resource from Harbour model.

12

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

Fig. 10. Hierarchically constructed Reader/Writer model in CCS.

Fig. 11. Reduced form of Buffers resource.

Polisher

Mill

Acquire 4

Acquire 2

Grind

Release 2 Dolliess Take 1

Release 2 Put 1

Release 2 HalfDone

Fig. 12. A simple milling process.

Polish

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

13

simple models, such as the previous two examples, CCS can help to reduce the number of paths between states in a model. This in turn can simplify the analysis of the behaviour of the model. The question remains as to whether it is ever possible in the CCS model to eliminate states completely. In terms of a state transition diagram, elimination of a potential state in a sub-model is possible if there are no edges entering it in the final model where it is used. In CCS terms, this means that no agent corresponding to a certain state in the sub-model is ever activated as the result of an action in the overall model agent. In the Reader/Writer example, this could mean that, for instance, the agent SharedBuff2 could be shown never to follow any of the actions possible in Model. By re-formulating that model with both readers and writers working in units of two buffers, such a condition is easily created. Following the reasoning above, a simple example of a model where certain levels of resource are unreachable can now be demonstrated. This simple case may seem trivial, but in more complex models, such possibilities may be far from obvious. Consider a simple factory model, whose extended activity diagram is shown in Fig. 12, where there are two machines, a Mill and a Polisher. The Mill shapes pieces and then passes them to the Polisher. Since the pieces are long, the Mill cannot begin work on a new piece until the Polisher has half finished its current piece. Pieces are transferred on Dollies. The Mill loads its ingots from two Dollies, while four are needed by the Polisher to move milled pieces for polishing. At the halfway, point the Polisher can release two Dollies. Intuitively it seems that the number of Dollies can never reach an even number. This can be verified easily in this simple example, starting from the straightforward CCS version in Fig. 13. This fact, together with the earlier rule, reduces the resource Dollies5 as shown in Fig. 14. This is clearly simpler to reason about, although its usefulness in simplifying a simulation may be small unless it is being very carefully coded. Since it is hoped that resources will be built-in primitives in any simulation package, it would be necessary to have ways of recognising useful simplifications. One such case would be where the upper limit of the amount of resource in use was unreachable. This is clearly true in the example, as no state with the resource, Dollies0, is ever reached. Thus the resource can be further modified as shown in Fig. 15.

Fig. 13. A simple model for unused resource states.

Fig. 14. Dollies resource with redundant states eliminated.

Fig. 15. Dollies resource normalised to zero lower bound.

14

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

The failure of the original resource to reach zero implies that there is more resource available than the model can make use of. This can be used to establish a tuning of the system being modelled and can also allow the simulation to normalise the amount of resource at a lower level. For full generality, it should be noted that There is a surplus n of resource Res when for all i in the range 0, . . . , n  1, Resi is unreachable. In the case given, a further simplification can be made, since those resource states involving odd numbers of dollies are unreachable. This permits the use of a resource with a unit representing two dollies, which can be reflected in the DEMOS model as well as reducing complexity in reasoning about the model. An alternative use of the same kind of analysis is found where the amount of a Bin or a Store can be shown never to exceed a certain limit. This is useful in providing a bound for the Bin (making it into a Store) or reducing the bound on a Store. 6.1.3. Unreachable states in processes The examples so far have shown simplification of passive objects, such as resources. It is also interesting to investigate state elimination in processes. The simplest case is again the elimination of alternatives in choices which are prefixed by unmatched actions. This is quite likely to happen in reusing components within models. A more complex situation occurs where the actions appear to be matched, but the unwinding of earlier actions absorbs their complement. Put simply, an action and its complement must appear together in at least one reachable state for an agent prefixed by that action to be executed. The example in Fig. 16 shows this in terms of an office services bureau and a messenger service, where the messenger service only accepts one delivery per day.

Input

Bureau Messenger Copy job

Print job

P.Avail

C.Avail Typing job

Printing

B.Avail

Print

T.Avail Type Copy job

L.Avail Booklets

Typing

Tomorrow

Copy Letters Copying

Copies Fig. 16. Bureau and Messenger Model.

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

15

The office services bureau is shown as a process which can perform three different tasks, depending on what is required. Tasks are requested shown by modelling an input process which places jobs in a different Bin for each task type. These jobs are removed by the Bureau process, processed and placed in an appropriate outgoing Bin. The Messenger process collects from whichever Bin it finds contains a finished piece of work, delivers this and returns to collect the next piece the following day. In the CCS model some of this detail, notably the input process, is removed in order to focus on the key elements. These effects translate back into the full model in a straightforward way. In the agent Model, the Bureau cannot evolve into C3, but can evolve into C1 or C2, because the Messenger service will not accept printing from it (see Fig. 17). It is important to note that this occurs as far as CCS is concerned because of the restriction of the label printing, which prevents any outside agent combining further to provide the complement to printing, which represents the absence of an alternative transport service. This is a simple case. Now consider the agent in Fig. 18. In Problem, Emergency cannot become C3 or C1. To test for such cases some temporal or process logic, such as the modal l-calculus, at first seems likely to be useful. It can provide the answer to the question, ‘‘In all successor states is there any where further progress is impossible?’’ and thus one possibility of eliminating redundant paths is established. This is the same as checking for deadlock freedom. It asks whether a dead-end can be reached, but not how many dead ends there are nor which states they are. If such a dead-end does exist and can be located, it may reveal unnecessary dead states which were included on the assumption that deadlock could not happen. It does reveal that the model is not well behaved in reaching a steady state, since a dead-end is an absorbing state, killing the model. In general, this is a sign of an error in the model’s formulation. It is demonstrated in [22] that the Concurrency Workbench provides a way of testing for deadlock which allows all states to be fully identified. Unfortunately this does not provide an answer to the original question. In fact there is no obvious way of exploiting a transition or reachability graph view, which starts from an initial state and generates successor states, to find unreachable states in some general graph of states. The real question is to establish whether any sub-states in the component processes do not lie on the paths reachable from the start state of the combined model. At first sight this seems impossible to answer for the general case. Special conditions were identified above which may be used when dealing with resources and buffers to establish whether they can be simplified. A similar method, removing agents from the definition of components and establishing that combined behaviour is unchanged, can be applied more generally, but is rather a brute force approach without some insight into likely cases. If such insight is available, the approach of [22] is applicable. Returning to built-in Concurrency Workbench functions, the min command binds to an identifier the smallest model which is observationally equivalent to a given model. This is an interesting possibility for simplifications, but may lead to re-formulations which no longer have recognisable DEMOS equivalents. Also,

Fig. 17. Processes with redundant states in CCS.

Fig. 18. Pre-emptive action removing successor states.

16

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

the reduced model is defined by the Workbench in terms of meaningless names and there seems no easy way of relating these back to the original. The Workbench also allows the complete set of reachable agents (states) to be generated for an agent (model). This offers another approach. The existence of unreachable agents results from the restriction of certain labels when the model is composed. Otherwise the workbench assumes that externally generated actions are always possible. By generating the reachable states both with and without such restriction, comparisons may be made to establish which states are redundant. This is shown to be successful in the testing of these examples in [22], but is again very time consuming unless intuition is available to guide the process. 6.2. Comparing models simplified by hand The danger with such sophisticated approaches to understanding behaviour is that they will not be attempted by those who see themselves primarily as simulation modellers and not as concurrency experts or formal modellers. In most cases, simplification is carried out in an informal manner and modellers are unable to establish whether such modifications are dangerous, except by running the resulting simulation models and examining their traces. It is therefore worth considering how far it is possible for a simulation modeller to ask whether an informally justified simplification, performed in order to speed up execution of a model, preserves its original behaviour. A suitable small example seems the best way to examine this.

Trans

Stream

1 Schedule 1

Input 4

Initialise

Write

Memory 1 Link

1 Build

4 2

1

Buffers Transmit 2

1

Fig. 19. Activity diagram of network model – before simplification by hand.

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

17

Consider a simple communications system, shown in Fig. 19, where a terminal inputs data to create a Stream of frames and sends these to a Transmitter, where packets are built out of frames before being passed to an output stage which sends them down a channel. This example contains two processes which might reasonably be modelled separately. For the purposes of simplification, they will be considered one at a time. Since the only communication between them is through a schedule call from the Stream process to the Trans process, this is reasonable. The first simplification replaces the internal logic of the Stream process with a simple hold. This is justified intuitively by noting that it was originally made up of two sequential holds, with one bracketed by an acquire/ release of a resource. As long as this resource is not already in use, this should have no effect (see Fig. 20). The second simplification applies the same sort of thinking to the Stream process. Since this releases the Link resource only to re-acquire it immediately after the Build phase of its operation, it might be safe to assume that it merely keeps the Link throughout (see Fig. 21). To decide if any of these simplifications is valid, from a behavioural point of view, the corresponding CCS models were generated and tested with the Concurrency Workbench. In writing these models, the question of which resources were to be considered local and which global had to be answered and the decision was taken that the Memory resource would be considered as local to the Stream process, while the Link and Buffers resources would be global. This is reflected in the fact that memAcq4 and memRel4 are restricted when the agent Input is defined, to represent a single Stream process and its Memory, in Fig. 22, while linkAcq1, linkRel1, buffAcq2 and buffRel2 are only restricted when two Trans processes are combined in Modelb.

Trans

Stream

1 Schedule 1

Input

Initialise 1 Link

and Write

1 Build

2

1

Buffers Transmit 2

1

Fig. 20. Activity diagram of network model – after first simplification by hand.

18

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

Stream

Trans

1 Schedule 1

Input and Write

Initialise

1 Link

2 1

Build Buffers

and Transmit 2

1

Fig. 21. Activity diagram of network model – after alternative simplification by hand.

Fig. 22. CCS version of full model in Fig. 19.

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

19

Fig. 23. CCS of first simplification.

Fig. 24. CCS of alternative simplification by hand.

The effect of this simplification is predicted by testing with the Concurrency Workbench to leave the externally observable behaviour of the overall model unchanged. Since the Memory resource was totally private and only used sequentially, it could never lead to alternatives within the Stream agent. Since it cannot engage in external actions, it can be safely removed. The second modification is less successful. Since the Trans processes compete for the Link and Buffs resources, the removal of the releasing of the Link means that there is one less point where the other Trans process could acquire it. Where it does acquire it the contention leads to potential deadlock, which is lost in the simplified version. This is clearly a dangerous simplification. Testing with the Concurrency Workbench makes this quite apparent (Figs. 23 and 24). 7. Conclusions The problem of establishing the behaviour of a system is very real for many simulation modellers. Answers to such questions can sometimes be found by expressing the system in a process algebra like CCS and using a tool such as the Concurrency Workbench to pose queries. This article has used simple examples to demonstrate that expressing process based simulations in both a discrete event simulation language (DEMOS) and a process algebra (CCS) can be achieved from a common graphical representation. Further, the resulting models can be used together to find both behavioural and performance properties. This approach is still at an early stage of development. In particular, the power of posing queries in the Concurrency Workbench is bought at the expense of an awkward notation and some difficulties in asking general questions easily. Now that the usefulness of combining these techniques has been shown, work remains in integrating the querying with the model description interface, to ease the learning curve for modellers. Another direction for extension of this work is in applying it to direct derivation of models from widely used formalisms for system specification. For instance, the CCITT approved protocol specification language LOTOS is based on process algebra features like those in CCS. With a well developed semantics for the simulation language, it may prove easier to find such mappings and to exploit them for both quantitative and qualitative results. Over the past few years, researchers have also looked at the derivation of both simulation and behavioural models from the widely used Unified Modelling Language (UML) system design language [23,24,10]. Considerable work has also been done on introducing stochastic concepts into process algebras [9,13]. To date little use has been made of this in understanding the behaviour of simulation models, but it is a logical next step. One process algebra aimed specifically at the representation of discrete event simulation behaviour is Spades [8]. Finally, the question of how to make use of an automatically simplified CCS model as a simulation model remains an open question. Work has recently begun on ‘‘round trip simulation’’, where EAD models can be converted (‘‘forward engineered’’) into stochastic process algebra models, the process algebra models

20

R. Pooley / Simulation Modelling Practice and Theory 15 (2007) 1–20

simplified and then converted back (‘‘reverse engineered’’) into EAD models. This will provide the basis for fully integrated modelling. References [1] H. Beilner, F.J. Stewing, Concepts and techniques of the performance modelling tool HIT, in: Proceedings of the European Simulation Multiconference, Vienna, SCS Europe, 1987. [2] G.M. Birtwistle, O.J. Dahl, B. Myhrhaug, K. Nygaard, Simula Begin, Chartwell-Bratt, 1972. [3] G.M. Birtwistle, Discrete Event Modelling on SIMULA, MacMillan, 1979. [4] G.M. Birtwistle, C. Tofts, R. Pooley, Characterising the structure of simulation models in CCS, Transactions of the SCS 10 (3) (1993) 205–237. [5] G. Chiola, A graphical petri net tool for performance analysis, in: D. Potier (Ed.), Proceedings of the International Workshop on Modelling Techniques and Performance Evaluation, AFCET, Paris, 1987, pp. 297–307. [6] R. Cleaveland, J. Parrow, B. Steffen, The concurrency workbench: a semantics based tool for the verification of concurrent systems, ACM TOPLAS 15 (1) (1993). [7] W. Franta, The Process View of Simulation, North-Holland, 1978. [8] Peter G. Harrison, B. Strulo, SPADES – a process algebra for discrete event simulation, Journal of Logic and Computation 10 (1) (2000) 3–42. [9] J. Hillston, A Compositional Approach to Performance Modelling, Cambridge University Press, 1996. [10] C. Hrischuk, J. Rolia, C.M. Woodside, Automatic generation of a software performance model using an object oriented prototype, in: Proceedings MASCOTS ’95, 1995, pp. 399–409. [11] Information Systems Research Associates PAWS Users Guide, 1986. [12] C. Lindemann, DSPNExpress: a software package for the efficient solution of deterministic and stochastic petri nets, in: R. Pooley, J. Hillston (Eds.), Computer Performance Evaluation – Modelling Techniques and Tools, 6th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation, Edinburgh, September 1992, Edits 10, Edinburgh University Press, pp. 9–20. [13] V. Mertsiotakis, M. Silva, Throughput approximation of decision free processes using decomposition, in: Proceedings of the 7th International Workshop on Petri Nets and Performance Models, (St. Malo), IEEE CS-Press, 1997. [14] R. Milner, Calculi for synchrony and asynchrony, Theoretical Computer Science 25 (3) (1983). [15] R. Milner, Communication and Concurrency, Prentice-Hall, 1989. [16] F. Moller, C. Tofts, A Temporal Calculus of Communicating Systems, Edinburgh University, Department of Computer Science, Report ECS-LFCS-89-104, 1989. [17] F. Moller, The Edinburgh Concurrency Workbench (Version 6.1), Edinburgh University, Department of Computer Science, LFCS Technical Note, TN34, October 1992. [18] R.J. Pooley, An introduction to programming in SIMULA, Blackwells, 1987. . [19] R.J. Pooley, M.W. Brown, Automated modelling with the general attributed (directed) graph editing tool – GA(D)GET, in: Proceedings of the European Simulation Multiconference, Nice, June 1988, pp. 410–415. [20] R.J. Pooley, Towards a standard for hierarchical process oriented discrete event simulation diagrams, Transactions of the Society for Computer Simulation 8 (1) (1991) 1–42. [21] R.J. Pooley, Demographer: a graphical tool for combined simulation and functional modelling, in: R. Pooley, R. Zobel (Eds.), UKSS ’93: Proceedings of the First Conference of the UK Simulation Society, September 1993, pp. 91–95. [22] R.J. Pooley, Formalising the Description of Process Based Simulation Models, Ph.D. Thesis, Edinburgh University, 1995. [23] R.J. Pooley, C. Kabajunga, Simulation of UML sequence diagrams, in: R. Pooley, N. Thomas (Eds.), UK PEW ’98 – Proceedings of 14th UK Performance Engineering Workshop, Edinburgh, July 1998, ISBN 0 9524027 4 2. [24] R. Pooley, P. King, The unified modeling language and performance engineering, IEE Proceedings – Software 146 (1) (1999) 2–10. [25] T.J. Schriber, Simulation Using GPSS, Wiley, New York, 1974. [26] C. Stirling, Modal and Temporal Logics for Processes, Technical Report ECS-LFCS-92-221, Laboratory for the Foundations of Computer Science, Department of Computer Science, University of Edinburgh, 1992. [27] K.D. Tocher, the Art of Computer Simulation, The English Universities press, London, 1963. [28] C. Tofts, Process Semantics for Simulation, Technical Report, Department of Mathematics and Computer Science, University of Swansea, 1993. [29] M. Veran, D. Potier, QNAP 2: a portable environment for queueing system modelling, in: D. Potier (Ed.), Proceedings of Modelling Techniques and Tools for Computer Performance Evaluation, North Holland, 1985, pp. 25–63. [30] E. Yu¨cesan, L. Schruben, Structural and behavioural equivalence of simulation models, ACM TOMACS 2 (1) (1992) 82–103.