What techies keep getting wrong about industrial automation
hivekit.io
hivekit.io
So, to anyone with dirt experience, hivekit just called themselves out as being the techies that don't get it.
On-road trucks are fragile and require highly attentive drivers to run without destroying the trucks off-road.
Everything breaks in the dirt, and almost all mining operations need very nuanced knowledge to conduct safely, for people or machines.
> Areas, where traffic is highly structured and controlled.
That isn't mining or the oil patch.
You are dealing with mud, dropped rocks that will take out brake chambers, continually changing conditions etc...
The Moravec Paradox hits all these attempts, because people without domain knowledge under estimate the skills required.
While minimizing operator count is useful, this isn't Minecraft. It takes a lot of skill and being adaptive changing conditions to even different with an excavator.
Some mines with consistent material properties and safe conditions do automate digging up a stope, but most mining requires expertise and informed judgement.
Even in the oilfield, drilling is a high skilled job, were you have to adopt to changing conditions to avoid breaking the drill stem, which is expensive to fish and fix.
Even robots in warehouses are a challenge and that is far closer to the authors claimed conditions.
And they are not completely wrong. If you asked any decent professional whether their work could be replaced by automation, they would probably give you reasonable sounding arguments why it is not that simple.
But as a techie that has on the ground experience with sensors, electronics, computer vision, programming and grew up close to mines I think it is key to realize that there are hard problems and there are hard problems. And mining automation is the latter.
But truck shovel routing is a version of VRP, trucks and shovels need to be matched or the approximations rise into the double digits of inefficiency.
If you look at the powder river area where they use the model they mentioned, truck shovel is for removing the spoil on top, and thus is a dynamic environment.
The actual coal is moved by conveyer belts at the mines I have been to.
VRP is nontrivial and the bean counters know this.
Note this fairly readable paper and the complexity of 2VRP vs 3VRP vs kVRP.
https://www.sciencedirect.com/science/article/pii/S0166218X0...
If they have some new method, it won't apply across surface, sub-surface, and oil at the same time unless P=NP.
VRP is noise on the signal, and it is not even that relevant in a lot of cases, it makes little difference to where and when a truck needs to be whether it is driven by a human or machine.
Additionally, the from-to endpoints are fairly well known, with very few options, and the state of the truck related to these (eg full, empty, healthy, faulted etc etc) and with very limited options for variability, unlike a travelling salesman problem which has far less constraints.
The subset of this problem is already fairly well understood and applies to any kind of transport of goods with a few fixed options, and in mining materials handling is called Route Sequencing (RSS). Can be conveyors with shuttles, or trucks with roads/intersections. Similar concepts occur in Amazon warehouses, airport luggage handling, graineries (eg wheat), and so on.
There are far greater immediate problems to solve beyond a few tweaks in efficiency relate to to VRP or RSS or whatever, first one being the "friction points" of human-machine interaction and how to manage safety in the context of already well established Functional Safety standards and regulations.
These Functional Safety problems already consume a significant part of any mining automation. I know because I am a Functional Safety Engineer (TUV Registered) that works in this area in one of the biggest and highest intensity mining centres in the world. I have worked for over the last 30 years designing, engineering and delivering mining and O+G automation and safety systems.
We already have autonomous dump trunks and autonomous road haulage (in some cases running up to 100km route lengths) in some mining operations, but have seen over 30 years of extensive de-manning in mining and materials handling operations. This has been primarily under the guise of safety by reduced exposure, party efficiency by removing human in loop ops, but also with the hidden under-current of de-unionisation - there used to be some very acrimonious and expensive strikes in the industry, unions were strong. Historically costing billions if not tens of billions of dollars, do not under estimate the company drive in this aspect. The biggest mining company in the world, and it's peers, is heavily involved in this.
Offshore, there have been some manned oil/gas platforms de-manned, with daytime access for maintenance as required, going back 20 years now.
It is already happening, it is just a matter of how fast, and to what degree, but it is constantly shifting equilibrium point (based on available tech, desire and available capital, motivation and opportunity etc etc). What could be done is counterpoised with inertia and stickiness driven by fear and greed, conservatism,anchoring and reaching and whole heap of human factors that often dominate over the technological capabilities.
You have to remember the scale of some of the projects is mammoth, an LNG development might be 60+ billion dollars over near 10 years, apart from the change in available tech over this time, spending this type of money is usually accompanied with a desire for certainty of outcomes, some times new tech is only applied when mission essential as there have been some notable failures of application or scaling up of new tech in the past.
I have only scraped the tip of the iceberg here and could develop whole rabbit warrens of discussion around all this, but I think I have made my initial point and then some. This is not a simple problem, it is harder than a hard problem, and VRP is not the deal breaker. VRP is not even close to being on the horizon of challenges that will impact the bigger picture outcomes.
Looking back a few hundred years it is easy to see that we have made progress. In the mining industry, for example, the need for large haul trucks is reduced by long conveyors. The longest I have seen is two miles. Those conveyors are barely attended to by operators and their operation is monitored by control systems connected wirelessly and reliably.
The real leap will come, not from increased automated operation, but from automated maintenance. That won't happen until well after IOT is more fully implemented. By that, I don't mean more devices connected to the Internet. In my opinion, IOT's potential lies in the future of the "Things" making decisions based on information from the connected devices.
I don't work there anymore but I'd bet that not much has changed since then.
I was lead developer on another IoT project about 3 years ago, and besides using cell modems instead of Ethernet, because the machines in this case were in geographically remote regions, the state of the art had barely changed.
>. It can transport a payload of 363 tons and costs around five million - which comes out to around 14k per ton of payload.
Did the unnamed author divide the price of the truck to the weight of a single load? If so, ignoring that it's not specifying a distance and hence the 1:2 cost ratio may be highly inaccurate, why? Is that some industry standard? It would be weird not taking into account amoritization cost/period too.
Finally, in conclusion, what do "techies" get wrong?
Not sure how they even think that the hoe that is loading them will also be able to load on-highway trucks.
It would be like loading water glasses by tipping a 55gal barrel.
The operator inefficiency of dumping into 20 trucks for an equivalent of one would reduce the time the hoe operator could actually mine.
As they are obviously claiming to solve things for very different use cases it looks like they have practically zero knowledge about their customers needs.
I have seen many, many cases over the decades where OT was confused for IT by management and the extensive OT considerations were ignored or had to be re-learned when an IT approach was taken to OT problems.
Often the IT based solution in OT world never ended up working at all and had to be discarded, or re-engineered from the ground up.
Just because you have boxes with screens connected by blue cables, history has proven many times that this does not make IT the best people to architect and implement your OT system, by a long, long way.
I read the answer as "there are several factors and broader context besides direct productivity gains that need to be taken into account when considering automation". And to be honest some techies do indeed forget about them. Elon Musk seems to be the the most striking example of "it's just an engineering problem" mindset.
1. Internet connections can be some combination of slow, unreliable, intermittent, or expensive. They also may be completely unavailable, although this is changing in the era of Starlink.
2a. Consumer grade compute hardware dies a quick death in harsh environments.
2b. Consumer grade compute hardware typically has more compute power than industrial rated computers. I've seen a handful software engineering teams have to drastically rebuild software because compute resource constraints were not realized until it was time to deploy software at the edge.
3. You are not allowed to push updates to your software willy nilly.
4. Service tech callout and installation costs are a big consideration for remote assets (oil wells, pipeline compressor stations, etc.), particularly at scale.