See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261274337

Why the mining industry needs a reference architecture for automation

initiatives

Conference Paper · July 2013

DOI: 10.1109/AIM.2013.6584357

CITATIONS READS

4 92

2 authors, including:

Peter Ross Mcaree

The University of Queensland
98 PUBLICATIONS 1,162 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Dimension Reduction for Nonlinear Discontinuous Data View project

Predictive Maintenance View project

All content following this page was uploaded by Peter Ross Mcaree on 01 May 2023.

The user has requested enhancement of the downloaded file.

2013 IEEE/ASME International Conference on
Advanced Intelligent Mechatronics (AIM)
Wollongong, Australia, July 9-12, 2013
Why the mining industry needs a reference architecture for automation
initiatives
John J. Dudley and P. Ross McAree
Abstract- Automation is increasingly seen by the mmmg
industry as a lever to reduce costs and improve safety. The
deployment and integration of technology in mining is today
usually done by adopting bespoke solutions where opportunities
are identified. There is limited attention given to the broader
needs that might be relevant in a complete mine-wide automa­
tion solution. The missing overarching plan for integrating
and deploying autonomous systems is what is referred to
in other industries as a reference architecture. This paper
presents a broad evaluation of the challenge of developing
a reference architecture for mining automation. The concept
of a reference architecture for mining is first investigated by
reviewing analogous efforts undertaken in other industries.
These efforts are subsequently evaluated against the unique
requirements of the mining industry. A set of generalised
mining automation architectural models are presented as an
indicative representation of the peculiar challenges that must
be confronted by such an artefact. The paper concludes with
a summary of the core challenges identified around creating a
reference architecture for mining automation and suggestions
on how these challenges might be addressed.
I. INTRODUCTION
Automation in the mining industry is being driven by
the ongoing imperative to improve safety, productivity and
to address the shortage of available skilled workers. Wide
ranging technology is being developed and deployed to
exploit these opportunities where identified. However, the
pace of uptake and the breadth of the front on which
development is occurring exposes the industry to a disjointed
and confused landscape. In particular, autonomous systems
and equipment that function effectively in isolation may
be ill-suited to integration into a comprehensive mine-wide
automation solution.
In such a landscape, there is significant risk that the
industry's pursuit of a mine-wide automation solution will
be hampered by the following obstacles:
• Lack of a common language and taxonomy: The mining
industry's engagement with automation is challenged by
a limited vocabulary upon which to base rich discus­
sions relating to overarching design and use.
• Independent technology development: The underlying
technology and equipment is developed by different
groups under different lifecycles using different devel­
opment tools. Without a common push for interoperabil­
ity and compatibility, significant additional work will be
required to integrate.
J. J. Dudley and P. R. McAree are with the School
of Mechanical and Mining Engineering. The University of
Queensland. St Lucia. QLD, 4072, Australia Email: ( J. J.
Dudley) j.dudleyl@uq.edu.au, (P. R. McAree)
p.mcaree@uq.edu.au
978-1-4673-5320-5/13/$31.00 ©2013 IEEE
Authorized licensed use limited to: University of Queensland. Downloaded on May 01,2023 at 22:47:40 UTC from IEEE Xplore. Restrictions apply.
• Additional demands on skills: The design, development
and deployment of automation technologies for mining
requires knowledge that varies dramatically in its matu­
rity across the industry. If the advantages of mine-wide
automation are proven convincingly in early trials, the
race to deploy across all operations exposes the industry
to still greater pressure around skills availability. If such
deployment has no consistency, then this will further
exacerbate skills shortages.
• Altered responsibilities: The replacement of human
roles by autonomous systems fundamentally alters the
responsibility structures to which the industry is ac­
customed. Without an overarching vision, the industry
will face significant difficulties in adapting to these new
structures.
• New safety risks: Autonomous systems introduce unique
safety risks around their operation. Without understand­
ing the complexities of the complete system, it will be
difficult to ensure these risks are properly understood
and addressed.
Each of these challenges has the potential to delay or
stifle the advantages offered by mine-wide automation. There
is thus a convincing argument for the industry to take a
collaborative approach to finding ways to address the above
challenges. These issues are industry-wide and significant
effort may be saved by sharing a common approach. A
proposed method is the compilation of industry accepted
guidance around the architectural design and deployment
of automation technologies in the mining environment. This
concept is referred to within this paper as a Mining Automa­
tion Reference Architecture or MARA.
This paper presents the outcomes from a body of research
conducted to explore the unique challenges associated with
developing a reference architecture for mining automation. A
review of the approaches taken by other industries as well as
efforts underway in the mining industry is presented. These
approaches are examined for potential transferability to the
unique needs of the mining industry. A collection of repre­
sentative architectural models are presented to reveal some
of the dimensions of the problem. The paper is concluded
by a review of the key challenges and suitable steps towards
developing a reference architecture for mining automation.
II. ANALOGOUS EFFORTS FOR S TANDARDIS ING
ADVANCED TECHNOLOGY INTEGRAT ION
Industries and organisations are quick to leverage ad­
vanced technology when its benefits are compelling. The
mining industry may learn from the approaches followed
1792
by others when new technology must be integrated en
masse and when distinct requirements around consistency
and expandability exist.
The diverse approaches reviewed are separated into three
categories: standardisation, conceptual architectures and risk
management. Significant overlap exists between these ap­
proaches. The standardisation of technology integration may
leverage a combination of all three. Nevertheless, it is
useful to make the distinction here in order to highlight
the potentially diverse dimensions of defining a reference
architecture for mining automation.
A. Standardisation
One commonly pursued method to support the introduc­
tion of new technology is through the specification of stan­
dards. Standards guide development and integration by being
definitive and explicit. A standard may, by way of example,
define a message format so that connected components com­
municate through an established and fixed language. By com­
plying with such standards, systems engineering becomes
simpler, particularly where multiple vendors contribute to the
solution. Standardisation brings significant value when it is
correctly applied, but efforts to standardise at the wrong time
or wrong level of abstraction result in procrustean edifices
that stifle, rather than facilitate, innovation. Standardisation
is best applied when the solutions to generic problems have
matured sufficiently that the benefit of solving a problem in
a specific way is both widely understood and is established
as best practice and there is a clearly identified need for the
'standardised' solution.
The Automatic Identification System (AIS) for ship po­
sitional information exchange is an example of an inter­
nationally standardised approach to exploiting the benefits
of a new technology. The challenge was to leverage posi­
tioning technology to supplement marine radar in situational
awareness for ships. To aid and guide the development of
such systems, the International Telecommunication Union
defined technical and operational characteristics in ITU-R
M.1371 (most recently updated in 2010 [I D. This standard
defines message types and data structures as well as the com­
munication framework to be used. For example, a position
report will contain a 'navigation status' for which 4 bits are
allocated and the range of possible statuses are defined (i.e.
o = under way using engine, I at anchor, etc.).
= systems. Their power is in providing an exemplar which
Standard NATO Agreement STANAG 4586 [2] was de­
fined in order to establish a convention for UAV control
system interfaces. The aim of the agreement is to promote
interoperability of UAV systems across NATO combined ser­
vices. STANAG 4586 defines an architecture and a message
set such that UAVs and control stations might be interoper­
able irrespective of manufacturer and user. The message set
supports low level control such as commanding a velocity
change through to supervisory functions such as assigning
waypoints. The concept of a Vehicle Specific Module ( VSM)
is also introduced as a software function that translates
STANAG 4586 compliant messages and protocols into the
specific formats required by the UAV and vice versa. This
1793
Authorized licensed use limited to: University of Queensland. Downloaded on May 01,2023 at 22:47:40 UTC from IEEE Xplore. Restrictions apply.
approach has encouraged the commercial pursuit of third
party development kits that UAV manufactures can employ
to ensure compliance.
Within the mining industry, the International Rock Ex­
cavation Data Exchange Standard (IREDES) body seeks to
define a standard communication language. Work to date
has concentrated on specification of XML schemas for
exchanging data sets relevant to operation of drill rigs and
LHDs [3]. The ambition of the organisation is to expand
the coverage of such schemas across all required mine data
communication [4].
To some, standards are seen as the panacea for the wide
set of challenges ahead for mining automation. In the long
term, this is a reasonable assertion. In the shorter term,
standardisation efforts around whole-of-mine automation will
flounder. The technology of mining automation and the
implementation of these technologies must undergo a journey
of maturation that distills best practice ways of solving
generic problems. The key milestones in this journey will
be the identification and articulation of these 'generic' prob­
lems themselves. This remark does not vitiate against the
application of existing standards where they are relevant and
suited. Rather, it reveals that the value that comes from
standardisation is driven by the recognition of the benefits
of having standards addressing distinct generic problems.
Consider the following example. A likely candidate for
standardisation is the exchange of spatial position informa­
tion between sub-systems of an automation solution, e.g. be­
tween automated haul trucks in a surface mining application.
Standardising this functionality, not dissimilar from the AIS,
is logical. However, standardisation requires knowledge of
what sort of information is relevant and useful for exchange.
A compelling problem requiring such information exchange
as its solution must first be identified and its requirements
distilled. Standardisation before this understanding is gained,
will not deliver a solution that represents best practice and
may actually hinder progress towards an effective solution.
B. Conceptual architectures
An alternative approach to supporting technology intro­
duction is the provision of conceptual guidance. Concep­
tual architectures promote consistency through highlighting
sensible ways to structure and utilise potentially complex
may be subsequently adapted to a specific context. They
differ from standardisation efforts by promoting consistency
in design rather than in detail.
A good example of a conceptual approach to system
architectures is the ISA-95 set of standards for Enterprise
Control Systems. The standard seeks to address the challenge
of integrating autonomous manufacturing systems with enter­
prise systems, i.e. integrating order processing systems with
production scheduling and production control. ANSI/ISA-
95.00.01-200, Enterprise-Control System Integration [5] de­
fines terminology and presents models for describing the
organisation and linking of system components. Several
techniques are employed in this standard to aid thinking and
decision making regarding the structure and organisation of
complex systems. A collection of hierarchical models of the
manufacturing and business systems are presented to provide
context for subsequent discussion of control and enterprise
domains and their interfaces. A collection of object models
are also presented which illustrate the structure and flow
of information throughout the system. The ISA-95 standard
dedicates significant text to defining key terms such that a
common conceptual language is available for use in rich
discussions.
The value of ISA-95 and similar conceptual approaches
are in the way they allow complex systems to be described in
general terms that reveal function and form unobfuscated by
specific detail. Their role is in distilling best practice as well
as logical structures and usage. A conceptual architecture
may be insufficient to guarantee interoperability of compo­
nents in itself, but does facilitate subsequent standardisation
efforts, as required. The conceptual architecture is arguably
an essential precursor for standarisation when the system is
complex and no precedent can be mined for established best
practice.
C. Addressing risk
The introduction of new technology inevitably changes the
risk profile of systems and processes. A number of examples
exist within other industries where a proactive approach
has been employed to mitigating risk associated with new
technology integration.
IEC 61508 [6] seeks to establish a defined life cycle
for identifying, addressing and managing systems respon­
sible for ensuring safe operation of equipment. It promotes
consideration of risk and safety during the system design
phase and provides guidance on determining requirements
for bridging the gap between intolerable and tolerable risk.
The IEC 61508 standard is a generalised version of concepts
first developed in the process industry.
The application of IEC 61508 to new technology integra­
tion inevitably influences the system architecture. The min­
ing automation system does present certain potential risks,
particularly around mobile vehicle interaction. The systems
required to mitigate such risk are expected to be relatively
complex. To formalise and add rigour to the process of risk
mitigation, there is value in including established practices,
such as those recommended by IEC 61508 and similar
standards, in a reference architecture for mining automation.
Within the mining industry there have already been moves to
incorporate such standards for the design and maintenance of
electrical and mechanical safeguards [7]. Despite this, there
are limited examples of carefully considered and tested-in­
use applications of IEC 61508 within the mining industry that
might aid understanding and further use. There are still fewer
examples of the standard applied to complex autonomous
mining systems. The development of a reference architecture
for mining automation presents a unique opportunity to
incorporate the practices of IEC 61508 at a conceptual level
with meaningful generality. This should support subsequent,
more detailed efforts in context as best practice and in-
1794
Authorized licensed use limited to: University of Queensland. Downloaded on May 01,2023 at 22:47:40 UTC from IEEE Xplore. Restrictions apply.
use testing elucidate appropriate needs and methods of risk
mitigation.
The separation of risk mitigation functionality from oper­
ational functionality is another method employed to make
high-risk technology integration tractable. Under this ap­
proach, risk mitigation functionality can be addressed dif­
ferently from the general functionality required to enable a
system to work. In such circumstances, the risk mitigation
functionality may be addressed through more prescriptive
means. An example of such an approach is the isolation of
'Sense and Avoid' functionality from the broader require­
ments of UAV operation in civilian airspace. The concept of
'Sense and Avoid' is the autonomous replication of the 'See
and Avoid' principle for manned aircraft under visual flight
rules.
The removal of the pilot and the need to replicate the
'See and Avoid' paradigm is not dissimilar from the expected
demands on unmanned vehicles operating in mining. Recog­
nising the growing demand for UAV operation in civilian
airspace, and the need to ensure 'equivalent level of safety
(ELOS)', effort was specifically concentrated on the required
functionality to manage the associated risks. In 2004, a subset
of the ASTM Committee F38 on Unmanned Aircraft Systems
released ASTM F2411 (since updated in 2007 [8]). ASTM
F2411 seeks to define the "design, construction, and per­
formance requirements necessary for the technical reliability
of airborne sense-and-avoid (S&A) systems that support the
detection of, and safe separation from, airborne objects such
as manned or unmanned aircrafts and air vehicles" [8]. By
compartmentalising and specifically mapping risk to required
functionality, the process of technology development and
integration is given clarity and direction.
III. THE UNI QUE CHALLENGE IN M IN ING
The development of a reference architecture for mining
automation must recognise the unique demands that char­
acterise the industry. The implementation of a mine wide
automation system is complicated by several factors: (1)
transient and unstructured environments; (2) close interaction
of diverse equipment; (3) operational variability; and (4)
diversity in involved parties.
1) Transient and unstructured environments: Mines con­
stantly change as the mine grows and advances and this
places special demands on the supporting infrastructure. In
contrast to automation applied in manufacturing and process­
ing, there is limited opportunity to establish permanent com­
munication networks and apply control strategies that rely on
high repeatability of the process. This places requirements on
adaptability and flexibility in the organisational and structural
arrangement of the system.
2) Close interaction of diverse equipment: The mining
process may employ diverse equipment fleets that are highly
distributed and mobile. Such equipment must at times inter­
act closely to achieve a common task. Future mines are likely
to employ mixed fleets with both manually operated and
automated equipment working together. The close interaction
between such equipment presents a unique risk that must be LAYER 4 - Operation Management
I time scale: hr - d I
mitigated.
3) Operational variability: The mining process may vary
extensively from operation to operation. This variation influ­
ences the type of equipment involved and the functionality
required to execute the process. Such variability suggests the Production Statistics Logistics Mine Planning

