Underground Mine Personnel Tracking Software: Who Is Actually Below at 04:12

Why the control room cannot answer the only question that matters

04:12. Smoke is reported near the workshop on the 720 level. The control room operator needs one number: how many people are underground, and where. The tag board in the lamp room says 63. The shift roster in the timekeeping system says 68 were rostered on. The contractor supervisor thinks his crew of nine went down at 03:30 but two went back up for a part. The tracking system installed in 2019 shows 41 tags, because it only covers the decline and the main levels, and the stopes were extended after commissioning. Refuge chamber occupancy is being established by phone, one chamber at a time, while the mine manager stands behind the operator asking for a number he can give the inspector.

Nobody in this scene is doing their job badly. This is the normal condition of an underground mine that has been operating for fifteen years. Tracking infrastructure arrives in layers: a leaky feeder system for communications, cap lamp tags added later for statutory compliance, wifi in the workshop, a proximity detection retrofit on the loaders after an incident, an LTE trial on one level. Each layer came with its own vendor, its own position model and its own screen. The roster lives elsewhere, usually in a timekeeping system the control room cannot access.

The consequence is that the mine holds five partial answers and no complete one. In a real emergency you get the number by counting tags in the lamp room and phoning supervisors, which is exactly the process the tracking systems were bought to replace. The regulatory pressure is real too: the MINER Act of 2006 in the United States pushed wireless communications and electronic tracking into underground coal mines, and jurisdictions worldwide have their own duties to account for persons underground. Confirm the specific obligations for your commodity and jurisdiction with a regulatory specialist, because they differ meaningfully between coal and hard rock and between countries.

Problem 1: the tag board records intent, not location

A tag board or a lamp room register tells you who collected a lamp. It does not tell you who is still below at shift change, who went up for smoko and did not come back, or who is a visitor escorted by a supervisor who then went to a different level. It is a check in system, and check in systems fail in the situation they exist for, because during an evacuation nobody updates the board.

What the build must do is treat presence as a derived state with a confidence level, not a boolean. A person is underground because a tag was read at the portal, was seen at a level reader 40 minutes ago, has a rostered shift that has not ended, and has not been read at an exit. Each of those is evidence. The control room screen should show the derived count, the confidence, and specifically the people whose evidence is stale, because those are the ones a supervisor needs to phone first. A system that displays a single confident number it cannot support is more dangerous than a tag board, since it invites a decision the data does not justify.

Problem 2: five vendors, five position models

Leaky feeder gives you zone presence along a cable. Wifi gives you an access point association that may be one hundred metres from where the person actually stands. Ultra wideband gives you metre level accuracy in the areas where somebody paid to install it. Vehicle telemetry gives you a machine position that implies an operator position, unless the operator got out. Newtrax, Mobilaris Mining Intelligence, Strata Worldwide, Becker Mining Systems and Sandvik OptiMine all do genuinely good work in this space, and Mobilaris in particular is strong at building a situational picture from mixed inputs.

The friction is not their capability, it is your history. These systems are sold as a stack, and the assumption behind the pricing and the integration is that you are standardising on one. A mine with a Becker leaky feeder from 2011, Newtrax tags on the loaders, and a wifi network the IT department owns is not a candidate for a clean stack, and the cost of ripping and replacing infrastructure across 40 kilometres of development is a capital project the board will not approve for a software benefit.

A custom build takes the position that the hardware stays and the model is yours. That means one ingestion adapter per source, a canonical person and asset identity so that one worker is one worker across cap lamp tag, vehicle login and roster, and a spatial model of the mine expressed as zones with connectivity rather than coordinates. Zones matter more than coordinates underground. Knowing somebody is in the 690 level east drive between the two egress points is operationally more useful than a position estimate with an unstated error of 80 metres.

Problem 3: the roster is the missing half of the answer

Tracking tells you who was seen. The roster tells you who should be there. The gap between those two lists is the entire emergency management problem, and at most sites the two systems have never been introduced. Contractors make it worse, because contractor crews are often managed on a separate induction spreadsheet, and a person can be site inducted but not competent for the area they are in.

The build must join the roster, the induction and competency records, and the live tracking into one view. That join pays for itself long before any emergency: it enforces zone access rules, so a worker without the current competency for a shaft area triggers an alert when read there, and it catches the visitor whose escort has gone to another level. It also produces what an inspector asks for after an event: not just how many were below, but who, when they entered and their competency status that day.

