Sensor Data Integration

The TSP is responsible for capturing and processing sensor data to determine and signal the health status of wheel ends. This article describes how to capture, manage, and share sensor 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

Sensor 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 sensor, 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 sensor.

Parsing & Processing Data

Sensors broadcast their current status 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. 

• Stable firmware: Suitable for production usage.
• Bearing faults firmware*: This firmware is only suitable during development to ensure that BLE connectivity works and that the implementation handles bearing faults.
• WEM faults firmware*: This firmware is only suitable during development to ensure that BLE connectivity works and that the implementation handles WEM faults.

* Development firmware runs a firmware version that predates the current firmware. Only use it for the use cases mentioned above. Other use cases are not valid because of an evolved Advertising Frame Description.

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

REQUIRED: Sensor 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).

Ensure Data is Properly Interpreted

Use the sensor data samples in the file HEX Strings Examples incl Decodings.xlsx document to validate that your code can properly interpret the sensor 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, sensor 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 sensor data are captured (see earlier sections).

Trigger Alarms & Present Data

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

REQUIRED: Sensor 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 sensor data to SKF for the sensor 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 sensor 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 sensor measurements, but there are rules to be aware of:

• The sensor must be commissioned in SKF systems before sensor data for that sensor can be shared with SKF. Sensor data for uncommissioned sensors is not accepted.
• Sensor 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.
• Sensor data must be qualified using the sensor’s hardware address.
• Sensor 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 sensor.
• 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 sensor data points from the same sensor can be grouped in a single API request. However, for a sensor 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 sensor data every 2 hours

For 10,000 vehicles with 4 sensors 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 sensor data as sent from the sensor.

• Simply assign the HEX-encoded string to the measurement attribute.

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

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