INTERVIEW: ‘A VPP is only as good as its weakest device integration’

A battery storage site can contain equipment from several manufacturers, each with its own protocols and ways of reporting data. Combine that across multiple sites, the exponential headache can compound. While standards and regulations often exist to provide guidance, individual implementations differ. And before a site controller or virtual power plant can put batteries to work, something has to make it speak the same language.

IOTech is a supplier of that software layer; its customers embed it in their own systems, with deployments ranging from small devices alongside individual assets to servers coordinating an entire site.

According to Andy Foster, the company’s chief product officer and co-founder, its software is used in one major storage provider’s fleet covering approximately 20 GW worldwide.

Foster spoke with ESS News about where the software runs, how it operates at the ‘edge’ or on-device, the division between local control and cloud-based optimization, and key engineering challenges.

ESS News: To start, what is IOTech’s software, and how and where does it run?

Andy Foster: We make edge software, the layer between the physical equipment and everything above it. On an energy site, that equipment is inverters, battery management systems, power conversion systems, and meters, usually from several suppliers, each speaking its own protocol.

To give you a sense of scale, our edge software is an integral part of the latest battery storage solutions from one of the world’s largest grid-scale storage providers. Across that fleet, there’s currently about 20 GW of capacity under management worldwide, and it’s growing at an increasing pace.

Most of the distributed energy resource (DER) sites where our software is deployed use a federated architecture, and it works in two tiers.

At the bottom are low-cost edge devices, typically small Arm-based compute units, sitting right next to the assets. They handle data acquisition and control for the equipment they’re attached to, and they normalize the data into a common model. On a large battery storage site, there can be thousands of these units.

They publish that normalized data onto a high-speed message bus. It’s then aggregated on a much smaller number of more capable machines, typically an x86 industrial PC or on-premises servers. Those host the site controller and site-wide services such as an edge data historian or an OPC UA server for supervisory control and data acquisition (SCADA) and the energy management system (EMS). IOTech edge software enables interoperability across all edge tiers and also with the cloud.

Control stays close to each asset, with no single bottleneck, and you still get one consistent site-wide view. On top of that sits fleet management: our customers deploy, configure, and update thousands of nodes across many sites centrally, without sending an engineer out.

Why does this have to happen at the edge rather than in a data center? Where does an on-site server fit?

Our view is: decide centrally, execute locally. Forecasting, trading, and portfolio optimization belong in the cloud or a data center. Some things have to happen on site, though.

The first is speed. Fast frequency services need a full response within about a second. In our architecture, acquisition and control happen at the asset, on those small Arm units, and site-level coordination happens on the site controller running on the same edge network. You can’t guarantee that timing through a round trip to a remote data center.

The second is resilience. If the site loses its external link, it still has to respect grid limits and protect the battery. Because everything that matters for control is on site, it keeps running. The federated design also means one failed node affects one asset, not the whole site.

The third is data volume. Thousands of nodes produce high-rate telemetry, and it’s far more efficient to normalize it at the asset and aggregate it on site than to ship it all raw.

On a large site, the on-premises server tier is part of the edge. What matters is that the control path doesn’t depend on anything off site.

How does your technology serve a virtual power plant (VPP)?

A VPP is only as good as its weakest device integration. The platform sends a dispatch instruction, and then thousands of devices from different manufacturers have to respond predictably, and you have to be able to prove they did.

We provide the layer underneath. At each asset, our edge nodes speak the device’s native protocol, enforce local limits, and execute commands. At site level, the site controller and services such as the historian and the OPC UA server present the whole site as one standard, well-behaved resource, with clean telemetry the VPP can use for settlement and verification. The same pattern scales down: on a home or small commercial site, a single small node does both jobs.

Put simply, the VPP platform decides what the fleet should do, and we make sure each site, and each asset within it, actually does it.

What’s the biggest engineering challenge?

Heterogeneity at scale. Every manufacturer, model, and firmware version reports slightly differently, and a firmware update can quietly change what a register means.

In a federated architecture, that’s multiplied by thousands of nodes on a single site, and many sites per customer. So the hard part isn’t connecting to one device. It’s running a large distributed system that behaves predictably in real time: consistent data models across every node, fast and reliable messaging, accurate timestamping, and safe software updates across thousands of nodes without disrupting operations.

That’s why we invest in profile-driven configuration rather than custom code, lean deterministic runtimes for the small nodes, and centralized fleet management. We’re also using AI at the edge to automate the mapping of device data to standards like SunSpec, which has traditionally been slow, manual work.

What compute is required, and is it on every stack or in the battery energy storage system (BESS) server room?

Both, in two tiers.

At the asset level, it’s low-cost, small Arm-based compute units that sit with the equipment: alongside the inverters, battery management systems, power conversion systems (PCS), and meters. On a large battery storage site, there can be thousands of them. Our runtime is written for exactly that class of constrained device.

At the site level, it’s a much smaller number of more capable machines in the control or server room, typically an x86 industrial PC or on-premises servers. They host the site controller, the data historian, the OPC UA server, and any customer applications.

We’re hardware-agnostic. We supply the software, and the customer or system integrator chooses the hardware to fit their design. The rule of thumb is that compute scales with the number of data points and sample rates, not with megawatts.

Is there room for a conversation about efficiency, or is it more about performance?

Both, but deterministic performance comes first: if you miss a response window, you lose revenue or breach a grid obligation. Once that’s guaranteed, efficiency matters a lot, and the federated architecture makes it matter more.

When you have thousands of units on one site, the per-unit numbers count. That’s why the asset tier, again, uses Arm devices, typically drawing a few watts each, rather than PCs. And it’s why we keep our runtime lean: it’s compiled, not a heavy general-purpose stack, so it fits on the smallest, coolest hardware that does the job. The heavier x86 compute is limited to a handful of machines at site level.

Even with thousands of nodes, the total is a small fraction of a large site’s auxiliary load for cooling and battery management. The bigger efficiency gain is operational: better data means faster fault detection, less downtime, and fewer site visits.

Which company pays IOTech, how does it work, and what does it cost?

We’re a software supplier to the companies that build and run fleets. Most of our customers are storage and solar system makers and integrators, who embed our software inside their own product under their own brand.

It’s typically licensed per edge node, with volume pricing that reflects the fact that a single large site can have thousands of nodes. It’s available by subscription or as a perpetual license with support. In some cases, instead of per-node licensing, the customer pays IOTech a royalty based on the site’s generating capacity, per MW of installed capacity. That ties our revenue to the scale of the assets we help run rather than to the hardware design. Central fleet management is priced by the number of nodes managed.

Per site, it’s a small fraction of the hardware and commissioning cost, and customers usually recover it through faster integration and fewer site visits.

This interview has been lightly edited for clarity.