Safety Standards Explained for SOH & RUL Prediction

How Safety Standards Actually Constrain SOH/RUL Algorithm Design #

Most design engineers approach standards compliance as a post-design audit. They build the SOH estimator, tune the RUL model, then hand a finished BMS to a certification lab and hope for the best. That sequence is backwards, and it creates rework that we see repeatedly on projects coming to us mid-development.

The standards applicable to SOH and RUL prediction don’t just test the output — they prescribe what the algorithm must do under specific conditions, what it must report to connected systems, and what protective actions it must trigger when confidence intervals fall outside defined bounds. Understanding that layer before you write firmware is worth more than any post-hoc compliance review.

The standards landscape breaks into four tiers based on application:

That’s not an exhaustive list, but it covers the four standards your SOH/RUL design will be evaluated against in the markets that actually matter for volume procurement.

A detail most datasheet-focused engineers miss: these standards do not operate independently. IEC 62619 references IEC 62133-2 for cell-level test methods, which in turn defines the cycling conditions under which capacity retention is measured. If your SOH model is trained on data from a different cycling protocol (say, HPPC rather than constant-current cycling at 0.2C), the model’s outputs may not be valid under the standard’s definition of “capacity.” That mismatch alone can trigger a retest cycle.

The Misdiagnosis That Derails Compliance: Confusing SOH Estimation Accuracy with SOH Reporting Compliance #

Here’s the root cause issue that we see mishandled on at least a third of the BMS projects we review before certification submission: engineering teams optimize their SOH estimator for accuracy (minimizing RMS error against a reference cycle) but never validate it against the reporting compliance requirements defined in the applicable standard. These are different problems with different consequences.

IEC 62619:2022 Clause 9.4 doesn’t care whether your extended Kalman filter achieves 1.8% RMS SOH error on your validation dataset. What it requires is that the BMS can detect and flag when capacity has degraded to the point where continued operation creates a safety hazard — and that the flagging happens within a defined response window. The standard requires protective action to initiate within 2 seconds of a protection threshold being crossed. If your SOH algorithm has a smoothing filter with a 10-second time constant to reduce noise-induced false positives, you may already be non-compliant with that response window, regardless of estimation accuracy.

RUL prediction adds a second layer. Most RUL implementations in Chinese BMS designs we’ve audited use a cycle-counting model with a fixed end-of-life threshold, typically set at 80% capacity retention. That’s a reasonable engineering choice. The compliance problem arises when that threshold doesn’t align with what the certifying standard defines as the safety-relevant end-of-life boundary for your specific application. For stationary systems certified under IEC 62619, the safety-relevant threshold is defined relative to original rated capacity, not relative to the capacity at first commissioning. If your pack was accepted at 97% of rated capacity on day one, your 80% retention model is actually running to 77.6% of rated — below the IEC threshold — without triggering any flag.

The measurement method to confirm whether your implementation is compliant: run a full capacity test per IEC 62133-2 Clause 7.3.2 (three formation cycles at 0.2C/0.2C, 25°C ±2°C), establish your true rated capacity baseline, then validate that your BMS protection logic references that value, not the commissioning-day measurement. We use this as a standard gate in what we call our BMS-07 compliance pre-check, conducted before any sample goes to a third-party lab. The confirmation threshold: your BMS-triggered protection must activate at or above 60% of rated capacity on this reference baseline. If it activates at 58% or 55% because of baseline drift in your SOC/SOH co-estimation, you’ll fail Clause 9.4 on the first review.

Corrective Actions When Your SOH/RUL Algorithm Fails Pre-Certification Review #

1. Recalibrate your SOH baseline to rated capacity, not commissioning capacity. This fixes the most common Clause 9.4 failure and requires only a firmware parameter change in most BMS designs. It costs nothing if caught early; it costs 3–6 weeks if caught at the lab after sample submission. Applies to 100% of cases where the failure is IEC 62619 Clause 9.4 non-compliance.

