A distributed ledger based platform for community-driven flexibility provision

Abstract

In this paper we propose and analyze a community-driven platform for flexibility provision based on a distributed ledger. We introduce and analyze the platform for the use case of a self-organized decentralized virtual power plant consisting of a local community of individual prosumers with photovoltaic-storages located on a low voltage feeder. Like a virtual power plant, it aggregates small-scale assets and is able to provide ancillary services in the form of active power provision to the electrical power system. However, the decentralized virtual power plant provides a direct flexibility market access of the distributed assets without the need for a third party. Thus, balancing group managers or system operators can directly interact with the distributed assets in an aggregated way without the need for an aggregator. The solution approach uses a heuristic algorithm for the coordination combined with a distributed ledger and democratic consensus within the community.

We propose the concept in detail, describe the prototypical implementation based on a consortium Ethereum blockchain and discuss results of the proof-of-concept. Our numerous test runs with up to 20 participants showed that the coordinated flexibility provision, energy sharing and according financial settlement works in practice, but would need an upgrade concerning the smart-meter hardware for an implementation in the field. We analyze the impact of the coordination interval on the community self-sufficiency and determine that one minute intervals are enough to reach 96% of the optimum. We evaluate the storage and communication effort and conclude with suggestions for future improvements and other possible applications of the decentralized platform like aggregated flexibility coordination between balancing group managers and system operators.

Background

Traditionally, the electrical power system (EPS) is designed, controlled and operated hierarchically and centrally in order to work reliably. However, the Energy Transition towards renewable energy sources (RES) is characterized by an increased volatility and decentralization of the supply. Especially as conventional power plants are dismantled, this leads to an increased need for bottom-up flexibility in order to be able to operate the EPS reliably. This is underlined by the current costs for EPS stability and congestion management, which are on a record high in Germany (BDEW Bundesverband der Energie- und Wasserwirtschaft e.V 2018).

At the same time more and more distributed assets are installed in the EPS, which are potentially able to offer such flexibility, like energy storage systems (ESSs) in private homes or battery electric vehicles (BEVs). The additional yearly construction of photovoltaic (PV)-plants and PV-storages in Germany shown in Fig. 1 underlines this for ESS. Considering vehicles, governments all over Europe aim to move towards a higher share of electric cars on the roads. However, most of these distributed assets are owned by citizens or small businesses and are not controlled centrally nor have access to a flexibility market. Thus these flexibility sources cannot be activated as long as they are not pooled in a virtual power plant (VPP).

Fig. 1

