Architecture

Architecture overview

Energy management is a complicated task, involving many aspects. For example, an energy management system might need to forecast PV production, heat usage, EV usage, but also might think about energy tariffs and the capacity of the grid connection. In order to achieve optimal interoperability and to simplify implementation, the S2 architecture splits the energy management system in two logical parts: The Customer Energy Manager (CEM) and the Resource Manager (RM). The CEM and the RM communicate with each other through the S2 protocol.

• The RM represents a flexible device and informs the CEM on how it is flexible. A RM communicates with only one CEM. The CEM sends instructions on how the device should behave, within the flexibility parameters offered by the RM. The RM does not know why the CEM wants the device te behave a certain way.
• The CEM represents the building and decides how to use the flexibility offered by the RM. A CEM typically communicates with multiple RM's, one for each flexible device. A CEM decides how it wants a flexible device to behave, within the flexibility parameters offered by the RM. It does not know exactly what kind of device the RM is controlling.

A device that is flexible typically has some task it needs to perform (e.g. keep the building warm inside, charge the EV before a certain deadline), but is flexible in how it performs the task (e.g. do it quickly with a lot of power or do it slowly with less power). You can think of S2 as a menu in a restaurant. The RM decides what is on the menu. The CEM selects an item from the menu. The RM is fully in control of the device, since the RM creates the menu. If it doesn't want to do a certain thing, it shouldn't put it on the menu. The CEM can only pick items that are on the menu. The CEM knows the reason why it favors one item over the other; the RM doesn't know and doesn't care.

S2 is designed with a service oriented architecture in mind. This means that S2 defines how a CEM should communicate with a RM and what kind of responsibilities they have, but it doesn't define how they should do it. For example, a CEM or a RM implementation could be very simple, but also very advanced. They could do all the work themselves, or they could connect with other systems to gather information or offload certain tasks. They can communicate with whatever system using whatever protocol. The S2 architecture extremely flexible in order to be able to accommodate as many situations as possible.

Resource Manager (RM)

To be precise, the RM doesn't necessarily represent one device, but one source of flexibility. Typically that is one device (e.g. a dishwasher), but it could also be multiple devices working together (e.g. a heating system consisting of a heat pump, buffer, pumps and valves). All devices connected to a RM should be able to be controlled independently from other devices in the building. If there are dependencies between two devices (e.g. two devices cannot run at the same time), they should be represented by one RM.

TODO Comfort

TODO Knowledge about the device

A RM is always responsible for user comfort, safe operation and durability of the device. The CEM merely sends requests to the RM (which we call instructions), that the RM can accept or reject. When the CEM sends instructions that would lead to discomfort for the user (e.g. it wouldn't charge the EV before the deadline) or unsafe operation of the device (e.g. it would turn on the heat pump when it already reached a critical temperature), the RM must reject these instructions and send the right instructions to the actual device. A malfunctioning CEM implementation may never lead to discomfort, unsafe situations or unacceptable wear to the device.

TODO Legacy protocol

Customer Energy Manager (CEM)

TODO

• Local or external
• Objectives
• Typically also connects to smart meter

Deployment

The RM and the CEM are merely software modules. In order to support as many situations as possible, the S2 architecture doesn't define how they should be implemented and where they run physically.

A RM could, for example, be implemented...

• On the device itself. This means the device must have a network connection and must have sufficient computational power to fulfill the responsibilities of a RM.
• On a dedicated gateway device for the specific device or brand
• As an app on a dedicated Energy Management computer inside the building, which could also host the CEM
• In the cloud environment of the device manufacturer

From a functional point of view it doesn't matter if the CEM or RM is running locally in the building or running externally and connected via Internet. However, for privacy, robustness, responsiveness or ease of use reasons you might want to favor one option over the other.

• Privacy: Some people won't like it if their data is stored in the cloud.
• Robustness: A local network connection is typically more reliable than an Internet connection. If you rely on energy flexibility for the operation of the local power grid this might be an issue.
• Responsiveness: If the energy flexibility use cases requires quick responses, an Internet based solution might not always suffice.
• Ease of use: People might prefer connecting through the cloud in order to avoid setting up hardware locally.
• Costs: Dedicated energy management hardware is costly and requires power. This can be avoided by connecting devices directly to the cloud.