METHOD AND SYSTEM FOR DECENTRALIZED ENERGY FORECASTING AND SCHEDULING

Abstract

A method for adjusting electrical energy flow schedules of a utility handling a plurality of distributed energy resources. The method comprising the steps of providing information regarding energy flow of the energy resources and storing said information on a distributed ledger; transferring energy schedules from the utility to the distributed ledger; transferring said information regarding the energy flow and the energy schedules from the distributed ledger to a computing means and computing proposed corrections for the energy schedules; transferring said proposed correction to the distributed ledger; transferring said proposed correction to the utility which decides to use or not to use the proposed correction. By deciding to use the proposed correction, the schedules are corrected and information is transferred from the utility to the computing means.

Claims

1. A method for adjusting electrical energy flow schedules of a utility handling a plurality of distributed energy resources (DER), the method comprising: providing information regarding actual energy flow of the distributed energy resources and storing said information on a distributed ledger; transferring actual energy schedules from the utility to the distributed ledger; transferring said information regarding the energy flow and the energy schedules from the distributed ledger to at least one computing means and computing proposed corrections for the energy schedules; transferring said proposed corrections to the distributed ledger; and transferring said proposed corrections to the utility which decides to use or not to use the proposed corrections; wherein by deciding to use the proposed corrections the energy schedules are corrected and information reflecting a degree of improvement is transferred from the utility to the computing means.

2. The method of claim 1, wherein said plurality of distributed energy resources comprise a plurality of producers and/or consumers.

3. The method of claim 1, wherein said proposed corrections are corrections regarding schedules for i) electrical energy flow from the producers to the utility (10) and/or ii) electrical energy flow from the utility (10) to the consumer.

4. The method of claim 1, wherein external data are transferred to the computing means, and wherein the computing of proposed corrections takes these additional external data into account.

5. The method of claim 4, wherein said external data can be selected from the group consisting of weather data, information about public holidays, vacation periods, weekdays, social events, TV shows/movies, union protests, school vacation information, and information on the state of turbines in a wind farm.

6. The method of claim 1, wherein the distributed ledger is a blockchain.

7. The method of claim 1, wherein the distributed ledger comprises smart contracts for validation of received corrections and schedules and/or ranking of received corrections based on expected performance.

8. The method of claim 1, wherein the DER comprises multiple generation/contribution and/or storage/consumption components and uses at least one renewable energy source from the group consisting of small hydro, biomass, biogas, solar power, wind power, and geothermal power.

9. The method of claim 1, wherein each DER contributes to a grid of a present utility.

10. The method of claim 1, wherein the utility automatically decides to use or not to use one or more of the proposed corrections, through a smart contract.

11. The method of claim 1, wherein the utility decides to use or not to use one or more of the proposed corrections at least partially based on recent and/or historical data.

12. A system for adjusting electrical energy flow schedules of a utility handling a plurality of distributed energy resources, the system comprising: a distributed ledger which receives information regarding actual energy flow of the distributed energy resources and actual energy flow schedules, wherein said information and energy flow schedules are stored on said distributed ledger; at least one computing means configured to compute proposed corrections for the energy flow schedules based on said information and energy flow schedules stored on said ledger, wherein said proposed corrections are transferred to said ledger and stored on said ledger; wherein said utility is adapted to evaluate either to use or not to use the proposed corrections stored on said ledger; and wherein by using the proposed corrections, the utility is configured to correct the energy flow schedules on the basis of the proposed corrections and to transfer information to the computing means.

13. (canceled)

14. A non-transitory computer-readable medium having stored thereon a computer program, the computer program comprising instructions to cause a computing system to: provide information regarding actual energy flow of the distributed energy resources and store said information on a distributed ledger; transfer actual energy schedules from a utility to the distributed ledger; transfer said information regarding the energy flow and the energy schedules from the distributed ledger to at least one computing means and compute proposed corrections for the energy schedules; transfer said proposed corrections to the distributed ledger; and transfer said proposed corrections to the utility which decides to use or not to use the proposed corrections; wherein by deciding to use the proposed corrections the energy schedules are corrected and information reflecting a degree of improvement is transferred from the utility to the computing means.

15. The non-transitory computer-readable medium of claim 14, wherein said proposed corrections are corrections regarding schedules for i) electrical energy flow from the producers to the utility (10) and/or ii) electrical energy flow from the utility (10) to the consumer.

16. The non-transitory computer-readable medium of claim 14, wherein the distributed ledger is a blockchain.

