Home › Second-Life Battery › EV Battery BMS

EV Battery BMS for Home Energy Storage

Every EV pack ships with its own Battery Management System (BMS). Second-life reuse is safe when — and only when — that BMS stays in place. This page explains the split between the original BMS and the BMS-EV controller, and why replacing the factory BMS with a DIY unit degrades the safety envelope.

What the original EV BMS does

An EV Battery Management System is a distributed measurement and protection network engineered by the automaker to a functional safety level typically corresponding to ASIL C or D under ISO 26262. In a Tesla Model 3 pack, one main BMS ECU (BMS_hp) communicates with 4 CMBs (cell monitoring boards) that each read voltages and temperatures across 25–27 modules; a total of 96 to 108 series-cell groups are individually monitored. BMW i3 uses a similar architecture with an SME (Speicher-Management-Elektronik) ECU and dedicated CSC (cell sensor controllers). VW MEB packs use one BMC and up to 12 CMCs. In all cases the BMS is responsible for:

• Cell voltage measurement. Each cell group measured to ±5 mV, sampled at 10–100 Hz.
• Temperature measurement. Typically 12–48 NTC sensors distributed across modules and coolant paths.
• Current measurement. Hall-effect or shunt-based measurement at pack terminals, ±1 % accuracy across ±500 A.
• State of Charge (SoC) estimation. Kalman-filtered SoC using coulomb counting and open-circuit voltage lookup.
• State of Health (SoH) estimation. Long-term capacity and internal-resistance tracking.
• Cell balancing. Passive dissipative balancing during charge (Tesla, i3, MEB), typically 50–200 mA bleed per cell above threshold.
• Contactor supervision. Main +, main −, precharge, and (on some packs) charge-port contactors — the BMS commands the closing but shares control with the vehicle in some architectures.
• Fault handling. Immediate contactor opening on any cell over/under-voltage, over-temperature, over-current, isolation fault or communication loss.
• Charge/discharge current limits. Continuous computation of I_max(charge) and I_max(discharge) based on SoC, temperature and SoH; broadcast on CAN.

What the BMS-EV controller does — and does not do

The BMS-EV controller is an external gateway. Its enclosure is ~150 × 100 × 40 mm; it hosts a microcontroller (typically STM32 or ESP32-class), two isolated CAN transceivers, contactor coil drivers rated for 12 V/2 A, precharge control lines, analog inputs for HVIL and precharge feedback, and firmware pre-configured for one specific battery + inverter combination. Its scope is:

• Protocol translation. Reads the battery-side CAN messages the original BMS broadcasts on the vehicle CAN bus, and re-encodes them into the CAN protocol the inverter expects (Pylontech, BYD, LG, or a native inverter dialect).
• Wake-up and heartbeat emulation. Vehicle BMSes require CAN messages from the VCU/gateway to stay awake and to remain in "high voltage" state. Outside the vehicle those messages are missing. BMS-EV generates a minimal set — typically 6–12 periodic messages per battery type — sufficient to keep the BMS in operational state.
• Contactor sequencing. Drives the precharge contactor, waits for DC-link voltage to reach ≥95 % of pack voltage, closes the main contactor, releases the precharge contactor. Aborts and opens contactors on any fault reported by the BMS.
• HVIL termination. Closes and monitors the vehicle-side end of the HVIL loop; opens contactors within 10 ms if the loop breaks.
• Fault propagation. Translates BMS fault flags (cell overvoltage, isolation, temperature, etc.) into corresponding inverter alarms.
• Logging (optional). Some firmware variants log via serial or WiFi to a local MQTT broker or the Battery Emulator Cloud service.

What the BMS-EV controller does not do:

• It does not measure any cell voltage directly.
• It does not command balancing.
• It does not override BMS protection decisions. If the BMS says "stop", the controller stops.
• It does not modify BMS firmware.
• It does not require pack disassembly, cell removal or CMB relocation.

System architecture

