A Blockchain-Based Configuration for Balancing the Electricity Grid with Distributed Assets

Abstract

This paper explores a future perspective to foster the provision of balancing services to the electricity grid by distributed assets. One recent test case, initiated by the Dutch Transmission System Operator (TSO), was to operate an Electric Vehicle (EV) fleet on the automatic Frequency Restoration Reserve (aFRR) market, which entails fast and automated reserves. To achieve that in a decentralised, automated and transparent manner, the role of blockchain technology for this specific application is explored. We propose a novel configuration that can serve as a basis for deploying distributed assets for aFRR markets using blockchain or any alternative Distributed Ledger Technology (DLT). Automation can be achieved via the deployment of smart contracts, which also results in transparency in the system. The blockchain configurations are designed for three phases in the aFRR market, namely: (i) Operational planning and scheduling by a balancing service provider (i.e., formulation and submission of aFRR bid), (ii) Real-time operations (i.e., activation and measurements), and (iii) Verification and settlement (i.e., imbalance correction and financial settlement). The paper concludes that the scalability of distributed assets that can participate in the system, combined with the large transaction times and energy consumption of some consensus mechanisms, could put limitations on the proposed architecture. Future research should address benchmarking studies of other alternatives (e.g., DLTs, such as the ones based on directed acyclic graphs, and non-DLT solutions) with the proposed blockchain solution.

1. Introduction

To maintain the electricity system frequency and keep it close to its nominal value (i.e., 50 Hz in Europe), electricity supply and demand need to be in balance. Traditionally, unexpected changes in supply and demand could be negated at the supply-side by adjusting the generation output of coal-and gas-fired power plants. Given the phase-out of fossil fuel-fired power plants from the generation mix, next to flexibility at the supply side, alternatives are also sought at the demand-side. Solutions that have received much attention in this area are demand response and transactive energy [1]. They entitle altering the short-term electricity usage patterns of end users by scheduling and levelling instantaneous power demand, for example, incentivised by financial compensation [2]. Various Distributed Assets (DA) can be operated for this purpose, for example, heat pumps [3], stationary energy storage [4,5] and smart appliances in households [6]. Another distributed asset that could play a major role is the Electric Vehicle (EV). The global EV stock has grown from around half a million in 2014 to over three million in 2017, and is expected to increase to 120 million in 2030 when current national policies are implemented, and to 228 million if ambitions are increased in order to meet climate goals [7,8]. In recent years, there has been an increasing amount of literature on using EVs for demand response [9]. Examples are the smart charging of EVs to increase the self-consumption of Photovoltaic (PV)-generated electricity [10], the provision of frequency containment reserves by EVs compared to the inertia of conventional generation [11], the mitigation of rapid PV fluctuations in the low-voltage grid [12] and flexibility potential quantification based on charging station data [13].

Providing flexibility with DA is associated with different challenges compared to centralized ones. To gain more insights into this topic, the Dutch Transmission System Operator (TSO) set up a pilot in the Netherlands [14]. In the first phase of this pilot, the charging process of a fleet of EVs was controlled by an aggregator. An aggregator is an organisation that can combine various DA into a single system resource which can be utilised for the provision of flexibility services [15,16]. This aggregator acts as a Balancing Service Provider (BSP) and offers an automatic Frequency Restoration Reserve (aFRR), which is an ancillary service used for restoring imbalance on the electricity grid [17]. Besides, blockchain technology was used in this pilot to manage data exchange and transactions in a decentralised, verifiable and immutable way, while the local control of the DA was achieved by the market parties involved in this pilot from their own back-end and control infrastructure. Blockchain is an emerging technology for decentralised computation, data storage and management that has been recently proposed and used in the energy sector due to its capability to enable the shift to more decentralised energy systems [18]. A blockchain is a Distributed Ledger Technology (DLT) that is used to connect a large number of anonymous nodes without the need for a central controlling agent. Blockchain technology utilises a consensus mechanism to ensure the security of the network and allows participants to store and share data in a secure and verifiable manner. Information is stored in sets of data called blocks and verified using cryptographic hashes [19]. The extension of a blockchain with smart contract technology expands the utility even further and enables smart optimization in the energy sector [20,21]. This pilot serves as a motivation to explore the potential role of the blockchain as an enabler for aFRR provision by a fleet of EVs in a more comprehensive manner, which is the purpose of this paper.

In previous studies, the aspects of aFRR provision by EVs and the role of blockchain technology have been assessed separately, whereas this study aims to provide an integrated approach. A review of the potential role of an EV fleet management in the future energy system for different applications is provided by [22], showing their potential for grid balancing. In [15], the opportunities, challenges and possible solutions for power balancing through aggregators and DA are determined. This research shows that no available platform has been identified yet to enable the provision of ancillary services on a local level. The literature on blockchain applications for the energy market is mostly focused on distribution network applications. A survey of blockchain technology in the energy sector is performed in [18]. The applications and challenges of using Blockchain as a secure, distributed cyber infrastructure for the future grid is discussed in [23]. The potential influence of blockchain on the configuration of the actors in the Dutch electricity system and its ability to transform the existing system is analysed in [24] based on a social network analysis. The iconic Brooklyn microgrid, which is a practical implementation of blockchain in local electricity markets, is presented in [25]. A blockchain-based system for Peer-to-Peer (P2P) energy trading between households is proposed in [26]. A decentralised optimal power flow algorithm for distribution networks using blockchain-smart contract is presented in [27]. The combination between EV and blockchain is addressed by [28], however, their blockchain is only used for the cryptocurrency that provides the incentives, whereas this study aims to provide an integrated approach.

