As we all experience with our work and home computers, software is never “done” and updates — whether planned or unplanned — are a continuous requirement. With the purchase of a new computer, you’ll generally get three to five years of steady operating system updates. Over time, updates can cause issues or not work at all as your hardware and software applications age.
Now imagine the same software update scenario across grid-scale battery energy storage system (BESS) sites. As most readers are aware, BESS deployments include a Battery Management System (BMS) to control the charging and discharging of individual cells. This is an important function to prevent over-voltage, which can occur as a result of fast charging and a sudden increased demand for discharging. The BMS is also responsible for logging core statistics, such as the voltage and temperature for individual cells, as well as string and bank level attributes (e.g. current, power and energy).
For the layperson, a single energy bank looks like a twenty-foot shipping container, because often battery providers modify actual twenty-foot containers for their specific needs. The capacity of a single energy bank dictates how many containers are installed at a location to provide the rated energy output.
To view fleet-wide historical and real-time usage data, operators use remote battery monitoring applications that rely heavily on telemetry generated by the BMS. In addition to collecting and reporting battery-related data, battery monitoring applications log and display environmental data such as humidity and ambient temperature.
Like any software system, over time the BMS needs to be updated in order to add new registers, apply bug fixes and/or security patches, or change units of measure (e.g kWh to MWh), for example. When such an update is required, the stakes are high. Despite rigorous testing, it has the potential to break the battery monitoring application, potentially leading to an entire energy bank overheating, overcharging or failing to discharge when requested.
How can you ensure that BMS updates won’t break your battery monitoring system?
For BESS integrators and operators, managing BMS software installed at their sites is a complex task. BMS software versions can differ not only between sites, but also between energy banks located at the same site. For the operator, testing multiple BMS versions with their monitoring applications can be a time consuming and costly exercise.
How do you keep the remote monitor software working, across multiple revisions of the BMS? Firstly, it’s important for the battery monitoring application to be able to query the BMS for its version. Without this, it will be only a matter of time before an update breaks the monitoring application. Even if the battery monitor has been updated, if it hasn’t been fully tested with all prior BMS releases, it could still fail in unexpected ways when trying to access data from energy banks running earlier versions.
At Peaxy, we’ve developed emulators for our customers to avoid battery monitor issues due to BMS software updates. These emulators impersonate the Modbus signals from the BMS, and API endpoints from battery monitoring systems. The emulators can be configured to mirror the configuration and register set of every battery system under management to validate full end-to-end compatibility for a string or bank, or across sites. As the BMS software is updated, the emulator is updated to match those same changes. By creating unique revisions of the emulator software for each BMS version, the battery monitor application can be updated and tested to ensure compatibility with the latest version, and all prior versions.
Peaxy’s Battery Monitor threads all the data, across the entire hierarchy of the fleet, from the site level down to individual cells, and then makes it queryable. For each cell, the entire manufacturing build and test data history is also made available.
In addition to providing a robust testing environment for the battery monitor application, the emulator provides a test bench for edge-deployed data agents responsible for transferring logged (BMS) data to the cloud before it’s further processed and made accessible to the battery monitor application. These testing scenarios can lead to significant cost savings.
For example, emulation can validate the physical hardware requirements for edge devices. Instead of installing an edge device for every energy bank, a scalable bank of emulators could validate that a single edge device is capable of managing multiple energy banks. Alternatively, emulation might also reveal that a less expensive edge device (e.g. with less memory and/or a less powerful CPU) can still do the job.
A BMS emulator can also help product engineering specify the correct performance parameters, such as the ideal data transfer rate for edge devices. It could be discovered, for example, that a polling rate at 10 second intervals (10Hz) is too slow to see all state transitions during a time window.
By emulating the BMS, BESS operators are assured that software updates will not disrupt or break their crucial abilities to monitor key battery performance metrics. Software updates might be a fact of life, but with careful planning and emulation, the updates will happen, and no one will even notice.
To find out how our Battery Monitor solution can help you navigate complex BMS upgrades and many other scenarios, please contact us today.
