BMS

A battery management system is the layer that keeps a battery safe and tells the rest of the system what state it is in. It sits in or next to the battery pack, usually as embedded hardware and firmware from the battery manufacturer. In a large storage system it is a hierarchy: a controller per module reads the cells, a rack controller combines the modules, and a system controller reports the whole battery to the outside world.

Its main functions:

• Measurement. Cell voltages, temperatures and pack current, read continuously.
• Estimation. State of charge (SoC) and state of health (SoH) cannot be measured directly. The BMS estimates them from current counting, voltage at rest and a model of the cells.
• Balancing. Cells drift apart over time. The BMS evens them out, either by bleeding energy from the fullest cells as heat (passive balancing) or by moving energy between cells (active balancing).
• Thermal management. It watches temperatures and triggers cooling, heating or a power reduction before a cell leaves its window.
• Protection. When a hard limit is crossed, the BMS opens the contactors and isolates the battery. It also reports the charge and discharge power the battery can accept right now, which shrinks when the battery is cold, nearly full or nearly empty.
• Communication. It passes SoC, limits, alarms and measurements to the systems above it, usually the power conversion system and the energy management system.

The acronym has a second meaning. In facilities, BMS stands for building management system, the control system that runs heating, ventilation, air conditioning, lighting and access in a building. The idea is similar, one control layer over many devices, but it is a separate field with its own vendors and protocols. This entry is about the battery sense.

Few projects write BMS firmware. Most buy a battery with a BMS inside and build the software that talks to it: an EMS, a monitoring platform or a fleet dashboard. The BMS then becomes an interface you do not control, and that is where the requirements come from:

• The BMS limits are hard constraints. The EMS reads the allowed charge and discharge power in every cycle and stays inside it. It keeps the battery in a narrower operating window, so the BMS protection is never the thing that stops it.
• Each battery model has its own register map and alarm codes, often over Modbus. Ask the battery supplier for the documentation and a contact for communication questions before the integration starts, and plan for a firmware update moving registers.
• Every read and write is checked. A failed read must not be published as a fresh value, and the software should read back what it wrote. A battery that reports nothing for a few cycles is an alarm, not a zero.
• Alarms are mapped. Hundreds of vendor codes have to become a short list that an operator can act on, with a clear state for a battery that is switched off.
• History is kept for the warranty. Temperatures, cycles, deep discharges and SoH estimates decide warranty claims and the battery's resale value, so the platform stores their history.

The Battery Regulation (EU) 2023/1542 made holding BMS data a legal requirement. Article 14 requires, from August 18, 2024, that stationary battery energy storage systems, light means of transport batteries and electric vehicle batteries contain a BMS holding data on the parameters that determine state of health and expected lifetime, listed in Annex VII. The person who legally bought the battery, and third parties acting on their behalf, must get read-only access to that data, among other purposes to evaluate the battery's residual value or to prepare it for reuse or repurposing.

For a buyer of battery software this has two consequences. The data the BMS holds is no longer only the battery vendor's business, so a platform has a legal basis to read it. And the platform should store it in a form that can be shown to an owner, a buyer of a used battery or an insurer.

Our work sits above the cell-level BMS: we build the software that reads it, respects its limits and turns its data into decisions. We have not written BMS firmware for chemical cells.

For Kyoto Group the storage was not a chemical battery but a molten-salt thermal store. In the 2024 phase our scope included what Kyoto calls the BMS of its thermal battery: control of the valves, pumps and the flow of hot fluid in the salt store, integrated with the plant's SCADA layer. Next to it the team built surveillance with infrared cameras and image recognition that works with the BMS and SCADA to catch anomalies a single sensor would miss.

The EMS we built for Skyfri started with communication workshops with the battery supplier in February 2024 and treats the limits the battery reports as hard constraints. For Global Green's battery storage sites we mapped the registers of battery systems from two manufacturers in 2026 and added an alarm for a battery in the off state in July 2026. Testing found a failed batch read that published stale values as fresh, which was fixed. In Zeronest's EMS the battery is reached through the inverter, so the minimum and maximum SoC come from the inverter model and can be overridden for each installation.