Trip - DriveQuant

Description
The overall approach behind DriveQuant’s trip analysis service is based on vehicle dynamics and powertrain modeling. Using vehicle or smartphone sensors, our services estimate the efforts applied to the powertrain enabling us, for example, to remodel the efforts between the road and the wheels or to estimate the exhaust pollutants.
DriveQuant’s data analysis service delivers a wide range of indicators describing vehicle usage and driver behavior. For a single trip, DriveQuant’s trip analysis service retrieves:
1.eco-driving indicators,
2.an estimate of the fuel consumption,
3.safety indicators,
4.tire and brake wear measurements,
5.pollutant emissions estimation,
6.a distraction score (phone use),
7.and a speed limit score.
The trip analysis API is automatically requested by the DriveKit SDK at the end of each trip. 
This API can also be used without the DriveKit SDK if you have your own GPS data collection system (OBD dongle, black box, vehicle data).
The distraction score (phone use) is only available for SDK users.
An additional cost is required for the use of the speed limit score, which is calculated using data coming from map data providers.
This section explains how to query the trip analysis API, how driving indicators are computed and how they are structured.
DriveQuant services provide additional data by collecting all vehicle trips so you can easily retrieve statistics for each of your vehicles. We recommend to add a new vehicle before requesting the trip analysis API if you target a vehicule mantenance use case.
post
https://service.drivequant.com
/v2/trip
Trip
Request
Account
Field
Type
Description
account
String
API key
userId
String
User unique identifier
vehicleId
String
Vehicle unique identifier
DriveQuant counts the number of active assets per customer. The DriveQuant API is a pay-per-active-asset API. An asset is considered active if it has performed at least one trip on a monthly basis. An asset can be a driver (identified with its driverId)  or a vehicle (identified by a vehicleId). 
Three main use cases can be considered:
1.The request includes only a driverId: This is common when the data collected comes from a mobile application installed on a driver's phone. The total number of assets per customer is equal to the number of unique driverId's.
2.The request includes only a vehicleId: This is common when the data collected comes from a telematics device plugged into the vehicle. The total number of assets per customer is equal to the number of unique vehicleId's.
3.The request includes a driverId and a vehicleId: This is common when a group of drivers can use several vehicle within a fleet. The total number of assets may be the number of unique vehicleId's or driverId's. Billing and counting will depend on your business model and the difference between the number of drivers and vehicles. Please contact DriveQuant sales department to find out the best pricing model.
The Account object must contain the account and the userId or vehicleId attributes.
Route
Field
Type
Description
gpsVelocity
double[]
GPS speed vector in km/h
latitude
double[]
Latitude vector in degree
longitude
double[]
Longitude vector in degree
gpsAccuracy
double[]
GPS accuracy vector in meter
gpsElevation
double[]
Elevation vector in meter
gpsHeading
double[]
Heading vector in degree
gpsDate
double[]
GPS timestamp vector in second
vehVelocity
double[]
Vehicle speed vector in km/h
vehEngineSpeed
double[]
Engine speed vector in rotation per minute
vehTankLevel
double[]
Fuel tank volume in liter
vehWheelAngle
double[]
Steering angle vector in degree
batteryVoltage
double[]
Measurement of the car battery voltage vector in volt
vehDate
double[]
Vehicle date timestamp vector in second
A request must contain all the data corresponding to a single trip. The trip data analysis cannot be cut into multiple queries. It is not recommended to merge data from several trips into a single request.
Route object must contain at least the vehDate or gpsDate and at least gpsVelocity or vehVelocity attributes.
The input variables included into Route object are arrays which must contain the same number of data points.
The sample period for all input vectors must be 1 second. The sampling frequency of 1Hz is a standard for GPS sensors. in case your telematics device does not satisfy this constraint, please contact us to determine what alternative can be applied.
Vehicle
Field
Type
Description
carTypeIndex
int
​Vehicle body type​
carEngineIndex
int
​Engine type​
carPower
double
Vehicle power in hp. This value must be entered in horsepower. In case you only have the engine power in kW you can apply the following formula: P[hp]=P[kW]/0.7355P [hp] = P [kW] / 0.7355P[hp]=P[kW]/0.7355
​
carMass
double
Vehicle mass in kg
carGearboxIndex
int
​Gearbox type​
carConsumption
double
Combined fuel consumption [l/100km] measured during the New European Driving Cycle (NEDC)
carAutoGearboxNumber
int
Number of gear ratios for the automatic gearbox. This parameter is taken into account only if carGearboxIndex is set to 1
Some parameters have a default value if not set, and a min and max limitations:
Field
Default value
Min
Max
carTypeIndex
1 (compact)
-
-
carEngineIndex
1 (gasoline)
-
-
carPower
150
40
450
carMass
1400
700
3500
carGearboxIndex
2 (manual 5-speed)
-
-
carConsumption
4.5
3
20
ItineraryData
Itinerary object is optional.
Field
Type
Description
startDate
Date
Trip start date. Example: 2017-09-07T08:00:00.000+0200
endDate
Date
Trip end date. Example: 2017-09-07T08:00:00.000+0200
departureCity
String
Name of the departure city
arrivalCity
String
Name of the arrival city
MetaData
Metadata can be used if you want to add some of your specific data in a trip. They can be added to the Trip API as a key/value object where the key and value have a String type
Example of JSON body request
1
{
2
	"account": {
3
		"account": "<API KEY>",
4
		"userId": "<UNIQUE USER ID>",
5
		"vehicleId": "<UNIQUE VEHICLE ID>" 
6
	},
7
	"vehicle": {
8
		"carTypeIndex": 4,
9
		"carEngineIndex": 1,
10
		"carPower": 205.0,
11
		"carMass": 1430.0,
12
		"engineDisplacement": 1618.0,
13
		"carGearboxIndex": 2,
14
		"carConsumption": 6.0
15
	},
16
	"itineraryData": {
17
    "startDate": "2018-02-15T15:20:00.000+0200",
18
		"endDate": "2018-02-15T15:50:00.000+0200",
19
		"departureCity": "<DEPARTURE>",
20
		"arrivalCity": "<ARRIVAL>"
21
	},
22
	"route": {
23
		"gpsVelocity": [...],
24
		"latitude": [...],
25
		"longitude": [...],
26
		"gpsHeading": [...],
27
		"gpsElevation": [...],
28
		"gpsDate": [...],
29
		"gpsAccuracy": [...]
30
	},
31
	"metaData" : {
32
		"customerStringData" : "<CUSTOMER STRING DATA>",
33
		"customerJsonData" : "{\"customerTestNumber\" : 1, \"customerTestString\" : \"<CUSTOMER TEXT>\"}"
34
  }
35
}
Copied!
Response
The table below summarizes the list of driving data analysis modules. The comments and itinerary statistics modules are included by default. All other modules are optional and can be combined as needed.
Field
Type
Description
itinId
String
Trip unique identifier
status
Boolean
true if no problem, false otherwise
comments
Comment[]
​Comment​
itineraryStatistics
ItineraryStatistics
​ItineraryStatistics​
itineraryData
ItineraryData
​ItineraryData​
ecoDriving
EcoDriving
​EcoDriving​
advancedEcoDriving
AdvancedEcoDriving
​AdvancedEcoDriving​
fuelEstimation
FuelEstimation
​FuelEstimation​
advancedFuelEstimation
AdvancedFuelEstimation
​AdvancedFuelEstimation​
safety
Safety
​Safety​
advancedSafety
AdvancedSafety
​AdvancedSafety​
safetyEvents
SafetyEvent[]
​SafetyEvent​
tireWear
TireWear
​TireWear​
brakeWear
BrakeWear
​BrakeWear​
pollutants
Pollutants
​Pollutants​
userId
String
unique id of the user
firstname
String
first name of the user
lastname
String
Last name of the user
endDate
String
End date  of the trip
Comment
Field
Type
Description
errorCode
int
Error code
comment
String
Error description
Possible values are described here.
ItineraryStatistics
Itinerary Statistics module provides several indicators that characterize the trip conditions: the trip distance, the vehicle movement duration and the idle duration. We also compute the number of sub-displacements. A trip can be characterized as a succession of events either dictated by the driver’s will or by external factors. These events, called breakpoints, are indicated with black dots in the figure below. Each section of a trip between two breakpoints is called sub-displacement. The figure illustrates these concepts for a short trip with one traffic light (vehicle stopped) and one intersection with priority (vehicle deceleration followed by acceleration).
Field
Type
Description
distance
double
Distance travelled in meter
speedMean
double
Mean vehicle speed in km/h
tripDuration
double
Total trip duration in second
drivingDuration
double
Vehicle movement duration in second
idlingDuration
double
Total duration of idling phases (vehicle stopped)
 in second
