The BMS Records That Decide Your Robot Battery Warranty Claim

A robot battery warranty claim is decided by records that had to be specified before the purchase order was signed, not by what anyone remembers at the moment of failure. Four record classes need to be named in the procurement documents and proven exportable during the pilot: the BMS event and fault log, held on a retention window longer than the warranty term; cumulative cycle and throughput counters bound to the pack serial number rather than the board; a version record for every firmware build loaded on every pack; and the supplier's native diagnostic export, in the exact format their service desk accepts. Those four sit on top of two contractual rights — data ownership with a defined export path, and a documented time base shared between the BMS and the robot controller.

Put yourself at the bench where this actually goes wrong, because the wrongness is quiet. The pack is out of the robot, sitting in its cradle, connector bay open, and the service ticket beside it says overtemperature cutoff at the end of a shift. You open the supplier's log viewer and it looks great. Charge events, discharge events, temperature traces, a fault code list. Then you scroll to the bottom and the oldest entry is six weeks old. The event you're claiming on happened four months ago. The log buffer wrapped and took the evidence with it on its way around, and nothing on the screen tells you that happened, because a rolled-over log looks exactly like a complete one until you check the date range.

What killed that claim wasn't the failure. It was absence. And absence is cheap to prevent at the specification stage and almost impossible to fix afterward, which is why I read a battery spec backwards now — starting from the claim I might have to file in year three and working back to what the pack has to be recording today.

Retention is a number you negotiate, not a default you inherit

The first question I ask about any BMS platform is not how many parameters it logs. It's how deep the log goes before it overwrites itself, and what the default is set to out of the box. Most embedded logging is a circular buffer sized for troubleshooting a recent event, not for supporting a claim eighteen months later. The default might hold a few thousand entries or a few weeks, whichever comes first, and nobody thinks about it until the day it matters.

So retention goes into the spec as a number, and the number comes from your warranty term plus the lag between a failure and someone actually investigating it. If the warranty runs thirty-six months and the failure typically surfaces at month thirty, you need the log to reach back well past that, because the pack may have been degrading for months before anyone pulled it. I write it as a floor — a minimum continuous retention period in months, with the fault and event history preserved at full fidelity even if high-frequency telemetry is sampled down.

That last distinction matters more than it sounds. Vendors will often trade depth against sample rate, and that's a reasonable trade. Thinned-out voltage traces over a long window still support a story about a pack that was being pushed. A fault code list that only covers the last ninety days supports nothing.

Cycle counters break the day someone swaps a board

Cumulative cycle count and amp-hour throughput are the numbers a supplier's warranty desk uses to decide whether the pack lived inside its rated life. They're also the numbers most likely to vanish, because the counters live on the BMS board, and boards get replaced in the field when a pack misbehaves. New board, counters back to zero, and now your pack looks brand new at the exact moment you're claiming it's worn out.

I want the counter history bound to the pack serial number and to the asset record, not just to whatever board is currently installed. In practice that means asking, during the pilot, what happens to counter continuity when a BMS board is replaced under repair — whether the replacement is pre-loaded with the pack's history, whether the service record carries the prior values forward, and who is responsible for making that happen. If the answer is a shrug, that goes in the supply agreement as a defined process, because a claim with a gap in the counter history is a claim the supplier can argue about for months.

The firmware version record is where most claims actually turn

Before a supplier evaluates whether your pack failed legitimately, they check what software it was running. That check is fast and it is unforgiving. If the pack was on a build that wasn't approved for that hardware revision, or if the firmware was modified without authorization, the conversation stops being about the failure and starts being about whether coverage applies at all.

So the version record isn't an IT nicety. It's the hinge the whole claim swings on. I want a register that captures, for every pack in the fleet, the build identifier currently loaded, when it was loaded, and by whom — and I want that register treated as a controlled document rather than a spreadsheet living on someone's laptop. Every update goes in it, including the ones a field technician performs with the supplier's own tool.

