First Planimate Model - the Perils of Average Thinking: Difference between revisions

From Planimate Knowledge Base
Jump to navigation Jump to search
(Created page with "== Explanation == This model will introduce you to basic elements of the Planimate® platform and also provide some initial experience with some important general concepts conce...")
 
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Explanation ==
== Explanation ==


This model will introduce you to basic elements of the Planimate® platform and also provide some initial experience with some important general concepts concerning the dynamic behaviour of systems.
This model will introduce you to basic elements of the Planimate® platform and also provide some initial experience with some important general concepts concerning the dynamic behaviour of systems.  


<br> We are going to take a look at a simple system and its dynamics.


We are going to take a look at a simple system and its dynamics.
The major dynamic events of this system will be as follows:


The major dynamic events of this system will be as follows:
{|
{|
|Arrivals
|-
| Arrivals  
| = Entry into System.
| = Entry into System.
|-
|-
|Waiting Around
| Waiting Around  
| = Queuing for Service.
| = Queuing for Service.
|-
|-
|Processing
| Processing  
| = by a Server.
| = by a Server.
|-
|-
|Departure
| Departure  
|= Exit from System.
| = Exit from System.
|}
|}


<br> The thing to appreciate here is:


The thing to appreciate here is:
*We want to make a model of a system to see, learn or show others how it works.  
*We want to make a model of a system to see, learn or show others how it works.
*In this system, events occur and it changes over time.  
*In this system, events occur and it changes over time.
*Hence the model must be '''dynamic.'''
*Hence the model must be '''dynamic.


<br> Imagine we could isolate an area in a real system (e.g. a set of office cubicles), then watch and record what happens in it.


Imagine we could isolate an area in a real system (e.g. a set of office cubicles), then watch and record what happens in it.
A video recording is one possible strategy for recording a system’s activities. To fully cover the system area, you may need many simultaneous recording streams. And what would you record - the people or the paper?


A video recording is one possible strategy for recording a system’s activities. To fully cover the system area, you may need many simultaneous recording streams. And what would you record - the people or the paper?
You would then also need to set up an array of screens for the viewer to watch the playbacks.Too many screens and not enough eyes makes forming a useful understanding of cause and effect in this system very elusive. And even then, there is still a need to be able to communicate this behaviour to others, so that they can understand it, before you can then fruitfully discuss future options for the system.


You would then also need to set up an array of screens for the viewer to watch the playbacks.Too many screens and not enough eyes makes forming a useful understanding of cause and effect in this system very elusive. And even then, there is still a need to be able to communicate this behaviour to others, so that they can understand it, before you can then fruitfully discuss future options for the system.
To be able to give this information to somebody else to review, some kind of language is needed to represent how the events going on in that system relate to each other, things like:


To be able to give this information to somebody else to review, some kind of language is needed to represent how the events going on in that system relate to each other, things like:
*what causes what,  
*what causes what,
*what waits for what else,  
*what waits for what else,
*what becomes what else,  
*what becomes what else,
*what decisions are made,
*what decisions are made,
… and much more.


With a standard language for this, we can use a machine (the PC) to build this system model.
… and much more.  


This is highly useful, because in this kind of machine we can use the language to reconfigure our system model to represent a variety of current interpretations of, or future options for the system being examined. These representations can be stored, transmitted, and reproduced in other machines, in other locations, before other eyes.
With a standard language for this, we can use a machine (the PC) to build this system model.  


Planimate® is a language for specifying the elements and behaviours of a dynamic system.
This is highly useful, because in this kind of machine we can use the language to reconfigure our system model to represent a variety of current interpretations of, or future options for the system being examined. These representations can be stored, transmitted, and reproduced in other machines, in other locations, before other eyes.  


Planimate® is a language for specifying the elements and behaviours of a dynamic system.


== Hands On ==
To represent a system in a Planimate model, we first need to learn about its building blocks and basic concepts.


Launch Planimate and explore it a little.
<br>


Maximize the window.
== Hands On  ==


Load a simple model from the Intro Folder
Launch Planimate and explore it a little.


Press a few buttons, run it etc, look around…
Maximize the window.


Load a simple model from the Intro Folder


Start a New Model (Discard current)
Press a few buttons, run it etc, look around…


If not already visible, show the Object Palette / sidebar  (View / Object Palette).


You can drag objects off the palette or click them and then click where you want them.
<br> Start a New Model (Discard current)


Drag them about,
If not already visible, show the Tools Menu / sidebar (View / Tools Window).


Rename them by clicking on the names.
You can drag objects off the menu tree (left mouse click on object and hold while dragging) onto the panel.  


Right-click on them to produce their editing menu.
Drag them about,


Delete them.
Rename them by clicking on the names.  


Copy and Paste them.
Right-click on them to produce their editing menu.  


Save, and then start a New model.
Delete them.  


Now for <u>your</u> first Planimate® model - a Distribution Centre.
Copy and Paste them.  


Change to Object View <Ctrl+O>.


Make the Clock visible using View / Simulation Clock.
Save, and then start a New model.  


Your mouse pointer should look like: [[File:object_edit_mouse_pointer.png]]


From the object palette, Add an:
Now for your first Planimate® model - a Distribution Centre.
{|border="1"
 
|[[Entry]]
Change to Object View &lt;Ctrl+O&gt;.
|Items cross the system boundary and enter a system from an Entry.
 
(NB: an Entry has no Capacity)
Make the Clock visible using View / Simulation Clock.
 
[[Image:sim clock.png]]
 
Your mouse pointer should look like: [[Image:Object edit mouse pointer.png]]
 
From the object palette, Add an:  
 
{| border="1"
|-
| [[Entry]]  
| Items cross the system boundary and enter a system from an Entry.  
(NB: an Entry has no Capacity)  
 
|-
|-
|[[Queue]]
| [[Queue]]  
|Items wait in Queues to access other objects.
| Items wait in Queues to access other objects.
|-
|-
|[[Multiserver]]
| [[Multiserver]]  
|We use the default Single Capacity (only holds one thing).
| We use the default Single Capacity (only holds one thing).  
Rename it to “Load or Unload”.
Rename it to “Load or Unload”.  
 
|-
|-
|[[Exit]].
| [[Exit]].  
|Items leave the system through the exit, it is another boundary.
| Items leave the system through the exit, it is another boundary.  
(NB: an Exit has no Capacity)
(NB: an Exit has no Capacity)  
 
|}
|}


<br> Line them up from left to right. These are the objects of our system.


Line them up from left to right. These are the objects of our system.
Save your Model (We will call this Model DC01).  


Save your Model (We will call this Model DC01).
Reflect on the question: “<u>Where</u> is the Distribution Centre?”. Next we need to define the items that will move through and interact with these objects in the Distribution Centre.  


Reflect on the question: “<u>Where</u> is the DC?”. Next we need to define the items that will move through and interact with these objects in the DC.


Go to Menu Bar / Edit / Item Classes / Add New Item Class.
Go to Menu Bar / Edit / Item Classes / Add New Item Class.  


Give it the name “Vehicle”
Give it the name “Vehicle”  


Notice the following things:
Notice the following things:  
*An Item icon appears in the Item Palette.
 
*The mouse pointer changes to show: [[File:flow_edit_mouse_pointer.png]]
*An Item icon appears in the Item Palette.  
*The mouse pointer changes to show: [[Image:Flow edit mouse pointer.png]]  
*(Flow) indicator in Planimate®’s Window Title.
*(Flow) indicator in Planimate®’s Window Title.
Now create a path from Entry > Queue > Server > Exit by clicking on each in turn, from left to right.


[[File:Path_simple.png]]
Now create a path from Entry &gt; Queue &gt; Server &gt; Exit by clicking on each in turn, from left to right.  


Type Ctrl-O to get back to object mode and save the model.
[[Image:Path simple.png]]


Run the Model. One item will move across the model. OK the dialog that announces the model has finished.
Type Ctrl-O to get back to object mode and save the model.  


To make things more interesting, right click the Entry and select Mode. Select “Periodic Arrivals” from the list. OK and run the model again.
Run the Model. One item will move across the model. OK the dialog that announces the model has finished.  


To make things more interesting, right click the Entry and select Mode. Select “Periodic Arrivals” from the list. OK and run the model again.


== Observations ==
<br>


Now it is time to study the model and make and discuss observations, so you get a better understanding of the language being used in a Planimate® dynamic model.
== Observations  ==


Here are some questions for you to examine:
Now it is time to study the model and make and discuss observations, so you get a better understanding of the language being used in a Planimate® dynamic model.
*Can you explain what the clock is doing?
 
*Can you identify the different “Events” in this simulation?
Here are some questions for you to examine:  
*Does the clock “Tick” during Animation?
 
*How many items animate at a time?
*Can you explain what the clock is doing?  
*Does the animation of an Item from one object to the next involve the passing of time - if so, <u>which</u> time?
*Can you identify the different “Events” in this simulation?  
*What is the Inter-Arrival Time between items?
*Does the clock “Tick” during Animation?  
*What is the processing delay time at the Load or Unload server?
*How many items animate at a time?  
*Does the animation of an Item from one object to the next involve the passing of time - if so, <u>which</u> time?  
*What is the Inter-Arrival Time between items?  
*What is the processing delay time at the Load or Unload server?  
*Is there any queuing - are any items waiting to enter the load or unload process?
*Is there any queuing - are any items waiting to enter the load or unload process?
:(look VERY carefully here).
:(look VERY carefully here).
*How does the processing capacity of this system compare to the demand placed on it?
 
*How does the processing capacity of this system compare to the demand placed on it?  
*What is the efficiency of this system?
*What is the efficiency of this system?


<br> Is this the “real world”?


Is this the “real world”?
*Are “customer” arrivals always normally steady?  
*Are “customer” arrivals always normally steady?
*Do all processes always take exactly the same time?  
*Do all processes always take exactly the same time?
*Do we expect to always get serviced immediately?
*Do we expect to always get serviced immediately?


<br> We need to make this model more realistic.


We need to make this model more realistic.
<br> More work is needed on INTERACTIONS between Items and Objects.  
 


More work is needed on INTERACTIONS between Items and Objects.
There are a number of types of interactions occurring in this model already:


There are a number of types of interactions occurring in this model already:
*Item Arrivals at the System boundary - INTER-ARRIVAL TIME.  
*Item Arrivals at the System boundary - INTER-ARRIVAL TIME.
*Items passing through the fixed entities - PROCESSING TIME.
*Items passing through the fixed entities - PROCESSING TIME.


<br> These interaction times can be made to vary from one item to the next, to make the system more realistic.


These interaction times can be made to vary from one item to the next, to make the system more realistic.
Let’s set up some parameters to go into these interactions:


Let’s set up some parameters to go into these interactions:
{| border="1"
{|border="1"
|-
!Time Parameter
! Time Parameter  
!Average
! Average  
!Variation Pattern
! Variation Pattern  
!Deviation
! Deviation
|-
|-
|'''Inter-Arrival
| '''Inter-Arrival'''
|5min 0sec
| 5min 0sec  
|Equally Likely
| Equally Likely  
(aka Uniform Distribution)
(aka Uniform Distribution)  
|2min 48sec
 
