AMR Change Control After Go-Live How to Define the Right Revalidation Scope
The Accepted System Starts Aging the Moment It Goes Live
An autonomous mobile robot application is accepted against a defined combination of hardware, software, maps, payloads, routes, infrastructure, procedures and operating conditions. Production then begins changing that combination. A rack moves. A new pallet enters the process. A software patch is installed. A Wi-Fi controller is replaced. A speed zone is widened to recover throughput. None of these actions may look like a new robot project, yet each can invalidate part of the evidence that supported the original release.
This is why AMR change control is not administrative document management. It is the engineering discipline that protects the validity of an accepted safety case after go-live. The central question is not merely, “Was the change approved?” It is, “Which assumptions, hazards, safety functions, interfaces and operating limits did the change touch, and what new evidence is required before the altered application can be released?”
The broad AMR and AGV acceptance testing guide explains how FAT, SAT, commissioning and handover fit together. This article begins where acceptance ends. It provides a lifecycle method for controlling the evidence delta created by changes without blindly repeating every original test or accepting unsupported claims because the robot “still seems to run.”
Revalidation Is a Delta Problem, Not a Calendar Ritual
Periodic testing can reveal degradation, but elapsed time alone does not define the correct revalidation scope. A system can remain unchanged for a year and retain its evidence, while one unreviewed parameter edit can alter stopping behavior in a minute. Revalidation should therefore be event-driven as well as periodic.
AMR safety revalidation is the structured confirmation that affected risk-reduction claims remain valid after a change, anomaly or accumulated drift. It differs from routine inspection, which checks condition; preventive maintenance, which restores expected condition; functional testing, which demonstrates selected behaviors; and complete reassessment, which rebuilds the risk argument for a substantially different application.
Do not confuse sameness of output with sameness of risk
A robot may still reach the same destination after a map edit, yet it may pass closer to a blind doorway. It may still stop after a firmware update, yet the response-time distribution may have changed. It may still dock after a payload change, yet the new center of gravity may increase load motion during an emergency stop. Successful task completion shows that the process works under the observed condition; it does not prove that the earlier safety evidence remains applicable.
Do not repeat the complete SAT by default
Full repetition can consume time without increasing confidence if most claims are unaffected. The better objective is complete impact reasoning followed by proportionate evidence. The organization must be able to explain why excluded tests are irrelevant, not merely why including them would be inconvenient.
The Change Passport: One Record That Travels with Every Modification
Effective autonomous mobile robot change management needs a common record that operations, engineering, safety, IT, maintenance and suppliers can all understand. We call this record the Change Passport. It follows the modification from proposal through impact analysis, test selection, deployment, observation and closure.
The passport is deliberately different from a maintenance ticket. A ticket records work performed. The passport records why the change is acceptable and which evidence boundaries have moved.
| Passport panel | Required content | Decision value |
|---|---|---|
| Baseline anchor | Released hardware, software, map, parameters, load, route and environment identifiers | Establishes the evidence starting point |
| Change fingerprint | Exact files, components, values, locations, reason, supplier notice and requested date | Prevents vague approval of an unknown modification |
| Exposure statement | People, tasks, zones, operating modes and abnormal conditions potentially affected | Connects technical change to real risk |
| Claim impact | Requirements, hazards, safety functions, interfaces and assumptions that may change | Defines the review boundary |
| Evidence delta | Analysis, inspections, simulations and tests required to restore confidence | Creates the revalidation plan |
| Deployment control | Backup, canary scope, schedule, hold points and rollback method | Limits exposure during implementation |
| Authorization | Named reviewers, residual restrictions, release decision and effective baseline | Prevents informal return to service |
| Observation window | Metrics, alarm thresholds, owner and closure criteria | Detects effects not visible in pre-release tests |
Describe the change as a difference between two controlled states
“Update navigation” is not sufficient. A reviewable description identifies the old and new versions, changed functions, default-value changes, dependencies, database or map migration, required restarts and compatibility limits. For a physical modification, record part identity, geometry, material, mounting, tolerances and any changed maintenance instruction.
Give the passport one accountable owner
Multiple specialists may contribute, but one person must ensure that the change does not move into production with missing analysis or open approvals. Ownership is not the same as technical competence: the owner coordinates the decision, while qualified reviewers approve the parts within their authority.
Draw the Impact Cone Before Selecting Tests
AMR change impact analysis should trace consequences outward from the modified item. The Impact Cone prevents teams from stopping at the first obvious effect. It has five layers, each broader than the last.
Layer 1: the changed item
Identify the exact parameter, executable, sensor, wheel, brake, route segment, access point, load fixture, workstation or procedure. Verify that the team understands what will physically or logically differ after implementation.
Layer 2: local behavior
Ask which direct behavior may change: detection, localization, acceleration, braking, path selection, docking, message timing, field switching, user authorization or fault response. Supplier release notes can inform this layer but cannot define it completely because the local configuration and use case matter.
Layer 3: composed system behavior
Trace the effect through fleet control, doors, elevators, conveyors, chargers, safety controllers, manufacturing execution systems and operator interfaces. A locally correct change may create an incompatible timeout, stale state or unexpected recovery path when combined with another subsystem.
Layer 4: operating exposure
Identify which people, traffic participants, loads, shifts, zones and foreseeable misuse scenarios encounter the changed behavior. This layer converts a technical difference into a risk question.
Layer 5: lifecycle controls
Determine whether training, inspection, spare parts, cybersecurity monitoring, incident response, drawings, operating instructions and future maintenance assumptions must change. A modification is not complete if the machine works but the organization continues using obsolete instructions.
The cone should be documented even when the final test scope is small. Its value is the reasoning that shows why the scope is small.
Classify Changes by What They Can Invalidate
Priority should not be determined by whether a change is labeled software, mechanical or operational. It should be determined by the claims it can invalidate. The following taxonomy helps teams look beyond departmental ownership.
| Change family | Typical examples | Hidden propagation |
|---|---|---|
| Safety configuration | Protective fields, speed limits, stop categories, muting or mode permissions | Stopping margin, coverage gaps, restart behavior |
| Autonomy software | Planner, localization, perception, costmap or obstacle-classification update | Route selection, confidence behavior, CPU load and timing |
| Fleet software | Mission engine, traffic rules, priority logic or database migration | Deadlock, queue spillback, stale authority and interface timing |
| Map and route | Lane, node, speed zone, one-way rule, no-go area or dock pose | Human exposure, sightlines, field switching and egress |
| Vehicle hardware | Scanner, encoder, tire, brake, drive, battery or controller replacement | Equivalence, response time, stopping performance and diagnostics |
| Payload and top module | New rack, pallet, conveyor, lift, manipulator or load range | Center of gravity, contour, stability, swept volume and braking |
| Site environment | Rack movement, floor repair, new doorway, lighting, reflectors or staging area | Localization, clearance, pedestrian behavior and emergency access |
| Network and infrastructure | Access point, VLAN, firewall, certificate, broker, lift or door controller | Latency, roaming, authentication, timeouts and loss response |
| Operating process | New shift, crossing rule, manual task, maintenance method or recovery role | Foreseeable misuse, authorization and human response |
High-frequency changes deserve stronger controls, not weaker ones
Teams often normalize routine map edits, payload additions or patches because they happen often. Frequency increases cumulative exposure and makes drift more likely. Repeated changes should have preapproved decision criteria, automated baseline capture and a defined regression portfolio, not an exemption from review.
Select Revalidation Depth Instead of Choosing “Test” or “No Test”
The Change Passport and Impact Cone support a graduated decision. A six-level Revalidation Depth model avoids two extremes: unnecessary full recommissioning and unsupported production deployment.
| Depth | Use when | Minimum evidence |
|---|---|---|
| D0 — Record only | No functional, environmental or exposure effect is credible | Documented rationale and baseline update |
| D1 — Equivalence verification | A replacement is demonstrably identical within controlled specifications | Identity, compatibility and configuration checks |
| D2 — Focused function check | One bounded behavior can change without meaningful system propagation | Targeted test plus adjacent negative case |
| D3 — Regression portfolio | Several connected behaviors or interfaces may change | Risk-selected nominal, boundary, failure and recovery tests |
| D4 — Partial application revalidation | Operating exposure, safety assumptions or multiple subsystems change | Updated risk assessment and affected SAT families |
| D5 — New release basis | The intended use, application boundary or architecture changes materially | Reassessment, redesigned controls and broad acceptance campaign |
Depth is determined by consequence and uncertainty
A small source-code patch may require D4 if its effect on safety-related timing is uncertain. A large visual-interface redesign may require D2 if it cannot influence motion authority and users are retrained. Line count, cost and installation time are poor substitutes for technical impact.
Uncertainty raises depth
If the supplier cannot explain changed dependencies, if the baseline is incomplete or if logs cannot demonstrate timing, choose a more conservative scope. Lack of evidence is not evidence of no impact.
Software and Firmware Updates: Treat Release Notes as Claims
AMR software update validation should begin before the package reaches a production vehicle. Obtain the release notes, known issues, compatibility matrix, migration instructions, security information, rollback constraints and hashes. Compare them with the local architecture and configuration rather than assuming that a vendor-tested release is automatically application-tested.
Look for indirect timing changes
A navigation update can alter processor load, message frequency, logging volume, boot time or watchdog behavior. These changes may affect safety-related communication, field selection or recovery even when no safety function is intentionally modified. Capture CPU, memory, latency and event timing where they participate in the application argument.
Test migration and rollback, not only forward operation
Database, map and parameter conversion should be verified on a representative copy. Confirm that backups are complete and restorable. Define whether rollback also requires downgrading maps, fleet databases, certificates or vehicle firmware. An emergency rollback plan that restores only one component may create an incompatible mixed version.
Separate security urgency from uncontrolled deployment
A critical vulnerability may shorten the review window, but it does not remove the need to evaluate operational and safety effects. Use an emergency path with defined authority, focused predeployment tests, restricted rollout and intensified monitoring. The site’s broader controls should align with the AMR and AGV cybersecurity guide.
Map and Route Changes Can Rewrite Human Exposure
An AMR map change risk assessment must consider more than whether the edited map loads successfully. A one-meter route shift can move the vehicle from a controlled lane into a forklift turning arc, reduce sight distance at a doorway, change approach direction at a person’s workstation or create a queue that blocks emergency access.
Trace every route-dependent control
Identify speed zones, protective-field selection, one-way rules, stopping points, traffic reservations, localization landmarks, docking poses, door triggers, elevator calls, pedestrian crossings and restricted areas tied to the changed geometry. Test both the intended path and credible replanning alternatives. Changes involving field coverage should also be checked against the principles in the safety laser scanner and protective-field guide.
Inspect the site, not only the map editor
Walk the route during representative operations. Verify rack positions, temporary staging, visibility, floor condition, lighting, signs, barriers and traffic behavior. A map can be internally consistent while no longer representing the facility.
Control publishing authority
Separate map drafting, review and production deployment. Record the map checksum and effective vehicles. Prevent a technician from experimenting directly in the live fleet. If an emergency edit is necessary, restrict the affected route until review and validation are complete.
Route changes should be reviewed with the principles in the AMR fleet traffic management and safety guide, especially where intersections, reservations and mixed traffic are affected.
Configuration Baselines Must Be Machine-Readable
AMR configuration management should make it possible to reconstruct what was running on each vehicle at a specific time. A spreadsheet of intended versions is not enough if deployed parameters can drift independently.
Capture the complete configuration graph
Record vehicle firmware, safety-controller logic, scanner configuration, autonomy software, fleet services, maps, route packages, certificates, interface schemas, payload profiles and relevant infrastructure versions. Store checksums or signed manifests where supported. Include vehicle-specific exceptions instead of assuming fleet uniformity.
Classify parameters by consequence
Mark settings that can influence speed, acceleration, braking, vehicle contour, field switching, localization response, motion authority, recovery or interface timeouts. Apply stronger authorization and automatic comparison to those settings. A parameter does not become non-safety-relevant simply because it resides in a standard database.
Detect configuration drift continuously
Compare running states with the released manifest and alert on unauthorized differences. Drift detection should include maps and infrastructure where possible. The goal is to find unreviewed changes before an incident investigation discovers them.
Build a Regression Portfolio That Mirrors the Safety Argument
AMR regression testing should not be a fixed collection of convenient demonstrations. It should be a modular portfolio linked to hazards, requirements and dependencies so the change review can select the right modules.
Maintain four test families
Anchor tests
These stable tests detect unexpected broad regression: representative mission completion, protective stop, emergency stop, localization loss, communication loss and controlled restart. They run after most meaningful releases.
Change-specific tests
These target the behavior intentionally modified, including its new boundaries and expected benefit. A new planner should be tested on route selection; a brake controller update should be tested on stopping performance.
Dependency tests
These challenge functions that consume or share the changed data, timing or resources. A map update may require field-switching, traffic and docking tests even when those modules were not edited.
Negative and recovery tests
These prove that invalid input, interrupted deployment, mixed versions, lost communication and failed initialization produce controlled outcomes. A release that works only after a perfect update sequence is not operationally robust.
Preserve comparable measurements
Use consistent test conditions, calibrated instruments, synchronized time and retained raw data. Compare distributions rather than only pass/fail labels where stopping, localization, latency or docking performance can drift gradually. Define acceptable change from the previous baseline before reviewing results.
Payload and Top-Module Changes Alter More Than Capacity
A new load, rack, conveyor, lift or mobile manipulator can change mass, center of gravity, braking, stability, scanner occlusion, vehicle contour, turning sweep, docking force and emergency recovery. Even when the new payload remains below the rated capacity, the earlier evidence may not cover its geometry or dynamic behavior.
Recalculate the moving envelope
Measure overhang in all directions and the swept contour during turns. Check whether the load blocks sensors, lights, emergency stops or manual controls. Verify protective coverage for every permitted travel direction and top-module state.
Repeat dynamic tests at meaningful boundaries
Test acceleration, braking, turning, slopes, floor transitions and emergency response at the new worst credible mass and center of gravity. Inspect load retention and settling after stops. Do not use a static load-placement check as evidence of dynamic stability.
Update recovery instructions
Operators may need different lifting points, towing methods, exclusion zones or equipment when a vehicle is stranded with the new load. Include these procedures in the change release rather than discovering them during a fault.
Site and Infrastructure Changes Are Part of the Robot Application
Facilities evolve continuously. Rack layouts, doors, lifts, conveyors, chargers, floor coatings, lighting, reflective surfaces and temporary barriers can all affect AMR behavior. The change process must therefore capture work orders outside the robotics team.
Create spatial change notifications
Define robot operating zones in the facility change-management system. Construction, layout, fire-route, staging and utility changes inside or near those zones should notify the AMR owner before work begins. This is more reliable than expecting robotics personnel to notice completed modifications.
Reinspect localization and clearance
New repetitive racks, glass, wraps, reflectors or lighting can alter perception and localization. Floor repair can change traction or introduce edges. Reconfirm minimum clearance and localization reserve where geometry becomes tighter.
Retest infrastructure handshakes
A replaced door, elevator, conveyor or charger controller may preserve electrical connections while changing state semantics or timing. Test request, acknowledgement, permission, completion, timeout, cancellation and recovery. For charging and positioning changes, the precision docking and autonomous charging guide provides additional context.
Network and Fleet Changes Can Expand the Blast Radius
Adding vehicles, access points, message brokers, firewall rules, certificates or fleet services can alter latency, congestion, routing authority and failure behavior. A change that appears to improve availability may also extend the time during which stale authority remains accepted.
Test loaded conditions
Measure roaming, message delay, order throughput and recovery while the fleet and network are representative of production load. A successful single-robot test on an empty wireless channel does not validate peak-shift behavior.
Challenge partial and asymmetric failures
Disconnect one vehicle, one access point, one fleet service or one interface path. Test delayed, duplicated and reordered messages. Verify lease expiry, reservation release, local safe behavior and operator visibility. Recovery should not replay obsolete commands.
Control mixed-version fleets
Define whether old and new robot or fleet software versions may operate together. Test the supported transition window and block unsupported combinations. Multi-vendor environments should also verify semantics, optional features and error handling described in the AMR fleet interoperability guide.
Wireless modifications should follow a controlled survey and failure-response review. See the AMR industrial wireless and Wi-Fi roaming guide for the underlying architecture.
Maintenance Replacement Is Still a Change
Replacing a scanner, wheel, tire, brake, encoder, motor, battery or controller can restore function while changing performance. “Like for like” must be demonstrated, not assumed from appearance or a supplier’s general compatibility statement.
Define equivalence criteria before failure occurs
Approved spare parts should include exact identity, revision limits, firmware, calibration, mounting, tolerance and configuration requirements. If alternatives are permitted, document the engineering basis and required post-replacement tests.
Verify the installed state
Check alignment, torque, wiring, field configuration, calibration, diagnostic coverage and configuration restoration. A correctly specified part can be installed incorrectly or inherit a default configuration.
Use maintenance data as a change trigger
Repeated replacement, uneven tire wear, increasing brake travel, scanner contamination or localization interventions may indicate a changing operating condition. Escalate patterns into impact review rather than closing each work order independently.
Deploy Through Rings, with Hold Points and Rollback
Testing proves selected conditions; controlled rollout limits consequences outside those conditions. Use deployment rings that expand only after predefined evidence is accepted.
Ring 0: offline evidence
Review files, hashes, compatibility, risk assumptions, simulations and test results without changing the live system.
Ring 1: representative test article
Apply the change to a controlled vehicle or environment that mirrors production configuration. Run the selected regression portfolio and verify rollback.
Ring 2: bounded production canary
Use one vehicle, one route, one shift or one operating window with explicit restrictions. Monitor the metrics most sensitive to the change and preserve comparable baseline data.
Ring 3: staged fleet release
Expand by controlled groups while checking configuration consistency, incident indicators, latency, stop behavior and manual interventions. Pause automatically if thresholds are exceeded.
Ring 4: normal operation with an observation window
Normal release does not immediately close the passport. Maintain heightened monitoring until the defined mission count, operating hours, payload variants and shifts have been observed.
Rollback must be a tested state transition
Define who can order rollback, what data must be preserved, how missions are stopped, which components revert together and how the restored baseline is verified. A rollback that depends on improvisation is not a control.
Give Each Discipline a Specific Decision
Lifecycle safety fails when a generic approval box hides distinct responsibilities. The change owner should collect explicit decisions from the functions affected.
| Role | Decision |
|---|---|
| Operations | Does the changed workflow remain usable, supervised and within released restrictions? |
| Safety or risk owner | Are hazards, assumptions, residual risk and revalidation depth acceptable? |
| Controls or robotics engineering | Are architecture, configuration, interfaces and test evidence technically adequate? |
| IT/OT cybersecurity | Are identities, access, patching, logging, backup and network effects controlled? |
| Maintenance | Are service procedures, spares, calibration and recovery updated? |
| Integrator or supplier | Are product limitations, dependencies and support obligations addressed? |
| Business release authority | May production resume under the documented conditions and residual risk? |
One person may fill several roles in a small facility, but the decisions should remain distinct. A production manager’s urgency cannot substitute for technical validation, and a supplier’s product approval cannot accept the user’s site-specific risk.
Turn Operational Signals into Revalidation Triggers
industrial mobile robot lifecycle safety depends on detecting when the application has moved outside the evidence boundary even if nobody submitted a formal change request. Operational data should therefore trigger review.
Watch leading indicators
Useful signals include increasing protective stops, emergency stops, localization resets, manual interventions, route replans, docking retries, field warnings, blocked-route time, network reconnections, message latency, wheel slip and recovery duration. Segment them by vehicle, route, payload, shift and software baseline.
Define threshold logic before the trend appears
A single event may require immediate hold, while gradual deterioration may require investigation after a statistical or operational threshold. Define owners, response time and escalation. Dashboards without response rules create awareness, not control.
Treat near misses and workarounds as evidence
Operators walking around a recurring robot blockage, resetting faults repeatedly or moving pallets by hand may indicate that the released workflow no longer matches reality. Encourage reporting and analyze the system rather than blaming the person who exposed the drift.
Changes to restart or fault-handling logic should preserve controlled recovery principles. The AMR failure recovery and resilience guide covers this operational layer in more detail.
A Worked Example: Moving a Pick Station by Four Meters
Consider a production team that moves a pick station four meters to create space for a new process. The map editor changes one destination pose and the vehicle still completes the mission. A task-based review might approve the edit immediately. The Change Passport reveals a wider impact.
Baseline anchor
The original station sat inside a low-speed zone with a frontal approach, clear scanner view, dedicated waiting node and operator position outside the vehicle’s turn. The acceptance evidence covered this geometry.
Impact Cone
The new position changes the approach to an oblique turn near a doorway. A rack partially blocks sightlines. The waiting vehicle can now extend into a cross aisle. The route crosses a different wireless roaming boundary, and the operator stands closer to the load sweep.
Evidence delta
The team updates the risk assessment, measures clearance, verifies the protective field during the turn, tests loaded stopping, observes pedestrian approaches, checks localization and roaming, challenges queue spillback and confirms the workstation handshake. Training and floor markings are updated.
Release
The change receives a bounded canary release for one shift with reduced approach speed. After the defined missions show stable stopping, localization and queue behavior, the passport closes and the new map checksum becomes the production baseline.
The example shows why test selection follows impact reasoning. The route edit did not require repeating battery endurance or unrelated charger tests, but it required more than checking that the destination could be reached.
Write Lifecycle Obligations into Supplier and Service Contracts
Change governance becomes expensive when the buyer discovers after handover that configuration exports, release notes, rollback packages, logs or old software versions are unavailable. Procurement should define the evidence needed throughout the support period.
Require structured release information
Suppliers should identify changed functions, safety relevance, dependencies, compatibility, known issues, migration, cybersecurity content, rollback limits and recommended regression tests. Marketing release notes are not sufficient for an industrial change decision.
Protect access to evidence
Contracts should address configuration export, log ownership, retention, diagnostic access, map and parameter backups, software hashes, license continuity and support after product end-of-life. The user must be able to reconstruct its released baseline without depending on one departing technician.
Define emergency support and responsibility
Set response times for critical vulnerabilities, unsafe anomalies and failed rollbacks. Clarify who performs impact analysis, who supplies test tools and who approves application release. Product support does not transfer the site owner’s responsibility, but it should provide the technical information needed to discharge it.
Standards Establish Lifecycle Duties, Not a Universal Retest List
As of August 2026, the ANSI/A3 R15.08 series states requirements across the design, integration and use of industrial mobile robot applications and explicitly emphasizes risk assessment and management of change in both the application and its operating environment. ANSI/A3 R15.08-3-2026 addresses user responsibilities for maintaining acceptable risk during day-to-day use.
ISO 3691-4:2023 remains the published international standard for driverless industrial trucks and their systems, including AGVs and AMRs, although ISO lists a draft replacement under development. Its scope and operating-zone emphasis reinforce the need to review site changes rather than treating the vehicle as an isolated product.
ISO 12100:2010 describes hazard identification and risk estimation and evaluation across relevant machine lifecycle phases. ISO 13849-2:2012 specifies validation by analysis and testing for defined safety functions and safety-related control-system performance; a replacement is under development.
Software and network changes may also intersect with industrial cybersecurity practices. IEC TR 62443-2-3:2015 addresses patch management in industrial automation and control system environments, while NIST SP 800-82 Revision 3 provides OT security guidance that accounts for performance, reliability and safety requirements.
These references do not prescribe one universal revalidation depth for every modification. The organization must apply the standards relevant to its jurisdiction, machine boundary and application, document its interpretation and select evidence based on the actual change and risk.
A Twelve-Question Release Review
The following AMR revalidation checklist is a decision summary, not a substitute for the Change Passport or risk assessment. A “no” or “unknown” answer should block release or create an explicit restriction and action.
- Is the previous released baseline uniquely identified?
- Is the proposed difference exact, complete and reproducible?
- Have direct, system, environmental and operational impacts been traced?
- Are affected hazards, requirements, safety functions and assumptions identified?
- Is the selected Revalidation Depth justified, including excluded tests?
- Are test conditions representative of the changed operating envelope?
- Have negative, failure and recovery behavior been considered?
- Are backups, compatibility limits and rollback steps verified?
- Are maps, parameters, procedures, drawings and training synchronized?
- Are responsible technical and business authorities named?
- Are deployment rings, hold points and observation metrics defined?
- Will the new production baseline and evidence remain reconstructable?
Focused FAQ
Does every AMR software update require a complete site acceptance test?
No. The required scope depends on the changed functions, uncertainty, dependencies and operating exposure. A documented impact analysis may justify a focused regression set, while a change affecting motion authority, safety timing or application boundaries may require partial or broad revalidation.
Can a vendor declaration replace site revalidation?
A vendor declaration can support product-level compatibility and known-impact analysis within its stated boundaries. It normally cannot establish the consequences of the site’s map, payload, traffic, infrastructure, interfaces or operating procedures. The user and integrator still need application-specific evidence.
Is moving a rack or workstation really a robot-system change?
It can be. The movement may alter clearance, sightlines, localization features, pedestrian behavior, route options, protective-field transitions or emergency access. Facility modifications inside the operating zone should enter the change process.
When is a replacement part truly like for like?
When identity, revision, performance, tolerances, firmware, configuration, mounting and diagnostics remain within an approved equivalence definition. The installed state must still be verified. Similar appearance or connector compatibility is not sufficient.
How should an urgent cybersecurity patch be handled?
Use an expedited but controlled path: assess safety and availability effects, verify package identity and compatibility, test in a representative environment, confirm backup and rollback, deploy to a restricted canary and monitor defined indicators. Urgency changes timing, not the need for evidence.
What operational events should trigger renewed review?
Examples include increased protective stops, repeated localization loss, manual interventions, near misses, new workarounds, docking retries, braking drift, network reconnections, unauthorized configuration differences and recurring maintenance. Trigger thresholds and owners should be defined before trends appear.
Who owns the final release decision after a change?
The organization should name a business release authority supported by qualified decisions from safety, robotics or controls engineering, operations, maintenance and IT/OT cybersecurity as applicable. A supplier may provide evidence but cannot accept all site-specific residual risk for the user.
How long should change evidence be retained?
Retention should support the machine lifecycle, regulatory and contractual obligations, incident investigation and reconstruction of every effective baseline. Keep superseded configurations, test results, approvals and rollback records rather than retaining only the latest state.
The Objective Is Controlled Evolution, Not a Frozen Factory
Mobile robot applications must change. Software needs patches, processes need improvement, layouts evolve and fleets expand. The engineering goal is not to prevent change but to stop change from silently outrunning its evidence.
The Change Passport establishes what is changing. The Impact Cone reveals where consequences can propagate. Revalidation Depth converts consequence and uncertainty into a proportionate evidence plan. Deployment rings, rollback and operational monitoring then control the transition into production.
A mature organization can answer four questions for every released modification: what changed, which safety and performance claims could move, what evidence restored confidence, and who authorized the new baseline. When those answers are traceable, the AMR application can evolve without treating yesterday’s acceptance certificate as permanent proof for tomorrow’s system.
