Optimization of microgrid energy use and distribution

0Associated
Cases 
0Associated
Defendants 
0Accused
Products 
99Forward
Citations 
0
Petitions 
2
Assignments
First Claim
1. A system for energy optimization, the system comprising:
 a server;
one or more databases in communication with the server;
the server is configured for;
receiving information collector data from at least one information collector, the information collector data comprising nearreal time individualized energy usage data for each of a plurality of customers or customer locations;
calculating a cost of service for each of the plurality of customers or customer locations based on their (1) individualized energy usage data, (2) a system generation cost for an energy provider or a locational marginal price of electricity, and (3) characteristics of an electric distribution system used to supply power to each of the plurality of customers or customer locations, the calculating further comprising assigning an individualized relative marginal cost value for each of the customers or customer locations, wherein the relative marginal cost value indicates differences in cost of service for different customers or customer locations, combining the relative marginal cost value with a weighted customer cost, wherein the weighted customer cost indicates an importance of a cost category for individual customers or customer locations;
forecasting individualized energy usage for each of the plurality of customers or customer locations;
forecasting customer specific cost of service for each of the plurality of customers or customer locations using the calculating results; and
optimizing, over a plurality of customers or customer locations, energy use and cost of service using the forecasted individualized energy usage and the forecasted customer specific cost of service.
2 Assignments
0 Petitions
Accused Products
Abstract
An energy distribution may include a server and one or more databases. The system may communicate with an energy provider to receive energy provider data, at least one information collector to receive information collector data such as individualized energy usage data, customer preferences, and customer or location characteristics, and the one or more databases for receiving data for optimization. The system may calculate a cost of service or avoided cost using at least one of the individualized energy usage data and a system generation cost at a nearest bus. The system may also forecast individualized demand by enduse, individualized demand by location, energy prices, or energy costs. The system may optimize energy distribution, energy use, cost of service, or avoided cost using the forecasted individualized demand by enduse, the forecasted individualized demand by location, the forecasted energy prices, and the forecasted energy costs.
114 Citations
View as Search Results
Water heater control using external temperature sensor  
Patent #
US 9,752,798 B2
Filed 02/23/2016

Current Assignee
Emerson Electric Company

Sponsoring Entity
Emerson Electric Company

Critical peak pricing demand response participant assessment  
Patent #
US 10,181,165 B2
Filed 02/12/2016

Current Assignee
Fujitsu Limited

Sponsoring Entity
Fujitsu Limited

Smart energy controlled water heater  
Patent #
US 9,605,872 B2
Filed 10/27/2015

Current Assignee
Emerson Electric Company

Sponsoring Entity
Emerson Electric Company

Establishing communication and power sharing links between components of a distributed energy system  
Patent #
US 9,941,696 B2
Filed 10/16/2015

Current Assignee
Cleanspark II LLC

Sponsoring Entity
Cleanspark II LLC

System tools for integrating individual load forecasts into a composite load forecast to present a comprehensive, synchronized and harmonized load forecast  
Patent #
US 10,128,655 B2
Filed 06/18/2015

Current Assignee
General Electric Technology GmbH

Sponsoring Entity
General Electric Technology GmbH

System and Method for Managing Battery Discharge During Critical Peak Pricing Intervals  
Patent #
US 20160036247A1
Filed 01/23/2015

Current Assignee
NantEnergy Inc.

Sponsoring Entity
NantEnergy Inc.

System and method for managing battery discharge during critical peak pricing intervals  
Patent #
US 9,727,898 B2
Filed 01/23/2015

Current Assignee
NantEnergy Inc.

Sponsoring Entity
Sharp Laboratories of America Incorporated

Methods, apparatus and systems for managing energy assets  
Patent #
US 9,772,643 B2
Filed 11/04/2014

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Solutions Inc.

Energy transfer with vehicles  
Patent #
US 10,124,691 B1
Filed 09/23/2014

Current Assignee
Failing Bryan Marc

Sponsoring Entity
Failing Bryan Marc

Energy transfer with vehicles  
Patent #
US 9,393,878 B1
Filed 09/23/2014

Current Assignee
Failing Bryan Marc

Sponsoring Entity
Failing Bryan Marc

Aggregator, monitor, and manager of distributed microgenerators  
Patent #
US 9,052,732 B2
Filed 08/28/2014

Current Assignee
Versify Solutions Inc.

Sponsoring Entity
Versify Solutions Inc.

Increasing vehicle security  
Patent #
US 9,114,719 B1
Filed 05/12/2014

Current Assignee
Failing Bryan Marc

Sponsoring Entity
Failing Bryan Marc

System and method for energy distribution  
Patent #
US 9,438,041 B2
Filed 03/14/2014

Current Assignee
Bosch Energy Storage Solutions Llc, Robert Bosch GmbH

Sponsoring Entity
Bosch Energy Storage Solutions Llc, Robert Bosch GmbH

Methods for reducing solar inverter output volatility, and related nodes and solar inverters  
Patent #
US 9,507,364 B2
Filed 03/10/2014

Current Assignee
Duke Energy Corporation

Sponsoring Entity
Duke Energy Corporation

Electricity suppressing type electricity and heat optimizing control device, optimizing method, and optimizing program  
Patent #
US 9,916,630 B2
Filed 03/07/2014

Current Assignee
Toshiba Corporation

Sponsoring Entity
Toshiba Corporation

Demand response event assessment  
Patent #
US 10,152,683 B2
Filed 01/22/2014

Current Assignee
Fujitsu Limited

Sponsoring Entity
Fujitsu Limited

UTILITY USAGE FORECASTING  
Patent #
US 20150192697A1
Filed 01/07/2014

Current Assignee
International Business Machines Corporation

Sponsoring Entity
International Business Machines Corporation

Utility usage forecasting  
Patent #
US 9,739,908 B2
Filed 01/07/2014

Current Assignee
International Business Machines Corporation

Sponsoring Entity
International Business Machines Corporation

Method for determining an optimal schedule of an appliance  
Patent #
US 9,686,093 B2
Filed 09/10/2013

Current Assignee
Whirlpool Corporation

Sponsoring Entity
Whirlpool Corporation

System and method for energy management  
Patent #
US 9,335,747 B2
Filed 05/16/2013

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

Facilitating revenue generation from wholesale electricity markets based on a selftuning energy asset model  
Patent #
US 9,098,876 B2
Filed 05/06/2013

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

Facilitating revenue generation from wholesale electricity markets using an engineeringbased model  
Patent #
US 9,171,276 B2
Filed 05/06/2013

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

Facilitating revenue generation from wholesale electricity markets based on a selftuning energy asset model  
Patent #
US 9,367,825 B2
Filed 05/06/2013

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

POWER INFRASTRUCTURE SIZING AND WORKLOAD MANAGEMENT  
Patent #
US 20140324535A1
Filed 04/30/2013

Current Assignee
Hewlett Packard Enterprise Development LP

Sponsoring Entity
Hewlett Packard Enterprise Development LP

System and method for managing distributed renewable energy systems and service providers  
Patent #
US 10,069,454 B2
Filed 03/19/2013

Current Assignee
SOLAR CHIEF LLC

Sponsoring Entity
SOLAR CHIEF LLC

SYSTEMS AND METHODS FOR MINIMIZING ENERGY COSTS FOR A POWER CONSUMPTION SYSTEM THAT HAS ACCESS TO OFFGRID RESOURCES  
Patent #
US 20140163756A1
Filed 03/15/2013

Current Assignee
ENGIE SERVICES U.S. INC.

Sponsoring Entity
ENGIE SERVICES U.S. INC.

System and Method for Optimizing A Demand Response Event  
Patent #
US 20140278687A1
Filed 03/15/2013

Current Assignee
TROVE PREDICTIVE DATA SCIENCE LLC

Sponsoring Entity
TROVE PREDICTIVE DATA SCIENCE LLC

Systems and methods for minimizing energy costs for a power consumption system that has access to offgrid resources  
Patent #
US 9,639,904 B2
Filed 03/15/2013

Current Assignee
ENGIE SERVICES U.S. INC.

Sponsoring Entity
OPTERRA ENERGY SERVICES INC.

Water heater control using external temperature sensor  
Patent #
US 9,310,098 B2
Filed 03/14/2013

Current Assignee
Emerson Electric Company

Sponsoring Entity
Emerson Electric Company

BROADCAST ENERGY DEMAND SYSTEMS AND METHODS  
Patent #
US 20130274936A1
Filed 03/13/2013

Current Assignee
MelRok LLC

Sponsoring Entity
MelRok LLC

Smart energy controlled water heater  
Patent #
US 9,188,363 B2
Filed 03/13/2013

Current Assignee
Emerson Electric Company

Sponsoring Entity
Emerson Electric Company

Facilitating revenue generation from data shifting by data centers  
Patent #
US 9,159,042 B2
Filed 02/22/2013

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

Energy banking system and method using rapidly rechargeable batteries  
Patent #
US 10,110,056 B2
Filed 02/04/2013

Current Assignee
Lightening Energy

Sponsoring Entity
Lightening Energy

SITE MANAGEMENT IN AN ONDEMAND SYSTEM  
Patent #
US 20130190943A1
Filed 01/11/2013

Current Assignee
Salesforce.com Inc.

Sponsoring Entity
Salesforce.com Inc.

Site management in an ondemand system  
Patent #
US 9,397,521 B2
Filed 01/11/2013

Current Assignee
Salesforce.com Inc.

Sponsoring Entity
Salesforce.com Inc.

System and method for energy distribution  
Patent #
US 9,312,698 B2
Filed 12/19/2012

Current Assignee
Bosch Energy Storage Solutions Llc, Robert Bosch GmbH

Sponsoring Entity
Bosch Energy Storage Solutions Llc, Robert Bosch GmbH

Facilitating revenue generation from wholesale electricity markets  
Patent #
US 9,159,108 B2
Filed 11/01/2012

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

Managing energy assets associated with transport operations  
Patent #
US 9,367,052 B2
Filed 10/29/2012

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

DISTRIBUTED FORECASTING AND PRICING SYSTEM  
Patent #
US 20140108093A1
Filed 10/15/2012

Current Assignee
International Business Machines Corporation

Sponsoring Entity
International Business Machines Corporation

System and method for predictive peak load management via integrated load management  
Patent #
US 9,002,531 B2
Filed 09/28/2012

Current Assignee
NantEnergy Inc.

Sponsoring Entity
Sharp Electronics Corporation

Aggregator, monitor, and manager of distributed demand response  
Patent #
US 9,805,325 B2
Filed 07/24/2012

Current Assignee
Versify Solutions Inc.

Sponsoring Entity
Versify Solutions Inc.

SYSTEMS AND METHODS FOR SELFSERVICE CLOUDBASED ARENAS FOR INFORMATION TECHNOLOGYDRIVEN SITUATIONAL MANAGEMENT  
Patent #
US 20140019335A1
Filed 07/12/2012

Current Assignee
CA Inc. dba CA Technologies

Sponsoring Entity
CA Inc. dba CA Technologies

Method and system for mitigating impact of malfunction in actual load determination on peak load management  
Patent #
US 8,761,949 B2
Filed 05/31/2012

Current Assignee
NantEnergy Inc.

Sponsoring Entity
Sharp Electronics Corporation

AUTOMATED FIELD PROVISIONING FOR ENERGY MANAGEMENT SYSTEMS  
Patent #
US 20130060395A1
Filed 05/25/2012

Current Assignee
HUNT ENERGY IQ L.P.

Sponsoring Entity
HUNT ENERGY IQ L.P.

METHODS, APPARATUS AND SYSTEMS FOR MANAGING ENERGY ASSETS  
Patent #
US 20120296482A1
Filed 04/19/2012

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Solutions Inc.

Methods, apparatus and systems for managing energy assets  
Patent #
US 8,892,264 B2
Filed 04/19/2012

Current Assignee
Viridity Energy Solutions Inc.

Sponsoring Entity
Viridity Energy Incorporated

SMART METER TRUST CENTER SWITCH  
Patent #
US 20130262844A1
Filed 03/28/2012

Current Assignee
Honeywell International Inc.

Sponsoring Entity
Honeywell International Inc.

Smart meter trust center switch  
Patent #
US 9,106,631 B2
Filed 03/28/2012

Current Assignee
Honeywell International Inc.

Sponsoring Entity
Honeywell International Inc.

System and Method For Managing Load Distribution Across a Power Grid  
Patent #
US 20120229089A1
Filed 03/07/2012

Current Assignee
Trilliant Networks Incorporated

Sponsoring Entity
Trilliant Networks Incorporated

System and method for managing load distribution across a power grid  
Patent #
US 9,041,349 B2
Filed 03/07/2012

Current Assignee
Trilliant Networks Incorporated

Sponsoring Entity
Trilliant Networks Incorporated

REGIONAL ENERGY MANAGEMENT SYSTEM, REGIONAL ENERGY INTEGRATED MANAGEMENT DEVICE AND REGIONAL ENERGY INTEGRATED MANAGEMENT METHOD USED IN REGIONAL ENERGY MANAGEMENT SYSTEM  
Patent #
US 20120221165A1
Filed 03/06/2012

Current Assignee
Toshiba Corporation

Sponsoring Entity
Toshiba Corporation

Regional energy management system, regional energy integrated management device and regional energy integrated management method used in regional energy management system  
Patent #
US 8,938,320 B2
Filed 03/06/2012

Current Assignee
Toshiba Corporation

Sponsoring Entity
Toshiba Corporation

Distributed gridinteractive photovoltaicbased power dispatching  
Patent #
US 9,229,501 B2
Filed 02/08/2012

Current Assignee
International Business Machines Corporation

Sponsoring Entity
International Business Machines Corporation

SMART ENERGY CONTROLLED WATER HEATER  
Patent #
US 20120118989A1
Filed 01/24/2012

Current Assignee
Emerson Electric Company

Sponsoring Entity
Emerson Electric Company

Smart energy controlled water heater  
Patent #
US 9,151,516 B2
Filed 01/24/2012

Current Assignee
Emerson Electric Company

Sponsoring Entity
Emerson Electric Company

Method for thermal energy dispatch  
Patent #
US 8,903,561 B1
Filed 01/10/2012

Current Assignee
Lockheed Martin Corporation

Sponsoring Entity
Lockheed Martin Corporation

Energy benchmarking analytics  
Patent #
US 8,660,868 B2
Filed 09/22/2011

Current Assignee
SAP SE

Sponsoring Entity
SAP SE

ELECTRICAL THERMAL STORAGE WITH EDGEOFNETWORK TAILORED ENERGY DELIVERY SYSTEMS AND METHODS  
Patent #
US 20120296479A1
Filed 05/16/2011

Current Assignee
VCHARGE INC.

Sponsoring Entity
VCHARGE INC.

Electrical thermal storage with edgeofnetwork tailored energy delivery systems and methods  
Patent #
US 8,768,528 B2
Filed 05/16/2011

Current Assignee
VCHARGE INC.

Sponsoring Entity
VCHARGE INC.

System And Method For Online Obtainment And Publishing Of Information Of Products  
Patent #
US 20110276430A1
Filed 05/05/2011

Current Assignee
SIMPLIBUY TECHNOLOGIES P LTD.

Sponsoring Entity
SIMPLIBUY TECHNOLOGIES P LTD.

ENERGYSAVING MEASUREMENT, ADJUSTMENT AND MONETIZATION SYSTEM AND METHOD  
Patent #
US 20110251933A1
Filed 04/07/2011

Current Assignee
ENERGY RESOURCE MANAGEMENT CORP

Sponsoring Entity
ENERGY RESOURCE MANAGEMENT CORP

Energysaving measurement, adjustment and monetization system and method  
Patent #
US 8,355,827 B2
Filed 04/07/2011

Current Assignee
ENERGY RESOURCE MANAGEMENT CORP

Sponsoring Entity
ENERGY RESOURCE MANAGEMENT CORP

OPTIMIZATION OF MICROGRID ENERGY USE AND DISTRIBUTION  
Patent #
US 20110231028A1
Filed 04/05/2011

Current Assignee
Integral Analytics Inc.

Sponsoring Entity
Integral Analytics Inc.

Optimization of microgrid energy use and distribution  
Patent #
US 8,706,650 B2
Filed 04/05/2011

Current Assignee
Integral Analytics Inc.

Sponsoring Entity
Integral Analytics Inc.

SYSTEM AND METHOD FOR OPERATING A TAP CHANGER  
Patent #
US 20120249278A1
Filed 03/31/2011

Current Assignee
General Electric Company

Sponsoring Entity
General Electric Company

Systems and Methods For Controlling Multiple HVAC Systems  
Patent #
US 20120253521A1
Filed 03/31/2011

Current Assignee
Trane International Inc.

Sponsoring Entity
Trane International Inc.

System and method for operating a tap changer  
Patent #
US 8,531,173 B2
Filed 03/31/2011

Current Assignee
General Electric Company

Sponsoring Entity
General Electric Company

Systems and methods for controlling multiple HVAC systems  
Patent #
US 9,494,952 B2
Filed 03/31/2011

Current Assignee
Trane International Inc.

Sponsoring Entity
Trane International Inc.

SYSTEMS AND METHODS FOR FORECASTING ELECTRICAL LOAD  
Patent #
US 20120253532A1
Filed 03/30/2011

Current Assignee
General Electric Company

Sponsoring Entity
General Electric Company

Systems and Methods for Predicting Customer Compliance with Demand Response Requests  
Patent #
US 20130254151A1
Filed 03/18/2011

Current Assignee
ABB Research Ltd.

Sponsoring Entity
ABB Research Ltd.

Systems and methods for predicting customer compliance with demand response requests  
Patent #
US 9,171,256 B2
Filed 03/18/2011

Current Assignee
ABB Research Ltd.

Sponsoring Entity
ABB Research Ltd.

SYSTEM AND METHOD FOR PROVIDING REDUCED CONSUMPTION OF ENERGY USING AUTOMATED HUMAN THERMAL COMFORT CONTROLS  
Patent #
US 20110218691A1
Filed 03/04/2011

Current Assignee
EFFICIENT ENERGY AMERICA INCORPORATED

Sponsoring Entity
EFFICIENT ENERGY AMERICA INCORPORATED

Increasing vehicle security  
Patent #
US 8,725,330 B2
Filed 01/28/2011

Current Assignee
Failing Bryan Marc

Sponsoring Entity
Failing Bryan Marc

Energy transfer with vehicles  
Patent #
US 8,841,881 B2
Filed 01/28/2011

Current Assignee
Failing Bryan Marc

Sponsoring Entity
Failing Bryan Marc

INTELLIGENT MANAGEMENT OF VIRTUALIZED RESOURCES FOR CLOUD DATABASE SYSTEMS  
Patent #
US 20120022910A1
Filed 01/05/2011

Current Assignee
NEC Corporation

Sponsoring Entity
NEC Corporation

Intelligent management of virtualized resources for cloud database systems  
Patent #
US 8,359,223 B2
Filed 01/05/2011

Current Assignee
NEC Corporation

Sponsoring Entity
NEC Laboratories America Inc

SYSTEM AND METHOD FOR MANAGING DISTRIBUTED RENEWABLE ENERGY SYSTEMS  
Patent #
US 20120103395A1
Filed 10/28/2010

Current Assignee
SOLAR CHIEF LLC

Sponsoring Entity
SOLAR CHIEF LLC

System and method for managing distributed renewable energy systems  
Patent #
US 8,401,711 B2
Filed 10/28/2010

Current Assignee
SOLAR CHIEF LLC

Sponsoring Entity
SOLAR CHIEF LLC

LOAD SHED SYSTEM FOR DEMAND RESPONSE WITHOUT AMI/AMR SYSTEM  
Patent #
US 20120029713A1
Filed 08/02/2010

Current Assignee
Haier US Appliance Solutions Inc. DBA GE Appliances

Sponsoring Entity
Haier US Appliance Solutions Inc. DBA GE Appliances

Load shed system for demand response without AMI/AMR system  
Patent #
US 8,386,087 B2
Filed 08/02/2010

Current Assignee
Haier US Appliance Solutions Inc. DBA GE Appliances

Sponsoring Entity
General Electric Company

System tools for integrating individual load forecasts into a composite load forecast to present a comprehensive synchronized and harmonized load forecast  
Patent #
US 20110035071A1
Filed 07/02/2010

Current Assignee
Alstom Technology Ltd.

Sponsoring Entity
Alstom Technology Ltd.

System tools for integrating individual load forecasts into a composite load forecast to present a comprehensive synchronized and harmonized load forecast  
Patent #
US 9,093,840 B2
Filed 07/02/2010

Current Assignee
Alstom Technology Ltd.

Sponsoring Entity
Alstom Technology Ltd.

RENEWABLE THERMAL ENERGY METERING AND CONTROLS SYSTEM  
Patent #
US 20110004350A1
Filed 07/01/2010

Current Assignee
INDIE ENERGY SYSTEMS COMPANY

Sponsoring Entity
INDIE ENERGY SYSTEMS COMPANY

Evaluating Energy Saving Improvements  
Patent #
US 20100305998A1
Filed 04/27/2010

Current Assignee
EMPOWERED ENERGY SOLUTIONS INC

Sponsoring Entity
EMPOWERED ENERGY SOLUTIONS INC

Methods and Systems for Analyzing Energy Usage  
Patent #
US 20110264291A1
Filed 04/26/2010

Current Assignee
Accenture Global Services Limited

Sponsoring Entity
Accenture Global Services Limited

Methods and systems for analyzing energy usage  
Patent #
US 8,386,086 B2
Filed 04/26/2010

Current Assignee
Accenture Global Services Limited

Sponsoring Entity
Accenture Global Services Limited

SYSTEM FOR MANAGING ENERGY AT LOADS  
Patent #
US 20100222934A1
Filed 01/27/2010

Current Assignee
Toshiba Corporation

Sponsoring Entity
Toshiba Corporation

System for managing energy at loads  
Patent #
US 8,543,248 B2
Filed 01/27/2010

Current Assignee
Toshiba Corporation

Sponsoring Entity
Toshiba Corporation

OPTIMIZATION OF MICROGRID ENERGY USE AND DISTRIBUTION  
Patent #
US 20100179704A1
Filed 01/14/2010

Current Assignee
Integral Analytics Inc.

Sponsoring Entity
Integral Analytics Inc.

Optimization of microgrid energy use and distribution  
Patent #
US 8,364,609 B2
Filed 01/14/2010

Current Assignee
Integral Analytics Inc.

Sponsoring Entity
Integral Analytics Inc.

AGGREGATOR, MONITOR, AND MANAGER OF DISTRIBUTED DEMAND RESPONSE  
Patent #
US 20090326726A1
Filed 06/25/2009

Current Assignee
VERSIFY SOLUTIONS INC.

Sponsoring Entity
VERSIFY SOLUTIONS INC.

Aggregator, monitor, and manager of distributed demand response  
Patent #
US 8,260,468 B2
Filed 06/25/2009

Current Assignee
VERSIFY SOLUTIONS INC.

Sponsoring Entity
VERSIFY SOLUTIONS INC.

System and method for managing and monitoring renewable energy power generation  
Patent #
US 8,761,948 B1
Filed 04/27/2009

Current Assignee
VERSIFY SOLUTIONS INC.

Sponsoring Entity
VERSIFY SOLUTIONS INC.

System and method for gathering and performing complex analyses on power data from multiple remote sources  
Patent #
US 8,606,686 B1
Filed 03/06/2009

Current Assignee
VERSIFY SOLUTIONS INC.

Sponsoring Entity
VERSIFY SOLUTIONS INC.

Universal performance monitor for power generators  
Patent #
US 8,965,719 B1
Filed 03/06/2009

Current Assignee
VERSIFY SOLUTIONS INC.

Sponsoring Entity
VERSIFY SOLUTIONS INC.

Portal Performance Optimization  
Patent #
US 20100198759A1
Filed 02/04/2009

Current Assignee
Workday Incorporated

Sponsoring Entity
Workday Incorporated

Portal performance optimization  
Patent #
US 8,121,960 B2
Filed 02/04/2009

Current Assignee
Workday Incorporated

Sponsoring Entity
International Business Machines Corporation

DISTRIBUTED GRIDINTERACTIVE PHOTOVOLTAICBASED POWER DISPATCHING  
Patent #
US 20100174418A1
Filed 01/02/2009

Current Assignee
International Business Machines Corporation

Sponsoring Entity
International Business Machines Corporation

Distributed gridinteractive photovoltaicbased power dispatching  
Patent #
US 8,352,091 B2
Filed 01/02/2009

Current Assignee
International Business Machines Corporation

Sponsoring Entity
International Business Machines Corporation

SYSTEM AND METHOD OF DEMOCRATIZING POWER TO CREATE A METAEXCHANGE  
Patent #
US 20100138066A1
Filed 11/13/2009

Current Assignee
THINKECO POWER INC.

Sponsoring Entity
THINKECO POWER INC.

Electric power grid control using a marketbased resource allocation system  
Patent #
US 20100114387A1
Filed 09/29/2009

Current Assignee
Battelle Memorial Institute

Sponsoring Entity
Battelle Memorial Institute

UTILITY MANAGED VIRTUAL POWER PLANT UTILIZING AGGREGATED THERMAL ENERGY STORAGE  
Patent #
US 20090093916A1
Filed 12/16/2008

Current Assignee
GreenerIce Spv LLC

Sponsoring Entity
GreenerIce Spv LLC

AUTOMATED PEAK DEMAND CONTROLLER  
Patent #
US 20090063257A1
Filed 08/29/2008

Current Assignee
POWERIT SOLUTIONS LLC

Sponsoring Entity


ENERGY OPTIMIZATION SYSTEM  
Patent #
US 20090319090A1
Filed 06/19/2008

Current Assignee
Honeywell International Inc.

Sponsoring Entity
Honeywell International Inc.

METHOD AND SYSTEM FOR SCHEDULING THE DISCHARGE OF DISTRIBUTED POWER STORAGE DEVICES AND FOR LEVELIZING DISPATCH PARTICIPATION  
Patent #
US 20080281663A1
Filed 05/09/2008

Current Assignee
Gridpoint

Sponsoring Entity
Gridpoint

UTILITY CONSOLE FOR CONTROLLING ENERGY RESOURCES  
Patent #
US 20080167756A1
Filed 01/03/2008

Current Assignee
Gridpoint

Sponsoring Entity


METHOD OF COMMUNICATING BETWEEN A UTILITY AND ITS CUSTOMER LOCATIONS  
Patent #
US 20080177678A1
Filed 01/24/2007

Current Assignee
Southern California Edison Company

Sponsoring Entity
Southern California Edison Company

System and method for determining expected unserved energy to quantify generation reliability risks  
Patent #
US 7,698,233 B1
Filed 01/23/2007

Current Assignee
Southern Company Services Inc.

Sponsoring Entity
Southern Company Services Inc.

SYSTEM AND METHOD FOR POLICY BASED CONTROL OF LOCAL ELECTRICAL ENERGY GENERATION AND USE  
Patent #
US 20080046387A1
Filed 07/23/2006

Current Assignee
Rajeev Gopal, GOPAL ROHIT

Sponsoring Entity
Rajeev Gopal, GOPAL ROHIT

Home power management system  
Patent #
US 20060259332A1
Filed 07/14/2006

Current Assignee
ROBERT BOSCH HEALTHCARE SYSTEM INC.

Sponsoring Entity
ROBERT BOSCH HEALTHCARE SYSTEM INC.

Method and system to calculate a demand for energy  
Patent #
US 7,406,364 B2
Filed 09/12/2002

Current Assignee
ABB Schweiz AG

Sponsoring Entity
ABB AB

Business management system and method for a deregulated electric power market using workspace portals.  
Patent #
US 20030041039A1
Filed 05/10/2002

Current Assignee
Siemens Power Generation Inc.

Sponsoring Entity
Siemens Power Generation Inc.

Method for evaluation of energy utilities  
Patent #
US 6,988,092 B1
Filed 12/21/2001

Current Assignee
ABB Research Ltd.

Sponsoring Entity
ABB Research Ltd.

System and method for energy management  
Patent #
US 6,785,592 B1
Filed 07/13/2000

Current Assignee
NTT DATA SERVICES CORPORATION

Sponsoring Entity
Perot Systems Corporation

20 Claims
 1. A system for energy optimization, the system comprising:
 a server;