The aim of this paper is to take a future perspective on the implementation of ancillary services provided by DA and explore the role that blockchain technology can play in such applications. Motivated by the Dutch pilot, the focus lies on the provision of aFRR by EVs, but the proposed frameworks are constructed in such manner that it can be applied to ancillary service provision by DA in general. Furthermore, we propose a blockchain configuration that can enable DA to operate in ancillary markets. The contribution of this paper is summarized as follows:

• The paper proposes the use of blockchain as an ICT solution for balancing the electricity grid in the aFRR sub-market by a fleet of EVs, based on a pilot study by the Dutch TSO.
• The blockchain configurations are designed for three phases in the aFRR market, namely: (i) Operational planning and scheduling, (ii) Real-time operations and (iii) Verification and settlement.
• The need for blockchain and other DLTs in this application is critically discussed, addressing which parties can be allowed to validate transactions on ancillary service markets, and whether the network should be public or private.

The remainder of this paper is structured as follows. Section 2 presents a comprehensive description of the current aFRR market mechanism in the Netherlands. A case study is described and discussed in this section, where an actual EV fleet is involved to provide aFRR in realistic operation settings. Further, the role of blockchain technology is introduced in this section. In Section 3, a blockchain-based framework to enhance aFRR verification as well as the blockchain configuration methods are proposed and thoroughly discussed. Finally, the paper is concluded in Section 4 with recommendations for future research.

2. Automatic Frequency Restoration Reserve (aFRR) Market Mechanism and Case Study

2.1. Procedure of Providing aFRR with Electric Vehicles (EVs)

In the aFRR market, BSPs can place bids for separate periods of 15 min, called Imbalance Settlement Periods (ISPs). This entails that for a certain financial compensation, the BSP offers to increase or decrease electricity supply or demand compared to their reference supply or demand, in return for a financial compensation according to the imbalance settlement system of the TSO [17]. In this process, certain market requirements must be met by the aFRR provider, for example, a minimum bid size of 1 MW and a minimum regulation rate of 7% per minute.

The procedure of providing aFRR with EVs consists of three phases: planning, operation and verification. In the planning phase, EV owners, who are part of an EV fleet connected to an aggregator company (i.e., BSP) that operates on the aFRR market, connect their car to their Charging Point (CP). They can enable smart charging (e.g., through an application developed by the BSP). In this application, customers can indicate their estimated time of departure and their minimum required State of Charge (SoC). The BSP has the flexibility to determine the charging process given these constraints. The BSP estimates in which ISP it will have enough EVs available to provide aFRR to reach the minimum bid size. Bids can be submitted until thirty minutes before the start of an ISP. The aggregator sends its bids containing, amongst others, the bid size, the bid price, the minimum regulation rate and the specific ISP to the TSO.

The next phase is the operation phase. In this phase, there is real-time data exchange of, for instance, an aggregated power measurement and a so-called reference signal. The reference signal is the power output a BSP expects one minute in the future. In case of an imbalance, the TSO activates the aFRR by sending setpoints to the relevant BSPs. These setpoints, sometimes called ‘delta signals’, are the requested change in power output compared to the reference signal. The BSP processes these setpoints, selects the EVs from the available pool and sends signals to the EVs to change their charging behaviour. As a result, their actual aggregated power output will diverge from the reference value of the pool without activation. This difference represents the delivered aFRR. When deactivating a bid, the TSO sends a setpoint of 0, after which the BSP can direct the selected EVs to resume their original charging schedule.

Lastly, verification is performed by the TSO to ensure that the aFRR is delivered properly and to compensate the BSP accordingly. To do so, process specialists execute ex-post visual analyses to determine whether the actual power differs from the reference signal [29]. Then, the aFRR energy volume is settled with each contributing BSP.

2.2. Aggregate Power and Reference Signal

To give an indication of the performance of the EV fleet in providing aFRR, we demonstrate how the fleet responds to the set points sent by the TSO. Figure 1 shows the aggregate power output and reference signals for a time interval of seven hours. Charging is regarded as a negative power output, as decreasing demand reflects providing the service of upward flexibility; activation in this sense thus means to stop charging. Note that the numbers on the y-axis are intentionally omitted as requested by the TSO, because of data confidentiality issues. Six bids were activated within the time frame, and each time the fleet responded by changing the charging rate to 0 kW.

