A Peek Under the Hood of The Connected Car: What It Does & How It Applies to IoT Systems

March 2, 2015 Adam Bloom

featured-connected-carWhile 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. As an example, the connected car dashboard below will be demonstrated this week at Mobile World Congress (see booth info below).

Behind this type of dashboard, 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.

Figure 1: Dashboard showing real time speed, RPM, coolant temperature, and fuel.

Figure 1: Dashboard showing real time speed, RPM, coolant temperature, and fuel.

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

Figure 2: Connected Car and IoT Architecture

Here is how it works:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. The dashboard (see additional screen shot below) serves insights and is built with HTML 5, Yeoman.io, and Angular.js. It is worth noting that JavaScript was, by far, the largest codebase in the entire project. The only other custom code was with the transform and Python pieces, as Spring XD is mainly configured.
    • 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.
image01

Figure 3: Dashboard with real-time, predicted, possible destinations on the right side.

Scaling the Architecture and Learning More

While this demonstrative architecture was delivered as a single node model, it was designed to scale to 100,000s of clients, millions of messages per second, and 100 GB per minute. Each module within the Spring XD runtime can scale to more instances, RabbitMQ is highly scalable, the underlying platform as a service is also designed to scale, the file system can operate on Hadoop/HDFS, and Pivotal GemFire‘s in-memory, distributed model is built to scale.

You can learn more about the mobile functionality, data science, predictive models, and architecture as well as how it applies to your industry in this video or at the Mobile World Congress in Barcelona from March 2-5, 2015. You can find us at:

  • Demonstrations and Conversations: Hall 3, Stand 3D10—Airwatch/VMware Booth
  • Telco 2.0 – Modernizing The Industry Through The Cloud: Tuesday Mar 3 @ 11am, Business Innovation Track at the Airwatch Booth, Hall 3, Stand 3D10
  • Billions of Sensors, Devices, Apps and Machines Managed by One Platform: Tuesday Mar 3 @ 5:30pm, Business Innovation Track at the Airwatch Booth, Hall 3, Stand 3D10
  • Consumer-grade Mobile Apps in the Enterprise: Wednesday Mar 4 @ 12:30pm, Business Mobility Track at the Airwatch Booth, Hall 3, Stand 3D10

For more information on Pivotal cloud, PaaS, data, application, data science, and mobile applications, visit the Pivotal blog or website as well as the Spring XD and RabbitMQ sites.

About the Author

Biography

Previous
First European Cloud Foundry Summit Comes to Berlin
First European Cloud Foundry Summit Comes to Berlin

As cloud com­put­ing, mo­bile, and in­ter­net of things technologies impact industries on a global scale, t...

Next
On DevOps: A Cloud-Native Government—What it Takes
On DevOps: A Cloud-Native Government—What it Takes

This post provides a summary and an additional perspective of the recent FierceDevOps article published by ...