Resources often undergo routine adjustments or changes, and the effects of such adjustments often last for a limited period of time. Examples are a truck in routine maintenance, a worker on lunch break, and adding salespeople for a weekend or a holiday shopping season.

The scheduling of a resource adjustment often needs to address the following issues:

In Simulation Studio, resource scheduling is supported by the Resource Agenda and Resource Scheduler blocks together. The Resource Agenda block is used to address the first issue listed above and the Resource Scheduler block addresses the other issues.

Resource adjustments are often related and happen in an orderly fashion. In Simulation Studio, related adjustment actions can be grouped together. A special type of value object called a Resource Agenda defines a sequence of related resource adjustment actions based on a relative simulation time starting at time zero. Each resource adjustment action includes a change to either the resource capacity value or the resource state value in targeted resource entities over certain time period; it is defined as a resource agenda entry. The Resource Agenda block provides a resource agenda to describe what kind of resource adjustments to make during a simulation run.

The Resource Scheduler block accepts and stores resource agenda objects during a simulation run. This block also accepts scheduling requests to perform resource adjustments. The resource agendas are later activated and processed by the Resource Scheduler block as specified by scheduling requests. Such a request tells the Resource Scheduler about the resource agenda to use for resource adjustments and how to deal with the second through last issues in the preceding list. After a resource agenda is activated, its entries are activated and processed sequentially. A scheduling request is fulfilled when all entries in the specified resource agenda are processed and all associated resource adjustments are actually completed.

There are two ways to provide a request to the Resource Scheduler block: statically or dynamically. A static request can be entered at the design or modeling time as an appointment by using the Appointments tab of the Resource Scheduler block properties dialog box. (See Figure 9.9.) At simulation time, appointments are processed as the initial requests by the Resource Scheduler block.

After an unrepeatable request is processed and all associated adjustments are completed, the request is discarded by the Resource Scheduler block. If a request is repeatable, the Resource Scheduler block sends a resource schedule entity out the OutRequest port to represent the request to be used again later. If the request is an appointment, the Resource Scheduler block creates the resource schedule entity based on the appointment. Later, these resource schedule entities can be submitted to a Resource Scheduler block through its InRequest port as dynamic requests. Before being submitted back to the Resource Scheduler block, these resource schedule entities can be processed (delayed, modified, counted, stored, and so on) to simulate complicated scheduling situations.

Sometimes, the contents of the resource agenda entries in a resource agenda are fixed and can be specified completely at the design time. Yet at other times, the duration or capacity changes of some adjustment action are not fixed or cannot be specified in the corresponding resource agenda entries at the design time. For example, the downtime or duration of a machine failure is not fixed but follows a certain statistical distribution (such as a normal distribution). In Simulation Studio, the numeric contents (such as duration, units, and units offset) of a resource agenda entry can be left unspecified or blank. Such an agenda entry is called a dynamic agenda entry. The Resource Agenda block populates the unspecified values by pulling these values dynamically though the InDuration or InValue input ports during the simulation. The desired values can be created through submodels that are connected to these input ports.

The rule of the “immediate actions” in a scheduling request enables the Resource Scheduler block to address the fourth through sixth issues in the preceding list. When a resource agenda entry is activated, the Resource Scheduler block performs the appropriate immediate actions as specified by the rule without any delay. The resource entities are usually either unseized in resource storage blocks or seized by controlling entities. The seized resources are busy and in use. The unseized and functional resources are free to be allocated upon requested. Usually, the seized resource entities are not adjusted before they become unseized and free. Otherwise, the resource adjustment is preemptive if it decreases the capacity or switches to a nonfunctional state. When the state value of unseized resources is changed to nonfunctional, these resources cannot participate in resource allocation until they become functional again. Therefore, the adjustment is disruptive to these resources.

Currently, when permitted by the specification of a resource adjustment request, the Resource Scheduler block uses several heuristics to process the request. For an increase of capacity, the Resource Scheduler block divides the increased units evenly among targets it deems suitable. For a decrease of capacity, the block tries to decrease as much capacity as possible from a first targeted resource before moving to the next target, and so on. In general, the Resource Scheduler block always attempts to finish processing a resource agenda entry in less simulation time without preemptive changes. For capacity changes, the Resource Scheduler block adjusts the currently unseized resources first. This “unseized first” heuristic decreases the waiting time for the seized resources to become unseized and avoids unnecessary preemptive adjustments. When the merging/splitting units option is enabled on a Resource Pool block, the first entrant of compatible resource entities always remains inside the Resource Pool block even when its resource capacity reaches zero after splittings. Therefore, the “unseized first” heuristic might result in capacity changes to the resource entities in the Resource Pool blocks being more likely than elsewhere, which makes it easier to model inventory replenishment situations in some simulations.

Usually the entries in a resource agenda are related, and a succeeding entry cannot be processed unless the preceding entries are finished. For this kind of temporally constrained situation, the Resource Scheduler block should not advance the agenda to process its next entry if the current entry is not completed. The actual simulation time period to finish the whole resource agenda can be much longer than the sum of the original duration values specified in the agenda entries. Choose the option to advance the agenda to the next entry if the resource agenda entries in the agenda are not temporally constrained, which might result in a shorter processing time for the resource agenda.

Choose to adjust the currently unseized resources immediately if the adjustment is intended to change free resources without any delay. This is useful in many modeling situations. Examples include increasing inventory levels immediately at all inactive warehouses, or putting all trucks currently in the garage under routine maintenance.

If you choose not to adjust currently unseized resource immediately, the Resource Scheduler block adjusts these resource later, after all the currently seized resources become unseized. This is useful in the situation where all or most of the resources need to be gathered before they can be adjusted at the same time collectively.

Choose to adjust the currently seized resources immediately if adjustment is preemptive and the seized resources need to be deallocated from their current controlling entities for further processing or different allocation.

For more information about the functionality of the Resource Agenda and Resource Scheduler blocks, see Appendix A: Templates.