Introducing IVMS can be quite complex and needs to be dealt with carefully at a number of levels.
The most important aspect is to get your staff on board. IVMS can be quite intrusive and if it is introduced in an aggressive manner it will enact an aggressive response: drivers will raise privacy issues and they will start tampering with the IVMS units, ranging from disconnecting the power supply to outright sabotage and breaking components. IVMS needs to be sold as a safety improvement, which it really is in the first instance. As we have shown before, IVMS ultimately pays for itself through a reduction in vehicle abuse and unauthorised trips, but these need to be derived benefits and will never be the primary purpose of IVMS.
When it gets to the actual technical implementation, IVMS allows for a high level of site customisation. Of course it comes with a baseline set of parameters and these are, as a result of the many years we have been implementing IVMS, quite close to what would generally be acceptable. Implementing IVMS with our default parameters and exception reports will get our users 80% of the way, the other 20% can be achieved through fine tuning. These are the technical aspects that need to be considered:
Driver identification: DigiCore Australia is, to our knowledge, the only IVMS supplier that makes a point of accepting our customers’ existing swipe card systems for this purpose. We have over the years worked with many RFID suppliers to achieve this ability, which can be quite complex and challenging, as we need to integrate what often is encrypted technology with our IVMS system. Of course we also have our proprietary swipe card systems (Dallas keys and RFID), but we will work with our customers to help them integrate their existing swipe card system. It is obviously a requirement that we are given a complete list of names and linked swipe card numbers so that we can enter it into our base C-Track system.
Mapping and Geozones: Users want to see their own sites online i.e. they want to see vehicle movements in terms of the areas they are familiar with. Commercially available mapping can only provide so much information, and the typical mine site often shows up as no more than a patch of dirt, so we need to be given mine or site maps to improve on this. These maps can be integrated with our online system, following which far better detail is given. Likewise, our overnight exception reporting needs to be given a level of intelligence: speed limits vary across mine sites and there may be restricted areas where access is controlled or outright prohibited. The maps as such will also be integrated into our batch processing system, all of which provides a high level of intelligence to our interpretation of IVMS data.
Customisable IVMS settings: These pertain to fine tuning the system, both inside the vehicle and also in the IVMS back-end system. At what point should the IVMS unit give a warning to the driver? What exactly constitutes excessive RPM? What is the tolerance towards excessive idling? At what point is driving considered to be harsh driving? What speed limit violations (if any) are tolerated? Can seatbelts be left unclipped below for instance 10 km/h? These are the variables that may and often do differ from site-to-site. Our IVMS system comes with a default set of parameters which, if left as they are, should do a fairly good job, but there obviously is room for improvement through customisation if required.
It has at times been said that IVMS is a verb, not a noun. This does not have to be quite the case though, but the reality is that it does require somebody to keeps their finger on it. Our experience has shown that it works best if a site could appoint what is known as an IVMS Champion i.e. a single point of call that works with us, particularly during the initial phases of implementation.