SCheduler METHODOLOGY

Campus Zone Division

The scheduling program will divide the UPLB campus into three distinct zones. These divisions are based on geographical and environmental constraints of the campus. Each zone is further divided into patches, and patrols can freely move within the patch they're assigned to. The user sets how many patrols are placed in each zone. The system guarantees that the patrol will not be assigned to visit patches outside of the zone it's assigned to.

The first zone covers the section of the lower campus situated north of Molawin Creek, which includes the areas surrounding Carabao Park, Oblation Park, Main Library, and the Math Building. The second zone is the other section of the lower campus south of the creek. This zone covers the Freedom Park and its vicinity, as well as parts of the College of Engineering and Agro-Industrial Technology (CEAT) and College of Veterinary Medicine (CVM). The third zone covers the Forestry Campus. The three zones are divided into eight, six, and four patches, respectively. The figure below shows the zone divisions and their patches.

The campus division was done this way due to several factors affecting each zone. The first zone has the most patches because of the density of buildings in the area. For a patrol standing at any point within the zone, their line of sight is frequently obstructed by buildings. When each patrol has decreased field of vision, vantage points have smaller coverage areas, thus the need to increase the number of patches. The second zone has a larger land area, but the zone mostly is very open space, particularly in the areas surrounding Freedom Park. In the third zone, most key areas are compactly placed along the main road, thus each patrol can easily cover a significant area of interest.

Dividing the campus into zones have several benefits. Keeping a patrol within its assigned zone allows the algorithm to calculate the next assignment faster, as it only needs to account for a section of the campus. The division also prevents the scheduler from clumping all the patrols in a small area of the map.

The zoning method only prevent patrols from being assigned to distant patches. In the real world, it does not restrict patrols from moving in between zones. This is important for interruptions, such as an emergency call to action. With the zoning limitations ensuring that patrols are spread across campus, the average response time would be minimized.

Weighted Probability

Each patch is given a weight value. The said value determines the probability of the patch being selected by the scheduling algorithm. For handling this task, the developers decide to use the Java class EnumeratedDistribution. Upon initialization, the EnumeratedDistribution class takes a List of Pairs as a parameter (in this case, List and Pair are both Java classes). Each Pair is comprised of an Object class and its weight, stored as a Double class. The probability distribution is based on the sum of all the weight values in the list.

Using this method yields several advantages. If any of the weight values are adjusted, the EnumeratedDistribution class can implicitly handle the changes to the probability distribution. Sampling multiple items from the list is also possible, in which the developer only has to update the list after every sampling. This would be useful when selecting multiple patches from the set.

With the program dividing the campus into three zones, changing the weight value of a patch only affects the probability of the zone that patch belongs to. This means that each zone has a probability distribution that is independent from the others. Historical data can be utilized to adjust the probabilities and make them more representative of the real world problem.

Scheduling Parameters

Before generating a schedule, the scheduling program asks for the following parameters from the end user:

1. Number of patrols allocated per zone

2. Number of intervals to be generated

3. Length of each interval (in minutes)

The second and third inputs determine how long the generated schedule would be. For the interval duration, the user can select between 10, 15, 20, 30, and 60 minutes. It is recommended that the schedule length do not exceed eight hours, which is the prescribed length for personnel duty. Changes made to these three parameters would cause a reset to the scheduler, and any generated schedules at that point will be erased. The figure below shows a snippet of the scheduler's interface where the end user inputs the parameters.

Probability Weights

When the initial parameters are set, the next panel will show the user the weight values of the patches. The interface shows three sections for the three zones. These values have a default preset, set in place by the developer. The program is able to save multiple presets, and users can change values of an existing preset or create a new one. Figure 3 shows the program interface where the end user can change the weight values of each patch.

When the patrol allocations and the patch weights are set, the scheduler proceeds through scheduling. For every interval, patches are selected in each zone equivalent to the number of allocated patrols. For cases where the number of patrols in a zone exceed the number of patches available, in which case the scheduler simply moves on to the next zone.

The generated schedule can be presented in text form or graphical form, as seen in the figures below. The graphical form allows the end user to quickly inspect if there are patches that are either overprotected or vulnerable for too long, and assess the schedule and the probability distributions.

At this point the user is then allowed to make several actions. The program can generate a new schedule using the same distributions. The user can also make adjustments to the probability distribution before generating a new schedule. Schedules will vary with timing, but the frequency of visits each patch is expected to be fairly consistent.

Patrol Assignments

At this point, the program only selected which patches in campus are to be patrolled. It did not assign which patrol unit will go to what patch. Assigning patrols to the selected patches should take into account each patrol's mileage, or the total distance they have travelled. Patrols will not be assigned to areas that are too far from their current location throughout the duration of the schedule.

Since patch selection is based on probability and not proximity, there will be instances that a unit must travel a significant distance from its current location to the patch it is assigned to. The scheduling program must keep the mileages of the patrols in a zone to be as close to each other as possible. However, if there is only a single patrol in each zone, the mileage is fully dependent on the selected patches and their order.

There is no reliable method to determine the exact coordinates of each patrol since they are free to roam around the patch. To calculate from one patch to every other patch within the zone, each patch has a reference point that is used for calculating the distance. This values will be used to add to the mileage of each patrol, as they travel between patches. Due to this the mileage values of the patrols may not be equal to the actual mileage accumulated in the real world.

When the program assigns a patrol to the patch, it deploys the patrol with the highest mileage to the patch nearest to that patrol. This method keeps the averages lower. This also makes sure that no patrol is staying in one place too often. This is useful in certain schedules where a high probability patch is selected for consecutive intervals, patrols will still be rotated so they don't overstay. The figure below shows a sample of the scheduler displaying the patrol units, their assigned zone (indicated by color), and their mileages.

Technical Details

The OCSG scheduler program was written in Java, and an executable .jar file is provided. To open said executable .jar, the user's computer must have Java 11 or newer installed. Installation files of Java 11 for Windows, Mac OS, and Linux-based operating systems can be found in Oracle.com's Downloads Archive. Online guides are available online for installation.