need for guidance that is easily adapted to specific context.

4) Diversity in involved parties: The integration of fleets LAYER 3 - Task Execution
I time scale: m - hr I
that may represent a broad spectrum of manufacturers,
legacy systems and owners into a comprehensive mine-wide
automation solution represents a particular challenge. The
mining industry is unique in the equity in size and influence
of the parties involved. In contrast to other industries where
peak bodies and legislative groups have taken proactive
LAYER 2 -Interoperability
I time scale: ms - s I
and prescriptive approaches to new technology integration,
the mining industry is, to date, characterised by largely
internalised efforts at a company level. There is no dominant � ��

IFi��ne����OII Ir�:�nef���OII
body capable of enforcing an industry-wide approach. With
subtly differing needs and perspectives from organisation-to­
organisation, the task for any individual body of defining and
obtaining buy-in on an industry accepted reference architec­ LAYER 1 - Equipment Control
I time scale: ms
ture for mining automation is particularly challenging.

I V. PRO POSED COM PONEN T S OF A MARA

In this section, a selection of the architectural constructs
reviewed in Section II are presented as a trial application in
the context of mining automation. The intent is to illustrate
the potential dimensions of defining a reference architecture, LAYER 0 - The Mining Process

recognising the unique challenges discussed in Section III.

A. System boundaries and separation

