You are here:Home>Learning Center>User’s Guide>Chapter 3 – Model Elements>Chapter 3 – Section 5 & 6

User's guide chapter 3 section 5 & 6



Previous: Chapter 2 Next: Chapter 4

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.

Entity Arrivals

Common Tabs

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.

Action

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.

Properties dialog entity arrivals action tab ProcessModel software

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.

Name

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.

Properties dialog entity arrivals name tab ProcessModel software

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:

• Continuous
• Daily Pattern
• Ordered
• Periodic
• Scheduled

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.

Properties dialog entity arrivals continuous ProcessModel software

Important information to be aware of 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.

Daily pattern arrivals graph

Important information to be aware of 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.

Properties dialog entity arrivals daily pattern ProcessModel software

Properties dialog entity arrivals daily pattern ProcessModel software

As displayed after the pattern for Monday has been defined

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.

Important information to be aware of 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).

Properties dialog entity arrivals ordered ProcessModel software

Properties dialog entity arrivals ordered ProcessModel software

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.

Properties dialog entity arrivals periodic ProcessModel software

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.

Properties dialog entity arrivals scheduled ProcessModel software

Properties dialog entity arrivals scheduled ProcessModel software

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.

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

Cost

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.

Properties dialog entity routing cost ProcessModel software

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.

See Also To learn more about costs, see ProcessModel and Activity-based Costing.

Action

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.

Properties dialog entity routing action ProcessModel software

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.

Name

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.

Properties dialog entity routing name ProcessModel software

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.

Routing Types

The following routing types are available:

• Alternate
• Attach
• Conditional
• Create
• Detach
• Else
• Ordered
• Percentage
• Pickup
• Renege

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

Description

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).

Usage

Simple directional decisions based on no room at the destination are made with the alternate routing

Properties dialog entity routing alternate route ProcessModel software

Properties dialog entity routing alternate route ProcessModel software

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.

Caution An alternate routing may be used with the following routing types:

• Alternate
• Else
• Conditional
• Percentage
• Create
• Renege
• Detach

DO NOT use an alternate routing with an Attach , Ordered , or Pickup routing. Instead, use the Else routing with these signal activated routings.

Example

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.

Military aircraft example

Alternate routes are drawn by selecting the line connector tool Right Angle Line 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.

Description

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:

  1. The parent entity goes to the attach location and waits for the child entities to arrive and attach.
  2. 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.

Usage

• 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.

Properties dialog entity routing attach route ProcessModel software

Properties dialog entity routing attach route ProcessModel software

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.

Properties dialog entity routing create route ProcessModel software

Properties dialog entity routing create route ProcessModel software

Training orders are created using a variable quantity. See Chapter 3, Section , Common Distributions. Seventy percent of the time a need for Training will be created. For information on the create route see Chapter 3, Section 3.6.4, Create.

Properties dialog entity routing attach route ProcessModel software

With the quantity set to ALL and the Attach To set to entity that created it, all children created from this parent are required to be attached before the parent will be released to the next activity.

3.6.3 – Conditional

Description

A conditional route causes entities to choose a routing based on some condition (usually a name or other entity attribute). This is one of the most powerful and diverse routes available in ProcessModel.

Usage

• The name of an entity creates a need to process along a different set of activities. For example Calls are processed one way while Faxes are processed by different activities.

Properties dialog entity routing conditional route ProcessModel software

• The process routing changes based on the time of day. If it is before 10:00 PM then one route is followed, but between 10:00 PM and 6:00 AM another route is followed. This time based decision would require that the variable be changed to reflect the time of day. See “Creating User-Defined Variables” in Chapter 3.12.4.
• The process routing changes based how high a priority, how valuable, if the entity is over due or if it has already been down a route. These entity specific types of decisions would require the creation and assignment of an attribute. See “Creating User-Defined Attributes” in Chapter Chapter 3.12.3.
• The process routing changes based on the number of resources available in process alternatives. Making resource based decisions requires definition of resources and the use of Functions. See “FreeUnits(name of activity or resource)” in Chapter 3.11.1. Many other model parameters may be checked.
• In a job shop (production facility designed to manufacture a wide variety of products) the number of entities and the potential variation of routings can be overwhelming if conventional model building techniques are used. To simplify the building process, conditional routings may be used at each processing juncture. An attribute may be defined to correspond with each juncture. Instead of many entity types, one entity type can be defined with attributes that tell the entity which route to take at each juncture. Scheduled arrivals are defined with attributes so that the entity “knows” what path to take at each juncture. For more information on Scheduled Arrivals see Chapter 3, Section 3.5.5, Scheduled.

