AGV Software Validation Guide
A software update can affect mission assignment, navigation behavior, system interfaces, or exception recovery. ZCNEST explains how warehouse operators can validate a release, control deployment risk, and confirm that normal pallet movements still work before returning the fleet to full operation.
Not every software release has the same operational risk. An update may change the user interface, introduce a new WMS message, modify mission scheduling, correct a navigation issue, or update the vehicle controller. The test plan should be based on the components changed and the warehouse processes that depend on them.
Ask the supplier for release notes, affected components, known limitations, prerequisites, and any required configuration changes. Confirm whether the vehicle firmware, fleet software, server environment, and external interfaces must be updated together.
Current software and firmware versions.
Vehicle configuration and navigation settings.
WMS, WCS, PLC, and other relevant interface versions.
Known issues, workarounds, and current operating performance.
Backup and rollback procedures supported by the supplier.
STAGE 01
Check dependencies, configuration differences, backups, permissions, and the documented recovery procedure before installing the release.
STAGE 02
Test the changed function and repeat essential existing workflows to verify that previously working operations remain reliable.
STAGE 03
Deploy according to an approved schedule, monitor predefined indicators, and keep the agreed recovery process available until acceptance criteria are met.
A successful software startup does not prove that the release is operationally ready. Use representative missions covering the warehouse's normal pallet movement patterns, including pickup, transport, drop-off, and confirmation of completion.
Where the update affects route planning or traffic control, test intersections, shared aisles, restricted areas, and interactions with other vehicles. Where it affects integration, verify task creation, acknowledgements, cancellation, timeouts, and the handling of invalid messages.
Normal mission creation and completion.
Occupied pickup or delivery positions.
Communication interruptions and delayed responses.
Vehicle stops, canceled tasks, and authorized recovery.
Server restart or other relevant recovery scenarios.
Inventory and mission-status consistency after an exception.
Acceptance criteria should be measurable and agreed upon before testing starts. Depending on the release, these may include successful completion of critical workflows, no unresolved high-severity defects, correct interface responses, and performance within the warehouse's established operating limits.
Avoid approving a release solely because no obvious error appeared during a short trial. Record test results, software versions, configuration changes, failures, corrective actions, and the final approval decision. The evidence helps the team investigate problems if they appear after deployment.
Before deployment, confirm whether the previous version can be restored and which configuration or database changes must also be reversed. Some updates may not support a simple downgrade, so rollback feasibility must be verified with the supplier rather than assumed.
Define who can authorize a rollback, how vehicles will be placed in a safe state, and how interrupted missions and inventory records will be reconciled. Schedule the update during a period when the warehouse can support testing and recovery if the release does not pass acceptance.
Keep the release version, test cases, results, open issues, interface checks, approval record, and recovery instructions together. Confirm that warehouse operators and support personnel know what changed and how to report unexpected behavior after deployment.
Chinese
English
