Drill and Blast Management Software: Why Nobody Can Explain the Oversize From Blast 214

Why the blast that caused the problem cannot be found

The crusher was choked twice on Tuesday with oversize, the excavator operators are complaining that the north face is digging hard, and the mill is running below throughput. Somebody asks the obvious question: which blast did this come from, and what was different about it. Getting an answer takes four days. The design is a file in the blast design package on the technical services drive. The as drilled depths are in a spreadsheet the drill contractor emailed, and it has 12 holes marked as redrill with no explanation. What was actually loaded is on a paper loading sheet in a folder in the shot firer's ute, and it shows five holes with the deck heights crossed out and rewritten in a different pen. The vibration data is a PDF from the monitoring contractor and the fragmentation photos are on somebody's phone.

That is the entire problem in this category. Drill and blast is a controlled experiment run two or three times a week, and almost nobody records the experiment well enough to learn from it. You have design intent, actual execution and downstream outcome, and the three are never in the same place, so the feedback loop that would improve powder factor, burden and spacing never closes. Instead the improvement loop is a superintendent's judgement, which is genuinely valuable and completely unauditable, and which leaves the site when he does.

The cost of that gap sits downstream, not in the blast budget. Poor fragmentation shows up as slower dig rates, more secondary breakage, higher crusher power draw and lost mill throughput. Ore loss and dilution at the contact shows up as grade that never reaches the plant. Neither of those hits the drill and blast cost centre, which is exactly why they persist: the department being measured on cost per tonne drilled has no incentive to spend more on explosives to save the mill money it never sees. A blast record that carries through to outcome is what makes that argument winnable internally, and that is usually the real reason to build.

Problem 1: as drilled is not as designed, and nobody records the difference

The design says 89 holes at 115mm on a 3.2 by 3.7 pattern, 8.5 metres deep with 2.6 metres of stemming. Reality is a hole that hit a void at 6 metres, three holes collapsed overnight after rain, two redrilled 400mm off pattern because the rig could not track over a boulder, and four holes wet enough to need an emulsion rather than the planned ANFO. Every one of those changes the energy distribution in the rock, and every one of them is written on paper.

Maptek BlastLogic is genuinely strong at exactly this problem: design to as drilled quality control is what it was built for, and if you are a single large mine willing to run that workflow, it works. Where sites hit friction is when the drill rigs are a mixed fleet with high precision navigation on two rigs and nothing on the rest, when a contractor drills half the pattern, or when the same crew works four quarries with different practices. The build must include a hole level record with designed and actual collar position, actual depth, water status, ground condition notes and a redrill link back to the original hole, captured by the driller on a tablet at the rig, not typed by a graduate three days later, and offline first, because your patterns sit in a pit with no coverage.

Problem 2: explosives are ordered, delivered, loaded and returned, and only three of those get written down

A truck delivers product, the shot firer loads the pattern, some product goes back, and the invoice arrives at month end. Almost nobody reconciles what was invoiced against what physically went into the ground. In the United States, federal explosives regulation requires licensed users to keep records of receipt, use and inventory of explosive materials, and magazine records are inspected. Your jurisdiction will have its own equivalent, and you should confirm the specifics with a compliance specialist rather than a software vendor.

Supplier platforms handle their own product well. Orica BlastIQ is a serious system and if you are an Orica site running their products and initiation systems it gives you real design to outcome capability. The honest limitation is structural rather than technical: a supplier platform is built around that supplier's products, and it will never be the neutral system of record for a group that runs Orica at one site, a competitor at another, and buys packaged product for a third.

What a custom build must include is product agnostic consumption at hole level, decked where you deck, so that actual kilograms of each product per hole roll up to a pattern powder factor and down to an invoice line. Then explosives cost per bank cubic metre is a real number, per pattern, per site, and the month end argument with the supplier ends because you have the loading record.

Problem 3: neighbours complain, and your defence is a PDF from a contractor

A quarry within earshot of housing gets vibration and airblast complaints, and some of them arrive on days you did not blast. The scaled distance approach and the vibration criteria from United States Bureau of Mines work are the common reference for surface blasting limits, and your regulator will have its own thresholds. What you need on a complaint call is not a research paper, it is the ability to say, within a minute, that the blast fired at 11:04, that peak particle velocity at the nearest monitor was measured and recorded, and that the design charge weight per delay was within the approved limit.