Move Time Time to move to the next activity or storage. Any expression is valid.

New Name Optionally assign a new name to the entity. This also assigns a new graphic to the entity if that graphic is defined as an entity on the layout.

An entity can be renamed using either the New Name drop down list in a routing Properties Dialog Box, or the NEWNAME statement in action logic. When renaming, all attributes from the original entity are inherited except the system created attributes ID and Name. The system created attributes which are inherited are Cost, CycleStart, and VATime.

Condition This is the condition for selecting this route (e.g Name = entity name). You may leave the field blank for a single unconditional routing which is equivalent to specifying a 100% routing. Complex expressions are also allowed using AND and OR operators (e.g. Att1 = 2 OR Att1 = 5). Any expression is valid. Valid comparison operators in conditional expressions are as follows:

= equal to
> greater than
< less than >= greater than or equal to
<= less than or equal to
<> not equal to
OR one of or both expressions
AND both expressions

Example

Insurance policies are treated differently if they are valued at less than $10,000. The process is different, expending less resources and time. When policies enter the system they have a field that contains the value of the policy. In ProcessModel this would be an entity attribute . In this example it was called a_Policy_Value. The conditional routes out of the decision are evaluated in the order draw. If the value of the attribute a_Policy_Value is less than or equal to 10000 then the top routing is chosen. If the value is greater than 10000 the bottom route is chosen.

Important information to be aware of If one or more Conditional routings are defined together, a conditional routing with the Condition field left blank may be used as a “last resort” routing. This Conditional routing must be the last routing connected to the activity. If none of the conditions in the other Conditional routings are satisfied, the entity will be routed along this “last resort” routing.

3.6.4 – Create

Description

A Create routing defines the creation of additional entities either before or after an activity. Created entities (such as a created order) can later be reattached to the creating entity or to some other entity by using the Attach or Pickup routing. To use an analogy, a Parent has a Child (create). The child is related to the parent and may be reunited with its unique parent at a later point in the model.

Most of the time a create route is in addition to a percentage route (the parent). If no percentage route is used with the create route, the creating entity exits the system.

The starting time for a created entity is when it is created not when the parent starts in the simulation.

This routing is often used with the attach routing (but it is not required) to form a closed loop “request and report back” system. Combined with the attach routing, the create routing forms a powerful combination with many uses in service, manufacturing and healthcare systems.

An example of the create routing follows: Phone orders are received by an Administrative group. After taking the order and entering the information into the system, the admin sends notification (create routings) of the order to Sales, Engineering and Accounting. Each of these groups has a part to play in assuring that the order is properly approved before the product can be released to production. The admin continues to work on the order (percentage routing) at the same time the other departments are completing their work.

In healthcare there are many examples of work completed in parallel with patient requirements (Lab, X-ray, Pharmacy, etc.).

In manufacturing, a create route can be used to initiate when elements of an assembly need to be started in the production area (combine with delays for different part types and resetting the cyclestart attribute).

 If you use a Create route to create a new entity, all user defined attributes are inherited as well as the system created ID attribute. However, all other system created attributes (Cost, CycleStart, Name, VATime) are not inherited.

Usage

• A customer order may have many separate parts that require parallel processing. For example an order may require a credit check from the finance department and a feasibility confirmation from engineering while the order is being processed. The create route is used to start all of the separate parts of the order. The attach route can be used to assure that the separate parts of the order are all accounted for before the order is completed. See “Attach” in Chapter 3.6.2.

Properties dialog entity routing create route ProcessModel software

Properties dialog entity routing create route ProcessModel software

• The quantity created can be controlled by an attribute on the parent. This technique is useful for the arrival of a truck that will “unload” a unique amount of entities. See “Attributes” in Chapter 3.12.3.

Create route example

Create route example

Create After Activity or Before Activity The new entity may be created and routed before or after the activity time and Action logic occur. If created before the activity, it may be reattached to the originating entity at the activity itself.

Move Time Time to move to the next activity or storage. Any expression is valid.

Quantity The quantity of entities to be created (0 – 9999). Any expression is valid and is evaluated each time a creation occurs. A value of zero causes the creation to be ignored. This means that creations can occur based on system conditions or entity attributes.

