This article primarily describes how to capture and handle data frames. The TSP is responsible for capturing, processing, and presenting relevant wheel-end health insights and device operational statuses to customers, as well as issuing notifications when necessary.
Sharing device data with SKF is essential to ensure that the latest device statuses are reflected in the TraX mobile app and to enable SKF to effectively support troubleshooting and resolve operational issues.
Capturing data frames
Devices broadcast status information using Bluetooth Low Energy (BLE) advertising frames. For additional details, refer to section 4.9.6, Advertising Timing, in the TraX Technical Specification (Connected Version).
Storing and intepreting data frames
Refer to the Data Frame Parsing Guide article for more information about properly intepreting the data frame.
Transferring data to the TSP’s central platform
Depending on the TSP platform’s capabilities, device data may need to be parsed on the edge (i.e., the vehicle) and sent in a different format to the TSP’s central platform. If this approach is required, ensure that the necessary parts of the data are captured (see earlier sections).
Triggering alarms and presenting insights
We recommend presenting device data in a "vehicle widget" where each wheel end is mapped to a specific device. Refer to the Alarm Prioritization & Recommended Actions and Device Features Reference articles for guidance on mapping device statuses to the urgency of action when designing the user interface and alarm capabilities.
Required: The user interface and/or alerting should cover the following statuses:
Wheel end health
- Wheel end failure
- Temperature
Device operational status
- Battery level
- Wheel end monitoring
- Temperature sensor
Transferring data to SKF
Sharing device data with SKF is essential to ensure that the latest device statuses are visible in the TraX mobile app and to enable SKF to effectively support and resolve operational issues.
Use the POST /sensors/{hardwareAddress}/measurements operation to upload data to SKF.
// Upload data points to SKF
POST /sensors/C4BD6A004042/measurements
// Example payload:
[
{
"measurement": "0000000000000000303034303432000000002122544242DD31000062105A00",
"timeStamp": "2019-08-24T14:15:22Z",
"measurementContext": {
"vehicle": {
"geographicPosition": {
"latitude": 57.69699,
"longitude": 11.9865
},
"mileage": {
"mileage-full": 2323
}
}
}
}
]Depending on the TSP’s capabilities to determine mileage, use either mileage-full or mileage-partial.
Usage notes
- The device must be commissioned in SKF systems before data can be submitted. Measurements from uncommissioned devices are not accepted.
- Device data must be qualified by the device’s hardware address.
- Measurements should be sent in chronological order. While the API accepts non-chronological data, other SKF services only guarantee correct behavior when data is received in chronological order.
- Date and time values must conform to ISO 8601 and use UTC without offsets, for example:
2017-06-21T14:07:17Z2017-06-21
Grouping data points
Under normal operating conditions, a device generates approximately 20 data points over a 12-hour period.
- We recommend batching 10 data points per request. This ensures that no data point is more than six hours old when transmitted to SKF. The maximum number of data points allowed per request is 20.
- All data points within a single request must originate from the same device.