WO2019070357A1

WO2019070357A1 - Method and system for secure and private forward trading platform in transactive microgrids

Info

Publication number: WO2019070357A1
Application number: PCT/US2018/049004
Authority: WO
Inventors: Aron LASZKA; Michael Walker; Abhishek Dubey; Karla KVATERNIK
Original assignee: Siemens Aktiengesellschaft; Vanderbilt University
Priority date: 2017-10-06
Filing date: 2018-08-31
Publication date: 2019-04-11

Abstract

A system and method for private and secure forward trading of energy assets in a microgrid includes smart contract agents of a blockchain platform that receive forward offers to exchange energy on the microgrid, including an energy amount, time intervals for the exchange, and a unit price. The information for all offers are forwarded to at least one off-blockchain solver engine, in a request for an optimized solution for matching offers, the optimization based on maximizing the amount of energy exchanged on the microgrid within microgrid safety constraints. The smart contract agents receive, from the solver engine, a candidate solution as a vector pair of a constrained linear formulation with a non-negative amount of power to be exchanged in a defined time interval, and a unit price for the energy exchange. The smart contract agents verify that the candidate solution satisfies the microgrid safety constraints.

Description

METHOD AND SYSTEM FOR SECURE AND PRIVATE FORWARD TRADING PLATFORM IN TRANSACTIVE MICROGRIDS

TECHNICAL FIELD

[0001] This application relates to power grids. More particularly, this application relates to a platform for secure and private forward trading in transactive microgrids.

BACKGROUND

[0002] A new vision for the future of power-grid operations is emerging. A decentralized system in which local communities are arranged in microgrids is now considered a viable solution, in which energy generation, transmission, distribution, and storage (i.e., electric vehicles, or wall-mounted residential batteries) can be strategically used to balance load and demand spikes. Additionally, microgrids can improve system reliability and efficiency by integrating inverter-based renewable resources into the grid and by supplying power to the local loads when the main grid is interrupted.

[0003] Transactive energy refers to a set of market based constructs for dynamically balancing the demand and supply across an electrical infrastructure of distributed energy nodes instead of the conventional hierarchal grid structure. Accordingly, customers on a common feeder can locally trade and exchange generated energy. However, realization of this market is still difficult because of three integrated problems that must be addressed.

[0004] The first problem relates to ensuring the physical stability and safety of the grid apparatus, and is mainly concerned with dynamically balancing supply and demand without violating line capacity constraints. The second is a distributed systems problem, which requires ensuring that this peer-to-peer market operates in a trustworthy manner even if some of the nodes are malicious. The third problem is related to privacy. Data collected from energy transactions is expected to be more fine-grained than data collected by currently deployed smart meters, and may be used to infer personal information about the market participants. For example, a participant's presence or absence at their residence might be inferable from their trading patterns. Note that energy futures, whose delivery may happen several hours after when the transaction is made, can play an important role in predicting and controlling microgrid load. In comparison, smart metering reveals only current (or past) usage.

SUMMARY

[0005] Aspects according to embodiments of the present disclosure include a transactive management platform (TMP) including an engine for executing automated, trusted microgrid forward trades of energy at the distribution level. A solver engine matches incoming offers as an automated auction in a way that ensures safety (i.e. capacity constraints are not violated) and preserves privacy (market participants are to remain anonymous), while maximizing local market throughput (i.e., promoting the amount of energy locally traded) and market efficiency. The technical solution disclosed herein solves a direct conflict between safety and privacy on the one hand and market efficiency on the other. Prosumers of the microgrid may utilize the TMP to post offers that are flexible in selecting multiple time intervals for providing energy, including preferred times for discharging battery stored energy.

[0006] The TMP may be used by a Distribution System Operator (DSO) to implement a regulation market on a microgrid by following an aggregated time variant demand signal throughout the day. The ability to closely regulate the demand curve enables efficient preplanning of generation resources by the DSO. The TMP may be operated to post offers for energy trades by the DSO, by microgrid participants (i.e., prosumers), by a third party on behalf of the DSO and/or some microgrid participants, or a combination thereof.

[0007] The TMP may implement algorithms on a decentralized trading platform based on blockchain technology.

[0008] The TMP allows transaction matching across feeders, and across time slots. Blockchain based agents may implement a smart contract for verification of candidate solutions for feasible matching of multiple offers. A non-blockchain based solver engine may periodically solve a linear program that outputs the matching solutions to the smart contract agents. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Non-limiting and non-exhaustive embodiments of the present embodiments are described with reference to the following FIGURES, wherein like reference numerals refer to like elements throughout the drawings unless otherwise specified .

FIG. 1 shows a diagram for an example of a multi-feeder microgrid in accordance with embodiments of the disclosure.

FIG. 2 shows a block diagram for an example of a transactive management platform (TMP) operating in accordance with embodiments of the disclosure.

FIG. 3 shows a diagram for an example of communications and events during operation of the TMP in accordance with embodiments of the disclosure.

FIG. 4 shows a diagram for an example of an energy trading system model using the TMP in accordance with embodiments of the disclosure.

FIG. 5 shows an exemplary computing environment within which embodiments of the disclosure may be implemented.

DETAILED DESCRIPTION