Created Entity Name The name of the newly created entity. To define a different graphic for this new entity, place a new entity object for it on the layout (it does not need to be connected to another object).

Conditional Create

When it is necessary to create only part of the time, an attribute can be used to carry the create quantity. That attribute is then placed in the quantity field of the create dialog.

When the creating entity reaches the point where the create occurs, then the attribute is read and the value placed in the quantity field. If the value is zero then no entity is created. If the value in the attribute is greater than zero, then that number will be created.

3.6.5 – Detach

Description

A Detach routing causes entities that have been attached to the current entity to be detached and routed to the connected activity.

More Information

A detach route can be used disassemble entities that have been previously assembled or to unload entities previously loaded (with an attach routing in the current model).

A detach route is almost always used in conjunction with a percentage routing so that the base or carrying entity has a place to go. If no percentage routing is drawn from the same activity as the detach then the carrying entity will exit the system.

You may not connect more than one Detach routing from the same activity, but you can detach all entities then add a storage and then separate entities using conditional routings.

After detaching, the parent entity’s attributes remain with the parent. In addition, any attributes assigned while the entities were attached remain with the parent. The detached child will retain any attributes it had prior to the attach. They will not inherit attributes assigned to the attached group of entities.

Usage

• Any time statistics are needed for items that have been previously attached use the detach at the end of the model.

Properties dialog entity routing detach route ProcessModel software

Properties dialog entity routing detach route ProcessModel software

• A bus route has people loading the bus (Attach route) and people unloading (Detach route) at predetermined stops. An attribute can be used to tag individuals. This tag is later used in the detach routing to signal them to leave the bus. See “Attributes” in Chapter 3.12.3.

Properties dialog entity routing detach ProcessModel software

Move Time Time required to move to the next activity or storage. Any expression is valid.

Detach After Activity or Before Activity The entity may be detached before or after the activity. Detaching before the activity allows the detached entity to be reattached as part of the same activity.

Condition An optional condition to be satisfied for detaching entities that are to use this routing. This allows multiple detach routings to be defined with different conditions. This could be used to detach and route specific entities (previously attached) to specific destinations.

Important information to be aware of You may only connect one Detach routing to a process step. If you specify a condition for the detach, only the entities matching that condition will be detached and follow that route. If the condition field is left blank, all attached entities will detach and follow the detach route.

Detach Child and Parent Separately

Since there is no route defined for the parent entity to use, it exits the model at that activity. In order to see the parent entity leave the activity, add a 100% exit route from the activity, in addition to the detach route. The child entities will leave on the detach route and the parent entity will leave on the 100% route.

Before or After the Activity on a Detach Route

The terms Before or After the activity when using a Detach route refer to the activity from where the route originates (the non-arrow head end of the route). If you detach Before the activity, all attached entities will be detached, be released to leave for the next activity and then the carrier entity will execute it’s processing time. If you detach After the activity, all attached entities enter the activity as a single unit. They then detach after the activity time has been executed.

Detaching Children and Grandchildren

In a detach route, the Detach needs to be done in levels. If you create and then attach entities at multiple levels (parent creating children, and children creating grandchildren, then attaching each entity back to their respective parent) you must use a separate detach route for each “generation” of child entities. You must also detach in the proper order; detach the most recently attached child entities, then detach the next most previous attached entities. In addition, the activity hosting the detach route for the grandchild entities (on the upstream end of the detach route) must have an input queue.

Combining Detach Route with other Route Types

You cannot combine Detach and Conditional routes. The only routing type you can combine with a Detach route is a 100% route. If you want to route each type of entity in the attached group to a different location, you must do it as a separate step after the detach has occurred. Leaving the Condition field blank on the Detach route will route “all” attached child entities down the Detach route. You could then use Conditional routes at a subsequent activity (following the Detach route) to route the child entities appropriately. If you enter a Condition on the Detach route, then only the entities matching that condition will be routed down the Detach route. All other child entities will remain attached to the parent entity, and go down the 100% route. If no 100% route is used in conjunction with the Detach route, the parent, and any remaining attached entities will exit the model immediately. In version 5 and above, Conditional routed can be combined with Detach. That being said, the conditional route would be for the base entity (parent entity) and not for the detached entity.

3.6.6 – Else

Description