Yearly additional construction of PV-plants and PV-storages in Germany (https://www.foederal-erneuerbar.de/startseite)

Many distributed assets can be empowered to provide ancillary services to the power grid by pooling them (Schlund et al. 2017b; Steber 2018). Pooling assets connected to one low voltage feeder within a local area results in energy communities, empowered to provide ancillary services locally. Such communities can act as aggregated cells according to the cellular concept (Benz et al. 2015). A known way to achieve such behaviour is using a VPP with a centralized information technology (IT) structure.

However, the expected revenue of such a local energy community is small and has to be shared between the VPP provider and the participants of the community, which might not be economically feasible for both. In addition, the goals of an aggregator are not always in accordance with the goals of the household as a participant. Citizens might not agree to let an aggregator directly remote control their assets, which are usually inside their own houses. This issue is strengthened as transparency about what exactly the assets are used for is not necessarily given for the participants of a VPP. Furthermore, controlling many distributed assets via a centralized VPP offers a central attack point on the critical infrastructure. For these given reasons it might be interesting to investigate alternative possibilities, which enable a direct flexibility market access for distributed assets without the need for an aggregator, where system operators or energy suppliers can directly interact with self-aggregating distributed flexibility assets. One way to solve this problem is using distributed ledger (DL) technology.

In this paper we propose and analyze such a fully distributed alternative concept to a VPP. Basically, it is a decentralized flexibility platform, which can connect parties in need of flexibility directly to aggregated flexibility sources without any other involved party. The concept is referred to as a decentralized virtual power plant (DVPP) in the following. We answer the question how to self-organize and financially settle such a local energy community in a fully distributed way by a proof of concept based on DL technologies (Wattenhofer 2017). We contribute to the state-of-the-art by proposing a new method for such self-organization and evaluating its advantages and disadvantages.

Therefore, the paper is structured as follows. At first, related work is presented before the conceptual approach and the implementation are described. This is followed by the technical and economical results and a conclusion.

Related work

This section presents related work in the field of DL technology in the energy sector including DL basics as well as related work in community energy sharing and self-organized grid management.

DL in the energy sector

In the past years numerous studies attributed a high potential to DL technology in the energy sector, especially in peer-to-peer (P2P) electricity trading (Burger et al. 2016; Dütsch and Steinecke 2017; Hasse et al. 2016; Schütte et al. 2017), but also in grid management (Burger et al. 2016) and in organizing the allocation of flexibility of any size (BDEW Bundesverband der Energie und Wasserwirtschaft e.V. 2017). Most of these studies approached the topic on a high level though. However, currently a lot of new initiatives are ongoing in this area, a good review of the current research and early development projects is provided in Andoni et al. (2019).

The DVPP-concept, which was first mentioned in Schlund (2018), belongs to the subgroup of initiatives for grid management. Other popular initiatives of this subgroup mentioned in the review paper are Enerchain (Merz 2016) providing P2P-energy trading on transmission system operator (TSO) level, a pilot project of TenneT¹ providing a virtual transmission line from north to south by coordinated (dis-)charging of networked home-storages and other initiatives like Electron² and BloGPV³.

Considering data processing performance analysis of DLs no work focusing on energy related applications is known to us. However, in Dinh et al. (2018) such an analysis has been done for the most popular permissioned blockchains, which are also mostly used in energy related applications. They conclude that there is still a big performance gap between blockchains and current databases.

Besides reviewing the initiatives in the energy sector in a systematic way, (Andoni et al. 2019) also describes the technology background. A short summary on the technology basics necessary for understanding this paper is provided in the following. The term blockchain (Nakamoto 2008) is often used as a synonym for DLs although blockchains are only the most prominent versions of DLs. A blockchain is not a single technology but a combination of several technologies. In general it is a distributed ledger, in which merkle trees of transactions are structured in blocks. These blocks are linked using cryptographic hash functions, which promises an immutability of the past. Peers of the network can modify the state by sending transactions using asymmetric cryptography. Different consensus mechanisms exist to ensure that the state of the blockchain network is not corrupted (Wattenhofer 2017; Nakamoto 2008; Wood 2018; Lamport et al. 1982).

Blockchains can be permissioned or permissionless and private or public, while most of the applications currently discussed in the energy sector either do not need a blockchain at all or might use permissioned blockchains (Wüst and Gervais 2017). In permissioned blockchains, energy efficient consensus mechanisms like proof-of-authority (PoA) (Wood 2015), where only approved validators are allowed to write new blocks, can be used. With different versions of PoA the network cannot be manipulated as long as a certain percentage (depending on the exact version of the PoA algorithm) of the validators are honest.

In this context, a smart contract is an agreement between two or more parties, encoded in such a way that the correct execution is guaranteed by the blockchain (Wattenhofer 2017). Including this concept, Ethereum⁴ aims to be a permissionless technology on which all transaction-based state machine concepts can be build (Wood 2018). Other projects like Hyperledger⁵ enable permissioned platforms for blockchain based applications.

We contribute to the state-of-the art by proposing and evaluating a platform for energy sharing and flexibility provision. The implementation is the first of its kind, which is open-source and its strengths and weaknesses are analyzed in detail. As the term blockchain originally described only public and permissionless blockchains, we use the term DL in the following to avoid misunderstandings.

Community energy sharing

Research activities in the field of community energy sharing have been increasing in the past decade especially since grid parity has been reached. An overview of research activities is provided in Strickland et al. (2016). Major findings are that the maximum load of secondary substations and the necessary grid reinforcement can be reduced, which can lead to decreased total costs. Community energy sharing can be achieved by means of one large ESS for the whole community or many distributed ESSs operated in a coordinated way.

Further research showed that the self-sufficiency rate (SSR) and the self-consumption rate (SCR) can be improved, both economic and technical benefits can be reached (Zhou et al. 2018) and that each participant can profit (Long et al. 2018). In Schlund et al. (2018b) the impact of community sizes was analyzed and it was shown that a smart operation strategy for distributed ESSs can in addition even lead to a considerable increase in power efficiency. Furthermore, the study showed that the largest share of the total benefits can already be achieved at comparatively small community sizes.

Decentralized and self-organized grid management

There have already been a lot of research projects focusing on decentralized grid management (Conrad 2010; Lehnhoff 2010; Lehnhoff et al. 2011). Most of the approaches used price incentives for an automated demand or supply response. Within the projects, different approaches of decentralization considering components of the power system or the IT system have been proposed and analyzed.

Hierarchical aggregation of sub grids with decentralized power system components through balancing group managers have been researched in detail (Lehnhoff 2010; Lehnhoff et al. 2011). They concluded that it is possible to satisfy all actors and to provide necessary balancing power by means of decentralized assets in a possibly cheaper way compared to the current centralized control.

Approaches without the need for any aggregators (Conrad 2010) have been proposed and analyzed as well. However, they have only proven to be robust until a small percentage of attackers in the system (≤5%). In addition, centralized service providers for authentication were necessary.

This paper aims at providing an open and fully decentralized platform, which is more robust to faulty nodes. The focus is not automating the grid management itself but providing an open, decentralized and secure flexibility platform without further intermediaries between distributed flexibility resources and system operators or energy suppliers, who might be in need for the flexibility. The forecasting, monitoring of the grid as well as the scheduling of the flexibility need is assumed to be done by the system operators and balancing group managers and is not focus of this paper. Summarizing, the concept provides a flexibility market access without the need for a central aggregator like a VPP. Minding the related work, this paper contributes to the state-of-the art by proposing a new method, which includes a financial settlement layer, works fully distributed without relying on a central platform and is more robust in case of attacks or faulty nodes compared to previously proposed approaches.

Conceptual approach

The proposed concept aims to enable two basic functionalities: community internal energy sharing through aggregation and flexibility provision of the community as one virtual unit to the external EPS. This shall be achieved on a fully distributed basis and thus without the need for an aggregator as visualized on the left side of Fig. 2. Hence, there are no costs for a third party and the participants can profit from the full economic benefit. The DVPP has thus the potential of directly providing a market access to small-scale distributed flexibility sources by directly linking them to parties in need of flexibility like distribution system operators (DSOs) or balancing group managers (BGMs). In analogy to a VPP, possible applications are frequency and voltage stability or congestion management.

Fig. 2

High level concept of the self-organized DVPP (left) compared to a centralized VPP (right)

A permissioned consortium DL is proposed in order to achieve a consensus on the community state and the coordination rules. The participants must have cryptographically authenticated smart meters with built-in private keys in order to facilitate digitally signed and secure transactions. As the participants have to be known and permissioned a simple form of PoA or practical byzantine fault tolerance (PBFT) (Castro and Liskov 1999) with each participant acting as a validating node can be used as consensus mechanism. This means that the network cannot be corrupted as long as more than a certain percentage (depending on the actual consensus mechanism) of the validators act honestly.

For the proof-of-concept, the participants of the community are assumed to be prosumers, each with a roof-top PV plant, an ESS, a household demand and a smart meter with a built-in private key. The concept is extendable to any kind of flexible assets though. Each of the n participants has the generation G_i(t) and the load L_i(t). Note that the participating houses are all located at one low-voltage feeder and they have one grid connection point for external balancing in case of over- or undersupply or provision of flexibility. The locality of the community is a basis for the assumption that line losses can be neglected and that the flexibility provision can also be used for local needs. As not all houses on the feeder are necessarily part of the community, the grid connection point might be virtual.

Considering the energy sharing part, the concept builds upon the previously published work in Schlund et al. (2018a). The residual loads of the participants P_res,i(t) are aggregated to a community residual load P_res(t) according to Eq. 1.

$$\begin{array}{*{20}l} P_{\text{res}}(t)=\sum_{i=1}^{n} P_{\text{res,} i}(t)= \sum_{i=1}^{n} L_{i}(t) - G_{i}(t) \end{array} $$

(1)

The ESSs of the community can now be used to cover this residual load. This is described by Eq. 2.

$$\begin{array}{*{20}l} P_{\text{ESS}}(t)=\sum_{i=1}^{n} P_{\text{ESS,} i}(t)= P_{\text{res}}(t) \end{array} $$

(2)

Additionally, an efficiency improving heuristic described in detail in Schlund et al. (2018b) is used to avoid low efficient part load operation of the ESSs. This is motivated as the power electronics of state-of-the-art converters have a low power efficiency in part load operation (Schlund et al. 2017a). The heuristic is basically a knapsack problem. It is solved by cumulating the optimal operation points of individual ESSs in the order of the best fitting state of charge (SOC) until P_res(t) is met. This means that the index i of each ESS is not static but dependent on the SOC distribution of the ESSs and updated each coordination timestep Δt_c. As shown in Eq. 3 the last ESS which is needed to cover P_res(t) has the index z(t).

$$\begin{array}{*{20}l} \sum_{i=1}^{z(t)} P_{\text{opt,} i} \geq P_{\text{ESS}}(t) \end{array} $$

(3)

P_ESS(t) is then only provided by the first z(t) or z(t)−1 ESSs depending on which of the two options result in a cumulated value of optimal operation points closer to P_ESS(t). The index of the resulting last active ESS is l(t). The active ESSs then provide P_ESS,i(t) according to Eq. 4, while the rest of the ESSs are set to standby. This idea has already been proposed in Schlund et al. (2018a).

$$\begin{array}{*{20}l} P_{\text{ESS,} i}(t) = P_{\text{opt,} i} \cdot \frac{P_{\text{ESS}}(t)}{\sum_{i=0}^{l(t)} P_{\text{opt,} i}} \end{array} $$

(4)

In addition to (Schlund et al. 2018a) a community internal financial settlement via an internal price p_c is enabled by means of a token. Furthermore, an automatic flexibility provision by the community is proposed here. The flexibility provision is directly triggered by an external payment from an energy supplier or system operator, who has a need for the flexibility. When flexibility is needed for any of the applications mentioned above, the participant who is in need for flexibility can transact tokens to the smart contract, thereby automatically shift the operating point of the DVPP in a desired direction and thus activate the flexibility provision of the distributed ESSs. The flexibility provision is realized by changing Eqs. 2 to 5 as long as the flexibility P_flex(t) is contracted. P_flex(t) is defined in producer counting arrow system here. The smart contract then automatically disburses the prosumers only in case they successfully provided the flexibility. Otherwise the payment is kept in the contract for the operator to be reimbursed. As the payment to the contract and the availability of funds of the party, which activated the flexibility is directly linked to the P_flex(t) variable, the participants providing the flexibility can be sure to be paid by the contract. On the other hand, the contract only pays the participants if they successfully provide the flexibility, which is verified by the smart meter measurement. This way the requesting party has a proof that the offered flexibility has actually been provided and is sure that it only pays for flexibility, which was provided. The price of the flexibility provision p_f can dynamically be set by the participants of the DVPP, e.g. by means of democratic voting, and can be higher than the internal price for energy sharing.

$$\begin{array}{*{20}l} P_{\text{ESS}}(t)=\sum_{i=1}^{n} P_{\text{ESS,} i}(t) = P_{\text{res}}(t)+P_{\text{flex}}(t) \end{array} $$

(5)

The operating principle of the DVPP is visualized in Fig. 3. During normal operation (before t₁, between t₂ and t₃ and after t₄) the DVPP tries to operate self-sufficiently. Therefore, it uses the flexibility of the ESSs to balance the cumulated load of all participants of the DVPP by a cumulated generation of all participants or vice versa. This results in a cumulated residual load of zero in case enough flexibility is available. At t₁ the DVPP smart contract receives a payment which automatically contracts the DVPP to provide positive flexibility until t₂. Thus its cumulated generation is increased (e.g. by discharging distributed ESSs) and the cumulative residual load shifts to +P. At t₃ the same process is triggered for negative flexibility provision. Summarizing, the operating principle of the DVPP is equivalent to the principle of a VPP with the difference that there is no VPP operator, no central controller, it is fully self-organized and the disbursement is automated.

Fig. 3

Exemplary visualization of the operating principle of the self-organized DVPP (producer counting arrow system)

Implementation

A real DL implementation is utilized in order to represent the full complexity of the technology, while the power flows are simulated. The following subsections describe the basic DL, the smart contract and the interfacing software.

Only freely available software and low-cost hardware is used for the implementation. Furthermore, the source code is published under GNU Lesser General Public License on https://github.com/cs7org/dvpp/ for reproducibility.

Distributed ledger

For the given use case a permissioned consortium DL is suitable. For the prototype we chose to utilize an instance of an Ethereum (Buterin 2018) blockchain with an energy efficient PoA Clique (Wood 2015) consensus. The reasons for this selection are a large developer community, the suitability for prototyping, a well documentation and an open source availability. For a robust implementation in the field PBFT or Aura might be more suitable as consensus mechanisms (Angelis et al. 2018). However, Clique is suitable for testing purposes, every participant of the community can act as a validating node and new validators can be added via democratic voting. In addition, we implemented a script for a coordinated creation of new blocks according to round-robin scheduling. This way the behaviour of Aura is imitated.

We implemented the prototype on two different setups. The first setup runs on up to four Raspberry Pis and is used for demonstration purposes, while the second setup runs in up to 20 virtual machines (VMs) and is used for the quantitative evaluation. For the second setup a server with two Intel Xeon E5-2637 v4 @ 3.50 GHz Central Processing Units and 80 GB of RAM is used. This way, every VM uses approximately 350 MHz of computing power and 4096 MB RAM. All VMs run on Ubuntu 18.04 and have geth (version 1.8.14), python3, and additional python3 libraries installed.

In both cases each machine is used to represent one participant of the DVPP. They communicate via TCP/IP and have all the same setup. Geth⁶ runs full authority nodes of an instance of the consortium Ethereum PoA-blockchain with 15 s block time (by default) on each device.

Smart contract

The coordination logic of the community is represented by a smart contract written in Solidity⁶ and deployed onto the DL. It offers registration and deregistration of houses, automatic deregistration of offline nodes, sharing of the ESS operating parameters, the SOCs and the residual loads of each house and the calculation logic of the control commands for the ESSs as described in the concept section. As the contract only stores up-to-date discrete values of the variables, they are described without a time dependency in the following. In order to manage the funds it uses an internal token, which basically maps public addresses of the participants to their stored funds in the contract.

A new participant can register at the smart contract with its desired or optimal operation points for charging and discharging P_opt,i, its maximum power limit P_max,i, its current SOC and its residual load P_res,i at the time the transaction is facilitated. In theory, any asset or aggregation of assets that can be described with a maximal operation point, optimal operation points for charging (or negative flexibility provision), discharging (or positive flexibility provision) and a SOC (or a similar flexibility model) can take part in the system. For the home storages considered here, the optimal operation point is usually close to 50% of the maximum power limit (Schlund et al. 2017a). Whenever a new participant registers (or deregisters) it is added in (removed from) the registry of the smart contract and the total power limit of the DVPP P_max is updated. When registering an amount of tokens has to be transferred to the contract in order to be able to take part in the energy sharing process, so the register function is payable in Solidity terms.

All participants update their operational parameters (current SOC_i, current P_res,i and the measured value of $P_{\text {ESS}, i}^{\mathrm {m}}$ of the previous coordination interval) once every defined coordination timestep Δt_c by executing the setState function. Note that P_res,i is counted in consumer counting arrow system, while $P_{\text {ESS}, i}^{\mathrm {m}}$ is counted in producer counting arrow system. The value of Δt_c can be chosen as desired by the community and is varied between 15 s and 15 min in the evaluation part as its resolution has an influence on the self-sufficiency of the community but also on the communication and data storage effort. The sequence of the transaction is visualized as a flow chart in Fig. 4. Note that a participation in the DVPP and also an update of the state can only be achieved by means of this transaction and this transaction can only be executed completely. In case it fails all changes are reverted.

Fig. 4

Sequence of the setState transaction, which needs to be executed each coordination time interval Δt_c

After a data plausibility check and an update of the SOC, the community members automatically check the last entry of the two neighboring participants (according to the registration index). In case the last entry of one of the neighbors is older than a threshold, the neighbor is assumed to be faulty/offline and is automatically deregistered. This threshold is parameterizable but has to be at least one coordination interval, by default is two coordination intervals. In case the neighbor has less value in his balance than what is needed in the worst case during the next two coordination intervals, they are also deregistered.

In case the DVPP was not contracted to provide flexibility to the EPS during the last coordination interval, the settlement of the community internal energy sharing is facilitated. Therefore, an approach only using withdrawals and no payments to other users is needed, because if participants would need to pay, they could just intentionally miss submitting their transactions in order to save money. This is solved by calculating a community reward r_c,i of the participant sending the transaction according to Eq. 6 and transferring r_c from each other participant to the balance mapping of the sender. The reward is however only calculated and transferred if $P_{\text {ESS}, i}^{\mathrm {m}}$ equals the according set value P_ESS,i from the previous coordination interval. Equation 6 is chosen in such way, that the withdrawals are positive in any case. However, the withdrawals of consumers are smaller than the withdrawals of producers, resulting in an overall payment from consumers to producers. Note, that these withdrawals are not actual withdrawals from the smart contract, but only transactions of its internal token. This follows a common security design pattern for smart contracts, preventing re-entry attacks.

$$\begin{array}{*{20}l} r_{\mathrm{c}, i} = \frac{P_{\text{ESS}, i}^{\mathrm{m}} - P_{\text{res}, i} + P_{\text{max}}}{n-1} \cdot p_{\mathrm{c}} \end{array} $$

(6)

Failing to commit a transaction or not operating the ESS according to the community logic is thus always punished as the failing participants fails to claim its reward and effectively pays more. After the internal settlement, the residual load for the next coordination interval is updated by setting P_res,i and adding it to P_res,i.

In case the flexibility provision was contracted there is no community internal settlement as the whole community gets paid for its flexibility provision, if it was successfully provided. It thereby is again checked if $P_{\text {ESS}, i}^{\mathrm {m}}$ matches its set value and if yes, the flexibility reward r_f is calculated according to Eq. 7. This reward is equal to the share of the flexibility provision, which was provided by the sender. It is transferred from the balance of the contractor address to the balance of the senders address. After this transfer the residual load for the next coordination interval is updated as described above. In addition it is checked, if enough flexibility is available for the next coordination timestep and if yes, the flexibility provision is continued during the next Δt_c.

$$\begin{array}{*{20}l} r_{\mathrm{f}, i} = \frac{P_{\text{ESS}, i}^{\mathrm{m}}}{P_{\text{ESS}}} \cdot |P_{\text{flex}}| \cdot p_{\mathrm{f}} \end{array} $$

(7)

The coordination logic of the DVPP as described in the concept is implemented in the readInstruction function. It calculates the set power for the requesting ESS. This function is deterministic and only depends on the state of the smart contract (the SOCs, P_res and the P_flex), but does not change any state. This way, it can be calculated off-chain. The dependency of the logic on the SOCs distribution ensures that the ESSs are treated equally and the SOCs of all participants are kept homogenous.

Furthermore, a function to contract the flexibility, which transfers funds to the contract and updates P_flex, as well as some other reader functions are implemented in order to be able to analyze the ongoings and check e.g. if there is any flexibility available in the DVPP. In addition, the contract provides functions to actively withdraw earned funds from it and to cancel an active flexibility provision for testing purposes. In order to settle the funds correctly the contract always keeps two periods of P_res,P_flex and P_ESS,i in its state.

For the rights management modifiers limit the access to the functions so only the allowed parties can execute the functions. E.g., setState is limited to participants once per coordination interval, the DVPP can only be contracted by non-registered users and if the DVPP is currently not contracted, a contract can only be cancelled by the contractor, you can only register if you are not yet registered, you can only deregister if you are registered and only read your own instruction for the next coordination interval and p_f can only be updated if there is no active flexibility provision.

The smart contract triggers events, when important state changes occur. This way it is easy and transparent for participants to observe what happens. The following events are implemented:

• NewContract(address _contractor, int _newSetValue, uint _PricePerBlock): triggered when a new contract is initiated

• ContractSelfCancelled(string _reason): triggered when a contract end by itself

• ContractEnd(): triggered when a contract ends

• ContractCancelled(): triggered when a contractor cancels the contract

• BalanceChange(address _from, address _to, uint _amount): triggered when balance is transferred within the balance mapping of the contract

• NewParticipant(address _who): triggered when a new participant joins the DVPP

• OfflineNodeDeregistered(address _who, address _from): triggered when an offline node is deregistered

• NodeDeregistered(address _who): triggered when a node deregisters

Depending on the setting of the coordination interval Δt_c the coordination has a high or low time resolution. A higher resolution results in an operation closer to the real-time course of P_res and P_flex. On the other hand a higher resolution also results in a higher communication and data storage effort. Both of these relationships are quantified in the “Results” section. In the current prototypical implementation Δt_c is determined by the blocktime for simplicity. Future improvements should include a parameterization of Δt_c independent from the blocktime, so a coordination interval can include several blocks and validating nodes are incapable of preventing others to submit transactions within a coordination interval.

Interfacing software

An interfacing software is written in Python 3⁷ and follows an object oriented approach, which enables adaptability e.g. onto other blockchain technologies as well as extensibility for additional features. It utilizes the Web3.py library and thereby JSON-RPC over HTTP to interact with the Geth instance running on the same device. This software runs in each of the participating nodes. For a smooth test run the system clocks of all nodes were synchronized using network time protocol.

At startup the simulation parameters are read in and the participant registers at the smart contract if it is not yet registered. The internal time resolution of the software is adjustable and 1 s by default. With this frequency, house-individual values for PV generation and household load are read from time-series files. This internal time resolution obviously must be higher than Δt_c. The residual load and the SOC of the ESS are transacted to the smart contract once each Δt_c. These transactions are facilitated in parallel in order to be able to simulate the ESS operation in real-time. With every new block, these values are distributed in the network and each house’s smart contract instance can calculate the control command for its ESS based on the new state. The ESS is then operated according to the battery command if possible.

When a new block is detected, the software also checks if the node is still registered. It might have been deregistered by other nodes in case it has no more balance or its communication was faulty and the other nodes assumed the node to be offline. All relevant data of this procedure is written to a log file so that it can conveniently be analyzed.

For the generation of PV power and the individual household load (Tjaden et al. 2015) time-series are used. The ESSs are modeled in Python 3 based on (Schlund et al. 2017a), which represents operational power dependent efficiencies for charging, discharging and idle mode and SOC-dependent power limits for the maximal charging and discharging powers. The empirical model includes a submodel for the battery itself and the power electronics of the AC/DC conversion including a battery management system. Thus, not only losses from the battery itself, but also from the necessary periphery are taken into consideration. Parameters like the size of the PV plant or the ESS are parameterizable.

Results

In this section results considering the general proof-of-concept are presented. The evaluation includes an energy management view, a communication effort view and an economic view. The system has been tested in over 25 different test runs of 3 to 7 days with different parameterizations of the system. During these test runs the general behavior proved to work. The quantitative results in the following are based on the operation during a sunny week in may with an average PV production of 80.4 kWh and an average demand of 65.3 kWh per household, both in 1 s resolution. Additionally, each participant has an ESS with a capacity of 8 kWh if not explicitly stated otherwise.

General behaviour

An exemplary day from one of the testruns with 20 participants and a coordination timestep of 30 min is visualized in Fig. 5 to provide a general understanding of the system. Figure 5a) shows the operation of all battery systems in producer counting arrow system (colored areas). The red line is the cumulative residual load of all participants of the DVPP P_res in consumer counting arrow system. During normal operation the ESSs try to equalize this curve.

