Skip to main content

Quality Assurance Test Protocol

Erik Wihlborg
  • Updated

The purpose is to verify that the integration solution developed by the TSP meets SKF’s minimal testing recommendations and can support a smooth and robust process for TraX sensor installation and use.

 

Scope

This protocol defines the set of tests for the entire integration solution, covering both SKF and TSP sides.

 

Test Methodology

Overview

If an issue is found, it should be classified into one of the following categories:

  • Show Stopper: Prevents the user from completing a critical action, halting the day-to-day work process. Classified as “failed” in the report.
  • Major: Prevents the user from completing a critical action, but can be bypassed with a workaround, allowing the user to continue daily work. Classified as “passed conditionally” in the report.
  • Minor: Prevents the user from completing a non-critical action, not affecting daily work. Classified as “passed conditionally” in the report.
  • Not Applicable (NA): No issue found.

Acceptance Criteria

All requirements and deliverables must be met. If issues are found, the following table defines the maximum allowable number of issues:

Issue Severity Maximum number of issues
Show stopper 0
Major 5
Minor NA

 

If the number of issues found is less than the maximum allowed, each issue must have an open ticket in TraX support and be documented in the report to pass the test.

Note: Each feature can generate a maximum of one issue. For example, if testing feature 3.2.1 across two different companies results in three major issues, 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)

TSP Platform

  • 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 a sensor was commissioned or decommissioned.
  • Ability to instruct the onboard gateway to start/stop listening to a specific sensor.
  • The gateway on the vehicle should be able to pick up BLE advertisement 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 the development environment that supported by TSP Provide information to SKF about the fleet that is going to be the test fleet:
  • Fleet Name
  • Fleet ID
  • Names and emails of testers

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:
  • Vehicle ID
  • Fleet ID
  • VIN
  • Etc.
 TSP vehicle store contains few vehicles with proper vehicle characteristics.
Connectivity1
2.1 Ability to connect to Web API
  1. Try to connect to TraX Web API;
  2. Make sure that the TSP can communicate with the TraX 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)
  1. Try to connect to TraX queues and receive a message from there;
  2. Make sure that you can connect to queues and that you can receive messages from the TraX queues.
 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
  1. Create a new vehicle in the TSP's vehicle store;
  2. Compare TSP- and TraX vehicle stores2.
 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
  1. Change a vehicle definitions (for example model or brand) in the TSP's vehicle store3;
  2. Compare TSP- and TraX vehicle stores1.
 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
  1. Remove a vehicle from the TSP's vehicle store;
  2. Compare TSP- and TraX vehicle stores2.
 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
  1. Make a few changes to a few vehicles in the TSP vehicle store;
  2. Compare TSP- and TraX vehicle stores2.
 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
  1. Search for vehicles by vehicle name in the TraX mobile App;
  2. Compare results to TSP's local vehicle store, and check that all relevant vehicles from the TSP’s vehicle store are presented in the search results;
  3. Repeat for 3-4 different vehicle names.

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
  1. Search for vehicles by VIN;
  2. Compare the results to TSP's local vehicle store, and check that all relevant vehicles from the TSP’s vehicle store are presented in the search results;
  3. Repeat for 3-4 different VINs.
 A list of vehicles filtered by VIN is presented to the user
5.3 Vehicle details
  1. Continue case 4.1 or 4.2 and select any vehicle from the list;
  2. Verify detailed information about the vehicle with the information about the vehicle in the TSP vehicle store;
  3. Check/correct the number of axles, specify driven/non-driven axles and click “Create Vehicle”;
  4. Repeat for 3-4 different vehicles/search cases (4.1 or 4.2).

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
  1. Continue case 5.3 and then commission a sensor to any wheel end at that vehicle. Make a screenshot of the sensor location (axle and side);
  2. Verify in TSP systems that the sensor has been commissioned;
  3. Repeat for 3-4 different sensors, axles, sides, and vehicles.
 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
  1. In continuation of case 6.1. Get the data about commissioned sensor from the TSP’s system
  2. Compare the data from screenshots taken in step 6.1 and make sure that the side and the axle in the TraX mobile application (screenshot) are the same as in the TSP’s system.
 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
  1. Continue case 6.1 and decommission one of the commissioned sensors. Make a screenshot after the sensor was decommissioned;
  2. Verify in TSP systems that the sensor has been properly decommissioned;
  3. Repeat for 3-4 different sensors, axles, sides, and vehicles.
 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
  1. In continuation of case 6.3. Get the data about commissioned sensors from the TSP system.
  2. Compare the data from the SKF’s system (screenshot taken during case 6.3) with data in the TSP’s system
  3. Make sure that the side and axle where the sensor was decommissioned are the same between TSP and SKF systems
 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
  1. Generate4 and capture data sent by the sensor that was commissioned during case 5.1;
  2. Verify that the measurement has been accurately parsed and that the data is available in TSP systems
 

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
  1. The table with HEX strings contains strings with all possible failures that the sensor can generate and some combinations of the faults.
  2. Take the first HEX string and inject failure bits (marked in red in the Excel document) to the BLE frame that was captured by the gateway for further processing
 (see comments under the table)6
  1. Check and compare values that were parsed and decoded by the TSP’s system with the failures and/or values presented in the table.
  2. Repeat steps 2-3 for all HEX strings in the table

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
  1. Continue case 7.2 and send data from the sensors to SKF.
  2. Contact SKF for verification in SKF systems. Provide SKF with all details about the measurement (date, mac-address of the sensor, etc.).
  3. Check that the data in SKF is the same as in the TSP
 Data in TSP systems and SKF systems are the same
Sensor Measurement. Data presentation
8.1 Data presentation to the customer
  1. Continue case 7.1 and review the data that should be presented to the customer;
  2. Check that the information is correctly presented for the correct vehicles/wheels/sides;
  3. Make sure that the widget (or any other software solution built by TSP) presents all required information about the wheel/sensor state and/or possible faults.

A vehicle widget (or any other software solution) represents all required data from all TraX sensors commissioned for the vehicle:

  • Battery level
  • Wheel End failure
  • Vibration sensor failure & other internal failure warnings + incorrect mounting position
  • Temperature sensor failure.

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 cannot be changed.
4 Refer to the Technical Specification for SKF TraX for conditions when the TraX sensor will generate BLE frames.
5  Examples of HEX strings are presented in the Excel file “HEX Strings Examples.xlsx”.
6 Failure bits in HEX strings examples are highlighted in red. These highlighted bits should be changed in the BLE frame captured by the gateway. After modification, the BLE frame 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

 

Related articles

Comments

0 comments

Article is closed for comments.