User's guide chapter 3 section 1 & 2



Previous: Chapter 2Next: Chapter 4

Chapter 3 – Model Elements

Model Elements chart

3.1 – Data Entry Rules for Names & Numbers

ProcessModel requires names and numbers to be entered following some simple rules. You should be familiar with these conventions to ensure that valid entries are made in your model.

Names

Using descriptive, but short, names is recommended. The name you enter in the properties dialog for a resource, for instance, could be used in Action logic. If the name is too long and cumbersome, entering the logic statements could become tedious. If the name is too short or cryptic, you may not remember what it is later. However, you are free to adopt your own naming convention within the limits of the following rules:

• All letters are case insensitive (“A” is the same as “a”).
• Only the letters A through Z (upper or lower case), the digits (0-9) and the underscores “_” may be used. No other symbols or characters may be used in ProcessModel names.
• Names must begin with a letter of the alphabet or an underscore “_”. (e.g. Item5 or _Item5, but NOT 3_Item).
• Names must be single words (use underscores “_” for spaces).
• DO NOT use hyphens, e.g., High-Color would be invalid.

If no name is assigned to an object, a default name will be assigned. Some words are reserved, using one of these words will result in an underscore being appended to the name.

Numbers

When entering numbers as a constant or within an expression, you should follow these rules:

• Do NOT use commas. The number 2,984.43 should be entered as 2984.43.
• Enter negative numbers using the dash (e.g.-345.23, not (345.23) or )

All values, such as quantity and time values, may be expressed as a number such as 23.5 or 9.25.

3.2 – Entities

Entities are the items or people being processed—e.g., products, documents, customers, etc. An entity is defined by selecting an entity shape from the shape palette, placing it on the layout, and entering any applicable information for that object in the properties dialog.

Entities are represented by graphics you choose from the palette. They will be shown as moving graphics during the process simulation. Using meaningful graphics in the model to represent entities in your real system will allow others to accurately visualize the flow through the process. They are processed at activities and are moved on routings from activity to activity. Entities can have an initial cost and collect additional costs from processing at activities, movement on routings and from the use of resources. There are hundreds of predefined entities in ProcessModel from all major industries.

Any ProcessModel graphic can be used as an entity (activity, resource, storage, link, label). To use a non entity graphic as an entity, double-click on the graphic and change the object type to Entity.

Each pre-defined entity graphic is assigned a number by ProcessModel. These numbers are used only for the NewGraphic statement (see NEWGRAPHIC).

Important information to be aware of ProcessModel contains several predefined entity shapes. Each predefined entity shape has the word ‘entity’ placed in parentheses in the shape name. However, you may also define custom entity shapes.

3.2.1 – General

Properties dialog general processmodel software

Name The name of the entity (e.g. Customer, Product_A, etc.). The entity name is used primarily for decision making and reporting purposes. It is simply a descriptive attribute that may be changed during the simulation and tested for making process decisions. Entity statistics are reported based on the final name of the entity.

Important information to be aware of When you add an additional text label to an entity, place the label on the center of the entity. Otherwise, the entity will appear smaller during simulation.

Statistics: Yes / No This selection determines whether statistical information will be collected, displayed in the scoreboard, and reported in the Output Module for this entity.

 The maximum number of entities that can be displayed in the simulation scoreboard is 12. That number cannot be modified.

Object Type Allows the type of object to be changed from Entity to something else.

3.2.2 – Cost

The identification of cost is optional and has no effect on the behavior of the model.

Properties dialog cost processmodel software

Initial cost The initial value assigned as the cost of each newly created entity (negative 1,000,000 to 1,000,000). Once assigned, the entity cost may be increased automatically during the simulation based on waiting time, activity time, and resource usage. This cost is added to the pre-defined Cost attribute of the entity.

Waiting cost The cost that is added to the entity per hour of waiting time. Cost may range from negative 1,000,000 to 1,000,000. This cost is added to the pre-defined Cost attribute of the entity.

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

User's guide chapter 3 section 3 & 4



Previous: Chapter 2 Next: Chapter 4

3.3 – Activities

Activities are the tasks performed on entities—e.g., assembly, document approval or customer checkout. An activity is defined in terms of the activity time as well as any resource requirements. User-defined action logic may also be specified for an activity. Activities have a processing capacity and may have input and output queues associated with them. Resources connected to an activity are captured before the activity takes place and freed after it has ended.

