Use Case Document
Version:	DRAFT 1.0	
Created:	Saturday, October 31, 2009	
Last Update:		
Print Date:		
By:	NAESB Smart Grid Task Force	
Distribution:	Public	

Table of Contents

Use Case Document	1
1    Introduction	6
1.1    Purpose of Document	6
1.2    Glossary	6
2    Application Overview	6
2.1    Define the Scope	6
2.2    Context	6
2.3    Technical Environment	6
Use Cases	7
3    Model	7
3.1    NAESB Demand Response Use Cases for NIST Smart Grid	7
<anonymous>	8
3.1.1    Actors	9
Commercial Customer	9
Curtailment Service Provider	9
DMS	10
DR Aggregator	10
DR Asset	10
DR Asset/Resource Owner	10
DR Controlling Entity	10
DR Program Participant	11
DR Resource	11
DRMS	11
Demand Response Program	11
Distributed Energy Resource	12
Distribution Company	12
Distribution Operator	12
Electricity Consumer	12
Energy Service Provider	12
Industrial Customer	13
LMS	13
Load Serving Entity	13
Merchant Operator	13
Metering Agent	13
Regulator	13
Residential Customer	14
System and Market Operator	14
3.1.2    DR Use Cases	14
3.1.2.1    1.0 Administrate DR Program	15
1.0 Administrate DR Program	16
1.1 Create DR Program	16
Sequence Diagram	17
1.2 Update DR Program	18
Sequence Diagram	18
1.3 Remove DR Program	19
Sequence Diagram	20
3.1.2.2    2.0 Administrate Customer for DR	20
2.0 Administrate Customer for DR	21
2.1 Register / Enroll Customer for DR Program	21
Sequence Diagram	22
2.2 Update Customer Identity	23
Sequence Diagram	23
2.3 Remove Customer from DR Program	24
Sequence Diagram	25
3.1.2.3    3.0 Administrate DR Resource	25
3.0 Administrate DR Resource	26
3.1 Administrate Bulk Power DR Resource	26
3.2 Administrate Distribution DR Resource	27
3.2.1 Declare DR Resource	27
Sequence Diagram	28
3.2.2 Register DR Resource	29
Sequence Diagram	31
3.2.3 Remove DR Resource	31
Sequence Diagram	31
3.2.4 Administrate DR Asset (Direct)	32
3.2.4.1 Register DR Asset	32
Sequence Diagram	33
3.2.4.2 Update DR Asset	33
Sequence Diagram	34
3.4.2.3 Remove DR Asset	34
Sequence Diagram	35
3.2.5 Administrate DER for DR Purpose	35
3.3 DR Bidding	35
3.3.1 DR Bid to Supply (Offers)	36
Sequence Diagram	37
3.3.2 DR Bid to Buy	37
Sequence Diagram	38
3.1.2.4    4.0 Execute DR Event	39
4.0 Execute DR Event	39
4.1 Notify DR Event (Bulk Power)	40
4.1.1 Advanced Notification for DR (Bulk Power)	40
Sequence Diagram	41
4.1.2 Update a DR Event (Bulk Power) 	41
4.1.3 Cancel a DR Event (Bulk Power)	42
Sequence Diagram	42
4.1.4 DR Resource Confirmation (Bulk Power)	43
4.2 Notify DR Event (Distribution)	43
4.2.1 Advanced Notification for DR (Distribution)	43
Sequence Diagram	45
4.2.2 Update a DR Event (Distribution)	46
Sequence Diagram	46
4.2.3 Cancel a DR Event (Distribution)	46
Sequence Diagram	46
4.2.4 DR Resource Confirmation (Distribution)	47
Sequence Diagram	48
4.3 Broadcast Pricing (Wholesale) for DR Purpose	48
Sequence Diagram	50
4.4 Broadcast Pricing (Retail) for DR Purpose	50
Sequence Diagram	51
4.5 Dispatch DR Instructions (Bulk Power)	51
Sequence Diagram	53
4.5.1 Monitor DR Event (Bulk) 	53
4.6 Dispatch DR Instructions (Distribution)	53
Sequence Diagram	54
4.7 DR Direct Load Control (Distribution)	55
Sequence Diagram	55
4.7.1 Monitor DR Event (DR Resource)	55
Sequence Diagram	56
4.7.2 Monitor DR Event (DR Asset)	56
Sequence Diagram	57
4.8 DR Event Execution	57
4.8.1 DR Execution - Dynamic Price-Based	57
Sequence Diagram	57
4.8.2 DR Execution - Notification Based	58
Sequence Diagram	58
4.8.2 DR Exedcution - Direct Load Control	58
Sequence Diagram	59
4.9 Operational Coordination between Transmission, Distribution and DR Resources	59
Sequence Diagram	59
Adjust Schedule	60
Apply Retail Uplift Charges	61
Assess Congestion Uplift Charges	61
Impacted Curcuit Analysis	61
Load Forecast by Circuit	61
Specify Load Profile	61
3.1.2.5    5.0 Post DR Event Management	61
5.0 Post DR Event Management	62
5.1 Post DR Event M&V / Settlement (Open Wholesale, No Open Retail)	62
Sequence Diagram	63
5.2 Post DR Event M&V / Settlement (No Open Wholesale, No Open Retail)	63
Sequence Diagram	63
5.3 Post DR Event M&V / Settlement (Open or Not Open Wholesale, Open Retail)	64
Sequence Diagram	64

1	Introduction
This document can be  modified to reflect the company logo as well as the general corporate layout.  To create an editable copy of this template:
 - Press F8. 
 - Press the option: [Manage Templates] .
 - From this select: [New]
In the Dialog box:
- In the field: Template Name - type in a name.
- From the Copy Template drop-down - select:{use case template}.
Below are some simple introductory remarks on the purpose of the document.

1.1	Purpose of Document
The Purpose of this Document is to define the Use Case for  ...

This is to be a standard paragraph to layout that the Business Logic and the elements within the package which are laying out the Use Cases for the package under development.  This text is definable as a template by the user and stored locally.  The system variables are filled in by EA via the RTF Document Generator.

1.2	Glossary

2	Application Overview
Some text on the application Overview…
2.1	Define the Scope
Definition of the Scope of the application …
2.2	Context
This is to give a brief definition of the context in which of the application will be implemented.  Specifying the relationship this system will have to existing systems within the environment.
2.3	Technical Environment
This is to give a brief definition of any applications relevant to the system being implemented.  There needs to be a definition of the relationship between these as well as any aspects that this system is reliant upon.

