While technology like the connected car has been hyped for years, the growth for all Internet of Things (IoT) applications across all sectors is growing exponentially. Gartner projects all of these connected things will grow from 4.9 billion in 2015 to 25 billion by 2020, and this includes cars. By looking at connected car functionality and architecture, we can get a better understanding of all IoT platforms. To simplify, there is a fairly consistent set of IoT components—sensors, mobile or device apps, big data stores, data science algorithms, and analytical output with a platform as a service (PaaS) layer underneath.
Behind this type of dashboard (see info below), predictive analytics and machine learning algorithms can incorporate driving behavior and sensor data to improve maintenance and mileage, route us to gas or charging stations, predict destinations, and even get us a better deal on car insurance. The same IoT system patterns apply to every industry—energy companies will predict issues before they happen on the power grid, manufacturers will optimize supply chains and engage differently with consumers, and industrial equipment will become more efficient.
The Connected Car—Functionality and Architecture
The demo system ultimately predicts a driver’s destination and determines if they can get there on the current tank of gas. Below, the connected car functionality and architecture is laid out in a diagram and explained further in the context of a world-class architecture, showcasing several Pivotal technologies.
Figure 2: Connected Car and IoT Architecture
Here is how it works:
- A dongle plugs into the car’s on-board diagnostics (OBD II) port, which has been on every U.S car made since 1996. Among other potential metrics, the dongle will interface with the car to capture RPM, speed, fuel level, fuel usage rate, acceleration, and temperature via a low level API using codes called parameter IDs (PIDs).
- An iOS application will connect via Bluetooth to the dongle and use a TCP socket to make requests and receive responses for each PID, looping through the desired set of PIDs. The phone enriches this data with GPS information (LAT/LONG) and sends the payload as an HTTP post, in one second intervals, over the cellular network to servers in JSON format.
- On the server, the Spring XD’s distributed runtime service is used for ingest and makes the development process very simple with about 47 lines of Java code and 16 lines of XML.
- First, an HTTP listener looks for posts and passes them to the transformer as JSON.
- This module adds a GUID and timestamp using the Spring Integration transformer.
- Designed as a distributed application runtime for big data, Spring XD then passes the JSON object to a RabbitMQ messaging service.
- For those unfamiliar, Spring XD builds upon Spring, Spring Integration, Spring Batch, Zookeeper, and other established technologies to make it easier to build big data and data science-driven applications.
- Data Science Algorithms and Processing:
- First, a python process picks up the data to add predictive values. As the driver’s journey starts, it predicts the destination of this journey based on the rich stream of information stored during previous journeys including RPM, acceleration, instantaneous fuel usage, day of the week, and time of day.
- As the journey is underway, the predictions are refined.
- For each message on the journey, a list of predictions are created, each with a target endpoint location in longitude and latitude, a value for remaining range given my remaining tank of gas (or electric charge), and the probability of the prediction.
- The JSON object is sent back to RabbitMQ with this information.
- Also, the data science model gets trained from the history of stored journeys on a periodic basis as part of an offline, batch process. The resulting metadata is stored in the file system and used to evaluate real-time streams of where the driver is headed.
- From RabbitMQ, the information follows two paths.
- First a message is taken off of the queue, streamed into a file and written to a persistent store, like a file system or Pivotal HD running with or without Pivotal HAWQ (SQL on Hadoop, soon to be open sourced).
- The stream is also tapped and written to Pivotal GemFire (soon to be open sourced) for dashboard queries, basically being used as a real-time data cache.
- The dashboard uses a REST API to communicate with Pivotal GemFire and get information in real-time, as it changes and is updated every second.
- The dashboard itself (shown previously and below) shows the car on a map with the current location, speed, RPMs, coolant temperature, fuel level, potential destinations by longitude and latitude, and the probability that those destinations will be the final destination