one or more databases in communication with the server;
the server is configured for;
receiving information collector data from at least one information collector, the information collector data comprising nearreal time individualized energy usage data for each of a plurality of customers or customer locations;
calculating a cost of service for each of the plurality of customers or customer locations based on their (1) individualized energy usage data, (2) a system generation cost for an energy provider or a locational marginal price of electricity, and (3) characteristics of an electric distribution system used to supply power to each of the plurality of customers or customer locations, the calculating further comprising assigning an individualized relative marginal cost value for each of the customers or customer locations, wherein the relative marginal cost value indicates differences in cost of service for different customers or customer locations, combining the relative marginal cost value with a weighted customer cost, wherein the weighted customer cost indicates an importance of a cost category for individual customers or customer locations;
forecasting individualized energy usage for each of the plurality of customers or customer locations;
forecasting customer specific cost of service for each of the plurality of customers or customer locations using the calculating results; and
optimizing, over a plurality of customers or customer locations, energy use and cost of service using the forecasted individualized energy usage and the forecasted customer specific cost of service.  View Dependent Claims (2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
 a server;
 13. A method for energy optimization, the method comprising:
 receiving, by a processor, information collector data from at least one information collector, the information collector data comprising nearreal time individualized energy usage data for each of a plurality of customers or customer locations;
calculating, by a processor, a cost of service for each of the plurality of customers or customer locations based on their (1) individualized energy usage data, (2) a system generation cost for an energy provider or a locational marginal price of electricity, and (3) characteristics of an electric distribution system used to supply power to each of the plurality of customers or customer locations, the calculating further comprising assigning an individualized relative marginal cost value for each of the customers or customer locations, wherein the relative marginal cost value indicates differences in cost of service for different customers or customer locations, combining the relative marginal cost value with a weighted customer cost, wherein the weighted customer cost indicates an importance of a cost category for individual customers or customer locations;
forecasting, by a processor, individualized energy usage for each of the plurality of customers or customer locations;
forecasting, by a processor, customer specific cost of service for each of the plurality of customers or customer locations using the calculating results; and
optimizing, by a processor, over a plurality of customers or customer locations, energy use and cost of service using the forecasted individualized energy usage and the forecasted customer specific cost of service.  View Dependent Claims (14, 15, 16, 17, 18, 19, 20)
 receiving, by a processor, information collector data from at least one information collector, the information collector data comprising nearreal time individualized energy usage data for each of a plurality of customers or customer locations;
1 Specification
This application is a Continuation of U.S. patent application Ser. No. 12/687,827, filed Jan. 14, 2010, which claims the benefit of U.S. Provisional Patent Application No. 61/144,642, filed Jan. 14, 2009, and U.S. Provisional Patent Application No. 61/228,010, filed Jul. 23, 2009; the contents of which are incorporated by reference herein in their entireties.
FIELD OF THE INVENTIONThe present invention relates to microgrid technology, and, more specifically, to optimization of energy use and distribution within a microgrid system.
BACKGROUND OF INVENTIONThe most common historical methods and processes for reducing peak electric demand involve controlling heating, cooling, or water heating in customer facilities. These control operations may include curtailing, cycling, reduction and/or periodic cessation of particular uses. These control operations are typically performed through voluntary action by customers or through voluntary participation in a utility controlled program.
In prior systems, these control operations were conducted by one way signaling of prespecified on and off cycles. The commands to cycle on or off were typically directed by the utility. In a typical situation, a single, uniformlyapplied dispatching strategy would have been issued. For example, air conditioners may have been instructed to cycle air conditioners off for 30 minutes of 60 possible minutes each hour over the course of the next 4 to 6 hours. These instructions would typically occur during times of extreme peak loads on the utility system. Frequently, customers chose a level of cycling prior to any actual events. For instance, in the previous example air conditioners are cycled off for 50% of an hour. Customers could also choose to cycle off for 75% of an hour, for example, or 45 minutes off out of 60 possible minutes.
During this controlled cycling, energy was reduced during the time of the interruptions, unless the customer's natural on/off cycling of that appliance was less than the utility's desired control. The utility, however, would not consider the relative cycling schedules for similarly situated homes along the same circuit. The utility would not optimize cycling of customers relative to one another along a circuit, nor tie the cycling directly to the intrahour peak demand of the utility, the localized or customerspecific cost to serve, or the characteristics and avoided costs related to the customers' location on a circuit.
With the advent of “smart grid” technologies, also called “smart home”, “smart meter”, or “home area network” (HAN) technologies, optimized demand reductions became possible at the end use or appliance level. Smart grid technologies provided the ability to capture realtime or nearrealtime enduse data and enabled twoway communication. Smart grid technologies currently exist for at least some percentage of a utility's customer base.
Using smart grid technologies, a system operator can optimally and dynamically dispatch on and off signaling to specific appliances at a customer location given the observed and forecast loads of other appliances on a circuit or system. In these systems, optimally dispatched appliances, enduses or vehicle loads differ from traditionally dispatched utility supply assets in that traditional supply assets have historically been dispatched based on aggregatelevel or systemwide least cost operational principles. The key differences between dispatching supply assets and dispatching appliances are highlighted below.
First, the forced change in an appliance's duty or “on” cycle, via traditional one way signaling, ignored the operations and scheduling of other appliance loads on a circuit. Often, a utility system peak is realized when enduses, otherwise randomly operating without central control, happen to cooccur or run at the same time during a short period of time. Rather than build supply capacity to meet these randomly occurring events, needs exists to more intelligently choreograph or manage these end uses, relative to each other, yet still provide the desired power and energy to customers such that their comfort, convenience or needs are not compromised. Needs exist for systems that optimally dispatch, schedule and manage how and when these appliance and end uses use energy, conditioned on the observed and forecasted usage of other appliances, such that the overall utility peak and system cost to serve all customers is minimized. Within traditional supply side resource dispatching frameworks, the customer load is given, and supply side resources are dispatched to accommodate this load, without regard for local cost to serve, or the ability to dispatch customer end uses, relative to each other, given a local marginal cost or specific needs or conditions exhibited along the circuit.
Second, traditional supply dispatching decisions valued only the marginal cost changes caused by aggregate supply changes and aggregate demand reduction of oneway signaling. Needs exist for systems that enable the active participation of demands into the supply analysis. Furthermore, if large enough loads are available, needs exist for systems that enable demand control to become a marginal price setter for marginal increments of “supply/demand” decisions. This may lower the marginal capacity or energy cost below the comparable, incremental unit of marginal supply. Further, traditional supply side dispatching systems operate on a single, regional price or cost to serve, often called a Locational Marginal Price or Cost (LMP). This price determines which supply side resources to dispatch within a region. However, this price necessarily reflects an average price within a region, not the local marginal cost to serve a given customer or given end use, nor considerations inherent within the energy distribution system.
Third, in the case of adding a supply side resource, energy still must be transmitted, distributed, and voltage adjusted in the delivery of electrons from a centralized plant to the customer's site. Needs exist for systems which incorporate, and optimally dispatch loads given these distribution costs, and adjust the value obtained from each customer site based on the forecasted losses, distribution costs, or voltage improvements, incurred for each customer, load and daytype. Traditional supplyoriented dispatching systems do not consider, or incorporate, distribution level cost benefits or risks within their dispatching decisions. Similarly, gridbased distribution management systems do not include supply side energy costs in their control systems which attend more toward voltage, reactive power, power factor, primary line losses or capacity inadequacies. As such, needs exist for a more focused attention on integrative systems that incorporate the value, costs and risks inherent in both the supply side and the distribution of electricity through the balanced consideration of demand side and supply side costs, the actual and forecasted cost to serve each home or businesses, and the more precise marginal cost and dispatching decisions, which supply dispatching methods alone cannot achieve.
Historically, previous demand reduction methods have ignored many demandspecific issues and impacts, microlevel marginal cost and value factors (e.g., marginal costs at the networked bus, primary losses, secondary losses, voltage benefits, power factor benefits, deferred localized distribution capacity additions, coordinated load control and scheduling across a circuit to levelize load), customer decision variables (e.g., comfort constraints, pricesetting options, override flexibility, behavioral predictions regarding appliance use, desire for bill stability, electric vehicle charging convenience and cost, solar, wind, other distributed generation additions), and the important changes in the marginal cost of supply resources that occur as more and more demand side options or distributed resources are adopted by customers. Needs exist for systems that permit the inclusion and consideration of more complex, robust and more customerfocused and locationfocused sources for managing the supply/demand/delivery energy balance, which reflects both price and nonprice customer behavior influences, in addition to the traditional options.
Needs exist for systems that provide near realtime appliance control and coordination not only relative to each other, to achieve least cost operational utility needs, but also relative to emerging resources such as wind, solar, storage batteries, distributed generation or electric vehicles, among others. Here, these emerging resources are often characterized by many units dispersed locally, in contrast to traditional supply resources which are more centralized and larger. Given the increasing emergence of these smaller, localized, widely distributed resources, the importance and value of coordinated dispatch, of loadleveling subject to energy reductions, or of dispatching these distributed resources in an optimal least cost manner becomes increasingly important. The development of microgridspecific algorithms that incorporate the realtime coordination of dispatchable customers' loads, over widely dispersed locales in greater number, and in conjunction with distributed storage (stand alone batteries and/or batteries in plugin hybrid electric vehicles) and distributed generation, including, but not limited to, renewable sources, requires more comprehensive and sophisticated dispatching solutions and systems to accommodate these emerging complexities.
Needs exist for systems that provide more automated control and support to customers, such that they can participate in energy conserving behaviors without requiring them to continually attend to utilityissued hourly, daily or other time of use price signals. Traditionally, utility sponsored time of use pricing promotions do not exhibit wide participation among customers, or require frequent monitoring by customers, to achieve bill savings or energy reductions. Needs exist for systems which enable customers to set desired bill savings, desired energy reduction, and then not be required to attend to these settings continually. Rather, any perceived reduction in comfort, convenience or savings achieved can be overridden or changed at any time that it is noticed or desirably to change these settings, but that needed systems are constructed such that customers are able to gain the benefits of cost savings and comfort control, without having to constantly monitor the system.
Needs exist for customers to reduce the natural volatility in their monthly electricity bills, primarily caused by varying weather conditions from month to month. Systems are desired that are able to lock in a targeted bill amount for a given time period, and either directly control customer appliances to achieve that end, or issue messages and communication to customers regarding their progress, or lack thereof, against this targeted bill, during that time period.
SUMMARY OF INVENTIONCertain embodiments of the present invention may provide a system for near realtime, micro level energy optimization. A system may include a server and one or more databases, the server operating in near realtime. The system may communicate with an energy provider that supplies energy to a plurality of customers to receive energy provider data, at least one information collector to receive information collector data including at least one of individualized energy usage data, customer preferences, and customer or location characteristics from the at least one information collector, and the one or more databases to receive data for optimization from the one or more databases. The system may calculate a cost of service or avoided cost for at least one of the plurality of customers or customer locations using at least one of the individualized energy usage data and a system generation cost at a nearest bus. The system may forecast at least one of individualized demand by enduse, or individualized demand by location for at least one of the plurality of customers or customer locations, or energy prices and energy costs. The system may also optimize energy distribution, energy use, the cost of service, or avoided cost using at least one of: the forecasted individualized demand by enduse, the forecasted individualized demand by location, the forecasted energy prices, and the forecasted energy costs. Interaction between the calculating, forecasting and optimizing may allow management and dispatch of enduses and energy supply at a micro level in near realtime.
In certain embodiments, the at least one information collector may be a third party vendor, and the individualized energy usage data is enduse level information collected through a home area network system. The at least one information collector may be a third party vendor, and the individualized energy usage data is sitelevel information collected through a smart meter. The at least one information collector may be a fourth party vendor, wherein at least one of the plurality of customers or customer locations are not part of a third party vendor customer base.
In embodiments of the present invention, near realtime may be a five minute interval or less. The individualized energy usage data may be available at an enduse level and the customer preferences are received for each enduse from each of the plurality of customers or customer locations. The customer preferences may include additional data selected from the group consisting of: customer willingness to have the enduse interrupted, customer willingness to have the enduse managed, customer willingness to have the enduse scheduled, desired bill levels, and combinations thereof.
The optimizing may also consider data selected from the group consisting of: the customer preferences, the customer or location characteristics, customer overrides, compliance histories, enduse information, enduse usage history, billing information including rates, historical individualized demand, historical and forecasted weather, historical and forecasted avoided costs by each of the plurality of customers or customer locations for commodity and noncommodity cost of service factors, historic and forecasted renewable generation, storage system capacity, storage charge and discharge rates, battery capacity, battery charging and discharge rates, vehicle arrival times, battery fill preferences, battery fill forecasts, desired bill levels, customer management settings per month, customer responses to prior program offerings, research surveys, satisfaction and behavioral/choice preferences, required energy reductions, required demand reductions, and combinations thereof.
The energy provider data may include overall energy usage data, required energy reductions, required demand reductions, cost of energy data, and data regarding distribution of energy. The system may also receive an actual system generation cost from the energy provider or a locational marginal cost of energy from an independent system operator for a bus in near realtime. Forecasting the system generation cost at a bus or locational marginal cost at a bus may use at least one of the following separate, interactive, nonlinear, or moving average terms: temperature, humidity, wind speed, time of day, day of week, month indicator variables, past values of the locational marginal cost at a bus, with parameters estimated wherein<FORM>φ(L)[(1−L)(LMP<sub>t</sub>−X<sub>t</sub>β]=θ(L)ε<sub>t </sub></FORM>
Where
L<sup>j</sup>LMP<sub>t</sub>=LMP<sub>t−j </sub>
φ(L)=1−φ<sub>1</sub>L−φ<sub>2</sub>L<sup>2</sup>− . . . −φ<sub>p</sub>L<sup>p </sup>
θ(L)=1−θ<sub>1</sub>L−θ<sub>2</sub>L<sup>2</sup>− . . . −θ<sub>q</sub>L<sup>q</sup>.
The system generation cost may be forecast for a bus using data including: generation units, system load, load on the bus, load on other buses, transmission capacity characteristics, microgrid distributed generation, and power flows. The system generation cost at a bus may be forecast in near realtime using: forecasted weather conditions, forced outage and transmission congestion inputs, generation units, forecasted system load, microgrid distributed generation forecasts, forecasted demand reductions, and a forecasted load at the bus.
Embodiments of the present invention may include receiving distributed generation data in at least near real time and/or receiving distributed storage data in at least near real time.
The calculating cost of service or avoided cost may use one or more of the following: primary line losses; secondary line losses; one or more voltage adder; marginal distribution capital costs; a shaping premium; a swing premium; a capacity premium; ancillary services costs; noncommodity and nondistribution related adders; and combinations thereof.
The forecasting of individualized demand by enduse or individualized demand by location may use inputs selected from the group consisting of: load prediction; weather forecasts; risk given load uncertainty; customer compliance forecasts; customer probability of override forecasts; time of day effects; day of week effects, and combinations thereof.
The optimizing may also use at least one of: the energy provider data, the information collector data, and the data for optimization.
In certain embodiments, the optimizing may include at least one of: maximizing revenue of the energy provider, minimizing customer discomfort, maximizing avoided costs, minimizing incentive costs, minimizing cost to provide and deliver power, and combinations thereof, while achieving a required total demand reduction or total energy reduction. The optimizing may use an incentive, the cost of service or avoidable cost, energy rates, the forecasted individualized demand by enduse, total time of current interruption or scheduling event, each customers' preferences for interruptions by enduse, total time each customer can be interrupted or rescheduled, probability that each customer will override an interruption, a total allowed number of controls per customer per time period, a maximum cycling for an enduse, soft and hard costs associated with controlling each of the plurality of customers, costs that vary by enduse, cycling of the enduse within lower and upper bounds, maintaining a predetermined level of enduse settings, enduse cycling constraints based on manufactured limits, staggering enduse starts, and combinations thereof. The optimizing may be represented as:
<maths id="MATHUS00001" num="00001"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><mo>(</mo><mrow><mrow><msub><mi>R</mi><mi>ih</mi></msub><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow><mo></mo><mrow><mo>(</mo><mrow><mrow><msub><mi>I</mi><mi>ijh</mi></msub><mo></mo><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>+</mo><mrow><msub><mi>COS</mi><mi>it</mi></msub><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></mrow><mo>)</mo></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths><maths id="MATHUS000012" num="00001.2"><math overflow="scroll"><mrow><mstyle><mspace width="4.4em" height="4.4ex"/></mstyle><mo></mo><mrow><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mstyle><mspace width="4.4em" height="4.4ex"/></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow></mrow><mo>≤</mo><mrow><msub><mi>Hours</mi><mrow><mi>ij</mi><mo></mo><mstyle><mtext></mtext></mstyle><mo></mo><mstyle><mtext></mtext></mstyle></mrow></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></mrow></mrow></math></maths><maths id="MATHUS000013" num="00001.3"><math overflow="scroll"><mrow><mstyle><mspace width="4.4em" height="4.4ex"/></mstyle><mo></mo><mrow><mrow><mrow><mn>0</mn><mo>≤</mo><msub><mi>X</mi><mi>ijh</mi></msub><mo>≤</mo><mrow><msub><mi>UB</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></mrow></math></maths><maths id="MATHUS000014" num="00001.4"><math overflow="scroll"><mrow><mstyle><mspace width="4.4em" height="4.4ex"/></mstyle><mo></mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><mrow><msub><mi>Reduction</mi><mi>h</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>h</mi></mrow><mo>∈</mo><mi>H</mi></mrow></mrow></mrow></math></maths>
In certain embodiments, the optimizing may include minimizing a total system peak demand during a period over the plurality of customers or customer locations subject to enduse kWh requirements and total kWh demand for each of the plurality of customers or customer locations. The optimizing may use the forecasted individualized demand by enduse, the forecasted individualized demand by location, and a real power of each enduse for the plurality of customers or customer locations. The optimizing may be represented as:
Min P
s.t.
<maths id="MATHUS00002" num="00002"><math overflow="scroll"><mrow><mrow><mrow><munderover><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow><mo>=</mo><mrow><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>i</mi></mrow><mo>∈</mo><mi>I</mi></mrow></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>HVAC</mi></mrow></mrow></math></maths><maths id="MATHUS000022" num="00002.2"><math overflow="scroll"><mrow><mrow><mrow><munderover><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mrow><mi>J</mi><mo>≠</mo><mi>HVAC</mi></mrow></mrow></mrow></math></maths><maths id="MATHUS000023" num="00002.3"><math overflow="scroll"><mrow><mrow><mrow><mi>P</mi><mo>≥</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>n</mi><mo>∈</mo><mi>N</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>NDemand</mi><mi>nh</mi></msub></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></math></maths>
In certain embodiments, the optimizing may include maximizing revenue, minimizing a total energy provider cost to provide and deliver energy, or maximizing avoided costs during a period over a plurality of customers or customer locations subject to enduse kW requirements and total kWh demand for the plurality of customers or customer locations during the period. The optimizing may use the forecasted cost of service or avoided cost, an energy rate, a real power of enduses, and the forecasted individualized demand by enduse. The optimizing may be represented as:
<maths id="MATHUS00003" num="00003"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><mo>(</mo><mrow><msub><mi>R</mi><mi>ih</mi></msub><mo></mo><mrow><msub><mi>COS</mi><mi>ith</mi></msub><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><mo>(</mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo>·</mo><msub><mi>RP</mi><mi>j</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow></math></maths><maths id="MATHUS000032" num="00003.2"><math overflow="scroll"><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo>·</mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>i</mi></mrow><mo>∈</mo><mi>I</mi></mrow></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mrow><mi>H</mi><mo>.</mo></mrow></mrow></mrow></math></maths>
In certain embodiments, the optimizing may include maximizing avoided cost, minimizing total cost to serve and deliver, or maximizing revenue subject to a predetermined individualized bill level set in advance by each customer for a period. The optimizing may use the forecasted cost of service or avoidable cost, an energy rate, a forecasted nondispatchable energy demand for each of the plurality of customers or customer locations for the period, the forecasted individualized demand by enduse, and a predetermined bill level for each of the plurality of customers or customer locations. The optimizing may be represented as:
<maths id="MATHUS00004" num="00004"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><mrow><mo>(</mo><mrow><msub><mi>R</mi><mi>ht</mi></msub><mo></mo><msub><mi>COS</mi><mi>ht</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><mrow><mo>(</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><mo>(</mo><mrow><msub><mi>Demand</mi><mi>jth</mi></msub><mo>·</mo><msub><mi>X</mi><mi>jth</mi></msub></mrow><mo>)</mo></mrow></mrow><mo>+</mo><msub><mi>NonDisp</mi><mi>th</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths><maths id="MATHUS000042" num="00004.2"><math overflow="scroll"><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><mrow><mo>(</mo><mrow><mrow><mo>(</mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><msub><mi>X</mi><mi>jth</mi></msub><mo>·</mo><msub><mi>Demand</mi><mi>jth</mi></msub></mrow></mrow><mo>)</mo></mrow><mo>+</mo><msub><mi>NDisp</mi><mi>th</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><msub><mi>R</mi><mi>th</mi></msub></mrow></mrow></mrow></mrow><mo>=</mo><mrow><mi>Bill</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>Target</mi></mrow></mrow></math></maths><maths id="MATHUS000043" num="00004.3"><math overflow="scroll"><mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><mrow><mrow><mn>0</mn><mo>≤</mo><msub><mi>X</mi><mi>jth</mi></msub><mo>≤</mo><mrow><msub><mi>UB</mi><mi>jth</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>j</mi></mrow></mrow><mo>∈</mo><mi>J</mi></mrow><mo>,</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mrow><mi>H</mi><mo>.</mo></mrow></mrow></mrow></mrow></math></maths>
In certain embodiments, the optimizing may include minimizing renewable generation volatility subject to a generation level during a period and storage system capacity. The optimizing may use a power output of a distributed storage system, a power output of a distributed generation source sent to the distributed storage system, a power generation from the distributed generation source, a storage level of the distributed storage system, an initial storage level of the distributed, and storage system charge and discharge rates. The optimizing may be represented as:
Max PVBatt
s.t.<FORM>PVBatt≦PVOut<sub>t</sub>+BattOut<sub>t </sub>tεT </FORM><FORM>PVOut<sub>t</sub>=PVGen<sub>t</sub>−PVIn<sub>t </sub>tεT </FORM><FORM>BattLvl<sub>t+1</sub>=BattLvl<sub>t</sub>+PVIn<sub>t</sub>−BattOut<sub>t </sub>tεT </FORM><FORM>BattLvl<sub>t=0</sub>=K</FORM><FORM>BattCap≧BattLvl<sub>t </sub>tεT</FORM>
Where:
 PVBatt is power output of a distributed generation and distributed storage system
 PVOut<sub>t </sub>is power from the distributed generation that is sent out to an energy distribution system at time t
 PVIn<sub>t </sub>is power from the distributed generation that is sent out to the distributed storage at time t
 PVGen<sub>t </sub>is power generation from the distributed generation at time t
 BattLvl<sub>t </sub>is a storage level of the distributed storage at time t
 BattOut<sub>t </sub>is power from the distributed storage sent out to the energy distribution system at time t
 BattLv<sub>lt=0 </sub>is an initial storage level of the distributed storage set to a value K
 BattCap is the capacity of the distributed storage.
The optimizing may be represented as:
<maths id="MATHUS00005" num="00005"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mtable><mtr><mtd><mrow><mrow><mo>(</mo><mrow><mrow><msub><mi>R</mi><mi>it</mi></msub><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>X</mi><mi>it</mi></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>PVtG</mi><mi>t</mi></msub></mrow></mrow><mo>)</mo></mrow><mo></mo></mrow></mtd></mtr><mtr><mtd><mrow><mrow><msub><mi>I</mi><mi>it</mi></msub><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow><mo></mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo></mo><mrow><msub><mi>PVC</mi><mi>t</mi></msub><mo></mo><msub><mi>PVGen</mi><mi>t</mi></msub></mrow><mo></mo></mrow></mtd></mtr><mtr><mtd><mrow><mrow><mo>(</mo><mrow><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>PVtC</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><msub><mi>COS</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow></mrow></mtd></mtr></mtable></mrow></mrow></mrow></math></maths><maths id="MATHUS000052" num="00005.2"><math overflow="scroll"><mrow><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><msub><mi>Dmd</mi><mi>it</mi></msub></mrow><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow><mo>=</mo><mrow><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><mrow><msub><mi>GtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow><mo>,</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></mrow></math></maths><maths id="MATHUS000053" num="00005.3"><math overflow="scroll"><mrow><msub><mi>PVGen</mi><mi>t</mi></msub><mo>=</mo><mrow><mrow><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>PVtG</mi><mi>t</mi></msub><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths><maths id="MATHUS000054" num="00005.4"><math overflow="scroll"><mrow><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mrow><mi>t</mi><mo>+</mo><mn>1</mn></mrow></msub></mrow><mo>=</mo><mrow><mrow><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mi>t</mi></msub></mrow><mo>+</mo><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>GtB</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><msub><mi>BtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths><maths id="MATHUS000055" num="00005.5"><math overflow="scroll"><mrow><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mrow><mi>t</mi><mo>=</mo><mn>0</mn></mrow></msub></mrow><mo>=</mo><mi>K</mi></mrow></math></maths><maths id="MATHUS000056" num="00005.6"><math overflow="scroll"><mrow><mrow><mi>BattCap</mi><mo>≥</mo><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mi>t</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></math></maths>
Where:
 R<sub>it </sub>is a cost charged to customer i in time t for energy
 Dmd<sub>it </sub>is demand for energy for customer i at time t
 X<sub>it </sub>is a fraction of period t to supply energy to customer i
 LMP<sub>t </sub>is Locational Marginal Cost at a distributed storage and a distributed generation
 BtG<sub>t </sub>is sales of power at time t from distributed storage to an energy distribution system
 PVtG<sub>t </sub>is sales of power at time t from the distributed generation to the energy distribution system
 I<sub>it </sub>is an incentive offered by the energy provider to customer i to curtail customer power during time t
 COS<sub>it </sub>is a cost to serve adder associated with moving electricity from a substation to customer i during period t
 GtC<sub>it</sub>, BtC<sub>it</sub>, and PVtC<sub>it</sub>, are the power from the energy distribution system, the distributed storage, and the distributed generation, respectively, to meet customer i's demand during period t
 PVB<sub>t </sub>is power from the distributed generation sent out to the distributed storage for storage at time t
 PVGen<sub>t </sub>is power generation from the distributed generation at time t
 BattLvl<sub>t </sub>is a storage level of the distributed storage at time t
 GtB<sub>t </sub>is power sent from the energy distribution system to the distributed storage for storage at time t.
 BattLv<sub>lt=0 </sub>is an initial storage level of the distributed storage set to a value K
 BattCap is the capacity of the distributed storage.
The optimizing may be represented as:
<maths id="MATHUS00006" num="00006"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mtable><mtr><mtd><mrow><mrow><mo>(</mo><mrow><mrow><msub><mi>R</mi><mi>it</mi></msub><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>X</mi><mi>it</mi></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>PVtG</mi><mi>t</mi></msub></mrow></mrow><mo>)</mo></mrow><mo></mo></mrow></mtd></mtr><mtr><mtd><mrow><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo></mo><mrow><msub><mi>PVC</mi><mi>t</mi></msub><mo></mo><msub><mi>PVGen</mi><mi>t</mi></msub></mrow><mo></mo></mrow></mtd></mtr><mtr><mtd><mrow><mrow><mo>(</mo><mrow><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>PVtC</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><msub><mi>COS</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow></mrow></mtd></mtr></mtable></mrow></mrow></mrow></math></maths><maths id="MATHUS000062" num="00006.2"><math overflow="scroll"><mrow><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><msub><mi>Dmd</mi><mi>it</mi></msub></mrow><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow><mo>=</mo><mrow><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><mrow><msub><mi>GtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow><mo>,</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></mrow></math></maths><maths id="MATHUS000063" num="00006.3"><math overflow="scroll"><mrow><mrow><munderover><mo>∑</mo><mi>t</mi><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow></mrow><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mi>t</mi><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow></mrow></math></maths><maths id="MATHUS000064" num="00006.4"><math overflow="scroll"><mrow><msub><mi>PVGen</mi><mi>t</mi></msub><mo>=</mo><mrow><mrow><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>PVtG</mi><mi>t</mi></msub><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths><maths id="MATHUS000065" num="00006.5"><math overflow="scroll"><mrow><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mrow><mi>t</mi><mo>+</mo><mn>1</mn></mrow></msub></mrow><mo>=</mo><mrow><mrow><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mi>t</mi></msub></mrow><mo>+</mo><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>GtB</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle></munderover><mo></mo><mrow><msub><mi>BtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths><maths id="MATHUS000066" num="00006.6"><math overflow="scroll"><mrow><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mrow><mi>t</mi><mo>=</mo><mn>0</mn></mrow></msub></mrow><mo>=</mo><mi>K</mi></mrow></math></maths><maths id="MATHUS000067" num="00006.7"><math overflow="scroll"><mrow><mrow><mi>BattCap</mi><mo>≥</mo><mrow><mi>BattLv</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mn>1</mn><mi>t</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></math></maths>
Where:
 R<sub>it </sub>is a cost charged to customer i in time t for energy
 Dmd<sub>it </sub>is demand for energy for customer i at time t
 X<sub>it </sub>is a fraction of period t to supply energy to customer i
 LMP<sub>t </sub>is Locational Marginal Cost at a distributed storage and a distributed generation
 BtG<sub>t </sub>is sales of power at time t from distributed storage to an energy distribution system
 PVtG<sub>t </sub>is sales of power at time t from the distributed generation to the energy distribution system
 COS<sub>it </sub>is a cost to serve adder associated with moving electricity from a substation to customer i during period t
 GtC<sub>it</sub>, BtC<sub>it</sub>, and PVtC<sub>it</sub>, are the power from the energy distribution system, the distributed storage, and the distributed generation, respectively, to meet customer i's demand during period t
 PVB<sub>t </sub>is power from the distributed generation sent out to the distributed storage for storage at time t
 PVGen<sub>t </sub>is power generation from the distributed generation at time t
 BattLvl<sub>t </sub>is a storage level of the distributed storage at time t
 GtB<sub>t </sub>is power sent from the energy distribution system to the distributed storage for storage at time t.
 BattLv<sub>lt=0 </sub>is an initial storage level of the distributed storage set to a value K
 BattCap is the capacity of the distributed storage.
In certain embodiments, the optimizing may include maximizing revenue, minimizing total cost to provide and deliver power, or maximizing avoided costs during a period over a plurality of customers or customer locations, a plurality of distributed generation sources and a plurality of distributed storage systems. The optimizing may use an energy rate during the period, the forecasted individualized demand by enduse, a forecasted individualized locational marginal cost of energy at each of the plurality of distributed generation sources and each of the plurality of distributed storage systems, incentives, the forecasted individualized cost of service or avoidable cost, forecasted power generation from each of the plurality of distributed generation sources, and the initial storage level of each the plurality of the distributed storage systems.
The optimizing may consider uncertainty in forecast variables. The uncertainty may use a conditional value at risk to incorporate, and provides for least cost planning dispatching solutions applied to enduses, distributed storage, ancillary services, allocations of cost of service adders or premiums, and combinations thereof.
In certain embodiments, the system may send instructions for enacting results of the optimizing.
In certain embodiments, forecasting daily energy prices may be represented as:<FORM>P<sub>t</sub><sup>D</sup>=ƒ<sub>1</sub>({right arrow over (P)}<sub>t</sub>,{right arrow over (W)}<sub>t</sub>,{right arrow over (Y)}<sub>t</sub>,{right arrow over (X)}<sub>t</sub>,ε)</FORM>
Where
 ƒ<sub>1</sub>: is an underlying regression function
 P<sub>t</sub><sup>D </sup>is a daily average electricity price of day t
 {right arrow over (P)}<sub>t</sub>: is a past daily average electricity price vector at day t
 {right arrow over (W)}<sub>t</sub>: is a past weather condition vector at day t
 {right arrow over (Y)}<sub>t</sub>: is a seasonality variables vector at day t
 {right arrow over (X)}<sub>t</sub>: is other independent variables vector at day t
 ε<sub>t</sub>: is a white noise error terms at day t.
In certain embodiments, the system may forecast a forward cost of energy represented as:
<maths id="MATHUS00007" num="00007"><math overflow="scroll"><mrow><mi>LWFCE</mi><mo>=</mo><mrow><munderover><mo>∑</mo><mi>t</mi><mi>T</mi></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><mfrac><mn>1</mn><mrow><mo>(</mo><mrow><mrow><munderover><mo>∑</mo><mi>i</mi><msub><mi>n</mi><mi>t</mi></msub></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>Q</mi><mi>i</mi></msub></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mi>j</mi><msub><mi>m</mi><mi>t</mi></msub></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>Q</mi><mi>j</mi></msub></mrow></mrow><mo>)</mo></mrow></mfrac><mo></mo><mrow><mo>(</mo><mrow><mrow><msub><mi>P</mi><mi>t</mi></msub><mo>·</mo><mrow><munderover><mo>∑</mo><mi>i</mi><msub><mi>n</mi><mi>t</mi></msub></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>Q</mi><mi>i</mi></msub></mrow></mrow><mo>+</mo><mrow><msub><mi>OP</mi><mi>t</mi></msub><mo>·</mo><mrow><munderover><mo>∑</mo><mi>j</mi><msub><mi>m</mi><mi>t</mi></msub></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>Q</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow></math></maths>
Where
LWFCE is a load weighted forward cost of energy
n<sub>t </sub>is peak hours in month t
m<sub>t </sub>is offpeak hours in month t
T is total months in the term of a contract
Q<sub>i </sub>is energy demand in peak hour i
Q<sub>j </sub>is energy demand in offpeak hour j
P<sub>t </sub>is a monthly forward peak price
OP<sub>t </sub>is a monthly forward offpeak price.
In certain embodiments, the system may communicate with at least one of the plurality of customers or customer locations through a customer portal. The system may communicate with the energy provider though a utility portal.
Certain embodiments of the present invention may provide a method for near realtime, micro level energy optimization. A processor may process in near realtime. The method may communicate with an energy provider that supplies energy to a plurality of customers to receive energy provider data, at least one information collector to receive information collector data including at least one of individualized energy usage data, customer preferences, and customer or location characteristics from the at least one information collector, and the one or more databases to receive data for optimization from the one or more databases. The method may calculate a cost of service or avoided cost for at least one of the plurality of customers or customer locations using at least one of the individualized energy usage data and a system generation cost at a nearest bus. The method may forecast at least one of individualized demand by enduse, or individualized demand by location for at least one of the plurality of customers or customer locations, or energy prices and energy costs. The method may also optimize energy distribution, energy use, the cost of service, or avoided cost using at least one of: the forecasted individualized demand by enduse, the forecasted individualized demand by location, the forecasted energy prices, and the forecasted energy costs. Interaction between the calculating, forecasting and optimizing may allow management and dispatch of enduses and energy supply at a micro level in near realtime.
Additional features, advantages, and embodiments of the invention are set forth or apparent from consideration of the following detailed description, drawings and claims. Moreover, it is to be understood that both the foregoing summary of the invention and the following detailed description are exemplary and intended to provide further explanation without limiting the scope of the invention as claimed.
BRIEF DESCRIPTION OF THE DRAWINGSThe accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate preferred embodiments of the invention and together with the detailed description serve to explain the principles of the invention.
FIG. 1 is a schematic of an overall system, according to one embodiment of the present invention.
FIGS. 2A2B show exemplary database relationships that may be used in an embodiment of the present invention.
FIG. 3 is a schematic overview of how data flows through the communication server in an embodiment of the present invention.
FIG. 4 shows an exemplary path for optimization.
FIG. 5 is a flow chart illustrating enduse forecasting in an embodiment.
FIG. 6A is a flow chart illustrating calculation of a customer cost of service in an embodiment.
FIG. 6B is a flow chart illustrating forecasting of bus locational marginal price (LMP) in an embodiment.
FIG. 6C is a flow chart illustrating forecasting of primary line loss in an embodiment.
FIG. 6D is a flow chart illustrating forecasting of secondary line loss in an embodiment.
FIG. 6E is a flow chart illustrating forecasting of transformer loss in an embodiment.
FIG. 6F is a flow chart illustrating forecasting of a voltage adder in an embodiment.
FIG. 7 shows a customer specific marginal cost to serve in an embodiment.
FIG. 8 is a flow chart showing a general flow for optimizations.
FIG. 9 is a graph and table showing dispatching with hour constraints in an embodiment.
FIG. 10 shows an exemplary solution of a load leveling optimization.
FIGS. 11A11B show an exemplary solution of a load leveling optimization but adding nonHAN households.
FIGS. 12A12B show exemplary solutions under realtime curtailment.
FIG. 13 shows an example monthly bill under a bill target optimization
FIGS. 14A14B show an exemplary dispatch of solar and storage by arbitraging market prices.
FIGS. 15A15B show exemplary optimal dispatching strategies with optimization and without.
FIGS. 16A16B show exemplary charging patterns of one battery versus three batteries.
FIG. 17 is a graph of an exemplary day for a PV system.
FIGS. 18A18B show an exemplary generation profile for PV according to one embodiment.
FIG. 19 shows an exemplary use of an ARMA model.
FIGS. 20A20B show an exemplary generation profile for PV according to another embodiment.
FIGS. 21A21F shows results from an exemplary scenario with low incentive costs and high cost of service for certain customers.
DETAILED DESCRIPTION OF THE EMBODIMENTSThe following systems and methods may provide reliable, least cost electricity to households and businesses.
Embodiments of the present invention may include several aspects. Embodiments may provide a process and method for jointly (1) forecasting, (2) optimizing and (3) costing the management and dispatch of ends uses and energy supply at a (4) micro level in (5) near real time. The confluence of these functions, when combined together and focused at a micro level energy application, in near real time, may provide significant cost savings and efficiencies beyond the traditional utility focus which tends to use aggregated loads, average or noncustomer specific costs, and is not able to adjust end use demands in near real time. The micro level is preferably an enduse level, in contrast to a location level.
First, traditionally, electric energy providers have not managed energy using (1) forecasted loads within a home, at (4) the micro or enduse level. Rather, decisions regarding energy management depended upon observable aggregations of loads across many homes. As such, the optimal energy management decisions were only based on aggregate forecasts, and typically dispatched a supply resource to balance demand and supply in real time. In those few cases where energy providers manipulated demands directly (e.g., demand response) or through pricing (e.g., critical peak pricing), the application of the end use management operation did not vary by customer, did not depend on the unique cost to serve a given customer, and the operational management of these end uses did not change in near real time. At most, enduse might have been cycled off for a period of time per hour, or for a sequential number of hours. But historical operations of end use control, or dispatching, have not considered or leveraged the advantages of a near real time dispatch where unique dispatching signals and solutions are individually issued to specific customer end uses, the optimal solution of which is to be determined by unique cost values ascribed to the targeted loads. Hence, embodiments of the present invention uniquely and directly manage enduses and distributed generation in near real time, based on individualized avoided cost estimates, such that an optimal set of dispatching instructions is derived and executed within a microgrid area, thereby creating greater cost savings and efficiencies than can be achieved using the more traditional aggregate level operation.
Second, embodiments of the present invention may provide the ability to more efficiently manage loads by focusing the (2) optimization at the (4) micro or enduse level in (5) near real time, which includes the end use level or premise level and the local contribution from distributed generation. Traditionally, energy providers have used optimization tools to determine which supply side resource to dispatch, given an aggregate load within a region. However, doing so at the micro level is uniquely more complicated and, if executable, may lead to greater cost savings and efficiencies than the traditionally aggregated view which emphasized the management of supply more than the optimal balancing of demand and supply simultaneously, as contemplated by embodiments of the present invention. The traditional aggregated approach may not be able to lower costs as effectively as the micro level system because of its lack of consideration of the benefits of direct, near real time control over end uses or demand, the cost of serving that end use or customer over time, or the benefit of optimally issuing uniquely determined dispatching signals in near real time to both end use demands and locally placed generation.
Third, embodiments of the present invention may provide the ability to better manage costs (3) by virtue of a certain method for estimating the unique cost to serve different loads over time. Traditional energy provider dispatching and supply management systems do not consider the long term cost to provide energy, nor the avoided costs that exist in delivery less power, or reducing loads, at specific locations. Embodiments of the present invention may provide more value to energy providers related to lowering overall utility costs, more so than has been achieved from traditional systems that emphasize supply costs over delivery costs, or that emphasize short run marginal costs over long run costs to serve power. Within this system, micro level, locational, cost analysis methods are provided which interface directly, and uniquely, with the forecasting and optimization processes, and which may provide an innovative and unique method for more appropriately valuing the costs and risks of serving loads within a region served by a bus, or collection of buses.
Fourth, embodiments of the present invention may operate within a microgrid area (4), or a group of customers or loads, served by a bus, or collection of buses. Because the system uniquely focuses on the near real time (5) dispatching and scheduling of end uses, the value of its combined forecasting and optimization is enhanced. Here, the system optimally determines which end uses to shift, schedule, interrupt, dispatch or force on, to obtain the maximum avoided cost savings to the utility. Without this micro level perspective, only aggregate level solutions are achievable.
Fifth, the system operates in near real time (5) uniquely updating the forecasts (1), the avoided costs (3), and the resulting optimal dispatching solution (2). The confluence of these functions, applied at a micro end use level (4), may be necessary to achieve the described system benefits. Traditionally, supply side dispatching systems have emphasized the dispatch of supply, given observed load. The new system uniquely alters the load, in near real time, such that the overall aggregate load serving function may be more efficient and achieved at lower cost.
As will be appreciated by one of skill in the art, aspects of the present invention may be embodied as a method, data processing system, or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment or an embodiment combining software and hardware aspects, all generally referred to herein as system. Furthermore, elements of the present invention may take the form of a computer program product on a computerusable storage medium having computerusable program code embodied in the medium. Any suitable computer readable medium may be utilized, including hard disks, CDROMs, optical storage devices, flash RAM, transmission media such as those supporting the Internet or an intranet, or magnetic storage devices.
Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as JAVA, C#, Smalltalk or C++, or in conventional procedural programming languages, such as the Visual Basic or “C” programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a standalone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through 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).
Aspects of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, systems and computer program products according to embodiments of the invention. 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, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, server, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computerreadable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computerreadable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, server or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks, and may operate alone or in conjunction with additional hardware apparatus described herein.
Historically, utilities have balanced supply and demand requirements by building plant capacity to meet the instantaneous peak demand (kW) of customers. This strategy, characterized by large capital investment in centralized plant facilities and significant distribution requirements, is a common model within many regulatory state frameworks. In some cases, power providers choose to offer pricing discounts or credits to some customers, during peak cost times, to motivate demand reductions during times where supply is unavailable or very expensive. These systems, however, are not as cost effective or efficient as they could be, due to their overemphasis on the use supply side resources, with an underemphasis on the benefits that could be achieved by optimally controlling both supply and demand side resources, simultaneously.
Embodiments of the present invention may include a combination of systems and methods that may balance supply and demand simultaneously, in real or nearreal time, such that peak cost times can be minimized or which arbitrage high versus low cost times or locations relative to each others' costs. Real or nearreal time may mean a level of approximately 5 minutes or less. Other, longer times may also be used in certain situations. In certain embodiments, speed may only be constrained by the speed of processors and/or network connections and communication conduits. Use of approximately 5 minutes or less may be beneficial because at longer times a customer may not be able to participate in the ancillary services market, which requires responding within 10 minutes to contribute to spinning or supplemental reserve. A system may need a 4 second response for frequency regulation. Further, a system may need one to five minute forecasting to accurately determine usage forecasts and duty cycles, to a point where you can adjust, schedule and optimize without customer noticing. Additionally, the system may need 5 minute or less to be able to arbitrage against 5 minute LMP pricing signal from an independent service operator (ISO). The system may also need minute by minute processing to optimize around other nonparticipants to level load on a transformer, or section of circuit.
Unlike previous approaches that focus on average prices for a region or system, or aggregate programs with similar dispatching strategies applied to all customers, the systems and methods of the present invention may enable the calculation, optimization and execution of microlevel assignments of demand reduction dispatching. Microlevel assignments of demand reduction dispatching may minimize total demand realized on an asset, whether a secondary transformer, circuit or service area system. This may minimize total utility system costs and level grid capacity. Under these systems and methods, it is not necessary to limit energy sales to achieve desired capacity savings. That being said, the systems and methods may optimize both capacity and energy reduction objectives at the same time, if desired.
Existing systems for balancing demand and supply generally focus on system average prices, but all current systems ignore the micro locational value available when optimally dispatched through a more comprehensive and exhaustive mathematic set of specifications. Furthermore, this combination of methods, procedures and systems can possibly provide a more reliable solution to the general supply and demand balance issue faced by the current centralized provision of electric power. Traditional utility supply systems do not have sufficient storage ability to mitigate high cost peak periods. This is one key reason why utilities are often vertically integrated. Demand and supply must be managed in real time. Embodiments of the present invention may create a type of virtual storage by optimally coordinating micro level end use demands with varied distributed generation resources, in light of the centralized power plant cost structure and demand requirements, such that demand and supply can be more optimally managed from both a supply and a demand perspective, versus the traditional overreliance on supply side resources.
Embodiments of the present invention are designed to optimize the microdispatch of appliances, vehicles, distributed generation, and distributed generation. The optimization may maximize value given customerestablished constraints, compliance histories, expected load, forward market prices, weather and regulatory recovery. The optimization generated by embodiments of the present invention is not the same as those typically used to dispatch supply side resources. The avoided marginal cost of dispatching these supply side resources may be one of the input decision variables into a system. The system, however, may also consider the marginal cost and benefit of additional appliance control dispatching at the same time.
Overview of Embodiments of the Present InventionFIG. 1 shows an exemplary set of relationships between the utility, the customers and other components. As illustrated in FIG. 1, embodiments of the present invention may include several components. Various inputs and/or forecasted values may be shown entering the communication server 101, the forecasting system 104 or optimizations 105. It is noted that inputs and/or forecasted values may be received, processed and/or forecast in any of the various components and may pass through any of the components.
Communication Server
A communication server 101 may include a processor and/or memory. Instructions carried out by the communication server 101 may be processed via one or more processors. The communication server 101 may be vendor neutral. Thus, the communication server 101 may communicate with any vendor using any type of protocol or data format, such as Extensible Markup Language (XML), Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), proprietary, etc.
The communication server 101 may calculate a real or nearreal time enduse specific “cost of service” (COS) 103. The communication server 101 may also statistically forecast at real or nearrealtime at a forecasting system 104. Nearreal time may include at a time of 5 minutes or less as well as hourly or other time periods. The communication server may forecast, among other factors, dispatchable enduse, whole building usage, “locational marginal price” (LMP), COS, and/or renewable generation. The forecasting system 104 is discussed in detail below under “Components of the Communication Server”.
The communication server may perform real or nearreal time optimizations 105. The real or nearreal time optimizations 105 may be broken down into several suboptimizations and these suboptimizations may be executed individually or in combination. The optimizations 105 are discussed in detail below under “Optimizations”.
The suboptimizations may include: demand response optimization 107, peak demand optimization 109, micro dispatch optimization 111, bill target optimization 113, renewable generation optimization 115, and/or microgrid optimization 117. These suboptimizations are discussed in detail below. Briefly, demand response optimization 107 may minimize or maximize an objective relative to a required reduction. Peak demand optimization 109 may minimize the total system peak demand subject to enduse kWh and total kWh demand. Micro dispatch optimization 111 may maximize revenue subject to end use kW and total kWh demand at a set level, such as five minute level. Bill target optimization 113 may maximize avoided cost subject to a customer's target bill level. Renewable generation optimization 115 may minimize renewable generation volatility subject to generation, battery capacity and demand. Microgrid optimization 117 may maximize avoided cost subject to generation, battery capacity, demand LMP, and COS.
Results of the suboptimizations 119 may be expressed as customer enduse, distributed/renewable generation, distributed storage, or dispatch signals in real or nearreal time, such as at a five minute level.
Therefore, the communication server 101 may draw together a diverse group of data and forecasted values to produce optimizations 105. The results of the optimizations 119 may be instructions for sending to customer locations and/or end uses that optimally dispatch enduses to produce a desired end results in terms of energy use or cost. Instructions may preferably be sent via the communication server 101 to a HAN vendor server 123 and/or a smart meter or alternative meter vendor server 125 to carry out the instructions. Alternatively, any party may send and/or execute the instructions, such as the utility 121, fourth party vendors 135, etc.
Existing systems do not draw together this diverse set of data and forecasted values into a single optimization system. The optimization system may first gather necessary data and then forecast values that may in turn be used in one or more suboptimization routines based upon a final goal for energy use and distribution. Data and forecasted inputs are chosen based upon desired goals to efficiently determine energy use and distribution requirements. Energy use, in preferred embodiments, may include consumption of energy by customers. Energy distribution, in preferred embodiments, may include supply of energy by an energy provider.
The communication server 101 may be in contact with several sources, including a utility 121, a HAN vendor server 123, a smart meter or alternative meter vendor server 125, a grid 127, distributed and/or renewable generation 129, distributed storage 131, databases 133, and/or fourth party vendors 135. Collectively, the third party vendors, such as the HAN vendor server 123 and the smart meter or alternative meter vendor server 125, and the fourth party vendors 135 may be referred to as information collectors.
Utility
The utility or energy provider 121 may provide information to the communication server 101 such that the communication server 101 can provide results of optimizations 119. The utility 121 may provide characteristics of a distribution system and/or commodity cost characteristics 137 to the communication server 101 to calculate the COS 103. The utility 121 may also provide required system reductions and/or objectives 139 to the realtime optimizations 105, overall energy usage data, required energy reductions, required demand reductions, cost of energy data, and/or data regarding distribution of energy.
HAN Vendor Server
The communication server 101 may provide real or nearreal time, twoway communication point with the HAN vendor server 123. The HAN vendor server 123 may represent and collect data 141 from buildings with HAN systems 143. The HAN vendor may be responsible for equipment that collects real or nearreal time information about the electricity use of each customer's enduses. The real or nearreal time information may be taken at intervals of more or less than five minutes. The customer's end uses may include HVAC, water heating, lighting, electric vehicles, plug loads, etc. The real or nearreal time information may be sent from the customer buildings with HAN systems 143 to the HAN vendor server 123. The HAN vendor server 123 may then communicate the data 141 to the communication server 101.
The data 141 may include real or nearreal time enduse usage data, customer willingness to be interrupted, managed, scheduled and bids, customer preferences, customer demographics, and/or desired bills.
The communication server 101 may also be responsible for sending out control signals to the HAN vendor server 123 based upon the results of the optimizations 119. The control signals may instruct that enduses are to be shut down to achieve the goals of the optimization. The HAN vendor server 123 may then be responsible for implementing the control signals at the customer location with HAN systems 143.
Smart Meter or Alternative Meter Vendor Server
The communication server 101 may provide real or nearreal time communication point with the smart meter or alternative meter vendor server 125, or alternatively, another metered device providing real time or near real time usage measurement, such as a whole house current transducer (CT), or similar metering device which is not a smart meter. For convenience, the term “smart meter vendor” is used herein, but this label does not imply that other, more traditional, metering devices are not feasible for use with the system. In this sense, a smart grid application does not necessarily require a smart meter. Note that a smart meter, itself, is not a necessary component of the system, though the user may choose to use a smart meter to communicate customer usage amounts to the system, and the user may choose to use smart meter data, downloaded periodically to the system, to update customer usage data estimates.
The smart meter or alternative meter vendor server 125 may represent and collect data 145 from buildings with smart meter or alternative meter systems 147. The smart meter vendor may be responsible for equipment that collects real or nearreal time information about the electricity use of each customer's building. As with the HAN vendor server, the real or nearreal time information may be taken at intervals of more or less than five minutes. The real or nearreal time information may be sent from the customer buildings with smart meter systems 147 to the smart meter vendor server 125. The smart meter vendor server 125 may then communicate the data 145 to the communication server 101. The data 145 may include real or nearreal time whole facility usage information.
Grid
The grid or energy distribution system 127 may also communicate with the communication server 101. The grid or energy distribution system 127 may communicate real or nearreal time locational marginal cost (LMP) 149. LMP is generally a marketpricing approach used to manage the efficient use of a transmission system when congestion occurs on a bulk power grid. LMP may be the cost of supplying the next MW of power considering generation marginal cost, transmission costs, and losses.
Distributed and Renewable Generation
The communication server 101 may also communicate with distributed and renewable generation systems 129. The distributed and renewable generation systems 129 may provide real or nearreal time generation data 151.
Distributed Storage
The communication server 101 may also communicate with distributed storage systems 131. The distributed storage systems 131 may provide real or nearreal time storage data 153, such as battery levels.
Databases
The communication server 101 may also be in communication with one or more databases 133. The one or more databases may provide and/or store information related to the optimizations 105. For example, a database may provide real or nearreal time or forecast weather conditions.
One or more databases 133 may store all the collected data. The data may be stored for many reasons including use as historical data. Historical data may be an important element of the forecasting system 104. The optimizations 105 may be forward looking, so forecasts of enduse demand and cost of service (prices) may be critical. To increase the accuracy of these forecasts, historical data may be used as much as possible. Therefore, this data must be readily accessible to the forecasting module 104 via the database 133.
The one or more databases 133 may store the information necessary to run the forecasting system 104 and/or the optimizations 105. The one or more databases 133 may also be used to populate various data fields in the user interfaces. Specifically, the one or more databases 133 may store customer information, compliance histories, appliance information, appliance usage history, customer preferences, customer profiles, customer overrides, billing information, weather information, customer characteristics, load forecasts, price forecasts, historical and forecast enduse load information for all monitored enduses, historical and forecast temperatures, humidity, wind speed, historical and forecast avoided costs by customers for both commodity and noncommodity cost of service factors, historical photovoltaic generation, solar storage, solar discharge, electric vehicle charging, electric vehicle discharging, car arrival times, battery fill forecasts, customer preferences for controlling enduses, bill management settings per month, customer responses to prior program offerings, and other data required to either forecast, value or optimize optimization dispatch signaling. The one or more databases 133 may also be depositories for research surveys, linked to later observed behaviors, satisfaction and behavioral or choice preferences, and used to simplify and improve customer impact measurement, verification and forecasting ability for regulatory compliance, independent system operator (ISO) system dispatching, ancillary service management or integrated resource planning.
Using precase customer input and comparing those inputs to postcase behaviors may enable a more accurate, more valuable and more predictive dispatching execution and implementation. This in turn may allow a user to more precisely target appliances and customers that best meet the users' objectives for peak load reduction, energy conservation, grid management or optimally leveraging distributed resources. Database information may also be used to improve the optimizations 105. FIG. 2A and FIG. 2B show exemplary database relationships that may be used in various embodiments of the present invention. Information stored in the databases may relate to customer locations, enduses, weather, forecasts, customer preferences, grid data, etc. Databases may be interactive and related by links and/or other references. Databases may be updated periodically, if necessary.
Fourth Party Vendors
The communication server 101 may be in communication with one or more fourth party vendors 135. The one or more fourth party vendors may collect information regarding total premise usage data from customers that include customers that are not part of either the HAN vendor or smart meter vendor customer base. If the HAN vendor or smart meter vendor cannot collect total premise data, then a fourth party vendor 135 may collect necessary information.
Components of the Communication Server
The communication server 101 may include several subcomponents. Components of the communication server 101 may include: a communication engine 155, a complex event processor 157, customer and utility portals 159, the forecasting system 104, and the cost of service (COS) forecasting system 103. The optimizations 105, which also may be run by the communication server 101, are discussed below in the section titled “Optimizations”.
FIG. 3 is a schematic overview of how data flows through the communication server 101. As shown in FIG. 1, the communication server 101 may communicate with a HAN vendor server 123. The communication server 101 may also communicate event executions with an event processing server 301. The event processing server 301 may be in communication with a utility portal 303, optimization modules 305 and one or more databases 307.
The optimization modules 305 may provide decisions and dispatch to the event processing server 301. The optimization modules 305 may process: loads and forecasts; avoided costs; capacity values; distributed storage and distributed generation status; and/or customer constraints. The optimization modules 305 may receive information from a forecasting system 104. The forecasting system 104 is discussed in more detail below, but may provide: load prediction; weather forecasts; risk given load uncertainty; customer compliance forecasts; override forecasts; and/or time of day and day of week effects. The forecasting system 104 may receive information from the one or more databases 307.
The one or more databases 307 may contain information regarding: weather; hourly loads; appliances; compliance history; price elasticity; incentive history; and/or preference history, among other data. A customer portal 309 may be in communication with the one or more databases 307 and/or the HAN vendor server 123. The customer portal 309 may provide information regarding: enduse information; appliance status; costs and bill savings; carbon saved; incentives; preferences; and/or overrides, among other data.
FIG. 4 shows an exemplary path for optimization. Real or nearreal time data may be received 401, such as usage, price and weather data. The data may be aggregated to a consistent level 403, such as the one minute level. The data may then be stored in a database 405. For each period data may be exchanged between the database 405 and a forecasting module 407. The forecasting module 407 may generate forecasts of demand and/or prices. A query may be performed to determine if there is an event in the next period 409. If yes, appropriate optimizations may be run 411 using data from the database 405 and forecasting module 407. Dispatch signals may then be sent to HAN vendors 413.
The following is more detailed information regarding various components of the communication server 101.
Communication Engine
One or more communication engines 155 may be housed within the communication server 101. A communication engine 155 may relate to a given grid circuit or substation bus. The communication engine may serve as a direct link between the communication server 101 and any HAN devices that are controlling appliances in the HAN buildings 143.
The communication engine 155 may send, receive and/or acknowledge messages to the HAN vendor server 123 through standard (TCP/IP) protocols, as specified by the HAN vendor, or through other communication conduits as available. The communication engine 155 may be in constant communication with a HAN activity server, and may continually receive data from the appliances in the HAN buildings 143 regarding their current status. The communication engine 155 may receive data from the HAN vendor server 123, and may perform initial processing of the data. Initial processing may include aggregation of subsecond data into minute level data, streaming of data to the complex event processor 157, and conducting frequency drop checks, or other rulebased requirements as specified by the user that are consistent with the capability of the HAN device. The communication engine 155 may also translate dispatch signals from the optimizations 105. The communication engine 155 may translate instructions into a communication format as required by the target HAN devices. The communication engine may communicate with any inhouse HAN provider that uses TCP/IP communications, or other nonproprietary communication conduits, or establishes their own communication link to the optimal dispatching signaling capability.
Complex Event Processor
A complex event processor 157 may be a lowlatency filtering, correlating, aggregating, and computing system that processes real or nearreal time data efficiently. Preferably, the complex event processor 157 may have a latency of about one minute or less. The complex event processor 157 may combine data from many sources quickly and send them to the various other components of the system. The system preferably does not use the complex event processor 157 for extensive real or nearreal time analysis of the data. Instead, perhaps preferably, the realtime analysis may be performed in the forecasting system 104 and/or the optimizations 105.
The real or nearreal time data being processed through the complex event processor 157 may include: HAN data from the communication server 101; weather data including forecasts; whole building consumption data for HAN and nonHAN household from smart meters or communicated from other wireless communication devices; nodal locational marginal prices (LMP) from independent system operators or the utility; and inputs by customers and the utility via the customer and web portals, respectively.
The complex event processor 157 may handle real or nearreal time “traffic control” components. The complex event processor 157 may be used to feed real or nearreal time data to the utility and customer portals 159, take data from the complex event processor 157 and store it in the one or more databases 133, call up the forecasting system 104, supply the forecasting system 104 with the required input data, store the forecasting results into the one or more databases 133, call up the optimizations 105 when decisions are required by the utility 121, supply necessary data, confirm and calculate dispatching results, and feeding dispatching results back to the utility 121.
The complex event processor 157 may be scalable up to five million events per second, per server, or more. This may be sufficient to optimally dispatch a region or collection of circuits on several buses, assuming an average of three dispatchable enduses per customer. Additional system capacity simply requires more servers, or faster complex event processors. Ideally, systems should be architected to minimally include coverage of the analytics for all customers on a given bus, although broader coverage is possible, given complex event processor and processing performance. In this manner, a bus level focus enables the use of a common bus level LMP cost to be used for dispatching customers located on that bus, either from direct signaling from the utility or from an ISO based pricing signal, or other transmission level price signaling. These LMP costs may be generally based on simpler, often quickly derived, linear programming solutions, and for which existing software solutions exist. Note that the CEP/Forecasting/Optimization system may leverage additionally complex and unique customerspecific or locationspecific marginal cost differences within its dispatching decisions, beyond the bus level LMP. Where users desire to optimize their dispatching strategies more broadly across multiple buses, and multiple LMPs per bus, in addition to the microgrid level dispatching, a more broadly defined architecture, with additional servers, is necessary.
Ideally, systems should be established individually for circuits radially linked to a bus, with one server dedicated to the peak load management for that bus or collection of circuits. In this manner, nodal level LMP prices can be directly integrated with the system, to ISO based pricing signals, or other transmission level price signaling.
Generally, dispatching at a minute by minute level is sufficient to optimize peak loads on a circuit and obtain desired value optimizations. This may assume market share penetrations of HANs along the circuit of approximately 30% to approximately 50% and minute by minute signaling of the total household or business loads for nonHAN customers is signaled back to the system through the complex event processor 157. Beyond 50% market share penetrations, the value obtained from system operation begins to experience diminishing returns, as the optimally dispatched signals already account for the observed loads of nonparticipants, and has optimized the loads of participating end uses in concert with these nonparticipating loads. So, for energy management objectives which pertain only to peak load reduction with constantly maintained energy levels, sufficient load leveling is achieved using approximately half of the customers on a circuit. For energy management objectives which additionally desire energy reductions in addition to peak load reductions, additional market share penetrations are desirable.
For subminute load sheds, the complex event processor 157 can respond to a frequencymotivated load shed or other shed as prespecified into the system, where the response may be triggered by preestablished criteria. To enable some management of frequency management at the sub minute level, however, this type of load management is not a choreographed or optimized dispatch. Rather, it is a one way, single load shed dispatch targeted at desired locations, without regard for end use coordination, or optimal least cost supply or distribution cost minimization objectives. This is simply an auxiliary use of the system, which can be leveraged during times of system reliability emergency.
Here, the complex event processor 157 may issue commands to all appropriate appliances using a single, quick signal sent to connected appliances on a circuit. Typically, this type of emergency load shed is an infrequent event (1 in 5 year or 1 in 10 year event). This type of emergency load shed, however, may have significant value to system operators as a backstop for emergency response. This operational capability of the system may not require optimization or forecasting components. Rather, the set of execution heuristics desired may be established by the user for execution only when those preset conditions are met.
The complex event processor 157 may also contain a review procedure and interactive environment that may allow the integration of several databases into a single portal, and a query environment for the user to observe the resulting effects of the dispatch signaling solutions. The complex event processor 157 may also enable the user to send frequent information to customers regarding their appliance usage or the results of the dispatching signals. The complex event processor 157 may enable automated notification to customers and reporting of loads, appliance usage, appliance health diagnostics, bill forecasts, bill management, and real or nearreal time performance measurements, where desired.
Utility and Customer Web Portals
The utility and customer web portals 159 may be web clients that allow the utility and customer, respectively, to interact with the communication engine 101 and vice versa. The communication engine 101 may use the utility and customer web portals 159 to provide real or nearreal time information about usage, prices, and other important factors. HAN customers may use the portal to provide the communication engine 101 with information about premise energy usage, which enduses can be dispatched, when they can be dispatched, and the value the customer places (monetarily or subjectively) on the output of the enduses.
The utility portal 303 may be used by the utility 121 to provide details about: system real or nearreal time energy usage; when an “event”, such as curtailment, load leveling, or other type, is planned; target reduction amount; length of the event; and other necessary information for the optimizations, such as targeted geographic areas or customers. The system may work with any communicationenabled web portal as long as the information needed for the optimizations is collected and customer settings can be updated from the portal to the system over time.
The utility portal 303 may perform real or nearreal time monitoring of customers and enduses, as well as other distributed resources, such as storage and generation, for a specified location, region, time period or collection of customers. The utility portal 303 may also provide realtime monitoring at the transformer level, feeder level, substation level, or system level, in user defined formats, where more local control is desired. The utility 121 may also set the utility portal 303 to dispatch customers directly, either optimally, geographically, or across prespecified grid segments or circuits, or via preset heuristics for emergency load shed or other special criteria. The utility portal 303 may provide reporting. Reporting may include real or nearreal time and cumulative reports on the results of the control events, impacts relative to forecasts, including financial, system, reliability and load reduction impacts. The functionality of the utility portal 303 may allow a customizable interface so the enduser may get the information they need for execution and operation. The enduser may also interact with the communication server 101 such that the dispatching solutions meet user needs.
Different utilities and users may find more or less value in specific aspects, capabilities or controls of the system. As such, user defined utility portal 303 functionality may evolve over time as users begin to learn which optimally dispatched strategies are more desirable for their needs.
The system may be capable of interfacing with any TCP/IP enabled customer portal 309, wireless enable portal or other communicating hardware, assuming five minute, or less, communication signaling is feasible. Such customer portals 309 may have any level of functionality. For example, a customer portal 309 may need to be able to provide real or nearreal time information to the customer to help them manage their electricity use and energy costs, or simply observe usage or control status. Additionally, the portal may allow the customer to communicate their preferences, profiles or constraints to the utility and the system, to control enduses, comfort, carbon emissions saved, time home, bill settings, bill forecasts, energy usage preferences, or related factors that serve to constrain dispatching.
The customer portal 309 may also provide a mechanism for the customer to override the controls during an event or to adjust comfort settings. The customer portal 309 can allow the utility 121 to provide the customer with customer specific program offerings, messages, prices, or incentives, customer offers, appliance monitoring and diagnostics, bill or tariff information, and test offer programs.
The utility portal and/or customer portal can be replaced by existing HAN vendor portals, where necessary, provided communication conduits are established for the optimal dispatch signaling.
Forecasting System
The forecasting system 104 may forecast enduse and total premise loads, energy costs, energy prices, avoided costs and renewable resource generation. Forecasting, in a preferred embodiment, may include taking data inputs, processing those outputs to determine an expected value at a future time, and supplying those outputs to the optimizations 105. Forecasts may be performed at the minute and/or the hourly level for the next hour, the next day and/or the remainder of the month. The following may be forecast: energy costs, energy prices, avoided load; avoided costs; capacity values; lost revenue; customer bills; regulatory earnings; and/or utility margin. Energy costs, in a preferred embodiment, may include the cost of an energy provider to supply energy. Energy prices, in a preferred embodiment, may include cost at which an energy provider supplies energy to a customer. The amount of resource extractable today versus waiting until the end of a specified peak pricing period may also be forecast.
The forecasting system 104 may use regressionbased modeling procedures that include weather conditions, time of day, and day of week variables to forecast the enduse for each customer until the end of the current month or season. The usage forecasts may be called automatically by the complex event processor 157. The results of the forecasting system 104 may be stored in the one or more databases 133. As new information continually arrives, the forecasts may be continually updated. During a dispatch or control event, the forecast values are stored in a separate table, representing the most accurate and current baseline for use in calculating measurement, verification and evaluation results for the peak load reduced and the net energy saved. These results are also useful for future expost evaluations or new program redesign, pricing incentives and related respecifications of system inputs.
FIG. 5 is a flow chart illustrating enduse forecasting. A HAN may provide real or nearreal time enduse data 501. The system may also receive real or nearreal time weather data 503 and/or prices/LMP 505. This information may be input into the forecasting system 104 and processed to produce a forecast enduse demand 507.
The following is an exemplary process for forecasting electricity demand in the forecasting system 104. The forecasting system 104 may forecast electricity demand for all major enduses that can be dispatched and are predictable, as well as total premise usage. Examples may include, but are not limited to, HVAC, electric vehicles, plug loads, and water heating. This may also be a model useful for a battery discharging context within a plugin hybrid electric vehicle context (PHEV) as well, although the weather variables may not be included in that case, and vehicle battery discharging carries additional complexities related to the vehicle's performance and customer satisfaction, or lack thereof, that do not similarly constrain electric vehicle charging management, which simply delays a vehicle's charge over an optimally determined schedule, given utility costs and preset customer parameters. However, operationally, the system executes either charging or discharging, or both, equally effectively. To begin the model, consider:
 Y<sub>ijt</sub>=Electricity usage during period t for customer i of appliance j.
 X<sub>ijt</sub>=Set of explanatory variables during period t for customer i of appliance j.
 X consists of variables such as temperature, humidity, time of day, day of week, and month.
 t is at least hourly, although in some cases it may need to be every 1 to 5 minutes.
So, at every time t the forecasting system 104 may estimate the parameters (the βs) of the following equation for all customers and appliances using regression techniques:<FORM>Y<sub>ijt</sub>=β<sub>ij</sub>X<sub>ijt</sub>+ε<sub>ijt</sub> (1)</FORM>
 Y<sub>ijt </sub>may consist of all the available electricity usage data for that customer for that appliance that has been collected from the HAN.
Therefore, the longer the HAN has been installed and monitoring information, the better the fit of the model.
The weather forecasts may be obtained in real or nearreal time from, for example, the National Oceanic and Atmospheric Administration's (NOAA) Meteorological Assimilation Data Ingest System (MADIS) using standard data import formats or methods, such as database transfers, File Transfer Protocol (FTP), batch flatfile process, text, XML or web services. Using the fitted parameters and forecasts of the X variables, the system may develop forecasts of T+1, T+2 . . . T+n values of Y and store them in a database according to the following equation:<FORM>Ŷ<sub>ijt+k</sub>={circumflex over (β)}<sub>ij</sub>X<sub>ijt+k </sub>k=1 . . . n (2)</FORM>
In some cases, the entire load of a house may be needed. Rather than model each individual load, all of which is may be not measured in realtime, all loads may be lumped together into a “nondispatchable” load equation, which may be monitored. Specifically:
 ND<sub>it</sub>=Electricity usage during period t for customer i of the nondispatch load of the house.
This nondispatchable load may be the total load of the house TL<sub>it</sub>, which is measured in realtime, less the total dispatchable load discussed above, or:<FORM>ND<sub>it</sub>=TL<sub>it</sub>−Σ<sub>j</sub>Y<sub>tij</sub> (3)</FORM>
The nondispatchable load can now be forecast using the same approach as the dispatchable load using the same explanatory variables:<FORM>ND<sub>it</sub>=β<sub>i</sub>X<sub>it</sub>+ε<sub>ijt</sub> (4)</FORM>
As before, the ND<sub>it </sub>may consist of all available electricity usage data for that customer that has been collected from the HAN. Therefore, the longer the HAN has been installed and monitoring information, the better the fit of the model. Forecasting this load is the same:<FORM><img id="CUSTOMCHARACTER00001" he="4.23mm" wi="5.67mm" file="US0801969720110913P00001.TIF" alt="custom character" imgcontent="character" imgformat="tif"/><sub>it+k</sub>={circumflex over (β)}<sub>i</sub>X<sub>it+k </sub>k=1 . . . n (5)</FORM>Cost of Service System
The communication server 101 may also include a system for forecasting cost of service (COS) or avoidable cost 103. Cost of service, in a preferred embodiment, may be the cost associated with supplying energy to a customer. Avoidable cost, in a preferred embodiment, may be the cost saved by using one particular distribution strategy over another distribution strategy. FIG. 6A is a flow chart illustrating calculation of a customer cost of service. The system for forecasting cost of service or avoidable cost 103 may receive as inputs: forecast bus/nodal LMP 601, forecast line loss 603, including primary and secondary line losses and transformer losses; forecast voltage adder 605; distributed capital cost 607; ancillary service value 608; shaping premiums 609; swing premiums 611; and/or miscellaneous adders 612. The inputs may be processed by the system for forecasting cost of service 103 to produce a forecast cost of service for a customer i at time t 613. Forecast inputs are determined as described below.
FIG. 6B is a flow chart illustrating forecasting of bus locational marginal price (LMP). The system may receive inputs from the utility 121 or an independent system operator (ISO) regarding real or nearreal time bus/nodal LMP 615. The system may also receive inputs of real or nearreal time weather data 617. The system may process the inputs and forecast a bus/nodal LMP 619 to be used in the determination of cost of service.
FIG. 6C is a flow chart illustrating forecasting of primary line loss. The system may receive inputs from the utility regarding real or nearreal time estimates of how primary line losses varies by customer, based on: real or nearreal time whole facility usage data 621; changing real or nearreal time weather data 623; voltage 625; and/or prices/LMP 601. The real or nearreal time electricity prices 601 or LMP may be received, against which the forecasted percentage of primary line losses, per customer, may vary. These inputs may be established per customer location, outside of the system, in conjunction with distribution planners within the utility who are familiar with the bus and circuit characteristics, power factor, voltage conditions, load balancing, circuit capacity, capacitor characteristics, circuit topography, and other circuitspecific characteristics which influence primary line losses. This circuit analysis may be conducted by the utility, such that a reasonable relationship or forecast is constructed which predicts the primary line loss at customer location as a function of a) customer load, b) voltage conditions, and c) weather. These forecasted inputs and relationships may be used to forecast primary losses at a given location, or for a given circuit section or customer location. The system may process the inputs and forecast primary line loss for the customer at time t 637 to be used in the determination of cost of service.
FIG. 6D is a flow chart illustrating forecasting of secondary line loss. The system may receive inputs from smart meters regarding real or nearreal time whole facility usage data 639, and unlike primary losses, the secondary losses may be wholly forecasted within the system, using system inputs and forecasts. The system may also receive inputs of real or nearreal time weather data 641, and inputs of real or nearreal time prices/LMP 601. The inputs may be used to forecast total load on a transformer and customer load 645. Other inputs for the determination of secondary line loss may be: line length 647; load factor on the transformer 649; power factor on transformer 651; and/or voltage on the transformer 653. The system may process the inputs and forecast secondary line loss 655 for the customer i at time t to be used in the determination of cost of service, more specifically, as follows. Where individual customer voltages, line lengths or transformer characteristics are not known, average customer inputs may be used. Secondary line losses (LineLoss<sub>it</sub>) may be directly estimated within the system based on user provided line lengths and loss characteristics. The secondary line losses may be added to the primary line loss described above.
SLoss<sub>it </sub>may follow Ohm's law (I<sup>2</sup>R), and, thus, may be a function of line resistance and the square of the power going through the lines:
<maths id="MATHUS00008" num="00008"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><msub><mi>SLoss</mi><mi>it</mi></msub><mo>=</mo><mrow><mrow><msup><mrow><mo>(</mo><mfrac><mrow><mi>k</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>W</mi><mi>it</mi></msub><mo>/</mo><mrow><munder><mo>∑</mo><mi>T</mi></munder><mo></mo><mrow><mi>k</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>W</mi><mi>t</mi></msub></mrow></mrow></mrow></mrow><msub><mi>PF</mi><mi>T</mi></msub></mfrac><mo>)</mo></mrow><mn>2</mn></msup><mo>·</mo><mi>k</mi></mrow><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mi>V</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>A</mi><mi>T</mi></msub><mo>·</mo><msub><mi>CL</mi><mi>TF</mi></msub><mo>·</mo><msub><mi>LF</mi><mi>T</mi></msub><mo>·</mo><mn>1</mn></mrow></mrow></mrow><mo>,</mo><mn>000</mn></mrow></mtd><mtd><mrow><mo>(</mo><mn>6</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>Where:
 kW<sub>t</sub>=Customer i's demand at time t.
<maths id="MATHUS00009" num="00009"><math overflow="scroll"><mrow><mrow><munder><mo>∑</mo><mi>F</mi></munder><mo></mo><mrow><mi>k</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>W</mi><mi>t</mi></msub></mrow></mrow><mo>,</mo><mrow><mrow><munder><mo>∑</mo><mi>T</mi></munder><mo></mo><mrow><mi>k</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>W</mi><mi>t</mi></msub></mrow></mrow><mo>=</mo><mrow><mi>the</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>total</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>demand</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>at</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>time</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>t</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>on</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>the</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>feeder</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>line</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>and</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>the</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>transformer</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>line</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>customer</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>,</mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mrow><mi>respectively</mi><mo>.</mo></mrow></mrow></math></maths>
 kVA<sub>F</sub>, kVA<sub>T</sub>=the voltage of the feeder line and the transformer line, respectively, to the customer.
 PF<sub>F</sub>, kPF<sub>T</sub>=the operating power factor of the feeder line and transformer line, respectively.
 CL<sub>F</sub>, CL<sub>T</sub>=The cable length of the feeder line and transformer line to the customer, respectively.
 LF<sub>F</sub>, LF<sub>T</sub>=The load factor of the feeder line and the transformer line, respectively.
The winding's loss in the transformer (or load loss) may also follow I<sup>2</sup>R, and thus can be expressed as:
<maths id="MATHUS00010" num="00010"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><msub><mi>WndLoss</mi><mi>it</mi></msub><mo>=</mo><mrow><mrow><msup><mrow><mo>(</mo><mfrac><mrow><mi>k</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>W</mi><mi>it</mi></msub><mo>/</mo><mrow><munder><mo>∑</mo><mi>T</mi></munder><mo></mo><mrow><mi>k</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>W</mi><mi>t</mi></msub></mrow></mrow></mrow></mrow><msub><mi>PF</mi><mi>T</mi></msub></mfrac><mo>)</mo></mrow><mn>2</mn></msup><mo>·</mo><mi>k</mi></mrow><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mi>V</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>A</mi><mi>T</mi></msub><mo>·</mo><msub><mi>WndImp</mi><mi>T</mi></msub><mo>·</mo><mn>1</mn></mrow></mrow></mrow><mo>,</mo><mn>000</mn></mrow></mtd><mtd><mrow><mo>(</mo><mn>7</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
Where the WndImp<sub>T </sub>is winding impedance of the transformer associated with the customer. The induction loss (IndLoss<sub>i</sub>) may be referred to as the “no load loss” of the transformer because it is independent upon the load passing through the transformer. Therefore, it is essentially a constant term specific to the transformer associated with each customer.
The above discussion shows that line loss for a give customer may be a function of demand for that customer, kW<sub>it </sub>as well as the demand for all the customers on that customer's transformer
<maths id="MATHUS00011" num="00011"><math overflow="scroll"><mrow><munder><mo>∑</mo><mi>T</mi></munder><mo></mo><mrow><mi>k</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>W</mi><mi>t</mi></msub></mrow></mrow></math></maths>as well as all the customers on that customer's feeder line.
Therefore, the system may conduct forecasts for all these demands in addition to the enduse demand forecasts discussed previously. There are two differences between these forecasts and the ones presented earlier. First, the demand on each transformer and feeder line may be at the premise or transformer level, not the enduse level. Second, this data may be collected from the utilities smart meters system, and not the Home Area Network data.
Finally, the forecasted customer loads 645 may be compared to the service transformer KVA rating 646, to estimate the number of times, and for what duration, total transformer load may exceed recommended transformer capacity. Using American National Standards Institute (ANSI) suggested peak load rating tables, or comparable transformer loss of life protocols operationalized within the utility, the system may multiply the percentage loss of life 648 times the utility input transformer cost of replacement 650, to arrive at a cost adder for the system which promotes the reduction of peak loads on transformers that are at risk of overloading.
FIG. 6E is a flow chart illustrating use of deferred or avoided distribution costs (CC<sub>it</sub>) 673. CC<sub>it </sub>661 may represent the annual marginal cost per KW of new distribution capital expenditures by the utility. These costs may include deferred distribution capital due to line upgrades, substation additions, capacitor additions, or related capital costs. In the same way that distribution planners may establish primary loss estimates per customer location, and established as a function of load, weather and circuit characteristics, distribution planners may also specify avoided, or deferred, distribution capital costs, established as a $/kW value for location j, which may contain one more customer i, for time t. Generally, the value does not vary over time, and is established for peak conditions, or a single time t. Further, this value requires comprehensive knowledge and familiarity with the local distribution system, and as such, cannot be estimated in real time within the system. Rather, the utility may specify the values to be assigned per location, to be applied to all customers located within that region j. The values may increase as distribution capacity decreases, relative to increasing customer loads. As locational distribution costs are avoidable through customer load reduction, or load leveling effects from optimized dispatching, the distribution cost adder applied to specific customers within targeted locations may realize more dispatching signaling as their avoidable or deferrable distribution capital cost adder increases. Real or nearreal time whole facility usage data 657 may be used for calculations. The whole facility usage data 657 and/or the distribution capital cost 661 may be used to forecast total load at a location 663, which may in turn be used to calculate avoided distribution cost 673.
FIG. 6F is a flow chart illustrating forecasting of a voltage adder or benefit. The system may receive inputs from a smart grid regarding hourly voltage 675. The system may also receive inputs of real or nearreal time weather data 677. The system may process the inputs and forecast a voltage 679 to be used in the determination of cost adder or benefit, which reflects the value forecasted to be gained from improving voltage conditions for a given customer location. Alternatively, the system may be operated such that a threshold voltage target is not exceeded, through the optimal dispatching of end use loads, or voltage objectives may call for improved voltage objectives at or near specific transformers, in which case the system may assign load leveling dispatching to those areas, to better manage voltages. A query determines whether the forecast voltage is below a preset limit 681. To ensure that load is levelized on a transformer, or to ensure that load is reduced for a given set of premises, in an effort to improve voltage within a targeted circuit section, an appropriately large cost, or adder, is used to motivate the application of load reduction in those areas. If no cost adder is included, then the voltage adder is set to zero 683. If yes, the voltage adder is set 685.
In this manner, the system can be used to complement existing or planned parallel distribution energy management efforts targeted specifically for distribution management purposes, such as integrated volt/var distribution management systems, or voltage reduction activities. The system may run in parallel with distribution management systems that control only grid assets, and not loads directly. In this sense, the system may enable a highly targeted and focused load reduction only in those areas or circuit sections where other distribution management systems are less able to control voltage to desired levels. In some cases, a very small circuit section's voltage drop may be too low to achieve overall voltage control objectives for the whole circuit. The system may be able to target a single, or a set of few, areas where targeted load reductions or load leveling on targeted service transformers improve voltage support beyond what the distribution management system alone can provide. This may complement the ability of the distribution management strategies for the whole circuit, without requiring the direct integration of otherwise separate systems. Importantly, the system is designed to avoid direct integration with other operational systems. Rather, the system may interface with other operational systems, which often contain their own optimization routines specific to specialized needs within their operations that either preexisted smart grid application, or if they were to be directly integrated, the combined system may not be able to derive real time or near real time optimized dispatching. Optimization solutions become notoriously slow as the number of inputs, constraints and objectives increase. Therefore, the system may provide significant advantages in light of its interfacing strategy being emphasized over direct integration with other optimization solutions which may exist for either distribution management or supply side management.
Miscellaneous Cost Adders. Several nonforecastable, constant cost adders may be input by the user, to reflect nonload risks, as desired. These cost adders generally reflect risks in serving load, and as such, may be additive to the overall cost to serve, but they may not necessarily vary with load, be forecastable from weather or other conditions, and may require unique analysis outside of the system, by the user or the utility, to establish appropriate inputs that may be added to the cost to serve, and on which load dispatch decisions may be based. If the user determines that a particular cost adder should not contribute to dispatching decisions, the user may not desire to include that miscellaneous cost adder in the system. Miscellaneous cost adders may include estimated costs for credit and collections, bad debt risk, execution risk, load following or supply/demand balancing costs, supply fee costs, purchase power agreement costs, legal costs, administrative costs, customer service costs, marketing costs, billing costs, hedging or risk management fees, ISO costs or fees, load diversity (negative cost), or metering costs, among others.
The system may optimally dispatch end uses in 1 to 5 minute increments, or less, which may provide support to spinning and supplemental reserves, within 10 minute time windows, such that ancillary service benefits may be achieved. Here, the forecast of the hourly LMP may be used to arbitrage the 5 minute LMP, such that end use loads can be dispatched through a series of commands which force end use loads to run or charge, or be delayed. This subroutine within the system may take advantage of the often variable nature of the 5 minute LMP, relative to the hourly forecasted value, given weather and system conditions. Conceptually, loads may be dispatched to run, or charge, when the forecasted 5 minute LMP is below the forecasted hourly LMP. Loads may be dispatched to delay running, or charging, when the forecasted 5 minute LMP is above the hourly forecasted LMP. Although the system may forecast the 5 minute LMP, the intrahour volatility in the LMP, at the five minute level may not be accurately forecastable. As such, the user may desire to employ this, or similar, simple dispatching heuristic. The user may adjust the sensitivity around which the system takes advantage of ancillary service value by weighting the cost adders higher or lower relative to the other cost of service adders. Where ancillary service benefit value is forecasted to be significant, as during extreme weather conditions, load leveling objectives may be of secondary importance, and the user may observe more volatility in the resulting peak load patterns. In this sense, dispatching objectives that strive to extract more ancillary service value may be likely to decrease the user's ability to achieve other objectives, such as load leveling, voltage support or other load management goals which benefit more from levelized loads.
The nonforecast inputs into the system for forecasting cost of service 103 may be directly accessed without forecasting. These may include miscellaneous adders 612, shaping premiums 609, or swing premiums 611.
Customerspecific cost to serve may be an important variable in the optimizations 105. One of embodiments of the present invention may be quantification of customerspecific marginal costs. Historically, utility system operators, independent system operators, and other entities involved in short term energy markets took actions and made decisions based on realtime hourly energy prices or next day price forecasts, which reflect an average of all buys and sells in a region or hub, or the average costs of supply side resources. The resulting index price, or ISO price, or internal utility specific supply cost, which reflects an average of these buys and sells or the average cost of supply, given demand, generally reflected the aggregate supply versus demand within a region, and did not reflect the longer run cost to serve for the next month, next year, or longer. Further, the index values, or short term prices, did not reflect the variance in marginal costs to serve specific customers, over extended periods, within that region. Where a customer uses significantly more energy during extreme weather, or during peak price hours, or pays a fixed $ per kWh rate without volume restriction, the cost to serve that customer over the planning horizon of a utility serving that load, is subsidized by other customers in the utility service area which exhibit lower than average costs to serve, or use less energy during peak priced time periods.
So, there may be an inherent subsidy that occurs within traditional supply side operations and dispatching, which may be remedied by the application of smart grid systems. Because current day or next day operations are only informed by the average load during the current day or next day, and do not consider longer term costs related to capacity, volume risk or energy use patterns of customers, ISO based or next day based dispatching systems may subsidize peakier, more costlier loads by overcharging less peaky loads. This subsidy generally does not occur within more competitive markets, where a single customer's hourly loads are evaluated, and forward risk captured as a swing, shaping and/or capacity premium, in the derivation of an annual or monthly price signal which incorporates the cost of risk or uncertainty in when, or how much, load is realized. However, within regulated utility dispatching contexts, or energy management contexts where average prices, rates or tariffs are employed, this micro level view may be lost among the service—are wide focus of traditional supply dispatching systems. Since smart grid technologies increasingly provide a system to secure substitutes to the receipt of power from the grid, customers may increasingly create more risk, and cost, to these utilities that experience increased customer migration, or arbitraging activity through renewables, distributed generation, competing aggregations, nonregulated providers or end use load management, among others.
The average market price for an hour potentially leads to suboptimal decisions on the part of less costlier customers, or may contribute to suboptimal utility decisions made regarding customer pricing or dispatching of load reduction resources. A micro focus of the system may provide an important hedge to the user, to more appropriately determine optimal dispatching solutions which minimize total costs and are more consistent with integrated resource planning principles over the long run.
FIG. 7 shows a customer specific marginal cost to serve. As shown in FIG. 7, the average hourly price for a year is $42/MWH, or $0.042 per kWh. In the example, the range of the cost to serve values for a sampled set of commercial customers spans $0.03 per kWh for street lighting load, which operates during nighttime when electricity is less expensive, to more than $0.10 per kWh for a water park, which operates during peak summer afternoon hours when electricity is most expensive.
An optimally dispatched system may reflect the more appropriate longer term cost to serve, beyond current day or next day costs, such that the long run least cost planning can be achieved, in addition to short term, daily or next day, operational requirements. There is more value to all utility customers to have more costly loads under the direct control of optimally dispatched systems, or to base the dispatching solutions on this higher cost to serve, rather than to dispatch loads assuming that there are no differences in each customer's cost to serve. Utilities and regulators are not required to price customers differently, although the system can be used toward that end, if desired.
Rather, a contribution of the system of embodiments of the present invention with respect to micro level cost focus is to estimate and forecast micro level cost of service values such that the dispatching of these loads across a service area achieves long term least cost planning objectives. Where utilities use only the short term, daily, or next day costs, without regard for long run volume risk, hourly usage patterns, capacity risk, or distribution specific avoided costs (e.g., losses, voltage, distribution capacity), potential price discrimination inequities emerge as lower cost customers subsidize higher cost customers, and utilities may begin to overpay pricing incentives to lower cost customers and still not be able to attract enough higher cost customers to optimally achieve least cost planning and operations objectives.
Targeting load reduction opportunities, or pricing incentives, or marketing and promotional resources, to higher cost to serve customers, such as a water park customer, in the case of a summer peaking utility, provides more effective load reduction hedges against future extreme weather conditions and increases long term and short term operational hedging opportunity and least cost supply planning, than targeting lower cost to serve customers, or an average, the information of which is not reflected in an average LMP price signal, but unfortunately becomes the consequence of ignoring costs to serve a customer at the micro level, or individually. In this sense, the system combines the strengths of appropriately pricing individual customer loads, including volume risk, capacity premiums and distribution related costs, as is often done within nonregulated contexts (e.g., purchased power agreements or structured bilateral deals for electricity), with the regulated requirements of integrated resource planning (IRP) principles, which do include long term capacity related needs. Hence, the system uses, individual costs to serve which more appropriately reflect true marginal costs of service than the average marginal cost reflective of the real time energy market, ancillary service market, ISO market or related energy pricing signal that reflects an aggregation of individual loads or pricing indices.
Users, however, are not required to use a full cost to serve, nor a fully individualized cost to serve. Where less variability between customers relative to their individual cost estimates, or pricing signals, is desired, users may decrease these differences, or the variability between individual customer costs, through the use of Relative Marginal Cost (RMC) Index specifications. Here, the cost to serve differences between customers can be converted into numeric values (e.g., standardized, relative to the overall average), which simply compares one customer to another, with the average cost specified as 1.0, and a customer with 50% higher cost than average becoming a 1.5 RMC score. By normalizing, or standardizing to the overall average cost, the customer costs can be weighted to drive the differences between customers to be closer and closer to 1.0 for all. Where the variance weights are zero, all customers receive the cost score of 1.0, which becomes the special case equivalent to traditional daily or next day supply side operations, or LMP equivalent. The closer that the variance weight approaches the individual customer's long run cost to serve, the closer the dispatching solutions get to optimality for a given supply demand context. The system can operate on either relative, or actual, marginal costs, per customer. In this case, the system does not optimize directly on dollar values, but rather on individualized RMC factors, times an importance weighting assigned to that particular cost to serve category, centered on the short term real time energy price, or standard ISO based price. Importantly, the use of RMCs may be useful within contexts where users do not desire to issue, or enforce, differential customer costs or prices. Rather, the benefits of optimal dispatching, driven by more accurate cost of service estimates per customer, can be realized without direct application of individualized pricing signals.
In FIG. 7, the cost to serve category shown pertains to supply side hourly energy costs. The average in this case is approximately $0.06 per kWh, and exemplified most typically by a large university customer load. This customer would receive an RMC weight of approximately 1.0, whereas a street lighting load would receive an RMC of approximately 0.67 (derived by approximating 0.04/0.06=0.67), signifying that the cost to serve a street lighting load is approximately twothirds that of serving an average type load, over the course of an average, weather normal year, and most closely represented in FIG. 7 by the load of a large university. The difference in cost between the 4.2 cents per kWh annual average short term ISO based cost and the long run annual average cost (approximately $0.06 per kWh) depicts the difference between the energyonly, short term price (daily, ISO based) and the long run cost to serve which includes capacity premiums (e.g., shaping premium and swing premium), which concerns long term IRP planners more so than short term operational dispatchers. This difference is larger the more that a customer's annual hourly load pattern diverges from the average. So, in the case of very peaky loads (e.g., a water park), the approximate average difference of 143% (0.06/0.042) can grow to be as large as 200% or more (0.10+/0.042) than the average cost to serve a given customer. Hence, attention to micro level costs within smart grid application contexts, or any context where customers have substitute options to purchasing power based on an averaged gridbased LMP price, may provide an important innovation where integrated into short term operational dispatching systems, given smart grid technologies.
Finally, the user can leverage the system for estimation of swing and shaping premiums for customers to spread this added cost to serve over targeted operational hours. Some users may choose to spread the premium over all peak hours (approximately 47.5% of all annual hours), or some users may wish to spread the premiums out over fewer hours to increase the pricing incentive's effect on the dispatching decisions. These are choices which must be made by the user in addition to the choice of what weight to apply for the Relative Marginal Cost Index, but which must be considered in tandem with that choice as the combined effect of the two is what will determine the nature and amount of the intercustomer cost of service differences, and hence influences, on the dispatching solutions
The system may allow for the use of RMCs for all its cost categories, both gridspecific (e.g., voltage reduction value, primary line losses, secondary line losses, power factor improvement, or deferred T&D capital costs assigned per acre or per region, the cost amount of which is the same for all customers in that acre or region) or supply side specific (e.g., energy reduced, capacity reduced, plant type avoided, reliability, emissions volume risk, hourly usage risk). Where actual costs are desired, the system uses these actual costs instead of the RMCs and their assigned importance weight.
Where the user wishes to use only RMCs and importance weights, a single average cost value is specified for the 1.0 value, typically the average market price or ISO price within the region, to ground the system's optimization solutions for dispatching. Here, the RMCs and their weights may be multiplied times the average market, and the closer the weights are to zero, the less variability will be reflected between customers in the dispatching decisions. Mixed use of RMCs and actual cost estimates is also possible. The system's primary focus is on insuring optimal dispatching of resources, given the supply and demand mix available, and helping users get as close to an optimal dispatching solution as is allowed within their current capabilities, even if the user has not yet applied micro level cost to serve valuation directly.
To use individualized cost to serve, the system for determining cost to serve 103 may take a locational marginal price (LMP) from an independent system operator (ISO) at a node. The node may be a predefined system injection point nearest the customer.
The bus level LMP may be the cost of supplying the next MW of power considering generation marginal cost, transmission costs, and losses. This bus level LMP is one component of the micro level cost to serve, and users may choose to use this level of individual customer cost to serve instead of the overall average for the system, or they may add on additional differences to get closer to the true avoided costs for the customer at that location. This information may be readily available in real or nearreal time from the ISO, such as in five minute increments, or it may be determined internally within a utility service territory, given the loads on buses, plant output and transmission capacity between buses.
With this information, the system 103 may incorporate these values into an extension of the line loss formulas combined with distribution premiums to determine the cost of service at the customer level. The details of this approach are presented below. Some utilities may not have all of this information readily available. For example, the system may require the user to establish relationships and functions for estimating primary losses and for avoided, or deferred, distribution capital costs.
As shown in FIG. 6A, the system 103 may require that some of these costs be directly specified by the user, and added to the total LMP estimated for that customer for a given time period. Cost inputs that can be input into the system by the user may include: (1) the 5 minute nodal or bus LMP (LMP<sub>it</sub>); (2) line losses (LL<sub>it</sub>); (3) voltage cost (VC<sub>it</sub>); (4) marginal distribution capital costs (CC<sub>it</sub>); (5) a shaping premium (ShP<sub>it</sub>); (6) swing premium (SwP<sub>it</sub>), and ancillary services (Anc<sub>it</sub>). Cost of service may be calculated as follows:<FORM>COS<sub>it</sub>=F(LMP<sub>it</sub>,LL<sub>it</sub>,VC<sub>it</sub>,CC<sub>ti</sub>,Sh<sub>ti</sub>,SwP<sub>ti</sub>,Anc<sub>it</sub>) (8)</FORM>
The user may choose to not vary some of the values over time, and where this is the case, the user may not need to forecast values that do not vary with time. For example, a single annual value may be used for distribution capital cost savings or value, for all customers within a region, or on a given circuit or bus. Or, the user may choose to apply the avoided distribution capital cost adder in terms of the locational $ per KW avoided, which is then forecast individually for each customer, but which is generalized in terms of the avoided cost per KW. Or, a capacity premium may be applied as a single value, related to a constant avoided supply unit, such as a natural gas peaker where the assigned capacity savings is assigned a constant dollar per KW reduced value, consistently applied across all customers equally, or as an avoided $ per KW value. In these cases, the costs may be computed externally by the enduser, and applied to all loads without regard for individual differences.
The Shaping Premium 609 (ShP<sub>it</sub>) may be the weighted average of typical peak and offpeak energy consumption of the customer for the entire year, season or month. A customer that uses a disproportionate amount of peak power may have a cost to serve that may be higher compared to business that uses relatively more offpeak power. To forecast both Shaping and Swing Premiums, hourly load and price forecasts may be developed using future expectations of weather, a customer's load response to weather, and across expected forward prices. Users may develop their own price or load forecasts, to be used in the derivation of the Shaping and Swing Premiums, or following one of the following methods for doing so.
Forecasting Annual Cost of Energy Over Peak and Off Peak Periods. The simplest method for forecasting energy costs, or LMPs, may be done over designed peak and off peak times. Here, the cost of energy may be simply the time weighted average of the forward peak and offpeak price. And the user may be free to determine which periods are assigned and peak versus off peak. An advantage of this method may be its simplicity, its transparency and ease of execution; however, it may not adequately incorporate hourly level of detail, costs or risks within the dispatching decisions.
<maths id="MATHUS00012" num="00012"><math overflow="scroll"><mtable><mtr><mtd><mrow><mi>FCE</mi><mo>=</mo><mrow><munderover><mo>∑</mo><mi>t</mi><mi>T</mi></munderover><mo></mo><mrow><mfrac><mn>1</mn><mrow><msub><mi>n</mi><mi>t</mi></msub><mo>+</mo><msub><mi>m</mi><mi>t</mi></msub></mrow></mfrac><mo></mo><mrow><mo>(</mo><mrow><mrow><msub><mi>P</mi><mi>t</mi></msub><mo>·</mo><msub><mi>n</mi><mi>t</mi></msub></mrow><mo>+</mo><mrow><msub><mi>OP</mi><mi>t</mi></msub><mo>·</mo><msub><mi>m</mi><mi>t</mi></msub></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>9</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
Where
FCE=Forward cost of energy
n<sub>t</sub>=Total peak hours in month t
m<sub>t</sub>=Total offpeak hours in month t
T=Total months in the term of the contract
P<sub>t</sub>=Monthly forward peak price
OP<sub>t</sub>=Monthly forward offpeak price
Alternatively, the user may elect to use a more rigorous method for forecasting energy costs, based on, for example, a generalized autoregressive conditional heteroskedastic framework (i.e., GARCH). The general framework of GARCH based forecasting is well known, however, the system may extend the general GARCH framework to more appropriately meet the unique needs of estimating shaping and swing premiums within an energy management context. Here, the system may estimate daily and hourly energy prices, consistent with many years of hourly weather, such that the user is able to more accurately estimate the cost of serving loads under different weather conditions. This methodology may include parameters for hours, days, weeks, day type, fuel prices, forced outages and weather variables, such that a reasonable forecast of forward hourly prices can be generated, to be subsequently aligned, hour by hour, with the forecasts of hourly loads. Because these hourly price and load forecasts may be simulated over many years of possible hourly weather conditions, the system may ensure that the full range of financial risk, and hence costs, are fully reflected in the shaping premium estimate.
Given that hourly analysis is used, the user may elect to assign the shaping premium over any number of hourly aggregations, as appropriate. The shaping premium may be established for each of 12 months, or each of 4 seasons, for example, and only over designated peak periods, as desired by the user. The fewer hours over which the shaping premium is spread, the higher the cost may be for those fewer hours. Further, the spreading of the shaping premium over these peak hours by the user may reflect the unique supply side capacity risk faced by the utility, and may be revised from time to time, to reflect variability in these supply risks. For example, a reasonable rule of thumb for spreading costs over these hours may be to calculate assignment or allocation weights proportionate to the loss of load probabilities for the utility. In this manner, relatively more shaping premium costs may be allocated to more extreme, or peakier, times of the day. Generally speaking, for a summer peaking utility using natural gas combustion turbines for capacity planning, a user might allocate the shaping premium for July over the peak and near peak hours between 2 pm and 7 pm, during the 20 example July weekdays, yielding approximately 100 hours over which to spread July's premium, and then choose to proportionally weight the allocation relative to July's price forecasts for those hours. Applied in this same manner across 3 or 4 summer months, the resulting 300 to 400 hours of availability reasonably reflects the operating characteristics of the avoided supply alternative, the natural gas peaker. In addition, the proportional allocation, relative to the price forecast, helps further boost cost to serve premiums or adders more toward those hours where load reduction, or optimal dispatch is needed most. In this sense, the hourly price forecast may serve as a proxy for the loss of load probability during those hours. At the beginning of the month, the system may establish similar premium adder allocations for similarly situated hours, since price forecasts beyond one week, given weather uncertainty after one week, typically reverts to a weather normal price forecast which, for example, would predict a similar price for all weekday 2 pm hours during July. As daily weather updates are input into the system, new price forecasts are generated and new allocations are possible. Hence, the extent to which extreme weather is realized early in the month, too much of the overall monthly premium may be allocated too soon in the early part of the month. As such, the system provides for optimal decision dispatching under conditions of future uncertainty, described later.
The following example model is a GARCH (1,1) with an AR(2) specification, the framework of which is wellknown. The innovation of the system lies with the unique process, calculations and application of the framework, juxtaposed with the load forecasts described shortly, to uniquely calculate a cost to serve shaping and swing premium individualized to a customer, based on smart meter usage data observations.
The following is an example of GARCH price forecasting using a GARCH (1,1) with AR(2) model.<FORM>Core In(PD<sub>t</sub>)=constant+β<sub>1 </sub>Day of Week+β<sub>2 </sub>Temp+β<sub>3 </sub>Month+υ<sub>t </sub></FORM>
Here, the core part of the model resembles a traditional regression model. Price may be taken as a log in order to both prevent negative prices and to more appropriately reflect the nonsymmetric, lognormal distribution that electricity prices.<FORM>AR υt=φ1*υt−1+φ2*υt−2+εt </FORM>
Second, the AR equation may specify two (arbitrary) autoregressive terms and its residual error. These terms may reflect the tendency for current price levels to depend on the price levels observed in the last two hours.<FORM>Shock ε<sub>t</sub>=SQRT(σ<sub>t</sub>*e<sub>t</sub>) where e<sub>t</sub>˜N(0,1)</FORM>
Third, a shock may be applied to the residual error term (or alternatively, the error is randomly distributed after controlling for these other prespecified effects).<FORM>Garch σ<sup>2</sup><sub>t</sub>=ω+α*ε<sup>2</sup><sub>t−1</sub>+γ*σ<sup>2</sup><sub>t−1</sub>+ . . . , e.g. δ<sub>t </sub>(Fuel, Outages)</FORM>
Fourth, the magnitude of the shock may depend on the current time period's variance, reflected in the combined ARCH (αε<sup>2</sup><sub>t−1</sub>) and GARCH (γ1σ<sup>2</sup><sub>t−1</sub>) terms, along with two other structural variables (e.g., peaks, force outages) that give an extra boost to the volatility during prespecified peak hours and/or hours within which plant outages occurred.
Given the intraday volatility of hourly prices, the user may choose to forecast an average daily price, or an average afternoon or peak period price using a GARCH based framework, and then apply this daily price forecast to historically observed price shape patterns (i.e., a 24 hour set of price values, taken each day, normalized to the average value, set as 1.0). Then, the user may denote this daily price by P<sub>t</sub><sup>D</sup>, with its appropriate regressors on daily data, prior to applying an appropriate price shape pattern of 24 hourly normalized weighting factors, randomly pulled from among a bin of similar weather conditions (e.g., a bin of day type price shapes observed when temperatures were between 92 degrees and 95 degrees during July). The general form is reflected more simply as:<FORM>P<sub>t</sub><sup>D</sup>=ƒ<sub>1</sub>({right arrow over (P)}<sub>t</sub>,{right arrow over (W)}<sub>t</sub>,{right arrow over (Y)}<sub>t</sub>,{right arrow over (X)}<sub>t</sub>,ε) (10)</FORM>
Where
ƒ<sub>1</sub>: The underlying regression function
P<sub>t</sub><sup>D </sup>Daily average electricity price of day t
{right arrow over (P)}<sub>t</sub>: Past daily average electricity price vector at day t
{right arrow over (W)}<sub>t</sub>: Past weather condition vector at day t
{right arrow over (X)}<sub>t</sub>: Seasonality variables vector at day t
{right arrow over (X)}<sub>t</sub>: Other independent variables vector at day t
ε<sub>t</sub>: White noise error terms at day t
In the above function, the underlying regression ƒ<sub>1 </sub>may take arbitrary function form, linear or nonlinear, in inputs, vector or scalar. For example, ƒ<sub>1 </sub>can be an ARIMA model with regressors. {right arrow over (P)}<sub>t </sub>may be a vector of past daily average electricity prices. {right arrow over (P)}<sub>t </sub>may serve as an autoregressive component of the regression function ƒ<sub>1</sub>. The past weather condition vector of day t, {right arrow over (W)}<sub>t</sub>, may contain weather information such as temperature, humidity, etc. The vector of seasonality variables of day t, {right arrow over (Y)}<sub>t</sub>, may contain seasonal dummy indicator variables. The vector of seasonality variables of day t may serve as the seasonality component of the regression function ƒ<sub>1</sub>.
The method may focus on the persistence of volatility over time; incorporating past measures of volatility into the current volatility and incorporates shocks to the current return. The conditional variance h(t) may depend on its own past values as well as on lagged values of the error terms.<FORM>R<sub>t</sub>=μ+βR<sub>t−1</sub>+ε<sub>t </sub></FORM><FORM>ε<sub>t</sub>=√{square root over (h<sub>t</sub>)}e<sub>t</sub>,e<sub>t</sub>˜IN(0,1)</FORM><FORM>h<sub>t</sub>=α+γ<sub>1</sub>ε<sub>t−1</sub><sup>2</sup>+ηh<sub>t−1</sub>. (11)</FORM>
Volatility depends on all the past values of the error terms. This can be seen by solving recursively:
<maths id="MATHUS00013" num="00013"><math overflow="scroll"><mtable><mtr><mtd><mrow><msub><mi>h</mi><mi>t</mi></msub><mo>=</mo><mrow><mfrac><mi>β</mi><mrow><mn>1</mn><mo></mo><mi>η</mi></mrow></mfrac><mo>+</mo><mrow><mi>γ</mi><mo></mo><mrow><mo>(</mo><mrow><msubsup><mi>ɛ</mi><mrow><mi>t</mi><mo></mo><mn>1</mn></mrow><mn>2</mn></msubsup><mo>+</mo><msubsup><mi>ηɛ</mi><mrow><mi>t</mi><mo></mo><mn>2</mn></mrow><mn>2</mn></msubsup><mo>+</mo><mrow><msup><mi>η</mi><mn>2</mn></msup><mo></mo><msubsup><mi>ɛ</mi><mrow><mi>t</mi><mo></mo><mn>3</mn></mrow><mn>2</mn></msubsup></mrow><mo>+</mo><mrow><msup><mi>η</mi><mn>3</mn></msup><mo></mo><msubsup><mi>ɛ</mi><mrow><mi>t</mi><mo></mo><mn>4</mn></mrow><mn>2</mn></msubsup></mrow><mo>+</mo><mi>…</mi></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>12</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
Different regions or price hubs may reveal different GARCH model specifications, based on the observed history of energy prices and the forward expectations of price volatility and level. GARCH forecasts may be generated for increments of possible future prices, generally from $25 per MWH ATC to $75 per MWH ATC, which typically allows the system to quantify the cost to serve a particular load under the possible set of forward price expectations. The system may hold twenty or more, or less, different forward hourly price expectations over 1 to 30 or more years of hourly weather, and databases the cost to serve a particular customer load under these price/weather combinations. The user may elect to use one of these price forecast scenarios, typically the current forward price expectations (i.e., short run shaping premium), or the user may leverage all of the forward price expectations, calculate shaping premiums under all these future cost expectations and use a long run shaping premium. The advantage of the long run shaping premium is that the user may currently face lower market prices this year, than what is usually typical, and as such, the use of the current forward expectations may exhibit lower shaping premiums than what might be realized, on average, over many years of load realizations.
The use of the long run shaping premium, which in this case may be higher than the short run shaping premium, may reflect an inherent hedge against future higher prices. This hedge is the financial value the utility or the user is willing to pay to customers to hedge against serving their load under extreme weather conditions, where prices may increase higher than today's expectations. Including the long run premium into today's cost to serve enables more efficient long term planning and operations on the part of the utility, mitigating future supply risk, and reflecting a long term value more consistent with integrated resource planning than with short term operational considerations, or concerns, alone.
This long term perspective may be more consistent with traditional utility planning where reserve margins and added capacity are secured in advance of the real time need, given long lead times for construction of new supply capacity. With this system, the cost to serve value over the long run is more appropriately ascribed to each customer, consistent with their hourly usage pattern, reflecting their risk to serve, and mitigating future supply costs and risk, by disproportionately realizing dispatching solutions which secure, reward and reinforce load reductions from those end uses which are more costly to serve.
Traditionally, regulated utilities may issue a single stream of hourly prices, reflective of average system costs and not customer specific costs to serve. Individual cost to serve methodologies may be used within bilateral or competitive markets, but these processes and methods do not consider optimal dispatching solutions within regulated contexts, or contexts where power is secured for aggregations of customers who pay an average rate over the course of a year or month. The system may combine the advantages of both perspectives through the use and application of the embedded forecasts, processes, systems, algorithms and execution to optimally dispatch end uses, subject to supply and price conditions, within such a captive customer, context.
Importantly, the use of shaping and swing premiums within the system may assume that a weekly, monthly, seasonal or annual contractual commitment exists between the utility and customer to insure the sustainability of such arrangements, similar to the regulated tariff framework, or structured bilateral power agreements. These contractual arrangements may be developed at the discretion of the user and their customers. Additionally, where the user does not desire to apply the system within a regulated context, the application of the system may be the same, but the values of some of the component parts of the cost of service change, or become zero. In more competitive contexts, it may be the case that only the LMP and/or market based ancillary service components of the COS are employed. However, the operation and execution of the system does not change.
Hourly Load Forecasts. Because shaping and swing premiums require the user to multiply loads times prices, to derive a cost to serve, the system may provide a method for forecasting hourly loads to be multiplied by the hourly prices described above. These load forecasts may be regression based forecasts, and as such, their derivation and application are wellknown. Rather, the unique contribution of the system derives from the joint set of automated processes, calculations and cost to serve calculations as applied to the energy management and end use and microgrid resource dispatching context described herein. The user may choose to apply a nonregression based methodology to estimate future loads, provided these forecasts depend on weather conditions expected within the utility's area, and that the price forecasts also depend on this same hourly weather data. First, hourly customer loads, by customer, or customer class, may be regressed against hourly weather conditions, for each hour, day type, and month. The estimation process may analyze, and choose from, candidate regression equations, may apply splines, knots (i.e., X values where slope changes occur), or may specify possible changes in load response over both independent weather variables and nonweather dependent variables (e.g., December or July variable, school hours, etc.), based on predictive ability or Fit diagnostics, such as adjusted Rsquared and/or mean average percent error. The selected regression functions may then be used to select the best equation for that customer, or class, for a given hour in a given month for a specific day type.
Hourly electricity demand Q<sub>k</sub><sup>H </sup>may be simply represented on hourly data as follows:<FORM>Q<sub>k</sub><sup>H</sup>=ƒ<sub>2</sub>({right arrow over (Q)}<sub>k</sub>,{right arrow over (W)}<sub>t</sub>,{right arrow over (Y)}<sub>k</sub>,{right arrow over (X)}<sub>k</sub>,ε<sub>k</sub>) (13)</FORM>
Where
ƒ<sub>2</sub>: The underlying regression function
Q<sub>k</sub><sup>H</sup>: Hourly electricity demand of hour k
{right arrow over (Q)}<sub>k</sub>: Past hourly historic energy consumption vector
{right arrow over (W)}<sub>t</sub>: Past weather condition vector at day t which hour k belongs to
{right arrow over (Y)}<sub>k</sub>: Seasonality variables vector at hour k
{right arrow over (X)}<sub>k</sub>: Other independent variables vector at hour k
ε<sub>k</sub>: White noise error terms at hour k
In the above, the underlying regression function ƒ<sub>2 </sub>may take arbitrary function form, linear or nonlinear, in inputs, vector or scalar. For example, ƒ<sub>2 </sub>can be an ARIMA model with regressors. {right arrow over (Q)}<sub>k </sub>may be a vector of hourly historic energy consumptions. It may serve as an autoregressive component of the regression function ƒ<sub>2</sub>. The weather condition vector {right arrow over (W)}<sub>t </sub>may contain weather information such as temperature, humidity, etc. The vector of seasonality variables, {right arrow over (Y)}<sub>k</sub>, may contain seasonal dummy indicator variables. It may serve as the seasonality component of the regression function ƒ<sub>2</sub>.
The resulting set of regression equations may number 576 in total, reflecting 24 hours, for weekday and weekend day types, over 12 months, or 576 hourly regression equations. The user may also choose to group similar types of hours together, for modeling purposes, such as all afternoon hours, to gain statistical power where insufficient sample exists. Each of these regression equations may then be applied to several years of hourly weather data, to simulate a range of possible loads that the utility faces in serving that load over a long term planning horizon. The average of these load simulations may reflect the load normal load shape for a given day type and month. The average of these load simulations may also reflect the interaction and influence of all weather, and nonweather factors, and as such, may be a more accurate reflection of the load at risk during peak weather times than traditional weather normalization methods might predict.
Importantly, this approach may differ from traditional weather normalization practices conducted among utilities. In this system, loads may be simulated or forecasted over many years of weather, yielding a full distribution of possible loads, the average of which becomes a load normal result, reflecting average weather conditions. In contrast, traditional utility weather normalization may construct a weather regression function for a load, and then score that function with weather normal data. In this latter case, the system does not have a full distribution, and the system may not be able to observe the range of risk the utility faces in serving that load. As such, the system may not be able to accurately value the cost to serve that customer, under varied future weather conditions, like one can with the more robust causal simulation methodology described herein.
Derivation of Shaping Premium from Load and Price Forecasts. Given the development of hourly load forecasts and hourly price forecasts above, both keyed to the same hourly weather, simulated over many years of weather, the system may then multiply prices times loads for all hours and derive the average shaping premium by dividing by the average price for a given period, be it seasonal, or monthly, or other, to be shaped over the userspecified peak hours for that period, as described previously.
Average Load Weighted Cost of Energy
<maths id="MATHUS00014" num="00014"><math overflow="scroll"><mtable><mtr><mtd><mrow><mi>LWFCE</mi><mo>=</mo><mrow><munderover><mo>∑</mo><mi>t</mi><mi>T</mi></munderover><mo></mo><mrow><mfrac><mn>1</mn><mrow><mo>(</mo><mrow><mrow><munderover><mo>∑</mo><mi>i</mi><msub><mi>n</mi><mi>t</mi></msub></munderover><mo></mo><msub><mi>Q</mi><mi>i</mi></msub></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mi>j</mi><msub><mi>m</mi><mi>t</mi></msub></munderover><mo></mo><msub><mi>Q</mi><mi>j</mi></msub></mrow></mrow><mo>)</mo></mrow></mfrac><mo></mo><mrow><mo>(</mo><mrow><mrow><msub><mi>P</mi><mi>t</mi></msub><mo>·</mo><mrow><munderover><mo>∑</mo><mi>i</mi><msub><mi>n</mi><mi>t</mi></msub></munderover><mo></mo><msub><mi>Q</mi><mi>i</mi></msub></mrow></mrow><mo>+</mo><mrow><msub><mi>OP</mi><mi>t</mi></msub><mo>·</mo><mrow><munderover><mo>∑</mo><mi>j</mi><msub><mi>m</mi><mi>t</mi></msub></munderover><mo></mo><msub><mi>Q</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>14</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
Where
LWFCE=Load Weighted Forward cost of energy
n<sub>t</sub>=Peak hours in month t
m<sub>t</sub>=Offpeak hours in month t
T=Total months in the term of the contract
Q<sub>i</sub>=Energy demand in peak hour i
Q<sub>j</sub>=Energy demand in offpeak hour j
P<sub>t</sub>=Monthly forward peak price
OP<sub>t</sub>=Monthly forward offpeak price
The Load Factor (shaping) Premium (LFP) may be represented:<FORM>LFP=LWFCE−FCE (15)</FORM>
The shaping premium may be viewed as the cost of energy above the around the clock (8760 hours per year) cost of forward energy. The premium may be characterized by the unique load weighting of individual energy consumers. The premium may be typically a positive number, but can be negative for large offpeak energy consumers. Street lighting for example will have a negative premium. The magnitude of the premium may be related to the covariance between price and consumption. Thus, the higher the covariance, the higher the premium.
Capacity Premium Alternative Method. A user may choose to use a simpler capacity premium, in some cases, to reflect the shaping and swing premiums, instead of derivation via hourly energy estimation. Here, a user may use a capacity premium, or fraction thereof, based on qualifying supply facility or other capacity cost equivalent (e.g., cost of capacity on the market). This value may replace both the shaping and swing premiums, and does not necessarily require that the cost vary by customer but varied cost allocation based on the per KW reduced is recommended. Here, a qualifying facility may reflect the construction cost of a natural gas peaker, or other peak serving supply resource, usually reported as a dollar per KW served. The user may also decrement the cost value, depending upon operational factors, including, but not limited to, hours of load reduction availability, advance notice, KW reduction available, override or compliance history, duration of reduction, or the hours in which reductions are realized. The capacity value may be spread over targeted peak hours as determined by the user, or across various months, or only in a given season.
Where regulation has established an avoided capacity value for a qualifying facility, this method may provide more consistency with existing avoided cost frameworks, and less complexity than the aforementioned hourly estimation method. Nonetheless, this capacity cost addition to the LMP, even if assigned to be the same per KW cost for all customers, does reflect the long term supply risk faced by the utility in serving uncertain loads. Assigned as per KW cost value, this approach proportionately reflects higher or lower KW reductions offered by customers, during the hours specified. Again, the fewer hours over which the capacity premium is spread, the higher the hourly cost. And again, this capacity premium can be allocated proportional to the loss of load probability or to future price expectations. However, this approach does not distinguish between customers with regard to their unique cost to serve. It may reflect a system average cost, over all customers.
The Swing Premium 611 (SwP<sub>it</sub>) may represent that some customer's loads are more volatile relative to other customers. Thus, the utility may invest in additional resources to cover the uncertainty associated with these customers' loads. This added risk and associated investment is termed the swing premium. All load serving entities whether they are utilities or onsite distributed generators are faced with the problem of demand uncertainty, or volume risk. Energy consumption may be largely determined by weather. However, actual temperatures can never be exactly known prior to the physical supply of energy. Planners have developed means to estimate consumption and schedule supply resources in anticipation of these forecasts. Typically, overall consumption may be matched with physical generation assets in energy and capacity markets and hedged with financial contracts. These assets and/or contracts may serve to mitigate the baseload consumption risk.
During mild or expected weather events, overall demand can exhibit significant load diversity, and less risk, among the various consumers within the system. During these hours there may be an equal likelihood that there are individual consumers using more than anticipated as there are consumers using less than anticipated. Overall, the system may balance as these loads cancel out and sum up to the expected forecast. However, during extreme weather events (either cold weather or hot weather), load diversity tends to decrease as loads work together in response to the weather event. During these hours, the planning forecast may deviate from actual exposing the load serving entity to supply risk. Because of load and price covariance, it is during these hours that the utility can be faced with high cost supply alternatives. And the higher the loads, generally the higher the costs to serve, and under a flat $ per KWH rate structure, customers are not constrained in terms of how much energy they use. This may be termed volume risk, due to the covariance between prices and loads, thereby necessitating the estimation of the risk, via application of one of the possible swing premium estimation methodology options, described below.
Conceptually, the covariance premium may be equal to the future cost of supplying the uncertain marginal energy above the “baseload” or hedged consumption. Because of the uncertainty, the premium is often referred to as a risk premium. There are four possible cash flows: 1) less than planned (forecast) consumption when spot prices are high; 2) less than planned consumption when prices are low; 3) more than planned consumption when prices are high; 4) more than planned consumption when prices are low. Whether a price is high or low is measured relative to the hedge cost, or the cost of the energy that was originally allocated for the planned (forecast) consumption. If the spot price is above the cost of the hedge, then the energy supplier may have positive revenue only if the consumer uses less than was planned, and may have negative revenue if the consumer uses more than was planned. When spot prices are less than the cost of the hedge the opposite may be true.
During strictly mild conditions, during times of load diversity, the cash flow from these four conditions may cancel out thus eliminating much of the supply risk. However, during extreme conditions, price and load covariance may work to reduce positive revenue and increase negative revenue resulting in a net loss to the energy supplier. This net loss may be what is measured by the risk premium and added to the retail cost of supply.
During mild (diverse) weather conditions, positive and negative cash flow may largely cancelout. During extreme weather conditions, when prices and loads are covaried, the positive cash flow may be reduced and the negative cash flow may increase. The energy supplier is short a straddle. The value of the short straddle is equal to the cost of the swing premium (risk transfer fee).
The value of the covariance premium (risk transfer straddle) can alternatively be measured using financial engineering tools such as the BlackScholes equation, simulating the average monthly covariance risk, or using Monte Carlo simulation. The user may choose which method best fits the particular end use energy management framework, or calculate the premium using all options and incorporate the average or maximum value estimates into the system. If the user has adopted the hourly estimation process described above, including hourly price forecasts, hourly load forecasts, and simulations conducted over multiple weather years, then the volume risk premium can be calculated as the average monthly covariance over multiple years of simulated observations. This method is based on robust hourly analysis, and is reasonably accurate where the forecasts themselves are acceptable.
Alternatively, a BlackScholes/Short Straddle Method estimation can be generalized and employed, by considering the regional and customer characteristics with the most impact on covariance premium. Regionally, price volatility creates the most impact in measuring the cost of uncertain consumption. Thus, the higher the price volatility, the higher the risk premium. From the perspective of the consumer, load volatility creates the most impact in swing premium. Thus, the higher the load volatility, the higher the uncertainty and the higher the risk premium. An advantage of the short straddle method for calculating the covariance cost of energy is in the ability to use the BlackScholes formulas to calculate the cost of the contract, which for some users, may be a simpler method to estimate a reasonable proxy for the shaping and swing, or capacity, premiums.
Correlated Diversity. When viewed as a hedged position, the portfolio risk can be priced as equivalent long straddles. When the hedger is long, the forward option contracts (hedge) and short the underlying energy, the change in the value of the hedger's position during the life of the hedge is<FORM>ΔS−hΔF (16)</FORM>
The variance, v, of the change in the value of the hedged position is given by:<FORM>v=σ<sub>S</sub><sup>2</sup>+h<sup>2</sup>σ<sub>F</sub><sup>2</sup>−2hρσ<sub>S</sub>σ<sub>F</sub> (17)</FORM>
So that:
<maths id="MATHUS00015" num="00015"><math overflow="scroll"><mtable><mtr><mtd><mrow><mfrac><mrow><mo>∂</mo><mi>v</mi></mrow><mrow><mo>∂</mo><mi>h</mi></mrow></mfrac><mo>=</mo><mrow><mrow><mn>2</mn><mo></mo><mi>h</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msubsup><mi>σ</mi><mi>F</mi><mn>2</mn></msubsup></mrow><mo></mo><mrow><mn>2</mn><mo></mo><msub><mi>ρσ</mi><mi>S</mi></msub><mo></mo><msub><mi>σ</mi><mi>F</mi></msub></mrow></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>18</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
Setting this equal to zero, and noting that ∂<sup>2</sup>v/∂h<sup>2 </sup>is positive, we see that the value of h that minimizes the variance is:
<maths id="MATHUS00016" num="00016"><math overflow="scroll"><mtable><mtr><mtd><mrow><mi>h</mi><mo>=</mo><mrow><mi>ρ</mi><mo></mo><mfrac><msub><mi>σ</mi><mi>S</mi></msub><msub><mi>σ</mi><mi>F</mi></msub></mfrac></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>19</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
Where<FORM>E(ΔS)−E(ΔF)=0</FORM>
ΔS Change in spot price S, during a period of time equal to the life of the hedge
ΔF Change in futures price, F, during a period of time equal to the life of the hedge
σ<sub>S </sub>Standard deviation of ΔS
σ<sub>F </sub>Standard deviation of ΔF
ρ Coefficient of correlation between ΔS and ΔF
h Hedge ratio
The hedge ratio in this method may be used to price available straddle positions the value of which is equal to the cost of the covariance premium. Price and Demand Covariance. Let the historical daily weather data set denoted by Ω<sub>{right arrow over (W)}</sub>. Note that Ω<sub>{right arrow over (W)}</sub> is a set whose elements is {right arrow over (W)}<sub>t</sub>, and Ω<sub>{right arrow over (W)}</sub> may have a large number elements. Let N be the number of elements in the set Ω<sub>{right arrow over (W)}</sub>. The probability of drawing any sample from Ω<sub>{right arrow over (W)}</sub> is 1/N. For each random sample {right arrow over (W)}<sub>t </sub>drawn from Ω<sub>{right arrow over (W)}</sub>, we compute the pair: {Q<sub>k</sub><sup>H</sup>,P<sub>k</sub><sup>H</sup><sup><sub2>ζ</sub2></sup>} using (12) or a comparable load forecast), and (8) or comparable price forecast, where (8) is forecast of average daily peak price, and (11) creates hourly prices from the daily average peak price, by randomly sampling a 24 hour price shape pattern from among available observed actual price shape patterns (24 hours) occurring during similar weather conditions for the day.
Hourly Price Shapes. Let the set Ω<sub>{right arrow over (P)}</sub>, we call it Price Shapes, to be the set of historical hourly prices of each 24hour day. That is,<FORM>Ω<sub>{right arrow over (P)}</sub>={[P<sub>i,1</sub><sup>H</sup>,P<sub>i,2</sub><sup>H</sup>, . . . ,P<sub>i,24</sub><sup>H</sup>]}<sub>i=1</sub><sup>n</sup> (20)</FORM>
where P<sub>i,k</sub><sup>H </sup>denotes the historical price of hour k of day i and n is the total number of historical days, 1≦k≦24 and 1≦i≦n. To further simplify the notation, we use {right arrow over (P)}<sub>i </sub>to denote the 24hour prices of day i, i.e. {right arrow over (P)}<sub>i</sub>=[P<sub>i,1</sub><sup>H</sup>,P<sub>i,2</sub><sup>H</sup>, . . . , P<sub>i,24</sub><sup>H</sup>].
Hourly prices {right arrow over (P)}<sub>i </sub>are then drawn randomly from Ω<sub>{right arrow over (P)}</sub> with probability 1/n. Suppose that {right arrow over (P)}<sub>j </sub>is the current random sample of 24hourly prices, we rescale each coordinate of {right arrow over (P)}<sub>j </sub>by a common scalar ζ such that the resulting daily average price is equal to P<sub>j</sub><sup>D</sup>. That is,
<maths id="MATHUS00017" num="00017"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><mi>ζ</mi><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mn>24</mn></munderover><mo></mo><mfrac><msubsup><mi>P</mi><mrow><mi>j</mi><mo>,</mo><mi>k</mi></mrow><mi>H</mi></msubsup><mn>24</mn></mfrac></mrow></mrow><mo>=</mo><msubsup><mi>P</mi><mi>j</mi><mi>D</mi></msubsup></mrow></mtd><mtd><mrow><mo>(</mo><mn>21</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
Note that P<sub>j</sub><sup>D </sup>is obtained from (8) using the regressors corresponding to the day j. We denote the ζ scaled scalars P<sub>j,k</sub><sup>H </sup>by P<sub>j,k</sub><sup>H</sup><sup><sub2>ζ</sub2></sup>. Under the context where there is no confusion about day j, we will write: P<sub>k</sub><sup>H</sup><sup><sub2>ζ</sub2></sup> for simplicity.
The system may then define the resulting set of pairs to be:
<maths id="MATHUS00018" num="00018"><math overflow="scroll"><mtable><mtr><mtd><mrow><msubsup><mi>Ω</mi><mrow><mi>Q</mi><mo>,</mo><mi>P</mi></mrow><mi>k</mi></msubsup><mo>=</mo><mrow><mo>{</mo><mtable><mtr><mtd><mtable><mtr><mtd><mrow><mrow><mrow><mo>(</mo><mrow><msubsup><mi>Q</mi><mi>k</mi><mi>H</mi></msubsup><mo>,</mo><msubsup><mi>P</mi><mi>k</mi><msub><mi>H</mi><mi>ζ</mi></msub></msubsup></mrow><mo>)</mo></mrow><mo></mo><mrow><msub><mover><mi>W</mi><mo>→</mo></mover><mi>t</mi></msub><mo></mo><munder><mo>→</mo><mrow><mstyle><mspace width="1.1em" height="1.1ex"/></mstyle><mo></mo><mrow><mo>(</mo><mn>12</mn><mo>)</mo></mrow><mo></mo><mstyle><mspace width="1.1em" height="1.1ex"/></mstyle></mrow></munder><mo></mo><msubsup><mi>Q</mi><mi>k</mi><mi>H</mi></msubsup></mrow></mrow><mo>,</mo></mrow></mtd></mtr><mtr><mtd><mrow><mrow><msub><mover><mi>W</mi><mo>→</mo></mover><mi>t</mi></msub><mo></mo><munder><mo>→</mo><mrow><mstyle><mspace width="1.1em" height="1.1ex"/></mstyle><mo></mo><mrow><mo>(</mo><mn>8</mn><mo>)</mo></mrow><mo></mo><mstyle><mspace width="1.1em" height="1.1ex"/></mstyle></mrow></munder><mo></mo><mrow><msubsup><mi>P</mi><mi>t</mi><mi>D</mi></msubsup><mo></mo><munder><mo>→</mo><mrow><mstyle><mspace width="1.1em" height="1.1ex"/></mstyle><mo></mo><mrow><mo>(</mo><mn>11</mn><mo>)</mo></mrow><mo></mo><mstyle><mspace width="1.1em" height="1.1ex"/></mstyle></mrow></munder><mo></mo><msubsup><mi>P</mi><mi>k</mi><msub><mi>H</mi><mi>ζ</mi></msub></msubsup></mrow></mrow><mo>,</mo></mrow></mtd></mtr></mtable></mtd></mtr><mtr><mtd><mrow><mo>∀</mo><mrow><msub><mover><mi>W</mi><mo>→</mo></mover><mi>t</mi></msub><mo>∈</mo><msub><mi>Ω</mi><mover><mi>W</mi><mo>→</mo></mover></msub></mrow></mrow></mtd></mtr></mtable><mo>}</mo></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>22</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths>
As with forecasting of electricity demand discussed above, the system 103 may forecast cost of service in a forward looking optimization. The system may forecast cost of service using similar methods to the electricity demand forecasting discussed above. In other words, a statistical model is used that relates the cost of service to variables such as temperature, humidity, time of day, day of week, and month. The parameters of the model, as before, may be estimated using historical data, and the forecast may be constructed using the same sources as the electricity demand model above.
As more and more system enabled end use and microgrid resource dispatching is enabled via more and more market share adoption of the smart grid application technologies, more PHEV charging, more renewable, more distributed generation, such as solar, wind and storage emerge, the price setter for peaking capacity is likely be, at least in some cases, the end use dispatchable resources, where increased customers' willingness to participate in peaking capacity markets occurs at prices lower than the alternative cost of supply. As such, the system may protect users and utility decision makers from over supplying demand response into a market, by valuing the marginal capacity costs as a function of the end use and microgrid resource dispatching resource's magnitude, relative to the system and the hours of resource availability. However, the user may opt to avoid using the simpler capacity premium, in this case, as this proxy for valuation does not reflect changes in, or consequences derived from, customer loads. The capacity premium method may be informed only by the marginal cost of peaking supply. Conversely, the hourly level valuation methodologies used for shaping and swing premiums may provide demand side information in the derivation of the premiums, as reduced loads during peak times may be reflected in the hourly level load forecasts. As such, lower premiums may emerge over time as more and more load reductions are observed, realized and incorporated into the system's load forecast estimation process.
Optimization Modules
Optimizing, in a preferred embodiment, may include taking data and forecasted inputs, processing the data and forecasted inputs to produce instructions for energy distribution and energy use based upon one or more desired goals. As shown in FIG. 1, the optimizations 105 may include one or more suboptimizations, such as, but not limited to, demand response optimization 107, peak demand optimization 109, micro dispatch optimization 111, bill target optimization 113, renewable generation optimization 115, and/or microgrid optimization 117. Suboptimizations may be chosen for particular purposes depending on particular goals. One or more optimizations may be used for a particular application. For example, if minimizing peak demand is a goal of the utility, then the peak demand optimization 109 may be used, whereas if demand reduction is desired, then the demand response optimization 107 may be used. If both goals are desired, both suboptimizations may be used in combination with results processed to maximize benefits of both suboptimizations.
The various suboptimization systems may use a series of complex linear and/or nonlinear mathematical models. The models may be applied within customerspecific constraints, along with microlocational costs and value, which are uniquely specified for a particular customer. Preferably, dispatching occurs for a 1 to 5 minute period, but other time periods may be possible. Dispatching may be subject to the constraints of, for example: a total allowed number of controls per customer per month or season; a maximum cycling for an appliance; soft and hard costs associated with controlling customers, which can be expressed as RMCs, or the loss of comfort, cost of incentives, or direct payments to customers, i.e., bids; and/or costs that vary by appliances or enduses.
The optimization systems may capture both a decrease in costs (LMP including adders), as well as the decrease in revenue. The optimization systems can be refined to capture any regulatory shared savings aspects, which depend on avoided costs, down to a customer level. The formulations may be general enough to include other enduses and customers, with or without distributed generation, such as solar water heat, PV, storage or PHEV battery charging and discharging. Additional control options may lead to less need for all customers to have control boxes, or may create more options for utilities to alternatively tap into houses.
FIG. 8 is a flow chart showing a general flow for optimizations. An optimization system may receive forecast cost of service at the customer 801, a forecast enduse demand 803, and/or technology and program constraints 805. A mathematical optimization 807 may then use the inputs and output a schedule of enduse run times, such as at a five minute level or less for the next hour 809, which may be sent to the HAN vendor server 123.
In various optimizations, at a minimum, there may be a constraint that individual demand reductions must sum to the total required reduction needed by the utility. Other constraints that may be included in the system are: cycling of the appliance is within the lower and upper bounds; maintaining a certain level of indoor temperature for each customer; maintaining a minimum level of water temperature in the hot water heater; not cycling an appliance faster than its manufactured limits, as well as other technical limitations of the appliance; staggering starts to avoid rapid load increases; and determining probability that a customer may override based on statistical modeling of past events.
The mathematical algorithms within the optimizations may determine the optimal combination of distributed resource and appliance control, coordination and dispatching, given set constraints and conditions. Every dispatching solution, however may be uniquely defined by the customers, the loads, the forecasts, constraints and objectives of each new desired solution. Therefore, it is impossible to prespecify the exact set of optimal dispatching solutions. Rather, the optimizations may enable an optimal dispatching and cycling of these resources to achieve the maximum energy and peak demand savings, subject to customer or utility specified constraints. In subsequent hours, or span of hours, as new constraints and conditions are observed, a new and different optimal dispatch solution is determined and made available for execution.
Specific Optimizations
The next sections address several suboptimization models included in the optimizations 105.
Demand Response Optimization (Curtailment)
The demand response optimization 107 may involve curtailment of use by customers.
In certain situations, a utility may be faced with a condition where there is no inventory, or buffer, between supply and demand. As such, supply must follow demand in real or nearreal time to ensure a supply/demand balance. Embodiments of the present invention may provide a systematic solution to demand adjustments. The demand adjustments may be subject to changing marginal costs of supply, such that overall costs are minimized, creating a virtual, real or nearreal time inventory buffer between supply and demand.
During specific peak hours, the expected total peak demand (kW) for electricity may exceed the availability of power supplies, increase costs of providing power, or jeopardize reliable supply. In response, the utility can purchase power from other power generators, which can be very costly or not feasible where constraints exist in the transmission system. Alternatively, the utility can adjust demand to mitigate the shortfall in the supply/demand balance by sponsoring load reductions in demand.
Embodiments of the present invention may provide an optimal dispatching of specific enduses under this situation, subject to constraints preset by customers, and accounts for variable costs to serve each customer, such that the overall dispatching strategies are jointly optimal across varying supply and demand conditions. Other demand response methods do not: (1) jointly optimize demand with supply, subject to customer constraints or multiple utility objective functions; (2) consider customer specific marginal costs, (3) update in real time (5 minutes or less); (4) capture ancillary service value; and/or (5) consider grid benefits such as leveling load on service transformers, reducing line losses or targeting specific grid areas in need to increased voltage support.
An objective of demand response optimization 107 may be to maximize utility revenue while achieving a demand reduction specified by the utility.
Mathematically, the problem is described below. Decision variables may include:
X<sub>ijh</sub>=the fraction of hour h to interrupt customer i, appliance j
Data may include:
 I<sub>ijh</sub>=the cost per hour to interrupt customer i in hour h, appliance j (the incentive)
 COS<sub>ih</sub>=the forecast cost to serve electricity to customer i in hour h
 R<sub>ih</sub>=cost per hour charged to customer i in hour h (the rate, it can also be a flat rate, which does not vary over time)
 Demand<sub>ijh</sub>=the forecast demand for energy for customer i, hour h, appliance j
 Hours<sub>ij</sub>=total hours of interruption allowed for customer i, appliance j
 Reduction<sub>h</sub>=the utility's required energy reduction for hour h
 UB<sub>ijh</sub>=upper bound on fraction of hour h that the utility can interrupt customer i, appliance j (0<=UB<sub>ijh</sub><=1)
The system can be set to maximize the revenue, and, thus, maximize avoided cost:
<maths id="MATHUS00019" num="00019"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><mo>(</mo><mtable><mtr><mtd><mrow><mrow><msub><mi>R</mi><mi>ih</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow><mo></mo></mrow></mtd></mtr><mtr><mtd><mrow><mo>(</mo><mtable><mtr><mtd><mrow><mrow><msub><mi>I</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>+</mo></mrow></mtd></mtr><mtr><mtd><mrow><msub><mi>COS</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></mtd></mtr></mtable><mo>)</mo></mrow></mtd></mtr></mtable><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths><maths id="MATHUS000192" num="00019.2"><math overflow="scroll"><mrow><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mspace width="5.6em" height="5.6ex"/></mstyle><mo></mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow></mrow><mo>≤</mo><mrow><msub><mi>Hours</mi><mi>ij</mi></msub><mo></mo><mstyle><mspace width="14.4em" height="14.4ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></mrow></math></maths><maths id="MATHUS000193" num="00019.3"><math overflow="scroll"><mrow><mrow><mrow><mn>0</mn><mo>≤</mo><msub><mi>X</mi><mi>ijh</mi></msub><mo>≤</mo><mrow><msub><mi>UB</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="15.8em" height="15.8ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></math></maths><maths id="MATHUS000194" num="00019.4"><math overflow="scroll"><mrow><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><mrow><msub><mi>Reduction</mi><mi>h</mi></msub><mo></mo><mstyle><mspace width="3.9em" height="3.9ex"/></mstyle><mo></mo><mi>h</mi></mrow><mo>∈</mo><mi>H</mi></mrow></mrow></math></maths>
The same model can also be used to address different situations. For example, if the incentive cost (I<sub>ijh</sub>) is not set by the utility, but is allowed to be set by individual customers through bids (real or nearreal time, prior to the actual event), then this same approach can be used for a bidding program irrespective of a sector. Alternatively, the cost of curtailment can also be replaced by the customer's selfreported cost of curtailing the enduse. This can include the cost of lost comfort, the cost of lost production, etc.
There may be several inputs into the demand response optimization for curtailment. Before addressing the details about the input variables, it may be noted that this problem is a forward looking situation. A relevant issue may concern how much demand reduction must be achieved to balance demand and supply in the next period. Therefore, a majority of the variables in the optimization must be forecast as they cannot be measured. In contrast, there may be variables that need not be measured as they are known before a problem arises. These two types of inputs are addressed separately.
The list of inputs for this optimization may be known or forecast. Inputs may include: customer has agreed to participate at that time; technology constraints; upper bound of curtailment; allowed total hours of reduction; required reduction; incentive; allowed hours of reduction; forecast inputs; cost of service; demand by enduse; voltage/power factor; line losses; total premise load; 5 Min LMP forecast; and/or weather forecast.
Known inputs may include: allowed hours of interruption (Hours<sub>ij</sub>), incentive (I<sub>ijh</sub>), rate (R<sub>ijh</sub>), and required reduction (Reduction<sub>h</sub>). Other inputs that are likely to be known at the time of optimization but that are not explicitly shown in the equations may include constraints such as whether or not the customer has agreed to curtailment during that specific period or has optedout, and technology constraints about the specific enduses (e.g., minimum battery charge times, recovery time). For example, it is not possible to force a water heater to run on, the system can only issue commands for when the water heater is not allowed to turn on. Note, however, that by observing the length of time between a system imposed off signal and when the water heater turns on due to its natural duty cycle (by doing small scale testing including different lengths of shutoff periods), it is possible to develop a customer specific relationship between the cutoff period and the maximum recovery period. This relationship may then be incorporated within the optimization to ensure that the on and off times capture the both the required load as well as recovery times.
As noted above, the allowed hours of interruption (Hours<sub>ij</sub>) may be a known variable. The allowed hours of interruption are generally stated as part of the terms and condition of the program. If the allowed hours of interruption are not included in the optimization, then it is possible that some customers would be dispatched more than they agreed.
The incentive (I<sub>ijh</sub>) may also be part of the terms of conditions of a utility program. Since utilities are often regulated, incentives are usually the same for all customers within a given rate class to avoid any indication of discrimination. However, since the cost of supplying electricity differs across customers, it is more efficient and less costly to offer different incentives to different customers. It also may be beneficial to vary incentives by time period, cost to serve, or to dispatch costlier loads in ways that lower overall total costs for the system. In these cases, the system may adjust the dispatching specifications to accommodate individual customer costs to serve, to yield optimal incentives, to respond to bidin prices from customers for their load, for pricing signal setting or for overall customer load dispatching. Note that the concepts of incentives and “bids” are analogous within the description. The system dispatching solutions operate in the same manner, but the inputs may vary, given the extent to which the utility has flexibility to optimize overall dispatching down to individualized customer or end use costs, or bids.
Every customer may have a different response to incentives offered by the utility to control appliances during an event. Once price elasticities are measured, either through surveys, customer bidding programs, past events or other means, and a program is set up whereby customers are paid on the basis of how much energy they are likely to save during an event, the system may maximize the avoided cost while minimizing the total incentive cost.
Table 1 shows different incentive elasticities across customers. In the first column there is a flat rate for all customers, but in the second column the incentive varies as the customer saves more. In both cases, the required demand reduction may be met, and the total avoided cost is similar, but the incentive cost (the customer payments) is substantially smaller when incentives are based on price elasticity, and customers are dispatched using the system and this price elasticity.
<tables id="TABLEUS00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="105pt" align="left"/><colspec colname="1" colwidth="35pt" align="center"/><colspec colname="2" colwidth="77pt" align="center"/><thead><row><entry/><entry namest="offset" nameend="2" rowsep="1">TABLE 1</entry></row><row><entry/><entry namest="offset" nameend="2" align="center" rowsep="1"/></row><row><entry/><entry>Incentives</entry><entry/></row><row><entry/><entry>Flat</entry><entry>Behavioral</entry></row><row><entry/><entry namest="offset" nameend="2" align="center" rowsep="1"/></row></thead><tbody valign="top"><row><entry/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="21pt" align="left"/><colspec colname="1" colwidth="84pt" align="left"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="77pt" align="char" char="."/><tbody valign="top"><row><entry/><entry>Avoided Cost</entry><entry>$348</entry><entry>$351</entry></row><row><entry/><entry>Customer Payments</entry><entry>$200</entry><entry>$23</entry></row><row><entry/><entry namest="offset" nameend="3" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
This same behavioral model in the system can be used to capture such things as probability of overrides during an event, forecasting when customers will come home or leave the house, predicting when there will be a sudden increase in water heating use due to showers/baths, etc. All this information can be incorporated into the dispatching descisions by the system.
The rate (R<sub>ijh</sub>) may be a generalized term that accommodates any type of rate, such as a flat rate or a timedifferentiated rate. Examples of time differentiated rates may include realtime pricing (RTP), where the rates vary by the hour, timeofuse (TOU) rates, where the rates vary by well defined periods of the day, and/or criticalpeak prices (CPP), where customers are charged a very high price during periods where the utility is experiencing critical demand conditions. These prices or rates may be issued in advance, or in real time. When issued in advance, the rate may be known within the optimization. Where the rate is forecast (i.e., 5 min LMP, real time RTP), or where the utility is responding to prices in realtime, the rate may not be known and the system may use a marginal costing estimation process, which includes both supply and demand resources, to estimate the magnitude of change in forecast prices, given the duration, magnitude and hours of availability for demand side resources.
The required reduction (Reduction<sub>h</sub>) may also be known. The utility may have the ability to forecast total demand and total supply. Therefore, it may be more efficient to respond to system level load reduction specifications or to report to system operators hourly forecasts of enabled load reduction realizations. The optimization may project current day and/or next day load reduction capability, the level of which may be ultimately selected by users or system operators. As is the case with rate (R<sub>ijh</sub>), as the level of demand under management of the system increases the demand reduction may change from being known to requiring forecasting. These effects may be estimated by a marginal costing estimation process, where the incremental cost of the last unit of demand reduction is matched to the incremental supply cost. In this manner, the utility does not overpay for too much demand reduction. As such, the system may stop short of joint dispatching of both supply and demand directly, opting instead to estimate the cost consequences of varied demand reduction realizations on supply, as a proxy. This approach may be used because a true joint dispatch of all these resources may be too slow and cumbersome to operate efficiently given the time constraints involved.
In addition to the above known inputs, forecast inputs may also be used. The key sets of forecast inputs into the optimization are (1) demand (Demand<sub>ijt</sub>) for dispatchable enduses, and (2) costs to serve (COS) the dispatchable enduses.
Demand may be forecast for dispatchable end uses. Examples of dispatchable enduses that may be forecast may include HVAC and water heating, but may extend to electric vehicle battery charging needs, lighting, pool pumps, spas and other end uses. While there are several methods for forecasting electricity demand, including neural networks and Markov Chains, a preferred method may use a statistical modeling framework.
A fitted value for each dispatchable enduse may be developed and used for demand (Demand<sub>ijt</sub>). This forecast may extend out from the next hour to the end of the month and may be stored the one or more databases 133. These forecasts may be constantly developed and stored so that the utility can call a demand response event at any time and all the necessary inputs are available.
Cost of service (COS) may also be forecast. When forecasting cost of service, several variables may also need to be forecast as well. These additional subvariables may include the cost of service adders, described previously. The forecasts of the additional subvariables are individually described below.
LMP nodal cost at bus: The current 5minute LMP nodal cost at bus (LMP<sub>t</sub>) may be obtained directly from the independent system operator (ISO) or the utility. An actual system generation cost from the energy provider or a locational marginal cost of energy from an independent system operator for a bus may be received in near realtime.
The system, however, may need forecasts of the future LMP nodal cost at bus. There may be several methods for forecasting electricity demand, where a preferred method may use a statistical modeling framework where:
LMP<sub>t</sub>=LMP nodal cost at bus at time t.
X<sub>t</sub>=Set of explanatory variables during period t for customer i.
The LMP at any point in time depends upon complex interactions of many variables including total system demand, total available generation units, system load, load on the bus, load on other buses, transmission system/capacity status and characteristics, microgrid distributed generation, power flows, and if it is a deregulated market, bidding strategies and future price expectations. Many of these variables may be difficult to obtain, particularly in near realtime. Forecasting a system generation cost may also use forecasted weather conditions, forced outage and transmission congestion inputs, generation units, forecasted system load, microgrid distributed generation forecasts, forecasted demand reductions, and/or a forecasted load at the bus. Therefore, as an approximation, a reasonable approximation may be to have the X matrix consist of variables, which may be separate, interactive, nonlinear, and/or moving average terms, such as temperature, humidity, wind speed, and indicators for time of day, day of week, and month. However, to capture the complexity of the LMP variable, these variables may be expressed single variables, lagged variables, interacted variables, as well as moving averages. In addition, a series of past LMP terms may be included as well, either as lagged terms, interactive terms, or as moving averages.
Estimation may use an autoregressive moving average (ARMA) specification. Specifically, as new LMP nodal cost at bus data is received, the system may estimate the following equation using the autoregressive moving average (ARMA(p,q)) specification:<FORM>φ(L)[(1−L)(LMP<sub>t</sub>−X<sub>t</sub>β]=θ(L)ε<sub>t</sub> (23)</FORM>Where
L<sup>j</sup>LMP<sub>t</sub>=LMP<sub>t−j </sub>
φ(L)=1−φ<sub>1</sub>L−φ<sub>2</sub>L<sub>2</sub>− . . . −φ<sub>p</sub>L<sup>p </sup>
θ(L)=1−θ<sub>1</sub>L−θ<sub>2</sub>L<sup>2</sup>− . . . −θ<sub>q</sub>L<sup>q </sup>
The parameters estimated may be Ø(p×1), θ(q×1), β, and σ<sup>2</sup>.
The output of the demand response optimization 107 may be a schedule of optimal load profiles for each controllable enduse. The optimal load profiles may be for a particular time period, such as each five minute interval, or less, for each customer that has a HAN device for the next hour during a demand response event. This schedule may be sent to the HAN vendor server 123. It may be the HAN vendor's responsibility to ensure that these signals are sent to the appropriate enduse at the appropriate location, and that their control technology can follow these dispatching signals.
Uncertainty: There may be some uncertainty with the demand response optimization 107. Since the demand response optimization 107 may be forward looking, it may require forecasting of demand and COS as discussed above. These variables may not be known with certainty. Therefore, any resulting solution of the optimization may have an associated degree of uncertainty. Therefore, this problem may be solved using stochastic optimization methods, rather than the deterministic optimization presented above.
Since this system may include both the optimization equation and the forecasting models of the demand and COS variables, a probability (mean and variance) of these variables as estimated from the customerspecific regression equations discussed above may be used. This approach may unify the forecasting and optimization analysis, and may more directly incorporate the interrelationships between weather, appliance holdings, demand, and prices than would be found by prior art of Monte Carlo sampling of the data to develop the probability distribution of the variables.
The next step in developing the stochastic specification of the problem may require defining the optimization problem. Since the demand and COS input variables are no longer single points but random variables, the resulting optimal solution is also no longer a single point, and so maximizing profit, for example, is not sufficient. Alternatives include: Markov Variation to maximize the expected profit while minimizing the variance of profits; Value at Risk (VaR) to do no worse than a set profit level (the value at risk) with a given probability, or to protect downside risk; Conditional Value at Risk (CVaR), where CVaR extends the VaR concept by minimizing the probability of the expected having a profit below the VaR; Maximize the expected profit subject to a profit floor; robust estimation, which does not use probability, and just maximizes the minimum possible outcome.
The choice between these alternatives may be dependent upon a choice of the decision makers at the utility or user, so the system may be capable of any of these formulations. However, a preferred formulation may be the CVaR specification, since this is superior to the wellknown and often used VaR approach. The CVaR specification of this optimization may be:
<maths id="MATHUS00020" num="00020"><math overflow="scroll"><mrow><mi>Min</mi><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>k</mi><mo>∈</mo><mi>N</mi></mrow></munder><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><msub><mi>p</mi><mi>k</mi></msub><mo></mo><msub><mi>v</mi><mi>k</mi></msub></mrow></mrow></mrow></math></maths><maths id="MATHUS000202" num="00020.2"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><mo>(</mo><mtable><mtr><mtd><mrow><mrow><msub><mi>R</mi><mi>ih</mi></msub><mo></mo><mrow><msub><mi>Demand</mi><mi>kijh</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow><mo></mo></mrow></mtd></mtr><mtr><mtd><mrow><mo>(</mo><mtable><mtr><mtd><mrow><mrow><msub><mi>I</mi><mi>ijh</mi></msub><mo></mo><msub><mi>Demand</mi><mi>kijh</mi></msub><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>+</mo></mrow></mtd></mtr><mtr><mtd><mrow><msub><mi>COS</mi><mi>kijh</mi></msub><mo></mo><mrow><msub><mi>Demand</mi><mi>kijh</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></mtd></mtr></mtable><mo>)</mo></mrow></mtd></mtr></mtable><mo>)</mo></mrow></mrow></mrow></mrow><mo>=</mo><msub><mi>r</mi><mi>k</mi></msub></mrow></mtd><mtd><mrow><mi>k</mi><mo>∈</mo><mi>N</mi></mrow></mtd></mtr><mtr><mtd><mrow><mrow><msub><mi>v</mi><mn>0</mn></msub><mo></mo><msub><mi>r</mi><mi>k</mi></msub></mrow><mo>≤</mo><msub><mi>v</mi><mi>k</mi></msub></mrow></mtd><mtd><mrow><mi>k</mi><mo>∈</mo><mi>N</mi></mrow></mtd></mtr><mtr><mtd><mrow><msub><mi>v</mi><mi>k</mi></msub><mo>≥</mo><mn>0</mn></mrow></mtd><mtd><mrow><mi>k</mi><mo>∈</mo><mi>N</mi></mrow></mtd></mtr><mtr><mtd><mrow><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow><mo>≤</mo><msub><mi>Hours</mi><mi>ij</mi></msub></mrow></mtd><mtd><mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mn>0</mn><mo>≤</mo><msub><mi>X</mi><mi>ijh</mi></msub><mo>≤</mo><msub><mi>UB</mi><mi>ijh</mi></msub></mrow></mtd><mtd><mrow><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><msub><mi>Demand</mi><mi>kijh</mi></msub><mo></mo><msub><mi>X</mi><mi>ijh</mi></msub></mrow></mrow></mrow><mo>=</mo><msub><mi>Reduction</mi><mi>h</mi></msub></mrow></mtd><mtd><mrow><mrow><mi>k</mi><mo>∈</mo><mi>N</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></mtd></mtr></mtable></math></maths>
The additional Stochastic parameters may be:
 p<sub>k</sub>=the probability of scenario k (based on the joint distribution of COS<sub>kih </sub>and Demand<sub>kijh</sub>).
 COS<sub>kih</sub>=the cost to serve electricity to customer i in hour h in scenario k (from the estimated forecast model).
 Demand<sub>kijh</sub>=the demand for energy for customer i, hour h, appliance j in scenario k (from the estimated forecast model).
 v<sub>0</sub>=the conditional value at risk (determined by the enduser).
Additional Stochastic Variables:
v<sub>k</sub>=the return under scenario k.
FIG. 9 is a graph and table showing dispatching with hour constraints when accounting for uncertainty. As shown in FIG. 9, forward market price, capacity need and weather uncertainties may increase the complexity and value that can be derived from the system. A suboptimal scenario shows the utility releasing the demand response resource too early in the week in response to high temps. An optimal scenario requires waiting based on load forecast probability estimates, short term weather forecast, and preset customer comfort and price constraints. Optimal dispatch for the week may require waiting a day or more to preserve option value for later in the week.
A stochastic optimization approach such as the one above may be used to optimally allocate the capacity, swing and shaping premiums over peak hours given the uncertainty over future weather conditions. This may be accomplished by adding an additional constraint into the model that assigns a customerspecific premium allocation over a given period, the sum of which equals the required premium required by the utility. The demand forecasting may incorporate both weather conditions as well as price responses (elasticity), and the COS may also incorporate weather conditions, so the resulting forward looking premium allocations from this approach may capture the uncertainty of weather as well as the interactions between price and demand.
This approach may also be used to optimally allocate the ancillary service management under uncertain demand conditions. In general, if demand has low volatility (hence a low degree of error in the demand forecast), then the optimal solution to the stochastic optimization problem may also have a low level of uncertainty. Under the CVaR approach, this implies that the value at risk is low, so from the ancillary services perspective, the optimal management of the demand resources may be well defined. In other words, the dispatching signals have little uncertainty associated with them, and there is no need to defer or delay signals. Conversely, if demand is very volatile (hence the forecast is likely to have a large error term), then the solution to the stochastic optimization may also have a large degree of uncertainty. From the CVaR perspective, this would imply a large value of risk. For ancillary services perspective, this large value at risk may result in a situation where it may be better to delay the signals so that more information is obtained, which would lower the uncertainty and thus lower the CVaR, which would in turn lower the resources that are available at the 5 minute level.
Demand Response Optimization (Load Leveling)
In the previous demand response optimization 109 scenario, the utility decreased system peak demand by actually forcing customers to reducing their consumption, i.e., curtailment. With load leveling, it may be possible to reduce demand (kW) by coordinating customers so that all appliances do not start at the same time. To ensure that the utility does not lose revenue, which is determine by kWh, and the customers do not sacrifice comfort, also determined by kWh, a constraint may be that the total kWh for each hour is constant.
An objective of the load leveling optimization may be to minimize the utility's total peak kW, over a 5minute or other length period, during an hour while keeping total kWh constant for each customer.
Mathematically, the problem may require a decision variable:
X<sub>ijt</sub>=1 if the appliance can run in period t, for customer i appliance j, 0 if not.
Data may include:
 Demand<sub>ij</sub>=the forecast demand for energy for customer I, appliance j
 RP<sub>j</sub>=the real power of appliance j (assumed for simplicity to be constant over time, but it can vary over time)
Thus, the optimization may be:
<maths id="MATHUS00021" num="00021"><math overflow="scroll"><mrow><mi>Min</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>P</mi></mrow></math></maths><maths id="MATHUS000212" num="00021.2"><math overflow="scroll"><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mtable><mtr><mtd><mrow><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijt</mi></msub><mo>·</mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow><mo>=</mo><msub><mi>Demand</mi><mi>ij</mi></msub></mrow></mtd><mtd><mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mi>P</mi><mo>≥</mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijt</mi></msub><mo>·</mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow></mrow></mtd><mtd><mrow><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></mrow></mtd></mtr></mtable></mrow></math></maths>
In this specification, P may be the peak demand for the hour. This specification can readily be extended for more than multiple hours (H) by relaxing the demand constraint. Specifically, since water heaters generally keep water temperature even without regular electricity use, the demand constraint can be relaxed by having the just the total kWh for water heating being meet across all the hours of interest, while the HVAC kWh must be meet for each hour of interest. Specifically:
<maths id="MATHUS00022" num="00022"><math overflow="scroll"><mrow><mi>Min</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>P</mi></mrow></math></maths><maths id="MATHUS000222" num="00022.2"><math overflow="scroll"><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mtable><mtr><mtd><mrow><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow><mo>=</mo><msub><mi>Demand</mi><mi>ijh</mi></msub></mrow></mtd><mtd><mrow><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>HVAC</mi></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><msub><mi>Demand</mi><mi>ijh</mi></msub></mrow></mrow></mtd><mtd><mrow><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mrow><mi>J</mi><mo>≠</mo><mi>HVAC</mi></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mi>P</mi><mo>≥</mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow></mrow></mtd><mtd><mrow><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></mtd></mtr></mtable></mrow></math></maths>
In this specification, P is the peak demand for all hours in H.
The end result of the load leveling optimization may be that kW is equal or approximately equal during all t periods. Thus, the peak load may become “levelized”.
FIG. 10 and Table 2 show an example of load leveling optimization for a single hour assuming a single enduse (AC). These results show that the kWh for each of the 24 customers is unchanged, and the peak demand is reduced from a maximum of 70 kW to 53.5 kW (a savings of over 23%). Notice that the peak kW is levelized, and is equal to the average of the unlevelized kW over the period.
<tables id="TABLEUS00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="91pt" align="left"/><colspec colname="1" colwidth="98pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><thead><row><entry/><entry namest="offset" nameend="2" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry/><entry namest="offset" nameend="2" align="center" rowsep="1"/></row><row><entry/><entry>kWh</entry><entry/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="91pt" align="left"/><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="98pt" align="center"/><tbody valign="top"><row><entry/><entry>Original</entry><entry>Levelized</entry></row><row><entry/><entry namest="offset" nameend="2" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="28pt" align="left"/><colspec colname="1" colwidth="63pt" align="left"/><colspec colname="2" colwidth="28pt" align="char" char="."/><colspec colname="3" colwidth="98pt" align="char" char="."/><tbody valign="top"><row><entry/><entry>Cust1</entry><entry>59.5</entry><entry>59.5</entry></row><row><entry/><entry>Cust2</entry><entry>199.5</entry><entry>199.5</entry></row><row><entry/><entry>Cust3</entry><entry>140</entry><entry>140</entry></row><row><entry/><entry>Cust4</entry><entry>91</entry><entry>91</entry></row><row><entry/><entry>Cust5</entry><entry>87.5</entry><entry>87.5</entry></row><row><entry/><entry>Cust6</entry><entry>168</entry><entry>168</entry></row><row><entry/><entry>Cust7</entry><entry>91</entry><entry>91</entry></row><row><entry/><entry>Cust8</entry><entry>105</entry><entry>105</entry></row><row><entry/><entry>Cust9</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Cust10</entry><entry>206.5</entry><entry>206.5</entry></row><row><entry/><entry>Cust11</entry><entry>182</entry><entry>182</entry></row><row><entry/><entry>Cust12</entry><entry>665</entry><entry>66.5</entry></row><row><entry/><entry>Cust13</entry><entry>101.5</entry><entry>101.5</entry></row><row><entry/><entry>Cust14</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Cust15</entry><entry>157.5</entry><entry>157.5</entry></row><row><entry/><entry>Cust16</entry><entry>52.5</entry><entry>52.5</entry></row><row><entry/><entry>Cust17</entry><entry>112</entry><entry>112</entry></row><row><entry/><entry>Cust18</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Cust19</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Cust20</entry><entry>35</entry><entry>35</entry></row><row><entry/><entry>Cust21</entry><entry>154</entry><entry>154</entry></row><row><entry/><entry>Cust22</entry><entry>143.5</entry><entry>143.5</entry></row><row><entry/><entry>Cust23</entry><entry>77</entry><entry>77</entry></row><row><entry/><entry>Cust24</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry namest="offset" nameend="3" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
Finally, the load leveling optimization may also be extended to account for consumption of households that do not have the home area network (HAN) technology. When it is possible to develop forecasts of the total household electricity use of the nonHAN households from data collected by smart meters, for example, then it may be possible to use the HAN equipped households to levelize total demand for both HAN and nonHAN households by changing the optimization equations. The new optimization may become:
<maths id="MATHUS00023" num="00023"><math overflow="scroll"><mrow><mi>Min</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex"/></mstyle><mo></mo><mi>P</mi></mrow></math></maths><maths id="MATHUS000232" num="00023.2"><math overflow="scroll"><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="8.6em" height="8.6ex"/></mstyle><mo></mo><mi>i</mi></mrow><mo>∈</mo><mi>I</mi></mrow></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>HVAC</mi></mrow></mrow></math></maths><maths id="MATHUS000233" num="00023.3"><math overflow="scroll"><mrow><mrow><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="7.5em" height="7.5ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mrow><mi>J</mi><mo>≠</mo><mi>HVAC</mi></mrow></mrow></mrow></math></maths><maths id="MATHUS000234" num="00023.4"><math overflow="scroll"><mrow><mrow><mrow><mi>P</mi><mo>≥</mo><mrow><mrow><munder><mo>∑</mo><mrow><mi>n</mi><mo>∈</mo><mi>N</mi></mrow></munder><mo></mo><msub><mi>NDemand</mi><mi>nh</mi></msub></mrow><mo>+</mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo></mo><msub><mi>RP</mi><mi>j</mi></msub><mo></mo><mstyle><mspace width="8.1em" height="8.1ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></math></maths>
Where NDemand<sub>nh </sub>is the demand for the nonHAN customer n in hour h (this term can also be used to capture nondispatchable enduses at HAN premises).
FIG. 11A and FIG. 11B show an example of the load leveling optimization for a single hour using the same data in the previous example but now adding 24 nonHAN households, also with a singleend use. These results show that the kWh for each of the 24 HAN customers is unchanged, and the peak demand is reduced from a maximum of 122 kW to 95 kW (a savings of over 22%). Table 3 shows the results of this optimization.
<tables id="TABLEUS00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="42pt" align="left"/><colspec colname="2" colwidth="70pt" align="center"/><colspec colname="3" colwidth="35pt" align="left"/><colspec colname="4" colwidth="70pt" align="center"/><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="4" align="center" rowsep="1"/></row><row><entry>HAN</entry><entry>kWh</entry><entry>NonHAN</entry><entry>kWh</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="42pt" align="left"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="42pt" align="center"/><colspec colname="4" colwidth="35pt" align="left"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="35pt" align="center"/><tbody valign="top"><row><entry>Customers</entry><entry>Original</entry><entry>Levelized</entry><entry>Customers</entry><entry>Original</entry><entry>Levelized</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="42pt" align="left"/><colspec colname="2" colwidth="28pt" align="char" char="."/><colspec colname="3" colwidth="42pt" align="char" char="."/><colspec colname="4" colwidth="35pt" align="left"/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="35pt" align="char" char="."/><tbody valign="top"><row><entry>Cust1</entry><entry>59.5</entry><entry>59.5</entry><entry>Cust1</entry><entry>105</entry><entry>105</entry></row><row><entry>Cust2</entry><entry>199.5</entry><entry>199.5</entry><entry>Cust2</entry><entry>101.5</entry><entry>101.5</entry></row><row><entry>Cust3</entry><entry>140</entry><entry>140</entry><entry>Cust3</entry><entry>101.5</entry><entry>101.5</entry></row><row><entry>Cust4</entry><entry>91</entry><entry>91</entry><entry>Cust4</entry><entry>122.5</entry><entry>122.5</entry></row><row><entry>Cust5</entry><entry>87.5</entry><entry>87.5</entry><entry>Cust5</entry><entry>115.5</entry><entry>115.5</entry></row><row><entry>Cust6</entry><entry>168</entry><entry>168</entry><entry>Cust6</entry><entry>129.5</entry><entry>129.5</entry></row><row><entry>Cust7</entry><entry>91</entry><entry>91</entry><entry>Cust7</entry><entry>115.5</entry><entry>115.5</entry></row><row><entry>Cust8</entry><entry>105</entry><entry>105</entry><entry>Cust8</entry><entry>126</entry><entry>126</entry></row><row><entry>Cust9</entry><entry>196</entry><entry>196</entry><entry>Cust9</entry><entry>105</entry><entry>105</entry></row><row><entry>Cust10</entry><entry>206.5</entry><entry>206.5</entry><entry>Cust10</entry><entry>87.5</entry><entry>87.5</entry></row><row><entry>Cust11</entry><entry>182</entry><entry>182</entry><entry>Cust11</entry><entry>91</entry><entry>91</entry></row><row><entry>Cust12</entry><entry>66.5</entry><entry>66.5</entry><entry>Cust12</entry><entry>112</entry><entry>112</entry></row><row><entry>Cust13</entry><entry>101.5</entry><entry>101.5</entry><entry>Cust13</entry><entry>91</entry><entry>91</entry></row><row><entry>Cust14</entry><entry>196</entry><entry>196</entry><entry>Cust14</entry><entry>112</entry><entry>112</entry></row><row><entry>Cust15</entry><entry>157.5</entry><entry>157.5</entry><entry>Cust15</entry><entry>98</entry><entry>98</entry></row><row><entry>Cust16</entry><entry>52.5</entry><entry>52.5</entry><entry>Cust16</entry><entry>98</entry><entry>98</entry></row><row><entry>Cust17</entry><entry>112</entry><entry>112</entry><entry>Cust17</entry><entry>80.5</entry><entry>80.5</entry></row><row><entry>Cust18</entry><entry>196</entry><entry>196</entry><entry>Cust18</entry><entry>105</entry><entry>105</entry></row><row><entry>Cust19</entry><entry>196</entry><entry>196</entry><entry>Cust19</entry><entry>122.5</entry><entry>122.5</entry></row><row><entry>Cust20</entry><entry>35</entry><entry>35</entry><entry>Cust20</entry><entry>87.5</entry><entry>87.5</entry></row><row><entry>Cust21</entry><entry>154</entry><entry>154</entry><entry>Cust21</entry><entry>80.5</entry><entry>80.5</entry></row><row><entry>Cust22</entry><entry>143.5</entry><entry>143.5</entry><entry>Cust22</entry><entry>112</entry><entry>112</entry></row><row><entry>Cust23</entry><entry>77</entry><entry>77</entry><entry>Cust23</entry><entry>119</entry><entry>119</entry></row><row><entry>Cust24</entry><entry>196</entry><entry>196</entry><entry>Cust24</entry><entry>84</entry><entry>84</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
The load leveling optimization may have several input variables. As discussed above for the curtailment optimization, the load leveling optimization uses both known and forecast variables.
Known inputs may include: (1) whether a customer has agreed to participate; (2) real power of the enduses; (3) technology constraints; (4) forecast inputs; (5) cost of service; (6) demand by enduse; (7) voltage/power factor; (8) total premise load; and/or (9) weather forecasts. Note that this load leveling optimization does not include prices.
Since the load leveling optimization does not affect the customers total energy usage, this optimization may not involve incentives, reduction targets, or other types of data commonly found in a typical demand response program. Essentially, the only inputs that may be known when the load leveling optimization is run include (1) whether a customer has agreed to participate, and (2) the real power of the enduses, which may be measured either at the time of installation of the HAN or by sensors associated with the HAN system.
Two sets of forecast inputs into the load leveling optimization may include: (1) demand for dispatchable enduses, and (2) forecasts of total premise load for HAN and nonHAN facilities.
Demand for Dispatchable EndUses: The load leveling optimization may forecast electricity demand for participating dispatchable enduses at each customer's house as described above for forecasting electricity demand.
Demand for NonDispatchable EndUses: For nonHAN households, the total premise usage may be forecast using the same statistical procedure for dispatchable enduses, where the dependent variable may be the 5 minute premise level total energy use collected from smart meters, and the independent variables may include such terms as the temperature, humidity, time of day, day of week, and month. If the rate is timedifferentiated, then X would include terms to capture the price elasticity effects of the changing rate.
If there is a significant component of the HAN households that contribute to peak demand that is not dispatchable, then it may be necessary to explicitly incorporate these enduses in this optimization through an N Demand term. Rather than trying to compute the nondispatchable demand directly though each individual enduse, the system may compute the nondispatchable demand by developing a total electricity demand for the household and then subtract the forecasts of the dispatchable enduses discussed above. The difference may be assumed to be the nondispatchable household load. Since the total household electricity demand may be composed of a wide variety of different enduses, many of which are unknown, the model for forecasting the load may include weather and nonweather terms. In general, the procedure may be identical to the procedure used for the dispatchable enduses and may use the same statistical framework.
Demand Response Optimization (RealTime Curtailment)
It may be possible to combine the two demand response optimizations described above and dispatch customers in real or nearreal time 111. Realtime curtailment may utilize a real or nearreal time cost to serve the customers by moving consumption to less expensive periods, such that over the entire time period energy use (kWh) is constant. Thus, the utility may gain a significant amount of avoided cost, yet the customer may not have any change in comfort or total usage of the enduse.
An objective of realtime curtailment may be to minimize the utility's total peak kW (over a 5minute period) during an hour while keeping total kWh constant for each customer. Mathematically, the problem may use a decision variable:
X<sub>ijth</sub>=1 if customer i appliance j can run in period t in hour h, 0 if not.
The realtime curtailment may also use data:
 COS<sub>ith</sub>=the forecast cost to serve electricity to customer i in period t, hour h
 R<sub>ih</sub>=cost per hour charged to customer i during hour h (the rate, it can also be a flat rate, which does not vary over time)
 RP<sub>j</sub>=the real power of appliance j (assumed for simplicity to be constant over time, but it can vary over time)
 Demand<sub>ijh</sub>=the forecast demand for energy for customer i, appliance j during period t, hour h.
The realtime dispatching problem may be used to maximize revenue, and, thus, maximize avoided cost:
<maths id="MATHUS00024" num="00024"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><mo>(</mo><mrow><msub><mi>R</mi><mi>ih</mi></msub><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><msub><mi>COS</mi><mi>ith</mi></msub><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><mo>(</mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo>·</mo><msub><mi>RP</mi><mi>j</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow></math></maths><maths id="MATHUS000242" num="00024.2"><math overflow="scroll"><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>ijth</mi></msub><mo>·</mo><msub><mi>RP</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><mrow><msub><mi>Demand</mi><mi>ijh</mi></msub><mo></mo><mstyle><mspace width="8.6em" height="8.6ex"/></mstyle><mo></mo><mi>i</mi></mrow><mo>∈</mo><mi>I</mi></mrow></mrow><mo>,</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></math></maths>
To capture ancillary service value, which must be available at the 10 minute or finer level, the t interval in the optimization in the system may be set to 5minutes. Any longer time period may significantly diminish the value of any demand or cost reduction from dispatching resources.
A concept in realtime curtailment may be to dispatch customers at a 5minute level so most of the energy consumption occurs at the lower costtoserve periods and little energy is used during the higher costtoserve periods. However, the total energy use for each hour for each appliance and each customer may be held constant, so that the customers do not have to sacrifice any comfort for the utility to achieve these least cost solution.
As specified above, the optimization does not incorporate any constraints regarding the peak (kW) demand. It is possible that the intrahour shifting would result in very high kW usage during low costofservice periods. There are several ways methods that may avoid this issue including incorporating a specific peak demand constraint or incorporating costs that increase with increasing kW to capture capacitor, circuit upgrade, and substation addition costs.
FIG. 12A and FIG. 12B show an example of realtime curtailment for a single hour assuming a single enduse (AC) and a single costofservice (COS) for all customers. FIG. 12A shows the resulting solution of realtime dispatching relative to original demand, and FIG. 12B shows the original and the optimal solution relative to the COS, showing how the optimal demand is reduced during the high COS periods and increased during the low COS periods. Table 4 shows how the total kWh is unchanged for each customer as well as showing the decrease in total COS in this example, a 38% reduction.
<tables id="TABLEUS00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="91pt" align="left"/><colspec colname="1" colwidth="105pt" align="center"/><colspec colname="2" colwidth="21pt" align="center"/><thead><row><entry/><entry namest="offset" nameend="2" rowsep="1">TABLE 4</entry></row></thead><tbody valign="top"><row><entry/><entry namest="offset" nameend="2" align="center" rowsep="1"/></row><row><entry/><entry>kWh</entry><entry/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="91pt" align="left"/><colspec colname="1" colwidth="42pt" align="center"/><colspec colname="2" colwidth="84pt" align="center"/><tbody valign="top"><row><entry/><entry>Original</entry><entry>Levelized</entry></row><row><entry/><entry namest="offset" nameend="2" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="21pt" align="left"/><colspec colname="1" colwidth="70pt" align="left"/><colspec colname="2" colwidth="42pt" align="char" char="."/><colspec colname="3" colwidth="84pt" align="char" char="."/><tbody valign="top"><row><entry/><entry>Customer 1</entry><entry>59.5</entry><entry>59.5</entry></row><row><entry/><entry>Customer 2</entry><entry>199.5</entry><entry>199.5</entry></row><row><entry/><entry>Customer 3</entry><entry>140</entry><entry>140</entry></row><row><entry/><entry>Customer 4</entry><entry>91</entry><entry>91</entry></row><row><entry/><entry>Customer 5</entry><entry>87.5</entry><entry>87.5</entry></row><row><entry/><entry>Customer 6</entry><entry>168</entry><entry>168</entry></row><row><entry/><entry>Customer 7</entry><entry>91</entry><entry>91</entry></row><row><entry/><entry>Customer 8</entry><entry>105</entry><entry>105</entry></row><row><entry/><entry>Customer 9</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Customer 10</entry><entry>206.5</entry><entry>206.5</entry></row><row><entry/><entry>Customer 11</entry><entry>182</entry><entry>182</entry></row><row><entry/><entry>Customer 12</entry><entry>66.5</entry><entry>66.5</entry></row><row><entry/><entry>Customer 13</entry><entry>101.5</entry><entry>101.5</entry></row><row><entry/><entry>Customer 14</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Customer 15</entry><entry>157.5</entry><entry>157.5</entry></row><row><entry/><entry>Customer 16</entry><entry>52.5</entry><entry>52.5</entry></row><row><entry/><entry>Customer 17</entry><entry>112</entry><entry>112</entry></row><row><entry/><entry>Customer 18</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Customer 19</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Customer 20</entry><entry>35</entry><entry>35</entry></row><row><entry/><entry>Customer 21</entry><entry>154</entry><entry>154</entry></row><row><entry/><entry>Customer 22</entry><entry>143.5</entry><entry>143.5</entry></row><row><entry/><entry>Customer 23</entry><entry>77</entry><entry>77</entry></row><row><entry/><entry>Customer 24</entry><entry>196</entry><entry>196</entry></row><row><entry/><entry>Total COS</entry><entry>$1,994</entry><entry>$1,311</entry></row><row><entry/><entry namest="offset" nameend="3" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
The processing of known and forecasted inputs is similar to those discussed above for curtailment and load leveling. Voltage forecasts and uncertainty may also be similar to that discussed above for curtailment and load leveling.
Bill Target Optimization
The bill target optimization 113 may allow individual customers to set electric bills going forward over a period. In exchange for a set bill, the individual customers may allow the utility to control appliances to achieve the bill target amount at the end of the period.
The bill target optimization 113 may dispatch a customer's major appliances, based upon a schedule supplied by the customer, to reach this bill level for the period. At the same time, the bill target optimization 113 may apply dispatching and control strategies to optimize and/or improve utility margins or revenues. By controlling appliance end use, subject to preset conditions and profiles permitted by the customer, the system may take load reductions during a higher marginal cost time period, or differentially more from higher cost regions. This system may also increase cost savings or margin for the utility because it allows the utility to minimize electricity use during high COS periods or within higher COS regions. FIG. 13 shows an example monthly bill under a bill target optimization 113 where the system dispatching solutions are established for various bill settings.
As discussed, utilities are a unique industry in that there is no existing inventory buffer. As a result, there may be certain hours where there are volatile costs of supply and inelastic demand. The system may create an inventory buffer using demand reductions and choreographing the operations of end use loads, as needed by utilities to meet necessary supply, but at the same time meeting customer needs and constraints regarding their preference, profile settings and preestablished criteria.
In the bill target optimization 113, an objective may be to minimize the utility's total peak kW (over a 5minute period) during an hour while keeping total kWh constant for each customer. Mathematically, the problem may include a decision variable:
X<sub>jth</sub>=1 if the customer's appliance j can run in period t in hour h, 0 if not.
The problem may also include the following data:
 COS<sub>th</sub>=the forecast cost to serve electricity to the customer in period t during hour h
 R<sub>th</sub>=cost per hour charged to the customer during period t of hour h (the rate, which can also be a flat rate, i.e., does not vary over time)
 NonDisp<sub>th</sub>=the total nondispatchable energy demand for the customer during period t of hour h.
 Demand<sub>jth</sub>=the forecast demand for energy the customer, dispatchable appliance j during period t of hour h.
 Bill Target=the customer's targeted Bill (for the month or week).
The bill targeting problem may maximize the revenue (thus maximize avoided cost) subject to meeting the customer's bill target:
<maths id="MATHUS00025" num="00025"><math overflow="scroll"><mrow><mi>Max</mi><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><mrow><mo>(</mo><mrow><msub><mi>R</mi><mi>ht</mi></msub><mo></mo><msub><mi>COS</mi><mi>ht</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><mrow><mo>(</mo><mrow><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><mo>(</mo><mrow><msub><mi>Demand</mi><mi>jth</mi></msub><mo>·</mo><msub><mi>X</mi><mi>jth</mi></msub></mrow><mo>)</mo></mrow></mrow><mo>+</mo><msub><mi>NonDisp</mi><mi>th</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths><maths id="MATHUS000252" num="00025.2"><math overflow="scroll"><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><mrow><mo>(</mo><mrow><mrow><mo>(</mo><mrow><munder><mo>∑</mo><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow></munder><mo></mo><mrow><msub><mi>X</mi><mi>jth</mi></msub><mo>·</mo><msub><mi>Demand</mi><mi>jth</mi></msub></mrow></mrow><mo>)</mo></mrow><mo>+</mo><msub><mi>NDisp</mi><mi>th</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><msub><mi>R</mi><mi>th</mi></msub></mrow></mrow></mrow></mrow><mo>=</mo><mrow><mi>Bill</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex"/></mstyle><mo></mo><mi>Target</mi></mrow></mrow></math></maths><maths id="MATHUS000253" num="00025.3"><math overflow="scroll"><mtable><mtr><mtd><mrow><mn>0</mn><mo>≤</mo><msub><mi>X</mi><mi>jth</mi></msub><mo>≤</mo><msub><mi>UB</mi><mi>jth</mi></msub></mrow></mtd><mtd><mrow><mstyle><mspace width="9.2em" height="9.2ex"/></mstyle><mo></mo><mrow><mrow><mi>j</mi><mo>∈</mo><mi>J</mi></mrow><mo>,</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow><mo>,</mo><mrow><mi>h</mi><mo>∈</mo><mi>H</mi></mrow></mrow></mrow></mtd></mtr></mtable></math></maths>
As before, to capture ancillary service value, which must be available at the minute or finer level, the t interval in the optimization in the system may be set to 5minutes, or less. Any longer time period may significantly diminish the value of the any demand or cost reduction from dispatching resources.
The fundamental concept in this optimization may be to dispatch customers at the 5minute level, or less, so that most of the energy consumption occurs at the lower costtoserve periods and very little energy is used during the higher costtoserve periods. However, the total energy use for each hour for each appliance and each customer may be held constant, so that the customers do not have to sacrifice any comfort for the utility to achieve these least cost solution.
As specified above, the bill target optimization 113 may not incorporate any constraints regarding the peak (kW) demand. It is possible that the intrahour shifting may result in very high kW usage during low costofservice periods. There are several ways methods that may avoid this, including incorporating a specific peak demand constraint or incorporating costs that increase with increasing kW to capture capacitor, circuit upgrade, and substation addition costs.
The processing of known and forecasted inputs is similar to those discussed above for curtailment and load leveling. Voltage forecasts and uncertainty may also be similar to that discussed above for curtailment and load leveling.
Managing Distributed Storage and Distributed Generation
A renewable generation optimization 115 may have the ability to manage distributed, micro level supply resources in conjunction with demand reductions or enduse choreography.
Generally, the operating characteristics of distributed resources are significantly different from other supply resources. For example, distributed resources, which are primarily installed for shortterm supplemental reasons, can also be used to take advantage of market pricing and cost opportunities, known as arbitrage. Taking advantage of these arbitrage opportunities can add significant revenue, cost savings or margin to the utility from a resource that may otherwise remain unused and idle.
FIG. 14A and FIG. 14B show an exemplary dispatch of solar and storage by arbitraging market prices. As shown in FIGS. 14A14B, forward market price, capacity need and weather uncertainties increase the complexity and value that can be derived from the system. An optimal dispatch for the week may require waiting a day or two to preserve option value for later in the week.
The system may have the capability to use stochastic optimization through the use of a conditional value at risk approach. In this methodology, a new parameter is introduced within the model, the conditional value at risk. The conditional value at risk may be evaluated as a function of uncertainty produced by the forecasts of the demand of the enduse in question (obtained directly from an estimated regression equation), and the forecast of the energy prices (also obtained directly from the estimated regression equation). By incorporating these parameters into the optimization, uncertainty about future conditions may be explicitly incorporated in the problem, as are risk preferences of the utility.
Electric Vehicle Smart Charging and Discharging
Electric vehicle smart charging and discharging may be part of the renewable generation optimization 115, other optimizations or a standalone optimization.
Significant joint planning between car manufacturers and utilities is currently underway. This joint planning may lead to new supply and revenue resources for utilities. Both electric vehicles (EVs) and plugin hybrid electric vehicles (PHEVs) may be chargeable and dispatchable within normal dispatching solutions.
For discharging, the system may treat the battery as it would a power storage device. Therefore, the battery may draw a minimum amount of KW for a given time period, conditioned on the other factors and resources available to it along a given circuit or system, and subject to preset constraints or conditions placed on the system.
For recharging, the system may enable the smart charging of PHEV batteries in the same way that end use load are choreographed, scheduled and operated along a circuit or system. If there were a large population of PHEVs recharging in any one hour, or span of hours, the simultaneous recharging might strain a utility's resources, particularly if charging demands occur during existing peak system load hours. In response, the system may calculate optimal charging patterns for the vehicles participating on a circuit or system, subject to the peak load objectives on that circuit, the end use loads available for dispatching or control, and other distributed resources. Subject to preset conditions by the vehicle owner, including minimum charge levels, pricing incentives or offers, time of day charging constraints or other constraints established for that customer, the system may establish a smart charging pattern for the participating vehicles on a circuit or system, to achieve the overall goals to be achieved on that circuit.
The system's approach to minimizing the PHEV risk and value to utilities may be enhanced by having appliance control and/or HAN boxes along the circuit. Having both together, further supported by solar water heat or storage, may enable an optimization system to rely less on PHEV constraints alone, but rather on the joint dispatch of all distributed resources available on that circuit. However, there is no natural dutycycle to PHEV charging, so the system may impose a preferred dutycycle onto the battery that fits a customer's needs and cost or charging preferences, and which is optimally integrated with the other end use duty cycles observed along the same circuit. Different PHEV owners may receive different imposed duty cycle smart charging strategies, depending upon the availability and operation of the distributed resources, other PHEVs and other end uses operating or being dispatched on the circuit for a given hour. Furthermore, the imposed smart charging duty cycle for a given PHEV might be revised in subsequent hours, as conditions change along the circuit or new peak reduction or avoided cost goals are specified by the user.
FIG. 15A and FIG. 15B show exemplary optimal dispatching strategies with optimization and without. In FIGS. 15A15B, the system's optimal dispatching solution is graphed for 12 PHEVs, 3 with 120V 15 A chargers and 9 with 220V 20 A charges. The graphs depict a simple example where all customers come home and plug in at 6 p.m. and all batteries need a full charge. Left alone, these batteries may cause a peak of 50 kW versus charging over more hours to 21 kW (delta 40%).
FIGS. 16A and 16B show exemplary charging patterns of one battery versus three batteries. Note that temperature/efficiency of charge is ignored here, but normally constrain the system's short run, spiked charging which is generally inefficient for battery charging. The system specifies constraints to allow a minimum charge time to ensure adequate temperatures.
Renewable Generation
The renewable generation optimization 115 may allow both adding and removing of electricity. A renewable generation optimization 115 may apply to stand alone batteries and/or batteries in a PHEV. Distributed storage may also allow for distributed generation.
There may be different basic optimizations contained in the renewable generation optimization 115.
Model 1. The first basic optimization may not involve the HAN at the customer location, and may minimize volatility associated with renewable generation resources, specifically wind and photovoltaic (PV). For both wind and PV, the output from a generation unit may be variable depending on natural conditions. For wind units, wind does not blow constantly, and so over time, the generation (kW) coming out of a wind generation unit may vary. The same is true for a PV unit, as clouds pass overhead and cover the sun, the amount of electricity generated by the PV system may be reduced. The extent of this volatility varies depending upon the part of the country. In California and Arizona, for example, there is very little cloud cover during the day, so the PV generation curve looks like a standard bell curve. However, for other parts of the country, clouds are constantly passed by, making it difficult to know how much power will be available from the PV system. FIG. 17 is a graph of an exemplary day for a PV system in North Carolina.
If there is a large percentage of such volatile generation in a utility system, it may make longterm planning difficult, and lead to overinvestment in capital or require the utility to buy power from the market to cover an unforeseen falloff in power. The system can minimize this volatility by coordinating renewable power with batteries so that the output from the system may be a constant amount of power, independent from the amount of power produced at even given point in time by wind or PV.
Within the renewable generation optimization 115, the optimization problem may be:
Max PVBatt
s.t.<FORM>PVBatt≦PVOut<sub>t</sub>+BattOut<sub>t </sub>tεT </FORM><FORM>PVOut<sub>t</sub>=PVGen<sub>t</sub>−PVIn<sub>t </sub>tεT </FORM><FORM>BattLvl<sub>t+1</sub>=BattLvl<sub>t</sub>+PVIn<sub>t</sub>−BattOut<sub>t </sub>tεT </FORM><FORM>BattLvl<sub>t=0</sub>=K</FORM><FORM>BattCap≧BattLvl<sub>t </sub>tεT</FORM>
Where:
 PVBatt is the power output of the PV (or wind) and battery (or any distributed storage) system.
 PVOut<sub>t </sub>is the power from the PV that is sent out to the Grid at time t.
 PVIn<sub>t </sub>is the power from the PV that is sent out to the Battery for storage at time t.
 PVGen<sub>t </sub>is the power generation from the PV at time t (exogenous).
 BattLvl<sub>t </sub>is the storage level of the Battery (i.e., the amount of stored power) at time t.
 BattOut<sub>t </sub>is the power from the Battery that is sent out to the Grid at time t.
 BattLvl<sub>t=0 </sub>is the initial storage level of the Battery.
 BattCap is the capacity of the Battery (based on the characteristics of the battery).
FIGS. 18A and 18B show an exemplary generation profile for PV. Using the generation profile of PV, and an initial battery level (K) of 100, and a nonbinding battery capacity of 1,000, the renewable generation optimization 115 may produce a levelized output over time of 3.27 kW. FIG. 18A shows the associated battery level and FIG. 18B shows the output.
To employ the renewable generation optimization 115, a reasonable estimate of the shape of the PV or wind generation profile over time (PVGEN<sub>t</sub>) may be required. A preferred approach, using a comparison of mean squared forecast error, may be an autoregressive moving average model (ARMA) using 5 minute data. Thus, in implementing the renewable generation optimization 115, the forecasting of the PVGEN term over time may be conducted using a multivariate ARMA(1,2) or ARMAX model. FIG. 19 shows an exemplary use of an ARMA model.
The algebraic specification of the ARMAX(1,2) model for PV generation may be:<FORM>y<sub>t</sub>=α<sub>1</sub>y<sub>t−1</sub>+β<sub>0</sub>x<sub>t</sub>+β<sub>1</sub>x<sub>t−1</sub>+ε<sub>t</sub>−θ<sub>1</sub>ε<sub>t−1</sub>−θ<sub>2</sub>ε<sub>t−2</sub> (24)</FORM>
To effectively predict generation of a PV or wind unit, the t in the forecast equation must be very small, on the order of 5minutes or less. The independent or exogenous variables in the ARMAX model are generally weather conditions such as temperature, wind speed, and cloud cover from areas “up wind” from the PV unit. Note that results of the renewable generation optimization 115 may vary depending upon the initial storage in the battery. In the above solution of FIG. 18A and FIG. 18B, an initial level of 100 kWh was assumed. If this assumption is changed to 500 kWh, the solution of FIG. 20A and FIG. 20B is obtained.
When comparing the 100 kWh and 500 kWh examples, a larger overall output is possible with 500 kWh. A natural extension of this model may include the cost of purchasing and storing this initial power, which can then lead to a solution which may consider the stored cost relative to the added leveled output. Furthermore, the model can easily include additional benefits in terms of “green” power, power reliability (having this power available when the grid is down), or incorporating the benefit of CO2 emissions reductions.
Model 2. The second basic optimization may expand upon the first basic optimization. The second basic optimization may include an ability to dispatch customer appliances in response to prices (LMP and COS).
As in other models, other possibilities may include minimizing CO2 emissions, minimizing peak demand, and/or minimizing customer discomfort. Much like the problems in the demand response optimization 107 discussion above, the optimization problem can be stated as:
<maths id="MATHUS00026" num="00026"><math overflow="scroll"><mrow><mrow><mi>Max</mi><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><mo>(</mo><mrow><mrow><msub><mi>R</mi><mi>it</mi></msub><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>X</mi><mi>it</mi></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>PVtG</mi><mi>t</mi></msub></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow><mo></mo><mrow><msub><mi>I</mi><mi>it</mi></msub><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow><mo></mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo></mo><mrow><msub><mi>PVC</mi><mi>t</mi></msub><mo></mo><msub><mi>PVGen</mi><mi>t</mi></msub></mrow><mo></mo><mrow><mrow><mo>(</mo><mrow><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>PVtC</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><msub><mi>COS</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></math></maths><maths id="MATHUS000262" num="00026.2"><math overflow="scroll"><mrow><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mspace width="2.2em" height="2.2ex"/></mstyle><mo></mo><mstyle><mtext></mtext></mstyle><mo></mo><msub><mi>Dmd</mi><mi>it</mi></msub></mrow><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow><mo>=</mo><mrow><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><mrow><msub><mi>GtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="14.2em" height="14.2ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow><mo>,</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></mrow></math></maths><maths id="MATHUS000263" num="00026.3"><math overflow="scroll"><mrow><msub><mi>PVGen</mi><mi>t</mi></msub><mo>=</mo><mrow><mrow><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>PVtG</mi><mi>t</mi></msub><mo>+</mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="15.em" height="15.ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths><maths id="MATHUS000264" num="00026.4"><math overflow="scroll"><mrow><msub><mi>BattLvl</mi><mrow><mi>t</mi><mo>+</mo><mn>1</mn></mrow></msub><mo>=</mo><mrow><mrow><msub><mi>BattLvl</mi><mi>t</mi></msub><mo>+</mo><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>GtB</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><msub><mi>BtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="4.7em" height="4.7ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths><maths id="MATHUS000265" num="00026.5"><math overflow="scroll"><mrow><msub><mi>BattLvl</mi><mrow><mi>t</mi><mo>=</mo><mn>0</mn></mrow></msub><mo>=</mo><mrow><mrow><mrow><mi>K</mi><mo></mo><mstyle><mtext></mtext></mstyle><mo></mo><mi>BattCap</mi></mrow><mo>≥</mo><mrow><msub><mi>BattLvl</mi><mi>t</mi></msub><mo></mo><mstyle><mspace width="26.4em" height="26.4ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths>
Where:
 R<sub>it </sub>is the cost charged to customer i in time t for energy, (we are ignoring appliances for ease of exposition).
 Dmd<sub>it </sub>demand for energy for customer i, time t
 X<sub>it </sub>is the fraction of period t to supply energy to customer i
 LMP<sub>t </sub>is the Locational Marginal Cost at the battery and the PV (this model assumes that the battery and PV are located at the substation—multiple batteries and PV systems at different locations can be easily incorporated by adding an additional LMP terms).
 BtG<sub>t </sub>is the sales of power at time t from the battery (or other type of distributed storage) to the Grid. Note this model assumes that the utility can buy and sell to the distributed storage unit at the LMP. A natural extension is to use the Cost of Service (COS) at the storage unit, and include any other adders such as bid/ask spreads.
 PVtG<sub>t </sub>is the sales of power at time t from the PV (or other type of distributed generation) to the Grid. Note as above, this model assumes that the utility can buy and sell to the distributed generation unit at the LMP. A natural extension is to use the Cost of Service (COS) at the generation, and include any other adders such as bid/ask spreads.
 I<sub>it </sub>is the incentive offered by the utility to customer i to curtail their power during time t.
 COS<sub>it </sub>the cost to serve adder associated with moving electricity from the substation to the customer i during period t. This cost occurs whether or not power comes from the grid, the battery, or the PV unit.
 GtC<sub>it</sub>, BtC<sub>it</sub>, and PVtC<sub>it</sub>, are the power from the Grid, Battery, and PV respectively used to meet customer i's demand during period t.
 PVB<sub>t </sub>is the power from the PV that is sent out to the Battery for storage at time t.
 PVGen<sub>t </sub>is the power generation from the PV at time t (exogenous).
 BattLvl<sub>t </sub>is the storage level of the Battery (i.e., the amount of stored power) at time t.
 GtB<sub>t </sub>is the power sent from the Grid to the Battery for storage at time t.
 BattLv<sub>lt=0 </sub>is the initial storage level of the Battery, and is set to some value K.
 BattCap is the capacity of the Battery (based on the characteristics of the battery).
In essence, this basic optimization may account for power flows from distributed storage 131, such as battery, PV, and wind, and the grid 127. The optimization may compare the costs of each of these assets relative to the cost of demand response (i.e., curtailing individual customer enduses).
A simple scenario may involve buying power from the grid at night 127, storing the power in a distributed storage 131 for use during the day (when Grid costs are higher), supply customers from the distributed storage 131 and the renewable generation 129 during the day, and if an incentive is below the COS, interrupting those customers that have a very high COS when there is not enough energy stored in the distributed storage 131 or available from the renewable generation 129.
FIGS. 21A21F show results from an exemplary scenario with low incentive costs and high COS for certain customers. Note that the graphs make a distinction between sending power to specific customers. Clearly, an electron from the PV or battery does not know where it is going, but this distinction is made to attempt to make this interrelationship clearer.
Model 3. The model 2 optimization allowed for the curtailment of customers. This was a result of a relative cost to serve customers compared to the rate and the cost to curtail the enduses (the incentive). An alternative may be to shift customer demand into other periods of the hour. This has the benefit of keeping customer energy (kWh) use constant for the hour, hence customer comfort is likely to be constant, and since the rate is based on kWh, the utility's revenue may remain unchanged. The optimization in this case may become:
<maths id="MATHUS00027" num="00027"><math overflow="scroll"><mrow><mrow><mi>Max</mi><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>t</mi><mo>∈</mo><mi>T</mi></mrow></munder><mo></mo><mrow><mo>(</mo><mrow><mrow><msub><mi>R</mi><mi>it</mi></msub><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>X</mi><mi>it</mi></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub></mrow><mo>+</mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>PVtG</mi><mi>t</mi></msub></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow><mo></mo><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo></mo><mrow><msub><mi>PVC</mi><mi>t</mi></msub><mo></mo><msub><mi>PVGen</mi><mi>t</mi></msub></mrow><mo></mo><mrow><mrow><mo>(</mo><mrow><mrow><msub><mi>LMP</mi><mi>t</mi></msub><mo></mo><msub><mi>GtB</mi><mi>t</mi></msub></mrow><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>PVtC</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow><mo>·</mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><msub><mi>COS</mi><mi>it</mi></msub></mrow><mo>)</mo></mrow></mrow></mrow></math></maths><maths id="MATHUS000272" num="00027.2"><math overflow="scroll"><mrow><mrow><mrow><mrow><mi>s</mi><mo>.</mo><mi>t</mi><mo>.</mo><mstyle><mspace width="2.2em" height="2.2ex"/></mstyle><mo></mo><mstyle><mtext></mtext></mstyle><mo></mo><msub><mi>Dmd</mi><mi>it</mi></msub></mrow><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow><mo>=</mo><mrow><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo>+</mo><msub><mi>BtC</mi><mi>it</mi></msub><mo>+</mo><mrow><msub><mi>GtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="14.2em" height="14.2ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow><mo>,</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></mrow></math></maths><maths id="MATHUS000273" num="00027.3"><math overflow="scroll"><mrow><mrow><munder><mo>∑</mo><mi>t</mi></munder><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><msub><mi>X</mi><mi>it</mi></msub></mrow></mrow><mo>=</mo><mrow><mrow><munder><mo>∑</mo><mi>t</mi></munder><mo></mo><mrow><msub><mi>Dmd</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="23.3em" height="23.3ex"/></mstyle><mo></mo><mi>i</mi></mrow></mrow><mo>∈</mo><mi>I</mi></mrow></mrow></math></maths><maths id="MATHUS000274" num="00027.4"><math overflow="scroll"><mrow><msub><mi>PVGen</mi><mi>t</mi></msub><mo>=</mo><mrow><mrow><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>PVtG</mi><mi>t</mi></msub><mo>+</mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><msub><mi>PVtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="15.em" height="15.ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></math></maths><maths id="MATHUS000275" num="00027.5"><math overflow="scroll"><mrow><msub><mi>BattLvl</mi><mrow><mi>t</mi><mo>+</mo><mn>1</mn></mrow></msub><mo>=</mo><mrow><mrow><mrow><msub><mi>BattLvl</mi><mi>t</mi></msub><mo>+</mo><msub><mi>PVtB</mi><mi>t</mi></msub><mo>+</mo><msub><mi>GtB</mi><mi>t</mi></msub><mo></mo><msub><mi>BtG</mi><mi>t</mi></msub><mo></mo><mrow><munder><mo>∑</mo><mrow><mi>i</mi><mo>∈</mo><mi>I</mi></mrow></munder><mo></mo><mrow><msub><mi>BtC</mi><mi>it</mi></msub><mo></mo><mstyle><mspace width="4.7em" height="4.7ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>∈</mo><mrow><mi>T</mi><mo></mo><mstyle><mtext></mtext></mstyle><mo></mo><msub><mi>BattLvl</mi><mrow><mi>t</mi><mo>=</mo><mn>0</mn></mrow></msub></mrow></mrow><mo>=</mo><mrow><mrow><mrow><mi>K</mi><mo></mo><mstyle><mtext></mtext></mstyle><mo></mo><mi>BattCap</mi></mrow><mo>≥</mo><mrow><msub><mi>BattLvl</mi><mi>t</mi></msub><mo></mo><mstyle><mspace width="26.4em" height="26.4ex"/></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>∈</mo><mi>T</mi></mrow></mrow></mrow></math></maths>
The variables are described above, except there is no longer the need for an incentive. Furthermore, a new constraint was added to ensure that demand for each time period t is held constant. The resulting solution has no change in the flow of power from the renewable generation 129 and distributed storage 131 to and from the grid 127. However, as one would expect, the usage of customers is now shifted to low price periods and there is no curtailment (cycling) of demand.
Exemplary Walkthrough
The following is a walkthrough of an exemplary application of the optimizations 105. The walkthrough is illustrative only and is not intended to limit the disclosure. In this walkthrough it is assumed there are five customers, all of which have two appliances: (1) an air conditioner (AC), which draws 3.5 kW of power, and (2) an electric water heater, which draws 4.5 kW of power. At 11:50, the forecasting system predicts the flowing 5 minute demands for each of the five customers as shown in Table 5.
<tables id="TABLEUS00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 5</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Forecast customer demand</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="char" char="."/><colspec colname="3" colwidth="35pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>8.0</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>4.5</entry><entry>28.5</entry></row><row><entry>12:05</entry><entry>8.0</entry><entry>8.0</entry><entry>4.5</entry><entry>8.0</entry><entry>3.5</entry><entry>32.0</entry></row><row><entry>12:10</entry><entry>8.0</entry><entry>8.0</entry><entry>3.5</entry><entry>8.0</entry><entry>0.0</entry><entry>27.5</entry></row><row><entry>12:15</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:20</entry><entry>3.5</entry><entry>3.5</entry><entry>0.0</entry><entry>4.5</entry><entry>0.0</entry><entry>8.0</entry></row><row><entry>12:25</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>3.5</entry><entry>0.0</entry><entry>7.0</entry></row><row><entry>12:30</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:35</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:40</entry><entry>0.0</entry><entry>0.0</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>16.0</entry></row><row><entry>12:45</entry><entry>0.0</entry><entry>0.0</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>16.0</entry></row><row><entry>12:50</entry><entry>3.5</entry><entry>4.5</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>24.0</entry></row><row><entry>12:55</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>40.0</entry></row><row><entry>Total</entry><entry>39.0</entry><entry>40.0</entry><entry>40.0</entry><entry>40.0</entry><entry>40.0</entry><entry>199.0</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
In this scenario, it is assumed that customers 1, 2, and 3 are on one transformer which has poor characteristics. This transformer may be on a feeder line that has many other customers. Additionally, customer 3 is very far away from the transformer. Conversely, customers 4 and 5 are assumed to be on a different transformer that has good characteristics, and which is on a different feeder line with few customers, and both customers are close to the transformer.
Given forecast demand above in Table 5, the system may compute forecast Cost of Service Adder (COS), which is the line loss that added to the LMP, as follows in Table 6.
<tables id="TABLEUS00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 6</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Forecast COS Adder</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left"/><colspec colname="2" colwidth="182pt" align="center"/><tbody valign="top"><row><entry/><entry>Forecasted Cost of Service Adders</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="14pt" align="left"/><colspec colname="2" colwidth="21pt" align="center"/><colspec colname="3" colwidth="42pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="42pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="42pt" align="center"/><tbody valign="top"><row><entry/><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="14pt" align="left"/><colspec colname="2" colwidth="21pt" align="center"/><colspec colname="3" colwidth="42pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="42pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="42pt" align="char" char="."/><tbody valign="top"><row><entry/><entry>12:00</entry><entry>27.0%</entry><entry>26.8%</entry><entry>26.5%</entry><entry>5.7%</entry><entry>5.6%</entry></row><row><entry/><entry>12:05</entry><entry>29.3%</entry><entry>29.0%</entry><entry>36.8%</entry><entry>4.2%</entry><entry>4.1%</entry></row><row><entry/><entry>12:10</entry><entry>17.9%</entry><entry>18.0%</entry><entry>17.9%</entry><entry>4.2%</entry><entry>0.0%</entry></row><row><entry/><entry>12:15</entry><entry>0.0%</entry><entry>0.0%</entry><entry>0.0%</entry><entry>0.0%</entry><entry>0.0%</entry></row><row><entry/><entry>12:20</entry><entry>27.1%</entry><entry>26.9%</entry><entry>26.9%</entry><entry>4.3%</entry><entry>0.0%</entry></row><row><entry/><entry>12:25</entry><entry>26.9%</entry><entry>27.0%</entry><entry>26.9%</entry><entry>4.4%</entry><entry>0.0%</entry></row><row><entry/><entry>12:30</entry><entry>0.0%</entry><entry>0.0%</entry><entry>0.0%</entry><entry>0.0%</entry><entry>0.0%</entry></row><row><entry/><entry>12:35</entry><entry>23.9%</entry><entry>23.9%</entry><entry>38.2%</entry><entry>0.0%</entry><entry>0.0%</entry></row><row><entry/><entry>12:40</entry><entry>27.0%</entry><entry>26.5%</entry><entry>40.8%</entry><entry>0.0%</entry><entry>4.2%</entry></row><row><entry/><entry>12:45</entry><entry>23.9%</entry><entry>23.9%</entry><entry>38.2%</entry><entry>0.0%</entry><entry>4.2%</entry></row><row><entry/><entry>12:50</entry><entry>24.1%</entry><entry>24.0%</entry><entry>23.9%</entry><entry>0.0%</entry><entry>4.2%</entry></row><row><entry/><entry>12:55</entry><entry>26.5%</entry><entry>26.8%</entry><entry>40.8%</entry><entry>4.5%</entry><entry>4.5%</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
The system may also forecast LMP, which is the cost to buy power at the closest node, at a 5 minute level. The forecast LMP may combine the forecast COS adder in Table 6 with the forecast LMP to get a CustomerSpecific Cost of Service as shown in Table 7.
<tables id="TABLEUS00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 7</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Forecast CustomerSpecific COS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="154pt" align="center"/><tbody valign="top"><row><entry/><entry>Forecasted</entry><entry>Implied cost of Service</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>LMP</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row><row><entry>12:00</entry><entry>0.16</entry><entry>0.21</entry><entry>0.21</entry><entry>0.21</entry><entry>0.17</entry><entry>0.17</entry></row><row><entry>12:05</entry><entry>0.18</entry><entry>0.23</entry><entry>0.23</entry><entry>0.25</entry><entry>0.19</entry><entry>0.19</entry></row><row><entry>12:10</entry><entry>0.15</entry><entry>0.18</entry><entry>0.18</entry><entry>0.18</entry><entry>0.16</entry><entry>0.15</entry></row><row><entry>12:15</entry><entry>0.22</entry><entry>0.22</entry><entry>0.22</entry><entry>0.22</entry><entry>0.22</entry><entry>0.22</entry></row><row><entry>12:20</entry><entry>0.22</entry><entry>0.28</entry><entry>0.28</entry><entry>0.28</entry><entry>0.23</entry><entry>0.22</entry></row><row><entry>12:25</entry><entry>0.21</entry><entry>0.27</entry><entry>0.27</entry><entry>0.27</entry><entry>0.22</entry><entry>0.21</entry></row><row><entry>12:30</entry><entry>0.35</entry><entry>0.35</entry><entry>0.35</entry><entry>0.35</entry><entry>0.35</entry><entry>0.35</entry></row><row><entry>12:35</entry><entry>0.40</entry><entry>0.49</entry><entry>0.49</entry><entry>0.55</entry><entry>0.40</entry><entry>0.40</entry></row><row><entry>12:40</entry><entry>0.33</entry><entry>0.42</entry><entry>0.42</entry><entry>0.47</entry><entry>0.33</entry><entry>0.34</entry></row><row><entry>12:45</entry><entry>0.25</entry><entry>0.31</entry><entry>0.31</entry><entry>0.35</entry><entry>0.25</entry><entry>0.26</entry></row><row><entry>12:50</entry><entry>0.54</entry><entry>0.67</entry><entry>0.67</entry><entry>0.67</entry><entry>0.54</entry><entry>0.56</entry></row><row><entry>12:55</entry><entry>0.63</entry><entry>0.80</entry><entry>0.80</entry><entry>0.89</entry><entry>0.66</entry><entry>0.66</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
With this information, the system may estimate a total cost to purchase power to meet demand for the utility going forward at five minute increments as shown in Table 8.
<tables id="TABLEUS00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 8</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Estimated Cost to Supply Total Demand</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="35pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="char" char="."/><colspec colname="3" colwidth="35pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="35pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>$1.66</entry><entry>$1.66</entry><entry>$0.00</entry><entry>$1.38</entry><entry>$0.78</entry><entry>$5.48</entry></row><row><entry>12:05</entry><entry>$1.86</entry><entry>$1.86</entry><entry>$1.11</entry><entry>$1.50</entry><entry>$0.66</entry><entry>$6.98</entry></row><row><entry>12:10</entry><entry>$1.45</entry><entry>$1.45</entry><entry>$0.63</entry><entry>$1.28</entry><entry>$0.00</entry><entry>$4.82</entry></row><row><entry>12:15</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:20</entry><entry>$0.99</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$1.05</entry><entry>$0.00</entry><entry>$2.04</entry></row><row><entry>12:25</entry><entry>$0.00</entry><entry>$0.94</entry><entry>$0.00</entry><entry>$0.77</entry><entry>$0.00</entry><entry>$1.71</entry></row><row><entry>12:30</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:35</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:40</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$3.72</entry><entry>$0.00</entry><entry>$2.75</entry><entry>$6.47</entry></row><row><entry>12:45</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$2.76</entry><entry>$0.00</entry><entry>$2.08</entry><entry>$4.85</entry></row><row><entry>12:50</entry><entry>$2.35</entry><entry>$3.01</entry><entry>$5.35</entry><entry>$0.00</entry><entry>$4.50</entry><entry>$15.21</entry></row><row><entry>12:55</entry><entry>$6.38</entry><entry>$6.39</entry><entry>$7.10</entry><entry>$5.27</entry><entry>$5.27</entry><entry>$30.39</entry></row><row><entry>Total</entry><entry>$14.69</entry><entry>$15.31</entry><entry>$20.68</entry><entry>$11.25</entry><entry>$16.03</entry><entry>$77.95</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
In this scenario, the utility may have a flat rate of $0.20/kWh (i.e., there is no timedifferentiated rates). Therefore, the projected revenue (rate times sales in kWh) may be equal to 0.20*199 (total kWh sales) or $39.80. Given that the forecast for the cost of supplying the power is $77.95, the implication is that the utility is expected to lose $39.80−$77.95=$38.15 in the coming hour.
The high LMP at 12:55 may be the result of a spike in temperature, and the utility may be unable to supply enough power to meet all the total system demand (the peak demand) at that point in time. So, what is often done is to call for a “demand response event.” The current stateoftheart in demand response is to offer all customers an incentive (assume it is $1.00 per an event), to let the utility control their appliances.
A typical demand response (DR) program with $1.00 incentive per event per participant may assume 75% cycling (i.e., AC and WH shut off for 45 minutes out of the hour). Assuming that the forecast demand from the system was accurate, then the demand under a typical DR program is as follows in Table 9.
<tables id="TABLEUS00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 9</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Demand curtailed by DR program</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>Demand Using Current DR Technology</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="char" char="."/><colspec colname="3" colwidth="35pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:05</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:10</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:15</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:20</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:25</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:30</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:35</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:40</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:45</entry><entry>0.0</entry><entry>0.0</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>16.0</entry></row><row><entry>12:50</entry><entry>3.5</entry><entry>4.5</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>24.0</entry></row><row><entry>12:55</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>40.0</entry></row><row><entry>Total</entry><entry>11.5</entry><entry>12.5</entry><entry>24.0</entry><entry>8.0</entry><entry>24.0</entry><entry>80.0</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
To determine the cost to supply this new demand, the curtailed demand may be multiplied by the cost of service in Table 7. Note that in the all the cases discussed, when the demand is reduced, the cost of service is also reduced.
Table 10 lists the total costs under the exemplary demand reduction program.
<tables id="TABLEUS00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 10</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Total Cost under DR Program</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>Forecasted Total Cost of Purchased Power</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="35pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="35pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:05</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:10</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:15</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:20</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:25</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:30</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:35</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:40</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:45</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$2.76</entry><entry>$0.00</entry><entry>$2.08</entry><entry>$4.85</entry></row><row><entry>12:50</entry><entry>$2.35</entry><entry>$3.01</entry><entry>$5.35</entry><entry>$0.00</entry><entry>$4.50</entry><entry>$15.21</entry></row><row><entry>12:55</entry><entry>$6.38</entry><entry>$6.39</entry><entry>$7.10</entry><entry>$5.27</entry><entry>$5.27</entry><entry>$30.39</entry></row><row><entry>Total</entry><entry>$8.72</entry><entry>$9.40</entry><entry>$15.21</entry><entry>$5.27</entry><entry>$11.85</entry><entry>$50.45</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
This blanket curtailment approach did reduce usage during the peak period, and resulted in a reduction in the total cost of delivered power from $77.95 down to $50.45. However, since there is no accounting for the peak LMP relative to when the DR program is implemented, the customers' are still using power during the peak period. The DR event essentially had no effect on reducing the strain on the system. In addition, the curtailment in customer's usage reduced the utility's revenue because of the loss in total kWh. With the DR program, the total sales dropped to 80 kWh, thus the utility receives revenue of only 80 kWh sales*$0.20/kWh or $16. Therefore, the net revenue under DR is $16, less the incentive cost of $5, less the cost of power of $50.45 for net revenue of negative $39.45, compared to the prior loss of $38.15. So in this example, a DR program actually results in the utility losing more revenue without the benefit of reducing peak demand during the critical peak period.
With the real or nearreal time enduse capability of embodiments of the present invention, this situation may be avoided. One option may be to use an optimal DR mode, which may give the highest avoided cost to achieve a given targeted demand reduction. With builtin COS forecasting the system may ensure that the peak may be reduced.
Using the demand reduction from the above DR program, the system may determine the best allocation to achieve the dispatching given each customer's forecast demand and COS. The results are presented in Table 11.
<tables id="TABLEUS00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 11</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>DR Dispatching using Embodiments of the Present Invention</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>IDROP Dispatched Demand</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="char" char="."/><colspec colname="3" colwidth="35pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>8.0</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>4.5</entry><entry>28.5</entry></row><row><entry>12:05</entry><entry>1.0</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>3.5</entry><entry>20.5</entry></row><row><entry>12:10</entry><entry>8.0</entry><entry>8.0</entry><entry>3.5</entry><entry>8.0</entry><entry>0.0</entry><entry>27.5</entry></row><row><entry>12:15</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:20</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:25</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>3.5</entry><entry>0.0</entry><entry>3.5</entry></row><row><entry>12:30</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:35</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:40</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:45</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:50</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:55</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>Total</entry><entry>17.0</entry><entry>24.0</entry><entry>3.5</entry><entry>27.5</entry><entry>8.0</entry><entry>80.0</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
Again, using the time and customer specific COS information in Table 7, the total cost for the utility to meet the demand is presented in Table 12:
<tables id="TABLEUS00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 12</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Cost to Supply the DR</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>Forecasted Total Cost of Purchased Power under Dispatch</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="42pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="42pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>$1.66</entry><entry>$1.66</entry><entry>$0.00</entry><entry>$1.38</entry><entry>$0.78</entry><entry>$5.48</entry></row><row><entry>12:05</entry><entry>$0.23</entry><entry>$1.86</entry><entry>$0.00</entry><entry>$1.50</entry><entry>$0.66</entry><entry>$4.25</entry></row><row><entry>12:10</entry><entry>$1.45</entry><entry>$1.45</entry><entry>$0.63</entry><entry>$1.28</entry><entry>$0.00</entry><entry>$4.82</entry></row><row><entry>12:15</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:20</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:25</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.77</entry><entry>$0.00</entry><entry>$0.77</entry></row><row><entry>12:30</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:35</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:40</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:45</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:50</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:55</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>Total</entry><entry>$3.34</entry><entry>$4.97</entry><entry>$0.63</entry><entry>$4.93</entry><entry>$1.43</entry><entry>$15.31</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
As Table 12 shows, even though the demand curtailment is the same as the typical DR program, the cost of supplying this is considerably less, $15.31 compared to $50.45. In addition, there is no appliance usage under the peak hours. As one would expect, the resulting net revenue is much higher in this case, a loss of only $4.31 relative to the loss of $50.45 in Table 10. Therefore, the DR mode of the system may be more effective than the rather imprecise DR programs currently in use.
The system's load leveling mode may limit the cost of the peak demand by minimizing demand at the five minute, or less, level. This approach is beneficial if it is not possible to develop meaningful forecasts of the cost of power down to the subhourly level. By levelizing demand throughout the hour, the issue of a peak period may be minimized. Further, by coordinating the natural duty cycle across customers, but ensuring that the total energy use of each customer is still achieved, this reduction in total peak demand is achieved without any reduction in customer comfort or total kWh sales.
Table 13 shows the result of using the system's load levelizing mode. This table shows that the demand for each 5 minute period is indeed equal, and the total load curve is flat. So this approach reduced the peak demand from the original 40 kWh during 12:55, to only 16 kWh, with no need to curtail customers, and no loss in comfort, and no change in kWh sales.
<tables id="TABLEUS00013" num="00013"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 13</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Load Leveled Dispatch</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>IDROP Dispatched Demand</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="char" char="."/><colspec colname="3" colwidth="35pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>2.3</entry><entry>8.0</entry><entry>0.0</entry><entry>6.3</entry><entry>0.0</entry><entry>16.6</entry></row><row><entry>12:05</entry><entry>0.0</entry><entry>0.6</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>16.6</entry></row><row><entry>12:10</entry><entry>0.6</entry><entry>0.0</entry><entry>8.0</entry><entry>8.0</entry><entry>0.0</entry><entry>16.6</entry></row><row><entry>12:15</entry><entry>8.0</entry><entry>0.0</entry><entry>8.0</entry><entry>0.6</entry><entry>0.0</entry><entry>16.6</entry></row><row><entry>12:20</entry><entry>8.0</entry><entry>0.6</entry><entry>0.0</entry><entry>0.0</entry><entry>8.0</entry><entry>16.6</entry></row><row><entry>12:25</entry><entry>0.0</entry><entry>1.2</entry><entry>8.0</entry><entry>0.0</entry><entry>7.4</entry><entry>16.6</entry></row><row><entry>12:30</entry><entry>8.0</entry><entry>8.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.6</entry><entry>16.6</entry></row><row><entry>12:35</entry><entry>0.0</entry><entry>8.0</entry><entry>0.0</entry><entry>0.6</entry><entry>8.0</entry><entry>16.6</entry></row><row><entry>12:40</entry><entry>8.0</entry><entry>8.0</entry><entry>0.0</entry><entry>0.6</entry><entry>0.0</entry><entry>16.6</entry></row><row><entry>12:45</entry><entry>0.6</entry><entry>0.0</entry><entry>0.0</entry><entry>8.0</entry><entry>8.0</entry><entry>16.6</entry></row><row><entry>12:50</entry><entry>3.5</entry><entry>5.1</entry><entry>0.0</entry><entry>8.0</entry><entry>0.0</entry><entry>16.6</entry></row><row><entry>12:55</entry><entry>0.0</entry><entry>0.6</entry><entry>8.0</entry><entry>8.0</entry><entry>0.0</entry><entry>16.6</entry></row><row><entry>Total</entry><entry>39.0</entry><entry>40.0</entry><entry>40.0</entry><entry>40.0</entry><entry>40.0</entry><entry>199.0</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
The cost the supply this levelized demand is presented in Table 14.
<tables id="TABLEUS00014" num="00014"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 14</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Cost to Supply Levelized Demand</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>Forecasted Total Cost of Purchased Power under Dispatch</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="42pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="char" char="."/><colspec colname="3" colwidth="42pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>$0.48</entry><entry>$1.66</entry><entry>$0.00</entry><entry>$1.08</entry><entry>$0.00</entry><entry>$3.22</entry></row><row><entry>12:05</entry><entry>$0.00</entry><entry>$0.14</entry><entry>$1.97</entry><entry>$0.00</entry><entry>$1.50</entry><entry>$3.60</entry></row><row><entry>12:10</entry><entry>$0.11</entry><entry>$0.00</entry><entry>$1.45</entry><entry>$1.28</entry><entry>$0.00</entry><entry>$2.84</entry></row><row><entry>12:15</entry><entry>$1.74</entry><entry>$0.00</entry><entry>$1.74</entry><entry>$0.13</entry><entry>$0.00</entry><entry>$3.62</entry></row><row><entry>12:20</entry><entry>$2.27</entry><entry>$0.17</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$1.79</entry><entry>$4.22</entry></row><row><entry>12:25</entry><entry>$0.00</entry><entry>$0.31</entry><entry>$2.14</entry><entry>$0.00</entry><entry>$1.56</entry><entry>$4.01</entry></row><row><entry>12:30</entry><entry>$2.80</entry><entry>$2.80</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.20</entry><entry>$5.80</entry></row><row><entry>12:35</entry><entry>$0.00</entry><entry>$3.93</entry><entry>$0.00</entry><entry>$0.23</entry><entry>$3.17</entry><entry>$7.33</entry></row><row><entry>12:40</entry><entry>$3.36</entry><entry>$3.34</entry><entry>$0.00</entry><entry>$0.19</entry><entry>$0.00</entry><entry>$6.89</entry></row><row><entry>12:45</entry><entry>$0.18</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$2.00</entry><entry>$2.08</entry><entry>$4.26</entry></row><row><entry>12:50</entry><entry>$2.35</entry><entry>$3.40</entry><entry>$0.00</entry><entry>$4.32</entry><entry>$0.00</entry><entry>$10.07</entry></row><row><entry>12:55</entry><entry>$0.00</entry><entry>$0.47</entry><entry>$7.10</entry><entry>$5.27</entry><entry>$0.00</entry><entry>$12.83</entry></row><row><entry>Total</entry><entry>$13.29</entry><entry>$16.21</entry><entry>$14.40</entry><entry>$14.50</entry><entry>$10.31</entry><entry>$68.70</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
The resulting net revenue is a loss of $28.90, which represents a significantly better profit than either doing nothing at all, or using the traditional DR approach. It is still lower than using the system to manage a given demand reduction, but that result did not account for the cost to customers associated with the loss of power, which may well be much greater than the incentive.
The final mode takes advantage of fact that the system can forecast both demand and supply at the 5 minute level. Therefore, it is possible to microdispatch customer's enduses at the 5 minute, or less, level based on the COS at that time, while still achieving the customer's total kWh usage over the entire period. Table 15 presents the results of the system's optimal microdispatching mode.
<tables id="TABLEUS00015" num="00015"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 15</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>MicroDispatch Results</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>IDROP Dispatched Demand</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="35pt" align="char" char="."/><colspec colname="3" colwidth="35pt" align="char" char="."/><colspec colname="4" colwidth="28pt" align="char" char="."/><colspec colname="5" colwidth="35pt" align="char" char="."/><colspec colname="6" colwidth="28pt" align="char" char="."/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>40.0</entry></row><row><entry>12:05</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>40.0</entry></row><row><entry>12:10</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>40.0</entry></row><row><entry>12:15</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>40.0</entry></row><row><entry>12:20</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:25</entry><entry>7.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>8.0</entry><entry>39.0</entry></row><row><entry>12:30</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:35</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:40</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:45</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:50</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>12:55</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry><entry>0.0</entry></row><row><entry>Total</entry><entry>39.0</entry><entry>40.0</entry><entry>40.0</entry><entry>40.0</entry><entry>40.0</entry><entry>199.0</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
This table shows that the total kWh both for all customers and overall is the same as in Table 5, but the occurrence of this demand is quite different. Note that there is no demand during the peak period.
Looking at the cost to supply this demand, as shown in Table 16, it is clear that there is a significant reduction in this cost, even though there has been no curtailment, and hence no cost in customers comfort.
<tables id="TABLEUS00016" num="00016"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 16</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Cost of Supply MicroDispatched Demand</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left"/><colspec colname="2" colwidth="189pt" align="center"/><tbody valign="top"><row><entry/><entry>Forecasted Total Cost of Purchased Power under Dispatch</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="42pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="center"/><tbody valign="top"><row><entry>Time</entry><entry>Cust. 1</entry><entry>Cust. 2</entry><entry>Cust. 3</entry><entry>Cust. 4</entry><entry>Cust. 5</entry><entry>Total</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28pt" align="center"/><colspec colname="2" colwidth="28pt" align="center"/><colspec colname="3" colwidth="42pt" align="center"/><colspec colname="4" colwidth="28pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><colspec colname="7" colwidth="28pt" align="char" char="."/><tbody valign="top"><row><entry>12:00</entry><entry>$1.66</entry><entry>$1.66</entry><entry>$1.65</entry><entry>$1.38</entry><entry>$1.38</entry><entry>$7.74</entry></row><row><entry>12:05</entry><entry>$1.86</entry><entry>$1.86</entry><entry>$1.97</entry><entry>$1.50</entry><entry>$1.50</entry><entry>$8.69</entry></row><row><entry>12:10</entry><entry>$1.45</entry><entry>$1.45</entry><entry>$1.45</entry><entry>$1.28</entry><entry>$1.23</entry><entry>$6.87</entry></row><row><entry>12:15</entry><entry>$1.74</entry><entry>$1.74</entry><entry>$1.74</entry><entry>$1.74</entry><entry>$1.74</entry><entry>$8.72</entry></row><row><entry>12:20</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:25</entry><entry>$1.87</entry><entry>$2.14</entry><entry>$2.14</entry><entry>$1.76</entry><entry>$1.69</entry><entry>$9.60</entry></row><row><entry>12:30</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:35</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:40</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:45</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:50</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>12:55</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry><entry>$0.00</entry></row><row><entry>Total</entry><entry>$8.59</entry><entry>$8.85</entry><entry>$8.96</entry><entry>$7.67</entry><entry>$7.54</entry><entry>$41.61</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>
Table 16 shows cost to supply the microdispatched demand. The net revenue, as one would expect, is the highest of all the cases presented, a net loss of only $1.81. Again, this net gain in revenue and the elimination of peak demand occurs without any cost, direct or indirect, to the customer.
Table 17 summarizes the results presented above.
<tables id="TABLEUS00017" num="00017"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center"/><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 17</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1"/></row><row><entry>Summary of Results</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119pt" align="left"/><colspec colname="2" colwidth="98pt" align="center"/><tbody valign="top"><row><entry/><entry>IDROP MODES</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="63pt" align="left"/><colspec colname="2" colwidth="21pt" align="center"/><colspec colname="3" colwidth="35pt" align="center"/><colspec colname="4" colwidth="35pt" align="center"/><colspec colname="5" colwidth="35pt" align="center"/><colspec colname="6" colwidth="28pt" align="center"/><tbody valign="top"><row><entry/><entry>Base</entry><entry>Current</entry><entry>DR</entry><entry/><entry>Micro</entry></row><row><entry/><entry>Case</entry><entry>DR Tech.</entry><entry>Dispatch</entry><entry>Levelizing</entry><entry>Disp.</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1"/></row><row><entry>Total kWh sales</entry><entry>199</entry><entry> 80</entry><entry>80</entry><entry>199</entry><entry>199</entry></row><row><entry>Peak Demand (kW)</entry><entry> 40</entry><entry> 40</entry><entry> 0</entry><entry> 17</entry><entry> 0</entry></row><row><entry>Cost of Power</entry><entry>$78</entry><entry>$50</entry><entry>$15 </entry><entry>$69</entry><entry>$42</entry></row><row><entry>Net Revenue</entry><entry>($38)</entry><entry>($39)</entry><entry>($4)</entry><entry>($29)</entry><entry> ($2)</entry></row><row><entry>Incentive Payments?</entry><entry>No</entry><entry>Yes</entry><entry>Yes</entry><entry>No</entry><entry>No</entry></row><row><entry>Customer Impacts?</entry><entry>None</entry><entry>Yes</entry><entry>Yes</entry><entry>None</entry><entry>None</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1"/></row></tbody></tgroup></table></tables>Summary of Optimization Systems
Embodiments of the present invention may have one or more of the following characteristics:
Calculating customer cost of service adders which are added to forecasts of nodal LMP prices, using commodity based, distribution based and other characteristics related to managing and delivering power. Forecasting 5minute nodal LMPs and updating customerspecific COS forecasts. Forecasting 5minute total house and major enduse (HVAC, WH) demand specific to each customer for the next hour. Forecasting hourly total house and major enduse (HVAC, WH) demand specific to each customer for every hour to the end of the month. New forecasts are developed every hour with new data. Forecasting 5minute photovoltaic (or wind) generation for the next hour with new forecasts developed every hour with new data. Forecasting probability of an individual overriding an event, developed prior to each event (included in dispatching model). Verification that customer is eligible for an event, given preset participation constraints and schedules. Verification that customer agreed to participate in an event. Realtime reporting of total house and enduse consumption to customers and utility via web portals. Utility web portal may use GIS interface and the customer portal may use a customizable graphical display, which may allow comparisons. Realtime reporting of LMP and COS to utility via web portal as well as forecast LMP and temperature. Realtime reporting of dispatchable load (by enduse) to utility via web portal. Display of customer characteristics via GIS interface in utility web portal. Display of distribution system via GIS interface in utility web portal including: overhead primary lines, overhead transformers, underground primary lines, overhead transformers, underground transformers. GIS display of solar potential in utility web portal including open field solar and solar gain. Realtime display of distributed renewable resource production, weather condition, and distributed storage status. Ability of to run dispatching execution strategies via the utility web portal in real time or in the future, with report generation ability for past events. A maintenance portal that provides customer service representative with realtime customer status information of the entire REMS system or specific customers. This information may include: whether or not the customer is currently in an event; the customer portal setting; if each enduse is running; the device interruption history; contact information; last login; account number; ability to run customizable reports on portal usage, electricity usage, event participation, connectivity, and overrides; ability for the customer to set five different device usage modes (hourly schedules for the week that allow specific customer to configure their appliance settings); optin and override event screens on the customer web portal that are incorporated into the dispatching models; customer portal includes notification area for communications from utility, mode override button, weather reports, device status, and a graphical contextlinked help file; load leveling dispatching of customers to minimize total system kW (sum of kW of houses with HAN/REMS and houses without HAN) while keeping kWh unchanged. The result is not only a minimized kW, but also a flattened kW, so that the volatility of kW is reduced, which results in a decrease in distribution system stress (transformers) as well as financial/planning uncertainty (risk). End use and microgrid resource dispatching to curtail use of HVAC and/or water heater of customers to achieve load reductions. Embodiments may conduct many types of demand response dispatching including: dispatch all customers (cycling amounts can be set to enduses, or specific customer enduses); dispatch customers to achieve a given load reduction target (cycling amounts can be set to enduses, or specific customer enduses); load reduction target may be met very closely because each customer's load is being forecast in real time; customers can be dispatched on the basis of their COS (which implicitly incorporates distribution system benefits), value of comfort, probability of override, willingness to pay (bid), uncertainty of load, etc.; results of dispatch presented in realtime in utility portal, which includes demand reduction (based on forecast), lost revenue, and avoided cost.
A bill target system may be used for curtailment of enduses of a specific customer to achieve that customer's monthly electric bill target. Enduses are curtailed on the basis of that customer's COS, so the avoided cost gained by the user or the utility which is associated with the customer is maximized, energy usage is reduced, and the customer's risk from bill uncertainty is mitigated or eliminated.
Renewable generation levelizing may coordinate photovoltaic or wind with substation battery or storage at customer location. This may minimize the fluctuation from renewable distributed resources at the 5 minute, or less, level by coordinating distributed storage with the renewable generation. A net result may be a flat generation curve from the combined system, which reduces stress on the distribution system, and minimizes the financial and planning uncertainty, or which more closely achieves least cost planning objectives of the utility.
Microgrid coordination may choreograph renewable distributed resource, distributed storage, and customers with REMS to maximize the value to customers and the utility. Using the LMP at the renewable resource and the battery, combined with the COS at each customer, the forecast generated from the renewable resource, and the forecast demand of each customer, the system may determine the highest value of each power flow from the PV, battery and grid to develop near realtime (5minute) dispatching of all distributed resources. This model can incorporate carbon emissions consideration, green power pricing, reliability concerns, and incentive payments.
In summary, there are three types of benefits enabled by methods, processes and algorithms of the system. These include distributionspecific or circuitspecific benefits to the utility, energy management benefits to the utility, and customerspecific benefits to end users. With respect to distributionspecific benefits, the following are enabled by the system. First, the system may control load volatility on the circuit, or at local service transformers, by optimally controlling the operation and use of end use customer appliances, thereby improving voltage conditions at targeted areas, and reducing, deferring or eliminating some distribution capital costs. The combined attention to both commodity based value and distribution specific value enhances the utility's ability to manage peak loads, deliver power more reliably, reduce energy costs, manage voltage, mitigate line losses and defer or eliminate future distribution capacity capital costs. Second, the system may respond to variability in solar resources output, due to weather or cloud cover, by adjusting customers' appliances and end use devices to accommodate the loss of solar power during such times, thereby mitigating intermittency risk inherent in solar power output. Third, the system may mitigate the need for storage resources on a circuit by coordinating customers' end use appliances and cycling, thereby reducing load volatility and overall system costs. Because end uses may be dispatching optimally, their use can be scheduled and choreographed such that random peak load realizations are minimized, or eliminated. Fourth, the system may improve voltage on a circuit, at targeted locations, by reducing usage of certain appliances or loads during peak times at specific locations, such that transformers serve a less volatile load, where voltage improvements are desired. This may be desirable to supplement targeted locations where utility's existing distribution management or integrated voltvar control systems are less effective than desired. Fifth, the system may enhance the identification of potential electricity theft by comparison of similarly situated customers' usage, conditioned on appliance, end use and behavioral characteristics. In contrast, specifically, there are several gridrelated functions that are intentionally not enabled by the system. These include outage restoration or detection, fault detection, the direct actuation of voltage control, reactive power injection, regulation, meter reading, turn on/turn off capability, safety improvement, or momentary outage mitigation.
The second set of benefits pertains to customer or end user benefits. First, the system allows a customer to fix the monthly electricity bill to a preset amount, to lock in desired energy savings or reduction, or to reduce bill volatility. The system may adjust the usage or cycling of appliances, conditioned on prespecified constraints selected in advance by the customer (e.g., only control appliance during hours 2 pm to 6 pm, only control the AC unit, reduce AC thermostat settings no more than 4 degrees). Second, the system may provide the customer the ability to override previously selected settings or constraints during operational control or cycling times, such that comfort and convenience is maintained by the customer. The system may incorporate the magnitude and frequency of override behaviors, subsequently, into that customer's forecasted load algorithms, such that the expected future load reductions forecasted for that customer are more accurately specified within the system's optimization module and dispatching executions for subsequent time periods. Third, the system may enhance the identification of usage amounts, costs and carbon content of customer's electricity consumption, reported to the customer through web enabled communication module. Fourth, the system may enable the provision of price signals and load reduction credits or rebates to be provided to customers in hourly, daily, monthly or annual specifications. Fifth, the system may provide customers the ability to preset comfort, convenience and cost savings preferences, or constraints, in advance and not require continual monitoring of the system, yet preserve the customer's ability to override these settings.
The third set of benefits derived from the system's methods, processes and specifications pertain to utility supply side benefits. First, the system reduces the amount of needed supply side energy production, due to appliance cycling options selected by customers, dispatching of microgrid resources, optimally dispatched by the system, significantly where customers may accept pricing credits, incentives, fixed billing options, or preset appliance patterns, settings or temperatures. Second, the system may enable the reduction in capacity requirements due to load leveling, by coordinating the cycling of appliances natural duty cycles and the storage inherent within electric hot water heating systems or other dispatchable appliances or microgrid resources, or as end use schedules and constraints selected by customers in advance for inclusion. Third, the system enhances the load following ability for utility system loads, increasing utility's ability to use the optimization system to complement the needs of supply side plant ramp rates, respond to forced outages, respond to spinning or supplemental reserve requirements, mitigate load following risk caused by intermittent or quickly ramping wind resources, or other ancillary service needs. Fourth, the system may increase the ability to meet mandated energy conservation or demand response requirements specified within state or federal regulatory or legislative frameworks. Fifth, the system may increase the potential to defer, or eliminate future supply side resource construction of plants, or future distribution costs. Sixth, the system may increase the potential to reduce, shift or manage supply side plant emissions. Seventh, the system may be able to realign the manner in which utilities make demand dispatching and microgrid dispatching decisions, namely where the system may enable the utility to use marginal costs that are more reflective of the utility's actual cost to serve individual customers. Here, average system pricing signals for a region are replaced with customer specific marginal costs, as the basis for making dispatching decisions, to better reflect overall avoided costs to the utility, such that least cost planning and integrated resource planning objectives can be better achieved. This enables a more cost effective and optimized dispatching strategy, given overall utility costs. As more and more demand dispatching resources are obtained the system may provide a more dynamically responsive process and method for allowing demand side resources to become price setters within the energy markets, by appropriately decreasing the cost to serve as load reduction potential increases, thereby protecting the utility from overcommitting demand side resources. Finally, the system may enable utilities or users the coordination and optimal scheduling of electric vehicle charging and discharging, charging and discharging of battery storage capacity, and the optimal integration of distributed resources including distributed generation, solar, wind and related power resources. The system is not limited to prespecified end uses. Any end use which can be controlled, adjusted or scheduled can be incorporated into the overall dispatching operations.
Although the foregoing description is directed to the preferred embodiments of the invention, it is noted that other variations and modifications will be apparent to those skilled in the art, and may be made without departing from the spirit or scope of the invention. Moreover, features described in connection with one embodiment of the invention may be used in conjunction with other embodiments, even if not explicitly stated above.