Skip to main content

Protocol for Quality Assurance Testing

Erik Wihlborg
  • Updated

This test protocol aims to verify that the integration solution developed by the telematics provider meets SKF’s minimum testing requirements and ensures a smooth, reliable process for TraX device installation and use.

It outlines the complete set of tests for the integration solution, encompassing both SKF and telematics components.

 

Test Methodology Overview

If an issue is identified, it should be categorized as follows:

  • Show Stopper: Blocks the user from completing a critical action, disrupting daily operations. Marked as "failed" in the report.
  • Major: Prevents a critical action but has a workaround, allowing work to continue. Marked as "passed conditionally" in the report.
  • Minor: Affects a non-critical action without impacting daily operations. Marked as "passed conditionally" in the report.
  • Not Applicable (NA): No issue found.

Acceptance Criteria

All requirements and deliverables must be met. The following table defines the maximum allowable number of issues:

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

 

Issue Management

If the number of identified issues is within the allowable limit, each issue must have an open ticket in TraX support and be documented in the test report for the test to pass.

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 a single issue.

 

Requirements

To integrate TraX devices, the telematics provider must develop an integration solution that includes the following:

 

Vehicle Store Integration

  • Share all vehicle definitions with SKF, including creation, updates, and deletions.
  • Provide a full vehicle definition update to SKF every 7-14 days.

Telematics Platform

  • Store and receive sensor configuration attributes.
  • Handle Sensor Configuration Changed events.
  • Receive all commissioned devices from SKF for a specific vehicle.
  • Determine whether a device has been commissioned or decommissioned.
  • Instruct the edge device (on the vehicle) to start or stop listening to a specific device.
  • Ensure the edge device can detect BLE advertisement frames based on MAC address.
  • Persist device data within the telematics system.
  • Provide a widget or dashboard to display wheel-end status to customers.

 

Test plan

1. Preparation

1.1 Setting Up a Fleet and Onboarding 3rd Party for Installing Devices

Action:

  • Create a new fleet in the development environment that is supported by telematics provider.
  • Request onboarding of the 3rd party Installer using the Onboard Installer support form. 
  • Create test users in the user administration section of the SKF platform.

Expected Result:

  • The fleet is created.
  • Tester accounts are created, and credentials/invitations are sent.

 

1.2 Populating the Fleet with Test Vehicles

Action:

  • Create several test (non-real) vehicles in the newly created fleet with appropriate vehicle definitions, including:
    • Vehicle ID
    • Fleet ID
    • VIN, etc.

Expected Result:

  • The TSP vehicle store contains test vehicles with correct attributes.

 

 

 

# 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.