3.3.1 – General

Properties dialog activity general ProcessModel software

Name The name of the activity (e.g. CheckIn).

Capacity The maximum number of entities (1 – 999,999) that can be processed concurrently (either individually or in batch). Scenario Parameters may be used in place of numeric values. INF may be used to represent the largest numeric value allowed (999,999).

Stats on This check box allows you to turn off statistics collection for individual activities in your model. By default, this option remains checked.

Time The time to perform the activity. Any expression including distributions, attributes, or variables may be entered as the time value. If a resource is connected to the activity, the resource is captured before the time is taken. Activity times may also be defined using TIME statements in the Action section of the dialog.

 If an entity is spending more time than expected at an activity where you are using action logic, you likely have time on the General tab AND in a TIME statement in your action logic. If you use a TIME statement in action logic, you should typically set the time on the General tab to 0. Otherwise you will first execute the time in the action logic. Then the time on the General tab will be executed. Thus your two time settings add together.

Input Queue Cap. The capacity of the input queue. The input queue is like a waiting area. If the input queue has available capacity, entities may be routed into it to wait until the activity has available capacity to process the entity. If the queue has no available capacity, entities must wait at the previous activity (or in that activity’s output queue) until capacity becomes available in the input queue or the activity (0–999,999). Scenario Parameters may be used in place of numeric values.

Output Queue Cap. The capacity of the output queue. The output queue is like a waiting area where entities will wait for available capacity at the intended destination (0–999,999). Scenario Parameters may be used in place of numeric values.

Object Type Allows the type of the object to be changed to something other than an activity. For instance, you may want to change an activity object into a storage or resource.

3.3.2 – Batching

The batching tab allows you to hold entities in queue until a specified quantity is reached. For example, parts might be held in front of a heat treating oven until a specified quantity is reached. The group of part is moved into the oven and the entire batch is heat treated for a specific time. The batch is then moved out of the oven. This batching is performed to increase the efficiency of an expensive resource allowing it cycle only when it has a full load.

When the batch is created in the input queue, one entity is moved into the capacity for processing (the batch). The processing time will be for the batch. If the batch is created in the output queue, then the routing time will be for one entity (again the batch).

A basic explanation of how ProcessModel works may prove helpful. When the batch quantity is reached, all entities are then attached to a new entity (the batch). You may change graphics, set attributes, accumulate cost and assign resources to the new entity. Recognize you are making assignments to the new entity. If the batch is unbatched, the batch entity goes away and the attached entities are removed from the batch and continue on. VA Time accumulated as a batch will be divided among the unbatched entities. Cost added to the batch will also divide to the unbatched entities.

If a resource is assigned (Get) to an entity prior batching, the resource will be trapped in the batch. If you have less resources than the quantity of the batch, the models will be unable to process the request to get the next resource and entities will stop at the Get statement. If a resource is assigned to a batch and is unbatched before the resource is released (Free), the resource will be transferred to the first exiting entity from the batch.

When and unbatch occurs, entities will exit the batch in the same order as they entered the batch.

A batch can consist of other batches. When unbatching, only one level of batch is unbatched at a time.

It is possible to accomplish many other types of batching. For example you could

1. Batch at the end of a shift regardless of quantity – see the model object “short batches”

2. Batch all waiting entities – see the model object “all waiting entities at a specific time”

3. Produce separate batches for different entities — see the model object “group similar entity types”

4. Batch based on multiple criteria — see the model object “smaller quantity because the batch was open too long”

 The batch will assume the name of the last ENTITY entering the batch. For example, if you had Car and Truck ENTITIES being batched together, and Truck was the last ENTITY to enter the batch, then the batch name would be Truck, regardless of how many of each ENTITY type were contained within the batch.

 Attaching is just creating a batch. So if a batch was -not- created after an attach operation, and you then unbatch, the attached child entities will be detached. However, unbatching should not be used as a detaching method because of the following; When forming a batch, a temporary entity is created and the batching entities grouped together with it. When you unbatch, that temporary entity is destroyed. Therefore, if you unbatch a group of “attached” entities, the parent entity will be destroyed and the child entities will detach and move downstream in the model.

Properties dialog activity batching ProcessModel software

Before Activity

None No batching occurs before the activity. (No Batch Size field appears.)
Batch The activity will batch or group incoming entities (whether or not the entities have already been batched) and process them as a batch. The number batched is defined by the Batch Size field.

