Designing a Data Model for Communication in a Home Energy Hub

Published: Fri 20 Jun 2014
A blog entry by Sasha Bermann

Contributed by:

Sasha Bermann
Chief Dissemination Officer
VaasaETT

Sasha Bermann's Blog

The eBADGE consortium is currently conducting a project pilot to design an early prototype, to be further developed at a later stage, for a data model for communication between all relevant stakeholders in a home energy hub – which is what eBADGE further down the line will create as part of the project.

 

The Pilot

The required communication in the eBADGE pilot can be divided into multiple levels where different entities communicate:

1) energy resources, energy storage, smart meters, home energy hubs (gateways), VPPs, microgrids, DSOs, energy providers exchange messages with home energy usage profiles, VPP activation commands and similar,

2) VPPs and other BSPs (balancing service providers), e.g. traditional generators, send bids to their TSO, who send activation commands back,

3) in an international balancing market based on the TSO-to-TSO model, TSOs forward bids to a common merit order list and coordinate balancing energy allocation from this list. No messages pass the level border (for example, the home energy hub never communicates directly with a TSO). Each higher level contains less message volume but must be more resistant to attacks and failures. In this document we will refer to the first level as the home energy hub (HEH) level and to the remaining two levels as the market level.

 

Ideally, all levels can be covered using the same technology. However, the actual communication channels must be isolated so that a potential attack on a home energy hub does not pose any threat on the market level.

In the eBADGE pilot the maintenance of the common merit order list and the coordination of balancing energy allocations from this list will be simulated through a central market operator. The role of the latter also includes the process of selecting the optimal bids in any given moment not only with regard to its price but also its dispatchability to the target area given the capacities and flows in the network. To encompass this complex role, we refer to this central market operator as a super-TSO. The main purpose of the market level and the simulator is to demonstrate the regulatory and economic feasibility of an integrated balancing market and the increased social welfare that such a market would provide. The implementation challenges beyond this pilot are mostly regulatory and information technology is secondary. On the other hand, the HEH level of the pilot also strives to demonstrate the technical feasibility of using a large number of households or small businesses as demand response resources. It is therefore conceivable that commercial projects following this pilot will strongly consider re-using the HEH-level technology developed here, while for the market level this is far less likely. Consequently, when one technical choice is optimal for the HEH level and another for the market level, we will most often choose the former over the latter.

 

 

Home Energy Hub Level Requirements

The basic business idea is a VPP aggregating the demand-response potential of many end-users (through HEHs) and selling it as balancing energy on the market. More elaborate scenarios are being developed in WP4 where, for example, telecommunication companies may offer data acquisition from HEHs and data storage, and DSOs and energy providers also take part in end-user-level demand-response. However, for this version of the data model, we shall restrict ourselves to the basic case. Thus, this level of the data model defines how the metering data is communicated from the HEH to the VPP or other relevant entity, how the activation commands are communicated back, and various status inquiries/reports. We estimate that the demand-response potential of a single home is in the order of 1 kW, so thousands of them must be aggregated to provide megawatts to the balancing energy market. Thus, the data model must be scalable to at least thousands, preferably tens of thousands HEHs per VPP. Since two VPPs can (and most often should) use completely isolated channels to communicate with their HEHs, the total number of VPPs is not the limiting factor for the HEH-level communications. The HEH has to be able to send the following reports:

• Power usage and generation profile for the whole building,

• Power usage and generation profile for each device (load, generator or storage) that is measured individually,

• Anomalous events, such as power outages, overvoltages,

• Detailed, high-resolution profile (U, I, P, Q, S, harmonics; or a subset of those if not all are being measured),

• Predicted load and generation profiles for the smart devices that are able to predict their usage (for example, after a user has set a washing machine cycle, the usage for the whole cycle could be predicted easily),

• HEH status,

• Capabilities of the HEH and of individual devices.

These reports are sent either on request or periodically, where the period and other parameters must be remotely configurable.

 

