Incremental Scheduling¶
Incremental scheduling can be used when scheduling a large number of activities that can be divided into groups with a defined ordering or sequence to them. The DSE can then process each pool of activities in sequence, so as not to be processing the entire set of activities at once, thus reducing the overall processing time.
For example, incremental scheduling could be used in a scenario where maintenance is to be carried out on a machine, requiring the machine to be decommissioned, then to have the maintenance work carried out, and then to be recommissioned. The three phases of work can be processed separately, but with dependencies obeyed so that maintenance work cannot begin until the decommissioning work has been completed first.
A minimum delay can be defined between two pools. The DSE will ensure that this much time will elapse between the end of the last scheduled activity within a pool and the first scheduled activity in its dependent pool.
Using Incremental Scheduling¶
Incremental scheduling is activated by setting the process_type attribute on the Input_Reference to 'INCREMENTAL'. The DSE will then calculate how the activities can be divided into separate batches to be processed incrementally.
Note
'INCREMENTAL' is a static process type, meaning that only load files can be sent in for this kind of scheduling.
The sequence for the activities should be defined by including the activities in activity pools via the Activity_Pool_Item table and setting the dependencies between the pools with the Activity_Pool_Link table. Pools may have multiple pre-requisite or dependent pools (so it does not need to be a linear, one-to-one ordering of the pools).
Parent pools can be defined to simplify the ordering of the pools. Parent pools may not directly contain activities, but can have dependency links to other pools. So there could be, for example, two parent pools called ParentPool1 and ParentPool2, which each have multiple child pools. An Activity_Pool_Link between ParentPool1 and ParentPool2 means that all of the child pools within ParentPool1 must be completed before any of the pools in ParentPool2 are allowed to begin.
Note
Two pools may only be linked together if they have the same parent pool (or if neither of them has a parent). So in the example above, there may be Activity_Pool_Link rows between any of the child pools within ParentPool1, but there may not be a link set up between a child pool of ParentPool1 and a child pool of ParentPool2.
The example above shows how a non-linear sequence of pools can be set up, using parent pools to define separate phases of the work. Each of the pools shown in green here can have activities assigned to them, but the parent pools in orange cannot directly have any activities.
Note
There may be more levels of parent pools than shown here. i.e. A pool may be a parent of another pool which is then the parent of another pool, and so on.
The require_fully_allocated attribute on the Activity_Pool_Link row can be used to defined whether the DSE must schedule 100% of the activities within a pre-requisite pool before the next pool is allowed to begin. So if a link between Pool1 and Pool2 has require_fully_allocated set to true, then the DSE will only schedule the activities in Pool2 if all of Pool1's activities are allocated. If it is not possible to schedule all of the Pool1's activities, Pool2 will go entirely unallocated. With require_fully_allocated set to false, if an activity in Pool1 goes unscheduled, Pool2 may still be scheduled, after the last activity in Pool1 that was able to be scheduled.
Warning
Due to the way in which the DSE will halt processing of the schedule at various times as it progresses incrementally throughout the sequence of work, it is possible that the final schedule is not as good as the schedule would be were the whole schedule processed as a single static schedule, so this mode should only be used when the number of activities is significantly large.
Warning
Due to the way in which pools are processed separately, constraints between activities belonging to different pools are not supported. So, for example, setting two activities belonging to separate pools as co-requisites of each other is not supported, nor could a separation group between two activities in different pools be expected to be obeyed.