Use Cases

3	Model

3.1	NAESB Demand Response Use Cases for NIST Smart Grid

NAESB Demand Response Use Cases for NIST Smart Grid
This package contains the set of Use Cases for Demand Response scenarios which may be implmented within a NIST standard Smart Grid 

Figure 1: NAESB-NIST-SMART-GRID-DR-USE-CASES

 

<anonymous>
Actors are the users of the system being modeled. Each Actor will have a well-defined role, and in the context of that role have useful interactions with the system.

A person may perform the role of more than one Actor, although they will only assume one role during one use case interaction.

An Actor role may be performed by a non-human system, such as another computer program.

 

3.1.1	Actors

Actors

Figure 2: Actors

 

Commercial Customer
A commercial business entity that consumes electricity, typically with demand between 20-200 KW. 

 

Curtailment Service Provider
An entity that provides load curtailment services on behalf of a group of electricity consumers. 

 

DMS
A system that manages the distribution network operations. 

 

DR Aggregator
An entity that has acquired curtailment rights from electricity consumers and manages the aggregate amount of capacity that is curtailable as an eligible energy or capacity resource to participate in Demand Response programs. 

 

DR Asset
An energy resource that is capable of shedding load in response to Demand Response Events, Electricity Price Signals or other system events (e.g. under frequency detection).

Examples of Demand Response Assets are: Smart Appliances, entire buildings that are under the control of an Energy Management System, Electric Vehicles.

 

DR Asset/Resource Owner
The entity that is reponsible for the DR Resource or Asset.

 

DR Controlling Entity
This is a generalized actor class and represents all the different entities that may need to manage and interact with wholesale and/or retail DR resources. It includes the followinng actors:  ISO/RTO, Distribution Company, Load Serving Entity, DR Aggregator. 

 

DR Program Participant
This may be a DR Aggregator, LSE, Distribution Company or Electricity Consumer.

 

DR Resource
DR resource is a virtual representation of one or more DR assets. 

Is similar to a DR Asset in that it is capable of shedding load in response to a triggering event. Unlike a DR Asset, which is autonomous, a DR Resource may consist of multiple DR Assets that have been aggregated to form a larger capacity or energy resource.

An apartment building with multiple electricity consumers, each one having one or more DR Assets may be considered one large DR Resource by aggregating the total load shedding capacity of all the DR Assets in the Apartment Building and representing the sum total of this capacity as one DR Resource.

A DR Resource may also consist of different types of Assets (e.g. A wind Turbine and an electric motor that work in combination to meet DR program obligations).

 

DRMS
A system that manages the demand response programs from utility point of view. Includes load control, integration with DMS, and DR program management. Uses historical and externally input data to make predictions and what-if analysis for DR purposes. 

 

Demand Response Program
A defined set of procedures and rules that enable  Electricity Consumers to temporarily change electricity consumption of a DR Asset or DR Resource in response to market or reliability conditions.  For purposes of these standards, Demand Response does not include energy efficiency or permanent Load reduction.

 

Distributed Energy Resource
Distributed energy resources are small, modular, energy generation and storage technologies that provide electric capacity or energy where it is needed*

A DER may be implemented by an Electricity Consumer to generate electricity for its own use during DR Events in order to meet load shedding obligations it may have within a Demand Response Program.

*Definition of DER provided by the Department of Energy, http://www1.eere.energy.gov/femp/pdfs/31570.pdf

 

Distribution Company
A Company that delivers electricity to end use customers and can accept energy delivery from end use customers that have some form of generation (DER).

 

Distribution Operator
The operation center of a distribution company which is responsible for the reliable delivery of electricity to end users. 

 

Electricity Consumer
Any entity that consumes electricity.

 

Energy Service Provider
A business entity that provides energy services to end users in a deregulated retail market. 

 

Industrial Customer
A industriall business entity that consumes electricity, typically with demand higher than 200 KW. 

 

LMS
Load Management System (includes load forecast)

 

Load Serving Entity
The entity that is responsible for serving the Electricity Customers Electricity needs. An LSE may also perform the role of DR Aggregator.

 

Merchant Operator
An operator of a merchant power generator which could be part of a regulated and vertically integrated utility or an Indepdent Power Producer (IPP) in a deregulated wholesale market. 

 

Metering Agent
Records the DR meter information during the time of the DR event onto persistent media.  Provides DR event meter data to the MDMS. Typically a smart meter.

 

Regulator
An entity responsible for delivering demand reductions which is compensated in accordance with policy.  

 

Residential Customer
A residential entity that consumes electricity, typically with demand lower than 20 KW, althoguh this could change with more PHEV adoption at home. 

 

System and Market Operator
The Market Operator manages the bulk electricity market and produces prices for various products. 

A System Operator is a Balancing Authority, Transmission Operator, or Reliability Coordinator whose responsibility is to monitor and control an electric system in real time (based on NERC definition).  The System Operator is responsible for initiating Demand Response Events (e.g. Advance Notifications, Deployment, and Release/Recall instructions).

ISO New England and PJM Interconnection are examples of Market and System Operators that perform this function

   

3.1.2	DR Use Cases

DR Use Cases

Figure 3: DR Use Case Overview Diagram

 

3.1.2.1	1.0 Administrate DR Program

1.0 Administrate DR Program

Figure 4: 1.0 Administrate DR Program

 

1.0 Administrate DR Program
This a high level use case, and see its sub use cases for details. 

 

1.1 Create DR Program
A DR program is created to meet one of two, or both, situations.  A DR program is created to meet a reliability need; i.e. projected insufficient energy supply, and/or for economic purposes; i.e. when market prices are peaking.

A properly designed DR program will have a clearly stated goal or objective, System Operator or Program Administrator, activation and operational protocols, and responsibilities and obligations.  The items that should be considered should include, but not limited to:
·    The type and size of Customer to be targeted
·    The type of program to be implemented; e.g. Direct Load Control, Firm Service Level, Guaranteed Load Drop, etc.
·    The type of metering to be used/required
·    Any regulatory requirements
·    Method of communication
·    Activation protocol
·    Marketing and Sales activities
·    Customer Education activities
·    Duration
·    Delivery Period
·    LSE Compensation
·    Data Exchange Protocols
·    Customer Authorization
·    Third Party Participation
·    Registration / Enrollment Process
·    Approval Process
·    Baseline Calculations
·    Settlement Process
·    Payment Process
·    M&V Methodology
·    Contractual Agreements
·    Dispute Resolution Process
·    Phase-in or Roll-out Plan

