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 Partner API reference to learn about the behavior of the API (endpoints, payloads, and much more). The API reference 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:
- Stable firmware - A firmware suitable for production usage.
- Bearing faults firmware - A sensor with firmware that generates bearing faults.
- 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}/measurements
API 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.
Comments
0 comments
Article is closed for comments.