Battery ID & Serialization
Most failures happen when teams mix model identity and unit identity. The passport record typically needs both: a stable model identifier for the design and a stable unit identifier for the physical item.
Treat these as different objects, with different owners, lifecycles, and change rules.
| Identity type | What it identifies | When it changes | Examples of owners |
|---|---|---|---|
| Model ID | A battery design or product definition (the type¯) | When the design changes in a way that affects declared data fields | Engineering, PLM |
| Unit ID | A specific physical battery unit placed on the market | Usually never; it should survive service and lifecycle events | Manufacturing, quality, ERP/traceability |
Identity hierarchy
Batteries often have hierarchy: cell, module, pack, and sometimes system integration (for example, in BESS containers). The passport requirement is not an excuse to serialize everything, but you must define what level is the unit¯ for your passport record.
Define one primary unit¯ identity level for passport purposes, and define how subcomponents link to it for traceability and service history.
| Level | Typical approach | Identity risk | Design note |
|---|---|---|---|
| Cell | Batch / lot traceability; sometimes unique serials for high-risk cells | Serial explosion; weak linkage to pack lifecycle events | Serialize only if you have a real business or safety need |
| Module | Often serialized for manufacturing and service | Module swaps break continuity if policy is unclear | Define whether module replacement is an update or a new unit |
| Pack | Common passport unit¯ identity for EV and many industrial products | Refurb and rebuild can invalidate assumptions | Treat pack serial as primary, with module linkage |
| System integration | BESS and larger products may add an installation identity | Confusing asset ID with battery unit ID | Keep asset ID separate; link to battery unit ID(s) |
Serialization strategy
A good serialization scheme is stable, unique, and machine-readable. It should avoid leaking sensitive data, avoid being smart¯ in ways that change over time, and support audit retrieval years later.
Use a documented format and freeze it. If you need internal semantics (plant code, date code), keep them in internal systems, not in the external unit identifier.
| Rule | Recommended practice | Common failure mode |
|---|---|---|
| Uniqueness | Global uniqueness across all products and years | Serials reused by plant, product line, or year |
| Stability | Unit ID never changes after creation | Serial replaced during refurb or rework with no linkage |
| Simplicity | Opaque IDs; keep meaning¯ in system fields | Embedding changing business logic into the identifier |
| Audit retrieval | ID resolves to a record with timestamped history | No historical log; only current state is stored |
QR codes and physical marking
The QR code is the access mechanism to the passport record. Your marking plan must account for durability, readability, tamper resistance, and service realities.
Define where the QR code is placed, how it is protected, and what happens if it is damaged. Do not assume the label will survive the entire lifecycle without a replacement policy.
| Marking topic | What to decide | Evidence to keep |
|---|---|---|
| Placement | Accessible without disassembly; protected from abrasion and chemicals | Marking drawing, work instruction, photo examples |
| Durability | Material, adhesive, and print method suitable for the environment | Qualification tests, supplier specs, change records |
| Replacement | Process to re-issue label without changing unit identity | Service procedure and audit log of replacements |
| Tamper handling | Policy for damaged/removed labels and suspected counterfeits | Investigation workflow and escalation records |
Change control
Identity breaks when change rules are vague. You need explicit criteria for when a change produces a new model ID, when it produces a new unit, and when it is only a lifecycle update.
Write these rules down and enforce them in systems and procedures. This is one of the highest-value compliance documents you can create for passport readiness.
| Change event | Model ID impact | Unit ID impact | Typical handling |
|---|---|---|---|
| Design revision that affects declared fields | New model ID or new model revision with controlled mapping | No change to existing units | Versioned model data; effective dates |
| Module replacement during service | No change unless design is different | Unit ID stays; update lifecycle record | Record service event; link replaced module serial |
| Pack rebuild from mixed sources | May require new model mapping | Often treated as a new unit with linkage to prior unit IDs | Define rebuild threshold¯ and identity policy |
| Second-life repurpose conversion | Depends on whether product is re-placed on the market | Unit ID should persist if possible; otherwise define successor linkage | Record role and status change; document trigger logic |
Audit-ready evidence
Identity compliance is proven with evidence. You need to show that IDs were generated consistently, assigned correctly, and preserved through lifecycle events.
At minimum, preserve an immutable event history for each unit ID and a controlled revision history for each model ID.
| Evidence item | Purpose | Where it usually lives |
|---|---|---|
| Serialization specification | Defines format, uniqueness rules, and allocation process | QMS / controlled document repository |
| Marking work instructions | Proves correct physical application and placement | Manufacturing process documentation |
| Event history log | Proves continuity, updates, and closure | Passport platform / audit log store |
| Change control records | Proves when IDs change and why | PLM + QMS change management |
Disclaimer. Informational guidance only. Not legal advice. Validate requirements against official regulation text and implementing acts.