Retesting After Component Replacement: A Deployment Evidence Guide

The impact assessment for a component replacement begins with identifying the functional role of the replaced component in the system and the acceptance criteria that depend on that function. A camera sensor replacement changes the imaging characteristics of the vision system, which affects all acceptance criteria that depend on vision-based detection, navigation, or positioning. A lidar sensor replacement changes the point cloud characteristics used for localization and obstacle detection, which affects navigation accuracy, obstacle avoidance, and any criteria that depend on spatial sensing.

A motor or actuator replacement changes the torque and speed characteristics of the affected joint or drive system, which affects cycle time, positioning accuracy, and any force or speed limit criteria for the affected motion. A computing module replacement changes the processing performance and memory characteristics of the compute platform, which can affect timing-sensitive behaviors in navigation, perception, and task execution.

For each replacement, the impact assessment should systematically identify the affected functional domains and the acceptance criteria within those domains before retesting begins.

Many robot components require calibration to the specific deployment environment or to the specific robot unit's mechanical state in order to function at the performance level verified at acceptance. When a calibrated component is replaced, the calibration must typically be repeated for the replacement component before acceptance-level performance can be expected. A camera sensor replacement requires intrinsic calibration of the new sensor and often requires extrinsic calibration of its position relative to the robot's reference frame.

A lidar sensor replacement requires calibration of the sensor's mounting alignment and sometimes the intensity calibration used for certain surface types. An inertial measurement unit replacement requires calibration of the sensor's offset from the robot's center of gravity and its response characteristics. Completing the required calibration before retesting and documenting the calibration procedure and results as part of the replacement record ensures that the retesting is performed in a state comparable to the original acceptance-tested state.

Retesting without appropriate calibration may produce results that do not accurately reflect the replacement component's performance in the deployment environment.

The retest plan after component replacement should list each acceptance criterion that was identified as potentially affected in the impact assessment, the specific test scenario to be executed for each criterion, the conditions under which the test will be run, and the pass criterion against which the result will be evaluated. The test scenarios and pass criteria should match the original acceptance test plan wherever possible, so that the retest results can be directly compared to the original results.

If the test conditions have changed since original acceptance - for example, if the facility layout has changed or the operational workflow has evolved - the retest plan should document the changes and assess whether the modified conditions are more or less demanding than the original conditions. Retest plans for component replacements should be approved by the deployment lead before retesting begins, with the approval documented so that the authority for the retest scope decision is on record alongside the test results.

Evidence capture during component replacement retesting should follow the same standards as original acceptance test evidence capture: primary evidence captured at the time of the test, specific to the test scenario and conditions, attributable to a specific test run with a date and operator identity. For sensor replacements, evidence should include the sensor output during the test scenarios - camera images or video, lidar point clouds, IMU readings - alongside the performance metrics derived from those outputs.

For computing module replacements, evidence should include performance timing measurements across the acceptance-critical compute-dependent functions. For actuator replacements, evidence should include force, speed, and position measurements for the acceptance-critical motion scenarios. The evidence should be captured in a format that facilitates direct comparison with the original acceptance test evidence for the same criteria, since the post-replacement performance comparison is the core analytical task that the evidence will support.

After component replacement retesting is complete, both the acceptance record and the provenance record must be updated. The acceptance record update links the new component's identity and the retest evidence to the acceptance criteria it satisfies, replacing the original acceptance evidence for those criteria with the post-replacement retest evidence. If the replacement component is from a different manufacturer or has different specifications than the original, the criteria verification results for the two components should both be preserved in the record, with a clear indication of which component's results are current.

The provenance record update captures the new component's manufacturer, model or part number, country of origin, and firmware version as a dated update to the affected subsystem's provenance fields. These two record updates together - acceptance and provenance - complete the documentation of the component replacement event and ensure that the deployment record accurately represents both the hardware identity and the acceptance state of the deployed system after the replacement.

• Conduct an impact assessment before retesting to identify acceptance criteria potentially affected by the replacement
• Complete any required calibration for the replacement component before beginning retesting
• Build a retest plan that lists affected criteria, test scenarios, conditions, and pass criteria matching the original acceptance test
• Capture retest evidence in formats consistent with original acceptance test evidence for direct comparison
• Document any criteria that fail or produce degraded results after replacement and initiate investigation
• Update the acceptance record to link the replacement component to the retest evidence for affected criteria
• Update the provenance record to reflect the replacement component's manufacturer, origin, and firmware version