Figure 1 provides multiple insights. Firstly, it can be observed that the EVs respond very rapidly in the case of activation, considering the steep decrease and increase in power demand. Secondly, it shows that in the fourth and sixth activation the power output increases slightly during the activation period. This can be explained by EVs plugging in during the activation, which will be elaborated on in Section 2.3. Thirdly, Figure 1 provides insights in the functioning of the reference signal provided by the BSP. The reference signal follows the power output but lags somewhat behind. This can mainly be observed during activations, as the power output changes very rapidly.

2.3. Individual Response of EVs to aFRR Activation

In order to investigate the individual responses of EVs to aFRR activation, the same time interval as in Figure 1 is analysed. In this time interval, six bids are activated. Figure 2A shows the upward setpoints sent by the TSO, Figure 2B shows the individual power output of the EVs and Figure 2C shows the status of the EVs.

The assets are allocated different statuses by the BSP. By allocating a status, the charging behaviour of the vehicles can be understood more easily.

Table 1. The different statuses of the assets in the pilot.

Asset Statuses	Description
Status (4) Vehicle outside aFRR pool	Allocated when the Electric Vehicle (EV) is not available for automatic Frequency Restoration Reserve (aFRR) anymore. For instance, if State of Charge (SoC) > 85%, when a SoC of 100% cannot be reached prior to the departure time in combination with aFRR provision or when an owner plugs out earlier than expected.
Status (3) Vehicle in aFRR pool	Default status when an EV is plugged in and the owner is granted permission for a flexible charging session.
Status (2) Vehicle allocated to a bid	When an EV is assigned by the Balancing Service Provider (BSP) to a placed bid.
Status (1) Vehicle activated	When an EV is activated for aFRR (i.e., is forced to stop charging).

shows the four statuses that can be allocated to the assets. Note that if an EV owner has not granted permission to a flexible charging session, no status is allocated, and no data is logged.

As already indicated by the aggregated response of the EV fleet, it can be seen that the EVs respond well to the sent setpoints; the power output of all EVs goes rapidly to 0 kW during activation. The duration of the activation is as respected as well. Analyses of other time intervals show that EVs sometimes deactivate (i.e., resume charging) sooner than demand, but this does not apply to the time interval visualised in Figure 2.

In the fourth and sixth activation, it can be seen that an EV plugs in during the activation period. During the fourth activation, this EV is represented by the red dashed line and in the sixth activation by the green line that does not equal 0 kW. This can also be seen in Figure 2C) as the red dashed line during the fourth activation and the green line in the sixth activation are the only lines that do not have status 1 (i.e., vehicle activated). This explains the drop below 0 kW of the aggregated profile in Figure 1. It is up to the TSO to decide how the BSP should handle the EVs that plug in during activation (i.e., activate immediately or not).

2.4. Role of Blockchain

A blockchain is a DLT that can record transactions between different parties in a decentralised, transparent, verifiable and immutable way [30]. To secure transactions on a blockchain application, asymmetric encryption is used. The transactional information (e.g., sender and receiver, timestamp, etc.) on a blockchain is stored in blocks. Each block is identifiable by its cryptographic hash and each block’s hash references the hash of the previous block, leading all the way back to the genesis block. Hashes are used as a unique digital fingerprint. A consensus algorithm needs to be in place to ensure everyone in the network agrees on a single version of truth and the network is resilient for malicious participants [31]. Probabilistic algorithms such as Proof of Work and Proof of Stake are mostly used in permissionless blockchains, where in permissioned blockchains one of the many Byzantine Fault Tolerance protocols can be implemented (e.g., the Practical Byzantine Fault Tolerance (PBFT) algorithm [32]). Permissioned versus permissionless relates to whether a participant needs permission from a central authority to write on the blockchain. Hence, in permissionless blockchains, authentication mechanisms are not available [33]. A further distinction can be made between private and public systems, which relates to who is allowed to read information in the blockchain.

In 2017, a new kind of DLT was introduced which is proposed as the evolutionary successor of blockchain technology, named the Tangle [34]. This new technology can be categorized as a Directed Acyclic Graph (DAG). The Tangle is a DLT, because the verification of the transactions and updating of the ledgers happens at a decentralised level. A major difference with the blockchain is that transactions can have multiple predecessors (or parents). This enables ramping up transaction volume and throughput [35]. A transaction is validated when a new transaction refers to this parent transaction, making it more accessible for smaller players [36]. The most developed application of the Tangle is the cryptocurrency IOTA. However, currently IOTA Foundation is the only validator of transactions [37].

In the literature, two closely related main advantages of blockchain in the energy trade are identified [31]. First, it can lower the entrance barrier for DA on electricity markets, bringing in more players, transparency and market liquidity. Second, transactions can be processed via a well-designed digital system in a decentralised manner instead of a third party, decreasing the stress on this third party and thus opening up possibilities for a higher number of transactions (i.e., P2P trading [26]).

