Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite very confusing section on EFI #4

Open
wants to merge 1 commit into
base: development
Choose a base branch
from
Open

Rewrite very confusing section on EFI #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions Architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,18 +10,18 @@ All this variety on both the DSM and appliance level presents *Energy Management

Nowadays most EMS’es are tightly coupled to a particalar DSM approach. This results in a vendor lock-in for consumers. A switch to another DSM approach/service almost always requires the installation of another EMS (hardware box).

The Energy Flexibility Platform & Interface (EF-Pi) is a runtime environment where on one side smart grid applications can be deployed and on the other side appliances can be connected. The EF-Pi provides interfaces to interact with the environment and connect devices and smart grid apps. Part of the interface definitions are the Control Spaces and Allocations.
The Energy Flexibility Platform & Interface (EF-Pi) is a runtime environment (or "platform") and device abstraction layer (EFI). Smart grid applications can be deployed into EF-Pi runtime and communicate with appliances via the device abstraction layer.

EF-Pi aims to create an interoperable platform that is able to connect to a variety of appliances and support a host of DSM approaches. This way the EMS hardware does not need to be changed when a consumer switches from one service to another. At the same time the Energy Flexibility Platform & Interface makes it easier for service providers to introduce new services, since they do not have to provide the EMS hardware to their consumers to go with it.
EF-Pi aims to create an interoperable platform that is able to connect to a variety of appliances and support a host of DSM approaches. This way, the EMS hardware does not need to be changed when a consumer switches from one service to another. At the same time the EF-Pi makes it easier for service providers to introduce new services, since they do not have to provide the EMS hardware to their consumers to go with it.

## High-level design
![](hourglass.png)

The Energy Flexibility Platform & Interface is the connecting part between appliances at the home of the consumers at one side, and the (smart) energy grid on the other side. Appliances of different vendors can implement functionality which can be used to choose when and maybe how to start and use certain energy consuming or energy providing appliances. Developers of EF-Pi are responsible for providing functionality which connects these parts. Protocols are used to communicate with appliances within appliance drivers. Smart Grid applications need a model of the appliance they are paired with, this is the Control Space and is generated by the appliance driver. The appliance driver uses a self-chosen communication protocol to communicate with the appliance itself. At the physical level, this could be Zigbee, Z-Wave, PLC, WIFI, Ethernet, propriety, etc. It is provided by the manufacturer and allows for mix & matching of protocols.
The EF-Pi connects consumer appliances on one side, with the smart energy grid business logic on the other side. Smart grid applications interface with EFI device abstractions implemented by appliance drivers. The EFI largely takes the form of a "Control Space" generated by the appliance driver. The appliance driver will use an arbitrary communication protocol to communicate with the appliance itself. At the physical level, this could be Zigbee, Z-Wave, PLC, WIFI, Ethernet, propriety, etc.

With the current Control Space of a device, Smart Grid Applications can determine the usage profile of the devices, i.e. when a device should start or stop. The application then makes an Allocation and if there is any energy flexibility available, it should be listed within Allocation. The appliance driver receives the Allocation and based on it can make a decision what is the optimal way to control the device. In this decision the user preferences are taken into account.
With the current Control Space of a device, Smart Grid Applications can determine the usage profile of the devices. For example when a device can start or stop. The smart grid application then makes an "Allocation" and if there is any energy flexibility available, it should be listed within Allocation. The appliance driver receives the Allocation and based on it can make a decision what is the optimal way to control the device. In this decision the user preferences are taken into account.

It is not the device that is modelled but rather its energy flexibility. From this a real device can be connected and used to perform the communication between the derived class and its device. In our experience four models are sufficient enough to cover all device types. These classes are called Control Spaces and are described in Table 1 below.
It is not the device that is modelled in EFI, but rather its energy flexibility. From this a real device can be connected and used to perform the communication between the derived class and its device. In our experience, four flexibility models are sufficient to cover all device types. These flexibility models are called Control Spaces and are described in Table 1 below.

Control Space | Description | Examples
--- | --- | ---
Expand Down