Trip management

Trip autostart

The automatic mode detects vehicle movements and triggers the trip analysis without driver intervention while the application is in background. The analysis is stopped automatically at the end of the trip.

This feature is recommended to avoid driver distraction and phone handling while driving. The automatic mode has been optimized to limit the battery drain.

By default, automatic trip detection is disabled, but you can enable it by calling the following method:

DriveKitTripAnalysis.shared.activateAutoStart(enable: true)

To disable automatic trip detection call the same method with parameter enable set to false

DriveKitTripAnalysis.shared.activateAutoStart(enable: false)

If a trip is running when automatic trip detection is disable, the trip will not be canceled. If you want to cancel the trip, you should also call cancelTrip method.

Manually start a trip

You can start a trip by calling the following method:

DriveKitTripAnalysis.shared.startTrip()

If a trip's already started, calling this method will have no effect.

Stop a trip

You can stop a trip by calling the following method. The trip will be stopped instantly:

DriveKitTripAnalysis.shared.stopTrip()

If a vehicle stops longer than the timeout configured, the trip will be stopped automatically.

If there is no running trip, calling this method will have no effect.

Cancel a trip

If you want to cancel a trip, you can call this method:

DriveKitTripAnalysis.shared.cancelTrip()

If no trip is running or if the trip has been sent to the server and is currently analyzed, calling this method will have no effect.

Vehicle

To obtain a more precise analysis on driving behavior, it's recommended to configure the vehicle used by the driver. You can do this by calling the following method:

DriveKitTripAnalysis.shared.setVehicle(vehicle: TripVehicle?)

A detailed description of vehicle parameter is available here.

If no vehicle is configured a default vehicle will be configured with following parameters:

• carTypeIndex = 1

• carEngineIndex = 1

• carPower = 150

• carMass = 1400

• carGearboxIndex = 2

• carConsumption = 4.5

• engineDisplacement = 1200

• frontTireSize = "205/55/16"

• rearTireSize = "205/55/16"

• length = 4.5

• width = 1.8

• height = 1.45

• engineCylinderNb = 4

• driveWheels = 0

SDK recorder state

Two methods are available to determine SDK state.

DriveKitTripAnalysis.shared.isTripRunning()

This method returns false if the SDK is in inactive state, and no trip is currently running.

If you want a more detailed state of the SDK, you can call the following method:

DriveKitTripAnalysis.shared.getRecorderState()

This method returns the state of the SDK:

• inactive: No trip is running.

• starting: The auto start mode detects a movement of the user and checks if it's a trip in vehicle.

• running: The trip has been confirmed by the speed of the movement.

• stopping: The SDK is in this state when a potential trip end is detected. If the trip continues, the SDK goes back in running state. The duration of the stopping state can be configured.

• sending: The trip is finished and is being sent to DriveQuant's server. When the SDK has the response from the server, the state becomes inactive waiting for the next trip.

StartMode of the current trip

Trip Analysis offers a method to retrieve the StartMode of the current trip. The method returns nil if no trip is running.

DriveKitTripAnalysis.shared.getCurrentStartMode()

Manual trip repost

Trip Analysis SDK have a repost mechanism, in most cases, when a trip is finished it is sent to DriveQuant's server to be analyzed and once it's done, the result of the analysis is sent back to the SDK.

In some case, the trip can't be sent to the server (no network for example). In this case, the SDK will save the trip data locally, to send it later. A retry will be attempted when the next trip will start.

If you want to check if there is locally saved trips and if they can be sent to the server, you can call the following method:

DriveKitTripAnalysis.shared.checkTripToRepost()

Custom stop timeout

A trip being analyzed is automatically stopped after a period of inactivity (which begins when the vehicle has stopped). The DriveQuant SDK allows to set the end-of-trip duration.

By default, the trip analysis is stopped after 240 seconds. This value can be tuned according to your need and you can choose any integer values between 120 and 480 seconds by calling the following method:

DriveKitTripAnalysis.shared.setStopTimeOut(timeOut: 180)

If a value greater than 480 is set, the value will be forced to 480.

If a value lower than 120 is set, the value will be forced to 120.

Sharing data during the trip

The Trip Analysis SDK records the trip locally while it is in progress. The data are recorded with a period of one point per second. At the end of the trip, the SDK requests the driving analysis service and then retrieves the driving indicators.

In addition to this feature, the SDK is also able to share data with the server before the journey is completed. The data is transmitted at a lower frequency with a time interval of one point per minute.

The system for sharing information during the trip can be used in a vehicle fleet management system. This feature requires access to specific APIs. For more information, contact DriveQuant.

Sharing information with the server allows you to store the trip data even if it's been interrupted and the data post could not be performed at the end of the trip. This can happen in very rare cases such as the destruction of the mobile phone for instance.

By default, this setting is disabled but you can enable it by calling the following method:

DriveKitTripAnalysis.shared.enableSharePosition(enable: true)

To disable this setting, call the same method with the parameter set to false

DriveKitTripAnalysis.shared.enableSharePosition(enable: false)

Here is the list of data shared every minute by the SDK:

• Date of trip start.

• Duration of the trip in seconds.

• Distance traveled in km.

• Longitude of the current location.

• Latitude of the current location.

• Smartphone battery level.

• Start-Mode for trip recording: manual, GPS-based or beacon-based.

• Beacon parameters: uuid, major, minor.

Access the trip trigger events

Why use trip triggers?

DriveKit's automatic start mode detects a trip and launches its recording immediately. This operating mode may not be appropriate for all use cases.

Your application may require other information or business logic before enabling the trip recording. For example, it may be appropriate to check that:

• A connected device is near to the smartphone.

• The trip recording is acceptable in a given time slot.

In this case, you may want to subscribe to the events that are indicative of the trip start but not necessarily launch the GPS sensor and the trip analysis.

This is why DriveKit allows you to subscribe to trigger events that indicate that a trip has probably started.

How does it work?

By default, this feature is disabled.

To enable this feature, DriveKit Trip Analysis should not be configured in automatic mode but in manual mode.

If DriveKit Trip Analysis is set to automatic mode, the trip will be recorded.

If DriveKit Trip Analysis is set to manual mode and you follow the instructions below, you will be able to listen for trip start trigger events but the trip analysis will not be started automatically.

To listen to trigger events that indicate a start of trip, even if the autostart is disabled, you can call the following method:

DriveKitTripAnalysis.shared.monitorPotentialTripStart = true

Once the feature is enabled, events will be available in the TripListener potentialTripStart() callback.

The potentialTripStart() method can return all StartMode values ; except MANUAL. Indeed, a trip manually started is considered as confirmed.