AnyLogic provides users with a Schedule — a special element allowing to define how some value changes in time according to the defined (optionally cyclic) pattern.

Schedule is frequently used to define:

• Timetable for a pool of resources defined with the ResourcePool.
• Agent generation times, or time pattern of agent arrival rate in the block Source.
• Pedestrian generation times, or time pattern (e.g. daily) of pedestrian arrival rate in the block PedSource.

Moreover, you can use schedule in none of the AnyLogic blocks but work with it from your code, obtaining its value using the corresponding API.

The following demo model illustrates how Source generates agents according to the daily rate pattern defined by rate schedule:

Demo model: Source Arrival Modes Open the model page in AnyLogic Cloud. There you can run the model or download it (by clicking Model source files).

Schedule works in one of two modes: it can either define intervals, or discrete time moments.

The first mode (intervals) is used when you need to define how some value continuously changes in time (usually according to some cyclic pattern). In the present case at any moment of time there is current value defined by the schedule. Intervals are used to define work timetables for worker shifts, cyclic pattern of pedestrian or agent arrival rate, etc.

The second mode (moments) is used when you need to define a sequence of key time moments and some values corresponding to this particular moments (or perform some actions, see the abstract below). The example — train arrival schedule: the specified number of pedestrians appears in the railway station model at the defined arrival moments.

Moreover, you can associate actions with key moments of the schedule (either interval switch times, or time moments — it depends on the schedule mode), by typing Java code in the Action section of the schedule properties. Actions are executed in those key moments, so that you can use schedule as a perfect tool for scheduling an unlimited number of actions in the future (probably, mapped to the particular calendar dates).

Schedule can control values of the following types:

• on/off (boolean type) — choose this option when the schedule defines time pattern of resource availability for ResourcePool.
• integer value — the schedule defines e.g. number of workers in a shift; number of agents or pedestrians that enter the system in the defined time moments.
• real value — the schedule defines e.g. pedestrian or agent arrival rate, but in this case we recommend to use the next option, Rate.
• Rate — the schedule defines the time pattern for agent or pedestrian arrival rate (when your Source or PedSource block’s Arrivals defined by this Rate schedule). You specify the rate values in the table in the schedule properties and choose the rate units in the Unit property (per second, per minute, per hour, per day, etc.)

You can define a schedule in one of three alternative views:

• Week — Use this view in case your schedule has weekly recurrence, e.g. if you need to define a weekly schedule for office men.
• Days/Weeks — The Calendar view is used when you need to define a schedule as a sequence of calendar dates and times, but with non-weekly recurrence. For instance, it is convenient for defining shift schedules, e.g. every third day (24 hours on, 48 hours off) — such schedule has 3-day recurrence. One more example — daily pattern of pedestrian arrival rate.
• Custom (no calendar mapping) — There is no mapping to calendar dates in this view. Schedule intervals and moments are defined simply as number of time units (milliseconds, seconds, minutes, hours, days, or weeks) passed from the model start. This view is convenient e.g. for defining maintenance intervention times, failures, etc. for various devices. Define schedule in this view when only interval durations are important, not the exact calendar times.

Schedules defined in the calendar views (Week and Days/Weeks) may have exceptions — particular time intervals when the value defined by this schedule should have other values, differing from the ones specified in the schedule.

In general, you define schedule similarly in all views: first, you select the type of the value that you want to control with this schedule (on/off, integer or real), and then define time intervals (or just time moments, it depends on the schedule mode) and specify values for each particular interval or moment. When defined the complete cycle of intervals or moments, you tell the schedule what is the recurrence time for this cycle.

But since the schedule definition varies a bit depending on the currently used view, we decided to consider several examples of schedule definitions:

•  Defining a weekly bank office timetable
•  Defining a shift schedule in the (duration = 4 days, Duration type: Days/Weeks)
•  Defining a device maintenance schedule (Duration type: Custom, no calendar mapping)

General

Name — The name of the schedule. The name is used to access the schedule from block's properties and from code.

Show name — If selected, the name of the schedule is displayed on the presentation diagram.

Ignore — If selected, the schedule is excluded from the model.

Visible — If selected, the schedule icon is visible on a presentation at runtime.

Data

Type — Type of the value defined by this schedule:on/off (the schedule defines the resource availability for ResourcePool), integer, real , or Rate (the schedule defines time pattern of agent or pedestrian arrival rate for Source or PedSource).

Unit — [Visible and applies when the schedule’s Type is set to Rate] Here you define the units for the rate values defined in the schedule’s table. The options are: per second, per minute, per hour, per day, etc.

The schedule defines — Here you can choose the schedule mode: whether it defines Intervals (Start, End), or discrete Time moments.

• Intervals (Start, End) mode is used when you need to define how some value continuously changes in time (usually according to some cyclic pattern). In the present case at any moment of time there is current value defined by the schedule. Intervals are used to define work timetables for worker shifts, cyclic pattern of pedestrian/agent arrival rate, etc.
• Moments is used when you need to define a sequence of key time moments and some values corresponding to this particular moments (or perform some actions).

