PaperlayerView exact revision on arXiv

Source-linked AI summary

Energy Crowdsourcing and Peer-to-Peer Energy Trading in Blockchain-Enabled Smart Grids

Shen Wang, Ahmad F. Taha, Jianhui Wang, Karla Kvaternik, Adam Hahn

arXiv:1901.02390v2eess.SY

TL;DR

The paper addresses the need for trusted platforms, real-time management methods, and secure infrastructure for prosumer-based grids with distributed energy resources and energy trading. It develops an OPF-based crowdsourced energy-system model, a two-timescale operating approach, and an IBM Hyperledger Fabric prototype for P2P trading and operator coordination.

  • Problem

    Prosumer-based grids require trusted software, distributed control methods, and secure infrastructure to manage distributed energy resources and large numbers of energy-trading transactions.

  • Method

    The paper combines an OPF-based crowdsourced energy-system model with day-ahead and faster-timescale operation for batteries, shapeable loads, DERs, and energy transactions, implemented using IBM Hyperledger Fabric.

  • Results

    The framework yields a day-ahead market equilibrium, designs incentives for hour-ahead and real-time adjustments, and prototypes blockchain-supported management of P2P energy trading.

  • Takeaways & Limitations

    The operational model supports prosumer-prosumer and prosumer-utility trading and can also be used to operate islanded microgrids.

  • Takeaways & Limitations

    The blockchain contribution is presented as a prototype implementation through IBM Hyperledger Fabric.

Abstract

from arXiv · show

The power grid is rapidly transforming, and while recent grid innovations increased the utilization of advanced control methods, the next-generation grid demands technologies that enable the integration of distributed energy resources (DERs)---and consumers that both seamlessly buy and sell electricity. This paper develops an optimization model and blockchain-based architecture to manage the operation of crowdsourced energy systems (CES), with peer-to-peer (P2P) energy trading transactions. An operational model of CESs in distribution networks is presented considering various types of energy trading transactions and crowdsourcees. Then, a two-phase operation algorithm is presented: Phase I focuses on the day-ahead scheduling of generation and controllable DERs, whereas Phase II is developed for hour-ahead or real-time operation of distribution networks. The developed approach supports seamless P2P energy trading between individual prosumers and/or the utility. The presented operational model can also be used to operate islanded microgrids. The CES framework and the operation algorithm are then prototyped through an efficient blockchain implementation, namely the IBM Hyperledger Fabric. This implementation allows the system operator to manage the network users to seamlessly trade energy. Case studies and prototype illustration are provided.

I. INTRODUCTION

The paper addresses the need for trusted platforms, distributed control, and scalable computational methods as prosumers and DERs transform electricity generation, consumption, and utility roles. It proposes a crowdsourced energy framework combining operational models, a two-phase algorithm, P2P trading, and blockchain implementation.

  • Motivation: Prosumers and DERs decentralize the grid and shift utilities from selling electricity toward providing transmission and distribution services.This shift creates requirements for trusted software, distributed operation and control, and computational methods supporting reliable operations and prosumer engagement.
  • Motivation: Energy crowdsourcing coordinates tasks such as EV charging, battery operation, load deferral, and renewable supply to address near-real-time demand shortages or surpluses.These tasks can be automated through smart inverters, plugs, and meters interfaced with utilities and blockchain infrastructure.
  • Research gap: Existing approaches may produce DER and load setpoints that prosumers do not adopt, omit prosumer-to-prosumer trading, and face blockchain scalability limitations.The paper identifies these as limitations of current OPF-based modeling and blockchain implementations.
  • Contributions: The proposed operational framework models distribution-level P2P trading among diverse crowdsourcees while an operator clears the market and enforces technical constraints.The framework also extends to operator-free islanded microgrids.
  • Contributions: A two-phase algorithm combines day-ahead scheduling with hour-ahead or real-time balancing through monetary incentives, supporting P2P trades between prosumers and utilities.The algorithm is designed for distribution-network operation and islanded, self-autonomous microgrids.
  • Contributions: The CES framework is prototyped in IBM Hyperledger Fabric, allowing operators and users to manage accounts and trade energy with utilities or neighborhoods.The prototype communicates with the two-phase algorithm and is described as open source for utility use.

