Simulation of Operations

The Discrete Event Approach to Computer Modelling

Conceptual Model

• The first step in modelling.– Avoid the temptation of modelling directly in a

simulation tool.– Identify the minimum set of entities– Determine an appropriate level of detail– map the relationships between them

All models are simplifications• Models are abstractions: they

don’t represent all the associations and attributes of the real.

• A conceptual Model identifies which associations are to be retained.

• If important associations or attributes are left out then the resulting computer model is likely to be flawed or invalid.

ACDs are conceptual models

DUMMY

DUMMY

WORLD CALL BUFFERInitiate Internal

Initiate External

BASE STATION

AVAILABLEFREQ’S

CALL

CALL

CALL

Internal call

External call

FREQUENCIES (6)

Coding a Simulation

• Define the entities’ names and attributes• Specify their interactions using Boolean and

conditional logic– IF x AND y OR x AND z THEN ….

• Specify a visual representation• Specify the input data• Specify the output statistics• Test and debug

The result of this is an executable program; a simulation.

Components of a Simulation • System State• Simulation Clock• Event List• Statistical Counters• Initialisation routine• Time advance mechanism• System description routines• Report generator• Random sampling functions• Graphics sub-model and display handling

Basic Structure

Main program

SystemDescription

Utilities

Simulation program structure

World Views

• Different conceptual models of how to describe a problem for simulation– Event Based– Activity Based– Process Interaction

• Each has a corresponding Executive

Event Based View

• Each system description routine corresponds to either:– An event at the start of an activity, or– An event at the end of an activity

• Events at the end of an activity can be scheduled (are only dependent on the passage of time)

• Start of activity events require testing of state to ‘see’ if they can take place.

Event Routines

t

S

Consequential

Scheduled

Scheduled

YoYo Moulder Routines

• Start Cycle – CONSEQUENTIAL• Conditions

– The machine is empty– There is moulding compound available– There is space in the output buffer to receive

output when the cycle completes• Assumption: Moulding compound is always

available

The next slide is a bit complex….

It illustrates the high level control structure used in See-Why (an event-based simulation tool-kit)

Please bear with me …

LEVEL 1

DATASCHEDL(event,duration,entity)

THE EVENT LISTSets, Entities & Variables

ONWARD(event, pointer)CLOCK

LEVEL 2 LEVEL 3

Utility Routines

DEFINE

DEFENT, DEFSET

DSFORM

DSPCHG, CHDESC,

INITIAL

HTEXT, PLTLNE, CLAREA

Event Routines

EPCTTR IHEDOF,

SPCTTR BEHEAD, ADDLAST

EMOULD NORMAL

SMOULD NEGEXP

EASSMB

SASSMB etc. (hundreds)

Executive Program

OWNCY

User Defined Routines

REPEAT

Start of Mould Cycle

C ***********************************************************SUBROUTINE SMOULD

C ***********************************************************C Check that the moulder is empty and the output buffer is ‘free’.

IF (ISIZEOF(IMOBUF) .EQ. 0 AND ISIZEOF(IMOULD) .EQ. 0)C If so, move an entity into the machine

JENT=IHEDOF(IWORLD)BEHEAD(IWORLD)CHDESC(JENT)=”SIDES”ADDLAST(JENT,IMOULD)

C and schedule the end eventSCHEDL(JMOULD,2,1.1)

ENDIFEND

C END SMOULD***********************************************

See-Why is a Fortran based Simulation Toolkit

End of Mould Cycle

C ************************************************C SCHEDULED EVENT FOR END OF MOULDING

SUBROUTINE EMOULDC ************************************************

JENT=IHEDOF(IMOULD)BEHEAD(IMOULD)ADDLAST(JENT,IMOBUF)END

C END SMOULD***********************************************

Executive

• Identify time of next event• Advance clock• Execute scheduled event routines ‘due’• Execute consequential events that follow from

these (these are specified in the main program)

No Scanning (searching), fast, harder to program

Main ProgramC Call the timing routine ONWARD and get the number of the next eventTOP

CALL ONWARD(EventNumber)C Jump to the piece of code associated with the event number (in this case 2-> LINE 20)

