why_the_s2_approach

Why the S2 approach?

There any many methods and models you could use for utilizing energy flexibility. Why do it the S2 way instead of some other way?

Energy flexibility isn't some physical phenomenon that needed to be modeled. If that were the case, all protocols for energy flexibility would have looked very similar. Instead, coming up with a solution for energy flexibility requires a lot of creativity. If you start with different requirements, or even prioritize them in a different way, you will end up with wildly different models, mechanisms and protocols for energy flexibility.

Unfortunately that means that there are many, conceptually incompatible solutions out there. Comparing S2 to all of them is a challenge. We'll start by explaining what the starting point of designing S2 was.

S2 design principles

These are the design principles that have led to the S2 protocol as it is today.

Energy flexibility from the built environment can only be successful if there is interoperability

todo

We won't settle on one energy flexibility utilization mechanism

todo

A protocol can only be successful if it is easy to understand

todo

Energy flexibility is valuable

todo

A protocol can only be successful if it doesn't tell you what to do

todo

The device is always in charge

todo

Frequently asked questions

These are some frequently asked questions regarding the design decisions of S2.

Can I use S2 to control an aggregated device?

Short answer: no.

The idea of cascading CEMs in quite appealing. A CEM uses S2 to talk to another CEM, that represents itself towards the first CEM as if it was a RM. The second CEM controls multiple devices, or maybe even more CEMs. These architectures are very common in computing science. For example, a directory contains files, but could also contain another directory, which could contain files and directories and so on.

Unfortunately, this doesn't work for S2. One of the main principles on S2 is to remain agnostic for the energy flexibility utilization mechanism. When you want to represent multiple devices in one S2 session, that means you must aggregate them. Aggregation, by definition, means you have to throw away some information. You can do that if you know what your objective is and what is relevant for your objective, and what is not. But within S2 we don't know what the objective is, because we want to remain agnostic towards the energy flexibility utilization system. In other words, we can't throw away information because we don't know what we can throw away. It is impossible to aggregate energy flexibility in such a way that limits your options further down the line.

In the S2 architecture the CEM implementation does know what the objective is. If you want or need to aggregate flexibility, you can do that within the CEM or any of the systems behind the CEM.