Duration type — Here you choose the duration type of the schedule. Depending on this choice, the schedule is defined in one of three alternative views:

• Week — Choose this option in case your schedule has weekly recurrence, e.g. if you need to define a weekly schedule for employees.
• Days/Weeks — Choose this option if you need to define a schedule as a sequence of calendar dates and times, but it has non-weekly recurrence (some number of days or weeks). For instance, it is convenient for defining shift schedules, e.g. every third day (24 hours on, 48 hours off) — such schedule has 3-day recurrence.
• Custom (no calendar mapping) — There is no mapping to calendar dates in this view. Schedule intervals/moments are defined simply as number of time units (milliseconds, seconds, minutes, hours, days, or weeks) passed from the model start. This view is convenient e.g. for defining maintenance intervention times, failures, etc. for various devices. Define schedule in this view when only interval durations are important, not the exact calendar times.

Default value — [Visible if The schedule defines option is set to Intervals (Start, End)] Here you define the default value for the schedule — the value that will be used for the intervals not defined in the schedule.

Repeat schedule weekly — [Visible if Duration type is set to Week] Here you need to define the weekly schedule for employees, which week days are working and which are not, when the shift starts and ends. Select on / off for Value for each weekly schedule variant.

Repeat every — [Visible if the Duration type is set to Days/Weeks, or Custom (no calendar mapping)] Here you define the recurrence of the schedule.

Snap to — [Visible if the Duration type is set to Days/Weeks or Custom (no calendar mapping)] If you want your schedule to be applied not from its start moment on model launch, here you can define, what model time corresponds to the start moment of the schedule. Please note that this setting does not define the time when the schedule starts applying - it defines how the start of the schedule is shifted regarding the zero model time.

Week starts from — [Visible if Repeat every is set to Weeks] The first day of the week in some countries (e.g. USA) is Sunday, while in some other (e.g. Russia) — Monday. Therefore if you will define a schedule with N-weekly recurrence considering that the first day of the week is Sunday and then send the model to the user from some other country, where the week starts from Monday, the schedule will be misinterpreted. So if you expect that your model will be used in other countries too, please define explicitly the first day of the week in your schedule so that this schedule will be locale-independent. And please do it before defining the schedule intervals, because all interval data in the table are deleted when you change the Weeks start from setting.

Loaded from database — [Visible if the Duration type is set to Days/Weeks or Custom (no calendar mapping)] If selected, allows to load data from the existing table in AnyLogic database defined by the user.

Table — Here you can specify the existing table from AnyLogic database.

• Choice conditions — Here you define a condition that specifies the particular value to be selected from the specified table column. You can add , duplicate , delete and arrange the conditions (, ).
• Start column — The column of the table that stores either interval start time data, if your schedule defines non-weekly recurrent intervals, or time moments data, if your schedule defines discrete time moments.
• End column — [Visible if The schedule defines: Intervals (Start, End)] The column of the table that stores interval end time data.
• Value column — The column of the table that stores a set of values, each value corresponding to a particular time interval or moment.

Action

Here you can type Java code to be executed in key moments of the schedule (either interval switch times, or time moments — it depends on the schedule mode). Actions are executed in those key moments, so that you can use schedule as a perfect tool for scheduling an unlimited number of actions in the future (probably, mapped to the particular calendar dates).

Exceptions

On this page you can define exceptions for the schedule — particular time intervals when the value defined by this schedule should have other values, differing from the ones specified in the schedule.

Preview

Here you can preview the schedule in the convenient way that is commonly used in digital diaries, organizers, and office software tools. This may help you to check whether the schedule was defined correctly and the resulting picture is the one you have expected to see.

Advanced

System dynamics units — If selected, you will be able to specify units of measurements for the value returned by this schedule in the edit box to the right. Having specified units for elements of your model, you may perform unit checking to find out dimension inconsistencies in the model.

In some countries Daylight Saving Time (DST) is practiced: time is temporarily adjusted to achieve longer evening daylight by setting the clocks an hour ahead of the standard time (you can find more information on DST in Wikipedia).

AnyLogic schedules consider DST automatically. The information about DST dates in the current country is taken from the computer’s OS settings (the Current locale is taken into account).

• If the schedule maps to calendar dates (duration type is Week, or Days/Weeks), and e.g. the schedule defines that the resource works from 00:00 to 08:00, at the night the DST starts the resource will actually work seven hours instead of eight, and when the DST ends — nine hours. But the resource will always work from 00:00 to 08:00.

  

• And now let’s consider the analogous schedule defined without mapping to the calendar. In this case intervals will always have the same well-defined duration regardless DST. Let’s assume that the model with such schedule starts on some day at 00:00. In this case at the night when DST starts the resource will work 8 hours, but the work hours will shift from 00:00-08:00 to 01:00-09:00 until the DST ends.

  

How can we improve this article?

Send