Context: smartphone-based connected insurance
Automatic trip detection and recording is a core feature of smartphone telematics. It simplifies the user experience for policyholders by avoiding the need to open a mobile application or manipulate their phone before driving.
This feature is critical for driver safety, as any smartphone-based insurance or prevention solution must encourage drivers to avoid manipulating their smartphone before or while driving.
The challenge lies in accurately recognizing and recording displacements, even when the application is running in background, while minimizing the phone's battery consumption.
It's a complex trade-off between two contradictory objectives that only telematics experts can achieve.
The aim of this article is to explain how the automatic detection mode works, and to describe the mechanisms that guarantee the performance of this solution.
Trip recording lifecycle
The trip analysis process begins by detecting the vehicle's displacement.
Before being able to analyze a trip, the system must first be able to detect that a trip has actually started, relying on various signals. The signals and data used are described in the rest of the article.
To reduce the phone's battery consumption, it is essential to use low-energy mechanisms. This is why the GPS sensor is not used to detect a trip or when the policyholder is not driving.
Once a trip has been detected, the GPS sensor is used to validate that it is made in a motorized vehicle, and to analyze the driver's behaviour.
When a trip has been detected and confirmed, the GPS sensor measures the vehicle's speed over the whole trip, until it comes to a complete stop. As a general rule, trip analysis is automatically stopped if the vehicle remains stationary for more than four minutes.
Automatic stop limits unnecessary use of the GPS sensor after a trip, and minimizes battery drain.
As soon as recording is stopped, the recorded data are analyzed on a server. The data processing takes no longer than one or two seconds, so the policyholder can check the results immediately.
This article does not aim to detail the analysis cycle. For readers who want to learn more, it is described in our public documentation.
Let's come back to the signals that lead to the detection of movement. A reliable telematics solution relies on several mechanisms designed to start recording data as soon as a vehicle trip begins. For high-performance detection, the DriveQuant SDK uses several mechanisms that collaborate: the first of these, which identifies a movement, can trigger recording.
These mechanisms are detailed below.
Activity recognition API on Android
On Android, the Google Play services include an Activity Recognition API that uses the smartphone's sensors to collect data, which is then analyzed using machine learning models.
The data comes from low-power sensors, and the processing algorithms are optimized to conserve the smartphone's resources. The recognized activities are described in the public documentation accessible here.
The DriveKit SDK listens for activity changes and triggers trip analysis if a mode of transportation in a motorized vehicle (IN_VEHICLE) is detected.
Significant location change on iOS
On iOS, there's also an Activity Recognition API that works in a very similar way to the Android API. But this method cannot be used when the application is running in the background.
However, there is a way of detecting a change in the user's location that can be likened to motorized displacement, using the significantLocationChange (SLC) method included in the iPhone's location management services.
The SLC event is based on estimating the phone's location from GSM antennas. This method does not allow precise detection of a user, but it is sufficiently powerful to identify a change in position following movement in a motorized vehicle. The SLC saves battery life by reducing the frequency of location updates compared to continuous location tracking.
The DriveKit SDK uses this event to trigger a trip analysis.
Enhanced detection with geozones
The two methods mentioned above are effective, but they do not guarantee an instantaneous detection of a trip's start:
-
On Android, the performance or latency of the activity detection API may vary depending on the quality of the phone's sensors.
-
On iOS, the SLC event has the advantage of being energy-efficient, but is also relatively infrequent.
To overcome these limitations, the DriveKit SDK incorporates a mechanism for reinforcing trip detection, based on the use of geo-zones.
The principle is simple: create a zone centred on the coordinates of the last point of a trip, corresponding to the vehicle's parking location.
The DriveKit SDK detects that a new trip has been started as soon as the user moves away from the previously recorded geo-zone.
Using a beacon
A beacon is a Bluetooth Low Energy (BLE) transmitter whose signal can be detected by an iPhone or an Android smartphone. Placed in a vehicle, the beacon immediately triggers the trip recording as soon as it is in the proximity of the policyholder's smartphone.
Despite not being essential, this device offers two advantages over the mechanisms previously described:
-
Trip detection is immediate, and begins even before the vehicle moves, thus ensuring that the entire trip is recorded. Unlike previous modes, which require the vehicle to be in motion to detect the trip, resulting in minor data loss at the start of the trip.
-
Identification of the insured vehicle. This feature is not possible with previous methods.
The DriveKit SDK supports the iBeacon standard defined by Apple in 2013. This standard is universal, popular and optimized for detection by smartphone.
We recommend the use of iBeacon for insurance offers where precise measurement of distance travelled is essential, such as mileage-based insurance.
Detection of connection to vehicle infotainment system
Most new vehicles are equipped with multimedia infotainment systems enabling Bluetooth connection with a smartphone.
The DriveKit SDK is able to detect the connection between the policyholder's smartphone and the vehicle, triggering a trip analysis.
Although simple and effective, this solution does have limitations:
- the vehicle interface allows connection with only one smartphone.
- The policyholder does not systematically connect his phone to the vehicle.
- This is not necessarily a problem, since this detection mode is not exclusive.
If the smartphone is connected, trip recording will start as soon as the trip begins. Otherwise, the trip will be detected using activity detection, the SLC signal on iOS or a geo-zone.
Android Auto and CarPlay
Car manufacturers are now incorporating the latest advances in connectivity, such as CarPlay or Android Auto.
The DriveKit SDK is designed to detect a connection to Android Auto and use this information to initiate the trip recording. Depending on the case, this device works with either a wired connection or a wireless Bluetooth connection.
However, for users with an iPhone and a CarPlay-equipped vehicle, this functionality is not currently available. Indeed, Apple does not share the connection event between an iPhone and a CarPlay system on iOS, except for CarPlay-enabled apps. Unfortunately, connected insurance mobile apps are rarely designed for CarPlay.
Conclusion
This article explains the reasons and principles that have enabled the smartphone to become a more effective data collection tool than traditional, and often more expensive, on-board telematics solutions such as connected devices.
On the one hand, the performance of a smartphone telematics solution lies in the use of several mutually reinforcing processes to maximize the detection of the policyholder's trips.
On the other hand, smartphone telematics relies on in-depth knowledge of the technological environment (iOS/Android ecosystem and connected objects) as well as policyholder mobility behaviours, based on rigorous technical principles.
To be successful, here are the essential ingredients an insurer should expect from its smartphone telematics provider:
-
A team of experts dedicated to the continuous improvement and optimization of the solution.
-
In-depth expertise in Android and iOS operating systems, and close monitoring of these ecosystem changes.
-
Solid technological understanding of connected objects and on-board vehicle interfaces.
-
Close attention to the use of smartphone computing resources and energy consumption to limit battery drain.
-
The ability to explain this technology in simple terms, and to transfer this knowledge to insurers to help them build simple, clear offers for consumers.
