Sensor Data Integration

The Telematics provider is responsible for capturing and processing device data to determine and signal the health status of wheel ends. This article describes how to capture, manage, and share device data.

We highly recommend reviewing the TraX web API OpenAPI document to fully understand the API's functionality, including its endpoints, payloads, and other important details.

Objectives 🎯

Device Integration

• Capture data.
• Parse & process data.
• Transfer data to Telemetics provider´s central platform

Alarm Detection & UI Integration

• Analyze data to determine if alarms should be triggered.
• Present the state of wheel-end health.

Application Integration

• Share data with SKF.

Storing Data Frames

Device data frames are captured by the gateway at the edge (vehicle) and transferred to the Telematics platform. Although the Telematics may parse and segment the data as needed, we recommend also storing the entire payload as originally sent from the device, i.e., the 62-character HEX-encoded string. This approach makes it easier to fulfill the requirements of this integration.

RECOMMENDED: Retain the entire advertisement frame exactly as sent by the device because that is the format the frame should be included in the Sensor Data Integration.

While we recommend retaining the entire advertisement frame exactly as sent by the device. However, at a minimum, the telematics provider can provide the sections labeled "MAC address" and "Statuses incl debug data" from the frame example below, padding all other data with zeros ("0").

               MAC address           Statuses incl debug data
                 ____|_____          ___________|____________
                /          \        /                        \
0201060A0957454D46464646354410FF0E0401114A2D4A2300000000006E00

Parsing & Processing Data

The structure of the data frames has evolved over the years with each major firmware release.

REQUIRED: The Telematics provider´s device integration implementation must support all valid advertising frame versions.

Refer to Guidance for Interpreting Device Data for more information about properly intepreting the data frame. 

Transfer Data to Telematics Central Platform

Depending on the telematic 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).

Trigger Alarms & Present Data

We recommend presenting device data in a "vehicle widget" where each wheel end is mapped to a specific device. Refer to the Acting on Sensor Data for guidance on mapping device statuses to the urgency of action when designing the user interface and alarm capabilities.

REQUIRED: Device Data Presentation Requirements

The user interface and/or alerting should cover:

• Battery level

• Wheel End Failure

• WEM failure

• Temperature Sensor failure

• Temperature Warning active*

• Vibration monitoring status*

* Firmware BSS10 feature.

Transferring Data to SKF

Now that the data has been captured, parsed, and the insights are visibile in the telematics platform UI, the data should be uploaded to SKF. Data is shared with SKF using the TraX web API.

Below is a sample request that shows how to transfer device data to SKF for the device with the hardware address "C4BD6A004042"

POST /sensors/C4BD6A004042/measurements

// Request payload:

[
  {
    "measurement": "0000000000000000303034303432000000002122544242DD31000062105A00",
    "timeStamp": "2019-08-24T14:15:22Z",
    "measurementContext": {
      "vehicle": {
        "geographicPosition": {
          "latitude": 57.69699,
          "longitude": 11.9865
        },
        "mileage": {
          "mileage-full": 2323
        }
      }
    }
  }
]

Parts of the measurement attribute are required, while other attributes should be provided. See the SKF TraX API reference for complete API request requirements.

The measurement attribute expects the TraX device advertising frame as a HEX-encoded string, along with additional information such as timeStamp, geographicPosition, and depending on the TSP’s capabilities to determine mileage, either mileage-full or mileage-partial.

Implementation Requirements & Notes

The POST /sensors/{hardwareAddress}/measurements API operation accepts a list of device measurements, but there are rules to be aware of:

• The device must be commissioned in SKF systems before data for that device can be shared with SKF. Device data for uncommissioned devices are not accepted.
• Device data should be sent in chronological order. While the operation accepts data in both chronological and non-chronological order, other SKF services only guarantee proper function if data is received in chronological order.
• Device data must be qualified using the device’s hardware address.
• Device data must be grouped in a single API request, but the request must not exceed 20 data points, and all data points must originate from the same device.
• Date and time must always conform to the ISO 8601 format, e.g., 2017-06-21T14:07:17Z (date time) or 2017-06-21 (date), and must use UTC (without time offsets).

For more details on expected API behavior, refer to the TraX API reference document.

Performance Considerations

Up to 20 device data points from the same device can be grouped in a single API request. However, for a device to produce 20 data points, it must be active for about 12 hours under normal operations, implying that measurements could only be uploaded twice a day to maximize the benefit of grouping measurements.

To optimize system load, balance the frequency of data transfers. Transferring data too seldom increases system load, while transferring too often is inefficient due to transport overhead.

RECOMMENDED: Transfer device data every 2 hours

For 10,000 vehicles with 4 device each, this translates to about 250 MB of data.

Providing the Measurement Attribute

Depending on the TSP’s technical platform capabilities, there are two methods for providing a valid measurement attribute:

Method A: When the TSP has access to device data as sent from the device.

• Assign the HEX-encoded string to the measurement attribute.

Method B: When the TSP does not have access to the device data as sent from the device.

• The device data payload needs to be reconstructed. Refer to the "Advertising Frame Description" section in TraX - WEM200 - Technical Specification Connected document.