17. The non-transitory computer-readable medium of claim 14, wherein the distributed ledger comprises smart contracts for validation of received corrections and schedules and/or ranking of received corrections based on expected performance.

18. The non-transitory computer-readable medium of claim 14, wherein the utility automatically decides to use or not to use one or more of the proposed corrections, through a smart contract.

19. The non-transitory computer-readable medium of claim 14, wherein the utility decides to use or not to use one or more of the proposed corrections at least partially based on recent and/or historical data.

20. The system of claim 12, wherein said plurality of distributed energy resources comprises a plurality of producers and/or consumers.

21. The system of claim 12, wherein the plurality of distributed energy resources comprises multiple generation/contribution and/or storage/consumption components and uses at least one renewable energy source from the group consisting of small hydro, biomass, biogas, solar power, wind power, and geothermal power.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The subject-matter will be explained in more detail with reference to a preferred exemplary embodiment which is illustrated in the attached drawing:

[0029] FIG. 1 schematically shows the involved participants and data flow;

[0030] FIG. 2a a flowchart for utilities; and

[0031] FIG. 2b a corresponding flowchart for a worker.

DETAILED DESCRIPTION OF EMBODIMENTS

[0032] An exemplary embodiment will be described with reference to the figures in which identical or similar reference signs designate identical or similar elements.

[0033] The main components and parties involved in the proposed system are shown in FIG. 1.

[0034] An electric utility 10 is a company in the electric power industry that engages in electricity generation and distribution of electricity. Thus, the utility 10 is managing the power grid operations and preferably also the electricity market, i.e., deciding on the electrical energy flow between the grid and a plurality of distributed energy resources (DER) 20. In particular, the distributed energy resources 20 comprise producers and consumers, wherein these decisions on the electricity market regulate the energy flow from producers to the grid of the utility 10 and energy flow from the grid to consumers. Said electrical energy flow is coordinated with corresponding schedules. Hence, a schedule coordinates when a certain amount of energy is transferred from/to the grid to/from consumers/producers.

[0035] The present disclosure provides a new component which is called “worker” 40. In particular, a worker 40 is preferably a computational means, preferably comprising one or a plurality of computational devices that is/are able to calculate and propose forecasts and/or schedule corrections for the energy flow on the basis of certain data. Said corrections may be used by the utility 10 for a more efficient energy flow. In other words, the workers help to solve the unit commitment problem.

[0036] Information on available energy produced by the producers, on energy required by consumers and the decision by the utility are generally negotiated on a market place. According to the present disclosure, such a market place uses a distributed ledger 30. In the following example, the market place will be presented as one logical actor for simplicity. However, a plurality of market places are also possible. For instance, according to the present disclosure a plurality of markets are possible and a worker can participate in several of these markets.

[0037] According to the present disclosure it is preferred to use a blockchain for the distributed ledger 30. Such a blockchain preferably stores the history of proposed and/or used schedules (unit commitment) with the history of actual flows (see arrow 1 in FIG. 1). In particular said history may be additionally stored together with a set of bids and offers from all participants buying/consuming or selling/producing energy, e.g., the consumers and the producers. Thus, in addition to the technical information of the consuming/producing history of energy, i.e., the flow of energy, also business information regarding buying and selling the energy may be stored in the distributed ledger. A preferred core function of a worker 40 is to analyze past and current energy flows together with additional information (see arrow 3), e.g. weather and/or other forecast data (see arrow 7) and to derive schedule corrections from this data (see arrow 4). Additionally or optionally, a worker 40 may analyze past and current bids in connection with the energy flows and/or said additional information.

[0038] A forecast correction or proposed correction would change the amount of energy consumed and/or produced by a set of participants in a certain time interval with a certain probability. Moreover, in addition to said technical features, a bid correction would change the amount of money offered/requested for energy by a (group of) prosumers in a time interval. Thus, a worker 40 proposes a forecast with schedule corrections (unit commitment) that fit the foreseen behavior of the system better. Optionally, said forecast may comprise bids (penalty cost reduction). To this end, workers insert correction proposals into the distributed ledger (see arrow 4).

[0039] In order to compute such a correction proposal, the worker 40 can use data from past events (schedules, consumption and optionally bids) stored in the ledger 30 and optionally external data (weather forecast, production forecast, demand forecast, see arrow 7 in FIG. 1). In particular, the worker 40 can use statistical and/or machine learning approaches to compute models of the system. At some later point in time, the value of a correction proposal can be determined retrospectively, i.e., how good the correction proposal matched the real situation. Additionally, the utility 10 could evaluate if the unit commitment problem was solved sufficiently and optionally how much money he would have saved if corrections would have been applied or not. This value can be computed in a number of ways and for different scenarios and time intervals.