drivingPercentage
double
Percentage of vehicle movement
idlingPercentage
double
Percentage of idling phases
subdispNb
int
Number of sub-displacements detected during the trip
meteo
int
​Weather code​
day
boolean
true if day, false if night
weekDay
boolean
true: Monday to Friday, false: Saturday to Sunday
transportationMode
int
​Transportation mode​
ItineraryData
Field
Type
Description
startDate
Date
Trip start date. Example : 2017-09-07T08:00:00.000+0200
endDate
Date
Trip end date. Example : 2017-09-07T08:00:00.000+0200
departureCity
String
Name of the departure city
arrivalCity
String
Name of the arrival city
departureAddress
String
Departure full address
arrivalAddress
String
Arrival full address
Eco-driving
Description
Eco-driving module performes an analysis of the entire trip, characterized by a succession of events and road segments. The driving efficiency is computed by comparing the vehicle speed recorded with an optimal speed profile, for each segment. This calculation takes into account the actual driving conditions and a physical vehicle model that captures the inertial dynamics of the vehicle and the efficiency of the powertrain components. The eco-driving score ranges from 0 and 10, and is calculated by comparing the actual energy consumed during the trip with the energy that would have been consumed using the optimal speed profile. The best eco-driving score corresponds to the highest driving efficiency.
Field
Type
Description
score
double
Eco-driving score (min: 0, max: 10). If trip is too short to be scored, score is set to 11.
scoreAccel
double
Score of the acceleration phases. If trip is too short to be scored, score is set to 6.
scoreMain
double
Score of the stabilized speed phases. If trip is too short to be scored, score is set to 6.
scoreDecel
double
Score of the deceleration phases. If trip is too short to be scored, score is set to 6.
stdDevAccel
double
Standard deviation of acceleration score
stdDevMain
double
Standard deviation of stabilized speed score
stdDevDecel
double
Standard deviation of deceleration score
​energyClass​
int
0: energy class A 
1: energy class B
2: energy class C
3: energy class D
4: energy class E
Scores definitions
Acceleration, deceleration and speed maintain phases have a large impact on the vehicle’s fuel consumption. As a consequence, by comparing the real and the optimal speed profiles, eco-driving analysis module returns 3 key driving indicators.
The acceleration and deceleration scores range from -5 to +5. For a value of (-5), your acceleration or deceleration is too slow. For the highest value (+5) you are accelerating or decelerating too fast. A score of (0) indicates that your acceleration or deceleration perfectly matches with an eco-driving style.
The speed maintain score ranges from 0 to 5. The minimum value (0) indicates that the driver has an appropriate behavior and drives at a constant speed. On the other hand, if the driving analysis module detects an oscillating speed profile, this score increases. The highest value (+5) indicates that you can improve to keep a constant speed to reduce your fuel consumption.
These indicators will help you improve your driving efficiency and reduce your energy consumption. They can also illustrate the level of anticipation that the drivers should adopt to avoid harsh accelerations and brakings.
The numerical values of driving scores can be transformed into driving tips. The tables below give examples of content that can be returned to a driver based on the driving notes of a trip:
scoreAccel
Description
-5 to -4
Acceleration is too low
-4 to -2
Weak acceleration
-2 to 1
Good acceleration
1 to 3
Strong acceleration
3 to 5
Acceleration is too high
scoreMain
Description
0 to 1.5
Good speed maintain
1.5 to 3.5
Irregular speed
3.5 to 5
Very fluctuating speed
scoreDecel
Description
-5 to -4
Deceleration is too low
-4 to -2
Weak deceleration
-2 to 1
Good deceleration
1 to 3
Strong deceleration
3 to 5
Deceleration is too high
The eco-driving analysis is performed for vehicle displacement greater than 100 meters and speed higher than 10 km/h. This avoids providing inaccurate driving scores during vehicle maneuvers (slow driving in traffic jams or in parking lots...). In that case, eco-driving analysis module returns the following error codes:
11 for the eco-driving score
6 for acceleration phase, stabilized speed phase and deceleration phase
Energy class
The energy class « energyClass » depends on the average fuel consumption of the vehicle. It positions the trip fuel consumption with respect to the average consumption of the vehicle.
Class A corresponds to 0.5 x the NEDC consumption of the vehicle expressed in gCO2/km.
Class E corresponds to 1.5 x the NEDC consumption of the vehicle expressed in gCO2/km
Then we defined the 5 classes with a uniform distribution between class A and class E. The energy class « energyClass » is calculated from the trip CO2 emission « co2Emission » and the function below:
Energy class definition
Advanced eco-driving
Field
Type
Description
ecoDrivingContext
EcoDrivingContext[]
Array of EcoDrivingContext
In order to provide fair scoring and to facilitate drivers comparison, the trip scores can be accompanied by road class scores. These scores are included in the EcoDrivingContext class into the Advanced Modules. This service differentiates 5 types of road conditions (contextId) to contextualize the driving scores:
0 - Traffic jam: This corresponds to vehicle displacements of less than 100 meters and performed with speeds below 10 km/h. In traffic jams, it is obviously not possible to improve your driving, that is why scoring are not provided for this type of road.
1 - Heavy urban traffic
2 - City
3 - Suburban
4 - Expressways
In case a road type is not included in the trip, the distance and duration percentages are equal to zero, the efficiency score is set to 11 and the driving scores (Accel/Main/Decel) are set to 6.
EcoDrivingContext
Field
Type
Description
distance
double
Percentage of distance travelled in a road type
duration
double
Percentage of elapsed time in a road type
efficiencyScore
double
Eco-driving score
scoreAccel
double
Score of the acceleration phases
scoreMain
double
Score of the stabilized speed phases
scoreDecel
double
Score of the deceleration phases
contextId
int
​Road conditions​
Fuel estimation
Description
The fuel consumption is obtained from a backward computation based on a mathematical modeling of the vehicle and powertrain. Fuel consumption estimation asses the mechanical traction power from the vehicle speed and mass. A power transfer is performed between each component of the powertrain to compute the engine torque. Finally, the engine torque combined with the vehicle speed help to process the fuel mass from an engine consumption map developed by IFPEN. This fuel mapping is adapted according to the vehicle parameters and is valid for any type of vehicle or fleet of vehicles.
This approach is particularly adapted to estimate real-driving fuel consumption which can be more than 20% above the homologation data provided by car manufacturers. The main advantage lies in the accuracy of the estimate that can reach 5% when all input variables are available and the vehicle parameters set. The estimation method accounts for the physical fuel characteristics. These parameters are listed below:
Fuel type
Density (kg/l)
Lower heating value (GJ/t)
CO2 emission factor (tCO2/TJ)
CO2 emission factor (kgCO2/l)
Gasoline
0.755
44
70.26
2.3340
Diesel
0.845
42
75.70
2.6866
Values calculated by fuel estimation module are described below:
Field
Type
Description
co2Mass
double
Total Mass of CO2 in kg
co2Emission
double
Total Mass of CO2 per unit of distance in g/km
fuelConsumption
double
Total fuel consumption per unit of distance in l/100km
fuelVolume
double
Total fuel consumption in liter
idleFuelPercentage
double
Idle fuel consupmtion percentage
idleFuelConsumption
double
Idle fuel consumption per unit of distance in l/100km
idleCo2Emission
double
Idle CO2 emission in g/km
idleCo2Mass
double
Idle CO2 mass in kg
engineTempStatus
boolean
Engine cold start ?
coldFuelVolume
double
Cold engine fuel volume
Advanced fuel estimation
Field
Type
Description
fuelEstimationContext
FuelEstimationContext[]
Array of FuelEstimationContext​
In order to provide detailed fuel consumption estimation across the vehicle trips, the advanced fuel estimation service may return the fuel consumption for each driving context of the vehicle. This service differentiates 5 types of road conditions (contextId): 
0 - Traffic jam
1 - Heavy urban traffic
2 - City
3 - Suburban
4 - Expressways
In case a road type is not included in the trip, the percentages of distance and duration are equals to zero as well as the co2Mass, co2Emission, fuelVolume and fuelConsumption.

