Defines either maintenance, repairs, or any other kind of activity that differs from the usual activity of the resources defined by the ResourcePool block.
You can schedule the recurrent downtime activities either through different types of triggers or with the help of the AnyLogic Schedule element. You can also customize the moment of the first occurrence for this activity.
If you define several triggers for the first occurrence, then the first of them to fire will initiate the countdown for the triggers that define the period of recurrence for this activity, provided that you have specified them.
If you don't define any triggers for the first occurrence and only specify the recurrence period, the first occurrence will take place when the specified period runs out. E.g., if you define the cycle of 50 working hours, the first downtime will take place once the resource has accumulated the 50 working hours from the start of the model run and will repeat with the same frequency until you stop the simulation.
A set of resources may have multiple tasks with different priorities and preemption policies.
- If all tasks have the same priority, they will be executed in the usual way following their occurrence schedule. If there are enough resource units available, tasks can be executed simultaneously. If two tasks have the same priority, but one of them was suspended for some reason, this suspended task will be picked1.
- If you have configured no preemption policy for the tasks, these tasks will be executed one after another following their occurrence schedule. If there are enough resource units available, tasks can be executed simultaneously.
- The occurrence of one task does not reset the priorities for other tasks.
1 Each resource unit may receive requests from different sources. When a single resource unit receives multiple tasks, suspended and new, with identical priority values, some rules apply to the picking order:
-
The suspended tasks from the individual queue of the resource unit have the highest priority.
This queue is formed by agents waiting in blocks that have the Task preemption policy set to Wait for original resource. -
After that, the suspended tasks from the queue of the ResourcePool block are processed.
This queue is formed by agents waiting in the blocks that have the Task preemption policy set to Seize any resource.
Once the suspended tasks from these queues are completed, the resource unit begins to process new tasks from their individual queues, and after that, the queue of the ResourcePool block.
If this order does not suit your needs, manually decrease the task’s priority by code, using the On task suspended action of the block.
If a downtime task has been defined by a schedule of any type, meaning it’s either a maintenance task or a custom task, and at the moment when this task should start, the resource is still executing a task of a higher priority, then the downtime task is delayed for as long as it takes the resource to complete the task of a higher priority.
Say, we have a downtime maintenance task specified with an "on"/"off" schedule. The "on" interval defines the maintenance task and is set to 2 hours long. It repeats every 10 hours, therefore the "off" interval lasts for 8 hours. If a task with a higher priority takes up the first hour of the scheduled "on" interval, then the maintenance task will start from the second hour and last for the scheduled 2 hours. The "off" interval will decrease for the same amount of time that the higher priority task has taken up from the scheduled interval, and will last for 7 hours instead of 8.
The downtime tasks of a specific ResourcePool block can occur simultaneously with the end of shift specified by the properties of this block. In this case, these downtime tasks will move to the event queue of this ResourcePool. They will start upon the completion of the end of shift task, that is, the start of the next shift.
Demo model: Maintenance of a Coffee Machine Open the model page in AnyLogic Cloud. There you can run the model or download it (by clicking Model source files).-
The type of resource units performing the task. This resource type is referred to below as T. To have different types of resources perform the same downtime task, select Agent here.
Default value: Agent
- Type
-
The type of downtime task performed by the resource units. The available options are Maintenance (may be triggered by schedule), Failure / repair (may not be triggered by schedule) or Custom (any type of interrupting activity for resource units).
Syntax: Downtime.ActivityType activityType
Valid values:
Downtime.ACTIVITY_MAINTENANCE — Maintenance
Downtime.ACTIVITY_FAILURE — Failure / repair
Downtime.ACTIVITY_CUSTOM — Custom -
[Visible and applies only if the Type is defined as either Maintenance or Custom]
Here you can choose whether you want to schedule tasks by defining the Triggers or you prefer to use AnyLogic Schedule instead.Value type: DowntimeDescriptor.TriggerType -
[Visible if the Defined by parameter is set to Schedule]
The schedule defining the occurrence pattern for the task. The schedule should be set to the “on/off” mode. During the “on” periods, the resource is on downtime.Value type: Schedule<boolean>
Local variable: T unit — the resource unit -
[Visible if the Defined by parameter is set to Triggers]
Here you can specify the period of working time (when the resource unit services an agent) and idle time that must pass between the assignments of this task. If the field is left empty, this type of trigger will not be applied.Value type: double
Local variable: T unit — the resource unit -
[Visible if the Defined by parameter is set to Triggers]
Here you can specify when the countdown for the Total time between occurrences parameter must start: either when the task starts or when the task finishes. If the downtime task has been started by a different trigger, the Total time between occurrences countdown will be restarted after the downtime task finishes.Value type: boolean -
[Visible if the Defined by parameter is set to Triggers]
Here you can specify the period of working time that must pass between the assignments of this task. Working time includes the time spent by the resource to reach the agent that seized it and the time of service itself. If the field is left empty, this type of trigger will not be applied.Value type: double
Local variable: T unit — the resource unit -
[Visible if the Defined by parameter is set to Triggers]
The number of times this resource must be seized between the assignments of this task. If the resource work was interrupted after it had been seized but then resumed once again, this is counted as two cycles. If the field is left empty, this type of trigger will not be applied.Value type: int
Local variable: T unit — the resource unit -
[Visible if the Defined by parameter is set to Triggers]
Enables the custom trigger values for the first downtime occurrence. If not enabled, the first downtime will occur when the recurrence period specified for the repeating downtime task runs out.Value type: boolean
Local variable: T unit — the resource unit -
[Visible if the Custom first occurrence option is selected]
Here you can specify the amount of time that must pass from the appearance of the resource unit until this task is first assigned to the resource. It includes both working time (when the resource unit services an agent) and idle time. If the field is left empty, this type of trigger will not be applied.Value type: double
Local variable: T unit — the resource unit -
[Visible if the Custom first occurrence option is selected]
Here you can specify the amount of working time that must pass until this task is first assigned to the resource. Working time includes the time spent by the resource to reach the agent that seized it and the time of service itself. If the field is left empty, this type of trigger will not be applied.Value type: double
Local variable: T unit — the resource unit -
[Visible if the Custom first occurrence option is selected]
The number of times this resource has been seized until this task is first assigned to the resource. If the resource work was interrupted after it had been seized and then resumed once again, it is counted as two cycles. If the field is left empty, this type of trigger will not be applied.Value type: int
Local variable: T unit — the resource unit
-
Here you can choose how you will model the downtime task:
Delay (timeout/schedule) — you can just set the duration of the task as a delay or use a schedule.
Delay (timeout/schedule) with resources — you can set the duration of the task as a delay or use a schedule and define the minimal logic for the resources that will execute this task. If the resources you are using for the downtime task are also used elsewhere, the priority of the downtime task will be 0. If you need to define a more complex logic including the prioritizing of resources, you should define it in a separate flowchart and select Go to flowchart option in this parameter.
Delay until stopTask() is called — the task will continue until its explicit termination by calling the stopTask() function.
Go to flowchart — Alternative to modeling a task just with a delay, you can model it with a flowchart describing the process. The flowchart start should start with the ResourceTaskStart block specified in the Task start block field below.Type of value: DowntimeDescriptor.TaskType
Valid values:
Downtime.TASK_DELAY — Delay (timeout/schedule)
Downtime.TASK_DELAY_WITH_RESOURCES — Delay (timeout/schedule) with resources
Downtime.TASK_WAIT_CALLBACK — Delay until stopTask() is called
Downtime.TASK_FLOWCHART — Go to flowchart -
[Visible if the Defined by parameter is set to Triggers and Task type is defined as Delay (timeout/schedule)]
The duration of the task.Value type: double
Default value: triangular(10, 20, 30) seconds
Local variable: T unit — the resource unit - Seize
-
[Visible if Task type is defined as Delay (timeout/schedule) with resources]
Define the seize mode: (alternative) resource sets or units of the same pool.
For more details, see Resources.Syntax: boolean seizeFromOnePool
Default value: (alternative) resource sets — false -
[Visible if Seize is set to (alternative) resource sets]
Here you can define several alternative resource sets (add new list by clicking the Add list button). The resource set is chosen based on the availability of units.
For more details, see Resources.Local variable: agent — the agent -
[Visible if Seize is set to units of the same pool]
ResourcePool block from where the resources are requested.
For more details, see Resources.Local variable: agent — the agent -
[Visible if Seize is set to units of the same pool]
Expression evaluated to obtain the required number of resource units for the agent.Value type: int
Local variable: agent — the agent
Default value: 1 -
If selected (true), the seized resources will be sent to the specified location.
Value type: boolean
Default value: false
Local variables:
agent — the agent
T unit — the resource unit - Destination is
-
[Visible if Send seized resources is selected]
Defines where the resources will be sent. The resources can be sent to:Agent — resources are sent to the current agent location.
Network node — resources are sent to the specified network node.
Attractor — resources are sent to the specified attractor.Get value:Seize.DestinationType destinationType
Valid values:
Downtime.DEST_ENTITY — Agent
Downtime.DEST_NODE — Network node
Downtime.DEST_ATTRACTOR — Attractor -
[Visible if Destination is the Network node]
Network node where the seized resources will be sent.Type of value: INode
Local variables:
agent — the agent
T unit — the resource unit -
[Visible if Destination is: Attractor]
Attractor where the seized resources will be sent.Type of value: Attractor
Local variables:
agent — the agent
T unit — the resource unit -
[Visible if Send seized resources is selected]
Here you can select the behavior of the resources after they are released: they will either Return to home location or Stay where they are.Value type: boolean
Local variable: T unit — the resource unit -
[Visible if Task type is defined as Go to flowchart]
ResourceTaskStart block that starts the flowchart defining the task process.Local variable: T unit — the resource unit -
Here you choose whether you consider this task in the collected usage statistics as “busy” time, “idle” time, or not take it into account at all.
Default value: not collected
Get value:Seize.DestinationType destinationType
Valid values:
Downtime.USAGE_NOT_COUNTED — not collected
Downtime.USAGE_BUSY — counted as ‘busy’
Downtime.USAGE_IDLE — counted as ‘idle’
-
Sets the priority of the task.
Value type: double
Local variable: T unit — the resource unit -
Sets whether this task may preempt the task currently being executed, if any. In other words, true means that unit will “drop its work” when this task is activated. If false, then the unit will finish all its tasks with less Priority. Note that true option has exceptions: current unit task may have a “uninterruptible” option No preemption.
Value type: boolean
Local variable: T unit — the resource unit -
Specifies the policy for the task preemption:
No preemption — cannot be preempted (unit will be busy with this task until it is finished).
Terminate — may be preempted and will be terminated.Value type: ResourcePreemptionPolicy
Local variable: T unit — the resource unit
- On start
-
Here you can type the code that will be executed when the task starts.
Local variables:
unit — the resource unit
ResourceUnitTask task — the task - On finish
-
Here you can type the code that will be executed when the task finishes.
Local variables:
unit — the resource unit
ResourceUnitTask task — the task - On terminate
-
[Visible if Preemption policy is defined as Terminate]
Here you can type the code that will be executed when the task has been terminated because of preemption.Local variables:
unit — the resource unit
ResourceUnitTask task — the task
| Function | Description |
|---|---|
| void restartTriggers(T unit) |
Resets the countdowns of all triggers for the specified resource unit and starts waiting for the next triggering events. unit — The unit which countdowns are to be reset. |
| void stopTask(T unit) |
Stops the downtime task for the specified resource unit and restarts all triggers according to their settings. unit — The unit which tasks are to be stopped. |
| boolean isActive(T unit) |
Returns if the specified resource unit is currently executing the downtime task. unit — The unit to check for downtime. |
-
How can we improve this article?
-