ON EventNumber GOTO 10, 20, 3010 EASSY

SASSYSMOULDSPCUT

C First execute the scheduled event and then try each consequential event.20 EMOULD

SASSYSMOULDGOTO 999

30 …

GOTO TOP

Activity View• Each routine describes an activity (including events at

start and end)• Each entity has a data structure that includes a time-

cell (when the next event for that entity takes place)• Each routine comprises

– Test head– Actions

• Test-Head: check availability of entities required for activity

• Actions: – identify time of end event; – change state of entities to committed (i.e. not available);– Update t-cell for each entity

Pseudo CodeSubroutine MoulderIF pAvailable(Moulder) AND pAvailable(Output_Space)THEN

end_ev=1.1Moulder.t_cell=Clock.now+end_evOutput_Space.t_cell=Clock.now+end_evNew sideside.t_cell=Clock.now+end_ev

ENDIF

Activity Based 2-phase executive• (1)Scan entity t-cells to find earliest time of next

event• Advance clock• Change entity state(s) to ‘available’• (2) Scan activity routines (test-heads) to see which

(if any) can be executed• Execute routine, repeat scan

Repeated scanning, slow, easier to program; activity routine ordering will affect behaviour.

3-phase approach is a development of this

Process Interaction• each process routine describes

the logic for the life cycle of a class

• Typically used to describe temporary entities

• Permanent entities are simple integers describing the number of entities of that type that are available

• (historically) this meant that they were poor at describing the logic of equipment and handling devices (now not an issue)

SIMAN Code

BEGIN;CREATE,1: EXPONENTIAL(9);QUEUE: BUFFER,10;SEIZE,Pr: Drill;DELAY: TRIANGULAR(3.2,4.2,5.2);RELEASE: Drill;COUNT: JobsDone: DISPOSE;

END;

Event Based Approach I

• Model is described as a set of events.• Scheduled events

– are only dependent on time• Consequential events

– are dependent on state, and usually need to be tested.

• examples:– SEE-WHY, SIMSCRIPT II.5

Event-Based Approach II

• efficient– the ‘fastest’ of all approaches (at run-time).

• little or no structure imposed on user.• maximum flexibility.• model development takes longest time.

Activity-Based Approach (2 phase)

• Model is described as a set of activities.• Each activity describes the conditions under which

it can be activated and the change of state that ocurrs when this happens.

TEST HEAD

ACTIONS

if x and y then:

change stateupdate t-cells

NOW SUPPLANTED BY 3 PHASE APPROACH

1. Time scan.2. Activity scan.

Activity-Based Approach

• slower than event-based approach• need for scanning of each activity’s test-

head.• Ordering of activities in the program is

important.• exhibits a degree of modularity.

Activity-Based Approach (3 phase)

• Identifies ‘bound’ and ‘conditional’ activities.• bound activities can be scheduled.• only conditional activities need to be scanned.• allows the behaviour of both permanent and

temporary entities to be represented*

* in other approaches either one or the other is the focus for modelling.

Activity-Based Approach (3 phase)

• Examples: ECSL, HOCUS• HOCUS

– Hand or Computer Universal Simulator– Based on a formal ACD-based description.

Process-Based Approach(aka ‘Process Interaction’)

• Temporary entities are the typical focus of modelling.

• describes a sequence of activities that an entity passes through durings its life.

• processes interact with one another by competing for resources – aquiring them and releasing them later.

Process-Based Approach• modularity based on parts - unlike activity-based

approaches that are based (mostly) on machines.• Unlike other approaches, time passes during the

execution of a process.• two lists used:

– pending ( future known events) scheduled.– current (due now & conditional) scanned.

• simple interaction mechanism is okay for simple interactions! But...

Examples: GPSS, SIMAN/Arena, ModSim,

Activity vs. Process• In their pure form:

– Activity-based approaches offer a convenient and modular solution to modelling systems that are defined by their physical layout. Changes to layout are straightforward.

– Process-based approaches suit systems where there is high part and route variety. The modularity is focussed on the parts ( & therefore routing) so adding and deleting these is relatively easy.

• BUT, these days most packages are hybrids, offering capabilities for both physical layout based problems and complex routing scenarios.