Optimise Telematics Data Flow Management with a No-Code Monitoring Tool

Telematics data management involves handling data flows from multiple devices. Getting insights is often impossible without access to historical data for trend analysis and anomaly detection, which might require substantial time and effort.

The IoT Logic Monitor tool addresses this issue, providing both a real-time and historical view of tracker data flow to analyse patterns and drastically facilitate debugging. The data storage methods are central to its success, enabling quick data access.

Denis Demianikov, VP of Product Management in Navixy, explains how we approach making telematics management easier in our products:

We strive to harness the evolution in technology in our solutions, simplifying device management and IoT data streaming for telematics professionals with low-code/no-code tools and an effective data storage system, addressing the need for faster analysis and easier integration. This approach aligns with industry trends toward making technology more efficient, empowering professionals to concentrate on innovation and impact.

– Denis Demianikov, VP of Product Management at Navixy

Let's explore how these mechanisms work to optimise telematics data management.

Getting to know the IoT Logic Monitor tool

The Monitor tool is part of a bigger product, IoT Logic, a telematics data processing and management solution using a low-code or no-code approach. When developing a product like this, we strive to allow our customers to maximise the benefits and advantages of working with telematics data. It’s important to note that when working with any information, including troubleshooting cases, you might want to observe the process as it goes inside the product to have a complete picture of receiving, processing and transmitting telematics data.

That’s what the IoT Logic Monitor tool does. This tool allows you to check and analyse attributes and tracker parameters in the flow. Its mechanism of storing historical data, as well as debugging capabilities, which are used to work with these values, allow not only to observe the data in real time – something that Navixy’s Air Console does – but also to view the historical data in a convenient format for several devices at once, making data monitoring much easier.

Benefits of historical data storage in IoT Logic

Let’s look at our data storage mechanism and its benefits in more detail.

Speaking of the main advantages of IoT Logic's historical value storage, we can highlight the following:

• Storage of the last 12 values of each parameter and attribute that was calculated in IoT Logic;
• Two repositories for each parameter – with valid values excluding null and including null;
• High performance in working with historical values.

Let’s break it down.

Storage of the last 12 parameter values

The main advantage is that IoT Logic stores not only the 1 last parameter value received from the device but also the 11 preceding values, expanding the possibilities for customers of the IoT Logic product. The user can refer to any of the 12 values using the IoT Logic Expression Language. The values are sorted by device time so that the chronological order of value generation is preserved.

Including and excluding null values

Also, if you need to know the last valid values of a parameter, excluding null values, you can explicitly specify this in the same expression language when writing functions and calculations. For example, you created an automated calculation in Navixy IoT Logic. With the help of the Monitor tool and the storage of valid values, you can understand how your calculations work and affect the data flow without checking it on the recipient's party.

Higher performance thanks to fast data access

Finally, storing data in memory using a distributed cache rather than the database speeds up access to historical values.

Below you can see an example of accessing the oldest valid value of the can_fuel parameter using the IoT Logic expression language:

1 value('can_fuel', 12, 'valid')

Mechanism for storing values in IoT Logic memory

We’ve just mentioned how storing values in memory instead of a database speeds up the process, so let’s look at how it works in more detail.

To better understand it, we can visualise the data storage mechanism. The diagram below shows the process of recording values for both storages – All and Valid.

As you can see, the data is stored not in the database, but directly into memory, which has a positive effect on performance by providing instant access to values. Compared to databases, our method is much faster. This means that the Monitor tool can handle large amounts of data. At the same time, through the distributed cache, which is part of the memory, the data is used by other instances of the IoT Logic flows.

The IoT Logic product uses Hazelcast Map (IMap) as a distributed cache, which complements the memory used and gives the IoT product the ability to scale further.

Differences in the two storage mechanisms

Now let's take a look at the differences between the data recording process for the All and Valid store. In the image below you can see a simplified diagram of both processes:

• The data packet has a necessary value
• The data packet does not have a necessary value

For example, let's take the parameter temp1, which is responsible for the temperature value that the device sends.

In the image above, you can see that if a value from the device comes with a data packet, it will be written to both storages, shifting the previous data. At the same time, their index will change to a higher one. If no value came with the data packet, the Null value will be written to the All storage, while the Valid storage will remain unchanged, since no valid value was received.

Using historical data in the IoT Logic product

We have looked at how data is stored on the product side. Now we will touch on how they are used in the product and how they can be viewed.

Below are the main ways to consume historical values of device parameters in an IoT Logic product:

• Initiate attribute node – to calculate new values
• Logic node – for logical operations and if/else expressions
• Monitor – debugging tool for viewing, analysing and monitoring historical values

In the Initiate attribute node, we can calculate new values based on the received data, calculate average values and rename device parameters. An example of use can be seen in the screenshot below:

In the examples, we can see the calculation of the difference between the current and previous temperatures, as well as the translation of speed from km/h to m/h.

In Monitor you can view historical data in tabular form with real-time updates for several devices in bulk. The table in Monitor looks as follows.

When you hover over a value, you will see a tooltip that shows the generation time on the device and the reception time on the server.

All values are arranged in one table and categorised, which is convenient for viewing and analysing the incoming values and attributes calculated in IoT Logic. Moreover, this data can be uploaded in JSON format for further use on a third-party server or application.

Also, if needed, you can change the number of displayed historical values for all parameters and use the specific value search to track a particular value in the table in real time. When a value is retrieved and displayed in the table, it will be highlighted in colour.

Conclusion: Making data management simple

As you can see, Monitor is a powerful data monitoring and debugging tool that can help you view, analyse and upload historical data for further processing and more in-depth analysis, thus expanding the already great capabilities of the IoT Logic product. It’s worth mentioning that we’re working on the IoT Logic product, always having our customers in mind. We strive to provide them with tools and solutions that give them the greatest flexibility to solve various cases. At the same time, we want to keep it simple, intuitive and visually appealing.