Important information to be aware of An input queue with a capacity that meets or exceeds the maximum batch size is required.

Important information to be aware of An Attribute may be used in the Batch Size field to set the number to be batched. The specified batch quantity is evaluated each time an entity is batched. If the entity attribute is less than or equal to the number already waiting to be batched, the batch is formed (with possibly a new size) and released for processing. This allows the specified batch quantity to vary if desirable. It also allows for the creation of short batches.

Unbatch The activity unbatches or ungroups the incoming entity (if the entity has not been batched, the unbatching is ignored) and processes each entity individually.

Rebatch The activity will batch or group the same number of entities back together that were unbatched previously. This means you don’t have to know how many entities were previously unbatched in order to rebatch them—no batch size is required.

Important information to be aware of An input queue with a capacity that meets or exceeds the maximum batch size is required.

After Activity

• None No batching occurs after the activity. (No Batch Size field appears.)
• Batch The activity will batch or group entities (whether or not the entities have already been batched) after the activity has completed processing. The number batched is defined by the Batch Size field.

Important information to be aware of An output queue with a capacity that meets or exceeds the maximum batch size is required.

• Unbatch The activity unbatches or ungroups entities after the activity has completed processing. If the entity has not been batched, the unbatching is ignored. No output queue capacity is required, but without sufficient capacity downstream, processing could be delayed while the unbatching occurs.
• Rebatch The activity will batch or group the same number of entities back together that were unbatched previously or arrived in quantities greater than one (in which case the quantity batched is the quantity of the arrival). This means you don’t have to know how many entities were previously unbatched in order to rebatch them—no batch size is required.

Important information to be aware of An output queue with a capacity that meets or exceeds the maximum batch size is required.

Batch Size Determines the number of entities to be included in each batch. (Used only when batching entities.) An Attribute may be used in the Batch Size field to set the number to be batched. The specified batch quantity is evaluated each time an entity is batched. If the entity attribute is less than or equal to the number already waiting to be batched, then batch is formed (with possibly a new size) and released for processing. This allows the specified batch quantity to vary if desirable. It also allows for the creation of “short batches,” or batches that formed early before the normal size is achieved.

Important information to be aware of Before using batching, consider that your batch may just as easily be modeled as a single entity (see Section 10.3.8, Job Shop Scheduling Opens in a new page). Also, remember that batching may require an input queue or output queue. Follow the directions on the properties dialog. If a queue is needed, make sure it has sufficient capacity to hold an equal or greater number of entities than the expected maximum batch size. Also note that all batches or groups are unbatched when the batched entity exits the model in order to complete statistics collection on each entity. However, if a batch or group has had an entity attached to it during the simulation, ProcessModel will not unbatch that particular batch (or any groups within that batch).

Variable Batch Size

Existing “in process” batch sizes change when variable batch sizes change.

First some definitions. A batch is a group of items that will be processed at one time. In ProcessModel when a number is entered into the Batch Size field, all processing at that activity will stop until the batch size is met. That means that a batch could wait for hour or even days for the batch to reach the specified size. Changing the batch sizes allows the modeler to have control over what to do if the batch size isn’t met and yet the batch still needs to close. For example: at Quest Diagnostics human samples are processed within predefined response times. The economic order size is to process 24 at one time , but when the end of the day arrives and the economic order quantity has not been reached, the order must still be closed even if there is only one specimen in the batch. These undersized batches are called Short Batches.

An entity needs to enter the batching location to trigger the review of the batch size. In other words you can’t cause the release of a batch by simply changing a variable, but the next entity to enter will cause the review of the batch size.

The entities waiting to be batched don’t know anything about the batch size value. They are always released into the batch when the number of waiting entities equals or is greater than the “current” batch size.

For example, suppose your initial batch size is 10 and you have 5 entities waiting to be batched. Then your batch size changes to 6 AND a new entity enters the batching activity. Those 5 waiting entities will be released into the batch as soon as one more entity arrives. They will not wait for a batch quantity of 10.

When Variable Batch Sizes Change

Sometimes a batch size is controlled by an attribute on the entity arriving at the batching location and other times by a variable. Use the method that best suites your needs. See the model object Batching \ Short Batches for an example of how to change the batch size.

3.3.3 – Action

Develop customized behavior for entities at an activity. In addition to the information set in the General tab of the activities properties dialog, logic can be developed to report statistics, control 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 activity action ProcessModel software

