Large and small batteries earn money (and stabilise the grid) only if they are charged, discharged or held in reserve at the right moments. The decision depends on volatile prices, forecast errors, grid limits and battery ageing. An optimiser combines price and load forecasts with a mixed-integer or stochastic model, often refined by reinforcement learning, and sends setpoints to the battery management system and bids to the market. The AI part is forecasting and policy learning; the guarantee part is a classical solver with hard safety limits.
Problem & value
- Today: many storage assets run fixed schedules (price spread rules, peak shaving thresholds, simple self-consumption). Utility-scale operators often outsource to an optimiser/trader; C&I sites rely on the inverter vendor's energy management system.
- Why hard: revenues are stacked across day-ahead, intraday, frequency containment and restoration reserves, and local services. Each choice changes state of charge and wear, so decisions are coupled over time. Forecast errors (prices, PV, load) directly cut revenue.
- AI value: better probabilistic forecasts, rolling-horizon stochastic optimisation, learned policies that react in real time, and explicit degradation costs so cycles are spent where they pay most.
- Market driver: the EU electricity market design reform (Regulation (EU) 2024/1747) explicitly promotes flexibility, including storage and demand response, and requires member states to assess flexibility needs; grid operators increasingly procure flexibility for congestion management [1]. German battery storage capacity has grown rapidly, with grid-connection queues for large projects now a bottleneck [2]. Revenue figures differ strongly by market and year; consult regulator/market-data publications rather than vendor claims.
Variants
- Utility-scale standalone storage: merchant trading across day-ahead, intraday and ancillary services, often with a tolling agreement.
- Co-located with PV/wind: firming, curtailment avoidance, grid-limited feed-in (see OPT-039).
- C&I behind-the-meter: peak shaving against network charges, self-consumption, dynamic tariffs, backup power.
- Virtual power plant / pooled flexibility: aggregating home batteries, EV chargers and heat pumps (see OPT-032, OPT-021).
- DSO/TSO flexibility products: local congestion and redispatch services (see OPT-022).
- Private use: household battery on a dynamic tariff is covered in OPT-032.
How it works
- market data + weather + load/PV telemetry
- probabilistic forecasts (price, load, generation)
- optimiser (rolling-horizon MILP / stochastic programme; degradation cost; grid and warranty limits)
- bid builder (day-ahead, intraday, reserve products; prequalification rules)
- real-time controller (re-optimise on new data, RL or MPC policy, imbalance handling)
- BMS/EMS setpoints (hard safety limits enforced locally)
- settlement, metering, performance report
- Forecasting: gradient-boosted trees or deep time-series models (e.g. quantile forecasts); time-series foundation models can be a baseline for load and price.
- Optimisation: the core is a linear/mixed-integer programme with efficiency curves, power and energy limits, throughput constraints and market rules. Stochastic or robust variants hedge against forecast error.
- Reinforcement learning: useful for fast intraday decisions and as a policy trained in a simulator; best used inside a solver or safety layer, not as the only controller.
- Human-in-the-loop: traders approve strategy parameters and risk limits; asset managers set warranty and degradation limits; the BMS has final authority over safety.
Data preparation
- Which data: day-ahead, intraday and balancing prices, load and PV or wind forecasts, battery telemetry (SoC, temperature, power limits), grid-connection and tariff data, warranty and cycle limits.
- Where it lives in an SMB: inverter or BMS portals, the energy manager's monitoring tool, smart-meter data from the grid operator, utility invoices and tariff contracts as PDFs, warranty terms in contracts.
- Typical gaps: gaps and clock drift in telemetry, inconsistent time resolution (15-minute vs. hourly), tariff rules and warranty limits not in machine-readable form, only a few months of history, closed vendor interfaces.
- Steps: (1) pull 12-24 months of market data from ENTSO-E and Netztransparenz; (2) export telemetry via Modbus, MQTT or vendor API, see PREP-005; (3) resample to one time grid and fill or flag gaps; (4) encode tariffs and warranty constraints as parameters; (5) store in TimescaleDB or Parquet. Contract PDFs can be read with the help of DOC-014. See also PREP-001.
- Share of effort: about 30 percent; much less with Path A where the vendor handles it. Check readiness with GUIDE-003.
Implementation paths
Which path for whom
- SMB: A. A C&I site or small storage owner without a trading desk should use the inverter vendor's EMS or a route-to-market partner that handles prequalification and bidding.
- Enterprise: B. Utilities and portfolio operators treat dispatch as a strategic margin driver and build their own strategy on market APIs, managed solvers and forecasts, often next to a partner.
- Developer: C. PyPSA, Pyomo, HiGHS and OpenSTEF allow transparent models and backtests without licence cost.
Path A — Buy (recommended)
- Optimisers / route-to-market: Fluence (AI-based Mosaic bidding software), Tesla Autobidder, Wärtsilä GEMS, Habitat Energy, Modo Energy (market analytics), and EU providers such as Entrix (Germany, part of Statkraft), Enspired (Netherlands/Germany), Node.energy, Next Kraftwerke (VPP), Sympower (demand response), Flexcity and Kiwigrid (C&I and EMS).
- Home and C&I: inverter/EMS vendors such as SMA, Fronius, Sungrow, Huawei and Victron offer built-in schedules.
- Choose A when: you do not have a trading desk, need market prequalification, or run fewer than a handful of assets. Check EU hosting, revenue-share vs. fee model, who owns data and bidding rights, and exit terms.
Path B — Build on cloud APIs
- Data: ENTSO-E Transparency Platform API (prices, load, generation), Regelleistung.net/Netztransparenz for German balancing data, weather APIs (DWD open data, ECMWF open data).
- Compute: managed MILP solvers (Gurobi, CPLEX, FICO Xpress, or OR-Tools) on EU cloud regions; forecasting with managed ML services or time-series foundation models.
- LLMs: only peripheral (explaining dispatch decisions, report generation, translating market rules); optimisation stays numeric.
- Choose B when: you want your own strategy and have energy-market engineers.
Path C — Self-host (open source)
- Modelling and solving: PyPSA/linopy, Pyomo, OR-Tools with HiGHS or SCIP; Julia/JuMP for fast rolling-horizon models.
- Battery models: PyBaMM for physics-based degradation, simplified throughput costs in production.
- RL: Stable-Baselines3, RLlib, Gymnasium environments built on historical prices; OpenSTEF (LF Energy) for open energy forecasting.
- Streaming and control: Kafka/MQTT, Modbus/IEC 61850 gateways. Hardware HW1 is sufficient (CPU server, edge controller); GPUs only for large neural forecasters.
Path D — Custom training
Worthwhile for portfolio operators: train price-forecast and RL policies on own multi-year market and telemetry data, and calibrate degradation models to your cell chemistry. Needs at least one to two years of high-resolution history and a backtesting simulator that reproduces market rules.
State of the art (2026)
- Co-optimisation of energy, reserves and degradation is the commercial standard; plain price-spread arbitrage is increasingly saturated as more storage enters the market, which lowers spreads in some markets.
- Probabilistic forecasting + stochastic MPC typically outperforms deterministic schedules, with value concentrated on intraday volatility.
- Learned policies (RL, imitation of optimal-hindsight schedules) show gains in research benchmarks and some pilots; robust production evidence is thinner than vendor marketing suggests.
- Foundation models for time series serve as zero-shot baselines for load and price forecasts but rarely beat tuned domain models on prices.
- Limits: forecast error on extreme price spikes, market-rule changes, model-plant mismatch, battery degradation uncertainty, and cyber exposure of control interfaces. Backtests overstate revenue because they ignore the market impact and partial information of real bidding.
Shared resources & combinations
- Same stack (time-series + optimization-solver): OPT-007 building energy, OPT-021 EV depot charging, OPT-023 district heating, OPT-032 home energy management; forecasting from PRED-007 (load/renewables) and PRED-008 (price).
- Upstream/downstream: PRED-026 supplies state-of-health for the degradation cost; OPT-039 handles the trading side; OPT-022 handles grid-operator flexibility needs; OPT-010 shares the trading-risk methods.
- Shared infrastructure: one rolling-horizon solver service and market-data pipeline can serve many assets.
Effort, cost & KPIs
- Path A: weeks for onboarding, plus revenue share or per-MW fees.
- Path B: 4-9 months with a small energy-data team.
- Path C/D: 9-18 months including market prequalification, backtesting and control-room processes.
- Cost drivers: market-data licences, solver licences, engineering time, prequalification and testing, 24/7 operations.
- KPIs: revenue per MW per year versus perfect-foresight benchmark, forecast error (pinball loss), availability, throughput/cycles against warranty, imbalance cost, degradation cost per cycle, bid-acceptance rate, grid-limit violations (target zero).
People & change
- Involve early: management (risk and revenue-sharing decisions), the asset or energy manager (process owner), control-room and operations staff, IT and IT security (control interfaces, NIS2, Cyber Resilience Act), legal (REMIT, contracts, bidding rights) and the optimiser or inverter vendor as partner.
- Works council: depends. The optimiser itself works on asset data, but control-room dashboards, operator overrides and logs can be suited to monitor staff; §87(1) no. 6 BetrVG then applies. Inform the works council under §90(1) no. 3 when shift and control-room processes change. Public utilities: staff council.
- Data protection: utility-scale data is non-personal; household batteries expose consumption profiles, so involve the DPO, minimise metering granularity and sign an AVV (Art. 28 GDPR); a DPIA is likely for large-scale household profiles.
- AI literacy: support operators and traders in reading forecasts, uncertainty and optimiser output (Art. 4 AI Act), see GUIDE-006.
- Pilot and communication: run in shadow mode next to the existing control on one asset. Typical concern: loss of control over a costly asset; address it with hard limits in the BMS, a kill switch and human approval of strategy parameters.
- Guides: GUIDE-010, GUIDE-013, GUIDE-009.
Risks, regulation & compliance
- EU AI Act: depends on context. A pure trading optimiser is minimal risk; software that is a safety component in the management or operation of critical digital infrastructure or electricity supply (Annex III point 2) can be high risk. Treat dispatch that influences grid stability as potentially in scope and document the classification. AI literacy duty (Art. 4) applies to operators.
- Energy and market rules: REMIT (market manipulation and insider-trading prohibitions, relevant for bidding and withholding capacity), prequalification for reserve products, grid-connection codes (NC RfG), NIS2 and the Cyber Resilience Act for control systems and connected devices, EU Battery Regulation 2023/1542 (state-of-health data and battery passport) [3].
- GDPR: utility-scale data is non-personal; home or household batteries expose consumption profiles, which are personal data. Use data processing agreements and minimise metering granularity.
- Technical risks: thermal/safety events if software overrides BMS limits, adversarial or manipulated price/data feeds, model drift after market changes. Mitigations: hard limits in the BMS, solver-based safety layer around learned policies, shadow mode before live control, kill switch, audit log.
Getting started
- Collect 12-24 months of price, telemetry and tariff data and define warranty and grid constraints in a machine-readable form.
- Build a perfect-foresight benchmark and a simple rule baseline in PyPSA/Pyomo to quantify the possible upside.
- Add probabilistic forecasts and a rolling-horizon optimiser; backtest with realistic market timing and fees.
- Run in shadow mode next to the existing control, compare against actual revenue.
- Decide buy vs. build using shadow results; prequalify for reserve products only after the process is stable.
Sources
- Regulation (EU) 2024/1747 (electricity market design) — https://eur-lex.europa.eu/eli/reg/2024/1747/oj
- ENTSO-E Transparency Platform — https://transparency.entsoe.eu/
- Regulation (EU) 2023/1542 (Batteries Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1542/oj
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- PyPSA documentation — https://docs.pypsa.org/
- OpenSTEF (LF Energy) — https://github.com/OpenSTEF/openstef
- Regelleistung.net (German balancing market platform) — https://www.regelleistung.net/
- HiGHS solver — https://highs.dev/
- PyBaMM — https://pybamm.org/