Underground Mine Personnel Tracking Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the build get scoped as a map when the control room needs three lists?

Every demo in this category opens with a mine plan and moving dots. It photographs well and it is close to useless at 04:12 with smoke reported on a level. An incident controller does not need a map. He needs three lists: people confirmed at a muster point or inside a refuge chamber, people currently moving toward one, and people whose last read is stale and therefore need a physical search. Those three lists are the product. The map is decoration on top of it.

The scope failure follows from the demo. Presence gets modelled as a boolean because a dot is either on the map or it is not, and once presence is a flag there is nowhere to put confidence, evidence age or the reason a person is believed to be below. Everything downstream inherits that weakness.

The fix: model presence as accumulated evidence with decay. A person is underground because a tag was read at the portal, was seen at a level reader forty minutes ago, has a rostered shift that has not ended, and has no exit read. Each of those contributes with its own reliability, and each ages. The control room screen shows the derived count, the confidence, and the named individuals whose evidence has gone stale. Design the three lists first and let the map be a view onto them, not the other way round, because a system built map first will not reorganise itself under pressure.

What goes wrong with the zone graph and identity data?

Two data problems decide whether the system works, and neither is software. The first is the spatial model. Underground, zones matter more than coordinates: knowing somebody is in the 690 level east drive between two egress points is more useful than a position estimate with an unstated error of eighty metres. But somebody has to turn survey data and level plans into a zone graph with connectivity and egress routes, and then keep maintaining it as development advances. A zone graph that is not maintained is worse than none within two years, because it will confidently place people in a drive that has been rehabilitated and sealed.

The second is identity. One worker appears as a cap lamp tag identifier, a vehicle login, a payroll number on the roster and a name on a contractor induction spreadsheet, and none of those keys join. Meanwhile a meaningful share of tag reads belong to nothing you care about: a tag sitting in a crib room charger for three days, a spare on a shelf, a vehicle mounted unit that implies an operator who got out an hour ago.

The fix: fund the zone graph as a workstream with a named owner on your side who updates it when levels change, and put that owner in the operating rhythm rather than in the project plan. Build a canonical person and asset registry so one worker is one worker across every source, and classify every tag by what it is: person, vehicle, spare, fixed asset. A tag with no assigned person is an exception to resolve, not a dot to display.

Why do the tracking hardware integrations break after launch?

Because the estate underneath them keeps moving. A leaky feeder system from one decade, cap lamp tags added later for statutory compliance, wifi the information technology team owns, a proximity detection retrofit after an incident, an area of ultra wideband where somebody funded it. Each has its own vendor, its own position model and its own screen, and several speak protocols that are undocumented or documented inaccurately.

The specific break is rarely dramatic. A vendor pushes firmware and a message field changes type. A reader is moved during development and keeps reporting under its old zone identifier. A new level is driven beyond reader coverage, so people working there produce no reads at all and the system quietly reports them as stale rather than as uncovered, which are very different operational statements. Stope extensions past the commissioned coverage area are the most common version of this, and they are invisible unless somebody is comparing coverage against the current mine plan.

The fix: one ingestion adapter per source, owned by you, with health monitoring on each: message rate, unique tags seen, last message time, and an alert when any of them departs from its normal band. Distinguish uncovered zones from stale reads on the screen, so an operator can tell the difference between no infrastructure and no signal. Keep the adapters in your repository, because they are what stops the next vendor negotiation from locking you in again.

What happens when the roster and competency join is not covered?

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 systems have never been introduced, because the roster lives in a timekeeping or human resources (HR) system the control room cannot reach.

Contractors make it sharper. Crews are frequently managed on a separate induction spreadsheet, so a person can be site inducted without being competent for the area they are standing in, and a visitor can be escorted by a supervisor who then goes to another level. After an incident, the inspector does not only ask how many were below. The question is who, when they entered, and what their competency status was that day.

The fix: join roster, induction and competency records to live tracking in one view, and use it every day rather than only in emergencies. That join enforces zone access rules, so a worker read in a shaft area without current competency raises an alert while it still matters. It also produces the post incident record without an assembly exercise. Treat contractor onboarding as part of the same identity registry rather than as a separate list, because a separate list is how the escorted visitor disappears.

Should you build custom or configure what you already own?

If you are commissioning a new mine or a major expansion and can standardise on one vendor's stack from the start, buy it. Newtrax, Mobilaris Mining Intelligence, Sandvik OptiMine, Strata Worldwide and Becker Mining Systems all do genuinely good work, and Mobilaris in particular is strong at building a situational picture from mixed inputs. A custom build in that situation reinvents infrastructure for no gain. The same applies if your only requirement is statutory tag tracking on a small single decline operation, where the problem really is simple.

There is also a hard line on what must never be rebuilt. Proximity detection and collision avoidance on mobile equipment, gas monitoring, ventilation control and refuge chamber life support are safety systems with their own certification and testing regimes. A custom build reads their state, displays it and alerts on it. It does not command them, and any developer who offers to reimplement collision avoidance because it uses the same tags is telling you they do not understand the liability.

Build the merged layer above the hardware when you carry two or more generations of tracking underground and replacing them is not fundable, when your roster sits somewhere the control room cannot see, or when an emergency exercise showed that muster reconciliation took longer than the exercise.

How do hidden costs get into the quote?

Protocol work is the first. Reading three tracking vendors is not three times one, because at least one will be undocumented and require packet capture and patient reverse engineering against a live system you cannot take down. The zone graph is the second and is routinely priced as a data import when it is a survey interpretation exercise with an ongoing maintenance commitment.

Historical playback is the third. Reconstructing the state of the mine at any past moment for an incident investigation means storing every read at full fidelity and rebuilding presence from it, which changes the storage and the query design rather than adding a screen. Rollout across multiple mines is the fourth, because sites name levels differently and each new naming convention is real mapping work. Degraded mode is the fifth: a control room screen that must survive a network partition and a surface power event with a visible last known state is an availability requirement with a cost, and it belongs in the acceptance criteria rather than in a hope.

The fix: ask for protocol work, the zone graph and playback priced separately, then ask what changes when a second site joins. Ask who on your side maintains the zone graph and how that is funded after the project closes.

What separates a build that works from one that fails here?

Ask the team to whiteboard the presence model before anything else. The right answer treats presence as evidence with decay and confidence and can say exactly what the screen shows when a person's last read is ninety minutes old. A developer who models presence as a flag has built an office access control system and will mislead a control room during an emergency.

Ask what they will refuse to build. The answer should include proximity detection, gas monitoring and anything that issues a command to a safety system. A developer who happily takes that scope is one you should not hire for this work, and their willingness tells you what else they have not thought through.

Ask how the system behaves when the network drops or surface power fails, and expect a degraded mode with an obvious timestamp on the last known state, tested with the emergency response team during a scheduled drill rather than discovered during a real one. Ask how the zone graph gets built from your survey data and who owns it afterwards. Then settle ownership before kickoff: the repository, the environments and the integration adapters. The adapters matter most, because they are the difference between owning your merged picture and renting it back from whichever vendor you negotiate with next.