Architecture for residential flexibility
Several architectural approaches are possible for designing the control chain. No definitive architecture has been selected for the Netherlands –or for Europe– at this time. The goal of this project is to develop limited message sets for selected protocols that are applicable across different architectural models.
The reference diagram illustrates functional communication between HEMS and devices. It intentionally does not differentiate between local and cloud-based control models. The HEMS serves as the central component and must support four protocols (in alphabetic order: EEbus, Matter, OCCP and S2). Devices may connect using one or more of the four selected protocols.
Many of the existing FEIDS in the market use a Modbus protocol (Modbus TCP or RTU). Modern HEMS are unlikely to support Modbus directly, because of drawbacks to the protocol. Devices using Modbus should instead interface with the HEMS via one of the supported protocols (EEBUS, Matter, OCPP, S2). Modbus is expected to be used only locally and translated at the device level, ensuring that all HEMS-facing communication follows a more secure and interoperable protocol.
To illustrate local versus cloud flows, the following sections present several implementation variants.
C.1 Local HEMS
1a.
The first implementation scenario is based on a fully local HEMS setup.
1b.
A specific variant of this involves communication from the local HEMS to a local control system managing one or more energy-intensive devices.
Another implementation scenario involves a cloud-based HEMS architecture. Two control routes are defined below.
C.2 Cloud-based HEMS
2a.
Communication from the cloud-based HEMS to a local control system that manages the devices.
2b.
Direct communication from the cloud HEMS platform to the individual device.
