Despite the pandemic, the team has been working diligently to add new carmakers to our platform. Our latest addition is Ford; our platform now supports all Ford passenger vehicles which are equipped with FordPass Connect. This technology became standard equipment on nearly all European-market Ford passenger vehicles during 2019. For more information on supported vehicles please check out our Learn pages on connected Ford vehicles.
These data connections do not rely on aftermarket OBD-II dongles. Ford vehicles use standard carmaker-installed telematics systems to provide data. Now that Ford telematics data is supported by our platform, it’s possible for third party developers and applications to access this vehicle data after the vehicle owner has provided consent.
This article is the latest in a series of Field Tests. In our first Field Test, we linked a BMW i3 and gathered data during a day spent exploring High Mobility’s home town of Tallinn, Estonia. The i3 was equipped with an early version of BMW’s ConnectedDrive technology, and sent new data at the beginning and end of every trip. We were able to get several readings of the i3’s vital statistics—including odometer, battery level, fuel volume, and mileage—as well as position, throughout our trip. In a recent follow-up test, we tested a BMW 320i equipped with BMW’s Live Cockpit Professional infotainment package, which sends mid-trip updates every three minutes or two kilometers, whichever comes first. We’ve also tested a Mercedes E300de diesel-hybrid.
For this test, we used a 2020 Ford Focus equipped with FordPass Connect, and gathered data during an afternoon driving around Berlin.
High Mobility provides a unified API which makes it possible to communicate with a variety of connected vehicles via a single integration. BMW, Ford, MINI, and Mercedes-Benz are all now supported.
Setup and data points
Setting up the sample app for the Field Test was trivial. In the platform (link for logged-in users), we created a ‘Production Mode’ app and selected the data points which the car could provide. Once the app had gone through the approval process, we cloned the Node.js Auto API Explorer from the High Mobility GitHub page, and configured it with the variables found in the app and in the Team Station settings.
To connect the car, we—now acting as the “car owner”—navigated to the Authentication URI and followed the consent flow.
We also queried the API every few seconds in order to see when new data was available. Ford webhooks are available on the High Mobility platform, so push notifications can let applications know whenever a linked vehicle has sent new data. We queried the API every time new data was available.
Today, the following Ford webhooks are available: authorisation_changed, battery_guard_warning, dashboard_lights_change, ignition_changed, tire_pressure_warning, and vehicle_location_changed.
Your application can use whichever webhooks make sense for your use case. For each data point in the charts below, we will display all the values we measured for that data point during the test. Please note that Battery Guard Warning and Tire Pressure Warning webhooks are triggered only when values for their respective data points dip below a critical threshold.
With the sample app set up, and the Focus connected, we drove around and watched the data roll in. We monitored the following data: latitude, longitude, heading, and altitude, odometer, fuel level, tire pressures, battery voltage, coolant temperature, seat belt warnings. In addition, we retrieved the tire pressure statuses, gear position and the ignition status.
Data point: Location
We expected the car would send—at a minimum—a location update when we turned the ignition on, another about a minute later, and a final update when the ignition was turned off at the end of the trip and this was confirmed in our test. Additional updates are sent whenever a dashboard light comes on.
If we unchecked seat belt, for instance, we would receive a Seat Belt Warning, as well as an update on all the other data points. When we stopped and lowered the tire pressure below a critical level, the car sent another update. We also turned the traction control off and fiddled with other buttons on the instrument panel and received additional updates.
These “mid-trip” updates—which were triggered by our interaction activity inside the car—led to the chain of red points which end at a blue point at the top of the map. At that blue point, we stopped pressing buttons, changing tire pressures, etc., we made a stop, and then started our way back southwest. The final four blue points in the southwest corner of the map were sent when stops were made to drop off the testers, we also stopped at the grocery store and the final blue dot marks the end of the return trip and the final parking destination.
Data point: Odometer
The car sent an odometer update whenever other data was updated. Because there were so many updates of other data points as we headed north, the odometer was also updated frequently.
Data point: Fuel Level
The Focus we tested was a gasoline-only vehicle, so it used a bit of fuel between each data point. We were surprised at the resolution, we were getting updates to the thousandth of a percent!
Data point: Tire Pressure
During our trip, we wanted to check to see when a Tire Pressure Warning webhook would be triggered, so we lowered the right front tire’s pressure until a dashboard light came on. Tire pressures retrieved via the Auto API matched what we saw on the dashboard and the measurements we took with the tire pressure gauge.
After the test, we plotted the data we’d gathered from the Auto API: it also shows that the right front tire was low.
Data points: Battery Voltage, Coolant Temperature
We didn’t experience any issues with the battery voltage or the coolant temperature, but were able to gather data throughout our test. These data points would be of interest to companies interested in monitoring a vehicle’s health.
Ford car data and webhooks can effectively power several use cases:
- Logbook applications can use the Ignition Changed webhook and the accompanying location update to determine exactly when a trip started and ended, which is helpful for logbook applications.
- Pay-as-you-drive (PAYD) insurance applications can check the odometer reading.
Ford data updates for the currently supported use-cases — Insurance, Enhanced Insurance, Logbook and Vehicle Health — are made available when the ignition is turned on at the beginning of a trip, and remain available until the ignition is turned off at the end of a trip.
At the bare minimum, an update is sent at the beginning of a trip, one minute later, and again at the end of a trip. The car will also send additional mid-trip updates whenever a dashboard light comes on, or if one turns off (for instance, if an under-inflated tire is reinflated).
That’s it for the Ford car data field test for now. Make sure to check out our other field tests with BMW and Mercedes-Benz.