What Should You Ask in a BMS Firmware Version Control Audit?

The opening request in a BMS firmware version control audit is the version numbering scheme and the change log that maps every release to a date and a reason — but the questions that decide whether control actually exists come later, at the sealing station, where the operator is asked to show how they know which firmware is inside the pack in their hands. Everything before that is documentation. Everything after it is evidence.

I start in the conference room anyway, because the quality manager needs to see me take the paper seriously, and because the paper tells me what to go look for on the floor. Binder, laptop, a projector nobody turns on. Before anything else I ask for three documents: the version numbering scheme, the change log, and the work instruction that tells the line what to do with both.

What the number actually means

The numbering scheme is the first tell, and it is a quiet one. I ask what the digits represent. Is it semantic — major, minor, patch — or is it a build counter that only ever goes up? Then the sharper question: what kind of change bumps which digit? If a protection threshold moves, does that get a new minor or a new major? Who decides, and is that decision written down anywhere?

If the answer is "whoever's doing the release," I write down that the scheme is a convention, not a control. That is not automatically disqualifying. Conventions hold fine until the person holding them leaves, and then they don't.

The change log is where I spend most of my time, because the reason column separates real logs from decoration. A row that says "bug fixes" or "performance improvements" tells me the log was written to look complete. The rows I trust are dull and specific: the overvoltage cutoff moved from one threshold to a lower one, the CAN heartbeat timeout was extended, a state-of-charge drift at low temperature was corrected. Reasons like that tell me somebody was inside the code and knew why.

Ask for the last two releases by date. Then ask what the release before that changed. If the answer requires opening a ticket system and searching, that's fine. If it requires calling someone who isn't in the building, the log is a summary, not a record.

The walk to the sealing station

ESD smock, heel strap, the smell of flux and isopropyl. The sealing station is where the lid goes on and the label goes on, and it is the only place in the plant where the abstract version number becomes a physical fact about a specific pack.

I don't ask the supervisor. I ask the operator two questions, in this order: how do you know which firmware is in this pack, and where do you write it down.

Then I watch the hands. A good answer comes with movement — pointing at the programmer readout, scanning a barcode on the pack, reading the number off the fixture display, then writing it into the traveler or scanning it into the MES. A bad answer is a shrug in the direction of the supervisor, or a look that says this is a question nobody has asked before.

What the red flags look like up close

Handwritten version labels are the classic one, and people get defensive about them, so it's worth being precise about why they matter. Handwriting alone isn't the problem. The problem is that a handwritten label means two manual transcription steps inside one shift, with no second pair of eyes, and it usually shows up alongside a work instruction that never mentions the label at all. That combination is a habit, not a process.

Other things I've learned to look for on the bench:

• A label with no version field, or a blank field where the version should be.
• A version on a label that does not appear anywhere in the change log. This one ends the tour. It means the record and the hardware disagree.
• A work instruction that says "record firmware version" without naming the field, the log, the form, or who verifies it.
• A label printer sitting idle while versions go on with a marker, because the label software doesn't have a version field configured.
• More than one programmer on the line, only one of which is the one the work instruction names.

Sampling the travelers against the packs

This is the part where the audit stops being a conversation. I pull five build travelers from the previous month — random, not curated, and I ask for the stack rather than a selection. Then I try to match each one to the physical pack, if the packs are still in the building, or to a label photograph if they shipped.

What I'm checking is narrow. Does the version recorded in the traveler match the version on the label? Does it match the version on the programmer log, if there is one? Are there gaps in serial numbers, and is there a traveler for each?

When the numbers line up across all three, the supplier has a chain. When they line up across the label and the traveler but nothing else, they have a record. When the traveler has a version and the label doesn't, they have a process that stops at the door of the shipping area.

The release question, and the one that follows it

For the most recent firmware version, I ask for the release record. Testing records first: what did you run against this build before it went anywhere near a production pack, and where are those results? Then sign-offs: who approved the release, and did that person have the standing to stop it?

A mature supplier can put a release packet on the conference table in ten minutes. A supplier that can't usually isn't hiding anything — they just never separated "we finished the code" from "we released the code," and those are different events.

Then the question I've found most useful in this whole section: where does the firmware live, and who can put it on a pack?

If the answer is a shared network drive and every technician's laptop, there is no version control. There is a version suggestion. What I want to hear is that the programming tool pulls from a release repository, that only released builds are available to it, and that unreleased builds require a separate tool that only a named few people hold.

How you'd find out, and how fast

I ask the supplier to describe, out loud, how a customer learns that the firmware in a product they already own has changed. Automatic or ad hoc is the fork in the road, and both answers are usable.

Then I ask to see the last notification they actually sent. Not the template. The sent item. If the honest answer is "we call you if it matters," then I am the one deciding what matters, and I'm doing it while my fleet is in the field carrying packs at three different firmware versions with no way to tell them apart from the outside.

The reverse question matters too: if a customer never updates, what happens to that version? Does it stay supported, or does it quietly fall off the testing list?

When the BMS is somebody else's

This is the part of the audit that gets honest about what's actually being audited. A pack assembler buying the BMS from a third party may have no ability to modify the firmware, and that is a legitimate way to run a business. What they cannot outsource is the record of what they flashed.

So the questions shift. Who sends you the firmware — a file, a physical programmer, a push from the vendor's cloud portal? Do you archive the exact file you flashed, or do you flash whatever the portal serves that day?

That second scenario is the failure mode I worry about most, because it's invisible. The pack built in March and the pack built in September both come off the line labeled with the same version number, and they are not the same code. Nothing on the label is wrong. Nothing in the traveler is missing. The vendor simply moved underneath you.

I also ask for the vendor's own change log covering the last two releases, and whether the vendor notifies the assembler before a change goes live or after.

The question I save for the end

By this point the room is tired and the coffee is cold, which is when I ask what's on the bench right now. Any engineering build, any test firmware, any file that isn't released. Who holds the tool to flash it. Whether it can reach a production pack, and what would have to go wrong for that to happen.

It sounds like a trap. It isn't. It's the question that separates a supplier who has a change log from one where the change log is the only thing that can go onto a pack.

Where I draw the line, and where I don't

A fifteen-person shop with a laminated log at the programmer, a folder of travelers, and a rule that only one person flashes firmware can be perfectly well controlled. I've stopped treating toolchain sophistication as a proxy for control. A large MES with a version field that nobody fills in is worse than a clipboard that gets filled in every time, because the MES creates the appearance of a chain without the substance.

There's a real tradeoff here that's worth saying out loud in the closing meeting: per-serial traceability is cheap on a line that already scans barcodes, and expensive to retrofit onto a line that labels by hand. That's a legitimate reason for a supplier to be at one level of maturity rather than another. It is not a legitimate reason for the label and the traveler to disagree.

My report almost never says "no version control." It usually says the records exist and the chain doesn't close at a specific point, and names the point.