Evolving Your First Planimate® Model

From Planimate Knowledge Base
Jump to: navigation, search

We will now refine our model of a distribution system, by gradually adding details.

We could assert that this initial model we have created shows the complete activity in a distribution centre.

To do so would mean assuming that the entry arrivals represent all types of visitations to the distribution centre, both deliveries and collections. The Load or Unload multiserver could be assumed to be performing either of those functions. Obviously there will be benefit in adding more detail, so we can learn more about the dynamics of the system.

Think about the major elements of a supply chain distribution centre.

Creating the Receival Subsystem

Re-Load DC01 and save it as DC 02.MDL.

Rename your Entry 1 to read “Inbound”.

From the Object Palette, add a Portal to the model and name it “DC Receiving”.

Edit the path so instead of going to the “Load or Unload Server”, it goes through the “DC Receiving” portal instead. Click on one of the arrowheads of the path to select it for Flow editing. Click on the multiserver to put the selection square around it. Now click in it and drag towards the Portal. Let go when the box is flashing around the Portal. It should now replace the multiserver in the path.

Ctrl-O to get to object mode and reposition the objects in a neat row. Copy the Load or Unload Server

About the Portal

Portal Palette Icon.jpg

A Portal object appears on the screen like any other object but rather than having a fixed behaviour, it is a link to a sub-system screen.

Every Portal contains one Subsystem screen on which there is always at least one Portal Entry and one Portal Exit. A Portal can be classified as “Logical Only”, as it cannot itself hold items. Only the capacity objects in the subsystem can hold items.

No time passes while an item moves into or out of a Portal. An item entering a portal is 'teleported' to the sub-system screen and appears on that screen at the Portal Entry object, and proceeds along its path. Likewise, any item entering a Portal Exit on a subsystem screen will re-appear on the screen containing the Portal which owns that subsystem, and proceed along the path.

For full details refer to this page: Portal

Notice the Model Hierarchy in the sidebar. This shows the hierarchical arrangement of all the portals. You can use it to navigate around your model, including for getting back to the <main> panel.

Now lets set up the distribution centre Receiving Portal.

Double click the DC Receiving Portal. You're now looking inside the portal. You will see a Portal Entry and a Portal Exit. These are the connection to the “outside world”.

Right click and paste the “Load or Unload” multiserver you copied earlier into the DC Receiving Portal.

Rename it to “Unload Truck”.

Click on the item in the Item Palette. This selects it and enables you to start a new path. Create a path for the Vehicle Item from the Portal Entry, through the Load or Unload multi-server and to the Portal Exit.

Save and Run your model to make sure it is connected together correctly and working. Planimate will report if there is a problem, such as a missing path inside the portal.

This receiving subsystem has two main parameters that are of interest at this level of detail:

  • Vehicle Holding Capacity - expressed as “Number of Unloading Bays”.
  • Unloading Rate - expressed as “Average time to Unload a Vehicle”.

To make these parameters easy to adjust, we will use portal specific variables which in Planimate are called Portal Attributes. These will store, display and provide the values we set to the model.

In Object View, right click on the MultiServer, and set the Server Limit to 100.

(We will assume that there will never be more than 100 receiving lanes).

Now right click on the MultiServer again and select the Capacity option.

A new dialog comes up. This dialog enables you to enter values and much more including mathematical formulae and most importantly, references to attributes in the model.

In this dialog type p.Receiving_Lanes. Planimate will realise this Portal Attribute doesn't exist yet and prompt you to create it. Select OK and another dialog appears.

Click in the “Initial Value” field and put a value of 5.

Click the “Add View” button. This creates an on-screen view of the attribute. For now, dismiss the configuration menu for the view. You can configure the view by right-clicking on it. Clicking in the numerical value enables you to change it.

Now we create another portal attribute for the unloading rate. Lets do it a different way. Select the MenuBar / Data / Portal Attributes option. This shows you a list of portal attributes. You will see the Receiving_Lanes attribute you just created.

Click the Add Attribute button at the bottom left. The Attribute dialog you saw before appears again. This time you need to enter a name, call it “Unload_Rate”.

Now drop down the “Format” combo-box list by clicking the small down facing arrow. You will see Planimate® has many ways of formatting the display of attributes.