2. Audit your protection response latency against the 2-second requirement. Check every filter, debounce timer, and communication latency in the protection trigger chain. A BMS with CAN bus SOH reporting where the host controller handles protection logic may have 400–800ms of communication latency before the relay opens. That eats most of your budget before the algorithm even runs. If you’re over 1.5 seconds end-to-end, either move protection logic onto the BMS local processor or reduce filter time constants.

3. Replace cycle-counting RUL with a capacity-fade model cross-validated against the standard’s cycling protocol. This is a more substantial firmware change, typically 4–8 weeks for a supplier with in-house BMS firmware capability. It’s the right investment for products targeting EU or AU stationary markets, where IEC 62619 compliance is mandatory and AHJs are increasingly requesting RUL model documentation as part of site approval. Dongguan-based BMS manufacturers with in-house firmware teams can turn this around in 5–6 weeks if you provide a well-specified requirement document.

4. For UN 38.3 transport compliance on aged packs, add a pre-shipment SOH gate. UN 38.3 Rev.7 Section 38.3.2.9 restricts shipment of lithium batteries to a state of charge at or below 30% unless additional packaging controls are applied. Your SOH/RUL model needs a corresponding check: if a pack’s RUL estimate puts it within 10% of its EOL threshold, it should require review before shipment, not just before deployment. Build that flag into your firmware now; retrofitting it post-certification adds a change control cycle that most certification bodies will treat as a material change requiring re-test.

5. For GB/T 36276-2023 compliance in China, add mandatory SOH calibration interval logging. The 2023 revision added a requirement that BMS systems in grid-connected stationary applications log full capacity calibration events with timestamps, at a maximum interval of 180 days. If your firmware doesn’t have that logging structure, it fails the GB/T audit regardless of algorithm quality. This is a data architecture change, not an algorithm change — scope it accordingly.

Prevention — What to Specify Upfront in Your Supplier Brief #

Before you issue an RFQ to any BMS supplier, your technical brief needs to specify three things explicitly: the SOH floor threshold referenced to rated capacity (not commissioning capacity), the protection response latency budget in milliseconds, and the applicable standard set by market. Don’t leave the standard selection to the supplier. We’ve seen suppliers default to GB/T when the product is destined for the EU, because that’s what their test lab is set up for.

For BMS engineering procurement, the document to request before qualification is the supplier’s BMS firmware change control log. A supplier that can’t show you a log with version history, parameter change records, and associated test results hasn’t got the firmware maturity to support a standards-compliant SOH/RUL implementation. That log absence is a harder disqualifier than any single spec gap.

Pair this with a review of your safety certification approach early — the standard selection decision affects cell chemistry, BMS architecture, and packaging design simultaneously.

Sourcing Guidance for Buyers #

When evaluating Chinese BMS suppliers for SOH/RUL compliance capability, the first document to request is the firmware test report from the most recent IEC 62619 or UL 9540A certification cycle, with the specific firmware version number visible. A supplier who provides a certification certificate without an accompanying firmware version reference has likely used a different firmware build for certification than the one they’ll ship. That gap is where field failures come from.

The qualification red flag specific to this product category: suppliers who quote SOH accuracy as a percentage without specifying the reference standard, cycling protocol, or C-rate. “±3% SOH accuracy” is meaningless without knowing whether that was measured at 0.2C constant current per IEC 62133-2 or at a HPPC pulse protocol. These produce different results on the same cell, and only one will be valid for certification purposes.

For incoming inspection, run a 3-sample capacity test per IEC 62133-2 Clause 7.3.2 conditions on each incoming BMS-integrated pack lot. The pass threshold is that all three samples must trigger SOH-based protection within ±5% of the specified SOH floor threshold. Based on our evaluation of 31 incoming lots from Shenzhen-area pack houses over the past 14 months, roughly one in five lots shows threshold drift exceeding 7% from the factory-specified value. That’s not a cell problem. That’s a firmware calibration problem, and it requires a supplier CAR, not just a lot rejection.

Published by compactbess.com Technical Team | Request a sourcing consultation