Once the DR program is developed, it should be tested which may be accomplished through a pilot program. The results of the test/pilot should then be compared against the goal/objective of the program and any needed modifications made.  Upon satisfactory results, the DR program should be filed with and approved by the Applicable Regulatory Authority, if any.  Depending on which Entity is creating the DR program, it must also be submitted and approved by the System Operator.  Finally, the DR program must be implemented.

Upon activation of a DR program, an observable demand reduction should occur.

Customer Size		Functional	
Customer Type		Functional	
Metering Type		Functional	
Program Type		Functional	
Regulatory Authority	State or federal	Functional	
Tariff Indicator	Is it a tariff based program? 	Functional	

Sequence Diagram

1.2 Update DR Program
Once a DR program is initiated, changes in various elements of the program may be required or desired.  After indentifying the specific required modification, each of the considerations identified in the Create step should be investigated to insure that there are no unintended impacts.  If there are, then further investigation and modification is required.

A regulated Entity must then present the modifications to the Applicable Regulatory Authority for approval.  The modified DR program must then be submitted to the System Operator, approved, and the changes communicated to Customers.

(Same data requirements as Use Case 1.1)

Sequence Diagram

1.3 Remove DR Program
Termination of a DR program must take into account any DR resource long term commitments in System and Market Operator programs, contractual obligations with DR Aggregators or Load Serving Entities.  In addition, State and or Federal regulatory agency filings and approvals must be considered prior to terminating a DR program.  Termination of a DR program may involve the removal of DR infrastructure, such as Direct Load Control Devices, advanced metering and pulse devices used in the M+V of the program. All outstanding payments to the DR resources should be completed prior to the termination of the DR program.

Data requirements to remove the DR program include: 

·    Contractual Agreements
·    Any regulatory requirements
·    Customer Education activities
·    Payment Process
·    Method of communication
·    Third Party Participation
·    Registration / Enrollment Process

Sequence Diagram

3.1.2.2	2.0 Administrate Customer for DR

2.0 Administrate Customer for DR

Figure 5: 2.0 Administrate Customer for DR

 

2.0 Administrate Customer for DR
This is high level use case, see it sub use cases for details. 

 

2.1 Register / Enroll Customer for DR Program
The registration/enrollment process must capture the key identifiers to enable accurate accounting of DR resources.  A requirement for a System and Market Operator or facilitating agency registration process for tracking registrations and movement of DR resources from one DR aggregator to another as may occur from time to time is required. An internet based application for the register/enrollment process is ideal for this type of program administration.  

Approval Process			
Baseline Calculations			
Contractual Agreements			
Customer Authorization			
Delivery Period			
DR Administrator	·    System and Operator
·    Utility
·    DR Aggregators
·    Energy Consultants
		
DR Resources	
		
M&V Methodology			
Metering Type	The type of metering to be used/required
		
Program Type	The type of program to be implemented; e.g. Direct Load Control, Firm Service Level, Guaranteed Load Drop, etc.
		
Registration / Enrollment Process	
		
Third Party Participation			

Sequence Diagram

2.2 Update Customer Identity
Once a DR registration is completed, changes in various elements of the registration may be required or desired.  After indentifying the specific required modification, each of the considerations identified in the register/enroll step should be investigated to insure that is accurate and complete.  

All parties (Utility, Aggregators, Energy Consultants, DR resources, Regulatory Agencies) affected by the update should be given reasonable time to review, dispute, and approve/disapprove the update(s).

(Same Data Requirements as Use Case 2.1)

Sequence Diagram

2.3 Remove Customer from DR Program
Removing a Customer Entity from a DR Program enrollment must take into account any DR resource long term commitments in System and Market Operator programs, contractual obligations with DR Aggregators or Load Serving Entities.  In addition, State and or Federal regulatory agency filings and approvals must be considered prior to removing a customer enrollment from a DR program.  

Approval Process			
Contractual Agreements			
Customer ID	Unique identifier of the customer		
DR Administrator	·    System and Operator
·    Utility
·    DR Aggregators
·    Energy Consultants
		
DR Asset ID	DR asset(s) idenfier(s)		
DR Resource ID	DR resource identifier.		
Third Party Participation			

Sequence Diagram

3.1.2.3	3.0 Administrate DR Resource

3.0 Administrate DR Resource

Figure 6: 3.0 Administrate DR Resource

 

3.0 Administrate DR Resource
This is high level use case, see it sub use cases for details. 

 

3.1 Administrate Bulk Power DR Resource

 

3.2 Administrate Distribution DR Resource
Used to administrate all the DR Resources and Assets. This includes a variety of activities surrounding the registration and management of information surrounding the DR Resources that a Controlling entity may call upon during a DR event. Before a DR Resource may be called upon it must be registered with the Controlling entity.  The administration of a DR Resource covers the following requirements:
•	Need by the Controlling entity to identify a DR Resource for communications pruposes
Need by the Controlling entity to establish DR Resource accounts for accounting purposes
Need by the Controlling entity to collect information from DR Resources prior to DR events for the purposes of detemrining which DR Resources to call upon during a DR Event
Need by the Controlling entity to collect information from DR Resources prior to DR events for the purposes of determining the nature of the DR signals to send to the DR Resources

3.2.1 Declare DR Resource

Asset-ID	Uniquely identifies a DR Asset		
DR Resoruce Operational Constraints	The are constraints that define the amount load that can be made available during a DR event and includes the following:
•	Minimum load
Maximum load
		
DR Resource Bid	This is a bid from the DR Resource.  See the DR Bidding use case for a description of the information requirements.		
DR Resource Schedule Constraints	These are a set of constraints that specify when the DR Resource will be available.  It may contain such information as:
•	Time of day schedule constraints
Black out dates
Maximum consecutive days of participation
Maximum duration of DR event participation
Minimum duration of DR event participation
Max number of times per day the DR Resource may be called
Minimum advanced notification necessary
		
DR Resrouce Identifer	This identifies the DR Resoruce.		
Effective-Start-Date	The date and time when the declared capabilities will be in effect.		
Hourly-Capacity-Availability	Amount of capacity available for interruption by hour for the period defined by effective start/end date. Expressed in Megawatts in decimal notation with 3 digit precision. 		
Message-Exchange-Pattern	The means by which price information is communicated to any party that is interested in receiving this information. The following are valid options: 
•	In-Only 
Robust In-Only
In-Out 
Refer to http://www.w3.org/TR/wsdl20-adjuncts/#patterns for complete descriptions.		
Monthy-Capacity-Availability	Average amount of capacity available for interruption by month for the period defined by effective start/end date. Expressed in Megawatts in decimal notation with 3 digit precision. 		
Source-Authentication	The recipient must have some assurance that the message was produced by a reliable, authoritative party. This will require some ability to validate the authenticity of the source and integrity of the data (e.g. digital signature applied to a price message).		
Temporary Opt-Out	This is used to temporarily opt out of DR Events and is used to over ride the normal operational constraints. The opt-out can be specified using the following criteria:
•	All events in a program indefinitely
Specific DR Event
All events in a specific time period