Action logic is processed when the entity enters the Capacity of an activity, and then entities also process the time entered on the General tab. For this reason, when action logic is used, often a TIME statement is included in the action logic and the General tab time is set to 0.

Action logic does not occur in the Input Queue of an activity. If a situation requires action logic in the input queue, see the model object “Flow control – action logic in the input queue”

For additional information see Section 3.11, Action Logic.

3.3.4 – Cost

The cost tab provides a method of adding cost to each entity as it moves through the process. The cost tab also provides a means for classifying how time is accounted at the activity (VA, NVA, BVA). Other costs may be added by the usage of resources (see section 3.4.3 Resource Costs), routings (see section 3.6 Entity Routing Costs) and the initial costs of an entity (see section 3.2.2 Entity Costs).

The identification of cost is optional and has no effect on the behavior of the model.

Properties dialog activity cost ProcessModel software

Hourly cost Cost added to each entity per hour of time spent performing this activity. Cost values may range from negative 1,000,000 to 1,000,000. Idle time, while waiting for resources, is not counted. This cost is added to the pre-defined Cost attribute of the entity being processed.

Activity cost Cost added to each entity completing this activity. This cost is added to the pre-defined Cost attribute of the entity being processed.

Important information to be aware of If costs are entered as a negative number and final completed production is entered as a positive then a net revenue number can be obtained from the Summary Report. See “Output Summary Reports Opens in a new page” in Chapter 6.2.

Important information to be aware of Resource cost must be a number. Expressions, attributes, variables, or scenario parameters are not allowed.

See Also To learn more about costs, see ProcessModel and Activity-based Costing Opens in a new page.

VA Time How the time for each entity completing this activity is categorized. As an entity is processed its total time in the system will be divided into three categories Value Added, Non-Value Added and Book Value Added. This allows an accurate accounting of how much of the total process time adds value from

VA — Value Added – Time for those work elements that transform the product or service in a way the customer is willing to pay for.

Value adding (VA Time) activities are those which must be done in order to meet the customer’s requirements. Without these activities, the customer wouldn’t get their desired output. To be a value added action the action must meet all three of the following criteria:

1. Necessary to meet customer requirements.

2. Required for or assists in the production of the product or service.

3. Represents an output that the customer is willing to pay for.

Value added time is calculated by summing the entity VA Time. If the VA type is set to BVA Time (Business Value Added) the time in the activity will be associated to another category. Otherwise all entity time is calculated as NVA Time (non value adding).

It’s not always easy to identify which of the three types an activity is. If you don’t understand customer requirements, spotting Real VA will be difficult. Book/Business Value Added is almost always the most contentious to identify. People will tell you “but we have to do that”, usually for reasons lost in time. Perhaps there was once an audit requirement to carry out a check at a step in the process, but does it apply now? Maybe there was a National Standard that stated an activity had to be done, but is it still required? The biggest challenges, in most public sector processes will be: “why are there so many checks, inspections and approvals required?” What value do they really add and can they be eliminated?

NVA — Non-value Added – Adding Time for those work elements that are not used to transform the product or service in a way the customer is willing to pay for.

Non Value Added activities are waste! They don’t contribute to the customer’s requirements and don’t need to be performed. Non value added time is characterized by the following:

1. If eliminated, would not impact the product or service to the customer.

2. Creates waste, extra time, rework.

3. Is performed because of inefficiency elsewhere within the process.

4. Represents a equivalent effort to other activities or adds unneeded steps to the process.

Non value added time is applied to an entity when an entity is in the capacity of an activity AND the VA Type is set to NVA Time.

NVA time is also accumulated when an entity:

* Travels on a route

* Sits in storage

* Waits in an input queue

* Is held by a Wait Until statement

NVA Time is calculated by summing the time an entity spends in the above 5 identified areas. Activities are classified from the customer’s point of view meaning that the value of each action in the process is determined by whether it adds value from the customer perspective—value added—or does not add value from the customer perspective—non-value added. Steps that are required but irrelevant from the customer perspective represent a final classification—business-value added.

BVA — Book-value Added – Time for those work elements that are required to stay in business. Often government required steps will be classified as BVA.

Important information to be aware of The time that an entity spends in the Input queue, Output queue or in route is Non-Value Added.

3.3.5 – Shift

Properties dialog activity shift ProcessModel software

