In this article
Energy storage system control combines battery supervision, operating-mode selection and supervisory monitoring. The battery management system (BMS) monitors battery condition and permissible limits. The energy management system (EMS) plans the use of stored energy. Supervisory control and data acquisition (SCADA) provides monitoring, alarms, archiving and information exchange.
Business owners need to check how these functions work together. A screen with graphs does not prove automatic optimisation, and buying a controller does not mean all algorithms are ready. This article helps define the integrator's task, identify required data and verify the result before operation begins.
Three systems address different tasks
The functional distinction is between equipment condition, decisions about its use and presentation of the result. These roles may be implemented across several devices or partly combined in one software environment. The number of cabinets does not determine the completeness of control: confirmed functions and coordinated interaction are required.
Consider the power plant controller (PPC) separately. It applies dispatch setpoints and regulates active and reactive power, voltage or other specified parameters at the connection point. The power conversion system (PCS) directly converts energy. Its role should not be confused with planning operating modes or retaining event history.
| Role | Main question | What to check |
|---|---|---|
| Battery control | What does its current condition allow? | Measurements, limits and alarms |
| Energy management | How should the available resource be used? | Priorities, plan and command adjustments |
| Supervisory control | What happened and what can the operator see? | Events, archives, notifications and access |
| Plant regulation | How is a setpoint met at the connection point? | Feedback and actual parameters |
Hardware is covered in storage system components. Here the focus is on information and commands exchanged between components. Even with an integrated package, identify who configures interaction with meters, existing generation and business systems.
Battery control sets permissible limits
The BMS monitors cell, module and rack parameters, including temperature, voltage, current, insulation condition and alarms as applicable to the configuration. These data support assessment of battery condition, establishment of limits and transition to a safe state under specified conditions. Logs help reconstruct the sequence of events.
State of charge (SOC) estimates the available charge, but does not alone determine all available power. Temperature, voltage and other equipment limits also affect the permitted operating mode. The higher-level system therefore needs the relevant states and permissions, not only a percentage on a screen.
A charge or discharge request must remain within permissible battery limits. The economic case for an operation does not justify ignoring those limits. Specific thresholds, delays and responses are set for the equipment and project; there are no universal settings for all storage systems.
During selection, relate operating limits to expected load. For the distinction between stored energy and its rate of delivery, see storage power and capacity. A state-of-charge percentage does not replace checking both characteristics.
Energy management sets priorities
The EMS plans and optimises operating modes, manages state of charge and allocates system resources between tasks. For a business, this may mean coordinating consumption with solar generation, limiting peaks or maintaining a specified reserve. Functions depend on the implementation, so the specification should describe actual scenarios rather than just name the system.
For example, an agreed strategy might give backup for critical loads priority over shifting consumption in time. This is a hypothetical task-setting example, not a universal mode. The customer defines the desired outcome and the designer checks whether the chosen configuration can provide it.
Planning may use generation, consumption and price forecasts. These must be compared with actual data and available battery resources. A poor forecast or an overlooked limit can change the result even if a command is executed correctly. More cycles do not automatically improve economics: losses and wear must also be considered.
A technical algorithm does not replace a trading strategy, contracts or a market participant's responsibilities. The same resource cannot simultaneously be committed in full to incompatible tasks. Requirements should describe priorities, rules for changing a plan and the authority of the person who can adjust it.
For a business with solar generation, consider these requirements alongside a hybrid energy solution. Software control alone does not create backup power without suitable power equipment and a switching arrangement.
How data and commands flow
In general, measurements and limits flow from equipment to the control system, and agreed commands return to the devices that execute them. The following functional cycle is not an installation diagram. In a particular project, a plant controller or another agreed component may handle part of the exchange.
- Receive the state. Collect measurements, battery limits and equipment availability.
- Determine the command. Match the required mode to permissions and priorities.
- Check execution. Compare the actual response with the command and record events.
Prepare a signal list describing what is transmitted, its source, recipient and units. For commands, specify permitted values, acknowledgement and expected response. Also agree how an outdated value is identified when updates stop. A connected cable does not prove correct data exchange.
In a hypothetical example, the plan calls for charging but the battery reports a restriction due to its current condition. The system must take the current limit into account, and the operator should see why the actual result differs from the plan. The purpose is to verify the agreed logic, not simply produce an attractive graph.
Matching protocol names in two data sheets do not guarantee matching signals, commands or implementation versions. Compare the documentation for the specific delivery. The Sungrow equipment catalogue helps identify relevant product lines, but the properties of one controller or storage unit cannot be applied to the manufacturer's entire range.
Monitoring should explain events
SCADA provides monitoring, alarms, archiving and information exchange. Depending on the implementation, permitted operator commands may also be sent through it. This does not mean SCADA independently performs EMS optimisation or replaces battery protection.
Agree which data the owner sees live, which are stored in the history and how they can be obtained for analysis. Reasons for limits, commands, mode changes and execution results matter. A summary graph of generated or delivered energy alone may not explain a particular shutdown.
Comparable logs need synchronised device clocks and clear timestamps. Otherwise, events from different systems are difficult to place in one sequence. Separately define export format, archive retention and how records are obtained for diagnostics. Agree these conditions before commissioning.
If the storage system interacts with a solar plant, allocate responsibility for both parts. The solar plant maintenance page describes work on the solar plant. Support for a separate storage installation, its controllers and software integration must be agreed for the specific scope.
During a demonstration, ask to trace one event from the original signal through notification to the archive. Establish who receives the notification, who analyses its cause and how resolution is recorded. This checks not just the interface but whether the information supports everyday operation.
Communications, access and failure behaviour
Loss of external internet, local channel failure and controller unavailability are different situations. Do not assume that the system will always continue or always stop in each case. For each scenario, define the permitted mode, operator notification and conditions for returning to normal control.
For remote support, distinguish viewing rights from permission to change settings. Access should be justified, limited to the necessary permissions and controlled. Remote connections should provide for multi-factor authentication, action logging and termination of temporary access after the task is complete.
Software updates also require an accountable party and an agreed procedure. Save necessary configurations before changes and define a recovery method. Coordinate testing with the supplier and integrator so changes can be checked without endangering normal site operation.
What to accept with the control system
Describe each scenario's outcome and verification method in the technical specification. The integration lead should verify interaction between components, not just their individual availability. Define work boundaries and document handover in the storage project delivery contract.
Before handover, clarify which functions work locally, which depend on an external service and which need a separate licence. Agree operator training and actions available after commissioning. This helps prevent a situation in which the owner receives equipment but lacks the documents or permissions needed for its agreed use.
- Agree a matrix of modes, limits and command priorities.
- Verify signals, units, exchange directions and acknowledgements.
- Test notifications and responses to agreed communication failures.
- Obtain documentation, configurations, access and support procedures.
- Record test results and outstanding observations.
Include these scenarios in the installation testing and acceptance programme. Trained specialists perform tests under an agreed procedure. For an initial discussion, prepare a site diagram, equipment list, desired modes and requirements for access and archives.