5 tips on building fleet management solutions

If you are looking to customize your fleet management processes, the MyGeotab Software Development Kit (SDK) opens up an incredible range of opportunities. The flexibility of the SDK makes it possible for fleet management companies to leverage the data available through MyGeotab for their telematics needs. Users can build applications, automate tasks, set up custom reporting, and integrate third party software. Basic data, including GPS and engine data, or more specialized information, such as trip or exception rule data, can be extracted, analyzed and used to inform important fleet decisions.

To help get you started, Geotab has provided a number of helpful online resources. This article describes where to find those resources and also outlines some key considerations that you should keep in mind when designing your code.

5 Essential Tips for Building Fleet Management Solutions with the MyGeotab SDK:

1. Browse Geotab’s learning resources on the SDK.

For a complete how-to guide, including concepts, sample code, and projects, go to the MyGeotab SDK site. As well, read the Geotab blog articles, “Learning the MyGeotab SDK” and “Better Practices for the MyGeotab API.” The guidelines provided in the second article are crucial for making your solution scalable. For example, one best practice is to keep your session id instead of logging in again and again. This is a great time saver.

2. Fetch data efficiently.

When retrieving the data, it is vital to minimize the number of data transfers. Such operations can not only create a bottleneck in the operation of your own code, but they can also slow down the host-server, taking resources from other processes. An efficient way of obtaining this data is through the API data feed, keeping in mind to not ask for too much data at once – a few thousand or tens of thousands of objects is a good upper limit. Another way to speed up how the code works, if the data transfer is still rate-limiting, is to employ MultiCalls. Caching any reused and slowly-changing data will also cut down on retrieving data.

3. Store your data permanently.

Once you have retrieved the data, store it permanently. Keeping backup data might be important if the state of your code is crucial for restarting. JSON is an excellent format to use in many cases, when the backup data also needs to be human-readable, which can be accessed through the MyGeotab API. Another option to consider might be a big data project. Gaining access to this valuable data from Geotab products opens up numerous opportunities for application. With more information, you can make more effective decisions for your fleet.

4. Reuse old building blocks.

To efficiently build your solution, it is important to reuse code. There are a number of simple and useful examples on the MyGeotab website. This article on MyGeotab SDK provides a good overview of the SDK. We have a simple data feed, which can be used as a starting point for more complicated data-gathering tasks.

Once the data is retrieved, it can be used in many ways. For example, the SendTextMessage sample code indicates how to message other MyGeotab users, which can be combined with the data feed for providing real-time feedback to coworkers. Updating coworkers about their daily trips or about engine faults, which occurred during the day with relevant supplementary information are two such useful applications.

5. Use engine fault data.

The health of your vehicles can be critical to your company’s success. Substantial cost savings can be found through preventative maintenance, which can be effectively targeted by focusing on known problems using engine data. We record engine fault data from data buses using OBDII, J1708, J1939, and our custom telematics device protocols. This data contains many important details about the type of fault, state of the fault, the count of how often the fault has occurred, and warning lamps in the car.

Any fault data contains a fault code, indicative of the kind of fault that is occurring. In the J1939 standard, this is the suspect parameter number (SPN). As well, there is a failure mode identifier, which indicates what kind of failure happened in a particular SPN, for example whether the fault occurred because data is erratic – irregularly low or high. The controller is the part of the car that the fault occurs in, such as the axle, engine, brakes trailer, or suspension trailer. The fault state can indicate whether or not a fault is serious, active, or historic. In the J1708 and J1939 standards, there are active and inactive faults. Active faults can indicate current problems in your vehicle, while inactive faults indicate that a specific kind of fault is no longer a problem. In OBDII, there is a pending fault state, indicating that the fault condition is tentative and might clear before becoming fully active.

You can also probe GPS data and engine status data around the time of incidents to determine what else might have been in play to cause the fault. Gathering information when an accident occurs, is critical to preventing future such events and enhancing fleet safety. Through MyGeotab, a wealth of information is available. Furthermore, by analyzing where the vehicle has been driven and under what conditions, you can gain further insights into the current state of your vehicles.

Learn More About the MyGeotab SDK

Want to learn more? Check out the SDK forums to connect with the Geotab Community and get answers to your questions. If you are trying to develop your solution and are uncertain how to proceed, feel free to make an inquiry on the SDK forum.

The Geotab DEV Channel features training videos for business software application developers using the Geotab Software Development Kit (SDK).

For company and industry-specific solutions, visit the Geotab Marketplace to view the existing portfolio of MyGeotab Add-ins, Hardware accessories and Add-Ons, Mobile Apps, General Software Solutions, and Custom Reports.

Feel free to contact Geotab or leave a message below to let us know your thoughts.