Shift file The name of the shift file which defines the times when this activity can be performed. A default shift file for all activities may be defined in the Options dialog under the Simulation menu.

Browse Allows you to search through one or more directories to locate a shift file.

Interrupt current activity to go off shift or on break Check this option if the current activity is to be interrupted in order to go off shift or on break. If not checked, the shift will interrupt the activity only after it has completed processing the current entity.

Create shift file Opens the shift editor for defining a shift and saving it as an.SFT file. For more information, see Section 3.10.1, Shift Definition.

 Shift with breaks; The breaks are not included in the scheduled hours reported in the Output report. Example: If you have an 8 hour shift with 1 hour of downtime for breaks and lunch, the Schedules Hours would show 7 hours for a 24 hour simulation run length or 35 hours for a 5 day run length.

3.3.6 – Submodel

The submodel tab (shown below) allows you to reference a subprocess chart when you are creating hierarchical models. All activities have a submodel tab in their properties dialog. For more information, see Chapter 7, Hierarchical Modeling.

Properties dialog activity submodel ProcessModel software

Subchart If the activity is to be linked to a subprocess, enter the name of the subchart file defining the subprocess.

Simulate subchart If a subchart is defined, it may be ignored for a particular run by unchecking this option. If checked, information defined for the activity is ignored as control drops to the subchart.

Activate If a subchart is defined, that chart will be opened. If a new name is entered into the Subchart field a new blank model will be created and activated.

 Submodel tab will not show on 50 object licenses.

3.4 – Resources

See Basics 9 – Representing People and Equipment — Resources video tutorial.

Resources are the agents used to perform activities and move entities such as service personnel, operators or equipment. More than one unit of a particular resource may be defined if they are used interchangeably and have the same operating characteristics. Resources may be shared between several activities. If no resource is assigned to an activity, it is assumed that no resource is required.

Resource in ProcessModel simulation software

3.4.1 – General

Properties dialog resource general ProcessModel software

Name The name of the resource (e.g. Worker).

Quantity The number of units of this resource type (1 – 9999). Scenario parameters may also be used. The quantity value is read only once at the beginning of the simulation so using values which change during a simulation (such as variables) cannot be used.

If scenario parameters are used in a resource quantity field, no indicator lights will be displayed during simulation. The only way to have indicator lights show during simulation is to use a numeric value in the resource’s quantity field. The maximum number of indicator lights during simulation for any resource is 12.

Object Type Allows the type of object to be changed from Resource to something else.

3.4.2 – Availability

Properties dialog resource availability ProcessModel software

Percent Available Enter the percentage of time the resource is to be available for use. If a percent is entered that is less than 100, interruptions will occur randomly and last for times that are also random with an average time of five minutes. Any expression excluding attributes is valid.

Time Available As an alternative to entering a percent availability, you may define availability in terms of Time between interruptions and the Interruption time, both of which may be defined as probability distributions or any other expression excluding attributes. Another way to look at this would be Mean Time To Failure (MTTF) and Mean Time To Repair (MTTR).

 The length of time a resource is unavailable is randomly determined. But the average break in availability will be approximately 5 minutes.

 A resource availability can be changed using a variable as the percentage, in the availability tab of the properties dialog. The following rules apply, assuming there is at least one change during simulation. 1. No value can be greater than 99%. Example: 100 & 10 will not work. 2. One of the values has to be less than 90%. Example: 99 & 89. 3. If one of the values is greater than 90% the other value can not be less than 10% of the first value. Example: 99 & 9. 4. Both values can be less than 90%. Example: 50 & 80.

3.4.3 – Cost

The identification of cost is optional and has no effect on the behavior of the model.

Properties dialog resource cost ProcessModel software

Important information to be aware of If costs are entered as a negative number and final completed production is entered as a positive then a net revenue value for the process can be obtained from the Summary Report.

Important information to be aware of Resource cost must be a number. Expressions, attributes, variables, or scenario parameters are not allowed.

Hourly cost Cost per hour for using this resource. This cost (negative 1,000,000 to 1,000,000) is added to the pre-defined Cost attribute of the entity using the resource.

Cost per use Cost each time the resource is used. This cost (negative 1,000,000 to1,000,000) is added to the predefined Cost attribute of the entity using the resource.

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

3.4.4 – Shift

Properties dialog resource shift ProcessModel software