Why keep the original BMS — and not use a DIY BMS

The alternative approach — physically removing the factory BMS, retro-fitting an aftermarket unit (SimpBMS, Batrium Watchmon, Orion BMS 2, REC BMS) and wiring cell taps to the new unit — appears in DIY communities. It is technically possible but structurally less safe than preserving the factory BMS. Reasons:

1. Certification. The factory BMS underwent development to ISO 26262 (functional safety, ASIL C/D) and ECE R100 (electric vehicle safety) with the pack's mechanical design. A user-installed DIY BMS carries no such certification and voids the pack's original type approval.
2. Cell tap access. Cell sensing on modern EV packs is routed through busbars and CMBs mounted on the module — cutting into these to add DIY BMS taps disturbs the module's electrical safety layout and, in Tesla and MEB packs, may compromise the pack's internal fusing.
3. Coolant and thermal integration. The factory BMS's thermal model is tuned to the pack's specific cooling geometry (Tesla's ribbon cooling, MEB's cold-plate, i3's inter-cell air paths). A DIY BMS without this model must derate heavily to stay safe.
4. Failure envelope. Factory BMSes have been validated against nail penetration, external short, overcharge, over-discharge and thermal propagation per UN 38.3 and IEC 62660. DIY BMSes trigger contactors but rarely include propagation-resistant enclosure design or pyro-fuse control.
5. Warranty and insurance. Many EU insurers explicitly cover installations that preserve OEM safety systems; they exclude DIY BMS conversions.

Comparison — Original BMS vs BMS-EV vs DIY BMS

How BMS-EV wakes the factory BMS outside the vehicle

Vehicle BMSes stay in a low-power sleep state unless the vehicle's other ECUs (VCU, gateway, DCDC converter) signal them to wake. Without those signals the pack sits at 0 V on its terminals — the internal contactors are open. To bring the pack up outside the vehicle, BMS-EV firmware emulates the minimum set of wake and heartbeat CAN messages the specific BMS expects.

Example — Nissan Leaf. The Leaf BMS (LBC) requires CAN ID 0x50B (message from vehicle control module, 6 bytes) and 0x1F2 (ready signal, 8 bytes) at 100 ms intervals to stay in "READY" state and close its contactors. If the messages stop for 500 ms it opens contactors. BMS-EV firmware for Leaf sends these two IDs plus 0x11A (shift indicator) as a synthetic vehicle.

Example — Tesla Model 3. The Tesla BMS_hp requires messages from the vehicle's Master Control Unit (MCU) and Vehicle Control Module (VCM) including 0x221 (VCFRONT_status), 0x321 (VCLEFT), and specific CRC + counter fields on each. BMS-EV firmware reproduces the essential subset (~8 CAN IDs) and increments counters/CRCs so the BMS accepts them as vehicle-authentic.

Example — VW MEB (ID.3, ID.4, Enyaq, Q4 e-tron). The MEB BMC expects around 15 messages from the vehicle's central gateway (Gateway_75 module), including terminal status, HV request, and 12 V system voltage. BMS-EV emulates these using MEB's AUTOSAR 0x2F CRC. Wake-up requires an initial "HV activation request" sequence lasting ~3 s before contactors close.

The exact CAN ID map and timing are pack-specific and are captured in each firmware build. This is why BMS-EV controllers are shipped pre-configured for a battery + inverter pair rather than as a generic device.

Preserving manufacturer SoH data

Every EV BMS tracks lifetime metrics — full-charge capacity (Ah), internal DC resistance per module, cycle count, cumulative kWh throughput, and cell-imbalance history. This data is stored in the BMS's non-volatile memory and continues to accumulate when the pack is used for stationary storage. Because BMS-EV does not reset or overwrite BMS memory, an operator who later returns the pack to the recycling chain retains an authentic SoH trail — required under Article 45 of the EU Batteries Regulation 2023/1542 for the digital battery passport. A DIY BMS conversion permanently erases this history.

Frequently asked questions