Proxy and Aggregator Cloud VENs

What we mean by "proxy" and "aggregator" implementation model for cloud-based VENs, and when and why to use either

3 minute read ∙ Aug 5th, 2021

Cloud-based VENs provide a lot of flexibility in implementation models, with important implications for interoperability and ease of use. One useful piece of terminology for cloud-based VENs is thinking of the VEN as either a proxy or an aggregator.

Defining Proxy vs Aggregator models

Proxy is where the VEN gives the VTN full access to individual devices, so it's role is limited to being a concentrated point of contact between the VTN and devices. For example, events can be targeted to individual devices or sites, and data is reported at the individual site level. In other words, the VTN gets full visibility and access to orchestrate control all the way down to devices.

In the Aggregator implementation model, the VEN owner aggregates load and provides it to the VTN. The aggregation can be one big chunk or multiple groups (e.g. geographic region, load type, etc); the key is that the VTN does not get exposure to individual devices and sites since they are aggregated to some useful level. From the VTN's perspective, it generally doesn't matter if it is a group of homogenous devices operated by an OEM or a mix of devices operated by an aggregator, since they are concerned with the overall characteristics of the aggregation (e.g. how much load is available, for how long, in which regions, etc) rather than what the individual devices are doing.

Flexibility vs Interoperability

The key implication of one or the other model is a familiar one - flexibility vs interoperability.

The proxy model is set up for flexibility - with access to individual devices you can achieve fine grained control and switch groupings on a regular basis if needed. But that comes at the cost of increased complexity and lower interoperability. The VTN can request nearly any type of data and impose device-specific control strategies. This level of flexibility nearly guarantees that different VTNs will come up with different integration requirements, increasing the integration requirements from utility to utility.

The aggregator model is generally better set up for interoperability. Since much of the underlying complexity is abstracted away there are fewer integration variables, so the likelihood that two different VEN to VTN integrations are the same or similar is therefore higher. It also means the VTN does not have to account for all of the different types of devices - they can request a certain amount of load with certain characteristics, and it's up to the VEN operator to figure out the best way of offering that. It pushes the implementation details downstream to the VEN operator.

Ultimately, the choice of which model to use often comes down to where the sophistication lies. Some DERMS platforms are very sophisticated and want to optimize as much as possible, for which they generally need maximum control and visibility over the end devices. They would prefer that VENs act as simple pass-throughs to execute their will. OEMs, however, are getting more sophisticated themselves, and generally want the flexibility to operate their assets on their own terms. They would argue they know their device and customer needs the best, so are best placed to determine strategies to execute load flexibility. As OEMs get more sophisticated, they are likely to push back on the proxy model.

Conclusion

This doesn't mean interoperability is impossible with the proxy model, just harder. There are valid reasons to implement that model, especially when the VTN operator is very sophisticated and the VEN operators are not. While the aggregator model is generally better for interoperability, developing a standardized set of use profiles would benefit the ecosystem for either model, as argued in a previous blog post.