XPAC

AUTOSCHEDULER
Release 7.5

A Computer Software System for

Mine Planning and Scheduling

User Guide
June 2002
 Runge Software
Runge Software and associated software products are the copyright of Runge Pty Ltd. Use, duplication or
disclosure is subject to the restriction stated in the software license. No part of this document may be copied
or reproduced in any form without the prior written consent of Runge Pty Ltd.

Although the software has been tested and the documentation reviewed, Runge Pty Ltd offers no warranty
for the quality, performance or fitness of the software or documentation for any particular purpose. In no
event will Runge Pty Ltd be liable for direct, indirect, special, incidental or consequential damages arising out
of the use or inability to use the software or documentation.

Runge Pty Ltd has a policy of continual improvement to all products and documentation. The information in
any documentation is subject to change without notice.

XPAC AutoScheduler User Guide, Release 7.5

Copyright Runge Pty Ltd A.C.N. 010 672 321
Brisbane, Australia, 2001
All Rights Reserved
Printed in Australia

XPAC, AutoScheduler,TALPAC, XERAS and DragSim are registered trademarks of Runge Pty
Ltd and/or associated companies.

Formula One and First Impression are registered trademarks of Visual Components Inc.
Cypress Enable is a registered trademark of Cypress Software Inc.

Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Microsoft Excel, Microsoft Access
and DAO are trademarks of Microsoft Corporation in the USA and other countries.

For further information or additional copies of this documentation contact:

Runge Pty Ltd

G.P.O. Box 2774 Ph: Australia (07) 3221 1883
Brisbane, Qld 4001 International (+617) 3221 1883
Australia. Fax No. (07) 3229 3756
email [email protected]
home page http\\www.runge.com
 ABOUT THIS MANUAL
This manual deals specifically with the features of
the XPAC AutoScheduler module, which are not
covered in the on-line help system. Users should
still consult the XPAC on-line help system for
information on features that are common to both
standard XPAC and the AutoScheduler module.
This document will be integrated with the on-line
help in a later release of the package.

Runge is committed to a policy of on-going product

development and new features are continuously
being added to the package.

Your input into the future design and features of

this package are both welcomed and encouraged.
Although we cannot guarantee every suggestion
will be implemented, we place great importance on
client feedback and all submissions will be
seriously considered. Please direct comments and
suggestions to the XPAC team in Brisbane.

Whilst every effort has been taken to ensure the

AutoScheduler is free from errors, our rigorous
testing regime cannot evaluate the package in
every possible real world situation.

Should any errors be found in the package,

whether major or minor, we strongly urge you to
report them to our programming team in Brisbane
as early as possible so they can be investigated and
eliminated. A client feedback facility has been
provided on the help menu for this purpose.
 TABLE OF CONTENTS

INTRODUCTION ............................................................... 1
WHAT IS THE XPAC AUTOSCHEDULER? .......................................... 1
OVERVIEW OF THE AUTOSCHEDULER .............................................. 2
SCHEDULING RESOURCES .................................................................. 4
XPAC’S SCHEDULING MODES .......................................................... 4
ADVANTAGES AND DISADVANTAGES ............................................... 5
Advantages ........................................................................................................ 6
Disadvantages ................................................................................................... 6
CONFIGURING AN AUTOSCHEDULER MODEL.................................... 6

DEPENDENCIES & DEPENDENCY RULES................ 9

INTRODUCTION .................................................................................. 9
DEPENDENCY RULES AND ACTIVITIES ............................................ 10
CREATING DEPENDENCY RULE SETS ............................................... 12
EDITING DEPENDENCY RULE SETS .................................................. 13
Script Dependency Rule Sets ........................................................................... 13
Absolute Address Dependency Rule Sets ........................................................ 14
Relative Address Dependency Rule Sets ......................................................... 18
Absolute Bearing Dependency Rule Sets ........................................................ 22
Relative Bearing Dependency Rule Sets ......................................................... 25
APPLYING DEPENDENCY RULE SETS ............................................... 29
DEPENDENCY RELEASE PROFILES ................................................... 32
Release Profiles With Upper Level Dependencies .......................................... 36
OR RULE GROUPS (ALTERNATIVE RULES)...................................... 38
VIEWING DEPENDENCY RULES ........................................................ 43
Using The Dependencies Window ................................................................... 43
Viewing Dependencies Graphically ................................................................ 44
CREATING DEPENDENCIES GRAPHICALLY ....................................... 48
Preparing To Create Dependency Rules ......................................................... 48
Creating Dependency Rules Graphically ........................................................ 52
Using The Docking Graphics Views ............................................................... 54
CIRCULAR REFERENCE TESTING...................................................... 55
Standard Circular Reference Testing .............................................................. 57
Pre-emptive Circular Reference Detection ..................................................... 59
Limitations When OR Rule Groups Are Used ................................................. 62
HOLE SCANNING ............................................................................. 62
ADJACENCY TABLES ....................................................................... 65
Adjacency Tables Classified By A Database Level ......................................... 65

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd Table of Contents (i)
 Adjacency Tables Classified By A Database Field ......................................... 68
DEPENDENCIES USING UPPER LEVEL RECORDS .............................. 69
SKIPPING NON-SCHEDULED RECORDS............................................. 71

CAPACITY CONSTRAINTS.......................................... 75
INTRODUCTION ................................................................................ 75
CREATING CAPACITY CONSTRAINT SETS ........................................ 76
EDITING CAPACITY CONSTRAINT .................................................... 77
Range Capacity Constraints ........................................................................... 77
Contents Of Range Capacity Constraints ....................................................... 79
Stockpile Capacity Constraints ....................................................................... 83
Concurrent Work In Progress Capacity Constraints ...................................... 85
PROPORTIONAL CAPACITY CONSTRAINTS ....................................... 87
APPLYING CAPACITY CONSTRAINTS ............................................... 89
CAPACITY CONSTRAINTS THAT DEFINE MINIMUMS ........................ 90

PERIOD CONSTRAINTS ............................................... 93

INTRODUCTION ................................................................................ 93
CREATING PERIOD CONSTRAINT SETS ............................................. 94
EDITING PERIOD CONSTRAINT SETS ................................................ 94
APPLYING PERIOD CONSTRAINTS .................................................... 96

PROXIMITY CONSTRAINTS ....................................... 97

INTRODUCTION ................................................................................ 97
CREATING PROXIMITY CONSTRAINT SETS....................................... 98
EDITING PROXIMITY CONSTRAINT SETS .......................................... 99
APPLYING PROXIMITY CONSTRAINTS ............................................ 100

STOCKPILES ................................................................. 103

INTRODUCTION .............................................................................. 103
CREATING STOCKPILES ................................................................. 106
EDITING STOCKPILES ..................................................................... 107
Setting The Maximum Pile Size ..................................................................... 108
Setting The Stockpiles Dependency Rules ..................................................... 109
Using Stockpile Creation Scripts .................................................................. 110

Table of Contents (ii) XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd
ii
 SELECTING STOCKPILES IN A SCENARIO ....................................... 111
ASSIGNING RESOURCES TO STOCKPILES ....................................... 112
CONSTRAINING MOVEMENTS TO STOCKPILES............................... 113
CONSTRAINING MOVEMENTS FROM STOCKPILES .......................... 113
CONTROLLING STOCKPILE SIZE ..................................................... 114

AUTOSCHEDULER RESOURCES............................. 115

INTRODUCTION .............................................................................. 115
CREATING AUTOSCHEDULER RESOURCES..................................... 116
ASSIGNING RESOURCES TO SCENARIOS ........................................ 118
ASSIGNING ROSTERS AND ROSTER EXCEPTIONS ........................... 119
ASSIGNING ACTIVITIES TO SCENARIOS AND RESOURCES ............. 120
ASSIGNING AUTO TARGET DETAILS .............................................. 122
Setting The Production Target ...................................................................... 122
Using Lower Target Limits ........................................................................... 123
Using Upper Target Limits ........................................................................... 124
Considerations When Using Upper Target Limits ........................................ 126
Sharing Objectives With Another Resource .................................................. 127
Assigning Accumulation Data Fields ............................................................ 128
Setting The Step Size ..................................................................................... 129
MANAGING TEMPORARY SHORTAGES OF MATERIAL.................... 131
ASSIGNING A RESOURCES OBJECTIVES ......................................... 133
Inserting New Objectives .............................................................................. 134
Setting An Objectives Type And Target......................................................... 135
Using An Objectives Advanced Settings........................................................ 137
Setting An Objectives Priority ....................................................................... 138
Setting An Objectives Period Bias ................................................................ 139
MANAGING RECORDS WITH SIMILAR QUALITIES .......................... 141
LOOK AHEAD OBJECTIVES ............................................................ 143
Look Ahead Ranking’s .................................................................................. 143
Look Ahead Objectives.................................................................................. 145
Look Ahead Objectives And Period Bias Settings ......................................... 146

RUNNING THE AUTOSCHEDULER ........................ 149

INTRODUCTION .............................................................................. 149
TIME SLICING ................................................................................ 150
APPLYING DEPENDENCY RULES .................................................... 150
MINED OUT AND PRESCHEDULED BLOCKS ................................... 151
RUNNING A SCHEDULE ................................................................. 152
Refreshing Cashed Database Ranges ........................................................... 152
Selecting The Periods To Schedule ............................................................... 153
Using The Global Statistics Cache ............................................................... 153
Configuring Reports To Execute Automatically ............................................ 154

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd Table of Contents (iii)
 Exporting Data For The schedule Analysis Tool .......................................... 155
DISPLAYING INFORMATION WHILST SCHEDULING ........................ 156

USER PROCESSING ..................................................... 161

INTRODUCTION .............................................................................. 161
SELECTING USER PROCESSING TRIGGER EVENTS .......................... 162
TRIGGER EVENT TYPES ................................................................. 163
Before Loading Schedule .............................................................................. 163
After Loading Schedule ................................................................................. 163
Pre Period Event ........................................................................................... 163
Pre Block Event............................................................................................. 164
Pre Step Event ............................................................................................... 164
Post Step Event ............................................................................................. 164
Post Block Event ........................................................................................... 164
Post Period Event.......................................................................................... 165
After Schedule Runs ...................................................................................... 165
Add Block To ABL ......................................................................................... 165
ASSIGNING USER PROCESSING SCRIPT PROPERTIES ...................... 165
ALLOWING DYNAMIC DATABASE CHANGES ................................. 166
ACTIVATING AUTOMATIC DATABASE TRACKING.......................... 167
SELECTING THE VARIABLES TO TRACK ........................................ 169
ROLLING THE DATABASE BACKWARDS ........................................ 171
EXAMPLE : LIMITING SHOVEL MOVEMENTS .................................. 172

SCHEDULE ANALYSIS TOOL ................................... 175

INTRODUCTION .............................................................................. 175
PREPARING TO USE THE SCHEDULE ANALYSIS TOOL ................... 177
RUNNING THE SCHEDULE ANALYSIS TOOL ................................... 179
USING THE MAIN SAT WINDOW .................................................. 179
SELECTING SAT VIEWERS............................................................. 182
ABL VIEWERS............................................................................... 185
DATABASE VIEWERS ..................................................................... 186
DEPENDENCY VIEWERS ................................................................. 188
MATERIAL DISTRIBUTION VIEWERS .............................................. 189

Table of Contents (iv) XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd
iv
Chapter 1
INTRODUCTION

What Is The XPAC AutoScheduler?

The XPAC AutoScheduler is an additional module for the XPAC

database and scheduling system. This module allows schedules to be
created automatically that achieve a set of user defined objectives, whilst
honouring any number of practical mining rules and constraints.

The AutoScheduler cannot be used independently as it makes extensive

use of the XPAC database and the many reporting and visualisation tools
XPAC provides. The module is fully integrated with the package and
both standard and automatic scheduling modes can be used in the same
schedule.

Runge first developed the AutoScheduler in 1992 as an internal

consulting tool and it was released commercially in 1994. Version 7 of
the AutoScheduler runs under the windows environment and was
released in January 2000.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 1

Overview Of The AutoScheduler

The AutoScheduler is relatively easy to use, with an intuitive approach to

mine planning and the definition of scheduling rules. It has been
developed generically to suit almost any type of mining operation and
can be configured to suit a wide range of applications.

For long term scheduling, targets and constraints for each period can be
pre-defined and the AutoScheduler will generate schedules that best suit
the objectives virtually at the click of a mouse. For shorter term
scheduling where control of grade or other values is more critical, the
AutoScheduler can be run period by period, allowing it’s parameters to
be adjusted to fine tune the scheduling results.

To ensure all physical restrictions on the mining sequence are satisfied,

such as pit slope angles or stoping sequence, a set of dependency rules
are defined for each block. A comprehensive suite of tools has been
provided to assist with this process.

The dependency rules are used by the AutoScheduler to determine which

blocks are available for mining at the beginning of a schedule and when
blocks are mined, which new blocks will become available. Period,
capacity and proximity constraints provide further control over the block
selection process, by limiting or preventing production from specific
parts of the mine during each period.

The scheduling rules represent the logic a scheduling engineer would

normally impose when generating schedules manually. Because these
rules are encapsulated within the database, all rules (included those
derived from experience) are documented in a format that is retained for
successive scheduling engineers.

In some instances, the scheduling rules change during the course of a

schedule, depending on which blocks have been previously selected. For
example, when a stope is selected for mining, its adjacent stopes may
become unavailable until it has been fully mined and back-filled.

To accommodate these dynamic scheduling rules which cannot be

defined before the schedule is run, scripts written in a Visual Basic
compatible language can be triggered at various points during the
schedule. These can modify the schedule configuration and therefore
influence the block selection process. This approach has many
similarities with event simulation and provides almost unlimited
flexibility.

The quality of each product (or resource) is controlled by user defined

objectives that influences which of the available blocks the
Autoscheduler will select at each point in the period.

2 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

2
 Each objective is used to influence the value of any field in the database
when considered over the duration of each scheduling period. Three
options are available, as follows.
 Maximise the value of the fields over each scheduling period.
 Minimise the value of the fields over each scheduling period.
 Target a specific value for the field over each scheduling period.

An unlimited number of objectives can be assigned to each resource and

these can be allocated priorities that define their relative importance.
Furthermore, the parameters of each objective can change from period
to period.

The use of stockpiles is often an essential element of the mines blending

strategy and XPAC can support an unlimited number of stockpiles with
different properties. Each stockpile can be assigned independent
objectives and targets, whilst constraints allow control over all material
movements within the system.

The AutoScheduler will suggest a sequence of blocks for each period

that best meets the objectives, whilst satisfying all scheduling rules and
constraints. The schedule can then be fine-tuned by adjusting the
individual parameters that control the block selection process.

One of the main advantages of the Autoscheduler’s heuristic scheduling

algorithm over more traditional methods such as Linear, Mixed Integer
and Dynamic programming is its speed. In medium sized deposits with
over 20,000 mining blocks, the traditional methods can take days to
schedule a single period, whilst the AutoScheduler can perform the same
function within minutes.

The Autoscheduler’s speed coupled with the ability to pre-programme

the mining logic within the scheduling system allows schedules to be
produced rapidly that satisfy an almost unlimited range of criteria. This
permits numerous alternative strategies to be studied in a reasonable time
frame, before the most appropriate is selected. The scheduling
engineer’s time becomes focused on analysing schedules rather than
generating them. In turn, this allows the best schedule to be selected
rather than the first valid schedule that can be generated in the available
time.

This also makes the AutoScheduler an ideal analysis tool for studying the
long-term implications of alternative strategies in complex operations.
For example, how will increasing the grade of one product effect the
mine’s ability to maintain the quality of it’s other products over the long
term?

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 3

Scheduling Resources

XPAC is a resource based scheduling tool that can cater for a large
number of resources in any schedule. Resources are very flexible and
can be used to represent a wide range of real world items that must be
scheduled. They usually fall into one of three broad and overlapping
categories, as follows:
 A product generated as the result of mining, such as Waste or Ore.
 An operation or activity that must be performed as part of the
mining process, such as underground development, back fill or open
pit blasting.
 The operation of an item of equipment (or a pool of equipment) that
performs one or more activities (such as a development jumbo or an
excavator).

The user is not restricted to one type of resource within a schedule and
can use them in any combination. For example, an underground stoping
operation can have resources that represent development, slot raising,
ore production from stoping operations and back fill.

XPAC’s Scheduling Modes

The XPAC AutoScheduler supports three scheduling modes, as follows.

 Standard Target Scheduling
 Standard Production Scheduling
 Auto Target Scheduling

These modes share many common features, the most significant being
the XPAC database used to store and manipulate the reserves to be
scheduled. But the methods are suited to different applications and it is
important to appreciate the advantages and disadvantages associated
with each before choosing the most appropriate technique(s).

XPAC has two native scheduling modes; Standard Target Scheduling

and Standard Production Scheduling. Both methods can be considered
manual and require the planning engineer to select the sequence of
blocks each resource must schedule (the resources input path).

With standard target scheduling, the planning engineer specifies the

target each resource must achieve in each period. XPAC then
determines which portions of the input path will be scheduled in each
period. This method requires very little configuration and is ideally
suited to broad brush scheduling tasks where minimal detail is required.

4 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

4
 With Standard production scheduling, the planning engineer does not
define the quantity of material that must be scheduled in each period.
Instead, the productivity each resource can achieve is defined. This
productivity can vary in different parts of the deposit and over time.
The scheduling engine still assigns portions of the resources input path
to each period, but does so based on the quantity each resource can
achieve at realistic productivities. This type of scheduling is more suited
to short term scheduling, where greater detail, flexibility and control are
required.

The AutoScheduler module provides an additional scheduling method

that takes a completely different approach to scheduling. Instead of
specifying an input path that each resource must follow, the objectives of
each resource are specified along with the mining rules and constraints
the resources must honour. The AutoScheduler then determines the
mining sequence for each resource that best satisfies their objectives
whilst honouring all rules and constraints.

Because of its speed and goal based approach, the AutoScheduler has
proved to be a perfect tool for blending operations that must satisfy
stringent product specifications. It is also ideal for analysing alternative
scenarios and investigating different strategies. However, AutoScheduler
models are more complex and require more time to configure than
standard scheduling models.

Users are not restricted to a single scheduling technique and different

methods can be used to schedule a common reserve database when this
is appropriate. For example, the AutoScheduler may be used to generate
strategic, long-term schedules, whilst production based scheduling can be
used to generate detailed short-term schedules.

It is also possible to combine different methods in a single schedule.

The first 18 months (where most detail is required) can be scheduled
using standard production scheduling and the remainder of the mine life
(where less detail is known or required) can be Autoscheduled.

Advantages And Disadvantages

The AutoScheduler has both advantages and disadvantages compared

with manual techniques and a clear understanding of these will help the
planning engineer choose the most appropriate scheduling method.

Several disadvantages with older versions of the package were associated

with its complexity and many of these have now been overcome. This is
a result of both the Windows interface and the numerous advanced tools
that have been provided to tackle the more difficult components of
AutoScheduler models.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 5

 Advantages
 Once defined, scheduling rules are always followed, reducing the risk
of scheduling errors.
 Rules that are based on the planner’s experience are captured in a
format that is retained for new engineers on site.
 Planning engineers spend less time creating schedules and more time
evaluating them.
 The extremely fast scheduling speed allows many more scenarios to
be evaluated.
 By generating many schedules, planning engineers develop a greater
understanding of the deposit.
 Rules can be added incrementally, allowing their individual effects to
be studied.
 Conflicting objectives can be played off against one another by
adjusting priorities.
 The model provides full documentation of a schedule for audit
purposes and forces the adoption of a systematic approach.

Disadvantages
 Scheduling system is more complex, increasing the learning curve.
 Set up time is longer than with manual scheduling methods.
 Sometimes perceived to be less flexible, as planning engineer cannot
break the rules as and when required.

Configuring An AutoScheduler Model

The configuration of an Autoscheduler model is very similar to a model

that uses one of the other scheduling methods. This is particularly true
of the main and calendar databases, and comparable design
considerations must be made. We therefore recommend users study
XPAC’s on-line help system, which describes most of the facilities
necessary.

The most significant differences between a standard XPAC model and

an AutoScheduler model lie in the definition of scheduling rules and
constraints, which are specific to the AutoScheduler. The tools provided
to create these components are described in detail in the following
sections of this manual. The definition of resources is also quite
different and has been described later in this manual.

6 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

6
 Due to the additional complexity associated with Autoscheduler models,
we recommend users plan the design of their database and scheduling
model completely before the database is constructed. This approach
ensures the database will cater for all the rules and constraints required in
the scheduling model. This also leads to simpler, more logically designed
models.

Although the Windows interface is very intuitive, users that are

unfamiliar with XPAC and the AutoScheduler module are unlikely to
make the most of the package without first understanding its basic
design philosophy. We therefore recommend that new users undertake a
Runge training course. Autoscheduler training courses are normally
customised to suit each client and Runge usually assists clients with the
design of their first model, once they have completed a training course.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 7

Chapter 2
DEPENDENCIES &
DEPENDENCY RULES

Introduction

Dependencies form an essential part of most AutoScheduler models and

are one of the principle methods of controlling a schedule’s mining
sequence. The basic form of a dependency would be as follows.

Block B cannot be scheduled until block A has been scheduled.

In this example, block B would be called a Successor of block A and block

A would be called a predecessor of block B.

We define the dependencies of a block by specifying its predecessors; the

blocks that must be scheduled before it can be scheduled itself. A block
can have many dependencies and they must all be satisfied before it will
become available for scheduling.

Even though a model may contain many thousands of dependencies,

they do not define what the mining sequence must be; to do this would
make the AutoScheduler redundant. Instead, they are used to specify
unacceptable mining sequences, preventing invalid mining sequences
from occurring within schedules that the AutoScheduler generates.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 9

 The AutoScheduler uses the Available Block List (ABL) to ensure each
record in the database is not scheduled until it has become available. If a
block does not have any dependencies it is immediately available for
mining and all such blocks are placed in the ABL before scheduling
begins.

Blocks that have at least one dependency are not placed in the available
block list at the start of the schedule, preventing them from being
selected. However, they are re-evaluated every time an available block is
scheduled and are added to the ABL once all of their dependencies have
been satisfied.

As the AutoScheduler will only select blocks from the available block
list, the dependency rules are always honoured. But just because a block
has been placed in the available block list does not mean it can actually
be scheduled; another scheduling rule, such as a period or a capacity
constraint may have temporarily made it unavailable for scheduling.

All but the simplest AutoScheduler models require many thousands of

dependencies, making it impossible to specify them individually. We
therefore create dependencies using generic dependency rules that are
applied to large areas of the deposit. A simple example would be a
dependency rule The Block Above, which would be applied to every block
in an open pit deposit to prevent under-cutting.

To simplify their management, related dependency rules are grouped into

sets and different sets can be applied to different portions of the deposit.
For example, in an open pit, the dependency rules needed to maintain an
acceptable pit slope would normally be grouped into a single dependency
rule set. This could be applied to all blocks in the pit other than those
on the southern wall, which could use an alternative rule set.

Dependency Rules And Activities

Each record within the database can have many user-defined activities
that must be performed in order to complete the record. The activities
required in a model are dependent on the type of deposit being
scheduled, the mining method being used and the level of detail required
in the schedule.

When creating a long-term schedule for an open strip coal mine, it may
be sufficient to create activities for overburden stripping and coal
mining. But when a creating a detailed schedule for an underground
stoping operation, activities may be required for development, support,
slot raising, stoping and backfill.

10 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

10
 The order in which the activities must be performed should be specified
in the Productive Activities window. These do not have to be sequential
and can occur in any order.

In the example below, activities 1 & 2 are performed first in any order.
Activity 3 can begin as soon as activity 1 is complete, but activity 4
cannot begin until both activities 2 & 3 are complete.

1 3
4
2

The sequence the activities must occur in is defined using the Precedence
column in the Productive Activities dialogue. The number of the preceding
activity must simply be entered in this column for each activity. If an
activity has more than one preceding activity, they should be separated
by commas. The only limitation is that an activity cannot be preceded by
an activity with a larger number than itself.

In the example above, activity 1 and 2 do not have any precedence’s and
so they can both start as soon as the record becomes available. But
activity 1 is a predecessor of activity 3, and so activity 3 cannot begin
until activity 1 has been completed. Lastly, activity 4 has two preceding
activities; 2 and 3. These are separated by a comma in the precedence
column (2,3), which indicates activity 4 cannot begin unless activities 2
and 3 have both been completed.

By default, dependency rules are applied to whole records such that Every
activity in the predecessor record must be completed before Any of the
activities in the successor record can be started. This default option is
referred to as ALL activities in both the predecessor and successor
records.

When required, this default can be over-ridden and dependencies can be

assigned to a specific activity in the predecessor record, the successor
record or both. Some examples are shown below.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 11

  Activity 2 in the predecessor record must be completed before any
activities in the current record can be started.
 All activities in the predecessor record must be completed before
activity 3 in the current record can be started.
 Activity 1 in the predecessor record must be completed before
activity 2 in the current record can be started.

Creating Dependency Rule Sets

All dependencies are created by dependency rules and these are grouped
into sets to simplify their management. Before any dependency rules can
be defined, users must create a new dependency rule set and give it a
unique name.

To create a new dependency rule set, the Dependency Rule Set item in the
tree structure of the schedule set up window should be selected with the
All Items tab active. A list of the current dependency rule sets will be
displayed in the right hand pane. Buttons are also provided to add a new
rule set or to delete, edit or rename an existing rule set.

When the New button is selected, a new item will be added to the list and
an appropriate name should be entered to the replace the default name
NewItem.

12 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

12
Editing Dependency Rule Sets

There are currently five different types of dependency rule sets, each
with different properties and behaviours, as follows:
 Script;
 Absolute Address;
 Relative Address;
 Absolute Bearing; and
 Relative Bearing.

When first created, dependency rule sets have the default type of Script
and to change this, the rule set must be edited. This is achieved by
selecting it in the right hand window and pressing the Edit button, or
simply by selecting it in the tree structure.

When edited, the right hand window changes to show the rule set’s
properties. This window has three tabs, with the Coordinates tab
containing the main options. The other tabs provide access to advanced
features that are not applicable to all types of rule sets. These advanced
properties are described in later sections of this document.

The dependency rule set’s type is selected from a drop down list box and
when changed, the options available in the window change accordingly.
The options available with each type of rule set are described in the
following sections.

Script Dependency Rule Sets

Script dependency rule sets allow dependencies to be created using XCM

scripts. Whilst script rules can take a little longer to configure than some
of the other rule types, they are extremely flexible and are commonly
used when the other predefined rule set types are unsuitable.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 13

 When this type of dependency rule set is selected, the user must indicate
which script the dependency rule set should execute. This should be
entered directly or selected from the dialogue box after pressing the
browse button.

If the script is located in the project directory, its name must be

specified. If it is located in a sub-directory of the project directory, the
name of the script should be proceeded with the characters .\ plus the
path to the subdirectory (for example .\XCMs\Haul Road
Dependencies.bas). If the script is located in a different directory, its
full path must be specified.

The user must also specify the database range the XCM script will be
executed over. By default the pre-defined range All is used, but this can
be changed to limit the effects of the rule set to a particular portion of
the deposit.

Only one script can be specified in a dependency rule set, although any
number of rule sets can be created. This allows different XCM scripts to
be executed over different database ranges.

The scripts used in dependency rule sets make use of several special
XCM functions that allow the interrogation of existing dependencies and
the creation of new dependencies. A list of the scripting functions
related to dependency rules can be found in the XCM programming
documentation and in the XCM quick reference guide.

To ensure the AutoScheduler manages dependency rules correctly,

dependency scripts can only be executed from within a dependency rule
set. If the user attempts to execute a script that creates dependencies
directly, an error message will be generated indicating the script must be
called from within a dependency rule set.

In addition to standard dependencies, script functions are also provided

to access more advanced dependency features such as release profiles
and OR rule groupings. These features are described later in this chapter.

The two additional tabs on the right hand pane of the schedule set up
window (Circular Reference Checking and Adjacency Tables) provide access to
advanced properties that are not appropriate to this type of dependency
rule set. The options on these tabs are therefore unavailable with this
type of dependency rule set.

Absolute Address Dependency Rule Sets

Absolute address dependency rule sets require the predecessor and

successor records to be specified absolutely for each dependency rule.
The database range is therefore redundant and cannot be assigned.

14 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

14
 There is no limit to the number of dependency rules each set can
contain. But to simplify their management, each rule set is normally
restricted to rules that share a common purpose or that apply to a
specific area. When necessary, several rules sets can be defined to
maintain this division.

Rules within this type of rule set are defined manually and each rule will
only create one dependency. Whilst this makes them very flexible, they
are obviously unsuitable for creating the thousands of rules most
AutoScheduler models require. They are therefore restricted to small
areas of a mine where exceptions to the generic rules occur.

