Your BMS Firmware Isn't Frozen Just Because the Spec Is

The BMS firmware revision number, not the BMS model number, is the identifier that belongs in your pack specification, on the purchase order, and on the goods-in record. A model number describes a circuit board. A revision number describes how that board behaves on your robot: what temperature trips the charge FET, how much current the pack will accept at 5 °C, how quickly it answers your vehicle controller, and how long it waits before deciding the controller has gone quiet. Two packs carrying the identical model number on the drawing can behave like two different products. If the revision is not a controlled line item, you find that out in the field, on the unit that happened to be carrying the load that week.

I learned that one on a twelve-unit pilot, and the lesson arrived as a service ticket. You are at the packing table with a laptop, the vendor's configuration utility open, a USB-CAN dongle hanging off the pack harness, and the fault log on the second screen. The fault says over-temperature. The thermistor reads 47 °C. Your approved spec says the charge FET trips at 55 °C, and it has tripped at 55 °C on the other eleven units since March. So you read the revision out of the pack. The tool says 3.1.4. The spec that went through design review, that four people signed eight months ago, says 3.0.9.

The supplier's engineer was not being evasive when he said, "It's the same board." It is the same board. That is the entire problem.

The drawing names hardware. It never named behavior.

On a pack drawing, "BMS: ABC-400A" is a bill-of-materials line. It tells you which PCB assembly the pack builder is buying. It tells you nothing about what is loaded into that board's flash when the pack leaves the line, and the flash image is what your robot actually negotiates with every time it closes a contactor.

I have sat in reviews where the pack drawing was version-controlled down to the connector keying, rev C to rev D, every dimension and torque callout documented, and the firmware inside the enclosure had moved four times under the same drawing revision. The drawing system worked perfectly. It was answering a question nobody was asking.

So I stopped treating the model number as the identity of the thing I bought. The model number is the chassis. The revision is the product.

What a firmware version register actually contains

Ask for it as a controlled document with a revision history, not as an answer buried in an email thread. If the supplier doesn't have one, that is itself the finding, and it is worth more than a good answer to a bad question.

The register I ask for carries, per pack program: the full revision string including the build or patch suffix, not a rounded 3.1; the hardware revision the release is qualified against; the release date and the checksum of the binary; a behavioral summary in plain language covering what moved in limits, timing, or fault handling; known limitations; and a named owner with a title and a phone number rather than "the firmware team."

On cadence, I ask for updates within ten business days of any release and a standing review at every quarterly business review. What I am actually testing is not whether the document gets updated. It is whether one person at that company knows they own it. If the name on the register turns over twice in a year, that tells me something about continuity I need to price in before I sign a five-year agreement.

The places a revision hides when nothing on the drawing moves

This is the part that gets skipped in most change-control conversations, and it is the part that costs money.

Charge current limits and the temperature derating tables behind them. Fault thresholds and recovery hysteresis, where 55 becomes 47 and the recovery window changes so a pack that used to self-clear now latches until someone power-cycles it. CAN message cycle timing and startup sequencing, where the pack answers at a different interval or takes 400 ms longer to report ready after contactor close, and your vehicle controller's timeout logic was tuned to the old number by someone who has since left. State-of-charge estimation, where a revised algorithm reports eight points differently and your dispatch plan quietly under-ranges the fleet. Sleep and standby current draw, which matters for an AMR parked over a long weekend. Precharge and contactor sequencing on power-up.

Not one of those is a drawing change. Not one of them requires a new pack-level part number. The change-control system everyone trusts, the drawing revision, never fires, because nothing on the drawing was wrong.

After design freeze, a firmware change needs four signatures

When the email arrives saying "we're moving the program to 3.2.x, minor bug fixes," I send back a template and I hold the shipment. In writing, before that release goes into anything with my program's name on it: the change described behaviorally rather than as miscellaneous fixes; before-and-after values for every limit, threshold, and timing parameter that moved; which of the supplier's test cases were re-run and which were waived; the exact revision string that will be flashed, with checksum; the effective date; and the first pack serial number affected.

