It is important to understand that when a location or resource goes off shift, it is essentially down. We call this type of downtime a shift downtime and it is treated slightly differently from other downtimes. Breaks, which are also part of the shift schedule, are treated exactly like clock-based downtimes. These downtimes are discussed in Locations and Resources.
All location shift downtimes have a default priority of 99, the highest non-preemptive priority possible. This means that when a location is scheduled to go off-shift, this downtime will take priority over all other entities with a priority less than 99 waiting for the location. If the location is currently in use, shift downtimes allow the current entity to complete its process at the location. After the entity is finished, the shift downtime proceeds as if it started at its scheduled time. This means that the location becomes available at the start of the next shift regardless of when it actually went off shift. This procedure is demonstrated in the following example.
Although the downtime is scheduled to last from time T2 to T4, the actual downtime does not begin until time T3. This is what happens for both locations and resources currently busy when the shift downtime is scheduled to occur.
To preempt a location in which an entity is currently processing, set the priority for going off shift to a number one level higher than the entity’s priority.
Please Note: Since the entity was preempted, the remaining time for the entity to be processed at the location was completed after the location shift downtime was completed.
An off-shift location may be preempted back into service by an entity. Following the preemption, the shift downtime will resume for any remaining time before the start of the next shift. The following example demonstrates this principle.
In this example an entity with priority of 200 or greater preempts an off-shift location. The location becomes available to process the entity. Once processing is complete, the location returns to its off-shift status.
In order for an entity to preempt any location downtime (shift or otherwise), it must have a priority level that is at least 2 levels higher than the downtime's priority. In this example the location shift downtime has a priority level of 99 so the entity must have a priority level of 200 or greater to preempt the shift.
If a preemptive clock downtime occurs during a shift downtime, the downtimes simply overlap.
This example shows the effect of a preemptive downtime occurring for a location already off-shift due to a shift downtime. Because location downtimes always overlap, the effect is as if the preemptive downtime never occurred. The location remains off-shift for the total duration of the shift downtime.
The example above could represent the situation where a recurring downtime, such as a lunch or dinner break, has been defined for a single location that is scheduled to be available for a two-shift period. It would be simpler to specify a single downtime for lunch and dinner that occurs once every 8 hours continuously than to define separate downtimes for lunch and dinner. In this case the preempting downtime would represent a meal break occurring while the location was off-shift.
Resource shift downtimes work exactly like location shift downtimes with the exception that if the off-shift downtime is preempted by some other downtime, the original off-shift downtime never resumes. The following examples show how a resource that is off shift is affected by a preemptive request by another entity (example 1) and by downtime preemption (example 2).
Suppose a resource, repairman, is off-shift. An important machine goes down unexpectedly. Because this machine is a bottleneck in the operation, it is vital to repair the machine as quickly as possible. The repairman is called in and takes 30 minutes to fix the machine. The logic for the downtime to call him back is “USE Repairman, 600 FOR 30 min”. This will preempt the shift downtime and use the repairman to repair the machine even though the repairman is off-shift. Once the repairman has repaired the machine, he returns to his shift downtime until he is scheduled to go back on shift. The repairman's shift downtime will end at the originally scheduled time regardless of the fact it was preempted by a repair activity.
Although the shift downtime is scheduled to last from time T1 to T4, the actual downtime lasts from T1 to T2 and then from T3 to T4.
This example shows the effect of a preemptive downtime occurring for a resource already off-shift due to a shift downtime. Since resource downtimes are not overlapping, as in the case of location downtimes, the shift downtime in progress is discontinued and the preemptive downtime takes control of the resource because it has a priority greater than or equal to five-hundred (remember that a downtime priority needs to be only one level higher than another downtime priority to preempt it). The effect in this example is that the total downtime is actually shorter than it would have been had the original shift downtime been completed.
Although in practice, situations like the example above are unlikely to occur, it is important to understand that the above condition is possible. Typically, preemptive downtimes are due only to some type of location or resource failure, in which case, the downtime occurrence would be based on usage and not clock time. If a preemptive downtime is based on usage, the situation in the example above could not occur because the location or resource would not be in use, and would not accumulate usage time.
|
© 2012 ProModel Corporation • 556 East Technology Avenue • Orem, UT 84097 • Support: 888-776-6633 • www.promodel.com |