Fig. 5

Overview of a the battery operation and b the SOC during an exemplary day of a testrun with Δt_c=30 min

To model the flexibility need, a DSO or BGM in need of flexibility is abstracted as an agent, who pseudo-randomly contracts the DVPP for flexibility. When it is zero, no flexibility is contracted and the DVPP is in energy sharing operation mode trying to operate self-sufficiently. When it is unequal to zero the DVPP tries to provide the contracted flexibility. The green line differs from the red line as it also considers the additional flexibility provision. The phases of active flexibility provision are marked with vertical lines. In the exemplary illustration positive flexibility is contracted in the morning (e.g. to cover the morning peak) and in the early evening (e.g. to cover charging of electric vehicles). Negative flexibility is only contracted at noon (e.g. to shift a peak of other PV plants).

During these phases the green line is the set value for the ESSs. It is visible, that at the beginning of each coordination interval, the ESSs exactly cover the according set value. However, during the coordination interval the operation is constant, which leads to a deviation between battery operation and set value. This deviation obviously increases in significance with increasing coordination intervals.

In Fig. 5b) the corresponding course of the SOC is visualized. The total SOC of the DVPP is composed of the individual SOCs. It is visible that the SOC changes according to the operation of the ESSs and that the SOCs of all participants are kept equally leveled. In the late afternoon all ESSs are fully charged and there is no more free capacity left. Thus, the PV surplus in the late afternoon cannot be stored in the ESSs. Such behaviour could be avoided by using prediction and a simple peak shaving algorithm on top of the proposed platform.