The work in [32] provides a flow chart to establish the technical need to use blockchain for a certain problem. In Section 3.2.1, we provide an adapted version of this flow chart, applied for the case of providing ancillary services by DA. We will use this as the basis for determining whether, and if so, which form of blockchain should be used for a specified application. The grid operator in case of aFRR provision is the TSO, but it could also be a DSO in case of P2P trading at the distribution level [26]. The TSO, DSOs and BSPs can all serve as writers; specific writing rights should be decided on by an appropriate central authority. This role could be fulfilled by the current grid operator or a newly established authority.

3. Proposed Blockchain-Based Framework for aFRR Verification and Blockchain Configuration

This section consists of three parts. In the first part, a new method for future aFRR verification is proposed. This method should simplify validation of aFRR provision by DA and enable the possibility for automation. In the second part, a blockchain configuration is proposed. In a future with a large increase in the number of aFRR providers, this simplification and possibility for automation is of great value. The third part discusses the considerations for using blockchain for the provision of aFRR by DA.

3.1. Proposed Future aFRR Verification Method

As explained in Section 2, the BSP bids certain amounts of flexibility in a specific time slot (ISP). Flexibility in the electricity system has two dimensions: flexibility in the power dimension (i.e., shifting supply or demand of power up or down) and flexibility in the time dimension (i.e., the amount of time the load can be shifted). Here, we focus on flexibility in the power dimension, denoted as ∆P. This can either be a flexibility provided by the BSP or a flexibility requested by the TSO.

The flexibility provided at time t (i.e., $\Delta P_{provided}^t$) can be calculated according to Equation (1):

$$\Delta P_{provided}^t=P_{actual}^t-P_0.$$

(1)

where P₀ is the actual power value of the EV pool one time step before receiving a signal to provide aFRR and where $P_{actual}^t$ is the power output during the activation. The $P_0$ is essential to measure accurately. In a future system with a larger dependence on DA, the power of assets that participate in ancillary service provision should be measured and logged from the moment they connect to a CP. Then, the P₀ can be determined by retracting the power value one time step before a request is sent to the BSP.

In the case that frequency restoration is needed, the TSO sends requests for a change in power. These are sometimes called ‘delta signals’ or ‘setpoints’: $\Delta P_{setpoint}^t$. This is an integer value, which leads to a stepwise increase or decrease of requested flexibility. In this activation, the regulation rate of the BSP is taken into account. The BSP in turn must follow this setpoint as closely as possible, but with a minimum regulation ramp speed equal to the regulation rate as specified in the bid message, respecting the minimum regulation rate of 7% per minute. A BSP can also include a higher regulation rate than this minimum of 7% per minute. The regulation rate can be converted to the flexibility to comply with the bid regulation rate, which we call $\Delta P_{\alpha }^t$, by Equation (2):

$$\Delta P_{\alpha }^t=\frac{regulation rate}{100\%}\ast Bid Size.$$

(2)

The flexibility provided by the BSP should always stay between the power values stemming from the $\Delta P_{setpoint}^t$ and $\Delta P_{\alpha }^t$, which is visually depicted in Figure 3. We will provide an example for upward aFRR provision to further elaborate on this. In this example, the BSP has bid 5 MW. The minimum regulation rate for aFRR is 7% per minute and can be chosen to be higher by a BSP when desired. For this example, we set the regulation rate at 20% per minute (i.e., minimum ramping of 1 MW/minute). The TSO can send updates to the setpoints at different moments in time, respecting the minimum regulation rate. Figure 3 shows the corresponding allowed flexibility provision (i.e., the area between $\Delta P_{setpoint}^t$ and $\Delta P_{\alpha }^t$). Three phases are apparent: upward setpoints, constant (no) setpoints and downward setpoints. For the latter phase, it is important to note that this is not a request for downward aFRR, but a decreasing request of upward aFRR. The $\Delta P_{provided}^t$ must meet conditions presented in Equations (3)–(5) for these phases, respectively:

$$\Delta P_{\alpha }^t\le \Delta P_{provided}^t\le \Delta P_{setpoint}^t,$$

(3)

$$\Delta P_{setpoint}^t=\Delta P_{provided}^t,$$

(4)

$$\Delta P_{setpoint}^t\le \Delta P_{provided}^t\le \Delta P_{\alpha }^t.$$

(5)

This is highlighted in Figure 3 by the marked area. Note that condition (4) starts at Time = 6 min. With proper measurement equipment in place, this could relatively easily be automatically verified.

