In the first post in this three-part series, our team at VMware’s Open Source Technology Center explored open source IoT projects with a focus of supporting Automotive IoT. Not finding a single open source project that met all our needs, we set out to build from scratch a proof of concept solution to better understand the nuances and complexities of the task. This post describes the working automotive IoT application that we engineered.
First, though, a quick word about use cases because automotive IoT is rich in this regard.
Insurance companies, for example, want to be able to track driving behavior to more accurately adjust premiums. Individual drivers may also be interested in “My Driving” data for expense report generation and to know more about their driving habits, including:
- Trip start and end points
- Distance driven
- Speed of driving
- Hard braking and acceleration
- Fuel consumption
- Weather conditions
- Crime risk
Rental car companies, delivery services and other fleet owners have similar concerns. All of these groups are also interested in data that helps with preventative maintenance.
City planners want to know where and when both traffic jams and speeding occurs but need to preserve driver and vehicle anonymity. Automotive IoT data can provide insights into how best to deploy scarce resources, address road repairs and plan future road works. Meanwhile, mapping companies and providers of any kind of analog mobile service are interested in both spatial and temporal traffic patterns.
In building our proof of concept, we primarily wanted to explore importing, reading, managing and analyzing data. We weren’t as interested in sending directions back to the automobile, as you might if you were developing an autonomous vehicle system. There’s plenty to learn just from developing a highly mobile open source data delivery system for the network edge.
To mimic the resource-constrained environment of an automotive edge, we chose a Canakit Raspberry PI 3B as our base unit for hardware. This uses an ARM-based processor with 1 GB RAM, a 32 GB SD card and comes with both Bluetooth and Wi-Fi built in. On-Board Diagnostic (OBD) sensors were then plugged into it directly from our car’s internal OBD unit in addition to a discrete GPS sensor. We used a small LCD display to make some configurations in the car. Alternately, a laptop could be used to run the edge code.
The system architecture we designed resembles the standard edge model we described in our first post. We developed the source code in Python thanks to its ease of use and the availability of support libraries. The source code, accessible at Sample Automotive IoT, has car edge (the code that tackles collecting and processing vehicle sensor data and transmitting to the cloud) and cloud application directories. We created three discrete automotive IoT applications: Insurance, My Driving and Smart City.
Car edge code: While the GPS code was inspired by GPS code, to connect to the OBD sensor we used the OBD library. Configuration information, such as vehicle-ID, vehicle type, hard braking and acceleration thresholds and other application-specific endpoint information, was captured in a config.yaml file at the edge. We used in-memory data persistence and a sliding window to analyze the sensor data to extract events of interest such as slow-downs, speeding, hard brakes and hard accelerations, total distance driven and fuel consumed.
Periodically, we persisted the data to the filesystem to prevent loss of data when the car (consequently the edge node) was shut off. The edge application transmitted events of interest to the various cloud endpoints when internet connectivity was available. Virtually the same sensor data supported all three transportation use cases; however, the data transmitted for each varied slightly, the most significant of which was the elision of personally identifiable information (vehicle-ID and driver-ID) for the Smart City application. Significantly, given our edge maps to a single vehicle, edge storage and compute demands were minimal.
Cloud application code: The three applications were kept distinct, each comprised of a database, a REST endpoint for the edge nodes to connect to, another for the database and the third that supported a simple web user interface that displayed all recorded events. The applications themselves are flask-based and take into consideration the threat of cross-site scripting. Given their proof of concept nature, we opted for data persistence to use an SQLite database.
Did it work? What did we learn?
While it was fulfilling to build a functional system, the sample code does not address software updates nor device registration, nor does it incorporate adequate testing or documentation. But, our Linux Conf AU 2019, NZ presentation, Multiple Birds with One Linux, IoT in the Automotive Space, left the audience eager to explore Automotive IoT. We certainly appreciate the value of building IoT frameworks that deal with common tasks to reduce the barrier of entry for developing IoT applications such as software updates, device registration and security.
Our final blog in this series addresses what’s next for automotive open source IoT. Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for when that piece goes live.