Problem 4: refuge chamber occupancy is currently a phone call

During an evacuation the control room needs to know, per chamber, how many people are inside, whether the door has been opened and closed, what the chamber telemetry says about oxygen and carbon dioxide, and who has acknowledged the evacuation instruction and who has not moved in ten minutes. Most sites hold some of this in the chamber vendor's system and none of it beside the tracking picture.

What the build adds is the evacuation state machine: declare an event, push the instruction through every channel available including the comms system and any tagged device, then track acknowledgement and movement per person. The screen the incident controller needs is not a map with dots. It is three lists: people confirmed at a muster point or in a chamber, people moving toward one, and people whose last read is stale and who therefore need a physical search. Building around those three lists rather than a map is what makes the system usable under pressure.

Problem 5: safety critical systems must not be quietly absorbed

This is where we will be blunt, because it protects you. Proximity detection and collision avoidance on mobile equipment, gas monitoring, ventilation on demand control and refuge chamber life support are safety systems with their own certification, testing regimes and legal standing. A custom build must not replace them, and any developer who offers to reimplement collision avoidance because it is the same tags is telling you they do not understand the liability. Your build reads their state, displays it, and alerts on it. It does not command it, and every screen should make clear that it is an advisory picture backed by the statutory procedure, not a substitute for it.

The same discipline applies to availability. If the control room relies on your screen, it has to survive a network partition and a surface power event, with a degraded mode showing the last known state and an obvious timestamp. Test that behaviour with the emergency response team during a scheduled exercise, not during a real one.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. An evacuation and mustering layer, meaning ingestion from existing tracking sources, canonical identity, the roster and competency join, zone based presence with confidence, and the incident controller screen, runs $80,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding equipment tracking and utilisation, zone access enforcement, contractor onboarding, shift reporting and historical playback for incident investigation runs $200,000 to $500,000 over 9 to 15 months. Tracking hardware, readers and network extension are site infrastructure and sit outside those numbers.

What drives the price up specifically underground: the number of distinct tracking vendors and generations you need to read, because each protocol is real work and some are undocumented. The spatial model, since somebody has to turn survey data and level plans into a zone graph with egress routes, which is a proper piece of work rather than a data import. Historical playback, which means storing every read at full fidelity and reconstructing state at any past moment for an investigation. And rollout across mines that name their levels differently.

What keeps it down: start with presence and mustering only. Equipment utilisation and productivity analytics can wait until the emergency picture is trusted by the people who use it at 04:12.

Build versus buy, and when buying is the right call

Buy if you are commissioning a new mine or a major expansion and can standardise on one vendor's stack from the start. In that situation Newtrax, Mobilaris, Sandvik OptiMine, Strata Worldwide or Becker will give you an integrated product with support and a roadmap, and a custom build would be reinventing infrastructure for no gain. Also buy if your only requirement is statutory tag tracking on a small single decline operation, since the problem is genuinely simple at that scale.

Build when two or more of these are true. You have two or more generations of tracking hardware underground and replacing them is not fundable. Your roster and competency records live in a system the control room cannot see. You have run an emergency exercise and the muster reconciliation took longer than the exercise. You operate several mines and group level assurance is currently a set of emailed spreadsheets. Or you have a vendor screen that shows tags but nobody can tell you which of those tags is a person, which is a vehicle and which has been sitting in a crib room charger for three days.

How to choose a developer for underground tracking software

Ask them to whiteboard the presence model before anything else. The right answer treats presence as evidence with decay and confidence, not as a flag, and it can articulate what the screen shows when the last read for a person is 90 minutes old. A developer who models presence as a boolean has built an office access control system and will mislead a control room in an emergency.

Ask what they will refuse to build. The answer should include proximity detection, gas monitoring and anything that commands a safety system. A developer who will happily take that scope is one you should not hire for this.

Ask how they will build the zone graph from your survey data and level plans, and who on your side owns it as levels change. This is the part that quietly rots: a spatial model that is not maintained is worse than no model within two years.

Ask who owns the code, the data and the integration adapters, and get it in writing before kickoff. You should own the repository, the cloud or on premise accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. The adapters matter especially here, because they are what stops you being locked in again by the next vendor negotiation.