The automotive industry is embracing the idea of building a connected car. They see opportunity in using telemetry data from vehicles to create new revenue opportunities, and to build a better user experience. However, implementing a connected car service that can scale to support millions of cars can present some challenges.
For most connected car services, there is a requirement for bi-directional communication between the car and the cloud. Cars will send telemetry data to the cloud and enable apps like predictive maintenance, assisted driving, etc. Similarly, the car needs to be able to receive messages from the cloud to respond to remote commands, like remote lock/unlock door and remote activation of horn or lights.
Implementing the car-to-cloud communication could be handled with scalable web technology, like HTTP requests. However, implementing the cloud-to-car communication would require static IP addresses for each car in the system. This is not a reasonable assumption since cars will move through cellular networks where there is no single IP address for each device.
Besides the bi-directional messaging challenge, there are a number of other unique technical challenges for connected car services:
- 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.
- Network latency can become an issue again due to cellular network performance. A responsive user experience must be able to deal with network latency.
- The cloud platform needs to be able to scale up and down to support millions of vehicles the connect at various points of time.
- 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 included a URL to initiate an HTTP request/response connection. However, this pattern has proven to be unreliable and typically results in slow user experience. In fact, 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 Architecture for 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 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:
- MQTT allows for a persistent always-on connection between the car and 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 transmit data. While the vehicle is offline, the broker will buffer data, and as soon as the vehicle is back online, it will immediately deliver the data.
- MQTT implements three message delivery quality of service levels, including 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.
- Cars running MQTT clients are not 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.
- MQTT brokers can be deployed to cluster nodes running on a private or public cloud infrastructure. This allows 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. For those companies wanting to get started using MQTT, there are lots of information available and solutions available, including open-source brokers HiveMQ, Eclipse Mosquitto, and VerneMQ. In the future, you should expect most cars to be sending their connected data using MQTT.