Battery Testing Lab Requirements
This page is complementary to the Testing Standards page. Standards define what to test. Requirements define how to run testing so the evidence is credible, attributable, and audit-ready. The goal is simple: when someone asks for proof, the test evidence holds up without rework.
When lab testing is required vs when field evidence is required
| Evidence type | Best for | Typical triggers | Output |
|---|---|---|---|
| Lab testing to standards | Market access, certification, transport acceptance, safety proof | New product, new market, new chemistry, certification requirement | Accredited test report and/or certificate |
| Production testing and QC | Ongoing conformity, lot control, drift detection | Manufacturing ramp, supplier changes, yield or quality signals | QC records, sampling plans, nonconformance and CAPA |
| Field monitoring and operational evidence | Real-world risk control, incident learnings, durability proof | Deployed fleets, BESS operation, warranty exposure | Telemetry, alarms, incident logs, corrective actions |
Lab requirements: how to choose a test lab that holds up in audits
Not all labs produce audit-ready evidence. Use these controls to reduce re-testing and “paper mismatch” failures.
| Lab control | What to verify | Why it matters |
|---|---|---|
| Accreditation scope | Lab accreditation covers the specific standard and methods being claimed | Prevents “test done, but not recognized” outcomes |
| Standard edition control | Lab will test to the correct edition and documents the edition explicitly | Wrong edition is a common audit failure |
| Sample handling and chain of custody | How samples are received, stored, labeled, and tracked | Without traceability, results can be challenged |
| Configuration definition | Exact model, revision, and key characteristics are locked for the tested sample | Prevents “wrong revision tested” disputes |
| Report quality | Clear pass/fail, test conditions, deviations, and sample IDs | Reports must be usable as legal-quality evidence |
Sample control and traceability requirements
Battery testing evidence is only as good as sample control. Define a repeatable sample control protocol:
- Assign a sample ID that maps to model, revision, and lot/batch.
- Record provenance: supplier, factory, date code, and configuration details.
- Record pre-conditioning: storage conditions and SOC (state of charge) at receipt.
- Lock the tested configuration: BMS firmware version, protection circuit type, thermal interface details (pack-level).
| Sample attribute | Minimum record | Common miss |
|---|---|---|
| Model and revision | Part number, revision, and bill of materials reference | Revision not captured, later design change breaks attribution |
| Lot and date codes | Lot/batch identifiers and manufacturing date codes | Cannot prove tested sample matches shipped production |
| Firmware and protection config | BMS firmware version and key protection settings | Firmware changes silently invalidate safety behavior assumptions |
| SOC and handling | SOC at receipt, storage conditions, handling controls | Inconsistent conditioning undermines repeatability |
Field requirements: what “good” looks like in deployed products
Field requirements are not only for BESS. Any battery with meaningful warranty exposure or safety exposure benefits from a field evidence loop. The goal is early detection and defensible corrective action.
| Field control | What to implement | Evidence artifact | Who owns it |
|---|---|---|---|
| Telemetry and alarms | Over-temp, over-current, under/over-voltage, isolation faults, gas/vent events (if instrumented) | Alarm logs and trend exports | Operations / Engineering |
| Incident reporting workflow | Standard incident form, root cause taxonomy, escalation criteria | Incident reports and investigation records | EHS / Quality |
| Corrective and preventive action (CAPA) | Fixes tracked to closure with effectiveness checks | CAPA log and verification evidence | Quality |
| Change control triggers | Thresholds that force engineering review and retest decision | Change requests and impact assessments | Engineering / Compliance |
Commissioning and acceptance testing for large installations
For large stationary systems, commissioning and acceptance tests are a field bridge between design intent and safe operation. The exact content varies by project and AHJ expectations, but common themes include:
- Functional checks for protection limits, alarms, and shutdown behavior.
- Verification of ventilation, detection, and emergency interfaces (where applicable).
- Confirmation of monitoring coverage and evidence retention.
- Baseline performance and thermal behavior under controlled load cases.
If the site is permitting-sensitive, keep commissioning evidence structured and retrievable. It becomes part of the audit package.
Minimum evidence pack for lab and field
| Pack element | Minimum contents | Most common weak point |
|---|---|---|
| Lab evidence pack | Test report, standard edition, sample traceability, scope statement | Model and revision scope not explicit |
| Transport evidence pack | UN 38.3 summary, classification, packaging and training records | Shipping workflow not standardized across teams |
| Field evidence pack | Alarm logs, incident reports, CAPA records, change control decisions | Data exists but is not retained or attributable |
Where to go next
| Topic | Recommended page | Why |
|---|---|---|
| Standards map | Testing standards | Which standards show up and what they are used for |
| Audit expectations | Audits | What auditors request and how evidence is evaluated |
| Transport compliance | Transport compliance hub | How evidence connects to air, sea, and road requirements |
Disclaimer. Informational guidance only. Not legal advice. Testing requirements depend on product type, market, and customer requirements. Use this page to make lab and field evidence audit-ready, then validate the specific test methods and acceptance criteria required for your products and target markets.