A Data Science contribution to the Mining Industry

Being an enthusiast for the application of Data Science (DS) in the Mining industry is a track that took me to places and challenges I had won't even imagine. Today, let me share with you, young - or not so young - mining professionals, how just one idea, just one question, that I had in my mind let me comprehend the DS beyond knowing a particular tool, IDE, library or framework. Brace yourself, and rest assured that I won't disappoint you.

To begin, a bit of context: have any once wondered what DS means? Well, I did it, surely did, and until today I have not found a more clever answer than this: "DS is the practice of using data to TRY to UNDERSTAND and SOLVE REAL-WORLD PROBLEMS" (Robinson and Nolis, Build a Career in Data Science p.5, Manning 2020). Why do I emphasize these words? Because you, actually, are TRYING to solve something using data, nothing ensures a "good" answer with the data available for that question. On the other hand, how clear is the question we want to solve? Will the answer provided be as insightful as we imagine or really want it to be? Here is where the debate begins: to apply DS, you need to have a "good question" and enough data to try to solve it.

In mining, we have tons of questions related to how to improve the way we are doing things. Saying which question is the most relevant in this industry is a debate that is beyond this article but, indeed is worth answering as soon as possible. However, aligned with what I mentioned, a simple curiosity came into my mind: How can we measure the connection reliability between the fleets (shovels and trucks) and the central server at a certain moment? i.e. (technically speaking), how could I do a ping for more than 80 pieces of equipment in the most effective way beyond that to make them one by one?

Here is when the debate began: some said to me: why is this important? NOW I can answer: Because it is a way to evaluate proper communication between the fleet and the FMS. This also allows a robust data transfer and, even more important, proper communication between the controller and the truck/shovel operator. Another one said: this is silly; there are other tools that do the same; why invest time on this? AGAIN, NOW I can answer: Sure, I am not reinventing the wheel; however, having a tool like this can enable the possibility to massify commands to the fleet to obtain parameters that, in most cases, are collected one by one.

In that sense, with a lot of patience, perseverance and a good amount of hours reading documentation and searching on Youtube, a small but powerful tool was developed and is shown in Fig1. In simple, what Fig1 shows is a Telegram bot made in python which, by receiving the "/ping" command, will launch a procedure in bash that will generate the ping for all the fleet (including shovels and trucks), giving the first cleaning of its output using awk. Next, another bash command will launch to send the data to my local machine. Then a third-bash command, using sed, will be in charge of cleaning the data to make it as ready as possible to send it to R and using ggplot2, along with some markdown features, in order to produce the image that you receive. This could be better explained in Fig2.

This tool able us to produce results in less than 1:30 minutes in its second version, thanks to GNU parallel (without it, the command took more than 5 min to get an answer). This bot, along with the capabilities that telegram offers us, is a great advantage for anyone that could need results to certain questions in seconds using the minimum network requirements. That is the main reason why this framework was chosen. And most importantly, this tool provides an opportunity to evaluate the time responsiveness of the fleet for the command provided. Also, this gives us the possibility to store it in a database and provide enough data to use it in other DS tools like Machine Learning (ML) models that can be produced in the future.

So, that is how an answer to the question mentioned at the beginning was answered. Yes, we can measure in a reliable way how good or bad the connection is. Indeed, it is not a life-or-death decision to have this information; however, this opens the door for new ways of development beyond what I imagined at the start of writing some code. For example, a fastest way to communicate with the fleet in your mining operation, extract any data that you require and present it on your phone by simply entering a command in an app.

Finally, there are two messages that I want to share: DS is beyond knowing a particular tool, IDE, library or framework. For me, DS is the opportunity to embrace challenges with, as Liam Neeson in Taken (2008) said, "[...] a particular set of skills; skills I have acquired over a very long career [...]". New tools or new versions of the old ones will constantly be developed; you must always keep in mind the relevance and the reliance on the answer provided; the "what do you use to obtain it" is a discussion for later on. Lastly, DO NOT COMMIT THE SAME MISTAKE THAN I DID: if you have an idea that could work, do your best to demonstrate to YOU that it works; otherwise, why it does not work. Similarly to what the other day, somebody told me: "Innovate is a learning path where there are more people sharing fears than solutions, so it would be better if you start doing something to change it."

A minute summary reading (for those who do not have time to read it all). The whole post is about an idea that came into my mind one day: making a ping to all the fleet simultaneously. Then, after many people whined about the existence of other tools doing the same thing, I came up with a telegram bot that takes one minute to produce a graph that informs about the current state connection of more than 80 pieces of equipment in less than 2 minutes. The whole process was achieved by using python, bash and R.