Control Philosophy and SCADA Design for Solar and BESS Systems

Engineer checking control and monitoring data at an electrical substation

By AGILE Consulting Engineers, Solar PV and Battery Energy Storage Systems (BESS) specialists.

A Battery Energy Storage System (BESS) with a well specified inverter fleet and a poorly defined control philosophy is still an unpredictable asset. The hardware can be excellent and the plant will still behave inconsistently if nobody has written down, precisely and unambiguously, who is allowed to tell the battery what to do and in what order. Control philosophy is the least visible document in a design package and one of the most consequential.

Table of Contents

What a Control Philosophy Document Actually Is

A control philosophy document sets out, at a design intent level, how a solar and BESS plant is meant to behave under every operating condition it will realistically encounter. It is not a configuration manual and it is not a substitute for the detailed engineering that a control systems specialist performs during implementation. It is the reference document that everyone involved in delivering and later operating the plant, from the protection engineer to the commissioning team to the eventual asset manager, uses to understand the intended behaviour before a single relay is set or a single control loop is tuned. Getting this document right early in detailed design reduces the risk of conflicting assumptions surfacing during commissioning, which is an expensive and stressful place to discover them.

Operating Modes

At a conceptual level, most BESS control philosophies define a small number of high-level operating modes and then describe the transitions between them. A grid-connected normal operation mode governs day-to-day behaviour when the plant is synchronised with the network. A backup or islanded mode governs behaviour if the plant is required to operate disconnected from the wider grid, which is particularly relevant for remote and microgrid applications. An engineering or maintenance mode governs behaviour when technicians need controlled access to the system outside normal automatic operation. Within these broad modes, plants typically step through a sequence of states such as startup, standby, charging, discharging, and various restricted or fault states, with clearly defined conditions for entering and leaving each one. The point of documenting this conceptually, rather than as a line by line specification, is to establish the intended behaviour that detailed control engineering and commissioning then implement and verify.

Control Hierarchy and Priority

Control hierarchy is the part of the philosophy that determines who wins when two instructions conflict. A solar and BESS plant typically has several layers capable of issuing instructions, potentially including the network operator or market signals, a site-level energy management function, individual inverter or Power Conversion System (PCS) controllers, and manual operator overrides. Without an explicit hierarchy, it is genuinely possible for two legitimate control instructions to conflict, for example a market dispatch signal calling for discharge at the same moment a protection or thermal limit calls for a reduction in output. A sound control philosophy establishes that safety and equipment protection limits always sit above dispatch or optimisation instructions, and it defines, layer by layer, which system has authority under which circumstances. This is described conceptually in the philosophy document; the specific relay settings, control loop parameters, and communication protocols that implement it are matters for the detailed control system design and remain outside what we would publish here.

Response Logic at a Conceptual Level

Response logic describes, in general terms, how the plant is expected to react to defined triggers such as a frequency excursion, a voltage deviation at the point of connection, a state of charge limit being approached, or a communications failure with an upstream controller. A control philosophy will typically state the intended response in plain terms, for instance that the plant should curtail output to remain within a defined export limit, or that the BESS should prioritise maintaining a reserve state of charge over a dispatch instruction once a lower threshold is reached. What it will not do, and what we deliberately do not provide in public technical content, is specify exact setpoints, timing parameters, or vendor-specific configuration steps. That level of detail depends on the specific equipment selected, the connection agreement in place, and applicable Australian Energy Market Operator (AEMO) and network technical requirements, and it is properly the output of a qualified engineer’s detailed design process rather than something that can be responsibly generalised in an article.

SCADA’s Role in Monitoring and Control

SCADA, or Supervisory Control and Data Acquisition, is the system that gives operators and asset managers visibility into what the plant is actually doing and, within defined limits, the ability to issue supervisory instructions to it. For a solar and BESS plant, SCADA typically aggregates data from inverters, the BESS controller, meteorological stations, protection relays, and site meters into a single monitoring environment. Its core functions include real time monitoring of plant performance and status, alarm and event management so operators are notified when a parameter moves outside expected bounds, historical data logging that supports performance verification and compliance reporting, and a supervisory control interface that allows authorised operators to issue high-level instructions such as mode changes or output limits, always within the boundaries that the underlying protection and control systems enforce. SCADA sits above the real-time control layer rather than replacing it, which is an important distinction: the fast protection and control functions that keep the plant safe operate independently of whether the SCADA link is available at any given moment.