[0010] FIG. 1 is a diagram for an example of a multi-feeder microgrid in accordance with embodiments of the disclosure. Microgrid 110 includes feeders F1, F2...FN, each feeder having a number of nodes, including prosumer node 120 and consumer node 130, each node representing a residential load or a combination of load and distributed energy resources (DERs) (e.g., rooftop solar panels and batteries). A prosumer node is one with the capability to sell energy and consumer nodes are interested in buying energy in a local peer-to-peer energy trading market. Each feeder may be protected by an overcurrent relay at the junction of the common bus. Each prosumer node 120 includes loads 122, a smart meter 123, and DERs 121, such as a type including solar panel, battery, windmill, or the like. Each consumer node 130 in the microgrid has different kinds of loads 132, some of which can be scheduled in advanced, making it possible for a consumer to bid in advance for supply times and price of energy to serve loads individually or as blocks of loads. The smart meter 133 may ensure proper billing per node. Smart contract agents 141 (e.g., a decentralized computing platform, such as a blockchain computer network using an Ethereum platform) may record all the transactions of the microgrid as a smart contract record, such as between prosumer node 120 and consumer node 130, in part by monitoring smart meters 123, 133. The smart contract record may be used for scheduling energy transfers between microgrid nodes and may be used by a Distribution System Operator (DSO) 151 to produce a monthly bill. The DSO may supply residual demand not met through the local market and may act as the custodian of the smart contract. In an embodiment, one or more solver engines 142 may complement the smart contract agents 141 by taking on heavy processing required to solve an optimization problem of matching buy and sell offers for an efficient market exchange. With the smart contract agents 141 relieved of optimization computing tasks, improved performance and efficiency of auditability and trustworthiness operations of a transactive management platform is gained, as will be explained in further detail below.

[0011] FIG. 2 shows a block diagram for an example of transactive energy system activities to be validated in accordance with embodiments of the disclosure. In an embodiment, a transaction management platform (TMP) 220 may be implemented as blockchain based smart contract agents 222 complemented by one or more off- blockchain solver engines 221 for optimized and trusted microgrid forward trades of energy at the distribution level, such as transaction activities 210. The solver engines 221 may be implemented as a high-performance computer for solving a computationally expensive linear program. The energy trading process may be formulated and solved by the solver engines 221 as a linear program which will be described in further detail below. The smart contract agents 222 may be implemented as a computer network that supports quasi-Turing-complete computation (e.g., a peer to peer network, or Ethereum Virtual Machines (EVM)), and may verify that proposed solutions from one or more solver engines 221 are feasible and may select the best solution from the candidate solutions. The final selected solution may then be recorded to a smart contract by the smart contract agents 222. In an embodiment trading activities for a transactive energy system may include the smart contract agents 222 recording trading parameters for consumers 201 and prosumers 202 for which buy and sell offers have been matched according to a set of optimization constraints. For example, input data from the consumers 201 and prosumers 202 may be received by DSO 203, which may be submitted using a web based application. Permitting trade settlements in advance (i.e., forward trading) allows the participants (i.e., DSO 203, prosumers 202 and consumers 201 ) to decide the amount of energy to be transferred into the local network and at what times. For example, posted offers from prosumers 202 to sell produced energy, or offers from consumers 201 to buy and consume energy may be received by the DSO 203. An offer may consist of quantity of energy being bought or sold, the time interval in which the trade is to be made, and a reservation price, such as the maximum or minimum price at which the buyer or seller is willing to trade. The TMP 220 may include a security component to electronically sign and publish the financial transaction 212, including information such as amount of energy and the financial value for billing purposes. The TMP 220 may process an exchange of energy and financial assets upon the agreement (e.g., a credit or debit transaction) as a recorded trade agreement in a smart contract protected from tampering by the decentralized blockchain. The DSO 203 may perform an energy production validation 213 by monitoring meter reading of prosumer 202 and by monitoring meter reading of consumer 201 for energy consumption validation, after which the financial exchange of assets may be executed by DSO 203. The TMP 220 may include a security component to electronically sign and record the actual energy transaction 214, which may include information such as amount of energy exchanged and a financial transaction ID.

[0012] Operational Safety and Cyber-Physical Security

[0013] The TMP 220 may be configured to include rule based constraints that ensure trading activity does not compromise operational safety regarding the stability of the physical system operation. Moreover, rule based congestion constraints along any feeder may be enforced by TMP 220. Specifically, each feeder is rated for a maximal power capacity, based on limited thermal properties of conductors. Therefore, it is important to ensure that local energy trade settlements involve net power production and consumption which result in instantaneous power flows that never violate this safety constraint. Furthermore, in the context of grid-connected microgrids, system stability refers to real-time balancing - i.e. the system's ability to dynamically match supply and demand as closely as possible, and a tendency to drive the difference between supply and demand to zero under small perturbations.

[0014] The TMP 220 improves resiliency of the microgrid, which includes the system's ability to react to contingencies and recover from faults. Because the smart contract of TMP 220 is decentralized, any failure, misbehavior or compromise of any limited set of elements cannot alter the functionality of the platform. Decentralization may be achieved through allowing multiple solver engines 221 to be deployed and operated to solve the offer matching optimization, and implementing a smart contract that can be executed on decentralized ledgers, such as a blockchain network of smart contract agents 222.

[0015] Solver engines 221 and smart contract agents 222 may also include rule based constraints to ensure that malicious or negligent trading activity is discouraged. Negligent trading may include energy producers 202 who commit to a certain production level and fail to deliver. Solver engines 221 and smart contract agents 222 may include rule based constraints to ensure transactional security by recording the execution of contractual obligations among all participants, including the DSO 203.

[0016] Market Security and Efficiency

