Europe’s energy system is being rebuilt around PV plants and wind farms, and they don’t follow a rigid schedule. Solar peaks at midday, wind comes and goes, demand follows its own curve, so the grid increasingly needs somewhere to put energy when there’s too much, and pull it back when there’s too little. Battery plants (BESS) are being built more and more for that purpose, and it’s happening fast.
Every one of these plants — and every solar farm and wind farm beside them — needs a SCADA system: the layer that lets operators monitor and control the asset, keeping it safe and available for the energy market.
Increasingly, the platform that layer is built on is Ignition. Unlimited-tag, unlimited-client licensing, native MQTT and IIoT tooling, and web-based Perspective visualisation make it well suited to sites that are enormous, data-dense, and built to be replicated.
For battery, solar and wind operators, Ignition has become the default. So much so that Ignition is now considered critical infrastructure.
Building the SCADA isn’t the hard part, though. Designing it so it works at the magnitude these sites reach, and keeps working as more sites are added, is the hard part. That’s what this project was about.
The client and the ask
The client is a European battery-storage operator we’d already worked with on earlier projects. They were building two new sites and asked us to deliver the SCADA system for both, on Ignition.
We’ll call the sites P1 and P2.
P1 is the large one: more than 300 MW, the largest plant we’ve ever dealt with.
P2 is smaller, at 80 MW.
Same client, same platform, two very different sizes.
The challenge
From the outside, a battery site is a row of containers. From a SCADA point of view, it’s an ocean of data with a very particular shape, and the shape is what makes it hard.
A site like this is made of repeatable units. We’ll call each one a block: a grouping of battery containers and inverters that behaves as a single unit of the plant.
The data produced by each block comes in two kinds:
- Operational data — the signals operators actually watch: inverter status, switchgear, metering, the health summaries that say how the asset is behaving right now.
- Battery-cell data — temperatures, voltages, states of charge, cell by cell — which is several times larger in volume, matters enormously for battery health and warranty, but doesn’t need to be watched second by second the way the operational signals do.
Across the two sites, that’s hundreds of thousands of live data points. Three problems fall straight out of it:
1. The two kinds of data have completely different appetites. Operational data has to be fast and always available. Cell data is enormous but lower priority. They have to be split.
2. It has to grow without being rebuilt. If the architecture only works at one size, it’s the wrong architecture. It has to scale from one block to dozens on the same pattern.
3. It has to live on the network that already exists. The sites were already designed around an IT network ring structure. The data architecture had to map onto that ring.
And underneath all of it: it can’t go dark. Redundancy here isn’t a nice-to-have; it’s the point.
Architecture: How we thought about it
The hard part of a project like this is the architecture — deciding how the data moves, where it’s split, how the whole thing maps onto the physical site and the network, and how it grows. This is the part clients most often need help with, and it’s where we spend our thinking.
For P1, three decisions shaped everything:
- One block = one node. Load distribution, data routing, the size of the message broker, the way the system maps onto the network ring — all of it is defined per block. Once the pattern works for one, it works for a dozen, and for dozens, by repetition rather than redesign. That single decision is what makes the architecture scale, and what let the same blueprint serve both a large site and a much smaller one.
- Separate the two data worlds from the start — a fast lane for operational data, a separate path for the heavy cell data. The important signals never wait behind the bulk ones.
- Treat redundancy and the existing network ring as fixed inputs, not afterthoughts — the design begins from them.
What we built
At the edge, close to the containers, sit Ignition Edge IIoT gateways. Each one handles blocks and owns one slice of the field. They map onto the network rings, so the software layout mirrors the physical one. Each publishes its data using MQTT Sparkplug B — a lightweight, report-by-exception protocol built for exactly this: many devices, many tags, only ever sending what’s changed.
All of those edge gateways report into a central Broker gateway, the MQTT hub for the whole system.
From there the data splits two ways, and this split is the heart of the design:
- The backend gateways are connected to the Broker. Each subscribes — via the MQTT Engine module — to its own portion of the field, so load is spread evenly instead of piling onto one machine.
- In parallel, the Event Streams module subscribes to the tag-change events and submits them to Kafka for historisation. Pushing the heavy historical write load onto purpose-built streaming infrastructure keeps it off the operational gateways — so storing the ocean of cell data never slows the signals operators are watching.
- On top sits a single Frontend gateway. It connects to every backend through remote tag providers, which gives it the full picture, and serves it to operators through Ignition Perspective sessions in the browser. Operators get one coherent view; the heavy lifting stays hidden underneath.
Every gateway — Edge, Broker, Event Streams, Backend, Frontend — was built with a redundant counterpart. If one fails, its partner carries on.
Beyond the architecture, the details are what make it usable:
- Tags and structure. A site this size is unmanageable as a flat list, so everything is built on standardised UDTs following the agreed-upon naming conventions, with full metadata — units, engineering limits, source, description.
- Alarming. Alarms on the tags that matter, with defined thresholds, priorities and classifications, and alarm data written through to the database.
- Security. Roles and access defined across every gateway — Administrator, Owner, Service Engineer, Engineer, Operator — down to component, view, action and tag level, so people see and touch only what they should.
- Languages. A built-in language selector, because the people operating these sites don’t all work in the same one.
And as for our work and cooperation, we made sure we created a safe place to build. Separate development, test and production environments, so changes are proven before they ever touch a live site. Build a prototype, get it approved, then wire in real data — never the other way round.
The outcomes
Operators get real-time visibility of every container, inverter and cell, in their own language, with access scoped to their role.
The enormous volume of cell data is captured and stored without ever choking the operational signals the asset depends on to react.
And because everything is defined per block on standardised structures, the next site isn’t a new project — it’s more of the same work.
Why this matters for you
Every battery plant needs a SCADA system. So does every solar farm and every wind farm. The technology to build one isn’t the scarce part — Ignition gives you the platform, and the field is full of integrators who can stand up a system that works on day one.
What’s scarce is the architecture work. Or rather, a trustworthy architecture work. These sites are data-dense, they have to stay up, they have to map onto networks that already exist, and — because operators rarely build just one — they have to scale without being rebuilt each time. The decisions that determine whether a system survives contact with production, and with the next site, are made early, in the architecture, long before the first tag is configured. That’s the part that’s genuinely hard, and it’s the part clients most often need a partner for.
It’s also what we do. We work exclusively on Ignition, which means we’re not learning the platform on a client’s site, we’re bringing patterns we’ve already proven. For an operator building out a fleet of plants, that’s the difference between a SCADA system and a SCADA system that scales… plus the peace of mind of working with friendly professionals who have done this before.