How SCADA, EMS, and BMS Relate

These three acronyms get used loosely in the industry, so it is worth separating them conceptually. SCADA is the monitoring and supervisory control layer described above. An Energy Management System (EMS) sits at a higher functional level and is generally responsible for optimising how the plant dispatches energy against market signals, network constraints, or site load requirements, translating those higher level objectives into setpoints for the BESS and PV assets. A Battery Management System (BMS) sits at the battery level itself, monitoring cell and module health, temperature, voltage, and state of charge, and protecting the battery from operating outside safe limits. In a well designed plant these three layers are architecturally distinct but coordinated, with clear data flows between them defined in the control philosophy and SCADA architecture documentation, so that a fault or limitation identified at the BMS level, for example, can be reflected up through the EMS and SCADA layers rather than being invisible to the systems making dispatch decisions.

Why This Documentation Matters Commercially

A clear control philosophy and SCADA architecture is not just good engineering practice, it directly affects project bankability and operational risk. Financiers and insurers reviewing a project want to see that operating behaviour under abnormal conditions has been thought through and documented, not left to be worked out ad hoc during commissioning. Asset owners want a plant that behaves predictably and whose performance can be independently verified against the documented intent. And commissioning teams, who are often under significant time pressure, work far more efficiently when they are implementing a well defined philosophy rather than reverse engineering intent from vendor defaults. Investing the time to get this documentation right during detailed design is one of the lower cost, higher value activities in the entire project lifecycle.

What to Do Next

If your project needs a control philosophy and SCADA architecture that will stand up to financier, network, and operational scrutiny, it is worth involving an experienced design team early enough that this thinking happens before equipment procurement locks in assumptions you cannot easily change later. AGILE’s solar and BESS system design service covers control philosophy development and SCADA architecture as part of a coordinated detailed design package, working alongside the electrical, structural, and civil disciplines that the rest of the plant depends on.

FAQ

What is the difference between a control philosophy and a SCADA design?

The control philosophy defines the intended operating behaviour of the plant conceptually, including modes, hierarchy, and response logic, while the SCADA design implements the monitoring, alarming, and supervisory control system that lets operators observe and manage that behaviour.

Does a control philosophy document include specific relay or inverter settings?

No. It is a design intent document. Specific settings, timing parameters, and vendor configuration are determined during detailed control system engineering by qualified specialists, using the control philosophy as their reference.

What are the typical operating modes for a BESS?

Most philosophies define a grid-connected normal operation mode, a backup or islanded mode for disconnected operation, and an engineering or maintenance mode, with the plant stepping through states such as startup, charging, discharging, and various restricted or fault states within those modes.

Why does control hierarchy matter?

Multiple systems, including network signals, energy management functions, and individual controllers, can issue instructions to a plant, and a defined hierarchy ensures safety and equipment protection limits always take precedence over dispatch or optimisation instructions.

How does SCADA relate to the BMS and EMS?

SCADA is the monitoring and supervisory control layer, the BMS protects and monitors the battery at cell and module level, and the EMS optimises dispatch against market or site objectives. All three are architecturally distinct but should be coordinated through defined data flows.

Why does this documentation matter to financiers and insurers?

It demonstrates that abnormal operating conditions have been thought through and documented in advance rather than left to be resolved during commissioning, which supports project bankability and reduces operational risk.



A Battery Energy Storage System (BESS) with a well specified inverter fleet and a poorly defined control philosophy is still an unpredictable asset. The hardware can be excellent and the plant will still behave inconsistently if nobody has written down, precisely and unambiguously, who is allowed to tell the battery what to do and in what order.

About the Author

Related Articles

Have a Similar Project?

Let’s discuss how we can help