In recent years, Solace has established itself as a leading technology supplier to the connected vehicle market. Our customers include leading car makers, auto parts manufacturers, rail companies and air traffic agencies like the FAA.
While these all make great case studies, nothing beats a live demo. Especially if it ends in a car crash. Who can look away from a car crash?
With that in mind a colleague and I recently put together a demo that simulates simple, visceral examples of how our customers use Solace technology in connected vehicle use cases, including an actual (toy) car crash.
Architecture
First, I’ll summarize the major components of the demo:
- Connected cars: The remote control car with the phone strapped to its roof represents a car with embedded sensors and 4G connectivity. The demo can have any number of cars, differentiated with unique VINs.
- The message broker: All cars and apps connect to the message broker and publish or subscribe in whatever message format is most appropriate, with the broker performing all routing and protocol translation automatically. In this demo, MQTT is used for all vehicle to broker traffic, MQTT is also used to and from the controller application, Solace message format (SMF) connects the analytics app, and REST/JavaScript connects to the web-based event history.
- Controller apps: This app is primarily to show outbound control and location tracking of the remote vehicle. It allows us to view the car’s location on a map, remotely honk the horn, start the engine, toggle the lights and more.
- Back-end systems: Most data collected from cars is consumed by storage and analytics applications that will archive or act upon the real-time data.
In most production deployments, there is a second layer of message brokers between the devices and the back-end systems so edge brokers can scale horizontally to handle any number of connected devices, with core data systems protected by multiple layers of security. In this simple demo, we have forgone the second layer of message brokers.
Major Message Patterns
Different types of message flows create different stresses on a connected car infrastructure, and this demo highlights some of those patterns.
Pattern 1: Data Collection
Pattern 1: Data CollectionThe video focuses primarily on remote control of the car, but the full demo includes real-time tracking of simulated vehicle sensor data via the controller apps and back-end systems. This is the most basic flow of information in a connected car application.
| In the Demo | How it Works | In the Real World |
|---|---|---|
| The car simulation app publishes data from the smartphone sensors every five seconds, which the message broker routes to relevant downstream subscribers. The data collected includes location, acceleration, magnetic field and more, simply so the demo has something to analyze and map in the receiving systems. When we do this demo for customers, we show a web display capturing all events as they are received, and an InfluxDB analytics engine doing time series analysis of the data streams. | The car simulation app opens an MQTT connection to a Solace message broker and publishes messages with persistence (QoS 1) so messages are never lost, even if the car is temporarily disconnected. Downstream systems connect to the broker using their most convenient protocols (in this case MQTT, and Solace message format) and the broker routes the information to each subscriber, automatically performing any necessary protocol transformation. | In our demo, we’re connecting one car through one broker to unladen back-end systems. Pretty simple. In a production setting there may be tens of millions of cars connected, gigabytes of data being sent per vehicle, regular volume spikes (e.g. during rush hour), and dozens to hundreds of downstream applications requesting different subsets of the data. Handling these data streams at scale, buffering through any outages and slowdowns, eliminating the need for messaging bridges and automatically managing HA/DR is what differentiates Solace over other MQTT brokers. |
Pattern 2: Remote Vehicle Control
Pattern 2: Remote Vehicle ControlThe video shows several examples of commands being sent from the controller app to the car for remote vehicle control. The two most common scenarios for this message pattern are for consumer smartphone applications that have limited control over the car (for example, start car, lock/unlock, open sunroof, turn on climate control, etc.) and for the car manufacturer or 3rd-party service provider to send instructions to change something in the car’s configuration or operations. For example, upon driving across the US/Canada border the back-end may reconfigure the car to automatically turn on daytime running lights (which are required by law in Canada but not the US) and present the option to switch from miles to kilometers on the dashboard.
| In the Demo | How it Works | In the Real World |
|---|---|---|
| You can see many examples of remote vehicle control displayed in the video, including control of the engine, horn, lights, and interior ambience lighting. In each case, the remote user alters settings with the smartphone application, and the changes occur in the car. To show the difference between non-persistent and persistent messages, the controller application sends ambience messages with persistence, which means only those messages will be saved for later delivery when we temporarily disconnect the car. | The controller app publishes a message addressed to a topic that includes the unique VIN number of a vehicle. Each vehicle-simulation app subscribes to all messages directed to its VIN using wildcards. For example for VIN ABC123, the vehicle app subscribes to ABC123*. It’s as simple as that — the back end publishes, the vehicle subscribes, and the broker routes messages to the right destination. In the demo, only ambience messages are persistent, so if the target car is offline, the broker stores those messages until the car comes back online. Messages like honking the horn, unlocking the door or switching on the lights are non-persistent, because those commands are only relevant when requested. You don’t want the car to unlock an hour later, for example. | Once again, directing a single message to a single car is easy. Things are way more challenging at the scale of tens of millions of connected cars. Solace has developed a unique tiered architecture which routes messages between endpoints based only on the topic, without a back-end application having to know which broker a specific car is connected to. Most other MQTT brokers are standalone, which means the application has to know how to direct messages. For example, let’s say ten million cars are connected to 100 MQTT brokers. If the unlock service needs to send a message to a specific car that is connected to message broker 37 of 100 that back end app has to somehow know which broker to direct the message to. This is not trivial, either you have to configure all brokers to know about all the connections on all the other brokers (which won’t scale) or you have to set up dispatch brokers that keep track of all connections and redirect all messages. With Solace, the unlock message is published to a VIN, and the self-organizing infrastructure knows how to directly route to that car. |
As an aside, I found it interesting to learn that because car manufacturers don’t want to run down the battery of cars that are switched off, they don’t leave on-board computers listening for messages. Instead, most send a special out of band alert to the car’s modem via SMS to “wake up” the car and have it connect back to the service to pull any data that is waiting for that vehicle. This is subject to the unreliable performance of SMS services, and often introduces long delays. For example, it can be quite an unsatisfying experience for the consumer clicking unlock on their smartphone to wait tens of seconds for an SMS message to reach their vehicle. As more cars get bigger batteries and leverage lower power semiconductors, the standard configuration for many new vehicles is “always on.” This eliminates the limitations of the SMS connection, and requires much more scalable infrastructure that can accommodate all of those cars maintaining connections all the time.
Pattern 3: High-Priority Events/Alerts
Pattern 3: High-Priority Events/AlertsMost car manufacturers need a channel for important two-way messages. For example, some back-end service might want to send critical configuration changes for a vehicle, alert the driver about an emergency weather or navigation situation, or have the car’s camera systems look for an amber alert license plate. On the other side of that equation, a driver or vehicle might want to initiate a request for urgent assistance in the event of an accident of medical emergency.
| In the Demo | How it Works | In the Real World |
|---|---|---|
| At the end of the demo, we drive the car quite recklessly into a wall, which triggers a priority event to the controller applications alerting the user about the crash. In our scenario, a human alert is the outcome, but it could also trigger notification to local police, an app like Waze, or emergency services. | The car simulation application monitors the smartphone accelerometer for changes beyond a configurable threshold, which is how the application identifies a crash vs. sudden acceleration or a change in direction. Exceeding that threshold publishes a persistent message to the message broker, which delivers it to downstream applications. That message displays an alert on the controller app, and is stored as an event in the other systems. | Once again, the challenge is reliably performing these actions at scale with very fast response times. Our customers choose Solace because our technology lets their infrastructure scale effortlessly to handle large connection counts and huge data volumes, and simplifies management of end-to-end message delivery which results in greater uptime and fast, efficient delivery of these important and urgent messages. |
Successful Connected Car Infrastructure is all about Scale and Flexibility
As you can see, while the demo is simple, what it represents is anything but. How our customers use Solace technology to accomplish these patterns at scale is what differentiates our solution from the other options available. We have heard from several of our customers that they simply couldn’t get other MQTT brokers to work at all beyond fairly modest connection counts and that the architecture proposed by other vendors resulted in significant complexity. Solace uniquely scales to tens of millions of cars and allows all message routing to occur entirely within the infrastructure (and not in the applications) which makes apps simpler to build, more maintainable and faster to deploy.
If you’re struggling with any of these issues, we’d love the chance to come see you so we can go into detail about how our customers are solving their connected vehicle challenges with Solace. We’ll even crash our demo into your conference room wall, live, just for fun!
If you’re a techie who’d like to learn more about the demo, which is available in Github so you can play around and customize it, click here.
Subscribe to Our Blog
Get the latest trends, solutions, and insights into the event-driven future every week.