The build ties monitor readings automatically to the blast that caused them, holds the complaint as a record with the caller, time and response, and produces the compliance pack a regulator asks for without a week of assembly. It should also flag the pattern in advance: this design exceeds your maximum instantaneous charge for the nearest sensitive receiver, adjust the timing or the deck before it fires. That check is worth more than any report written afterwards.

Problem 4: the outcome never gets attached to the blast that caused it

Fragmentation photos are taken sometimes. Dig rate lives in the fleet management system. Crusher throughput and power draw live in the plant historian. None of them carries a blast identifier, so the correlation you want cannot be computed even in principle.

The fix is unglamorous and decisive: every downstream measurement gets stamped with the blast it came from. That means the muckpile has a blast id, the trucks loading from it inherit it, and the crusher feed window inherits it too. Once that link exists, image based fragmentation analysis becomes genuinely useful rather than a curiosity, because a P80 estimate finally has a design, a powder factor and a rock domain attached to it. This is also the one place where machine learning is worth funding in drill and blast: with a few hundred blasts of clean linked records, a model over design parameters, measure while drilling data and rock domain gives a usable prediction of fragmentation and dig rate. Without linked records it gives you nothing.

Problem 5: measure while drilling data is collected and then ignored

Modern rigs record penetration rate, rotation pressure, feed pressure and other channels per hole. That data is a free geotechnical survey of every pattern you drill, and at most sites it sits on the rig or in an OEM portal untouched. Joined to the hole record, it gives you hardness proxies that let you vary charge by hole rather than by pattern, and it flags voids and soft zones before loading.

Nobody is going to hand you this joined up. Rig vendors expose their own data in their own format, and the join is site specific because your hole naming convention is yours. That is precisely why this ends up as a custom build: the value is in the join, and the join is the part no vendor ships generically.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A single blast record system, meaning design import, tablet based as drilled capture at the rig, product agnostic loading capture, and one blast page that shows design, actual and outcome side by side, runs $60,000 to $140,000 and ships in 10 to 16 weeks. A full platform adding explosives inventory and reconciliation, vibration and complaint management, fragmentation analysis, measure while drilling ingestion and multi site rollups runs $160,000 to $400,000 phased over 6 to 12 months.

What drives the price up specifically here: the number of drill rig and monitoring vendors whose data you want, since each is a real integration. Blast design package interoperability, since round tripping a design without losing timing information takes care. Regulatory reporting across more than one jurisdiction. And multi site rollout, because each site will insist its loading practice is the standard one.

What keeps it down: start with one site and the blast record itself. Capture 30 blasts end to end before building a single analytics screen, because analytics on an untrustworthy record are worse than none.

Build versus buy, and when buying is the right call

Buy if you are a single site that runs one explosives supplier's ecosystem end to end, has high precision drill navigation across the fleet, and has stable fragmentation. BlastIQ within an Orica supply relationship, or BlastLogic where design to as drilled quality control is the whole problem, will get you further faster than a custom project, and we would say so before quoting. Hexagon MinePlan is the reasonable answer where you are already standardised on that planning stack and want blast to live beside it.

Build when two or more of these are true. You buy explosives from more than one supplier, or intend to tender competitively and want a neutral consumption record. You run several sites or a quarry group where practice varies and group level comparison is currently impossible. Your drill rigs, vibration monitors and design package come from three vendors and the join is a spreadsheet. You have been asked to defend a vibration complaint and it took days. Or your improvement loop depends entirely on one superintendent's judgement, in which case the software project is really a knowledge capture project and should be scoped as one.

How to choose a developer for drill and blast software

Ask them to whiteboard the blast data model before you sign anything. The right answer has design hole and actual hole as separate linked records, decks as children of a hole, product consumption at deck level, and a blast identifier that propagates downstream to muckpile, truck loads and crusher feed. A developer who models a blast as one record with a total kilograms field has not thought about decking and will rebuild the schema in month three.

Ask what they have integrated on a pit floor. Rig telemetry, vibration monitors, a plant historian and a blast design file format are four different problems, and the answer should name specific vendors and specific pain, not describe integration in the abstract.

Ask how the tablet behaves with no signal for a full shift, and what happens if two people capture the same pattern. If duplicate reconciliation is an afterthought, your record will have gaps in the patterns that were rushed, which are the ones that went wrong.

Ask who owns the code and the data, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. The point of this build is to stop your blast history being locked inside somebody else's platform, so accepting a new lock would defeat it.