The VPP must be able to control the HEH and the appliances through the following:

• Activation commands for individual devices (i.e. increase/decrease load or generation on the specified device),

• Activation commands for the whole household/business, where it is up to the HEH and/or the user how to achieve it,

• Tariff (pricing) updates through which the VPP can motivate/boost/incentivize demand response.

 

The data model must allow the HEH to reject or modify activations. However, depending on the contract between e.g. the home user and the VPP, this may only be allowed in certain limited cases.

 

 

 

Market Level Requirements

The market-level of the data model will be used to collect bids from BSPs at the TSOs and to send activation commands to the BSPs. On the international market, the model must also cover sharing bids of each TSO with the super-TSO and coordinating the cross-border balancing mechanism. Scalability to tens of TSOs and thousands of BSPs must be ensured.

 

This part of the model is not intended to replace the existing protocols used to allocate cross-border capacities, control the transmission grid, inform about failures in the energy grid etc.; rather, it should contain just the messages necessary for the implementation of the eBADGE pilot. In particular, the market simulator developed in WP2 will be the pilot entity representing the central market operator (so called super-TSO) and the pilot VPPs will act as the BSPs communicating with the simulator. The BSPs must be able to, regardless of whether the balancing energy market is national or cross-border:

• Send bids to their TSO,

• Receive activation commands from their TSO and acknowledge or reject them. In an international market operated by a super-TSO, the latter must also be able to:

• Receive forwarded bids from all TSOs in order to build a common merit order list,

• Receive a balancing request from a TSO that detects an imbalance in its area, i.e. a requests to activate bid(s) from the common merit order list,

• Send a bid activation order to the TSO that the bid came from, who then forwards it to the BSP,

• Inform the imbalanced TSO whether their request was granted or not,

• It must be possible to express imbalance netting.

How the super-TSO is informed about the network state (cross-border capacities, flows, etc.) is beyond the scope of this data model. In the eBADGE pilot the network state will be simulated by the market simulator while in a production environment existing communication protocols would most probably be used to exchange network state data.

 

Preliminary Conclusions

The requirements analysis has shown that the communication and data model can be divided into two levels:

• HEH-level, where the metering data is collected, individual demand-response commands are sent, etc.,

• Market level, where the BSPs send balancing energy bids and the TSOs activate selected ones as needed.

 

The analysis of existing data and messaging standards has shown that on the HEH-level, the eBADGE requirements and the OpenADR 2.0 standard are not aligned closely enough to warrant implementation of this standard. All other standards from the Smart Grid domain are even less appropriate for reasons of inextensibility, lack of fitness for our objectives, or dependency on inbound connectivity into the home energy hubs. On the market level, no suitable standards exist either. The existing markets, such as the Slovenian intra-day market, use the data models and exchange formats defined by the respective vendors of the market software. After the definition of a new data model, JSON encoding was chosen as a suitable compromise between compactness, human-readability, interoperability and extensibility. The data model will be further developed and specified as the project progresses and more research will be published on the matter.

 

eBADGE in brief

 

eBadge is an EU funded FP7 project with the objective of proposing an optimal pan-European Intelligent Balancing mechanism, which is also able to integrate Virtual Power Plant Systems by means of an integrated communication infrastructure that can assist in the management of the electricity Transmission and Distribution grids in an optimized, controlled and secure manner. The project has a duration of 3 years in total and is currently in the 2nd year.

 

eBadge’s aim of balancing the European electricity market brings great value to Europe because it enables the market to function more efficiently and with less wastage. In addition to that it also holds the potential for lowering the costs of balancing services throughout Europe to the benefit of European business and civil society alike. Thus eBadge leads the way to a sustainable Europe – both when it comes to keeping costs as well as resource spenditure at reasonable levels. eBadge empowers consumers to participate and engage in the energy market of tomorrow – it supports the transition from being a consumer to being a prosumer.

 

More information about eBADGE: http://www.ebadge-fp7.eu