Sequence Diagram

3.2.2 Register DR Resource
Description:

A party with ownership, controlling intererst or administrative responsibilities for an Asset or Resource communicates status related operational information about the Asset or Resource to a controlling entity.

For example the owner of a DR resource or asset may wish to declare thier inability to shed load (an outage) due to Summer shutdown or may wish to reduce the available capacity of a resource/asset due to equipment maintenance or other causes.

Asset-ID	Uniquely identifies a DR Asset		
Available-Capacity	The total amount of power (negawatts) available from the asset/resource. Expressed in interger format representing the amount of kilowatts available.		
Customer Identifier	This is a customer identifier (e.g. account number) that signifies to the Utility who owns the DR Resource.		
DR Program Identifier	This identifies the DR program that this DR Resource is participating in.		
DR Resource Identifier	This identifies the DR Resrouce that is being registered.		
DR Resource Operational Constraints	The are constraints that define the amount load that can be made available during a DR event and includes the following:
•	Minimum load
Maximum load
		
DR Resource Schedule Constraints	These are a set of constraints that specify when the DR Resource will be available.  It may contain such information as:
•	Time of day schedule constraints
Black out dates
Maximum consecutive days of participation
Maximum duration of DR event participation
Minimum duration of DR event participation
Max number of times per day the DR Resource may be called
Minimum advanced notification necessary
		
Effective-Start-Date-Time	The start date and time which an asset/resource is available		
Location	An identifier to indicate the location of the asset/resource		
Location-type	A value used to interpret the value contained in the Location element. Examples of Location-type include:
•	Zone
Node
Zip-code
USNG		
Maximum-Duration	The maximum amount of time the asset/resource is capable of delivering power (negawatts). Expressed in hours using decimal notation. For example a value of 0.5 indicates a maximum duration of 30 minutes which the  asset/resource can reduce power consumption by the level indicated in Available-Capacity.		
Message-Exchange-Pattern	The means by which price information is communicated to any party that is interested in receiving this information. The following are valid options: 
•	In-Only 
Robust In-Only
In-Out 
Refer to http://www.w3.org/TR/wsdl20-adjuncts/#patterns for complete descriptions.		
Minimum-Duration	The minimum amount of time that an Asset/Resource Owner is willing to allow the resource/asset to be utilized during a DR event. Expressed in decimal format representing hours. For example a value of 1.5 indicates that an asset/resource must be utilized for no less than one hour and 30 minutes durign any DR event.		
Parent-Resource ID	Used by an Asset to indicate that it "belongs to" a particular Resource. Assets may be aggregated into a Resource, but are not required to. Resources are atomic and may not be aggreated.		
Report-type	Indicates the type or report being issued by the Asset or Resource Owner. This is an enumerated value containing one of the following:
•	REGISTRATION (to register a new asset/resource)
CHANGE (refers to permanent changes) 
RETIREMENT		
Response-time	The amount of time before an asset/resource is capable of meeting its full performance, in response to a request by a controlling entity to shed load. Expressed as minutes in decimal format		
Source-Authentication	The recipient must have some assurance that the message was produced by a reliable, authoritative party. This will require some ability to validate the authenticity of the source and integrity of the data (e.g. digital signature applied to a price message).		

Sequence Diagram

3.2.3 Remove DR Resource

DR Resource Identifier	This identifies the DR Resrouce that is being removed.		

Sequence Diagram

3.2.4 Administrate DR Asset (Direct)

3.2.4.1 Register DR Asset
The DR Asset registration process must capture the key identifiers to enable accurate tracking of DR assets and their capabilities. A requirement for a System and Market Operator, Load Serving Entity, DR Aggregator, or other entity facilitating the registration process (hereafter called DR Asset Administrator) is to track assets. This is done through DR asset registration and association of physical DR assets to DR resources, in order to recognize the asset and its potential contribution as part of a DR Resource.  The DR Asset Administrator ultimately administers the DR Asset registration process to recognize DR Assets that can serve as part of a DR Resource, although the customer may be party to the registration process.

Asset Operator			
Asset Owner			
Asset Physical Location			
Authorized Asset Servicers			
Date of Registration and Last Update			
DR Asset Administrator	•	System and Operator
Distribution Utility
Load Serving Entity
DR Aggregators
		
DR Asset Availability and Status 	Run Status, Setpoint, Override status, etc.		
DR Asset Identifier 	Asset Name, ID		
DR Asset Physical Capabilities 	•	Ramp Up/Down Rate, Maximum Capacity
		
DR Asset Product 	Manufacturer, Model, Version, Date of Manufacturer		
DR Asset Type 	(DG, renewable, storage, curtailable or interruptible load)		
DR Resources			
State of Registration Process			

Sequence Diagram

3.2.4.2 Update DR Asset
Once a DR asset registration is completed, changes to elements of the registration may be required or desired. After identifying the specific required modification and verification of authorization to perform the update, each of the considerations identified in the DR asset registration step should be followed to update the DR Asset information. The ability to update DR Asset information helps to ensure the asset information on record is up-to-date and complete.  

Parties that are privy to and rely on the update should be notified of updates made and have access to review and in some cases approve/disapprove the update(s).

Asset Operator			
Asset Owner			
Asset Physical Location			
Authorized Asset Servicers			
Date of Registration and Last Update			
DR Asset Administrator	•	System and Operator
Distribution Utility
Load Serving Entity
DR Aggregators
		
DR Asset Availability and Status	Run Status, Setpoint, Override status, etc.		
DR Asset Identifier 	Asset Name, ID		
DR Asset Physical Capabilities 	Ramp Up/Down Rate, Maximum Capacity		
DR Asset Product Origin 	Manufacturer, Model, Version, Date of Manufacturer		
DR Asset Type 	DG, renewable, storage, curtailable or interruptible load		
DR Resources			
State of Registration Process			

Sequence Diagram