| 2min 48sec
|-
|-
|'''Load or Unload
| '''Load or Unload'''
|5min 0sec
| 5min 0sec  
|Bell Curve
| Bell Curve  
(aka Normal Distribution)
(aka Normal Distribution)  
|1min 6sec
 
| 1min 6sec
|}
|}
Regardless of the variation pattern, we will keep the averages the same.


== More Hands On ==
Regardless of the variation pattern, we will keep the averages the same.


Go to '''Menu Bar / Edit / Interactions''' (Ctrl-I is a shortcut).
<br>


Notice the following things:
== More Hands On  ==
*The mouse pointer changes to show:
*(Interact) indicator in Planimate®’s Window Title.
*The Item Path appears in RED.


<br> Double-click on the ENTRY (Alternatively Right-click on the ENTRY and select Arrival Details from the pop-up menu) to bring up the ‘Arrival Details’ dialog box.


Click on the ENTRY
*Click the Pattern button next to Interval  
*Click the Pattern button next to Interval
*Configure the Distribution Pattern Dialog as above
*Configure the Distribution Pattern Dialog as above
:(Equally Likely / Mean 0:5 / Range 0:2.48).
:(Equally Likely / Mean 0:5 / Range 0:2.48).
*Click on the Preview Plot button to View the distribution pattern.
*Click on the Preview Plot button to View the distribution pattern.
:[[File:training_entry_equally_likely_dist.png]]
 
:[[Image:Entry inter arrival dialog.png]]
 
*Click OK to close both dialogs.
*Click OK to close both dialogs.
Right click on the Load or Unload Server Object
 
*Select Bell Curve / Mean 0:5 / StdDev 0:1 06 in the Distribution Pattern Dialog.
 
*Right click on the ‘Load or Unload’ Server Object and select the available option under Delay Time. This brings up the Delay Time dialog box for class ‘Vehicle’.
*Select Bell Curve / Mean 0:5 / StdDev 0:1 06 in the Distribution Pattern Dialog.  
*Click Preview Plot to View distribution pattern.
*Click Preview Plot to View distribution pattern.
:[[File:training_entry_normal_dist.png]]


Notice the range of possible values in the sample plot. While the graph may show numbers less then zero the minimum will be clamped to 0 as time cannot go backwards.
:[[Image:Delay Time class vehicle.png]]
 
Notice the range of possible values in the sample plot. While the graph may show numbers less then zero the minimum will be clamped to 0 as time cannot go backwards.  
 
Save, Run and Observe the Model
 
Notice any new behaviour?
 
Queuing now happens. If you want to log and trace the queuing activity, refer to the Logging Object Attributes – Log Viewer Module section.
 
 
We will now make use of the time acceleration features of Planimate®.
 
With the model paused, right click on the background of the model. The '''Advance to Time &amp; Advance for Interval''' options enable you to ‘fast-forward’ the model up to a future point of time.
 
Select '''Advance For Interval''' in the background menu and enter “20d” in the dialog. This will advance for 20 days. After the advance (it will be quick) select “Pause”.
(Note: You may get an error message about the Entry being “blocked”. If so, this will be explained below)
 
<br>
 
== Queue Occupancy  ==
 
 
The default Queue has a capacity of 10 items, 5 visible and 5 indicated by the counter. If you run the model for a longer period, the queue will become full. This means the next item out of the Entry has nowhere to go and the Entry indicates this “blocked” situation by becoming red.
 
[[Image:Queue full.png]]
 
 
Blocking an Entry is bad for a simulation because it means items that were scheduled to arrive are not making it into the simulation.
 
RULE: Never Block an Entry because it will distort demand on your system.
 
Let’s try “fix” the system by adding a bigger queue capacity.
 
<br>
 
== Exploratory Exercise  ==
 
 
Now would be a good time to investigate the queue occupancy further using the Log Viewer module to log the attribute. Read about the Log Viewer module in section ‘Logging Object Attributes – Log Viewer Module’ if you haven’t already. Add the Log Viewer module to your DC01 model and set it up to monitor the queue’s occupancy.
 
Run the model again, and have a look at the graph of the queue’s occupancy.
 
[[Image:Queue occupancy.png]]
 
You can see where the queue grows to its maximum capacity of 10 items, leading to a blockage at the Entry.
Make a bigger queue capacity (100).
 
Stop the run and (in Object Mode) right click on the Queue and set its Capacity to 100.
 
Run the model again, advance for 20 days then stop the run.
 
This time, the increase in queue capacity allows the model to run fully without blockages.
 
[[Image:Queue occupancy 2.png]]
 
From the graph of queue occupancy over the time period, we can see it reaches a maximum occupancy of around 40, which is well under the maximum capacity of 100.
 
Try run the model for 52 weeks (type in “52w” in the Advance for Interval dialog) and look at the occupancy. What do you find? More blockage?
 
This is an unstable system.
 
Even though the average rates of arrival and service match, due to the accumulating effect of the variation, the longer system runs, the longer the queue (and the wait) will get.
 
<br>
 
=== Reflect and Discuss  ===
 
 
What is going on here?
 
*The system experiences serious, significant instability, evidenced by rapid growth and shrinkage in queue occupancy. Will you have room for a large enough queue?
*What will customers and managers think of the waiting times?
*Where does catch up come from, and how does it happen?
*Are there any useful control mechanisms is the current system?.
 
<br> Discuss the causes of the instability of this system.
 
*Dependency due to the Queue?
*Variation in arrivals, and/or in the server?
*The queue size limit?
 
Actually the thing you can really blame is full utilisation... What..?
 
<br> If you had until now assumed that::
 
:A ‘balanced system”,
:where average process capacity = average demand,
:would also be a ‘stable’ system…
 
has this experience altered that view?
 
<br> What will it take to “tame” this system?
 
*We need to design Recovery Time into it.
*How do we go about this?
 
<br>


Save, Run and Observe the Model
== Utilisation Ratio Exercise  ==
*Notice any new behaviour.
*Queuing now happens.
*Let us trace the queuing activity.


Go back to object mode (Ctrl-O) and right click on the Queue.
Lets say we found a way to reduce our loading time by just 5%. How would it affect the chaotic behaviour of the model?


Select “Log Attributes To File”.
With the DC01 model loaded, type Ctrl-I to edit interactions and click on the [[Multiserver]] (Load or Unload). In the distribution dialog, set the scaling field to 0.95 instead of 1.0


Tick the Queue 1 Occupancy row and OK the dialog.
This change will scale back the process time for all items so they will (on average) be 5 percent shorter. Effectively, we have added 5 percent extra capacity to the server in this subsystem.  


Save and Run the model. Now click and pause the model (or press ESC).
Run the model and investigate the logged results.  


We will now make use of the time acceleration features of Planimate®.
<br>


With the model paused, right click on the background of the model. The '''Advance to Time & Advance for Interval''' options enable you to ‘fast-forward’ the model up to a future point of time.
=== Reflect and Discuss  ===


Select '''Advance For Interval''' in the background menu and enter “20d” in the dialog. This will advance for 20 days. After the advance (it will be quick) select “Pause”.
There’s nothing like a bit of extra capacity to tame an unstable system!


== Viewing Results Graphically ==
Here is the shape of the general relationship between utilisation and average queue length:


Planimate models often contain graphs and views of data, but for simplicity in this tutorial we will use a pre-made Planimate application to study our model's performance.
[[Image:Training utilvsQlength.png]]


The “Log Attributes To File” option we selected earlier has caused the Queue's occupancy to be written to a log file.
*now the question to be addressed will be.. how much capacity to supply?


Select '''menubar / Tools / Log Viewer'''. This will open another window, the Planimate Log Viewer application.
Change the scaling to test different what-ifs. You will get a good idea of how the instability relates to utilisation ratio.  


From its menu bar select '''File / Load Data'''. Browse to the folder where you saved the DC model, In this folder you should find dc01_01. Upon opening this file you will receive a “Log Data Successfully Loaded” message. OK It.
You can actually do a wide range of explorations with this issue, because the nature of the curve is affected by both the pattern and degree of variation, and the interplay between the arrival and processing patterns.  


The viewer will switch to a new page and you will see Queue 1 Occupancy on the left. Click the cross in the left hand column, it will change to a tick and a graph will appear.
Knowing the effects of the utilisation ratio, the question of how much capacity to supply is now not only solvable, but justifiable to other decision makers who may also carry the assumption about full utilisation being a worthwhile pursuit.  


[[File:training_first_q1_log.png|500px]]
Knowing what circumstances you don’t want to happen (full utilisation), you can now take on the possibility of managing customer expectations. The issue to focus on now is customer experience, rather than “fire-fighting”.  


Notice the peak of the instantaneous graph is at 10. Lets examine this closer. Alt-tab back to Planimate and run model again. Use the Advance To Time again but this time select “Continue” instead of pause. Look closely at the Queue and Entry.
How much stability and recovery time do you want or need, to meet customer expectations?


The default Queue has a capacity of 10 items, 5 visible and 5 indicated by the counter. You can see that the queue is full. This means the next item out of the Entry has nowhere to go and the Entry indicates this “blocked” situation by becoming red.
The way is now open for you to study the impact of fostering various customer behaviour, as well as the provision of supply capacity.  


[[File:training_blocked_entry.png]]
Both supply AND demand dynamics can be studied, and understood.  


Blocking an Entry is bad for a simulation because it means items that were scheduled to arrive are not making it into the simulation.
The next step will be to take this new appreciation of the non-linearity of system behaviour forward as we use the language of Planimate® to refine the representation of a Distribution Centre that we have achieved so far.  


RULE: Never Block an Entry because it will distort demand on your system.
[[Evolving_Your_First_Planimate®_Model|Next:&nbsp;Evolving your first model]].


Let’s try “fix” the system by adding a bigger queue capacity.
[[Category:Training]]

Latest revision as of 12:36, 1 March 2016

Explanation

This model will introduce you to basic elements of the Planimate® platform and also provide some initial experience with some important general concepts concerning the dynamic behaviour of systems.


We are going to take a look at a simple system and its dynamics.

The major dynamic events of this system will be as follows:

Arrivals = Entry into System.
Waiting Around = Queuing for Service.
Processing = by a Server.
Departure = Exit from System.


The thing to appreciate here is:

  • We want to make a model of a system to see, learn or show others how it works.
  • In this system, events occur and it changes over time.
  • Hence the model must be dynamic.


Imagine we could isolate an area in a real system (e.g. a set of office cubicles), then watch and record what happens in it.

A video recording is one possible strategy for recording a system’s activities. To fully cover the system area, you may need many simultaneous recording streams. And what would you record - the people or the paper?

You would then also need to set up an array of screens for the viewer to watch the playbacks.Too many screens and not enough eyes makes forming a useful understanding of cause and effect in this system very elusive. And even then, there is still a need to be able to communicate this behaviour to others, so that they can understand it, before you can then fruitfully discuss future options for the system.

To be able to give this information to somebody else to review, some kind of language is needed to represent how the events going on in that system relate to each other, things like:

  • what causes what,
  • what waits for what else,
  • what becomes what else,
  • what decisions are made,

… and much more.

With a standard language for this, we can use a machine (the PC) to build this system model.

This is highly useful, because in this kind of machine we can use the language to reconfigure our system model to represent a variety of current interpretations of, or future options for the system being examined. These representations can be stored, transmitted, and reproduced in other machines, in other locations, before other eyes.

Planimate® is a language for specifying the elements and behaviours of a dynamic system.

To represent a system in a Planimate model, we first need to learn about its building blocks and basic concepts.


Hands On

Launch Planimate and explore it a little.

Maximize the window.

Load a simple model from the Intro Folder

Press a few buttons, run it etc, look around…



Start a New Model (Discard current)

If not already visible, show the Tools Menu / sidebar (View / Tools Window).

You can drag objects off the menu tree (left mouse click on object and hold while dragging) onto the panel.

Drag them about,

Rename them by clicking on the names.

Right-click on them to produce their editing menu.

Delete them.

Copy and Paste them.


Save, and then start a New model.


Now for your first Planimate® model - a Distribution Centre.

Change to Object View <Ctrl+O>.

Make the Clock visible using View / Simulation Clock.

Sim clock.png

Your mouse pointer should look like: Object edit mouse pointer.png

From the object palette, Add an:

Entry Items cross the system boundary and enter a system from an Entry.

(NB: an Entry has no Capacity)

Queue Items wait in Queues to access other objects.
Multiserver We use the default Single Capacity (only holds one thing).

Rename it to “Load or Unload”.

Exit. Items leave the system through the exit, it is another boundary.

(NB: an Exit has no Capacity)


Line them up from left to right. These are the objects of our system.

Save your Model (We will call this Model DC01).

Reflect on the question: “Where is the Distribution Centre?”. Next we need to define the items that will move through and interact with these objects in the Distribution Centre.


Go to Menu Bar / Edit / Item Classes / Add New Item Class.

Give it the name “Vehicle”

Notice the following things:

  • An Item icon appears in the Item Palette.
  • The mouse pointer changes to show: Flow edit mouse pointer.png
  • (Flow) indicator in Planimate®’s Window Title.

Now create a path from Entry > Queue > Server > Exit by clicking on each in turn, from left to right.

Path simple.png

Type Ctrl-O to get back to object mode and save the model.

Run the Model. One item will move across the model. OK the dialog that announces the model has finished.

To make things more interesting, right click the Entry and select Mode. Select “Periodic Arrivals” from the list. OK and run the model again.


Observations

Now it is time to study the model and make and discuss observations, so you get a better understanding of the language being used in a Planimate® dynamic model.

Here are some questions for you to examine:

  • Can you explain what the clock is doing?
  • Can you identify the different “Events” in this simulation?
  • Does the clock “Tick” during Animation?
  • How many items animate at a time?
  • Does the animation of an Item from one object to the next involve the passing of time - if so, which time?
  • What is the Inter-Arrival Time between items?
  • What is the processing delay time at the Load or Unload server?
  • Is there any queuing - are any items waiting to enter the load or unload process?
(look VERY carefully here).
  • How does the processing capacity of this system compare to the demand placed on it?
  • What is the efficiency of this system?


Is this the “real world”?

  • Are “customer” arrivals always normally steady?
  • Do all processes always take exactly the same time?
  • Do we expect to always get serviced immediately?


We need to make this model more realistic.


More work is needed on INTERACTIONS between Items and Objects.

There are a number of types of interactions occurring in this model already:

  • Item Arrivals at the System boundary - INTER-ARRIVAL TIME.
  • Items passing through the fixed entities - PROCESSING TIME.


These interaction times can be made to vary from one item to the next, to make the system more realistic.

Let’s set up some parameters to go into these interactions:

Time Parameter Average Variation Pattern Deviation
Inter-Arrival 5min 0sec Equally Likely

(aka Uniform Distribution)

2min 48sec
Load or Unload 5min 0sec Bell Curve

(aka Normal Distribution)

1min 6sec

Regardless of the variation pattern, we will keep the averages the same.


More Hands On


Double-click on the ENTRY (Alternatively Right-click on the ENTRY and select Arrival Details from the pop-up menu) to bring up the ‘Arrival Details’ dialog box.

  • Click the Pattern button next to Interval
  • Configure the Distribution Pattern Dialog as above
(Equally Likely / Mean 0:5 / Range 0:2.48).
  • Click on the Preview Plot button to View the distribution pattern.
Entry inter arrival dialog.png
  • Click OK to close both dialogs.


  • Right click on the ‘Load or Unload’ Server Object and select the available option under Delay Time. This brings up the Delay Time dialog box for class ‘Vehicle’.
  • Select Bell Curve / Mean 0:5 / StdDev 0:1 06 in the Distribution Pattern Dialog.
  • Click Preview Plot to View distribution pattern.
Delay Time class vehicle.png

Notice the range of possible values in the sample plot. While the graph may show numbers less then zero the minimum will be clamped to 0 as time cannot go backwards.

Save, Run and Observe the Model

Notice any new behaviour?

Queuing now happens. If you want to log and trace the queuing activity, refer to the Logging Object Attributes – Log Viewer Module section.


We will now make use of the time acceleration features of Planimate®.

With the model paused, right click on the background of the model. The Advance to Time & Advance for Interval options enable you to ‘fast-forward’ the model up to a future point of time.

Select Advance For Interval in the background menu and enter “20d” in the dialog. This will advance for 20 days. After the advance (it will be quick) select “Pause”. (Note: You may get an error message about the Entry being “blocked”. If so, this will be explained below)


Queue Occupancy

The default Queue has a capacity of 10 items, 5 visible and 5 indicated by the counter. If you run the model for a longer period, the queue will become full. This means the next item out of the Entry has nowhere to go and the Entry indicates this “blocked” situation by becoming red.

Queue full.png


Blocking an Entry is bad for a simulation because it means items that were scheduled to arrive are not making it into the simulation.

RULE: Never Block an Entry because it will distort demand on your system.

Let’s try “fix” the system by adding a bigger queue capacity.


Exploratory Exercise

Now would be a good time to investigate the queue occupancy further using the Log Viewer module to log the attribute. Read about the Log Viewer module in section ‘Logging Object Attributes – Log Viewer Module’ if you haven’t already. Add the Log Viewer module to your DC01 model and set it up to monitor the queue’s occupancy.

Run the model again, and have a look at the graph of the queue’s occupancy.

Queue occupancy.png


You can see where the queue grows to its maximum capacity of 10 items, leading to a blockage at the Entry. Make a bigger queue capacity (100).

Stop the run and (in Object Mode) right click on the Queue and set its Capacity to 100.

Run the model again, advance for 20 days then stop the run.

This time, the increase in queue capacity allows the model to run fully without blockages.

Queue occupancy 2.png

From the graph of queue occupancy over the time period, we can see it reaches a maximum occupancy of around 40, which is well under the maximum capacity of 100.

Try run the model for 52 weeks (type in “52w” in the Advance for Interval dialog) and look at the occupancy. What do you find? More blockage?

This is an unstable system.

Even though the average rates of arrival and service match, due to the accumulating effect of the variation, the longer system runs, the longer the queue (and the wait) will get.


Reflect and Discuss

What is going on here?

  • The system experiences serious, significant instability, evidenced by rapid growth and shrinkage in queue occupancy. Will you have room for a large enough queue?
  • What will customers and managers think of the waiting times?
  • Where does catch up come from, and how does it happen?
  • Are there any useful control mechanisms is the current system?.


Discuss the causes of the instability of this system.

  • Dependency due to the Queue?
  • Variation in arrivals, and/or in the server?
  • The queue size limit?

Actually the thing you can really blame is full utilisation... What..?


If you had until now assumed that::

A ‘balanced system”,
where average process capacity = average demand,
would also be a ‘stable’ system…

has this experience altered that view?


What will it take to “tame” this system?

  • We need to design Recovery Time into it.
  • How do we go about this?


Utilisation Ratio Exercise

Lets say we found a way to reduce our loading time by just 5%. How would it affect the chaotic behaviour of the model?

With the DC01 model loaded, type Ctrl-I to edit interactions and click on the Multiserver (Load or Unload). In the distribution dialog, set the scaling field to 0.95 instead of 1.0

This change will scale back the process time for all items so they will (on average) be 5 percent shorter. Effectively, we have added 5 percent extra capacity to the server in this subsystem.

Run the model and investigate the logged results.


Reflect and Discuss

There’s nothing like a bit of extra capacity to tame an unstable system!

Here is the shape of the general relationship between utilisation and average queue length:

Training utilvsQlength.png

  • now the question to be addressed will be.. how much capacity to supply?

Change the scaling to test different what-ifs. You will get a good idea of how the instability relates to utilisation ratio.

You can actually do a wide range of explorations with this issue, because the nature of the curve is affected by both the pattern and degree of variation, and the interplay between the arrival and processing patterns.

Knowing the effects of the utilisation ratio, the question of how much capacity to supply is now not only solvable, but justifiable to other decision makers who may also carry the assumption about full utilisation being a worthwhile pursuit.

Knowing what circumstances you don’t want to happen (full utilisation), you can now take on the possibility of managing customer expectations. The issue to focus on now is customer experience, rather than “fire-fighting”.

How much stability and recovery time do you want or need, to meet customer expectations?

The way is now open for you to study the impact of fostering various customer behaviour, as well as the provision of supply capacity.

Both supply AND demand dynamics can be studied, and understood.

The next step will be to take this new appreciation of the non-linearity of system behaviour forward as we use the language of Planimate® to refine the representation of a Distribution Centre that we have achieved so far.

Next: Evolving your first model.

Retrieved from ‘