Enabling the Connected Car with HiveMQ
Introduction
The automotive industry is at the forefront of a digital revolution, and according to McKinsey, by 2030 about 95% of new vehicles sold globally will be connected, up from around 50% today.
As cars become more connected, automakers and connected car platform providers are using IoT technology to drive revenue by providing new services and gathering valuable telemetry data from vehicles. From efficient fleet management and car-sharing to predictive maintenance and advanced driver assistance systems, the possibilities for the future of mobility are endless.
The ride of the future is just beginning - organizations need methodologies and technology partners that will allow them to scale, innovate, and provide reliability on the front and back end of their connected car deployments. Let’s explore how HiveMQ is powering the evolution of connected cars as trusted technology partners.
Customer Expectations: Fast and Reliable
Customers are starting to embrace a more advanced connected car experience. They appreciate the benefits of increased safety, more intuitive and responsive HMI and more efficient maintenance.
However, customers have high expectations of their digital interactions. Driven by the user experience of smartphones and the web, customers expect a fast and responsive user experience. Unlocking a car door with a mobile app should take sub-seconds, not 30 seconds. Throughout a trip, customers expect in-car features or car sharing services to be fast and reliable; no matter the location or peak customer demand.
Safety is also a key concern for customers and OEMs. For safety critical features, such as autonomous driving, OEMs and government regulators require a consistent and reliable user experience.
Fast and reliable are two features that need to be designed into all connected car services.
Technical Challenges Building a Connected Car Platform
A connected car platform is the software infrastructure supporting any new connected car service. It includes the software technology required to connect vehicles with the cloud, transmit data and events between the vehicle and the cloud, and integrate the telematics data with existing back-end IT systems at an OEM or supply chain partner.
Building a connected car platform comes with some unique technical challenges. The movement of the vehicles and the sheer number of simultaneous connected devices create some unique architectural issues, including:
Network connectivity is often unreliable. Vehicles connected to a cellular network will move through network blind-spots that can interrupt the connection between a vehicle and the cloud. Reconnecting the vehicle with the cloud can result in slow response times and lost messages.
Network latency. Similar to network blind-spots, network speed and latency can create inconsistent flow of data between the vehicle and cloud. A responsive and reliable user experience should minimize the impact of network latency.
Instant bidirectional data movement. A connected car needs to be able to move data from the vehicle to the cloud and vice versa. A challenge with vehicle to cloud communication is the sending of information can be initiated by the cloud or a vehicle. This means traditional client request/response architectures are not suitable for connected car platforms that need to communicate with millions of connected cars.
Scaling up and down to support millions of vehicles. The supporting cloud platform needs to be able to accommodate millions of simultaneous connections in a reliable manner. The customer experience can’t be slowed due to peak usage periods.
Securing the connected car. A connected vehicle needs to operate in a trusted environment. It is imperative hackers can’t get control of any vehicle.
Integration with enterprise systems. The IoT data from a connected vehicle needs to be integrated with the IT systems of OEM and supply chain partners. Many of these systems will be custom developed or proprietary vendor solutions. The flow of information between the vehicle and the IT system is often bidirectional so the integration needs to support bidirectional data movement.
HiveMQ and MQTT: A New Architecture for Connected Car
A new type of architecture is required to address many of the challenges faced when building a connected car platform. Existing web technologies are not well suited for unreliable networks and bidirectional data movement. The architecture pattern of sending an SMS with a URL to initiate an HTTP connection between a vehicle and cloud does not create a fast, reliable user experience. SMS can be unreliable and creating a new HTTP connection for each vehicle to cloud interaction results in slow performance.
HiveMQ introduces a new publish/subscribe style of architecture for the connected car platform. Based on the IoT standard MQTT, the HiveMQ enterprise platform implements the architectural features required to build and deploy a scalable, reliable and secure connected car platform.
Architecture Features
Persistent Always-on Client Connection: The MQTT publish/subscribe architecture allows for each vehicle to be decoupled from other vehicles and back-end services and enables a persistent, always-on push connection to the cloud. When a network connection is available, a vehicle will publish data to the HiveMQ 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 HiveMQ broker will buffer data and as soon as the vehicle is back online immediately deliver the data.
Guaranteed and Reliable Data Delivery: HiveMQ 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. HiveMQ’s support for advanced message retention policies and offline message queuing are essential to accommodating network latency and unreliable mobile networks.
Secure non-addressable clients: 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. HiveMQ supports industry security standards, like TLS, to ensure communication from the vehicle to cloud is encrypted.
Elastic Scalability and Auto Heal: HiveMQ is architected to automatically scale up and down the number of cluster nodes required to service millions of connected cars. HiveMQ is based on a masterless cluster architecture that allows device connections to be distributed across the cluster nodes. This means the user does not see any change in user experience when nodes are started or stopped since the car can resume its session on any of the remaining cluster nodes. HiveMQ integrates seamlessly with all major load balancers so cars don’t require any knowledge about HiveMQ cluster nodes in the cloud.
Open API and Extension Framework: HiveMQ delivers an open API and extension framework that makes it possible to integrate HiveMQ and the vehicle telemetry data with existing enterprise IT systems. Developers can create custom extensions that enable bidirectional data movement between existing proprietary and commercial systems, HiveMQ and a vehicle. The extension framework can also be used to integrate enterprise security systems with HiveMQ to enable permission policies for communication between the car and cloud.
Deploying Connected Car Platforms
A connected car platform is typically deployed to a private or public cloud platform that needs to scale to meet the demands of millions of vehicles. There are a number of issues that need to be addressed to operate this type of platform, including:
Remote debug and troubleshooting. If a car becomes non-responsive to messages or is transmitting erroneous messages there needs to be a way to remotely debug and troubleshoot the interaction between a specific vehicle and the cloud platform.
Data privacy regulations. Connected cars will operate in different countries and even cross country borders that may have different data privacy regulations.
Data ownership. Many OEMs and service providers will want to maintain ownership and control of the data created by a connected car.
Lifespan of the vehicle. A vehicle lifespan may last 15-20 years. Therefore, control of the APIs between the vehicle and the cloud platform need to remain in sync and be consistent.
HiveMQ addresses many of these issues with a set of system administration and management tools and a flexible deployment architecture.
Real-time fleet monitoring: HiveMQ control center console allows administrators to monitor a fleet of connected vehicles. An overall summary dashboard gives an operation team the complete real-time overview of the HiveMQ broker cluster and general system health. Administrators can use the HiveMQ control center to monitor real-time data between the vehicle and the cloud platform. An administrator can query the status of each vehicle, remotely disconnect a vehicle and reset the MQTT message subscriptions for a vehicle.
Remote Debug and Trace: For remote debugging, HiveMQ can initiate trace recordings that show the interaction between a vehicle and the cloud platform. This allows administrators to identify and correct issues or bottlenecks in the system.
Multi-Cloud Strategy: HiveMQ embraces a multi-cloud strategy to provide flexible deployment options. This is especially important for companies that need to have control over the proximity of the data processing and data storage. HiveMQ can be deployed to public cloud providers (AWS, Microsoft Azure and GCP), private cloud native orchestration platforms (OpenShift, DC/OS or Kubernetes), and native on-premise deployments (Linux, Windows and OS X).
Based on Industry Standards: HiveMQ is 100% compliant with the MQTT specification, an OASIS and ISO IoT standard. Compliance to a standard ensures the API or interface between a vehicle and the cloud is not a single vendor solution. This is especially important for vehicles that have a lifespan of 15-20 years.