3.4.2.3 Remove DR Asset
Removing a DR Asset must take into account any DR resource long term commitments in System and Market Operator programs, contractual obligations with DR Aggregators or Load Serving Entities.  In addition, State and or Federal regulatory agency filings and approvals must be considered prior to removing a customer enrollment from a DR program.  

Approval Process			
Contractual Agreements

DR Administrator	•	System and Operator
Utility
DR Aggregators
Energy Consultants
		
DR Resources			
Third Party Participation			

Sequence Diagram

3.2.5 Administrate DER for DR Purpose

  

3.3 DR Bidding
Demand Response Bidding occurs after the DR Assets and Resources that are to comprise the desired bid have been registered, and a bid is to be formed. The DR Bidding use case has two sub use cases, depending on the type of bid to be developed for submission: a bid to supply (i.e., an offer), or a bid to buy. The bidder may be a Customer bidding with an Aggregator or LSE, a DR Aggregator bidding up to an LSE or regional market operator, or a LSE bidding up to a regional market operator. 

Before the start of the bidding process, it is assumed DR Resources are already registered that can be selected to provide the physical resource participating in the DR Bidding program. It is also assumed that the bidder has already registered to bid with the bid receiver and has been informed on the appropriate timing and parameters for bid participation. The DR bidding process starts with the decision of the bidder to develop a bid for submission. The bidder submits its bid to the bid receiver within the appropriate time window and following set guidelines for bidding. The bidder receives information on the outcome of the submitted bid from the bid receiver, who notifies on the bid outcome (e.g., a resource award or other DR commitment). 

Examples of some types of products that may be (or become) eligible for DR bidding include: 
* Retail Emergency DR
* Retail Price-responsive DR
* Installed Capacity
* Day-ahead Energy
* Real-time Imbalance Energy
* Ancillary Service Operating Reserve
* Regulation
* Frequency Control

DR Resource Identifier	The identifies the DR Resouce that the bid is being submitted for.		
Load Amount	This is the amount of load that the DR Resource can make available during the scheduled period.		
Load Profile Schedule	This is the schedule that the DR Resource's load profile will be available.		
Offer Price	This is the price at which the DR Resource is offering their shed resource.		

3.3.1 DR Bid to Supply (Offers)
The Bid Receiver opens the forum/venue for receiving a bid. (This may include initiating the bidding process by sending initial information to Bidders indicating parameters of acceptability for bids to be made). The Bidder communicates an offer to supply a specified product/service and the pricing or other incentive structure the bidder is willing to accept for DR. (This may be as simple as the customer sending a response back to the Bid Receiver that accepts or rejects the initial bid sought, or may involve more complex bid structuring).

Each bid will have a clearly specified product or service that is being bid and pricing/incentive structure offered. The bidder also nominates the amount of and nature of supply being offered, the DR Resource to physically provide the service, and other physical parameters affecting resource availability and capability, in addition to the identity number of the bidder and resource(s) that comprise the bid.

The Bid Receiver reviews bids received and clears them, notifying the bidders of the outcome. 

The Bidder receives the notification of awards or resource commitments and uses the information internally in preparation for DR Resource Dispatch.

Bidder Identity			
Identity of Resource(s)			
Pricing structure 			
Product/Service type	Product/Service type to offer to supply		
Quantity of offer			
Resource Availability			
Resource Capability (Max Capacity) 			
Resource Physical Operating Capability 	(Ramp up/Ramp down, and type specific)		
Resource Type			
Timestamp of Bid			
Trade Date or Period 	timeframe of offer		

Sequence Diagram

3.3.2 DR Bid to Buy
The Bid Receiver opens the forum/venue for receiving a bid. (This may include initiating the bidding process by sending initial information to Bidders indicating parameters of acceptability for bids to be made). The Bidder communicates a bid to buy a specified product/service and the pricing or other incentive structure the bidder is willing to pay to avoid DR. (This may be as simple as the customer sending a response back to the Bid Receiver that accepts or rejects the initial bid sought, or may involve more complex bid structuring).

Each bid will have a clearly specified product or service that is being bid for purchase and corresponding pricing structure that is acceptable to the bidder. The bidder also includes the quantity of product/service in the bid to buy, and specifies any DR Resource(s) that can physically substitute for the product/service in the event the bid to buy is not cleared (i.e., the bidder is unwilling to pay more than the going/market outcome price for the product/service). Other information submitted include physical parameters affecting resource availability and capability, in addition to the identity (or ID) of the bidder and resource(s) that comprise the bid.

The Bid Receiver reviews bids received and clears all bids, notifying the bidders of the outcome. 

The Bidder receives the notification of resource commitments and uses the information internally in preparation for DR Resource Dispatch. 

Bidder Identity			
Identity of Resource(s)			
Product/Service type	Product/Service type to offer to supply		
Quantity of bid			
Resource Availability			
Resource Capability (Max Capacity) 			
Resource Physical Operating Capability 	(Ramp up/Ramp down, and type specific)		
Resource Type			
Timestamp of Bid			
Trade Date or Period 	timeframe of offer		

Sequence Diagram

3.1.2.4	4.0 Execute DR Event

4.0 Execute DR Event

Figure 7: Execute DR Event

 

4.0 Execute DR Event
This is high level use case, see it sub use cases for details. 

 

4.1 Notify DR Event (Bulk Power)

4.1.1 Advanced Notification for DR (Bulk Power)
Description:

One or more communications  to DR Program Particpants that a DR event is expected to be implemented by the System Operator. DR Events may be called for reliability, emergency or other situations as determined by the System Operator.

A DR Event refers to the time periods, deadlines and transitions during which Demand Resources perform. The System Operator shall specify the estimated duration and applicability of a Demand Response Event.  All deadlines, time periods and transitions may not be not applicable to all Demand Response products or services.

Effective-Start-Date-Time	The starting date and time when DR resources are expected to comply with their obligations under a DR program.	Functional	
Estimated-Duration	A decimal representation of the expected duration of the event with integers representing hours and decimal positions representing fractions of hours. For example:
•	1.5 indicates a duration of 1 hour and 30 minutes from the Effective-Start-Date-Time
	Functional	
Event-Description	A description of the resource or program event that is being announced by the System Operator.	Functional	
Event-Identifier	A unique identifer for the event. Should be expressed as a URI in accordance with http://www.w3.org/TR/uri-clarification/#uri-schemes	Functional	
Location	An identifier used to indicate the location affected by this event.
This is mutually exclusive from Target-Identifier. An event MUST pertain to either a Location or Target-Indetifier.	Functional	
Location-type	A value used to interpret the value contained in the Location element. Examples of Location-type include:
•	Zone
Node
Zip-code
USNG
	Functional	