Shift file The name of the shift file which defines the times during which this resource is scheduled to be available. If different units of the same resource have a different schedule, they should be defined as separate resource types (e.g. Shift1_operators, Shift2_operators).

Important information to be aware of A default shift file for all resources may be defined in the Options dialog under the Simulation menu.

Browse Allows you to search through one or more directories to locate a shift file.

Interrupt current activity to go off shift or on break Check this option if the current use of the resource is to be interrupted in order to go off shift or on break. If not checked, the priority is 99 which is the highest non-interruptive priority.

 If an entity is being worked on when it’s resource goes off-shift, the entity will wait at the activity until that same resource comes back on shift. The only way to get the entity to be passed to the next shift coming on-line is to use action logic. There is a model object in the ProcessModel software that demonstrates how to make that occur. It is under the category Shifts \ Release Entity To Next Shift.

Create shift file Opens the shift editor for defining a shift and saving it as an.SFT file. See Section 3.10.1, Shift Definition.

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.

User's guide chapter 3 section 7 & 8



Previous: Chapter 2 Next: Chapter 4

3.7 – Resource Assignments

Resource assignments define the use of one or more resources in performing an activity or moving an entity. For each entity that is processed or moved, each assigned resource is captured and held until it is freed via the resource connection or a FREE statement in Action logic. While the resource is captured, it is not available for use by other activities or routing connections. To be pulled away from a task the resource is performing, it must be interrupted by a resource assignment that has the Respond immediately box checked.

Resources may be captured for performing an activity or a move. They may also be freed or kept after the activity or move is completed. Multiple or alternative resources may be used for an activity or move.

A connected resource is always captured BEFORE any defined activity or move time and freed AFTER an activity or move time. If an input queue is defined for an activity, the connected resource is captured prior to the entity entering the activity. If no input queue is defined, the entity enters the activity and then captures the resource. Multiple resources required for an activity or routing are not captured until they are all available. To capture multiple resources as each becomes available, use a GET statement in the Action logic of the activity or routing.

Assignment Types

Following is an explanation of each type of resource assignment and the information in its properties dialog.

• Get and Free
• Get
• Free
• Alternate

Using Multiple Resources

You may use multiple resources and mix the resource connection types. You can mix multiple and alternate resources. When defining multiple resource connections, remember that they are executed in the order in which they were defined. To change that order, disconnect the resource connections and reattach them in the order you desire.

Resource Priority Values

There are 10 levels of priority values: 0 – 99, 100 – 199, 200 – 299 . . . 900 – 999. 0 – 99 is the only non-preemptive level.

Preemption means that the current work being done by a resource will be interrupted in order for the resource to go to the location of the preemptive GET. After that higher priority work is complete, the resource will return to the interrupted location. Preemption will occur only when the value of the calling priority is at least one level higher than the resource’s current priority.

The calling priority is at least 100 higher than the resource’s current priority.

For example, if a resource is working at a priority of 50, then a priority call of 150 will be required to perform a preemption. The 150 GET will be completed before returning to the initial 50 GET.

Using a priority which is 300 or higher will bring a down (or off shift) resource back on-line (or on shift).

Resource Priority, Shifts, and Interrupt

The Resource priorities, interrupt, shifts, and ‘Interrupt current activity to go off shift or on break’ can be used in a model together, the following restrictions apply.

  1. A resource priority of more than 100 is an interrupt priority, meaning that if a resource is working on a task that has a lesser priority the resource will leave that task and start working on the priority that is 100 or more.
  2. If the resource priority is less than 100, but it is higher than the other task the resource is working on, the resource will not leave the task its working on, but will complete it and then come to work on the task with greater priority.
  3. If ‘Interrupt current activity to go off shift or on break’ is checked on shift of the resource, this will mean that the ‘Interrupt current activity to go off shift or on break’ has a priority of 299. The resource will leave any task its working on and go offline.
  4. An interrupt priority that is used to have the resource leave the task its working on, and start working on another task will work with ‘Interrupt current activity to go off shift or on break’ if the priority is set to less than 199.
  5. An interrupt priority of greater than 199 will keep a resource online, even if its scheduled to go offline and ‘Interrupt current activity to go off shift or on break’ is checked.
  6. An interrupt priority of greater than 599 will bring back an offline resource online, even if its offline and ‘Interrupt current activity to go off shift or on break’ is checked.

3.7.1 – Get and Free

The Get and Free resource connection allows you to use the resource for the duration of the activity or move, and once the activity or move is complete, the resource is freed.