FuelEstimationContext
Field
Type
Description
contextId
int
Road conditions
distance
double
Percentage of distance travelled in a road type
duration
double
Percentage of elapsed time in a road type
co2Mass
double
Total Mass of CO2 in kg
co2Emission
double
Total Mass of CO2 per unit of distance in g/km
fuelVolume
double
Total fuel consumption in liter
fuelConsumption
double
Total fuel consumption per unit of distance in l/100km
Safety
Field
Type
Description
safetyScore
double
Driver risk index for a given itinerary
Ranges from 3 to 10
nbAdh
int
Number of adherence threshold crossing
nbAccel
int
Number of strong accelerations
nbDecel
int
Number of strong decelerations
nbAdhCrit
int
Number of adherence threshold crossing (critical)
nbAccelCrit
int
Number of critical accelerations (critical)
nbDecelCrit
int
Number of critical decelerations (critical)
 If trip is too short to be scored, safetyScore is set to 11.
Advanced safety
Field
Type
Description
safetyContext
SafetyContext[]
Array of SafetyContext​
SafetyContext
Field
Type
Percentage of distance travelled in a road type
distance
double
Percentage of distance travelled in a road type
duration
double
Percentage of elapsed time in a road type
safetyScore
double
Ranges from 3 to 10
nbAdh
int
Number of adherence threshold crossing
nbAccel
int
Number of strong accelerations
nbDecel
int
Number of strong decelerations
nbAdhCrit
int
Number of adherence threshold crossing (critical)
nbAccelCrit
int
Number of critical accelerations (critical)
nbDecelCrit
int
Number of critical decelerations (critical)
contextId
int
Road conditions
In case a road type is no included in the trip, the distance and duration percentages are equal to zero and the safety score is set to 11.
SafetyEvents
The data provided in the following table helps to display safety events on your map system and deliver the locations of harsh braking or acceleration as well as the coordinates where a tire to road adherence threshold has been crossed.
Field
Type
Description
time
double
Time since the beginning of the trip in second
latitude
double
Latitude in degree
longitude
double
Longitude in degree
velocity
double
Vehicle speed in km/h
heading
double
Vehicle heading in degree
elevation
double
Altitude in meter
distance
double
Distance travelled since the beginning of the trip in meter
type
int
Type of event
    1. Adherence
    2. Acceleration
    3. Braking