Message-Exchange-Pattern	The means by which DR event information is communicated between parties. The following are valid options: 
•	In-Only 
Robust In-Only
In-Out 
Refer to http://www.w3.org/TR/wsdl20-adjuncts/#patterns for complete descriptions.	Functional	
Source-Authentication	The recipient must have some assurance that the message was produced by a reliable, authoritative party. This will require some ability to validate the authenticity of the source and integrity of the data (e.g. digital signature applied to a price message).	Functional	
Target-Identifier	Specific Asset or Resource affected by the event. This is mutually exclusive from Location. An event MUST pertain to either a Location or Target-Indetifier.	Functional	
TimeStamp	The date and time when the event was announced. MUST be in ISO 8601 standard format	Functional	

Sequence Diagram

4.1.2 Update a DR Event (Bulk Power) 

 

4.1.3 Cancel a DR Event (Bulk Power)
Description:

Occurs when a System Operator decides that a DR Event which was previously announced will not be implemented.

Effective-End-Date-Time	The date and time when the cancelllation is effective.	Functional	
Event-Identifier	A unique identifer that identifies the previously announced notification of DR Event which is being cancelled. MUST refer to an existing Advanced Notification of DR Event.	Functional	
Message-Exchange-Pattern	The means by which DR event information is communicated between parties. The following are valid options: 
•	In-Only 
Robust In-Only
In-Out 
Refer to http://www.w3.org/TR/wsdl20-adjuncts/#patterns for complete descriptions.	Functional	
Source-Authentication	The recipient must have some assurance that the message was produced by a reliable, authoritative party. This will require some ability to validate the authenticity of the source and integrity of the data (e.g. digital signature applied to a price message).	Functional	
TimeStamp	The date and time when the "cancellation notice" was announced. MUST be in ISO 8601 standard format	Functional	

Sequence Diagram

MUST-REFER-TO-ACTIVE-ADVANCED-NOTIFICATION
Can only be issued for an active Advacned Notification of DR event. 
4.1.4 DR Resource Confirmation (Bulk Power)

  

4.2 Notify DR Event (Distribution)
These set of interactions is used to notify a DR Resource of a DR event.

4.2.1 Advanced Notification for DR (Distribution)
This is used by the Controlling entity to send the DR Event notification (i.e. DR signal) to the DR Resource.

Controlling Entity ID	An identifier for the controlling entity issuing the DR event.		
DR Program ID	Identifier of the program that this DR event was issued for.	Functional	
DR Resource Group ID	A group which this DR Resource belongs to. Can be used for multi-cast notifications.	Functional	
DR Resource ID	Identifier of the DR Resource that this Event is intended for.	Functional	
DR Resource Operation Mode (Schedule)	Operation modes are representations of how the DR Resource should respond to the Event Data that is part of this event. Operation modes allow DR logic to be implemented within the DR Controlling entity and allow the DR Resource to respond to a much simpler representation of the DR Event data. Operation modes are simple enumerations of the values which may be scheduled during the DR Event active period.  The possible values are the following:

NORMAL - This value is used to signify that no response to the DR Event is necessary by the DR Resource.

MODERATE - This is typically used to signify a moderate level of respeonse by the DR Resource.

HIGH- This is typically used to signify a high level of response by the DR Resoure.

SPECIAL- This is typically used to signify a special circumstance to the DR Resource.
	Functional	
DR Resource Specifications	This specifies which DR Assets within a DR Resources should be used and can be specified int he following fashion:
•	Geographic location
Grid location
DR Asset group ID
		
DR Resource Type ID	I program spewcific field that can be used to identify a type of DR Resource within a DR program.	Functional	
Event Data	A collection of information that is associated with a DR event.  An instance of such information represents a specific type of information that was defined to exist for DR events when the program was first set up. For example a DR program my have been set up to use real-time pricing as the values that are sent when DR events are issued.  In that caset he information would be prices. Furthermore each type of information may have a schedule of values that are valid across the entire period for then the DR event is active. Therefore a single type of information may have multiple values each of which are valid during a different time period during the event. Each type of information has the following attributes when it is defined:
•	name
data type

The following data types should be supported:
•	PRICE_ABSOLUTE - Price number
PRICE_RELATIVE - Change in price
PRICE_MULTIPLE - Multiple of current price
LOAD_LEVEL - Amount of load based on an enumeration, i.e. moderate, high, etc
LOAD_AMOUNT - Fixed amount of load to shed in KW
LOAD_PERCENTAGE - Percentage of load to shed, i.e. 10%
GRID_RELIABILITY - Number signifying the reliability of the grid

	Functional	
Event ID	Identifier for the DR event that was created when the DR event was first issued. Should be a globally unique identifier for each Controlling entity.	Functional	
Event Schedule	Schedule for the DR Event periods. Includes the following:
•	Notification date/time
Event start date/time
Ramp time (potentially randomized)
Event end date/time (possibly specificed as a duration)
	Functional	
Test Event Flag	This attribute signifies whether this is a test event or not.  Test events may be issued by the Utility/ISO like other DR Events.
	Functional	

Sequence Diagram

4.2.2 Update a DR Event (Distribution)
Used to update a DR event that has been previously notified.  The requirements for this use case are the same as those for the "Advanced Notification for DR" use case.

Event	See the "Advanced Notification for DR" use case.		
Event Modification Number	Modification number of the DR event.  Used to indicate if the DR Event has been modified by the Utility. Each time it is modified this number is incremented.		
Modification reason code	The reason the event was modified.		

Sequence Diagram

4.2.3 Cancel a DR Event (Distribution)
This is used by the Controlling entity to notify the DR Resrouce that a DR Event is being cancelled. It should only be executed if a DR Resouce has prviously receieved notifiation of a DR Event and that event has subsequently been cancelled.

Cancellation reason code	The reason the event  is being cancelled.		
DR Event Identifier	Identifier for the event that is being canceled.		
Effective date/time	The date and time this cancellation takes effect.		

Sequence Diagram

4.2.4 DR Resource Confirmation (Distribution)
This is a confirmation messages that is sent by a DR Resource to the Controlling entity as a result of receiving a DR Signal form the Controlling entity. It may be used as an acknowledgement of the receipt of the DR signal, but it may lso contain a vaierty of information that is used to signify how the DR Resource will repsond to the DR Signal.