In order to understand better what is happening when using coordination intervals with high resolution, a zoom view is visualized in Fig. 6. The two charts show the time span between 14:00 and 14:15 with a PV surplus and no contracted flexibility provision. The colored areas represent the residual generation in producer counting arrow system (−P_res,i, pale) and the operation of the ESSs $\left (P^{\mathrm {m}}_{\text {ESS,} i}, bright\right)$. In addition, the resulting aggregated power at the virtual grid connection $P^{\mathrm {m}}_{\text {VGC}}$ is displayed in red. As no flexibility is contracted (green line), the set value for the virtual grid connection in zero.

Fig. 6

Zoom in an exemplary test during PV surplus with a) Δt_c=15 s and b) Δt_c=30s

In Fig. 6a), it is visible that the surplus of the PV plant is split into energy packets, which are distributed to the participating ESSs. These energy packets are characterized by a power value and the coordination interval of 15 s. As a result of the coordination algorithm the power values of all of the packages are close to P_opt,i. The resulting power at the virtual grid connection $P^{\mathrm {m}}_{\text {VGC}}$ is kept close to its set value of zero, with the exception of little power spikes between the coordination intervals resulting from propagation delays of the new blocks. In Fig. 6b) the coordination interval is doubled, resulting in larger energy packets and fewer switching spikes.

