.svg){kind=small}
We have seen a sharp rise in the number of queries about how APIs for connected cars work and what to expect. To answer these questions, we decided to perform a field test with a connected car that can be accessed through HIGH MOBILITY’s Auto API — a standardised connected car API. In this post we’ll be sharing with you some of the experiments we performed with a connected BMW i3 in Tallinn, Estonia so you can see first-hand what working with car data via a real vehicle really looks and feels like. Throughout the day, we ran an application to gather the car’s data via our Auto API.In this post, we’ll be explaining what information was sent and how frequently, what it looks like when data is accessed through our standardised interface.
Short Auto API Background
Though a basic connectivity for cars on our roads have existed for more than two decades, there have hitherto been no APIs which offer access to their data. HIGH MOBILITY was founded on the idea that connected cars will play a huge role in the future of mobility, and that it should be possible to interact with all of them in the same way. From the beginning, we saw a great deal of interest from developers in what we were doing, which prompted us to build the APIs and tools they needed in order to work with connected vehicles. In addition, we worked tirelessly with carmakers to provide previews through our vehicle emulators and simulations — long before production data became available.
Setting up the permissions to query BMW CarData
In order to see in real-time the latest data available on the car, we wrote an application to fetch new car data from the i3 through our platform every five seconds, and saved the resulting JSON responses. Each query asked for data corresponding to all of the permissions which were selected in the “Permissions” section in Production Mode.
This arrangement allowed us to see the latest data the car had relayed. The application was configured almost exactly as it would have been had it been gathering data from an emulator on our platform. The only difference was that the application was initialised with production API credentials.
Here is the route we took. It was composed of many short trips.
Parsing the vehicle data
In the morning, we hopped in the car and ran the program. We began running errands, while keeping a watchful eye on the responses from our servers. Though we are intimately familiar with the theory, we had many questions about how the API data is updated by the car during day-to-day activities.
How frequently would the data change?
Would the data update at a regular interval, either in terms of time or odometer reading?
If updates are irregular, what triggers them?
As we ran our errands — buying snacks at a gas station, heading to a carwash, and meeting friends for lunch — we began to determine how frequently data flowed from the roof-mounted antenna or, more accurately, what triggers a BMW to upload its latest vehicle status.
Here is a portion of one of the responses:
For the first few hours, we were not entirely sure what triggered the car to send updates. Though the data made sense — the mileage climbed, the battery level dropped — updates to the API data were sporadic. Sometimes thirty minutes passed between updates; other times, consecutive updates were less than one minute apart.
When we realized that the updates didn’t occur at regular intervals, we began noting our interactions with the car to determine the relationship between an owner’s actions and the frequency of updates. To determine whether something as simple as unlocking the doors would trigger an update, we decided to run a series of tests. We took the car on a very short trip, with exaggerated intervals between opening the door, turning the engine on, etc. (seen below from 12:09:40 to 12:19:20), and got two updates.
We discovered that the car sent data when the front door was opened, and again when the driver left the car after the trip and locked the doors. The updates took about 50 seconds to become available through the API. At this point, we still were not sure if it was necessary to drive the car in order for it to send an update after the doors were locked. In order to determine this, we unlocked and opened the driver’s door, (12:27:55) and got an update around fifty seconds later. Without driving the car, we exited it and locked the doors (12:32:00). We saw an update, again around fifty seconds later.
The Car
The car used in this test is a consumer model, and not a BMW test vehicle in any way. It is a 2015 BMW i3 REx with a ConnectedDrive subscription that includes the “Remote Services” package. You can find more information on eligible vehicles and necessary data packages in our bmw page.
Conclusion
It seems as though BMW updates vehicle data at what might be considered the beginning and end of a trip. One update occurs when a driver unlocks and opens his door, and another occurs when the driver leaves the car and locks the vehicle.
Though we don’t have data on it, it is plausible that the car would send updates in other situations as well. For example, if it has been parked or been driven for a certain amount of time, or when the battery has finished charging. Without further testing, we cannot say for certain.
We plan to run similar tests in the future with vehicles from other manufacturers, refining our data-gathering app and experimental techniques as we go. Watch this space for updates on our latest findings; as we spend more time with the vehicles accessible by our platform, we will be able to hone in on the differences among the various ways manufactures update their data.