III. INTEGRATED OPERATIONAL MODEL OF CESS

The operational model represents a crowdsourced energy system on a radial distribution feeder with diverse DERs, crowdsourcee types, and energy-trading transactions. It distinguishes day-ahead participants from faster-timescale participants and defines operator-mediated and peer-to-peer trading.

  • Network and participants: The model covers radial distribution networks with diverse DERs, crowdsourcees, and energy-trading transactions.The feeder is represented as a tree graph with buses for utility generation, crowdsourcing users, and loads.
  • Network and participants: The crowdsourcer is the utility or another system operator, while crowdsourcees are divided into Type 1 and Type 2 participants.The two participant types correspond to different control commitments and operating timescales.
  • Crowdsourcee types: Type 1 crowdsourcees commit day-ahead or provide complete DER control in exchange for socio-economic incentives or bill discounts.Their participation provides operators with day-ahead planning flexibility.
  • Crowdsourcee types: Type 2 crowdsourcees make near-real-time adjustments after operator notifications based on their network location and the grid’s physical state.They operate on a faster timescale than Type 1 crowdsourcees.
  • Energy-trading transactions: Type A transactions send power from Type 1 or Type 2 crowdsourcees to the network operator, whereas Type B transactions let crowdsourcees trade with one another.Because Type 1 production and demand response are operator-controlled, Type B transactions occur only among Type 2 crowdsourcees.

A. Operational Model of Generators, Loads and DERs

The operational model represents conventional generation, solar panels, batteries, uncontrollable loads, and shapeable loads across distribution-system buses and time periods. It distinguishes utility-controlled and user-controlled solar decisions while modeling batteries as dispatchable resources.

  • The model includes dispatchable synchronous generation, solar generation, controllable stationary batteries, uncontrollable loads, and shapeable loads indexed by bus and time.
  • Dispatchable generators use quadratic cost functions with parameters α_i,t, β_i,t, and γ_i,t.
  • CT 1 crowdsourcees let the utility or operator control solar injection, whereas CT 2 crowdsourcees choose local use or sale to the operator or other users.
  • Batteries are modeled as dispatchable loads that withdraw or inject power, with negative P^b_i,t indicating withdrawal.Charging and discharging efficiencies, stored energy bounds, and charging or discharging power limits are included in the battery model.
  • The net battery power P^b_i,t equals discharging power minus charging power, with separate limits for each direction.

4) Uncontrollable Loads:

The model treats uncontrollable loads as given and represents shapeable loads with flexible power profiles, fixed daily energy demand, and allowable operating windows. These loads are collected in a vector for optimization.

  • Uncontrollable loads, including lights, plug loads, and street lights, are treated as given quantities S^u_i,t.
  • Shapeable loads S^s_i,t include electric vehicles and appliances with flexible power profiles but fixed 24-hour energy demand E^s_i,demand.
  • Shapeable loads must be satisfied within each load’s interval from t_i,start to t_i,end.
  • The shapeable-load model sets its power variable to zero outside the permitted operating interval over a horizon of T time periods.The formulation uses time interval Δt and collects shapeable-load variables in x^s_i,t.

B. Distribution Network Model

The distribution-network model uses branch-flow variables and a convex SOCP relaxation to represent electrical operation efficiently. It organizes battery and shapeable-load decisions by crowdsourcee type for CES optimization and incentive design.

  • For each bus, the model defines complex voltage, squared voltage magnitude, and net complex and real power injections.
  • For each line, it defines parent and child buses, complex impedance, branch current, squared current magnitude, and branch power flow.
  • The variable vector x_t collects battery and shapeable-load variables, then separates them into x^1_t and x^2_t for the two crowdsourcee types.
  • The branch-flow model removes voltage and current phase angles and uses only squared voltage, squared current, bus power, and branch-flow variables.
  • A second-order cone relaxation converts the nonconvex branch-flow model into convex constraints solvable efficiently by an interior-point method in polynomial time.
  • The CES algorithm minimizes generation cost and thermal losses while rescheduling shapeable loads and DERs, supporting P2P trading and islanded microgrid operation.

A. Phase I: Day-Ahead CES Operation

