Our concept

The Hebes platform aims to facilitate the seamless integration and control of different Internet-enabled devices under a set of common goals. A characteristic case we aim to support is the integration of the existing and future energy assets of consumers under the unifying goals of increased energy self-consumption, energy efficiency and demand response potential.

Our main premise is that technology integration requires more than the ability to share different data encodings between the involved systems. It requires primarily the ability to functionally compose different device or subsystem interfaces into an integrated model that can be monitored, continuously updated and controlled.

And this premise has guided the design of the Hebes platform, so that from its users’ point of view, it acts as a cloud-based service that enables them to integrate their technology assets by:

  • Utilizing the assets' connectivity capabilities to maintain a secure two-way communication with them,
  • Identifying and continuously updating an integrated model of the respective devices’ function and capabilities, and
  • Producing specially tailored controllers that coordinate the operation of these assets towards user-defined goals, such as efficiency, comfort, safety.

Our methods

Our platform is able to learn the dynamics of a system - possibly composed by many different devices, while at the same time devising control signals for its operation. To this end:

  • We start by collecting data from the connected system and employing iteratively refitted local linear models to drive its operation. The two advantages gained from the derived linear–quadratic–Gaussian (LQG) controllers are that: a) we can drive the system without having a mature global policy law, and b) they can be easily stabilized while we still do not have a full picture of the system’s dynamics.
  • We employ a risk-aware approach to explore the state and action spaces that is based on monitoring user-defined metrics of safe operation (such as speed, distances from obstacles, voltage or temperature levels).
  • At the same time, the state and control data collected is used for training a Gaussian Process state space model (GPSSM), so that to capture the system’s dynamics. As the GPSSM becomes better and better in representing the actual system, the whole process transitions from being model-free to being model-based.
  • The GPSSM will now guide the exploration part of the algorithm; it is used for filtering out data that do not provide new information to the model, as well as for exploring the regions of the model that have still considerable uncertainty.
  • The model-free approach is then re-introduced into the process with the goal of addressing possible bias that may exist in the GPSSM.

Our Infrastructure

  • Our platform communicates with devices through MQTT, using the EMQ (Erlang MQTT Broker).
  • It also communicates with developers through a simple RESTful API.
  • The model serving part of our functionality is based on zerorpc.
  • The model training part of our functionality is based on an in-house developed framework that we internally call hakka and we plan to open-source when the beta testing phase is over. The name hakka comes from "hebes" and "akka", the JVM-based actor framework. This is because we took a lot of akka’s concepts and ideas, and developed a Python framework that combines actors with coroutines. The main rationale for this combination is that actors make it easy to design asynchronous and resilient data processing pipelines, while coroutines make it easy to coordinate stateful fan-out and fan-in patterns (fan-outs emerge when starting and awaiting new coroutines, and fan-ins emerge naturally when coroutines return and the data flow is reversed).
  • The algorithms have been developed by using mainly the capabilities of MXNet.

Our targeted market

The proposal for a Directive of the European Parliament and of the Council on common rules for the internal market in electricity requires that Member States will ensure that consumers are entitled, on request, to a dynamic electricity price contract by their supplier.

This implies that consumers would first pursue the technological capabilities that enable demand flexibility, and then choose to expose themselves to dynamic prices. However, it is unlikely that consumers will invest in new technological capabilities having demand response (DR) as their primary goal. On the contrary, it is reasonable to assume that consumers would adopt these technologies according to a value stemming from:

  • Increased consumption of electricity generated onsite from renewable resources. When self-consumption is economically rational, consumers may invest in technologies that increase their demand flexibility as a way to increase the proportion of the self-produced electricity they consume.
  • Increased energy efficiency. In many cases, flexibility is utilized by applications that aim primarily to increase energy efficiency. As an example, functionality that utilizes the flexibility of demand for thermal energy underlies the intelligent recovery operation mode of most sophisticated thermostats.

The aforementioned support the argument that a viable approach to the engagement of consumers in DR programs is through technology solutions that allow them to exploit the flexibility potential that is inherent in the technology assets they own, as long as:

  • The goals of increased energy self-consumption and energy efficiency are not sacrificed.
  • Their participation in DR programs is as seamless as possible.

We believe that the Hebes platform is perfectly suited for this challenge. The reason is that our Control-as-a-Service scheme makes it possible to develop control schemes that safeguard that energy efficiency and energy self-consumption are always put first, while conditionally maximizing the degree of change compared to the baseline consumption that is achievable by a DR event during a given time period. In this way, we can actually embed DR into the daily operation of the connected systems and devices.

Our research priorities

To be actually useful, the Hebes platform must enable its users to monitor and fully control their devices through a unified graphical interface. This means that – at least for in-building systems – integration requires effectively combining two different paradigms: one that is based on automated control with minimal user involvement and one that is based on users devising automation rules in the form of “if this then that”, and then deciding themselves when to set them in effect. The latter is the current automation paradigm, and thermostat scheduling is a good example.

Accordingly, we focus our research priorities on enhancing our platform to systematically adapt the control of connected devices to the users’ preferences. To this end, we aim to utilize the user-defined settings as a way to appropriately refine the corresponding control functionality, as well as to identify the extent to which users are satisfied with the control actions.

Subscribe to receive news on our beta testing phase