Why MQTT Is Essential for Building Connected Cars

The automotive industry is embracing the idea of inventing the truly connected car. They see the opportunity and benefits of leveraging telemetry data gathered from vehicles to create new revenue opportunities and build more robust customer experiences. However, successfully launching a connected car service that can scale to support millions of cars across vast distances and in a whole range of environmental conditions can present some serious challenges.

For most connected car services, bi-directional communication between the car and the cloud is a requirement, even though some edge processing can make connected cars more independent of the cloud. Connect vehicles send telemetry data to the cloud and enable applications like predictive maintenance, assisted driving, emergency response, etc. Similarly, the vehicle needs to be able to receive messages from the cloud to respond to remote commands like remote door locking and unlocking, remote activation of horn or lights, changing traffic environments, etc.

Implementing the car to cloud communication could be handled with standard web messaging protocols like HTTP. However, given that the IP addresses of vehicles would be unstable as they shift from cellular network to network, the cloud to car communication may require a different kind of communication system.

Besides the bi-directional messaging challenge, there are a number of other unique technical challenges for connected car services:

1. Connectivity is often unreliable as a car can move through network blind-spots. The process of reconnecting with the cloud can result in slower response time and lost messages.
2. Network latency can become an issue again due to cellular network performance. For a responsive user experience, the car must be able to deal with network latency.
3. The cloud platform needs to be able to scale up and down to support millions of vehicles that connect at various points of time.
4. A connected vehicle needs to operate in a trusted environment so hackers can’t take control of the car.

Many companies have attempted to implement a connected car service using HTTP and SMS. To establish a connection with the car, the cloud platform would send an SMS to the vehicle that includes a URL to initiate an HTTP request/response connection. However, this pattern has proven to be unreliable and typically results in sluggish user experiences. In some cases, a remote command being sent from a mobile phone app would take up to 30 seconds to complete the request. 30 seconds to unlock your car doors from a mobile app is not the type of user experience car companies want to deliver to their customers.

A New Communication Architecture for the Connected Car

Car companies, tier 1 suppliers and startups needed to find a new style of architecture for their connected car services. Many of these companies are now turning to the MQTT publish/subscribe architecture for implementing their services. MQTT has become the defacto IoT standard for connected devices and moving data from the device to the cloud.

It turns out MQTT addresses many of the challenges of creating scalable and reliable connected car services, for instance:

1. MQTT allows for a persistent always-on connection between the car and the cloud. When a network connection is available, a vehicle will publish data to the MQTT broker and will receive subscribed data from the same broker in near real-time. If a network connection is not available, the vehicle will wait until the network is available before attempting to transit data. While the vehicle is offline, the broker will buffer data and will immediately deliver the data as soon as the vehicle is back online.
2. MQTT implements three message delivery quality of service levels: at most once, at least once and exactly once delivery. This makes it possible to create connected car services that function in a reliable manner. MQTT’s advanced message retention policies and offline message queuing are essential to accommodating network latency and unreliable mobile networks.
3. Cars running MQTT clients aren’t addressable over the internet. The MQTT client running on each car is responsible for establishing a secure persistent TCP connection, using TLS, with the MQTT broker in the cloud. This means no public internet endpoint is exposed on the car, so no one can directly connect to the car. This makes it virtually impossible for a car to be directly attacked by a hacker on the internet.
4. MQTT brokers can be deployed to cluster nodes running on a private or public cloud infrastructure. This allows for the broker to scale up and down depending on the number of vehicles trying to connect.

Getting Started with MQTT

MQTT addresses many of the issues of building a connected car service. Car companies such as BMW are already using MQTT to provide reliable messaging for their car-sharing application. If you’d like to learn more about using MQTT to build connected vehicles, check out this resource.

Written by Ian Skerrett, Head of Marketing at HiveMQ.

• Artificial Intelligence
• Asset Tracking
• Autonomous Vehicles
• Connectivity
• Edge Computing

• Artificial Intelligence
• Asset Tracking
• Autonomous Vehicles
• Connectivity
• Edge Computing