Phase I performs day-ahead CES-OPF scheduling using forecasts, user preferences, and prescheduled trades, then computes equilibrium schedules and DLMPs for subsequent operation. Type 2 users’ trading choices are incorporated through energy-trading constraints.

  • CT 1 users’ DERs are controlled by the operator, while CT 2 users decide participation based on preferences and offered incentives.
  • CT 2 users may sell surplus solar power to the utility when incentives are sufficient or acceptable in hour-ahead or real-time markets.
  • Users who decline Type B trades have the corresponding trading quantities set to zero in the power-balance model.
  • Other CT 2 sellers and buyers submit day-ahead supply-demand requests, represented by EnergyTrading(x^2_t, y_t) constraints.
  • CES-OPF minimizes generator costs together with thermal losses across distribution lines.
  • User preferences, day-ahead forecasts, voltage bounds, and generation constraints are incorporated into the optimization and can support centralized or decentralized solution methods.
  • After CES-OPF, equilibrium generation, battery, and shapeable-load schedules are fixed for 24 hours, and DLMPs are computed from real-power-balance dual variables.

B. Phase II: Real-Time CES Incentives Design

Phase II develops near-real-time incentives for Type 2 crowdsourcees, using forecast updates and net energy injections to address demand and solar-output fluctuations. CES-ID minimizes operating deviations, losses, and incentive budgets while supporting utility energy trading.

  • Incentive design: Phase II uses crowdsourced incentives to relieve near-real-time demand shortages or surpluses caused by forecast errors.The design offers additional incentives to Type 2 crowdsourcees based on energy provided to the grid.
  • Phase II information: Type 2 crowdsourcees cannot schedule shapeable loads and batteries 24 hours ahead because they have no utility contract.During Phase II, these loads are treated as uncontrollable, while solar generation is known ahead of time.
  • Incentive design: CES-ID uses known net injection power to design incentives for Type 2 crowdsourcees at each time.The routine formulates incentive decisions around the net injection power provided to the grid.
  • Optimization objective: CES-ID minimizes generation-cost deviation from the day-ahead point, network thermal losses, and the Type 2 incentive budget.The optimization includes generation, network, and budget objectives.
  • Computation and settlement: CES-OPF and CES-ID use a convex branch-flow model solvable efficiently in polynomial time, with CES-ID solved hourly.Computed incentives are sent to users at the end of the day, and blockchain assists the resulting Type A transactions.

V. BLOCKCHAIN AND SMART CONTRACTS IMPLEMENTATION FOR CESS

The paper presents a blockchain implementation designed to scale the proposed optimization models to millions of crowdsourcees and energy-trading transactions. It also integrates the optimization algorithms with that blockchain implementation.

  • The implementation targets scalability for millions of crowdsourcees and energy-trading transactions.
  • The blockchain design integrates the optimization models introduced in Sections III and IV.
  • An algorithm is presented to connect the optimization models with the blockchain implementation.

A. Blockchain and Smart Contracts Implementation for CESs

The implementation maps CES requirements to a permissioned Hyperledger blockchain with smart contracts and an operator-managed workflow. Its two-phase algorithm links day-ahead and hour-ahead optimization to energy-trading contracts.

  • Platform requirements: Blockchain selection considers user membership, computational requirements, consensus performance, and user privacy.These requirements are mapped to blockchain features in Table V.
  • Platform selection: Hyperledger is selected because its RBFT consensus, permissioned membership, and chaincode support fit CES requirements.The permissioned model restricts participants to the distribution-grid service region and supports privacy protection.
  • System governance: The system retains a utility or system operator to manage the grid, support trades, clear the market, and enforce technical constraints.The operator ensures that trading does not violate limits such as distribution-line limits.
  • Implementation architecture: The implementation uses three modules: optimization, a Node.js communication application, and an IBM Hyperledger Fabric information system.Fabric peers communicate, execute Go chaincode, and maintain state and ledger data.
  • Phase I: The operation algorithm obtains preferences and day-ahead P2P requests, estimates forecasts, solves CES-OPF, and establishes Type A and Type B contracts.
  • Phase II: During Phase II, the algorithm selects willing Type 2 sellers, obtains hour-ahead forecasts, solves CES-ID, and communicates incentives.
  • Implementation characteristics: The implementation is described as scalable to millions of crowdsourcees, easy for users, compatible with optimization formulations, and energy-efficient.Energy-trading records are maintained and synchronized across peers.