When a rule set of this type is first created, an empty rule table is
displayed in the right hand side of the schedule set-up window. To add
rules, the Display Main Database Tree checkbox should be ticked. This will
replace the schedule set up tree with a main database tree.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 15

 Once the tree view has been displayed, it can be expanded and collapsed
until the desired predecessor and successor records are visible. To add a
rule to the table, the successor record must first be selected in the tree by
clicking on it (it will be highlighted in blue). The associated predecessor
is then dragged into an empty row in the dependency rule table. If the
selected record has several predecessors, they should be dragged into
successive blank rows before the selected record (the successor) is
changed.

When the user is dragging predecessors into the table in this manner, the
cursor will show an invalid symbol until it is over a valid cell in the rule
table. When the cursor is over an empty row in the table, it changes to
an arrow with a plus (+) symbol.

Once a dependency rule has been created, both the successor and
predecessor records can be modified. This is achieved by dragging a
replacement record from the tree to the successor or predecessor
columns of the rule that must be modified. When the user drags a
replacement successor or predecessor over an existing record, the cursor
will change to an arrow (without a plus symbol) indicating this action will
replace the existing value rather than adding a new dependency.

Although the successor and predecessor records selected in absolute

address dependency rules are normally lower level records, this does not
have to be the case. The user is able to define an upper level record as
the successor, the predecessor or both the successor and predecessor.

16 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

16
 For example, if a model contains two pits and one of the pits must be
completed before the other can begin, it is easier for the user to create a
dependency rule directly between the two pits. XPAC will manage the
lower level dependencies required to implement this rule. The
precautions that should be taken when using dependency rules that
involve upper level records are described later in this chapter.

The rule table has columns for the successor and predecessor activities,
and when new rules are inserted, they are both given the default value of
All. This default can be changed in one or both of the columns, if the
rule must apply to specific activities.

Absolute address rules can also be placed into OR rule groups. As soon
as one of the rules within any such group has been satisfied, all the rules
in the group are assumed to have been satisfied. The properties of OR
rule groups are explained in more detail later in this chapter.

To create an OR rule group, the successor must be selected in the tree

view and the first predecessor must be dragged into a new row of the
table, as if a normal dependency is being created. Without changing the
selected record in the tree (the successor), the second predecessor in the
OR rule group should be dragged over the first predecessor with the
<CTRL> key pressed. The cursor will change to an arrow with a plus
sign.

