Consider a vehicle monitoring system managing a fleet of cars, trucks, forklifts, or other vehicles. Each vehicle in the fleet is outfitted with a hardware device that collects a variety of data on the driver’s behavior. This data includes driving speed, maximum acceleration and shocks experienced by the vehicle, driving patterns such as the amount of time spent driving vs. the amount of time spent idling.

All of this data is logged into the device’s memory for later upload to the computer, typically through some form of a wireless interface. The device also works as an access controller for the vehicle - drivers use access codes or RFID cards to "log on" to the vehicle.

A driver’s access to the vehicle can also be a subject to time limitations, such as "only within predefined shift", "only within standard working time", etc. Moreover, all vehicle log-ins and log-outs are recorded. In combination with vehicle driving pattern records, this creates an extensive audit trail. The system can also perform a number of additional functions such as monitoring oil and gas level, battery charge, etc. In critical situations, the vehicle can be remotely immobilized by a command sent through the wireless interface.

 
The wireless connection to each vehicle is typically unstable. Even on a site that has blanket wireless coverage, there are always some wireless "blind spots" where the connection is unstable or unavailable. Often, vehicles are not even confined to a particular site and only return to the base occasionally. This dramatically narrows the window of opportunity for communicating with any particular monitoring device.

An average fleet includes many types of vehicles, requiring different configurations. Additionally, vehicles are typically outfitted with a monitoring device at different times. As a result, some carry older monitoring devices, some carry newer ones, and firmware versions are not all the same.

In a regular working environment, it is next to impossible to collect all vehicles and update their devices and firmware in one fell swoop. Very often, some monitoring devices will receive an upgrade. For this upgrade to work, the PC software collecting the data from these vehicles will have to be upgraded too. This, in turn, will make it incompatible with older versions of monitoring devices still working on some vehicles. Experience shows that this cycle of update problems can be endless.

SimageM2M is built from the ground up to avoid all of these limitations. Data is synchronized between the devices and the server whenever a connection is available. You can always change the settings for a given vehicle, and as soon as that vehicle comes into range, the new settings are automatically downloaded onto it.

​

You could also browse the list of vehicle events (log-ins, log-outs, alerts etc) whenever you want, and not just when the vehicle is in range. You will just see the most recent data available, and as soon as the vehicle comes into range (or synchronizes again via GPRS or other long-range media) you’d see new data.

​

SimageM2M is smart enough to adapt to many different firmware versions. You could even manage several vehicles as one group, despite each vehicle containing a different version of the monitoring device and firmware, installed at different times. You could make a single, sweeping change for a setting (like a speed threshold, for example) that would take effect on all such vehicles at once.

Deploying SimageM2M doesn’t mean you have to stop using your current system. SimageM2M supports open protocols for exchanging data and executing operations. Thus, while you could use the built-in SimageM2M Client as the end-user software, SimageM2M is just as useful when used as middleware, with your existing enterprise-grade fleet management system serving as the front end.