With a higher resolution of the coordination interval, a more accurate provision of flexibility is possible. To demonstrate this. Figure 7 shows a comparison of the set values and measured values on DVPP level during a test run with a coordination interval of 15 s and ESSs with a capacity of 4 kWh. Smaller capacities have been chosen here to be able to observe the behaviour, when there is no more flexibility available (the cumulated SOC is either empty or full).

Fig. 7

Comparison of measured and set values for a the operation of the ESS and b the virtual grid connection during an exemplary day in producer counting arrow system with Δt_c=15 s and battery capacities of 4 kWh

In Fig. 7a) the cumulated set value for all ESSs (green) and its measured value (blue) are compared and the absolute difference is displayed in red. Whenever flexibility is available, the ESSs operate as commanded and the red line equals zero. Only in the afternoon, when all ESSs are fully charged, the command cannot be fulfilled. Figure 7b) shows the same comparison for the virtual grid connection, likewise on DVPP level. In addition to the observation from above, in Fig. 7b) slight deviations between the set value and the measured value occur as the information update about the current state only occurs each Δt_c. Thus the deviations occur although the ESSs all operated according to their command. With the coordination interval of 15 s these deviations seem to be negligible.

An advantage of the platform is, that it provides an automated financial settlement for everything that happened. Figure 8 shows the financial settlement for the same period as Fig. 7. For demonstration purposes the community internal price for energy sharing p_c is constantly $5\cdot 10^{8} \frac {\text {wei}}{{\text {mW}} \cdot \Delta t_{\mathrm {c}}}$ and the price for flexibility provision is p_f is $1\cdot 10^{9} \frac {\text {wei}}{{\text {mW}} \cdot \Delta t_{\mathrm {c}}}$. In normal operation, both prices can be determined dynamically, e.g. through voting or by means of other applications like a market in a layer on top of the platform. The contracted flexibility is visualized in blue on the secondary axis. It is visible that the financial settlement works as expected, even with the small coordination interval of 15 s. In case flexibility is successfully provided the balance of the parties providing it increases linearly at the rate of p_f. When it is not successfully provided, there is no increase and when there is no flexibility contracted, the internal settlement depends on each participants power balance and p_c. During the internal settlement the balances diverge as the feed-in from the PV plants is heterogeneous.