Get and free connector route

Get and free connector route

Quantity The number of units of this resource that are required. Any expression is valid.

Priority Enter the priority (0 – 99) for responding to this activity. Higher values have higher priorities. A priority is only necessary if the resource is assigned to multiple tasks that may be competing for the services of the resource.

Respond immediately Check this box if the resource is to interrupt any other activity in order to respond immediately to this activity. This selection is only meaningful if the resource is assigned to multiple tasks. (A resource that is off shift or on break will not respond until back on duty by this request.)

3.7.2 – Get

The Get resource connection allows you to get the resource and hold it until you explicitly free it later using a Free resource connection or FREE statement in Action logic.

Get resource connector route

Get resource connector route

Quantity The number of units of this resource that are required. Any expression is valid. You may leave this field blank or enter 0 if the actual getting of the resource is done explicitly in the Action logic of the activity or routing. In this case, the connection serves only as a graphic representation of the resource being used.

Priority Enter the priority (0 – 99) for responding to this activity. Higher values have higher priorities. A priority is only necessary if the resource is assigned to multiple tasks that may be competing for the services of the resource.

Respond immediately Check this box if the resource is to interrupt any other activity in order to respond immediately to this activity. This selection is only meaningful if the resource is assigned to multiple tasks. (A resource that is off shift or on break will not respond until back on duty by this request.)

3.7.3 – Free

The Free resource connection frees a resource that was previously captured using the Get resource connection. If you attempt to free a resource that has not been captured, the Free connection is simply ignored.

Free resource connector route

Free resource connector route

Quantity The number of units of this resource to be freed. Any expression is valid.

3.7.4 – Alternate

To use a resource as an alternate to another resource, connect the alternate resource to the other resource’s assignment connection as shown in the illustration below. If the resource units of the connection to which it is attached are unavailable, the alternate resource will be used. If neither one is available, the first available resource will be used.

Alternate resource connector route

Alternate resource connector route

Alternate to an Alternate

To define an alternate resource for an alternate resource, simply connect the resource to the other alternate connection as shown below. No more than one alternate may be connected to another resource connection so that the order of preference in selecting resources is clear. To define multiple alternate resources, simply continue connecting an alternate resource to each previously connected alternate resource.

Alternate to an Alternate resource connector route

Alternate to a Get Connection

When an alternate resource is connected to a Get resource connection as shown in the following illustration, the resulting captured resource must be freed with either a Free resource connection or a FREE statement in Action logic.

Alternate to a Get Connection resource connector route

Since you cannot know which resource will be captured when assigning resources as alternates to a Get resource connection, you must create a Free resource connection for every possible resource as shown above. Doing this will free the resource that was captured and ProcessModel will ignore the other Free resource connections. See “FREE” in Chapter 3.11.2 for the use of FREE ALL in action logic.

Alternate Resources On Different Shifts

Define an alternate resource on a different shift in the same manner as the alternate descriptions provided above. Assign each resource type to the appropriate shift. See “Defining & Editing Shift & Break Blocks” in Chapter 3.10.1. If a resource is off shift, a check will be made to see if the alternate is available.

3.8 – Order Signals

An Order Signal is a connection from an activity or storage to an Ordered arrival or routing which notifies the arrival or routing to order or release additional entities. The signal is triggered by a drop in inventory level at the storage or activity input queue.

Order Signals route

Order Signals route

Reorder Level The level to which the storage or activity input queue must drop before signaling an order for more entities. Any expression is valid.

Order Quantity The quantity to order when an order is placed. Any expression is valid.

Place order at start Check if an initial order is to be placed at the beginning of the simulation run. If the initial order is insufficient to raise the queue or storage level above the reorder level, a Periodic arrival should be defined, in addition to the Ordered arrival, with its First time field set at time zero (0) to initialize the inventory level (see Periodic).

Important information to be aware of When an order signal is used to order entities at an arrival connection (the Order Signal is connected to an arrival connection), the arrival type must be Ordered . To learn more, see Ordered.

Important information to be aware of For ordering to continue, the inventory level must rise above the reorder point. If your system functions so that inventory trickles in and never allows the quantity to rise above the reorder point, another method of re-ordering entities must be used. For an alternate ordering method multiple capabilities in ProcessModel will be required. Continuous along with WAIT UNTIL.

User's guide chapter 3 section 9 & 10