DR Assets Charcterisitics	The expected response characteristics of each DR Asset that is part of the DR Resource. May be needed for aggreagated DR Assets and may be as simple as whether a DR Asset is participating or its actual load profile. For each DR Asset the following should be given following:
•	Location of Asset, either geograpic or grid location
Asset schedule of participating
Asset load profile (schedule)
		
DR Resouce ID	The identifier of the DR Resource		
DR Resource Load Profile Response	Load profile response characterization of the DR Resource in response to getting the DR signal.		
Notification Received Acknolwledgement	This is an acknowledgement of the receipt of a DR notification or dispatch. It should include any necessary provisions for non-repudiation.		
Opt in/out	This is used to temporarily opt in/out of DR Events and is used to over ride the normal operational constraints. The opt-in/out can be specified using the following criteria:
•	All events in a program indefinitely
Specific DR Event
All events in a specific time period

In addition there may be a schedule associated the opt in/out state.

Sequence Diagram

4.3 Broadcast Pricing (Wholesale) for DR Purpose
Description:

The System Operator calculates the price of products per location and communicates the price to interested parties

Currency	Identifier used to interpret the price element. MUST follow ISO 4217 standard.	Functional	
Duration	The amount of time for which this price is valid, commencing at the Effective-Date-Time specified. A value of zero means price is valid until next price broadcast override.
Specified in decimal notation where integers represent minutes and decimals represent fractions of minutes. For example:
•	5 indicates that prices will be published every 5 minutes
.5 indicates that prices will be published every 30 seconds
	Functional	
Effective-Date-Time	The date and time which the price is in effect. In ISO 8601 standard format.	Functional	
Location	An identifier used to indicate an area which this price is in effect. A value of "null" indicates that the price is in effect for all areas.	Functional	
Location-type	A value used to interpret the value contained in the Location element. Examples of Location-type include:
•	Zone
Node
Zip-code
USNG
	Functional	
Message-Exchange-Pattern	The means by which price information is communicated to any party that is interested in receiving this information. The following are valid options: 
•	In-Only 
Robust In-Only
In-Out 
Refer to http://www.w3.org/TR/wsdl20-adjuncts/#patterns for complete descriptions.	Functional	
Price	Expressed in decimal notation with a precision up to 6 decimal places. Prices MAY be either positive or negative	Functional	
Product-Identifier	Identifies the type of product (e.g. energy, regulation, etc.) which this price pertains. Contains an enumeration of various products that may be offered. Extensibility MUST be supported in order to accommodate multiple jurisdictions and markets.	Functional	
Publishing-Interval	Indicates the frequency with which price information is expected to be published. Specified in decimal notation where integers represent minutes and decimals represent fractions of minutes. For example:
•	5 indicates that prices will be published every 5 minutes
.5 indicates that prices will be published every 30 seconds
	Functional	
Source-Authentication	The recipient of a "Price Message" must have some assurance that the message was produced by a reliable, authoritative party. This will require some ability to validate the authenticity of the source and integrity of the data (e.g. digital signature applied to a price message).	Functional	
TimeStamp	Indicates the Date and Time when this information was published. MUST follow ISO 8601 standard representation.	Functional	
Unique-Identifier	An identifier used to identify the message. Should be expressed as a URI in accordance with http://www.w3.org/TR/uri-clarification/#uri-schemes	Functional	
Unit-of-Measure	Indicates the unit of measure for which the price pertains. MUST be complaint with the International System of Units as defined by NIST SP 330, ref: http://physics.nist.gov/Pubs/SP330/sp330.pdf

Examples of NIST compliant units of measure include:
•	kWh
MWh 
	Functional	

Sequence Diagram

MUST-SUPPORT-IN-ONLY-PATTERN
At a minimum the "IN-only" MUST be supported. This will ensure that  any party, DR Asset or DR Resource that wishes to receive prices may access this information. 
4.4 Broadcast Pricing (Retail) for DR Purpose
Demand Response programs are designed to address different power system concerns caused by the imbalance between generation, transmission and consumption or environmental concerns. Some DR programs are conducted on a voluntary basis, where the customer can opt to maintain the level or load; some DR programs are mandatory, where either the customer loads will be curtailed under certain conditions or customer will incur financial penalties for noncompliance.

In retail market, certain “DR Messages” can be broadcasted to DR resources either directly or through Service Providers.

Based on the OpenADR discussion, broadcasting function is mainly used for volunteer or non mission critical DR massage, therefore, message acknowledgement or confirmation is optional. 

DR Source of Power/Generation

“DR Message” also can be source of power or generation. ANSI C12.19-2008 defined the following source of power/generation in Standard Table 12. 

Precondition: 

The DR controlling entity sends the DR message to service providers. In the case of DR pricing, DR controlling entity calculates the wholesale price per location and communicates the appropriate price associated with the DR product to service providers. 

Post Condition:

DR Resources received the DR pricing information, and may or may not act based on the DR agreement or contract. 

Same as the wholesale pricing use case			

Sequence Diagram

4.5 Dispatch DR Instructions (Bulk Power)
Description:

Instructs a DR Asset or Resource to change its consumption level (reduction and restore purposes).

Effective-Start-Date-Time	The starting date and time when a DR Asset or Resource is expected to comply with the dispatch instruction. This is referred to as the "Reduction Deadline" in teh NAESB M&V standard.	Functional	
Load-Reduction-Amount	The amount of electric power which is to be shed (reduced). Must be interpreted within the context of the Unit-of-Measure value, for example a value of 1 in this element combined with a Unit-of-Meausre value of MW would indicate a reduction of 1 megawatt is expected from a DR Asset or Resource.

A value of zero indicates that no load reductions are needed and consumption may return to normal levels. Thsi is equivalent to the  "release/recall" instruction in hte NAESB M&V standard.	Functional	
Measurement	Information provided by a DR Participant indicating consumption levels over time. A Measurement Message contains all required information needed by a System Operator to assess DR Asset or Resource Performance.	Functional	
Message-Exchange-Pattern	The means by which Dispatch information is communicated between parties. The following are valid options: 
•	In-Only 
Robust In-Only
In-Out 
Refer to http://www.w3.org/TR/wsdl20-adjuncts/#patterns for complete descriptions.	Functional	
Source-Authentication	The recipient must have some assurance that the message was produced by a reliable, authoritative party. This will require some ability to validate the authenticity of the source and integrity of the data (e.g. digital signature applied to a price message).	Functional	
Target-Identifier	A unique identifier for the DR Asset or DR Resource, as detemined by the System or Market Operator, that is the intended recipient of this dispatch instruction.	Functional	
TimeStamp	Indicates the Date and Time when the dispatch instruction was issued. MUST follow ISO 8601 standard representation.	Functional	
Unit-of-Measure	Indicates the unit of measure for which the Load-Reduction-Amount pertains. MUST be complaint with the International System of Units as defined by NIST SP 330, ref: http://physics.nist.gov/Pubs/SP330/sp330.pdf

