Purpose
To verify that the integration solution developed by the TSP meets SKF minimal testing recommendations and can support a smooth and robust process of TraX sensor installation and use.
Scope
The protocol defines the set of tests for the whole integration solution both from the SKF and TSP sides.
Test Methodology
Overview
If an issue is found it should be classified into one of the following categories:
- Show stopper – Prevent the user from completing a Critical action, without which the user can not proceed with the day-to-day work process. The show stopper will be classified as “failed” in the report.
- Major – Prevent the user from completing a Critical action that can be completed by a different set of actions (workaround), in this case, the user can proceed with his day-to-day work. Major will be classified as “passed conditionally” in the report
- Minor – Prevent the user from completing an action that does not affect its day-to-day work process. Minor will be classified as “passed conditionally” in the report
- Not Applicable (NA) – No Issue was found
Acceptance Criteria
All requirements and deliverables should be accomplished. In case any issue is found, the following table defines the maximum number of issues allowed :
Issue Severity | Maximum number of issues |
---|---|
Show stopper | 0 |
Major | 5 |
Minor | NA |
If the number of issues found is smaller than the maximum number of issues allowed, to pass the test, each issue should have a designated Open ticket in Azure that is documented in the report.
Note: Each feature can produce a maximum amount of one issue (e.g. testing feature 3.2.1 on 2 different companies was found with 3 Major issues, in this case, they will be counted as one issue)
Requirements
To use TraX sensors TSP needs to develop an integration solution that MUST include the following:
Vehicle store integration
- Share all vehicle definitions with SKF (creation, updating, and deleting of the vehicles)
- Share all vehicle definitions with SKF (full update once in 7-14 days)
Sensor integration (Software solution)
- Ability to store and receive sensor configuration attributes
- Ability to receive sensor configuration changed events
- Ability to receive all commissioned sensors from SKF for a specific vehicle
- Ability to determine if the sensor was commissioned or decommissioned
- Ability to instruct the onboard gateway to start/stop listening to a specific sensor
Sensor Integration (Hardware solution)
- An onboard gateway should be able to pick up BLE adv. frames based on a MAC-address
- Ability to persist sensor data to TSP’s system
IoT/UI integration
- Widget/Dashboard to present wheel end status to a customer
Test plan
# | Stage | Test steps/actions | Expected results |
---|---|---|---|
Preparation | |||
1.1 | Creating a new fleet in STAGING that supported by TSP | Provide information to SKF about the fleet that is going to be the test fleet:
|
Support of new testing fleet established on SKF side; Accounts of testers are created, and credentials/invitations are sent to testers. |
1.2 | Populate fleet with a few vehicles that will be used for testing | Create a few vehicles (NOT REAL ONES) under the newly created fleet with proper vehicle definitions:
|
TSP vehicle store contains few vehicles with proper vehicle characteristics. |
Connectivity1 | |||
2.1 | Ability to connect to Web API |
|
TSP should receive a successful response from the TraX Web API. |
2.2 | Ability to connect to queues (Optional. If TSP architecture doesn’t use queues, skip this step) |
|
TSP should be able to connect to TraX brokers and receive a message(s) from the queues |
Vehicle store integration. Continuous updates | |||
3.1 | Creation of a new vehicle |
|
The new vehicle should automatically be created in the TraX vehicle store. Usually, an update SHOULD not exceed 60 minutes and the time depends on a TSP architecture. |
3.2 | Changing a vehicle in the TSP’s vehicle store |
|
The changes to the vehicle definitions should be reflected in the TraX vehicle store. Usually, an update SHOULD not exceed 60 minutes and the time depends on a TSP architecture. |
3.3 | Removing a vehicle from the TSP’s vehicle store |
|
The removed vehicle should also be removed from the TraX vehicle store. Usually, an update SHOULD not exceed 60 minutes and the time depends on a TSP architecture. |
Vehicle store integration. Full updates | |||
4.1 | The full update of vehicles in the vehicle store |
|
All vehicles (in the scope of TraX) in the TSP's vehicle store get recreated in the TraX vehicle store. Full update MUST be done once in 7 days but the exact time depends on a TSP architecture. |
Vehicle store integration. Data quality | |||
5.1 | Search for vehicles by name |
|
A list of vehicles filtered by vehicle name is presented to the user; The list includes all vehicles relevant to the search query. |
5.2 | Search for vehicles by VIN-number |
|
A list of vehicles filtered by VIN is presented to the user |
5.3 | Vehicle details |
|
A page with vehicle details should be presented to the customer; It should be possible to add/remove axles for the selected vehicle, select driven/non-driven axles; Information about the vehicle is the same as in the TSP’s vehicle store (Vehicle ID, number of axles, etc.) |
Commissioning/Decommissioning of the sensors | |||
6.1 | Commissioning of a sensor |
|
The TraX sensor gets automatically registered in SKF and TSP systems. The time of commissioning depends on a TSP integration solution architecture. Usually commissioning of the sensor SHOULD not exceed a few minutes. |
6.2 | Commissioning data check |
|
The axle and side of the vehicle where the sensor is commissioned are the same in SKF and TSP systems |
6.3 | Decommissioning of a sensor |
|
The TraX sensor gets automatically decommissioned in SKF and TSP's systems. The time of decommissioning depends on a TSP integration solution architecture. Usually decommissioning of the sensor SHOULD not exceed a few minutes. |
6.4 | Decommissioning data check |
|
The axle and side where the sensor is decommissioned are the same in TSP and SKF systems. |
Sensor measurements. Data capturing | |||
7.1 | Generating and capturing regular data sent by a sensor |
|
Captured sensor measurements should become available in SKF and TSP systems. The time of data measurement sync depends on a TSP integration solution architecture RECOMMENDED time, when the data will appear in the SKF’s systems, SHOULD be approx. 2 hours. |
7.2 |
Generating and capturing failures data; BLE decoding check |
|
Decoded values in TSP are the same as decoded values in the table TSP can correctly identify all faults and faults combinations that the sensor can generate |
7.3 | Captured data check |
|
Data in TSP systems and SKF systems are the same |
Sensor Measurement. Data presentation | |||
8.1 | Data presentation to the customer |
|
A vehicle widget (or any other software solution) represents all required data from all TraX sensors commissioned for the vehicle:
Required information presented only for axles/sides with commissioned sensors; Data that is shown to the customer is the same as data that was generated by the sensor on the corresponding vehicle/axle/side |
1 Instructions on how to check connectivity are presented in the paragraph “Connectivity testing”.
2 Vehicles in the TraX vehicle store can be retrieved using GET /fleets/{fleetId}/vehicles.
3 Fleet ID and Vehicle ID are immutable and hence are not allowed to be changed.
4 See Technical Specification for SKF TraX for conditions when the TraX sensor will generate BLE frames.
5 Table with examples of HEX strings presented in Excel file “HEX strings examples.xlsx”
6 Failure bits in HEX strings examples are highlighted in red. Highlighted bits should be changed in the BLE frame captured by the gateway. After that BLE with injected failure bits should be treated as a regular BLE frame.
Resource & Environment Needs
- Establish support for the new fleet in the SKF
- Active Enlight accounts for installers
- A fully ready TSP integration solution (software and hardware)
- TraX mobile application
- TraX Sensor
- Onboard gateway
Terms/Acronyms
Make a mention of any terms or acronyms used in the project.
TERM/ACRONYM | DEFINITION |
---|---|
BLE | Bluetooth Low Energy |
VIN | Vehicle Identification Number |
Comments
0 comments
Article is closed for comments.