.svg){kind=small}
The field test with a Mercedes-Benz vehicle
To provide definitive answers to these questions, we are testing real cars from each of the manufacturers we support. For this article, we headed to the Mercedes-Benz headquarters in Stuttgart to field test the Auto API with one of their latest cars, the Mercedes-Benz E 300 de Diesel-Hybrid.
Rather than providing data points à la carte, Mercedes-Benz offers a variety of data buckets, each of which contains a selection of data points that has been pre-tailored with specific use cases in mind. We will explore each below.
This article will present a short background on Mercedes-Benz vehicle data products before revealing our findings from our day of testing with sample data and graphs. Details on the car and authentication process can be found at the end of the article.
A note on compatible vehicles and regions
The vast majority of Mercedes-Benz passenger vehicles built after 2016 are compatible with High Mobility's Auto API. In order for an app to retrieve data from a car, a few additional conditions must be met. The vehicle must have a Mercedes me connect subscription with the “Interface to Third Parties” service activated, and the vehicle owner must consent to providing data access to the third-party.
The process is for the vehicle owner: a totally stock, unmodified car rolls off the dealer’s forecourt and is already compatible with our APIs; no hardware, no installation, and no configuration. Only the car owner’s consent is required. That’s it!
Data services extend to the following countries :
Normally, the APIs have request limits; for our test, Mercedes-Benz kindly removed these limits to allow testing of different use cases in a short time span.
The test
In our first few minutes with the car, we headed from Daimler in Stuttgart to the nearby Mercedes-Benz Museum. While driving, we monitored each API to confirm that it was active and responding as anticipated. For example, we’d open the sunroof or windows, and make sure that the relevant API reflected the change in state. We performed similar experiments with all of the production APIs. The APIs for the “touch points” we interacted with — doors, windows, sunroof, and locks — updated in a matter of seconds. API data for other vehicle attributes, like fuel and battery level, was updated rather more sporadically, with a maximum delay of around fifteen minutes.
The purpose of this test was to see:
What triggered the car to send data updates.
How fast the new data was available via API.
How third-parties could make good use of it.
Once we’d confirmed that everything worked smoothly, we set off on a longer trip. The idea was to drive long enough to see the battery and fuel levels diminish, so that we might obtain a data set which could better show the change in the data points over time.
From the Mercedes-Benz Museum, we drove for a few kilometres in town, then continued on an unintentionally circuitous route north and then back to Daimler.
The trip started at 11:52 a.m., and finished at 12:45 p.m.
The data
We then sifted through all the data we had gathered during the test. Below, we’ll take a look into each data bucket and its associated use case. Keep in mind that Mercedes-Benz does not provide historical data through their APIs. Each query returns the latest data point and a timestamp; the charts below were made possible by continuous querying. In order to make it clear how frequently the data is updated, the discrete points on the charts below indicate when we received new data. It is possible to call the APIs at any time, and they will always return the latest data that is on the server — in the case of these charts, that would be the nearest data point appearing to the left of the time when the API is called.
Let’s explore each data bucket.
Bucket: Pay As You Drive
Included APIs: Mileage, timestamp
The Pay As You Drive insurance data bucket is Mercedes-Benz’s response to this popular usage based insurance use case. Since Pay As You Drive only requires a mileage reading, this data bucket has only one data point: Mileage. An application can query the Mileage API up to two times per day, then bill the car owner according to the mileage he or she has driven. The chart below shows the mileage data that the Auto API provided during our drive. Though the data was not updated every time the odometer incremented by another kilometre, the available data was never more than ten minutes old. Since a Pay As You Drive application might need odometer updates on a daily, weekly, or monthly basis, mid-trip updates are more than sufficient.
Bucket: Fuel Status
Included APIs: Fuel Level, Estimated Range, timestamp
The Fuel Level and Estimated Range data points are useful for fuelling and loyalty applications. The Auto API provides the current fuel level as a percent of the total capacity, and the estimated range provides an estimate of the combined electric and gasoline range.
During our trip, the APIs indicated decreases in both the fuel level and the estimated battery level. After the trip, we refuelled the car at 10:42 a.m., and received updated data from the API a few minutes later. In production, the rate limit for these APIs is one call per hour, sufficient to extrapolate when a car might need to refuel.
Soon after the car was refuelled, the API indicated that the tank was 100% full, and the estimated range showed that the range had jumped to more than 1200 km.
Bucket: Vehicle Status & Lock Status
Vehicle Status APIs: Windows, Doors, Trunk, Rooftop, and Lights: Positions and timestamp
Lock Status APIs: Door Locks, Trunk Lock, Gas Flap Lock, Vehicle Heading, timestamp
The Vehicle Status and Lock Status data buckets can be used for Damage Prevention and Theft Prevention; a car owner can confirm from anywhere that their car is locked, and that its windows and doors are shut. We’ve created an infographic to show what data the APIs provided as we were preparing to leave the car at the end of our trip. In order to simplify the graphic, we will focus only on the right side of the car and the trunk:
Here’s the story behind the graphic. We had parked next to a charging station and gotten out of the car. After plugging it in and talking for a bit, we decided to end our test. There is where the infographic starts — with the car’s doors and windows shut, and with the doors unlocked. We then opened the trunk to remove a backpack, opened the front passenger door to make sure we hadn’t left anything behind, then shut it and locked the car.
Note: Each of the these data buckets can be queried 50 times per day.
Bucket: Electric Vehicle
Included APIs: Battery Level, Estimated Range, timestamp
The Electric Vehicle data bucket contains the Estimated Range and Battery Level data points. Note that the Battery Level API delivered up-to-the-minute information the whole time the car was charging (the chart is one hour wider than the others in order to show the entirety of the charging time after our test).
The Electric Vehicle data bucket can be used to help electric vehicle owners combat range anxiety. When the API shows that a car is nearing the end of its range, an application could direct the car owner to a charging station near his or her route.
The Car: Mercedes-Benz E 300 de Diesel-Hybrid (MY2020)
For our test, Mercedes-Benz provided one of the newest vehicles in its fleet, a sophisticated diesel electric plug-in hybrid which can drive up to 50 km on electric energy alone. It was the perfect vehicle to use while testing our APIs; the drivetrain meant we could use all of our internal-combustion and battery-related APIs. Please note that the car was totally standard, and not in any way modified or otherwise specially prepared for this test. Check out the official site here.
Connecting to the Car
We connected to the car using the standard workflow that is already in production. During the consent flow, the car owner is asked to enter their Mercedes me portal credentials into a consent page handled by Daimler. In Stuttgart, a representative from Mercedes-Benz entered the relevant credentials on the page, then consented to the sharing of the vehicle’s data for this test. After we had received the access token, we used a script to query all available data points on the E 300 de, and recorded the responses and timestamps in a spreadsheet.
Conclusion
We were pleased to see that our test car provided information to the APIs which consistently matched what we observed from the vehicle during our test. Data on the human-interaction points was updated almost immediately. Updates on the constantly changing “internal” car data, like mileage, battery level, and range, were sent sporadically. All data points were updated while driving, and with a maximal delay of about ten minutes.
We are positive that these results appeal to any third party who is looking to integrate Mercedes-Benz car data into their application or service.
This field test is the second in a series. In the first field test, we queried a BMW i3 while driving it through the capital of Estonia. Though the Auto API works the same way whether querying data from a BMW or Mercedes-Benz, cars from different manufacturers may offer different data points, and send information at different intervals.
For more information about the consent flow car owners go through when sharing their car data with an application, read our post on customer consent. Stay tuned for more vehicle API tests. If you have any questions about the APIs, the consent flow, or developing on our platform, please write us a message in the comments and don’t forget to try out the data products, emulators and tutorials for yourself over on the High Mobility platform.