[0017] The TMP 220 may include provisions for ensuring the protection of consumer interests, as well as those of the DSO. Consumer interests include being billed correctly based on energy prices set by the market and the measurements made by the smart meters. The TMP 220 may provide market logic that promotes market efficiency by maximizing transaction volume. Additionally, the TMP may ensure all prosumers will be allowed to participate in the market fairly without discrimination or favoritism as the rules and constraints applied by the TMP are driven by maximizing energy trading and utilization of the local energy supply while preserving system safety limits.

[0018] Privacy

[0019] Information such as the amount of energy produced, consumed, bought, or sold by any prosumer should be available only to the DSO and the essential market functions of the TMP. The TMP may be configured such that all bids and asks, and the matching thereof, remain anonymous. The TMP may be configured such that a participant's energy usage patterns and personal information, such as financial standing, is not to be inferable from the participant's trading activity.

[0020] The hybrid platform implemented by the TMP 220 is unlike popular blockchain systems which suffer from design limitations that prevent their direct application to validating energy trades. In particular, the time to complete transaction-confirmation by conventional blockchain platforms is relatively slow and variable, primarily due to the proof-of-work algorithm and most of the communication occurring via the ledger. Additionally, proposed blockchain solutions lack privacy, as all transactions in such systems are public, in contrast with the disclosed TMP which enables prosumers to transfer assets to anonymous accounts prior to trading. Another known solution involves a double-auction market mechanism, which can be implemented to preserve participant privacy. However, such exchange implementations involve centralized database architectures prone to single points of failure.

[0021 ] Energy Trading Problem

[0022] A technical problem to be solved by the disclosed embodiments includes the problem of matching energy future bids with asks (i.e., offers to buy energy to be delivered in the future with offers to sell energy) in the local energy trading market, such as a microgrid. The technical solution aims to promote market efficiency by maximizing the amount of energy futures traded within the microgrid, while satisfying microgrid safety requirements. An initial technical problem formulation may assume that all offers are available at the same time, such that the market can be cleared at once. A generalized formulation of the problem considers a stream of incoming offers, which are cleared periodically.

[0023] Basic Problem Formulation

[0024] Table 1 provides a list of symbol notations described herein. TABLE 1 List of Symbols

Microgrid

F - set of feeders

Cf^xt - maximum net power consumption or net power production in feeder f e F Cf* - maximum total power consumption or total power production in feeder f ε F Δ - length of time intervals

Offers

Sf - set of selling offers from feeder f e F

Bf - set of buying offers from feeder f e F

S, B - set of all selling and buying offers, respectively

S(t), B(t) - set of selling and buying offers submitted by the end of time interval t, respectively

E_s, Eb - amount of energy to be sold or bought by offers S E S and b e B, respectively

Is, lb - time intervals in which energy could be provided or consumed by offers seS and b€ B, respectively

Rs, Rb - reservation prices of offers s e S and b e B, respectively M(s), M(b) - set of offers that are matchable with offers s and b, respectively l(s, b) - I. Π lb Solution p_s,b,t - amount of energy that should be provided by s to b in interval t n_s,b,t - unit price for the energy provided by s to b in interval t

Feasible(S,B) - set of feasible solutions given sets of selling and buying offers S and B

finalized trade values

[0025] The TMP 220 may be configured to solve a problem formulated as follows. For a feeder denote the maximum amount of power that may flow in or out

of the feeder f at any point in time, and let denote the maximum amount of power

that may be consumed or produced within the feeder at any point in time. In other words, limit is imposed on the net production and net consumption of all prosumers

and consumers in feeder f, while limit is imposed on the total production and total