[0040] Some workers 40 might be better at computing correction proposals for certain time intervals or energy mix scenarios. E.g., some workers might be very good at predicting wind energy in certain regions, other workers achieve higher quality forecasts for solar energy. Furthermore, some workers 40 might generate better seasonal forecasts or may be specialized on time intervals of specific lengths. Thus, corrections can be evaluated in many different ways, taking system properties and constraints into account. This analysis improves the probability to select the right correction suggestions for subsequent time intervals.

[0041] The utility 10 can choose among corrections as provided via the distributed ledger 30 to the utility and confirm their use by appending a signed confirmation message to the distributed ledger 30. The utility 10 can base this decision on the quality/gain of proposed corrections in the (recent) past, e.g. the decision may be at least partially based on historical data. In other words, the utility 10 can learn which workers 40 provide good corrections. In particular, it is preferred that learning and automatically deciding is done via machine learning. The generation of the training set and training the machine learning classifier is preferably based on simulated date and/or historical data. Alternatively or additionally, this choice can be automated through a smart contract. In this case, the correction for the next time interval would be selected automatically based on a given formula that evaluates the performance of previously proposed corrections.

[0042] The worker 40 that proposed the accepted correction may receive feedback on the level of correctness (see arrow 6), which may be used for further calculations. Additionally, the worker 40 may be rewarded by the utility, by either paying a certain amount to the worker, e.g., in FIAT (Fiat money; see e.g. “https://en.wikipedia.org/wiki/Fiat_money”) and/or a virtual currency and/or offering some service, e.g., electricity at a reduced cost. Instead of costs, the reward may be of pure technical nature, e.g., the worker may receive any kind of service from the utility like energy etc.

[0043] It is preferred that the actual schedule is stored (see arrow 2) on the ledger 30, such that a smart contract can be used to identify if a proposed correction has been applied and optional rewards and/or penalties may be settled automatically. This preferred mechanism ensures that workers 30 are indeed remunerated if their proposed corrections are used. The rewards can be fixed or depend on the amount of cost reduction achieved by the correction over a time interval. Fixed reward amounts can be set arbitrarily, e.g., computed on the basis of past data as well. These rewards may be considered as incentive that the worker participates in the process which finally helps to improve the grid stability and/or to avoid blackouts. Hence, the prosumers and the utility get a technical benefit. The incentive, however, is not necessarily money but can be more generally provided in form of a token. Based on the tokens the workers collect, services from the utility may be provided to the workers. The cost reductions can stem from lower reserves (legislation requires a certain amount of reserve energy) as with better predictions and unit commitment schedules, reserves can be minimized. Moreover, increased grid availability may reduce costs, which in turn results in lower penalty payments for network down time. The advantage of the present disclosure, however, is also reflected in technical and/or environmental advantages, e.g., the use of fossil energy sources may be reduced as more renewable energy sources can be handled due to more accurate predictions and better unit commitment.

[0044] Instead of a correction proposal, the worker 40 could also offer the used computational methods (model) with a smart contract. In this case, the worker 40 could be paid per usage of the model and/or whenever it adjusts the model or its parameters.

[0045] FIG. 2a illustrates parts of the method of the present disclosure in a flowchart for a utility 100 and in FIG. 2b parts for a worker 40. In particular, in step 101 the utility collects data regarding the energy flow from the ledger 30, i.e., the amount of electrical energy that is available from the individual participants and how much energy is needed. Additionally, said available and needed energy may be provided by bids and offers, such that the “costs” are an indication of the availability or urgency of the amount of energy. The utility computes a schedule on the basis of said data (step 102) and sends this schedule to the ledger 30 (step 104). In step 105 it is checked whether there exists a proposed correction for the schedule. The proposed correction is evaluated in step 106 and subsequently decided whether this correction is acceptable (step 107). The schedule as previously computed in step 102 is then corrected by the accepted correction(s). Step 108 computes the remuneration and penalties for such an applied correction, wherein said remuneration/penalties are stored and therefore published on the ledger 30 (step 109).

[0046] FIG. 2b illustrates parts of the method of the present disclosure in a flowchart for a worker 40. In particular, in step 401 the worker collects external data (see arrow 7 in FIG. 1) and data from the distributed ledger 30 as indicated by arrow 3 in FIG. 1. The worker 40 computes a correction proposal in step 402 and transfers said correction proposal in step 403 to the ledger 30 (see arrow 4 in FIG. 1).