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.
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!
Controller App
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
As you see in the video, the demo is set up as two Android phones connected over an internet connection to a PubSub+ message broker, which can be in the cloud, in a datacenter or on a local laptop. We have a web tracker which also subscribes to the same vehicle event messages receiving them in Solace message format (SMF) through our JavaScript API. A Java process receives those messages in SMF using our native Java API, then directs the data into an Influx DB to represent a typical big data analytics back-end.
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.