An Else routing is executed if none of the one or more Attach , Pickup , or Ordered routings with which it is associated can be executed. An analogy might help to explain how the Else route would work in conjunction with an Attach route. An understanding of the attach route is important before this analogy will make sense. If the main entity is the Parent and the attaching entity is the Child then the Else route would tell the child what to do if the Parent didn’t show up. The Child arrives at the activity that has the attach route and looks for a corresponding parent at the destination. If the Parent has not yet arrived, then the Child follows the Else route. The Else route in conjunction with the Pickup route allows for the Parent to leave if the Child is not ready when the Parent arrives.

Else route example

Only one Else routing may be defined from an activity or storage having Attach, Pickup, or Ordered routings. However, an Else routing may have an alternate routing attached to it, which effectively allows for multiple Else routings.

If the Else routing is unable to be executed because of insufficient capacity at the next activity, the first of all the routings that can be satisfied is executed. For example, if an activity has two Attach routings and an Else routing connected from it, and neither of the Attach routings have an entity waiting for an attaching entity, then the Else routing will be executed if capacity is available. If capacity is unavailable, the entity waits for the first routing that can be executed.

Usage

Else Routing with a Group of Attach Routings

If no entity is waiting at the connecting activities for this entity to be attached, the entity will be routed via the Else route.

Else Routing with a Group of Attach Routings

Else Routing with a Group of Ordered Routings

If no order signal has been given, the entity will be routed via the Else route.

Else Routing with a Group of Ordered Routings

Else Routing with a Group of Pickup Routings

If no entities are waiting to be picked up at the destination activity or storage, the entity doing the picking up will be routed via the Else route.

Else Routing with a Group of Pickup Routings

Else Routing with a Group of Pickup Routings

Move Time Time to move to the next activity or storage. Any expression is valid.

Caution DO NOT use an Else routing with an Alternate, Conditional, Detach, Else, Percentage, or Renege routing. Doing so will cause an error to occur when you run the simulation.

3.6.7 – Ordered

Description

An ordered routing causes the routing entity to wait until an order signal is received (see Order Signals). Entities will wait in the output queue of the activity (or in the storage) from which the Ordered routing is connected until the Order Signal is received. If you want to continue processing entities behind the entity waiting for an order signal, make sure the capacity of the output queue or storage is sufficient.

Usage

• Just-in-time systems require that production inventory is controlled. The Ordered route in conjunction with the Order Signal allow the control of when and how much is ordered from an upstream activity.

Ordered routing in process improvement

Ordered routing in process improvement

Move Time Time to move to the next activity or storage. Any expression is valid.

3.6.8 – Percentage

Description

The Percentage routing causes a specified percentage of the output entities to be routed to the connected activity or storage. Multiple percentage routes can be defined from an activity. If capacity is unavailable at the connected activity or storage, the entity waits until capacity becomes available before moving.

Usage

• Single routes from one activity to another default to Percentage. That is to say that 100% of the time they will move from the current process to the next.

• Simple decisions that cause an entity to follow a yes or no path based on a percentage.

• Decisions involving more than two outcomes that are selected by percentage. The result of the decision is the route that is selected.

• Tagging entities with specific information a percentage of the time. For example 10% of the parts could be marked as high priority by setting an attribute in the action tab of the entities that traversed the 10% percentage route. See “Attributes” in Chapter 3.12.3 and also See “Action Logic” in Chapter.3.11.

Percentage routing in process improvement

Percentage routing in process improvement

Move Time Time to move to the next activity or storage. Any expression is valid.

Percent The percentage of output entities using this routing. The total percentage for multiple percentage routings must total 100% (If you have only two percentage routings from one activity or storage, ProcessModel automatically balances the percentage fields to equal 100%). Decimal fraction values (e.g. 25.5) may be entered. Only constant values are valid here.

New Name Optionally assign a new name to the entity. Statistics for the output report will be reported under this new name. This also assigns a new graphic to the entity if that graphic is defined as an entity on the layout.

An entity can be renamed using either the New Name drop down list in a routing Properties Dialog Box, or the NEWNAME statement in action logic. When renaming, all attributes from the original entity are inherited except the system created attributes ID and Name. The system created attributes which are inherited are Cost, CycleStart, and VATime.

Important information to be aware of To develop a percentage route that changes for each entity type, use conditional routes and set the condition in the action tab of the activity. See “Conditional” in Chapter 3.6.3 and see “Action Logic” in Chapter.3.11.

3.6.9 – Pickup

Description

