Product Simulation Stands Up to the Test

Created by Matthew Lee - Published March 24, 2016


 matthew-lee @ivolvemattl
nexis

One of my colleagues has recently written about the importance of writing quality software. Another has written of the benefits and challenges of ensuring only a quality product leaves our front door.  These are both essential elements of the software development lifecycle… but how do we get from point A to point B?  How do we know that the Fleet Management System (FMS) software we’re writing is going to pass the suite of system tests it’s subjected to and be fit for purpose on customers’ mining fleets?

How does iVolve undertake product simulation?

Here at iVolve, I work with a team of engineers writing the FMS applications that run onboard, in the little box of hardware installed in machines such as a mining truck, excavator, dozer or drill.  While it would be great to have our own 360+ tonne truck in the backyard to test on, zoning laws and economics don’t work in our favour.  The trick, then, is to write software designed to not only run in the real world, but to also run in a simulated environment – allowing us to test all kinds of scenarios on ‘fake’ machines.

On a real mining machine, our onboard hardware runs one instance of our onboard software. It communicates with the host machine and across the wireless mesh network with other machines.  When writing and testing the software, it’s not always practical to have multiple hardware devices or access to real GPS data, and it’s impossible to have a real shovel to test on.  To overcome these difficulties, our software has been designed to run many copies of itself on one server, each with the “personality” of a target machine.

What does product simulation mean onsite?

Instead of communicating with other machines across the mesh network, we’ve written tools to simulate UDP broadcasts between those instances.  Need GPS data? We have simulators for that.  Need “real” operational data from a truck?  We’ve written numerous simulators to inject realistic data into the software.  Tracking down that elusive bug from a particular machine that only occurs when it’s driving North-East on the third Sunday of the month?  We can capture raw data from the machine while it’s happening and replay it into the application while stepping through with a debugger.

These are just some of the techniques we employ at iVolve to ensure fit-for-purpose Fleet Management System software is deployed to our customers.