Then it routes on my side, and it needs four approvals rather than one. Engineering validation signs that it still meets the duty cycle. Quality signs under change-control discipline. Service signs on field impact and spares. Procurement signs on cost, schedule, and whether the contract language covers it. The program lead breaks ties.

Three of those four will want to wave it through, because the supplier is being cooperative and everyone is busy. Service is the one that saves you, every time, because service is the function that has to explain a new fault code to a technician at a customer site in year three.

I have never gotten a supplier to freeze firmware across a five-year program, and I've stopped asking. A firmware team serving three hundred customers ships on its own rhythm; a bad revision left in place is worse than a changed one. What I can require is that no revision gets loaded into a pack built for my program without written approval and a notification window. Thirty days is a reasonable ask for a scheduled release. Emergency fixes get a phone call and retroactive approval, and I would rather have that than silence.

Your fleet will run more than one version. Budget for the matrix.

Packs reach new firmware three ways: they go back to the supplier and return current; a field tech loads it with a vendor tool and a laptop, if you bought that capability at RFQ; or it arrives over the air through the robot's telematics gateway, if the BMS supports it and your security team allows the route.

Divergence is structural, not sloppy. Replacement packs ship from a later build lot. Warranty repairs come back current. New robots arrive with whatever is shipping that quarter. And nobody pulls a working unit out of service for an update that isn't fixing anything. Within eighteen months, a forty-unit fleet is running three revisions, and how many you're carrying should be a number you know rather than a number you discover.

The cost lands in your diagnostics table. A fault code means something narrower on the newer release than it did on the older one. Your service procedure grows a branch. Spare packs have to be matched to units. Keep a fleet firmware map, serial number to revision, and update it at every service event. If a unit is in the shop for anything at all, update it and log it, because that is the cheapest maintenance window you will ever get.

The records that answer the question months later

Eventually someone asks which firmware was in pack serial X when it shipped. A customer, an auditor, an insurer, a program manager who inherited the file. You want to answer that in an hour.

Four sources, in descending order of how much I trust them. The pack label, with the revision printed or laser-marked alongside a date code. The supplier's as-built record, keyed to pack serial. The programming station log, with a timestamp, a station or operator, and the binary checksum. And your own goods-in read-back: plug the vendor tool into every pack at receiving and export the revision screen to a file named by serial number.

That last one takes about ten minutes a pack. It is the only one of the four that is in your control, and it is the one that has settled every argument I've been in. I keep those exports next to dated snapshots of the version register in the program file, because the register is a living document and the snapshot you looked at during the build is the one that matters later.

Archive or escrow, and what neither one buys you

Archive per pack program, not per company. A corporate escrow of "the firmware" is close to useless when what you need in year four is the specific binary, the parameter file flashed alongside it, the programming tool or a documented service path, and the release note that says what changed.

Escrow is a legal instrument and I am not going to pretend to advise on the agreement language. The operational point is narrower and harder. An escrowed file that neither you nor any service provider can physically load into a pack is a stack of paper. Before anyone counts escrow as continuity coverage, ask who programs a replacement pack in year four, with what tool, at what cost, and how many days it takes to get one to a dock in Ohio. If the answer is that it has to go back to the factory, your archive protects information and not the fleet.

Some suppliers will hand over a service programming tool and a training session for your field team. That is worth more than the escrow clause and it costs less than people assume, but it has to be asked for at RFQ, not after the third failure.

The spec line I write now

It reads roughly like this: BMS firmware revision 3.0.9 as recorded in the supplier's firmware version register dated [date], loaded at time of manufacture and marked on the pack label. No revision substitution without written approval from the buyer's program office, with a minimum 30-day notification for scheduled releases and same-day notification for emergency fixes. The supplier maintains the firmware version register and provides updates within ten business days of release. As-built records identify the firmware revision loaded into each pack serial number.

That paragraph has done more for me than any amount of extra diligence at the drawing level. The spec was never frozen. It just looked that way on paper. What you're actually buying is the right to know the moment it moves.