3.5 – Entity Arrivals
Arrival connections define how entities enter the system to begin processing. Entity arrivals are defined by connecting an entity object to an activity or storage object and then entering any defining information in the properties dialog for the connection. Multiple arrival connections can be created from an entity to one or more activities or storages.
There are two common tabs on the properties dialog for arrivals: Action and Name. These tabs are explained in this section first followed by a description of each type of arrival.
Assign custom behavior to a model when entities arrive in the model. In addition to the arrival information set in the General tab of the arrival properties dialog, assignment statements and IF…THEN statements can reference user-defined entity attributes as well as predefined attributes and variables.
Action logic is processed at the instant the entity is created but before entering any activity. To learn more about Action Logic, see Section 3.11, Action Logic.
The Name tab (shown below) allows you to define route names when you are linking hierarchical models. All arrival connections have a Name tab in their properties dialog. For more information, see Chapter 7, Hierarchical Modeling.
Connection name This name is used when mapping connections between different charts (main model and submodel). For hierarchical modeling only. See “Connection Naming” in Chapter 7.3.3.
Entity Arrival Types
Following is a description of each type of arrival that can be defined. To change the arrival type, select the desired type from the Type option under the General tab of the Arrival properties dialog. The following types are available:
• Daily Pattern
3.5.1 – Continuous
A continuous arrival causes entities to continuously feed the connected activity whenever processing capacity is available at the activity; any activity input queue is ignored. This type of an arrival should only connect to activities and requires no other information to be defined.
You should be aware of the following operating constraints when using the Continuous arrival:
• DO NOT bring other arrivals into the same activity or storage to which the Continuous arrival is attached.
• Since the input queue is ignored when using the Continuous arrival, any batching activity set to occur before the activity will be ignored as well.
3.5.2 – Daily Pattern
A daily pattern arrival shows the rate at which entities arrive for different time periods during the day. Arrivals are assumed to occur randomly within each period. The pattern for each day of the week can be different from the others.
If a shift file has been defined for the activity where entities arrive, it is a good idea to synchronize the arrival periods with the activity schedule.
Day The list of days of the week. A pattern may be defined for each day.
Start – End, Quantity The list of period entries showing the start time, end time, and quantity of entities to arrive during that period for the day currently selected.
Copy day Button to copy a day’s pattern in order to paste it later on another day. Prevents tedium of entering the same periods for each day of the week that has the same arrival pattern.
Paste day Once a day has been copied, the Paste button becomes active and lists the name of the day that will be copied in the button itself. Select another day in the Day list and press the button to paste the pattern into the new day.
New Creates a new period entry in the Start – End, Quantity list with default times and quantity. The order of the new entry in the list will automatically be adjusted to maintain a chronological list.
Delete Removes an arrival period from the list.
Start time The start time edit field for the currently selected period.
End time The end time edit field for the currently selected period.
Quantity The quantity edit field for the currently selected period. Any valid expression may be used.
Time entries for a Daily Pattern many not overlap (Correct example: Monday 8:00-9:00, 9:00-10:00. Incorrect example: Monday 8:00-9:00, 8:30-9:30 — these time slots overlap).
How To – Define a daily pattern
1. Click on the Define Pattern button to display the Daily Pattern dialog.
2. Click the New button to create a new entry in the pattern dialog. This creates the Monday 8:00am – 9:00am, 1 default entry. (The quantity and times may be changed as desired.)
3. Repeat step 2 for each time period to be defined in which arrivals occur.
4. Once a particular day’s pattern has been defined, you can copy the pattern to another day by selecting the defined day, clicking on the Copy day button, then selecting the day to which the pattern will be copied and clicking the Paste button. (The name of the weekday appears on the Paste button, so you will know which day is being copied.)
A Note About Time
When you use the Daily Pattern arrival or Scheduled Arrival, you must understand that statistics, especially resource statistics, may be affected due to the way the clock works in ProcessModel. Each ProcessModel simulation begins at 12:00 a.m. (midnight) on Monday morning of the first week. Therefore, Daily Pattern or Scheduled arrivals may skew statistical results, especially with regard to resource and input and output queue utilization. The solution is the use of Shifts in conjunction with your Daily Pattern or Scheduled arrivals. For more information see Schedules—Shifts & Breaks.
3.5.3 – Ordered
An ordered arrival is used in connection with an order signal connection to place an order for more entities to arrive (see Section 3.8, Order Signals).
Lead Time This is the time required for the entities to arrive once an order is placed. Any expression excluding attributes is valid.
3.5.4 – Periodic
A periodic arrival causes entities to arrive at repeating time intervals. It is also useful for initializing inventory levels at the beginning of the simulation. This is done by entering a time of zero (0) in the Repeat Every field.
Repeat every The time between arrivals. Any expression excluding attributes is valid. A time value of zero (0) will cause only one entry for this arrival.
Quantity per arrival The number of entities that arrive after each time interval. Any expression excluding attributes is valid.
First time The time (relative to the beginning of the simulation) that the first arrival should occur. Use a time of zero (0) to initialize the model with entities at the beginning of the simulation.
The maximum amount of time that can be entered in the First Time field of a Periodic arrival is 35,791 hours. If a larger value is entered, the arrival will occur as the simulation starts rather than at the designated time.
3.5.5 – Scheduled
A scheduled arrival causes a quantity of entities to arrive at a storage or activity at set times such as appointments or incoming shipments. Multiple scheduled arrivals for the same time occur in the order in which they are defined.
Arrivals [Time, Quantity] The list of defined arrivals listing the quantity, the week number, the day of the week, and the time the arrivals begin to come into the system.
New This button allows you to create a new arrival based on the data held currently in the edit fields of the dialog.
Delete Allows you to delete the selected entry from the Arrival list.
Week This is the week in the simulation when the arrivals are to occur (numbered from 1 in ascending order).
Day This is the day of the week on which the entities are to arrive.
Time This is the time of day that the arrival occurs. If more than one arrival is scheduled for the same time, the arrivals will occur in the order in which they were defined.
Quantity The number of entities to arrive at the scheduled time.
Action Although not required, you may enter Action logic for each scheduled arrival. This is useful for assigning a value or descriptor to an attribute at the time of arrival based on the particular arrival entry in the dialog. Select the arrival in the Arrivals list above and enter the logic in the Action text box. To learn more see Action Logic.
How To – Define an arrival schedule
1. Click on the Define Schedule button to display the Scheduled Arrivals dialog. A default arrival is automatically created as shown on the previous page.
2. To create an additional arrival click on the New button. (Edits to the quantity and time fields are updated to the currently selected arrival once you move to another field or press New.)
How To – Read in an arrival schedule from outside files
1. Create scheduled arrivals with a quantity of zero for the number of arrivals anticipated.
2. From the Tools menu select Export Data. Export the data to the chosen application.
3. Open the exported file. Modify the Excel or Access File by adjusting the desired parameters and save.
4. Press the file import button to import the changed data into ProcessModel.
A Note About Time
When you use the Daily Pattern arrival or Scheduled Arrival, you must understand that statistics, especially resource statistics, may be affected due to the way the clock works in ProcessModel. Each ProcessModel simulation begins at 12:00 a.m. (midnight) on Monday morning of the first week. Therefore, Daily Pattern or Scheduled arrivals may skew statistical results, especially with regard to resource and input and output queue utilization. The solution is the use of Shifts in conjunction with your Daily Pattern or Scheduled arrivals. For more information, see Schedules—Shifts & Breaks.
The maximum number of weeks allowed for scheduled arrivals is 213.
3.6 – Entity Routings
See Basics 5 – The Logic of the Flow video tutorial.
Entity routings define direction and conditions for the flow for entities. An entity routing is defined by connecting activities and storages to depict the direction and sequence of flow. An activity or storage may have multiple input routing connections and multiple output routing connections. Entities do not move to the next activity or storage until there is available capacity and the condition or rule for routing the entity has been satisfied.
If resources are connected to the routing, they are captured after the entity has been cleared to move to the next activity and freed after the move time has elapsed.
The General properties tab allows you to select the type of routing and set certain information specific to that type of routing. Then each routing dialog consists of three tabbed sheets on which you can define information about the routing. The Cost tab allows you to define cost data, and the Action tab allows you to define specific actions to take place prior to the move. The Name tab allows you to route entities to and from submodels. Since the Cost, Action, and Name tabs are common for all routings, they are defined first in this section.
Common Properties Tabs
ProcessModel allows you to assign a cost to the routing of an entity from one activity or storage to the other. The cost is added to the pre-defined Cost attribute of the entity in the model after the move is completed.
All routing connections have a cost tab in their properties dialog. The identification of cost is optional and has no effect on the behavior of the model.
Cost per move The cost added to each entity after completing a particular routing. This cost (negative1,000,000 to 1,000,000) is added to the pre-defined Cost attribute of the entity being moved.
To learn more about costs, see ProcessModel and Activity-based Costing.
Develop customized behavior for entities that follow this route. In addition to the information set in the General tab of the routing properties dialog, logic can be developed to report statistics, control movement or processing, collect information and a host of other items. Variables, entity attributes, systems information and if-then statements allow expansive capabilities to be accessed from the action tab.
A routing’s Action Logic is processed when the condition for routing to the next activity (activity or storage) has been satisfied and any resources have been captured to make the move but before the actual move takes place. You may think of this logic as exit logic or logic processed just prior to exiting the activity. For additional information see Action Logic.
The linkage tab (shown below) allows you to define connection names used when you are creating hierarchical models. For more information, see Chapter 7, Hierarchical Modeling.
Connection name This is used to map connections into and out of the activity that represents the submodel. A connection going into this activity will route the entity to a like named connection in the submodel. A connection coming from this activity receives entities from the submodel’s like-named connections.
The following routing types are available:
And they are explained in detail on the following pages.
Routing Execution Order
When you use multiple routings from an activity, the order in which they were created or connected to the originating activity is the same order in which ProcessModel will consider each routing connection to determine which routing the entity will take.
The order in which routings are created is usually only important when you create more than one of the same routing type from the same activity or storage. For instance, you want to pick up an entity from one of two activities. If an entity is waiting at activity one, it should be picked up. The entity waiting at activity two should only be considered if activity one has no entity waiting. To model this, the Pickup routing should be connected to activity one first.
Changing Execution Order
The order in which ProcessModel considers routing connections can be changed by disconnecting the routings from the originating activity and then reconnecting them in the order you want them to be considered.
3.6.1 – Alternate
An alternate routing is executed if the destination for its primary routing has no capacity for additional entities. The alternate routing is created when you connect a line from a routing (the primary routing) to the alternate destination as illustrated below.
If capacity is unavailable at the alternate destination, the entity is routed to the first destination with available capacity. DO NOT attach more than one alternate to any routing so that it is always clear which routing is the alternate. However, an alternate routing may itself have an alternate routing; as many alternate routings as needed may be defined.
Action logic on a route will only be executed when an entity actually traverses that route. Therefore, in an alternate routing situation, action logic on the primary route will not be executed if the entity selects the alternate route. However, if a resource “connector line” is attached to the primary route, and the resource is not available, entities will be blocked from selecting either the primary or the alternate route. When a resource connector line is used, the resource must be available before any other actions can occur on the object’s capacity (route, activity, or storage).
Simple directional decisions based on no room at the destination are made with the alternate routing
Type Any routing connected from another routing must be an alternate, so this field cannot be changed.
Move Time This allows you to specify a different move time for the alternate routing. Any expression is valid.
An alternate routing may be used with the following routing types:
DO NOT use an alternate routing with an Attach , Ordered , or Pickup routing. Instead, use the Else routing with these signal activated routings.
Military aircraft land for refueling and are directed to a series of hydrants (which is the fastest method of refueling). If all of the hydrants are full then the aircraft is diverted to a series of large fuel bladders. If all of the fuel bladders are being used the aircraft is sent to a parking spot where trucks fuel the aircraft. Refueling by truck is the slowest method of refueling and thus selected only when the other options are not available.
Alternate routes are drawn by selecting the line connector tool and drawing from an existing route to a destination activity or storage.
3.6.2 – Attach
See Standard Assembly video tutorial.
See Conditional Assembly video tutorial.
An Attach route causes the routing entity to be attached to an entity waiting at the destination activity or storage. The presence of another entity (routed from a different routing) at the destination signals the attach routing to occur. The other entity at the destination activity or storage is detained until the attachment occurs.
To use an analogy, the Parent (or main entity) requests a Child to join it (Attach). The Child stays put (before the attach routing) until a parent requests it. The Child then travels the attach routing and becomes part of the Parent. The Child is carried by the parent, unless specifically Detached. See Detach.
The attach action takes place prior to any activity time defined at the destination activity
If you don’t want to hold up processing entities that are behind the entity waiting to be attached, define an output queue with sufficient capacity.
After an Attach or Pickup has occurred, the attributes of the parent entity are the only attributes recognized by the system. The child’s attributes are masked until a detach occurs. To pass a child’s attributes to the parent when attaching or picking up, you must assign the child attribute to a variable. Then after the attach/pickup, assign that variable to a parent’s attribute.
Properties of Attach Routes:
- The parent entity goes to the attach location and waits for the child entities to arrive and attach.
- You can attach multiple children to the parent by using a number, variable, attribute, scenario parameter, or the word ALL in the attach route’s quantity field.
• The attach routing is the primary method of assembling entities. A Parent or main entity is the base and the attach (s) is (are) the subcomponent (s). The assembly will not move to the next activity until the subcomponent is attached.
• When the attach is coupled with the create route it acts to hold the further processing of the main entity until all of the child entities related to that parent have been attached. An order may create all of it’s components at the start of a model and then hold the order until all of the components are completed and attached.
Move Time Time to move to the next activity or storage. Any expression is valid.
Quantity The quantity of entities to be attached. If you wish to attach every entity waiting in the input queue of the activity where the attaching takes place, enter ALL . Any expression is valid. A quantity of zero results in no attachment.
Attach to Choose whether the entity is to be attached to any entity (for general assembly) or to the entity that created it (for re-attachment to the entity that Created it).
To collect statistics on any entity that has been attached to another entity, it must be Detached prior to exiting the model.
To attach all the children created by a parent, set the Quantity to ALL and the Attach To to entity that created it. This means that if some parent entities created no children, then none will be attached, while parent entities that created many entities will require all of those entities to be attached before moving to the next activity.
If the entity requesting the attach has an attribute that describes the quantity to be attached and that same attribute is used in the quantity field of the attach route, then attaching is controlled by the attribute. If the attribute of the requesting entity is set to zero, no entities are attached. If the attribute of the requesting entity is set to five then five entities will be attached. If the requesting entity carries several attributes then options of a complex assembly can be handled. At each station where assembly takes place, the corresponding attribute will determine the number of parts assembled.
Example Suppose that a software order can generate two possible options in addition to its own processing. The first option is inclusion of training which happens 70 percent of the time. The second option is inclusion of one day of consulting which happens 30 percent of the time. If the options are included, additional work needs to be completed in parallel with the order and then be inserted into the order before the shipment is released to the customer. In some instances neither training or consulting will be included. In other instances both training and consulting will be needed. In either case if something was created, it must be attached and if nothing was created the order should not be delayed.