validated and transparent energy storage valuation and ......esic modeling guidelines . this is a...
TRANSCRIPT
Energy Research and Development Division
FINAL PROJECT REPORT
Validated and Transparent Energy Storage Valuation and Optimization Tool
Appendix B: Functional Requirements and Interface Specification
California Energy Commission Edmund G. Brown Jr., Governor
March 2017 | CEC-500-2017-016-APB
i
Prepared by: Primary Author(s): Robert Entriken Electric Power Research Institute 2430 Hillview Avenue Palo Alto, CA 94304 650-855-2121 www.epri.com
Contract Number: EPC-14-019
Prepared for:
California Energy Commission
Ostap Loredo-Contreras Contract Manager
Ben Kaun Project Manager
Fernando Pina Office Manager Energy Systems Research Office
Laurie ten Hope Deputy Director Energy Systems Research Office
Robert P. Oglesby Executive Director
DISCLAIMER
This report was prepared as the result of work sponsored by the California Energy Commission. It does not necessarily represent the views of the Energy Commission, its employees or the State of California. The Energy Commission, the State of California, its employees, contractors and subcontractors make no warrant, express or implied, and assume no legal liability for the information in this report; nor does any party represent that the uses of this information will not infringe upon privately owned rights. This report has not been approved or disapproved by the California Energy Commission nor has the California Energy Commission passed upon the accuracy or adequacy of the information in this report.
ii
ACKNOWLEDGEMENTS
The Electric Power Research Institute (EPRI) prepared this report.
Principal Investigator R. Entriken
This report describes research sponsored by the California Energy Commission.
iii
ABSTRACT
This document describes functional requirements for the StorageVET software. These requirements, in general, are descriptions of the high-level functions of this software that implement the Use Cases that are described in the Use Case document.
Functional requirements are very valuable in the design and development phase of software, because they enable the StorageVET to be used for high-priority Use Cases.
Keywords: Energy Storage, Functional Requirements, Grid Services, Analysis, Modeling, Valuation
Please use the following citation for this report:
Electric Power Research Institute. (EPRI). 2015. StorageVET: Functional Requirements. California Energy Commission. Publication Number: CEC-XXX-2015-XXX.
iv
v
TABLE OF CONTENTS ....................................................................................................................................................................... i
Acknowledgements ................................................................................................................................. ii
ABSTRACT .............................................................................................................................................. iii
TABLE OF CONTENTS ........................................................................................................................ v
EXECUTIVE SUMMARY ...................................................................................................................... 1
CHAPTER 1: Introduction ....................................................................................................................... 2
Locations ................................................................................................................................................. 2
Technologies ........................................................................................................................................... 3
Services .................................................................................................................................................... 4
Scenarios .................................................................................................................................................. 6
Report Overview .................................................................................................................................... 7
CHAPTER 2: Functions ............................................................................................................................ 8
Application Functions ........................................................................................................................... 8
Use Case Mapping ............................................................................................................................. 8
Application Function Descriptions .................................................................................................. 8
Scenario Functions ................................................................................................................................. 9
Use Case Mapping ............................................................................................................................. 9
Scenario Function Descriptions ...................................................................................................... 10
Investment Reporting Functions........................................................................................................ 15
Use Case Mapping ........................................................................................................................... 15
Investment Reporting Function Descriptions .............................................................................. 15
Operational Reporting Functions ...................................................................................................... 17
Use Case Mapping ........................................................................................................................... 17
Operational Reporting Function Descriptions ............................................................................. 17
Physical Reporting Functions ............................................................................................................. 17
Use Case Mapping ........................................................................................................................... 17
vi
Physical Reporting Function Descriptions ................................................................................... 17
Market Functions ................................................................................................................................. 18
Use Case Mapping ........................................................................................................................... 19
Market Function Descriptions ........................................................................................................ 19
Operator Functions .............................................................................................................................. 21
Use Case Mapping ........................................................................................................................... 21
Operator Function Descriptions..................................................................................................... 21
Location Functions ............................................................................................................................... 22
Use Case Mapping ........................................................................................................................... 22
Location Function Descriptions ..................................................................................................... 22
Technology Functions ......................................................................................................................... 23
Use Case Mapping ........................................................................................................................... 23
Technology Function Descriptions ................................................................................................ 23
Service Functions ................................................................................................................................. 25
Service Function Descriptions ........................................................................................................ 25
Time Functions ..................................................................................................................................... 32
Use Case Mapping ........................................................................................................................... 32
Time Function Descriptions ............................................................................................................ 32
Indexes and Tools ................................................................................................................................ 33
Use Case Mapping ........................................................................................................................... 33
Index and Tool Function Descriptions .......................................................................................... 33
Indexes and Tools Module Structure ............................................................................................ 33
Parking Lot Functions ......................................................................................................................... 33
computeBeneficialIntervalsByOperator() ..................................................................................... 33
defineTimeModel() .......................................................................................................................... 34
Other() ................................................................................................................................................ 34
CHAPTER 3: Interfaces .......................................................................................................................... 35
vii
Module Interface .............................................................................................................................. 35
User Input Interfaces ........................................................................................................................... 35
Display Module ................................................................................................................................ 35
Benefits Module ................................................................................................................................ 36
User Interface Module ..................................................................................................................... 36
External Interfaces (Andres) ............................................................................................................... 37
Inputs ................................................................................................................................................. 37
Outputs .............................................................................................................................................. 38
User Inputs and Data ....................................................................................................................... 38
Internal Interfaces ................................................................................................................................ 39
Scenario Interfaces ........................................................................................................................... 39
Financial Interfaces .......................................................................................................................... 39
Market Interfaces .............................................................................................................................. 42
Service Interfaces .............................................................................................................................. 43
Technology Interfaces ...................................................................................................................... 44
Applications .......................................................................................................................................... 45
References................................................................................................................................................. 46
1
EXECUTIVE SUMMARY StorageVET Model Structure
This is an updated version of the ESVT modeling appendix. It includes all the model equations, variables, and parameters. It is a general description, for use across different markets.
StorageVET Use-Case and Functional Requirements
These two documents combine both general attributes and California specific use cases. They are stand-along deliverables under the CEC requirements.
StorageVET: California Power Market Details and User Guidelines
This is about California-specific details and applications, as well as how to interpret StorageVET results in the context of actual storage operations in the CAISO markets, etc.
ESIC Modeling Guidelines
This is a general survey of model types and applications, which includes price-taker type models and others. It is intended as helpful for model selection and interpretation of results across the board.
This is an interim report. The final report will have a more extensive an Executive Summary.
2
CHAPTER 1: Introduction This document describes functionality of the StorageVET software. It is derived mostly from processes in the StorageVET Use Cases document.
Studying the detailed functionality of the Use Cases is important, because it is the foundation for software development and it gives the development team the ability to see the whole picture of not only what StorageVET must do, but also it allows the team to see how it can be done. This Functional Requirements foundation and investigation of how to make StorageVET achieve this functionality gives the necessary insight into designing the software architecture that is capable of implementing this functionality.
As a developer of StorageVET, one should strive not only to understand the requirements, but also to imagine how to implement them. The developer should imagine how certain functions, perhaps in slightly different forms, are reused over and over, which is an indicator of core functions that require added flexibility and efficient performance for good results in multiple contexts. Additionally, the developer should think about processes and precedence of functions, so that the functional modules have the right starting and ending conditions and fit together properly.
The Functional Requirements have the following major context parameters:
β’ Location β Location is specified generally according to the grid connection, whether transmission, distribution, or behind the meter. It also may include some aspects of grid integration, like the surroundings in terms of urban or rural setting, or whether there is a significant local load or generation source. Contextual price information is also an important part of the location.
β’ Technology β Storage technologies can be in the form of electrical and thermal storage, and technologies can also include non-storage benchmarks, like a combustion turbine or demand response resource, that are used to help assess performance.
β’ Services β Storage is very flexible, and there is a long list of services it can provide. These are described later in this introduction.
β’ Scenarios β StorageVET uses scenarios as a collection of values of parameters to vary in order to implement different types of analyses. Details are provided later in this introduction.
Configuring various location, technology, service and other elements as comparative scenarios and evaluating the costs and benefits is the main function in support of all use cases.
Locations The California Public Utility Commission (CPUC) web site [2] has published a reference document that helps guide the assessment of storage value.
3
Table 1: CPUC Storage Grid Domains / Locations
Storage Grid Domains
Regulatory Function Use-Case Examples
Transmission- Connected
Generation/Market
(Co-Located Energy Storage) Concentrated Solar Power, Wind + Energy Storage, Gas Fired Generation + Thermal Energy Storage
(Stand-Alone Energy Storage) Ancillary Services, Peaker, Load Following
Transmission Reliability (FERC) Voltage Support
Distribution- Connected
Distribution Reliability Substation Energy Storage (Deferral)
Generation/Market Distributed Generation + Energy Storage
Dual-Use (Reliability & Market) Distributed Peaker
Behind-the-Meter Customer-Sited Storage Bill Mgt / Permanent Load Shifting, Power Quality, Electric
Vehicle Charging Source: CPUC http://docs.cpuc.ca.gov/PublishedDocs/Published/G000/M079/K533/79533378.PDF Table 1. The locational information can include additional factors that reflect policy and economics. For instance, the California Independent System Operator (CAISO) publishes wholesale prices for electrical energy and ancillary services (a subset of Services) on a nodal basis for supply and a wider-area (zonal) basis for load. Depending on the grid connection and the rate structure, these prices can vary significantly. Even behind-the-meter storage may be affected by CAISO nodal prices.
The energy and services are heavily dependent on factors that may further help define scenarios, like fuel prices and energy policy. Additionally, they may be affected by emission policies, should certain emission limits be reached or should emission taxes be added to these prices.
Technologies The technology configuration establishes the power and energy capacities of the storage system as well as efficiency and performance characteristics. StorageVET includes a framework of technical parameters that can characterize a wide range of storage technologies including pumped hydro, compressed air energy storage (CAES), static batteries, flow batteries, ultracapacitors, superconducting magnetic energy storage (SMES), thermal storage (rooftop ice or chilled water systems, molten salt, or water heaters), dispatchable hydro, EV batteries, liquid air, and power-to-gas systems.
Non-storage technologies can also be configured to serve as benchmarks. These include combustion turbines, diesel backup generators, and demand response programs.
4
Figure 1 illustrates the most general case of energy flows considered by the technology configuration framework.
Figure 1: Energy Flow Diagram for Storage Technologies
Source: EPRI
Efficiencies and capacity limitations are key inputs in determining the range of eligible services and net load objectives the system can deliver. Specific storage technologies generally include only a subset of these energy flows. Additional technical parameters not included in this diagram include maximum ramp rate, minimum charge/discharge, degradation characteristics (by cycle or by time), and dependencies on ambient temperature.
Services Services are defined by the StorageVET services list, which is presented in Table 2.
Table 2: Overview of Grid Services
Domain Timing of Decision
Grid Service Category Grid Services
Resource Planning and Operations
5β15 years ahead
Resource Planning Resource Planning
3 years to Resource Adequacy Resource Adequacy (Generic)
5
months ahead
Resource Adequacy (Flexible)
1β3 days ahead, or annual contracts
Energy Scheduling Day-Ahead Energy Time-Shift
Real-Time Energy Time-Shift
Ancillary Services Frequency Regulation
Spinning Reserve
Non-Spinning Reserve
Frequency Response/Inertial Response Flexible Ramping
Black Start (annual contract)
Transmission 5β15 years ahead
Transmission Planning Transmission Capacity Investment Deferral Transmission Voltage Investment Deferral
Months ahead to real-time
Transmission Operations Transmission Congestion Relief
Transmission Voltage/Reactive Power Support
Distribution 3β10 years ahead
Distribution Planning Distribution Capacity Investment Deferral (Load Growth) Distribution Capacity Investment Deferral (N-1 Contingency) Equipment Life Extension
Day-ahead to real-time
Distribution Operations Distribution Losses Reduction
Conservation Voltage Reduction
Dynamic Voltage Control
Backup Power/Microgrid
Each service has an objective for an asset in order to offer a quantifiable benefit with specified minimum criteria for success or value accrual relationships. There are also specific constraints that promote or inhibit the service.
An example source of constraints is the other types of services being offered, and whether a given service has priority over others. Ownership, control, and location of an asset affect the accessible services.
There are different ownership types (utility owned, customer owned, and third-party/IPP), which further affect the objective and constraints of each service. This is because ownership affects tax incentives and impacts, rebate programs, and business models.
6
Note that ownership is different from control. For instance, a system can be owned by a third party but operated by a utility or another entity serving as scheduling coordinators (in the CAISO market). This is summarized conceptually in Figure 2.
Figure 2: Taxonomy of Services by Location and Control
Scenarios The detailed functions in those processes were collected together and revised according to similarities. Input variables that may be varied from one scenario to another are designated as scenario variables.
In the example of a single scenario variable representing an input value or option, a single defined value represents a scenario. This scenario can be represented as a point in a one-dimensional space that is defined by the range of possible values of the single scenario variable.
In the example of a collection of scenario variables, the collection of their defined values also represents a scenario. This scenario can be represented as a point in a multi-dimensional space that is defined by the ranges of possible values of the collection of scenario variables.
A set of scenarios (points) defined for the same collection of scenario variables (multi-dimensional space) is a scenario set. Out of necessity and convenience, collections of scenario variables are grouped according to similarities between the scenario variables. The types are as follows:
Location β As seen later, storage locations have three types. At least one use case investigates multiple locations, and these locations are collected in a Scenario Set of type Location.
Primary Actor Point of Connection
Create a list of grid services by
1) controlling actor and 2) location
Transmission
Utility
3rd Party / IPP
Distribution
Utility
3rd Party / IPP
Consumer
Utility
Consumer
3rd Party / IPP
7
Technology β As seen later, storage technologies can have many types. Several use cases investigate storage project performance across multiple technologies, and these technologies are collected in a Scenario Set of type Technology.
Service β As seen later, storage can perform many types of services. Most use cases investigate storage project performance co-optimized for multiple services, and these services are collected in a Scenario Set of type Service.
Uncertainty β Storage performance always depends on a tradeoff between how to schedule charging and discharging in the present versus using stored energy in the future. As such, storage valuation involves forecasts, which are prone to error. Those forecast errors that most affect the valuation can be treated as uncertainties, which are collected in Scenario Sets of type Uncertainty.
Project β A storage project is defined by location, technology, and services. Many use cases involve the simulation and comparison of multiple storage projects, which are collected in Scenario Sets of type Project.
Schedule β A storage project schedule describes its availability, state of charge and operational variables, like charging and discharging. Availability is defined as a time series of capability parameters like maximum and minimum levels of power and energy. Many use cases involve testing storage performance across multiple schedules. Such schedules are collected in Scenarios Sets of type Schedule.
Sizing β A storage project can have multiple dimensions of size, like the maximum and minimum levels of power and energy. Depending on the technology, there may be additional sizing parameters that form a sizing. These sizings are collected in Scenario Sets of type Sizing.
PQ β Power quality (PQ) involves the arrival of uncertain events of a special form, and are needed for one of the Use Cases. These events are collected in Scenario Sets of type PQ.
Backup β Backup power from a storage project is triggered by the arrival of uncertain events of a special form. These events are needed for one of the Use Cases, and are collected in Scenario Sets of type Backup.
Report Overview The chapters of this document are as follows:
β’ Functions: What the system has to do, β’ Interfaces: Environment in which the system will perform.
Additional sections may be added as this document evolves.
8
CHAPTER 2: Functions The Electric Power Research Institute (EPRI) imagines regulators as important users of StorageVET. The regulatory responsibility may benefit substantially from having a reference model, scenarios, and process for evaluating energy storage systems. Accordingly, the following use cases focus on the development and benchmarking of ESS models and scenarios and then on an ESS evaluation process that is facilitated by these reference components.
The following functions are based on priorities driven by the Use Case Document and the concept of behind-the-meter (BTM) storage, which is providing primarily end-use services and secondarily transmission and distribution services, based on a side agreement with a utility or third party.
Application Functions Use Case Mapping Application Function Descriptions screenLocations() screenTechnologies() sizeStorage() Ability to ensure storage is sized large enough for the load to be backed up. (Sizing Use Case)
[JKL] Compute optimal size and services portfolio for a variety of applications (we propose doing this via scenario analysis)
[RE] Sizing is a Use Case. Optimizing services is done naturally for those that can appear in the co-optimized dispatch model. Others are much more complex and not yet handled as well.
TBD: Consider implementing under applications the ESVT sizing that was specific to certain services. The sizing functionality can use the Services objects from which it needs data. compareBase_AlternateScenarios() For retail customers, have a total electric bill before vs. total electric bill after is an important comparison. In other words, including the fixed portions of the tariff is useful even if storage cannot address them. billSavings_Incentives() SGIP β Self-Generation Incentive Program
Inclusion of relevant rebates: e.g. SGIP (1st priority) and solar ITC (2nd priority)
ability to include pq_Backup_Incentives() Ability to change priority of PQ/Backup vs. bill savings and other revenue.
9
pq_Backup_billSavings_Incentives() billSavings_DR_Incentives() Provide valuation from multiple perspectives, as defined in California Standard Practice Manual
billSavings_WholesaleServices_Incentives() btm_WholesaleServices_PQ_Backup_Incentives() Ability to guide operation of storage with simple rules (e.g. charge off-peak only, discharge only on-peak, etc.) trans_WholesaleServices_PQ_Backup() Ability to value βincidentalβ reliability, which may not be incorporated into dispatch decisions. runMultipleSimualtionPasses() This function executes multiple simulations of different dispatch sequences for multiple incompatible services on the same storage device. Such services can be CAISO market participation, utility scheduling, and customer dispatch scheduling, which may need to be committed with different business processes and modeling horizons.
After each simulation pass, createLeftOverStorageTechnology() is used to create a new, virtual storage device that depends on the dispatch commitments of earlier simulations and a the starting storage device.
As another example, actual dispatch procedure can be split into 1) operational planning and 2) real-time operations. The dispatch procedure will be somewhat different depending on which of the 4 following types of services are in scope.
β’ Utility forecastable services (T&D load growth deferrals) β’ Utility non-forecastable services (outage-related) β’ CAISO market services
o Day-ahead market o Real-time market
β’ Customer services
Scenario Functions The Scenario Module is declared as: Module Sc_Scenario_Module 'Scenario Module'
Use Case Mapping The following table maps function names to Use Cases.
Use Case
Function 1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 checkForParameterConflicts() X X X X X X X compareScenarios() X X X X X X X X X X X X X X computeAvailability() X X X
10
createInput() X X X X X X X X defineScenarioComparison() X X X X X X X defineScenarioSet() X X X X X X displayScenarioComparison() X X X X X X X X X X X X X X displayScenarioSet() X X X X X X X X X displayScenarioVariables() X X displayTechnology() X identifyReferenceScenario() X X inputCEP() X X inputModel() X X X X X X X X X X X X X X inputScenarioComparison() X X X X X X X inputScenarioSet() X X X X X X X X X X X X X X modifyScenarioSet() X X X navigateScenarioComparison() X X X X X X X X X X X X X X outputCEP() X outputScenarioComparison() X X X X X X X outputScenarioSet() X X X X X X X X X X runScenarios() X X X X X X X X X X X X X X selectScenarioVariables() X X X selectScenario() X X selectTechnology()
Scenario Function Descriptions Following is a list of descriptions of each function:
checkForParameterConflicts() Checks the list of scenario variables and the list of Storage Project scenario variables for conflicts or overrides and reports on significant changes. First order conflicts would be those that do not correspond to the combinations of primary and secondary Scenario types used by runScenarios().
compareScenarios() Use the Scenario Set Comparison Logic to rank elements of a Scenario Set either individually or pairwise. See defineScenarioComparison() for more information about the ranking process.
If the ranking is for individual scenarios, then the Comparison Logic has one or more ranking metrics, which could be either standard versions or user-defined. If the ranking is for pairs of scenarios, then the Comparison Logic defines the pairs and has metrics for flagging significant differences in inputs and outputs between the scenarios pairs.
The scenarios can have different types, depending on the purpose of the scenario.
TBD: Describe how payback period will be reported and displayed in the GUI.
computeAvailability() StorageVET uses the storage schedule to determine the necessary required power and energy at the start and end of the operating horizon that is needed to achieve the given performance. The remaining power and energy in the system is available for other uses.
11
This analysis is conducted across all Scenarios, which may be probabilistic Uncertainty Scenarios and Operating Scenarios. StorageVET computes Storage Project statistics for performance and/or availability, depending on the Use Case.
createInput() Create individual input datasets for all Scenario Sets. This may involve a cross product of the primary and secondary Scenario Sets, as seen in runScenarios().
defineScenarioComparison() The user defines for each scenario variable the logic for Scenario comparisons. Comparison logic is an attribute of the Scenario Set and can have allowable or preferable forms, depending on the Scenario type. Generically, scenarios can be based on continuous or discrete variables. More specifically, Scenarios can have higher-order types, as defined in runScenarios(), like Uncertainty, Location, Service, and Technology. In particular, Uncertainty Scenarios may or may not have associated probabilities or weights, which enable the computation of additional metrics.
These scenario variables can have different metrics, as seen in runScenarios(), especially for the primary Scenario types. The comparisons have two forms:
β’ a ranking of individual scenario performance metrics, or β’ a ranking of difference metrics for pairs of scenarios.
The choice of Comparison depends on the cardinality of the primary Scenario Set and the secondary Scenario Set as in the following table.
Table X: Comparison Metrics
Primary Scenario Set Cardinality
Secondary Scenario Set Cardinality
Primary Comparison
Type
Secondary Comparison
Type
1 1 null null
1 >1 null P or D
>1 >1 P P or D
>1 1 P null
Sometimes, the desired ranking of one Use Case is the opposite of another. StorageVET offers the ability to choose Comparison Logic and manipulate the direction of positive performance.
Difference Metrics
Difference metrics are absolute or one-way differences between like inputs or outputs for Scenario pairs. There can be combinations of multiple difference metrics applied to the same pair of scenarios, as in cases when outputs are expected to remain within a range of values,
12
wherein the upper range has a metric for exceedances and the lower range also has a metric for exceedances.
In some Use Cases, there is a Reference Scenario used as a reference or base case. This function has the ability to use consistent metrics automatically in order to compare the Reference Scenario with the other Scenarios in the associated Scenario Set.
Performance Metrics
Performance metrics are functions of the inputs and/or outputs of a scenario. Often, these metrics are standard outputs, like the CEP metrics. They can also be user-defined.
defineScenarioSet() The user chooses from among all combinations of the values of each scenario variable those specific points in this scenario space that constitute a set of Scenarios to be run by StorageVET. The user gives this set a unique identifier.
This function may have a pre-defined Scenario Set argument that defines the type of set to define. In which case, the argument set will be used for selecting elements.
This function may have an integer argument to limit its cardinality in order to manage computation times.
This function sets the Scenario type automatically, if the new set is a subset of a pre-defined type. If not, the function assumes that the type is Uncertainty or else it may allow the user to define a new type.
Scenario Set types may have specific requirements for their elements.
Scenario Sets have attributes for creation and modification dates and version number that are maintained automatically.
In the context of a Scenario display, this function will signal changes for indicating which scenarios are added to the set.
This function allows the user to optionally specify a Reference Scenario, against which some Use Cases compare other scenarios.
displayScenarioComparison() Display for the user the top-level statistics about inputs and outputs flagged by compareScenarios() across the Scenario set. This includes major project scoring metrics as determined by the Regulator.
displayScenarioSet() Provide the user with a list of Scenarios for selection.
This display varies by the number of Scenario Sets to display, the dimension and type of each Scenario Set, and by the type of each Scenario Variable.
13
The display gives special treatment to Reference Scenarios. Each Scenario Set may have a Reference Scenario.
When there is a single Scenario Variable, this function calls displayScenarioVariable(). When there are multiple Scenario Variables, this function allows the user to view the combined space or drill down into a single Scenario Variable.
When there are multiple Scenario Set, possibly of different types, this function displays an overview of the Scenario Sets and allows the user to drill down into a specific Scenario Set.
displayScenarioVariables() Provide the user with a list of scenario variables for selection.
Variables are selected by default from the full set of data parameters. This function has an optional Scenario type argument and when provided, variables are selected from data parameters of that type.
This function has optional arguments for Scenario Sets, like Location, Service, Technology, and Project, which may further restrict the selection space.
Note that this function displays discrete and continuous variables in different, appropriate formats.
displayTechnology() Provide the user with a display of the parameters for a selected technology, and allow the user to customize the parameter settings. It is expected that StorageVET will include default generic technologies for the user to customize.
identifyReferenceScenario() The user identifies from among all of the Scenarios (subset of points in scenario space) one Reference Scenario, against which the other scenarios may be compared. The Reference Scenario is an attribute of a Scenario Set. A Scenario Set display uses special marking for the Reference Scenario.
inputCEP() StorageVET inputs a standard CEP file. This function can be used to help restart a Use Case at an intermediate step.
inputModel() The user chooses a storage project model. This model is input and populates the model and data with default values.
inputScenarioComparison() StorageVET inputs a file that contains a Scenario Comparison across for a given Scenario Set argument. This function can be used to restart a use case at an intermediate step.
14
inputScenarioSet() This function allows the user to input a defined Scenario Set. Some Use Cases create a single Scenario Set with one or more elements. Other Use Cases create a collection of related Scenario Sets. See runScenarios() for more information.
This function uses the context of a Use Case to screen the available input.
modifyScenarioSet() Allow the user to redefine the elements of a Scenario Set in order to further resolve a Comparison. This involves displaying the region of the Scenario Set having the most significant metric values, and allowing the user to zoom in on that region, if possible, to resolve the Comparison with greater accuracy.
navigateScenarioComparison() The user selects input or output comparisons and drills down into the upstream calculations to investigate the sources of the differences.
outputCEP() StorageVET creates a standard CEP output file that reports the location, technology, and size of the best Storage Projects. This file may be supplemented with information about the primary service.
outputScenarioComparison() StorageVET creates an output file that reports the Comparison based on a given Scenario Set.
outputScenarioSet() This function allows the user to output a defined Scenario Set. Some Use Cases create a single Scenario Set with one or more elements. Other Use Cases create a collection of related Scenario Sets. See runScenarios() for more information.
This function uses the context of the Use Case to determine the proper dimensionality for the Scenario Set to be output.
runScenarios() This function runs StorageVET for each element of an arbitrary Scenario Set. Scenarios are always run independently.
For some use cases, the Scenario Set is given directly as a single argumentβthe primary Scenario Set. For some Use Cases, the primary Scenario Set has only one element, as in Operator Use Cases, when there is only one defined Storage Project.
For other use cases, the Scenario Set is a cross product of the primary Scenario Set and one or more secondary Scenario Sets. These sets have allowable types that depend the Use Case.
Table X: Constructed Scenario Set Types
Primary Scenario Type Secondary Scenario Types
15
Project Uncertainty Project Schedule Location Technology x Uncertainty Sizing Technology x Uncertainty (Location, Technology, and Service) Uncertainty (Availability, Uncertainty) Uncertainty (PQ, Uncertainty) Uncertainty (Backup, Uncertainty) Uncertainty
β’ Simulations across Project Scenario Sets are run for all Uncertainty Scenario Sets. β’ Simulations across Location Scenario Sets are run for all Technology and Uncertainty
Scenario Sets. β’ Simulations across Sizing Scenario Sets are run for all Technology and Uncertainty Scenario
Sets. β’ Simulations for a given Location, Technology, and Service Scenario are run over all
Uncertainty Scenario Sets or the combinations of Availability and Uncertainty Scenario Sets or the combinations of PQ and Uncertainty Scenario Sets or the combinations of Backup and Uncertainty Scenario Sets.
selectScenarioVariables() The generic form of this function defines Uncertainty scenario variables, which are typically user-defined. Additionally, there are predefined types including Incentive, Project, Location, Technology, Service, Sizing, Schedule, and Degradation.
selectTechnology() Allow the user to select a technology from a list and possibly drill down and edit the technology attributes.
Investment Reporting Functions Use Case Mapping Investment Reporting Function Descriptions computeInvestmentNPV() NPV (for remaining cost tests)
TBD: If we compute the required upfront incentive to make customer NPV equal to 0, is that sufficient information for supporting the design of an incentive program. computeSalvageValue() computeDegradationCost() computeNetBenefitByOperator() For CAISO market services that require aggregation, include the ability to split the value between the aggregator (3rd party) and the storage operator, or include a fixed cost of aggregation.
16
For demand response program, provide the ability to the operator of the storage to change under specified conditions (e.g. peak load day or when the retail tariff is off-peak). netRIMtestBenefit() Consider reporting B/C ratio in addition. netPACTBenefit() Consider reporting B/C ratio in addition. netPCTBenefit() PCT β Participant Cost Test
Consider reporting B/C ratio in addition.
TBD: Is the Total Cost of Ownership the cost stack of the PCT?
TBD: Is the breakeven capital cost for owner the benefit stack minus non-capital costs of the PCT? netTRCBenefit() Consider reporting B/C ratio in addition. reportSGIPBenefits() SGIP β Self-Generation Incentive Program
Ability to calculate qualifying storage capacity (power, kW), while meeting qualifying minimum duration (2 hours)
Ability to change whether a rebate occurs as a lump sum or over multiple years (I think >30kW may get paid over a few years and have some M&V requirements)
Rebate with a minimum duration (including a qualifying capacity calculation)
If we verify that larger systems may receive the rebate over multiple years, we will also implement that
[UH] TBD: What are the performance incentives in the SGIP? reportDGITC() ITC β Investment Tax Credit
Ability to separately distinguish total system costs versus βITC qualifying costsβ.
Ability for user to specify the minimum percent of charging energy annually that must come from solar.
Ability to track percentage of total charged energy that originates as solar power.
β’ βITC Qualifying Costsβ calculation β’ Provision of the dispatch optimization inputs necessary to restrict charging to be only from
solar β’ Ability to impose external (user-entered) constraints on charging and discharging.
17
reportPayBackPeriod() Payback period (and implied payback period when relevant, if desired). Assume that this is based on Business As Usual (BAU) using only net load and the tariff.
TBD: Otherwise, we need a scenario for BAU and another with storage to compare. reportResidualCapacity() Residual capacity is the quantity available all hours of the year.
TBD: What is the value placed on this capacity. reportLCOC() LCOC β Levelized Cost of Capacity
TBD: What is this.
Levelized cost of capacity (for T&D, CTs, or CCGTs) reportLCOE() LCOE β Levelized Cost of Energy reportSCT() SCT β Societal Cost Test
Not a priority, because emission impacts are not in scope.
Operational Reporting Functions Use Case Mapping Operational Reporting Function Descriptions reportDispatch() This involves Services, Technologies, and Products being provided.
Currently implemented reporting hourly by month.
TBD: What other reporting frameworks are needed and what is the priority for doing this.
Reliability reports may use this functionality and select for emergency Product provision, or Technology scarcity.
Physical Reporting Functions Use Case Mapping Physical Reporting Function Descriptions reportDurationIndex() Outage duration index for any technology. reportFrequency() Outage frequency index for any technology.
18
reportExpectedUnservedProduct() reportLossOfProductProbability() reportMileage() reportDegradation() TBD: Simple explanation. reportIncidentalBackup() Report available backup service that happens to be there. This is related to Left-Over Storage Technology.
Market Functions The market functions create market models and run them. There are three types of markets:
Day Ahead β Operates in the morning before the first hour of a day, hour-ending 1 (HE1). The Operating Horizon is 24 hours. There is typically 2 days of look ahead, which means that the Dispatch Window is 72 hours.
Real Time β Operates in the 20 minutes before the quarter-hour of the Operating Horizon, which is 15 minutes in three 5-minute intervals. There is typically 2 hours of look ahead, which means that the Dispatch Window is 2.25 hours.
End Use β Operates in conjunction with either the Day Ahead or the Real Time Market, depending on whether there are End-Use Services being provided. If no End-Use Services are being provided in a given use case, then this market is not active.
StorageVET can model technologies with substantially different operating characteristics. Certain aspects of the optimization formulation are specific to only the subset of technologies that display a particular operating characteristic. There are four important categories of operating characteristics that impact the optimization and only apply to a subset of technologies:
1. the ability to charge using electric power from the grid,
2. the ability to use non-electric fuel (i.e., natural gas),
3. constraints on charging, such as start-up costs, substantial start-up times, and minimum charging levels, and
4. constraints on discharging, such as start-up costs, substantial start-up times, and minimum discharging levels.
Technologies with electric pumps (namely, pumped storage) fall in the third category. Technologies that use non-electric fuel sources (CAES and CT) fall into the fourth category. StorageVET restricts technologies that have non-trivial charging or discharging constraints to only be in one state in any given hour. Technologies that do not have substantial charging or discharging constraints (batteries and flywheels) may switch between charging and discharging an unlimited number of times within each hour. The following table outlines the key operating characteristics that impact the optimization by technology:
19
Technology Type
Charging Ability (Electric Power)
Non-electric Fuel Use
Constrained Charging*
Constrained Discharging*
Battery/Flywheel Yes No No No
Pumped Storage Yes No Yes No
CAES Yes Yes No Yes
CT No Yes N/A Yes *Constraints include non-trivial start-up costs, start-up times, and minimum operating levels
This Guide generally presents one DA and one RT optimization formulation across all technologies.
Use Case Mapping
Market Function Descriptions The StorageVET functionality for defining time functionality for the scheduling model is in createGeneralMarket() Like most optimization problems, an Energy Storage technology modelβs market revenue or net avoided fuel cost maximization problem is structured as a set of decision variables, parameters, and an objective function with a series of constraints. At a high level, the deterministic energy market revenue problem β allowing for storage technologies with start, stop and idle decisions β is structured basically the following mixed integer program:
The following objective and equations are defined where:
index t refers to the time interval, typically hour of day,
p refers to an exogenously determined price or cost,
q refers to the state of charge or state variable,
πππ‘π‘πΆπΆ and πππ‘π‘π·π· refer to charging and discharging decision variables, respectively,
c refers to an exogenously determined non-market cost, which in this case is the cost for start-up,
C refers to a vector of constraint parameters associated the decision variables, and
z refers to an Boolean (0,1) decision variable used to determine storage unit start, stop and idle states.
Objective
Objective Function: ππππππ (ππ
ππ, ππ ππ, π§π§)οΏ½οΏ½
ππ
π‘π‘=1
(πππ‘π‘ πππ‘π‘ππ β πππ‘π‘ πππ‘π‘ππ β πππ§π§ π§π§π‘π‘ )οΏ½,
Budget Balance Equations
Operational Bounds: 0 β€ πππ‘π‘ , πππ‘π‘ππ , πππ‘π‘ππ β€ πΆπΆπ‘π‘ ,
20
Integer Constraints Start, Stop and Idle Constraints: πππ‘π‘ π§π§π‘π‘ = 0, ππππ π§π§π‘π‘ = 0;π’π’π’π’π’π’π’π’π’π’π’π’π’π’πππππ’π’π’π’π’π’ πππ’π’βπ’π’π’π’πππππ’π’π’π’,
Integer Constraints π§π§π‘π‘ ππ (0,1), createDayAheadMarket()
Objective TBD: create one combined objective that includes costs of operating technologies and benefits for providing all services.
Objective Function: ππππππ (πΈπΈπΈπΈπΈπΈ_π·π·,πΈπΈπΈπΈπΈπΈ_πΆπΆ,π π π π ,π π π·π·)οΏ½οΏ½
ππ
π‘π‘=1
[(πππ‘π‘πΈπΈπΈπΈπΈπΈ πΈπΈπΈπΈπΈπΈ_π·π·π‘π‘
β πππ‘π‘πΈπΈπΈπΈπΈπΈ πΈπΈπΈπΈπΈπΈ_πΆπΆπ‘π‘ )/πΈπΈπΈπΈπΈπΈ_π π π π ] + (πππ‘π‘π π π π π π π π π‘π‘ + πππ‘π‘π π π·π· π π π·π·π‘π‘ )οΏ½,
Objective Function:
ππππππ (π π π π ,π π π·π·)οΏ½οΏ½
ππ
π‘π‘=1
(πππ‘π‘π π π π π π π π π‘π‘ + πππ‘π‘π π π·π· π π π·π·π‘π‘ )οΏ½,
Objective Function: ππππππ (πΈπΈπΈπΈπΈπΈ_π·π·,πΈπΈπΈπΈπΈπΈ_πΆπΆ, πππ π )οΏ½οΏ½
ππ
π‘π‘=1
[(πππ‘π‘πΈπΈπΈπΈπΈπΈ πΈπΈπΈπΈπΈπΈ_π·π·π‘π‘
β πππ‘π‘πΈπΈπΈπΈπΈπΈ πΈπΈπΈπΈπΈπΈ_πΆπΆπ‘π‘ )/πΈπΈπΈπΈπΈπΈ_π π π π ] + πππ‘π‘πππ π πππ π π‘π‘ οΏ½,
Objective Function: ππππππ (πΈπΈπΈπΈπΈπΈ_π·π·,πΈπΈπΈπΈπΈπΈ_πΆπΆ)οΏ½οΏ½
ππ
π‘π‘=1
[(πππ‘π‘πΈπΈπΈπΈπΈπΈ πΈπΈπΈπΈπΈπΈ_π·π·π‘π‘
β πππ‘π‘πΈπΈπΈπΈπΈπΈ πΈπΈπΈπΈπΈπΈ_πΆπΆπ‘π‘ )/πΈπΈπΈπΈπΈπΈ_π π π π ]οΏ½,
Energy Balance Constraint
21
Capacity Balance Constraint
Ramping Balance Constraint
Voltage Control Balance Constraint createRealTimeMarket() createEndUseMarket() runMarket()
Operator Functions Operator is also known as βDispatch Control Operatorβ.
Decision S_Control_Actor 'Dispatch Control Actor' = Choice(S_Control_Act_Ix,2,0)
Index S_Control_Act_Ix βDispatch Control Actorsβ = ['Utility','Customer']
The operator mostly affects the objective function, but can also cause different constraints (hard or soft) to be swapped in or out. The mechanism for constraint selection is via the compatibility and use of services. Different operator types will be responsible for providing different services via a given technology. Therefore, the operator indexes the available services and the services govern the scheduling model formulation.
Operator is used to index inputs that serve functions of compatibility and selecting input data. Examples of specific operations are:
β’ Compatibility between operator and location, β’ Compatibility between operator and services, β’ Compatibility between operator and technology type, β’ Selecting schedules of service prices (tariffs), β’ Selecting schedules for service needs, and β’ Selecting schedules for technology availability.
Use Case Mapping Operator Function Descriptions createOperator() An operator may just be an identifier that is used elsewhere for purposes of compatibility and data selection. createEndUseTariff() Variable O_Energy_Price 'Energy Price by Opt Dimensions' β This variable has the energy price from the tariff, based on an implicit selection from an internal array in the definition of O_Energy.
Variable S_E_Price_Cal βRetail Energy Price by Calendarβ <$/kWh>
TBD: Include service level agreement. Payment is made in exchange for service.
22
TBD: This may just call a method in the services module. createWholesaleMarketTariff() Variable O_Energy_Price 'Energy Price by Opt Dimensions' β This variable has the energy price from the tariff, based on an implicit selection from an internal array in the definition of O_Energy.
Variable Selected_Wholesale_P βSelected Wholesale Prices by Calendarβ <$/MWh>
TBD: This may just call a method in the services module. createRegulatedTariff() Variable O_Energy_Price 'Energy Price by Opt Dimensions' β This variable has the energy price from the tariff, based on an implicit selection from an internal array in the definition of O_Energy.
TBD: Include service level agreement. Payment is made in exchange for service.
TBD: This may just call a method in the services module.
Location Functions Decision S_Selected_Loc βSelected Locationβ β allows the user to specify a choice from the Index S_Location βLocationβ, which is defined as ['Customer Premise', 'Distribution System', 'Transmission System'].
Location is used to index inputs that serve functions of compatibility and selecting input data. The specific operations are:
β’ Compatibility between locations and services, β’ Compatibility between locations and operator type (control actor), β’ Compatibility between locations and technology type, β’ Selecting schedules of service prices (tariffs), β’ Selecting schedules for service needs, and β’ Selecting schedules for technology availability. [PS] TBD: Location also needs a sense of LAP_ID, which comes from the CAISO p-node concept for those that are serving load. There are 72 of these identifiers, we are using them because most storage will be at a load-type p-node and we need to keep the number of nodes to a minimum in order to manage the data properly. Otherwise the total number of p-nodes is over 3,000.
[PS] TBD: Location may need a sense of a climate zone.
[PS] TBD: Location may need a sense of premises, in terms of size and orientation.
Use Case Mapping Location Function Descriptions createLocation() Create a location in general that can be used to define a scenario.
23
selectLocation() [PS] TBD: To what extend does a user need a selection function to help define scenarios. Talk to Max.
Technology Functions Index Technology βTechnologyβ = ['Battery: Li-Ion', 'Battery: Sodium Sulfur', βBattery: Lead Acid', βBattery: Zinc Bromide', βBattery: Liquid Metal (Ambri)', βBattery: Na Ion (Aquion)', βBattery: Vanadium Redox', βBattery: Zinc Bromide', βBattery: Fe Cr', βUltracapacitor', βSuperconducting Magnetic Energy (SMES)', βPumped Hydro', βInclined Railroad Systems', βHydraulic Cylinder Gravity systems', βCAES: geologic adiabatic', βCAES: geologic non-adiabatic', βCAES: above ground adiabatic', βCAES: above ground non-adiabatic', βFlywheel', βWater Heater', βThermal Brick', βChilled Water', βIce', βLiquid Air', βSolar Thermal (molten salt)', βVehicle to Grid', βDispatchable Hydro', βCombusion Turbine (benchmark)', βReciprocating Backup Generator (benchmark)', βPower to Gas (CH4)', βPower to Gas (Other)']
Technoly is used to index inputs that serve functions of compatibility and selecting input data. The specific operations are:
β’ Compatibility between technology and services, β’ Compatibility between technology and operator type (control actor), β’ Compatibility between technology and location type, β’ Selecting capability for providing of energy, capacity (power), and ramping. β’ Selecting efficiencies, housekeeping power, heat rate (fuel use), self discharge rate. β’ Selecting degradation characteristics. β’ Selecting the active dispatch constraints.
Use Case Mapping Technology Function Descriptions createLoadTechnology() createGenericStorageTechnology() TBD: Second priority. createBatteryStorageTechnology() Batteries have two categories: closed cell and flow.
Input Variables
Decision Variables
ENE (t) MWh Energy state of charge (SOC) at the beginning of time interval t (market and location specific)
πππ‘π‘πΈπΈπΈπΈπΈπΈ $/MWh Market clearing price for Energy in interval t (market and location
24
specific)
ENE_C (t) MWh Energy charging scheduled in time interval t
ENE_D (t) MWh Energy discharging scheduled in time interval t
State of Charge Constraint The inter-temporal SOC constraint requires that the SOC (MWh) at the start of each interval t+1 is equal to the SOC (ENE) at the start of the prior interval t plus any energy charged in interval t minus any energy discharged during interval t:
πΈπΈπΈπΈπΈπΈπ‘π‘ + πΈπΈπΈπΈπΈπΈ_πΆπΆπ‘π‘ β πΈπΈπΈπΈπΈπΈ_π·π·π‘π‘ = πΈπΈπΈπΈπΈπΈπ‘π‘+1.
A starting SOC assumption for any interval is accomplished by fixing the variable to a MW value or a value derived as a percentage of a parameter (e.g., % of energy capacity).
TBD: include losses during charging and discharging.
Capacity Constraint The energy capacity constraints require that the net state-of-charge at the end of interval t be between the minimum and maximum energy capacity of the resource:
πΈπΈπΆπΆπππΈπΈ_πππππΈπΈ β€ πΈπΈπΈπΈπΈπΈπ‘π‘ + πΈπΈπΈπΈπΈπΈ_πΆπΆπ‘π‘ β πΈπΈπΈπΈπΈπΈ_π·π·π‘π‘ β€ πΈπΈπΆπΆπππΈπΈ_ππππππ.
The power capacity constraints determine the limits (MW) on charging (PCAP_C) or discharging (PCAP_C) for any interval t:
πΈπΈπΈπΈπΈπΈ_π·π·π‘π‘ β€ πΈπΈπΆπΆπππΈπΈ_π·π·,
πΈπΈπΈπΈπΈπΈ_πΆπΆπ‘π‘ β€ πΈπΈπΆπΆπππΈπΈ_πΆπΆ.
Ramping Constraint Each battery has ramp rate (RR) limit for energy operations, which designates the time (MW/min) to increase or decrease production from one energy dispatch point to another, typically over a pre-determined time interval:
πΈπΈπΈπΈπΈπΈπ‘π‘+1 β πΈπΈπΈπΈπΈπΈπ‘π‘ β€ π π π π
For those having multiple ramp rates depending on the state of charge or other operational factors, the StorageVET user may vary the ramp rate parameter to determine how unit operations affects market benefits.
createBenchmarkCTTechnology() createCAESTechnology()
25
createDGTechnology() This includes PV. createFlexibleLoadTechnology() Includes controlled charging of PEVs.
This is loads that have fixed energy requirements within a constrained time window, but flexibility about when the energy is provided. This includes PEV charging and Air Conditioner loads.
Ability to schedule least cost charge over the dispatch scheduling window. createDRTechnology() Ability to set discrete number of call options per time period which result in a discharge of energy storage at its rated capacity for a limited period.
createLeftOverStorageTechnology() This function enables the ability to use a different dispatch sequences for multiple incompatible services, like CAISO market participation, utility scheduling, and customer dispatch scheduling. It creates a new storage device from the dispatch commitments of earlier simulations and a given storage technology.
As an example for customer services, one can define a new storage device that has time-varying charging and discharging abilities that are based on external inputs. This is important, because a separate technical analysis in OpenDSS or other tool may identify times when the storage is not allowed to do certain things (e.g. do frequency regulation at certain times, charge on-peak, discharge during reverse power flow, etc.) createDegradationModel() Each technology should account for cycling and other measure of degradation that are due to the way it is scheduled. Depends on historic use. Current capabilities depend on the degradation. createModularStorageTechnology() Modular systems have multiple storage modules and they are installed as needed, for the benefit of services over the years, like distribution investment deferral.
Service Functions Service Function Descriptions createEnergyTimeShiftingService() This is a battery discharging to serve fixed loads.
Ability to address high bill savings discharge opportunities.
Ability to capture flat and TOU rates.
The Net Benefit is divided between the operator (likely, the customer) and a 3rd party aggregator.
26
Input Variables
πππ‘π‘πππππ π $/kWh TOU rate for electricity consumption in interval t (utility specific)
π π π π _πΆπΆπππΈπΈπ·π·π·π· MW The eligible Regulation Up capacity in the Day-Ahead market, as determined by the CAISO market rules and the storage technologyβs operational attributes
π π π·π·_πΆπΆπππΈπΈπ·π·π·π· MW The eligible Regulation Down capacity in the Day-Ahead market, as determined by the CAISO market rules and the storage technologyβs operational attributes
π π π π _πΆπΆπππΈπΈπ π ππ MW The eligible Regulation Up capacity in the Real-Time market, as determined by the CAISO market rules and the storage technologyβs operational attributes
π π π·π·_πΆπΆπππΈπΈπ π ππ MW The eligible Regulation Down capacity in the Real-Time market, as determined by the CAISO market rules and the storage technologyβs operational attributes
πππ π _πΆπΆπππΈπΈπ·π·π·π· MW The eligible Spinning Reserve capacity in the Day-Ahead market, as determined by the CAISO market rules and the storage technologyβs operational attributes
πππ π _πΆπΆπππΈπΈπ π ππ MW The eligible Spinning Reserve capacity in the Real-Time market, as determined by the CAISO market rules and the storage technologyβs operational attributes
πΈπΈππ_πΆπΆπππΈπΈπ·π·π·π· MW The eligible Non-Spinning Reserve capacity in the Day-Ahead market, as determined by the CAISO market rules and the storage technologyβs operational attributes
πΈπΈππ_πΆπΆπππΈπΈπ π ππ MW The eligible Non-Spinning Reserve capacity in the Real-Time market, as determined by the CAISO market rules and the storage technologyβs operational attributes
Decision Variables
πππ‘π‘π π π π $/MW Market clearing price for Regulation Up capacity in interval t (market and location specific)
πππ‘π‘π π π·π· $/MW Market clearing price for Regulation Down capacity in interval t (market and location specific)
27
πππ‘π‘πππ π $/MW Market clearing price for Spinning Reserve capacity in interval t (market and location specific)
πππ‘π‘πΈπΈππ $/MW Market clearing price for Non-Spinning Reserve capacity in interval t (market and location specific)
Constraints In the Day-Ahead market, a non-REM NGR resource, the eligible quantity of Regulation Up and Regulation Down, respectively, in the DAM, is:
π π π π _πΆπΆπππΈπΈπ·π·π·π· = π π π π π π πΈπΈπ π Γ πππΆπΆπΈπΈ (π’π’ = 60),
π π π·π·_πΆπΆπππΈπΈπ·π·π·π· = π π π π π π πΈπΈπ π Γ πππΆπΆπΈπΈ (π’π’ = 60),
where t is 60 minutes (the procurement interval in the DAM), and MCE is calculated on the basis of continuous dispatch over 60 minutes.
For a REM NGR resource, where MCE = 15 minutes, the eligible quantity of Regulation Up and Regulation Down, respectively, in the DAM, is:
π π π π _πΆπΆπππΈπΈπ·π·π·π· = π π π π π π πΈπΈπ π Γ 4, assumes MCE (t = 15)
π π π·π·_πΆπΆπππΈπΈπ·π·π·π· = π π π π π π πΈπΈπ π Γ 4, assumes MCE (t = 15).
In the Real-Time Market, a non-REM NGR resource, the eligible quantity of Regulation Up and Regulation Down, respectively, in the RTM, is:
π π π π _πΆπΆπππΈπΈπ π ππ = π π π π π π πΈπΈπ π Γ πππΆπΆπΈπΈ,
π π π·π·_πΆπΆπππΈπΈπ π ππ = π π π π π π πΈπΈπ π Γ πππΆπΆπΈπΈ.
Where t is 30 minutes (the procurement interval in the RTM), and MCE is calculated on the basis of continuous dispatch over 30 minutes.
TBD: Include energy losses for provision of ancillary services as a coefficient in the energy balance constraint.
The costs of energy charging due to efficiency losses when providing Regulation. These calculations are a function of the actual energy used when providing Regulation, which is on average less than the capacity reserved, and which can be called the βdispatch-to-contract ratio.β Hence, the first step is to calculate this quantity for each hour being evaluated if such data is available, or using an average based on historical data; the second step is to calculate the make-up energy quantity and costs.
Following are the methods for calculating the eligible capacity (SR_CAP, NS_CAP) on a storage technology prior to offering it into the market, which is a function of the resourceβs ramp rate (RR), the power capacity (PCAP), and the minimum continuous energy (MCE). In each case,
28
the eligible capacity is the ramp-rate constrained energy which can be sustained for the MCE period.
The eligible capacity for resources is the same in both the DAM and RTM.
πππ π _πΆπΆπππΈπΈπ·π·π·π· = π π π π πππ π Γ πππΆπΆπΈπΈ (π’π’ = 30),
πΈπΈππ_πΆπΆπππΈπΈπ·π·π·π· = π π π π πππ π Γ πππΆπΆπΈπΈ (π’π’ = 30),
where t is 30 minutes, and MCE is calculated on the basis of continuous dispatch over 30 minutes.
createReshapeNetLoadService() Ability to assess maximum peak shaving potential during demand charge assessment period (monthly or annual as tariff specifies) and set a peak shaving target.
TBD: Ability to update peak shaving target during demand charge assessment period if target is missed due to higher priority services or outage. This is secondary functionality. Consider extending the modeling horizon to get the same effect, as long as the foresight is reasonable.
Ability to alter the timeframe over which the peak load (and demand charge assessment) is considered β Some tariffs have monthly, annual, or daily demand charges. Consider handling monthly with an extended horizon. Consider handling annual with a form of Backup Power service. This is a reserve of power and energy for an unexpected discharge to meet an extreme peak period.
TBD: PV Self-Consumption Service β Does this include functionality beyond what is need for ITC?
ITC β Investment Tax Credit
TBD: System Electric Supply Capacity β reduce the system peak for reserve system (resource adequacy).
TBD: Local Electric Supply Capacity β reduce the local peak to make more local generation available. createDemandChargeManagementService() TBD: Simple guidance.
β’ Ability to capture monthly, annual (placeholder for 12-month ratchet), seasonal (placeholder for seasonal ratchet), and TOU demand charges.
createResourceAdequacyService() TBD: Simple guidance.
Input Variables
π π ππ_ππππππ_πΆπΆπππΈπΈ MW The eligible system RA Qualifying Capacity, as determined by CPUC and/or CAISO market rules and the storage technologyβs operational
29
attributes
π π ππ_πΏπΏπΏπΏπΆπΆ_πΆπΆπππΈπΈ MW The eligible local RA Qualifying Capacity, as determined by CPUC and/or CAISO market rules and the storage technologyβs operational attributes
π π ππ_πΈπΈπΏπΏππ_πΆπΆπππΈπΈ MW The eligible flexible RA Qualifying Capacity, as determined by CPUC and/or CAISO market rules and the storage technologyβs operational attributes
Resource Adequacy Net Qualifying Capacity (NQC) is a function of deliverability, as determined through power flow analysis of the available transmission. NQC is a fraction of QC.
Decision Variables
RU_D (t) MW Regulation Up scheduled in interval t using capacity available for discharging (i.e., generation providing RU)
RU_C(t) MW Regulation Up scheduled in interval t using capacity scheduled for charging (i.e., load dropping to provide RU)
RD_D (t) MW Regulation Down scheduled in interval t using capacity scheduled for discharging (i.e., generation withdrawn providing RD)
RD_C(t) MW Regulation Down scheduled in interval t using capacity scheduled for charging (i.e., load RD)
SR (t) MW Spinning Reserve scheduled in interval t
NS(t) MW Non-Spinning Reserve scheduled in interval t
Equations The Qualifying Capacity for a system or local RA resource is current calculated as the maximum production able to be sustained for 4 hours. This is a simple division calculation using the maximum energy capacity (MWh) of the resource, ECAP_MAX:
π π ππ_ππππππ_πΆπΆπππΈπΈ = π π ππ_πΏπΏπΏπΏπΆπΆ_πΆπΆπππΈπΈ =πΈπΈπΆπΆπππΈπΈ_ππππππ
4 βπ’π’.
To determine the joint value of capacity and operational services, StorageVET could utilize several different approaches to modeling resource obligations.
Capacity resources have the obligation to bid or self-schedule their full capacity into the CAISO day-ahead and real-time energy and ancillary service markets. For conventional generation, this approach is sufficient to ensure that the CAISO has the option to commit and dispatch the resource during Availability Assessment Hours. Because storage resources need to be charged,
30
and because here is no guarantee that operations are economic on all days, additional rules are needed to ensure that they are available.
To ensure that the resource discharges during a subset of peak hours we use a penalty for non-performance. This penalty ensures that the technology is available during capacity hours by setting a very high penalty for insufficient discharge during capacity hours. This is defined as a penalty to the objective function and not a constraint to avoid infeasible solutions due to the qualifying capacity constraint.
createBackUpService() Current focus is to develop functionality for BTM, but will create general functionality for other locations as a second priority.
TBD: Need to define N-1 contingency and need for backup.
Ability to backup a portion of the net load that is considered to be critical load.
When there is insufficient backup power, shed load with an associated penalty.
Ability to treat BTM DG as separate from the load.
Ability for the user to override the minimum sizing for backup.
Ability to reserve energy for arbitrary time windows.
Ability to assess marginal expected value of backup energy over time.
Ability to use information from the LBNL ICE model, SAIDI/SAIFI, locational outage probability (e.g. substation, feeder, service transformer, customer site).
Customer reliability includes the ability to size the system to be able to back up all load, ability to enter separate critical load, and islanding costs.
Customer reliability will have flexible user inputs for hourly input or one consistent annual reservation input, and for an option to specify a kW reservation or a VARS reservation (and a power factor).
TBD: Backup Power/Microgrid (Distribution) β second priority and will have further discussions about how to make this work. createPowerQualityService() Drivers are voltage flicker and ramping, over and undervoltage, and momentary outage or power spike.
Ability to configure hourly or other duration reservation of VARs or watts so that system is ready for autonomous operation.
Ability to calculate the impact of watts, VARs, and VA (apparent power) on one another (PQ circle).
31
createBlackStart() TBD: Simple guidance.
createSolarConsumptionService() Ability to include a soft constraint (financial incentive) in the optimization (e.g. 5 cents/kWh penalty for non-solar charging) to bias charging to come from solar.
Ability to force all charging energy of storage to come from the solar output createEnergyOptionService() Ability to call storage to provide energy at its rated capacity for a limited period, for a limited number of times per commitment period.
Ability to specify providing control to utility during certain hours of the day (e.g. off-peak) or certain days of the year (e.g. peak days).
createDegradationService() Ability to track cycles and depth of discharge for aging effects (See Use Case 3.7: Calibrate Degradation Model).
Account for mileage and other metrics of storage degradation.
Ability to calculate marginal cost of a cycle to consider for dispatch decision-making (especially for heavy cycling services (e.g. frequency regulation) and marginal value services (e.g. energy time-shift)).
Consider lifetime limits with replacement costs as an alternative to cycle costs.
createDemandResponseService() DR will have annual or monthly utility payment in return for reservation of capacity and duration for a specified # of events per year. This Service has the ability to provide control during peak or off-peak periods or certain days of the year (ex. peak days).
TBD: Need clarification whether peak days are user-defined or calculated within the model)
TBD: Need clarification on what the utility does with this control (simply reserves it for RA hours?)
TBD: Define Demand Response (Fast/Flexible) createDistributionCapacityDeferral() TBD: Simple guidance.
TBD: Distribution Equipment Life Extension β Is this not part of deferral? Degradation models for distribution systems is beyond scope.
TBD: Distribution Capacity Investment Deferral β Limits are based on contingency analysis and the peak load is limited by the contingency-based loading limits. createCVRService() Not a priority.
32
CVR β Conservation Voltage Reduction
Same Distribution Losses Reduction Not a priority.
createTransmissionCongestionRelief() Not a priority. Implemented through price signals and energy dispatch.
createTransmissionCapacityDeferralService() TBD: Simple guidance.
createTransmissionVoltageControlService() TBD: Transmission Voltage / Reactive Power Support.
Not a priority.
createDistributionDynamicVoltageControlService() Not a priority.
createITCService() [PS] TBD: Is this a Service or part of DG Technology.
[PS] TBD: Will the ITC have the functionality to use some percentage of solar? The range could be 0 to 100%. createSGIPService() Consider putting qualifications for SGIP as a service with payments.
Time Functions Use Case Mapping Time Function Descriptions The StorageVET functionality for defining time functionality for the scheduling model is in defineCalendar() The StorageVET calendar functionality is in the βDate Utility Moduleβ. definePlanningHorizon() TBD: Index F_Model_Years is defined in terms of βPlant Lifeβ and we need to change this to a time model that is independent of the technology.
TBD: Index βYearsβ and Index βModel Yearsβ need to be differentiated. defineOperatingHorizon() Defines the period over which dispatch decisions are being made within a single co-optimization of services. Also know as the look-ahead period.
The future period of time for which storage operation is being scheduled; Begining and ending states of charge are constrained.
Variable O_Days_per_OW 'Days per Opt Window' β time-length of the dispatch window.
Index O_Dispatch_Index βDispatch Indexβ β interval-length of the operating horizon.
33
defineDispatchInterval() Dispatch interval β simulation time-step, adjustable based on granularity of input data and user preference.
Decision βIO_Select_Intervalβ indicates a selection from the Index βInterval Choiceβ, with the current choices being from the set{'4-second','5-minute','15-minute','30-minute','1-hour','2-hour','3-hour'}. See IO_HPP for the hours per interval.
Variable IO_Hrs_per_Dispatch defines the time-length of a dispatch interval. TBD: Change name to IO_Hrs_per_Interval. defineDispatchWindow() Defines periods during which dispatch may take place, like peak periods.
[PS] TBD: Define variables for implementing a rolling horizon that enables look-ahead, rather than a more tight constraint on the terminal boundary conditions.
[PS] TBD: Include boundary conditions in the technology definition. runDispatch() [PS] TBD: Determine whether this is the same as runScenario(). We interpret this statement to mean that dispatch should have flexibility as to which intervals are computed explicitly. Financial results would then interpolated for intervals not computed explicitly.
TBD: Storage dispatch for desired time periods beyond the dispatch by month already implemented.
TBD: How do we coordinate with service-specific dispatches?
Indexes and Tools The Indexes and Tools Module is declared as: Module IT_Indexes_and_Tools 'Indexes and Tools Module'
Use Case Mapping Index and Tool Function Descriptions TBD Indexes and Tools Module Structure Module SI_mod 'Static Indexes~' Module IT_Function_librarie 'Function libraries' Module Template_Change_Log2 'Template Change Log'
Parking Lot Functions computeBeneficialIntervalsByOperator() Financial Function
It would be beneficial to identify low hanging fruit for a demand response program via a βcompareβ function that compares time increments when the customer value (participant cost
34
test) is positive and the utility value (program admin cost test) is negative. This may be an opportunity to find a win-win opportunity.
defineTimeModel() Time Function
Ability to set the duration of the simulation to one day, one week, one month, or one year is a useful function to do quick simulations and better understand what is going on in the model without information overload. This should also help testing. Only a subset of financial results will be available for shorter durations.
Other() Enable financial reporting output that allows for positive or negative grid impacts (e.g. positive frequency regulation benefit, negative energy time-shift, negative local grid impact, etc.)
Ability to change some service hierarchies, including using different dispatch sequence for CAISO market participation, utility scheduling, and customer dispatch scheduling (this is difficult to implement, and we feel strongly that there is only one services hierarchy that truly makes sense).
EVs (this would take considerable effort to implement if the charging loads are dynamic, and we think it is out of the scope of the project; using only static charging load shapes would likely result in misleading results).
35
CHAPTER 3: Interfaces This section describes interfaces between StorageVET and other software applications.
The sections of this chapter follow the following template.
Module Interface A major module of StorageVET has several sub-modules by conventions. They are as follows:
β’ Details β Details are hidden β not part of any interface. β’ Inputs β Part of the internal interface. β’ Outputs β Part of the internal interface. β’ User Inputs and Data β Part of the user interface or user inputs and outputs. β’ Shared Indexes β Not used β’ Change Log β Not useed
We now present the interfaces in terms of the major StorageVET modules.
User Input Interfaces The User Input Module is declared as: Module User_inputs 'User inputs'
Type Identifier Title Alias Day_to_Omit_from_Lea 'Day to Omit from Leap Year' Alias Load_Year1450400043 'Load Year' Alias Select_Tariff 'Select Tariff' Alias Select_Dis1450481854 'Select Dispatch Interval' Alias Charge_Cap1450724279 'Charge Capacity' Alias Discharge_1450724279 'Discharge Capacity' Alias Energy_Cap1450724279 'Energy Capacity' Alias Charge_Eff1450724279 'Charge Efficiency' Alias Discharge_1450724280 'Discharge Efficiency' Alias Minimum_Ch1450724279 'Minimum Charge Limit' Alias Minimum_Di1450724279 'Minimum Discharge Limit' Alias Interval_C1452794348 'Interval Choice' Alias Scenario_definitions 'Scenario definitions' Alias Result_by_scenario 'Result by scenario' Alias Results_from_scenari 'Results from scenarios' Alias Select_load 'Select load'
Display Module The Display Module is declared as:
36
Module Dispatch_Display 'Dispatch Display'
Type Identifier Title Decision Display_Month 'Month' Variable Peak_Load_Day_for_Mo 'Peak Load Day for Month' Variable Load_by_Dispatch 'Load by Dispatch' Decision Day_of_Month 'Day of Month' Variable Storage_Activity[IO_D_Dispatch,Storage_Effect] 'Storage Activity' Variable Load_Comparison[Storage_Effect,IO_D_Dispatch] 'Load Comparison'
Benefits Module The Benefits Display Module is declared as: Module Benefits_Display 'Benefits Display'
Type Identifier Title Variable Retail_Energy_Cost_S 'Retail Energy Cost Savings' Variable Retail_Demand_Charge 'Retail Demand Charge Savings' Variable Wholesale_Energy_Cos 'Wholesale Energy Cost Savings' Variable Resource_Adequacy_Av 'Resource Adequacy Avoided Cost' Variable Retail_Energy_Cost 'Retail Energy Cost' Alias Storage_Ef1456213950 'Storage Effect' Variable Retail_Demand_Charg1 'Retail Demand Charge' Variable Wholesale_Energy_Co1 'Wholesale Energy Cost' Alias Retail_Energy_Price_ 'Retail Energy Price by Calendar' Alias Load_Compa1456215850 'Load Comparison' Alias Selected_W1456217222 'Selected Wholesale Prices by Calendar' Variable Benefit_Results[Benefit,Undefined] 'Benefit Results'
User Interface Module The User Interface Module is declared as: Module UI_Mod 'User Interface Module'
Type Identifier Title Module UI_Introduction 'Introduction' Module UI_Data_Import 'Data Import' Library ACP_option_library 'ACP style library' Module UI_Technologies 'Technologies' Module UI_Services 'Valuation Services'
Module UI_Location_and_Tari 'Location and Tariffs'
Module UI_Dispatch2 'Dispatch Services' Module UI_Financial_results 'Financial results' Module UI_Scenarios 'Scenarios'
37
External Interfaces (Andres) The Data Module is declared as: Module IO_Data_mod 'Data Module'
Inputs Module IO_Inputs 'Data Import and Export Inputs' Services Input Data StorageVET is expected to have interfaces to price data from the CAISO and utility tariffs. The CAISO data may be either nodal or zonal, depending on tariff decisions from the CPUC. The CAISO nodal data is very detailed and has a very large quantity. This makes it more difficult to manage.
Utility tariff information is also available via OpenEI (see below).
Services have qualitative information about the service and its behavior, along with price data about its value.
Energy Input Data
Type Identifier Title Alias IO_Energy_Pri1450481 'Energy Price by Calendar' Alias IO_Peak_Perio1450481 'Peak Period By Calendar'
Ancillary Services Input Data TBD: Behavior and value Technology Input Data StorageVET has an interface for importing the ESIC cost template. User enters detailed storage project cost information and those outputs imported with StorageVET and used as project cost inputs.
The cost template is an Excel macro file, called βUpdated ESIC Cost Tool-Filter.xlsmβ.
Services have qualitative information about the service and its behavior, along with cost data.
Battery Input Data TBD: Behavior and costs
CAES Input Data TBD: Behavior and costs
38
Load Input Data
Green Button data is used to characterize customer sites.0F
1 StorageVET is expected to include the ability to download or otherwise import Green Button data that will help define scenarios regarding locations.
Weather Input Data StorageVET is expected to be populated with useful weather data that can be used to help determine storage performance and other related items.
Time Input Data Type Identifier Title Alias IO_Date_Utili1450482 'Date Utility Inputs'
OPEN EI OpenEI is a source of end-use energy data.1F
2 It contains specific information on buildings, energy, efficiency, consumption, demand, and potential.
Outputs Module IO_Outputs 'Data Import and Export Outputs'
Type Identifier Title Alias IO_Energy_Pri1450482 'Energy Price by Calendar and Dispatch' Alias IO_Load_by_Ca1450482 'Load by Calendar and Dispatch' Alias IO_Peak_Perio1450482 'Peak Period By Calendar and Dispatch' Alias IO_Dispatch145048356 'Dispatch' Alias IO_Dispatch145133396 'Dispatch'
User Inputs and Data Module IO_User_Inp_and_Data 'Data Import and Export User Inputs and Data'
Type Identifier Title Alias Input_Variables 'Input Variables'
1 Green Button web site: http://www.greenbuttondata.org/
2 OpenEI web site http://en.openei.org/
39
Internal Interfaces Scenario Interfaces Inputs Module Sc_Scenario_Module_I 'Scenario Module Inputs'
Type Identifier Title Alias Sc_Select_Tar1452472 'Select Tariff' Alias Sc_Al1452472825 'Scenario variables' Alias Sc_Al1452475493 'Dispatch Solution' Variable Sc_Total_revenues 'Total revenues' Alias Sc_Al1452475744 'Energy Price by Calendar and Dispatch' Alias Sc_Al1452475957 'Scenario_result_vars' Decision Sc_Select_technology 'Select technology' Alias Sc_Al1452783655 'Select load' Decision Sc_ra 'Resource Adequacy Participation' Decision Sc_Frequency_regulat 'Frequency regulation service' Alias Sc_Al1455996979 'Service Selections' Alias Sc_Al1456082358 'Flag Demand Charge Min' Alias Sc_Al1456082359 'Flag Retail Rate Arbitrage' Alias Sc_Al1456082360 'Flag Resource Adequacy Dispatch' Decision Sc_dcr 'Demand Charge Reduction' Alias Dispatch_C1456186156 'Dispatch Control' Alias Select_Who1456186662 'Select Wholesale Energy Price' Decision Sc_Retail_Energy_ts 'Retail Energy Time Shift' Decision Sc_Wholse_Energy_ts 'Wholesale Energy Time Shift'
Outputs Module Sc_Scenario_Module_O 'Scenario Module Outputs'
This module is empty.
TBD: Are there really no outputs for other modules? User Inputs and Data Module Sc_Scenario_Module_U 'Scenario Module User Inputs and Data'
Type Identifier Title Alias Sc_Al1456087401 'Scenario input variables'
Financial Interfaces The Financial Module is declared as: Module IO_Change_Lod 'Data Import and Export Change Log'
40
Inputs Type Identifier Title Alias New1454960619 'Dispatch Solution' Alias New1454960620 'Energy Price by Calendar and Dispatch' Alias New1454960621 'Load by Calendar and Dispatch' Alias New1454960622 'Peak Period By Calendar and Dispatch' Alias New1454960623 'Technology Characteristics' Alias New1454960624 'Imported Technology Characteristics' Alias New1454960625 'Hours per Dispatch' Alias New1454960629 'Month' Alias New1454960630 'Day of Month' Alias New1454960631 'Dispatch' Alias New1454960632 'Hour of Year' Alias New1454960635 'Day365 by Month/Date' Alias New1454960636 'Peak Status' Module F_From_Services 'From Services Module'
Outputs Type Identifier Title Alias New1454960639 'Capital Costs of System ($/kW)' Alias New1454960640 'Fixed O&M Costs ($/kW-year)' Alias New1454960641 'Variable O&M Costs of System ($/MWh)' Alias Stacked_Utility_Cost 'Stacked Utility Costs and Benefits' Alias Stacked_Customer_Cos 'Stacked Customer Costs and Benefits' Alias Annual_Customer_Cost 'Annual Customer Costs and Benefits' Alias Annual_Utility_Costs 'Annual Utility Costs and Benefits'
Variable F_NPV_System_CB [F_CostBen_CostTest, F_CostBen_Comps_All] 'NPV System Costs and Benefits'
Alias NPV_of_Utility_Servi 'NPV of Utility Services' Variable F_Dispatch_Plot 'Dispatch Plot' Alias Dispatch_Vis_Month 'Dispatch Vis Month' Alias Dispatch_Vis_Day_of_ 'Dispatch Vis Day of Month' Alias Dispatch_Vis_Week 'Dispatch Vis Week'
User Inputs and Data Type Identifier Title Decision F_Inflation 'Inflation'
Decision F_Debt_Pct [Ownership_type1, Financing_Assumption] '% Debt'
Decision F_Equity_Pct '% Equity' Decision F_Debt_Interest_Rate 'Debt Interest Rate' Decision F_PctCostsFinanced '% of System Cost Financed'
41
Decision F_State_Tax_Rate 'State Income Tax Rate' Decision F_Federal_Tax_Rate 'Federal Income Tax Rate' Decision F_Property_Tax_Rate 'Property Tax Rate' Decision F_Federal_ITC 'Federal Investment Tax Credit' Decision F_AftTaxNominalWACC 'After Tax Nominal WACC' Decision F_OwnershipType_sel 'Selected Ownership Type' Decision F_UpfrontPayment 'Whether or Not Owner Pays All Costs Upfront' Decision F_StateRebate_perkW '$/kW State or Local Rebate'
Decision F_Debt_Equity_Term [IO_TC,IT_Storage_Systems] 'Debt/Equity Term'
Decision F_AS_Cost_Share 'AS Cost Share' Decision F_Program_Cost_input 'Program Cost' Decision F_LossFactorInput 'Loss Factor Input' Alias Day_Ahead_1455662503 'Day Ahead Energy Prices' Alias Energy_Pri1455662503 'Energy Price Input Time Interval' Alias Select_Tar1455663753 'Select Tariff' Alias Distributi1455663847 'Distribution Upgrade Price ($/kW)' Alias Distributi1455663848 'Distribution Load Input Time Interval' Alias Distributi1455663849 'Distribution Network Load' Alias Load_Growt1455663847 'Load Growth Rate (%/yr)' Alias Upgrade_Si1455663847 'Upgrade Size' Alias Upgrade_Th1455663847 'Upgrade Thresholds by Season' Alias System_Loa1455664127 'System Load' Alias A__of_Capa1455664127 '# of Capacity Hours Per Month' Alias A__of_Capa1455664128 '# of Capacity days by month' Alias A__of_Top_1455664127 '# of Top Capacity Hours Per Year' Alias Cost_of_Ne1455664127 'Cost of New Entry ($/kW-year)' Alias Daily_Capa1455664127 'Daily Capacity Hours by Month' Alias Resource_B1455664127 'Resource Balance Year' Alias Selected_C1455664127 'Selected Capacity Hours Method' Alias Start_Year1455664127 'Start Year Resource Adequacy Payment ($/kW-year)' Alias System_Loa1455664128 'System Load Input Time Interval' Alias Distribution_Network 'Distribution Network Upgrade Lifetime' Alias Transmissi1455736630 'Transmission Load Input Time Interval' Alias Transmissi1455736631 'Transmission Upgrade Size' Alias Transmissi1455736632 'Transmission Upgrade Price ($/kW)' Alias Transmissi1455736633 'Transmission Bus Upgrade Thresholds by Season' Alias Transmissi1455736634 'Transmission Network Upgrade Lifetime' Alias Transmissi1455736635 'Transmission Bus Load Growth Rate (%/yr)' Alias Transmissi1455736636 'Transmission Network Load' Decision F_Consum_Incent 'Incentive Payments' Decision F_PGE_Loss_Def[0,SI_30min_day] 'PG&E Loss Definition'
42
Decision F_SCE_Loss_Def 'SCE Loss Definition' Decision F_SDGE_Loss_Def 'SDG&E Loss Definition' Decision F_MACRS_Term_Sel 'MACRS Term' Alias Selected_Avoided_Cos 'Selected Avoided Costs'
Market Interfaces The Market Interfaces are implemented in the Dispatch Optimization Module, and it is declared as: Module O_mod 'Dispatch Optimization Module' Inputs Module O_Inputs 'Dispatch Optimization Inputs'
Type Identifier Title Variable Final_SOC Final State of charge Alias Dispatch_P1449081754 Dispatch Period Alias Charge_Cap1449081754 Charge Capacity Alias Discharge_1449081754 Discharge Capacity Alias Energy_Cap1449081754 Energy Capacity Alias Charge_Eff1449081754 Charge Efficiency Alias Discharge_1449081755 Discharge Efficiency Alias Minimum_Charge_Limit Minimum Charge Limit Alias Minimum_Discharge_Li Minimum Discharge Limit Alias Hours_per_Peroid Hours per Peroid Variable Initial_SOC Initial SOC Alias Hours_per_1450396444 Hours per Dispatch Period Alias Peak_Statu1450396444 Peak Status Alias Dispatch_P1450396444 Dispatch Period Alias Peak_Perio1450396444 Peak Period Map Alias Day_of_Mon1450396444 Day of Month Alias Dispatch_P1450396523 Dispatch Period Alias Charge_Cap1450396523 Charge Capacity Alias Discharge_1450396523 Discharge Capacity Alias Energy_Cap1450396523 Energy Capacity Alias Charge_Eff1450396523 Charge Efficiency Alias Discharge_1450396524 Discharge Efficiency Alias Minimum_Ch1450396523 Minimum Charge Limit Alias Minimum_Di1450396523 Minimum Discharge Limit Alias Hours_per_1450396523 Hours per Peroid Alias Final_Stat1450396523 Final State of charge Alias Energy_Pri1452794056 Energy Price by Calendar and Dispatch Alias Load_by_Ca1452794057 Load by Calendar and Dispatch
43
Alias Peak_Perio1452794057 Peak Period By Calendar and Dispatch Outputs Module O_Outputs 'Dispatch Optimization Outputs'
Type Identifier Title
Variable EA_Dispatch[SI_Month,SI_Day_of_Month] Dispatch Solution
Variable SOC2 SOC User Inputs and Data Module O_User_Input 'Dispatch Optimization User Inputs and Data'
This module has no content.
Service Interfaces Module S_Services_Module 'Services Module' Inputs Type Identifier TItle Variable T_Cycle_Life_Profile Selected Cycle Life Profile Alias New1457582270 Peak Status Alias New1457582271 Holiday Alias New1457582272 California IOU Alias New1457582273 Dispatch Solution Alias New1457582274 Hours per Dispatch Alias New1457582275 Daily Dispatch Alias New1457582276 Day of Month Alias New1457582277 Month Alias New1457582278 Season Alias New1457582279 Day of Year Alias New1457582280 Day365 by Hour8760 Alias New1457582281 Hour of Year Alias New1457582282 Month by Day Alias New1457582283 Day365 by Month/Date Alias New1457582284 Imported Technology Characteristics Alias New1457582285 Technology Characteristics
Outputs Module S_Outputs 'Services Modules Outputs'
Type Identifier Title
Objective S_Services_Hierarchy [S_Active_Hierar_Step, S_Placeholders] 'Services Hierarchy'
Module S_kW_and_kWh_Reqs 'Energy and Capacity Requirements'
44
Module S_Outputs_Non_Opt 'Outputs for Non-optimized Services' Module S_Reg_Outputsfor_Opt 'Frequency Regulation Outputs for Optimization' Module S_Retail_Rates_mod 'Retail Rates' Module S_WholesalePrice_Mod 'Wholesale Prices' Module S_Constraints_on_BTM 'Hard Constraints on Disptach' Module For_Avoided_Cost_Cal 'Avoided Cost Inputs and Indexes' Module S_Soft_U_Constraints 'Soft Constraints on Dispatch' Alias New1457582292 'Service Compatibility Check' Alias New1457582338 'Flag Demand Charge Min' Alias Dispatched_Services 'Dispatched Services'
User Inputs and Data Type Identifier Title Decision S_Control_Actor 'Dispatch Control Actor' Decision S_Service_Selections 'User Dispatch Service Selections' Decision S_Whole_E_Price_Sel 'Select Wholesale Energy Price' Decision S_Selected_Tariff 'Select Retail Tariff' Module S_Market_Prices 'Market Prices and Scheduling Constraints' Module S_Capacity 'System and Local Capacity' Module S_Retail_Rates 'Retail Rates' Module S_TandD_Deferral 'T & D Deferral' Decision S_Selected_Loc 'Selected Location' Decision S_Days_in_Dispatch_P 'Days in Dispatch Period' Decision S_Model_Start_Year 'Model Start Year' Alias Selected_Ownership_T 'Selected Ownership Type'
Technology Interfaces Module T_mod 'Technology Module'
Inputs Module T_Inputs 'Technology Inputs'
This module is empty. Outputs Module T_Outputs 'Technology Outputs'
Type Identifier Title Alias T_Chg_Cap1450398254 'Charge Capacity' Alias T_Dschg_Ca1450398254 'Discharge Capacity' Alias T_Energy_C1450398254 'Energy Capacity' Alias T_Chg_Eff1450398254 'Charge Efficiency'
45
Alias T_Dschg_Ef1450398254 'Discharge Efficiency' Alias Minimum_Ch1450395639 'Minimum Charge Limit' Alias Minimum_Di1450395640 'Minimum Discharge Limit'
User Inputs and Data Module T_User_Input 'Technology User Inputs and Data'
This module is empty.
Applications StorageVET is expected to interface with the CEP data format [3], which will help define input and performance metrics for storage projects. This format may also be useful when interfacing with other applications that are used to simulate storage projects.
The StorageVET project team is investigating the need for interfacing with other applications for simulating storage. This activity is ongoing and will be further documented in later drafts of these Functional Requirements.
46
References [1] U.S. EIA (2015). Annual Energy Outlook 2015: With Projections to 2040. U.S. Energy Information
Administration report 0383(2015). April 2015. http://www.eia.gov/forecasts/aeo/pdf/0383(2015).pdf
[2] CPUC Storage website. http://www.cpuc.ca.gov/PUC/energy/storage.htm
[3] CPUC (2014). Consistent Evaluation Protocol (CEP) for Energy Storage Benchmarking and General Reporting Purposes, December 1, 2014. http://www.pge.com/includes/docs/pdfs/b2b/wholesaleelectricsuppliersolicitation/Energy_Storage/Final_CEP.pdf
47
APPENDIX A TABLE OF ACRONYMS AEO β Annual Energy Outlook
CAES β compressed air energy storage
CAISO β California Independent System Operator
CPUC β California Public Utilities Commission
CEP β Consistent Evaluation Protocol
DER β distributed energy resource
DRP β distribution resources plan
ESS β energy storage system
FERC β Federal Energy Regulatory Commission
IPP β independent power producer
PQ β power quality
SOC β state of charge
T&D β transmission and distribution
TOU β time of use
48
APPENDIX B: STORAGEVET INPUT INFORMATION StorageVET input data reflects multiple levels of information over a future operations or planning period.
National Information National-level information describes things like fuel prices, economic conditions, financial parameters, national policies, and any other inputs that are not much affected by location. National information should be internally consistentβfor example, relatively high fuel prices and interest rates are not usually associated with sustainable economic conditions. A good source of U.S. national information, with multiple important scenarios, is the Energy Information Administration (EIA) Annual Energy Outlook (AEO) [1]. The 2015 version of the AEO has a reference scenario and sensitivity scenarios that investigate future economic growth and alternative natural gas and oil prices.
Location-Specific Information Location-level information describes electricity prices, incentive programs, connection charges, and capital costs.
Electricity Market Information Descriptions of electricity market products and price information are available commercially and from planning processes of the California Energy Commission and CAISO. Products include the following:
Energy β Energy is traded multiple times per day, for different commitment periods. A common product used in valuation is the day-ahead energy (DAE), which is traded about one day prior to the start of the commitment period (usually midnight) for a duration of 24 hours.
Ramping β The net load changes over short durations of hours, and these changes, up and down, can be significant to the extent that they affect resource adequacy and grid reliability. The CAISO is considering new services provided generally by controllable resources, of which storage can be a significant provider.
Ancillary Services β These services are reservations of power transfer capability for minimum duration times. A list was provided in Table 2.
Capacity β Often defined as the ability of storage to transfer power for a minimum duration of 4 hours during peak load periods. The peak period is typically during summer months during hours of highest net load (14:00 β 18:00).
Avoided T&D Costs Because energy storage can reduce net load during peak demand periods, capacity requirements for transmission and distribution (T&D) infrastructure can be reduced. In some
49
cases, operational expenses can also be reduced by energy storage. For example, storage may ameliorate congestion on certain transmission paths, reducing losses. All quantifiable avoided costs, whether capital or operational, are considered economic benefits of energy storage.
StorageVET Configuration StorageVET is designed to answer the following general questions. Some use cases may only consider a subset of these:
β’ Is a storage system with given technical characteristics capable of modifying a load such that the resulting net load meets certain requirements?
β’ Can a storage system with given technical characteristics provide ancillary services with specific requirements?
β’ Can a storage system with given technical characteristics successfully avoid capital and/or operational costs that would otherwise be incurred?
β’ How should an energy storage system be dispatched in order to maximize the combined benefit of available services, net energy revenue, and avoided costs?
Depending on which of these questions are relevant to a particular use case, the following data and configuration inputs may apply. In general, the user can either select available data and configurations embedded in the tool or enter custom data and configuration parameters.
Location and Operational Parameters β’ Define location (for example, transmission, distribution, or behind the meter) β’ Define operational restrictions or predetermined dispatch schedules β’ Service selections and dispatch objectives β’ Define pass/fail objectives for desired net load required to successfully achieve avoided
costs β’ Select services of interest and describe energy cost/revenue schedules β’ Technology Configuration (some quantities are potentially dependent on ambient
temperature or state of charge) β’ Specify charge/discharge capacity and ramping characteristics β’ Specify energy storage capacity or duration of discharge at maximum power β’ Specify charge/discharge/self discharge efficiency losses β’ Characterize degradation effects of the storage system (may be in terms of cycle life, total
mileage, or time) β’ Quantify the cost of consumables (for example, fuel heat rate for a CAES or CT benchmark
system).
Operational Limitations Describe time-dependent operation limitations, which may result from statutory, technical, or operational reasons. These may be quantified in terms of min/max charge/discharge power, or required states of charge at specific times.
50
Economic Perspective Select the economic perspective for which valuation is desired. Quantify key economic parameters such as discount rate or fuel prices.
1
APPENDIX C: USE CASE TERMINOLOGY Actors Actors are associated with roles and physically take the form of people and objects that interact.
StorageVET The common actor in these use cases is the StorageVET software application. Each process typically has one step to run Storage VET.
Regulator StorageVET is imagined to be a tool used by a utility regulator.
Investors StorageVET is imagined to be a tool used by an energy storage system (ESS) investor.
Stakeholders Stakeholder actors are generally part of proceedings to approve storage projects.
Program Administrator The program administrator is a specific role in a utility or regulatory commission tasked with running an incentive program for energy storage systems.
Participant A participant receives incentives from an incentive program for building and operating an ESS. Participant behavior, in the form of operational and planning decisions, is affected by the design of the incentive program, and they give qualitative feedback on the design and implementation in terms of ease of understanding, fairness, and implementability.
Researcher StorageVET is imagined to be a tool for ESS researchers. Researchers are involved in all aspects of ESS design, and they may use StorageVET to help represent the economic viability of a storage project or to help develop a detailed model of a specific storage project.
Market Designer A market designer is a role that imagines and evaluates electricity market design features. StorageVET may be useful for helping to test the impact that storage may have on electricity markets.
Vendor A vendor is the role of a person or organization that develops energy storage systems. Vendors may interact directly with a storage development program or indirectly through a utility.
2
Storage/DER Operator An operator is a person or organization that operates an ESS or distributed energy resource (DER) device. Operators may use StorageVET to assist in operational decision-making.
Information Exchange During the use case process, the actors exchange information to accomplish their tasks. As an example, one or more actors may prepare input files for StorageVET, which is run, and then StorageVET may provide its output files to one or more actors.
Process A use case process has three parts:
β’ Starting Condition β a set of assumptions and available information used to begin the process β’ Steps β one or more steps that involve information processing and exchange between the
actors β’ End Result β the set of information used for decision support toward meeting the use case
goal
Exceptions Any part of the process may lead to not having a successful completion along a primary process. In this event, the process may undergo a subprocess to handle the exception. If no such subprocess exists, then the use case process ends in failure. Otherwise, the subprocess leads the actor(s) through steps to resolve the unsuccessful part of the primary process and returns to the following step in order to proceed with the primary process.