The pickup routing functions the same as the attach routing except that the controlling entity retrieves the attached entity instead of having the entity sent to it. To continue the analogy of the Parent and Child, in a Pickup routing, the Child notifies the Parent that it is ready to be picked up. The Parent then moves along the pickup route. after the Parent arrives at the destination the Child is joined to the Parent. The key difference between this route and the Attach is that the Parent must stay behind the Pickup route until requested and yet still perform as the entity that reports statistics in the output report.

A pickup route causes the routing entity to move to the activity when an entity to be picked up enters the input queue of the activity. The entity being picked up is attached to the entity having the pickup routing. The pickup action takes place prior to any activity time defined.

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 Pickup Routes:

  1. The parent entity must wait on the upstream side of the Pickup route until the child gets to the pickup location’s input queue. The child then requests the parent to come and pick it up.
  2. Since there is no quantity field on a Pickup route, only one child entity can be picked up by a parent entity.

Usage

• At a fast food restaurant the Parent or main entity places the order (create route). The Parent entity the goes to the waiting area. The Child entity is the order and is processed behind the scene. When the Child (order) is ready the Parent (customer) is notified (pickup route) and comes to claim the order.

Pickup routing in process improvement

Pickup routing in process improvement

Move Time Time to move to the next activity or storage. Any expression is valid.

Pick up any entity / Pick up created entity Choose whether each entity is to pick up any entity waiting for pickup or its own created entity (i.e. an entity which was created from it).

Important information to be aware of To collect statistics on any entity that has been attached to another entity, it must be detached prior to exiting the model.

Caution If you use resource connections at the destination of the Pickup routing to capture resources, the resources will be assigned to the entity being picked up, and you will not be able to free that resource until the entity that is picked up has been detached. In other words, the resource will be trapped. To assign a resource to the entity doing the pickup, so that it will not be trapped, use the GET or JOINTLYGET statements in Action logic rather than resource connections. See “Action Logic” in Chapter.3.11.

3.6.10 – Renege

Description

The Renege routing is used to cause entities (usually customers) to be routed to another activity or out of the system if they have not started the activity before a specified amount of time has expired. This phenomenon of dropping out of the waiting queue is referred to as reneging or abandonment. The entity will exit the system if you do not connect the routing to another activity or storage. An activity with a renege routing must have an input queue size of one or more.

Usage

• Customers tire of waiting in line or on hold and leave.

• If a customer problem is not handled in the required time, the problem is escalated (renege route) to another process.

• Material waiting processing has an expiration time (such as glue strips or oxygen absorption pads). If the expiration time has lapsed, then the expired material must be removed.

Renege routing in process improvement

Renege routing in process improvement

Move time Time to move to the next activity or storage. Any expression is valid.

Renege after The maximum time that an entity will wait for available capacity at the activity before reneging. If capacity becomes available in the activity before the renege time has expired, the entity will not renege, so any additional time spent waiting to capture a resource before beginning the activity is not considered. Any expression is valid.

New Name Optionally assign a new name to the entity. This also assigns a new graphic to the entity if that graphic is defined as an entity on the layout. Assigning a new name is a way to cause separate statistics to be gathered for the entities that actually renege.

An entity can be renamed using either the New Name drop down list in a routing Properties Dialog Box, or the NEWNAME statement in action logic. When renaming, all attributes from the original entity are inherited except the system created attributes ID and Name. The system created attributes which are inherited are Cost, CycleStart, and VATime.

If the renege time is based on entity type, you can make a prior assignment of the renege time to an attribute and reference it in the Renege after field.

If a resource is connected to the activity from which reneging takes place, be sure that the resource is always available to avoid waiting additional time to get the resource. You can do this by making the resource dedicated to the activity or by selecting Respond immediately in the resource assignment connection’s properties dialog. In other words, if there is room to move out of the input queue, but a resource is required but not available, the entity will not be able to renege (it is already committed to move forward).

Remember that a renege only happens from the input queue. If the entity has already moved to the capacity area of the activity, then it can’t renege.

Once an entity has either entered an activity’s capacity or determined that it -will- enter the capacity, the renege will no longer have any effect on that entity. For example, if you get and free your resources in action logic (rather than with a connector line), the entity must enter the activity before it knows whether a resource is available or not. Therefore, if the resource is not available and the entity must wait “in” the activity for the resource longer than the specified renege time, the renege will have no affect on that waiting entity since it has already entered the activity.