Every time you are making incremental improvements to build a new version of your software, you are doing it on the shoulders of the previous implementations. We’ve gone through a lot of this while growing our GPS tracking system and have gained extensive expertise in receiving telematics data from all sorts of devices across various protocols.
The very first GPS tracking device I dealt with was Skipper-2 that communicated via SMS messages. An SMS message contained one or more GPS coordinates of device location and sensor states. The Internet back in 2004, especially in a closed country like Belarus, was not very widespread, so I didn't have access to public resources that each child can find these days. I started naming these timeline points with coordinates and sensor states as messages — telematics messages.
In a little while, I integrated the first GPRS-enabled devices into the software; these were Gelix-2 and Morion AT-300 (the port numbers reflect the history of integration — the very first port was 20100).
Today, as well as 13 years back, the term "telematics message" means the same — it reflects the time of the measurement and a set of various parameters that a device collected at that point in time. Parameters can be digital as well as analog, e.g. a picture from the vehicle front camera or internal accelerometer data that can be used for eco-driving purposes. Some smarter devices these days can also detect such events as fuel filling or dangerous driving and send special messages notifying about them happening.
Here comes the key question — what can you do with these data? Or, how the data that the software receives from a device reflect its actual state? The ways to interpret parameters in the telematics messages greatly depend on the software possibilities and trackers configuration. For example, let's take engine ignition status and total mileage value fetched from CAN bus and see how we have been able to interpret these values in various generations of the GPS tracking software by Gurtam.
The very first generation of our GPS tracking software, named GPSDisp, was designed to work only with a handful of known GPS trackers and interpreted the message parameters directly as a vehicle state. To visualize ignition state vehicle power cable from the generator connected to one of the digital inputs on the tracking device, then in an SMS message we had information that some of the inputs had an ON state at that moment. So, we didn't deal with the ignition itself, we worked directly with the parameters instead. It was customer’s headache to know that, say, input 1 represents the ignition status of the vehicle. For mileage data, we didn't have any connection to CAN bus interface at that time.
The next generation of our software, known as Wialon B2, prided itself in support of multiple types of GPS devices. We already knew that in some devices the wire from the generator connected to digital input 1, in other devices to input 2, and yet other devices could have a special parameter in the protocol to identify the use of external power supply (based on higher voltage readings).
To accommodate this variability we implemented the solution in which users could specify vehicle settings to customize how raw parameters are interpreted and how already converted values are stored in the database. This meant that each vehicle could have messages with IGN parameter reflecting its ignition state if the device was properly configured during installation and the vehicle configuration was correctly set up in the software. The problem with this implementation was that we could only change a parameter name and apply a conversion formula during the message storing stage. Hence, if the vehicle information is not configured correctly, your data will be off until you reconfigure it. However, reverting already stored messages to their original parameter values and reapplying conversion was not possible.
In the subsequent generation of our GPS tracking software, named Wialon B3, we used a totally different approach. We stored all the parameters that we could extract in a telematics message along with any custom names of parameters. In addition to that (and this is where the innovation was), we introduced a virtual layer — sensors — to operate vehicle data. Each sensor is configured for a specific vehicle and contains a type and a mathematical formula to interpret values in original parameters from a telematics message. This way we ensured that raw data from the devices were stored in the database and we could later configure all real sensors installed in the vehicle on the fly. But one solved problem triggered a set of new problems:
- If we wanted to replace the device or change the configuration of a sensor at some point in time, we could not do that without affecting all the historic calculations for that sensor. Changing the formula would have resulted in all historic reports reflecting new data (recalculated with the updated formula).
- Since various devices in different protocols store the same data under different parameter names, we could not simply switch the device to a different type. It meant reconfiguring all its sensors, which led to the issue discussed above: you lose all historic calculations for reconfigured sensors. We did have some normalized parameters (location information and several other) but achieving full flexibility raised significant compatibility issues.
- Once we started dealing with billions of messages we faced performance and calculation issues. Storing original values of parameters in telematics messages forced us to recalculate sensor values for each point in time we needed them for.
To alleviate these complications flespi gateway got a special normalized and standardized scheme for telematics message parameter names. We introduced a concept of tags suggesting that each parameter can contain one or several tags related to it. Each known parameter has standard units, which is often present in its name. Here are some examples of the tags we have:
- can — everything related to the CAN bus
- fuel — everything related to fuel
- position — everything related to the position
- tacho — each piece of data from tachograph has this tag in its name
- passenger — everything related to passenger count
- mileage — various forms of mileage
A full list of standard message parameter names can be extracted using a special REST API method. For each protocol, we also have a special method for fetching all possible parameters that can go into the message generated by the channel.
Additionally, we have added a new page to our website showing our users what protocols and devices flespi gateway supports to date, what parameters can be managed, and what values they can take. Soon, when we start working with devices and things in the Registry module (scheduled for Q3 2017), specifying only message parameter tags to store only part of received data will become possible.
Now with this new message parameter names convention in place, flespi gateway can directly communicate with devices and ensure that in the case of tracking devices replacement all the data remains hundred-percent valid, normalized and standardized.
You are welcome to browse the full list of currently supported standardized protocols.