Fig. 8

Exemplary time behavior of the balances of the participants with Δt_c=15s and battery capacities of 4 kWh

Evaluation from the energy management perspective

In this subsection the SSR, the SCR and the energy efficiency (η) of the ESSs is evaluated in dependency of Δt_c. These performance indicators are defined as follows:

• The SSR is defined as the share of the household demand within the community, which was concurrently provided by the PV plants or the ESSs

• The SCR is defined as the share of the total PV production within the community, which was concurrently consumed by the households or the ESSs

• The energy efficiency is defined as the totally discharged amount of energy with respect to the totally charged amount of energy.

For the determination of the three indicators a simulation of the system is performed supposing an instant information exchange between the nodes. The SOC of the ESS at the end of the considered period must equal the SOC at the beginning. Moreover, no additional flexibility is provided to the grid during the test runs. The performance indicators highly depend on a great number of parameters like the size of the PV plants, the household demand, the considered time period and the sizes of the ESSs. Here we are not interested in the total values but in the sensitivity of the indicators in dependence of Δt_c and we keep the other degrees of freedom constant. Table 1 shows the SSR, the SCR and the efficiency in dependence of Δt_c for the parameterization described at the beginning of this section.

Table 1 Comparison of the self-sufficiency rate, the self-consumption rate of the community and the total energy efficiency of the ESSs depending on Δt_c for a sunny week in may