As mentioned before, flexibility ∆P is defined as the difference between the actual power and the reference power. Currently, the reference power is sent by the BSP and represents the expected power one minute in the future. We see disadvantages of this procedure. First, it imposes additional data exchange and complexity; methods should be in place to accurately predict the load every moment in time. In the current system, these are regular operations for power suppliers. However, this prediction will become increasingly complex with assets that are more difficult to accurately predict on short time scales (e.g., when a power output of an asset is weather dependent or the stochastic nature of EVs plugging in/out times). Second, prior research has shown that market parties sometimes do not comply with the requirement to send the reference signal a priori and build up their reference signal a posteriori for their own benefits [16]. Third, the current verification is not automated. Different solutions exist to address it. We suggest considering to change the reference signal from a prediction to the actual power at that time, i.e., the instantaneous power, as the reference signal (i.e., $P_0$). An important advantage of this method is that it would simplify the process—using the instantaneous power ensures the only data stream is the measured power, instead of having two separate data streams (i.e., measured power and reference power). Furthermore, it can facilitate the development of an automated verification tool to assist the TSO to assess the performance of market parties that provide balancing services. It should be noted that we do recommend to test whether the reliability of a reference signal based on instantaneous power is similar to the reference signals based on prediction of power output.

3.2. Proposed Future Blockchain Architecture

3.2.1. Need for Blockchain

According to the flow chart illustrated in Figure 4, there could be a use for the blockchain technology for the application of providing ancillary services with DA. We elucidate this by treating the various questions for the considered application one-by-one in

Table 2. Assessment of whether blockchain is needed in a future system for provision of ancillary services by Distributed Assets (DA).

Question	Assessment
Do you need to store data?	Yes. It is of importance to store data about the ancillary service provision for transparency, monitoring and verification purposes.
Are multiple electricity market players allowed to write?	Yes. First, BSPs need to be able to write their bids as transactions on the blockchain. Second, other energy market players could also have an interest in participating or reading transactions from the platform. For example, the DSO could communicate local congestion constraints. Also, market players that are impacted by the ancillary service provision of an independent BSP could have a role.
Can you use an always online grid operator?	The grid operator is always online, but one of the proposed architecture goals is that the TSO would not be the only validator in a future system, which creates extra trust and transparency.
Are all writers known?	Yes, in the current situation. The BSPs and DSOs are known entities in the context of ancillary services, and thereby should be a known party. If all owners of DA are allowed to write on the blockchain (e.g., also an individual EV owner), it is possible that not all writers are known. In that case, a permissionless blockchain could be the most suitable option—however, it should be noted that this is far from current practices.
Are all writers trusted?	This is open for discussion. If all writers trust each other, a database with shared write access is probably the best solution [32]. However, given the expected increase of BSPs, the financial implications of ancillary service provision and the systemic importance of the balancing markets, security measures and trusted validation become very important. In that case, a blockchain holds value.
Is public verifiability required?	This is also open for discussion. On the one hand, one might argue that transparency is important. In that case, it is best to opt for a Public Permissioned Blockchain. On the other hand, the transparency in this application could potentially hamper the privacy of involved users. Besides, involved companies want to protect their strategy for competition reasons. In that case, Private Permissioned Blockchain would be best.

. From the analysis, the following remarks should be considered before providing a definitive answer on whether blockchain is needed for this application, and if so, which type. First, it should be clear which parties can be allowed to validate transactions on ancillary service markets. A further open question is the public verifiability: should everyone be allowed to read on the blockchain (i.e., a public permissioned blockchain), or only selected parties (i.e., private permissioned blockchain)?

3.2.2. Blockchain Configuration

This section describes a proposed blockchain concept for the provision of ancillary services (i.e., aFRR in this case) by DA (i.e., EV in this case). The method described in Section 3.1 aims to support the TSO with respect to the verification and settlement phase by the automation of processes. This section links the proposed method to a blockchain architecture to: (a) increase the integrity of the input data which will enhance the reliability of the method proposed in Section 3.1, (b) increase transparency for all participants by agreeing on predefined set of rules (e.g., a smart contract) and (c) enable the possibility to incorporate other participants, such as DSOs for congestion management purposes. A smart contract is defined as an agreement whose execution is both automatable and enforceable. It is automatable by computer, although some parts may require human input and control and enforceable by either legal enforcement of rights and obligations or tamper-proof execution [38].

Figure 5 depicts an overview of all proposed transactions and offers a visual representation of the proposed architecture. The figure distinguishes five different entities operating on the blockchain, presented in the circles, namely the DA owner, CP, DSO, TSO and BSP. Our proposed concept is based on transactions that need to be validated by reaching consensus in the blockchain network before they are accepted on the blockchain. Note that transactions are not restricted to monetary transactions but may also entail merely information exchange.