This will add a new line into the table that shares the same successor
(indicated with a quotation ditto symbol (“) in the successor column. A
number will also be shown in the => column, indicating the number of
the OR rule group.

Absolute address dependency rules can also be created graphically, by

clicking on any 3D plot with the mouse. The graphics view is basically
used as a replacement for the database tree described above. This facility
only applies to absolute address rules sets and is described later in this
chapter.

The Lag list box under the rule table allows users to assign a delay to
each of the dependencies created by the rules in the set. The duration of
the delay is specified in calendar days and either a reference to a main
database field or an absolute value can be specified. If a main database
field is selected, a unique delay can be assigned to each record.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 17

 When a lag is assigned to a dependency, the successor will not become
available when the rule has been satisfied. This will be delayed by the
duration specified in the Lag list box, with the delay beginning the
moment the rule is satisfied.

The Release Profile list box under the rule window allows the user to assign
a release profile to the dependencies created by the rules in the set. A
release profile allows the successor record in each dependency to
become available for mining as soon as a specified percentage of the
predecessor has been mined. Release profiles are described in greater
detail later in this chapter.

The two additional tabs on the right hand pane of the schedule set up
window provides access to more advanced properties. The only
advanced option available with this type of rule set is Circular Reference
Testing, and this is described more fully later in this chapter.

Relative Address Dependency Rule Sets

This type of dependency rule set is used to define generic dependency

rules that are applied to a specified range of records (the Successor Range).
Instead of specifying the address of the successor and predecessor
records absolutely, the address of the predecessor record is specified
relative to the address of the successor record.

We use the APIL numbers on each level of the database to define the
location of each record in the deposit. This also provides a convenient
method of specifying the relationships (or APIL offsets) from one
record to a neighbouring record.

18 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

18
 When the same relationship between predecessor and successor repeats
over a section of the mine, the same rule can be used to create the
dependencies for every record in that section. A good example would be
the generic rule Block Above, which is applied to every record within an
open pit deposit.

To create a rule set of this type, Relative Address must be selected in the
Type list box. An empty rule table will then be displayed in the window.
The table has a column for each level in the database hierarchy as well as
columns for the successor and predecessor activities. The final column
indicates whether the rule is assigned to an OR rule group.

The database level columns are used to specify offsets that must be
applied to the APIL numbers of the successor block to obtain the APIL
numbers of its predecessor. Offsets for every level must be provided
and these are determined by subtracting the APIL of the successor
record from the APIL number of the predecessor record. The general
formula for these offsets is as follows.

 Offset (Level 1) = Predecessor APIL (Level 1) – Successor APIL(Level 1)

 Offset (Level 2) = Predecessor APIL (Level 2) – Successor APIL(Level 2)

 Offset (Level n) = Predecessor APIL (Level n) – Successor APIL(Level n)

Whilst these formulae will always generate the correct values, it is

normally just a simple case of determining what numbers (which could
be positive or negative) must be added to each of the successors APIL
numbers in order to find its predecessors APIL numbers.

Offsets must be specified for every level in the hierarchical database, but
often many of the offsets will be zero. For example, in an open cut coal
mine with a Pit/Strip/Block/Seam database structure, a rule is needed to
prevent any seam from being undercut by the seam below. A relative
address rule that achieves this would have an offset of –1 on the seam
level and an offset of zero on the other database levels.

Although this rule type does not require the deposit to have a regular
geometric blocking, its effectiveness can only be realised if the APIL
numbers are carefully chosen. For example, the development in an
underground deposit rarely has a regular geometric layout. However, if
the blocks along each drive are allocated sequential APIL numbers
(which is usually the case), a single rule can be used to assign most of the
dependencies required to control the mines development sequence.

Because rule sets of this type are generic, they will be applied to every
record in the specified Successor Range. The relationships between
successor and predecessor records must therefore be valid for every
block in this range. If different relationships exist in different portions
of the deposit, different rule sets must be created for each portion.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 19

 In most situations, each rule in a relative address rule set will create a
dependency for every record in the successor range. The main exception
is when the associated predecessor record does not exist and in this
situation, no dependency will be created.

Before the rule set creates a dependency, XPAC tests whether the
predecessor record occurs within the range specified in the Predecessor
Filter list box. If the predecessor record is within the range, the
dependency will be created as normal. But if the predecessor record is
not in the range, the dependency will not be created. By default the
Predecessor Filter range will be set to All, ensuring that every dependency
will be created.

Relative address dependency rule sets are usually used to create

dependencies between lower level records. But it is also possible to
define generic rules between upper level records using this type of rule
set.

For example, an open pit model with a Pit\Bench\Easting\Northing database

structure may require a rule preventing one bench from being mined
before the entire bench above has been completed. But this is difficult if
we do not know where one bench will be completed and where the next
bench will begin.

To define an upper level dependency, the columns representing one or

more database levels must be disabled. Right clicking on the appropriate
column and selecting the Disable Column option will disable the selected
column and all columns to its right (representing the levels below the
selected level).

20 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

20
 A number of precautions should be taken when using dependency rules
that involve upper level records. These are described later in this
chapter.

The activity columns in the rule table are assigned the default value All
when rules are first created, ensuring Every activity in the predecessor
must be completed before Any activities in the successor can be started.
This default can be over-ridden by selecting a different activity from the
drop down list provided when a cell in one of the activity columns is
clicked.

The Or Group Number column allows users to create OR rule groups using
relative address rules. By default, new rules are assigned an Or group
number of zero, indicating they are normal dependency rules. But if two
or more rules are assigned a unique number, they will be treated as an Or
rule group, and will all be satisfied as soon as one of the rules has been
satisfied. The properties of OR rule groups are explained in more detail
later in this chapter.

Each rule set can contain many rules, but they will all be applied to the
same successor range. If different rules must be applied to different
successor ranges, they should be placed in separate rule sets.

The Lag list box under the rule table allows users to assign a delay to
each of the dependencies created by the rules in the set. The duration of
the delay is specified in calendar days and either a reference to a Main
database field or an absolute value can be specified. If a main database
field is selected, a unique delay can be assigned to each record.

When a lag is assigned to a dependency, the successor will not become

available when the rule has been satisfied. This will be delayed by the
duration specified in the Lag list box, with the delay beginning the
moment the rule is satisfied.

The Release Profile list box under the rule table allows the user to assign a
release profile to the dependencies created by the rule set. A release
profile allows the successor record in each dependency to become
available for mining as soon as a specified percentage of the predecessor
has been mined. Release profiles are described in greater detail later in
the chapter.

As with the other types of rules, the two additional tabs on the right
hand pane of the schedule set up window provides access to more
advanced rule properties. Most of the advanced option can be used with
this type of rule set and these are described more fully later in this
chapter.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 21

 Absolute Bearing Dependency Rule Sets

When open pit deposits are modelled within XPAC databases, the
hierarchical structure is often based on the regular geological model used
for grade estimation and pit optimisation. In such instances, three of the
hierarchical database levels are usually used to represent the three
dimensional coordinates of each block within the models framework.

Open pit models commonly use three database levels to represent each
blocks Bench (Z coordinate), Easting (X coordinate) and Northing (Y
coordinate). Other levels may also be used, but these usually classify the
blocks into related groups such as pits, stages and material types.

In many instances, the APIL numbers used to represent the coordinates

of each block equal the number of whole blocks from a given origin
(commonly referred to as the blocks IJK numbers). In such cases the
APIL numbers of successive blocks in each plane increment by one.
This approach is also used by pit optimisation packages such as Whittle.

In some cases, the physical coordinates of each block’s centroid are used
as APIL numbers and the values assigned to successive blocks will
therefore increment by a value equal to the block size in the associated
direction.

Absolute bearing dependency rule sets were originally designed to

simplify the definition of dependencies within this kind of model, but
have also proved useful in other deposits that are subdivided into regular
3D grids.

To create a rule set of this type, Absolute Bearing must be selected in the
Type list box. A grid will then be displayed on the right hand pane of the
schedule set up window that represents a horizontal plane with North up
the screen. The central cell of this grid (coloured blue) does not
represent a particular block in the deposit. Instead it represents each
record in the successor range (the records the rule will be applied to).

22 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

22
 Three drop-down list boxes are used to specify which database levels
represent coordinates in the X, Y and Z axes. The entry in each must be
unique and in tabular deposits with only one block in the vertical plane,
None can be specified for the Z axis.

Each axis also has a multiplier text box, which is used to specify the
increment in APIL numbers between successive blocks in each direction.
They have a default value of 1 but this can be edited if the APIL
numbering system is not based on the number of whole blocks from a
given origin. Negative multipliers can also be entered if the coordinate
system does not increase in the standard direction (positive toward the
East, the North and upward).

To create a new rule in the rule set, the predecessor block relative to the
blue successor block must be selected using the mouse and the New Rule
button pressed. If the block immediately below the blue block were
selected, it would indicate the block to the South is a predecessor of the
blue block. When the rule is applied to a range, each block in the range
would be assigned a dependency that requires the block to its South to
be mined before it can be mined.

When a new rule is created or whenever the Edit Rule button is pressed, a
rule table is displayed showing all the rules within the set. This has
columns for each axis and for the successor and predecessor activities.
The offsets shown in the axis columns represent the displacements from
the successor to the predecessor. They are shown in whole blocks with
positive displacements in the standard directions, regardless of the value
or sign of the multiplier.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 23

 Because the grid represents the horizontal plane, it cannot be used to
specify vertical offsets and so by default, new rules are assigned a zero
displacement in the Z-axis. If the predecessor is above or below the
successor, the Z displacement should be adjusted in the rule table
accordingly.

The activity columns in the rule table are assigned the default value All
when first created, ensuring Every activity in the predecessor must be
completed before Any activities in the successor can be started. This
default can be over-ridden by selecting a different activity from the drop
down list provided when a cell in the activity column is clicked.

The Or Group Number column allows users to create OR rule groups using
absolute bearing rules. By default, new rules are assigned an Or group
number of zero, indicating they are normal dependency rules. But if two
or more rules are assigned a unique number, they will be treated as an Or
rule group, and will all be satisfied as soon as one of the rules has been
satisfied. The properties of OR rule groups are explained in more detail
later in this chapter.

Three additional columns in the rule table can be used to specify

alternative displacements for each rule in the set. These alternatives are
only required if pre-emptive circular reference testing is being used, and
this advanced option is explained in more detail later in this chapter.

When the rule table is closed (using the OK or Cancel buttons) the new
rule will be shown in the grid as a red block with an arrow pointing to it.
The arrows point to the predecessors (the red blocks) that must be
mined before the successor (the blue block) can be mined. If there are
two or more predecessors vertically above one another, the arrow is
shown in bold. When one of the selected predecessors is vertically
above or below the blue predecessor block, its colour is not changed, but
an arrowhead is displayed at the centre of the blue block.

24 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

24
 Before the rule set creates a dependency, XPAC tests whether the
predecessor record occurs within the range specified in the Predecessor
Filter list box. If the predecessor record is within the range, the
dependency will be created as normal. But if the predecessor record is
not in the range, the dependency will not be created. By default the
Predecessor Filter range will be set to All, ensuring that every dependency
will be created.

The Lag list box under the grid allows users to assign a delay to each of
the dependencies created by the rules in the set. The duration of the
delay is specified in calendar days and either a reference to a main
database field or an absolute value can be specified. If a main database
field is selected, a unique delay can be assigned to each record.

When a lag is assigned to a dependency, the successor will not become

available when the rule has been satisfied. This will be delayed by the
duration specified in the Lag list box, with the delay beginning the
moment the rule is satisfied.

The Release Profile list box under the grid allows the user to assign a
release profile to the dependencies created by the rule set. A release
profile allows the successor record in each dependency to become
available for mining as soon as a specified percentage of the predecessor
has been mined. Release profiles are described in greater detail later in
the chapter.

The two additional tabs on the right-hand side of the schedule set up
window provide access to more advanced rule properties. All of the
advanced option can be used with this type of rule set and these are
described later in this chapter.

Relative Bearing Dependency Rule Sets

Although absolute bearing rule sets can simplify the definition of

dependencies when the database represents a regular geological block
model, there are some inherent disadvantages.

Because the rules are specified relative to a Northerly orientated grid,

they are independent of the blocks face advance direction. Different
face advance directions will require different rule sets and if the face
advance directions change, the successor ranges allocated to each rule set
will require updating.

Although relative bearing dependency rules share many similarities with

absolute bearing rules, the predecessors are defined as offsets relative to
the blocks face advance direction, rather than relative to North. This
overcomes many of the disadvantages associated with absolute bearing
rule sets.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 25

 When Relative Bearing is selected in the Type list box of a new rule set, a
grid is displayed on the right hand side of the schedule set up window
that is identical to the grid used with absolute bearing rule sets.
However, the grid is orientated so the blocks face direction is up the
grid. The bearing of the grid will therefore be different for different
blocks.

In the example above, the three selected blocks are not relative to any
specific bearing. Instead they indicate that each block in the successor
range will have three predecessors; the Block Behind, the Block Behind and
Right and the Block Behind and Left.

Controls that are similar to absolute bearing rule sets are provided to
select the database levels for each axis and specify appropriate
multipliers. Furthermore, rules are created and edited in exactly the same
way as absolute bearing rules. To create a dependency, select the
appropriate block by clicking on it and then press the New Rule button.

Whenever the New Rule button or the Edit Rule button is clicked, the rule
table will be displayed. Again, the user must update the offset in the Z
direction, if the predecessor block is above or below the successor block.

26 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

26
 The activity columns in the rule table are assigned the default value All
when first created, ensuring Every activity in the predecessor must be
completed before Any activities in the successor can be started. This
default can be over-ridden by selecting a different activity from the drop
down list provided when a cell in the activity column is clicked.

The Or Group Number column allows users to create OR rule groups using
absolute bearing rules. By default, new rules are assigned an Or group
number of zero, indicating they are normal dependency rules. But if two
or more rules are assigned a unique number, they will be treated as an Or
rule group, and will all be satisfied as soon as one of the rules has been
satisfied. The properties of OR rule groups are explained in more detail
later in this chapter.

Three additional columns in the rule table can be used to specify

alternative displacements for each rule in the set. These alternatives are
only required if pre-emptive circular reference testing is being used, and
this advanced option is explained in more detail later in this chapter.

The most obvious difference between relative bearing and absolute

bearing rule sets is the additional Face Advance button, which displays the
Productive Activities dialogue when clicked.

The face advance bearing should be entered in the Advance Bearing

column, and although different values can be assigned for each activity,
they are usually all given the same value.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 27

 It is important to note that a blocks face advance direction is quite
different to its mining direction / elevation. Mining direction /elevation
is the bearing and inclination that each activity will be performed in
within the block. This is only used when constructing period progress
and mine status plots. But the face advance direction refers to the
overall direction the face in which the block occurs will advance.

As an example, consider an open cut coal mine that is subdivided into

strips that run East-West. A dragline will mine the blocks in each strip
along the strip, say toward the West. But the face will advance
perpendicular to the strips over time, say in a Northerly direction.

The face advance bearing is normally stored in a field of the main

database, allowing each record to have a unique value. To specify which
field the face advance bearing should be obtained from, the code of the
field should be entered in the Advance Bearing column of the Productive
Activities dialogue.

When a main database field is used to store the face advance bearing,
each record must be assigned an appropriate value, either using an XCM
script or by importing appropriate data.

The relative address method supports 8 face advance directions and

these should be entered as bearings in degrees. The eight valid face
advance directions are shown below along with the bearings that must be
used in the database field to represent them. If the bearing does not
match one of the eight standard face advance directions allowed, the
nearest valid face advance direction will be used.

FACE ADVANCE DIRECTION BEARING

North 0
North-East 45
East 90
South-East 135
South 180
South-West 225
West 270
North-West 315

When relative bearing rules are applied to each block in the successor
range, the grid is orientated to the blocks face advance direction before
the rule is applied. If the face advance directions are changed, the rule
set should be re-applied and the dependencies will be automatically re-
orientated.

28 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

28
 Before the rule set creates a dependency, XPAC tests whether the
predecessor record occurs within the range specified in the Predecessor
Filter list box. If the predecessor record is within the range, the
dependency will be created as normal. But if the predecessor record is
not in the range, the dependency will not be created. By default the
Predecessor Filter range will be set to All, ensuring that every dependency
will be created.

The Lag list box under the grid allows users to assign a delay to each of
the dependencies created by the rules in the set. The duration of the
delay is specified in calendar days and either a reference to a main
database field or an absolute value can be specified. If a main database
field is selected, a unique delay can be assigned to each record.

When a lag is assigned to a dependency, the successor will not become

available when the rule has been satisfied. This will be delayed by the
duration specified in the Lag list box, with the delay beginning the
moment the rule is satisfied.

The Release Profile list box under the grid allows the user to assign a
release profile to the dependencies created by the rule set. A release
profile allows the successor record in each dependency to become
available for mining as soon as a specified percentage of the predecessor
has been mined. Release profiles are described in greater detail later in
the chapter.

The two additional tabs on the right-hand side of the schedule set up
window provide access to more advanced rule properties. These
advanced options are more appropriate to this dependency rule type than
any other, due to the greater risk of generating circular references. These
advanced options are described in later sections.

Applying Dependency Rule Sets

The user can define as many rule sets as required, with any combination
of rule set types. Each rule set (other than absolute address rule sets)
also has a unique successor range, so they can be applied to specific
portions of the deposit.

Although dependency rule sets can be created using the All Items tab of
the schedule set up window, the Scenarios tab must be chosen to select
which rules will be used in each scenario.

Selecting the Dependency Rule Sets item in the tree structure when the
Scenarios tab is active will display a list of every dependency rule set in the
model. Each item has a checkbox to the left of its title and ticking this
activates the rule set for the current scenario.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 29

 Only the rule sets that are active in a scenario appear under the
Dependency Rule Sets item in the tree view. Dependency rule sets cannot
be deleted when the Scenarios tab is active and only checked rule sets can
be edited. To delete a rule set or edit a rule set that is not active in the
scenario, switch to the All Items tab.

When a dependency rule set is checked, the AutoScheduler immediately

applies the rules within that set and creates the dependencies they define.
Similarly, when the rule set is unchecked, the dependencies created by
that rule set are removed.

If a dependency rule set is edited when the Scenarios tab is active, two
additional buttons become available on the right hand side of the
window. These are called Apply Rule Set and Delete Rule Set and are
greyed when the All Items tab is selected. The example below shows an
absolute bearing rule set being edited with the Scenarios tab selected. The
additional buttons are provided for every type of rule.

30 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

30
 If a rule set is modified after it has been applied, the dependencies the
rule set creates will become out of date. The Apply Rule Set button re-
applies the rule, updating the dependencies it creates and should be
clicked whenever the rule set is modified. The Delete Rule Set button
deletes the dependencies that have been created by the rule set, but it
does not remove the rule set from the scenario and a checkbox remains
beside its name.

If a rule set is no longer up to date because it has been modified since it

was last applied or the dependencies it creates have been deleted, any
schedules that are run would give invalid results. To provide a visual
warning of this situation, the names of any rule sets that are out of date
and the name of the Dependency Rule Sets item are coloured red in the
schedule set up tree.

If a dependency rule set with a red name is re-applied, the colour of its
name is changed to black to indicate it has been brought up to date. If
there are no other rule sets with red names in the scenario, the colour of
the Dependency Rule Sets item in the schedule set up tree will also be
changed to black.

There are several other methods that can be used to apply and delete rule
set, as follows.
 The Scheduling | (Re)Apply All Rule Sets menu option will remove all
existing dependencies from the model and then re-apply all the rule
sets selected in the current scenario, in the order they appear in the
schedule set up tree.
 If the Scheduling | Remove All Rule Sets menu option is selected when
the Scenarios tab is chosen, all existing dependencies will be removed.
It should be noted this option does not remove the rule set from the
scenario, and a tick remains against that rule sets name. The name of
this rule set in the schedule set up tree will be turn red to indicate it
must be re-applied.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 31

  Right clicking the Dependency Rule Sets item in the schedule set up tree
displays a context sensitive menu containing the option Apply All
Rule Sets. This option has the same effect as the menu item with the
same name, described above.

Whenever the Dependency Rule Sets item in the tree is coloured red, the
dependencies within the model are not up to date. If a schedule is
executed when the model is in this state, a warning message is displayed
asking if the rule sets should be re-applied before the schedule continues.
In most situations, this option will be accepted.

Dependency Release Profiles

With normal dependencies, a successor will not become available until

100% of all its predecessors have been scheduled. But there are
situations when a successor should become available after only a portion
of its predecessors has been scheduled.

An example is in an open cut coal mine, where coal mining can begin as
soon as coal is exposed, regardless of whether the block has been fully
stripped or not. Release profiles are normally used for short term
scheduling, but are also useful for models that contain large blocks (for
example, an open pit that has been subdivided into whole benches).

Release profiles specify the relationship between the quantity of the

predecessor that has been mined and the quantity of the successor that
has become available (has been released). Usually a certain proportion of
the predecessor must be mined before the successor becomes available
and thereafter, the quantity of the successor released is proportional to
the amount predecessor that has been scheduled.

To allow these complex rules to be established in AutoScheduler models,

each dependency rule set can be assigned a release profile that defines
the relationship between the percentage of the predecessor that has been
scheduled and the percentage of the successor this must release.

To assign a release profile to a dependency rule set, the appropriate

release profile must be selected from the Release Profile drop-down list
when the dependency rule sets is being edited. Four pre-defined release
profiles have been provided as examples, but user defined release
profiles can also be added.

32 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

32
 To edit an existing release profile or create a new release profile, the
browse button beside the Release Profile drop-down list should be pressed.
This will display a window containing a list of available release profiles,
with buttons to create new profiles or edit, delete and rename existing
profiles.

To edit an existing rule, select it in the list and press the Edit button.

The table on the left of the window lists the data points in the release
profile and this is represented graphically on the right. The two columns
in the table contain the percentage of the predecessor mined at each
point in the profile and the percentage of the successor that will be
released (ie become available) at these points. Before the data in the
table can be edited, the Allow Modification checkbox must be ticked.

The properties of release profiles are quite straightforward, but they do

take some practice to interpret correctly. The graphical representation of
the release profile greatly assists with this.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 33

 The example shown above (20% Lag Proportional) contains four data
points. This profile should be interpreted as follows.
 The first data point at (0,0) is compulsory, as a release profile must
always have an origin. This indicates that before a predecessor has
been scheduled, none of its successor will be available.
 The second data point is at (20,0) and the line from the previous
point runs horizontally. This indicates that whilst the first 20% of
the predecessor is being mined, none of the successor will be
released.
 The third data point is at (100,80) and the line from the previous
point rises upwards at 45. This indicates that once twenty percent
of the predecessor has been scheduled, any further material
scheduled in the predecessor will release some of the successor
(makes it available).
The rate at which the successor depends on the slope of the curve,
and because in this case the line climbs at 45, the quantity of the
successor released will equal the quantity of the predecessor that has
been scheduled.
 The last data point at (100,100) is compulsory, as all release profiles
must have a termination point. This indicates that once the
predecessor has been completely scheduled, the remainder of its
successor will become available.
As the previous point had already reached 100% mined, the line
from the previous data point is vertical. This indicates that as soon
as the predecessor has been completely scheduled, the remaining
20% of the successor will become available.

In most situations, records in the database will have several dependencies

and some or all of these may have release profiles associated with them.
In these situations, the dependency that has released the smallest amount
of the successor will be applied.

As an example, consider a record that has two predecessors, both of

which have the 20% Lag Proportional release profile described above.

If 50% of one predecessor has been scheduled, but none of the second
predecessor has been scheduled, none of the successor will be released.
Even though the first dependency will allow 30% of the successor to be
mined, the second rule has not released any material and the smallest
released quantity is always used.

If 100% of the second predecessor is now scheduled, 30% of the

successor will become available. Even though the second predecessor
has now released 100% of the successor, the first predecessor will not
release more than 30% of the successor.

34 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

34
 Even though the many possible interactions between dependencies with
and without release profiles may appear complex at first, their
application is quite logical. Furthermore, the user is sheltered from the
complexities of the interaction between different rules.

Providing there is an adequate supply of material for all resources, the

state of all dependencies with release profiles will be updated whenever
they must select a new scheduling step.

But if a resource is waiting for material to become available, this

approach is not suitable. Material could become available at any point in
time (not necessarily at the end of a scheduling step) and once a record
has become available, the quantity of material released will generally
increase continuously.

It would be impractical for the Autoscheduler to monitor dependencies

with release profiles on a continuous basis and instead, the status of
these dependencies is updated periodically as the schedule progresses.
By default, the time period between successive release profile updates is
set to 1 day of scheduling time, but this can be modified by selecting the
advanced button on the Release profile management dialogue. This
should not be confused with the advanced button beside the Release
Profile drop-down list box on the dependency dialogue.

When the advanced button is clicked, a dialogue opens which allows the
user to change the Time Step value from its default setting of 1 day. It
should be noted that this setting is only used when a resource is delayed
and other resources are scheduling records that have dependencies with
release profiles assigned to them.

We do not recommend this setting is changed unless there is a specific

reason for doing so.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 35

 Release Profiles With Upper Level Dependencies

When release profiles are applied to standard dependency rules, the

behaviour of the rules are fairly straightforward. But they can become
quite complex when release profiles are assigned to dependency rules
that to refer to upper level records.

By default, XPAC will always rationalise dependency rules applied to

upper level records to the fewest possible lower level dependencies that
would achieve the same outcome. If a release profile was assigned to the
upper level dependency, the same profile will be assigned to all the lower
level dependencies this rule creates.

In this configuration, the trigger quantity must be scheduled from each

of the lower level predecessors before any of the successor(s) becomes
available. Thereafter, the quantity of the successor that is available will
equal the smallest quantity released by the various predecessors.

In the following example, an upper level rule ensures that when an upper
level predecessor (containing children A and B) is scheduled, material
from the upper level successor (containing children C and D) will be
released. This rule uses the 25% Lag Proportional release profile. For
simplicity we will assume all 4 records contains the same ore quantity.

40% Mined 60% Mined

(releases 15%) (releases 35%)

A B
100 25% Lag Proportional

75
% Released

50

25

0
0 25 50 75 100
% Mined

C D
15% Released 15% Released

Because the release profile is applied to each lower level dependency the
upper level rule generates, each dependencies release profile will be
evaluated independently of the others.

36 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

36
 In the example, 60% of record B has been mined which releases 35% of
records C and D. But only 40% of record A has been mined and this
only releases 15% of records C and D. When determining how much of
the successor record can be scheduled, XPAC will always apply the rule
that has released the smallest quantity of material (in this example 15%).

Whilst this approach can be very useful, there are situations where the
total quantity mined and total quantity released apply directly to the
upper level records, rather than to their children individually. The mined
quantity would now be considered as the total quantity mined from all
the children of the upper predecessor record. The quantity released
would also be allocated to the upper level successor, to be shared
between all its children in any combination.

When the release profile must be applied in this manner, the Advanced
Release Profiles dialogue should be opened by clicking the Advanced…
button beside the Release Profile list box in the dependency dialogue.

The Use Upper Level Profiles checkbox must be ticked and accumulation
fields must be selected for each activity the release profile applies to.
These are usually the accumulation fields used by the resources mining
those activities, but the user can choose different fields if required. They
are applied to each activity independently of one another.

If these settings were applied to the previous example, the material

scheduled from all of the predecessors children is 50% of the total.
When this value is applied to the release profile, the quantity of material
released from the successors is 25% of the successors total.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 37

 50% Of Total Mined (releases 25%)
40% Mined 60% Mined

A B
100 25% Lag Proportional

75

% Released
50

25

0
0 25 50 75 100
% Mined

C D
Up to 50% Up to 50%
released released
Max 25% of Total Released

Although the total quantity of the successor that is released is only 25%,
this can be shared between the successors children in any combination.
50% of record C could be scheduled without any material scheduled
from record D. Conversely, 50% of D could be scheduled with no
material from record C being scheduled. Any combination between
threes two extremes could also apply.

OR Rule Groups (Alternative Rules)

Although each record can be assigned many predecessors using a

combination of rule types, 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 … have all been scheduled. This is shown graphically below.

Predecessor Predecessor
B C

Successor
A

Predecessor Predecessor
? D

38 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

38
 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 … has been mined. This is shown graphically below.

Alternative
Predecessor
B1

Alternative
Predecessor
Successor C1
A

Alternative
Predecessor
D1

Alternative
Predecessor
?1

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.

Predecessor Predecessor
H I

Alternative
Predecessor
B1
Alternative
Predecessor
G2
Successor Alternative
Predecessor
A C1
Alternative
Predecessor
F2
Alternative
Predecessor
D1

Predecessor
E

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 called its

Group Number and each rule within an OR rule group must be assigned
the same group number. These numbers are specific to the rule set in
which they occur and the same group number can therefore occur in
different dependency rule sets. But different OR rule groups in a single
dependency rule set must have unique numbers.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 39

 With script rule sets, specific XCM functions have been provided to
examine and create OR rule groups. These make use of the group
number and the user is responsible for the allocated of group numbers
to each OR rule group. A detailed description 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,

XPAC automatically assigns a new group number when a second
predecessor is added to a dependency rule.

Before an OR rule group can be created, a normal dependency must be

created containing the groups successor and the first of its alternative
predecessors. 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. This process has been described in more detail earlier in
this chapter.

Once the 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.

40 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

40
 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
blank row.

To help the user identify which predecessors occur within groups, a

thick separating line is drawn in the table between each normal rule and
between 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 is shown in the central
column.

Or rule groups can also be created using relative address, absolute

bearing and relative bearing dependency rule sets. With relative address
rule sets, a column is provided in the rule table where the user can
specify the group number.

The rule table in absolute bearing and relative bearing rule sets also have
a group number column, but the user must add a new rule or edit an
existing rule in order to display the rule table.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 41

 By default, new rules in are assigned a group number of zero, indicating
the rule is not part of an OR rule group. But if this is changed to a value
of 1 or greater, the rule is assumed to be part of an OR rule group.

If there are two or more rules with the same group number, XPAC will
assume they are all satisfied as soon as one of their predecessors has
been scheduled. In the following example, each block will become
available as soon as one of the four blocks adjacent to it has been
scheduled.

Each dependency rule set can contain any number of OR rule groups as
well as any number of normal rules. The user must simply give the rules
in each OR rule group a unique group number. The normal dependency
rules in the rule set must have a group number of zero.

The management of OR rule groups introduce some complex

mathematical problems, particularly regarding the validation of rules and
the detection of circular references.

42 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

42
 When there are no OR rule groups in a model, 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.

 1 group of 2 alternative rules 2 dependency networks.

 10 groups of 2 alternative rules 1024 dependency networks.
 100 groups of 2 alternative rules 1.2 x1031 dependency networks.

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.

Viewing Dependency Rules

Dependencies can be viewed in a table or on a graphical plot. Both

methods have their advantages and disadvantages. The Schedule
Analysis tool also contains a form that allows a user to view how
dependencies are being satisfied. This is particularly important when
confirming rules has been implemented correctly and is described later in
this users guide.

Using The Dependencies Window

To examine individual dependencies, the Dependencies window should be

opened using the Scheduling | Dependencies menu option.

This will open a window with a database tree structure in the left pane.
When a record is selected in the tree, its predecessors are listed in the
right pane. Clicking the Show Successors check box will display the
successors of the selected record after its predecessors. In the window,
the record selected in the tree is shown in black, whilst its predecessors
are shown in red and its successors are shown in blue.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 43

 The user is able to filter the dependencies so that only those generated
by the selected rule sets are displayed. The default option is All – No
Rule Information, which displays every dependency, but does not indicate
which rule set created it. The user can also select the option All, which
will include the name of the rule set that created the dependency, but this
additional information does make the window respond a little slower.

The records in the database tree are usually shown in black. But if a
circular reference exists in the model, the colour of records within the
circular reference will be shown in red. Parents of the records within a
circular reference are also shown in red, making it easy to identify where
they occur in a model. This requires the Circular Reference Record Colouring
checkbox in the Global Options dialogue to be ticked.

Viewing Dependencies Graphically

Dependencies can be viewed graphically on any polygon graphics plot.

This feature is controlled using the Dependency tab in the polygon graphics
template.

By default, no dependencies will be display on the polygon graphics

drawing but the user can choose to display predecessors, successors or
both. The later option is only appropriate when chained dependencies
are being displayed.

44 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

44
 If the user selects the Predecessors option, red arrows will be drawn that
point from each block to each of their predecessors. If the user selects
the Successors option, blue arrows will be drawn to each block from each
of their successors. In both cases the arrow is drawn From the successor
To the predecessor, reinforcing the principle that dependencies are
always defined by selecting a blocks predecessors and never its
successors.

If the user selects the Both option, both the red and the blue arrows will
be displayed. When both a red and a blue arrow join two records, the
colour of the arrow is changed to magenta. This option is only really
appropriate when the Show Dependencies For Selected Records Only checkbox
is ticked.

If a dependency has any special properties assigned to it (for example, if

it is in an OR rule group or has a release profile) it will be displayed in
pink or light blue, depending on whether it is pointing to a predecessor
or from a successor.

If the user selects the Predecessors, Successors or Both options, the user can
select which rule sets should be displayed on the plot. If the Display All
Rule Sets checkbox is selected, the checkboxes for each individual rule set
will be greyed and the plot will display every dependency in the current
scenario.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 45

 If the user selects a sub-set of the rules that have been applied to the
scenario, XPAC will re-optimise the selected rules. This may result in
the plot displaying different dependencies to those within the current
scenario. Because of this, the selection of specific rules is normally used
to view the effects of one or two rule sets before adding it to a model.

If the Show Dependencies For Selected Records Only checkbox is ticked,

dependencies will only be shown for the records that have been selected
in the plot. When this option is selected, the user can choose to display a
chain of dependencies limited to a specified maximum depth. This
option is very useful when the model contains a large number of
dependencies and displaying all of them would result in an over-cluttered
and confusing image.

46 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

46
 If a dependencies successor or predecessor record is not included in the
plots range, the dependency will not be displayed on the plot.

If the Show Dependencies For Selected Records Only checkbox is not ticked,
every dependency between records in the plots range will be displayed as
an arrow. As there can be thousands of dependencies in the model, this
checkbox is normally left ticked.

The user has several options regarding the quality of the arrows used to
represent dependencies. High quality arrows are better when plots are
rotated in 3D, but they do take longer to render. When high quality
arrows are selected, the arrows shaft and head size can be adjusted
separately. The head of the arrow can also be moved away from the
centroid of the predecessor a small distance, to avoid them getting
confused with other dependencies that point to the same record.

The following example shows a split graphics window containing an

isometric view of a portion of the deposit and a section through it. The
red arrows point from the selected block to its predecessors whilst the
blue arrows point from its successors to the selected block. The selected
block is shaded.

It should be noted that all arrows point to predecessors, regardless of

their colour. Users sometimes find this convention confusing when they
first display dependencies on a plot, as the arrows point backwards,
opposite to the face advance direction. But it quickly becomes quite
intuitive and reinforces the principle that dependencies are always
defined by stating the predecessors of a block and never its successors.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 47

Creating Dependencies Graphically

Generic dependency rules that are applied to large areas of a mine are
normally responsible for creating most of the dependency rules in
AutoScheduler models. These types of rules are very flexible and each
one can create many thousands of individual dependencies.

But at most mines there are areas that do not follow the general rules.
Although script rule sets are commonly applied in these areas, it is often
simpler to create the dependencies manually using absolute address rule
sets.

The standard method for creating absolute address dependency rules is

to drag predecessors from a database tree, after the successor has been
selected. Although this is very efficient, it is sometimes more intuitive to
select the records from a graphical image of the deposit. This is
particularly true in mines where the deposit has been subdivided in an
irregular manner or where the record names do not indicate their relative
positions.

The AutoScheduler allows any polygon graphics image to be used to

create dependency rules, with all standard graphics tools such as colour
coding and record annotation available. Furthermore, the tools allow
both standard dependency rules and OR rule groups to be created.

When creating dependency rules graphically, the Dependencies docking

windows must be used. The docking windows provided in polygon
graphics are very useful, but can be difficult to master initially. Some
hints on their use have therefore been provided at the end of this
section. These can also be found in XPAC’s on line help system.

Preparing To Create Dependency Rules

Before dependency rules can be created graphically, the polygon image

that will be used to define the dependencies must be displayed. A new
template can be created for this purpose or an existing template can be
used. The graphics window should be maximised when creating
dependency rules to provide an adequate display area and the docking
windows must also be well organised.

The Dependencies tab in each polygon graphics templates is used to

control how dependencies are displayed on the graphics image. We
recommend the following settings are initially chosen when the polygon
image is being used to create dependencies. Once the image has been
displayed, some changes may be required, particularly to the arrow size
settings.

48 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

48
  The Predecessors option should be chosen in the Display Dependencies
frame, with the Display All Rule Sets checkbox ticked.
 The Show Dependencies For Selected Records Only checkbox should not be
ticked.
 High quality arrows should be selected with a Head Size and Shaft Size
for the arrows set to fairly low values (say 5 and 1). These will have
to be adjusted to suit the size of the blocks being displayed.
 The Position Arrow Head Away From Block Centre checkbox should be
ticked.

We also recommend that shading is not used in the image unless

absolutely essential as it can obscure the dependency arrows that are
drawn between the centroids of related records. If shading is being used,
the extrusion depth should be set to zero and large, high quality arrows
should be used.

Once the plot has been displayed, the Dependencies mode button should
be pressed and the Dependencies View should be opened. This can either
de docked to an edge of the screen or left to float over the image.

In most instances, all other docking windows should be closed. The

only exception is the Polygon Tree View, which may be required
occasionally when switching between different parts of the deposit
(switching between benches in an open pit, for example) after setting
appropriate options in the Graphics | Tree View menu.

Most users will determine the window layout that best suits their
requirements. A good starting point is with both the Dependency View and
the Tree View docked on the right hand side of the screen, with the Tree
View on the bottom. The window splitter should also be adjusted so the
full width of the Dependency View is visible.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 49

 The Tree View is normally left hidden, but can be displayed simply by
pressing its button on the tool bar. When this is done, the graphics
window does not change size and the image does not have to be re-
drawn.

As we wish to use this plot to display a number of dependencies, the

Show Dependencies For Selected Records Only checkbox should not be ticked
in the polygon plots template. You can display and modify the template
at any time when a plot is visible by pressing the <F4> key. Changes that
are made to the template of an open plot are not saved unless the save
option is selected.

The docking dependency window has a number of settings that specify

which dependencies should be displayed when creating dependencies
graphically and to which rule set the new rules should be added. This
window is shown in its undocked state below.

50 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

50
 The Scenario drop down box is used to select the scenario that will be
used when dependency rules are created. The active scenario is selected
by default and it is rarely changed.

The View Rule Set drop down list box defines which dependencies will be
displayed in the polygon view whilst the dependencies are being created.
This setting only applies when the Dependency Rule View is visible and
over-rides the settings defined in the Dependency tab of the polygon plot’s
template. The following options are available.

 None: Will not display any dependency arrows in the graphics image.
 Selected Rules: Displays arrows to represent dependencies that will be
created by the rules currently selected in the Dependencies View. The
user can select multiple rows in the use the Dependencies View using
windows standard methods (ie holding the <Ctrl> or <Shift> keys
whilst clicking on rows.
 Edit Rule Set: Displays arrows that represent the dependencies that
will be created by the rule set currently being edited. This is the most
common selection.
 Scenario Rules: Displays arrows that represent every dependency
defined in the selected scenario.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 51

  Individual Rule Sets: An entry is provided in the drop down list box for
every Absolute Address rule set in the active scenario. When one of
these items is chosen, arrows that represent the dependencies that
will be created by the chosen rule set will be displayed.

The Edit Rule Set drop down list box is used to specify the rule set where
new rules will be added. This can be any existing rule set, providing it
has the type Absolute Address and is active in the selected scenario.
Alternatively the <New Rule Set> option can be selected, which will
automatically create a new Absolute Address rule set and prompt for an
appropriate name.

The two Activity drop down boxes are used to specify the default
predecessor and successor activities that will be assigned to any new
rules added graphically. By default, these are set to All, but they can both
be changed. The activities assigned to each rule can also be changed
individually, after the rule has been created.

The Release Profile list box allows a release profile to be assigned to each
of the dependencies created by this rule set. Any release profile can be
selected or a new release profile can be created. However the same
release profile will apply to all rules within the set.

Creating Dependency Rules Graphically

The rule table in the Dependency Rule View is similar to the one used for
Absolute Address rule sets in the schedule set up window. This shows
any rules that already exist in the rule set being edited (the one selected in
the Edit Rule Set drop-down list box) and any new rules that are added to
it.

To create a new rule, the user must first select the successor record by
clicking on it. The colour of the selected block will change to blue, to
emphasise the selected successor block.

To help identify blocks in the image, the record name is displayed in a

tool tip for 15 seconds when the mouse is held over a block for a few
seconds. The name is also shown in the status bar and this remains as
long as the cursor is over the record. Additional information from any
combination of fields can be also displayed with the record names by
selecting a transposed field selection template in the Fields drop down
box on the tool bar.

Once the successor has been chosen, its predecessors are selected by
clicking on them with the <Ctrl> key pressed. Each of the selected
predecessor blocks will change colour to red to emphasise them. The
cursor will also change to an arrow with the word AND when the <Ctrl>
key is pressed, indicating that standard dependency rules are being
defined.

52 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

52
 Once all the predecessors have been selected, the rules can be added to
the rule set by selecting the successor block (the block coloured light
blue) for a second time, with the <Ctrl> key still pressed. This places a
rule in the rule table for every selected predecessor, all with the same
successor.

There is no need to drag blocks from the polygon image to the

dependency rule table, as is required when creating dependencies in the
schedule set up tree. Simply selecting the successor record a second time
will automatically transfer the dependency rules to the table. This
approach is much faster when creating dependencies graphically.

OR rule groups can also be created graphically, following a very similar

process. The successor must again be selected first, but the <Shift> key
must be pressed when the predecessors are selected. The cursor will
change to an arrow with the word OR and when selected, the predecessor
blocks will change colour to pink to help emphasise them.

When the successor record is selected for a second time (with the <Shift>
key pressed), a single OR rule group will be added to the rule set
containing all the selected alternative predecessors.

The type of rule set created (standard rules or an OR rule group) depends
on whether the <Ctrl> or <Shift> key is being pressed when the successor
is selected for the second time. Even if the <Ctrl> key was being pressed
when the successors were selected, an alternative rule group will be
created if the <Shift> is being pressed when the successor is selected for
the second time. It doesn’t really matter which key is pressed when the
predecessors are chosen, providing the correct key is pressed when the
successor is clicked a second time and the rules are added to the list.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 53

 Using The Docking Graphics Views

There are seven docking windows (or views) associated with each
graphics template that either display useful information or allow the view
to be used interactively.

These views are extremely flexible and once their basic properties have
been mastered, they help maximise the screen space available to display
the polygon plot when other activities are being performed. The
docking windows available are as follows.

 Legend
 Polygon Tree View
 Polygon Transfer View
 Input Path View
 Dependency View
 Animation Control Bar
 Animation Path View

Buttons are provided that toggle the visibility of these windows and
similar menu options are available in the Graphics menu.

Some of the views are not appropriate in all situations and their button
/menu option may appear greyed. Specifically, the Dependencies view can
only be selected when Dependencies mode is chosen and the Animation
Control and Path views can only be chosen when a path has been loaded
for animation.

Each of these windows can be docked along any edge of the screen
(along the sides, below the tool-bars or above the status bar) or they can
be positioned so they float over the polygon view. We recommend the
polygon window is maximised when these windows are being used.

It is useful to understand the following properties when starting to use

these docking windows.

 When a window is made invisible by clicking its visibility button on

the tool bar, it will be restored to the same location when it is made
visible again. The docking windows can therefore be hidden to
preserve screen space, but remain readily accessible.
 The visibility and location of the windows associated with each
template are stored with that template and will be restored the next
time it is opened.
 Double clicking the title bar of a floating window or the edge of a
docked window will change it from floating to docked, or vice versa.

54 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

54
  Floating windows can be docked by dragging them to the
appropriate side of the screen. Once docked, they can be re-sized by
pointing to the frame of the window and dragging once the re-size
cursor is shown.
 Docked windows can be dragged off the edge of the screen (either to
another edge or to a floating window) by dragging any edge of the
window.
 If you want to drag a window beyond the applications frame, the
<Ctrl> key should be pressed whilst dragging. They will not dock
whilst this key is being pressed.
 When these windows are being dragged, the outline of the window is
shown. If the outline is shown as a thin black line, the window will
dock when the mouse button is released. If the outline is a thick
grey line, the window will float when the mouse button is released.
 More than one window can be docked to the same edge of the
screen. In this situation, the space allocated to each window can be
adjusted by dragging the divider bar.

Circular Reference Testing

Suppose we define two dependencies such that A is a predecessor of B

and B is a predecessor of A. This will prevent both records A and B from
ever becoming available. We call this situation a Circular Reference and
must obviously avoid them in AutoScheduler models.

When a record is dependent upon itself, a circular reference exists with a

length of 1. When two records are dependent upon one another, the
length of the circular reference is two. Circular references can have any
length.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 55

 Length 1
Record A A is Dependent On Itself

Length 2
Record A Record B A is Dependent On B
B is Dependent On A

Record A Record B
Length 3
A is Dependent On B
B is Dependent On C
C is Dependent On A

Record C

Because a record within a circular reference will never become available,

it will never be scheduled. Furthermore, any records that are dependent
on any of the records in the circular reference will never be scheduled,
nor the records dependent on them and so on.

Record G Record H

Record F

Record E Record I

Record A Record B

Record D Record J

Record C

Record L Record K

Record P Record O Record N Record M

56 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

56
 This is clearly an undesirable situation, but it can occur, particularly when
the dependencies derived from several complex rules interact. Two
techniques are currently available to help users avoid circular references.
The first is simply the detection of circular references, so that users can
refine the rules and therefore avoid the circular references. The second
technique involves filtering out the dependencies generated by a rule, if
they would create circular references.

Standard Circular Reference Testing

To test if there are any circular references within a models dependencies,

the Scheduling | Scan For Circular References menu option can be selected.
This rapidly scans through every dependency within the current scenario
and generates a report outlining the records within the each circular
reference it finds. If there are a large number of dependencies, XPAC
will not display all the rules, although the user will be warned about this
situation. The information in the circular references report must be used
to help rectify the problem by identifying why the current set of
dependency rules created a circular reference.

It is important to note that circular reference testing is performed using

the dependencies in the current scenario and not the rules that created
them. If a rule has been temporarily removed, the dependencies it
creates will not exist in the current scenario and will not be included in
the circular reference test.

Standard circular reference testing can also be performed whenever a

rule set is applied. To use this facility, the rule set must be edited and the
Circular Reference Checking tab should be selected. The options are not
available with script dependency rule sets, although XCM functions are
available that allows the script to perform this function itself.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 57

 Standard circular reference testing is not active by default, but two
options are available for rule sets whose type is not script.

If the After Every Rule option button is selected, a scan for circular
references will be performed once every rule in the set has been applied
to each records in the specified range. This is the standard option and
when applied, the time required to apply the rule set will increase.

If the Every Single Dependency Instance option is chosen, a scan for circular
references will be performed whenever a dependency is created. This
option causes a significant increase in the time required to apply the rule
set.

Under normal circumstances, these options would not be applied to

dependency rules, as the reduction in speed when the rule set is applied
would be unacceptable. Instead, a full circular reference scan would be
performed after all rule sets in the current scenario had been applied. If
a circular reference was detected during this scan, individual rule
scanning can then be used to help identify which rule set (or
combination of rule sets) resulted in the circular reference.

58 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

58
 Pre-emptive Circular Reference Detection

Circular references rarely occur as a result of absolute address rule sets,

as the user has considered the implications of each individual rule. But
this is not the case with the generic rule sets that are defined for a small,
idealistic portion of the mine but are applied to large areas with varying
geometry.

When Relative Bearing rule sets are used, the risk of generating circular
references increases significantly. It is very easy to repeatedly modify the
face advance directions when using this type of rule and it is easy to
overlook the implications associated with this.

Problems occur most frequently along boundaries between areas with

different face advance directions. For example, if two areas have
opposite face advance directions and the block behind is specified as a
predecessor, a line of circular references would be created along the
boundary of the two areas.

A typical characteristic of this type of circular reference is that they have

a length of two and occur when the face advance bearings of two
adjacent records move away from one another at an angle of 90 or
more. It is not uncommon to obtain many thousands of circular
references in these situations and normally they result from the same
combination of rules.

Pre-emptive circular reference detection overcomes this problem by

determining in advance whether the rules in any given rule set will cause
circular references. If they will, remedial action is taken to avoid the
problem arising.

Although very powerful, the facility is only available for Absolute Bearing
and Relative Bearing rule sets. Furthermore, it will only test for possible
conflicts between the rules in a single rule set.

By default, pre-emptive circular reference detection is not active and if it

is required, the option button associated with one of the three operating
modes should be selected.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 59

 If pre-emptive circular reference detection is active, the AutoScheduler
evaluates whether the rules within the current rule set will create any
circular references. If it finds that a circular reference will be created, the
remedial action it takes will depend on which operating mode has been
chosen. Only rules within the current rule set are tested in this manner
and dependencies generated by other rule sets are not included in the
test.

If the Omit Rule option was chosen, a dialogue will be displayed when a
circular reference is found that asks which of the two rules forming the
circular reference should be omitted. The dependency created by the
selected rule or rules will then be omitted from the model.

Because this type of circular reference usually occur in groups, many

similar circular references are likely to occur in the model. To avoid
having to select the same option many times over, the Apply Action To
All Identical Circular References check box can be ticked. Thereafter, if a
circular reference is found as a result of the same pair of rules applied to
blocks with the same face advance bearings, the dialogue will not be re-
displayed. Instead, the previous response will be used.

Despite this option, there are still many different combinations of

mining directions and rules that can cause a circular reference. To avoid
the need to select which rule to omit each time a new combination is
found, the Don’t Ask (Omit Both Rules) check box can be ticked. In this
configuration, both of the dependencies that would have caused the
circular reference will be omitted from the model.

Whilst this option may appear quite drastic, only a small number of rules
are omitted and many thousands of rules will remain. Because of this,
omitting both rules seldom has any significant impact on the face
advance profile.

60 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

60
 An alternative to the Don’t Ask (Omit Both Rules) option is the Don’t Ask
Again checkbox. When ticked, the user will only be asked which rule to
omit when the first circular reference is found. Thereafter, the same
response will be used for all subsequent circular references that are
detected. As the choice of rule to omit usually has very little impact on
the overall schedule, this is a common option when the Don’t Ask
checkbox is not selected.

If the Run Script option is selected when a circular reference is detected,

the AutoScheduler will not create the dependency. Instead, an XCM is
executed allowing the user to evaluate the circumstances that caused the
circular reference and take the most appropriate action. Whilst this
option is very flexible, it is seldom used.

If the Apply Alternative Rule option is selected when a circular reference is

detected, the AutoScheduler will apply the alternative rule associated
with the rules that would cause the circular reference. If the alternative
predecessors exist, a dialogue will be displayed asking which rule should
be replaced by it’s alternative. Again a check box can be ticked to avoid
having to select an option if a similar circular reference is detected and a
Don’t Ask Again checkbox can be ticked to force the same response to
be used for all subsequent circular references.

If the Don’t Ask (Apply Both Rules) check box is ticked, the dialogue box
will not be displayed and instead, both of the dependencies that would
have caused the circular reference will be replaced by their alternatives.

An alternative can be defined for each rule in the rule set by clicking the
Edit Rule button when defining any absolute bearing or relative bearing
rule set. Three alternative rule columns are provided in the rule table
where alternative offsets in the X, Y and Z directions should be
specified. These columns are greyed unless the Apply Alternative Rule pre-
emptive circular reference testing mode has been selected.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 61

 The alternative rules used in this pre-emptive circular reference testing
mode should not be confused with the alternative dependencies that
form OR rule groups.

Limitations When OR Rule Groups Are Used

Although circular reference testing is an invaluable tool for detecting

problems within complex models, there is one limitation when there are
rules in OR Rule Groups.

The number of alternative dependency networks increases exponentially

as the number and complexity of the OR rule groups increases, making a
rigorous test prohibitive in all but the simplest cases.

Currently, circular reference testing will only include dependencies that

are created by standard dependency rules. Dependencies created by
rules within OR rule groups are ignored. This small limitation will be
addressed in a future release of the package.

Hole Scanning

When relative address, absolute bearing and relative bearing rule sets are
used, dependencies are not created unless the associated predecessor
record does not exist in the database. Whilst this is usually the most
appropriate response to the missing block, it can cause unwanted
behaviour in certain situations.

Where topography intersects the upper benches of a model, holes can

occur in the effected benches. If all the predecessors of blocks around
the hole are missing, they will not be assigned dependencies and will
therefore be treated as available blocks. Similar effects can also be seen
around the edges of irregular shaped deposits.

62 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

62
 Year 1
Year 2
Year 3
Face Advance Year 4
Direction Year 5

Areas Scheduled
Prematurely

When this situation occurs, the blocks are often scheduled too early,
normally in V shaped areas in the lee of holes and to prevent this from
occurring, specific rules must be defined for each area.

Hole scanning techniques are used to avoid the need for these specific
rules. They function by iteratively applying the appropriate dependency
rules to missing blocks until an appropriate record is found. A number
of alternative methods have been provided to perform this function and
these are assigned on the rule sets Circular Reference Checking tab. These
methods are only available to relative address, absolute bearing and
relative bearing dependency rules sets.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 63

 Another valuable use for hole scanning occurs when records in the
database do not necessarily have sequential APIL numbers and the next
record in the database hierarchy should be used as the predecessor,
rather than a record with a specific APIL. An example of this situation
is in open strip coal mines, where seams can be missing due to geological
factors or seam aggregation.

By default, hole scanning is not active and if required, the option button
associated with one of the four scanning methods should be selected.
Each method is different and their effectiveness varies in different
circumstances.
 Missing Block Scanning is the simplest method and is the most
commonly used. If a rule points to a predecessor that is missing, the
rule will be re-applied from the location of the missing predecessor
rather than the successors location. The scanning process repeats
until a block is found or the maximum number of iterations specified
in the Scan Range text box is reached. If a block is not found during
the scanning process, a dependency will not be created.
 Block Behind Scanning takes a similar approach, but rather than
applying the rule to the location of the missing block, it is applied to
the block behind the successor, based on it’s face advance direction.
The scanning process continues to apply the rule to blocks further
behind until a predecessor is located or the scan range is exceeded.
 Side Scanning is quite different to the other methods and is more
suited to large holes. If this technique is used and the desired
predecessor record is missing, the AutoScheduler will scan from side
to side, looking for an alternative predecessor. It first looks for the
block behind and left, then behind and right. If neither of these
exist, it will look for a block behind and two to the left, then behind
and two to the right. This process will be repeated until a suitable
predecessor is found or the scan range is exceeded.
 The Run Script option is provided as an alternative when the pre-
defined hole-scanning methods are not suitable. If this option is
selected, a script will be executed whenever a missing block is
encountered, allowing the user to evaluate the circumstances and
take the most appropriate action.

Two additional option buttons have been provided to further customise

the behaviour of the hole scanning methods. By default, the Apply After
Each Rule option is selected which causes hole scanning to be performed
whenever a predecessor block is missing. But if the Apply Only After All
Rules option is selected, no hole scanning will occur unless all of the rules
in the rule set point to missing blocks.

64 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

64
Adjacency Tables

Adjacency tables provide additional control over dependency rules that

point between different stages, push-backs or other pre-defined
groupings within the deposit.

Often, records in each stage or push back are mined independently of

one another and dependencies should not be created between them. For
example, if a pit is being mined in three stages, mining usually
commences with stage 1, followed by stage 2 and then stage 3.

When generic dependency rule sets (relative address, absolute bearing

and relative bearing) are used to create the dependencies, it can
sometimes be difficult to prevent (or filter out) the rules that would
make stage 1 dependent on stage 2 and 3 (or stage 2 dependent on stage
3). Adjacency tables address this issue and two options are available,
depending on how the blocks have been allocated to stages or groups, as
follows.
 A database level is used to classify the deposit into different groups.
Although generic dependency rules can determine the PIL numbers
of the predecessor on the levels used to represent its X, Y and Z
coordinates, it cannot determine the PIL number on the stage level.
As a result, no dependencies will be created that cross a stage
boundary, even if they are required.
 A field in the database is used to classify the deposit into different
groups. Generic dependency rule sets will not identify to which
grouping each record belongs and will therefore create all
dependencies, whether they cross group boundaries or not.

As the approach taken in each case differs slightly, they are discussed
separately.

Adjacency Tables Classified By A Database Level

When a database level is used to classify the deposit into groups, generic
dependency rules will assume the predecessor is located in the same
group as the successor. If this is not the case, it will not be able to locate
the predecessor, even though its physical location (its PIL numbers on
the levels used to represent its X, Y and Z coordinates) are known.

For example, in a model with a Stage/Bench/Northing/Easting database

structure, a generic rule can be used to find the predecessors Bench,
Northing and Easting, but not its Stage. If the predecessor is not in the
same stage as the successor, the generic dependency rule will not be able
to locate it and it will therefore assume the predecessor is missing.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 65

 In this situation, an adjacency table can be used to instruct XPAC to
check for the predecessor in other stages, if it is not found in the same
stage as the successor. The table is used to indicate which stages are
adjacent to one another and which stages are independent of each other.

To assign an adjacency table to a dependency rule set, the Adjacency Table

tab must be selected when the rule set is being edited. Ticking the Use
Adjacency Table checkbox activates the adjacency table and displays a grid
where the adjacency data must be entered.

The Classify By drop-down list box allows the user to choose how the
records in the database have been classified into groups. It contains a list
of all database levels followed by all database fields. In this section, we
will consider the use of database levels to classify the deposit. The use of
database fields for this purpose are considered in the following section.

By default, the first database level is assigned to the Classify By list box,
but the user can select any other database level for this purpose. If the
user changes the value in this list box, a warning message is displayed
indicating that any data in the existing adjacency table will be lost.

66 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

66
 Once the database level used to classify the deposit has been selected,
the AutoScheduler will scan the entire database and construct a list of
each group of records within the database. This is based on record
names rather than the APIL numbers, and if the same level name occurs
more than once in different parts of the database (for example, if Stage 1
occurs in several pits), they will be treated as different groups.

Once the list of groups has been determined, the square grid will be re-
sized so there is a row and column for every group found with
appropriate titles. The adjacency table is now established and the user
can define which groups are adjacent to one another.

Each row in the table represents a group to which the successor may
belong, whilst the columns represent the groups that may be adjacent to
it. As a group is always adjacent to itself, the cells along the diagonal are
not available.

To indicate that a number of groups are adjacent to group A, the user

must click the cells in the row titled group A using the mouse. Naturally,
only the columns associated with adjacent groups should be clicked. A
tick will appear in the cell when it is clicked, and if it is clicked again, the
tick will be removed.

The adjacency data does not have to be symmetrical, and group A can be
adjacent to group B without group B being adjacent to group A.
However, if the Symmetrical check box is ticked, whenever an entry is
added to the table, the inverse entry will be added automatically. This
will not effect entries that existed in the table before the Symmetrical
checkbox was selected.

When a dependency rule set is applied, it will search for the predecessor
in the same group as the successor. If this search fails, it will then search
for the predecessor in each adjacent group. A dependency will only be
created if the predecessor is found in the successors group or in one of
its adjacent groups.

In the example above, 2 ticks have been placed in the adjacency table.
The first tick indicates that Stage_1 is adjacent to Stage_2 and the second
indicates that Stage_3 is adjacent to the Stage_1.

If the successor of a dependency is located in Stage_1, XPAC will first

look for the predecessor in the same stage. If it cannot locate the
appropriate record, it will then check for the predecessor in Stage_2. If it
cannot find it in Stage_2, XPAC will assume the predecessor does not
exist, as there are no other stages adjacent to Stage_1.

If the successor of a dependency is located in Stage_2, XPAC will look

for the predecessor in the same stage. If it cannot locate the appropriate
record, it will assume the predecessor does not exist, as there are no
stages adjacent to Stage_2.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 67

 If the successor of a dependency is located in Stage_3, XPAC will first
look for the predecessor in the same stage. If it cannot locate the
appropriate record, it will then check for the predecessor in Stage_1. If it
cannot find it in Stage_1, XPAC will assume the predecessor does not
exist, as there are no other pits adjacent to Stage_3.

Adjacency Tables Classified By A Database Field

When a field in the database is used to classify the deposit into groups,
generic dependency rules will always locate the predecessor, regardless of
the group to which it belongs. This is because the grouping does not
form part of the records unique identification.

Adjacency tables are also used in this situation, but instead of extending
the search to include additional groups, they filter the search to avoid
unwanted groups.

The user should first select the field that has been used to allocate
records to each group in the Classify By drop-down list box. The
AutoScheduler will then scan the entire database and construct a list of
each group of records within the database. This is based on the value of
the field and every unique value will be included in the list.

Any field can be used as the basis of the classification, but care should be
taken when it is selected, particularly in large models. If a grade field was
selected accidentally, XPAC could identify thousands of unique groups
and an enormous grid would be required.

68 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

68
 When the dependency rule set is applied, it will evaluate the rules as
normal, but before creating each dependency, it will check which stages
the successor and predecessor belong to. If they occur in the same stage
or if the stages have been flagged as adjacent, the dependency will be
created as normal. But if they occur in different stages that have not
been flagged as adjacent, the dependency will not be created.

Although adjacency tables were introduced to overcome the two

problems described above, they have also been used in other situations
where some of the dependencies a rule set would normally create must
be filtered out. However, the introduction of a Predecessor Filter range to
dependency rule sets has reduced the reliance on adjacency tables for this
purpose.

Dependencies Using Upper Level Records

Dependencies are always processed at the lowest level in a database

because it is the availability of individual records that must be controlled.
But when dependencies are created, it is sometimes easier to define the
dependency rules in terms of upper level records. XPAC will therefore
automatically resolve any upper level dependencies into their equivalent
lower level dependencies when the rules are applied.

Consider a model that contains 2 pits and a dependency rule is used to

ensure pit 2 will not start until pit 1 has been completed. If the pits were
fairly small and only contained 1000 records each, the dependency rule
will require 1,000,000 lower level dependencies to implement it. If this
approach is followed, the use of upper level dependencies could quickly
become very inefficient.

To reduce the impact of upper level rules and limit the number of lower
level dependencies required to represent an upper level dependency rule,
XPAC performs an optimisation process whenever upper levels rules are
applied. This examines the dependencies that already exist between
children of the upper level successor and children of the upper level
predecessor. This can significantly reduce the number of dependencies
required to implement an upper level rule.

In the following example, there are two benches, each with six blocks.
We will consider two dependency rules as follows.
 The blocks on each of the benches cannot be scheduled unless the
blocks to their East have been scheduled (ie mine each bench from
East to West).
 Bench 2 cannot be scheduled unless bench 1 has been scheduled (an
upper level rule where both the successor and predecessor are both
upper level records).

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 69

 The following diagram shows the dependencies that would be created if
the first rule was applied on its own. The arrows always point from
successors to predecessors (they point to the blocks that must be mined
before the dependency will be satisfied.).

Rule 1
Before a block can be mined, the block
to its east must be mined.

Bench 1

Bench 2

The next diagram shows the dependencies that would be created if rule 2
is applied on its own. In this instance, a dependency is required from
every record in bench 2 to every record in bench 1.

Rule 2
Bench 2 cannot be mined until
Bench 1 is mined

Bench 1

Bench 2

The final diagram shows the dependencies created when rule 1 is applied
to the model followed by rule 2. The redundant dependencies are
identified and eliminated when the rule is applied.

70 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

70
 Rule 1 Then Rule 2
After Optimisation

Bench 1

Bench 2

To function efficiently, all standard dependencies should be applied to a

model before rules with the upper level dependency are applied. Rule
sets that involve upper level records must basically be applied last.

When XPAC applies dependencies, it does so in the order the rules are
displayed within the schedule set up tree. To amend this order, the rule
sets can simply be dragged and dropped to new locations. To gain most
benefit from the optimisation process, you should place rule sets that
involve upper level dependencies at the bottom of the list in the schedule
set up tree.

When the Apply All Rule Sets option is selected (either from the menu,
the right click menu or from a prompt when a schedule is run) the rule
sets will be applied sequentially in the order they occur within the tree.
But if rule sets are applied individually, it is possible a dependency that
was previously used in the optimisation process is changed or removed.

For this reason, we always recommend the Apply All Rule Sets menu
option is selected before scheduling, if any significant changes are made
to dependencies in models. This is more important in models that use
upper level dependencies, where optimisation will have been used.

Skipping Non-Scheduled Records

Each activity in an Autoscheduler model must be assigned a zero test

data field, which is used to identify which activities occur in each record.
This assignment is performed in the Productive Activities dialogue.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 71

 By default, each activity is assigned the special value Include All Records,
which indicates that XPAC should not test the activities Zero Test Data
Field and instead assume that all activities must be scheduled in every
record.

But often, this will cause many empty activities to be included in the
schedule unnecessarily, slowing the schedule down in the early periods.
To avoid this, a field must be selected in the Zero Test Data Field column
of the Productive Activities dialogue that quantifies how much of each
activity exists in each record.

If the value of an activities zero test data field in a record is greater than
zero, the activity is assumed to exist for that record and will therefore be
included in the schedule. But if the value of the zero test data field is
zero or negative, it is assumed the activity does not exist in that record
and so it won’t be included in the schedule.

Zero test data fields can therefore be considered as a filter that

determines which activities must be included in the schedule within each
record. The default value for the zero test data field (Include All Records)
assumes every activity will occur in every record.

Another pre-defined option called Use Accumulation Field will utilise

the accumulation fields of all resources that can perform the activity. If
the value of every field used as the ADF of the resource that can
perform an activity, that record will be excluded from the schedule. Put
more simply, any activity that can be performed by any of the resources
will be included in the schedule.

Even if a records activities are considered available for scheduling, they

will only be scheduled if their accumulation fields contain values greater
than zero. For example, the Autoscheduler will not schedule the waste
activity in a block if that block does not contain any waste material.

Regardless of the reason why a records activities are excluded from the
schedule, a potential problem exists if the excluded block is a
predecessor of other blocks. Because the predecessors are not
scheduled, its successors will never become available for scheduling.

72 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

72
 To avoid this situation, blocks are tested during the scheduling process
whenever they become available. If the Autoscheduler determines the
block will not be schedule for whatever reason, dependencies that have
this block as their predecessor will automatically be satisfied. This
process is performed recursively and correctly releases successors even
when there are multiple non-scheduled records or non-scheduled
records in a chain of dependencies. The process is performed
automatically and user intervention is not required.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 73

Chapter 3
CAPACITY CONSTRAINTS

Introduction

Capacity Constraints are an important tool for limiting production from

the entire deposit or from any portion of it. The maximum capacity
assigned to a specified portion of the deposit can vary from period to
period and can apply to production from any combination of resources.

As an example, consider a multi-pit mine that blends a product from

several pits. To control the quantity of material scheduled from each of
these pits, a capacity constraint could be defined for each, with an
appropriate maximum limit. In an underground mine a maximum limit
can be placed on each stope to control draw rate, whilst other capacity
constraints can be applied to each group of stopes to limits the quantity
reporting to each ore pass.

When a capacity constraint is applied, the AutoScheduler monitors the

quantity of material produced from the specified portion of the deposit
during each period and will not allow the maximum limit to be exceeded.
If a scheduling step would break the capacity constraint, that step will be
truncated so that maximum is reached but not exceeded.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 75

 The Accumulation Field of each constraint is the database field that stores
the quantity the constraint must control. This must be an additive field
of the appropriate activity and whilst this is normally the accumulation
data field of the resource that schedules the record, this does not have to
be the case. For example, a capacity constraint in an open pit would
commonly control the ore produced from that pit, but it could also be
used to limit the production of material with a high clay content or the
number of haul truck hours consumed over the entire mine.

A capacity constraint can apply to the production from any group of

resources. For example, one constraint could restrict the material
produced by the ore mining fleet whilst another could restrict the
material produced by the ore and waste mining fleets in total.

Creating Capacity Constraint Sets

Capacity constraints that share a common purpose or apply to a

common area of the mine are usually grouped into sets to simplify their
management. Before a capacity constraint can be defined, a capacity
constraint set must exist.

To create a new capacity constraint set, the Capacity Constraint item in the
schedule set-up tree should be selected with the All Items tab active. This
displays a list of the capacity constraint sets currently defined in the right
hand pane. Buttons are provided to add a new constraint set or to
delete, edit or rename an existing constraint set.

When the New button is selected, a new item will be added to the list and
an appropriate name should be entered to the replace the default name
NewItem.

76 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

76
Editing Capacity Constraint

To edit a capacity constraint set, the Edit button should be clicked after
selecting the appropriate constraint set from the list in the schedule set
up window. Alternatively, the appropriate constraint set can be edited
directly by selecting it in the tree.

There are four types of capacity constraints available and all the
constraints in a set must have the same type. The four types are as
follows.
 Range
 Contents of Range
 Stockpiles
 Concurrent Work In Progress (WIP)

When a new capacity constraint is created, it will be assigned the default

type Range, which is the most common. This can be changed using the
Type drop down list box.

The settings for each type of capacity constraint are very similar, but the
way they influence the schedule is sometimes different. The use of each
type of constraint will be described in the following sections.

Range Capacity Constraints

Range capacity constraints are the simplest and most commonly used of
the four types. They set a maximum limit on the production from a
given portion of the deposit. When the capacity constraint is applied to
a model, the AutoScheduler will accumulate the production scheduled
from every record in the specified range and will not allow the total in a
period to exceed that periods limit (its maximum capacity).

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 77

 A column in the range capacity constraint table is used to define each
constraint in the set. There is no restriction placed on the number of
constraints (columns) each constraint set can contain.

To add a new constraint to a constraint set, a new column must be

created by pressing the <Insert> key after selecting a column as the
insertion point (this is usually the empty column at the end of the table).
Alternatively, the Insert option can be chosen from the right click menu.

Each range capacity constraint (ie each column in the table) has a
number of rows where its settings are defined. The purpose of each row
is described below.

 The Range row in the constraint table is used to specify the portion
of the deposit that must be controlled by the capacity constraint.
Either an existing range can be chosen from the drop down list or a
new range can be defined by pressing the browse button.

 The Maximum Capacity row of the constraint table is used to

specify the maximum limit the capacity constraint will impose. This
limit normally changes from period to period (particularly when the
period duration varies) and so a field in the calendar database is
usually used to store the maximum limit.
If the maximum quantity remains constant throughout the schedule,
an absolute value can be entered in the Maximum Capacity field. It
is also possible to use an expression for the maximum capacity. An
example would be a daily maximum rate multiplied by period
duration from a calendar database field.

 The Proportional field in the table allows the user to indicate the
capacity constraint should be applied evenly across the period, rather
than simply limiting the total achieved during the period. In this
sense it is used to control the production rate rather than the total
production over the period. A detailed description of proportional
constraints and the sub-periods they use has been provided later in
this chapter.

78 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

78
  The Accumulation Field indicates what quantity the constraint will
control and can be any additive field in the database. Often, this is
the field used to store the quantity that must be scheduled from each
record, such as ore tonnes or development metres. But other fields
can also be controlled, such as the haul truck hours required, the re-
agent consumed in the plant when the block is processed or the
quantity of ore with a high clay content.

When the capacity constraint must be applied to multiple resources

or resources that schedule more than one activity, an accumulation
field can be specified for each of the activities. The AutoScheduler
will then accumulate production from all of these fields when
determining whether a scheduling step will cause the maximum limit
to be exceeded. When the activity does not influence the constraint,
the accumulation field for that activity should be left as None.

 The remaining Resources rows in the constraint table are used to

indicate which resources the capacity constraint will constrain.
Selected resources are displayed with a tick and clicking a cell in this
column will toggle that resources tick on and off.

If the All Resources cell is ticked, a greyed tick will be placed in every
resources row. The user will not be able to remove any resources
from the constraint whilst the All Resources cell is selected.

If the constraint should not apply to every resource, the tick in the
All Resources row should be removed. The ticks for each of the
resources will turn black and the user can then select any
combination of resources. For example, if a capacity constraint is
used to limit the ore quantity produced from a pit, only the Ore
Miner resource would be selected. But if the constraint was limiting
total material movement, both the Ore Miner resource and the
Waste Miner resource would be ticked.

Contents Of Range Capacity Constraints

Contents of Range capacity constraints are more complex than Range

capacity constraints, even though the rows in the table used to create
them are identical. The difference lies in the way the constraints are
applied to the database range.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 79

 Range constraints add up the production from every record within the
database range and prevent this total from exceeding the maximum limit.
But Contents of Range capacity constraints add up the production from
each element in the database range separately and ensures each of the
totals does not exceed the maximum limit. It effectively creates a
separate constraint for each element in the range and can be extremely
useful when the production from many small areas of the mine must be
controlled individually.

To further illustrate the difference between Range and Contents Of Range

capacity constraints, the following example shows the effects of a Range
capacity constraint on a section of a model.

Constraint Type = Range

Range = Include A at Lowest Level
Maximum = 480 units
480
A

300 180
B C

140 160 0 180

D E F G

20 70 50 0 100 60 0 0 0 80 70 30
H I J K L M N O P Q R S

The small numbers represent the quantity of material scheduled in a

period. The constraint controls the quantity of material accumulating to
record A (the red value), regardless of which lower level records this
comes from. Some lower level records produce large quantities of ore
whilst an entire branch of records generates no production. Despite this
erratic distribution, the Autoscheduler will not allow more than 480 units
from being produced by the children of record A.

In the next example, the capacity constraint type has been changed to
Contents of Range and the maximum value has been reduced to 40 units.

80 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

80
 Constraint Type = Contents Of Range
Range = Include A at Lowest Level
Maximum = 40 units
480
A

240 240
B C

120 120 120 120

D E F G

40 40 40 40 40 40 40 40 40 40 40 40
H I J K L M N O P Q R S

Because this is a contents of range constraint, the maximum is applied to

each of the element in the range. In this instance, the scanning level of
the range is Lowest Level so the range contains the 12 lowest level records
(H to S). The Autoscheduler will therefore prevent any of these 12
records from producing more than 40 units. The same quantity of
material was scheduled, but it is now evenly distributed over all lowest
level records.

In the last example below, the scanning level of the range has been set to
Level 3 (the level containing records D, E, F and G). The maximum has
also been increased to 120 units.

Constraint Type = Contents Of Range

Range = Include A at Level 3 (D, E etc)
Maximum = 120 units
480
A

240 240
B C

120 120 120 120

D E F G

40 80 00 0 100 20 40 40 40 0 120 0
H I J K L M N O P Q R S

Because the scanning level has been raised, the range no longer contains
the lower level records. Instead the range consists of four upper level
records (D, E, F and G) and this is where XPAC will apply the maximum
limits.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 81

 The material produced in each lower level branch is erratic again, with
some lower level records producing large quantities of material whilst
others produce none. But the Autoscheduler has ensured the total from
each lowest level branch does not exceed 120 units. Again the total
production has not changed, but this time we have smoothed production
between records on the third level of the database.

The database ranges used for this type of constraint normally have a
scanning level applied. This ensures the elements within the range are
upper level records that accumulate their children’s production, rather
than the children themselves. The definition of database ranges and the
use of scanning levels are described in more detail in XPAC’s standard
on-line help system.

The main reason for using contents of range capacity constraints is to

avoid the need to create a large number of range constraints. Consider an
underground mine with a Level/Drive/Stope database structure. If the
constraint’s range is set to Include All with a Drive scanning level, the
constraint will control total production in each drive. If there were 200
drives in the model, the one constraint will have replaced 200 range
capacity constraints.

It is still possible to use database ranges with the scanning set to lowest
level. This will prevent production from each individual record in the
range from exceeding the maximum limit specified. In the example
above, if the scanning level of the range is changed to Stope, the Contents
of Range constraint would limit production in each individual stope.

The Maximum Capacity row of a Contents of Range capacity constraint is

used to store the maximum production the constraint will allow from
each of the elements in the range. There are a number of alternative
settings for this.
 If each element in the database range has its own unique limit, a
reference to a main database field must be entered into the in the
constraints maximum capacity row. When the AutoScheduler reads
the maximum capacity from the main database, it will do so at the
database ranges scanning level.
The user must therefore ensure the value of the field when
accumulated to this scanning level gives the correct maximum. This
can be achieved by writing the same value to every lower level record
in each section controlled by the constraint and then setting the field
type to Average.

 If the same production limit applies to every element in the database

range and does not vary from period to period, the maximum value
can simply be entered in the constraints maximum capacity row. An
expression could also be entered.

82 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

82
  If the same production limit applies to every element in the database
range, but this limit must change from period to period, a reference
to a calendar database field can be entered on the constraints
maximum capacity row.
 If each element in the database range has its own unique limit, but
this limit must vary from period to period, the user can enter a
formula into the constraints maximum capacity field that multiplies,
adds or subtracts a main database field and a calendar database field.
For example, the daily maximum limit can be placed in a main
database field and this can be multiplied by the days per period to
obtain the total maximum limit.

All of the other settings associated with Contents of Range capacity

constraints (such as proportionality, accumulation fields and resource
flags) are used in the same way as they are in range capacity constraints.

Stockpile Capacity Constraints

Stockpile capacity constraints can only used when an AutoScheduler

model contains stockpiles. They are normally used to specify the
maximum size a stockpile (or a group of stockpiles) can grow to, but can
also be used to limit the amount a stockpile (or a group of stockpiles)
can grow each period.

It should be realised that this type of constraint does not limit the
amount of material moved to a group of stockpiles or depleted from a
group of stockpiles; normal range capacity constraints can be used to do
this. Instead, these are used to control the maximum inventory within a
stockpile or group of stockpiles at any point during the schedule.

Stockpile capacity constraints share many similarities to range capacity

constraints, but with some unique characteristics. The purpose of each
row in the constraint is described below.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 83

  The Range is used to identify which stockpiles the constraint is
applied to. Any group of stockpiles can be specified in this manner
and the constraint will only be applied to the stockpiles within the
range. This type of constraint should be applied to entire stockpiles,
rather than to individual piles within a stockpile.

Stockpile ranges cannot be defined until the stockpiles they will

contain have been created. The stockpiles should therefore be
defined before the constraints that will control their maximum size.

The records associated with each stockpile are not created until the
stockpile is assigned to a scenario, and if the stockpile is de-activated,
ranges containing that stockpile will become invalid. This problem
can be avoided by using the automatic ranges created for records on
level 1 of the database, which include the parent of each stockpile
(the names of these ranges are displayed in blue in the Ranges
dialogue). If a group of stockpiles must be controlled, a new empty
range should be created and the appropriate automatic ranges should
be added to it using the Include Other Range button.

 The Type row is used to define the purpose of the constraint and
two options are available as follows.

Total Sizeprevents the total size of the stockpiles included within the
range from exceeding the maximum limit specified. This would
typically be used when there is a limited space available to create the
group of stockpiles, which cannot be exceeded. The distribution of
material between individual stockpiles within the group is not
controlled and additional constraints should be created, if this is
required.

Size For Each Periodprevents the total size of the stockpiles included
within the range from growing by more than the specified limit each
period. This would typically be used to prevent the stockpiles from
suddenly increasing in size by an unacceptable amount.

 The Accumulation Field rows have the same purpose as they do in

the other types of capacity constraint; they define what quantity the
constraint should monitor and control (ore quantity, clay quantity
etc) and can be any additive field in the main database. If material
types associated with more then one activity can be placed on the
stockpile, accumulation fields must be specified for each and the user
must ensure these fields are compatible.

 The Resources rows at the bottom of the table are used to define
which resources the constraint will monitor and control. With this
type of capacity constraint, the user must ensure that every resource
that can send material to the controlled stockpiles or remove material
from them are included in the range. Failure to do this may lead to
unexpected results.

84 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

84
 Concurrent Work In Progress Capacity Constraints

Concurrent Work In Progress (WIP) constraints are quite different from

the other types of capacity constraints. Instead of controlling how much
production comes from specific areas of the deposit each period, they
are used to control the number of areas that are being mined
concurrently in specific parts of the deposit. This should not be
confused with proximity constraints, which limit the number of
resources that can operate in the same record at any point in time.

To use a WIP capacity constraint, two types of fields must be created in

the main database.

 The Flag Field is used by the Autoscheduler to indicate which

records in the database are active (records where mining has begun,
but hasn’t been completed). If the constraint applies across multiple
activities, they must each have their own flag field. This field is
usually Additive but in some instances, it must be set to Maximise
for the lower levels and Additive thereafter.

When a record is scheduled for the first time, the AutoScheduler

automatically writes a value of 1 into this field. This flag is then
automatically reset back to zero when the record has been finished.
Although the user does not have to manage the values of flag fields,
they must be assigned a value of zero before the model is scheduled
for the first time.

 The Maximum Capacity field is used to store the maximum

number of records that can be active in each portion of the database
the constraint controls. This is a main database field and is normally
defined as Average.

As with the other types of capacity constraint, each constraint has its
own column in the constraint table. The purpose of each row in this
table is described below.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 85

  The Range row is used to specify the area to which the constraint
will apply. This range will be subdivided into portions, based on the
setting chosen in the constraint tables Level row.

 The Maximum Capacity row is used to indicate which field in the

main database has been used to store the maximum number of active
records in each portion of the selected range. The field can be
assigned to any activity, but the user is responsible for assigning
appropriate values to it.

 The Level row is used to indicate which of the databases hierarchical

levels should be used to subdivide the selected range into portions.
The constraint will control the number of active records in each of
these portions.

As an example, consider an underground stoping operation with a

Level/District/Stope database structure. If we were to create a
Concurrent WIP capacity constraint with a range of All and the level
set to District, it would limit the number of active stopes within each
ventilation district on each level. If the range was changed to 450
Level but the level row was left unchanged, the constraint would
control the number of active stopes in each district on the 450 level.

 The Clear at End of Period (EOP) row controls when XPAC

resets the value of the flag field to zero. If this row is not ticked in
the constraint table, the flag will not be reset until the record has
been fully scheduled. If this row is ticked, the value of the flag field
will be reset at the end of each period. In this instance, the
Autoscheduler will reset the flag field to 1 when the record is
scheduled for the first time in each period.

 The Flag Field rows are used to indicate which main database fields
should be used as the Active Flag fields. If the capacity constraint is
being used to control more than one activity, flag fields must be
assigned to each.

 The Resource rows are used to indicate which resources should be

controlled by the constraint. Generally, every resource that can
perform the activities that have been assigned flag fields would be
selected.

86 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

86
Proportional Capacity Constraints

All capacity constraints other than WIP constraints have a proportional

property that can be activated by clicking the proportional row for that
constraint. A tick will then be placed in the cell and a browse button will
be displayed. Clicking this browse button opens the Proportional
Constraint dialogue box.

This dialogue is used to split each period into a number of sub-periods

with equal duration. XPAC will then apply the capacity constraint to
each sub-period, rather than to each complete period. The maximum
capacity is also sub-divided between each sub period so the total for the
period does not change.

The sub-period type allows the user to specify the duration of the sub
periods in different ways. Two options are available, as follows.

 The Duration sub-period type allows the required sub period

duration to be entered directly in the text box. If a value of 2d 00:00
was entered, a sub period of 2 days would be used.

 The Period Portion option allows the period to be split into a

specified number of sub periods with equal duration. If a value of 10
is entered in the text box, the period will be divided into 10 sub-
periods of equal duration.

By their very nature, capacity constraints cannot be used to directly

control production rate. However, the proportional feature does allow
us to emulate a constraint on production rate. The best way to describe
the way the proportional feature approximates a production rate
constraint is with an example.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 87

 Consider a mine where clay within the ore presents a processing
problem. A capacity constraint has therefore been used to limit the
quantity of high clay material produced during each period to 30% of the
total ore produced. The following graph shows the proportion of high
clay ore produced as a percentage of total ore production during the first
2 periods of the schedule.

100
90
% Hi-Clay Ore In Total

80
70
60
50
40
30
20
10
0
Period 1 Period 2

As the total production of high clay material did not exceed 30% of the
total ore quantity in each period, the capacity constraint was honoured.
But at specific times during each period, high clay production represents
over 80% of the total production.
Standard capacity constraints control the total quantity produced in a
period and not the rate at which it is produced. If the plant was unable
to accommodate such a high clay feed for such extended periods, the
capacity constraint must be applied over shorter periods (sub-periods),
with proportionally reduced maximum limits.
The following graph shows the effects of making the constraint
proportional, with 12 sub-periods of equal duration per period. At the
start of each sub-period, clay production is usually high, but this drops to
zero at toward the end of each sub-period to ensure the maximum for
that sub period is not exceeded.
100
90
% Hi-Clay Ore In Total

80
70
60
50
40
30
20
10
0
Period 1 Period 2

Sub Periods

88 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

88
 The production of clay becomes more erratic when this feature is
activated, particularly when there is a lot of high clay material available.
At the start of each sub-period the production of clay is unconstrained
but as soon as the limit is reached, production falls to zero.

Even though production appears to be more erratic, the average rate of

clay production is a lot smoother over the course of each period. It
never exceeds 50% of total and over each sub-period it never exceeds
30%.

Whilst this form of constraint does not ensure a consistent production

rate is maintained, it does emulate it. Furthermore, the smaller the sub-
period duration, the closer the constraint will approximate a constant
rate. But care should be taken when specifying very small sub-periods as
it may reduce the scheduling speed significantly.

Applying Capacity Constraints

Different combinations of capacity constraint sets can be used in

different scenarios. To select which constraint sets should be used in a
scenario, the Capacity Constraint item in the schedule set up tree should be
selected with the Scenarios tab active. This displays a list of all capacity
constraints in the right hand window.

Each capacity constraint set in the list has a checkbox in front of its
name and this should be ticked to activate the constraint set in the
current scenario. The selected constraint sets (those with a tick in their
checkboxes) are shown under the capacity constraint item in the
schedule set-up tree.

Be careful when assigning a large number of constraints in a schedule for

the first time. It is easy to inadvertently over-constrain a model so it is
unable to generate an acceptable schedule. It is better to assign new
constraints sequentially, so the effects of each one can be studied.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 89

Capacity Constraints That Define Minimums

Capacity constraints are normally used to specify a maximum limit on

the production from particular areas. But they can also be used to
specify a minimum quantity that must be produced from those areas.

Although there is no setting in the user interface to provide this facility,

it can be achieved by applying the opposite capacity constraint. This
uses the principle that if a certain portion of the total production must
come from a particular area, no more than the remainder can be
produced from the rest of the deposit. The approach is best explained
with an example.

Consider a mine split into two pits. The mine must produce 1 million
tonnes of ore, but each pit must produce at least 25% of the total.
Although we cannot force the AutoScheduler to mine a minimum of
250,000 tonnes of ore from each pit, we can ensure it does not mine
more than 750,000 from them. In doing so, we achieved the same result.

In some instances, it can be a little harder to determine the correct

constraints to achieve the desired minimum production levels, but a
solution always exists.

Consider a mine split into 3 pits that must produce 270,000 tonnes in a
period. The quantity of material in each pit and the minimum
production each must contribute are as follows.

Pit Available Minimum

Ore Required
A 150,000 100,000
B 100,000 100,000
C 90,000 60,000

How would we assign capacity constraints so that each pit achieves the
specified minimum production rates?

By inspection, three inverse constraints can be defined using the

Minimum Required values as follows. (The variables a, b and c have been
used to represent the production from each pit).

b + c ≤ 170,000
a + b ≤ 210,000
a + c ≤ 170,000

Furthermore, the sum of the minimums (260,000) is only 10,000 less

than the total target (270,000), indicating that we cannot allow any pit to
produce more than 10,000 more than its minimum. These can also be
expressed as constraints, as follows.

90 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

90
 a ≤ 110,000
b ≤ 110,000
c ≤ 70,000

If we were to create these six constraints, the AutoScheduler would

select the best schedule possible, whilst honouring the desired
minimums. Although the first set of constraints is relatively easy to
identify, the second set of constraints is often overlooked.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 91

Chapter 4
PERIOD CONSTRAINTS

Introduction

Period Constraints are an important tool for preventing areas of the

mine from being scheduled during specified periods. As an example,
consider a mine with some areas that are inaccessible during the wet
season. Period constraints can be used to prevent these areas from being
scheduled during the rains.

Period constraints function by temporarily suspending the blocks within

the Available Block List if they occur within the constraints range. This
will only happen if the current period is in the period range specified.
The period range is simply a range of the calendar database.

Each block in the available block list is tested at the start of each period
controlled by the constraint and any record in the specified range will be
suspended. Blocks are also tested when they are added to the Available
Block List, to ensure they are not subject to an active period constraint.
Once a record has been suspended by a period constraint, it will remain
that way until the end of the period.

A period constraint can be applied to any combination of resources. It is

therefore possible to prevent one resource from scheduling a block,
whilst allowing access by a second resource.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 93

 Although these restrictions could be applied using capacity constraints,
period constraints are usually much simpler to use. They are also easier
to process, improving the overall scheduling speed.

Creating Period Constraint Sets

Period constraints that share a common purpose or apply to a common

area of the mine are usually grouped into sets to simplify their
management. Before a new period constraint can be defined, a period
constraint set must exist.

To create a new constraint set, the Period Constraint item should be

chosen in the schedule set up tree with the All Items tab active. This will
display a list of the period constraint sets currently defined in the model,
with buttons to add a new constraint set or to delete, edit or rename an
existing constraint set.

When the New button is selected, a new item will be added to the list
and an appropriate name should be entered to the replace the default
name NewItem.

Editing Period Constraint Sets

To modify the constraints in a period constraint set, that set must be

edited. To do this, the Period Constraints item should be selected in the
schedule set up tree, when the Scenarios tab is active. After selecting the
appropriate constraint from the list, the Edit button should be clicked.
Alternatively, the appropriate period constraint set can be selected
directly in the schedule set up tree.

94 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

94
 Each constraint set can contain many constraints and each one is
displayed in a column of the period constraint table. When a new period
constraint set is edited, it will contain one empty column titled New
Constraint.

To add a new constraint to a constraint set, a new column must be

created by pressing the <Insert> key after selecting a column as the
insertion point (this is usually the empty New Constraint column at the
end of the table). Alternatively, the Insert option can be chosen from the
right click menu. This will insert a new constraint that can be edited as
required.

Each period constraint (ie each column in the table) has a number of
rows where the settings of the constraint are defined. The purpose of
each row is described below.

 The Database Range row is used to define the records the period
constraint will apply to. The period constraint always applies to the
lower level records in the range. If the range has an upper level
scanning range, the lower level records below each items in the range
will be controlled by the constraint.

 The Period row is used to specify the periods during which the
constraint will apply. These are specified using a calendar database
range, which can include any combination of periods. The periods in
the range do not have to be contiguous.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 95

  The remaining Resource rows in the table indicate which resources the
period constraint will apply to. Selected resources are indicated with
a tick and clicking these columns will toggle the tick on and off.

If the All Resources row is ticked, a greyed tick will be placed in every
resources row. The user will not be able to remove any resources
from the constraint whilst the All Resources row is selected.

If the constraint should not apply to every resource, the tick in the
All Resources row should be removed. The ticks for each of the
resources will turn black and the user can then select any
combination of resources.

For example, if a period constraint is used to prevent low grade or

from being sent directly to the LOM, forcing it to a stockpile, only
the Ore Miner resource would be selected. But if the period
constraint must prevent any mining from areas north of a creek
during the rainy season, both the Ore Miner resource and the Waste
Miner resource would be ticked.

When a period constraint is defined, it will only effect the model during
periods within the specified calendar database range. In these periods,
none of the records in the specified database range will be scheduled.

Applying Period Constraints

Different combinations of period constraint sets can be used in different

scenarios. To select which period constraint sets should be used in a
scenario, the period constraint item should be selected in the schedule
set up tree, with the Scenario tab active. This displays a list of all period
constraints in the right hand window.

Each period constraint set in the list has a checkbox in front of its name
and this should be ticked to activate the constraint set in the current
scenario. The selected constraint sets are displayed under the Period
Constraints item in the schedule set up tree.

96 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

96
Chapter 5
PROXIMITY CONSTRAINT S

Introduction

Proximity Constraints are normally used with the standard production

scheduling methods, but they can be applied to Autoscheduler resources
with slightly reduced functionality.

With production scheduling, proximity constraints are used to reduce the

production rate of resources when more than one is scheduled to work
in the same block. They also assign the maximum number of resources
that can mine a record at any point during the schedule.

A good example is an underground coal mine where either one, two or

three continuous miners can operate in a multi-drive heading. To model
this rule, a proximity constraint would be used to specify that no more
than three continuous miners can work in any heading at the same time.
It would also define the drop in production rate as the number of
continuous miners in the heading increases.

As Autoscheduler resources are target based, proximity constraints

cannot be used to adjust a resources production rate. But they can be
used to limit the number of resources that can be scheduled in a block at
the same time. This is the only use for proximity constraints in
Autoscheduler models.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 97

 Proximity constraints are applied to groups of resources defined by their
class. Each constraint is assigned to a resource class and will apply to all
the resources in that class. The class of a resource can only be changed
when the All Items tab is selected in the schedule set up tree.

Creating Proximity Constraint Sets

Proximity constraints that share a common purpose or apply to a

common area of the mine are usually grouped into sets to simplify their
management. Before a new proximity constraint can be defined, a
proximity constraint set must exist.

To create a new constraint set, the Proximity Constraints item should be

chosen in the schedule set up tree with the All Items tab active. This will
display a list of the proximity constraint sets currently defined in the
model, with buttons to add a new constraint set or to delete, edit or
rename an existing constraint set.

98 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 When the New button is selected, a new item will be added to the list
and an appropriate name should be entered to the replace the default
name NewItem.

Editing Proximity Constraint Sets

To modify the constraints in a proximity constraint set, that constraint

set must be edited. To do this, the Proximity Constraints item should be
selected in the schedule set up tree, when the Scenarios tab is active. This
displays a list of all the constraint sets active in the current scenario.
After selecting the appropriate constraint from the list, the Edit button
should be clicked. Alternatively, the appropriate proximity constraint set
can be selected directly in the schedule set up tree.

Each constraint set can contain many constraints and each one is
displayed in a column of the proximity constraint table. When a new
proximity constraint set is edited, it will contain one empty column titled
New Constraint.

To add a new constraint to a constraint set, a new column must be

created by pressing the <Insert> key after selecting a column as the
insertion point (this is usually the empty New Constraint column at the
end of the table). Alternatively, the Insert option can be chosen from the
right click menu. This will insert a new constraint that can be edited as
required.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 99

 Each proximity constraint (ie each column in the table) has a number of
rows where the settings of the constraint are defined. The purpose of
each row is described below.

 The Database Range row is used to define the records that the
proximity constrain will apply to.

 The Activity row is used to indicate whether the constraint applies to

the performance of a specific activity in the record or to all activities
in the record.

 The Maximum Capacity row is used to specify how many resources in

the selected class are allowed to work in each record.

 The Production Rate Decrease rows are used to specify the production
rate of resources changes when more than one resource operates in a
block at the same time. The rates are entered as a percentage of the
resources normal production rate. When used with Auto-Target
resources, the production rate changes are not used.

Applying Proximity Constraints

Different combinations of proximity constraint sets can be used in

different scenarios. To select which proximity constraint sets should be
used in a scenario, the proximity constraint item should be selected in
the schedule set up tree, with the Scenario tab active. This displays a list
of all proximity constraints in the right hand window.

100 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 Each proximity constraint set in the list has a checkbox in front of its
name and this should be ticked to activate the constraint set in the
current scenario. The selected constraint sets are displayed under the
Proximity Constraints item in the schedule set up tree.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 101

Chapter 6
STOCKPILE S

Introduction

In blending operations and mines where a high grading policy is

practiced, stockpiling strategies are essential elements of the mining
system.

To allow stockpiling strategies to be modelled and scheduled within

XPAC, a stockpiling option has been provided. This facility is extremely
flexible and several different types of stockpiles can be modelled.
Furthermore, the properties of these stockpiles are totally user definable.
Despite this flexibility, stockpile management is totally automatic and
requires no intervention from the user during scheduling.

Most records in the database are flagged as unavailable (or partially

unavailable) as soon as they have been scheduled, preventing them from
being scheduled a second time. Whilst this property is normally
desirable, it does not take account of situations where material must be
double handled through stockpiles. To accommodate this, the
AutoScheduler will automatically create records in the database tree
whenever material is moved to a new stockpile.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 103

 Because the material within stockpiles already occurs in main database
records (otherwise it could not be scheduled) a separate branch of the
tree is created with a parent called Stockpiles. This occurs at the same
level as the record Top (database level 0) and represents the total material
that has been moved to all stockpiles during the schedule.

When a model has no stockpiles, two of the pre-defined ranges (<All>

and <Top>) are normally used interchangeably. But when stockpiles are
being used it is important these ranges are applied correctly. The 3
predefined ranges are as follows.

<All> Every record in the database, whether it is a

normal record or a stockpile.
<Top> Every normal record in the database (excluding
stockpiles)
<Stockpiles> Every stockpile record in the database (excluding
normal records)

A record is also created under this parent for each stockpile that has
been defined and activated in the current scenario. As different
scenarios can have different combinations of stockpiles, the database will
automatically adjust itself when the active scenario is changed.

Note: Because the records within a stockpile are only valid for the current
scenario, when the active scenario is changed, all stockpile records are
lost. A new schedule must be generated for the scenario before the
stockpile records will be re-created. To avoid this problem when
alternative stockpiling strategies are being assessed, different scenarios
can be built in different copies of the project.

Each stockpile is subdivided into a number of piles. The size of these

piles is user defined and is based either on the quantity of material within
the pile or the time spent on construction. Each pile is represented by a
record on level 2 of the database, under the stockpiles parent record.
Sequential integers are used as the names of each pile.

The user can select four different pile types, as follow.

 Average Each pile is modelled as a single record containing

the aggregate of all the material moved to the
stockpile.

104 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

  FIFO Each pile is modelled as a series of individual
records, each containing the material moved to the
pile in a single scheduling step (a Parcel).
Dependencies are applied to these parcels ensuring
the parcels within the pile are mined in a First In
First Out order.
 LIFO Each pile is modelled in the same way as FIFO
stockpiles, but the dependencies between parcels
are assigned in the opposite direction. This forces
the parcels to be mined in a Last In Last Out order.
 Unrestricted Each pile is modelled in the same way as FIFO
stockpiles, but there are no dependencies assigned
between parcels. This allows the parcels to be
mined in any order.

If the stockpile has been modelled as average, all material moved to the
stockpile is added into a single pile record (on level 2 of the database,
under the appropriate stockpile parent record). The high grade stockpile
in the following database tree has this structure.

However, if the stockpile has been set to LIFO, FIFO or Unrestricted,

each parcel of material moved to a stockpile can be reclaimed
individually and so these must be stored in separate records. Parcel
records are created on level 3 of the database as children of the
appropriate pile record. The Low_Grade stockpile in the following tree
diagram has this structure.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 105

 The records associated with stockpiles are only created when they are
complete and until this point, they are not available for scheduling. For
this reason, the piles in average stockpiles become available when the
pile has been completed, whilst parcel records become available when
their associated scheduling step has been completed (unless a
dependency rule is preventing this.

Creating Stockpiles

To create a stockpile, the Stockpiles item must be selected in the schedule

set up tree with the All Items tab active. This will display a list of the
stockpiles currently defined in the model, with buttons to add a new
stockpile or to delete, edit or rename an existing stockpile.

106 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 When the New button is selected, a new item will be added to the list
and an appropriate name should be entered to the replace the default
name NewItem.

Although most items in the tree can be given a name of any length and
may include spaces, restrictions are placed on stockpile names. This is
because the name of the stockpile will also as used as the name of the
main database record that will represent it. The name of the stockpile
therefore has the same restrictions that apply to all record names; a
maximum of 12 characters with no special characters. Any space in the
name will be converted to underscore characters.

Editing Stockpiles

To edit the properties of a stockpile, the stockpile should be selected

from the list on the right hand side of the schedule set up window and
the Edit button should be clicked. Alternatively, the stockpile item can be
selected directly in the schedule set up tree. This will display the
properties currently assigned to the stockpile.

There are three settings used to control the properties of each stockpile
and these are explained in the following section.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 107

 Setting The Maximum Pile Size

This setting is used to control the size of each pile within the stockpile,
which is based either on the quantity of material within the pile or the
time it takes for construction.

 When Quantity is used as the pile size units, the user can either select
the pre-defined Period Target option or enter a fixed quantity directly
into the right hand list box.

When Period Target is chosen as the pile size, the AutoScheduler will
create a new pile when the existing pile contains a quantity of
material equal to the sum of the targets of the resources assigned to
that stockpile for the current period. Providing the targets for these
resources were achieved during a period, a new pile will be created at
the beginning of the next period and at the end of the schedule there
will be the same number of piles as there were periods scheduled.

When a fixed quantity is chosen as the pile size, the AutoScheduler

will create piles with the specified size, whether this takes a portion
of a period or several periods. With this setting, there is no
guarantee that the end of a pile will coincide with the end of each
period. In this instance the user can tick the New S/P Each Period
checkbox, which forces the AutoScheduler to begin a new pile at the
start of each period, whether the previous pile has been complete or
not.

 When Time is used as the pile size units, the user can again enter a
specific duration or choose the pre-defined Period Duration option.

When Period Duration is chosen as the pile size, the AutoScheduler

will create a new pile at the beginning of each period. Again, at the
end of the schedule there will be the same number of piles as there
were periods scheduled.

When a fixed duration is selected, the AutoScheduler will create piles

at regular intervals, regardless of how much material has been placed
in them. The duration can equal a portion of a period or several
periods. With this setting, there is no guarantee that the end of a
stockpile will coincide with the end of each period. In this instance
the user can tick the New S/P Each Period checkbox, which forces the
AutoScheduler to begin a new pile at the start of each period,
whether the previous stockpile has been under construction for the
specified time period or not.

108 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 Setting The Stockpiles Dependency Rules

The stockpiles dependency rules control how the records used to model
the stockpile are organised and how they become available when the
stockpile is depleted.

The Pile Type list box allows the user to define the behaviour of each pile,
and four settings are available as follows.

 The Average setting indicates that all material moved to a stockpile

should be merged into a single record. When each parcel of material
is moved to the stockpile, its contents are combined with the
material from other parcels already moved to the pile. In effect a
running total is maintained for every field in the database.

When the pile has been completed, the running total is stored in a
pile record on level 2 of the database, under the stockpiles parent
record. The individual movements of material to the stockpile
cannot be identified from the database records, as they have all been
merged into a single record. But the output path of the resource(s)
that built/depleted the stockpile can be used to provide a history of
movements to/from each stockpile.

 The First In First Out (FIFO) setting indicates that every parcel of
material moved to the stockpile (every scheduling step with this
stockpile as its destination) must be stored as a separate record. This
allows each parcel to be depleted independently of the others.

To model this, a pile record is still created under the stockpile parent
record. But this pile record is assigned a series of children, with each
modelling an individual scheduling step to the stockpile (on level 3 of
the database). Furthermore, when each parcel is added to the
database, a dependency is created with this parcel as the successor
and the previous parcel as the predecessor. This ensures the order
the parcel records are deleted is first in first out.

 The Last in First Out (LIFO) setting indicates the parcels within
each pile should be modelled in the same way as for FIFO
stockpiles, but the dependency chain is created in the opposite
direction (the next parcel is the predecessor). The records are
created in exactly the same way, but the last parcel will be mined
first, followed by the penultimate, and so on.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 109

  The Unrestricted setting again indicates that each pile must be
modelled in exactly the same way as FIFO stockpiles, with a level 3
record for each individual parcel. But in this case, no dependencies
are created whatsoever, allowing the parcels to be mined in any
order.

When the average setting is chosen as the Pile Type for a stockpile, a
moderate number of records will be required. But when any of the other
pile type options are chosen, the number of records needed to model the
stockpile can become very large, especially if each step is very small.
Care should be taken to ensure the maximum increment settings of
resources mining to these types of stockpiles are reasonable.

The Between Piles drop-down list box allows the user to define the order
that each pile must be mined in and two alternative settings are available
as follows.

 The Unrestricted setting is the most common and is used to

indicate that once a pile has been created, it will be immediately
available for mining. If multiple piles are created, they can be
depleted in any order.

 The FIFO setting is used to indicate that once a pile has been
created it cannot be scheduled unless the previous pile has been fully
depleted. This is achieved by creating dependencies between each
pile record, with the previous pile as the predecessor.

Using Stockpile Creation Scripts

Stockpile creation scripts provide a convenient way to modify the

properties of material when it is moved to a stockpile. For example,
assume each record in the database contains information about the costs
associated with the mining and treatment of the material within it. This
would probably be based on the assumption that when the block is
mined, it is taken to its ultimate destination. But if the block is mined to
a stockpile, some of these costs might not be incurred, but new costs (re-
handle) will be introduced. Making changes to account for this sort of
issue is a common application for stockpile creation scripts.

To apply a stockpile creation script, the name of the script must simply
be entered in the list box provided or selected using the brose button.
The script will only be run when a stockpile record (either a pile or a
parcel) is added to the database and it will only execute over this single
record.

110 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Selecting Stockpiles In A Scenario

As with other scheduling components, any combination of the stockpiles

defined in a model can be activated in a scenario. To achieve this, the
Stockpiles item must be selected in the schedule set up tree, when the
Scenarios tab is active. This will display a list of the stockpiles currently
defined in the model in the right hand window.

Each stockpile in the list has a checkbox in front of its name and this
should be ticked to activate the stockpile in the current scenario. The
selected stockpiles are shown under the stockpiles item in the tree
structure.

When a stockpile is activated in the current scenario, the associated

stockpile parent record is added to level 1 of the database. When a
stockpile is unselected, its parent record (plus any of the data and
children it contains) is removed. The stockpile section of the main
database will therefore always reflect the stockpile settings of the current
scenario.

When the active scenario is changed, the stockpiles in the database will
change to suit the new scenario and any existing pile and parcel records
will be cleared. This data is not saved, but it can be re-created by re-
scheduling the scenario.

It is often useful to incorporate stockpile records into database ranges,

so capacity and period constraints can be applied to stockpiles as well as
main database records. This is performed in the normal way, using a
combination of Include/Exclude rules and constraints. But when a
stockpile in such a range is de-selected from the active scenario, the
records associated with that stockpile will be removed from the database
and the reference to it will be removed from the range.

Whilst this does not represent a direct problem, if the stockpile is

reselected in the scenario, the records that belonged to the stockpile will
not be recreated and the reference to the stockpile in the range will not
be re-established.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 111

 If the range is based on one of XPAC’s automatic database ranges
(which in most instances it would be), this will not represent a problem,
as XPAC will automatically re-create the range when the stockpile is
selected again.

We recommend that care be taken when selecting and de-selecting

stockpiles in complex scheduling models. If such changes are required,
the allocation of stockpiles in all database ranges should be confirmed
before the scenario is scheduled. We also recommend that a copy of the
model be created for each scenario.

Assigning Resources To Stockpiles

Once a stockpile has been applied to a scenario, resources can be

configured to move material to it. In the current version, a resource can
either produce a final product (as normal) or move material to a
stockpile, but it cannot do both in the same project. Furthermore, a
stockpile resource can only send material to a single stockpile. However,
it is possible for a single stockpile to be filled by more than one resource.

To allocate a resource to a stockpile, the resources Auto Target Details

item must be selected in the schedule set up tree when the Scenarios tab is
active. The window on the right has three tabs and the Modes tab must
be selected to change the resources stockpile setting.

When a resource is changed from a Standard Resource to a Stockpiled

Product, the name of the stockpile must be entered in the dropdown list.
Only stockpiles that are active in the current scenario can be selected.

112 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 When a resource is changed in one scenario, care must be taken to
ensure this doesn’t change the settings of that resource in a different
scenario. When the same resource is used to mine to different stockpiles
in different scenarios, different resources should be created for each.

Constraining Movements To Stockpiles

When stockpiles are being used in a scenario, it is often necessary to limit

the quantity of material that will be mined to them. This is relatively
straightforward as the targets of each resource defines how much
material each will move to their associated stockpiles.

When targets are assigned, the user simply sets the targets to equal the
quantity of material that should be moved to the stockpile. In the
current version of the package, this must be a pre-determined value,
although upper and lower limits can be used to vary this. The use of
upper and lower limits is explained more fully in the next chapter.

It is also possible to vary stockpile targets dynamically, using user

processing scripts and capacity constraints. These are fairly advanced
options and we recommend users seek assistance from Runge before
these methods are used.

Constraining Movements From Stockpiles

Any number of resources can deplete stockpiles, and it is often necessary

to limit the quantity of material each resource can remove from a
stockpile or group of stockpiles. This is achieved using range capacity
constraints in the normal way.

As an example, consider a model with two stockpiles (HG and LG) and
two products (Export and Domestic). The total quantity of stockpiled
material that is used in each product must be restricted. Furthermore,
we must limit the quantity of material from the LG stockpile in the Export
product. To do this we must define three Range capacity constraints as
follows.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 113

 Constraint 1 Range : <Stockpiles>
Resources : Domestic
Max Capacity : Limit of stockpile material in Domestic

Constraint 2 Range : <Stockpile>

Resources : Export
Max Capacity : Limit of stockpile material in Export

Constraint 3 Range : LG Stockpile

Resources : Export
Max Capacity : Limit of LG stockpile material in Export

Capacity constraints are very flexible and any combination of material

movements, from any combination of stockpiles, by any combination of
resources can be controlled.

Controlling Stockpile Size

There is often a finite capacity for stockpiling material and as a result, the
total size of a stockpile (or a group of stockpiles) must be prevented
from exceeding the maximum capacity.

Standard capacity constraints cannot be used for this purpose, as we are

not concerned with the total movement to or from the stockpile.
Instead we are interested in the inventory within the stockpile or group
of stockpiles at any point in time.

To impose this type of constraint, we must use a stockpile capacity

constraint that has been assigned the type Total Size. This type of
constraint has been described in a previous chapter, along with
constraints of the type Size For Each Period.

114 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Chapter 7
AU TO SCHEDUL ER RESOUR C ES

Introduction

XPAC is a resource based scheduling system that can cater for up to 30

resources in each project. Resources are very flexible and can represent
a wide range of scheduled items. They usually fall into one of four
overlapping groups, as follows.

 A final product generated as the result of mining, such as waste or

ore.
 An intermediate stockpile product generated as the result of mining,
such as low grade ore.
 An operation or activity that must be performed as part of the
mining process, such as underground development or open pit
blasting.
 The operation of an item of equipment (or a pool of equipment) that
performs one or more activities.

The use of resources varies depending on the deposit, the mining

method and the scheduling requirements, making it difficult to provide a
distinct definition. For example, do we schedule the operation of the
equipment or the activities that equipment performs?

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 115

 Currently, XPAC provides three different methods for scheduling
resources, Standard Target, Standard Production and Auto Target. These
methods have been described in Chapter 1. It is possible to use any
combination of scheduling methods in a single schedule, but care should
be taken if it is possible for a standard resource and an Autoscheduler
resource to mine the same record.

The information needed for each resource varies depending on the

scheduling methods they use. Standard target and standard production
resources have been described in XPAC’s on-line help system and only
auto target resources unique to the AutoScheduler module are described
in this document. Reference is also made to the XPAC help system
when describing features common to all resources, such as rosters and
roster exceptions.

The most significant difference between Autoscheduler resources and

standard resources is that their output path (the sequence of blocks the
resource has scheduled) is not based on a manually defined input path.
Instead, the output path is generated automatically so that it best meets
the resources objectives. Naturally this output path will also honour any
additional mining rules and constraints that have been imposed.

Creating AutoScheduler Resources

Resources that will be scheduled by the AutoScheduler are created in a

similar manner to resources scheduled with the other methods, using the
schedule set up window. With the All Items tab active in the schedule set
up tree, select the Resources item. This will display a list of the existing
resources in the right hand window with buttons to add a new resource
or to delete, edit or rename an existing resource.

116 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 When the New button is pressed, a new item will be added to the list and
an appropriate name should be entered to the replace the default name
NewItem. When first created, resources should be edited so their general
properties can be assigned. To do this, select the resource from the list
and press the edit button, or select the resources item in the tree.

The resource Name is shown in the upper text box and this can be edited
if required. It can also be changed using the Rename button in the
resource list or by clicking twice on the resources item in the tree. The
Description field allows a more meaningful description to be specified and
has no other purpose.

The Class drop down list allows the user to classify the resource into one
of several pre-defined groups. The class controls the picture that will be
used to visually identify the resource and the icon used to represent it in
the schedule set up tree. It is also used to group similar resources
together for proximity constraints. These have been described in a
previous chapter.

The Resource Colour frame is used to allocate a unique background colour

to the name of resources when displayed in the Combined Output Path
window. A preview showing how the colours will be displayed is also
provided. More information regarding output paths and the combined
output path window can be found in XPAC’s on-line help system.

The Use Sound During Animation checkbox allows the user to specify
whether a sound should be used when schedule animations are played.
If this is selected, the user can select the sound file the resource should
use and whether this file should be directional. More information about
schedule animations can be found in XPAC’s on-line help system.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 117

Assigning Resources To Scenarios

Once the resources have been created, we must indicate which should be
used in each scenario. They must also be allocated a type that identifies
the methods that will be used to schedule them. The three scheduling
methods currently available in XPAC are as follows.

 Standard Production Resource [SP]

 Standard Target Resource [ST]

 Auto Target Resource [AT]

With the Scenarios tab active, select the Resources item in the schedule set
up tree. This will display a list of the existing resources in the right hand
window with three tick boxes beside each item in the list (one for each
scheduling method).

To assign a resource for Auto Target scheduling, a tick should be placed

in the appropriate column for that resource. An entry will then be
placed under the Resource tab in the tree structure, with a two character
suffix in square brackets that indicates its type ([AT] for Auto Target).

Resource can be allocated to more than one scheduling method by

placing ticks in more than one checkbox. An entry will be placed in the
tree structure for each allocated scheduling method. Although these will
share the same resource name, their two character suffixes will be unique
and they will behave independently.

This facility allows a resource to use more than one scheduling method
in a scenario. For example, standard productivity based scheduling could
be used for the first year of a schedule with Autoscheduling thereafter.
If this approach is adopted, only one of the resources instances should
be allocated a target each period, with the others given a target of zero.

118 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Assigning Rosters And Roster Exceptions

Each resource must be assigned a roster (and optionally a roster

exception template) that are used to determine the available operating
time during each period. With Auto Target resources, the roster is only
used to determine the productivity required to achieve its target each
period and to ensure appropriate delays are inserted into the resources
output path.

An explanation of rosters and the methods used to create them can be

found in XPAC’s on-line help system. Each roster is given a unique
name and there are no restrictions on the number of rosters that can be
defined in a model.

To allocate a roster to a resource, the resources Roster item should be

selected in the tree structure with the Scenarios tab active. This will
display a list of the existing rosters in the right hand window with a tick
box to the left of each name. Only one roster can be assigned to each
resource and once selected, its name will appear under the Roster item in
the tree structure.

Although rosters provide a flexible means of defining the working

patterns of a resource, there are usually exceptions to the roster that
must be considered, such as public holidays and planned maintenance.
These usually occur on a fixed date and may recur at regular intervals.

These are defined in roster exception templates, which are explained in

XPAC’s on-line help system. Each roster exception template is given a
unique name and there are no restrictions on the number of roster
exception templates that can be defined in a model.

To allocate a roster exception template to a resource, its Roster Exceptions

item should be selected in the tree structure with the Scenarios tab active.
This will display a list of the existing roster exception templates in the
right hand window with a tick box to the left of each name.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 119

 Only one roster exception template can be assigned to each resource and
once selected, its name will appear under the Roster Exceptions item of
the schedule set up tree.

Assigning Activities To Scenarios And

Resources

Before a resource can be assigned to perform one or more activities, the

activities that will be used in the scenario must be assigned.

AutoScheduler models can contain any number of productive activities

and these are defined using either the Edit | Productive Activities menu item
or the Productive Activities item in the schedule set up tree.

Each Scenario can use a different combinations of productive activities

and these are assigned by selecting the Productive Activities item in the
schedule set up windows tree structure, when the Scenarios tab is active.
This will display a list of every activity in the model, with a checkbox
beside the name of each activity.

The correct productive activities must be assigned in this way before the
details of the resources that perform them can be assigned. Over 30
resources can be used in a scenario, although this varies from model to
model. But we strongly recommend users try to restrict the number of
resources to a manageable level (up to 5) where possible.

120 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 Once the activities that will be scheduled in the current scenario have
been chosen, the activities each resource will perform can be defined.
To do this, the resources item should be selected in the schedule set up
tree, when the Scenarios tab is active.

The Delay Activity list box allows the user to select a non-productive
activity to use in the resources output path for periods when the
resource is idle due to a shortage of available material. The creation of
new Non-Productive Activities is described in XPAC’s on-line help system.

The Resource Activities table contains one row for each activity that has
been made active in the current scenario, and the activity name is shown
in the first column. Each resource in an AutoScheduler model can
perform multiple activities, although it is more common to create
separate resources for each activity.

The Active column in the table is used to indicate which activities this
resource will perform. If a tick is placed in an activities checkbox, the
resource will be able to perform that activity. If the checkbox is not
ticked, the resource will not be able to perform that activity.

If a resource can perform an activity it must be assigned an accumulation

field. This is performed using the resources Auto-Target Details item in
the schedule set up tree and is described in the following section. The
Accumulation Field column is provided only for reference purposes and
cannot be modified in this table.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 121

Assigning Auto Target Details

Before a resource can be scheduled, we must provide details about its

target and the quantity of material it must schedule from each record
during each scheduling step. These have a major impact on the way the
AutoScheduler operates and they must be assigned correctly. They also
provide the user with considerable flexibility and can be used to
overcome some complex scheduling problems.

To access the target details for an AutoScheduler resource, the Auto

Target Details item must be selected in the schedule set up tree, whilst the
Scenarios tab is active. This displays the properties of the resource in the
right hand window, which contains three tabs. The Target Details tab
contains the controls for assigning the resources target options.

The options provided in this window are described in the following

sections. To avoid confusion, the term Material has been used to
describe what a resource schedules, even though resources can be used
to schedule other quantities, such as development advance, metres
drilled, haul truck hours consumed and volume back filled.

Setting The Production Target

Every Auto Target resource requires a target that indicates the quantity
of material the resource should schedule each period.

122 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 The targets assigned to each resource would normally vary from period
to period, particularly when the duration of each scheduling period
changes. A field in the calendar database is therefore used to store the
target for each resource. This field should be chosen from the options
in the Production Target drop down list box. When the target does not
change from period to period, a fixed value or an expression can be
entered directly rather than selecting a field reference.

The units of the target must correspond with those of the resources
accumulation field. For example, if the accumulation field contains
tonnes of ore, the target must also be specified in tonnes of ore. If
different units are used for these two fields, the scheduled quantities will
be incorrect. The use of accumulation fields is described later in this
section.

Using Lower Target Limits

When the AutoScheduler generates a schedule, it will always attempt to

schedule the targeted quantity for each resource in each period. This
applies in all situations, regardless of the rules, constraints and objectives
that have been specified. But in some situations, it may be impossible to
achieve the target because there is simply not enough material available.

Consider an open cut coal mine with two resources; waste stripping and
coal mining. When their targets are well balanced, both resources will
achieve their targets in every period. But if the coal target is increased
without increasing the waste target accordingly, a point will be reached
where there is no more coal available to mine and the AutoScheduler will
fail to achieve it’s coal target.

If the AutoScheduler reaches the end of a period and it has been unable
to satisfy the targets of one or more resources, it will terminate the
schedule and generate an appropriate warning message. The user can
then investigate the problem and after adjusting the targets to more
practical levels, re-schedule the model.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 123

 But in some instances, the user may prefer the AutoScheduler to
continue scheduling, even if it does not achieve the specified target for
every resource. This is particularly true when the shortfall is relatively
small or when the user is trying to establish the material movement
requirements in an unfamiliar deposit.

To provide more control over the scheduling process, a lower limit can
be specified for each resource to indicate the lowest acceptable
scheduled quantity in each period. When a lower limit has been
specified for a resource, the AutoScheduler will not terminate the
scheduling run if it cannot meet each resources target, providing each
resource has at least achieved its lower limit.

Even when a lower limit has been set, the AutoScheduler will still try to
schedule the resources targeted quantity and providing sufficient material
is available each period, it will achieve it. Only if there is a shortage of
available material will the scheduled quantity fall below target.

To assign a lower limit to a resource, the Lower Limit check box must be
ticked on the resources Auto-Target Details window. The lower limit must
also be entered in the drop down combo box, either as an absolute value
or as a reference to a calendar database field. As with the target, the
lower limit must be specified in the same units as the resources
accumulation field.

If the lower limit in a period is set to zero, the AutoScheduler will not
terminate the scheduling run, even if there was no material available for
the resource to schedule during a period. This setting can be useful for
resources that are only scheduled occasionally and where it is unclear in
which periods they will be required, if any. The lower limit can never be
negative and should never be greater than the target.

Using Upper Target Limits

When a resource fails to meet its target because there was insufficient
material, lowering the acceptable limit for the resource may not be a
viable solution. An alternative approach would be to raise the target of
the other products, which may indirectly make more of the required
material available.

For example, if an open cut coal mine did not have sufficient coal
available to feed a power station, lowering the production level would
not be acceptable. Instead, the mine would have to increase waste
stripping to make more coal available.

124 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 If the targets (or lower limits when they are in use) of one or more
resources could not be achieved, the user could manually increase the
targets of the other resources in the hope this would overcome the
shortage of available material. But this process can be tedious, especially
if the process is performed incrementally to ensure any increase in target
is as small as possible.

To overcome this problem, the user can specify an upper limit for each
resource that will only be applied if another resource fails to achieve its
target (or its lower limit, if it is in use).

To assign an upper limit to a resource, the Upper Limit check box must
be ticked in the resources Auto-Target Details window. The upper limit
must also be entered in the drop down combo box, either as an absolute
value or as a reference to a calendar database field. The upper limit must
be larger than the resources target in each period and must be specified
in the same units as the resources accumulation field.

In normal circumstances, the AutoScheduler will terminate the current

schedule if one or more of the resources fails to achieve its target (or its
lower limit, if it is in use). But if one or more of the resources that did
achieve their targets have upper limits applied, the AutoScheduler will
reschedule the entire period, after increasing the targets of those
resources that have been assigned an upper limit and that did achieve
their targets.

When the AutoScheduler determines that the period must be

rescheduled with higher targets, the size of the increase needed to rectify
the problem is not known. Simply increasing the targets to their upper
limits may over-compensate and to avoid this, the re-scheduling process
is performed iteratively.

When an upper limit is specified, the user must also specify an increment
size in the Target Increment text box. Either an absolute value or a
reference to a calendar field can be entered. The increment must be
larger than zero and must have the same units as the resources
accumulation field. When the AutoScheduler detects it must re-schedule
a period, it will increase the targets of appropriate resources by this
increment. If this fails to rectify the problem for all resources, the
targets will be increased by a further increment (up to their upper limits)
and the model will be re-scheduled a second time.

This process is repeated until an acceptable solution is found or every

target reaches its upper limit. As each resource can have a different
increment assigned, they may require a different number of iterations
before they reach their upper limit.

To provide further control over the process, the user can specify the
maximum number of iterations that should be performed, even if this
prevents the targets being increased to their upper limits. At no stage
will the AutoScheduler increase a resources target beyond its upper limit.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 125

 Even if the upper limit has been specified for one or more resources, the
AutoScheduler will attempt to schedule the targeted quantity of material
for all resources. It will only start to increase resource targets if one or
more of the resources fails to achieve its target (or lower limit when they
have been specified).

Considerations When Using Upper Target Limits

Upper limits provide a very useful tool for identifying the relationships
between ore and waste production over the course of a period. But they
do have disadvantages when used as part of the routine scheduling
process. Users must always bear this in mind when using upper limits.

Setting a waste target intentionally low whilst giving it a high upper limit
is a very simple strategy for minimising the quantity of waste mined in
each period. This approach is basically a waste deferral strategy, where
the mine is being operated at close to a waste bound state. Waste will
only be mined if it is required to expose the targeted ore.

Being waste bound, the resources that schedule the ore will select
whatever ore is available. When there is insufficient ore to satisfy the
targets (forcing the Autoscheduler to mine more waste), any attempt at
meeting product grade is futile, because every available block will be
scheduled, regardless of its grade. Typically the user will find that if this
strategy is adopted without due consideration of its implications, control
over the product grade is lost or seriously reduced.

The cause of the problem is the loss of available inventory. At any point
in the schedule, it is the available inventory that the Autoscheduler must
select from. If the schedule progresses with very little inventory, It will
have to select whatever is available.

When mines operate with large inventories, there is normally a wide

range of available ore sources and these would normally have a range of
grades and other characteristics. This makes it easy to meet product
specifications, but requires a large mining area and brings forward waste
removal.

As the working inventory becomes smaller, it becomes harder to achieve

grade. It also becomes more important to control the grade of the
available inventory so it remains possible to blend an acceptable product.
This type of control is usually achieved using look ahead constraints,
which are described later in this chapter.

When the working inventory is reduced to its absolute minimum value

by setting a low target and a high upper limit, the objectives assigned to
the ore resources will have virtually no effect on the grade of the material
they schedule. Objectives are used to specify the desired outcome of the
schedule (such as meeting product grades) and have also been described
later in this chapter.

126 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 For this strategy to be successful, the objectives used to control the
grade of the ore must be augmented by objectives that control the grade
of the ore being exposed. Furthermore, the objectives must be placed
on all activities that can expose ore, including waste and low grade
mining.

This strategy can be quite complex to configure and usually requires

extra time to fine-tune the model, as there is a weaker correlation
between objectives and results. Changes to priorities must often be
made a little before they are required, whilst occasionally, control over
grades will appear to be lost altogether.

To avoid these problems, we strongly recommend upper limits are used

only as an investigative tool, to establish how strip ratios vary over time
and the relationship between strip ratio and grade. Once indicative
annual targets have been established for all resources, their target settings
should be set to these indicative values and their upper limits should be
deactivated.

Although the targets may require some fine tuning to begin with, the
user should quickly find it relatively easy to control the size of the
inventory by varying the targets assigned to the waste and low grade
resources. The inventory will also behave like an in-pit surge stockpile,
buffering ore production from strip ratio fluctuations.

Sharing Objectives With Another Resource

In some instances, a model requires two resources that contribute

toward a single product to be modelled individually (ie as separate
scheduling resources) rather than considering them as a single fleet.

The Fleet Size feature provided in previous versions did help to emulate
this situation, but with several limitations. This has now been replaced
by the Share Objectives feature, which provides greater flexibility and
overcomes some of the problems with the old fleet size facility.

The Use Objectives Of drop down list box contains a list of all resources
in the current scenario. The name This Resource is used in place of the
current resources full name.

When the user selects This Resource in the Use Objectives Of drop-down list
box, the resource will use its own objectives as normal. But if the user
selects one of the other resources, the resource will no longer use its own
objectives.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 127

 Instead, objectives will be obtained from the specified resource, and the
Autoscheduler will treat the two resources as a joint target. Each
resource will still achieve its own target, but the aggregate production
from the resources will now best meet the specified objectives, rather
than the production from each individual resource.

As an example, consider a mine that utilises two excavators to produce a

single product. Previously, these resources would have been scheduled
as a fleet, with a single objective that was assigned a target equal to the
sum of the two excavator targets.

It is now possible to schedule these excavators with separate resources,

whilst still achieving the correct total product specs. A target must be
assigned to each resource (the split between the two excavators cannot
be variable), but it is no longer necessary for the material contributed
toward the final product by each excavator to match the final product
specifications. XPAC will allow these two products to produce different
quality material, whilst ensuring their aggregate product meets the
objectives.

Any number of resources can contribute toward a product, and it does

not matter which resource is chosen to carry the objectives, providing
the value selected in its Use Objectives Of drop-down list box is This
Resource. All other resources that must contribute toward the final
product should have the chosen resource selected in their Use Objectives
Of drop-down list boxes.

When multiple resources are set to share objectives in this manner, it is

important the total target for the final product is apportioned to each
resource contributing toward that product. This apportionment must be
based on the expected capacity of each resource and whilst the split
between resources can be varied from period to period, it must be pre-
defined before the schedule is run.

Assigning Accumulation Data Fields

Each activity a resource can schedule must be assigned an Accumulation

Field. This is a field in the database the resource uses to quantify how
much of each activity must be scheduled in each record. It must have
the same units as the target assigned to the resource. Some examples of
the fields selected as accumulation fields are shown below.

 When a resource is used to schedule ore mining, a field containing

total ore quantity (tonnes) would be used as the accumulation field.
 When a resource is used to schedule the operation of a dragline, a
field containing total dragline waste volume (bcm’s) would be used as
the accumulation field. An alternative for this would be the dragline
hours required to dig each block.

128 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

  When a resource is used to schedule underground development, a
field containing development advance (metres) would be used as the
accumulation field.

There is a lot of flexibility regarding the selection of accumulation fields,

but some restrictions do apply. Firstly, as the data from the selected
accumulation fields will be added together during, the field must be
additive. Furthermore, the field must be assigned to the appropriate
activity (it would be pointless to use a field assigned to activity 1 as the
accumulation field for activity 2).

When a resource can perform multiple activities, the user is responsible

for ensuring the accumulation fields are chosen sensibly. The two
accumulation fields should have the same units and these should match
the units of the target the resource will be assigned to. It is not possible
to use a single resource that schedules ore mining based on tonnes and
waste mining based on volume at the same time; different resources
would have to be used in this instance.

The parent item of each Auto-Target resource has a Resource Activities

table that is used to define which activities it can perform. The Auto-
Target Details window contains a similar table (called Accumulation Fields),
but this allows the user to change the accumulation field assigned to each
activity.

Note: The tick in the Active checkboxes can be changed in either the
Resource Activities table on the resources parent item or in the table
described above. If it is changed in one table, the change will also be
reflected in the other. The accumulation field setting can only be
modified in Accumulation Field table on the resources Auto-Target Details
window.

If an activity has not been set as active in the Productive Activities item of
the schedule set up tree (this has been described earlier in the users
guide) that activity will not be displayed in the accumulation field table.

Setting The Step Size

When schedules are generated, the size of each scheduling step is based
on the user defined Step Size.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 129

 The requested step size can be an absolute value entered directly into the
list box or a calendar database field selected from the drop down list.
Furthermore, the value can represent a quantity, a percentage of the
record or a fraction of the record, depending on the option chosen in the
second drop down list box.

If an absolute value is chosen for the requested step size, the requested
step size of each scheduling step will be constant. If a percentage or a
fraction (Parts) is chosen as the requested step size (these options are
functionally equivalent), the requested step size of each scheduling step
will vary depending on the record size.

Whenever possible, the Autoscheduler will select steps of the requested

size. But smaller step sizes will be taken in the following circumstances.
 When there is not enough material left in the record to achieve the
requested step size.
 When scheduling the requested step size would cause a capacity
constraint to be broken.
 When a second resource selects a step from a record that is already
been mined, the steps of both resources may need to be truncated if
the block does not contain sufficient material to satisfy both steps.
 When scheduling the maximum increment would cause the resources
target to be exceeded for the current period.

In these situations, the AutoScheduler will select a smaller amount of

material than the requested step size. This will not cause the
Autoscheduler to select a different block because the maximum quantity
that can be scheduled from each record is considered as an integral part
of the block selection process.

In the last of these exceptions, when the requested step size cannot be
scheduled because it would cause the target to be exceeded, the user can
choose to place the remainder of the step at the beginning of the next
period. This is achieved by ticking the Continue Same Step Over Period
Boundary checkbox. This setting will have no effect in any other situation
where the requested step size is not achieved.

The Requested Step Size setting is very important as it impacts on the

number of steps that are scheduled each period. If the setting is small,
the schedule will contain a large number of small steps. This improves
blending ability but time required to generate a schedule will increase.
Conversely, when the maximum increment is large, blending ability
becomes more restricted, but schedules will be generated more quickly.

130 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Managing Temporary Shortages Of Material

If a shortage of material occurs during the course of a period, the

AutoScheduler will insert a delay into the output path to indicate the
resource was inactive. The duration of this delay will equal the duration
of the material shortage.

As previously described, the non-productive activity that should be

inserted into the output path for this delay can by select in the resources
parent item in the schedule set up tree. An appropriate non productive
activity must be defined before it can be selected in the Delay Activity list
box.

At the start of each period, the Autoscheduler determines the available

time available in the period after considering period duration, roster and
roster exceptions. Using these values it can determine the rate at which
the resource must operate in order to achieve its target at the end of the
period. This has been represented on the following graph.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 131

 Production Rate
Targeted Production Rate = Target / Available Period Duration

Start of Time End of

Period Period

When a temporary shortage of available material occurs, the resource will

be delayed and will resume scheduling as soon as new material becomes
available. However, some productive time will have been lost and to
achieve its target in the remainder of the period, it must operate at a
higher productivity.

Increased
Production Rate
Production Rate

Targeted Production Rate

Material Shortage

Start of Time End of

Period Period

To prevent the resources productivity from increasing to impractical

levels, the maximum productivity increase can be specified as a multiple
of its targeted productivity.

Maximum Production Increase Production Shortfall

Production Rate

Targeted Production Rate

Material Shortage

Start of Time End of

Period Period

132 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 If the maximum allowed increase in production is lower than the rate the
resource needs to meet its target, it will be prevented from rising above
the maximum level and will therefore fail to achieve its target.

The Maximum Increase in Productivity is located on the Modes tab, when the
resources Auto Target Details item is selected in the schedule set up tree.
This is specified as a multiple of the targeted productivity and the default
value is 2 (twice the targeted productivity).

A value of –1 will disable the maximum productivity, so that no limit is

imposed. This is the recommended setting for normal use, particularly
with long and medium term schedules.

Assigning A Resources Objectives

Objectives are used to define what we would like each resource to

achieve during each scheduling period. Examples would be to achieve
specific product and impurity grades, to maximise profit or minimise
haul distance. Any numeric variable in the database can be used in an
objective to control the outcome of a schedule.

Objectives can be used to maximise the value of a field, minimise the

value of a field or achieve a specific value for a field. Objectives apply to
each scheduling period and when a particular value is targeted, the
AutoScheduler will try to ensure the average value of the controlled field
over the course of each period equals the desired value.

There are no restrictions on the number of objectives that can be

assigned to a resource and each objective is allocated a priority that
defines its relative importance. Objectives only have a direct influence
on the resource to which they are assigned, but often there are indirect
relationships between resources due to the other scheduling rules
imposed on the model.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 133

 Objectives are not rules or constraints and there is no guarantee they will
be achieved. It is quite easy to assign a set of objectives that are totally
unachievable and the user must ensure that objectives are realistic. As an
example, it would be pointless to target a grade far above the deposit
average. The AutoScheduler may generate an above average grade early
in the schedule, but this will not be sustainable.

Each resource would normally have several objectives and these are
often contradictory. It is the overall effect of all objectives that dictates
which blocks will be scheduled.

Inserting New Objectives

To define the objectives for a resource, the Auto-Target Details item must
be selected in the schedule set up tree. When the Objectives tab is
selected, a table containing a column for each objective assigned to he
resource is displayed in the right hand window.

To insert a new objective, an objective must be selected in the table

(usually the New Objective column) to define the insertion point. The
Insert option should be chosen from the right click menu or the <INS>
key should be pressed to insert a new objective. A new column will be
inserted into the objectives table to the left of the selected objective.

Once the new objective has been inserted, the database field containing
the quantity to be controlled should be selected from the drop down list
in the Field row of the table.

134 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 Although any numerical field can be controlled by an objective, the
AutoScheduler is not as effective when targeting a specific value for an
additive field. To overcome this problem, additive fields should be
converted into a ratio by dividing it by the activities quantity (the
resources accumulation field) before being used as the basis of an
objective. This problem does not apply to objectives that maximise or
minimise a field.

The AutoScheduler can also control the values of fields that are weight-
averaged against fields that are not proportional to the resources
accumulation field. For example, an objective can be used to control a
ratio of grades or the grade of a fraction in the product (such as lump
and fines).

If the resource can schedule several activities, a field must be selected for
each of these activities and the user must ensure they are compatible.
For example, if a resource can mine high grade copper ore and low grade
copper ore, an objective to control copper grade will require two fields.
These fields must contain the copper grades of their respective ore types
(ie Cu grade of high grade ore and Cu grade of low grade ore).

Setting An Objectives Type And Target

To assign the objectives remaining properties, any of the other fields in

the objectives column (the Target, Priority or Period Bias rows) should be
clicked. This will open the resources Target and Period Bias dialogue.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 135

 When an objective is first entered, it is given the default type of
Maximise. Options are also available for Minimise and Target.

When the target type is set to Maximum or Minimum, no additional

information is required, as the AutoScheduler must simply select blocks
with the highest or lowest values in the controlled field. If the objective
must target a specific value, a number of additional values must be
assigned.

136 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 The Target list box is used to indicate the variables ideal value at the end
of each period. An absolute value can be entered or a calendar database
field can be selected from the drop down list. The AutoScheduler will
try to make the value of the controlled field equal to this value at the end
of each scheduling period.

The upper and lower values indicate the maximum and minimum
acceptable values. It is important to realise that these setting have no
bearing over the records the AutoScheduler will select whatsoever.

These values are only tested at the end of each period, to determine
whether the product is within specification tolerances. If the value of a
controlled field lies outside the acceptable range at the end of a period,
the user can choose the action that will be taken, using the If Tolerance Is
Exceeded frame. Three options are available as follows.
 Pause the schedule and ask the user if he wishes to continue or not.
 Execute the script the user has selected.
 Ignore the problem and continue scheduling

Under normal circumstances, the Ignore option would be selected, so the

schedule will be generated for all periods. It is normally better to see
how frequently the grade exceeds tolerance and how quickly it recovers,
rather than having the schedule stop as soon as the tolerance has been
exceeded.

If the schedule takes a long time to generate, the Stop Schedule or Warn
User option does allow the user to fine-tune the point where the
Autoscheduler abandons the scheduling run. This is normally most
appropriate when fine-tuning a schedule.

The Run Script option is a very powerful feature that allows the user to
automate the response when specific tolerances are exceeded. The script
would typically be used to add some comments to a log file, modify
certain parameters in the main and calendar databases then re-run the
schedule from the start of the previous period. This facility can also be
used to batch process schedules when performing sensitivity analysis, but
this is can be quite complex to configure.

Using An Objectives Advanced Settings

When an objective is targeting a specific value, there are two additional

settings used to control the selection process, called the Advanced Auto
Target Details. These values adjust the spread of selected blocks in
relation to the weighted frequency distribution of the controlled variable.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 137

 In normal situations, the AutoScheduler determines values for these
settings automatically (based on the standard deviation of the controlled
fields distribution). But they can also be adjusted manually to fine-tune
the scheduling process.

An objective with the type Target must first be selected, as the advanced
settings do not apply to maximise and minimise objectives. Select the
Scheduling | Advanced Auto Target Details Objectives menu option to display
the following dialogue.

The use of these variables lies outside the scope of this guide and has
been included only to assist advanced users. We recommend users seek
assistance from Runge staff before they attempt to use these options.

If the Standard Deviation Tolerance Multiplier option is selected, multipliers

can be entered in the text boxes that increase or decrease the values
relative to their defaults. The default values are both 0.5, but different
multipliers can be specified for the upper and lower tolerances, allowing
the selection region to be skewed.

If the Absolute Tolerance option is chosen, the user can enter upper and
lower tolerances directly and these will over-ride the default settings.
When this option is chosen, we recommend values are chosen at least
20% either side of the target, although this will vary from deposit to
deposit. The units for the settings should correspond with the units of
the field being controlled.

With both options, the user can also enter references to calendar
database fields that allow the settings to vary from period to period.

Setting An Objectives Priority

Each objective must be given a priority that defines its importance

relative to the other objectives assigned to the same resource. The
priority is an integer value from 1 to 100, with higher numbers indicating
greater importance. A value of zero can also be used to assign no
priority, neutralising the objectives effects for one or more periods.

138 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 To assign or change the priority of an objective, the Priority field in the
Target And Period Bias dialogue should be edited. If an absolute value is
entered in the Priority list box (the default value is 100), the objectives
priority will remain constant from period to period. If the priority
changes from period to period or if the objective must be deactivated in
some periods (given a priority of 0) a calendar database field should be
used to store the priority value. This field can be selected from the drop-
down list box

The priority of the objectives assigned to each resource are relative to

one another and are not absolute. If a resource has one objective, its
effective priority will be 100% whether the priority value assigned to the
objective. But if a resource has two or more objectives, their priorities
are relative to one another. If the priority of one is increased, the priority
of the others will be effectively reduced, even though their relative
priority values have not changed.

To determine the absolute priority for each objective, its value should be
calculated as a percentage of the sum of the priority assigned to of all
objectives. As the Relative Priority of an objective can vary from period
to period, the objectives effective priority can also change. Furthermore,
if the relative priority of any objective is changed, the effective priority of
every objective assigned to that resource will also change.

Setting An Objectives Period Bias

An objectives period bias setting is used to adjust the priority of an

objective during the course of a period. The effects of the period bias
setting on the objectives priority are shown on the graph of importance
over time, which is displayed beside the Period Bias drop-down list box.
The following options are available.
 Constant : The priority of the objectives will remain constant
throughout each period (the default and most common setting).

 Increasing : The objective begins each period with zero priority, but
this increases linearly over the course of the period until it reaches its
assigned priority at the end of the period.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 139

  Decreasing : The objective begins each period with its assigned
priority, but this decreases linearly during the period to zero.

 Step Up : The objective begins each period with a zero priority and
this is maintained to a fixed point during the period. When this
point is reached, the priority of the objective increases to its assigned
value and remains there for the remainder of the period. Various
options exist regarding the point during the period when the priority
changes (1/3, 1/2, 2/3 etc).

 Step Down : The objectives priority starts at its assigned value, but at
a predefined time in the period, this priority falls to zero and remains
there for the remainder of the period. As with step-up period biases,
various options exist regarding when the priority change occurs.

140 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 Because the period bias causes the priority of an objective to vary over
time, the effective priority of every objective will also vary over time,
even if only one objective has a period bias setting.

Managing Records With Similar Qualities

During the scheduling process, the Autoscheduler uses the objectives to

determine which records should be mined during each scheduling
period. But occasionally, records with identical values in the fields
controlled by objectives will be available at the same time and the
Autoscheduler must choose between them in some way.

Two options have been provided in these situations, as follows.

 Mine equivalent blocks in Database Order.

 Mine equivalent blocks in ABL Order (First Use Oldest Added).

This option is selected in the Autoscheduler Modes tab of the schedule set-
up tree when the Scenarios tab is active.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 141

 By default, Database Order is selected, which ensures that when more
than one equivalent record is available to a resource, it will select the one
that occurs first in the database hierarchy. Although this option has no
real logical basis, it ensures the Autoscheduler will always re-create the
same schedule, even if the dependency rule sets are applied in a different
order.

If the ABL Order (First Use Oldest Added) is selected, when there is
more than one equivalent record is available to a resource, it will select
the one that has been in the ABL the longest. This does have a logical
basis and it is a much faster process, but it has the disadvantage that if
the order the dependency rule sets are applied in changes, a schedule
may yield slightly different results even though its other settings have not
been changed.

This problem is minor and only occurs in unusual circumstances.

Because of this and the significant speed increase it can produce, we
recommend this option is used, providing the following precautions are
taken.

 Do not change the order of the rule sets in the model if the schedule
configuration is not being changed.

 After changing the schedule configuration, right click the scenarios

Dependency Rule Set item in the schedule set-up tree and choose the
Apply All Rule Sets menu option.

142 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 To provide a visual indication that this problem is occurring, a warning
message is added to the Event Log window (if it is open) whenever the
Autoscheduler has to select a record from a number of equivalent
records.

The most common situation where this problem occurs is the choice of
records for a resource that is scheduling an ancillary material, such as
waste. There are often few objectives assigned to these resources and
they often control fields with discrete distributions.

To overcome this problem, we strongly recommend these resources are

assigned look ahead objectives that help ensure the ancillary resources
are contributing toward the successful achievement of the resources
producing the main products. This not only makes it less likely for
equivalent blocks to occur in the ABL, but also improves the quality of
the products generated by all resources. Look ahead objectives are
described in the following section.

Look Ahead Objectives

Although the AutoScheduler is very good at achieving the objectives in

the current period, it can be harder to ensure this remains the case in
subsequent periods. If, in the process of achieving the current periods
objectives, it fails to maintain the quality of the remaining available
material, look ahead objectives can be used to control the grade of
material produced in subsequent periods. These are objectives that
control look ahead ranking fields in the main database that are calculated
before the schedule is run.

Look Ahead Ranking’s

Look ahead ranking’s are simply fields in the database that are used to
store quality information about to each records successors, rather than
about themselves. These fields are usually calculated using XCM scripts
that are executed after all the dependency rule sets have been applied.

The types of look aheads ranking’s that are required in a model depend
on the deposit, the resources assigned to schedule it and the objectives
assigned to these resources.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 143

 Successors
100,000 t 30,000 t 40,000 t 60,000 t
2.4 g/t 3.4 g/t 1.8 g/t 2.1 g/t

50,000 t
1.3 g/t
230,000 t
2.4 g/t

Predecessor

In the example above, a predecessor (the green record) has 4 successors

(the red records). The blue numbers show the tonnage and gold grade
of these records. The red numbers in the predecessor are the total
tonnage and the weight-averaged gold grade of its four successors.

When a field is used to store the average grade of a blocks successors

rather than the grade of the block itself, it provides an indication of the
grade of the material that will become available if the block was mined.
It can also be used as the basis of a look ahead objective to help control
the grade of the available material.

As most of the successors will have other predecessors, there is no

guarantee that mining this block will make its successors available. But it
will contribute toward their release and in general, this technique does
help to ensure consistency in product grades.

Where there are small pockets of attractive material surrounded by

poorer quality material, this approach may be inadequate. In this
situation, the look ahead ranking may require modification so that it
contains the average grade of a blocks successors and their successors.
There is no limit on the depth of successors the ranking can be based
upon and different weighting’s can be used at different depths.

The many different techniques used to create look ahead ranking’s lie
outside the scope of this manual and if users need help when establishing
look ahead ranking’s for their model, we recommend they contact Runge
to discuss their requirements. One simple example will be used to
illustrate the technique.

Consider a Cu mine where the ore mining resource has a single objective
that is used to ensure the Cu grade of the product meets a fixed target
each period. To establish a simple look ahead ranking, two fields will be
added to the database, as follows.
 The Look Ahead Ranking field is used to store the average Cu grade
of the blocks successors. This field should be weighted against the
Look Ahead Quantity field.

144 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

  The Look Ahead Quantity field is used to store the total tonnage of the
blocks successors. The field is additive and its only purpose is to
weight the Look Ahead Ranking field against.

Once the fields have been created, a script must be written that
determines appropriate values for them. This script makes use of the
GetDependencies(), GetNumberOfSuccessors() and GetSuccessor() xcm
functions to obtain the record numbers of each blocks successors.
Descriptions of these functions can be found in the XCM programming
document, which is available from the Help menu. Once the record
numbers of a blocks successors is known, it is a relatively easy matter to
determine their total tonnage and average Cu grade.

Look Ahead Objectives

Once suitable look ahead ranking’s have been established, look ahead
objectives can be used to manipulate their values. They can make a
significant impact on the performance of an Autoscheduler model,
particularly when results are initially good, but become erratic during the
course of the schedule.

A look ahead objective is basically a standard objective that is used to

control a look ahead ranking field. Experimentation is needed to
determine the most appropriate relative priority to assign the ranking.
The higher its priority, the better the quality of the available ore will
become, but when it rises too high, the ability to achieve the resources
other objectives will decrease.

Look ahead objectives are not as precise as standard objectives because

good blocks that are attractive to the Autoscheduler may have some very
unattractive predecessors. Even when the look ahead ranking are
designed to penalise blocks with particularly bad successors, this still
applies. As a result, they should be considered as first pass objectives
that create a better pool of material for the second pass objectives to
blend into an acceptable product.

The use of look ahead objectives becomes extremely important when the
quantity of available material carried as inventory is reduced. Financial
pressure makes the option of reducing the working inventory quite
attractive, especially in periods when the strip ratio is higher than normal.

The Autoscheduler can only select blocks from the available block list –
the blocks that have had all their dependencies satisfied. As the quantity
of available material falls, the options available to the Autoscheduler also
decrease.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 145

 As the quantity of available material continues to fall, this problem
becomes more significant until the point is reached where there is no
spare available material whatsoever. When the mine is operated in a
waste bound state such as this, every available block of ore will be
scheduled and the ore resource has no choice about its mining sequence
whatsoever.

At most mines, the quantity of available material at any point in the

schedule is maintained at a safe, reasonable level. A compromise is made
between the economic considerations and the mines ability to blend a
suitable product. But when it is essential to operate with little or no
available material, the only way to control the product grade is with look
ahead constraints.

The principle is to ensure the grade of the ore exposed during each
period always meets specification. If the material that is exposed has an
acceptable quality, the scheduled ore will also have an acceptable quantity
because most of the blocks that become available are also mined.

Look Ahead Objectives And Period Bias Settings

When look ahead ranking’s are first applied, they are normally given a
fairly low priority and therefore have a limited effect. As the priority is
increased, the major, long term grade fluctuations will be reduced, but
the short term grade fluctuations increase. This is because the priority
applied to the look ahead ranking is detracting from the objectives that
are controlling the final product grade.

When this situation occurs, changes to the objectives period bias settings
can lead to dramatic overall improvements. The method is best
illustrated with an example.

Consider a mine with two sets of objectives; one set is used to control
the quality of the product (the main objectives) and the other is used to
control the quality of the material made available by scheduling (the look
ahead objectives).

When the model is scheduled using only the main objectives, the results
are generally good, but become erratic in some periods. This is typical of
the situations where look-ahead objectives can be effective. But when
the model is scheduled using both the main and look-ahead objectives,
results are less erratic, but the overall objectives are not well satisfied.

Although the quality of the available material will have generally

improved, the Autoscheduler is less able to select the best sequence of
blocks because it is also trying to ensure the quality of the available block
list remains reasonable.

146 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 The solution to this problem is to apply period biases to the objectives in
both sets. Initially, the look ahead objectives should be assigned a
Decreasing period biases and the main objectives should be assigned an
Increasing period biases.

100

75
Priority

50

25

1
Start of End of
Period Time Period

Grade Objectives (Increasing Period Bias)

Look-Ahead Objectives (Decreasing Period Bias)

With these settings, the schedule will begin each period with a low
priority on the main objectives and a high priority on the look ahead
objectives. It will be focused almost entirely on improving the quality of
the pool of available material and will pay little attention to the quality of
the material it is scheduling.

As the period progresses, this situation reverses and at the end of the
period the main objectives have almost total priority. The model is
totally focused on achieving the period’s objectives, regardless of how
this effects the quality of the available material. This focus occurs when
it is needed most – as the finishing touches are being made to the
product quality. If this approach is successful, some other options can
be evaluated, as follows.

 Change the main objectives period bias to Constant. This may

improve the quality of the schedule further, but without degrading
the quality of the available material.

 Try the use of a Step-Up ½ period bias for the objectives that control
product quality.

 Try the effect of using a Step-Down ½ period bias for look ahead
objectives.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 147

 The user should also experiment with the priority settings after the
period biases have been changed. Even if the priorities have been
studied previously, the changes to the period bias settings will have
changed the behaviour of the model. The normal fine-tuning process
should therefore be repeated.

148 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Chapter 8
RUNNING THE
AUTOSCHEDULER

Introduction

The most difficult part of using the AutoScheduler is defining the rules,
constraints and resources the model requires. Once this has been done,
it is relatively easy to generate schedules for any given scenario.
Furthermore, it is very straightforward to create new scenarios with
slightly different properties, allowing different alternatives to be
explored.

Most of the facilities used when generating schedules (such as reporting

and polygon graphics) are described in XPAC’s on-line help system and
users are encouraged to make use of this tool when seeking help. This
chapter does not replace this information, but rather augments it where
the use of the AutoScheduler differs from the standard scheduling
methods.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 149

Time Slicing

In XPAC 7.4, XPAC’s scheduling engine was upgraded to use dynamic

time slicing for all Autoscheduler resources. This technique eliminates
the approximations associated with the old fixed duration time slicing,
resulting in more reliable schedules. It is also more efficient, resulting in
a small improvement in scheduling speed. However, time slicing was
still required when a scenario made use of stockpiles.

From version 7.5 onwards, XPAC’s scheduling engine has been

upgraded to eliminate the need for fixed duration time slicing altogether.
The Autoscheduler can now handle time slicing automatically and the
time slicing item in the schedule set-up tree has therefore been removed.

The only other feature visibly impacted by this change is advanced

release profiles, which has an option to use the current time slice as its
sub-period duration. In the few models that may make use of this
advanced feature, any release profiles with their sub-period intervals set
to Time Slice will be changed to a period equal to the scenarios time slice
duration when they are upgraded to version 7.5.

Applying Dependency Rules

Although not strictly necessary, we recommended users re-apply all rules

before they start scheduling. This is particularly true if dependency rules
are used that refer to upper level records.

The best way to do this is to right click the active scenarios Dependency
Rule Sets item in the schedule set up tree and select the Apply All Rule
Sets option. The Scheduling | Re-Apply All Rule Sets menu option will also
perform the same function.

When XPAC re-applies all rule sets, it removes all existing dependencies
and re-applies each of the rule sets in the order they are shown in the
schedule set up tree. Maintaining a consistent order is important when
upper level optimisation is being used. Any dependency rule sets that
involve upper level records should be applied after the dependency rule
sets containing only lower level rules.

Various tools are provided to examine and test the dependencies the
dependency rule sets create and these should be used to ensure the
expected dependencies have been generated. A full circular reference
test should also be performed before scheduling begins, by selecting the
Scheduling | Scan Circular References menu option.

150 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 If any of the selected dependency rule sets are not up to date (shown in
red text in the schedule set up tree) when a schedule is run, the user will
be asked whether the dependency rules should be re-applied. In most
situations this option would be accepted.

Mined Out And Prescheduled Blocks

The XPAC database represents a snapshot of a deposit at a specific

point in history and at operational mines, ongoing mining will have
depleted some of the material the model contains. Furthermore,
schedules are normally prepared in advance, with a start date at some
point in the future. In operational mines some of the reserves in the
model will have been depleted by the time the schedule begins.
Position at The Time
Reserves Issued

When Schedule
Based on Face

is Generated

Start Date
Schedule
NOW

Time
Actual Forecast
Mining Mining
(MOQ) (Preschedule)

Material that has already been mined is specified in the Mined Out
Quantity (MOQ) table. The Mined Out Quantities table is opened using
the Scheduling | Mined Out Quantities menu option. Because actual mining
has already occurred and cannot be changed, the same MOQ table will
be applied to every scenario.

Material that hasn’t been mined yet, but is forecast for mining before the
schedule begins is specified in the pre-schedule table. Because the
mining that has been forecast may be different in each scenario, different
pre-schedules can be assigned to each scenario.

When the AutoScheduler generates schedules, it should not consider

material that, by the time the schedule begins, will have already mined.
This is achieved by processing all items in the MOQ and Pre-schedule
tables. This involves adjusting the percentages remaining, percentages
available and processing all dependency rules that have been satisfied.

The entries in the MOQ and pre-schedule tables are processed in the
same way and it makes no real difference which table records are placed.
Users may find it more convenient to define all depleted material in the
pre-schedule, rather than defining it in two separate places.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 151

 If user processing scripts are used to implement dynamic scheduling
rules, care must be taken to ensure pre-scheduled blocks are correctly
processed. This usually involves scanning the records in the MOQ and
pre-schedule tables with a Post Pre-Schedule user processing script. This
must process each record in the same way as the other user processing
scripts would have, if they had been mined during the schedule.

The MOQ and pre-schedule tables are described in XPAC’s on-line help
system along with instructions on their use. These apply to all schedules,
regardless of the scheduling methods being used.

Running A Schedule

Schedules are executed by pressing the schedule start button or selecting

the Scheduling | Run option on the menu when the schedule set up
window has the focus. The AutoScheduler will perform a scenario
validation and then prepare to execute the schedule. As it does so, some
questions will be asked. It may also report an error if it finds the
AutoScheduler has not been configured correctly.

Refreshing Cashed Database Ranges

If the schedule contains constraints and dependency rules that refer to

databases ranges, the user will be asked if the cached ranges should be
used. XPAC creates a list of records in each range to speed up
processing and confirms these are still valid. This question will only be
asked once during each session for each range and the user can choose
not to be asked for any further range by ticking the checkbox.

152 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 If it is unclear whether changes have been made to the database since the
date shown in the dialogue, the user should select No to this question and
XPAC will re-evaluate the range. If the database has not changed, the
Yes option can be selected to skip the re-evaluation process. The user
can also select the Don’t Ask Again For Any Range (this session) checkbox
to avoid being asked the same question for a large list of ranges.

Selecting The Periods To Schedule

The AutoScheduler will then ask which periods should be scheduled.

Because there cannot be any holes in schedule time, the schedule cannot
be started beyond the point where it has been scheduled to previously.
For example, if the schedule has previously been run to the end of
period 10, the schedule can only be started from periods 1 to 11, but not
later.

The user must enter the periods when the schedule should begin and
when it should end to end. The Autoscheduler will check the validity of
these settings and will warn users of any errors.

Using The Global Statistics Cache

A checkbox on the dialogue instructs the Autoscheduler to use the

global statistics cache. In order to achieve the specified objectives, the
Autoscheduler must perform a statistical analysis of the deposit before
the schedule starts. On large models with many objectives, this can take
a considerable amount of time.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 153

 To help reduce the impact of this delay, the statistics gathered during the
first analysis are stored in a cache. Subsequent schedules can then use
the cached information, rather than repeating the analysis of the reserve.
Whilst the global statistics cache can be a very useful feature, users must
remember to turn this checkbox off if any changes are made to the
database.

Configuring Reports To Execute Automatically

A button on the lower right corner expands this dialogue to show some
additional options.

All reports in the schedule are listed in the extended window with a
check box in front of their name. When a tick is placed in these
checkboxes, the associated reports will be run automatically after each
scheduling has been completed.

This feature is generally used to run a small, fairly quick report that
provides immediate feedback on the schedule. Other, more complex
reports are usually run when the schedule has been completed, either
when fine tuning certain aspects or generating a full set of reports.

154 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 Exporting Data For The schedule Analysis Tool

The Export Data For Schedule Analysis Tool instructs XPAC to generate a
log file whenever a schedule is run. Whilst this does slow the schedule
down a little, it provides a large amount of information regarding the
schedule which can be examined using XPAC’s Schedule Analyser tool
(SAT).

If a schedule is executed when this checkbox is selected, a file will be

created with the same name as the scenario and the extension .xsa
(XPAC Schedule Analyser).

Once the <OK> button is pressed, the Autoscheduler will check the
schedule start and end periods are valid and if this is the case, will
proceed to do a full validation of each resource in the scenario and the
entire scenario itself. A detailed validation routine has been developed to
identify possible errors and avoid wasting time on schedules that are not
valid. If any problems are found, these are reported in meaningful error
messages.

The validation and initialisation processes can be quite slow, particularly

with large databases with many available blocks and complex schedule
configurations. To reduce the impact of this delay, status information is
saved the first time a schedule is run during a session. Subsequent
scheduling runs make use of the saved data to speed up the initialisation.

When the AutoScheduler begins scheduling, two progress bars are

shown on the schedule progress dialogue. The first shows the progress
of the whole schedule whilst the second shows the progress of the
current period.

If the AutoScheduler is unable to meet the target (or lower limit when
one is specified) of any resources, an error will be generated informing
the user of the resource that caused the error. It will then terminate the
scheduling run so the user can investigate and rectify the cause of the
problem.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 155

 Once all periods in the scheduling run have been completed, the
AutoScheduler will terminate and the progress dialogue will disappear.
The user can then generate reports, Gantt charts, period progress plots
and mine status plots to analyse the generated schedule. If the option
was selected, a report will also be executed. Such a report would
normally be configured to display its results in a window.

Displaying Information Whilst Scheduling

XPAC allows the user to display additional information as the schedule

progresses. Whilst this is currently a fairly limited feature, it can
sometimes be useful. The schedule analyser tool should be used to get a
more detailed analysis of the scheduling process.

Before any additional information can be displayed, the user must select
which fields he wishes to view. To do this, the AutoScheduler Modes tab
should be selected in the schedule set up tree.

156 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 To activate the feature, the user must first tick the Display Extra Progress
Information checkbox and then select up to three fields for each activity
that will be monitored during the course of the schedule. Any fields of
the associated activity can be selected.

Before the information can be displayed, XPAC must be set to track the
additional field during the scheduling process. The fields that must be
tracked should be entered in the Fields to Track table on the
Autoscheduler modes item of the schedule set up tree.

Certain fields are tracked automatically during the scheduling process,

including all fields used as accumulation fields and objectives. The fields
already tracked by the Autoscheduler can be displayed by ticking the
Display Already Tracked Fields checkbox.

Tracking the data required to generate this display requires additional

processing, which does reduce scheduling speed somewhat. To
minimise this, the user should remove the tick in the Include column
against activities that do not need to be monitored.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 157

 To add fields to this table, a new row should be added by clicking on the
next empty row and selecting a field from the drop-down list box. There
is no need to select fields that are already tracked.

When a schedule is being generated, the additional information can be

displayed by clicking the Show Extra Information button at the bottom
right corner of the Schedule Progress dialogue. This will expand the
dialogue to reveal the selected information.

During the course of the schedule, pressing the Hide Extra Information
button will collapse the dialogue to its previous state. The user can also
pause and restart the schedule at any time using the Pause button.

The first row in the table contains the ABL count, which is often the
most useful information displayed. For each activity, two values are
shown, separated by a forward slash (37 / 37).

158 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 The second value equals the total number of records with this activity in
the available block list. The first value equals the number of records
with this activity in the available block list that are not temporarily
unavailable due to a constraint or other restriction. The first number is
therefore always smaller or equal to the second.

The next section displays statistics relating to the fields that have been
selected in the Autoscheduler Modes item in the schedule set up tree. The
values will be updated after each scheduling step. Up to 3 fields can be
selected for each activity, but only 2 activities can be displayed
simultaneously.

The last two rows in the table shows the quantity of material the
resource has scheduled in the period so far and the quantity it has
scheduled since the start of the schedule. Again, this information is
updated after each scheduling step.

At the bottom of the dialogue is a series of checkboxes with one box per
activity. Information can only be displayed for two activities in the
dialogue at the same time. Therefore only two of the checkboxes can be
ticked at a time and these are used to control which activities are
displayed in the two columns above.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 159

160 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd
Chapter 9
USER PROCESSING

Introduction

To increase the speed of the AutoScheduler, as many scheduling rules

are pre-processed as possible before scheduling begins. This allows the
scheduling engine to optimise the process, greatly reducing the size of
the mathematical model that must be solved.

But sometimes it is not possible to define a scheduling rule before the

schedule begins, because its properties will change over time, in response
to what has been scheduled up to that point. These are called Dynamic
Scheduling Rules because the properties of the rules change during the
course of the schedule.

Dynamic scheduling rules are implemented using User Processing scripts or

Triggers; XCM’s that are automatically executed at pre-determined points
during the course of the schedule. Although the purpose of user
processing scripts are usually quite specific, they are standard XCM’s like
any other.

Although we have provided many different facilities to control the

behaviour of the AutoScheduler and the characteristics of the schedules
it generates, every mine is unique and has it’s own idiosyncrasies.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 161

 Sometimes a model will require scheduling rules that cannot be created
using the standard tools or some site-specific logic must be
implemented. User processing scripts are also very useful in these
situations.

User processing can be considered as an event simulation system within

the Autoscheduler. If a specific event occurs within a specified area of
the deposit, the associated user processing XCM will be executed. The
script can further evaluate the situation and take any appropriate action.
Examples would be changing the maximum capacity for an area of the
mine, modifying cut-off grades and changing a blocks priority.

Selecting User Processing Trigger Events

To activate a user processing script, it must be assigned to an event. The

script cannot be run over a range as normal scripts are and will not
execute until its assigned even occurs. Each resource has its own set of
user processing events, allowing different resources to trigger different
user processing scripts when a particular event occurs.

To view or edit the user processing scripts allocated to a resource, the

Triggers item must be selected under the appropriate resource in the
schedule set up tree, when the Scenarios tab is active. The name of this
item will be green if the resource has been assigned one or more user
processing scripts.

The window is split into two portions. The lower portion lists all the
trigger events the resource can make use of with checkboxes beside their
names. When a checkbox is ticked, an entry will be placed in the upper
portion of the window with the appropriate trigger event. Any
combination of events can be ticked at the same time.

162 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Trigger Event Types

Currently there are ten events that can be used to trigger User Processing
scripts. Different events occur at different times during the course of
the schedule and some of the events can occur many times.

The user can define an unlimited number of User Processing scripts and
they can be assigned any combination of trigger events. The various
trigger events currently available are described below.

Before Loading Schedule

This event occurs at the beginning of the schedule before any processing
has occurred. It will always occur once during a scheduling run,
regardless of the scheduling runs start period.

After Loading Schedule

This event occurs after the Mined Out Quantities and Pre-Schedule tables
have been processed but before scheduling begins. The event will only
occur if the schedule is run from the beginning of the schedule (as
specified in the Calendar Options item of the schedule set up tree), as
this is the only time the MOQ and pre-schedule tables are processed.

Pre Period Event

This event occurs at the start of each scheduling period and will
therefore occur several times during the course of most scheduling runs.
This event is often useful to reset dynamic scheduling rules that apply to
each scheduling period separately.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 163

 Pre Block Event
This event occurs before a block is mined for the first time. It can
therefore occur many times in a period, but only once for each record.

As the script is triggered before the step has occurred, the step will not
have been processed and the reserves will not have been modified. It is
still possible to obtain details of the step that is about to occur, but any
details obtained about the state of the reserve will reflect the condition
before the associated step has occurred.

Pre Step Event

This event occurs before every scheduling step and therefore occurs
quite frequently. It will also occur when the block is mined for the first
time, even though the pre-block step will have also been triggered by this
step.

As the script is triggered before the step has occurred, the scheduling
step will not have been processed and the reserves will not have been
modified. It is still possible to obtain details of the step that is about to
occur, but any details obtained about the state of the reserve will reflect
the condition before the associated step has occurred.

Post Step Event

This event occurs at the end of every scheduling step and is similar to
the pre step event. If the step completes the scheduling of a block, the
Post Block event will also be triggered by this step.

As the script is triggered after the step has occurred, the scheduling step
will have been processed and the reserves will have been modified
accordingly. It is still possible to obtain details of the step that has
triggered the script and any details obtained about the state of the reserve
will reflect the condition after the associated step has occurred.

Post Block Event

This event occurs whenever the mining within a block is complete and is
similar to the pre block event.

As the script is triggered after the step has occurred, the scheduling step
will have been processed and the reserves will have been modified
accordingly. It is still possible to obtain details of the step that has
triggered the script and any details obtained about the state of the reserve
will reflect the condition after the associated step has occurred.

164 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 Post Period Event
This event occurs at the end of each scheduling period and will therefore
occur several times during the course of most scheduling runs. The
event occurs at the end of the period, regardless of whether the targets
for the current period were achieved or not.

After Schedule Runs

This event occurs at the end of the scheduling run and will occur
whether the AutoScheduler was able to complete the full scheduling run
or not.

Add Block To ABL

This event occurs whenever a step causes a record to be added to the
ABL. It is usually used in conjunction with scripting functions that
return the record numbers of the blocks that have been added to the
ABL.

Assigning User Processing Script Properties

To make a script execute when an event occurs, the name of the script
should be entered in the XCM column of the appropriate trigger event.
If more than one script must execute when an event occurs, the event
should be selected in the table and the <Insert> key should be pressed.
This will create a duplicate of the event in a new row, which can be
assigned its own settings.

When an event relates to the mining of a specific database records (Pre-

Block, Pre-Step, Post-Step and Post-Block), it must be assigned a filter range.
The event will only be triggered if the record that has been mined occurs
within the range. This feature helps to minimise the number of times
events will occur, if they only apply to specific records.

The default filter range is <ALL>, but this can be changed by clicking
the cell under the If In This Range column and selecting a new range from
the drop-down list box. This column is greyed out for events that do
not relate to a specific block.

With all User Processing scripts, a range must be specified over which
the XCM will be executed. In addition to any of the user defined ranges,
two special ranges can be specified, ABL (run over every record in the
ABL) and Run Current (run only over the record associated with the
event). These additional ranges are not suitable for all trigger event
types.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 165

 The final column in the table is the Active column. This simply provides
a convenient way of disabling a user processing script without having to
clear the contents of the table. This is very useful when the scripts must
be switched on or off temporarily.

Allowing Dynamic Database Changes

By default, the user is not allowed to modify the database and if scripts
attempt to do this, a warning message will be displayed. To de-activate
this security measure and allow user processing scripts to modify the
database, the AutoScheduler Modes item in the schedule set up tree must be
chosen, with the Scenarios tab active.

If the Allow Database Writes checkbox is not ticked, an error message will
be displayed if any attempt is made to modify the database during the
course of a schedule.

If the checkbox is ticked, user-processing scripts will be allowed to

change the contents of fields in the main and calendar databases without
generating and error. However, it is strongly recommended that fields
are not modified in records that have already been scheduled unless great
care is taken. Failure to observe this recommendation may result in the
report writer generating invalid reports.

166 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Activating Automatic Database Tracking

The ability to modify the main and calendar databases during the course
of the schedule is extremely powerful and is utilised in many different
ways. But it can also be quite dangerous if used incorrectly.

Schedules can be re-run many times and any period prior to the last
scheduling period can be used as the starting point. If dynamic rules
change the contents of the database during the course of the schedule,
the databases original values must be restored before the next schedule is
generated. If this is not done, different results would be obtained every
time the schedule is generated.

In XPAC 7 this process is fully automated, and all changes made to the
database during the course of the schedule are recorded. Whenever the
schedule is re-started from a period prior to the last period scheduled,
the Database Tracking facility will roll back the database and restore it to
the condition it was in immediately before the new start period.

This is illustrated in the following diagram, which represents a time line

for two consecutive scheduling runs (represented by the red arrows).
We will assume a user processing script is being used to modify fields in
the database whenever a block is mined. At the end of the schedule, the
condition of the database reflects the state of the deposit at the end of
the scheduling run (EOP 7).

1st Scheduling Run : Start to EOP7

Undo Changes : P7 to P4

2nd Scheduling Run : SOP4 to EP10

End of Period 1

End of Period 2

End of Period 3

End of Period 4

End of Period 5

End of Period 6

End of Period 7

End of Period 8

End of Period 9

End of Period 10
Start of Schedule

The second scheduling run begins on period 4 and continues until period
10. If the Autoscheduler simply ran the second schedule, it would start
with the database fields assigned values as they should be at the end of
period 7; not at the start of period 4 where the schedule must begin.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 167

 To overcome this problem, XPAC’s database tracking facility monitors
all changes to the database. When a schedule is run from a period earlier
than the end of the most recent schedule, all database changes from the
end of the most recent schedule to the new schedule start point will be
reversed. In the example above, all changes made in periods 4, 5, 6 and
7 will be reversed (the green arrow).

To activate Database Tracking, the Global Options dialogue should be

opened from the Tools menu and the Main Options tab should be chosen.
The appropriate tick box must be selected before database changes will
be tracked and rolled back. This option should not be selected if
dynamic rules will not be used to modify the database, as it does impact
on scheduling speed a little.

It must be realised that as soon as the database tracking feature is

activated, the AutoScheduler will start monitoring all database changes.
Suppose database tracking was activated and then the user ran a script to
initialise the database. When a schedule is generated, the database
tracking facility would immediately undo the changes made to the
database by the XCM, because it must assume this change was made at
the current scheduling time (the end of the previous scheduling run).
Taking any other action could introduce errors if a script was run
between schedules.

We therefore recommend that when database tracking is used, the

database should be fully initialised and prepared for scheduling
immediately before the tracking feature is activated. It should effectively
be the last change made before the first schedule is run. Thereafter, the
tracking facility should remain unchanged until the next time
modifications must be made to the database.

If the user wishes to make any permanent changes to the database after
the database tracking feature has been activated, database tracking must
be de-activated before the changes are made and then re-activated once
the changes have been competed and the database re-initialised.

168 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 An alternative to using the database tracking feature is to manually
initialise the schedule with a user processing script at the beginning of
each schedule. This presents a relatively straightforward solution to the
problem, but does require the user to begin every schedule from the first
scheduling period (as defined in the Calendar Options item in the schedule
set-up tree).

This script would normally be assigned to a Before Loading Schedule trigger

event to avoid the need to execute It manually before every scheduling
run. The format of the script would be the same as a normal script that
initialised the database and as it does not require any functions specific
to user processing, it can also be run as a normal script over a range.
This makes testing of the script far more straightforward.

If written to process each record sequentially (as a typical script would

be), it must be assigned to the execution range <TOP> to ensure every
record is initialised. Improved performance can be achieved by taking
control of the database traverse, but this does complicate the script
considerably. When initialisation scripts must be executed over very
large databases, we recommend users consider writing their initialisation
scripts so they perform their own database traverse. In this situation, the
script would be assigned the execution range Run Current.

Selecting The Variables To Track

By default, the AutoScheduler will only track changes to fields used in

the model, such as those used for accumulation fields, objectives and
constraints. But it will not track every field in the database; to do so
would have too great an impact on performance.

Occasionally, the user needs to track some additional fields that will not
be tracked by the AutoScheduler and these fields must be defined as
tracked fields. To do this, the AutoScheduler Modes item should be
selected in the schedule set up tree, when the Scenarios tab is active.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 169

 The fields that must be tracked should be added to the Fields to Track
table by selecting them from the drop-down list. The Include checkbox
beside each field allows them to be temporarily disabled without having
to delete the entry altogether.

When the Display Already Tracked Fields checkbox is ticked, the variables
the Autoscheduler will track automatically are displayed at the top of the
table. To distinguish them, they are shown with a grey background. This
helps users identify which fields they need to add to the list, as there is
no benefit from adding fields that are already tracked.

170 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Rolling The Database Backwards

Once a schedule has been generated with the database tracking feature
active, the database fields will be in the state the user processing scripts
left them at the end of the schedule. This is emphasised by the date
shown beside the project name in XPAC’s title bar.

But it is sometimes useful to check the values of the database fields

before the schedule had been run, or at some intermediate point during
the course of the schedule. This can be achieved using the Show Database
Changes option on the scheduling menu. This option is only available if
the database tracking feature is active and there are recorded changes
available to reverse.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 171

 The Show Database Changes dialogue allows the user to specify the point
during the schedule where the database must be examined. Once a
period has been selected, the database will be changed so that all fields
contain the values they would have had at the end of the selected period.
The title of the database is also changed to highlight that the database
has been rolled back to an intermediate point during the schedule, and is
no longer displaying its normal values.

There is a special option in the drop down list that causes all the changes
made to the database to be reset to their original values. This is a
permanent change and after it has been selected, the schedule will have
to be re-started from the first period.

The new Schedule Analysis Tool also has a viewer that allows the contents
remaining in the database at any point in time during the schedule to be
examined. This is a far more versatile tool for general use.

Example : Limiting Shovel Movements

A common use of user processing scripts is to limit the movement of

loading equipment when blending to achieve tight grade specifications.
Every time a resource completes a scheduling step, the AutoScheduler
selects the next block for the resource. But trying to best satisfy the
grade objectives can cause an excessive number of shovel relocations to
be scheduled.

This problem occurs because limiting the number of shovel relocations

has not been defined as an objective in the model. In practice, the shovel
will not be relocated if there is only a marginal improvement in the
overall blend. Reducing the number of shovel relocations is therefore as
much of an objective as the grade specifications, even though they are
usually contradictory.

To define the problem mathematically, we will assume that when a block

is close to the current loading position it has an intrinsic attractiveness
regardless of its grades. We will use a value between 0 and 10 to quantify
this attractiveness with higher values representing more attractive blocks.

A database field called the Proximity Index (with code of mPIndx) will
be used to store each blocks attractiveness value. At the start of the
schedule, this will be set to zero indicating they have no attractiveness
what so ever. It would also be possible to flag the areas where mining is
currently taking place to provide an initial starting point.

172 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 As we do not know which blocks will be selected during the course of
the schedule, a user processing script will be used to assign the proximity
index dynamically. This script will be triggered by a Post Step event so
that it will be executed whenever a block is mined. The filter range will
be set to ALL so that mining in any block will trigger the event,
regardless of its location. It is also set to only run over the current block.

The user processing script is quite straightforward and simply writes a

value into the proximity Index of surrounding blocks with larger values
allocated to the closer blocks.

To complete the configuration of the dynamic rule, an objective is added

to the resource that maximises the value of the Proximity Index field.
This will encourage the AutoScheduler to select blocks close to areas
that have recently been scheduled. Initially this should be given medium
priority value relative to the resources other objectives.

When the schedule is executed, every block in the model will have a
proximity index of zero and the new objective will have no effect. But
when a block is mined, its proximity index and that of the surrounding
blocks will be assigned values greater than 1. Furthermore, this value is
highest close to the current digging location and decreases as the blocks
get further away from the current digging point.

Now that some records have values in the Proximity Index field, the new
objective will have an influence over the selection process, encouraging
the AutoScheduler to select blocks close to the previous mining location.

When a distant block has marginally better grades than a block beside
the current loading position, the Autoscheduler would usually select the
distant block, as it will better satisfy the objectives. But when the new
objective is added, the close block may be selected, depending on the
priority assigned to the new objective. When this objective has a high
priority, the distant blocks must be significantly better than the closer
blocks before they will be scheduled. When the priority is lowered,
distant blocks that are only slightly better than the close blocks will be
scheduled.

In most blending situations, limiting the number of loading sites and

meeting product specifications are contradictory. When the number of
loading sites is reduced, product quality reduces. This reduction is often
acceptable, providing it is not too extreme.

The relative importance of an objective when compared to the resources

other objectives is defined by its priority. If the introduction of the new
objective does not influence the grades significantly, the priority assigned
to the new objective can be increased. In most situations this will result
in a further reduction in the number of loader moves.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 173

 But if the introduction of the new constraint causes the grades to move
outside acceptable levels, the priority of the new constraint should be
relaxed. The use of a relatively high priority but with one of the
decreasing period biases may also improve the overall schedule.

When long term schedules are being generated, the values in the
proximity Index are usually left with the values assigned to them by the
user processing scripts for the entire schedule, but they can also be reset
at the end of each period. A separate user processing script that is
triggered by a Post Period event would carry out this task.

In short term scheduling, it is often necessary to model the location of

the shovels more closely. In this situation the user processing script
clears previously assigned proximity indexes at the same time as it assigns
new ones. Delays can also be built into the algorithm so the proximity
values will reduce over time.

The use of user processing scripts in this manner is straightforward and

can achieve a wide range of objectives. The ability to adjust the priority
placed on the associated objective is also extremely useful.

174 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Chapter 10
SCHEDULE ANALYSIS TO OL

Introduction

The Schedule Analysis Tool (or SAT) is a general XPAC feature that can
be used with any of the scheduling methods. But as its real strength lies
in the analysis of the many alternative schedules the Autoscheduler can
produce, a description of how the SAT is used will be given in this guide.

Whilst the definition of individual scheduling rules in the Autoscheduler

is relatively straightforward, the interactions between these rules during a
schedule can be extremely complex. Fortunately the user is protected
from this complexity during the scheduling process, but this doesn’t help
if the schedule failed for some unknown reason. It can be very difficult
to determine where such a problem lies and whether the cause is one of
the rules or the way a rule has been implemented.

The SAT is a new tool that has been developed to help identify what is
happening during the course of a schedule. Graphical animations of a
schedule have proved to be very useful visualisation tools. The SAT
extends the concept of animation, but to the contents of tables and
graphs rather than graphics. In this respect, the SAT provides control
over the fourth dimension of a schedule – Time.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 175

 When analysing a schedule, different information about the schedule is
required at different times. Furthermore, the data relating to a schedule
is not fixed; it refers to the situation at a particular point in the schedule
and so it changes when a different point in the schedule is examined.
The SAT has been designed to overcome the difficulties associated with
analysing a wide range of data that changes dynamically with time.

The SAT acts as a manager for SAT Viewers. These are simply windows
that display different types of information about the schedule at a given
point in time (referred to as the Schedule Time). The SAT organises these
viewers in a tree structure whilst making it easy to create, edit and delete
them. It is also makes it easy to select different combinations of viewers
at different times.

The user has complete control over the format of these viewers and in
most situations, ranges and other filters can be applied to customise the
information displayed. Several SAT viewers of the same type can be
displayed, simultaneously and each can be configured to display different
data (for example, data for different parts of the mine or different
resources).

The SAT also provides controls that allow the user to advance or rewind
the current scheduling time. As this is done, all visible SAT viewers are
updated to reflect the new scheduling time. These controls allow you to
animate the tables; you can wind time forwards and backwards and the
viewers will all update their contents to reflect the new schedule time. A
kind of video editing tool for schedules.

176 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 This is the very first version of the SAT and so it has had very little
exposed to the real world. There are still a few rough edges that need to
be smoothed out you should really consider this version a prototype. It
is generally better to get some information slowly rather than no
information quickly!

We have focussed on functionality for this release and must still optimise
the SAT for speed and efficiency. It can run quite slowly with big
models and speed decreases as the number of viewers is opened.

Although we hope to make significant improvements to the SATs speed

in future releases, we recommend you develop the habit of closing
viewers when they are no longer needed. It is certainly worth avoiding a
screen full of viewers like the screenshot in the introduction to this
chapter.

We also recommend that you run the SAT as a stand along application
without XPAC running in the background. The SAT runs several times
faster in this mode with no loss of functionality.

Preparing To Use The Schedule Analysis Tool

The schedule analysis tool obtains its information from two data files
rather than from the Autoscheduler, eliminating the need to re-schedule
the model every time you wish to use the SAT.

These files will be generated automatically whenever a schedule is run,

but as this reduce the scheduling speed, the facility must be activated.
This can be done whenever the Run Scenario option is selected.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 177

 Whenever a scenario is scheduled, XPAC displays the Select Period Range
dialogue and waits for the user to enter the start and end periods for this
scheduling run. A button on the lower right corner expands this
dialogue to revealing more options. The data files used by the SAT will
not be created unless the Export Data For Schedule Analysis Tool checkbox
is ticked.

When this option is selected, XPAC will generate two schedule analysis
data files every time a schedule is run, as following.
 The SAT’s configuration file has the name ProjectName.xsa where
ProjectName is the name of the XPAC model being scheduled. This
file stores the configuration of each viewer and because it is
associated with the SAT during installation, it will open automatically
if it is double clicked in Windows Explorer. Windows short-cuts to
this the xsa file can also be created to make opening the SAT easier.
 ProjectName.ABL is used to store data relating to the ABL as the
schedule progresses and can be very large when the ABL contains
many entries.

The data files are created in the .\ScenarioData\Scenario-n\ directory, under

the current project directory. The files will be overwritten each time a
scenario is re-scheduled, although a copy of the file can be made.

If you wish to preserve the SAT data files for a scenario, we recommend
a copy of the model is made to ensure the SAT files remain synchronised
with the database. Any major changes to the database would invalidate
the SAT files.

178 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

Running The Schedule Analysis Tool

The schedule analysis tool can be run as an independent application or

from within the Autoscheduler. The latter option does allow the user to
switch back and forth between the SAT and XPAC but it does
significantly increase the SAT’s response time when the schedule time is
changed. For this reason, we recommend that in general, the SAT is run
as a stand-alone application without XPAC open in the background.
Whilst the SAT is running in this way, the XPAC model should not be
opened unless the SAT is closed beforehand.

To run the SAT tool from outside XPAC, click the Windows Start
button and select the Programs | Runge Software | Schedule Analysis Tools
menu item. A dialogue box will request the name of the schedule
analysis data file (the .xsa file) that must be analysed. The SAT can also
be executed by double clicking on the .xsa file directly in the windows
Explorer.

To execute the schedule analysis tool from within XPAC, the XPAC
Schedule Analyser button on the tool bar should be clicked. The other
options described for execution as a stand alone application will also
start the SAT when XPAC is open.

When the SAT is run with XPAC open, the speed at which the SAT
responds to changes in schedule time drops significantly. It is also
impossible to close XPAC whilst the SAT is open. For these reasons,
we recommend the SAT is not used when XPAC is open unless this is
absolutely necessary.

When the main SAT window opens, all visible SAT viewers will also be
opened with the same size, location and properties as they had the last
time they were used. Closing the main SAT window will also closes all
SAT viewer windows. Similarly minimising the main SAT window will
also minimise all viewer windows.

Using The Main SAT Window

The purpose of the main SAT window is to control Schedule Time that all
SAT viewers are synchronised to. Several tools have been provided to
simplify this process, whilst displaying what the current scheduling time
is.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 179

 The main SAT window consists of a menu and tool bar, a set of time
controls and a combined output path. These are all different ways of
displaying the current scheduling time and allowing it to be changed. If
you adjust any of the time controls or select somewhere in the output
path, scheduling time is adjusted and all time controls respond
accordingly. There are also buttons that advance and rewind scheduling
time.

The pair of sliders at the top of the main SAT window provide a visual
indication of the current scheduling time and a means of changing it
rapidly. The upper slider controls the current period in the scheduling
run whilst the lower slider controls the current time within the current
period. Controls are also provided to directly enter the period, date and
time. As these are changed, the sliders update accordingly.

A combined output path is displayed underneath the slider controls and

this is also linked to the current time. As the scheduling time is
advanced, the steps that are occurring at that point in the schedule are
highlighted. Likewise, if you select a different step in the path (or
move/page up or down), scheduling time will be adjusted to equal the
selected steps start time.

180 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 As with normal output path windows, the fields in the SAT’s combined
output path table are completely user definable. Any main or calendar
database field can be moved into and out of the table, along with any if
the standard output path fields. The type of information displayed for
each field can also be modified using the option buttons on the right of
the dialogue. The path fields are modified by right-clicking on the
combined output path window and selecting the Path Fields option.

At the bottom of the combined output path is a period summary that

shows the totals for each period. As scheduling time changes, this will
update accordingly. Initially the summary will be uncalculated and the
numbers will be shown in read. These are calculated by pressing the
<F9> key or selecting the View | Calculate Totals menu option. The period
summary has tabs on the bottom to select the output path of a single
resource or all the resources. Its fields are also user-definable and are
independent of those fields selected in the path window.

If the model contains stockpiles, a stockpile summary will be shown

below the period summary. This provides a period-by-period summary
of the material moved to the stockpiles, material depleted from the
stockpiles and the inventory remaining in the stockpiles. Again, tabs are
provided to view information about a single stockpile or all the
stockpiles and fields in the table are user definable.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 181

 If the stockpile summary window is not required, it can be removed by
dragging its divider to the bottom of the window. Once this has been
closed, the period summary window can also be closed in the same way.

Selecting SAT Viewers

SAT Viewers are the windows that display information about the
schedule. This information is not static and is updated whenever
scheduling time is advanced or rewound, ensuring all SAT viewers
remain synchronised.

There are currently four types of SAT viewer and each one displays a
different type of information. Each type also has a set of properties that
allows the information it displays to be customised. We hope to add
many new types of SAT viewers in future releases. The four types
currently available are as follows.
 ABL viewer
 Database Viewer
 Dependency Viewer
 Material Distribution Viewer

182 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 The normal way of creating new SAT Viewers is to open the Edit Viewer
Properties dialogue using the appropriate tool bar button or the View | Edit
Viewer Properties menu item. This contains a tree showing all the viewers
that have been defined, as well as controls to modify their properties.

When first opened there are no SAT viewers and so the tree initially
contains only four parent items; one for each type of viewer. When SAT
viewers are added, they will be displayed under the appropriate parent.

To add a new SAT viewer, the Add button should be pressed. This
opens a dialogue that requests the type of rule to be added.

As soon as OK is selected, the new SAT viewer window will be opened

and the tree structure in the viewer tree will update itself. When the new
item is added to the tree, it will be placed under in the correct parent and
the Rename button can be used to provide a more meaningful name.

The icon and parent indicate the type of SAT viewer, but not how this
viewer differs from others of the same type. This is the information that
should be placed into its name.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 183

 When the user selects one of the SAT viewers, the properties of that
viewer are shown on the right hand side of the dialogue.

This is not the only way a SAT viewers properties can be changed, and
once the SAT viewer is visible, its properties dialogue can be opened
simply by right clicking on it. The properties of each type of SAT viewer
will be described later in this chapter.

Whenever an individual SAT viewer is selected in the tree, the Viewer

Window Is Visible checkbox allows the SAT viewer to be displayed or
hidden. Clicking on a SAT viewer’s close button will also hide its
window and remove the tick from its visibility checkbox.

When it is no longer required, the List Of Schedule Viewers window should

be closed. You will not be able to change the current scheduling time in
the main SAT window or select a viewer with this dialogue open.

Each of the SAT viewers is placed in an unconstrained window that can

be placed anywhere on the desktop and they are not restricted by the
boundaries of the main SAT window. Whilst this allows you to organise
the windows in any manner, it can quickly become confusing if a
multitude of disorderly windows are allowed to take over. It’s also easy
to loose a SAT viewer underneath others.

It is worthwhile keeping the viewers well organised when using the SAT.
There is a temptation to configure the SAT with one viewer of each type
occupying a different part of the screen. Whilst there is nothing wrong
with this, the SAT was not really designed to be used in this way.

184 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 It is very easy to open, edit and close viewers. Whenever you need to see
some new information, you can simply pop a new viewer onto the screen
and assign appropriate options.

Over time, some viewers will be refined for specific tasks, particularly
with the viewers that are highly configuarable, such as the Material
Distribution viewer. These should be given meaningful names so they
can be identified and opened when required.

It is advisable to keep viewers closed when you do not require the

information they contain. Every open viewer increases the workload
when the scheduled time is changed, reducing the speed you can move
through the schedule. As it is easy to hide and display different viewers,
it is better to get into the habit of hiding viewers when they are no longer
required, rather than leaving them to consume computer resources.

ABL Viewers

ABL viewers are designed to show the contents of the available block list
at any point during the course of the schedule. These are the blocks that
have had all their dependency rules satisfied and can therefore be
selected for mining.

The ABL viewer displays a table containing every block within the ABL.
By default, this table contains each records original ADF value and their
current ABL value (after any mining has taken place).

The last columns in the table show whether any constraints or other
rules have temporarily made the blocks unavailable. In a future release,
we hope to expand this facility so you can identify which constraint (or
constraints) is responsible for preventing each record in the ABL from
being scheduled.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 185

 When you right click on an ABL viewer, the viewers Properties dialogue
will be displayed. These properties can also be accessed by selecting the
appropriate viewer in the Edit Viewer Properties dialogue.

This viewers properties allows the table of ABL records to be filtered by

resource. A record is only appropriate for a resource if it contains a
quantity in one of the resources ADF field. When only a sub-set of the
resources are selected, ABL records that are not appropriate for the
selected resources will be displayed in grey.

The properties dialogue also contains a Fields Displayed button, which

allows the standard fields in the ABL table to be customised. The user
can select any fields from the main and calendar databases as well as any
of the standard ABL fields.

Database Viewers

The database viewer looks in many respects like a normal view of the
main database. On the left is a tree displaying the database hierarchy and
on the right is a table showing the data.

186 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 But the data shown is not the total quantities the database would usually
contain. Instead either the quantity mined from each record so far in the
schedule, or the quantity remaining in each record will be shown.
Obviously, both will change whenever the scheduling time is changed.

The database hierarchy is fully supported and as you move around the
hierarchy, the right hand table changes accordingly. The database is not
re-calculated when scheduling time changes, and so the upper level
records will turn red in the tree to indicate they are no longer valid. The
<F9> key should be pressed to re-calculate the data.

When you right click a database viewer, its properties dialogue will open.
Selecting the appropriate viewer in the Edit Viewer Properties dialogue will
also provide access these properties.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 187

 There are only two options available at the present time. The user can
either set the database to show the reserves remaining in the deposit at
the current scheduling time or the reserves that have been mined up to
the current scheduling time.

Dependency Viewers

Dependency viewers allow the dependencies associated with a single

record (the Master Record) to be studied as scheduling time changes. The
master record is shown in the centre of the window, with red arrows
pointing to its predecessors and blue arrows pointing from its
successors.

As scheduling time advances, the current record does not change.

Instead the lower half of each records box is shaded to represent the
percentage of that record that has been mined at the current scheduling
time.

Typically, each record will be unmined and therefore unshaded. But as

the scheduling time advances, the predecessors will start to be scheduled
and as this occurs, the lower half of their box will be shaded.
Throughout this stage, the master record will be shown with a red face in
its top right corner indicating it is unavailable.

Once all the predecessors have been scheduled the red face will change
to a green face, indicating this record is now available for mining. As
scheduling time is advanced still further, the master record will be mined,
followed by its successors.

This schematic is only intended to be an indicative representation of the

scheduling process. Neither release profiles nor lags associated with any
of the dependencies will be taken into consideration.

188 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 When you right click a dependency viewer, selecting the Properties menu
item will open its properties dialogue. These properties can also be
accessed by selecting the appropriate viewer in the Edit Viewer Properties
dialogue.

The only property that can be adjusted at present is the Master record.
The record number of the required record must be entered in the text
box. When a record is selected, the viewer is re-drawn to show the new
record, along with its successors and predecessors.

Once the viewer is open, you can make any of the displayed records the
master record by double clicking on it. This allows you to follow a chain
of dependent records backwards or forwards through the model.

You can also change the master record by right clicking on a row in the
main SAT windows combined output path and selecting the Update
Dependencies For This Record menu option. The selected item in the
combined output path will become the master record. This feature only
effects the first dependency viewer you created and if this option is
selected when the viewer is not visible, it will be displayed automatically.

Material Distribution Viewers

This viewer displays a series of histograms that show the distribution of

a grade or other quality variable over a specific portion of the mine.
Although each viewer can only shown a histogram of a single quality
variable, it can display plots for several different populations at the same
time. Each of these distributions will then update themselves whenever
the scheduling time is changed.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 189

 Viewers can be configured to plot any quality field and it can be
weighted against any field (including the preset value Count). The user
can also select any combination of populations and each one will be
displayed in the plot as an additional series.

Right clicking on the viewer will open its Properties dialogue. This
dialogue has 3 tabs, with each one used to assign different properties.
The dialogue initially opens on the General tab. These properties can also
be accessed by selecting the appropriate viewer in the Edit Viewer
Properties dialogue.

The general tab allows the user to select the fields the histogram should
be based upon and the populations that should be displayed.

The Frequency Field is used to determine which field contains each records
material quantity. This must be an additive field and should have the
same activity as the Interval field.

190 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 The Interval Field is used to determine the quality of each record. This
must be a numerical field and in most situations, it will be a weight-
averaged field.

The Population Types list box displays the 9 populations that can be
displayed on the histogram. The suer can select any combination of
these populations, although some combinations will be more useful than
others. The populations currently available are as follows.
 Initial Deposit : This population includes every record in the
deposit. As this uses the initial database values, the distribution of
this population will not change over time. This is usually used as a
reference to compare the other populations against.
 Initial Deposit After Pre-Schedule : This population is similar to
Initial deposit population, although it excludes material within the
MOQ and pre-schedule tables. Again, it will not change as
scheduling time changes.
 Mined in Schedule : This population includes all material that has
been scheduled so far. The quantity of material in this population
will increase as scheduling time is advanced.
 Remaining Deposit With Stockpiles : This population includes all
the material remaining in the deposit at the current scheduling time,
including the material that is residing in stockpiles. The quantity of
material in this population will decrease as scheduling time is
advanced.
 Remaining Deposit Without Stockpiles : This population is
similar to the remaining deposit with stockpiles, but excludes
material residing in stockpiles. The quantity of material in this
population will decrease as scheduling time is advanced.
 Remaining Stockpiles : This population includes all material that
resides in the stockpiles at the current scheduling time. The quantity
of material in this population will vary as time changes and can
increase or decrease throughout the schedule.
 Mined in Period : This population includes all material scheduled in
each period. The quantity of material in this population will increase
during each period, but will fall to zero at the end of each period.
 ABL Entries : This population includes all material that has had its
dependencies satisfied and has been added to the available block list.
The material in this population will increase and decrease throughout
the schedule as blocks are mined and new blocks become available.
It should be noted the current version of the SAT does not consider
the effects of release profiles and considers a block as available, as
soon as any of the block becomes available. As a result this
population may overstate the quantity of material slightly.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 191

  Unconstrained ABL Entries : This population includes all material
within the ABL that is prevented from being scheduled by period
and capacity constraints. The quantity of material in this population
is always smaller or equal to the ABL Entries population. The
population also ignores the effects of release profiles.

To assign details of the intervals the histogram will use, the Interval tab
should be selected in the properties dialogue.

The three test boxes in the dialogue allows the user to specify the lower
limit of the first interval and the upper limit of the last interval, together
with the number of intervals required. XPAC will then automatically
determine the upper and lower limits of each interval.

In many populations, there will be a small number of outlying values,

both above and below the majority of the population. The Combine
Values Below Starting Value checkbox causes all material with a quality
value below the starting value to be considered as part of a single interval
at the start of the distribution. The Combine Values Above Ending Value
checkbox performs the same function, but for material with a quality
value above the ending value.

The advanced tab on the viewers Properties dialogue provides access to

some additional settings.

192 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd

 The range list box allows all populations to be filtered based on a
database range. If a record within a population falls inside the specified
range, it will be included in the plot. If the population lies outside the
range, it will not be included in the plot. This allows the user to analyse
trends in specific portions of the deposit as well as in the total deposit.

The Chart Designer button provides access to XPAC’s chart design tool.
This allows the format of just about every component of the chart to be
modified. Some examples of how the basic plot can be formatted are
shown below.

XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd 193

194 XPAC 7.5 AutoScheduler User Guide /  Runge Pty Ltd