Commercial blasting systems and methods

Abstract

A commercial blasting system includes a central controller configured to send blasting command instructions for two or more electronic blasting devices. The electronic blasting devices include a Wireless Electronic Blasting device and a wired Electronic Blasting System device. The system includes: a remote blaster configured to receive the blasting command instructions for the EBS device, and configured to send a corresponding blasting command to the EBS device via wires / cables; and an antenna system configured to receive the blasting command instructions for the WEB device, and to send a corresponding blasting command to the WEB device via magnetic induction signals. The remote blaster is configured to send handshake messages to the controller indicating that the EBS device is programmed to synchronize sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

Description

COMMERCIAL BLASTING SYSTEMS AND METHODSRELATED APPLICATIONS

[0001] The present patent application is related to Australian Patent Application No. 2023901892, entitled "Commercial blasting systems and methods" and filed on 15 June 2023 in the name of Orica International Pte Ltd, the as-filed specification of which is hereby incorporated herein by reference in its entirety. The present patent application is also related to Singaporean Patent Application No. 10202301672W, entitled "Access control for electronic blasting machines" and filed on 13 June 2023 in the name of Orica International Pte Ltd, the as-filed specification of which is hereby incorporated herein by reference in its entirety.TECHNICAL FIELD

[0002] Aspects of the present disclosure relate to systems and methods that provide commercial blasting with remotely controlled detonators / initiators, including wireless electronic blasting (WEB) devices and electronic blasting system (EBS) devices in blast holes (which may extend in any direction, including down / up / across) of one or more blasts. Such commercial blasting may be used in surface mining operations, underground mining operations, quarrying operations, demolition operations, and / or seismic surveying.

[0003] Aspects of the present disclosure also relate to systems and methods that provide safety and access control in commercial blasting operations having remotely controlled electronic blasting systems with detonators / initiators, including by preventing unauthorized operation of the blasting systems. Such electronic blasting systems may include wireless electronic blasting (WEB) systems with the WEB devices, and wired electronic blasting systems (EBS) with the EBS devices.BACKGROUND

[0004] Commercial blasting systems and methods may be used in surface mining operations, underground mining operations, quarrying operations, demolition operations, and / or seismic surveying.

[0005] Some commercial blasting systems and methods use at least one electronic blasting system (EBS), e.g., the i-kon (TM) system from ORICA LTD, that includes many EBS down-hole devices (e.g., i-kon detonators) in the blast holes and connected by wires to a remote blaster (also known as a “remote blasting machine”), e.g., ORICA’s BLASTER 3000 (TM), which is in turn controlled by a controller (also known as the “blast controller”, “control station” or “central command station”) that registers and controls the remote blaster (or perhaps many remote blasters) to initiate a blast according to a predefined blasting plan.

[0006] Other commercial blasting systems and methods use wireless electronic blasting (WEB) systems, e.g., the WebGen (TM) system from ORICA LTD, that includes many WEB down-hole devices (e.g., WebGen primers) in the blast holes and configured to receive magnetic induction (MI) communication signals through the earth (TTE) — where “earth” means rock / ore / stemming / etc. — from a MI transmit antenna (e.g., one of ORICA’s WebGen antennae). Such TTE communication is often practically only in one direction, thus providing only one-way or “downlink” communication from out-of-hole equipment, including out-of-hole transmit antennae. Tn this context “TTE” communication refers to wireless communication signals carrying information through substantially non-conductive geological materials without using wires, and thus the term “earth” in this context can include material in which the devices arc buried, including earth, rock, ground, soil, stemming material, bulk explosive material, concrete and / or brick, depending on the type of operation.

[0007] Preciously, EBSs or WEB systems were selected based on the types of blasts being used (e.g., stoping), the material being blasted, and / or the type of the blasting operation (including, e g., the safe accessibility of the blast area prior to blasting); however, some types of operations wrere limited by having to use just one or just the other system / method.

[0008] Furthermore, in order to achieve security in some exemplary^ prior remote blasting systems, including EBSs, two physical dongles have been required to initiate a blast successfully, including a remote dongle and a firing dongle. At startup of a remote blaster(also known as a “remote electronic blasting machine”), an individual physical remote dongle was written by the remote blaster with details of the remote blaster, such as attached loggers, number of detonators, serial numbers of the devices attached to the remote blaster, its ID number, and a random digital key generated by the remote blaster. A human operator took the physical remote dongle back to a blasting system controller (also known as the “controller blaster”, “control station”, “control blaster”, or “central command station”) to register the remote blaster, e.g., see US Patent Ser. No. 6851369 (“Access control for electronic blasting machines”, Feb. 08, 2005, to Orica Explosives Technology Pty’ Ltd, with inventors Dirk Hummel and Olaf Cramer). Only a registered remote blaster was taken into consideration for the next blasting sequence. The random digital key on the remote dongle was used to encrypt information transmitted betw een the blasting system controller and the remote blaster. After initialization of the remote blaster via the blasting system controller, the firing dongle was required at the blasting system controller to enable activation of firing voltage on the remote blasters. The firing dongle enabled activation of the firing voltage and stored the final FIRE commands, thus only if the firing dongle was inserted into a communication port of the controller (e.g., its 7-pin port, or a USB port) was the operator able to progress the blasting sequence. After pressing the fire keys on the blasting system controller, the blasting system controller read out the FIRE commands from the firing dongle. Those commands were required to initiate the detonators attached to the remote blaster.

[0009] However, in applications w here a large number of remote blasting machines or remote blasters is required, e.g., over 100 remote blasting machines, carrying physical dongles or authorization keys from each remote blasting machine back to the controller may be too slow / difficult within relevant time limits, particularly when there is a change in the blasting plans, e.g., when the remote blasting machines arc underground, and the blasting system controller is on the surface (thus not underground) and some distance away, e.g., accessed by a slow elevator, while still ensuring the remote blasters are safely and reliably registered at the blasting system controller. For example, in underground mining, more detonators may be connected ready for blasting than are eventually required (depending on effects of earlier blasts), and it may be undesirable / dangerous to take physical dongles or authorization keys from each remote blaster back to the blasting system controller when there is a change in the blasting plan.

[0010] It is desired to address or ameliorate one or more disadvantages or limitations associated with the prior art, or to at least provide a useful alternative.

[0011] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.SUMMARY

[0012] In accordance with the present invention, there is provided a commercial blasting system including: a central controller configured to send blasting command instructions for two or more electronic blasting devices, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; at least one remote blaster connectable to the central controller and configured to receive the blasting command instructions for the EBS device, and configured to send at least one corresponding blasting command to the EBS device via wires / cables; and at least one antenna system connectable to the central controller and configured to receive the blasting command instructions for the WEB device, and configured to send at least one corresponding blasting command to the WEB device via magnetic induction (MI) signals, wherein the remote blaster is configured to send one or more handshake messages to the controller indicating that the EBS device is programmed for the blast for the controller to synchronize sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

[0013] In one or more embodiments, the central controller is configured to provide a WEB state machine and an EBS state machine, and to synchronize the WEB state machine with the EBS state machine based on the handshake messages.

[0014] Tn one or more embodiments, the central controller is configured to send a MT FIRE command instruction and an EBS FIRE command instruction separated by a predetermined interval.

[0015] In one or more embodiments, at least one of tire remote blasters and the antenna system arc phy sically one combined device and the predetermined interval is used by the combined device to send tire MI FIRE command instruction and the EBS FIRE command instruction.

[0016] In one or more embodiments, the central controller is configured to receive any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send the blasting command instructions.

[0017] In one or more embodiments, the central controller and tire antenna system are connected by a two-way data interface to provide handshake messages to the controller from the antenna system.

[0018] Tn accordance with the present invention, there is provided a commercial blasting system including: a central controller configured to send blasting command instructions to two or more electronic blasting devices in a blast according to a blasting plan, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; at least one remote blaster connectable to the central controller and configured to receive the blasting command instructions for the EBS device, and configured to send at least one blasting command to the EBS device via wires / cables based on the blasting command instructions;at least one antenna system connectable to the central controller and configured to receive the blasting command instructions for the WEB device, and configured to send at least one blasting command to the WEB device via magnetic induction (MI) signals based on the blasting command instructions; and at least one MI synchronization device configured to receive the blasting command via the MT signals, and connectable to the or each remote blaster to send sync signals representing the blasting command for the WEB device to synchronize firing of the EBS device and the WEB device.

[0019] In one or more embodiments, the MI synchronization device is configured to perform any one or more of the following: on receipt of an Ml sequence, responsively7send an Ml signal-to-noise (SNR) signal for the remote blaster and / or central controller; on receipt of an MI SYNC command, responsively send a prepare-to-fire command instruction for the remote blaster, wherein the prepare-to-fire command is sent to the remote blaster at a predetermined time after receipt of the MI SYNC command; and on receipt of an MI FIRE command, responsively7send a FIRE command instruction for the remote blaster to fire the EBS device.

[0020] In one or more embodiments, the remote blaster is configured to send handshake messages to the controller indicating that the EBS device is programmed for the blast for the controller to synchronize sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

[0021] In one or more embodiments, the central controller is configured to provide a WEB state machine and an EBS state machine, and to synchronize the WEB state machine with the EBS state machine based on the handshake messages.

[0022] In one or more embodiments, the central controller is configured to receive any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send the blasting command instructions.

[0023] In one or more embodiments, the MI synchronization device includes a magnetometer configured to generate an electronic / electrical output representing the received blasting command.

[0024] Tn one or more embodiments, the magnetometer includes at least one MT antenna and corresponding receiver.

[0025] In one or more embodiments, the MI synchronization device includes a communication interface for connection to the remote blaster.

[0026] In one or more embodiments, the system further includes: a physical remote registration device configured to communicative ly connect to the central controller and to the at least one remote blaster and / or the at least one antenna system (each referred to hereinafter as a "remote unit"), wherein the central controller is configured to provide a public-private asymmetric encryption key pair with a public key and a private key, and to write the public key to the remote registration device when the remote registration device is communicatively connected to the controller, wherein each of the at least one remote blaster and / or the at least one antenna system is configured to read the public key from the remote registration device when the remote registration device is communicatively connected to the corresponding remote blaster or antenna system, wherein the central controller and each of the at least one remote blaster and / or the at least one antenna system are configured to communicate with each other via a data network using the key7pair.

[0027] In one or more embodiments, each remote blaster and / or each antenna system is configured to provide a handshake encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the handshake encryption key to the central controller using the public key and the data network.

[0028] In one or more embodiments, the central controller is configured to provide a communications encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the communications encryption key in a second handshake message to each remote blaster and / or each antenna system using the handshake key and the data network.

[0029] Tn one or more embodiments, the central controller and each of the at least one remote blaster and / or the at least one antenna system arc configured to communicate with each other using the communications encryption key and tire data network.

[0030] In one or more embodiments, the central controller is configured to provide a broadcast encryption key7that is not unique / quasi-unique to each remote blaster or antenna system, and to send the broadcast encrypt ion key to each remote blaster and / or each antenna system using the data network.

[0031] In one or more embodiments, the central controller is configured to encrypt and send blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption key7and the data network.

[0032] In one or more embodiments: the central controller has a secure communications interface, each remote blaster and / or each antenna system has a secure communications interface corresponding to the secure communications interface of the central controller, the central controller is configured to provide a public-private asymmetric encryption key7pair with a public key and a private key, and to wnte the public key individually to each remote blaster and / or each antenna sy stem when each remote blaster and / or each antenna system is respectively connected via the secure communications interfaces,each remote blaster and / or each antenna system configured to read the public key from the central controller when connected via the secure communications interfaces, and the central controller and each of the at least one remote blaster and / or the at least one antenna system are configured to communicate with each other via a data network using the key pair.

[0033] In one or more embodiments, each remote blaster and / or each antenna system is configured to provide a handshake encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the handshake encryption key to the central controller using the public key and the data network.

[0034] In one or more embodiments, the central controller is configured to provide a communications encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the communications enciyption key in a second handshake message to each remote blaster and / or each antenna system using the handshake key and the data network.

[0035] In one or more embodiments, the central controller and each remote blaster and / or each antenna system are configured communicate with each other using the communications encryption key and the data network.

[0036] Tn one or more embodiments, the central controller is configured to provide a broadcast encryption key that is not unique / quasi-unique to each remote blaster and / or each antenna system, and to send the broadcast encryption key to each remote blaster and / or each antenna system using the data network.

[0037] In one or more embodiments, the central controller is configured to encrypt and send blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption key and the data network.

[0038] In accordance with the present invention, there is provided a commercial blasting method including:sending blasting command instructions for two or more electronic blasting devices, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; receiving the blasting command instructions for the EBS device, and sending at least one corresponding blasting command to the EBS device via wires / cables: receiving the blasting command instructions for tire WEB device, and configured to send at least one corresponding blasting command to the WEB device via magnetic induction (MI) signals; sending one or more handshake messages indicating that the EBS device is programmed; and synchronizing sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

[0039] In one or more embodiments, method includes synchronizing a WEB state machine with an EBS state machine based on the handshake messages.

[0040] Tn one or more embodiments, method includes sending a MT FIRE command instruction and an EBS FIRE command instruction separated by a predetermined interval (or the "predetermined MI fire delay").

[0041] In one or more embodiments, method includes sending the MI FIRE command instruction and the EBS FIRE command instruction from a unitary device.

[0042] In one or more embodiments, method includes receiving any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send the blasting command instructions.

[0043] In one or more embodiments, method includes sending handshake messages in response to the blasting command instructions for the WEB device.

[0044] In accordance with the present invention, there is provided a commercial blasting method including: sending blasting command instructions to two or more electronic blasting devices in a blast according to a blasting plan, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; receiving the blasting command instructions for the EBS device; sending at least one blasting command to the EBS device via wires / cables based on the blasting command instructions; receiving the blasting command instructions for the WEB device; sending at least one blasting command to the WEB device via magnetic induction (MI) signals based on the blasting command instructions; receiving the blasting command via the MI signals; and sending sync signals based on the blasting command received via the MI signals in order to synchronize firing of the EBS device and the WEB device.

[0045] Tn one or more embodiments, method includes any one or more of the following: sending an MT signal-to-noise (SNR) signal after receipt of an MT sequence; sending a prepare-to-fire command at a predetermined time after receipt of an MI SYNC command; and sending a FIRE command fire to the EBS device after receipt of an MI FIRE command.

[0046] In one or more embodiments, method includes sending handshake messages indicating that the EBS device is programmed for the blast in order to synchronize sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

[0047] In one or more embodiments, method includes synchronizing a WEB state machine with an EBS state machine based on the handshake messages.

[0048] In one or more embodiments, method includes receiving any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send the blasting command instructions.

[0049] In one or more embodiments, method includes generating an clcctronic / clcctncal output representing the blasting command received via tire MI signals.

[0050] In one or more embodiments, method includes generating tire electronic / electrical output using at least one Ml antenna and corresponding receiver.

[0051] In one or more embodiments, method includes sending the sync signals via a communication interface to a remote blaster.

[0052] In one or more embodiments, method includes: the central controller of the electronic blasting system providing a public-private asymmetric encryption key pair with a public key and a private key: the central controller communicatively connecting to a physical remote registration device to write the public key to the remote registration device; each remote blaster and / or each antenna system separately communicatively connecting to the remote registration device to each separately read the public key; and each remote blaster and / or each antenna system communicating with the central controller via a data network using the public key.

[0053] In one or more embodiments, method includes each remote blaster and / or each antenna system providing a handshake encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the handshake encryption key to the central controller using the public key and the data network.

[0054] In one or more embodiments, method includes the central controller providing a communications encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the communications encryption key in a second handshake message to each remote blaster and / or each antenna system using the handshake key and the data network.

[0055] Tn one or more embodiments, method includes the central controller and each remote blaster and / or each antenna system communicating with each other using the communications encryption key and the data network.

[0056] In one or more embodiments, method includes the central controller providing a broadcast encryption key7that is not unique / quasi-unique to each remote blaster and / or each antenna system, and sending the broadcast encryption key to each remote blaster and / or each antenna system using the data network.