Just as important, I want the supplier to state in writing which builds are warranty-qualified, and to notify us before a release changes the terms under which the warranty applies. That's the piece people miss. Firmware governance and warranty terms are usually managed by two different groups who never talk, and the gap between them is where coverage quietly disappears. A release that fixes a thermal issue but shifts the warranted operating envelope is not a neutral event, and you only catch it if the release notice has to cross a buyer's desk before it lands on a fleet.

The export has to be a file you can produce without the supplier standing next to you

Suppliers have a diagnostic file format, and their warranty desk wants that format and not a CSV you assembled yourself. I've watched a legitimate claim stall for weeks because the only person who could generate the required export was a field engineer who was booked out a month, and by the time he arrived the pack had been moved and the storage had been wiped for return shipping.

I ask, in the pilot, for the actual tool and the actual file. Who can run it, what it's called, what it contains, how it's named, and whether we can produce it ourselves or need the supplier to do it. If it's supplier-only, that becomes a contractual response time for diagnostic exports, not a favor. If we can run it, I want the tool licensed to us and versioned, because a diagnostic tool that stops working after a falling-out is not a data right.

Time sync is the detail that turns a log into evidence

A fault code with a timestamp is a fact. A fault code with a timestamp that can be matched to what the robot was doing is evidence. Those are different things, and the difference is whether the BMS clock and the robot controller clock agree.

BMS real-time clocks drift, and some of them reset on power loss or battery disconnect. If the BMS thinks the pack failed at 14:02 and the controller logged a heavy duty cycle and an ambient spike at 09:40, you don't have a contradiction — you have an unexplained offset, and an unexplained offset is enough for a supplier to set the claim aside while it asks you to prove the clocks. I specify a shared time base, a documented sync method at commissioning, and a periodic check that the offset stays inside a stated tolerance. Then I log the offset as part of the integration record so nobody has to reconstruct it later.

Run the claim before you need it

Here's the part that most procurement writeups skip, and it's the part I consider non-negotiable. During pilot validation, I induce a fault on purpose — a forced over-temperature cutoff or a deliberate undervoltage event, something benign and controlled — then I export the full record set and send it to the supplier's warranty desk with one question attached: would this support a claim for this pack?

Sometimes the answer is yes. Often it's a list of what's missing, and that list is worth more than any clause you could have written from imagination. You find out in week six of a pilot, when the supplier still wants your business, rather than in month twenty-two, when they don't. I keep the written answer in the contract file. It becomes the reference definition of a complete claim package for that program.

What actually goes in the agreement

Six things, and I'd rather lose a point on unit price than lose any of them. Ownership of pack data, in plain language, with a defined export path and format. A retention floor stated in months, tied to the warranty term, with notice required before it's reduced. Delivery of the firmware version register and the list of warranty-qualified builds, updated on each release. A change-notice obligation for any firmware release that affects warranted operating conditions. Continuity of cycle and counter records across BMS board replacement. And a diagnostic export commitment — either the tool licensed to us, or a defined turnaround when we request a file.

One more, easy to forget: what happens to data access at end of life or end of relationship. A supplier-hosted portal is fine by me as long as the export right survives the commercial relationship ending. If the historical records become unreachable the moment you move to a second source, you never really owned them.

Where I'll bend

Not everything here is free. Deeper retention costs memory and sometimes a larger BMS board, and on a small AMR pack there are real space and cost constraints. I've accepted reduced-frequency voltage telemetry in exchange for full-fidelity fault and event history over a long window, and I've accepted quarterly scheduled exports instead of continuous streaming. On one program I accepted a supplier's portal in place of direct file access, on the condition that a bulk export was available on request within a stated number of business days and would be delivered in the native format.

What I won't bend on is the firmware version record or the diagnostic export test. Those two are where claims actually go to die, and they cost almost nothing to fix before the order and a great deal to argue about afterward.

The claim you'll file in two years is being written right now, in a spec review, by whoever decides how long the log holds and whether anyone bothered to write down which build is on the pack.