Examples of NIST compliant units of measure include:
•	kW
MW 
	Functional	

Sequence Diagram

4.5.1 Monitor DR Event (Bulk) 

  

4.6 Dispatch DR Instructions (Distribution)
This interaction is used to dispatch DR Resources.  This type of interaction is used when the Contorlling entity needs to achieve specific objectives from the DR Resouces during DR events. This means that specific instructions will be given to the DR Resouce with obejctives (e.g. shed 100KW) for the load profile of the DR Resource. 

Note that for the retail use cases a Dispatch is considered a special type of DR Notification and thus it is very similar in nature to the requirements given for that interaction.

Dispatch Instructions	A collection of dispatch instructions that is associated with a DR event.  An instance of such instructions represents a specific type of instruction that was defined specifically for the DR program.  Each type of instruction may have a schedule of values that are valid across the entire period for then the DR event is active. Therefore a single type of instruction may have multiple values each of which are valid during a different time period during the event. Each type of instruction has the following attributes when it is defined:
•	name
instruction type

The following instruction types should be supported:
•	LOAD_LEVEL - Amount of load based on an enumeration, i.e. moderate, high, etc
LOAD_AMOUNT - Fixed amount of load to shed in KW
LOAD_PERCENTAGE - Percentage of load to shed, i.e. 10%
		
DR Program Name	Identifier of the program that this DR event was issued for.		
DR Resource ID	Identifier of the DR Resource that this dispatch is intended for.		
Event ID	Identifier for the DR event that was created when the DR event was first issued.		
Event Modification Number	Modification number of the DR event.  Used to indicate if the DR Event has been modified by the Utility. Each time it is modified this number is incremented.		
Event Schedule	Schedule for the DR Event periods. Includes the following:
•	Notification date/time
Event start date/time
Event end date/time
		
Test Event Flag	This attribute signifies whether this is a test event or not.  Test events may be issued by the Utility/ISO like other DR Events.		

Sequence Diagram

4.7 DR Direct Load Control (Distribution)
This use case covers direct interactions between the Controlling entity and a specific DR Asset for the purposes of putting that asset into a specific load control state (e.g. turn it on or off). In this case the DR Asset is a DR Resource with only one DR Asset and thus the interaction is directly with the DR Asset.

Load Address/Identifier	This is an identifier for the load which is being controlled.
Note: Is this an ID or and address? What else is needed?		
Load Control Command	This is a command to a specific load.		

Sequence Diagram

4.7.1 Monitor DR Event (DR Resource)
This interaction is used to monitor A Resource's behaviour. It may be executed as a result of the DR Resource receiving a DR signal or it may be conducted continuously.  

Operatinal Constraints	This is used to supply information about when and how a DR Resouce may participate in a DR Event. The following items may be supplied:
•	Limits on load profile performance
Schedule of participation

Note that this information may also be supplied as part fo the administration of the DR Resource and thus it may not be necessary that it be part of this interaction.		
Opt in/out state	This is used to temporarily opt in/out of DR Events and is used to over ride the normal operational constraints. The opt-in/out can be specified using the following criteria:
•	All events in a program indefinitely
Specific DR Event
All events in a specific time period

In addition there may be a schedule associated the opt in/out state.
		
Usgae Information	Information about the current electricity usage of the DR Resource.		

Sequence Diagram

4.7.2 Monitor DR Event (DR Asset)
This interaction is used to monitor the state of a DR Asset.  It may be executed as a result of the DR Asset receiving a DR signal or it may be conducted continuously.

Exception Conditions	This is used to report that the load controller may not behave as commanded because of a variety of conditions including:
•	Faults in device
Customer override
		
Load Control State	The state of the load. Includes both commanded states and user settings.  May include a schedule of future states if a particular control algorithm for the load controller is being executed.
		
Operational Constraints	Constraints on how the load maybe controlled. May include limits on the state of the load controller and also include schedules upon those constraints.		

Sequence Diagram

4.8 DR Event Execution

4.8.1 DR Execution - Dynamic Price-Based

Sequence Diagram

4.8.2 DR Execution - Notification Based

Sequence Diagram

4.8.2 DR Exedcution - Direct Load Control

Sequence Diagram

4.9 Operational Coordination between Transmission, Distribution and DR Resources

Sequence Diagram

Adjust Schedule

 

Apply Retail Uplift Charges

 

Assess Congestion Uplift Charges

 

Impacted Curcuit Analysis
Indentify impacted circuits, check againts circuit operating limites and equipment asset management contraints. 

 

Load Forecast by Circuit

 

Specify Load Profile

    

3.1.2.5	5.0 Post DR Event Management

5.0 Post DR Event Management

Figure 8: 5.0 Post DR Event Management

 

5.0 Post DR Event Management

 

5.1 Post DR Event M&V / Settlement (Open Wholesale, No Open Retail)
After DR Event has been completed, then Measurement and Verification (M&V) can take place to confirm action has been taken or measure the response.  After the M&V, then the Financial Settlement is calculated and sent to the Electricity Customer.

This Use Case covers the scenarios with an open Wholesale, but no Open Retail Markets.

Sequence Diagram

RELEASE-RECALL
DR has finished Deployment Period so calculations for M&V and Settlement can now take place. 
5.2 Post DR Event M&V / Settlement (No Open Wholesale, No Open Retail)
After DR Event has been completed, then Measurement and Verification (M&V) can take place to confirm action has been taken or measure the response.  After the M&V, then the Financial Settlement is calculated and sent to the Electricity Customer.

This Use Case covers the scenarios with no open Wholesale and no Open Retail Markets.

Sequence Diagram

RELEASE-RECALL
DR has finished Deployment Period so calculations for M&V and Settlement can now take place. 
5.3 Post DR Event M&V / Settlement (Open or Not Open Wholesale, Open Retail)
After DR Event has been completed, then Measurement and Verification (M&V) can take place to confirm action has been taken or measure the response.  After the M&V, then the Financial Settlement is calculated and sent to the Electricity Customer.

This Use Case covers the scenarios with no Open Retail Markets, and includes either Open or not Open Wholesale Markets..

Sequence Diagram

RELEASE-RECALL
DR has finished Deployment Period so calculations for M&V and Settlement can now take place.