level
int
Intensity related to the event
    1. Strong
    2. Harsh
value
int
Absolute value of the event:
in m/s2 for acceleration and braking events
normalized between 0 and 1 for the adherence events
The service provides the time, coordinate and severity level of each event. Two levels of severity are calculated using specific threshold values for each event.
Type of event
Unit
Strong
Harsh
Acceleration 
m/s2
2.0
2.5
Braking
m/s2
-1.8
-2.4
Adherence limit
-
0.2
0.3
Pollutants
Field
Type
Description
co
double
Carbon monoxide (CO) emissions expressed in mg/km
hc
double
Hydrocarbons (HC) emissions expressed in mg/km
nox
double
Nitrogen oxide emissions (NOx) expressed in mg/km
soot
double
Soot emissions expressed in mg/km
Tire and brake wear estimates
Description
The wear analysis service has been designed to monitor the brake pads and tires wear levels. This service was designed to improve vehicle maintenance solutions and can be used to create maintenance alerts.
The wear estimation relates to the power dissipated in the tire - road or brake disc - brake contact. To compute this variable our service relies on the vehicle’s dynamic modelling that estimates the braking efforts and the efforts at the contact between the tire and the road. 
For each trip, the service gives for each components (front/rear brakes/tires):
The worn mass fraction during the trip.
The total worn percentage since the installation of new tires or brakes.
Tire and brake wear indicators for a single trip
The wear analysis service measures tire wear and brake pad wear. The service allows to distinguish the front and rear axles of the vehicle. The wear is assumed to be the same for the right tire and the left tire of the vehicle. A similar assumption is made for the brake pads.
The output value corresponds to a mass fraction of the worn component (tire or brake pad). This value is expressed in thousandth part of parts-per-million (ppm) which is a unit equivalent to a parts-per-billion (ppb). 
The worn mass fraction (tire or brake pad) is given for each individual trip. To obtain the total worn mass fraction, the sum of all the trip’s values must be done. The total worn mass fraction value is bounded between a minimum and a maximum value: 
Minimum value = 0 ppb. If the total worn mass fraction is 0, the component (tire or brake pad) is assumed to have no wear.
Maximum value = 10910^9109
ppb. If the total worn mass fraction reaches the maximum value, this means that the component (tire or brake pad) is fully worn and must be replaced.
For a tire, the maximum value for the mass fraction (10910^9109
ppb) indicates that the tire has lost all its usable mass of rubber. This corresponds to a minimum tire tread height of 1.6 mm. In France, a tire must legally have a minimum tread height of 1.6 mm over its entire circumference.
The wear calculation service estimates for each trip:
The worn fraction of front tires
The worn fraction of the rear tire
The worn fraction of the front brakes
The worn fraction of the rear brakes.
Example of tire autonomy calculation: 
Assuming a vehicle that has performed NNN
 trips, the tire autonomy ( dad_ada​
 ) in km can be computed as follow:
​da=f(w)×∑k=1Ndid_a=f(w)\times\sum_{k=1}^Nd_ida​=f(w)×∑k=1N​di​
 with f(w)=1109×∑k=1Nwi−1f(w)=\frac{1}{10^9\times\sum_{k=1}^Nw_i}-1f(w)=109×∑k=1N​wi​1​−1
 
where ω is the tire worn mass fraction for the trip i (in ppb) and di is the distance (in km) of the trip i. The wear function f(ω) is a decreasing function that goes from infinity to zero. When f(ω) equals zero, the tire has no longer autonomy and must be replaced. This function is displayed below:
Total tire and brake wear indicators
In order to facilitate the integration within a vehicle maintenance service, the DriveQuant API provides for all your requests the following set of data related to any component (tires or brakes):
The total distance traveled with a given component (Distance)
The level of wear of the considered component (TotalWear)
The remaining autonomy before a complete wear (Autonomy)
The average wear speed of the considered component (WearRate)
The total autonomy of the considered component is assumed to be equal to the total travelled distance plus the remaining autonomy (Distance + Autonomy).
The diagram below illustrates the principle and the meaning of these quantities. The figure shows the evolution of the wear as a function of the distance traveled with the component. This is a generic representation that applies to a brake pad or a tire.
The autonomy of a set of tires or brakes is calculated for each axle (front and rear). For example, the most worn tire between the left tire and the right tire on the same axle is used.
Field
Type
Description
frontTireWear
int
Worn mass fraction of the front tires (right/ left) for current trip
Unit : thousandths part of ppm = ppb
Min. value = 0 / Max. value = 10910^9109
 
