Sensor Data Integration

The TSP 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 TSP’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

Device data is captured by the gateway at the edge (vehicle) and transferred to the TSP platform. Although the TSP 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.

Parsing & Processing Data

Devices broadcasts statuses using Bluetooth Low Energy (BLE) advertisement frames.

REQUIRED: The TSP’s device integration implementation must support all valid advertising frame descriptions.

Refer to the "Advertising Frame Description" section in the TraX - WEM200 - Technical Specification Connected. 

While capturing the complete device data is recommended, only a subset must be captured to meet the requirements:

REQUIRED: Device Data Capturing Requirements

• End of MAC address
• Battery
• Health status
• Position
• Axle
• Tcurrent
• Tmin
• Tmax
• Frame Counter
• Debug data ¹

¹ The debug data portion of the BLE frame is required and needs to be treated as an opaque string in TSP systems (i.e. not decoded).

Development Devices

In addition to the TraX devices running stable firmware, SKF offers devices running a firmware specifically designed for the development integration phase, referred to as "development devices."

Development devices broadcast BLE advertising frames every 10 seconds, cycling to one of six supported data frames every five minutes.

These frames represent a subset of device statuses but do not encompass the full range of data variations required for complete device integration.

Please be aware that the TraX mobile apps may prompt you to upgrade the firmware of development devices. Do not perform firmware upgrades on these devices, as they are intended solely for development purposes and must not be used in production environments.

The data frames generated by a development device include:

AdvFrame1: Battery low level + Bearing failure 0x12
AdvFrame2: Battery extreme low level 0x01
AdvFrame3: Vibration sensor failure (WEM FAILURE) 0xA1
AdvFrame4: Internal WEM Failure (Piezofailure) 0x61
AdvFrame5: Temperature Sensor Failure 0x25
AdvFrame6: Bearing Failure + Temperature Sensor failure 0x26

Contact your sales represent for more information about TraX development devices.

Ensure Data is Properly Interpreted

The structure of the data frames has evolved over the years with each major firmware release. To ensure accurate data interpretation, the TSP must determine the frame version before parsing the data. The frame version is located at position 60 (the second-to-last byte) in the hexadecimal string of the device data.

REQUIRED: To ensure accurate data interpretation, the TSP must identify the frame version before parsing the data.

We provide device data samples in the file HEX Strings Examples incl Decodings.xlsx, use them to validate that your code can properly interpret the data format.

Refer to the TraX - WEM200 - Technical Specification Connected for complete instructions on capturing and parsing sensor data.

Transfer Data to 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).

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

// 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 ust be commissioned in SKF systems before data for that device can be shared with SKF. Device data for uncommissioned devices is 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.

• Simply 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.