Data workflow and categories of data
We describe how different categories of data are processed on the platform and how they can be accessed.
For a basic use case, you will access our platform through the SDK and the APIs, as described in Available Methods and API
Additionally, you can access data in a variety of ways that fit different architectures and use cases. Below we describe how to do this:
Principal schematic of data flows
Three main categories of data: Sensor/GPS, Device Status, and In-Vehicle data
- GPS and sensor data is the core telematics information processed by our platform and the most important part. All physical and geographic data (location, speed, cornering speed, acceleration) are included in this category.
- Device Status (Former Heartbeats) is a very basic status updates. They are transmitted about every two hours, and provide information like phone and app status, if tracking enables, how many trips are waiting to be uploaded, etc.
- In-vehicle Data (not to confuse with sensor data) is data obtained directly from the car's onboard computer via OBD (Add-on Service with Bluetooth OBD). (For most typical applications, this is not required, but it can be a very powerful integration for fleet management solutions that also want to monitor the maintenance information of the vehicle like engine fault codes or time since the last oil change.
Gathered data
- GPS (1hz) 👉 Raw Telematics Data Format
- Data from a gyroscope, magnetometer, and accelerometer (60hz)
- Data on whether the device is locked and the screen is on
General description of data flow
On the most basic level, telematics data flows from user devices to the Datamotion platform and from there to your own back-end (if you have your own back-end, which is optional). Additionally, you may choose to show data again on the user devices, which is accomplished by accessing the API from your app (not shown above). You can choose to not do that at all (e.g. in fleet apps, where you just collect data), or you can choose to only do that (if you don't have a back-end). This all depends on the architecture of your solution.
Furthermore, you can choose to access raw telematics data directly (Items 1 and 2 above), or you can choose to utilize our processed and enriched data (items 3, 4 and 5 above). This also depends on your setup.
Few solutions will use all options, so some of the details below may not apply to use.
Data options
Data merged into a trip and identified as vehicle trips
Including false-positive crash events
Events filtered by our AI-model
Note that this is an advanced and rare use case. For most driver behavior and fleet management use cases, you will not need to use this.
[In-vehicle data collection]](doc:bluetooth-obd) is an advanced feature that is available as an add-on, and it works as follows: The SDK connects through Bluetooth to a so-called OBD (On-Board Diagnostics) device that talks directly to the car's onboard computer to get data like engine failure codes, maintenance status, etc. One example would be to generate a notification when the "Check Engine" light is on.
This feature requires additional hardware 👉 Bluetooth OBD and communication via Bluetooth, and requires specific knowledge of the make and model of the car. It is most commonly used by fleet apps that actively manage the vehicles and their maintenance.
👉 In-vehicle data
The SDK also captures permissions & phone status data to support background operation. We call this "heartbeats" - system information from the mobile device that contains permissions status, device information, and so on.
👉 Device Status
GPS and sensor data: The core datasets of our solution.
Items 1, 2, and 4 above
In most cases, the raw telematics dataset is not useful, and most applications will take advantage of our ready-to-use processing services that are easily accessible through the various APIs. However, some use cases (basic forensics, advanced behavior scoring, etc.) may benefit from having access to raw telematics datasets to store, process, and analyze the data on your own platform.
Data Processing Workflow for GPS and Sensor data
The SDK continually collects data from the sensors (GPS locations and acceleration events). Out of that data, our SDK creates raw "tracks": A series of locations and events from when the user started driving until they stop and exit the vehicle. This can be trickier than it sounds: For example, did the driver stop at a red light, or did the driver park in a parking spot next to a red light? Did they actually start driving, or did the GPS signal jump locations and it just looked like they are moving at driving speed? Such considerations may result in some invalid tracks, which are removed. Additionally, some tracks can be actively excluded - when a driver is off the clock, outside a certain geofence, or riding as a passenger. These are excluded tracks. Everything that is not invalid or excluded results in raw trips data on our platform. Once these trips are filtered, processed, and enriched, they become processed trips data.
Data samples
For your convenience, we've attached the data from a sample trip (recorded in March 2021 outside Cambridge, UK)
- Raw Telematics data (notification IncomingTrackReceived) Download JSON file, 1.2 MB
note that an IncomingTrackRemoved notification technically also links to an object similar to this one, but it will contain little or no useful information, but may be used for troubleshooting if you get many invalid tracks. - Processed Trip Data (notification TrackEnrichementFinished) Download JSON file, 341 kB
Data Format Reference
👉 Raw Telematics Data Format
👉 Processed telematics data format
👉 Processed telematics data - Offline Reporting
How to get the data?
1. Realtime data
Configure 3rd party end-point and point data to this end-point More details
1-8 items from the scheme above
When a dataset moves from one stage to the next on the Datamotion platform, it creates an event. You can subscribe to those events to then access the relevant data
Note
Notification message doesn't contain any track’s data, such as events or waypoints. To get these details, you have to query the track’s data using the Web API service, using credentials received from SNS Message.
We support several well-known notification services, including Amazon and Azure. Each notification contains URLs, identifiers, and credentials for the respective dataset.
Important
Your back-end or application had to be prepared to receive several notifications related to a single trip. It means the previous version of the track has been updated, and you need to retrieve an updated version from our API again.
An Example where this happens would be that the track was merged with another trip segment. the updated trip will have new trip details (time, distance, etc)
Updated over 2 years ago