Year three: what happens to a robot fleet at end of life

The planned end of an autonomous robot fleet's service life rarely announces itself as a sudden mechanical failure. In operational practice it is almost always the electrochemical ageing of the traction batteries that quietly undermines the original operating plan. Where the vehicles covered a shift without an intervening charge in the first year, the usable window shortens continuously as operating hours accumulate. For the operator that means the same number of units no longer does the same amount of work it did at rollout.

This loss is not linear; it accelerates towards the end of the chemical service life. Operators can see the turning point directly in telemetry that already accrues day to day. A rise in daily charging cycles alongside a falling run time per charge is the first clear signal. In parallel, relative dwell time at the chargers increases, so availability on the floor falls.

• Shorter run times per charge on an identical route and task profile
• More unplanned opportunity charging during core operating hours
• Longer dwell at docking stations to restore minimum voltage
• Clustering of aborted or slowed runs immediately before end of shift

Once battery degradation means runs can no longer be completed at the end of a window, the wider operation starts running late. At that point management has to decide whether a cell replacement makes economic and technical sense, or whether the fleet has reached its planned life. How charging and dwell can be planned in the first place is covered in our article on charging infrastructure for robot fleets. A vendor-independent integrator reads this wear curve as the signal to begin the transition to the next life-cycle phase in good time.

When a manufacturer formally withdraws a robot model from sale, that is not the end of its working life on the floor. But a structured end of life does require the remaining pillars of manufacturer support to be looked at separately. In practice, firmware maintenance, mechanical spares supply and back-end software services expire at entirely different times.

To be clear about scope: this is about the planned end of life, not the unplanned disappearance of a supplier. What happens when a manufacturer fails unexpectedly is treated separately in what an operator loses when a robot supplier goes under; how to test for that risk beforehand is in the robotics supplier due diligence checklist. Operators frequently run into difficulty because they misread end of life as a single date.

The physical mechanics of a mobile robot, properly maintained, often outlast the manufacturer's software support by a wide margin. But once security and firmware updates stop, failure and security risk on the local network rise, even when the drivetrain is faultless.

Maintenance planning has to track these three phases separately. A shortage of spares can be cushioned by stocking critical components in advance; the expiry of software and cloud services cannot be compensated by holding hardware.

Of all the phases of end-of-support, shutdown of manufacturer-side cloud services is the largest operational risk. Many current robot systems are architected so that essential control, fleet management and compute functions do not run locally on the vehicle but sit in the manufacturer's server estate. When that service is discontinued, the operator loses access to the system as a whole.

In such architectures the end of cloud connectivity produces an abrupt stop. Even with drivetrain, sensors and batteries in perfect condition, a vehicle without its back-end connection can accept no orders, reconcile no dynamic exclusion zones and perform no multi-robot coordination. The physical asset becomes unusable more or less overnight.

• Loss of central order dispatch and of interfaces to third-party systems
• Loss of the ability to synchronise map data and route changes fleet-wide
• No telemetry for predictive maintenance and condition monitoring
• Loss of fault diagnosis and remote access for maintenance teams

It is therefore essential to establish at selection time how far the vehicles' basic functions depend on external cloud infrastructure. A robot that can execute navigation decisions and hold its maps locally, and that exposes open interfaces, stays operable even when the manufacturer's management portal is switched off.

In conventional plant engineering, the residual value of a machine follows from its physical condition and its operating hours. For autonomous mobile robots that logic only partly holds. A robot deeply integrated into a specific building — lift controls, fire doors, operational software — typically fetches a lower resale price than a standard, unintegrated unit.

The reason for that apparent loss lies in the nature of integration itself. Most of the investment made sits not in the bare chassis but in the site-specific configuration, interface adaptation and safety design of the operating environment. None of that transfers to another operator or another site.

The difference runs along three factors. On resale, an integrated fleet is constrained, because reconfiguration and decoupling from the site's software cost effort, whereas standard hardware with no special configuration can be taught into a new environment with no preparatory work. On site-specific value the relationship inverts: the integrated fleet carries full process value for its current operator right up to its last working day, while an unintegrated unit, with no process to attach to, initially does nothing at all. And on decommissioning, the integrated fleet requires safety zones, interfaces and building connections to be unwound, whereas standard hardware can simply be taken out of service.

Asset managers have to reflect this in depreciation. At the end of its service life an integrated fleet can rarely be sold at a profit. Its economic value has to be recovered in full over the real operating period through process stability; the vehicle itself, at end of life, is primarily an electronics and materials value on the balance sheet.

The contractual end of a fleet term carries substantial operational risk if the handover of operating data was not settled from the outset. Over several years of operation a fleet accumulates a great deal of process value: high-precision environment maps, travel lanes, stopping points, time-based exclusion zones and historical audit logs. That data represents the operator's own procedural knowledge about its own site.

When an operating contract expires or a service provider is changed, that knowledge must not be lost. If map formats are proprietary and encrypted, or export functions for waypoints are missing, the whole teach-in and survey process has to be run again from scratch for a successor fleet. That means avoidable downtime and avoidable reinvestment.

• Retention of all generated 2D and 3D maps in open, standardised file formats
• Complete export of all defined routes, driving rules, virtual walls and transfer points
• Release of the full audit logs and event records, so the evidence obligation can still be met
• Deletion of all site-related operating and infrastructure data on the outgoing provider's servers

Negotiating data export at the point of termination is essentially hopeless, because the outgoing provider has no commercial incentive left to prepare proprietary data structures. The obligation to hand over all configuration and operating data in machine-readable standard formats therefore has to be anchored in the original procurement and integration contract. At termination there is no negotiating position left to use.

When a robot fleet reaches the end of its economic life, that does not necessarily mean the whole automation project has to be set up again. Operators face a choice between complete hardware replacement and a modular fleet refresh. Replacing individual units step by step is in most cases the more economic and the operationally more stable strategy.

The precondition for a successful refresh is a strict separation of physical hardware from higher-level process logic. Where the connection to lifts, automatic doors, warehouse management or facility management systems is decoupled from the robot mechanics themselves, worn chassis can be exchanged for current successor models without having to adapt the building infrastructure again.

• Retention of existing interfaces to building management technology and IT infrastructure
• Avoidance of lengthy interface re-validation when integrating new units
• Step-by-step transition without interrupting shift operation on the floor
• Targeted modernisation of individual units according to actual mechanical wear

A modular approach of this kind protects the investment budget and reduces operational risk sharply. An experienced integrator designs the integration architecture from the outset so that individual hardware components stay exchangeable while the site's operating system carries on unchanged.

The planned end of a hardware generation loses its edge where operators have built on a vendor-independent integration architecture. Where control commands, fleet rules and data flows are not coupled directly to one robot builder's own software, the integration layer acts as a buffer between the physical machine and the site's processes.

This is what the werob platform is for: it decouples operational logic entirely from the particularities of individual hardware manufacturers. Standardised connectors attach robot fleets to higher-level systems such as ERP, WMS or facility management software. When a robot generation has to be replaced after several years of service, the entire interface landscape stays as it is. The connector for the successor model is activated, and the processes carry on.

• Standardised connectors decoupling hardware drivers from operational software systems
• A central cockpit for cross-vendor monitoring of fleet condition, telemetry and audit logs
• Retention of hard-won process logic and interfaces across hardware generations
• Avoidance of vendor lock-in and full freedom in choosing successor hardware

Through the central cockpit, operators keep sight of fleet condition across the whole life cycle. When the first signs of battery wear appear, or a manufacturer announces end-of-support for a model, a vendor-independent integration platform makes the move to current hardware possible without having to reinvent the operation.