Although every record can be assigned many predecessors using a combination of several different methods, every predecessor must be scheduled before the record itself becomes available for scheduling. This can be written generally as Successor A cannot be scheduled until predecessor B AND predecessor C AND D; have all been scheduled. This is shown graphically below.

 

 

Dependency rules can also be placed into groups of alternatives called OR rule groups. As soon as one of the predecessors within any such group has been scheduled, the AutoScheduler assumes that all the other rules in that group have also been satisfied. This type of dependency can be written generally as Successor A cannot be scheduled until predecessor B1 OR predecessor C1 OR D; has been mined. This is shown graphically below.

 

 

OR rule groups can contain any number of predecessors and a successor can be allocated any number of OR rule groups, in addition to any number of ordinary rules. This allows complex mixtures of normal dependency rules and OR rule groups to be assigned to individual successors, as the following example shows.

This would be read as Successor A can not be scheduled until (B1 Or C1 Or D1) And E And (F2 Or G2) And H and I have been scheduled.

Each OR rule group is assigned a unique reference number, which is used when creating OR rule groups with script and relative address rule sets. Absolute bearing and relative bearing rule sets cannot be used to create OR rule groups.

With script rule sets, specific XCM functions have been provided to examine and create OR rule groups. These make use of a unique reference number allocated to each OR rule group called its group number. A list of the scripting functions related to dependency rules can be found in the XCM programming documentation.

When an Absolute Address rule set is used to create OR rule groups, the user must either create a new rule set to contain the group of alternative predecessors or select an existing rule set to which the alternative predecessors will be added. This method has been described earlier in this chapter.

If a new rule set is created, a standard dependency must be added first containing the groups' successor and its first alternative predecessor in the usual manner. This is achieved by clicking on the successor record in the database tree (it will be shown with a blue background) and then dragging the first alternative predecessor from the tree to a new row in the rule table.

Once this initial rule has been created, the other alternative predecessors must be added to it. This is achieved by dragging them from the tree to the same row in the dependency table, whilst the control key <Ctrl> is held down. A new row will be inserted into the table, above the row the predecessor was dropped on.

When dragging with the <Ctrl> key pressed in this manner, the cursor will change to an arrow with a plus symbol when it is over a valid cell in the rule table. If the control key was not depressed, the predecessor being dragged would replace the record it is dropped upon, rather than being added to an alternative rule group containing that predecessor. In this situation the cursor would still change to an arrow, but without the plus symbol.

Blank alternative predecessors can also be added by pressing <Ctrl-Insert> when an existing dependency rule is selected in the table. This will create a blank row in the rule table and the alternative predecessor can then be defined by dragging it from the tree to the predecessor column of the new row.

To help the user identify which predecessors occur within groups, a thick separating line is drawn in the table between each rule or each group of rules. To further emphasise the predecessors are alternatives in a group, the successor is only displayed for the first element in the group and the group number (an integer that uniquely identifies each OR rule group) is shown in the central column.

The management of OR rule groups introduces some complex mathematical problems, particularly regarding the validation of rules and the detection of circular references.

When there are no OR rule groups in a project, there is a single network of dependencies that must be satisfied by a schedule. But the number of possible networks increases exponentially as the number and complexity of alternative rules is increased. It is the objectives of the schedule that ultimately dictates which of these networks will be honoured. The following example illustrates this point.

As the number of possible dependency networks can easily become enormous, it would be impractical to analyse every one for potential circular references.

For this reason, full and pre-emptive circular reference testing routines do not consider dependencies that have been created by rules within OR rule groups. Expanding the circular reference testing facility to include alternative dependency rule groups will be added in a future release.