[0057] In one or more embodiments, method includes the central controller encrypting and sending blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption key and the data network.

[0058] In one or more embodiments, method includes: the central controller providing a public-private asymmetric encryption key pair with a public key7and a private key; the central controller communicatively connecting to each remote blaster and / or each antenna sy stem via respective secure communications interfaces to separately provide the public key to each remote blaster and / or each antenna system; and each remote blaster and / or each antenna system respectively communicating with the central controller via a data network using the public key.

[0059] In one or more embodiments, method includes each remote blaster and / or each antenna system providing a handshake encryption key7that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the handshake encryption key to the central controller using the public key and the data network.

[0060] In one or more embodiments, method includes the central controller providing a communications encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the communications encryption key in a second handshake message to each remote blaster and / or each antenna system using the handshake key and the data network.

[0061] Tn one or more embodiments, method includes the central controller and each remote blaster and / or each antenna system communicating with each other using the communications encryption key and the data network.

[0062] In one or more embodiments, method includes the central controller providing a broadcast encryption key7that is not unique / quasi-unique to each remote blaster and / or each antenna system, and sending the broadcast encryption key to each remote blaster and / or each antenna system using the data network.

[0063] In one or more embodiments, method includes the central controller encrypting and sending blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption key and the data network.BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Some embodiments of the present invention are hereinafter described, by way of nonlimiting example only, with reference to the accompanying drawings, in which: a. FIG. 1 is a schematic diagram of a dual blasting system (also referred to as a “concurrent blasting system") disclosed herein; b. FIG. 2 is a schematic diagram of a synchronized blasting system disclosed herein; c. FIG. 3 is a schematic diagram of a first arrangement of electronic blasting devices of the dual blasting system or the synchronized blasting system, wherein the electronic blasting devices include one or more wireless electronic blasting (WEB) devices and one or more electronic blasting system (EBS) devices in separate holes;d. FIG. 4 is a schematic diagram of a second arrangement of electronic blasting devices of the dual blasting system or the synchronized blasting system, wherein the electronic blasting devices include one or more WEB devices and one or more EBS devices in each hole; e. FIG. 5 is a schematic diagram of a loop antenna system of the dual blasting system or the synchronized blasting system, wherein the antenna system includes a loop antenna; f. FIG. 6 is a flow chart of a dual blasting method performed by the dual blasting system; g. FIG. 7 is a flow chart of a synchronized blasting method performed by the synchronized blasting system; h. FIG. 8 is a schematic diagram of an access control system for a plurality’ of electronic blasting machines (“remote blasters”) of the dual blasting system or the synchronized blasting system; and i. FIG. 9 is a flow chart of an access control method performed by the access control system of FIG. 8.DETAILED DESCRIPTIONOverview

[0065] As shown in FIGs. 1 and 2, disclosed herein are combinable or combined blasting systems, each including: a. a wireless electronic blasting (WEB) sy stem, including at least one antenna system 102 configured to send magnetic induction (MI) signals 104 through the earth / ground / etc. (TTE) to WEB devices 302 of two or more electronic blasting devices 110 in two or more holes 306 in the earth / ground / etc.; and b. a wired electronic blasting system (EBS) coupled to the WEB system, wherein the EBS includes at least one remote blaster 106 configured to send non-wireless signals though wires / cables 108 to EBS deGees 304 of the electronic blasting devices 110 in the holes 306.

[0066] The combined blasting systems (which may be referred to as "centralized firing systems) can control one blast or multiple blasts using the combination of the WEB system and the EBS. Each blast typically has one or more (up to 10) blast identifiers (or group identifiers) that identify which of the WEB devices 302 have been selected for that blast: the identifier may be referred to as a “group ID” (GID) that defines the group of selected WEB devices 302, or a “blast ID” (BID) that defines the group of selected WEB deGees 302 within the blast. The GID or BID is thus shared by a group of plural WEB devices 302. For example, the term “Group ID” may be used for WcbGcn 100-typc devices whilst the term “Blast ID” may be used for WebGen 200-type devices, both terms referring to the same type of identifier, typically a code or encryption code, that allows selected ones of the WEB devices 302 in a blasting site to be addressed as a group, e.g., for transmitting and verifying the blasting commands. In examples, from 1 to 10 mutually different GIDs or BlDs can be selected / assigned to respective 1 to 10 groups of the WEB devices 302 in one blasting site. The BID or GID is different from an individual identifier of each WEB device: each WEB device can have an individual identifier that may be referred to as a device ID or unit ID (UID) and each individual identifier differs from all other individual identifiers of the WEB device (at least the WEB devices in each blast or site).

[0067] The WEB system has different ty pes of communication delays (also referred to as “latencies”) from the wired EBS. Accordingly, the combinable or combined blasting systems arc configured to operate according to combined blasting methods, described hereinafter, in which commands for the EBS devices are combined (in the dual blasting system 100) or synchronized (in the synchronized blasting sy stem 200) with MI signals 104 for the WEB system in such a way as to manage / account for such delays in a safe / useful manner.

[0068] The combinable or combined blasting systems include a dual blasting system 100 (also referred to as a “concurrent blasting system") or a synchronized blasting system 200, described hereinafter. The / each antenna system 102 includes at least one current generator (“CG”) for driving electrical current through at least one MI antenna to control, generate and modulate the MI signals 104. Although only one antenna system 102 and corresponding WEB system is shown in FIG. 1 and FIG. 2, the systems 100,200 may each include two or more of the antenna system 102, all controlled and synchronized by the central controller 112. In one or more implementations, one of the remote blasters 106 and at least one of theantenna systems 102 may be physically one combined device or a unitary device (in other words, one device / unit with both one of the remote blasters 106 and one of the antenna systems 102), e.g., for improved synchronization and / or use of a "predetermined MI fire delay" described hereinafter.

[0069] As described hereinafter, the combinable or combined blasting systems are configured to control EBS messages 1 14 to the at least one remote blaster 106 of the EBS such that the EBS devices 304 and the WEB devices 302 dctonatc / initiatc with selected timing or approximately selected timing, including timings from the blast plan. This control of the timing (in the dual blasting system 100) or synchronization (in the synchronized blasting system 200) is not available or is insufficient in prior art systems, in part because the signaling protocols for pnor art EBS and WEB systems are substantially different, and in part because prior art WEB devices often can only receive one-way wireless blasting commands (e.g., ARM / F1RE commands) and need to conserve power (so they have a sleep mode), whereas the EBS devices can be in constant electrical contact by way of the in-hole wires / cable 108, thus allowing continuous charging and 2-way communication with the EBS devices.Electronic Blasting Devices

[0070] As shown in FIGs. 3 and 4, the dual blasting system 100 or the synchronized blasting system 200 includes one or more WEB devices 302 (e.g., including WebGen devices) and one or more EBS devices 304 (e.g., including i-kon or ORICA's eDev (TM) devices) — e.g., from one of each to dozens or hundreds of each — that are deployed in the holes 306 in-field (e.g., in an open cut / surface mining / quarrying site, or a geophysical / seismic exploration site, or an underground mining site). Tire holes 306 may be referred to as “blast holes”. Prior to their deployment, the WEB devices 302 and the EBS devices 304 can be stored in one or more device magazines, e.g., transported to a particular in-field zone or location at the site by way of a vehicle.

[0071] The holes 306 may be prepared for blasting to include, as shown in FIGs. 3 and 4:a. at least one inner deck (also referred to as a “lower deck7’ for down holes), which can include a first inner deck 308,408 and a second inner deck 310,410, one deeper than the other; and b. at least one outer deck 312,412 (also referred to as an “upper deck” for down holes).

[0072] Each inner deck includes a deeper portion of each blast hole with one of the blasting devices, a bulk explosive composition 314 (e.g., an ammonium nitrate (AN) based explosive, such as an AN-based emulsion explosive) around the blasting device in the hole, and stemming materials 316 capping / sealing off the top / shallow end of the bulk explosive composition 314. The outer deck 312,412 includes a shallower portion of each blast hole with one of the blasting devices, the bulk explosive composition 314 around the blasting device in the hole and extending toward a collar of the hole, and the stemming materials 316 capping / sealing off a top / shallow end of the bulk explosive composition 314 at or towards the collar. The blasting devices within and across a current exposed, outermost, or upper blasting deck can be configured for initiation, or can be initiated, to blast the current exposed, outermost, or upper blasting deck, and the blasting devices within and across one or more unexposed, inner, deeper, or lower blasting decks can initiated at the one or more selected durations after initiation of the outer blasting devices to blast the subsequent exposed, outermost, or upper blasting deck, and so on for further deeper decks with the WEB devices. As shown in FIGs. 3 and 4, a blast hole array can contain more than two blasting decks, with the inner decks including two or more layers of the blasting devices, thus three or more blasting devices can be positioned in one or each blast hole.

[0073] As shown in FIGs. 1 to 4, the EBS devices 304 are connected to the remote blaster 106 via respective ones of the wires / cables 108 extending from the EBS devices 304 toward the collar of their hole. The wires / cables 108 connect the EBS devices 304 to the remote blaster 106 directly (e.g., for ORICA’s e-Dev (TM) devices) or via a logger (not showm) (e.g., for i-kon devices). The EBS devices 304 are controlled by blasting commands (e g., ARM / FIRE / ABORT commands) from the remote blaster 106 via the wires / cables 108 and via the logger if present. As shown in FIGs. 3 and 4, each WEB device 302 can be configured for deployment within the blast holes such that a lengthwise, longitudinal, or central axis of the WEB device 302 is intended to be naturally aligned at least nearlycoincident or parallel to a lengthwise, longitudinal, or central axis of the blast hole in which it is deployed.

[0074] As described hereinbefore, each WEB device 302 can have, be assigned, or be programmed with its unique unit identifier (UTD) stored in memory in the initiation device, e.g., in association with its manufacture, or after manufacture. As described hereinbefore, additionally, or alternatively, selected groups of the WEB devices 302 can have, be assigned, or be programmed with the GID / BID stored in memory of the WEB devices 302, c.g., prior to, in association with, or following deployment in a set of blast holes. Tire GID or BID refers to an entire blast or section of a blast, c.g., if each ring in a blast has been assigned a different BID, multiple rings can be fired together, by selecting those BIDs in a single blast or they can be fired ring by ring with only one BID per blast.Dual Blasting System (“Concurrent Blasting System”)

[0075] As shown in FIG. 1, the dual blasting system 100 can include a central blasting system controller 112, which may also be known as the “blast controller”, “control station”, “central command station”, “centralized blast controller”, “remote blasting system controller”, or “omni-remote blasting system (ORBS) controller”.

[0076] In the dual blasting system 100, the controller 112 includes at least one microprocessor and associated memory' with instructions read by the microprocessor to provide two state machines, including: a. a WEB state machine that controls states of the WEB system, such states including a SLEEP state, an AWAKE state, an ARM state, a FIRE state, and a DISABLED state; and b. an EBS state machine that controls states of the EBS, such states including a PROGRAMMED state, a CALIBRATED state, a CHECKED state, an ARMED state, a FIRST-LAST DET TESTED state, a FIRED state, and a DISABLED state.

[0077] In some examples, the WEB state machine may include one or more states of the same state machine in ORICA’s BLASTER W product.

[0078] In some examples, the EBS state machine may include one or more states of the same state machine as in ORICA’s B3000 central controller product.

[0079] Tn the dual blasting system 100 (and in the synchronized blasting system 200), the controller 112 is configured to send EBS messages 114 to the remote blaster 106 (or to a plurality of tire remote blasters 106) via a data network communication coupling, pathway, link, or connection referred to herein as the EBS network connection 116. The EBS network connection 116 provides two-way communication, e g., according to existing protocols, e.g., LTE and / or WiFi. The controller 112 is configured to send WEB messages 118 to the antenna system 102 via a data network coupling, pathway, link, or connection referred to as the WEB network connection 120, and the WEB network connection 120 also provides two- way communication, e.g., according to existing protocols, e.g., LTE and / or WIFI. The data network connections (the EBS network connection 116 and the WEB network connection 120) can include portions of a local area network (LAN) or data network in the site that may be referred to as the “mine network”. The controller 112 has data interfaces to the EBS network connection 116 and the WEB network connection 120, and is thus configured to control both the WEB system and the EBS, and to receive messages, including handshake messages 122 from the remote blaster 106. The antenna system 102 (including the CG) has a data interface to the WEB network connection 120, which is a two-way data interface such that the central controller 112 can receive WEB handshake messages 119 from the antenna system 102. The or each remote blaster 106 has a data interface to the EBS network connection 116.

[0080] The controller 112 can communicate with the antenna sy stem 102 when connected via the WEB network connection 120, e.g., which can use a portion of the mine network, as described hereinbefore.

[0081] In the dual blasting system 100 (and in the synchronized blasting system 200), the WEB devices 302 are configured to receive blasting commands in the MI signals 104 from the antenna system 102, and these blasting commands are controlled by respective blastinginstructions from the controller 112 that are sent to the antenna system 102 in the WEB messages 118. The blasting commands include an MI ARM sequence and an MI FIRE sequence. The MI ARM sequence includes a WAKE-UP command, a START command, the BID(s), and an MI ARM command. The MI FIRE sequence includes a MI SYNC command and an MI FIRE command. On receipt of the MI SYNC command, the WEB devices 302 are configured to synchronize their internal clocks and calculate the timing to issue FIRE signals to their respective electronic detonators (e.g., i-kon detonators, or i-kon W detonators that have a connector interface rather than a wire).

[0082] The EBS messages 114 depend on and represent the states of the EBS state machine.

[0083] In the dual blasting system 100 (and in the synchronized blasting system 200), the controller 112 includes a communications port configured to receive a blasting dongle 124 (e.g., including a USB memory stick, or other manually removable machine-readable memory unit that includes a data interface (to communicatively connect to the controller 112, e.g., USB) integrated with the machine -readable memory providing electronic non-volatile computer memory storage, e.g., flash memory), also referred to as the “blasting-dongle” or "firing dongle", that both the WEB state machine and the EBS state machine require in order to enter the ARM / FIRE states and thus send the ARM / FIRE commands for both the WEB devices 302 and the EBS devices 304. The blasting dongle 124 is an authorization key for the shot-firer in charge (who can be the operator) that allows the shot-firer to operate the controller 1 12 through the states of both state machines (EBS and WEB). The EBS requires the blasting dongle 124 for powering up the detonators of the EBS devices 304 to firing voltage, which happens prior to programming (described hereinafter). Hie blasting dongle 124 contains "keep alive" codes which the controller 112 reads and sends every few seconds to the remote blasters 106: these keep alive codes are required to reset a so-called "keep alive" timer of each remote blaster 106 that enables generation of the firing voltage. (The "keep alive" timer is a functional safety' feature.) If the keep alive codes are not received by any one of the remote blasters 106, that remote blaster 106 remains at, or automatically returns to, an inherently safe voltage level at which associated EBS devices 304 do not fire. If the blasting dongle 124 is removed from the controller 112 during the blasting sequence, the keep alive codes are no longer available, and the remote EBS blasters 106 move to theDISABLED state in which they are unable to fire the EBS devices 304 (even if something goes wrong with the EBS state machine).

[0084] In the dual blasting system 100 (and in the synchronized blasting system 200), the controller 1 12 also includes a communications port configured to receive a physical blast file key device (not shown), e.g., including a USB memory stick, or other manually removable machine-readable memory unit. The physical blast file key device contains a blast file key that includes the BIDs to be fired in a particular blast, along with additional information enabling tracking and a secure and safe execution of tire blast. Tire blast file key is generated at planning the blast by a blast planning system, then encoding information is added, and finally, once the blast is fired, post blast information is added. Tire blast file key may therefore be referred to as containing a "Curriculum Vitae" (CV) of each (wireless) blast.The blast file key is required by the WEB state machine but not the EBS state machine. The WEB state machine may require the blast file key in order to enter the ARM / F1RE states and thus send the ARM / FIRE commands for the WEB devices 302. The BIDs of the blast file key are required in order to active / fire the WEB devices 302.

[0085] In the dual blasting system 100 (and in the synchronized blasting system 200), the remote blaster 106 is configured to send the handshake messages 122 to the controller 112, generally via the EBS network connection 1 16. The handshake 1 12 is used by the controller 112 to control the WEB state machine and the EBS state machine, and thus to synchronize the WEB system with the EBS as explained hereinafter with reference to a dual blasting method 600 (also referred to as a “concurrent blasting method”) and the synchronized blasting method 700.

[0086] Tire dual blasting system 100 (and the synchronized blasting system 200) may include one or more Ml measurement devices (also referred to as "Ml measuring devices") configured to measure a signal-to-noise (SNR) of the MI signals 104 that is, in use, tested to be preferably above a pre-defined threshold. In the dual blasting system 100, the one or more MI measurement devices provide MI measurements, not synchronization, and are conducted prior to a blast, e.g., for checking / confirming the MI signal receivability in a mine / environment, but not during the blast. In the dual blasting system 100 and the synchronized blasting system 200, the MI measurement devices are generally used pre-blasting in order to survey the mine site for sufficiently good SNRs in a process that is independent from the blasting process. In use, the MI measurement devices are arranged / located / buried in the path of the MI signals 104. The MI measurement devices each include an appropriately tuned MI antenna and receiver, e.g., from a DRX of a WebGen device, and can generate an electronic / electrical output signal representing the measured SNR and send such signal to the controller 112, e.g., via the EBS network connection 116 or via a data network in the site or via a wire to the controller 1 12 or the remote blaster 106.Alternatively, the MI measurement devices may be physically collected and read out via a wired interface, and the data from the MI measurement devices being reviewed in order to determine whether the measured SNR in the area is sufficient for a secure and safe blast.

[0087] The dual blasting system 100 (and the synchronized blasting system 200) may include a user interface (UI) 126 connected to and controlled by the controller 112 to display information to a human operator and to receive human input from a human operator. The Ul 126 includes a FIRE button for the operator to start the firing sequences.

[0088] The dual blasting system 100 may be used for two or more independent blasts, having respective different BIDs and EBS identifiers, e g., one BID for the WEB devices 302 and an unrelated set of identifiers (IDs) for the EBS devices 304. The EBS deGees 304 do not have BIDs: instead, the EBS deGees 304 have respective individual IDs, which are stored in the corresponding remote blaster 106 (e.g., for eDev devices) or the corresponding loggers (e.g., for i-kon devices). It may be useful to have these multiple independent blasts prepared and executed together, e.g., within a selected period of time in which the site is cleared, thus mitigating tire need to clear the site for each blast, even if they are independent, e.g., not part of the same blasting plan.Dual Blasting Method (“Concurrent Blasting Method”)

[0089] The dual blasting system 100 performs the dual blasting method 600 automatically or substantially automatically. The dual blasting system 100 and the dual blasting method 600 may be useful for applications in which the synchronization of the wired blast (using the EBS devices 304) and the wireless blast (using the WEB devices 302) need not be as prccisc / cxactas provided by the synchronized blasting system 200. As shown in FIG. 1, the dual blasting system 100 does not require a MI synchronization device (also referred to herein as a "syncbox 202", shown in FIG. 2) to perform the dual blasting method 600 described. In the dual blasting method 600, the wired blast fires independently of the wireless blast, which means that, if there is a failure in the antenna system 102 (which includes the CG) during sending the MI FIRE sequence, the wireless blast will misfire while the wired blast will fire. In other words, the dual blasting system 100 and the dual blasting method 600 provide concurrent blasting of wired and wireless blasts, but may not support synchronous blasting of both EBS and WEB systems, which implies that the dual blasting method 600 is only recommended in applications / opcrations where the wired blasts and the wireless blasts arc independent and locally separated since the wired blast may fire independently of whether tire antenna system 102 (and the CG) transmits the Ml FIRE command to the wireless detonator or not, e.g., if the antenna system 102 fails prior finalizing the transmission of the MI FIRE command, the wired blasts will fire regardless.

[0090] As shown in FIG. 6, the dual blasting method 600 includes: a. in a preparatory phase (P), encoding and loading the WEB devices 302 (602), which includes: encoding the WEB devices 302 with an encoder (including encoding the selected BID), loading the WEB devices 302 into the holes 306, setting the WEB devices 302 into a SLEEP state (thus setting the WEB state machine to the SLEEP state), and loading the corresponding deck(s) around / onto the WEB devices 302; b. in the preparatory phase (P), logging, loading, connecting and testing the EBS devices 304 (604A), which includes: logging the EBS devices 304, e.g., with a logger, loading the EBS devices 304 into the holes 306, testing the EBS devices 304, connecting the EBS devices 304 to the remote blaster 106 by the respective wires / cables 108 — optionally with one or more loggers between the EBS devices 304 and the remote blaster 106 also connected by the respective wires / cables 108 for some types of the EBS devices 304 (e.g., for i-kon devices), and loading the corresponding deck(s) around / onto the EBS devices 304:c. in the preparatory phase (P), connecting the controller 112 to the remote blaster 106 (604B), which includes: a data interface of the remote blaster 106 connecting to the EBS network connection 116. and the remote blaster 106 sending a COMMUNICATIONS handshake of the handshake messages 122 to the controller 112 via the data interface and the EBS network connection 116: this COMMUNICATIONS handshake confirms to the controller 112 is communicatively connected to the or each remote blaster 106; d. in the preparatory phase (P), connecting the controller 112 to the antenna system 102 (604B), which includes: the two-way data interface of the antenna system 102 connecting to the WEB network connection 120, and the antenna system 102 sending a COMMUNICATIONS handshake of the WEB handshake messages 119 to the controller 112 via the two-way data interface and the WEB network connection 120: this COMMUNICATIONS handshake confirms to the controller 112 is communicatively connected to the or each antenna system 102; e. in a first phase (1), the controller 112 configuring a concurrent blast (608), which includes selecting the EBS and the WEB system, which includes selecting the or each remote blaster 106 and the antenna system 102 for the blasting method 600, e.g., by the operator selecting a dual “concurrent” blast via the UI 126 of the controller 112; f. in a second phase (2), the controller 112 receiving initialization inputs (610), which includes: (i) the controller 112 receiving the blast file key provided by the operator to the controller 112, (ii) the controller 112 receiving a beacon clearance confirmation, e.g., by reading a beacon ID (e.g., in an RFID device), to confirm the blast file key is associated with the blast location defined by the beacon ID, and (iii) receiving a manual input from the user, e.g., via the GUI, to initialize the blast — in this phase, the blast file key and the beacon ID are only required for the WEB blast and WEB state machine, and the provided information is only stored on the controller 112 at this stage; furthermore,initialization of the blast in this phase only relates to the EBS blast and the EBS state machine, g. in a third phase (3), the remote blaster 106 initializing the loggers (612A) — if they are present — and the remote blaster 106 verifying communication via the EBS network connection 116 with the controller 112, and reporting any failures (including potential failures) of the EBS devices to the controller 1 12 in a further handshake message of the handshake messages 122 (612B); h. in a fourth phase (4), if communication with the or each remote blaster 106 is not verified or if a failure is reported in the further the handshake message (of the handshake messages 122), the controller 112 knows from the remote blaster 106 that something in the process failed and so the controller 112 aborts both the WEB and EBS blasts, either automatically or on operator action; i. in the fourth phase (4), if there are no failures reported in the handshake messages 122, the controller 112 can receive a program input from the operator (by a program button on the UI 126), and receive the blasting dongle 124 (614), and — responsive to the program input and the blasting dongle 124 being received — send programming instructions to the remote blaster 106 in the EBS messages 1 14; j. in a fifth phase (5), responsive to the programming instructions, the remote blaster 106 programing the EBS devices 304 (616A), and reporting any failures (including potential failures) to the controller 112 (616B) — this includes the remote blaster 106 sending a PROGRAMMED handshake of the handshake messages 122 indicating that the EBS devices 304 are programmed for the blast (and arc in the PROGRAMMED state); k. in a sixth phase (6), the controller 112 confirming / accepting potential failures in the PROGRAMMED handshake (e g., if the PROGRAMMED handshake takes longer than a selected wait time to be received, in examples between 10seconds and 3 minutes, depending on a size of the EBS blast), or aborting (618), e.g., based on operator input via the UI 126, l. in a seventh phase (7), the controller 112 automatically sending an ARM command instruction to the WEB system (specifically to the or each antenna system 102) in the WEB messages 118, wherein the ARM command instruction includes the BID of the WEB devices 302 in this blast (620) — if the antenna system 102 validly receives the ARM command instruction, the antenna system 102 automatically sends an ARM ACKNOWLEDGE handshake to the controller 112 in the WEB handshake messages 119, and if the controller 112 does not receive this ARM ACKNOWLEDGE handshake within a selected wait time, the controller 112 automatically aborts the method 600 (in examples, the selected wait time is between 2 minutes and 4.5 minutes, depending on a size of the WEB blast); m. in the seventh phase (7), each remote blaster 106 keeping its EBS devices 304 charged, thus in a charged state (622), n. in the seventh phase (7), the antenna system 102 (which includes the CG) transmitting the MI ARM sequence in the MI signals 104 (624) — as mentioned hereinbefore, the MI ARM sequence include the WAKE-UP command, the START command, the BID(s), and the MT ARM command; o. in an eighth phase (8), the WEB deGees 302 waking up responsive to the WAKE-UP command (626); p. in a ninth phase (9), the controller 112 starting a time window for the operator to press / activate / select the FIRE button, and detecting when the operator does press / activate / selectthe FIRE button, and — responsive to the FIRE button being pressed / activated / selected via the UI 126 — the controller 112 sending an instruction in the EBS messages 114 to the remote blaster 106 to control the remote blaster 106 to issue the CHECK command, the ARM command and the first-last-det-check sequence to the connected EBS devices 304 (628);q. in a tenth phase (10), responsive to the instruction from the controller 112, the or each remote blaster 106 issuing the CHECK command, the ARM command, and the first-last-det-check sequence to its connected EBS devices 304 (630A), and reporting any failures to the controller 112 in an additional handshake message of tire handshake messages 122 (630B); r. in an eleventh phase (1 1), the controller 1 12 automatically aborting if the first- last-dct-chcck sequence fails (as reported in the additional handshake message) in the tenth phase (632A), otherwise the controller 112 automatically accessing a predetermined timing for commanding the WEB devices 302 and tire EBS devices 304 to fire (including a predetermined interval referred to as the “Ml fire delay” described hereinafter), and then the controller 112, at time T = 0, automatically instructing the antenna system 102 to transmit the MI FIRE sequence by sending a fire command instruction to the antenna system 102 in the WEB messages 118 (632B) — if the antenna system 102 validly receives the MI FIRE command instruction, the antenna system 102 automatically sends a MI FIRE acknowledge handshake to the controller 112 in the WEB handshake messages 119, and if the controller 112 does not receive this MI FIRE acknowledge handshake within a selected wait time, the controller 112 automatically aborts the method 600 (in examples, the selected wait time is about 4 seconds (for FIRE only) or about 30 seconds (in implementations where the SYNC is arranged to be perfonned after the user presses the FIRE button); s. in a twelfth phase (12), responsive to the instructions from the controller 112, the antenna system 102 (via the CG 504) transmitting the MI FIRE sequence, including the Ml SYNC command and the Ml FIRE command (634); t. in a thirteenth phase (13), the WEB devices 302 receiving the MI SYNC command, and synchronizing their internal clocks (636) — in response to the MI SYNC command, all of the WEB devices 302 synchronize their clocks, e.g., they synchronously start a time ticker that exactly ticks once every 0.5 seconds;u. in a fourteenth phase (14), the controller 112, according to the predetermined MI fire delay, thus at T = (MI fire delay), automatically instructing the or each remote blaster 106, by sending an EBS FIRE command instruction, to issue the prepare-to-fire command and the FIRE command (638); v. in a fifteenth phase (15), responsive to the EBS FIRE command instruction, from the controller 1 12 in the fourteenth phase (14), the or each remote blaster 106 transmitting the prcparc-to-firc command followed by the FIRE command to the EBS devices 304 (640); w. in the fifteenth phase (15), the WEB devices 302 receiving the MI FIRE command and issuing FIRE signals to their respective electronic detonators according to their synchronized clocks (642) — when the WEB devices 302 have received the MI FIRE command, they each wait until the next occurring time tick (e.g., on the 0.5 second mark), and they send the FIRE command to their electronic detonators on that time tick; and x. in a sixteenth phase (16), the EBS devices 304 firing, responsive to the FIRE command (from the remote blaster 106) (644), and the WEB devices 302 firing substantially concurrently with the EBS devices 304, responsive to the FIRE signals (646).

[0091] In the dual blasting method 600, the remote blaster 106 does not wait for the MI ARM command or tire MI FIRE command because there is no sync-box 202 in tire dual blasting system 100. Instead, the controller 112 first automatically commands the antenna system 102 to transmit tire MI FIRE sequence (in 632), then — at a later time determined by the predetermined interval referred to as the "Ml fire delay" — commands the remote blaster 106, according to the EBS timing, to issue the prepare-to-fire command and the FIRE command (in 638). The Ml fire delay thus approximately or substantially or precisely accounts for expected / measured delays in the WEB system (including delays in the WEB messages 118, the antenna system 102, the MI signals 104 and the WEB devices 302) compared delays in the EBS (including delays in the EBS messages 114, the remote blaster 106, the wires / cables 108, the loggers if present, and the EBS devices 304). Depending on implementation details,the MI fire delay may be able to precisely account for the MI FIRE delay (within an error range that does not affect blasting outcomes). The predetermined MI fire delay may be determined for each implementation of the dual blasting system 100 as described hereinafter with reference to the eleventh phase (11). Using the MI fire delay effectively assumes the MI FIRE command will get through to the wireless initiator devices 302.

[0092] Tn the second phase (2), after the sending of the PROGRAMMED handshake, or earlier in the method 600, the operator inserts the blast file key into the controller 112, and then confirms the beacon clearance. The controller 112 thus receives a manual input from the operator (c.g., insertion of the blast file key, or operation of the UI 126) to move both state machines to the next mode, e.g., the ARM mode (e.g., by the operator pressing / activating / selecting an ARM button on the controller 112). In the method 600, the blast file key can be inserted at any convenient time up until sending of the ARM sequence. The confirming of the beacon clearance relates to the WEB system: the operator has to present the beacon ID (e g., an RFID card or tag) to the controller 112 to ensure that the BIDs of the WEB blast are linked to the location of the blast. The beacon ID is located at the blast or at the stope and needs to be picked up prior blasting. The beacon clearance confirmation can avoid the wrong blast being fired, and confirms that the blast location and the BIDs match with the blast plan.

[0093] With reference to the fourth phase (4), the controller 112 knows from the remote blaster 106 that something in the process failed because the remote blaster 106 responds to requests of the controller 112, c.g., the controller 112 may command the remote blaster 106 to program all EBS devices, and — after a certain time — the controller 112 starts polling the remote blaster 106 for confirmation, and — once the confirmation arrives — the controller 112 sets its internal state machine to “dets programmed” state, or — if confirmation fails — the blast is aborted by the controller 112

[0094] With reference to the sixth phase (6) — including the controller 112 confirming / accepting the potential failures or aborting (618) — the remote blaster 106 can confirm that some / most (e.g., around 100) of the EBS devices 304 are successfully programmed but some / few (e.g., 2) are not, in which case the operator gets a dedicated failure message at the UI 126 to decide whether they want to abort, or to fire the blast withsome or few of the EBS devices 304 not programmed (thus confirming / accepting misfires) by selecting to proceed by the UI 126.

[0095] With reference to the seventh phase (7), after both state machines enter the ARM mode, the controller 1 12 sends the MT ARM sequence in the WEB messages 1 18 to the antenna system 102, in response to which the antenna system 102 transmits the MI ARM sequence to the WEB devices 302, and in response to which the WEB devices 302 validate the received MI ARM sequence (using an automatic validation method in the WEB devices 302, e.g., as do WebGen devices) and the WEB deGees 302 may synchronize their respective clocks (c.g., as do WebGen 100 devices).

[0096] In the ninth phase (9), the controller 112 may control the first-last det checks to be performed as close to the blast time as possible by signaling issuance of the first-last-det- check sequence (in 628).

[0097] In the tenth phase (10), the remote blaster 106 sends the CHECK command, the ARM command and the first-last-det-check sequence to its connected EBS devices 304 (in 630A), via tire connected loggers if present (which pass the CHECK and ARM command through to the EBS devices 304). If present, each logger checks the first and the last det on its network for being armed correctly, then the logger tells the remote blaster 106 whether the check was successful. The remote blaster 106 tells the controller 112 of any failures (in 630B), which might be in response to a next status request from the controller 1 12.

[0098] In the eleventh phase (11), if the first-last-det-check fails for any one of the connected EBS devices 304 (as reported in 630B), the controller 112 automatically aborts the EBS blast and aborts the WEB blast. If tire first-last-det-check fails, the logger (if present) reports “not armed correctly” to the remote blaster 106, and the remote blast 106 tells the controller 112 at the next status response in the handshake messages 122.

[0099] In the eleventh phase (11), the controller 112 automatically accesses the predetermined timing for commanding each remote blaster 106 to issue the prepare-to-fire command for its loggers to pass following commands to its connected EBS devices 304. The controller 112 receives / accesses the MI fire delay (which includes a value of predetermined expected delay time), which is the time that is expected to occur between sending the MIFIRE command in the MI signals 104 and the WEB devices 304 sending the FIRE signals to their detonators. The MI fire delay is predetermined based on properties / configuration / measurements of the site and the WEB network connection 120, e.g.: the propagation time of the MI signals 104, the configuration of the WEB network connection 120, and the configuration of the antenna system 102. From the MI fire delay, the controller 112 selects the time to send the EBS fire instructions to provide substantially concurrent firing of both systems (WEB and EBS), thus the time to send the EBS fire instructions is selected to substantially match the MI fire delay. However, as this is not synchronized, and may include an inaccuracy, e g., approximately a second because of unpredictable latency, this method 600 is described as “concurrent” blasting rather than synchronized blasting. Hie value of the MI fire delay may be predetermined in laboratory trials / experimental testing. The latencies that cannot be predicted may amount to substantially one second, including network latency between the controller 112 and the CG 504 of the antenna system 102 (e.g., LTE or Ethernet latency) and a latency in the WEB devices 302 that is not known by the controller 112 as it depends on the calibration of the individual clocks of the WEB devices 302. When the MI FIRE command is sent by the antenna system 102 and the WEB devices 302 have received it, they all will send the FIRE signal to their dets synchronously but in a time window of up to substantially half of a second after receiving the MI-FIRE, depending on the clock synchronization (as described hereinbefore), and the time between receipt of the FIRE command and sending of the FIRE signal is unpredictable and can be referred to as the latency in the WEB devices 302.

[0100] In the thirteenth phase (13) and fifteenth phase (15), the WEB devices 304 that receive the MI blasting commands (including the MI SYNC command and the MI FIRE command) automatically validate the blasting commands, e.g., using the validation process of existing WebGen devices, e.g., based on matching a BID in the blasting command with a BID encoded into each WEB device 304.Synchronized Blasting System

[0101] In the synchronized blasting system 200, as shown in FIG. 2, the controller 112 is configured to send the WEB messages 118 to the antenna system 102 via the WEB network connection 120 equivalently to the connections in the dual blasting system 100.

[0102] In contrast to the dual blasting system 100, the antenna system 102 sends the WEB messages 118 (via the MI signals 104) to a MI receiving module 202 (referred to herein as the "MI synchronization device" or the “sync-box 202”) that is configured to generate sync signals 204 (representing the WEB messages 118 and optionally the SNR measurements) and sends these to the remote blaster 106 via a communication interface, referred to herein as the SYNC-intcrfacc 206 (c.g., an RS485 serial interface on the sync-box 202). The sync signals 204 synchronize (which includes controlling the timing of) the remote blaster 106 with the received WEB messages 11 . This synchronization allows for safe and effective operation of the WEB devices 302 and the EBS devices 304 in a combined blast, also referred to as a “synchronized blast”. The sync-box 202 effectively extracts the WEB messages 118, and synchronizes and sends the sync signals 204 to the connected remote blaster 106. The syncbox 202 has one remote blaster 106, thus a dedicated one of the at least one sync -box 202 may be required for each remote blaster 106, including when the remote blasters 106 are located at different places in the site and each one needs a pick-up for the MI signals 104 carrying the WEB messages 118. The or each remote blaster 106 synchronizes (which includes controlling the timing of) the EBS commands with the received sync signals 204 representing the WEB messages 118, in the synchronized blasting method 700 as described hereinafter.

[0103] There may be uncontrollable latency^ between the controller 112 and the antenna system 102, making precise coordination, synchronization and timing control of the messages in the MI signals 104 for the WEB devices (320) difficult to synchronize with the messages forthc EBS devices (304). The sync-box 202 allows the system 200 to account for the uncontrollable latency between the controller 112 and the antenna sy stem 102.

[0104] As shown in FIG. 2, the or each sync -box 202 may be a unit / module separate from the remote blaster 106, e.g., located / placed in an access tunnel 208 when in use in the site, such that the MI signals 104 from the antenna system 102 reliably / substantially reach the sync -box 202, preferably with an MI SNR above the pre-defined threshold (the SNR measurementsprovide information in order to confirm whether good MI signals are being received; however, SNR measurements are not necessarily required for a synchronized blast to be possible). Tire sync-box 202 may include a protective housing / casing to protect the sync-box 202 in the access tunnel 208 and the site environment, including from dust / heat / pressure. In use, the or each sync -box 202 is arranged / located / buried in the path of the MI signals 104. The or each sync-box 202 includes a magnetometer in the form of an appropriately tuned MI antenna and receiver, e g., equivalent to a DRX of a WebGen device, and is configured to generate an clcctronic / clcctrical output representing the sync signals 204 for the SYNC- interface 206. Alternatively or additionally to tire or each sync-box 202 being the unit / modulc separate from the remote blaster 106, the or each sync-box 202 may be a unit / module incorporated into the corresponding remote blaster 106, e g., coupled directly to the remote blaster 106 (e.g., in a protective housing / case of the remote blaster 106, with the SYNC-interface 206 including an electrical plug / socket connection rather than a long wire / cable as for the separate sync -box 202) thereby7providing the remote blaster 106 with the appropriately tuned MI antenna and receiver to receive the MI signals 104. The sync-box 202 and / or the remote blaster 106 can include conductive / magnetic shielding between the MI antenna and / or receiver of the sync-box 202 and electrical / electronic components of the remote blaster 106 to block / mitigate radiative electromagnetic interference (EMI) from the remote blaster 106 generating spurious / undesirable signals / noise in the sync -box 202; if the sync-box 202 is incorporated into the corresponding remote blaster 106, the conductivc / magnctic shielding is arranged to block / mitigate the EMI from the remote blaster 106 whilst still allowing reception / detection of the MT signals 104 by the magnetometer of the sync-box 202. The sync -box 202 and / or the remote blaster 106 can be configured to have separated operational frequencies (thus an "EMI frequency separation") so the operational frequencies of the components of the remote blaster 202 have substantially no overlap with the operational frequencies of the tuned MI antenna and the receiver of the sync -box 202 — in this way, if the remote blaster 106 generates undesirable EMI, the receiver of the sync -box 202 does not detect it or at least does not mistake it for the MI signals 104 due to the frequency separation. This frequency7separation to mitigate EMI includes the MI antenna having one or more centre / resonant frequencies that do not overlap with the operational radiative frequencies of the remote blaster 106. The sync -box 202 may be removably insertable into and / or manually connectable to the remote blaster 106, thus allowing theremote blaster 106 to be conveniently configured for synchronized operation (by way of the synchronized blasting method 700) if required — the remote blaster 106 may therefore be reconfigurable between pure EBS blasting, dual blasting according to the dual blasting method 600, and synchronized blasting according to the synchronized blasting method 700. The sync -box 202 may be arranged deep in tire access tunnel 208, which may be a borehole (and the SYNC -interface 206 may include a communications wire / cable), may be arranged close to or at the collar of the access tunnel 208, may be arranged within a line of sight (LOS) of the remote blaster 106 (and the SYNC-intcrfacc 206 may include a LOS or through-thc-air (TTA) communications link with substantially no latency , e.g., using WiFi), or may be arranged at or inside the remote blaster 106 (with the EMI shielding and / or EMI frequency separation). The sync-box 202 need not require SIL3 certification because it cannot generate a firing voltage sufficient to fire a detonator, e.g., unlike the WEB devices 302.

[0105] In addition to the one or more Ml measurement devices described hereinbefore, in the synchronized blasting system 200, as shown in FIG. 2, the SNR measurement can be generated by the sync -box 202 including or acting as one of the MI measurement devices: the sync -box 202 therefore verifies good MI communication to itself — this SNR measurement provides a control to mitigate a risk of the WEB devices 302 being fired but not the EBS devices 304 because of a too-weak MI FIRE signal. In the blasting process provided by the synchronized blasting system 200, the MI measurements by the sync -box 202 determine whether the received MI signals arc good enough for secure reception.Synchronized Blasting Method

[0106] The synchronized blasting sy stem 200 performs the synchronized blasting method 700 automatically or substantially automatically. Tn the synchronized blasting system 200, the EBS blast only fires if the / each sync-box 202 detects and validates the MI FIRE sequence with sufficient SNR; thus, if the antenna system 102 aborts during transmission of the MI FIRE sequence, the EBS blast and the WEB blast will not fire.

[0107] As shown in FIG. 7, the synchronized blasting method 700 includes:a. in preparatory phase (P), encoding and loading the WEB device 302 (702) as in the dual blasting method 600, b. in the preparatory' phase (P), logging, loading, connecting and testing the EBS devices 304 (704A) as in the dual blasting method 600; c. in the preparatory' phase (P), connecting the controller 1 12 to the remote blaster 106 (704B) as in the dual blasting method 600, step 604B; d. in the preparatory' phase (P), connecting the controller 112 to the antenna system 102 (704B) as in the dual blasting method 600, step 604B; e. in the preparatory' phase (P), encoding and connecting the sync-box 202 (706), which includes connecting the synch-box 202 to the remote blaster 106 and to the controller 112 — the encoding can be done prior to loading, or later in the method 700, e.g., directly prior to the blast; f. in the preparatory' phase (P), connecting the controller 112 to the sync -box 202 (706B), which includes: the SYNC-interface 206 of the sync -box 202 connecting to the data network (e.g., the mine network, e.g., via the remote blaster 106) and the sync-box 202 sending a COMMUNICATIONS handshake of the handshake messages 122 to the controller 112 or the remote blaster 106 via the SYNC-intcrfacc 206 — this COMMUNICATIONS handshake confinns to the controller 1 12 and / or the remote blaster 106 that the sync-box 202 is communicatively connected thereto; g. in a first phase ( 1), the controller 112 configuring a synchronized blast (708), e.g., by the operator selecting a synchronized blast via the UI 126 of the controller 112 (instead of selecting a dual / concurrent blast as in the dual blasting method 600), and the controller 112 receiving information for the wireless blast from the blast file key and the beacon ID; h. in a second phase (2), the controller 112 receiving initialization inputs (710) as in the dual blasting method 600, and then instructing the remote blaster 106 toinitialize the EBS devices 304 and instructing the antenna system 102 to initialize the WEB devices 302, i. in a third phase (3), the remote blaster 106 initializing the EBS devices 304 — by way of the loggers (712A) if they are present (712A), as in the dual blasting method 600: j. in the third phase (3), the remote blaster 106 and / or the controller 112 verifying communication with the sync -box 202 via the SYNC-interface (712B); k. in the third phase (3), the remote blaster 106 verifying communication via the EBS network connection 116 with the controller 112, and reporting any failures (including potential failures) of the EBS devices 304 to the controller 112 as in the dual blasting method 600, and any failures of communication with the sync-box 202 (712C); l. in a fourth phase (4), if communication with the or each remote blaster 106 and the sync -box 202 is not verified or if a failure is reported in process 712C, the controller 112 aborting both the WEB and EBS blasts (714), as in the dual blasting method 600; m. in the fourth phase (4), if there arc no failures, the controller 112 receiving a program input from the operator and receive the blasting dongle 124 (714), as in the dual blasting method 600; n. in a fifth phase (5), responsive to the instructions from the controller 112, the remote blaster 106 programing the EBS devices 304 (716A), and reporting any failures (including potential failures) to the controller 112 (716B), as in the dual blasting method 600; o. in a sixth phase (6), the controller 112 confirming / acccpting potential failures or aborting (718), as in the dual blasting method 600;p. in a seventh phase (7), the controller 112 instructing the sync -box 202 (e.g., via the remote blaster 106 using the EBS messages 114) to wait for an MI ARM command, or alternatively the remote blaster 106 instructing the sync- 202 box autonomously based on its own state machine; and then, in response to be wait instruction, the sync -box 202 waiting for the MI ARM command (719A), and the controller 112 displaying an indication to the operator that sync-box 202 is waiting for the MT ARM command to be detected (719B); q. in an eight phase (8), the controller 112 automatically sending an ARM command instruction to the WEB system (specifically to the or each antenna system 102) in tire WEB messages 118, wherein the ARM command instruction includes the BID of the WEB devices 302 (and the sync -box 202) in this blast (720), as in the dual blasting method 600 except the sync -box 202 is present — and, as in the dual blasting method 600, if the antenna system 102 validly receives the ARM command instruction, the antenna system 102 automatically sends an ARM ACKNOWLEDGE handshake to the controller112 in the WEB handshake messages 119, and if the controller 112 does not receive this ARM ACKNOWLEDGE handshake within a selected wait time, the controller 112 automatically aborts the method 700; r. in the eighth phase (8), each remote blaster 106 keeping its EBS devices 304 charged, thus in a charged state (722), as in the dual blasting method 600; s. in the eighth phase (8), the antenna system 102 (which includes the CG) transmitting the MI ARM sequence in the MI signals 104 (724), as in the dual blasting method 600; t. in a ninth phase (9), the WEB devices 302 waking up responsive to the WAKE-UP command (726A), as in the dual blasting method 600; u. in the ninth phase (9), the sync -box 202 receiving the WAKE-UP command, and optionally other MI signals 104 of the MI ARM sequence, and optionally measuring / determining at least one SNR value of the MI signals 104 (726B);v. in the ninth phase (9), the sync -box 202 reporting the SNR value and / or whether is “good” (relative to the pre-defined threshold) to the controller 112 and / or to the remote blaster 106 using the electronic / electrical output signal representing the measured SNR, including via the sync-interface 206 to the remote blaster 106, which forwards information representing the measured SNR to the controller 112 (726C); w. in a tenth phase (10), the controller 112 displaying the SNR value and / or whether it is good, and automatically aborting the blast if the SNR is below the prc-dcfmcd threshold (726D); x. in an eleventh phase (11), the or each remote blaster 106 executing the CHECK and ARM commands, and the first-last-det -check sequence (730A), and reporting any failures to the controller 112 (730B), as in the dual blasting method 600: y. in a twelfth phase (12), the controller 112 automatically aborting if the first- last-det-check sequence fails in the eleventh phase (732A), as in the dual blasting method 600; otherwise displaying to the operator that the blast is ready to fire (732B); z. in a thirteenth phase ( 13), the controller 1 12 detecting when the operator does press / activate / select the FIRE button, and — responsive to the FIRE button being pressed / activated / selected via the UI — the controller 112 sending a MI FIRE command instruction in the WEB messages 118 to the antenna system 102 to issue the MI FIRE sequence (732C) — and, as in the dual blasting method 600, if the antenna system 102 validly receives the Ml FIRE command instruction, the antenna sy stem 102 automatically sends a MI FIRE acknowledge handshake to the controller 112 in the WEB handshake messages 119, and if the controller 112 does not receive this MI FIRE acknow ledge handshake within a selected wait time, the controller 112 automatically aborts the method 700;aa. in a fourteenth phase (14), responsive to the MI FIRE command instruction in the WEB messages 118, the antenna system 102 (with the CG) transmitting the MI FIRE sequence, including the SYNC command and the MI FIRE command (734), as in the dual blasting method 600; bb. in a fifteenth phase (15), the WEB devices 302 receiving the MI SYNC command, responsively synchronizing their internal clocks (736); cc in the fifteenth phase (15), the sync-box 202 receiving the MI SYNC command (737), and responsively synchronizing its clock; dd. in the fifteenth phase (15), if the EBS includes the loggers, either the sync-box 202 or the remote blaster 106 accessing / detennining a timing for commanding the remote blaster 106 to issue the prepare-to-fire to the loggers ("Tl") in advance so that, after the sync-box 202 receives the MI FIRE command and the next clock tick occurs, the sync-box 202 can issue a FIRE command on the sync-interface 206 (synchronously with all WEB devices 304 sending FIRE commands to their detonators) which is immediately forwarded (with tire output signal edge following the input signal edge) by the remote blaster 106 to the EBS devices 306, thus with no unpredictable latency, including via the loggers if present, as described hereinafter in a seventeenth phase (17); ee. in a sixteenth phase (16), either (i) the sync-box 202, according to its determined timing "Tl ' for the remote blaster 106 in the fifteenth phase (15) and based on an internal clock of the sync-box 202, commanding the or each remote blaster 106 to issue the prepare-to-fire command to the loggers, and responsively the or each remote blaster 106 issuing the prepare-to-fire command; or (ii) the or each remote blaster 106 itself issuing the prepare-to- firc command according to its determined timing “Tl” for in the fifteenth phase (15) and based on an internal clock of the remote blaster 106 (738), ff. in the seventeenth phase (17), the sync-box 202 and the WEB devices 302 substantially simultaneously receiving the MI FIRE command (740);gg. in the seventeenth phase (17), the sync -box 202, responsive to the MI FIRE command, issuing the FIRE command to the or each remote blaster 106 according to its synchronized clock, and then the or each remote blaster 106 responsively and immediately (with substantially no latency) forwarding the FIRE command to of its all connected EBS devices 304 (via the loggers if present); and hh. in the seventeenth phase (17), the WEB devices 302, responsive to the MI FIRE command, issuing FIRE signals to their respective electronic detonators according to their synchronized clocks (742); and li. in an eighteenth phase (18), the EBS devices 304 firing, responsive to their FIRE commands (from the or each remote blaster 106) (744); and the WEB devices 302 firing substantially simultaneously with the EBS devices 304, responsive to the FIRE signals (746).

[0108] In the preparatory' phase (P), the encoding, connecting and loading the sync-box 202 (706) includes optionally encoding the sync-box 202 with the BID using the encoder, which includes the same process as encoding the WEB devices 302 — this is optional because assigning the BID to the sync -box 202 can alternatively be achieved automatically via the remote blaster 106 once the controller 112 has read the blast file key, or the BID may be fixed, assigned permanently to the sync-box 202 — in either case, the controller 1 12 has the BID of the sync-box 202 stored such that the BID of the sync-box 202 is used in the WEB messages 118 and thus these messages are recognized / decoded / validated by the sync -box 202 through comparison to its stored / assigned BID.

[0109] In the eighth phase (8), after sending the Ml ARM sequence in the WEB messages 118, the controller 112 can optionally determine (and optionally display to an operator on the U1 126 and / or the remote blaster 106) the SNR of the Ml signals as received by the Ml measurement devices (e.g., the sync-box 202), and — if the measured SNR is below the predefined threshold — the controller 112 can automatically abort the EBS blast and the WEB blast. In a sync scenario (with the sync -box 202), when the sync -box 202 receives / measures too low an SNR, and the sync -box 202 tells the controller 112 directly that the SNR is toolow, or the sync -box 202 tells the remote blaster 106, which in turn tells the controller 112 at the next status request that the SNR is too low, and then then controller 112 decides to abort.

[0110] The ninth phase (9) may include the sync -box 202 receiving the MI ARM command and then validating the received MT ARM command (using an automatic validation method in the WEB devices 302, e.g., as do WebGen devices), and, if validating fails, sending a ABORT / DISABLE signal to the controller 1 12, via the sync signals 204, the remote blaster 106 and the handshake messages 122, in response to which the controller 112 automatically aborts the EBS blast and aborts the WEB blast.

[0111] In the fifteenth phase (15), in response tire validation of the FIRE command by the sync -box 202, the or each sync -box 202 (and / or the remote blaster 106) or the or each remote blaster 106 automatically uses the timing = “Tl”. Timing “Tl” is the timing for the or each respective remote blaster 106 to issue the prepare -to-fire command for its loggers to pass all subsequent commands to all connected EBS devices 304 without delay / latency. "Tl" is a predetermined / selected fixed time for the implementation of the synchronized blasting system 200 and depends the predetermined time for which the loggers remain actively passing all commands after they receive the prepare-to-fire command, which is referred to as being in a "prepare to fire" state. When the loggers have received the prepare-to-fire command from the remote blaster 106, they only remain in the "prepare to fire" state for a few seconds. In some embodiments, the time between MI-SYNC and MI-FIRE is about 7 seconds, and "Tl" is detennined / selected such that the prepare-to-fire signal is not sent too early before the MI- FIRE signal arrives, thus keeping the loggers in the "prepare to fire" state long enough to pass through the FIRE command without delay / latency. The prepare-to-fire command may only be required in an implementation of the synchronized blasting system 200 which includes the loggers because the prepare-to-fire command controls the loggers to forward the following command (which will typically be FIRE in the synchronized blasting method 700) to the EBS devices 304 without time delay / latency in order to synchronize with the WEB devices 302. The timing "T 1 " is required because the loggers have a time-out period after they have prepared to fire, thus the FIRE command has to arrive before the end of this time-out period to avoid latency / delays, e.g., otherwise the loggers could respond with time-out errors rather than firing the EBS devices 304 with synchronicity. The timing "Tl" is thus a constant delay time (for each implementation of the synchronized blasting system 200, depending on itsloggers) that is predetermined / selected based on the predetermined time-out period of the loggers (e.g., substantially 5 seconds) and the predetermined time interval between the MI- SYNC and MI-FIRE commands (e.g.. substantially 7 seconds), e.g., the timing "Tl" can be between substantially 2 seconds and 6 seconds.Antenna System 102

[0112] As shown in FIG. 5, the antenna system 102 can include a loop antenna system 500 that includes a loop antenna 502 (e.g., as used in existing WebGen systems that have larger antennas, e.g., with 40-m diameters) that is sized and located / arranged to generate and direct the MI signals 104 in the required direction / area, towards the electronic blasting devices 110, the MI measurement device and the sync-box 202. The loop antenna 502 is driven by a current generator 504 (“CG”, e.g., as used in existing WebGen systems) of the antenna system 102. The current generator 504 is arranged and operates to receive the WEB messages 118 from the controller 112 and encodes them into modulation of a drive current to the loop antenna 502 to correspondingly modulate / encode the MI signals 104. Hie MI signals 104 are generated across a substantial area of the plane of the loop antenna 502 with substantially equal carrier frequency, modulation and phase. The loop antenna 502 can include two or more loops / windings all driven by a single current source.Encoding and Loading of WEB Devices 302

[0113] An authorized worker or an automated loader can obtain a one WEB device 302 from the magazine. The authorized worker can use a portable / hand-held encoder to program the obtained WEB device 302 by way of a manual encoding procedure using the encoder, or the automated loader can use an integrated encoder to program the obtained WEB device 320 by way of an encoding procedure. During the encoding procedure, the encoder can communicate (a) blast timing information corresponding to an initiation time delay for the WEB device 302 (e.g., corresponding to a precise time delay that this WEB device 302 is programmed to wait before triggering explosive initiation of the initiation unit after the WEB device 302 receives the FIRE command); and possibly or optionally (b) the GID / BID. Oncethe WEB device 302 has been encoded by way of the encoding procedure, the WEB device 302 can process and carry out commands including, for instance, the MI WAKE, ARM, and FIRE commands. After its encoding, if the WEB device 302 is within signal communication range of the antenna system 102, the WEB device 302 be triggered to cause explosive initiation of explosive composition(s) carried by its initiation unit, at least when any safetyprotocols / systems have been activates / deactivated, e.g., as described in International Patent Application Publication No. WO 2022 / 019841 Al of PCT / SG2021 / 050432 (“Systems, methods, and devices for commercial blasting operations”), which is hereby incorporated byreference herein. Once the WEB device 302 has been encoded / programmed, the WEB device 302 can be loaded into a particular one of the holes, in association with the loading of the one or more explosive compositions 314 and possibly stemming materials 316 into the hole as part of a blast hole loading procedure. The explosive composition loading can occur by way of a mechanized, automated, or autonomous platform or vehicle configured for carry ing and dispensing explosive compositions into blast holes, for instance, a vehicle conventionally referred to as a Mobile Manufacturing Unit (MMU), e.g., based on a commercially available ORICA LTD BM-7 (TM).Access Control System 800

[0114] In at least some implementations, the dual blasting system 100 and the synchronized blasting system 200 can include an access control system 800 for controlling access to the remote blasters 106 and the antenna system 102. In the access control system 800, the central controller 112 is in the form of a central controller 804 that provides a configuration key 808 to the remote blasters 106 and the antenna system 102. In the description of the access control system 800 hereinafter, the remote blasters 106 and the antenna system 102 are described as similar in the sense of their connection to the central controller 804: specifically, each of the remote blasters 106 and the antenna system 102 are referred to as a "remote unit 802", which can therefore be either one of the remote blasters 106 or the antenna system 102, because methods provided by7the access control system 800 enable control of each of the remote blasters 106 and the antenna system 102 (or each of the antenna systems 102, if there are more than one) by the central controller 804. Thus, in this context, the remote blasters106 may be referred to as "EBS remote blasters", and the or each antenna system 102 may be referred to as a "WEBS remote blaster", all being "remote units 802".

[0115] Unlike the controller 112 configured to operate without the access control network 800, the central controller 804 is configured to communicatively connect to three (3) mutually different physical access-control devices: (i) the blasting dongle 124, (ii) the blast file key device; and (iii) a physical configuration dongle (which includes machine-readable memory for data storage) in the form of a remote registration device 806 (described hereinafter), or the remote units 802 by way of a direct secure communications interface (described hereinafter).

[0116] As it is a form of the controller 112, the central controller 804 is configured to transmit the blasting command instructions (e.g., representing the FIRE command etc. described hereinbefore) to either a selected one of the remote units 802, or a selected group of the remote units 802 (selected based on and ID, e g., the group ID, blast ID or device IDs).

[0117] Each remote unit 802 is substantially remote from the central controller 804, thus located at a significant spatial distance from the central controller 804 during operation, wherein the significant spatial distance can be as close as one meter, or up to several tens of kilometers.

[0118] The central controller 804 is configured to communicatively connect to each remote blaster 802 during configuration using a secure communications interface of the central controller04 and a corresponding secure communications interface of tire remote unit 802, in some instances via a device-based secure communications interface of a remote registration device 806, described hereinafter.

[0119] In one or more implementations, the secure communications interface and the corresponding secure communications interface provide a direct communications connection between the central controller 804 and each of the remote units 802 individually or in turn (because the remote units 802 and generally configured one by one). In one or more implementations, the secure communications interface and the corresponding secure communications interface can include a wireless near-field communications interface, e.g, configured to communicatively connect using a radio-frequency identification (RFID)protocol or a Near-Field Communication (NFC) protocol. In one or more implementations, the secure communications interface and the corresponding secure communications interface can include a wireless short-range communications interface, e.g., configured to communicatively connect using a Bluetooth protocol, e.g., Bluetooth Low Energy. In one or more implementations, the secure communications interface and the corresponding secure communications interface can include a wired communications interface for use with a corresponding cable (having connector terminals) and / or a plug, e.g., configured to communicatively connect using a Universal Serial Bus interface and a USB cable, e.g., USB 3, or a One Wire Bus interface, or a Secure Digital (SD) interface In one or more implementations, the secure communications interface and the corresponding secure communications interface can include a wired communications interface for use with a corresponding cable (having connector terminals), e.g., configured to communicatively connect using a Universal Serial Bus interface and a USB cable, e.g., USB 3. In use, the remote unit 802 may be tested and configured in a secure room (accessible only by authorized persons) with the central controller 804. There may be a "commissioning day" for each area in a mine site, and the remote units 802 being commissioned on that day can be brought very close to the central controller 804, e.g., touching the central controller 804 or connected by the corresponding cable (mentioned hereinbefore), without requiring a separate individual / unique physical configuration device to carry a configuration key 808 described hereinafter.

[0120] Tn one or more implementations, the secure communications interface of the central controller 804 provides a direct communications connection between the central controller 804 and the remote registration device 806. Tire remote registration device 806 is an individual / unique physical device, which includes the device-based secure communications interface and a machine-readable memory for data storage, which may be described as "persistent memory", e.g., a flash memory’ chip. The remote registration device 806 reads the configuration key 808 from the central controller 804, stores the configuration key 808 in the machine-readable memory , and writes the configuration key 808 to the connected remote unit 802. The remote registration device 806 may be referred to as a "dongle" or "remote registration dongle", and the configuration key 808 may be referred to as a "dongle key". In these implementations, the corresponding secure communications interface of each of theremote units 802 provides a direct communications connection between the remote registration device 806 and each of the remote units 802 (in turn because the remote units 802 and generally configured one by one). In these implementations, the central controller 804 is not directly connected to the remote units 802 during commissions because the remote registration device 806 is instead used to transfer the public key generated by the central controller 804. In these implementations, it may be desirable to provide only one remote registration device 806, or only a selected limited number of the remote registration device 806 that arc able to transfer the public key, to improve the security of the remote units 802 and to thus improve site safety. In one or more implementations, the secure communications interface, the device-based secure communications interface and the corresponding secure communications interface can include a wireless near-field communications interface, e g., configured to communicatively connect using a radio-frequency identification (RFID) protocol or a Near-Field Communication (NFC) protocol. If the device-based secure communications interface is the wireless near-field communications interface, the remote registration device 806 may be powered by the wireless near-field communications interface to operate, and may be in the form an RFID card, NFC card, or smart card. In one or more implementations, the secure communications interface, the device-based secure communications interface and the corresponding secure communications interface can include a wireless short-range communications interface, e.g., configured to communicatively connect using a Bluetooth protocol, e g , Bluetooth Low Energy . Tn one or more implementations, the secure communications interface, the device-based secure communications interface and the corresponding secure communications interface can include a wired communications interface for use with a corresponding cable (having connector terminals) and / or a plug, e.g., configured to communicatively connect using a Universal Serial Bus interface and a USB cable, e.g., USB 3, or a One Wire Bus interface, or a Secure Digital (SD) interface. If the device-based secure communications interface is a USB interface, the remote registration device 806 may be referred to as a "USB dongle", "USB drive" or "thumb drive" and may be powered by the USB interface. The remote registration device 806 is a physical configuration device with a housing that can be carried by a person, e.g., by hand. The remote registration device 806 may be powered by the device-based secure communications interface to operate, as mentioned hereinbefore. Alternatively, the remote registration device 806 may have an internal power source thatpowers the device-based secure communications interface: in some implementations, the remote registration device 806 is a hand-held communications device — e.g., a smart / cell phone or personal communicator (e.g., an iPhone) — with the machine -readable memory and the device-based secure communications interface installed, e.g., Bluetooth and / or NFC as in commercially available smart / cell phones. Tire remote registration device 806 may require personal authentication to operate the device-based secure communications interface, e.g., a biometric lock or user-password combination, e.g., a face identification or a finger / thumb print identification. In the implementations with the wired communications interface, the remote registration device 806 is physically connectable to the central controller 804, e.g., to be plugged into the port 810, to create the communications connection for receipt of the configuration key 808, and it physically connectable to each of the remote units 802, in turn, to create the communications connection for transmission of the configuration key 808 to the remote unit 802. In use, having the separate individual / unique physical configuration device to carry the configuration key 808 may be more safe, secure and / or "idiot proof' than allowing direct secure connections between the central controller 804 and the remote units 802. In some implementations, the remote registration device 806 can include a plurality of secure communications interfaces, including a first secure communications interface corresponding to the secure communications interface of the central controller 804, and one or more second secure communications interfaces corresponding to the secure communications interfaces of the remote units 802, such that the central controller 804 can have a different secure communications interface from one or more of the remote units 802, allowing flexibility and back compatibility between the central controller 804 and the remote units 802 — for example, if the remote registration device 806 is a smart / cell phone, it can receive the configuration key 808 (and other data described hereinafter) via USB or Bluetooth (a first dcvicc-bascd secure communications interface) from the central controller 804, and then transfer the configuration key 808 (and the other data) to the remote units 802 via NFC (a second device-based secure communications interface); however, some implementations may have just one device-based secure communications interface fortesting and simplicity. It is noted that the device-based secure communications interface or interfaces do not limit the types of the second signals connections 812 that are established by the configuration key 808 and the other data: the second signals connections 812 can includea multitude of communications interfaces, including any one or more of LAN, 4G / 5G, radio modem, and telephone line.

[0121] In addition to its secure communications interface, the central controller 804 has a data network connection to a data network (e.g., an existing mine network as described hereinafter) that includes first signal connections 812, shown in FIG. 8, between the central controller 804 and each of the remote units 802. The first signal connections 812 are thus data network connections for electronic communication as described hereinafter.

[0122] The access control system includes the remote registration device 806.

[0123] The central controller 804 is configured to provide — by way of randomly generating or accessing — a public-private asymmetric encryption key pair with a public key and a private key, and to write the public key7(also referred to herein as the configuration key 808) to each remote unit 802 when connected to the secure communications interface either directly or via the remote registration device (when the remote registration device 806 is communicatively connected to the central controller 804, e.g., in or to a port 810 of the central controller 804).

[0124] Each of the remote units 802 (also referred to as “remote blast boxes” or “remote blasting machines”) has a data network connection to the first signal connections 812 in the data network. Each of the remote units 802 has a second signal connection 814 to at least one set of blast initiators / detonators 816. The second signal connection 814 can include: (i) a direct connection from a remote unit 802 to its blast initiators / detonators 816; or (ii) a connection via at least one logger between a remote unit 802 and its blast initiators / detonators 816, e.g., at least one i-kon (TM) Logger.

[0125] Each remote unit 802 is configured to receive the at least one blasting command instruction from the central controller 804 via the first signal connections 812.

[0126] The remote units 802 are configured to control the loggers and / or the initiators / detonators 816 via the respective second signal connections 814.

[0127] Each remote unit 802 has a port 818 configured to connect and receive the remote registration device 806, and to access / read data on the remote registration device 806,specifically including the configuration key 808, whilst the remote registration device 806 is communicatively connected to the remote unit 802 via electronic communication via the port 818. The port 818 is configured to support the secure communications protocols, which depend in the implementation, as described hereinbefore.

[0128] While the remote registration device 806 is communicatively connected one of the plurality of the remote units 802, that remote unit 802 is configured to read the configuration key 808 from the remote registration device 806, including when the remote registration device 806 is physically connected to tire remote unit 802 (depending on the implementation).

[0129] There is generally only one central controller 804 in tire access control system, and the secure communications interface is generally arranged such that the configuration key 808 can be transferred to one remote registration device 806 or to the plurality of the remote units 802 at any time. In general, the remote registration device 806 ("dongle") is attached to one of the remote units 802 during commissioning. The remote registration device 806 ("dongle") may be one of potentially many separate physical devices, e.g., multiple separate physical remote registration devices 806 (“dongles”) can be used to configure multiple remote units 802, essentially simultaneously.

[0130] Instead of, or in addition to the remote registration device 806, the system 800 can include a direct connection from the central controller 804 to each remote unit 802 — separate from the first signal connections 812 — which can take the form of a cable connection, or other direct connection that docs not itself store the configuration key 808 (and other configuration data) internally in its machine -readable memory'. Thus the direct secure connection of the remote unit 802 to the central controller 804 (c.g., via cable or wireless connection in the control room) may perform the function of tire remote registration device 806 ("dongle"), in implementations where the central controller 804 transfers the configuration key directly to each remote unit 802, the secure communications interface can connect to one or more of the corresponding secure communications interfaces at a time. In some implementations, multiple (e.g. ten) remote blasters 806 can be placed in a secure room (e.g., the control room) and set up largely simultaneously, using the secure communications interfaces (e.g., Bluetooth); this may be done at the same time as one or more remote units 802 are configured by one or more of the remote registration devices 806 ("dongles"), whichmay be relevant if there is an implementation with dozens of remote units 802. It may be desirable to use both secure communications interfaces simultaneously in some implementations, i.e., both the direct secure communications interface from the central controller 804 to each remote unit 802 and the at least one remote registration device 806 ("dongle"), e.g., the remote registration devices 806 ("dongles") can be used to avoid needing to go to the control room from underground where the remote blasters 806 are installed remotely (e.g. for repairs, replacements, and resets), while the direct secure communications interface can be used in the control room to set up and install new remote blasters 806 (e.g., when installing new remotes, or commissioning new systems).

[0131] In implementations with the remote registration device 806, there may be a limited number of the remote registration devices 806, e.g., one, in the access control system, so while one of the plurality of the remote units 802 is communicatively connected to the remote registration device 806 (e.g., plugged into the port 818), the others of the plurality of the remote units 802 are not communicatively connected to the remote registration device 806. Alternatively, the access control system may include a plurality of the remote registration device 806, each having the configuration key 808, in which case the remote registration devices 806 are duplicates that allow many of the remote units 802 to be registered in parallel, e.g., in large mining operations.

[0132] The remote registration device 806 is physically transferable from the central controller 804, e.g., above ground, to each of the remote units 802, e.g., below ground, e.g., by a human operator. The remote registration device 806 needs to be transported to each of the remote units 802 for commissioning thereof, but only once each. For example, this need only happen one time at first introduction of each remote unit 802 to the access control system 800. The configuration key 808 is stored on / in the remote unit 802 permanently (for the duration of the blasting operation) and the configuration key 808 is used in every new blasting session to encrypt a handshake key 820, which is generated newly for each new blasting session.

[0133] As shown in FIG. 8, the encrypted symmetric handshake key 820 is sent to the central controller 804 in a first handshake message 822 (described hereinafter), which uses its private asymmetric key corresponding to the configuration key 808 to decrypt the first handshakemessage 822 and read / access / store the handshake key 820, and to send an encrypted second handshake message 826 (’‘handshake reply”) with a specific communications key 824 selected for each remote unit 802. All further communication messages 830 between the central controller 804 and the remote unit 802 can then be encrypted with the remote blaster's specific communications key 824. Tire encrypted further communication messages 830 between the ORBS controller 804 and the remote units 802 include the messages between the controller 1 12 and the remote blaster 106, and the messages between the controller 1 12 and the antenna system 102, in the dual blasting method 600 and the synchronized blasting method 700, starting with tire communications handshakes 640A,704A described hereinbefore.

[0134] Each remote unit 802 is configured to provide — by way of randomly generating or accessing — the handshake key 820 that is unique / quasi-unique to the or each remote unit 802, thus different from the handshake keys 820 of the other remote units 802 connected to the central controller 804. Accordingly, the handshake key 820 uniquely identifies each remote unit 802 in the access control system 800.

[0135] Each remote unit 802 is configured to encrypt its handshake key 820 with its received configuration key 808, and then send the encrypted handshake key 820 in the encrypted first handshake message 822 to the central controller 804 unit via the first signal connections 812.

[0136] The central controller 804 is configured to receive the encrypted first handshake message 822 (with the handshake key7820), and responsively to decrypt the encrypted first handshake message 822 using the private key — a copy of which is store / retained in / by the central controller 804, including after the remote registration device 806 has been removed from the central controller 804. Having decrypted the first handshake message 822, the central controller 804 is configured to rcad / acccss the handshake key 820 from the first handshake message 822 from each remote unit 802.

[0137] The central controller 804 is configured to store the handshake keys 820 in a data store that associates / identifies the respective remote units 802 in a blast plan / blast planning data, thus allowing the central controller 804 to selectively send messages to selected remote units 802 using their respective handshake keys 820. In particular, the central controller 804is configured to provide (generate / access) a third data encryption key in the form of a communications key 824 for each of the remote units 802, and to encrypt these communications keys 824 into encrypted messages for the remote units 802 in the fonn of tire second handshake messages 826. The second handshake messages 826 each contain the communications key 824 for a selected one of the remote units 802. The central controller 804 is configured to send the second handshake messages 826 to the respective remote units 802 using the first signal connections 12.

[0138] Each remote unit 802 is configured to receive its one of the second handshake messages 826, and to then decrypt its second handshake message 826 using its handshake key 820 that it stored / retained after sending tire first handshake message 822. Each remote unit 802 is configured to access its communications key 824 from the decrypted second handshake message 826, and to store / retain this communications key 824 for use in encrypting communications messages 830 to send to the central controller 804, and in decrypting communications messages 830 received from the central controller 804. The central controller 804 is configured to send blasting command instructions, e.g., representing the FIRE command, to each remote unit 802 using the communications messages 830 that are encrypted by the central controller 804 for that remote unit 802 using the communications key 824 associated with that remote unit 802. The communications key 824, used by each remote unit 802 and the central controller 804, thus establishes a form of encrypted communications channel between the central controller 804 and each respective remote unit 802 based on the corresponding communications key 824. This use of encryption between the central controller 804 and each remote unit 802 means the messages, including status messages from the remote units 802 and firing commands from the central controller 804, can be secure, and access to the operation of the access control system 800 can be safely and securely controlled, e.g., secure from unauthorised third party manipulation, e g., eavesdropping, manipulation, spoofing or other forms of “hacking7’.

[0139] In addition to the communications messages 830, which are enciypted with the communications key 824 uniquely associated with one of the remote units 802, and sent to that remote unit 802, the central controller 804 may be configured to generate, encrypt and send broadcast messages 832, which are sent to all remote units 802, e.g., substantially simultaneously. Examples of the broadcast messages 832, which are the commands sentfrom the controller 804 to all, or selected subgroups of, the remote blasters 106 and the at least one antenna system 102, simultaneously, include one or more of the CALIBRATE, CHECK, ARM, FIRST-LAST DET CHECK, SYNC & FIRE, and FIRE commands, depending on the implementation and the blast. The central controller 804 may be configured encrypt and send the broadcast message 832 with all of the plurality of the communications keys 824 respectively so that all of the plurality of the remote units 802 can decrypt and read one instance of the broadcast message 832. Alternatively, the central controller 804 may provide (gcncratc / acccss) and storc / usc a fourth data encryption key in the form of a broadcast key (not shown) that can be distributed to the plurality of the remote units 802 (at least to every’ active remote unit 802). Once all of the active remote units 802 have received the broadcast key, it allows all active remote units 802 to understand the encrypted broadcast / multicast messages 832 (encrypted with the broadcast key). The broadcast key is distributed by’ the communications messages 830, or in the second handshake message 826, so each remote unit 802 can access, read and store a copy of the broadcast key, and then use that broadcast key to decry pt the broadcast message 832. In embodiments, communications key 824 is different for each remote unit 802, therefore only the communication between central controller 804 and an individual one of the remote units 802 can be encry pted with the communications key 824, and, to send broadcast / multicast communication between the central controller 804 and the selected group (including two or more, or many, or all) of the remote units 802 at once (thus substantially simultaneously), the broadcast key is required, and the broadcast key is known / storcd / acccsscd / uscd by all of the connected remote units 802 (that are members of the blast). The broadcast key can be the second symmetric key’ generated by the central controller 804, second to the communications key’ 824, which is the first symmetric key: in other words, the central controller 804 can generate two sets of mutually separate symmetric keys: one set for the communications keys 824 (including one key for each active remote unit 802), and another set for broadcast keys (including perhaps just one key per blasting session or per group of blast initiators / detonators 816).

[0140] In summary , the access control system can provide and use at least the first three of the following four data encryption key sets: a. the configuration key pair, which is a public / private key pair (the configuration key 808 is the public key that is transported by / in the remoteregistration device 806 and the private key is kept secure in the central controller 804, stored in a secure data file system of the central controller 804), which is provided by the central controller 804 (e.g., during a configuration process, e.g., in response to a user input / command at the central controller 804), and which encrypts the first handshake message 822; b. the handshake key 820, which may be a symmetric key, which is stored in a data memory of the remote unit 802, which is provided by the remote unit 802 (e.g., during a registration process that includes registering tire remote unit 802 at the central controller 804 as an active blaster that can be used for a or the next blasting sequence), which is sent in tire first handshake message 822 from the remote unit 802 to the central controller 804 via the first signal connections 812, and which encrypts the second handshake message 826 (also referred to as the “handshake reply message”); c. the communications key 824, which may be a symmetric key, which is stored in a registr / database (also referred to as the “blaster manager”) of the central controller 804, and in the data memory of the remote unit 802, which is provided by the central controller 804 (e.g., by a router service of the central controller 804 during the registration process), which is sent in the second handshake message 826 from the central controller 804 to the remote unit 802 via the first signal connections 812, and which encrypts the communications messages 830 (including any non-broadcast / multicast messages); and d. the broadcast key, which may be a symmetric key, which is stored in the registry / database of the central controller 804, and in the data memory of the remote unit 802, which is provided by the central controller 804 (e.g., by a blasting service of the central controller 804 during a blast start process), which is sent in the second handshake message 826 or one of the communications messages 830 from the central controller 804 to the remote unit 802 via the first signal connections 812, and which encrypts the broadcast messages 832 (including any broadcast / multicast messages).

[0141] In example implementations, the configuration key pair (including the shared configuration key 808) can provide RSA encryption, the handshake key 820 can provide AES encryption, the communications key 824 can provide AES encryption, and the broadcast key can provide AES encryption. In other example implementations, the configuration key pair can provide AES encryption, or another suitable available encryption.

[0142] The configuration key 808 may be 8024 bits long, and may be used for two or more, or many, blasts. The configuration key pair need only be selectively rc-gcncratcd, c.g., at the end of a site life cycle. Hie configuration key pair may be generated using a toolbox function, c.g., an OpcnSSL toolbox function, in the central controller 804. The configuration key 808 may have a substantially greater complexity (based on bit length) than the handshake key 820, the communications key 824, and / or the broadcast key: having the communications key 824 and the broadcast key less complex than the configuration key 808 can allow for high security (as the configuration key 808 is hard to hack / break) while allowing for high system performance during the blasting operations (as enciypting / decrypting with the communications key 824 and the broadcast key is more efficient than with the configuration key pair).

[0143] The handshake key 820 may be generated by a function, e g., an OpenSSL function, on the remote unit 802. The handshake key 820 may be valid for one blasting session. In example implementations, the handshake key 820 may be 256 bits long.

[0144] The communications key 824 may be generated by an OpcnSSL function in the central controller 804. The communications key 824 may be 256 bits long and / or may be valid for one blasting session (thus the communications key 824 may have the same complexity and / or duration as the handshake key 820). Although the communications key 824 may have the same complexity and / or duration as the handshake key 820, it can be preferable to generate and use the communications key 824 for the communications messages 830 (instead of just re-using the handshake key 820) because it may be preferable to have the communications key 824 — which is the key used for most of the encrypted communication in the access control system 800 — provided by the central controller 804 rather than by the individual remote units 802, e.g., because there may be better security, monitoring and control of the central controller 804 than the individual remote units 802.

[0145] The broadcast key may be generated by an OpenSSL function in the central controller 804. The broadcast key may be 256 bits long and / or may be valid for one blasting session (thus the broadcast key may have the same complexity and / or duration as the handshake key 820 and / or the communications key 824).

[0146] The messages between the central controller 804 and each remote unit 802 include the encrypted communications messages 830 and / or the broadcast messages 832. The messages between the central controller 804 and each remote unit 802 may also include unencrypted messages, e.g., messages not related to safety', e.g., messages representing signal strength requests from the central controller 804 and / or representing signal strength answers from the remote units 802.

[0147] The access control system described herein allows the remote units 802 to securely and reliably register at the central controller 804, and to establish secure communications (by way of the encrypted messages 830,832) without the need to share any physical key / dongle each time the remote unit 802 is switched on for blasting, or for each remote unit 802 to have a physical dongle transferred from its remote location to a secure / central location of the central controller 804; once the configuration key 808 has been transferred to each remote unit 802 during commissioning (in a commissioning process), the remote units 802 and the central controller 804 share the digital public and symmetric keys for a plurality of blasting sessions instead of having to carry / transport a physical dongle for each blasting session as in prior systems. After commissioning, each remote unit 802 and the central controller 804 share the asymmetric key pair of the configuration key 808, consisting of the public key (existing on every remote unit 802) and the private key (located on the central controller 804): on powcr-on, each remote unit 802 provides the handshake key 820, which is sent, encrypted by the configuration key 808, to the central controller 804, which in turn decrypts it by means of the asymmetric private key (which is the private key corresponding to the configuration key 808). After this decryption of the first handshake message 822 to obtain the handshake key 820, the asymmetric key (of the configuration key 808) is no longer used for this particular blasting session, and instead the communications key 824 is used for the blasting session.

[0148] Technical advantages of the access control system described herein may include that a physical dongle / key only is required at first commissioning of the dual blasting system 100 or the synchronized blasting system 200: once the remote units 802 are registered at tire central controller 804, substantial messages / communication between the central controller 804 and the remote units 802 is securely encrypted; e.g., in contrast to the system of US 6851369 that requires a separate dongle to be physically transported from each remote unit 802, thus requiring many dongles to be physically collected, carried and separately connected to its central controller for each blasting session. Unlike the system of US 6851369, the access control system described herein may allow for up to many, e.g., up to several thousands, of the remote units 802 to securely connect to the central controller 804, and connecting such a large number of remote blasters using prior technology may have been impractical or undesirable.

[0149] For improved security, the remote registration device 806 can only be created / written by a person authenticated as a system administrator by way of a usemame / password combination provided to the central controller 804 by its secure user interface (UI). Specifically, the central controller 804 is configured to only allow writing of the configuration key 808 to the remote registration device 806 and / or directly to the remote units 802 (depending on the implementation) after successful authentication of the usemame / password combination of the system administrator in the central controller 804 by its secure user interface (UI).

[0150] In addition to the configuration key 808, the remote registration device 806 may carry / include system connection information representing a network location identifier (ID) of the central controller 804 in the data network that defines the first signal connections 812. The system connection information may include a static internet protocol (IP) address and / or a network port number of the central controller 804 on the data network. Each remote unit 802 can be configured to read this system connection information from the remote registration device 806, and to use this system connection information to address / direct at least the first handshake message 822, and optionally the communications messages 830, to the central controller 804. Each remote unit 802 can also be configured to recognize the communications messages 830 and / or broadcast messages 832 from the central controller 804 based on this system connection information.

[0151] The remote units 802 are configured to encode and send their remote network locations IDs to the central controller 804 in the encrypted first handshake message 822 and / or in the communications messages 830, and the central controller 804 is configured to decrypt the respective remote location IDs and store them associated with the identifiers of the remote units 802, e.g., in the blaster manager. For example, the remote network location ID may include an IP address and / or a network port number respectively of each remote unit 802 on the data network. The network connections of the remote units 802 define remote ends of the first signal connections 812, and the network connection of the central controller 804 defines the other ends of the first signal connections 12. The central controller 804 uses the remote location IDs to addrcss / dircct at least the second handshake message 826 (“handshake reply”), and optionally the communications messages 830, to the selected ones of the remote units 802. The remote units 802 are configured to send additional characteristic information of the remote unit 802 to the central controller 804 in the encrypted first handshake message 822 and / or in the communications messages 830, including one or more of: interface information, a blaster ID of the remote unit 802, identification of loggers attached to the remote unit 802, identification of the blast initiators / detonators 816 connected to the remote unit 802, and other registration data described hereinafter. During operation, the communications messages 830 may carry the following from the remote units 802 to the central controller 804: detonator / initiator information, including delay times, measured vibration data, and / or firing flags.

[0152] Tn summary, the encrypted messages generated, transmitted (via the first signal connections 812) and used by the access control system include: a. the first handshake message 822 (also referred to as the “handshake command” or “handshake CMD”), which is transmitted from each remote unit 802 to the central controller 804, which is encrypted by the configuration key 808 (e g., using RSA encryption), and which is used to provide initial contact / registration of each remote unit 802 in the access control system 800, and to provide the handshake key 820 (a symmetric key) to the central controller 804 (for use in encrypting the second handshake message 826);b. the second handshake message 826 (also referred to as the “handshake reply”), which is transmitted from the central controller 804 to each remote unit 802, which is encrypted by the handshake key 820 (e.g., using AES encryption), and which is used to send the communications key 824 to each remote unit 802 (for use in encrypting the communications messages 830 to the central controller 804); c. the communications messages 830 from each remote unit 802 to the central controller 804, which are encrypted by the communications key 824 (e.g., using AES encryption), and which can include a register-blaster command that provides registration data of the remote unit 802, including one or more of: a unique local blaster ID, a local password, a blaster serial number, a blaster Alias, blaster remote interface address information, and the remote network locations IDs; d. the communications messages 830 from the central controller 804 to each remote unit 802, which are encrypted by the communications key 824 (e.g., using AES encryption), and which can include: a register-blaster reply that confirms registration of each remote unit 802 after processing of a corresponding the register-blaster command (correspondingly from each remote unit 802), and / or provides a temporary blaster ID to each remote unit 802; and e. the broadcast messages 832 from the central controller 804 to each remote unit 802, which arc encrypted by the broadcast key (e.g., using AES encryption), and which can include multicast or broadcast blasting commands.

[0153] As shown in FIG. 8, the access control system includes a further physical dongle, in addition to the remote registration device 806, in the form of the blasting dongle 124 (also referred to as the “blasting-dongle” or "firing dongle"). The central controller 804 is configured to only allow the blasting command instructions (representing the blasting commands and / or firing commands) to be sent in the messages 830,832 when the blasting dongle 124 is physically coupled, or at least communicatively connected with, the centralcontroller 804. The blasting dongle 124 is registered by the central controller 804. The UI asks to insert the blasting dongle 124, and registration of the blasting dongle 124 is performed in a back end of the central controller 804 in a dongle service. In most blasting operations, only one blasting dongle 124 is valid as a time, and if a new blasting dongle 124 is registered, any previous firing dongles 834 become invalid. Each remote blaster will only relay firing codes to the blast initiators / detonators 16 when in receipt of appropriate command(s) and data package(s) from the central controller 804 that can only be generated when the blasting dongle 124 is connected.

[0154] As explained hereinbefore, the central controller 804 is configured to: a. provide (randomly generate or receive / access) the communications key 824, which can be the first symmetric encryption key, and the broadcast key, which can be the second symmetric encryption key; b. transmit the communications key 824 to the remote units 802 using a first secure channel provided by the handshake key 820 and the first signal connections 812; c. establish a second secure channel using the communications key 824 and / or the broadcast key (the second secure channel is not equal to the second signal connection because the second signal channel refers to communication on the first signal connection between the controller 804 and the remote units 802); and d. transmit commands / requests (e g., status requests, and / or multicast or broadcast blasting commands, e.g., a D1SARM / D1SABLE command or a FIRE command) to two or more of the remote units 802 via the second secure channel.

[0155] In use, the central controller 804 provides the configuration key 808 and the communications key 824, and optionally the broadcast key. The communications key 824 may be a static key that does not change after a blasting session is completed, or a dynamic random key that can be generated by the central controller 804 for every blasting session.The dynamic generation of a new communications key 824, and optionally a new broadcast key, may be triggered by a registration of a new one of the remote units 802 with the central controller 804.

[0156] Tn use, on commissioning of the dual blasting system 100 and / or the synchronized blasting system 200 on the site, each remote unit 802 requires configuration using the central controller 804, which provides the configuration key 808 (including the public key) to each remote unit 802. The central controller 804 has the secure communications interface to transmit the configuration key 808: (a) directly to the remote registration device 806 in some implementations, or (b) directly to the corresponding secure communications interface of each remote unit 802, in other implementations. Tire central controller 804 generates the public-private key pair for the remote registration device 806, and stores the public key in the form of the configuration key 808 on the physical remote registration device 806. The individual / unique physical remote registration device 806 is taken by a human operator and / or a remote / autonomous vehicle to each remote unit 802 on the site. Each remote unit 802 reads the configuration key (public key) and the connection information (described hereinbefore) from the remote registration device 806. Each remote unit 802 generates the unique remote symmetric key in the form of the handshake key 820, which uniquely corresponds to the remote unit 802, during the registration process. This handshake key 820 is encrypted by the remote unit 802 using the configuration key 808 (public key) from the remote registration device 806. The encrypted handshake key 820 (symmetric key) is then used for a handshake process between the remote unit 802 and the central controller 804. The central controller 804 decrypts the handshake key 820 using its private key and uses the handshake key 820 to encrypt its own symmetric key in the form of the communications key 824 for further communication with the remote unit 802. Further communication between the central controller 804 and the remote units 802 use the communications key 824 (symmetric keys) for encryption.

[0157] The communications key 824 may be stored in the central controller 804, e.g., in a service provided by the central controller 804 (e.g., a Docker (TM) service), depending on structural design of the central controller 804. Structurally, the central controller 804 may include a front end, including a web user interface, and the back end, which includes various services, and between the services and the front end there are included communicationapplication programming interfaces (APIs). In example implementations, the central controller 804 may include a single-board computer, e.g., a BeagleBone (TM) computer, and the services may include the blasting service, the blasting manager, tire dongle sendee, the UI, the router sendee, a proxy service and / or an LED senice.

[0158] The first signal connections 812 may include one or more communications connections in series and / or parallel between the remote unit 802 and the central controller 804, e.g., communications connections including: a local area network (LAN), a wireless LAN (WLAN, e.g., WiFi), an LTE communications link, a Radio Frequency (RF) communications link, an analogue telephone line, and / or a leaky feeder network (e.g., using commercially available RF modems) The communications connections may form part of existing mine communications infrastructure, thus the communications connections may be used for communications between other on-site equipment, e.g., fortelephony / data communications, at the same time as being used for the first signal connections 12 because the first signal connections 812 are secured by the encryption and thus not accessible / readable / writable by any of the other on-site equipment.

[0159] The second signal connections 814 may include wired connections from the remote unit 802 to its loggers and / or blast initiators / detonators 816, e.g., using a blasting cable or harness, or the second signal connections 814 may include a wireless connection from the remote unit 802 to the blast initiators / detonators 816, e.g., using through-the-earth (TTE) magnetic induction (MT) signalling from the remote unit 802 to the blast initiators / detonators 816, e.g., as used in Orica’s WcbGcn 200 (TM) wireless electronic blasting system. The second signal connections 814 may include a blasting cable connection to tire one or more loggers if loggers arc present, and harness wire connection from the loggers to the initiators / detonators 816.

[0160] The blast initiators / detonators 816 may include wireless electronic detonators or initiators, e.g., Orica’s i-kon detonators, eDev (TM) detonators, and / or Orica’s WebGen 200 (TM) initiators.

[0161] The central controller 804 may communicate with the remote registration device 806, when it is connected to the port 810, using the dongle service, e.g., running in a container onthe central controller 804. The central controller 804 may include additional services in respective containers, e.g., user interface (UI) services, blasting services (to control the blasting sequence), and blast manager services, as described hereinbefore.

[0162] The secure first signal connections 812 are used for two-way communications between the remote units 802 and the central controller 804 so the central controller 804 can monitor status of the remote units 802, and thus the connected initiators, during a programming sequence. The status may include: an active status, a no-reply status, an inactive status, and / or an errors status.

[0163] Tire remote registration device 806 includes tire device-based secure communications interface, which can include one or more of a One Wire Bus, a Universal Serial Bus (USB) interface, a Secure Digital (SD) interface, radio-frequency identification (RFID) interface, Bluetooth (TM) interface, or Bluetooth Low Energy interface, as described hereinbefore, providing an interface to communicatively connect to the ports 810,818), integrated with the machine-readable memory providing electronic non-volatile computer memory storage, e.g., flash memory'. The remote registration device 806 may thus take the form of a USB dongle, USB “stick” or “thumb drive”, as described hereinbefore.

[0164] The remote unit 802 may include a waterproof / water resistant housing that protects the electronic components of the remote unit 802 from water in the site, e.g., with an ingress protection (TP) rating of 54 or more, or 67 or more. The electronic components include a power source (e.g., internal battery and / or external power connection), modules for wired / wireless communications (e g., WiFi, Bluetooth, Ethernet, cellular chips) via the first signal connection, a microprocessor, machinc-rcadablc memory’ that stores commands for the microprocessor, a port or MI antenna for the second signal connections 814, and tire port 818 for connection of the remote registration device 806 (e.g., a physical data carrier interface, which may include a USB port, 1-wire port, proprietary dongle port, SD-card slot).

[0165] The central controller 804 may include a power source (e.g., external power source), modules for wired / wireless communications (e.g., WiFi, Ethernet, cellular chips) via the first signal connection, a microprocessor, machine-readable memory that stores commands for the microprocessor (including an operating system and a user interface), and the port 810 forconnection of the remote registration device 806 (e.g., a physical data carrier interface, which may include a USB port, 1-wire port, proprietary dongle port, SD-card slot). The central controller 804 includes the port for connection of the blasting dongle 124 (e.g., a physical data carrier interface, which may include a USB port, 1-wire port, proprietary dongle port, SD-card slot).

[0166] The blasting commands include ARM, FIRE, or DISARM commands. The FIRE command is the same for all of the blast initiators / dctonators 816, it also docs not include the delay information, which is programmed by the loggers / blaster at an earlier programming time. Each of the blast initiators / dctonators 816 has a device ID which is read by the logger / scanner during blast preparation. Hie device ID is associated with the delay time. At blasting, each of the blast imtiators / detonators 816 gets programmed with its assigned delay time, addressed by the device ID, from a blasting plan. After sequentially programming each of the blast initiators / detonators 816, the blast gets armed (by sending an ARM command) and then fired (by sending a FIRE command). The ARM and FIRE command are broadcast commands in the broadcast messages 832 to all of the blast initiators / detonators 816 in the blast.

[0167] As shown in FIG. 9, the access control system 800 is configured to perform a method 900, which includes: a. the central controller 804 generating the configuration key pair and the communications key 824 for each blasting session (902); b. the central controller 804 writing the configuration key 808 (and the system connection information) to the remote registration device 806 whilst it is communicatively connected to the port 810 (904) — or in other implementations, writing the configuration key 808 directly from the central controller 804 to each of the remote units 802 individually or in turn by the secure communications connections described hereinbefore, c. the remote registration device 806 physically being transported, and thus transporting the configuration key 808 to each remote unit 802 (906) — or in other implementations, each of the remote units 802 receiving theconfiguration key 808 directly from the central controller 804 instead of via the remote registration device 806; d. each remote unit 802 generating the handshake key 820 in the registration process (908); e. each remote unit 802 reading the configuration key 808 (and the system connection information) from the remote registration device 806 whilst it is communicatively connected to the port 818 ( 10); f. each remote unit 802 encoding the handshake key 820 using the configuration key 808 to generate the first handshake message 822 (912); g. each remote unit 802 sending the first handshake message 822 to the central controller 804 via the first signal connections 812 (914); h. the central controller 804 decry pting the first handshake message 822 using the configuration key 808 to access the handshake key 820 (916); i. the central controller 804 encrypting the communications key 824 using the handshake key 820 to generate the second handshake message 826 (also referred to as the “handshake reply”) (918); j. the central controller 804 sending the second handshake message 826 to each remote unit 802 via the first signal connections 812 (920); k. each remote unit 802 receiving and decrypting the second handshake message 826 using the handshake key 820 to access the communications key 824 (922); l. each remote unit 802 encrypting information for the central controller 804 using the communications key 824 and sending these communications messages 830 to the central controller 804 via the first signal connections 812 (924);m. the central controller 804 receiving and decrypting the communications messages 830 from each remote unit 802 using the communications key 824 to access the information from each remote unit 802 (926); n. the central controller 804 encrypting information for each remote unit 802 using the communications key 824 and sending these communications messages 830 to each remote unit 802 via the first signal connections 812 (928); o. each remote unit 802 receiving and decrypting the communications messages 830 from the central controller 804 using the communications key 824 to access the information from the central controller 804 (930); p. the central controller 804 encrypting broadcast information for the plurality of remote units 802 using the broadcast key and sending these communications messages 830 to the plurality of remote units 802 via the first signal connections 812 (932); and q. the plurality of remote units 802 receiving and decrypting the broadcast messages 832 from the central controller 804 using the broadcast key to access the broadcast information from the central controller 804 (934).Interpretation

[0168] The tenn “antenna” used herein refers to an aerial, i.e., a transducer configured to convert between electromagnetic waves and corresponding electrical voltages / currents.

[0169] The term “initiation” refers to the initiation or triggering of combustion, a deflagration, a deflagration to detonation transition (DDT), or detonation in a material or substance carrying an explosive composition, and the associated formation of different chemical species, or the initiation of chemical reactions that result in combustion and the associated formation of different chemical species in the material or substance. The term “explosive initiation” refers to initiation giving rise to an explosion or detonation, theoccurrence of which corresponds to or is defined by at least some of a rapid energy release, volume increase, temperature increase, and gas production or release, as well as the generation of at least a subsonic shock wave. Tire term “detonation” refers to tire generation of a supersonic detonation wave or shock front in an explosive material or substance, in a maimer understood by individuals having ordinary skill in the relevant art.

[0170] The term “commercial blasting operation” includes the initiation and / or detonation of explosive materials or substances disposed in the physical media, c.g., a geological formation, by way of initiation devices as part of mining, quarrying, civil construction / demolition, seismic exploration, and / or another non-military blasting operation. Such initiation and / or detonation explosively blasts, e.g., fractures and / or heaves, or the physical media in which the commercial blasting operation occurs. Such initiation and / or detonation can be referred to as blasting, in a manner readily understood by individuals having ordinary skill in the relevant art. The physical media in which the commercial blasting operation occurs is located in a commercial blasting environment, such as a mining environment, e.g., an open cut or underground mine.

[0171] As used herein, the term “set” corresponds to or is defined as a non-empty finite organization of elements that mathematically exhibits a cardinality of at least 1 (i.e ., a set as defined herein can correspond to a unit, singlet, or single element set, or a multiple element set), in accordance with known mathematical definitions (for instance, in a manner corresponding to that described in An Introduction to Mathematical Reasoning: Numbers, Sets, and Functions, "Chapter 11 : Properties of Finite Sets" (c.g., as indicated on p. 140), by Peter J. Eccles, Cambridge University Press (1998)). Thus, a set includes at least one element. In general, an clement of a set can include or be one or more portions of a system, an apparatus, a device, a structure, an object, a process, a procedure, physical parameter, or a value depending upon the type of set under consideration.

[0172] The FIGs. included herewith show aspects of non-limiting representative embodiments in accordance with the present disclosure, and particular structural elements shown in the FIGs. may not be shown to scale or precisely to scale relative to each other. The depiction of a given element or consideration or use of a particular element number in a particular FIG. or a reference thereto in corresponding descriptive material can encompassthe same, an equivalent, an analogous, categorically analogous, or similar element or element number identified in another FIG. or descriptive material associated therewith. The presence a FIG. or text herein is understood to mean "and / or" unless otherwise indicated, i.e., “A / B” is understood to mean “A” or “B” or “A and B”. The recitation of a particular numerical value or value range herein is understood to include or be a recitation of an approximate numerical value or value range, for instance, within + / - 20%, + / - 15%, + / - 10%, + / - 5%, + / - 2.5%, + / - 2%, + / - 1 %, + / - 0.5%, or + / - 0%. The temi "essentially all" or "substantially" can indicate a percentage greater than or equal to 50%, 60%, 70%, 80%, or 90%, for instance, 92.5%, 95%, 97.5%, 99%, or 100%.

[0173] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention. Reference to one or more embodiments herein, e.g., as various embodiments, many embodiments, several embodiments, multiple embodiments, some embodiments, certain embodiments, particular embodiments, specific embodiments, or a number of embodiments, need not or does not mean or imply all embodiments.

[0174] Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

[0175] The process of encrypting described herein may also be referred to as “encoding”, and correspondingly the process of decrypting described herein may also be referred to as “decoding”.

Claims

CLAIMS1. A commercial blasting system including: a central controller configured to send blasting command instructions for two or more electronic blasting devices, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; at least one remote blaster connectable to the central controller and configured to receive the blasting command instructions for tire EBS device, and configured to send at least one corresponding blasting command to the EBS device via wires / cables; and at least one antenna system connectable to the central controller and configured to receive the blasting command instructions for the WEB device, and configured to send at least one corresponding blasting command to the WEB device via magnetic induction (MI) signals, wherein the remote blaster is configured to send one or more handshake messages to the controller indicating that the EBS device is programmed for the blast for the controller to synchronize sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

2. The system of claim 1, wherein the central controller is configured to provide a WEB state machine and an EBS state machine, and to synchronize the WEB state machine with the EBS state machine based on the handshake messages.

3. The system of claim 1 or 2, wherein the central controller is configured to send a MI FIRE command instruction and an EBS FIRE command instruction separated by a predetermined interval.

4. The system of claim 3, wherein at least one of the remote blasters and the antenna system are phy sically one combined device and the predetermined interval is used by the combined device to send the MI FIRE command instruction and the EBS FIRE command instruction.

5. The system of any one of claims 1 to 4, wherein the central controller is configured to receive any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send tire blasting command instructions.

6. The system of any one of claims 1 to 5, wherein the central controller and the antenna system are connected by a two-way data interface to provide handshake messages to the controller from the antenna system.

7. A commercial blasting system including: a central controller configured to send blasting command instructions to two or more electronic blasting devices in a blast according to a blasting plan, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; at least one remote blaster connectable to the central controller and configured to receive the blasting command instructions for the EBS device, and configured to send at least one blasting command to the EBS device via wires / cables based on the blasting command instructions: at least one antenna system connectable to the central controller and configured to receive the blasting command instructions for the WEB device, and configured to send at least one blasting command to the WEB device via magnetic induction (MI) signals based on the blasting command instructions; and at least one MI synchronization device configured to receive the blasting command via the Ml signals, and connectable to the or each remote blaster to send sync signals representing the blasting command for the WEB device to synchronize firing of the EBS device and the WEB device.

8. The system of claim 7, wherein the MI synchronization device is configured to perform any one or more of the following: on receipt of an MI sequence, responsively send an MI signal-to-noise (SNR) signal for the remote blaster and / or central controller;on receipt of an MI SYNC command, responsively send a prepare-to-fire command instruction for the remote blaster, wherein the prepare-to-fire command is sent to the remote blaster at a predetermined time after receipt of tire MI SYNC command; and on receipt of an MT FIRE command, responsively send a FIRE command instruction for the remote blaster to fire the EBS device.

9. The system of claim 7 or 8, wherein the remote blaster is configured to send handshake messages to the controller indicating that the EBS device is programmed for the blast for the controller to synchronize sending a FIRE command for the EBS device with sending a FIRE command for the WEB device10. Tire system of any one of claims 7 to 9, wherein tire central controller is configured to provide a WEB state machine and an EBS state machine, and to synchronize the WEB state machine with the EBS state machine based on the handshake messages.

11. The system of any one of claims 7 to 10, wherein the central controller is configured to receive any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send the blasting command instructions.

12. The system of any one of claims 7 to 11, wherein the MI synchronization device includes a magnetometer configured to generate an electronic / electrical output representing the received blasting command.

13. The system of claim 12, wherein the magnetometer includes at least one MI antenna and corresponding receiver.

14. Tire system of any one of claims 7 to 13, wherein the MI synchronization device includes a communication interface for connection to the remote blaster.

15. The system of any one of claims 1 to 14, further including: a physical remote registration device configured to communicative Iv connect to the central controller and to the at least one remote blaster and / or the at least one antenna system,wherein the central controller is configured to provide a public-private asymmetric encryption key pair with a public key and a private key, and to write the public key to the remote registration device when the remote registration device is communicatively connected to the controller, wherein each of the at least one remote blaster and / or the at least one antenna system is configured to read the public key from the remote registration device when the remote registration device is communicatively connected to the corresponding remote blaster or antenna system, wherein the central controller and each of the at least one remote blaster and / or the at least one antenna system are configured to communicate with each other via a data network using the key pair.

16. The system of claim 15, wherein each remote blaster and / or each antenna system is configured to provide a handshake encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the handshake encryption key to the central controller using the public key and the data network.

17. The system of claim 16, wherein the central controller is configured to provide a communications encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the communications encryption key in a second handshake message to each remote blaster and / or each antenna system using the handshake key and tire data network.

18. Tire system of claim 17, wherein the central controller and each of the at least one remote blaster and / or the at least one antenna system are configured to communicate with each other using the communications encryption key and the data network.

19. The system of any one of claims 16 to 18, wherein the central controller is configured to provide a broadcast encryption key that is not unique / quasi-unique to each remote blaster or antenna system, and to send the broadcast encryption key to each remote blaster and / or each antenna system using the data network.

20. The system of claim 19, wherein the central controller is configured to encrypt and send blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption kcv and the data network.21 . The system of any one of claims 1 to 14: wherein the central controller has a secure communications interface, wherein each remote blaster and / or each antenna system has a secure communications interface corresponding to the secure communications interface of the central controller, wherein the central controller is configured to provide a public-private asymmetric encryption key pair with a public key and a private key, and to write the public key individually to each remote blaster and / or each antenna system when each remote blaster and / or each antenna system is respectively connected via the secure communications interfaces, wherein each remote blaster and / or each antenna system configured to read the public key from the central controller when connected via the secure communications interfaces, and wherein the central controller and each of the at least one remote blaster and / or the at least one antenna system are configured to communicate with each other via a data network using the key pair.

22. The system of claim 21, wherein each remote blaster and / or each antenna system is configured to provide a handshake encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the handshake encryption key to the central controller using the public key and the data network.

23. The system of claim 22, wherein the central controller is configured to provide a communications encry ption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and to encrypt and send the communications encryption key in a secondhandshake message to each remote blaster and / or each antenna system using the handshake key and the data network.

24. The system of claim 23, wherein the central controller and each remote blaster and / or each antenna system are configured communicate with each other using the communications encryption key and the data network.

25. The system of any one of claims 21 to 24, wherein the central controller is configured to provide a broadcast encryption key that is not unique / quasi-unique to each remote blaster and / or each antenna system, and to send the broadcast encryption key to each remote blaster and / or each antenna system using the data network.

26. Tire system of claim 25, wherein the central controller is configured to encrypt and send blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption key and the data network.

27. A commercial blasting method including: sending blasting command instructions for two or more electronic blasting devices, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; receiving the blasting command instructions for tire EBS device, and sending at least one corresponding blasting command to the EBS device via wircs / cablcs; receiving the blasting command instructions for the WEB device, and configured to send at least one corresponding blasting command to the WEB device via magnetic induction (Ml) signals; sending one or more handshake messages indicating that the EBS device is programmed, and synchronizing sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

28. The method of claim 27, including synchronizing a WEB state machine with an EBS state machine based on the handshake messages.

29. The method of claim 27 or 28, including sending a MI FIRE command instruction and an EBS FIRE command instruction separated by a predetermined interval30. Tire method of claim 29, including sending the MT FIRE command instruction and the EBS FIRE command instruction from a unitary device.

31. The method of any one of claims 27 to 30, including receiving any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send the blasting command instructions.

32. The method of any one of claims 27 to 31, including sending handshake messages in response to the blasting command instructions for the WEB device.

33. A commercial blasting method including: sending blasting command instructions to two or more electronic blasting devices in a blast according to a blasting plan, wherein the two or more electronic blasting devices include at least one wireless electronic blasting (WEB) device and at least one wired electronic blasting system (EBS) device; receiving the blasting command instructions for the EBS device; sending at least one blasting command to the EBS device via wires / cables based on the blasting command instructions; receiving the blasting command instructions for the WEB device; sending at least one blasting command to the WEB device via magnetic induction (MI) signals based on the blasting command instructions; receiving the blasting command via the MI signals; and sending sync signals based on the blasting command received via the MI signals in order to synchronize firing of the EBS device and the WEB device.

34. The method of claim 33, including any one or more of the following: sending an MI signal-to-noise (SNR) signal after receipt of an MI sequence: sending a prepare-to-fire command at a predetermined time after receipt of an MI SYNC command: and sending a FIRE command fire to the EBS device after receipt of an MI FIRE command.

35. The method of claim 33 or 34, including sending handshake messages indicating that the EBS device is programmed for the blast in order to synchronize sending a FIRE command for the EBS device with sending a FIRE command for the WEB device.

36. The method of any one of claims 33 to 35, including synchronizing a WEB state machine with an EBS state machine based on the handshake messages.

37. The method of any one of claims 33 to 36, including receiving any one or more of a beacon clearance confirmation, a blasting dongle, and a blast file key in order to send the blasting command instructions.

38. The method of any one of claims 33 to 37, including generating an electronic / electrical output representing the blasting command received via the MI signals.

39. The method of claim 38, including generating the clcctronic / clcctrical output using at least one MI antenna and corresponding receiver.

40. Tire method of any one of claims 33 to 39, including sending the sync signals via a communication interface to a remote blaster.

41. The method of any one of claims 27 to 40, including: the central controller of the electronic blasting system providing a public-private asymmetric encryption key pair with a public key and a private key; the central controller communicatively connecting to a physical remote registration device to write the public key to the remote registration device;each remote blaster and / or each antenna system separately communicatively connecting to the remote registration device to each separately read the public key; and each remote blaster and / or each antenna system communicating with the central controller via a data network using the public key.

42. The method of claim 41, including each remote blaster and / or each antenna system providing a handshake encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the handshake encryption key to the central controller using tire public key and the data network.

43. Tire method of claim 42, including the central controller providing a communications encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the communications encryption key in a second handshake message to each remote blaster and / or each antenna system using the handshake key and the data network.

44. The method of claim 43, including the central controller and each remote blaster and / or each antenna system communicating with each other using the communications encryption key and the data network.

45. The method of any one of claims 41 to 44, including the central controller providing a broadcast encryption key that is not unique / quasi-unique to each remote blaster and / or each antenna system, and sending the broadcast encryption key to each remote blaster and / or each antenna system using the data network.

46. The method of claim 45, including the central controller encry pting and sending blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption key and the data network.

47. The method of any one of claims 27 to 40, including: the central controller providing a public-private asymmetric encry ption key pair with a public key and a private key;the central controller communicatively connecting to each remote blaster and / or each antenna system via respective secure communications interfaces to separately provide the public key to each remote blaster and / or each antenna system; and each remote blaster and / or each antenna system respectively communicating with the central controller via a data network using the public key.

48. The method of claim 47, including each remote blaster and / or each antenna system providing a handshake encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the handshake encryption key to the central controller using the public key and the data network.

49. Tire method of claim 48, including the central controller providing a communications encryption key that is unique / quasi-unique to each remote blaster and / or each antenna system, and encrypting and sending the communications encryption key in a second handshake message to each remote blaster and / or each antenna system using the handshake key and the data network.

50. The method of claim 49, including the central controller and each remote blaster and / or each antenna system communicating with each other using the communications encryption key and the data network.

51. The method of any one of claims 47 to 50, including the central controller providing a broadcast encryption key that is not unique / quasi-unique to each remote blaster and / or each antenna system, and sending the broadcast encryption key to each remote blaster and / or each antenna system using the data network.

52. The method of claim 51, including the central controller encry pting and sending blasting command instructions to each remote blaster and / or each antenna system using the broadcast encryption key and the data network.

Images