rearTireWear
int
Worn mass fraction of the rear tires (right/left) for current trip
Unit : thousandths part of ppm = ppb
Min. value = 0 / Max. value = 10910^9109
​
frontBrakePadWear
int
Worn mass fraction of the front brakes (right/left) for current trip
Unit : thousandths part of ppm = ppb
Min. value = 0 / Max. value = 10910^9109
 
rearBrakePadWear
int
Worn mass fraction of the rear brakes (right/left) for current trip
Unit : thousandths part of ppm = ppb
Min. value = 0 / Max. value = 10910^9109
 
frontTireDistance
int
Total distance analyzed for the front tires (in km)
Min. value = 0 / Max. value = 1 000 000
rearTireDistance
int
Total distance analyzed for the rear tires (in km)
Min. value = 0 / Max. value = 1 000 000
frontBrakeDistance
int
Total distance analyzed for the front brakes (in km)
Min. value = 0 / Max. value = 1 000 000
rearBrakeDistance
int
Total distance analyzed for the rear brakes (in km)
Min. value = 0 / Max. value = 1 000 000
frontTireAutonomy
int
Front tires remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
rearTireAutonomy
int
Rear tires remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
frontBrakeAutonomy
int
Front brakes remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
rearBrakeAutonomy
int
Rear brakes remaining distance before change (in km)
Min. value = 0 / Max. value = 1 000 000
frontTireTotalWear
double
Total worn mass percentage of the front tires (right/left) 
Min. value = 0% / Max. value = 100%
rearTireTotalWear
double
Total worn mass percentage of the rear tires (right/left) 
Min. value = 0% / Max. value = 100%
frontBrakeTotalWear
double
Total worn mass percentage of the front brakes (right/left) 
Min. value = 0% / Max. value = 100%
rearBrakeTotalWear
double
Total worn mass percentage of the rear brakes (right/left) 
Min. value = 0% / Max. value = 100%
frontTireWearRate
double
Average wear rate for the front tires (in %/1000 km )
rearTireWearRate
double
Average wear rate for the rear tires (in %/1000 km )
frontBrakeWearRate
double
Average wear rate for the rear brakes (in %/1000 km )
The wear rate measures the component wear (in %) as a function of distance. This variable allows to compare vehicles and to inform a vehicle fleet manager whose components are wearing out too quickly. The wear rate is related to the type of vehicle, the driving style, the type of road used and the driving condition. This is why its value can change if the typology of trips changes and if the vehicle is driven by several drivers who have different driving styles.
Driver distraction (score)
Distracted driving becomes a serious problem and is becoming a major road safety issue.
That's why we've developed a service that measures the driver's interactions with his smartphone while driving. The objective is to increase driver awareness through a distraction score. This can be used to compare drivers, to classify them or to organize driving challenges.
The DriveKit SDK is capable of measuring the two main indicators of distracted driving: screen unlocks and outgoing or incoming (and answered) phone calls.
The distraction score depends on 2 parameters :
the smartphone unlocking frequency;
the total duration of the call (or calls if there are several in the same trip).
Each parameter is giving a sub-score from 0 to 10. The distraction score is the minimum between these two sub-scores.
The sensitivity functions for calculating the two sub-scores from the unlocking frequency and call duration are shown below.
This service is only available with the DriveKit mobile SDK.
The response body includes the trip scores as well as detailed data related to unlocks and calls. This way you can better understand the score construction and provide clear explanations to the driver.
The data returned by the service are listed in the table below:
Field
Type
Description
nbUnlock
int
Number of phone screen unlock events
nbLock
int
Number of phone screen lock events
distance
double 
Relative distance traveled with the screen on (in %)
distanceM
double
Distance traveled with the screen on (in m)
duration
double
Relative duration traveled with the screen on (in %)
durationS
double
Duration traveled with the screen on (in s)
score
double
Phone distraction score (Min. value = 0, Max. value = 10)
scoreUnlock
double
Distraction sub-score which takes into account the number of locking/unlocking
scoreCall
double
Distraction sub-score which takes into account the number of calls during the trip
calls
Call[]
Call
Call
The Driver distraction score provides an array with all the calls answered or made by the driver. For each call, it contains information about its conditions.
Value
Type
Description
id
int
Unique identifier of the call
start
double
Seconds from beginning of the trip when call starts
end
double
Seconds from beginning of the trip when call ends
durationS
double
Duration traveled in call (in s)
duration
double
Relative duration traveled in call (in %)
distanceM
double
Distance traveled in call (in m)
distance
double
Relative distance traveled in call (in %)
status
string
INCOMING : incoming call
OUTGOING : outgoing call
UNKNOWN : unknown call status
audioSystem
string
Audio system used to make the call (SPEAKER, LOUDSPEAKER, A2DP, HANDSFREE, HEADPHONE, CAR_AUDIO, UNKNOWN)
forbidden
boolean
true if the call is forbidden
false if the call  is authorized (made with handsfree)
Response body example
1
"driverDistraction": {
2
    "nbUnlock": 0,
3
    "durationUnlock": 13,
4
    "durationPercentUnlock": 2.5,
5
    "distanceUnlock": 33.54196351499925,
6
    "distancePercentUnlock": 0.4636710466546759,
7
    "score": 10,
8
    "scoreUnlock": 10,
9
    "scoreCall": 10,
10
    "calls": [
11
      {
12
        "id": 0,
13
        "start": 85,
14
        "end": 118,
15
        "durationS": 33,
16
        "duration": 6,
17
        "distanceM": 734,
18
        "distance": 10,
19
        "status": "INCOMING",
20
        "audioSystem": "HANDSFREE",
21
        "forbidden": false
22
      },
23
      {
24
        "id": 1,
25
        "start": 320,
26
        "end": 344,
27
        "durationS": 24,
28
        "duration": 5,
29
        "distanceM": 295,
30
        "distance": 4,
31
        "status": "UNKNOWN",
32
        "audioSystem": "HANDSFREE",
33
        "forbidden": false
34
      }
35
    ]
36
  }
Copied!
 Example of use
The screenshot below shows how to display the phone use data on a mobile phone interface:
Driver distraction (events)
The distraction score service provides additional information related to screen unlock and screen lock events. Thus, it is possible to get the location of events related to phone use. These informations are useful if you need to display these data on your mapping system or if you want to perform advanced data analysis.
The table below lists all the data returned by the service:
Field
Type
Description
time
double
Time since the beginning of the trip (in s)
latitude
double
Latitude (in deg)
longitude
double
Longitude (in deg)
velocity
double
Vehicle speed (in km/h)
heading
double
Vehicle heading (in deg)
elevation
double
Altitude (in m)
distance
double
Distance travelled since the beginning of the trip (in m)
type
int
Type of event : (1) Screen ON and (2) Screen OFF
Response body example
1
"distractionEvents": [
2
        {
3
            "time": 248.0,
4
            "latitude": 48.92460229,
5
            "longitude": 2.38685389,
6
            "velocity": 0.0,
7
            "heading": 0.6352998743575466,
8