UN 38.3 is not IEC 62133-2, and robot packs often need both

UN 38.3 is the evidence that lets a lithium-ion pack travel, IEC 62133-2 or IEC 62619 is the evidence that argues the pack is safe as a product, and an NRTL certification is the evidence that gives a US buyer a file number to look up. A robot pack usually needs all three, and the fastest way to get the right package is to stop asking which standard applies and start writing a list of who is asking: the carrier for transport, the customer or insurer for product safety, and the destination market for the national mark.

The first time that distinction stopped being theoretical for me was at a contract manufacturer's conference room table with three documents fanned out in front of me. On the left, a UN 38.3 test summary — a couple of pages, a table of test types, a configuration listing, a signature block. In the middle, a CB test certificate with IEC 62133-2 printed on it. On the right, the customer's supplier quality checklist, with one line underlined twice: "UL listed or recognized battery, file number required."

The sales engineer across from me called all three of them "the certification." He wasn't lying. He just had one word for three different questions, and that word is where robot pack programs quietly fall apart — not in the lab, but at tables where everyone nods and nobody says out loud that the carrier has never cared about IEC 62133-2 and the insurer has never cared about a test summary.

Start with names, not standards

I build the map before I read a single report. Three rows on a legal pad.

The carrier. Usually a freight forwarder or an airline's dangerous goods desk. They want the UN 38.3 test summary, and sometimes the full report behind it. That is a transport question. It exists so the pack can get on a plane, a ship, or a truck.

The customer. Could be the AMR builder's own quality group, could be the end user at the warehouse, and behind the end user there is often an insurer. What they want is product safety evidence — what this cell does when it's overcharged, shorted, crushed, or cooked.

The destination market. If the fleet is deployed in the United States, someone eventually wants a mark with an NRTL behind it and a file number a third party can verify.

Three rows. Then I work them left to right, because the order matters: the transport row is a shipping gate you cannot skip, the product safety row is where you make a real engineering choice, and the national mark row is where most buyers get handed a marketing sentence instead of a document.

UN 38.3 answers a shipping question, and nothing else

The test types come out of the UN Manual of Tests and Criteria. Altitude simulation, thermal, vibration, shock, external short circuit, impact or crush, overcharge, forced discharge. Read that list slowly and notice what it's built around: a package moving through a logistics chain. A box being flown, stacked, dropped, and left on a hot tarmac.

Now put your AMR duty cycle next to it. An eight-hour shift of shallow partial cycles between, say, 40 and 60 percent state of charge. Opportunity charging at every station stop. Two months of the year in a chilled aisle. UN 38.3 has no opinion on any of that, and it isn't supposed to.

It will not tell you whether the busbar weld survives vibration in your enclosure with your mounting bracket. It will not tell you whether your balancing logic drifts. It will not tell you what happens when one cell in the middle of the block goes into thermal runaway. That is not a hole in the test. It is a different question.

Two practical things I insist on here. First, the test summary has to describe the configuration you actually ship — cell make and model, chemistry, capacity, series and parallel arrangement, BMS. A summary for a 13S4P pack does not cover the 13S6P you moved to when the customer asked for more runtime. Second, keep the summary with every shipment, because the forwarder will ask, and asking them to wait while you dig through a shared drive is how you miss a vessel.

Where the real decision lives

This is the part I want the reader sitting next to me for, because it's the one that costs schedule.

IEC 62133-2 is the secondary cell and battery safety standard written around portable applications. IEC 62619 is written for industrial applications. That's the scoping line, and a lot of programs either never learned it or quietly ignore it.

A warehouse AMR sits in an awkward spot. It is not portable in the sense of being carried in a pocket, and it is not a forklift either. So which one gets cited depends on how the pack is used and what the customer asks for. If the pack lives in a fixed fleet, on a docking charger, in an industrial building, the argument for 62619 is strong and I will make it. But if the customer's internal spec template says 62133-2 because that template came over from their consumer products division, I am going to be asked for 62133-2, and spending a quarter arguing standards theory with a supplier quality engineer who is measured on checklist completion is a bad trade.

