Haulage Simulation

In 2011 the only place you could watch haul trucks run the roads of Oyu Tolgoi was a spreadsheet on my laptop. The mine was still years from production, a giant copper deposit under the Gobi Desert whose haul roads existed only as engineering drawings. But in Excel the trucks drove: hauling between loading and dumping points, slowing exactly where the grade said a loaded truck had to slow, working around each other on the network. I was an undergraduate intern, and I had written the whole thing in VBA.

The year before, at Rio Tinto's borax operation in Boron, California, I had been handed a question about the crusher: when should a haul truck wait in the queue, and when should it give up and dump to a stockpile? I recognized it as the bank-queue problem from a business math class, the kind you attack with Monte Carlo simulation, so I taught myself VBA on the job and built one. Rio Tinto's internal Technology & Innovation group caught wind of that work and brought me a much bigger version of the same problem. I didn't apply for this internship. The Boron simulation applied for me.

Their problem was Oyu Tolgoi. Phase one of the project had left a set of older, non-traditional vehicles, fundamentally different from the fleet the mine was moving toward, and the planners needed to know whether there was a better equilibrium with those machines still in the mix. Rio Tinto had internal simulation tools for haulage, but they were built for operating sites, places you could calibrate against. Oyu Tolgoi's roads, fleets, and schedules were all still theoretical. There was no mine to observe. The question needed a mine built out of math.

So the simulator got written from scratch, and it got written in Excel. Why Excel? The honest first reason is that VBA was the only language I knew besides Java, and I didn't know how to get data into Java. But the reason I stand by fifteen years later is better: I have always needed to see a program to reason about it. Excel gives you that for free. The data sits in front of you on the way in and the way out, and the macro recorder did something I still miss in modern tools: do a thing by hand, and it writes down the code that does it. It was a self-exposing API. There was a real magic to that, and nothing since has replicated it.

The work at Boron had also surfaced an interesting issue: just because an answer is correct doesn't mean people will believe it. You need to take them on a journey, and people often don't believe what they can't see. So I had an idea: what if I took my Monte Carlo simulations, turned them into a discrete event simulation, and visualized the trucks moving around the haulage network? Now you might see a problem here. I wanted to visualize 3D operations, and the tool I had was Microsoft Excel. Excel just so happens to have a 2D canvas you can draw to: plots. Add the fact that a haulage network is just nodes and edges, combine it with a little matrix math, and all of a sudden you can create 2D representations of 3D workings using nothing but scatter plots and the data underneath them.

The world of computers is full of "3D," but we are always viewing it on a 2D output. Even VR goggles are mostly flat panels.

The simulator took the haulage network as X, Y, Z coordinates, operating distributions for things like load sizes and queue times, and rimpull curves for each candidate machine. A rimpull curve is the manufacturer's chart of how much pulling force a truck can produce at a given speed. Run it against the grade and resistance of a road segment and you get the speed a loaded truck can actually hold there, which is how the model set speeds dynamically instead of assuming flat averages. The curves themselves came out of digging through the Caterpillar Performance Handbook, with senior technical folks at Technology & Innovation and on site supplying network designs and fleet data. Time advanced in fixed ticks, and every tick each machine on the network moved, queued, loaded, or dumped, interacting with everything else sharing the roads.

Routing the trucks meant computing shortest paths across the network, which meant Dijkstra's algorithm, and I could not find a Dijkstra written in VBA anywhere. So I hand-wrote one, never having taken an algorithms course.

The 3D visualization is the part people never believe. Excel has no 3D engine, but it has a scatter chart, and the rest is matrix math I googled my way to: take the network's 3D points, pick a perspective, transform each point to where it sits from that viewpoint, and plot the result. Connect the points with lines and a scatter chart becomes a graph, and a haulage network is a graph. Add small markers moving along the edges and you have trucks. Planners could watch the operation run instead of reading it off a table.

The finished simulator ran about 7,000 lines of VBA, and my test suite was my eyes: build a little network, run it, watch whether the trucks made the right decisions. Needing to see my programs run is what let me program at all back then, and it never really stopped being how I work. The most entertaining part, to me: the only data structure I knew was the array, and I didn't understand the difference between VBA memory and worksheet data, so everything was stored in Excel tables and treated like 2D arrays. The things I could have done with a hash table! That Dijkstra ran on top of all that still blows my mind.

The simulator gave the planners their answer on the phase-one fleet, and then it outlived the question it was built for. Rio Tinto turned it around and applied it at Kennecott, their copper mine outside Salt Lake City, to evaluate a new pushback, the next planned expansion of the pit. An operation that very much did exist. I like the symmetry: the tool got written because the official tools could only model real mines, and it ended up modeling a real one too. Two years later I was at Kennecott myself, working as an operations engineer. The spreadsheet got there first.