The proposed types of transactions are designed in such a way that two separate entities (i.e., represented in the circles of Figure 5 are involved in each data log (i.e., parallelograms in transactions 1–12 and C of Figure 5. Therefore, the reliability of the input data increases since the data of the two independent entities should be consistent. To ensure this consistency, the time stamping of the different identities should be similar. Unfortunately, these entities have different and asynchronous timing intervals. It is probably up to the one requesting the service (i.e., the TSO) to indicate which level of consistency is required (e.g., to agree on Universal Time Coordination (UTC)). For aFRR provision it is required to provide an initial response within 30 s, which subsequently requires the difference in two subsequent timestamps to be less than that duration in order to be able to detect the activation. This implies a trade-off between having granular data by syncing the data measures with high frequency which also results in large volumes of data, versus the option of having a lighter system that is easier to monitor and verify, but introduces more uncertainties due to larger mismatches in timestamps.

To give an example of logging a transaction by two entities, the second transaction in Figure 5 represents the DA communicating with the BSP. Both entities register the time, whether the DA is available, their own hashed ID and the hashed ID of the other entity. According to the PBFT consensus model, one of the full validating nodes is assigned to request the blockchain network whether these two data logs match. This results in a voting process by the network in which the votes are replicated and shared amongst the nodes various times to detect any (un)intended inconsistencies in the voting process. If the required majority is achieved and a consensus is reached by the network, then the two data logs are transformed into a transaction. This transaction is then logged on the blockchain with the corresponding timestamp. Three phases can be identified: the operational planning and scheduling phase, the real-time operation phase and verification and the settlement phase. Next, we will continue by elaborating on the proposed concept phase per phase, focusing on an EV as a DA.

Operational Planning and Scheduling by BSP

Logging transactions on the blockchain starts when the EV connects to the CP. The EV logs its ID, that is hashed and thereby pseudonymized to avoid privacy issues. It also logs the hashed ID of the CP and the time of plugging in. The CP logs the same information (i.e., hashed IDs of the CP and EV and the timestamp). As large numbers of these transactions can be expected, the transaction should be accepted on the blockchain using smart contracts, in order to limit the validation efforts required. If the conditions in the smart contract are met, it results in a virtual handshake between the EV and the CP. $T{x}_{handshake}$ (transaction 1) is then accepted on the blockchain with a corresponding timestamp.

The EV owners can communicate their preferences regarding departure time and the desired SoC via a mobile application. This is preferred over the option of always maximally charging the vehicles. Enabling the option to indicate the desired SoC increases the level of freedom for the consumer and the number of time intervals in which upward aFRR can be provided. Some EVs with a low SoC cannot reach 100% at the moment of their indicated departure time due to time constraints, especially in cases when charging would be postponed to deliver the aFRR. Hence, the vehicle cannot join the pool for aFRR provision. However, it might be possible that the consumer is satisfied with a lower SoC. This would mean that less charging time is needed, resulting in more time intervals in which aFRR could be provided.

$T{x}_{available}$ (transaction 2) relates to the above-mentioned processes. The EV logs whether it is available for aFRR based on permission of the owner. The BSP estimates whether the EV is capable of delivering aFRR based on the desired SoC, the charging rate and the available amount of time. If both the EV and the BSP log that the EV is available for aFRR provision and this is validated by the network, then $T{x}_{available}$ is accepted on the blockchain with a corresponding timestamp.

The third step of the planning phase concerns the bidding process by the BSP. It is proposed to use the same mechanism as described in Section 2. However, one important aspect should be considered. In the future multiple BSPs should be added to the blockchain to increase the pool of decentralised assets that can provide aFRR. Needless to say, BSPs do not want their competitors to know the details of their bids. This can be solved by encrypting the transaction as described in Section 2. In this case, the BSP would encrypt the transaction with the public key of the TSO. Subsequently, only the TSO can decrypt the message by using its private key. Hence, the TSO is the only other participant on the blockchain that knows the bids per BSP. Both the TSO and the BSP can log the hash of the bid, which results—when validated by the network—in $T{x}_{bid}$ (transaction 3).

Simultaneously, the DSO is involved in the planning phase. It is important to mention Article 182, paragraph 5, of the guideline on electricity balancing here: “Each reserve connecting DSO and each intermediate DSO shall have the right, in cooperation with the TSO, to set, before the activation of reserves, temporary limits to the delivery of active power reserves located in its distribution system. The respective TSOs shall agree with their reserve connecting DSOs and intermediate DSOs on the applicable procedures” [39]. Thus, the DSO can formulate predefined constraints regarding transformer overloading, cable overloading and voltage deviations, and these constraints can be integrated in smart contracts. Whenever these constraints are violated the option to activate reserve providing assets in the specific distribution network could automatically be excluded by the smart contract and $T{x}_{available}$ is transformed into $T{x}_{unavailable}$. The proposed solution offers the opportunity to develop procedures related to Article 182 in a predefined, automated and transparent way and is depicted by $T{x}_{article 182}$ (transaction C). It should be noted here that this would be in conflict with the freedom of dispatch of connected parties. Alternatively, a DSO could use the blockchain merely to communicate its preferences, or in a system with local energy markets provide incentives focused on fostering the DSO’s operations.

Real-Time Operations

At the beginning of an activated bid, the first setpoint sent by the TSO and received by the BSP is logged as $T{x}_{setpoints start}$ (transaction 4). From this point in time, the EV and CP start logging the provided flexibility $\Delta P_{provided}^t$ by the individual EV after aFRR activation on the blockchain according to Equation (1) of Section 3.1. Because of the simplified reference signal, this can all be logged directly based on the actual power output at the CP. Both the EV and the CP keep logging $\Delta P^t$ during the activation which is logged as $T{x}_{\Delta P_{EV}^t}$ (transaction 5). The proposed verification method in Section 3.1 focuses on the aFRR response on BSP level and not on EV level, since the TSO activates, monitors and settles on BSP level. Therefore, a smart contract is deployed to automatically aggregate the $\Delta P_{provided}$ by the individual EVs to the $\Delta P_{provided}$ of the pool according to Equation (6):

$$\Delta P_{BSP}^t={\displaystyle \sum }_{k\in N}\Delta P_{provided,EV,k}^t$$

(6)

where $\Delta P_{BSP}^t$ represents the total flexibility provided at time interval t and by the aFRR pool, consisting of EVs indexed by $k\in \left\{1,2, \dots , N\right\}$. This is reflected by transaction 6. The TSO and the BSP keep logging the flexibility provided until the end of the activation which is indicated by the setpoint-0, sent by the TSO. The TSO and the BSP both log this final setpoint of the activation, which is after validation, referred to as $T{x}_{setpoint end}$ (transaction 7). The BSP then sends a signal to the EVs to resume the original charging operation.

If the EV is still available for aFRR, depending on its desired SoC and the remaining time until departure, it returns to the status in which it is available to provide aFRR, reflected by $T{x}_{available}$ (transaction 2). If the asset is not able to deliver aFRR in any later time intervals, $T{x}_{unavailable}$ (transaction 11) is logged by the BSP and the EV and the asset is excluded from the aFRR pool. The final transaction is logged when the EV plugs out. Both the EV and CP log this transaction as $T{x}_{unshake}$ (transaction 12). This information could be used by the BSP, that is responsible for the aFRR provision of their entire pool of DA, to distribute compensation among individual assets.

Verification and Settlement

This phase starts immediately after the end of ISP of the activation, since the aFRR price is determined at the end of each ISP. Hence, it can occur that transaction 8, 9 and 10 are logged earlier in time than $T{x}_{unavailable}$ (transaction 11) and $T{x}_{unshake}$ (transaction 12) which are still part of the operation phase.

Transaction 8, 9 and 10 relate to the verification and settlement phase. Transaction 8 relates to the verification method described in Section 3.1. Hereafter, a smart contract could be used to automatically calculate the activated aFRR volume of activation A, $E_{aFRR}^A$, by summing the flexibility provided by the BSP $\Delta P_{BSP}^t$ over time according to Equation (7):

$$E_{aFRR}^A={\displaystyle \sum }_{t=1}^{t_{ISP}}\Delta P_{BSP}^t\ast \Delta t$$

(7)

where $E_{aFRR}^A$ is the volume (energy) of aFRR provided during an activation with $\Delta t$ as the time duration of the interval. This is reflected by transaction 9. Note that in the case of upward and downward aFRR provision within one ISP, the $E_{aFRR}^A$ needs to be calculated separately for upward and downward aFRR.

The financial settlement is based on multiplying the delivered aFRR volume with the aFRR price of that specific ISP, which can also be automated via a smart contract. This is represented by transaction 10, $T{x}_{settlement}$. It should be noted that the BSP can execute the verification and settlement process on the asset level according to the same strategy. The EV and CP log the change in power output due to aFRR activation. The BSP needs to have a contract with the EV owner that determines the settlement between BSP and EV and/or charger. Examples could be a discount on charging sessions, a discount on energy contracts or a financial reward per activation.

On the longer term, it could be the case that a true Economy of Things could emerge [40]. This would require a DLT preferably with high scalability, minimum transaction fees and a lightweight consensus model to avoid high energy consumption and high transaction latency. For such an application, a DAG (such as the Tangle of IOTA, described in Section 2.4) seems to be a suitable technology. However, as this technology is still in an early phase of development and is thus accompanied by a high degree of uncertainty, aggregators are still included in our proposed blockchain architecture. Among the more proven technologies, the cryptocurrency Ripple [41] shows good performance, with around 500,000 transactions per day in 2019 [42] and a transaction speed of over 10,000 transactions per second [35]. Ripple’s consensus protocol employs collectively trusted subnetworks to speed up transactions. To achieve consensus, a node is only required to check within its own subnetwork rather than the complete network [35]. In any case, it is recommended to implement a relatively light consensus model, as all nodes are registered and identified, to increase transaction speed and to decrease energy consumption.

3.3. Future Outlook: Considerations for Blockchain Technology in aFRR Provision

From the possible blockchain layouts, the private and permissioned blockchain seems to be most suitable for this purpose. Given the interests at stake, it must be closely monitored and evaluated who is granted access to the blockchain, and what rights each individual participant has. One advantage of using blockchain is that compared to having one party responsible for the verification of all transactions (i.e., the TSO in the application under consideration/study), the responsibility is shared.

However, various considerations have to be taken into account before a definitive answer can be given about the potential of blockchain for the provision of ancillary services with DA. Firstly, an incentive would be required for BSPs (or other participants) to validate transactions on the blockchain. This could entail additional costs—it should be determined whether the added benefits surpass the additional costs. A second major challenge is the number of transactions that are expected. In the first two months of 2019, there were on average a little over 300,000 bitcoin transactions per day [43]. As is well-known, this has led to gigantic energy consumption and transaction times [44]. The former is obviously problematic in the context of the energy transition. However, having a private and permissioned blockchain configuration, where no mining is required, and all parties involved are known and trusted by the network could be seen as a solution for this challenge. The latter could intervene with how markets operate. With many countries designing policies to promote the adoption of EVs, it is not difficult to imagine that the amount of EVs on the road would be in the order of magnitude of millions. As suggested in Section 2.4, one could opt for a lighter consensus mechanism, but a trade-off exists with the security of such a mechanism. Furthermore, solutions with higher transaction rates are at an early stage of development, and thus questions about their scalability still exist.

A further problem with the blockchain is that it could be difficult to control energy trading if many players can validate. In blockchain, it could occur that two blocks are created simultaneously; the block that has more blocks chained to it afterwards is included in the “valid chain”, while the other is considered an orphan block. In the case of aFRR provision with DA, protocols need to be designed to prevent a DA pool from delivering the aFRR, but not receiving compensation.

Lastly, controlling the DA themselves does not need to happen on a blockchain-based architecture. Market parties can just control the EVs from their own back end and control infrastructure. However, currently the required hardware is not in place to enable the proposed solution. It should be noted that some CPs can only measure on a time resolution of 15 min, which is insufficient to log the power output for verification of provided flexibility. However, ElaadNL (the Dutch knowledge centre in the field of smart charging infrastructure) and the Dutch DSOs, as an example, have decided to start implementing the SMR-5 m in CPs that are capable of registering every second [45]. Therefore, it is assumed that in the future, it will be possible to measure power response on a high resolution via both the EV and CP. Besides, currently leased lines are used between the TSO and BSPs as a communication infrastructure for aFRR provision, which is a rather expensive option, especially considering a future with a large number of participating BSPs in aFRR service provision. With more stakeholders involved, it is likely that the communication infrastructure will exploit the mobile network and the internet.

Taking these considerations together, our strong recommendation is to increase the research effort for a future configuration of aFRR provision by DA. DLTs need to be compared to solutions that do not rely on these technologies. Within solutions based on DLTs, different consensus mechanisms need to be constructed and compared. Given the fast developments in this field, it is too early to give a definitive answer on whether DLT are a suitable solution, let alone which DLT and/or consensus mechanism.

4. Concluding Remarks

A future power system is expected to rely more and more on DA. Given the inherent variability and difficulty of forecasting energy resources that are influenced by weather patterns, such as solar and wind, and the phase-out of traditional suppliers of flexibility, new solutions must be found to ensure the functioning of the power system. The fast-increasing deployment of EVs offer an opportunity here, as these DA are characterised by fast ramping up or down charging rates.

In this paper, we propose a new system design for the verification method when providing aFRR with DA. The most important alteration we propose is to change the reference signal that a BSP must send to the TSO with a prediction of their load, to the measured instantaneous power at the moment right before activation of the aFRR. This facilitates the automation of this process. To scale up the provision of aFRR by DA, new concepts are needed. We provided a possible future configuration for this, which can serve as a basis for development of a blockchain, or other DLT implementation, for the provision of aFRR by EVs specifically, but also for provision of ancillary services by DA in general. We see private permissioned blockchain as the most suitable option. Within this field, the consensus mechanism operated by Ripple shows promising performance. Other interesting DLT solutions are the ones based on DAG, however, these are still at a very early stage of development.

The presented blockchain-based solution for the aFRR market has been implemented in practice in a pilot by the Dutch TSO and recently also in collaboration with the TSOs of Germany, Switzerland and Italy. Blockchain technology has several advantages for the considered application as it can ensure that all the transactions by the stakeholders involved in the aFRR market are immutable and verifiable. Besides, it enables the possibility to validate aggregate measurements with individual device measurements (e.g., via smart meters and charging stations). We argue that the practical feasibility at large scale, considering the legacy systems and the retrofitting solutions, must be assessed in a case-by-case since each TSO, as well as the ISO, have their own legacy system in place.

The proposed configurations and design serve as a basis for supporting future bench-marking studies. Various considerations need to be taken into account for future research. First, different blockchain architectures and/or other DLTs need to be tested further, validated in practice and compared to each other. Also, non-DLT solutions could be considered. An important performance indicator is the time and energy needed for validation. This testing is needed to reach a definitive answer on whether these technologies can be used for providing ancillary services with DA. Furthermore, it should be critically assessed what information needs to be stored on the blockchain, which energy market players can play the role of validators, what would be a suitable incentive mechanism for the validation effort and how it is verified whether the validation itself is executed correctly. A further open question is the level of transparency: should everyone be allowed to read-encrypted-transactions, or only a selected group of participants? In the former case, instead of a private permissioned blockchain, a public permissioned blockchain would be more suitable. In general, the benefits of the blockchain must be made clear and tangible and weighted against the disadvantages.