My move is to test to the standard that fits the application and be ready to explain, in writing, why the other one doesn't apply to this duty. Sometimes the honest answer is that we do both. That is a cost and schedule decision, and it belongs before the tooling is cut, not after.

Neither of these is a US mark. Both are IEC documents. And neither one covers the charger, the enclosure integration, or the vehicle-level system — those live in somebody else's file, and you should know whose.

The US mark, and why "UL certified" is not an answer

Here is the trap. Someone on the customer side asks for UL. The reflex is to assume UL 2054, which is scoped to household and commercial batteries, or UL 2271, which is written for light electric vehicles. An AMR is neither a household appliance nor a light electric vehicle. It's industrial machinery with a battery on it. So neither file is automatically the one your pack belongs under, and a supplier who tells you "it's UL" without naming the standard has told you nothing.

What most of these programs actually end up shipping with is a CB test certificate to the IEC standard that fits the application, paired with a national certification issued by an NRTL that accepted the CB report. The CB certificate is the international half — it's a mutual recognition package, which means the NRTL does the national deviation work instead of rerunning the whole test. The NRTL's own certification is the half a US buyer or an authority can look up by file number. Together, that's the combination that satisfies both a global customer and a domestic one without two full test campaigns.

Some programs do land on a listing under 2271 or 2054 because a customer spec or an insurer demanded that specific file. That's a legitimate outcome. But go in knowing the file's scope description may not describe an industrial AMR, and that mismatch is exactly what an auditor finds two years later when nobody remembers why the file was chosen.

Read the scope page, not the badge

When a supplier sends me a certificate, I read four things before I read anything else: the certificate number, the standard and edition it's issued against, the applicant name, and the configuration it covers.

Then I read the scope, because that's where the truth is. Does the file cover the cell, the module, or the assembled pack? Does it cover my series and parallel count? Does it cover the enclosure and the BMS? Does it cover the charger, or is the charger a separate file I don't have?

Phrases like "UN tested," "IEC compliant," and "UL certified" are claims. The test I apply to a claim is simple: show me a document with a number on it and a scope paragraph, or we're not done.

The sequence I actually run

1. Write the ask list. Carrier, customer, insurer, destination market — one row each, with the name of the person or department behind it.
2. Clear the transport gate. UN 38.3 summary and report, matching the shipped configuration, refreshed whenever the configuration changes.
3. Choose the product safety standard by application, and reconcile it against what the contract actually names. If they disagree, resolve it in writing before testing starts.
4. Build the US half as a pair — CB test certificate plus NRTL national certification — unless a customer file or insurer demands a specific listing, in which case document why.
5. Lock the scope and write the change list: cell, chemistry, capacity, series and parallel count, BMS hardware, safety-relevant firmware functions, enclosure, mounting orientation, charger. Any item on that list can narrow or void the evidence you just paid for.
6. Decide who owns the file. If the NRTL certificate sits in the supplier's name and that supplier later discontinues the pack or gets acquired, you can end up holding inventory nobody can certify. That belongs in the supply agreement in plain language, along with who pays for a retest when you change a cell.

I'm describing a sequence, not a legal conclusion. Whether a particular mark is required for a particular deployment is a question for your customer's compliance group, and in some cases for counsel. What I can tell you is that the sequence above has never failed me, and skipping step one is how programs end up re-testing a pack they already tested.

The thing that actually costs you

It isn't the testing. It's the clock after the testing. Change a cell after the file is issued and you are not in a conversation, you are in a rebuild — new samples, new lab slot, new report, and a customer asking why the delivery date moved.

So the last thing I do on any robot pack program is walk the change list with the supplier and the customer in the same room, and get an answer on paper for each line. Not because I enjoy it. Because the alternative is discovering, eighteen months into a fleet deployment, that the certificate on the wall describes a pack slightly different from the one in the robot, and that nobody can say when the two drifted apart.