One conceptual tool employed in ISA-95 that provides

significant clarity to the process of thinking about and
integrating complex manufacturing systems is the hierar­
chical breakdown. The hierarchy presented for manufac­
turing control systems in ISA-95 is itself developed with
strong influences from the Purdue Reference Model [9].
The hierarchical breakdown provides a logical separation of
system components and helps to delineate system boundaries
and responsibilities. This separation of the complex system
allows for a similar separation of the problem of defining re­
quired functions and structures. The hierarchical breakdown
provides defined boundaries that aid in limiting discussion to
a level-of-detail appropriate to the hierarchical layer under
consideration.
A hierarchical breakdown of the mining automation sys­
tem, adapted from that presented for manufacturing control
systems in ISA-95, is presented in Fig. 1. Each layer is
described in detail below:
• Layer 0 - The Mining Process: defines the physical
mining process. The activities of the mining process
dictate the functionality that the autonomous equipment
must provide. The mining process is predetermined
and unalterable; autonomous equipment are simply the
agents which execute the process.
• Layer 1 - Equipment Control: defines the activities
performed to provide equipment level autonomy, i.e. the
Fig. 1. Mining automation system hierarchy.
capability to actuate motions. This level of autonomy
makes use of sensors, actuators and logic processing
hardware that is typically located within the equipment's
system boundary.
• Layer 2 - Interoperability: defines the activities that
are performed to enable equipment interaction. Interac­
tion may require communication of information across
equipment system boundaries and/or execution of more
advanced logic.
• Layer 3 - Task Execution: defines the activities that
are performed to execute an autonomous workflow.
The functionality and interoperability of equipment,
established in Layers 1 and 2, is leveraged to execute
an actual task in support of the mining process, e.g.
integrating trucks and shovels and orchestrating the
load-haul-dump cycle.
• Layer 4 - Operation Management: defines the business
activities that are automated or informed by autonomous
equipment and systems. These activities are not directly

