For the Internet of Things, MQTT has become the main data protocol. For connecting devices and cloud applications, this lightweight implementation of the Publish/Subscribe pattern with Quality of Service turned out to be the best choice. Transport telematics, being a part of the IoT world, is also actively transitioning to MQTT.
In this post, we will explain why MQTT is increasingly gaining importance for GPS solution integrators, what technical challenges should be expected during implementation, and how Navixy helps you get around them.
Complex and large-scale projects switch to MQTT first
Today, in transport telematics, MQTT is mainly used in large and multifunctional systems. This is where equipment and applications by different vendors with varying degrees of novelty need to be combined. In scalable projects, it is crucial for such components to be easily integrated and maintained by independent development teams. Therefore, if you are creating such systems, you have probably already come across MQTT or it will happen soon.
If you look at the projects implemented by Navixy partners using MQTT today, they are most often in the following spheres:
- Chain supply management: Large retail chains and production companies require strict compliance with the delivery schedule and transportation conditions—for example, the cargo temperature—from their suppliers. Since the suppliers’ fleets are equipped with a wide range of systems from multiple GPS providers, their data needs to be accumulated from different sources.
- Gig applications and sharing economies: Taxi, car rental, carsharing, and city mobility services need to process large data arrays consisting of machine data and user requests. At the same time, information often needs to be processed in a lightning-fast manner, while servers can be located in different regions.
- Insurance telematics: Calculating insurance premiums and investigating road accident details are two aspects where insurance companies progressively rely on the data collected from dedicated vehicle devices. Meanwhile, usage volume analysis, driving skills scoring, accident reconstruction, and statistical and predictive analytics are separate tasks involving complex processing algorithms. Therefore, IoT data exchange between devices and applications plays a key role here.
- Smart cities, tax, and state regulation: Solving road safety, traffic, and environmental issues in modern cities is associated with the use of signals from millions of sensors mounted on vehicles and infrastructure facilities. This data is addressed in an interconnected manner and forms a single context for management at all levels. Therefore, effective data exchange is required while complying with the laws on its storage and processing location.
Many of these projects are implemented based on NavixyCloud and cloud IaaS, including specialized IoT platforms AWS IoT platform, Google Cloud IoT, IBM Watson IoT platform, Microsoft Azure IoT, etc.
MQTT support by GPS tracker manufacturers contributes in their favor
Naturally, manufacturers of transport telematics devices want integrators to use specifically their products in the largest projects. So, MQTT can be found in new equipment lines more and more often. Such models are now produced on a large-scale basis by DCT, Xirgo, Globalmatix, Teltonika, TOPFLYtech, and other companies.
Since in most cases projects with MQTT turn out to be quite specific, devices with a flexible configuration become pilots for manufacturers. For example, those are 4G gateways capable of connecting to various sensors, operating with the CAN bus, and setting software logic. However, MQTT has gradually appeared at least as an option in other models, even with basic functionality. So, manufacturers use MQTT benefits very rationally, including subscription patterns (topics) and three levels of quality of service (QoS).
Practical challenges in building MQTT-based transport telematics systems
Despite being a convenient and widespread protocol for creating IoT solutions, implementing MQTT in various vehicle devices and transport telematics features requires additional attention from integrators, manufacturers, and developers.
In practice, two factors specifically need to be taken into account:
- The data coming from the devices is heterogeneous. Due to the variety of GPS tracker models, connected sensors, and the vehicles themselves, the data comes in different formats and units of measurement, and requires additional calculations. It even happens that an MQTT protocol has a proprietary device manufacturer’s protocol wrapped inside. Therefore, if the necessary manipulations of the data are not performed beforehand to unify them, IoT application developers will have to solve these tasks for each functional module separately, which negates the main benefit of MQTT as a universal and simple protocol.
- Vehicle IoT devices not only transmit data to applications, but also regularly receive commands from them. To this end, devices implemented not only Publish, but also Subscribe to MQTT mechanisms. The semantics and syntax of commands are largely determined by the device hardware capabilities and their intended use in vehicles. It is more profitable for application developers to think beyond these differences to save time on development and make the system more scalable.
To help integrators in overcoming these challenges efficiently, the MQTT Central module can be integrated to the Navixy platform. It facilitates unified communication between IoT devices and applications.
MQTT Central as a terminal for transport between a system's IoT components
Navixy MQTT Central is an optional platform module that allows integrators and developers to easily arrange the exchange between IoT devices and applications using a common MQTT protocol.
An important benefit of MQTT Central is that the transmitted data and commands can be simultaneously unified; that is, standardized and normalized. This allows developers to prescind from features not critical for the business logic, such as the “zoo” of GPS devices utilized or differences in the vehicle CAN controllers.
Using MQTT Central facilitates the creation, customization, and integration of telematics systems in a shorter time, providing for solutions with high fault tolerance and excellent scalability, as well as compatibility with modern IoT platforms.
Among the extra benefits of Navixy MQTT Central, driven by the internal architecture, the following are noteworthy:
- JSON or XML: data output in the selected protocol with low latency
- REST API and ETL: data uploading to ERP and BI systems
- On-Premise or Cloud with 99.9% availability
Two user cases help illustrate the capabilities of such an approach from different perspectives more clearly.
Case А. Tow truck service and roadside assistance
A system built by a Navixy partner for a major national roadside assistance service may serve as the first and simplest example. The client’s fleet, consisting of tow and repair trucks, was already equipped with solutions by Skypatrol, Concox, and TOPFLYtech. The client needed the partner to develop a customized solution for situational monitoring with data output on screens in four regional dispatch centers. The system used vehicle parameters including location and speed, as well as the status of the vehicle’s availability for a new call.
Thus, the data had to be collected in real time from multiple different devices operating both on MQTT and proprietary protocols, and independently processed at four locations. At first, it was planned to use cross-server data forwarding, which would allow for instant data exchange and would solve the problem of a unified and device-agnostic protocol. However, the use of Navixy MQTT Central and, consequently, MQTT protocol for communication between applications made it possible to accelerate the application development, make the system more scalable (it was planned to launch additional dispatch centers), and fault-tolerant due to the Subscription model with QoS 1 and QoS 2.
Case B. Car sharing and car rental service
The second case demonstrates the benefit of the so-called MQTT topics, when individual components of complex software systems can subscribe to the required data set. That is, using topics, you can determine the subset of data received by a particular application of a large software package.
In this case, a company operating in the car sharing and rent-a-car segments independently engages in the development of key business applications where separate functional modules are created and maintained by different development teams. This segregation is partly driven by the performance considerations and partly by the organizational aspects, since the company has been actively growing due to taking over the competitors.
The company’s fleet, at that time comprising more than 1,500 cars, was equipped mainly with custom-tailored telematics gateways. They had GPS navigation, CAN bus operation, and other sensors, as well as MDVR mobile video surveillance.
The operating part of the business was carried out based on the in-house software platform, while a separate team was responsible for each of its functions:
- Mobile applications with recommendations on the nearest available cars, making orders and payment, and other user interaction aspects.
- Car maintenance with fleet car deliverers and technical staff for preparing the cars based on the information about the remaining fuel, mileage, error signals of the DTC-based self-diagnosis system, etc.
- Responding to emergency situations, including unauthorized use, accidents, damage, and theft.
- Calculation of the trip cost, including scoring drivers for harsh maneuvers and traffic violations.
Each of these modules, in its own way, is an independent and complex task, however, they often use common data from GPS, accelerometers, CAN bus and sensors, video surveillance, etc. Therefore, it was important for programmers to be able to easily get the necessary data and send commands to devices. For example, for timely maintenance, it is important to get the MIL status and error codes from the CAN bus, VIN, and odometer readings, as well as information about speed, seat belt, accelerator pedal position, and engine speed for driving skills scoring.
The use of Navixy MQTT Central allowed these tasks to be implemented in the most efficient way. The development teams were able to configure their applications to receive the necessary data and send commands to the devices. Moreover, they saved time by combining the old systems and the current one into a common space, opted out of working with devices at a low level, and were able to focus on the development of business functionality. MQTT benefits also provided for a high reliability of communication between geographically distributed servers and further scalability of the system.
MQTT importance for building modern transport telematics and IoT systems
Both MQTT’s inherent functionalities and the growing popularity of this IoT protocol itself are forcing manufacturers, developers, and integrators to actively switch to it. The recently implemented projects on vehicle and mobile assets monitoring are clearly indicative thereof. Over time, more MQTT-based GPS systems, being not only functionally complex, but also large-scale, will be created.
The MQTT-based products and solutions are cheaper to develop and implement. Deployment and customization are faster, while development and support get easier. At the same time, there are always aspects associated with the distinguishing features of the MQTT implementation in GPS devices and specific user cases. Navixy MQTT Central allows for eliminating these features and focusing on the substantive part of creating scalable and reliable solutions. MQTT Central functionality is available in all three Navixy supply options and is easily integrated with mainstream cloud IoT platforms.
