A Cell or BMS Change Can Quietly Void Your Battery Pack Certification
A cell substitution, a BMS revision, or a firmware update can move a battery pack out of the configuration that was actually tested, and once that happens the certificate and the test evidence on file stop describing the product in the box. The control that prevents it is unglamorous: a change log that ties every BOM revision, cell lot, and firmware version to the certification evidence that covers it, plus a hold point that keeps an unreviewed substitute off the line until that link exists.
The pack on the bench looks right. Same part number on the label, same connector, same wrap, same weight in the hands. Then the service tool goes into the comm port, the screen wakes up, and the firmware string reads one digit off from the revision written into the certification folder. Nothing looks different. Everything is different.
That was receiving inspection, not an audit. Nobody flagged anything, because as far as the supplier's system was concerned nothing had changed. The part number never moved. Same board. What changed was the code flashed onto it, and that code sets the protection thresholds and the charge behavior the pack was tested against.
The certificate describes a build, not a product family
This is the part that trips up good engineers. A certificate is not a stamp of approval on a design idea. It is a record that a specific assembly, with specific components and specific firmware behavior, passed specific tests. Change any of the inputs and the record still exists, still looks official, still downloads as a clean PDF from a shared drive, and no longer covers what you are shipping.
The two documents that usually get out of step first are the UN 38.3 test summary and the certification file. The test summary is the one that travels with the shipment, which means a stale summary is not a filing problem, it is a shipping problem. When the cell, the pack design, the protection circuit, or another safety-critical component changes, the honest starting assumption is that the test summary no longer matches the product until somebody has actually evaluated it. Sometimes that evaluation ends in delta testing rather than a full retest. Sometimes it does not. Either way, that determination is not mine to make at a desk, and it is not the supplier's to make on your behalf.
UL and IEC schemes work the same way underneath the paperwork. They certify a tested construction, and the follow-up program generally expects to be notified before a change that affects compliance with that construction. The critical components list attached to a listing is effectively a frozen shopping list. Swap in a cell from a different manufacturer because it drops into the same holder, and you have changed an item on that list.
Firmware is not the soft part
People treat firmware like a settings screen. It is not. In a battery pack, firmware is a safety function. It decides when the protection FET opens, what the overcurrent cutoff is, how the charge curve tapers, how the pack behaves when a cell drifts. A revision that widens a threshold by what looks like a rounding error has changed the behavior the pack was tested with.
The nasty version of this is the quiet one. The BMS supplier updates its firmware for its own reasons, or a contract manufacturer flashes a newer build because that is what came on the reel, and nobody in the chain considers it a change worth announcing, because the board part number did not change. This is exactly the case where a pack on your dock can be out of the certified configuration while every document in the file says otherwise.
So version strings have to be read, not assumed. On the lines I work with, that means pulling the firmware version off a sample pack at receiving and comparing it to the number recorded as certified. It takes minutes. It has caught more than one surprise.
Notifications arrive, just not where you are looking
Product change notices are the trigger for this whole review, and they are easy to lose. They show up as a distributor email, a portal notification nobody is subscribed to, a line item in a quarterly review deck, or a comment at a trade show. Cell makers discontinue lines. Second-source parts get qualified. A plant moves production to a different site. A BMS vendor revises code. Each of those is a notification event, whether or not anyone labels it one.
What I do with a PCN is stop reading it as an announcement and start reading it as a question: does this touch a cell, a protection circuit, a firmware build, or a component on the critical list for any pack we ship under certification? If yes, it opens a change record that cannot be closed by updating a drawing. It closes when the compliance evidence file has been updated, or when the change has been evaluated and formally rejected.
The traps I see most often are these. A second-source cell qualified by purchasing because the primary went on allocation, with the qualification folder showing capacity and cycle data and nothing about certification impact. A protection IC replaced with a pin-compatible alternative. An end-of-life notice on a cell that gives you a couple of quarters, where the whole program gets rushed at the end and notification is the last thing anyone remembers. And a firmware bump that came bundled with a bug fix, which is the hardest one to argue against and still has to be evaluated the same way as any other change.
None of that happens because someone is trying to sneak something past you. It happens because the change looks small from where the person making it is standing.
The log is the whole system
Everything above collapses without a simple register, and a simple register beats a beautiful one. Ours has a row per shippable configuration: assembly part number, cell manufacturer and model, cell lot range, BMS part number, firmware version, UN 38.3 test summary revision and date, certification file reference, and the date someone last verified the row against what is actually being built. One page, maybe two. It gets checked at the monthly production review, and it gets checked after every PCN.
Note what that row does that a certificate PDF cannot. It ties a physical thing, a lot of cells and a firmware build, to a piece of evidence. When a customer or a customs officer or a certification body asks whether a specific shipment is covered, the answer comes from the row, not from the certificate sitting in a folder nobody opens.
PPAP and APQP sit on top of this. A change approval that updates the drawing, the control plan, and the PSW but leaves the compliance evidence file untouched has approved half a change. I have watched a PSW get signed for a component substitution with no one in the room asking what it did to the test summary, and the parts flowed the same week.
Production records close the loop. The build record for a lot should let you walk from a serial number back to the cell lot and the firmware version that went into it. Without that, you cannot show that you built the certified configuration. You can only show that you believe you did.
Where I draw the practical line
I am not going to pretend this is free. Notifying a certification body costs time, and sometimes it costs testing. Holding an older firmware revision while a change is evaluated costs schedule. There are real cases where the cheapest path through a change is to delay it, and if you do not have the analysis in hand when the change lands, you are making that call by accident.
What I refuse to do is let a change close on a drawing revision alone. The rule is short: no BOM or firmware revision ships until a named person has recorded, in writing, what it did to the certification evidence. Not what it probably did. What it did.
And I say out loud that the boundary of what it did belongs to the certification body, not to me. My job is to notice the change, freeze the configuration, ask the question with the actual documents in front of me, and not let production run ahead of the answer.