Previous: Chapter 2 Next: Chapter 4

3.9 – Storages

Storages are waiting areas, stock places, etc. where entities can wait for further processing. Storages are useful when controlling the order in which entities are allowed to move on through the model. Since an activity provides the option to have a built-in input and output queue, a storage is for visual purposes or to model special queuing conditions such as multiple activities sharing a common input queue.

Explaining Storages

3.9.1 – General

General tab on properties dialog for storage

Name The name of the storage (e.g. StockRoom ).

Capacity The maximum number of entities that can occupy this storage (1 – 999,999). Scenario Paramenters may also be used in this field.

Queuing order The order in which entities are queued to leave the storage: none, first-in first-out, last-in first-out.

None Entities that have completed their Action Logic are free to process any routing logic independent from other entities that have finished their Action Logic. Will process FIFO if no other routing requirements are enforced (i.e. Conditional Routes, Get with a priority, etc.).

First In, First Out (FIFO) — The first entity completing its Action Logic must be routed first.

Last In, First Out (LIFO) — The last entity completing its Action Logic must be routed first.

Object Type Allows the type of object to be changed from Storage to something else.

3.9.2 – Action

Action tab on properties dialog for storage

Action Develop customized behavior for entities at an storage. Logic can be developed to report statistics, control 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. For additional information see Section 3.11, Action Logic.

3.10 – Schedules—Shifts & Breaks

3.10.1 – Shift Definition

Weekly shifts and breaks for activities and resources are defined using the Shift editor and may start and end at any minute of the day. Defining shifts for resources and activities in a model is only necessary when there are activities or resources with different work schedules. Otherwise the simulation can be run for a single block of time as though there was no off-shift time.

Shifts and breaks are defined by blocking out sections of time on a grid divided into days and hours. Once a weekly shift and break schedule has been defined, it may be saved in a shift file, which has an.SFT extension. This allows you to use the shift definition in models you create later.

Creating shifts in ProcessModel Shift Definition

This screen shot of the Shift Editor shows a shift defined to begin at 8 a.m. and end at 4:30 p.m. with two short breaks and a lunch break.

If the shift file opens blank but the model simulates correctly, make sure the file path is shorter than 255 characters.

 The shift file in a resource’s Shift tab can not be changed as conditions change in the simulation. Each resource can only have 1 shift for the entire simulation run. An attribute, variable, or scenario parameter can however be checked in the action logic. Then based on that parameter’s value, The appropriate resource with the desired shift can be selected.

How To – Open the Shift Editor

1. Open the Options dialog from the Simulation menu and click on the Files tab.

or…

Click on the Shift tab of the properties dialog when a resource or activity is selected.

2. Click on the Create Shift File button.

Shift Editor

The Shift editor consists of a menu bar, Shift and Break mode buttons, time control buttons, and a grid representing one week of time. (All shown on the previous page.)

The remainder of this section describes the Shift Editor menus and the following procedures:

• Drawing a Block of Time for a Shift or Break
• Selecting a Block
• Resizing a Block
• Editing the Begin or End Time
• Deleting a Block
• Duplicating a Specific Day’s Shift
• Customizing Shift and Break Colors

Shift Editor Menus

The menus used in the Shift editor are accessible from the menu bar at the top of the editor and include the following:

File For opening shift files and saving open shift files.

Edit For deleting unwanted shift and break blocks. You may also duplicate a specific day of the shift. If you delete a shift, it deletes the shift as well as the breaks in the shift.

View For access to status and tool bars.

Options For customizing the colors which represent shifts and breaks.

Defining & Editing Shift & Break Blocks

You define a shift by selecting the Shift tool and drawing a shift block for each day that is to represent time on the shift. The break block tool can then be selected to draw break blocks over any portion of the defined shift. A break differs from off-shift time in that if a resource or activity is busy when a break time is scheduled to occur, the duration of the break time remains unchanged even if it could not immediately take effect. Off-shift time, in contrast, is reduced by any delay in going off shift, i.e., the activity comes back on shift at the scheduled time regardless of any delay in going off shift. This behavior typifies most real world situations.

When drawing a shift or break block, you must be sure to follow these rules:

• Shift blocks may not overlap with other shift blocks.
• Break blocks may only be drawn on top of shift blocks.
• Break blocks may not overlap or be adjacent to other break blocks.

How To – Draw a block

1. Click on the Shift or Break button to designate the type of block.