consumption in feeder f. Time is divided into t intervals of fixed length Δ. The input of the energy trading problem is the set of buying and selling offers submitted by the participants. Participants include both prosumers 202 and the DSO 203. The DSO can shape load (i.e., the demand curve) and trade energy futures by participating in the energy market the same way as prosumers do. The DSO may influence the energy supply and demand of prosumers through posting DSO offers. This enables the DSO to shape the aggregated time-variant demand signal to better match a desired, ideal demand signal for the microgrid. The ideal demand signal depends primarily on the bulk electricity market. For feeder f ε F, we let S_f and B_f denote the set of selling and buying offers submitted by participants located in that feeder, respectively. A selling offer s E S_f is a tuple (E₈, l_s, R₈). Similarly, a buying offer b∈ B_f is a tuple (E_b, lb, Rt>), where the values pertain to consuming/buying energy instead of producing/selling, and reservation R_b is the highest price that the participant is willing to pay. For convenience, let S and B denote the set of all buying and selling offers (i.e., let

pair of selling and buying offers s ε S and b e B are matchable if the following equations are true:

[0026] In other words, a pair of offers is matchable if there exists a price that both participants would accept and a time interval in which the seller and buyer could provide and consume energy. For a given selling offer s e S, let the set of buying offers that are matchable with s be denoted by M(s). Similarly, let the set of selling offers that are matchable with a buying offer b be denoted by M(b). Further, let l(s, b) = l₈ ΙΊ l_b.

[0027] A solution to the energy trading problem may be modeled by a pair of vectors where:

is a non-negative amount of power that should be provided by the seller

seS and consumed by the buyer b E M(S) in time interval t e l(s, b);

is the unit price for the energy provided by seller seS to buyer beM(s) in

time interval t e l(s, b).

The TMP 220 may include a constraint rule that the buyer consumes and the seller produces a constant level of power during the time interval.

[0028] A pair of vectors is a feasible solution to the energy trading problem on

a condition that a selective combination of the following constraints are satisfied.

(1) The amount of energy sold or bought from each offer is at most the amount of energy offered:

(2) The amount power flow on any feeder of the microgrid does not exceed safety limits, such as allowable current ratings of conductors, by applying one or both of the following constraints:

(2a) The net power flowing into or out of each feeder is below the safety limit in all time intervals according to feeder line capacity ratings, by calculating the difference between consumption and production, and ensuring the difference remains at or below threshold

where Eq. (5) represents net production power and Eq. (6) represents net consumption of power in the feeder.

(2b) The amount of energy consumed and produced within each feeder is below the safety limit in all time intervals according to feeder line capacity ratings, by calculating the double summation consumption in Eq. (7) and double summation production in Eq. (8), and ensuring each remains at or below threshold Ct^nt :

(3) The unit prices are between the reservation prices of the seller and buyer:

From the feasible solutions that satisfy Eq. (3) to (9) above, an objective of the energy trading problem is to maximize the amount of energy traded within the local market of the microgrid. Such an optimal solution to the energy trading problem can be expressed by the following equation:

where Feasible(S,B) is the set of feasible solutions given selling and buying offers S and B (i.e., set of solutions satisfying Equations (3) to (9) with selling offers S and buying offers B).

[0029] Extended Problem Formulation

[0030] In the basic problem formulation above, it may be assumed that all buying and selling offers B and S are available at once, and the market may be cleared in one take. In practice, however, both the prosumers and the DSO may continuously submit new offers as their predictions, their physical state, and the market conditions vary over time. As the set of submitted offers grows, the optimal solution to the energy trading problem may change, and the optimal value of each

may vary. While each change can increase the amount of energy traded, the trade values

and need to be

finalized at some point in time. At the very latest, values for interval t need to be finalized by the end of interval M ; otherwise, participants would have no chance of actually delivering the trade. Here, the energy trading problem may be extended to consider a growing set offers and a time constraint for finalizing trades. The approach finalizes a minimum set of trades in each interval, which maximizes efficiency while providing safety. [0031] For an extended solution that more closely approaches a practical scenario, a clearing period Tclear may be defined in which all trades for time interval t (i.e., all values are to be finalized by the end of time interval t - Tclear, where

Tclear is a positive integer constant, and may be set by the operator. Preventing last- minute" changes can be crucial for safety and fairness since it allows both the DSO and the prosumers to prepare for delivering (or consuming) the right amount of power. In practice, the value of Tclear should be chosen considering both physical constraints (e.g., how long it takes to turn on a generator) and communication delay (e.g., some participants might leam of a trade with delay due to network disruptions).

[0032] Let denote the finalized trade values, and let B(t) and S(t)

denote the set of buying and selling offers that participants have submitted by the end of time interval t. Then, the TMP 220 may take the following steps at the end of each time interval t.

Find an optimal solution {p*, π*) to the extended energy trading problem:

subject to:

Trade values may be finalized for time interval t+Tclear based on the optimal solution

By taking the above steps at the end of each time interval, trades may be cleared based on as much information as possible (i.e., considering as many offers as possible) without violating any safety or timing constraints. Next described is how to implement the market using a blockchain-based decentralized platform.

[0033] Hybrid Solution

[0034] In an embodiment, one or more solver engines 221 may receive offer information, such as by a communication from the smart contract agents 222 or from the DSO 203, and then may apply the rules and constraints including amount of energy offered for buying or selling within time intervals proscribed by participants (Eq. (3), (4)), power feeder safety limits (Eq. (5), (6), (7), (8)), and ensuring that unit price of offers is between reservation prices of seller and buyer (Eq. (9). A solver engine 221 may identify one or more feasible solutions and submit the optimum solution (p, τή (e.g., according to Eq. (10)). The first solver engine 221 to submit a candidate solution to the smart contract agents 222 may be rewarded with an incentive (e.g., a financial incentive) to encourage time expediency in receiving proposed solutions within time limits imposed on participant's offers. The smart contract agents 222 may perform a validation of the candidate solutions received from the solver engines 221 as a simpler operation than the multivariable optimization solution derived by the solver engines 221 , as validation only involves plugging the solution vector

into each of the Equations (3) to (9) to confirm feasibility, and to detect any invalid submission by an untrusted or potentially malicious party acting as a solver.

[0035] An implementation of the hybrid approach for solving the above described basic and extended energy trading problems on a decentralized computing platform TMP 220 combines the auditability and trustworthiness of blockchain-based smart contracts using smart contract agents 222 with the efficiency of more traditional computing platforms using solver engines 221. First, the problem of matching buyer and seller offers may be solved by solver engines 221 formulating it as a linear program. Then, the computation and verification may be performed by the computational nodes and the smart contract agents 222 in a decentralized microgrid.

[0036] To formulate the basic energy trading problem efficiently as a linear program, real-valued variables may be created for each s e S. b e M(s), t e l(s, b).

Then, the following reformulation of the matching problem is a linear program:

subject to Equations (3) to (9) and

To reformulate the extended energy trading problem described above (i.e., in which both the prosumers and the DSO may continuously submit new offers as their predictions, their physical state, and the market conditions vary over time) as a linear problem similarly, the values and the additional constraints using

Equations (16)(17).

[0037] Although solving linear programs is not computationally complex, with a large number of variables and constraints, it can be challenging in resource-constrained computing environments. Since computation is relatively expensive on blockchain- based distributed platforms, and high-level language tools lack built-in support for facilitating implementation of a linear programming solver, solving the optimized energy trading problem is executed using the solver engines 221 instead of the smart contract agents 222.

[0038] The technical solution of the hybrid approach is to use a high-performance computer to implement the solver engines 221 for solving the computationally expensive linear program off-blockchain, and then use the smart contract agents 222 to record the solution on the blockchain. To implement this hybrid approach securely and reliably, the following issues are addressed. Firstly, computation that is performed off- blockchain by a solver engine 221 does not satisfy the auditability and security requirements that smart contracts do. Thus, the results of any off-blockchain computation by solver engines 221 may be verified in some way by the smart contract agents 222 before recording the results on the blockchain. Secondly, due to network disruptions and other errors (including deliberate denial -of-service attacks), the off- blockchain solver engines 221 might fail to provide the smart contract agents 222 with a solution on time (i.e., before trades are finalized). Thus, the smart contract agents 222 may proceed without an up-to-date solution. Thirdly, for the sake of reliability, the smart contract agents 222 may accept solutions from multiple off-blockchain solver engines 221s; however, these solver engines 221 might provide different solutions. Thus, the smart contract agents 222 may choose from multiple solutions (some of which may come from a compromised computer).

[0039] A smart contract generated by smart contract agents 222 may verify whether a solution proposed by one or more solver engines 221 is feasible and may

compute the value of the objective function for a feasible solution. Compared to finding an optimal solution, these operations are computationally inexpensive, and they can easily be performed on a blockchain-based decentralized platform. Using these capabilities, the smart contract agents 222 provide the following functionality. Solutions may be submitted to the smart contract agents 222 at any time. The smart contract agent 222 verify the feasibility of each submitted solution, and if the solution is feasible, then smart contract agents 222 may compute the value of the objective function represented by Eq. (11). The smart contract always keeps track of the best feasible solution submitted so far, which is referred herein as the candidate solution. At the end of each time interval t, the smart contract agents 222 finalize the trade values and

for interval t + Tclear based on the candidate solution. If no solution has been

submitted to the smart contract so far, which might be the case right after the trading system has been launched, p = 0 may be used as a candidate solution.

[0040] The above functionality achieves a modular capability that supports arbitrary external solvers with a high level of security and reliability. Firstly, it is clear that an adversary cannot force the contract to finalize trades based on an unsafe (i.e., infeasible) solution since such a solution would be rejected by the smart contract agents 222. Similarly, an adversary cannot force the smart contract to choose an inferior solution instead of a superior one. In sum, the only action available to the adversary is proposing a superior feasible solution, which would actually improve energy trading in the microgrid.

[0041] The smart contract is also reliable and can tolerate temporary disruptions to the solver engines 221 or the communication network. Notice that any solution {p, τή that is feasible for sets S and B is also feasible for supersets S' 2 S and B' 2 B. As the sets of offers can only grow over time, the contract can use a candidate solution submitted during time interval t to finalize trades in any subsequent time interval τ > t. In fact, without receiving new solutions, the difference between the amount of finalized trades and the optimum will increase only gradually. Since an earlier solution could specify trades for any future time interval, the difference is only due to the offers that have been posted since the last solution was found and submitted.

[0042] The smart contract agents 222 is complemented with an efficient linear programming by one or more solver engines 221 , which can be run off-blockchain on one or more computers. The solver engines 221 may be run periodically to find a solution to the energy trading problem based on the latest set of offers posted. Once a solution is found by a solver engine 221 , it is submitted to the smart contract agents 222 in a blockchain transaction. Note that if new offers have been posted since the solver engine 221 started working on the solution, the smart contract agents 222 will still consider the solution to be feasible. This again due to any feasible solution for sets S and .9 also being feasible for supersets

[0043] From the perspective of the solver engine 221 , being able to submit multiple solutions to the smart contract for the same problem has many advantages. For example, it allows the linear programming to be run as an anytime algorithm. Further, the solver engine 221 may be implemented as multiple— potentially untrusted— entities to execute and submit solutions to the problem, since the smart contract is configured to select the best feasible solution. This is especially important in microgrids where a trusted third party is not guaranteed to always be present. In such settings, prosumers 202 can be allowed to volunteer and provide solutions to the energy trading problem. In an embodiment, a software component (e.g., an application) may be installed on a computer of the prosumer to implement the solver engine 221 using the linear program functionality described herein. Thereby, solutions are enabled in an efficient and very flexible manner, while reaping the benefits of smart contracts, such as auditability and trustworthiness.

[0044] FIG. 3 shows a diagram for an example of communications and events during operation of the TMP 220 in accordance with embodiments of the disclosure. For ease of presentation, FIG. 3 shows only one prosumer 202 and only a single message of each type. In practice, a large number of prosumers may interact with the DSO and the smart contract module 222 and solver engine 221 of TMP 220, and each of the prosumers may exchange multiple messages with the DSO. In addition, prosumer 202 may represent one or more consumers, since any prosumer may also act as both a prosumer and a consumer (e.g., a prosumer may offer to buy energy if it is very inexpensive, but at the same time also offer to sell from its battery if it is very expensive).

[0045] The workflow 300 may include the following messages. A withdraw assets message 301 may be sent by a prosumer 202 to the DSO 203, asking the DSO to transfer energy and/or financial assets from the prosumer's account at the DSO to an anonymous address to protect prosumer's privacy. Before sending this message, a random anonymous address is generated for the prosumer. The message specifies the assets that the prosumer wishes to withdraw from the DSO (i.e., permits to trade an amount of energy production on the TMP, including and the time intervals for the energy transfer) and the anonymous address to which the DSO 203 should transfer them. Note that the prosumer may send this message long before actually engaging in trading, so the DSO does not have to be online continuously.

[0046] A failed withdrawal message 302 may be sent by the DSO 203 to the prosumer 202, notifying the prosumer that the requested assets cannot be withdrawn. For example, the DSO may examine the proposed transaction and determine the energy amount exceeds safety requirements for a feeder, or that insufficient funds are available for a purchase offer.

[0047] The DSO 203 may call Smart Contract engine 222 with an addEnergy message 303 and an addFinancialBalance message 304, creating energy assets (e.g., production assets represent permits to sell energy, consumption assets represent permits to buy energy) and financial assets on the blockchain and transferring them to an account having an anonymous address. By this transaction, assets withdrawn from the DSO are added to the blockchain-based ledger of the smart contract. Before recording this transaction, the DSO may first verify whether enabling the prosumer to trade these assets would violate any safety requirements. The call specifies the assets and the anonymous address to which they are transferred.

[0048] Smart contract engine 222 may broadcast an AssetAdded message 305 and a FinancialAdded message 306, notifying the anonymous prosumer of a transfer event in which the requested energy and financial assets for a specified time interval have been transferred to the anonymous address.

[0049] Smart contract engine 222 may be called by a prosumer from its anonymous address with a PostOffer message 307, publicly posting an energy bid or ask with time intervals and price in a transparent and auditable communication.

[0050] Smart contract engine 222 may broadcast an OfferPosted message 308, notifying solver engines 221 that an offer event was posted, indicating offer ID, energy, intervals and price information.

[0051] After a time interval, solver engine 221 executes a solution for the energy trade based on all submitted offers, including offer of message 308, and solver engine 221 calls the smart contract module 222 for a smart contract transaction using a SubmitSolution message 309 that indicates power and price information, submitting the new solution for the energy trading problem.

[0052] Following a verification that the submitted solution is feasible, and further, that the this is the most feasible of all submitted solutions, a finalized energy trade event is broadcast by the smart contract module 222, sending a SolutionFinalized message 310 including power and price information, notifying both prosumers 202 and solvers 221 of energy trades that have been finalized.

[0053] Prosumer 202 may send depositEnergy message 311 and (e.g., with energy, intervals information), and depositFinancial (amount) message 312 to the smart contract, whereby the smart contract agents 222 deposits energy and financial assets to the prosumer's account Note that to protect privacy, the calls do not specify the prosumer, so the DSO has to keep track of which prosumer has used which anonymous address. [0054] Smart contract agents 222 may broadcast Energy Deposited message 313 (e.g., including anonymous address, energy, and intervals information) and Financial Deposited message 314 (e.g., including anonymous address, and amount information), notifying the DSO 203 that assets have been deposited to prosumer's account with DSO from smart contract account with anonymous address.

[0055] FIG. 4 shows a diagram for an example of an energy trading system model using the TMP in accordance with embodiments of the disclosure. In an embodiment, the energy trading system 400 includes nodes of a peer-to-peer computer network including DSO 411, prosumers 413, 414, and TMP 410 nodes that include smart contract agents 421, 422, 423, smart contract 431, and solver engine 412. In an embodiment, the smart contract agents 421, 422, 423 may operate as blockchain miners to operate the smart contract 431. The nodes may communicate using peer-to- peer messaging protocol, such as ZeroMQ, for exchanging information such as described above with respect to FIG. 3. Ethereum may be used as the generalized blockchain peer-to-peer decentralized computation platform running the platform for smart contracts 431. The other nodes may interact with the smart contract agents 421 , 422, 423 using a Geth Ethereum client. The smart contract node 431 may be implemented in Solidity, a high-level language for Ethereum, and may be executed by a network of Geth mining nodes 421 , 422, 423.

[0056] FIG. 5 shows an exemplary computing environment within which embodiments of the disclosure may be implemented. In an embodiment, the computer system 510 may implement the solver engine 221 as described above, where remote computing devices 580 may implement a smart contract agent 222 and/or DSO 203. In an embodiment, the computer system 510 may implement the smart contract engine 222 as described above, where remote computing devices 580 may implement solver engine 221 and/or DSO 203.

[0057] As shown in FIG. 5, the computer system 510 may include a communication mechanism such as a system bus 521 or other communication mechanism for communicating information within the computer system 510. The computer system 510 further includes one or more processors 520 coupled with the system bus 521 for processing the information. [0058] The processors 520 may include one or more central processing units (CPUs), graphical processing units (GPUs), or any other processor known in the art. More generally, a processor as described herein is a device for executing machine- readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information to an output device. A processor may use or comprise the capabilities of a computer, controller or microprocessor, for example, and be conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may include any type of suitable processing unit including, but not limited to, a central processing unit, a microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Complex Instruction Set Computer (CISC) microprocessor, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), a System-on-a-Chip (SoC), a digital signal processor (DSP), and so forth. Further, the processor(s) 520 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling read/write operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor may be capable of supporting any of a variety of instruction sets. A processor may be coupled (electrically and/or as comprising executable components) with any other processor enabling interaction and/or communication there-between. A user interface processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

[0059] The system bus 521 may include at least one of a system bus, a memory bus, an address bus, or a message bus, and may permit exchange of information (e.g., data (including computer-executable code), signaling, etc.) between various components of the computer system 510. The system bus 521 may include, without limitation, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, and so forth. The system bus 521 may be associated with any suitable bus architecture including, without limitation, an Industry Standard Architecture (ISA), a Micro Channel Architecture (MCA), an Enhanced ISA (EISA), a Video Electronics Standards Association (VESA) architecture, an Accelerated Graphics Port (AGP) architecture, a Peripheral Component Interconnects (PCI) architecture, a PCI-Express architecture, a Personal Computer Memory Card International Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, and so forth.

[0060] Continuing with reference to FIG. 5, the computer system 510 may also include a system memory 530 coupled to the system bus 521 for storing information and instructions to be executed by processors 520. The system memory 530 may include computer readable storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) 531 and/or random access memory (RAM) 532. The RAM 532 may include other dynamic storage device(s) (e.g., dynamic RAM, static RAM, and synchronous DRAM). The ROM 531 may include other static storage device(s) (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition, the system memory 530 may be used for storing temporary variables or other intermediate information during the execution of instructions by the processors 520. A basic input/output system 533 (BIOS) containing the basic routines that help to transfer information between elements within computer system 510, such as during start-up, may be stored in the ROM 531. RAM 532 may contain data and/or program modules that are immediately accessible to and/or presently being operated on by the processors 520. System memory 530 may additionally include, for example, operating system 534, application programs 535, and other program modules 536.

[0061] The operating system 534 may be loaded into the memory 530 and may provide an interface between other application software executing on the computer system 510 and hardware resources of the computer system 510. More specifically, the operating system 534 may include a set of computer-executable instructions for managing hardware resources of the computer system 510 and for providing common services to other application programs (e.g., managing memory allocation among various application programs). In certain example embodiments, the operating system 534 may control execution of one or more of the program modules depicted as being stored in the data storage 540. The operating system 534 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system.

[0062] The application programs 535 may a set of computer-executable instructions for performing the TMP operations in accordance with embodiments of the disclosure.

[0063] The computer system 510 may also include a disk media controller 543 coupled to the system bus 521 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 541 and/or a removable media drive 542 (e.g., floppy disk drive, compact disc drive, tape drive, flash drive, and/or solid state drive). Storage devices 540 may be added to the computer system 510 using an appropriate device interface (e.g., a small computer system interface (SCSI), integrated device electronics (IDE), Universal Serial Bus (USB), or FireWire). Storage devices 541, 542 may be external to the computer system 510, and may be used to store data in accordance with the embodiments of the disclosure.

[0064] The computer system 510 may also include a user input interface 560 and one or more input devices, such as a user terminal 561 , which may include a keyboard, touchscreen, tablet and/or a pointing device, for interacting with a computer user and providing information to the processors 520. The display 566 may provide a touch screen interface which allows input to supplement or replace the communication of direction information and command selections by the user terminal device 561.

[0065] The computer system 510 may perform a portion or all of the processing steps of embodiments of the invention in response to the processors 520 executing one or more sequences of one or more instructions contained in a memory, such as the system memory 530. Such instructions may be read into the system memory 530 from another computer readable medium, such as the magnetic hard disk 541 or the removable media drive 542. The magnetic hard disk 541 may contain one or more data stores and data files used by embodiments of the present invention. The data store may include, but are not limited to, databases (e.g., relational, object-oriented, etc.), file systems, flat files, distributed data stores in which data is stored on more than one node of a computer network, peer-to-peer network data stores, or the like. The processors 520 may also be employed in a multi-processing arrangement to execute the one or more sequences of instructions contained in system memory 530. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

[0066] As stated above, the computer system 510 may include at least one computer readable medium or memory for holding instructions programmed according to embodiments of the invention and for containing data structures, tables, records, or other data described herein. The term "computer readable medium" as used herein refers to any medium that participates in providing instructions to the processors 520 for execution. A computer readable medium may take many forms including, but not limited to, non-transitory, non-volatile media, volatile media, and transmission media. Non-limiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disk 541 or removable media drive 542. Non-limiting examples of volatile media include dynamic memory, such as system memory 530. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up the system bus 521. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0067] Computer readable medium instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including any aforementioned languages, an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0068] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer readable medium instructions.

[0069] The computing environment 500 may further include the computer system 510 operating in a networked environment using logical connections to one or more remote computers, such as remote computing device 580. The network interface 570 may enable communication, for example, with other remote devices 580 or systems and/or the storage devices 541 , 542 via the network 571. Remote computing device 580 may be a personal computer (laptop or desktop), a mobile device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer system 510. When used in a networking environment, computer system 510 may include modem 572 for establishing communications over a network 571 , such as the Internet. Modem 572 may be connected to system bus 521 via user network interface 570, or via another appropriate mechanism. [0070] Network 571 may be any network or system generally known in the art, including the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a direct connection or series of connections, a cellular telephone network, or any other network or medium capable of facilitating communication between computer system 510 and other computers (e.g., remote computing device 580). The network 571 may be wired, wireless or a combination thereof. Wired connections may be implemented using Ethernet, Universal Serial Bus (USB), RJ-6, or any other wired connection generally known in the art. Wireless connections may be implemented using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellite or any other wireless connection methodology generally known in the art. Additionally, several networks may work alone or in communication with each other to facilitate communication in the network 571.

[0071] It should be appreciated that the program modules, applications, computer- executable instructions, code, or the like depicted in FIG. 5 as being stored in the system memory 530 are merely illustrative and not exhaustive and that processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by a different module. In addition, various program module(s), script(s), plug-in(s), Application Programming Interface(s) (API(s)), or any other suitable computer-executable code hosted locally on the computer system 510, the remote device 580, and/or hosted on other computing device(s) accessible via one or more of the network(s) 571 , may be provided to support functionality provided by the program modules, applications, or computer-executable code depicted in FIG. 5 and/or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of program modules depicted in FIG. 5 may be performed by a fewer or greater number of modules, or functionality described as being supported by any particular module may be supported, at least in part, by another module. In addition, program modules that support the functionality described herein may form part of one or more applications executable across any number of systems or devices in accordance with any suitable computing model such as, for example, a client-server model, a peer- to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 5 may be implemented, at least partially, in hardware and/or firmware across any number of devices.

[0072] An executable application, as used herein, comprises code or machine readable instructions for conditioning the processor to implement predetermined functions, such as those of an operating system, a context data acquisition system or other information processing system, for example, in response to user command or input. An executable procedure is a segment of code or machine readable instruction, sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes. These processes may include receiving input data and/or parameters, performing operations on received input data and/or performing functions in response to received input parameters, and providing resulting output data and/or parameters.

[0073] The functions and process steps herein may be performed automatically or wholly or partially in response to user command. An activity (including a step) performed automatically is performed in response to one or more executable instructions or device operation without user direct initiation of the activity.

[0074] The system and processes of the figures are not exclusive. Other systems, processes and menus may be derived in accordance with the principles of the invention to accomplish the same objectives. Although this invention has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the invention. As described herein, the various systems, subsystems, agents, managers and processes can be implemented using hardware components, software components, and/or combinations thereof. No claim element herein is to be construed under the provisions of 35 U.S.C. 112(f), unless the element is expressly recited using the phrase "means for."

Claims

CLAIMS What is claimed is:

1. A system for controlling forward trading transactions on an energy microgrid with safety and privacy protections, the system comprising:

a plurality of smart contract agents operating on a blockchain-based platform used to control forward trading transactions of prosumers on the microgrid in participation with a distributed service operator, each smart contract agent configured to:

receive, from the distribution service operator, a transmission of asset information related to energy assets and financial assets withdrawn from anonymous accounts of the prosumers;

deposit the energy assets and financial assets of the prosumers into anonymous smart contract accounts;

receive, from the prosumers, forward offers to exchange energy on the microgrid, including an energy amount, time intervals for the exchange, and a unit price;

send, to at least one off-blockchain solver engine, the received offers in a request for an optimized solution for matching offers, wherein optimization is based maximizing the amount of energy exchanged on the microgrid within microgrid safety constraints;

receive, from the at least one solver engine, a candidate solution as a vector pair (p, pi) of a constrained linear formulation with the vector p equal to a non-negative amount of power to be provided by seller prosumers and consumed by buyer prosumers in a defined time interval, and the vector pi equal to unit prices for each respective power amount p in the time interval; and

verify that the candidate solution satisfies the microgrid safety constraints for any feeder line in the microgrid.

2. The system of claim 1 , wherein each smart contract agent is configured to reject a solution that fails to meet a constraint of amount of energy sold or bought from each offer is at most the amount of energy offered.

3. The system of claim 1 , wherein the smart contract agents is configured to reject a solution that fails to meet a constraint of net power flow in a feeder to remain below a feeder capacity safety limit in all time intervals.

4. The system of claim 1 , wherein the smart contract agents is configured to reject a solution that fails to meet a constraint of amount of energy consumed and produced within each feeder is below a feeder capacity safety limit in all time intervals.

5. The system of claim 1 , wherein the smart contract agents is configured to reject a solution that fails to meet a constraint of unit prices being between the reservation prices of the seller and the buyer.

6. A method for controlling forward trading transactions on an energy microgrid with safety and privacy protections, the method executed by a plurality of smart contract agents operating on a blockchain-based platform and comprising steps of:

receiving from a distribution service operator a transmission of asset information related to energy assets and financial assets withdrawn from anonymous accounts of the prosumers;

depositing the energy assets and financial assets of the prosumers into anonymous smart contract accounts;

receiving, from the prosumers, forward offers to exchange energy on the microgrid, including an energy amount, time intervals for the exchange, and a unit price;

sending, to at least one off-blockchain solver engine, the received offers in a request for an optimized solution for matching offers, wherein optimization is based maximizing the amount of energy exchanged on the microgrid within microgrid safety constraints;

receiving, from the at least one solver engine, a candidate solution as a vector pair (p, pi) of a constrained linear formulation with the vector p equal to a non-negative amount of power to be provided by seller prosumers and consumed by buyer prosumers in a defined time interval, and the vector pi equal to unit prices for each respective power amount p in the time interval; and

verifying that the candidate solution satisfies the microgrid safety constraints for any feeder line in the microgrid.

7. The method of claim 6, wherein each smart contract agent is configured to reject a solution that fails to meet a constraint of amount of energy sold or bought from each offer is at most the amount of energy offered.

8. The method of claim 6, wherein the smart contract agents is configured to reject a solution that fails to meet a constraint of net power flow in a feeder to remain below a feeder capacity safety limit in all time intervals.

9. The method of claim 6, wherein the smart contract agents is configured to reject a solution that fails to meet a constraint of amount of energy consumed and produced within each feeder is below a feeder capacity safety limit in all time intervals.

10. The method of claim 6, wherein the smart contract agents is configured to reject a solution that fails to meet a constraint of unit prices being between the reservation prices of the seller and the buyer.