1795

Authorized licensed use limited to: University of Queensland. Downloaded on May 01,2023 at 22:47:40 UTC from IEEE Xplore. Restrictions apply.
 involved in the physical execution of the mining process
but exploit the information that is present within the
mine-wide automation system to derive ancillary bene­
fits.
The different layers in the hierarchy represent different
types of activities with different functions. Separating the
complete system in this way provides the opportunity to
approach the task of describing requirements differently for
each layer. For example, the activities in Layer 1 may be
associated with low level exchange of data and actuation
commands which may be well suited to standardisation
efforts. Activities in Layer 3, however, relate to organisation
and use structures which may vary according to context and
application. Such requirements may be better examined from
a conceptual architecture perspective such as that represented
by ISA-95's reference models.
B. Generalising functions and structures
Before it is possible to embark on standardisation efforts
it is necessary first to understand in a broad sense what
functions and structures are required of the system and its un­
derlying equipment. The STANAG 4586 approach achieves
clarity by defining different levels of interoperability. The
specification of message formats for interoperability thus
represents the spectrum from low level direct control (i.e.
commanding a speed increase) to high level supervisory
control (i.e. designating a waypoint). This approach may
have value for mining automation but would require a very
extensive message set to cover the many different functions
and types of equipment used in the industry. Such message
sets, however, would be difficult to define and utilise without
a broader understanding of the expected usage and organisa­
tion of equipment in an autonomous arrangement. STANAG
4586 avoids this problem by concentrating on a very defined
system arrangement requiring cross compatibility of ground
stations and DAVs. There is arguably a conceptual layer that
needs to be in place before similar standardisation efforts are
applied to mining automation.
One method explored for generalising function and struc­
tures at the conceptual level is the specification of design
patterns. A pattern is a model solution to an observed
problem. The solutions provided by these patterns imply
certain core functionality or capability exists in the broader
system architecture. The patterns are given distinct names
that are meant to allow them to be used in discussions to
convey a deeper concept. Multiple patterns may aim to solve
the same underlying problem but according to distinctly
different strategies.
Fig. 2 presents a collection of patterns described to repre­
sent alternative strategies to the high level organisation of a
mine-wide automation system. Each pattern inevitably places
certain requirements on the capability and interoperability of
equipment executing the mining process.
The spectrum of patterns is set by two extremes, cen­
tralised organisation and decentralised organisation. A cen­
tralised organisation is characterised by highly dependent
and tightly coupled elements, which rely on commands and
1796
Authorized licensed use limited to: University of Queensland. Downloaded on May 01,2023 at 22:47:40 UTC from IEEE Xplore. Restrictions apply.
Fig. 2. Patterns describing organisational c oncepts.
information from a central source. Centralised organisations
simplify the task of coordinating component systems at the
cost of creating a single critical point of failure. This places
high demands on both the central system and the communi­
cation links. In Fig. 2, the 'Conductor' pattern describes an
approach involving a centralised controller that orchestrates
the activities undertaken by autonomous equipment when
such activities are too complex to be handled independently.
The 'Conductor' gathers information, determines actions for
equipment and issues instructions. Autonomous equipment
provide the basic functionality necessary to move and actuate
but defer responsibility to this centralised intelligence in
circumstances that do not represent the predictable workflow.
By contrast, a decentralised organisation is characterised
by highly independent and decoupled elements, which rely
on their individual abilities to gather information and formu­
late plans. Decentralised organisation can improve robustness
but may complicate the orchestration of the system as a
whole. The empowerment of the fringes places high demands
on a system's ability to perceive and plan. The "Solo"
pattern in Fig. 2 describes an organisational structure in
which autonomous equipment are given scope to indepen­
dently make decisions. The approach requires that entities
be equipped with additional intelligence and be authorised
to act independently.
The organisational patterns summarised in Fig. 2 illustrate
some differing alternatives for both planning-control and
perception systems for mining automation. The interoper­
ability grouping of patterns in Fig. 2 represents a melding
of the planning-control and perception patterns, specifically
for handling activities involving two or more participants
interacting. A distinction is drawn between temporarily
deferring control of equipment involved in an interaction
to a higher level supervisory system (i.e. 'Puppeter') and
the alternative of equipment controlling their own activity
to achieve the interaction (i.e. 'Team'). A third alternative
CHandover') is the context based transition to a master­
slave type relationship to achieve an interaction, e.g. a loader
assuming control of a truck during the loading cycle.
The proposed value of the patterns approach to gener­
alisation of structure and functionality is in the conceptual
guidance it can provide. Each pattern captures an approach
to solving an architectural problem, that can be applied
irrespective of equipment type and operation. For example,