Select “Time [#w #d] hh:mm:ss”. This will enable you to set the Unload_Rate using hours:minutes:seconds formatting.

Set a value of 1:0:0. This means one hour.

Again click Add View so you can readily work with the attribute on the panel.

You might want to reposition the attribute views so they are not above each other – there should be 2 of them now.

The final step is now to associate the second attribute with the multiserver. To do this we need to go to interaction view.

Type Ctrl-I and click on the multi-server. Since we want to control the distribution from an attribute, its easiest to set up a “unity” distribution and then scale this. Set the Mean to 1 and the StdDev to 0.1.

Now click on the little “>” next to the Scaling field. Recognise this dialog? Its the same one you used to set the Capacity of the multiserver.

Type just the letter “p” and then “.” ... see that, Planimate® has popped up a list of all the available portal attributes for you. Now type a “U”. The selection is narrowed down to the attribute you want. Use the up and down arrows to highlight it and press space. The reference is selected and you can click Ok or press Enter to accept it.

With this configuration, the distribution will be scaled by the attribute. Since the mean of the distribution is 1, after scaling the mean will be whatever the value of the Unload Time attribute.

Dont forget to Ok the distribution dialog otherwise changes within will be lost.

Its now time to go back to the <main> screen. You can do this using the Model Hierarchy. You can also double click either portal entry or exit. If you prefer typing, Ctrl-D and Ctrl-F walk you through the panels you have recently visited, much like the forward and back buttons in a web browser.

On the <main> panel, go to Interaction mode and click on the Entry. We will add a parameter for its arrival interval in the same way as we did for the Multiserver.

Set the arrival distribution values to Equally Likely, Mean:1 Range:1 and select the Scale “>” button. Enter “P.Arrival_IAT”, format it as “[w d] hh:mm:ss” and add a view.

Let us assume for now the following circumstances for the distribution centre

  • 24 hour x 7 day operation.
  • 150 deliveries in a 24 hour period (average).
  • 40 minutes to unload a vehicle (on average).

Now we can use the above figures to set up some reasonable starting parameter values before we test our new model structure. Some simple arithmetic will suffice:

Inter-Arrival Time:

1440 minutes / 150 deliveries = 9.6 minutes between vehicles.

Let us say it is equally probable that a vehicle will arrive any time within that interval.

So we use an equally likely distribution set to Mean: 1.0 Range: 1.0.

Scaled by 9.6 minutes will give us the average arrival interval of 9.6 minutes.

Number of Receiving Lanes

Ignoring the Utilisation Ratio issue initially, we can calculate the nominal number of receiving lanes required:

40 minutes per vehicle / 9.6 minutes IAT = 4.17 Lanes

This can be rounded up to five lanes.

We do need to allow for recovery capacity by reducing the utilisation ratio, however having to round up the number of lanes may have realised this for us anyway.

Allow for Recovery

Recheck the Utilisation Ratio with the new numbers:

40 minutes per vehicle / 5 Lanes = 8 minutes between vehicle departures (average)

8 minutes / 9.6 minutes = 83% utilisation.

This looks like it will work.

Out of interest, 4 lanes in use = 10 mins between vehicles, and Utilisation of 10 / 9.6 = 104%, which will definitely not work, in a continuous processing environment like this one.

Enter these numbers into the correct portal attributes in your model, save it, run it, and check the logged results.

Creating the Dispatch Subsystem

Now that you have created a subsystem where our Receival Parameters are stored, the benefit of a housing a subsystem in a portal begins to become clearer.

Save your Model as DC04, so you can review how you built up your model at a later date.

You can now make a copy of this portal, then paste it to create another subsystem, which we will use to represent the Dispatch System, which also happens to have lanes, and processing capacity.

We can rename the portal attribute and the multiserver inside this portal to suit our purposes. Copy the Inbound Entry, paste it and rename it to “Dispatch”.

Let us assume that there will be slightly less outbound vehicles than inbound. Perhaps due to the consolidation of incoming goods into pallets for stores.

100 dispatch vehicles per day will result in an IAT of 14.4 minutes.

If we assume that loading a vehicle takes a similar time to unloading (40 mins), then we nominally require

40 min / 14.4 min = 2.8 lanes.

Round up to three lanes and then checking utilisation ratio, this is:

40 min / 3 lanes = 13.33 mins between vehicles

13.33 min / 14.4 min = 92.6%

This utilisation ratio is fairly high.

We should be careful with this one, and test to satisfy ourselves that it will be adequate.

Let’s do so now.. after checking that your model follows this example, and that your second queue is being logged.

Training receiving and dispatch.png

Implementing a Sorter Facility

Now you can begin the process of linking the receivals with the dispatch subsystem.

Save your Model as DC05, so you can review how you built up your model at a later date.

The activity of unloading vehicles produces pallets of goods that need to be staged, then moved to an unpacking area, where cartons are placed on to a sorter.

You are about to model that area, and the processes leading up to it.

You will be adding more detail to the processes inside the Receival subsystem, and adding a new Portal, to represent the Sorter facility.

This exercise introduces another object, called the Splitter, which enables you to generate different item classes in varying quantities. You will use it to create Pallets from unloaded vehicles, and cartons from pallets.

You will also be required to specify a range of new Portal Attributes.

This exercise will also introduce you to the impact of congestion and blocking effects on the dynamics of a system, and you will use this study to determine required performance parameters.

First, go inside the Receivals subsystem to add more detail there, like in this example.

Training receiving area.png

The object named “Create Pallets” is called a Splitter, and is available from the Object Palette.

In Object View (Ctrl+O), add the splitter, and add a multi-server.

Name them as above.

Set the capacity of Stage Pallets to a Portal Attribute (“Pallet Staging Capac” in this example).

Training multiserver capacity.png

Ensure the Stage Pallets Server limit is greater than what you think the maximum capacity might be.

Add an alternate portal exit, by clicking on the original portal exit and selecting "Add Alternate Exit".

Next, move to flow edit view (Ctrl+U).

You need to edit the path for the Vehicle Item as shown above.

Next, add a new Item Class called “Pallet”. (You can click in a blank tile of the Item Palette to do this)

Lay the Pallet Item path from the Splitter, through the Stage Pallets multi-server, and then to the alternate portal exit.

Now for Interactions.

Click on the Vehicle Item Class in the Item Palette.

Click on the Create Pallets splitter to display the “Splitter Schedule”.

Training splitter config.png

This is where you specify that when a Vehicle Item enters this splitter, the splitter will produce:

  1. Some Pallet Items
  2. One vehicle (which will be the incoming one).

Create a Portal Attribute called “Pallets per Vehicle” while editing this splitter schedule.

Ensure it has a view, and set its value to be 10.

This assumes that there will be 10 pallets unloaded per vehicle, for each and every vehicle, which we will work with for the time being.

From now on, every time a vehicle enters the splitter, 10 pallet items will be produced, followed by a truck.

NOTE that if the pallet items become blocked, so will the vehicle, and so will any other vehicle trying to enter the splitter.

Next we need to ensure that there is no time delay associated with the Pallet Staging multi-server.


Click on the Pallet item class in the Item Palette, and then click on the multi-server and set the interaction to zero. This effectively turns the Pallet Staging object into a queue. The advantage with using a multi-server is that we can manage its capacity via the portal attribute that sets its capacity.

You now need to move to the Main Screen.

Add a Portal Object and call it “Sorting”.

Training add sorter portal.png

Lay a path for the Pallet Item class between the Receiving Portal and the Sorting Portal.

Create a new Item Class called “Carton”.

Lay a path from the Sorting Portal to an Exit object obtained from the Object Palette.

This exit will be temporarily used until we are ready to link the system with the dispatch subsystem.

Now move inside the Sorting Portal to its subsystem.

In this subsystem, Pallets enter, and are unpacked in one or more lines. The unpacking process produces Cartons, which are loaded into the sorter, and the cartons will spend some time in the sorter before they leave it. The sorter has a capacity limitation, so once it is full, it will block the pallet unpacking process, which in turn will block back into the receiving subsystem.

Add objects and paths as follows:

Training basic sorter flow.png

The Portal Attributes to be defined are:

Pallet Unpack Lines Pallet Unpack Time
Cartons per Pallet Carton Sort Time Sorter Capacity

Once this editing is completed, add stats for and log those objects that will record occupancy.

  • Unpack Pallet
  • Sorter
  • Stage Pallets
  • Unload Truck

From this point, you will need to test the parameter values you want to assign to these areas.

Run the model and use the logs to look for any symptoms of congestion in the system, and to determine where the source(s) of congestion might be located.

If you discover congestion, try altering the parameters you think might need changing.

After you have achieved a system that is functioning, perform some arithmetic analysis of the demands and loadings and performance capability in each of the processes in these areas.

Determine if there might be any potential longer-term issues when considering the utilisation ratio, and the impact on system stability.

Implementing a Wrapping Facility

Now you can extend the processing of cartons beyond the sorting facility into the wrapping facility.

Save your Model as DC06, so you can review how you built up your model at a later date.

The activity of sorting produces cartons grouped ready for placing onto pallets. This is performed in the wrapping facility, where cartons are stacked on to pallets and wrapped, before being sent on to staging area or dispatch lanes.

In the wrapping subsystem, incoming cartons are randomly grouped together into Down Lane sets, and when the required number of cartons is detected, then a wrapper will collect them, spend some time to wrap them and then produce a pallet.

The number of down lane groups produced here is fixed at five, however a more flexible grouping mechanism could be implemented with more advanced modelling techniques.

The number of wrappers, and the average wrapping time is variable, so we will provide attributes to specify these parameters.

You will be adding a new Portal, to represent the Wrapping facility, and defining a new Item Class to perform the wrapping process, and which will operate as an ‘Agent’ in this part of the system.

This exercise introduces some more new Planimate® objects, the Switch, the PickUp and the Dispatcher.

Training wrapping flow.png

Once again, the performance parameters for this subsystem will need analysis and testing, by running the model and reviewing the logged results throughout the system and performing check calculations of rates and capacities.

Completing the Process - Delivery to Staging and Dispatch

In the final linking of the system end-to-end, we will be sending wrapped pallets either to the staging or dispatch subsystems.

The switches control where and how the pallets are directed as they emerge from Wrapping.

Training final dc layout.png

Inside Staging, we simulate some delays, and provide a capacity limitation.

If this system becomes blocked, it spreads back through the entire system.

Training final receipt layout.png

The Dispatch system is modified to collect those pallets that are available after a vehicle has spent its allotted time in the lane.

Training final dispatch layout.png