How do you turn AMR duty cycle into annual battery cycle counts?

Annual equivalent full cycles equals total annual amp-hour throughput divided by pack usable capacity. The raw quotient is only the starting point. What belongs in a replacement forecast is that number adjusted for depth of discharge, ambient temperature at the robot's station, and the end-of-life threshold you actually intend to run to. Adjusted annual equivalent full cycles, divided into a delivered-cycle life you can defend with the supplier, gives you pack-years per robot. That is the unit a finance team can budget against, and it is the only version of this calculation I am willing to put in front of a plant controller.

I do this arithmetic on a whiteboard more often than in a spreadsheet, because the argument is never about the division. It is about which inputs survive contact with the fleet. Here is the order I check them in, and the places where the number most often goes wrong.

The denominator is wrong more often than the numerator

Almost every bad forecast I have reviewed divided throughput by nameplate capacity. A 48 V, 100 Ah pack is not 4.8 kWh of usable energy. The BMS holds a floor, often somewhere around 10 to 15 percent state of charge, and a ceiling short of 100 percent, so the window you can actually cycle might be 80 to 85 percent of nameplate. Then the pack reaches end of life at some fraction of that original window, commonly 80 percent, sometimes 70 if the duty profile is forgiving.

Pick one convention and stay with it. I use beginning-of-life usable capacity as the denominator and let the delivered-cycle figure absorb the fade. Mixing them double-counts aging and makes the forecast look alarmist, which is a fast way to lose the room.

Amp-hours or watt-hours, also pick one. Amp-hour throughput is fine when the whole fleet runs the same nominal voltage. If you are comparing a 24 V tug fleet against a 48 V AMR fleet, convert to watt-hours, because Ah across different voltages is not a comparable unit. One caveat on watt-hours: late in life the pack sags under load, so each amp-hour delivers fewer watt-hours. A watt-hour count understates the cycling damage in the last year. I usually keep the count in amp-hours and treat voltage sag as a separate derate.

Docking events are not cycles, and this is where the big errors live

I have watched a very capable maintenance planner divide docking events per day into a cycle-life spec and conclude the fleet needed new packs in fourteen months. The actual answer was over five years.

A robot that docks eight times a day for a twelve-minute top-up is not running eight cycles. If each event returns roughly 5 Ah into a 40 Ah usable window, that is 40 Ah of throughput across eight events, which is one equivalent full cycle per day, not eight. The number of charge events barely matters to the count. The amp-hours do.

This is the part that separates opportunity charging from conventional charging in the model. Opportunity charging changes the depth of each cycle and the count of events, but it does not change the throughput. Two fleets doing identical work, one cycling 80 percent once a shift and one sipping 12 percent ten times a shift, land on nearly the same annual equivalent full cycles. What differs is the second-order effect: shallow cycling is generally kinder to total lifetime throughput than deep cycling, so the opportunity-charged fleet will usually get more delivered cycles out of the same cells even at the same annual count.

Which means the depth-of-discharge mix is not decoration. It is the input that sets the delivered-cycle figure you divide into. Get a week of BMS logs per robot archetype and read the actual start and end state of charge per event. Assume nothing from the shift schedule.

Build the day, then the year

The formula wants annual throughput, so build it in three steps rather than one.

Step one, throughput per operating day, from the logs. Say a mid-size AMR consumes about 32 Ah at 48 V over an eight-hour operational period. With a 40 Ah usable window, that is 0.8 equivalent full cycles per day.

Step two, operating days. This is where shift patterns and the calendar matter. Three shifts, six days, minus holiday shutdowns, might land near 300 days. A two-shift operation running five days lands closer to 250. That difference alone is a seventeen percent swing in the forecast, and it is the input ops managers are most willing to argue about, so get it in writing.

Step three, multiply. 0.8 cycles a day across 300 days is 240 equivalent full cycles per year.

Now pair that with hours, because cycle count is not the only life limit. Some packs are limited by operating hours or by calendar aging before they hit their cycle ceiling. A robot that runs 4,500 hours a year and a robot that runs 2,000 hours a year can post similar cycle counts if their duty depths differ. If you only carry the cycle number, you will miss the unit that dies from time rather than from cycling.

Break patterns feed both numbers. A lunch stop that gives a full hour of charge is a different daily energy picture than a break schedule that gives four fifteen-minute windows. Neither changes the annual amp-hour total much. Both change what the robot can physically get through, which is how you end up discovering that your real end-of-life trigger was a missed mission, not a capacity threshold.