the 'Team' pattern can be applied to achieve a concep­
tual appreciation of truck/shovel interactions as well as to
continuous miner/shuttle car interactions. Patterns may also
be merged or switched according to context in order to
achieve a satisfactory balance of performance and robustness.
The implications on the functional requirements of equip­
ment, data exchange and communication infrastructure can
subsequently be extracted within some context. Low level
standardisation efforts may then be undertaken if a particular
pattern is deemed to have value. By contrast, performing an
assessment of required function by starting with a notional
solution, for example, of how and what information might be
exchanged between a shovel and a truck in order to achieve
a loading cycle, is inevitably biased by the solution chosen
and the equipment considered.
C. Mitigating risk
A mine-wide automation system introduces certain risks
that should be considered at integration. The two dominant
foreseeable safety risks with potentially fatal consequences
are collision and unplanned movement. Unplanned move­
ment is a significant risk when autonomous equipment must
be accessed or approached. Collisions may occur between
autonomous equipment and: other autonomous equipment;
infrastructure; manually operated equipment; and personnel.
The collision risk is given focus in this section.
Fig. 3 presents a superficial fault tree analysis of a collision
event between a haul truck and a manually operated light
vehicle. Some hypothesised causes of the collision event are
presented. Consider the possibility that a communications
failure between equipment and support systems may be the
cause of the collision. This implies that the risk mitigation
process may need to not only target equipment performance
requirements but also that of supporting systems and infras­
tructure. This is difficult to achieve without an established
understanding of how the complete mine-wide automation
system is expected to be assembled.
As discussed in Section II, there is a parallel between
the mining automation collision risk and the risk of mid-air
collisions in civilian airspace involving UAVs. An approach
similar to the isolation of the 'Sense and Avoid' risk mitiga­
tion functionality for UAVs may be useful for addressing
the collision risk for autonomous mining equipment in a
holistic and consistent fashion. Arguably, the same principle
of 'equivalent level of safety' should apply to autonomous
mining vehicles when the operator is removed. If the risk in
an autonomous and potentially manual-autonomous environ­
ment is deemed intolerable, then a 'collision avoidance' type
risk mitigation functionality may be necessary.
While the example of Fig. 3 is specifically framed around
a collision between a haul truck and light vehicle, the causal
faults are noticeably generic. Separating and generalising
'collision avoidance' functionality provides the basis for
achieving a robust and consistent means to addressing the
risk of collisions of all types.
1797
Authorized licensed use limited to: University of Queensland. Downloaded on May 01,2023 at 22:47:40 UTC from IEEE Xplore. Restrictions apply.
View publication stats
Commuincations Failure
Hardware Failure
Administrative Control Breach
Planning Error
Safety System Failure
Fig. 3. Fault tree analysis of collision event.
V. ADDRESSING KEY CHALLENGES
This paper aims to reveal the various dimensions involved
in creating a comprehensive Mining Automation Reference
Architecture (MARA). The principle challenge is handling
the uncertainty of form and complexity of the mine-wide
automation system. To some, explicit standards are viewed as
an attractive means of guiding integration efforts. However,
premature and poorly contextualised standardisation efforts
are more likely to hinder than aid automation initiatives.
While best practice and proven-in-use implementations are
yet to emerge, the MARA should focus at the conceptual
level. In particular, the MARA should provide aids that help
users to handle complexity and uncertainty.
The following recommendations are made:
• Define a common language and terminology to enable
rich discussion
• Form an advisory group of key parties empowered to
promote automation strategy definition and adoption
• Define a conceptual architecture with generalised struc­
tures and functions
• Isolate distinct functions necessary for risk mitigation
• Once best practice begins to emerge, determine where
standardisation efforts should be focused
To ensure that the benefits of automation are not stifled
by significant barriers encountered upon integration, the
mining industry must view the consolidation of disparate
technologies into a mine-wide solution as a distinct problem
in its own right.
REFERENCES
[I] International Telecommunications Union: Radiocommunication Sector.
Technical characteristics for an automatic identification system us­
ing time-division multiple access in the VHF maritime mobile band.
M. 137 1-4.201O.
[2] Standard interfaces of UAV Control System (UCS) for NATO UAV
Interoperability. STANAG 4586, 2007.
[3] C. Mueller. "Iredes: Standardized integration of mining equipment
into corporate it infrastructure," proceedings of the 32nd International
Symposium on the Application of Computers and Operations Research
in the Mineral Industry. pp. 489-494. 2005.
[4] International Rock Excavation Data Exchange Standard ( IREDES),
"Purpose." http://www. iredes. org / index. php/purpose.
Accessed: 5/212013.
[5] Enterprise-control system integration. ISA-95.00.0 1, 2000.
[6] Functional safety of electrical/electronic/programmable electronic
safety-related systems. TEC 6 1508, 2010.
[7] NSW Department of Primary Industries, Explanatory notes to assist in
interpreting Coal Mine Health and Safety Regulation 2006. LU07-05.
2007.
[8] Standard Specification for Design and Performance of an Airborne
Sense-and-Avoid System. ASTM F24 1 1-07.2007.
[9] T. J. Williams, A Reference Model for Computer Integrated Mamifac­
turing. North Carolina: Instrument Society of America. 1989.