VI. CASE STUDIES

The case study evaluates the CES framework on a modified Southern California Edison 56-bus feeder with batteries, solar panels, and two crowdsourcee types. It illustrates utility trades and peer-to-peer trades through the proposed transaction scenarios.

  • Simulation setup: The numerical tests use the Southern California Edison 56-bus test feeder over a 24-hour horizon.Uncontrollable load profiles are generated from CAISO data and normalized for feasible optimization problems.
  • Case-study outputs: Figure 5 presents the energy-trading transaction scenarios, while Figure 6 presents aggregate load and generation after CES-OPF.
  • Simulation setup: The modified feeder places stationary batteries, solar panels, uncontrollable loads, and shapeable loads at each bus.Batteries have 80% of local peak uncontrollable-load power capacity, four-hour storage, and 20% initial energy.
  • Crowdsourcee assignment: Each bus is assigned either a Type 1 or Type 2 crowdsourcee, producing 40 Type 1 and 16 Type 2 users.Prime-numbered buses are assigned Type 2 status; the remaining buses are Type 1.
  • Energy-trading scenarios: Type A transactions occur between crowdsourcees and utilities, whereas Type B transactions occur among Type 2 users.The examples show Node 2 selling excess solar energy to the utility and Node 43 buying energy from Node 53.

B. Results and Discussions

The results compare CES-OPF scheduling with unscheduled operation and examine incentive-based real-time trading, including distribution-network and islanded-microgrid cases.

  • Phase I: Day-Ahead CES Operation: CES-OPF reschedules CT 1 shapeable loads and coordinates solar injections, batteries, and controllable loads relative to the original profile.The comparison is between operation without crowdsourcing or trading and CES-OPF over T = 24 hrs.
  • Phase I: Day-Ahead CES Operation: The CES-OPF battery charges during solar production, while limited solar generation restricts changes in the overall CES-OPF profile.The paper directs readers to the islanded microgrid test for cases with sufficient solar production.
  • Phase I: Day-Ahead CES Operation: Lower DLMPs at Nodes 1 and 55 result from Type 1 crowdsourcees’ net injections after DER rescheduling and renewable-energy injection.Fig. 7 compares DLMPs with and without scheduling DERs through CES-OPF.
  • Phase II: Real-Time CES Incentives Design: Phase II incentives vary with DLMP and net injection, rewarding Node 2’s solar contribution and coordinating Node 53’s surplus with Node 43’s battery demand.Node 43 charges between 9 am and 2 pm; Node 53 receives utility incentives and negotiated payments during different periods.
  • Phase II: Real-Time CES Incentives Design: After Algorithm 1, CT 2 renewable energy is injected and traded through incentives, while unexpected CT 2 load demand is covered by the substation generator.The utility cannot schedule CT 2 shapeable loads, and the unexpected demand appears in the aggregate profile.

3) Islanded Microgrid Test:

The paper illustrates its CES framework through an islanded microgrid scenario and a Hyperledger Fabric prototype, while identifying blockchain-security risks and future consensus work.

  • Islanded microgrid test: The islanded microgrid simulation assumes users have sufficient solar generation, adequate battery storage, and fully controlled DERs.All users participate in the program under the microgrid management algorithm.
  • Prototype illustration: The Hyperledger Fabric prototype supports user management, energy sales to utilities or neighborhoods, and transaction listings with prices and users.The web application interacts with optimization solvers, forecasting algorithms, and crowdsourcees.
  • Limitations: Blockchain-based energy trading remains exposed to malicious operators, stakeholders, and outsiders who may target algorithms, bids, messages, or clearing prices.Digitally signed Hyperledger messages protect consensus results when there are 2f + 1 total operators for f malicious operators.
  • Future work: Future work will address distributed blockchain consensus and threats from malicious crowdsourcees, market operators, and outsiders.These extensions target unresolved security concerns in crowdsourced energy systems.
Loading 1901.02390v2…