First Planimate® Model - the ‘Perils of Average Thinking’From Planimate Knowledge Base
ExplanationThis 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.
The major dynamic events of this system will be as follows:
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:
… 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.
Hands OnLaunch 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…
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. 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. Your mouse pointer should look like: From the object palette, Add an:
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:
Now create a path from Entry > Queue > Server > Exit by clicking on each in turn, from left to right. 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.
ObservationsNow 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:
There are a number of types of interactions occurring in this model already:
Let’s set up some parameters to go into these interactions:
Regardless of the variation pattern, we will keep the averages the same.
More Hands OnGo to Menu Bar / Edit / Interactions (Ctrl-I is a shortcut). Notice the following things:
Right click on the Load or Unload Server Object
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
Go back to object mode (Ctrl-O) and right click on the Queue. Select “Log Attributes To File”. Tick the Queue 1 Occupancy row and OK the dialog. Save and Run the model. Now click and pause the model (or press ESC). 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”.
Viewing Results GraphicallyPlanimate 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. The “Log Attributes To File” option we selected earlier has caused the Queue's occupancy to be written to a log file. Select menubar / Tools / Log Viewer. This will open another window, the Planimate Log Viewer application. From its menu bar select File / Load Data. Browse to the folder where you saved the Distribution Centre model, In this folder you should find dc01_01. Upon opening this file you will receive a “Log Data Successfully Loaded” message. OK It. 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. 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. 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. 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 ExerciseLets 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. Alt-tab back to the Log Viewer and load the dc01_01 file again. The maximum occupancy of 40 is within the queue's limit... but even averaged, there are over 25 waiting in the queue for a process which on average takes 5 minutes each! Try run the model for 100 days and look at the occupancy. 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 DiscussWhat is going on here…
Actually the thing you can really blame is full utilisation... What..?
has this experience altered that view?
Utilisation Ratio ExerciseLets 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 DiscussThere’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:
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. |





