Skip to main content

Sensor data integration

Erik Wihlborg
  • Updated

The TSP is responsible for capturing and processing sensor data to determine and signal wheel end health status.

🚩 Device integration objectives

  • Capture sensor data
  • Parse & process sensor data
  • Transfer sensor data to TSP’s central platform

🚩 Alarm detection & UI integration objectives

  • Analyze sensor data to evaluate if alarms should be triggered.
  • Presentation of the state of wheel-end health.

🚩 Application integration objectives

  • Share sensor data with SKF

We recommend that you review the TraX web API definition to learn about the behavior of the API (endpoints, payloads, and much more). It's documented in the OpenAPI document TraX API reference. The document can be viewed online, or downloaded for viewing in your preferred OpenAPI renderer.

 

Capture sensor data

In the Sensor configuration integration, the vehicle's gateway was instructed to listen for broadcasts from sensors commissioned to the same vehicle.

RECOMMENDED: The gateway SHOULD filter sensor broadcasts based on hardware address

The gateway should filter sensor broadcasts based on hardware address (MAC address) to ensure that sensor data from nearby neighboring vehicles are not captured.

If gateway hardware address filtering is not possible, additional downstream processing steps in TSP's platform will be required to correlate/connect sensor data with the relevant vehicle.

 

Parse & process sensor data

Sensors broadcast their current status using Bluetooth Low Energy advertisement frames.

REQUIRED: The TSP's device integration implementation MUST support all valid advertising frame descriptions

Learn about the sensor data format in the "Advertising frame description" section in TraX - WEM200 - Technical Specification US. Ask your SKF representative for access to sensors running three different firmware to ensure you can generate and parse all the sensor data variants the sensor is capable of producing:

  1. Stable firmware - A firmware suitable for production usage.
  2. Bearing faults firmware - A sensor with firmware that generates bearing faults.
  3. WEM faults firmware - A sensor with firmware that generates WEM faults.

While we recommend TSPs to capture the complete sensor data, only a subset of it MUST be captured to meet the sensor data capturing requirements

REQUIRED: Sensor data capturing requirements

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

1 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 sensor data is properly interpreted

Use the sensor data samples in the file HEX strings examples incl decodings.xlsx to validate that your code can properly understand the sensor data format.

See the TraX technical specification for complete instructions about how to capture and parse sensor data.

 

Transfer sensor data to TSP’s central platform

Depending on the TSP platform's capabilities, sensor data may have 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 required parts of the sensor data are captured (see earlier).

 

Alarms and presentation of sensor data

We RECOMMEND that sensor data is presented in a "vehicle widget" where each wheel-end is mapped to a specific sensor.  See the Acting on sensor data article for guidance regarding mapping sensor statuses to the urgency of acting when designing the user interface and alarm capabilities.

REQUIRED: Sensor data presentation requirements

The user interface or alerting SHOULD cover:

  • Battery level

  • Wheel End Failure

  • WEM failure

  • Temperature Sensor failure

  • Temperature Warning active*

  • Vibration monitoring status*

*BSS10 feature.

 

Transfer sensor data to SKF

To transfer sensor data to SKF for the sensor with the hardwareAddress of "C4BD6A004042" execute:

Request: POST /sensors/C4BD6A004042/measurements

  {
    "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, whereas other attributes SHOULD be provided. See SKF TraX API reference for complete API request requirements.

The measurement attribute expects the TraX sensor advertising frame as a HEX-encoded string (more about that later), and additional information such as timeStamp, geographicPosition, and depending on the TSP's capabilities to determine mileage, either choose mileage-full or mileage-partial.

 

Implementation requirements & notes

The POST /sensors/{hardwareAddress}/measurementsAPI endpoint 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 by the web endpoint for sharing sensor data.
  • Sensor data SHOULD be sent in chronological order. While the endpoint accepts sensor data in both chronological and non-chronological order, other SKF services only guarantee to function properly if sensor data are received in chronological order.
  • Sensor data MUST be qualified using the sensor's hardware address.
  • Sensor data SHOULD be grouped in a single API request, but the API 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, for example, 2017-06-21T14:07:17Z (date time) or 2017-06-21 (date), and it MUST use the UTC (without time offsets).
  • To learn more about the expected API behavior, please see the TraX OpenAPI document SKF TraX API reference.

 

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, which implies that measurements could only be uploaded twice a day to get the greatest benefit from grouping measurements.

To optimize the load on the system, it’s important to strike a balance between transferring sensor data too seldom (increases system load), and too often (inefficient data transfer due to transport overhead).

RECOMMENDED: Transfer sensor data every 2 hours

We recommend that the TSP transfer sensor data to SKF every 2 hours. For 10 000 vehicles with 4 sensors, this translates to about 250 MB of data.

 

Providing the measurement attribute

Depending on the capabilities of the TSP’s technical platform, we’ve seen two methods for providing a valid measurement attribute.

Method A: When the TSP has access to sensor data as it was sent from the sensor

  • This is the easiest option to implement. 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

  • In this case, the sensor data payload needs to be reconstructed. Learn how to do that in the "Advertising frame description" section in WEM200/US technical specification.
  • Optional information can be padded with zeros. See "Sensor data capturing requirements" earlier in the document.

Related articles

Comments

0 comments

Article is closed for comments.