This demo (here on GitHub) illustrates how Solace PubSub+ is being used in real-world connected car scenarios, highlighting both data collection and remote vehicle control capabilities. The demo consists of several components:
- A car-simulation app running on a smartphone acting as the vehicle’s sensors
- A controller app running on a second smartphone that send commands to the vehicle remotely
- A PubSub+ message broker running either in the cloud or on a laptop
- Back-end applications that capture and analyze activity from the connected cars
Obviously this an extremely simple example, intended to demonstrate how PubSub+ is deployed with our large corporate and government clients. These customers have validated that PubSub+ can handle millions, tens and even hundreds of millions of connected vehicles for large-scale data collection and remote vehicle control. This is a non-trivial challenge and requires architectural features and capabilities not available in most message brokers. You can learn more about our connected vehicle capabilities at solace.com/connectedvehicle
Watch the demo, then read on to learn what’s going on behind the scenes.
Connected Car Simulator
The app representing the car uses the phone’s sensors to collect location and accelerometer data that is published to a PubSub+ message broker. It also uses the phone’s screen and speakers to simulate actions like starting the car and honking the horn. The app also generates a crash alert message if it detects an acceleration higher than the (configurable) amount specified in field labelled “G Level in M/S”. The demo doesn’t really require you to physically attach the “car app” to physical model car, but it’s a lot more fun that way!
The controller app represents a consumer’s remote vehicle control app (start car, unlock door, change ambience lighting), as well as the carmaker’s remote services (unlock door, turn on lights). This app is also used to receive crash alerts and show the car’s location on a map.
Behind the Scenes
In this demo the apps use MQTT QoS 0 (non-persistent) messages for most interactions, such as the collection of data and sending of commands like starting the car, sounding the horn, turning on the lights and unlocking the door. These are best effort exchanges of information where the driver or a remote support rep either wants something to happen right away, or not at all. For example, you wouldn’t want a car unlock message that couldn’t get through due to bad signal to be delivered to your car some random time later whenever the 4G signal improves.
The demo uses MQTT QoS 1 (persistent messages) to change the car ‘ambience’, which in the demo is the background color of the car simulator screen. If you disconnect the vehicle sensor app, then send the ambience command from the controller app, the PubSub+ message broker queues the message until the car comes back online, at which point the color changes on the vehicle app.