Without any coordination the ESSs operate alone and only try to satisfy their own household demand with a greedy charging strategy. As expected the coordination can improve all of the indicators significantly. The influence of Δt_c in the SSR and the SCR is also significant. This can be explained by the larger deviations that result from larger coordination intervals. Comparing Fig. 5a) with Fig. 6 shows that energy packets with a lower resolution map the residual generation less accurately. However, at a Δt_c of 1 min, 96% of the optimum is still reached. This suggests that a higher resolution is not necessary from an energy management point of view.

Note that when comparing the simulation results to a real test run with the same input data, the results deviate slightly. This can be explained by block propagation times and deviations in system time synchronism resulting in the spikes shown in Fig. 6.

In addition to the observations above, a smaller Δt_c also results in a faster response to a flexibility request, which makes the concept potentially suitable for a wider range of applications. On the other hand a smaller Δt_c results in an increased data storage and communication effort, which is analyzed in the next section.

Data storage and communication effort

To evaluate the data storage and communication effort of the prototypical implementation, tests with different amounts of nodes were run and the network traffic was measured using psutil (Rodola). As the communication characteristic during the tests showed that the communication is determined by the transactions and the propagation of the blocks and both occur in the interval of Δt_c, the communication effort can be normalized to Δt_c. For all experiments a fully meshed P2P network was used and two parameters were varied:

• the total number of participants n

• the number of validators n_val, with n_val≤n as the validators are a subgroup of the participants

The resulting communication effort for different parameterizations is summarized in Table 2 for validating nodes and in Table 3 for non-validating nodes. It is calculated as average values over the according test run, while each test run ran at least for 250 coordination intervals. As expected, the communication effort increases with the number of participants. However, the increase seems to be less than linear. With few validators, non-validators face a higher communication effort as the validators, probably as they receive new blocks more often. Summarizing, the communication effort of about 300 kB per coordination interval is no limiting factor, especially not for low resolutions of Δt_c

Table 2 Measured average communication effort with standard deviation of the validating nodes of the DVPP in kB per Δt_c

Table 3 Measured average communication effort of non-validating nodes of the DVPP in kB per Δt_c

In order to evaluate the data storage effort the block size b was analyzed. It increases linearly with the number of participants n according to Eq. 8, with b₀ being the size of an empty block and tx being the size of a transaction. Both of the parameters were determined during the experiments.

$$\begin{array}{*{20}l} b = b_{0} + tx \cdot n \,\,\,\,\,\,\,\, \text{with} \,\,\,\, b_{0} = 0.61\text{kB} \,\,\,\, \text{and} \,\,\,\, tx = 0.24\text{kB} \end{array} $$

(8)

Considering this relation up to 4164 participants could be included in a single DVPP before reaching a block size of 1 MB. For the setup with 20 participants, this results in a total used storage of about 190 MB (2.8 GB) per year with a Δt_c of =15 min (1 min).

Economical evaluation

For an economical evaluation, incomes from energy sharing and from flexibility provision have to be opposed to investment and operational costs. For a real and secure implementation in the field, smart-meters with a built-in private key, a processing unit to run the node and a gateway for the communication would be necessary. As such devices are not yet available, we estimate the extra costs compared to a normal smart meter with the costs of a single-board computer as it was used in the prototype. This costs 30 € and has an electricity consumption of about 3 W resulting in yearly electricity costs of less than 8 € based on an electricity price of $0.299\frac {\EURcr}{\text {kWh}}$ (Bundesnetzagentur 2017). In large scale, the costs would obviously decrease drastically.

In contrast stand savings by increased self-sufficiency and efficiency through energy sharing of up to 5.30 € per household in this week in May alone. This value is based on the same electricity price as above and an feed in tariff of $0.122\frac {\EURcr}{\text {kWh}}$ (German Government 2017). However, considering the legal framework in Germany energy sharing is so far only allowed without using the public grid. This means that, as long as the legal framework is not adopted, the concept is only thinkable in privately owned grids or projects with large tenement houses.

In addition, a more valuable income might be generated by means of flexibility provision. For an economical evaluation, knowledge about the prices for flexibility provision is necessary, which is unavailable as this form of flexibility is not yet used in local grids. However, depending on the situation in the local grid, the value of this service might vary strongly. In a future scenario with a high share of renewable energies and the need for flexibility, it might be a considerable additional income for such flexible communities.

Conclusion

In this paper we proposed a new concept for a self-organized, fully decentralized platform for coordinated flexibility provision using a consortium Ethereum blockchain. The decentralized platform directly links a community of flexible prosumers in a local grid areas with system operators or balancing group manager and has thus the potential of providing small-scale flexibility sources an access to a flexibility market. The concept is fully transparent, highly automated and each participant is a validating node. Besides flexibility activation directly through a payment it enables energy sharing for an increased self-sufficiency and power efficiency. We showed the general functionality, which was validated during numerous test runs with up to 20 participants. We also implemented an on-chain automated financial settlement layer, which is especially interesting if the blockchain is implemented as a subchain or a shard of a public chain and can thus manage real value.

However, the blockchain based implementation is quite complex and comes with an overhead considering communication and data storage. This overhead and possible limitations are quantified in the paper. An additional possible limiting factor for up-scaling is the on-chain computational effort. This will be analyzed in future work and might be solved by multichain approaches or sharding. Another disadvantage might be that all members of the community are able to see the power consumption of their fellow community members.

For an implementation in the field, the smart meter hardware would need to be able to run a node or communicate to a trusted node and to access the controller of the flexibility source (e.g. the battery system). Furthermore, the smart contract would need to allow for some measurement inaccuracies, a more intelligent pricing scheme is necessary and line losses might be included. Additionally, a robust incentivising scheme for the validators is necessary.

Improvements of the prototype might include a decoupling of the coordination interval and the block time in order to really run in a robust and fault-tolerant way and to avoid the necessity of system clock time synchronism. Future analyses can involve case studies with smart applications on top of the platform and a wide range of parameterizations of participants. In addition, the same concept is also possible on a higher level with aggregators, system operators or balancing group managers acting as participants and validating nodes. This way, these parties would be able to easily coordinate their aggregated flexibility sources in a transparent and automated way. This seems to be a promising use case of the proposed decentralized flexibility platform as the mentioned advantages on the aggregated level justify the complexity, no special new hardware is required for an implementation, regulatory restrictions are more likely to be overcome and the necessary number of nodes have proved to be operable.