Temperature is a line item, not a footnote

Ambient at the robot's station goes into the conversion. The rule of thumb I have used for years, and which most cell vendors will acknowledge without putting in a datasheet, is that usable cycle life falls roughly by half for every ten degrees Celsius of sustained operating temperature above the mid-twenties. That is a rule of thumb, not a laboratory result, and it is conservative in some chemistries and optimistic in others. Use it as a derate factor, not a precision instrument.

What matters for procurement is that the number is site specific. An AMR working near a dock door in a southern warehouse in July is not the same asset as one working in a conditioned cleanroom forty feet away, even with identical routes and identical packs. The charging room temperature matters too. Charging a warm pack is harder on it than discharging a warm pack. If your chargers sit against an exterior wall with no airflow, that is a derate you should write down and defend.

Cell cycle life and pack delivered cycles are two different numbers

When a vendor quotes 4,000 cycles, read the conditions. Depth of discharge, ambient temperature, charge and discharge C-rate, and the end-of-life threshold. A figure quoted at 80 percent depth of discharge, 25 degrees Celsius, 0.5 C, to 80 percent capacity retention tells you something, but it does not tell you what your fleet will get.

Then discount again, because that number is a cell number. A pack has one BMS, one contactor, one weakest cell, and a set of interconnects. The pack is done when the first cell trips your threshold, not when the average cell does. Series imbalance and thermal gradients inside the enclosure guarantee that pack-level delivered cycles land below the cell-level spec. In my experience the gap is real and worth taking seriously, though how big it is depends on how well the pack was built and how evenly it was cooled. This is exactly the kind of thing an audit of the supplier's cell matching and thermal design tells you, and it is why two vendors quoting the same cells can deliver very different pack lives.

So the calculation has three columns, and I keep all three visible. What the spec sheet says. What your duty cycle implies. What your site actually delivers. The forecast uses the third column, and the reconciliation between them is what you show the supplier when the first packs come back early.

What the number is actually for

Most people treat the annual cycle count as an answer. It is a scheduling tool.

Run it per robot archetype, not per fleet. Three archetypes cover most AMR fleets: short high-frequency tote moves, long-haul transport between zones, and low-utilization specialty units. They will land on wildly different annual counts, and averaging them hides the one that matters.

Then look at commissioning dates. A fleet stood up over a single quarter will hit its cycle-life wall within a few quarters of itself. That is not a consumable line item drifting upward over a decade. That is a cash event with a date on it, and the date is roughly four to six years after go-live depending on your adjusted count and your derates. If you can buy the replacement packs on the original purchase order, at original pricing, with original lead times, you should at least price the option. Custom industrial packs are not catalog items, and a twelve-week lead time turns a planned replacement into a stalled fleet.

Finally, reconcile. Most credible BMS platforms report cumulative amp-hours charged. Pull that number quarterly and divide by usable capacity. It will not match your model, and the delta is the most valuable thing you will learn all year. When the field number runs hot, you either have a temperature problem, a charger problem, or a duty profile that drifted from what ops told you at specification time. All three are cheaper to find in year two than in year five.

Where this model breaks

Equivalent full cycles is a throughput proxy, and throughput is not the only aging mechanism. Calendar aging keeps working on a pack that sits idle over a long weekend, and it accelerates at high state of charge and high temperature. A low-utilization specialty AMR that runs 600 hours a year may still lose meaningful capacity over five years while posting a cycle count that suggests it should last a decade. If more than a third of your fleet is low-utilization, the cycle model will overshoot and you should carry calendar fade as a separate line.

The model also assumes the pack ages as a unit. It does not. In practice you will face the question of whether to replace the whole pack or rebalance or re-cell it, and the answer depends on whether the failure is a weak module or uniform fade. That decision is its own analysis, but the annual cycle count is the input that tells you when to start having it. And it assumes a linear relationship between throughput and fade, which is a decent approximation in the middle of life and a poor one at the very beginning, when formation-related fade runs faster than throughput would predict.

None of that makes the conversion less useful. It makes it a forecast rather than a promise. I have yet to see a fleet where the first version of this number was right. I have seen plenty where the third version, reconciled against BMS throughput and against the first packs that came back, was good enough to build a five-year capital plan on.